[Kubernetes] 컨트롤플레인 개념

쿠버네티스의 컨트롤플레인

쿠버네티스(Kubernetes) 아키텍처에서 컨트롤 플레인(Control Plane)은 클러스터 전반의 ‘두뇌’ 역할을 수행하는 핵심 컴포넌트들의 집합임.

즉, 워커 노드(Worker Node)와 파드(Pod)를 비롯한 모든 리소스를 제어하고 관리하는 중앙 집행부라고 볼 수 있음.

컨트롤 플레인의 주요 목적은 클러스터 상태를 파악하고(상태 관리), 요청에 따른 적절한 자원 할당(스케줄링), 리소스의 원하는 상태(Desired State) 보장을 통해 전체 클러스터가 정상적으로 동작하도록 유지 및 관리하는 데 있음.

 

주요 구성 요소 : kube-apiserver

1. 역할

쿠버네티스의 프런트엔드(Front-end) HTTP/REST API 역할을 수행함.

모든 요청(클라이언트, 내부 컴포넌트, Kubelet 등)은 반드시 kube-apiserver로 들어오며, kube-apiserver를 통해 인증(Authentication), 인가(Authorization), 어드미션 컨트롤(Admission Control) 등의 단계를 거침.

쿠버네티스 객체(CRD, Deployment, Service, etc.) 생성, 조회, 수정, 삭제 등 대부분의 작업이 kube-apiserver에 의해 처리됨.

 

2. 특징

Scale-out을 위해 여러 개의 kube-apiserver 인스턴스를 구성할 수 있으며, 외부 로드밸런서를 통해 트래픽을 분산시킴.

모든 상태 정보는 etcd에 영구 저장되므로 kube-apiserver는 Stateless하다고 볼 수 있음.

 

주요 구성 요소 : etcd

1. 역할

쿠버네티스 상태(모든 리소스 메타데이터, 구성 정보 등)의 영구 데이터 저장소(Key-Value Store)임.

클러스터 내의 모든 리소스 정보(파드, 서비스, 시크릿, 컨피그맵, 네임스페이스, RBAC 등)가 etcd에 저장됨.

 

2. 특징

일관성과 고가용성을 보장하는 분산 Key-Value 스토어로, Raft 합의 알고리즘을 통해 리더 선출 및 데이터 복제를 수행함.

스냅샷(Snapshot) 및 백업/복구가 매우 중요함.

etcd가 정상 동작하지 않으면 컨트롤 플레인이 동작하지 못하게 됨.

성능 및 안정성을 위해 디스크 I/O 및 네트워크 속도에 민감하며, 프로덕션 환경에서 별도의 노드(혹은 별도의 디스크)를 두어 관리하는 것이 좋음.

 

주요 구성 요소 : kube-controller-manager

1. 역할

쿠버네티스에서 실행되는 여러 컨트롤러(Controller)를 통합하여 실행하는 프로세스임.

각 컨트롤러는 클러스터의 실제 상태를 사용자가 의도한 상태(Desired State)와 동일하게 유지하기 위해 동작함.

예를 들어, 레플리카셋(ReplicaSet) 컨트롤러, 노드 컨트롤러, 서비스 컨트롤러, 디플로이먼트 컨트롤러 등이 있음.

 

컨트롤러는 일반적으로 다음과 같은 단계로 동작함.

kube-apiserver를 통해 현재 쿠버네티스 리소스 상태를 감지(Watch).

실제 상태와 원하는 상태가 다를 경우, 이를 일치시키기 위한 액션(파드 생성/삭제, 노드 태깅 등)을 수행.

작업 결과를 다시 kube-apiserver에 반영.

 

2. 특징

여러 컨트롤러가 병렬적으로 동작하지만, 모두 하나의 프로세스(kube-controller-manager) 내에서 실행됨.

고가용성을 위해 여러 노드에 kube-controller-manager를 띄우더라도, 오직 한 인스턴스만 활성(Active) 상태로 실제 작업을 수행하며, 나머지는 대기(Standby) 상태로 동작함.

 

주요 구성 요소 : kube-scheduler

1. 역할

파드를 어떤 노드에 할당할지를 결정하는 스케줄링 로직을 담당함.

CPU, 메모리, 디스크, 네트워크, 태인트(Taint)·톨러레이션(Toleration), 노드 어피니티(Node Affinity) 등 다양한 스케줄링 요구사항을 고려하여, 각 파드를 배치할 최적의 노드를 선택함.

 

2. 특징

스케줄러는 노드 리소스와 파드 요구사항을 매칭하여 효율적인 자원 활용을 극대화함.

쿠버네티스 1.19+ 버전부터는 스케줄링 플러그인(Plugin) 프레임워크를 통해 커스텀 로직(프로필 기반, 예약/바인딩 단계 등)을 추가할 수 있음.

여러 대의 kube-scheduler를 구성할 수 있지만, 한 번의 스케줄링 이벤트는 특정 스케줄러 인스턴스가 담당하여 처리함.

 

주요 구성 요소 : cloud-controller-manager

1. 역할

클라우드 환경(예: AWS, GCP, Azure 등)에서 노드, 볼륨, 로드밸런서 등의 리소스 연동을 처리하는 전담 컨트롤러 프로세스임.

쿠버네티스 1.6 이후부터 컨트롤 플레인과 클라우드 벤더별 로직이 분리되어, cloud-controller-manager가 담당하게 됨.

 

2. 특징

퍼블릭 클라우드 환경에서는 노드 자동 등록, LB 생성, 스토리지 볼륨 연결 등이 자동으로 이루어짐.

온프레미스 환경에서는 필요하지 않을 수도 있음(혹은 외부 CSI, CCM 모듈 사용).

 

동작 메커니즘 요약

1. 사용자(또는 내부 컴포넌트)의 요청

kubectl CLI나 UI, 혹은 내부 프로세스 등이 API 요청을 보냄

모든 요청은 kube-apiserver를 통해 인증, 인가, 어드미션 컨트롤 단계를 거친 후 처리됨

 

2. 데이터 저장

kube-apiserver는 등cd(또는 etcd 클러스터)에 쿠버네티스 오브젝트 상태를 읽고/쓰면서 현재 상태를 갱신

 

3. 컨트롤러 동작

kube-controller-manager 내 여러 컨트롤러는 kube-apiserver를 관찰(Watch)하고, 원하는 상태와 실제 상태가 어긋나면 자동으로 맞춤

파드가 부족하면 새로운 파드 생성, 필요 없는 파드는 제거 등

 

4. 스케줄링

새로 생성된 파드는 아직 어떤 노드에도 할당되지 않은 상태(Unscheduled)가 되며, 이를 kube-scheduler가 감지하여 자원 조건, 어피니티 등을 고려해 적절한 노드에 할당

 

5. 노드(워커 노드)에서 파드 실행

스케줄링이 완료되면 해당 노드의 kubelet이 파드를 실제로 실행하고 상태를 모니터링

 

고가용성 구성

컨트롤 플레인은 한 곳에서 장애가 나도 전체 클러스터가 중단되지 않도록 고가용성 구성을 갖출 수 있음.

 

1. kube-apiserver 다중화

보통 3개 이상의 컨트롤 플레인 노드(각 노드마다 kube-apiserver 실행)를 두고, 외부 로드밸런서를 통해 API 요청을 분산시킴.

모든 kube-apiserver 인스턴스는 동등하게 동작하며, etcd를 공유함으로써 스테이트리스하게 확장 가능함.

 

2. etcd 클러스터링

3개 이상의 etcd 인스턴스를 구성하여 리더 선출 및 데이터 복제를 통해 장애 대응력을 높임.

반드시 홀수 개로 구성해야 과반(Voting Majority)을 이룰 수 있습니다(3, 5, 7개 등).

고성능 스토리지(SSD)와 빠른 네트워크가 권장됨.

 

3. kube-controller-manager & kube-scheduler 다중화

여러 컨트롤 플레인 노드에서 각각 실행되지만, 내부적으로 리더 선출을 통해 단 한 개만이 Active하게 동작함.

Active 컨트롤러 또는 스케줄러 인스턴스가 장애가 발생하면, Standby 인스턴스가 자동으로 리더 역할을 승계함.

 

4. 클라우드 환경 별 특성 고려

클라우드 LB(AWS ELB, GCP LB 등)나 내부 로드밸런서(HAProxy, Nginx, Keepalived 등)를 통해 HA를 구현함.

벤더별 CCM(Cloud Controller Manager)을 사용 시 노드 자동 등록/해제, LB 프로비저닝 등이 자동화됨.

 

컨트롤 플레인과 워커 노드의 분리

프로덕션 환경에서는 컨트롤 플레인 노드와 워커 노드(Worker Node)를 물리적으로(혹은 논리적으로) 분리하여 배포하는 것이 일반적임.

컨트롤 플레인 노드에서는 앞서 언급한 주요 구성 요소들이 실행되며, 보안, 네트워크, 리소스 분리 등의 이유로 일반 워크로드(파드)를 실행하지 않는 편이 좋음.

소규모 테스트 환경(예: Minikube 등)에서는 하나의 노드에 컨트롤 플레인과 워커 역할이 통합되어 동작할 수도 있음.

 

모범 사례 및 고려 사항

1. etcd 백업 및 모니터링

정기적인 스냅샷 백업과 로그 모니터링이 필수임.

etcd 장애 시 전체 클러스터의 정상 동작이 불가능하므로, 복구 계획을 미리 수립해야 함.

 

2. 리스소 할당 및 모니터링

kube-apiserver, kube-scheduler, kube-controller-manager 모두 CPU와 메모리 사용량을 모니터링하며 적절한 리소스 리미트/리소스 요청 설정이 권장됨.

Node를 확장하거나 Scale-out이 필요한 시점을 모니터링 지표를 통해 정교하게 관리함.

 

3. 인증/인가/보안 정책

RBAC(Role-Based Access Control) 설정, 네트워크 정책, Pod Security Policy(현재는 PSP에서 PSA로 대체) 등을 통해 보안을 강화해야 함.

kube-apiserver 접근을 제어하기 위해서 mTLS, 방화벽, VPN 등 다양한 보안 레이어를 갖춤.

 

4. 버전 관리 및 업그레이드 전략

컨트롤 플레인 컴포넌트부터 순차적으로(주로 etcd → kube-apiserver → 컨트롤러 매니저/스케줄러 → 워커 노드) 업그레이드하는 전략이 일반적임.

HA 구성 시, 한 노드씩 롤링 업그레이드 형태로 진행해 클러스터 다운타임을 최소화할 수 있음.

 

5. 로깅 및 관찰(Observability)

컨트롤 플레인 로그를 모두 중앙화된 로깅 시스템(예: Elasticsearch, Loki 등)에 수집하고, 모니터링 툴(예: Prometheus, Grafana)과 연동해 상태를 관찰함.

이벤트(Event) 정보를 통해 Pods/Nodes/Controllers의 이상 징후를 빠르게 감지하고 대응함.

 

정리

쿠버네티스 컨트롤 플레인은 클러스터 리소스를 효율적으로 관리하고, 사용자의 의도(Desired State)를 자동으로 유지하는 핵심적인 역할을 수행함.

컨트롤 플레인을 이해한다는 것은 곧 쿠버네티스의 동작 메커니즘을 깊이 이해하는 것과 같음.

주요 사항으로는 다음과 같음.

 

1. 주요 컴포넌트(kube-apiserver, etcd, kube-controller-manager, kube-scheduler 등)의 구체적인 동작 원리

2. HA 구성(멀티 컨트롤 플레인, etcd 클러스터링) 및 장애 대응 전략

3. 보안 및 리소스 관리, 업그레이드 절차 등 운영 시 필수 고려사항

4. 실시간 모니터링(Observability) 및 자동화(Infra as Code, GitOps 등) 전략

 

이러한 요소들을 종합적으로 설계하고 운영하는 것이 쿠버네티스 컨트롤 플레인을 안정적이고 효율적으로 다루는 핵심으로 볼 수 있음.