[쿠버네티스] Control Plane 상세 분석: API Server, Scheduler, Controller Manager, etcd

쿠버네티스의 Control Plane 상세 분석

쿠버네티스를 실무에서 안정적으로 운영하고 장애에 유연하게 대응하기 위해서는 컨트롤 플레인을 우리의 의도대로 동작시키고 조율하는 능력이 필수적입니다. 오늘은 마스터 노드를 구성하는 4대 핵심 컴포넌트의 역할과 실제 동작 흐름을 파악하고, 심층적으로 파헤쳐 보겠습니다.

스케줄러는 생성된 Pod를 실시간으로 감지하여, 리소스 상태와 제약 조건을 분석해 가장 적합한 Node를 선정(Binding)하는 “배포 담당자” 입니다.

👉 Pod 생성 시 어떤 노드가 최적 배치인지 결정
👉 노드들에게 점수(0~100점)를 매겨 등수를 매겨 최적의 노드 선출

👉 API Server에게 해당 Pod가 배포될 선출 노드 정보를 전달
👉 리소스 상황(CPU, 메모리), 정책 등을 고려해서 스케줄링

 

 

컨트롤러는 끊임없이 현재 상태(Current State)를 감시하고, 이를 사용자가 정의한 희망 상태(Desired State)와 일치시키기 위해무한히 반복(Reconcile Loop)하는 “자동화 상태 관리자”입니다.

👉 현재 배포된 Pod현황을 API Server를 통해 확인
👉 Deployment, ReplicaSet의 라이프사이클 및 스케일링 관리

👉 노드 상태 모니터링 및 장애 시 Node Lifecycle 관리

👉 ServiceAccount 관리

 

API 서버는 클러스터의 유일한 진입점(Entrypoint)으로서, 모든 요청의 인증과 인가 및 무결성 검증을 수행하고
etcd와 데이터를 주고받는 유일한 창구 역할을 하는 게이트웨이 입니다.

👉 쿠버네티스의 핵심 진입 점 (kubectl api call에 대한 응답)
👉 외부 리소스에 대한 인증/인가 접근제어
👉 Yaml 문법,필드 등을 최종 검증하고 etcd에 데이터를 기록

👉 etcd와 직접 통신하는 유일한 컴포넌트

👉  데이터를 실시간으로 빠르게 처리하는 컴포넌트기 때문에 성능에 민감

 

etcd는 클러스터의 모든 설정과 상태 데이터가 저장되는 원천 데이터 저장소이자, 분산 환경에서도 데이터의 강력한 일관성을 보장하는 고가용성 Key-Value 저장소입니다.

 
👉 클러스터의 모든 설정 정보를 저장하는 Data Store
👉 DB와 유사하게 데이터를 저장하기 때문에 Disk I/O 및 Memory에  민감
👉 데이터는 Key – Value 방식으로 저장
👉 동시성은 MVCC (Multi-Version Concurrency Control)로 구현
👉 Compaction(압축) / Defrag(조각 모음)라는 두 단계로 나누어 처리

 

PostgreSQL과 유사하게 WAL 트랜잭션 로그를 먼저 기록하여 스냅샷으로 저장하며, etcd는 핵심 컴포넌트기 때문에 운영자는 주기적으로 snapshot save을 남겨 형상관리가 필요합니다.

etcd는 RDBMS와 유사한 WAL(로그 선기록) 방식으로 데이터 무결성을 보장하며, 운영자는 주기적인 스냅샷(Snapshot)을 통해 클러스터 재해 복구(DR) 체계를 확립해야 합니다.

 

Red Hat OpenShift나 바닐라 쿠버네티스를 커스텀하여 구축한 대부분의 엔터프라이즈 PaaS 플랫폼들은 서비스의 무중단 운영을 위해 마스터 노드를 기본적으로 다중화(High Availability, HA) 하여 구성합니다. 마스터 노드가 클러스터의 단일 장애점 이 되는 것을 막기 위함이죠.

 

 

쿠버네티스의 Work Node 상세 분석

지금까지 살펴본 마스터 노드(Control Plane)는 클러스터를 관리하고 유지하는 핵심 통제 영역으로, 쿠버네티스 운영자가 가장 중요하게 관리해야 하는 인프라 영역입니다.

그렇다면 우리가 개발한 애플리케이션은 어디에서 실행될까요? 바로 워커 노드 입니다.

워커 노드는 애플리케이션 컨테이너를 담고 있는 파드(Pod) 가 배치되어 실제 서비스 트래픽을 처리하는 실행 영역입니다. 개발자의 비즈니스 로직과 서비스가 사용자에게 전달되는 무대라고 볼 수 있습니다.

운영자가 마스터 노드를 통해 클러스터의 안정성과 가용성을 책임진다면, 개발자는 워커 노드 위에서 애플리케이션이 효율적으로 동작할 수 있도록 파드를 설계해야 합니다. 이제 파드가 생성되고 실행되는 과정을 통해 Control Plane과 Data Plane이 어떻게 협력하는지 살펴보겠습니다.

Kubelet은 각 노드에 배치된 관리 에이전트(Node Agent)로서, API Server의 파드 명세를 받아 컨테이너 런타임(CRI)을 통해 실제 컨테이너를 실행하고 상태 진단(Probe) 결과를 API에게 전달하는 “실행 책임자” 입니다.

👉 Kubelet은 각 노드에 하나씩 할당
👉 API Server를 통해 요청을 받으며, 요청 받은 행위를 처리
👉 Liveness, Readiness, Startup을 통한 컨테이너 상태 진단
👉 내장된 cAdvisor를 통해 노드/컨테이너의 리소스 사용량 및 상태를 API Server에 보고

kube-proxy는 API Server를 감시하며 Service와 Endpoint의 변경 사항을 리눅스 커널 레벨(iptables/IPVS)의 규칙으로 실시간 변환하여 가상의 Service IP로 들어온 트래픽을 실제 Pod IP로 연결하는 “네트워크 관리자”입니다.

👉 API Server를 watch 후 service & endpoint 변경 감시
👉 노드의 커널 레벨의 NAT Rule 라우팅 관리
👉 실제 트래픽이 들어오면 커널 레벨에 트래픽 연결 및 부하 분산

 

 

Container Runtime은 Kubelet의 요청을 받아 이미지 풀링 및 관리를 수행하고, 실제 프로세스를 생성하는 “컨테이너 실행 엔진” 입니다.

👉 실제로 이미지를 Pull하고, 컨테이너를 실행하며, 중지하는 동작은 모두 컨테이너 런타임이 담당
👉 CRI 표준 규격만 맞추면 어떠한 컨테이너 플랫폼도 컨테이너 런타임으로 활용 가능

Kubernetes : ContainerD를 표준 CRI로 사용

OpenShift  : CRI-O를 표준 CRI로 사용

오늘은 쿠버네티스의 "뇌" 역할을 하는 마스터 노드와, "손과 발"이 되어 실제 애플리케이션을 구동하는 워커 노드의 조화로운 아키텍처를 학습했습니다.

 

마스터 노드는 클러스터의 제어 흐름과 데이터 정합성을 관리하고, 워커 노드의 파드는 애플리케이션이 서로 분리되어 독립적으로 실행될 수 있도록 보장합니다.