TIL

Kubernetes Concepts 개요

• 공식 Concepts 문서 정리
• 튜토리얼에서 Pod/Deployment/Service까지 맛봤다면, 이 문서는 그 바깥을 둘러싸는 개념(아키텍처, 네트워킹, 스토리지, 보안, 스케줄링)을 체계화한다.

쿠버네티스의 동작 모델

• 쿠버네티스는 선언적(declarative) 시스템
  • 사용자는 YAML로 “원하는 상태(desired state)”를 선언
  • 컨트롤러가 현재 상태를 관찰해 그 상태로 수렴
  • 이 “관찰 → 차이 계산 → 조정”의 반복을 컨트롤 루프라고 부름
• 모든 쿠버네티스 오브젝트는 공통 필드를 가진다.
  • apiVersion, kind — 리소스 타입
  • metadata — name, namespace, labels, annotations
  • spec — 사용자가 원하는 상태
  • status — 시스템이 관찰한 실제 상태. 사용자가 쓰는 필드가 아님
• 메타데이터 중 특히 중요한 것들
  • Namespace: 오브젝트 이름의 스코프를 나누는 논리적 경계. 팀/환경(dev/stage) 단위 격리에 사용
  • Label: 식별용 key/value. Service selector, Deployment selector, 모니터링 대상 분류 등 전반에 쓰임
  • Annotation: 도구·라이브러리가 참고하는 비식별 메타데이터 (빌드 SHA, 인증서 해시 등)

클러스터 아키텍처

┌─────────────────────────────────────────────────────┐
│                  Control Plane (두뇌)                │
│  ┌────────────┐  ┌────────┐  ┌──────────────────┐  │
│  │ API Server │─→│  etcd  │  │     Scheduler    │  │
│  └─────▲──────┘  └────────┘  └──────────────────┘  │
│        │                                            │
│        │         ┌──────────────────────────────┐  │
│        └─────────│ Controller Manager / Cloud CM│  │
│                  └──────────────────────────────┘  │
└────────▲────────────────────────────────────────────┘
         │ (kubelet이 주기적으로 API 호출)
┌────────┴────────────────────────────────────────────┐
│                 Worker Nodes (일꾼)                  │
│  ┌─────────┐  ┌────────────┐  ┌──────────────────┐ │
│  │ kubelet │  │ kube-proxy │  │ container runtime│ │
│  └─────────┘  └────────────┘  └──────────────────┘ │
│                      [ Pod ] [ Pod ] [ Pod ]        │
└─────────────────────────────────────────────────────┘

컨트롤 플레인 컴포넌트

• kube-apiserver
  • 모든 조작의 관문이 되는 REST API
  • 인증/인가, 유효성 검사, etcd 저장을 처리
  • kubectl도 결국 API Server를 호출
• etcd
  • 클러스터의 모든 상태를 저장하는 분산 KV 스토어 (Raft 합의)
  • 사실상 단일 진실 공급원(single source of truth)
• kube-scheduler
  • 아직 노드가 배정되지 않은 Pod를 적합한 노드에 배정
  • 자원 요구, affinity, taint를 고려
• kube-controller-manager
  • Deployment, ReplicaSet, Node, ServiceAccount 등 다양한 컨트롤 루프를 한 프로세스로 실행
• cloud-controller-manager
  • 클라우드 제공자 API와 연동 (LoadBalancer 프로비저닝, 노드 라이프사이클)
  • GKE에서는 Google이 운영

노드 컴포넌트

• kubelet: 노드 위에서 Pod 스펙을 받아 컨테이너를 띄우고 상태를 API Server로 보고
• kube-proxy: Service의 가상 IP를 실제 Pod로 라우팅하는 네트워크 규칙(iptables/IPVS)을 관리
• 컨테이너 런타임: containerd, CRI-O 등. CRI(Container Runtime Interface) 규격으로 kubelet과 통신

워크로드

• Pod 자체는 수동으로 만들지 않는다. 대신 아래 컨트롤러로 Pod의 생명주기·개수를 관리
• ReplicaSet
  • 지정된 개수의 Pod 복제본을 유지
  • 거의 항상 Deployment가 만들고 관리하므로 직접 다룰 일은 드묾
• Deployment
  • 상태 비저장(stateless) 앱용
  • 롤링 업데이트/롤백을 관리
  • 실무에서 가장 많이 쓰는 컨트롤러
• StatefulSet
  • 상태 유지(stateful) 앱용 (DB, Kafka 등)
  • 각 Pod에 안정적인 네트워크 식별자(<name>-0, <name>-1…)와 전용 영구 스토리지를 바인딩
  • 생성/종료 순서가 보장됨
• DaemonSet
  • 모든(또는 선택된) 노드에 Pod를 하나씩 띄움
  • 로그 수집기, 모니터링 에이전트, CNI 같은 노드 레벨 시스템에 사용
• Job: 완료를 목적으로 하는 일회성 태스크. 성공 조건을 만족하면 종료
• CronJob: Job을 cron 스케줄로 반복 실행
• HorizontalPodAutoscaler (HPA): CPU/메모리/커스텀 메트릭에 따라 Pod replica 개수를 자동 조정

서비스, 로드밸런싱, 네트워킹

• 쿠버네티스 네트워크 모델의 전제
  • 모든 Pod는 고유한 IP를 가진다.
  • 모든 Pod는 NAT 없이 서로 통신할 수 있다.
• Service
  • Pod 집합에 대한 안정적인 L4 접근점
  • ClusterIP/NodePort/LoadBalancer 타입은 01. 기본기 문서 참고
• Ingress
  • 경로/호스트 기반 HTTP(S) 라우팅 (L7)
  • Ingress 오브젝트 자체는 규칙 선언일 뿐
  • 실제 동작은 Ingress Controller(NGINX Ingress, GCE Ingress 등)가 구현
• Gateway API
  • Ingress의 후속 표준
  • 더 풍부한 트래픽 규칙(트래픽 분할, 헤더 기반 라우팅 등)을 지원
• NetworkPolicy
  • Pod 간/네임스페이스 간 L3/L4 트래픽 허용·차단 규칙
  • CNI 플러그인이 구현을 지원해야 동작
• DNS (CoreDNS)
  • Service는 <service>.<namespace>.svc.cluster.local 형태로 클러스터 DNS에 자동 등록

스토리지

• 컨테이너는 기본적으로 일회성이라 저장 장치를 별도 개념으로 다룬다.
• Volume
  • Pod 수명과 연결된 스토리지
  • 컨테이너가 재시작돼도 유지되지만 Pod가 사라지면 함께 사라지는 종류(emptyDir 등)도 있음
• PersistentVolume (PV)
  • 클러스터 수준에서 관리되는 실제 스토리지 (디스크, NFS, GCE PD 등)
  • Pod 수명과 독립적
• PersistentVolumeClaim (PVC)
  • 사용자가 요청하는 “스토리지 주문서” (크기, 액세스 모드, 스토리지 클래스)
  • 조건에 맞는 PV에 바인딩됨
• StorageClass
  • 동적 프로비저닝 정책
  • PVC가 요청되면 해당 클래스의 provisioner가 PV를 자동으로 생성
  • GKE에서는 기본 standard-rwo(Persistent Disk) 같은 클래스가 제공됨
• CSI (Container Storage Interface): 스토리지 벤더가 플러그인을 제공하는 표준 규격

설정 (Configuration)

• 설정을 코드(이미지)에서 분리해 런타임에 주입하는 것이 쿠버네티스의 원칙
• ConfigMap: 비민감 설정 (환경 변수, 프로퍼티 파일, 커맨드라인 인자)
• Secret
  • 민감 정보 (비밀번호, 토큰, 인증서)
  • base64 인코딩되어 저장되지만 암호화는 아님
  • etcd 암호화(envelope encryption)나 외부 시크릿 스토어(Secret Manager 등) 연동이 실무 권장
• Probe (헬스체크)
  • Liveness Probe: 실패 시 컨테이너를 재시작. “앱이 살아있는가?”
  • Readiness Probe: 실패 시 Service 엔드포인트에서 Pod를 제외해 트래픽을 차단. “앱이 트래픽을 받을 준비가 됐는가?”
  • Startup Probe: 초기 부팅이 긴 앱을 위한 기동 감지. Liveness/Readiness가 발동하기 전까지 시간을 벌어줌
• Resource Requests/Limits
  • CPU/메모리의 최소 보장치와 상한
  • 스케줄링은 requests 기준으로 동작
  • 상한 초과 시 CPU는 throttle, 메모리는 OOMKill

보안

• ServiceAccount
  • Pod가 쿠버네티스 API를 호출할 때 쓰는 자격 증명
  • 모든 Pod에는 기본 ServiceAccount가 자동 연결
• RBAC (Role-Based Access Control)
  • 사용자·ServiceAccount의 권한을 Role/ClusterRole + RoleBinding/ClusterRoleBinding으로 정의
  • 네임스페이스 스코프 vs 클러스터 스코프로 Role vs ClusterRole이 갈림
• Pod Security Admission
  • 네임스페이스 단위로 privileged / baseline / restricted 프로파일을 강제하는 어드미션
  • 과거 PodSecurityPolicy의 후속
• NetworkPolicy: 네트워크 레벨 격리
• Workload Identity (GKE)
  • GCP IAM 권한을 쿠버네티스 ServiceAccount에 안전하게 매핑
  • 노드에 서비스 계정 키 파일을 두지 않고도 Pod가 GCP 리소스에 접근 가능
  • GKE에서 GCP API를 호출할 때 사실상 표준

정책 (Policy)

• 멀티 팀 클러스터에서 특정 팀이 자원을 과점유하지 못하게 막는 기본 방어선
• ResourceQuota: 네임스페이스 단위로 CPU/메모리/오브젝트 수 등 총량을 제한
• LimitRange: 네임스페이스 내 컨테이너·Pod의 기본 requests/limits, 최소/최대값을 강제

스케줄링·선점·퇴출

• Scheduler
  • 새로 생성된 Pod에 대해 “필터링(자원·제약 확인) → 스코어링 → 바인딩” 순으로 노드를 선택
• nodeSelector / Node Affinity
  • “이런 라벨이 붙은 노드에만 배치”하는 규칙
  • GKE의 노드 풀 구분(예: GPU 풀, spot 풀)에 자주 활용
• Pod Affinity / Anti-Affinity: 특정 Pod 근처에 배치하거나 반대로 떨어뜨려 배치
• Taints and Tolerations
  • 노드가 “이 taint를 toleration으로 허용하는 Pod만 받겠다”고 선언하는 반대 방향 제어
  • 전용 노드(GPU 전용 등) 구성에 사용
• Topology Spread Constraints: 여러 존/노드에 Pod를 고르게 분산해 가용성을 높임
• Priority / Preemption: 우선순위가 높은 Pod가 스케줄되지 못하면 낮은 우선순위 Pod를 밀어내 자리 확보
• Eviction: 노드 자원 부족(memory pressure 등) 상황에서 kubelet이 Pod를 종료해 노드를 보호

클러스터 관리와 확장

• 클러스터 관리의 범주
  • 노드 추가/제거, 버전 업그레이드, etcd 백업, 인증서 갱신, 로깅/모니터링, CNI 플러그인 운영 등
  • GKE에서는 대부분 관리형으로 추상화 → Minikube 학습 때는 이 차이를 의식해두면 전환이 수월
• 쿠버네티스 자체를 확장하는 방식
  • CRD (Custom Resource Definition): 새 리소스 타입을 API에 추가
  • Operator: CRD + 전용 컨트롤러를 조합해 특정 애플리케이션(DB, Kafka 등)의 운영 지식을 코드화한 패턴
  • Admission Webhook
    • 오브젝트가 etcd에 저장되기 직전에 검증(validating) 또는 변형(mutating)
    • Gatekeeper·Kyverno 같은 정책 엔진이 동작하는 지점
  • Device Plugin: GPU/TPU 같은 특수 디바이스를 노드 자원으로 노출