쿠버네티스 입문: 핵심 개념과 용어 가이드

반응형

쿠버네티스(k8s)란?

컨테이너 오케스트레이션 도구의 일종이다. 이 말은 시스템 전체를 통괄하고 여러 개의 컨테이너를 관리하는 일을 말한다.
오케스트라의 지휘자를 떠올리면 이해하기 쉽다. 지휘자가 악단을 지휘하듯, 여러 개의 컨테이너를 지휘하는 도구가 바로 쿠버네티스다.
 
쿠버네티스를 일반적인 개발자가 관리하는 일은 드물지만 쿠버네티스로 어떤 일을 할 수 있는가에 대한 지식은 시스템을 개발할 때 유용할 수 있다. 쿠버네티스로 관리되는 시스템은 이를 전제로 개발해야 한다. 그렇지 않다면 쿠버네티스의 이점을 제대로 살릴 수 없다.
 
도커는 하나의 서버에서 실행되지만 쿠버네티스는 여러 대의 서버가 존재한다는 것을 전제로 한다.
 
여러 대의 서버에서 일일이 컨테이너를 실행하고 관리하는 일은 매우 번거롭다. 예를 들면, 20개의 컨테이너를 만들려면 docker run 커맨드를 20번 실행해야 할 것이다. 어떻게든 컨테이너를 생성해 실행했다 해도 여러 대의 서버를 일일이 모니터링하며 장애가 일어나면 컨테이너를 다시 실행해야 하는 것은 물론이고 컨테이너를 업데이트하게 된다면 다시 한번 큰 수고가 따른다.
 
도커 컴포즈를 사용한다고 해도 서버가 여러 대라면 반복 작업은 사라지지 않는다.
 

쿠버네티스는 이렇게 번거로운 컨테이너 생명 주기 관리를 대신 해주는 도구다
 
 

쿠버네티스의 구성 - 마스터 노드와 워커 노드

쿠버네티스는 전체적인 제어를 담당하는 마스터 노드와 실제 동작을 담당하는 워커 노드로 구성되는데 이 것을 클러스터라고 한다.
 
마스터 노드는 컨테이너를 직접 실행하지는 않으며 워커 노드에서 실행되는 컨테이너를 관리하는 역할을 한다. 따라서 도커 엔진같은 컨테이너 엔진도 설치되지 않는다.
 
워커 노드는 실제 서버에 해당하는 부분으로 컨테이너가 실제 동작하는 서버다. 컨테이너가 동작해야 하므로 컨테이너 엔진이 설치가 되는 부분이다.
 
클러스터는 사람이 개입하지 않아도 마스터 노드에 설정된 내용에 따라 워커 노드가 관리되며 자율적으로 동작한다.

클러스터 구성

 

마스터 노드의 구성

• API 서버 (kube-apiserver): 클러스터 관리의 중심, 클러스터 내부 및 외부의 모든 API 호출을 처리한다.
• 클러스터 저장소 (etcd): etcd는 키-값 저장소 (No SQL DB) 로 클러스터의 구성을 정의하는 모든 정보들이 저장된다.
• 스케줄러 (kube-scheduler): 새로 생성된 파드를 적정한 워커 노드에 할당한다.
• 컨트롤러 매니저 (kube-controller-manager): 클러스터의 상태를 유지하는 다양한 컨트롤러를 실행한다. (노드 컨트롤러, 레플리카셋 컨트롤러, 디플로이먼트 컨트롤러 등)
• 클라우드 컨트롤러 매니저 (cloud-controller-manager): 특정 클라우드 서비스 제공업체의 환경과 쿠버네티스의 클러스터를 연동한다.

위 5가지 요소를 컨트롤 플레인이라며 컨트롤 플레인을 통해 워커 노드를 관리한다.

워커 노드의 구성

• 컨테이너 런타임 (Container Runtime): 컨테이너를 실행하기 위한 환경(도커 엔진 부분)으로 컨테이너의 생명 주기를 관리한다. 대표적인 컨테이너 런타임으로는 Docker, containerd, CRI-O가 있다. 
• kubelet: 마스터 노드에 있는 kube-scheduler와 연동하며 워커 노드에 파드를 배치하고 실행한다. 또한 실행 중인 파드의 상태를 정기적으로 모니터링해 kube-scheduler에 통지한다. (파드 생성 과정은 하단 리소스 부분에서 설명한다.)
• kube-proxy: 네트워크 트래픽을 관리한다. 매니 페스트에 정의된 서비스 내용에 따라 트래픽을 적절한 파드로 라우팅하고, 로드 밸런싱을 수행한다. 
• 네트워킹 플러그인 (CNI - Container Network Interface):  파드가 서로 통신할 수 있도록 하고, 클러스터 외부의 네트워크와 연결하는 역할을 한다. (각 파드의 IP 주소 할당 및 네트워킹 환경을 구성)

 

쿠버네티스는 항상 '바람직한' 상태를 유지한다.

쿠버네티스도 컨테이너를 수동으로 생성하거나 삭제할 수 있지만 일일이 명령어를 입력하는 방식을 사용하지는 않는다.
"컨테이너는 oo개, 볼륨은 xx개로 구성하라"와 같이 매니 페스트 파일에 정의하고 자동으로 컨테이너를 생성하거나 삭제하면서 이 상태를 만들려고 하는 것이 쿠버네티스이다.
 
이렇게 설명하면 도커 컴포즈와 구별이 잘 가지 않을 수도 있겠지만 도커 컴포즈는 옵션을 지정해 수동으로 컨테이너의 수를 바꿀 수는 있어도 모니터링 기능이 없어서 컨테이너를 만들 때 외에는 관여하지 않는다. 이에 비해 쿠버네티스에는 이 상태를 유지하는 기능이 있다. 수동으로 컨테이너를 삭제해도 매니페스트 파일에 정의된 내용대로 재 생성한다.
 
 

쿠버네티스 구성과 관련된 용어들

리소스

파드, 서비스, 레플리카셋, 디플로이먼트 등 쿠버네티스에서 컨테이너 관리를 목적으로 매니페스트 파일(주로 YAML)에 작성되는 추상적인 개념이다. 기본적인 리소스만 해도 30개 이상되지만 주요 리소스 3가지만 정리해봤다.
 

파드(Pod): 매니 페스트에 정의되고 워커 노드 내에 생성된다. 쿠버네티스에서 가장 기본이 되는 배포 단위. 

파드의 생성 과정

1. 파드 정의: 사용자는 파드는 매니페스트 파일에 정의한다. 이 파일에는 실행할 컨테이너, 필요한 볼륨, 네트워크 설정 등을 포함한다.
2. API 서버에 전송: 사용자가 전송한 매니페스트 파일은 쿠버네티스 API 서버에 전송(kubectl apply 명령어) 되어 파드 생성 요청을 한다. 
3. 스케줄링: 쿠버네티스 스케줄러는 파드를 실행할 적절한 워커 노드를 선택한다.
4. 컨테이너 생성: 선택된 워커 노드의 kubelet은 파드 정의에 따라 컨테이너 런타임을 사용하여 컨테이너를 생성하고 실행한다.
5. 볼륨 마운트: kubelet은 파드에 정의된 볼륨을 컨테이너에 마운트 한다. 이 볼륨은 워커 노드의 스토리지 시스템(예: 로컬 디스크, 네트워크 스토리지 등)에서 제공된다.
6. 파드 구성: 생성된 컨테이너(들)과 마운트된 볼륨(들)을 함께 묶어 파드를 구성한다. 아래 명령어로 현재 클러스터 내의 파드 목록을 확인할 수 있다. 만약 파드가 성공적으로 생성되었다면 파드의 상태는 Running이어야 한다.

 
 

서비스(Service): 매니 페스트에 정의되고 쿠버네티스 마스터 노드의 API 서버 내에 생성된다.

서비스 생성 과정

1. 서비스 정의: 사용자는 서비스에 대한 설정을 매니페스트 파일에 정의한다. 이 파일에는 서비스의 타입, 선택기(selector), 포트 설정 등의 정보가 포함한다.
2. API 서버에 전송: 사용자가 전송한 매니페스트 파일은 쿠버네티스 API 서버로 전송되어 API 서버 내에서 서비스 오브젝트를 생성하고 서비스의 정보는 클러스터의 etcd에 저장한다.
3. 서비스 생성: 서비스가 생성되면 그 정보는 API 서버를 통해 클러스터 내에 전파된다. 워커 노드 내의 kube-proxy는 이 정보를 수신하여 서비스에 대한 네트워크 요청을 적절한 파드로 전달한다.
4. 서비스 사용: 생성된 서비스는 이제 클러스터 내부 또는 외부에서 해당 서비스의 이름 또는 IP를 통해 접근할 수 있게 된다. 이렇게 접근하는 경우 마스터 노드의 API 서버를 거치지 않고 직접 서비스에 도달할 수 있다. 서비스는 지정된 포트를 통해 들어오는 요청을 연결된 파드로 전달한다.

 
 

레플리카셋(replicasets): 매니 페스트에 정의되고 파드의 수를 관리한다

1. 레플리카셋 정의: 사용자는 레플리카셋에 대한 설정을 매니페스트 파일에 정의한다. 이 파일에는 레플리카셋의 이름, 복제본의 수, 레플리카셋이 관리할 파드의 템플릿이 포함된다. 
2. API 서버에 전송: 사용자가 전송한 매니페스트 파일은 쿠버네티스 API 서버로 전송되어 API 서버 내에서 레플리카셋 오브젝트를 생성하고 레플리카셋의 정보는 클러스터의 etcd에 저장한다.
3. 스케줄링 및 파드 생성: 쿠버네티스 마스터의 컨트롤 플레인은 레플리카셋 매니페스트를 읽고 지정된 수와 파드 복제본을 유지허기 위해 필요한 파드 생성 명령을 워커 노드에 전달한다. 파드 스케줄러가 이 파드들을 클러스터 내의 적절한 노드에 할당한다.
4. 레플리카셋 관리: 레플리카셋은 지정된 수의 파드 복제본이 항상 실행되고 있음을 보장한다. 어떤 파드가 실패하거나 삭제되면, 레플리카셋은 자동으로 새 파드의 생성, 교체 명령을 전달 한다.

 

디플로이먼트(Deployment): 매니페스트 파일에 정의되는 파드(Pod)와 레플리카셋(ReplicaSet)을 관리하기 위한 고 수준의 리소스. 디플로이먼트를 사용하면 배포, 스케일링, 업데이트 및 롤백을 보다 쉽고 안정적으로 관리할 수 있다.

디플로이먼트 생성 과정

1. 디플로이먼트 정의: 사용자는 디플로이먼트에 대한 설정을 매니페스트 파일에 정의한다. 이 파일에는 파드 템플릿, 복제본 수, 업데이트 전략 등이 포함된다.
2. 디플로이먼트 생성: 사용자가 전송한 매니페스트 파일은 쿠버네티스 API 서버로 전송되어 API 서버 내에서 디플로이먼 오브젝트를 생성하고 디플로이먼트의 정보는 클러스터의 etcd에 저장한다.
3. 레플리카셋 생성 및 파드 배포: 디플로이먼트는 자체적으로 하나 이상의 레플리카셋을 생성한다. 각 레플리카 셋은 디플로이먼트가 정의한 템플릿에 따라 파드를 생성하고 관리한다.
4. 업데이트 및 롤백: 디플로이먼트는 새로운 버전으로의 업데이트를 자동으로 롤아웃하고, 문제가 발생하면 이전 버전으로 롤백할 수있다.