전체 비유: 아파트 단지 운영 본부#

Kubernetes 아키텍처를 아파트 단지 운영 본부에 비유하면 이해하기 쉽습니다:

이처럼 Control Plane은 “관리사무소에서 단지 전체를 운영"하고, Worker Node는 “각 동에서 실제 입주민을 수용"합니다.

대상 독자: Kubernetes 구조를 이해하고 싶은 백엔드 개발자 선수 지식: Docker 기본 개념 소요 시간: 약 25-30분 이 문서를 읽으면: Kubernetes 클러스터의 구성요소와 각 역할을 이해할 수 있습니다

TL;DR

• Kubernetes 클러스터는 Control Plane(뇌)과 Worker Node(근육)로 구성됩니다
• Control Plane은 클러스터 상태를 관리하고, Worker Node는 실제 워크로드를 실행합니다
• kubectl 명령은 API Server를 통해 클러스터와 통신합니다

클러스터 전체 구조#

Kubernetes 클러스터는 크게 두 부분으로 나뉩니다.

flowchart TB
    subgraph CP[Control Plane]
        API[API Server]
        ETCD[(etcd)]
        SCHED[Scheduler]
        CM[Controller Manager]
    end

    subgraph WN1[Worker Node 1]
        K1[Kubelet]
        KP1[Kube-proxy]
        P1[Pod]
        P2[Pod]
    end

    subgraph WN2[Worker Node 2]
        K2[Kubelet]
        KP2[Kube-proxy]
        P3[Pod]
        P4[Pod]
    end

    API <--> ETCD
    API <--> SCHED
    API <--> CM
    API <--> K1
    API <--> K2
    K1 --> P1
    K1 --> P2
    K2 --> P3
    K2 --> P4

Control Plane과 Worker Node의 역할을 비교하면 다음과 같습니다.

Control Plane은 클러스터 전체를 관리하는 두뇌 역할을 하고, Worker Node는 Control Plane의 지시에 따라 실제 컨테이너를 실행하는 역할을 합니다.

Control Plane 구성요소#

Control Plane은 클러스터의 두뇌입니다. 4개의 핵심 컴포넌트로 구성됩니다.

API Server (kube-apiserver)#

API Server는 Kubernetes의 프론트엔드입니다. 모든 통신은 API Server를 거칩니다.

flowchart LR
    kubectl --> API[API Server]
    Dashboard --> API
    CI/CD --> API
    API --> Internal[내부 컴포넌트]

주요 역할은 다음과 같습니다.

인증과 권한 검사를 수행합니다. kubectl 명령이 들어오면 먼저 요청자가 누구인지(인증), 해당 작업을 할 권한이 있는지(인가)를 확인합니다.

요청 검증을 수행합니다. YAML 문법이 올바른지, 필수 필드가 있는지 등을 검사합니다.

etcd와 통신합니다. 검증을 통과한 리소스는 etcd에 저장됩니다. API Server만 etcd에 직접 접근할 수 있습니다.

# API Server에 직접 요청하기 (kubectl이 내부적으로 하는 일)
kubectl get pods -v=8  # -v=8은 HTTP 요청을 상세히 출력

etcd#

etcd는 클러스터의 모든 상태를 저장하는 분산 키-값 저장소입니다.

저장되는 정보는 다음과 같습니다.

etcd가 손상되면 클러스터 상태를 완전히 복구할 수 없습니다. 그래서 프로덕션에서는 etcd 백업이 필수입니다.

주의
etcd는 Kubernetes의 유일한 상태 저장소입니다. 다른 컴포넌트들은 상태를 저장하지 않고, 필요할 때 API Server를 통해 etcd에서 조회합니다.

Scheduler (kube-scheduler)#

Scheduler는 새로 생성된 Pod를 어느 노드에서 실행할지 결정합니다.

flowchart LR
    A[새 Pod 생성 요청] --> B[Scheduler]
    B --> C{노드 선택}
    C --> D[Node 1: 8GB 여유]
    C --> E[Node 2: 2GB 여유]
    C --> F[Node 3: 16GB 여유]
    B -->|선택| F

스케줄링 결정 요소는 다음과 같습니다.

Scheduler는 결정만 내립니다. 실제 Pod 실행은 해당 노드의 Kubelet이 담당합니다.

Controller Manager (kube-controller-manager)#

Controller Manager는 여러 컨트롤러를 실행하는 프로세스입니다. 각 컨트롤러는 특정 리소스를 관리합니다.

주요 컨트롤러와 역할은 다음과 같습니다.

컨트롤러의 동작 원리는 **조정 루프(Reconciliation Loop)**입니다.

flowchart LR
    A[현재 상태 확인] --> B{원하는 상태와 일치?}
    B -->|Yes| C[대기]
    B -->|No| D[상태 조정]
    D --> A
    C --> A

예를 들어 Deployment에서 replicas: 3으로 설정했는데 현재 Pod가 2개라면, ReplicaSet Controller가 1개를 추가로 생성합니다.

Worker Node 구성요소#

Worker Node는 실제 워크로드가 실행되는 곳입니다.

Kubelet#

Kubelet은 각 노드에서 실행되는 에이전트입니다. Pod의 생명주기를 관리합니다.

주요 역할은 다음과 같습니다.

Pod 실행을 담당합니다. API Server로부터 할당받은 Pod 명세대로 컨테이너를 실행합니다.

상태 보고를 수행합니다. Pod와 노드의 상태를 주기적으로 API Server에 보고합니다.

헬스 체크를 실행합니다. Liveness/Readiness Probe를 실행하고 결과에 따라 조치합니다.

flowchart TB
    API[API Server] -->|Pod 명세| Kubelet
    Kubelet -->|상태 보고| API
    Kubelet --> CRI[Container Runtime]
    CRI --> Container[컨테이너]

Kubelet은 컨테이너 런타임(containerd, CRI-O 등)과 통신하여 실제 컨테이너를 관리합니다.

Kube-proxy#

Kube-proxy는 네트워크 규칙을 관리합니다. Service로 들어오는 트래픽을 적절한 Pod로 전달합니다.

동작 방식을 비교하면 다음과 같습니다.

대부분의 환경에서 iptables 모드를 기본으로 사용합니다. 대규모 클러스터에서는 IPVS 모드가 권장됩니다.

Container Runtime#

실제 컨테이너를 실행하는 소프트웨어입니다.

Kubernetes v1.24부터 Docker를 직접 지원하지 않지만, Docker로 빌드한 이미지는 모든 런타임에서 실행 가능합니다.

kubectl 명령의 흐름#

kubectl apply -f deployment.yaml 명령을 실행했을 때 클러스터 내부에서 일어나는 일을 추적해봅니다.

sequenceDiagram
    participant User as kubectl
    participant API as API Server
    participant ETCD as etcd
    participant CM as Controller Manager
    participant Sched as Scheduler
    participant Kubelet
    participant CRI as Container Runtime

    User->>API: 1. Deployment 생성 요청
    API->>API: 2. 인증/인가 확인
    API->>API: 3. 요청 검증
    API->>ETCD: 4. Deployment 저장
    ETCD-->>API: OK

    API->>CM: 5. Deployment 이벤트 알림
    CM->>API: 6. ReplicaSet 생성
    API->>ETCD: 7. ReplicaSet 저장

    CM->>API: 8. Pod 생성
    API->>ETCD: 9. Pod 저장 (nodeName 없음)

    Sched->>API: 10. 미배치 Pod 감시
    Sched->>Sched: 11. 노드 선택
    Sched->>API: 12. Pod에 노드 할당
    API->>ETCD: 13. Pod 업데이트

    Kubelet->>API: 14. 자기 노드의 Pod 감시
    Kubelet->>CRI: 15. 컨테이너 실행
    CRI-->>Kubelet: 컨테이너 시작됨
    Kubelet->>API: 16. Pod 상태 업데이트

각 단계를 요약하면 다음과 같습니다.

고가용성(HA) 구성#

프로덕션 환경에서는 Control Plane을 고가용성으로 구성합니다.

flowchart TB
    LB[Load Balancer]

    subgraph CP1[Control Plane 1]
        API1[API Server]
        ETCD1[(etcd)]
    end

    subgraph CP2[Control Plane 2]
        API2[API Server]
        ETCD2[(etcd)]
    end

    subgraph CP3[Control Plane 3]
        API3[API Server]
        ETCD3[(etcd)]
    end

    LB --> API1
    LB --> API2
    LB --> API3

    ETCD1 <--> ETCD2
    ETCD2 <--> ETCD3
    ETCD1 <--> ETCD3

HA 구성의 핵심 요소는 다음과 같습니다.

관리형 Kubernetes(EKS, GKE, AKS)를 사용하면 Control Plane HA는 클라우드 제공자가 관리합니다.

개발자 관점: 왜 아키텍처를 알아야 하나?#

배포 문제가 발생했을 때 어떤 컴포넌트를 확인해야 하는지 알기 위해서입니다.

증상별 원인 컴포넌트#

컴포넌트 장애 시 영향도#

핵심 포인트
Control Plane 장애 시에도 이미 실행 중인 Pod는 계속 동작합니다. 하지만 신규 배포, 스케일링, 자동 복구가 중단됩니다.

실습: 클러스터 구성요소 확인#

실제 클러스터에서 구성요소들을 확인해봅니다.

Control Plane 컴포넌트 확인#

# kube-system 네임스페이스의 Pod 확인
kubectl get pods -n kube-system

예상 출력:

NAME                               READY   STATUS    RESTARTS   AGE
coredns-xxx                        1/1     Running   0          1d
etcd-minikube                      1/1     Running   0          1d
kube-apiserver-minikube            1/1     Running   0          1d
kube-controller-manager-minikube   1/1     Running   0          1d
kube-proxy-xxx                     1/1     Running   0          1d
kube-scheduler-minikube            1/1     Running   0          1d

노드 정보 확인#

# 노드 목록
kubectl get nodes

# 노드 상세 정보
kubectl describe node <node-name>

노드 상세 정보에서 확인할 수 있는 항목은 다음과 같습니다.

API Server 상태 확인#

# 클러스터 정보
kubectl cluster-info

# API 리소스 목록
kubectl api-resources

다음 단계#

아키텍처를 이해했다면 다음 단계로 진행하세요: