Kubernetes Architecture: 구성 요소·제어 흐름·장애 지점

Kubernetes architecture는 클러스터 상태를 관리하는 Control Plane과 컨테이너화된 워크로드를 실행하는 worker Node의 협업 구조입니다. 사용자가 Kubernetes API에 원하는 상태를 제출하면 API Server가 요청을 처리하고, controller·scheduler·kubelet은 API 상태를 바탕으로 각자의 책임 범위에서 조정하거나 실행을 지시합니다. container runtime은 kubelet의 CRI 요청에 따라 컨테이너를 실행합니다. 이 구조는 하나의 “Master”가 모든 구성 요소에 고정된 순서로 명령을 내리는 단일 작업 흐름이 아니며, 실제 물리 배치와 관리 책임은 배포판과 관리형 서비스 구성에 따라 달라질 수 있습니다.

발행자와 증거 범위

이 글의 발행자는 옵저버빌리티 플랫폼을 제공하는 Guance입니다. Guance는 Kubernetes나 Cloud Native Computing Foundation(CNCF)을 대표하지 않으며, 자체 제품 설명은 독립적인 성능 검증이 아닙니다. Kubernetes 구성 요소와 제어 메커니즘은 Kubernetes 한국어 Cluster Architecture, 현재 영어 Architecture와 Components를 중심으로 확인했습니다. 자료 확인일은 2026년 8월 1일이며, 한국어 번역이 늦을 수 있는 항목은 영어 원문과 교차 확인했습니다.

한국 검색 결과에 등장하는 cncf.co.kr은 **CNF(Cloud Native Forum)**의 도메인이지 공식 CNCF 도메인 cncf.io가 아닙니다. 따라서 이 글은 cncf.co.kr을 기술 사실의 일차 출처로 사용하지 않습니다. Kubernetes의 CNCF 프로젝트 상태를 확인할 때는 CNCF 공식 Kubernetes 프로젝트 페이지만 사용합니다.

Kubernetes의 기본 개념, 도입 조건, Docker·VM과의 관계가 먼저 필요하다면 Kubernetes란 무엇인가: 역할과 한계을 읽으십시오. 이 글은 그 내용을 반복하지 않고 구성 요소, control flow와 failure domain에만 집중합니다.

참조 아키텍처와 전제

Kubernetes 공식 Architecture 문서는 클러스터를 Control Plane과 하나 이상의 worker Node로 설명합니다. Control Plane은 클러스터를 관리하고, Node는 Pod를 실행합니다. 여기서 중요한 것은 공식 그림을 모든 클러스터의 유일한 물리 토폴로지로 해석하지 않는 것입니다.

관련 가이드쿠버네티스(K8s) 모니터링 시작하기 — 4계층 지표와 알람 설정→

• self-managed 클러스터에서는 운영팀이 Control Plane과 Node의 배치·업그레이드·복구를 직접 맡을 수 있습니다.
• managed Kubernetes에서는 공급자가 Control Plane 책임의 일부를 맡을 수 있지만, 노출되는 구성 요소와 책임 범위는 서비스 계약과 구현에 따라 다릅니다.
• 구성 요소가 하나의 머신에 함께 있거나 여러 머신·가용 영역에 분산될 수 있습니다.
• 네트워크, 스토리지, cloud provider와의 연결은 선택한 플러그인과 배포 방식에 따라 달라집니다.

따라서 다음 설명은 Kubernetes API와 공식 구성 요소의 논리적 책임을 이해하기 위한 reference model입니다. 특정 EKS, GKE, AKS 또는 사설 배포의 내부 물리 경로를 관찰했다고 주장하지 않습니다.

Control Plane 구성 요소

Kubernetes Components는 Control Plane의 대표 구성 요소로 kube-apiserver, etcd, kube-scheduler와 kube-controller-manager를 설명하며, cloud-controller-manager는 cloud provider와 연동할 때 사용할 수 있는 구성 요소로 구분합니다.

API Server는 “모든 문제를 처리하는 중앙 실행기”라기보다 클러스터 API의 중심입니다. Kubernetes Controller 문서에 따르면 controller는 원하는 상태와 현재 상태를 비교해 변화가 필요할 때 조정합니다. scheduler와 controller, kubelet은 API 상태를 매개로 각자 동작하며, 하나의 긴 동기식 함수처럼 순서대로 실행되지 않습니다.

etcd도 임의의 애플리케이션이나 모든 구성 요소가 직접 읽고 쓰는 범용 데이터베이스로 설명하면 안 됩니다. Kubernetes Components는 etcd를 Kubernetes cluster data의 backing store로 설명합니다. 운영 절차에서는 API Server 데이터 경계, 접근 제어, 백업과 복구를 공식 etcd·Kubernetes 문서에 따라 별도로 검토해야 합니다.

Worker Node 구성 요소

Kubernetes Nodes 문서와 Components를 기준으로 보면 Node는 Pod를 실행하기 위한 다음 책임을 가집니다.

Container Runtimes 공식 문서는 Kubernetes가 CRI를 통해 container runtime과 통신한다고 설명합니다. runtime의 지원 상태와 설정은 Kubernetes 버전과 배포판에 따라 바뀔 수 있으므로, 특정 runtime이나 socket 경로를 이 개념 글에 영구적인 기본값으로 고정하지 않습니다.

Liveness, Readiness and Startup Probes 문서는 kubelet이 구성된 probe를 실행하는 방식을 설명합니다. probe는 작성자가 정의한 검사만 확인합니다. readiness가 성공했다고 해서 데이터 정확성, 외부 의존성 또는 전체 사용자 여정이 정상이라고 단정할 수는 없습니다.

API 요청에서 Running Pod까지의 제어 흐름

다음은 Deployment 같은 workload object가 제출된 뒤 Pod가 실행 상태로 가는 개념적 sequence입니다. 각 단계는 공식 메커니즘을 요약한 것이며, 네트워크 패킷의 완전한 순서나 특정 배포판의 내부 구현을 재현한 Lab 결과가 아닙니다.

1. Client → API Server: 사용자는 kubectl 또는 다른 client로 원하는 오브젝트를 Kubernetes API에 제출합니다. API Server는 Kubernetes HTTP API를 노출합니다. 출처: Kubernetes Components.
2. API 상태 보존: 승인된 API 상태는 클러스터 데이터의 backing store인 etcd에 보존됩니다. 이 설명은 “client가 etcd에 직접 쓴다”는 뜻이 아닙니다. 출처: Components.
3. Controller의 관찰과 조정: workload controller는 API의 desired state와 current state를 관찰해 필요한 ReplicaSet·Pod object를 조정합니다. 출처: Controllers와 Deployments.
4. Scheduler의 Node 선택: 아직 Node가 지정되지 않은 Pod가 있으면 scheduler가 resource request, constraint, 정책과 가용 Node를 고려해 배치할 Node를 선택합니다. 출처: kube-scheduler.
5. kubelet과 runtime: 선택된 Node의 kubelet은 자신에게 할당된 Pod를 확인하고 CRI를 통해 runtime에 필요한 컨테이너 실행을 요청합니다. 출처: Components와 Container Runtimes.
6. 현재 상태 업데이트: kubelet은 container state와 Pod conditions를 API에 반영하고 구성된 probe를 실행합니다. controller와 사용자는 API에서 현재 상태를 읽습니다. 출처: Kubernetes Pods와 Probes.

이 단계들은 서로 격리된 일회성 작업이 아닙니다. controller, scheduler와 kubelet은 상태 변화에 반응해 계속 동작하며, 재시도와 조정이 비동기적으로 일어날 수 있습니다. 그러므로 화면에 보이는 한 시점의 status만 보고 어느 구성 요소가 원인이라고 확정하지 말고, 시간대가 맞는 object 변화, Events, component log·metric과 실행 계층 증거를 함께 확인해야 합니다.

개념 흐름의 텍스트 대안

client → kube-apiserver ↔ etcd (API state)
                  ↑
       ┌──────────┼──────────┐
       │          │          │
  controller   scheduler   kubelet
  watch/write  watch/bind  watch assigned Pods/write status
                             │
                             ▼
                    CRI-compatible runtime → containers

이 도식의 화살표는 official mechanism을 요약한 개념 관계입니다. 원본 sequence SVG와 모바일용 텍스트 대안은 아직 최종 디자인·접근성 검토를 거치지 않았고, Lab에서 직접 관찰한 화살표로 표시할 수 없습니다.

Workload와 Service 경로

Deployment 공식 문서에 따르면 Deployment는 ReplicaSet을 통해 Pod의 선언적 업데이트를 관리합니다. Deployment, ReplicaSet과 Pod를 한 객체의 다른 이름처럼 취급하면 어느 controller가 어떤 상태를 관리하는지 놓치게 됩니다.

Service 문서는 Service를 하나 이상의 Pod로 실행되는 네트워크 애플리케이션을 노출하는 추상화로 설명하고, EndpointSlice 문서는 Service의 backend endpoint를 확장 가능하게 표현하는 API를 설명합니다.

일반적인 조사 경로는 다음처럼 층을 나눕니다.

Service endpoint가 존재한다는 사실과 사용자 요청이 성공한다는 사실은 다릅니다. 반대로 애플리케이션 5xx가 있다고 해서 Control Plane 장애라고 바로 판단할 수도 없습니다. 각 층의 증거를 시간과 리소스 identity로 연결해야 합니다.

통신과 보안 경계

Control Plane–Node Communication 문서는 API Server와 Node 사이의 통신 경로와 보안 전제를 설명합니다. 이 아키텍처 글에서는 다음 경계만 고정합니다.

• kubelet과 Kubernetes API를 watch하는 Node 구성 요소는 API Server와 통신하며, 인증·인가와 전송 보호가 필요합니다.
• container runtime은 보통 로컬 CRI를 통해 kubelet의 요청을 받아 컨테이너를 실행합니다. runtime 자체가 Kubernetes API를 직접 watch한다고 일반화하지 않습니다.
• API 통신에는 인증과 인가 경계가 있으며, 하나의 “로그인 성공”으로 모든 권한을 설명할 수 없습니다.
• kubelet API, API Server에서 Node로 가는 연결, tunnel 또는 provider-specific 연결 방식은 배포 형태에 따라 달라질 수 있습니다.
• 정확한 포트, 인증서, service account, network policy와 hardening 절차는 현재 버전의 공식 보안·설치 문서에서 확인해야 합니다.

이 글은 실제 클러스터의 kubeconfig, 인증서, token, service account secret, hostname, IP 또는 내부 도메인을 수집하거나 공개하지 않습니다. 향후 Lab에서도 이러한 값은 원본 보관 단계부터 접근을 제한하고 공개본에서는 제거해야 합니다.

HA와 failure domain은 같은 말이 아닙니다

Control Plane을 여러 인스턴스로 구성했다고 해서 애플리케이션이 자동으로 고가용해지는 것은 아닙니다. kubeadm HA Topology와 Running in Multiple Zones는 Control Plane topology와 여러 zone을 사용하는 배치 원칙을 각각 다룹니다. 실제 가용성은 다음 층을 따로 검토해야 합니다.

이 표는 조사 시작점을 정리한 Guance 편집 자산이지 자동 근본 원인 트리가 아닙니다. 한 신호가 여러 failure domain에서 나타날 수 있으며, 상관관계만으로 원인을 확정해서는 안 됩니다. 특정 SLO와 복구 시간을 약속하려면 서비스 계약 또는 고정 환경의 재현 가능한 Lab이 필요합니다.

아키텍처를 관측하는 방법

Kubernetes Observability는 metrics, logs와 traces 같은 텔레메트리와 시스템 상태를 이해하기 위한 관측을 설명하고, Logging Architecture는 cluster-level logging을 별도로 설계해야 하는 이유를 다룹니다. 조사할 때는 다음 순서가 유용합니다.

관련 가이드Kubernetes란? 개념·작동 원리·도입 판단 기준→

1. 대상과 시간을 고정합니다. cluster, namespace, workload, Pod UID, Node와 변경 시각을 구분합니다.
2. API object 상태를 확인합니다. spec, status, condition과 owner relationship으로 어느 controller 경계에서 차이가 생겼는지 봅니다.
3. Events를 가설 단서로 사용합니다. scheduling, image pull, probe 같은 변화와 시각을 찾되 Events 하나만으로 원인을 확정하지 않습니다.
4. 구성 요소 로그·메트릭으로 범위를 좁힙니다. API Server, controller, scheduler, kubelet과 runtime 중 관련 경계를 확인합니다.
5. 애플리케이션과 사용자 신호로 검증합니다. platform state가 회복된 뒤 요청 성공률, 지연, trace·log와 사용자 결과도 회복됐는지 확인합니다.

Guance의 Container 통합 문서(영문), 현재 KubernetesPrometheus discovery 문서(영문), 그리고 ServiceMonitor / PodMonitor 지원 필드 문서(영문)는 Guance가 공개한 수집 설정 경로입니다. 이 링크들은 Kubernetes의 공식 작동 방식을 증명하지 않으며, 현재 지원 범위·권한·버전·필드와 제한은 Guance 제품 owner의 검토와 대상 환경의 검증이 필요합니다. Guance 한국어 Kubernetes 모니터링 솔루션 역시 자체 제품 설명이지 독립 Lab 결과가 아닙니다.

세 가지 failure scenario Lab — 모두 미실행

이 실습의 목적은 vendor 성능을 비교하거나 Guance가 자동으로 원인을 찾는다고 증명하는 것이 아닙니다. 서로 다른 failure domain에서 어떤 증거를 수집해야 하는지 재현 가능한 방법으로 확인하는 것입니다.

공통 실험 조건

Scenario 1: Scheduling boundary

• 계획: 존재하지 않는 Node label을 요구하는 node selector 또는 충족할 수 없는 constraint를 가진 Pod를 제출합니다.
• 수집 예정: Pod phase·conditions, scheduler Events, 선택 가능한 Node와 constraint 정의, 수정 전후 object 상태입니다.
• 판단 경계: scheduler가 아직 Node를 선택하지 못한 상태와 Node에서 컨테이너 실행이 실패한 상태를 구분합니다.
• 현재 결과: 공개 자료에 명시되지 않음. Pod가 실제로 Pending이었는지, 어떤 Event가 생성됐는지, 수정 후 언제 바인딩됐는지 실행하지 않았습니다.

Scenario 2: Node/runtime boundary

• 계획: 존재하지 않는 image digest 또는 tag를 사용한 workload를 disposable cluster에 배포합니다.
• 수집 예정: Pod/container state, Events, kubelet·runtime evidence, registry 요청 경계와 수정 후 상태입니다.
• 판단 경계: scheduler가 Node를 선택한 사실과 해당 Node에서 이미지를 가져와 컨테이너를 실행한 사실을 분리합니다.
• 현재 결과: 공개 자료에 명시되지 않음. ErrImagePull, ImagePullBackOff 또는 다른 상태가 실제로 관찰됐다고 주장하지 않습니다.

Scenario 3: Readiness와 EndpointSlice boundary

• 계획: 고정적으로 실패하는 readiness probe를 가진 테스트 workload와 Service를 구성한 뒤 probe를 수정합니다.
• 수집 예정: Pod Ready condition, probe 결과, Service selector, EndpointSlice membership과 실제 Service 요청 결과입니다.
• 판단 경계: 컨테이너 process 실행, readiness, Service endpoint 등록과 애플리케이션 응답을 서로 다른 사실로 기록합니다.
• 현재 결과: 공개 자료에 명시되지 않음. endpoint 포함 여부, 복구 순서와 소요 시간은 아직 측정하지 않았습니다.

세 Lab 모두 원시 출력과 두 번째 실행이 확보되기 전에는 “실측”, “검증 완료”, “몇 초 내 복구” 또는 제품 우위를 뜻하는 표현으로 바꿀 수 없습니다. 공식 문서는 구성 요소의 책임을 증명하고, Lab은 이번 환경에서 직접 관찰한 사실만 증명해야 합니다. 둘 사이의 해석은 inference로 별도 표시해야 합니다.

다음 학습·구현 경로

2. 최신 upstream 사실은 Kubernetes 한국어 Architecture와 현재 영어 Components에서 확인합니다.
3. 설치, 인증·인가, cluster hardening과 HA 구현은 이 글의 범위를 넘습니다. 대상 Kubernetes 버전의 공식 setup·security 문서를 사용하십시오.
4. Guance 수집 구현은 Container 통합 문서(영문), KubernetesPrometheus discovery 문서(영문), ServiceMonitor / PodMonitor 지원 필드 문서(영문)에서 확인하고, 권한·signal·object·제한을 테스트 환경에서 검증합니다.
5. 제품 관점의 production monitoring을 평가할 때만 Guance 한국어 Kubernetes 모니터링 솔루션을 참고합니다. 이 링크는 Guance의 자체 설명이며 Kubernetes 공식 자료나 제3자 검증을 대체하지 않습니다.

공식 일차 자료

• Kubernetes Cluster Architecture — KO / current EN
• Kubernetes Components
• Kubernetes Controllers
• kube-scheduler
• Kubernetes Nodes — KO / current EN
• Kubernetes Container Runtimes
• Kubernetes Pods — KO / current EN
• Kubernetes Deployments
• Kubernetes Service와 EndpointSlices
• Control Plane–Node Communication
• HA Topology와 Running in Multiple Zones
• Kubernetes Observability와 Logging Architecture
• CNCF Kubernetes project

Research status와 공개 조건