1. Kubernetes 클러스터 계층 구조
쿠버네티스로 시스템을 구축하면 어떤 모습이 나타날까요? 이는 곧 하나의 클러스터가 될 것이고, 클러스터는 여러 대의 컴퓨터로 구성되어 있을 테며, 컴퓨터마다 상이한 애플리케이션이 올라갈 것입니다. 기능이 비슷한 애플리케이션끼리, 또는 역할이 비슷한 컴퓨터들을 그룹 지어 제어/관리하기도 할 것이구요.
추상적으로 설명하긴 했지만, 쿠버네티스의 시스템 모델은 ‘클러스터-PC(또는 노드)-애플리케이션’의 계층 구조로 그릴 수 있습니다. 아래 도식처럼 말이죠.
여기서 알 수 있는 점은,
- 클러스터 내 PC는 Master/Worker Node 두 종류로 구분
- PC(노드)마다 쿠버네티스 오브젝트를 가지고 있고, 특히 Worker Node는 ‘Pod’라는 엔티티를 관리
- Pod 안에 컨테이너, 곧 애플리케이션이 운영되고 있음
클러스터 내 구성 요소가 맡는 역할을 간단히 살펴보면 다음과 같습니다.
Cluster: 전체 시스템
├── Master Node
| ├── Kube-proxy
| ├── API-server: 다른 노드와 소통하는 주체
| ├── Etcd
| ├── Scheduler
| └── Controller
└── Worker Node
├── Kubelet
├── Kube-proxy
└── Pod
└── Container
2. Master 노드 vs Worker 노드
쿠버네티스 클러스터를 구성할 때, 제일 먼저 PC(또는, 노드)마다 고유한 역할을 부여해야 하는데요. 일차적으로 관리자에 버금가는 역할을 지닌 Master Node와 웹 애플리케이션, DB 등의 서비스가 올라가 있는 Worker Node로 우선 구분을 짓습니다.
Master Node의 역할
사용자 또는 서비스 개발자가 특정한 애플리케이션을 클러스터에 띄우거나 어떤 변경 사항을 적용하고 싶을 때, 해당 요청을 일괄적으로 받아들이는 노드가 Master입니다. Master Node는 요청을 분석해서 어떤 작업을 수행해야 하는 지를 Worker Node에게 전달합니다.
현실 사례를 빗대어 이야기해보면, 용역 업체(클러스터)에게 작업(서비스)을 발주하면 대표나 임원급의 인물들(Master Node)이 요청 사항을 먼저 검토하고, 해야 할 일들을 실무를 담당하는 직원(Worker Node)에게 던져주는 식이라 보면 이해가 쉽습니다.
Master Node는 클러스터에서 단독으로 존재할 수도 있고, 여러 대의 PC가 동시에 Master Node 역할을 맡을 수 있는데요.
보통 클러스터를 초기화할 때, 제일 먼저 Master Node의 role을 부여 받은 노드에게 대표격으로 ‘Leader Node’라는 명칭을 주기도 합니다. 그리고 Master Node 그룹을 Control Plane이라고 부릅니다.
Master Node의 구성 요소
사용자, 그리고 Worker Node와 작업 내용을 주고 받고 클러스터 상태를 감독하기 위해서 다음과 같은 구성 요소들이 포함되어 있습니다.
API server
Master Node의 프론트엔드 격으로, 내부 및 외부의 작업 요청을 처리합니다. REST 방식 또는 kubectl(쿠버네티스용 커맨드라인 인터페이스)를 통해 API server로 작업 요청을 보낼 수 있습니다.
Etcd
현재 클러스터의 상태 정보, 즉 노드부터 Pod, 각종 쿠버네티스 오브젝트와 관련된 자료들이 저장되는 데이터베이스입니다. 쿠버네티스는 Etcd에 저장된 데이터를 모니터링(Health Check)하고, 원래 유지되어야 하는 상태를 일탈한 경우, 클러스터 재구성을 수행합니다.
Etcd에 저장되는 데이터는 key-value 쌍 형태를 띠게 되며, Master Node가 여러 개인 클러스터에서는 Leader Node의 Etcd를 일관적으로 복제하여 각 Master Node에 사본을 전달하는데요. 이러한 복제 관리를 통해 클러스터의 가용성을 높일 수 있습니다.
Scheduler
작업 요청 내역에서 요구되는 CPU 및 메모리 자원을 고려하여 Worker Node에게 작업을 할당하는 컴포넌트입니다. 좀 있다가 설명할 테지만, 쿠버네티스에서 작업의 최소 단위는 ‘Pod’이며, 쿠버네티스 Scheduler는 이제 막 생성되었거나 아직 어디에도 할당되지 않은 Pod를 실행할 노드를 선택합니다.
Controller Manager
Scheduler가 Pod를 할당하고 나서, 정확한 장소에 정확한 수의 Pod가 운용되고 있는 지를 감시하는 컴포넌트입니다. 감시하는 대상을 세부적으로 4가지로 나누어 각각에 최적화된 Controller Manager가 존재합니다.
- Node Controller: 노드의 상태를 점검하고 문제 발생 시 대응
- Service Controller: 로드밸런싱, 내부 IP 배분 상태를 점검
- Endpoint Controller: 서비스와 Pod 간의 매핑 상태를 점검 (여기서 Endpoint는 일반적인 기기를 의미하는 것이 아니라 Pod를 의미)
- Replication Controller: 지정된 수의 Replica(사본)이 동작하는지 확인
CoreDNS
DNS가 호스트나 서버 식별을 위한 네임 스페이스를 관리하기 위해 설계된 것처럼, 쿠버네티스의 CoreDNS는 클러스터 안에 존재하는 Pod와 Service을 도메인 방식으로 접근할 수 있도록 돕는 애드온 기능입니다.
클러스터 외부에서 Pod와 연결이 필요할 때, 할당된 내부 IP 주소 대신 도메인 이름을 사용하여 쉽게 채널을 구성할 수 있습니다.
Worker Node의 역할
클러스터 내에서 실제로 컨테이너(애플리케이션)이 호스팅 되는 머신입니다. 쿠버네티스는 컨테이너를 기능에 따라 그룹화하여 ‘Pod’라는 단위로 배치하며, Worker Node마다 하나 이상의 Pod가 포함되어 있습니다. 물론, Master 노드도 Pod를 구성할 수 없는 건 아니지만, 일반적으로 그렇게 운용을 하지 않을 뿐이죠.
Worker Node의 구성 요소
Kubelet
Master Node의 API server와 소통하는 대변인 격인 컴포넌트입니다. 현재 노드의 상태를 보고하고, Master Node에서 제시한 작업에 따라 Pod를 운용합니다.
Kube-proxy
Node 안에서 네트워킹 규칙을 관리합니다. 내부 간, 또는 클러스터 바깥에서 Pod로의 통신을 가능케 하는 요소입니다.
Pod
컨테이너를 관리하는 최소한의 단위입니다. 쿠버네티스는 컨테이너를 하나하나 직접 배포하는 게 아니라 Pod라는 다수의 컨테이너 그룹으로 작업 명세를 생성/요청합니다.
IP 주소 역시, 컨테이너별로 할당되는 게 아니라 Pod에 할당됩니다. 같은 pod 내에 속하는 컨테이너들은 동일한 localhost를 공유하는 셈이죠.
Container Runtime
컨테이너를 실제로 생성하고 관리하는 시스템입니다. 쿠버네티스를 소개하는 그림에서 대부분 Docker 아이콘이 있어서 당연히 컨테이너를 Docker가 만들어 주리라고 생각할 수 있지만, 사실 선택지는 많습니다. Docker 엔진 외에도 containerd, cri-o가 대표적이죠.
Pod가 노드에서 실행되려면 Worker Node마다 컨테이너 런타임이 설치되어 있어야 합니다.
Pod가 생성되는 과정
Pod 생성 요청 또는 쿼리를 보내는 주체는 사용자(사람)이고 이를 일차적으로 수용하는 대상은 Master Node입니다. 따라서 사용자와 Master Node 간의 요청을 전달하고 해석할 수 있는 인터페이스가 존재해야겠죠.
kubectl이 정확하게 그 역할을 도맡고 있습니다. 사용자는 새로 추가 또는 변경하고자 하는 클러스터의 스펙(Pod 구성 같은 정보가 들어가 있음)을 YAML 파일 형태로 정의하고 쿠버네티스에 전달합니다.
이후의 작업은 일괄적으로 Master Node에서 이뤄지게 되는데요. 그 프로세스를 아래와 같이 나열할 수 있습니다.
- 사용자가 kubectl을 통해 API Server에 Pod 추가 요청
- API Server는 etcd에 업데이트 되어야 할 사항을 기록하고 Scheduler에게 pod 생성 요청이 들어왔음을 알림
- Scheduler는 API server에게 특정 node에 pod을 할당하라고 요청
- API server는 etcd에 pod을 어디에 할당할 계획인지 기록
- kubelet에서는 새로 할당된 pod이 존재하는 지 API server에게 상시로 물어보고, 그런 경우 pod을 생성하고 API server에게 pod 배치가 완료되었음을 통보