컨트롤 플레인은 쿠버네티스 클러스터의 두뇌이자 의사결정 계층으로, 워커 노드가 실제 워크로드를 돌리는 동안 전체 상태를 정의하고 조율하는 역할을 맡음 조직 비유로 보면 컨트롤 플레인은 본사와 경영진, 워커 노드는 지점과 현장 직원에 해당함

개념과 정의

컨트롤 플레인은 Desired State를 선언적으로 저장하고, Observed State와 비교해 일치하도록 끊임없이 조정하는 계층 사용자는 API를 통해 상태를 선언하고, 컨트롤 플레인은 스케줄링과 컨트롤 루프로 이를 만족하도록 시스템을 수렴시킴

핵심 구성요소

  • API 서버 kube-apiserver — 모든 요청의 진입점, 인증·인가·어드미션 수행 후 상태 변경을 etcd에 반영

    • kubectl, 컨트롤러, 스케줄러 등 모든 클라이언트는 API 서버를 통해 상호작용

    • 예시

      kubectl get pods
kubectl apply -f app.yaml

  • etcd — 클러스터 상태를 저장하는 분산 키-값 저장소

    • 네임스페이스, 파드, 서비스, 컨피그맵 등 모든 리소스 스펙과 상태 저장
    • 강한 일관성 기반으로 컨트롤 루프의 신뢰성에 핵심 역할

  • 스케줄러 kube-scheduler — 새 파드를 어떤 노드에 배치할지 결정

    • 리소스 여유, 어피니티/안티어피니티, 톨러레이션, 노드 셀렉터 등을 고려해 최적 노드 선택
    • 프리엠션과 스코어링으로 공정성과 효율성 균형 유지

  • 컨트롤러 매니저 kube-controller-manager — 다양한 컨트롤러의 조정 루프 실행

    • 레플리카셋, 잡, 데몬셋, 노드, 엔드포인트 등 컨트롤러가 선언된 상태에 맞게 생성·삭제·수정 수행
    • 핵심은 지속적 리컨실리에이션으로 상태 수렴 보장

동작 개요

  1. 사용자가 Desired State를 API로 제출
  2. etcd에 영속화
  3. 스케줄러가 파드 배치 결정
  4. 컨트롤러들이 실제 상태를 감시하고 조정
  5. 워커 노드의 kubelet이 파드 실행과 헬스 리포팅 수행 이 흐름이 반복되며 장애나 변동에도 선언된 상태로 복귀하는 자기치유 성질을 구현함

EKS와 일반 k8s 차이

관리 관점

  • 일반 k8s — 컨트롤 플레인 노드 설치, etcd 운영과 백업 전략, 버전 업그레이드 플랜, 보안 패치, 모니터링, 다중 AZ 기반 HA를 직접 설계·운영해야 함
  • EKS — 컨트롤 플레인은 완전관리형으로 제공, 마스터 노드와 etcd는 사용자가 접근·관리하지 않음, 내부적으로 백업·복구와 패치·HA가 관리됨, 제어플레인 로그를 CloudWatch로 전송 가능

비용 구조

  • 일반 k8s — 컨트롤 플레인 인프라 비용, 운영 인력 비용, 백업 스토리지와 모니터링 도구 비용을 직접 산정
  • EKS — 클러스터당 제어플레인 사용료가 시간 단위 과금, 워커 노드는 EC2 등 사용량 기반, EBS·ELB 등 연동 리소스는 각각 과금

통합 기능

  • 일반 k8s — 로드밸런서 연동, 스토리지 프로비저닝, 인증·인가, 로깅/모니터링을 별도 구성 필요
  • EKS — AWS Load Balancer Controller로 ALB/NLB 연동, EBS/EFS CSI 드라이버 통합, IAM Roles for Service Accounts IRSA로 퍼미션 연계, Control Plane 로깅과 메트릭의 CloudWatch 통합 용이

네트워킹

  • 일반 k8s — CNI 선택·설치, 네트워크 정책 구현, 인그레스 컨트롤러 구성 필요
  • EKS — AWS VPC CNI 기본 제공으로 VPC 네이티브 IP 모델, Security Groups for Pods로 L3/L4 격리 가능, 표준 Kubernetes NetworkPolicy는 별도 구현체 필요 Calico 등, 인그레스는 AWS Load Balancer Controller 사용 권장

실제 사용 예시

클러스터 생성

  • 일반 k8s — 컨트롤 플레인 노드 준비, kubeadm init, etcd 구성, CNI 설치, 인증서와 RBAC 설정, HA면 컨트롤 플레인 복수 AZ 배치와 프런트 VIP 구성 필요

  • EKS — 명령 몇 줄로 제어플레인과 매니지드 노드그룹 생성 가능

    eksctl create cluster \
  --name my-cluster \
  --region ap-northeast-2 \
  --nodes 2

업그레이드

  • 일반 k8s — 사전 etcd 스냅샷, 컨트롤 플레인 컴포넌트 순차 업그레이드, kubelet 및 CNI 애드온 호환성 검증, 워커 노드 롤링 업데이트가 필요

  • EKS — 컨트롤 플레인 버전을 먼저 올리고 노드그룹을 순차 업그레이드, 콘솔이나 eksctl로 진행 가능

    eksctl upgrade cluster \
  --name my-cluster \
  --version 1.24

주의와 베스트 프랙티스

  • 컨트롤 플레인 가용성 — 일반 k8s는 etcd 쿼럼과 컨트롤 플레인 노드 다중화가 핵심, EKS는 다중 AZ가 기본이지만 리전 장애 시 DR 전략 별도 고려 권장
  • 업그레이드 — 마이너 버전 스큐 정책과 애드온 호환성 체크, 사전 테스트 클러스터에서 리허설 권장
  • 보안 — EKS는 IRSA로 최소권한 부여, 일반 k8s는 OIDC 연계와 RBAC 최소화 적용, API 서버 접근 경계 명확화
  • 네트워크 정책 — EKS에서 SG for Pods와 NetworkPolicy는 모델이 다름, 필요한 레이어에 맞게 병행 설계 권장
  • 관측성 — 컨트롤 플레인 로그와 감사 로그 활성화, 메트릭 기반으로 컨트롤러 지연과 스케줄링 실패 감시

마무리

컨트롤 플레인은 선언된 상태를 기준으로 클러스터를 지속적으로 수렴시키는 조정자 역할을 수행함 일반 k8s는 높은 설계 자유도와 통제가 장점이나 운영 복잡도가 큼, EKS는 운영 부담을 크게 줄이는 대신 서비스 종속성과 과금 구조를 함께 고려해야 함 워크로드 특성과 팀의 운영 성숙도에 맞춰 관리형과 자가 운영형 중 합리적 선택 필요

참고자료