Kubernetes 101

Kubernetes(K8s)는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈소스 오케스트레이션 플랫폼이다.

본 글은 Kubernetes 의 기본 컴포넌트들에 대해서 설명하는 글이다.

Pod

Kubernetes에서 가장 작은 배포 단위이다. 하나 이상의 컨테이너를 묶어 네트워크와 스토리지를 공유한다.

• 같은 Pod 내 컨테이너는 동일한 네트워크 네임스페이스(IP, 포트)를 공유한다

• localhost로 컨테이너 간 통신이 가능하다

• 본질적으로 일시적(ephemeral) 이다 — 언제든 삭제되고 재생성될 수 있다

• Controller(Deployment, StatefulSet 등)를 통해 관리한다

Service

Pod에 대한 네트워크 접근을 제공하는 추상화 계층이다. 고정된 IP와 DNS를 제공한다.

유형	접근 범위	특징	사용 시점
ClusterIP (기본값)	클러스터 내부	가상 IP 할당, 외부 접근 불가	내부 마이크로서비스 간 통신
NodePort	외부 (노드 포트)	30000-32767 포트 개방, 모든 노드에서 접근 가능	개발/테스트 환경
LoadBalancer	외부 (LB)	클라우드 LB와 연동, NodePort + ClusterIP 자동 생성	프로덕션 외부 트래픽
ExternalName	DNS 매핑	CNAME 레코드 생성, 프록시 없음	외부 서비스 추상화, 마이그레이션

Headless Service: ClusterIP: None으로 설정하면 개별 Pod의 IP를 직접 반환한다. StatefulSet에서 각 Pod에 직접 접근할 때 사용한다.

Ingress & Gateway API

Ingress

클러스터 외부에서 내부 Service로의 HTTP/HTTPS 라우팅을 관리하는 리소스이다.

• L7(HTTP/HTTPS) 로드 밸런싱

• 호스트/경로 기반 라우팅

• SSL/TLS 종료(Termination)

• Annotation에 의존하는 설정 방식 (컨트롤러마다 다름)

Ingress NGINX는 2026년 3월 지원 종료 예정이다. 이후 버그 수정, 보안 패치가 중단되므로 Gateway API로의 마이그레이션이 필수이다.

Gateway API

Ingress를 대체하는 차세대 트래픽 관리 API이다.

비교 항목	Ingress	Gateway API
프로토콜	HTTP/HTTPS만	HTTP, HTTPS, gRPC, TCP, UDP
설정 방식	Annotation 의존	네이티브 리소스 정의
역할 분리	없음	GatewayClass / Gateway / Route 분리
트래픽 분할	컨트롤러별 상이	네이티브 지원 (Canary, A/B)
멀티테넌시	제한적	네이티브 지원

flowchart TB
    subgraph "Infra Provider"
        GC[GatewayClass]
    end
    subgraph "Cluster"
        GW[Gateway]
    end
    subgraph "Application"
        HR[HTTPRoute]
        GR[GRPCRoute]
        TR[TCPRoute]
    end

    GC --> GW
    GW --> HR
    GW --> GR
    GW --> TR
    HR --> SVC1[Service A]
    HR --> SVC2[Service B]
    GR --> SVC3[Service C]

Deployment & Replicaset

Stateless 애플리케이션의 선언적 배포와 업데이트를 관리하는 컨트롤러이다.

flowchart TB
    Deployment --> RS1["ReplicaSet (v2, 현재)"]
    Deployment --> RS2["ReplicaSet (v1, 이전)"]
    RS1 --> Pod1[Pod]
    RS1 --> Pod2[Pod]
    RS1 --> Pod3[Pod]
    RS2 -.-> |롤백 시 활성화| Pod4[Pod]

Rolling Update 로 동작한다

1. 새로운 ReplicaSet을 생성하고, 새 Pod를 점진적으로 추가한다

2. 새 Pod가 Ready 상태가 되면, 이전 ReplicaSet의 Pod를 하나씩 종료한다

3. maxUnavailable과 maxSurge 파라미터로 속도를 제어한다

4. 문제 발생 시 kubectl rollout undo로 즉시 롤백이 가능하다

Statefulset

상태가 있는(Stateful) 애플리케이션을 위한 컨트롤러이다. 안정적인 네트워크 ID와 영구 스토리지를 보장한다.

Statefulset vs Deployment

항목	Deployment	StatefulSet
Pod 이름	랜덤 (app-xyz123)	순차적 (app-0, app-1, app-2)
생성/삭제 순서	임의	순서 보장 (0 → 1 → 2)
스토리지	공유 또는 없음	Pod별 개별 PVC
네트워크 ID	불안정	안정적 (pod-name.svc.ns.svc.cluster.local)

Daemonset

모든 노드(또는 선택된 노드)에 Pod 하나씩을 실행하는 컨트롤러이다.

• 노드가 추가되면 자동으로 Pod를 배치한다

• 노드가 제거되면 해당 Pod도 함께 제거된다

• tolerations과 nodeSelector로 특정 노드만 선택할 수 있다

PersistentVolume (PV) & PersistentVolumeClaim (PVC)

스토리지 프로비저닝(PV)과 소비(PVC)를 분리하는 추상화 계층이다.

flowchart LR
    Admin -->|Static Provisioning| PV[PersistentVolume]
    SC[StorageClass] -->|Dynamic Provisioning| PV
    User -->|Request| PVC[PersistentVolumeClaim]
    PVC -->|Binding| PV
    Pod -->|Mount| PVC
    PV --> Storage[(실제 스토리지)]

핵심 개념

개념	설명
PV	클러스터 수준의 스토리지 리소스
PVC	스토리지 요청 (크기, 접근 모드 지정)
StorageClass	동적 프로비저닝 템플릿 (PVC 생성 시 자동으로 PV 생성)
CSI Driver	Container Storage Interface 플러그인

StorageClass

PV/PVC만으로도 스토리지를 사용할 수 있지만, 매번 수동으로 PV를 미리 만들어 놓아야 한다는 불편함이 있다.

StorageClass는 이 과정을 자동화한다.

간단하게 비유해보자면 다음과 같다.

• StorageClass 없이 (정적 프로비저닝): 창고에 빈 USB를 여러 개 준비해 둔다 → “10GB짜리 하나 주세요” 하면 맞는 게 있을 때만 연결된다

• StorageClass 있으면 (동적 프로비저닝): “SSD 타입, 10GB” 라고 주문서(PVC)만 작성하면, StorageClass가 자동으로 실제 스토리지를 생성하고 PV를 만들어 바인딩해준다

CSI Driver

Kubernetes는 다양한 스토리지 시스템(AWS EBS, Google PD, Ceph, NFS 등)과 연결해야 한다.

하지만 각 스토리지마다 API와 동작 방식이 다르다.

CSI(Container Storage Interface) Driver는 이 차이를 추상화하는 표준 인터페이스이다.

• Kubernetes는 “볼륨 생성해줘, 볼륨 붙여줘, 볼륨 떼줘”

• CSI Driver가 이를 각 스토리지 시스템의 고유 API로 번역(?)해서 실행한다

• 마치 USB 포트처럼, 어떤 저장장치든 CSI 규격만 맞으면 Kubernetes에 연결할 수 있다

Access Modes

• ReadWriteOnce (RWO): 단일 노드에서 읽기/쓰기

• ReadOnlyMany (ROX): 다수 노드에서 읽기 전용

• ReadWriteMany (RWX): 다수 노드에서 읽기/쓰기

Reclaim Policy

• Delete: PVC 삭제 시 PV와 실제 스토리지 함께 삭제

• Retain: PVC 삭제 후에도 PV와 데이터 보존 (수동 정리 필요)

ConfigMap & Secret

애플리케이션 설정 데이터와 민감 정보를 Pod와 분리하여 관리하는 리소스이다.

항목	ConfigMap	Secret
용도	설정 데이터	비밀번호, 토큰, 키 등 민감 정보
인코딩	평문	Base64 인코딩 (기본값, 암호화 아님)
보안	없음	RBAC 접근 제어, 암호화 at rest 권장

Job & CronJob

일회성 작업(Job)과 주기적 작업(CronJob) 을 관리하는 컨트롤러이다.

Job

• 성공적 완료(또는 실패 임계값 도달)까지 Pod를 실행한다

• backoffLimit: 최대 재시도 횟수

• activeDeadlineSeconds: 작업 타임아웃

• ttlSecondsAfterFinished: 완료 후 자동 정리 시간

• parallelism: 동시 실행 Pod 수

CronJob

• Unix cron 스케줄 기반으로 Job을 주기적으로 생성한다

• concurrencyPolicy: Allow / Forbid / Replace (중복 실행 정책)

• successfulJobsHistoryLimit / failedJobsHistoryLimit: 히스토리 보관 수

Namespace

클러스터 내 논리적 격리 단위이다. 리소스를 팀, 환경, 애플리케이션 단위로 분리한다.

주요 용도

1. 리소스 격리: ResourceQuota로 네임스페이스별 CPU/메모리 한도 설정

2. 접근 제어: RBAC으로 네임스페이스별 권한 관리

3. 네트워크 격리: NetworkPolicy로 네임스페이스 간 트래픽 제어

4. 조직 구조: 팀별, 환경별(dev/staging/prod), 앱별 분리

HPA(Horizontal Pod Autoscaler)

관측된 메트릭을 기반으로 Pod 수를 자동 조정하는 컨트롤러이다.

지원 메트릭

1. Resource Metrics: CPU, 메모리 사용률 (Metrics Server 필요)

2. Custom Metrics: RPS, 큐 길이 등 (Prometheus Adapter 필요)

3. External Metrics: 클라우드 제공자 메트릭, 외부 모니터링 시스템