개요

쿠버네티스는 명령을 조율하는 Control Plane과 실제 워크로드가 실행되는 Data Plane으로 구성됨 각 컴포넌트의 역할과 흐름을 이해하면 트러블슈팅, 성능 최적화, 보안 구성에 필요한 기준이 생김 클라우드 매니지드 쿠버네티스의 경우 Control Plane은 보통 제공자가 관리하지만 동작 원리 이해는 필수

Control Plane

API Server

  • 클러스터 유일 진입점
  • 모든 컴포넌트와 사용자는 API Server를 통해 통신
  • 인증과 권한 확인 수행

etcd

  • 클러스터 상태와 스펙을 보관하는 분산 키밸류 저장소
  • API Server만 직접 접근 가능
  • 상태 복구의 근간이 되는 데이터 원장

Scheduler

  • 스케줄링 되지 않은 파드를 관찰하고 적합한 노드를 선택
  • 리소스 사용량, 어피니티와 테인트, 스케줄링 정책 등을 고려
  • 노드 선택만 담당하며 파드 생성은 수행하지 않음

Controller Manager

  • 다양한 컨트롤러의 이벤트 루프 집합
  • 현재 상태를 관찰하고 선언적 원하는 상태를 유지하도록 조정

Cloud Controller Manager

  • 클라우드 공급자 API 연계 담당
  • 예시 구성에서는 외부 로드밸런서 생성, 노드 라우팅 정보 동기화 등을 위임

Data Plane

Kubelet

  • 노드별 에이전트
  • 파드 스펙을 감시하고 컨테이너 런타임에 생명주기 명령 전달
  • 파드 상태를 주기적으로 보고

kube-proxy

  • 서비스 네트워킹 데이터플레인 규칙 구현
  • iptables 또는 IPVS로 서비스, 엔드포인트 룰 관리
  • 일부 CNI 구현은 eBPF 등으로 프록시 없이 동작 가능하나 일반적 구성에서는 규칙 기반 전송 사용

Container Runtime

  • 컨테이너 실행 엔진 역할
  • containerd가 현재 표준으로 널리 사용, 기타 CRI 호환 런타임 존재

Controllers 상세

Workload

  • Deployment 웹앱 등 무상태 워크로드 롤링 업데이트와 롤백 관리
  • ReplicaSet 지정된 수의 파드 복제 개수 보장
  • DaemonSet 모든 노드 또는 선택된 노드에 1개씩 파드 배치, 로그나 모니터링 에이전트에 적합
  • StatefulSet 순서와 영속 스토리지 정체성이 필요한 워크로드에 적합
  • Job/CronJob 일회성 배치 또는 스케줄 주기 작업

Scaling

  • HPA 메트릭 기반 파드 수 자동 조정

파드 생성 흐름

  • 사용자가 스펙을 적용하면 API Server가 요청을 검증하고 etcd에 파드가 Pending으로 기록됨
  • Scheduler가 스케줄링 되지 않은 파드를 감지해 목표 노드를 결정함
  • 해당 노드의 Kubelet이 할당 사실을 감지하고 컨테이너 런타임에 실행을 지시함
  • 런타임이 컨테이너를 기동하면 Kubelet이 상태를 API Server에 보고하고 Running으로 갱신됨

Pod Deep Dive

논리적 위치

  • 파드는 컨테이너 런타임이 관리하는 격리된 실행 단위 내부에 존재
  • 노드 > Kubelet > 런타임 > 파드 > 컨테이너 구조로 관리됨

기술적 원리

  • 네임스페이스로 격리, cgroup으로 자원 제한 적용
  • 동일 파드 내 컨테이너는 네트워크 네임스페이스를 공유하므로 같은 IP 사용

디스크 경로 예시

  • 컨테이너 이미지와 레이어 배포판에 따라 /var/lib/containerd 등 런타임 디렉터리 사용
  • 파드 로그 /var/log/pods 경로 활용하는 배포판 다수 존재
  • 볼륨 마운트 /var/lib/kubelet/pods/[pod-uuid]/volumes 구조가 일반적

Pause 컨테이너

  • 파드 네임스페이스 소유자 역할을 하는 최소 컨테이너가 먼저 생성됨
  • 나머지 컨테이너는 이 네임스페이스에 합류하여 동일 네트워크와 IPC, PID 환경을 공유

Networking

Service

  • 변하는 파드 IP 위에 고정 진입점을 제공하는 가상 IP
  • ClusterIP 클러스터 내부 통신용
  • LoadBalancer 외부 노출을 위한 L4 엔드포인트

Ingress

  • L7 라우팅 구성으로 호스트와 경로 기반 분기 제공
  • 매니지드 환경에서는 Ingress 컨트롤러가 외부 로드밸런서를 생성하고 규칙을 동기화

DNS

  • CoreDNS가 서비스와 파드 이름을 IP로 해석해 통신 단순화

Storage

  • 파드는 일시적 존재이므로 데이터 영속화를 위해 볼륨 필요
  • PV 클러스터에 프로비저닝된 실제 스토리지 추상화
  • PVC 워크로드가 요청하는 스토리지 스펙과 바인딩 요구사항 선언
  • 동적 프로비저닝 StorageClass에 따라 CSI 드라이버가 자동으로 볼륨 생성과 바인딩 수행
  • 가용영역 종속 스토리지의 이동 제약 존재, 다중 가용영역 공유가 필요하면 네트워크 파일시스템 계열 선택 고려

Configuration과 보안

Configuration

  • ConfigMap 비민감 설정 분리 보관
  • Secret 민감 정보 저장, 전송과 저장 시 보호 구성 필요

보안 경계와 권한

  • Namespace로 워크로드와 리소스의 논리적 격리 구성
  • ServiceAccount는 파드의 신원 주체로 사용, RBAC로 권한 최소화 적용
  • 클라우드 연계 환경에서는 서비스계정 기반 IAM 연동 기능이 제공되며, 파드 단위 외부 리소스 접근 권한을 세분화 가능
  • 컨테이너 레벨 보안은 이미지 서명 검증, 런타임 권한 축소, PSP 대체 정책이나 정책 엔진 사용 등으로 보완

운영과 확장 생태계

Helm

  • 다수의 매니페스트를 차트로 패키징하여 템플릿 기반 배포와 버전 관리에 활용

Operators

  • 도메인 특화 운영을 자동화하는 커스텀 컨트롤러, 백업과 클러스터링 등 고급 시나리오 관리에 적합

노드 오토스케일링

  • 워크로드 대기로 인한 스케줄 실패 시 요구 리소스에 맞춘 노드 증설을 자동화하는 구성 사용

GitOps

  • 선언적 설정을 저장소에 보관하고 컨트롤러가 변경을 지속 동기화
  • 배포와 롤백 이력이 명확하며 재현 가능성 확보에 유리

Service Mesh

  • 사이드카 프록시를 통해 mTLS, 라우팅 제어, 관측성 기능을 표준화하고 애플리케이션 수정 없이 적용

Observability

  • Prometheus 계열로 메트릭 수집과 경보 구성
  • Grafana로 대시보드 시각화
  • Loki 등 로그 수집 스택으로 텍스트 로그 질의와 보관 수행

핵심 요약

  • Control Plane은 API Server, etcd, Scheduler, Controller Manager, 클라우드 연계 모듈로 구성
  • Data Plane은 노드 위 Kubelet, kube-proxy, 컨테이너 런타임과 파드로 구성
  • 파드는 네임스페이스와 cgroup으로 격리되고 동일 파드 내 네트워크 공유
  • Service와 Ingress로 안정적 엔드포인트와 L7 라우팅 구성
  • PV와 PVC, StorageClass로 영속 스토리지 동적 프로비저닝
  • ConfigMap과 Secret으로 설정과 비밀 분리, ServiceAccount와 RBAC로 최소 권한 적용
  • Helm, Operators, 오토스케일러, GitOps, Mesh, 관측성 스택으로 운영 자동화와 가시성 강화

참고자료