컨트롤 플레인은 쿠버네티스 클러스터의 두뇌이자 의사결정 계층으로, 워커 노드가 실제 워크로드를 돌리는 동안 전체 상태를 정의하고 조율하는 역할을 맡음 조직 비유로 보면 컨트롤 플레인은 본사와 경영진, 워커 노드는 지점과 현장 직원에 해당함 개념과 정의 컨트롤 플레인은 Desired State를 선언적으로 저장하고, Observed State와 비교해 일치하도록 끊임없이 조정하는 계층 사용자는 API를 통해 상태를 선언하고, 컨트롤 플레인은 스케줄링과 컨트롤 루프로 이를 만족하도록 시스템을 수렴시킴 핵심 구성요소 API 서버 kube-apiserver — 모든 요청의 진입점, 인증·인가·어드미션 수행 후 상태 변경을 etcd에 반영 ...
개요 쿠버네티스는 제어 평면과 워커 노드, 그리고 그 사이를 매개하는 런타임과 커널 메커니즘이 맞물려 동작하는 분산 시스템 핵심은 단일 진실 소스에 원하는 상태를 기록하고, 이를 지속적으로 감시하고 조정해 실제 상태를 일치시키는 루프 각 컴포넌트의 역할과 상호작용을 이해하면 장애 대응, 스케일링, 성능 튜닝의 기준점 확보 가능 구성요소 관계 한눈에 kubectl / CI │ ▼ kube-apiserver ──> etcd │ ▲ │ └(상태 영속) │ ├─ kube-scheduler(어디 배치할지 결정) └─ kube-controller-manager(원하는 상태로 맞춤: ReplicaSet 등) [각 워커 노드] kubelet ──(CRI gRPC)──> container runtime ──(OCI)──> runc/crun ──> cgroup 설정 + 컨테이너 시작 │ │ ├─(CNI 호출) 네트워크/IP 할당 └─ 네임스페이스/마운트 등 격리 └─ kube-proxy(서비스 라우팅: iptables/ipvs) 모든 컴포넌트의 권위자이자 입구는 apiserver etcd와 직접 통신하는 주체는 apiserver만 존재 kubelet은 apiserver를 watch하여 자신에게 배정된 파드 감지 container runtime은 OCI 런타임을 통해 cgroup과 네임스페이스를 세팅하고 컨테이너 프로세스 실행 Pod 생성에서 Running까지 사용자가 kubectl apply 등으로 Desired State를 제출하면 apiserver가 인증과 유효성, 어드미션을 거쳐 etcd에 영속화 controller-manager가 오브젝트를 관찰하고 필요한 부수 리소스를 생성, 예 ReplicaSet과 Pod 등 scheduler가 Pending 파드에 대해 노드 배치를 결정, 리소스 요청, 어피니티, 토폴로지, taint와 tolerance 등을 고려해 Pod에 NodeName 바인딩 대상 노드의 kubelet이 apiserver watch로 자신에게 할당된 파드 탐지 kubelet이 이미지 풀, 볼륨 마운트, 네트워크 준비를 순차 수행, CNI 플러그인을 호출해 인터페이스와 IP 할당 kubelet이 CRI를 통해 container runtime에 파드와 컨테이너 생성 요청 전달 runtime이 OCI 런타임 runc 또는 crun을 호출하여 cgroup 생성과 리눅스 네임스페이스 PID NET MNT UTS IPC 설정 후 엔트리포인트 실행 kubelet이 liveness readiness 스타트업 프로브로 상태를 확인하고 apiserver로 주기 보고 kube-proxy가 Service와 Endpoints 변경을 반영해 iptables 혹은 ipvs 규칙 갱신, 서비스 트래픽 라우팅 경로 성립 클러스터 DNS와 Service IP를 통해 파드로 트래픽 전달 완료 cgroup과 리소스 제한 연결 PodSpec의 resources.requests와 limits가 kubelet을 거쳐 runtime에 전달되고, runtime과 OCI가 cgroup v1 또는 v2에 실제 quota와 limit 설정 CPU는 shares와 quota를 통해 스케줄러 가중치와 시간 쿼터 부여 메모리는 hard limit과 OOM killer 점수 조정으로 커널 레벨 강제 쿠버네티스 리소스 제한의 실체는 cgroup 설정이라는 점이 핵심 장애·스케일·자체 복구 흐름 컨테이너 크래시 발생 시 kubelet이 상태를 보고하고 컨트롤러가 Desired 수를 보장하기 위해 재시작 또는 재스케줄 수행 노드가 NotReady로 전환되면 스케줄러와 컨트롤러가 파드를 다른 노드로 이동시키는 복구 경로 선택 HPA VPA 클러스터 오토스케일러 등으로 Desired State를 조정하면 동일한 조율 루프로 반영되어 자원과 파드 수가 확장 또는 축소 용어 핵심 정리 control plane apiserver 권위와 입구, scheduler 배치, controller-manager 조율, etcd 단일 진실 저장소 worker node 파드를 실제로 실행하는 머신 풀 kubelet 각 노드의 현장 에이전트, 파드 라이프사이클 관리와 apiserver 동기화 담당 container runtime kubelet 지시로 컨테이너 생성과 삭제를 수행하는 실행기, CRI 인터페이스 준수 cgroup 컨테이너 자원 격리와 제한의 커널 메커니즘, OCI 런타임이 설정 마무리 apiserver는 진실의 관문, etcd는 진실의 저장소, 스케줄러와 컨트롤러는 계획과 조율, kubelet은 현장 실행, runtime과 OCI는 컨테이너 생성, cgroup은 자원 격리 담당 ...