쿠버네티스 코어 아키텍처 — 조정 루프
kubectl apply부터 자가 치유까지 — API 서버·etcd·컨트롤러·스케줄러·kubelet이 '기대 상태'라는 한 점을 바라보며 각자 루프를 도는 것을 실행한다.
1 / 10쿠버네티스의 심장은 하나의 문장입니다 — "기대 상태를 선언하면, 조정 루프가 실제를 그쪽으로 끌고 간다." 파드 3개짜리 Deployment를 선언해 봅니다.
kubectlAPI 서버etcd컨트롤러스케줄러kubelet
node-1
파드 없음
node-2
파드 없음
etcd 기대 상태: replicas 0 · 실행 중 0
단계 목록 · 키보드 ←/→ 이동, Space 재생
쿠버네티스는 명령을 실행하는 시스템이 아니라, '기대 상태(etcd)와 실제 상태의 차이'를 쉬지 않고 없애는 조정 루프들의 집합이다.
왜 헷갈리는가
kubectl을 원격 명령 도구로 이해하면 모든 게 이상해진다 — 죽인 파드가 되살아나고, apply가 '실행'이 아니라 '제출'이고, 장애 복구를 아무도 명령하지 않는다. 열쇠는 명령형이 아니라 선언형 + 조정 루프라는 한 가지 발상이다.
애니메이션이 보여주는 것 — 부품별 한 가지 책임
kubectl은 '원하는 상태 문서'를 제출할 뿐이다. API 서버는 유일한 정문(인증·검증)이고, etcd만이 진실을 갖는다. 컨트롤러 매니저는 기대와 실제의 차이를 보고 파드를 만들거나 지우고, 스케줄러는 배정되지 않은 파드에 노드를 골라 주며, 각 노드의 kubelet이 실제 컨테이너를 띄우고 상태를 보고한다.
핵심 장면은 새벽 3시의 파드 사망이다. 누구도 명령하지 않지만 루프가 '기대 3, 실제 2'를 발견하고 채운다 — 자가 치유는 마법이 아니라 차이 해소 루프의 부수 효과다.
이 관점이 풀어 주는 실무 수수께끼
운영 중 마주치는 현상 대부분이 조정 루프로 설명된다.
- kubectl delete pod 했는데 되살아남: 파드는 ReplicaSet의 기대 상태의 산물이다. 원본(Deployment)을 지워야 안 돌아온다.
- Pending에 멈춘 파드: 스케줄러가 조건(자원·테인트·어피니티)에 맞는 노드를 못 찾은 것 — kubectl describe의 Events가 그 이유를 말한다.
- 컨트롤 플레인이 죽어도 서비스는 돈다: kubelet과 이미 뜬 컨테이너는 노드에 있다. 다만 새 배포·복구(루프)가 멈출 뿐이다.
- GitOps(Argo CD)는 같은 패턴의 확장: git이 기대 상태, 클러스터가 실제 상태, Argo가 조정 루프 — 쿠버네티스 발상의 재귀 적용이다.
- Operator/CRD: '기대 상태 + 조정 루프' 패턴을 내 도메인(DB 클러스터 등)에 확장하는 공식 통로.
기억할 것
- 명령이 아니라 선언 — apply는 실행이 아니라 기대 상태 제출이다.
- etcd만 진실을 갖고, API 서버만 정문이며, 나머지는 전부 루프다.
- 자가 치유 = '기대 vs 실제' 차이 해소의 부수 효과.
- 파드가 되살아나면 그 파드의 '기대 상태 원본'(Deployment)을 찾아라.
- GitOps와 Operator는 같은 조정 루프 발상의 확장이다.