쿠버네티스 개념 정리

쿠버네티스를 들어가기 전에 도커의 문제점으로 제기되는 이슈들을 이해할 필요가 있습니다. 

도커의 단점 : 
♣ 개발 서버와 운영 서버를 오가며 운영해야 하는 번거로움이 있다.  
♣ 컨테이너들이 정상 운영되는지 지속적으로 감시해야 한다.  
♣ 리소스 현황 파악이 어렵다. 엔지니어가 여러 서버와 마이크로서비스 배포 조합수를 계산하는 데에 한계가 있다.

 

쿠버네티스의 장점
⊙ 자동화된 빈 패킹 (bin packing) - 각 컨테이너가 필요로 하는 CPU와 메모리를 쿠버네티스에게 지시하여 리소스를 잘 사용할 수 있도록 합니다. 

⊙ 자동화된 복구 (self-healing) - 실패한 컨테이너 재시작, 컨테이너 교체, 사용자가 정의한 엔드포인트로 상태 검사를 통해 자동 kill & 재시작을 할 수 있습니다. 

⊙ 자동화된 롤아웃과 롤백이 가능합니다. 

 

쿠버네티스 개념 
: 쿠버네티스는 여러개의 컨테이너화된 애플리케이션을 여러 서버(쿠버네티스 클러스터)에 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다. 
- 이름의 유래 : 그리스어로 "조타수"이며 주어진 명령을 핸들에 반복 실행해야 한다는 의미가 내포되어 있습니다. 

 

---

▶사용자 의도 : 어떤 어플리케이션을 얼마나 어디에 어떤 방식으로 배포할 것 인지를 정의 

▶의도 정의 방법 : 쿠버네티스 오브젝트로 정의하며 오브젝트 종류에 따라 정의할 수 있는 속성이 달라집니다. 
     쿠버네티스 오브젝트란 : 쿠버네티스 클러스터를 이용해 애플리케이션을 배포하고 운영하기 위해 필요한 모든 쿠버네티스 리소스입니다. 

▶표현 방식 : YAML 형식 
작성 예시 :

apiVersion: apps/v1                  # 오브젝트를 생성할 때 사용하는 API 버전 
kind: Deployment                     # 생성하고자 하는 오브젝트 종류 
metadata:                            # 오브젝트를 구분 지을 수 있는 정보  ( name, labels, namespace..)
	name: nginx-deployment
spec:                                # 사용자가 원하는 오브젝트 상태 
	selector:
	replicas: 2 
	template:

▶전달 형식 : REST API 

---

 

🔍쿠버네티스의 상태를 통해 사용자 의도를 확인 가능
예시 ( ※ 경우의 수에 따라 해석이 다를 수 있습니다. ) : 

현황 :
현재 클러스터에는 10개의 node에 5개의 namespace가 있으며 50개의 Deployment를 이용해 애플리케이션을 배포하고 있으며 Replicaset은 3이며 Rolling Update를 실행하고 있다. 

해석 : 
서버는 10대를 운영하고 있으며 5개의 서비스 그룹으로 눠져 있고 마이크로서비스가 대략 50개 정도이며 Pod는 3개씩 생성되며 새로운 버전을 배포하면서 이전 버전을 종료시켜 서비스 다운 타임을 최소화하고 있다.