Cloud Native,Kubernetes

쿠버네티스 아키텍처 완전 정복 — 컨트롤 플레인부터 워커 노드까지

핵심 요약 — 쿠버네티스 아키텍처는 클러스터의 상태를 결정하는 컨트롤 플레인과 컨테이너를 실제로 실행하는 워커 노드, 두 계층으로 이루어집니다. 모든 컴포넌트는 API 서버를 중심으로 “선언된 상태를 현재 상태로 만드는” 조정 루프를 돌립니다.

2026년 07월 26일

Kubernetes 도입·운영, 전문가와 상담하세요

프로덕션 Kubernetes 도입부터 안정화까지 — CNCF Korea 전문가가 무료 상담으로 함께합니다.

Kubernetes 도입 문의하기 →

쿠버네티스 아키텍처의 큰 그림 — 두 계층 구조

쿠버네티스 클러스터는 “결정하는 쪽”인 컨트롤 플레인과 “실행하는 쪽”인 워커 노드로 나뉩니다.

쿠버네티스 공식 문서는 클러스터를 “컨트롤 플레인(Control Plane)과 하나 이상의 워커 노드(Worker Node)로 구성된 집합”으로 정의합니다(출처: Kubernetes 공식 문서 — 클러스터 아키텍처). 컨트롤 플레인은 클러스터 전체의 두뇌입니다. 어떤 Pod를 어느 노드에 배치할지, 죽은 컨테이너를 어떻게 되살릴지, 선언된 복제본 수와 실제 수가 다르면 무엇을 만들고 지울지를 결정합니다. 워커 노드는 그 결정을 받아 컨테이너를 실제로 띄우고 유지하는 손발입니다.

이 구조를 그림으로 그리면 다음과 같습니다.

그림 1. 쿠버네티스 클러스터의 2계층 구조 — 컨트롤 플레인과 워커 노드

다이어그램을 읽을 때 기억할 원칙은 하나입니다. 컴포넌트끼리 직접 대화하지 않고, 모든 상태 변경이 API 서버를 경유한다는 점입니다. 스케줄러도, 컨트롤러도, kubelet도 API 서버에 물어보고 API 서버에 결과를 보고합니다. 이 단일 창구 설계 덕분에 인증·인가·감사가 한 곳에서 이루어지고, 컴포넌트를 독립적으로 교체하거나 확장할 수 있습니다(출처: cncf.co.kr 쿠버네티스 아키텍처 가이드).

컨트롤 플레인에는 무엇이 있나?

컨트롤 플레인은 kube-apiserver, etcd, kube-scheduler, kube-controller-manager 네 가지 핵심 컴포넌트로 구성됩니다.

각 컴포넌트의 역할을 하나씩 보겠습니다(출처: Kubernetes 공식 문서 — 클러스터 아키텍처).

kube-apiserver — 클러스터의 유일한 관문입니다. kubectl, 대시보드, 다른 컨트롤 플레인 컴포넌트, 워커 노드의 kubelet까지 모든 요청이 이 REST API를 지납니다. 인증(Authentication)·인가(Authorization)·어드미션 컨트롤(Admission Control, 요청을 저장 전에 검증·변형하는 단계)을 순서대로 통과시킨 뒤에야 상태 변경을 허용합니다. 상태를 직접 저장하지 않고 무상태(stateless)로 동작하므로 수평 확장이 가능합니다.
etcd — 클러스터의 모든 상태가 저장되는 분산 키-값 저장소입니다. Raft 합의 알고리즘으로 여러 멤버가 동일한 데이터를 유지하며, 과반수(quorum)가 살아 있어야 쓰기가 가능합니다. 그래서 3대·5대처럼 홀수로 구성하는 것이 정석입니다(출처: etcd 공식 문서). etcd가 곧 클러스터의 진실이므로, etcd 백업이 곧 클러스터 백업입니다.
kube-scheduler — “아직 노드가 정해지지 않은 Pod”를 감시하다가 어느 노드에 배치할지 결정합니다. CPU·메모리 요청량, 노드 셀렉터, 어피니티(affinity)·안티어피니티, 테인트(taint)와 톨러레이션(toleration) 같은 제약 조건을 점수화해 최적 노드를 고릅니다. 결정만 하고, 실행은 해당 노드의 kubelet에게 맡깁니다.
kube-controller-manager — 수십 개의 컨트롤러를 하나의 프로세스로 묶어 실행합니다. Deployment 컨트롤러, ReplicaSet 컨트롤러, Node 컨트롤러, Job 컨트롤러가 각각 “선언된 상태와 현재 상태를 비교해 차이를 없애는” 조정 루프(reconciliation loop)를 돕니다. 복제본 3개를 선언했는데 2개만 떠 있으면 1개를 더 만드는 주체가 바로 컨트롤러입니다.
cloud-controller-manager(선택) — 퍼블릭 클라우드에서 운영할 때 로드밸런서 프로비저닝, 노드 상태 확인 같은 클라우드 사업자 연동 로직을 분리해 담당합니다. 온프레미스 클러스터에는 없어도 됩니다.

그림 2. 컨트롤 플레인 4 + 1 컴포넌트의 역할과 볼 지표

정리하면 컨트롤 플레인은 “관문(API 서버) + 장부(etcd) + 배치 담당(스케줄러) + 유지 담당(컨트롤러)”의 조합입니다. 네 역할이 분리되어 있어 하나가 느려져도 다른 역할이 곧바로 무너지지 않습니다.

워커 노드에서는 무엇이 실행되나?

워커 노드에는 kubelet, kube-proxy, 컨테이너 런타임 세 가지가 상주하며 Pod의 실행을 책임집니다.

kubelet — 각 노드의 에이전트입니다. API 서버를 감시하다가 자기 노드에 배정된 Pod 명세(PodSpec)를 발견하면, 컨테이너 런타임에 실행을 지시하고 컨테이너가 명세대로 건강하게 떠 있는지 계속 확인합니다. 상태는 다시 API 서버로 보고합니다.
컨테이너 런타임(Container Runtime) — 컨테이너를 실제로 생성·실행하는 소프트웨어입니다. kubelet은 CRI(Container Runtime Interface)라는 표준 인터페이스로 런타임과 대화하므로, containerd든 CRI-O든 교체가 가능합니다(출처: cncf.co.kr — containerd·CRI-O·runc 해설). 도커와 쿠버네티스의 관계가 궁금하다면 시리즈의 쿠버네티스 vs 도커 편에서 런타임 계층을 따로 다룹니다.
kube-proxy — 서비스(Service)의 가상 IP로 들어온 트래픽을 실제 Pod로 전달하는 네트워크 규칙(iptables 또는 IPVS)을 노드마다 유지합니다. Pod 간 통신과 CNI 플러그인 이야기는 쿠버네티스 네트워킹과 CNI 편에서 이어집니다.

그림 3. 워커 노드 내부 — 실행 경로와 네트워크 경로를 같은 3단 구조로 대비

노드에서 실행되는 최소 단위는 Pod입니다. Pod의 생명주기와 멀티컨테이너 패턴은 쿠버네티스 Pod 완벽 가이드에서 심화 해설로 다루므로, 이 글에서는 “kubelet이 관리하는 실행 단위”로만 정리하고 넘어가겠습니다.

kubectl apply 한 줄의 여정 — 요청 흐름 추적

kubectl apply 이후의 흐름은 인증 → 저장 → 컨트롤러 → 스케줄러 → kubelet → 런타임의 6단계로 요약됩니다.

Deployment 매니페스트를 적용했다고 가정하고 전체 여정을 따라가 보겠습니다(출처: Kubernetes 공식 문서 — 클러스터 아키텍처).

kubectl → API 서버: kubectl이 매니페스트를 REST 요청으로 만들어 kube-apiserver에 보냅니다. 인증서·토큰으로 사용자를 확인하고(인증), RBAC 규칙으로 권한을 확인하며(인가), 어드미션 컨트롤러가 기본값 주입·정책 검증을 수행합니다.
etcd 저장: 검증을 통과한 Deployment 오브젝트가 etcd에 기록됩니다. 이 시점에는 아직 어떤 컨테이너도 실행되지 않았습니다. “원하는 상태”가 장부에 적혔을 뿐입니다.
컨트롤러 반응: Deployment 컨트롤러가 새 오브젝트를 감지해 ReplicaSet을 만들고, ReplicaSet 컨트롤러가 복제본 수만큼 Pod 오브젝트를 만듭니다. 이 Pod들은 아직 노드가 비어 있는(unscheduled) 상태입니다.
스케줄러 배치: kube-scheduler가 노드 미지정 Pod를 발견하고, 자원 요청량과 제약 조건을 평가해 노드를 결정한 뒤 그 결과를 API 서버에 기록합니다.
kubelet 실행: 해당 노드의 kubelet이 자기에게 배정된 Pod를 발견하고, CRI를 거쳐 컨테이너 런타임에 이미지 풀(pull)과 컨테이너 생성을 지시합니다.
상태 보고와 조정: kubelet이 컨테이너 상태를 API 서버로 보고하고, 이후 컨테이너가 죽으면 재시작하며, 노드 자체가 죽으면 컨트롤러가 다른 노드에 Pod를 다시 만듭니다.

그림 4. kubectl apply 한 줄의 6단계 여정과 증상별 역추적

이 흐름을 알면 장애 지점을 역추적할 수 있습니다. Pod가 Pending이면 4단계(스케줄러·자원 부족)를, ImagePullBackOff면 5단계(런타임·레지스트리)를, 오브젝트 생성 자체가 거부되면 1단계(RBAC·어드미션)를 의심하는 식입니다. 아키텍처 이해가 곧 트러블슈팅 지도이기도 합니다.

고가용성(HA) 구성 패턴

프로덕션 컨트롤 플레인은 3대 이상 홀수 노드로 구성하며, etcd를 함께 두는 스택형과 분리하는 외부형 두 패턴이 있습니다.

컨트롤 플레인이 한 대뿐이면 그 서버 장애가 곧 클러스터 관리 기능의 중단입니다(이미 실행 중인 Pod는 당분간 돌지만, 새 배포·복구·확장이 멈춥니다). 그래서 프로덕션에서는 고가용성 구성이 기본이며, kubeadm 기준으로 두 가지 토폴로지가 표준입니다(출처: Kubernetes 공식 문서 — HA 토폴로지 선택).

스택형(stacked) etcd 토폴로지 — 각 컨트롤 플레인 노드에 etcd 멤버를 함께 배치합니다. 서버 3대로 HA가 완성되어 구성이 단순하고 비용이 적습니다. 대신 노드 하나가 죽으면 API 서버와 etcd 멤버가 동시에 사라지므로 장애 결합도가 높습니다.
외부(external) etcd 토폴로지 — etcd 클러스터를 컨트롤 플레인과 별도 서버로 분리합니다. API 서버 장애와 데이터 저장소 장애가 서로를 끌어내리지 않아 안정성이 높지만, 서버가 최소 6대 필요해 비용과 운영 부담이 커집니다.

그림 5. HA 토폴로지 두 갈래 — 스택형 etcd vs 외부 etcd

어느 쪽이든 공통 원칙은 같습니다. 첫째, etcd는 과반수 합의가 필요하므로 3대 또는 5대 홀수로 둡니다. 2대 구성은 1대 구성보다 오히려 가용성이 나쁩니다. 둘째, 여러 API 서버 앞에 로드밸런서를 두어 kubelet과 kubectl이 단일 주소로 접근하게 합니다. 셋째, etcd 정기 스냅숏 백업을 자동화합니다. 컨트롤 플레인 전체를 잃어도 etcd 스냅숏이 있으면 클러스터 상태를 복원할 수 있습니다.

그림 6. etcd 멤버 수와 허용 장애 — 왜 홀수인가

아키텍처 이해가 운영을 바꾸는 지점

컴포넌트별 역할을 알면 모니터링 대상, 장애 대응 순서, 업그레이드 전략이 달라집니다.

아키텍처 지식은 교양이 아니라 운영 도구입니다. 첫째, 모니터링이 구체화됩니다. API 서버 응답 지연, etcd 디스크 쓰기 지연(fsync), 스케줄링 대기 Pod 수는 클러스터 건강의 선행 지표입니다. 특히 etcd는 디스크 성능에 민감해 SSD 사용이 사실상 필수입니다(출처: etcd 공식 문서). 둘째, 장애 대응 순서가 잡힙니다. “배포가 안 된다”는 신고가 오면 API 서버 → etcd 쿼럼 → 컨트롤러 → 스케줄러 → kubelet 순서로 요청 흐름을 따라 내려가며 확인하면 됩니다. 셋째, 업그레이드 전략이 명확해집니다. 컨트롤 플레인을 먼저, 워커 노드를 나중에 올리는 순서와 버전 차이 허용 범위(version skew)는 모두 “kubelet이 API 서버의 클라이언트”라는 구조에서 나오는 규칙입니다.

이 구조는 클라우드 네이티브 설계 전반의 축소판이기도 합니다. 선언적 API, 조정 루프, 느슨한 결합이라는 원칙이 쿠버네티스 안에서 그대로 구현되어 있기 때문입니다. 더 큰 그림은 클라우드 네이티브란 무엇인가에서 확인하실 수 있습니다.

그림 7. 조정 루프 — 선언된 상태로 수렴시키는 한 바퀴

쿠버네티스 아키텍처는 결국 “선언된 상태를 향해 끊임없이 수렴하는 시스템”이라는 한 문장으로 모입니다. 컨트롤 플레인이 결정하고, 워커 노드가 실행하며, 모든 대화가 API 서버를 지나고, 모든 진실이 etcd에 남습니다. 이 지도를 머리에 넣어 두면 새로운 기능이 추가되어도 “이 컴포넌트는 어느 계층의 어떤 역할인가”라는 질문 하나로 빠르게 자리를 찾을 수 있습니다.

자주 묻는 질문 (FAQ)

컨트롤 플레인과 마스터 노드는 같은 말인가요?

같은 대상을 가리킵니다. 과거에는 마스터 노드(master node)라고 불렀지만, 쿠버네티스 커뮤니티가 용어를 정비하면서 공식 문서는 컨트롤 플레인으로 통일했습니다. 옛 자료를 읽을 때 마스터 노드가 나오면 컨트롤 플레인으로 바꿔 읽으시면 됩니다.

etcd는 왜 홀수로 구성해야 하나요?

etcd는 Raft 합의 알고리즘으로 과반수가 동의해야 쓰기를 확정합니다. 3대면 1대 장애를, 5대면 2대 장애를 견딥니다. 4대는 과반수가 3이라 허용 장애 수가 3대 구성과 같은 1대뿐이면서 비용만 늘어나므로, 홀수 구성이 표준입니다.

컨트롤 플레인이 다운되면 서비스도 바로 중단되나요?

이미 실행 중인 Pod는 워커 노드의 kubelet과 컨테이너 런타임이 유지하므로 당장은 계속 동작합니다. 다만 새 배포, 장애 Pod 자동 복구, 오토스케일링처럼 컨트롤 플레인의 결정이 필요한 기능은 모두 멈춥니다. 그래서 프로덕션에서는 HA 구성이 필수입니다.

스케줄러는 노드를 어떤 기준으로 고르나요?

먼저 자원 요청량·노드 셀렉터·테인트 같은 조건으로 배치 불가능한 노드를 걸러내고(filtering), 남은 후보를 자원 여유·어피니티 만족도 등으로 점수화해(scoring) 가장 높은 노드를 선택합니다. 결정 결과는 API 서버에 기록되고 실행은 kubelet이 담당합니다.

워커 노드 하나가 죽으면 그 위의 Pod는 어떻게 되나요?

Node 컨트롤러가 노드의 상태 보고가 끊긴 것을 감지하면 일정 시간 뒤 해당 노드의 Pod를 퇴거(eviction) 대상으로 표시하고, ReplicaSet 컨트롤러가 다른 정상 노드에 대체 Pod를 만듭니다. 복구 시간은 감지·퇴거 관련 타임아웃 설정에 따라 달라집니다.

참고 리소스

Featured Image alt 후보: 컨트롤 플레인과 워커 노드의 컴포넌트 연결을 표현한 다크 톤 쿠버네티스 아키텍처 다이어그램.