"배포했는데 왜 안 되죠?"
"스케일링이 이상해요!"
"이 파드는 왜 자꾸 죽는 거죠…?"
쿠버네티스를 처음 만난 개발자라면 누구나 한 번쯤 이런 혼란과 마주하게 됩니다. YAML 파일 몇 줄로 복잡한 애플리케이션을 배포하는 과정이 마치 마법처럼 느껴지기도 하죠. 하지만 이 '마법' 뒤에는 컨트롤 플레인 → 워커 노드 → 지속적 조정(Reconciliation)으로 이어지는 정교한 내부 메커니즘이 숨어 있습니다. 이 흐름을 이해한다면, 쿠버네티스가 어떻게 자가 치유(Self-healing)하고 오토스케일링(Autoscaling)하는지 그 비밀을 명쾌하게 파악할 수 있습니다.
이 글에서는 쿠버네티스의 내부 작동 원리를 핵심 컴포넌트 중심으로 살펴보고, 매니페스트 파일 한 줄이 실제 실행 중인 컨테이너로 변환되는 여정을 따라가 보겠습니다.
1. 쿠버네티스 클러스터 한눈에 보기: 지휘자와 연주자들
쿠버네티스는 기본적으로 컨트롤 플레인(Control Plane)과 다수의 워커 노드(Worker Nodes)로 구성된 분산 시스템입니다. 마치 오케스트라처럼, 컨트롤 플레인이 지휘자(두뇌) 역할을 하며 클러스터 전체의 "원하는 상태"를 기억하고 조율하면, 워커 노드들이 연주자(실행부)가 되어 실제 애플리케이션 컨테이너(파드)를 구동합니다.
2. 시작점: 매니페스트 파일 – "바람직한 상태"를 선언하다
모든 쿠버네티스 작업은 개발자가 매니페스트(Manifest) 파일을 작성하는 것에서 시작됩니다. 주로 YAML 형식으로 작성되는 이 파일에는 애플리케이션이 어떤 모습으로 실행되어야 하는지, 즉 "바람직한 상태(Desired State)"가 명시적으로 선언됩니다.
- 사용할 컨테이너 이미지는 무엇인가?
- 복제본(Replica)의 수는 몇 개로 할 것인가?
- 노출할 포트 번호는 무엇인가?
- 필요한 환경 변수나 볼륨 마운트는 어떻게 설정할 것인가?
이 매니페스트 파일은 kubectl apply -f deployment.yaml과 같은 명령어를 통해 쿠버네티스 클러스터로 제출됩니다. 이 순간부터 매니페스트 파일에 담긴 "바람직한 상태"를 현실로 만들기 위한 쿠버네티스의 여정이 시작되는 것이죠.
# 예시: 디플로이먼트 매니페스트 파일을 클러스터에 적용
kubectl apply -f deployment.yaml3. 컨트롤 플레인: 클러스터의 지휘 본부 – 4대 핵심 컴포넌트
매니페스트 파일이 제출되면, 가장 먼저 도착하는 곳이 바로 클러스터의 두뇌 역할을 하는 컨트롤 플레인입니다. 컨트롤 플레인은 다음과 같은 핵심 컴포넌트들로 구성되어 클러스터 전체를 지휘하고 통제합니다.
| 컴포넌트 | 핵심 역할 |
|---|---|
| API 서버 (API Server) | 클러스터의 유일한 프론트엔드. 모든 내부/외부 통신의 관문. 인증/인가/어드미션 컨트롤 수행 및 상태 저장/조회. |
| 스케줄러 (Scheduler) | 새로 생성된 파드(Pod)를 "어느 워커 노드에 배치할지" 결정. (자원 현황, 어피니티/톨러레이션 등 고려) |
| 컨트롤러 매니저 (Controller Manager) | 클러스터의 실제 상태와 원하는 상태를 지속적으로 비교하며, 차이가 발생하면 이를 자동으로 맞추는 조정 루프 실행. |
| etcd | 클러스터의 모든 설정 정보와 현재 상태를 저장하는 고가용성 분산 Key-Value 데이터베이스. (쿠버네티스의 기억 장치) |
컨트롤 플레인은 etcd에 저장된 클러스터의 현재 상태를 지속적으로 읽고, 사용자가 제출한 "바람직한 상태"와 비교합니다. 만약 차이가 감지되면, "워커 노드야, 파드 하나 더 실행해!" 또는 "이 파드는 스펙이 변경되었으니 업데이트해!"와 같은 명령을 내리게 됩니다.
4. 워커 노드: 컨테이너를 실제로 실행하는 현장
컨트롤 플레인의 지시를 받아 실제 애플리케이션 컨테이너(파드)를 실행하고 관리하는 곳이 바로 워커 노드입니다. 각 워커 노드는 다음과 같은 주요 컴포넌트를 가지고 있습니다.
| 요소 | 역할 |
|---|---|
| Kubelet | 각 노드에 할당된 에이전트. API 서버의 지시를 받아 컨테이너 런타임을 호출하고 파드의 상태를 관리 및 보고. |
| Kube-proxy | 노드의 네트워크 규칙 관리. iptables 또는 IPVS를 사용하여 서비스(Service)에 대한 로드 밸런싱 및 접근성 제공. |
| 컨테이너 런타임 (Container Runtime) | Docker, containerd, CRI-O 등. 컨테이너 이미지를 가져와(pull) 실제 컨테이너를 시작/중지하는 엔진. |
스케줄러가 특정 파드를 어떤 워커 노드에 배치할지 결정하면, 해당 노드의 Kubelet이 파드 명세(PodSpec)를 전달받습니다. Kubelet은 이 정보를 바탕으로 컨테이너 런타임에게 컨테이너 실행을 위임하고, Kube-proxy는 해당 파드가 네트워크를 통해 올바르게 통신할 수 있도록 필요한 설정을 담당합니다.
5. 쿠버네티스의 핵심 철학: 지속적인 조정 (Reconciliation Loop)
쿠버네티스를 진정으로 강력하게 만드는 것은 바로 "지속적인 조정 루프(Reconciliation Loop)" 라는 핵심 철학입니다.
- 비교 (Compare): 컨트롤러 매니저는
etcd에 저장된 바람직한 상태(Desired State) 와 워커 노드들로부터 보고받는 실제 상태(Actual State) 를 끊임없이 비교합니다. - 행동 (Act): 만약 두 상태 사이에 차이가 있다면, 컨트롤러는 파드 생성, 재시작, 스케일링, 롤백 등 필요한 조치를 자동으로 취하여 차이를 메웁니다.
- 반복 (Repeat): 이 비교-행동 루프는 멈추지 않고 계속 반복되며, 이를 통해 쿠버네티스는 자가 치유(Self-Healing) 와 오토스케일링(HPA) 과 같은 놀라운 기능을 제공할 수 있습니다.
이 루프 덕분에 가능한 일들:
- ▶️ 노드가 다운되었나요? 걱정 마세요! 쿠버네티스가 해당 노드의 파드들을 다른 건강한 노드에 자동으로 재배치합니다.
- ▶️ CPU 사용률이 80%를 넘었나요? HPA(Horizontal Pod Autoscaler)가 감지하고 자동으로 레플리카(파드) 수를 늘려 부하를 분산시킵니다.
- ▶️ 새로운 버전의 애플리케이션을 배포하고 싶나요? 디플로이먼트 컨트롤러가 중단 없는 롤링 업데이트를 부드럽게 진행합니다.
6. 문제 발생 시 진단 포인트: 어디부터 봐야 할까?
쿠버네티스 환경에서 문제가 발생했을 때, 위에서 설명한 작동 흐름을 이해하고 있다면 원인 파악에 큰 도움이 됩니다. 다음 명령어들을 활용하여 문제의 실마리를 찾아보세요.
kubectl describe pod <pod-name>: 파드의 상세 정보, 최근 이벤트, 재시작 횟수, OOMKilled 등의 로그를 확인합니다. (파드가 왜 죽는지, 왜 Pending 상태인지 힌트를 얻을 수 있습니다.)kubectl get events --sort-by=.metadata.creationTimestamp: 클러스터 전체 또는 특정 네임스페이스의 최근 이벤트들을 시간순으로 확인하여 오류의 발생 시점과 내용을 파악합니다.kubectl top pod/kubectl top node: 파드 또는 노드의 현재 리소스(CPU, 메모리) 사용량을 확인하여 리소스 부족 문제를 진단합니다.- 컨트롤 플레인 컴포넌트 로그 (API 서버, 스케줄러, 컨트롤러 매니저): 보다 심층적인 문제 해결을 위해 컨트롤 플레인의 로그를 직접 확인해야 할 수도 있습니다. (주로 관리형 쿠버네티스 서비스에서는 접근이 제한될 수 있습니다.)
이러한 진단 정보들을 앞서 설명한 컨트롤 플레인 ↔ 워커 노드 간의 상호작용 흐름에 대입해 보면, "왜 내 파드가 예상대로 동작하지 않는지"에 대한 원인을 좀 더 체계적으로 추적할 수 있습니다.
7. 요약: 마법이 아닌, 정교한 오케스트레이션
쿠버네티스의 작동 원리를 다시 한번 정리하면 다음과 같습니다.
- 개발자는 매니페스트 파일을 통해 애플리케이션의 "바람직한 상태" 를 선언합니다.
- 컨트롤 플레인은 이 "바람직한 상태"를
etcd에 저장하고, 클러스터의 실제 상태와 비교하며 지속적으로 조율합니다. - 워커 노드는 컨트롤 플레인의 지시에 따라 실제 컨테이너(파드)를 실행하고 관리합니다.
- 지속적인 조정 루프(Reconciliation Loop) 가 이 모든 과정을 끊임없이 반복하며, 시스템의 안정성과 원하는 상태를 유지합니다. (자가 치유 + 자동 확장)
쿠버네티스가 처음에는 마치 이해할 수 없는 "마법"처럼 보일 수 있습니다. 하지만 그 내부에서 벌어지는 정교한 오케스트레이션 과정을 이해하는 순간, 이 강력한 도구는 한층 더 친숙하고 유용하게 다가올 것입니다. 이 글이 여러분의 쿠버네티스 여정에 작은 나침반이 되어, 디버깅과 운영에 도움이 되기를 바랍니다. 🙌
