Kubernetes 면접 완벽 가이드: Pod, Service, Deployment 핵심 정리

Kubernetes 면접에서는 세 가지 핵심 오브젝트인 Pod, Service, Deployment에 대한 질문이 빠지지 않습니다. 컨테이너 스케줄링부터 네트워크 라우팅, 롤링 업데이트까지 이 세 요소의 상호작용을 깊이 이해하는 것이 단순히 정의를 암기하는 지원자와 프로덕션 시스템을 설계할 수 있는 지원자를 구분하는 기준이 됩니다.

이 가이드에서는 각 프리미티브를 프로덕션 수준의 YAML과 함께 살펴보고, 면접관이 중시하는 내부 동작 원리를 설명하며, DevOps 및 플랫폼 엔지니어링 면접에서 실제로 출제되는 질문들을 다룹니다.

Kubernetes Pod 이해하기: 가장 작은 배포 단위

Pod는 Kubernetes에서 스케줄링의 원자적 단위입니다. 동일한 네트워크 네임스페이스, IPC 네임스페이스, 스토리지 볼륨을 공유하는 하나 이상의 컨테이너를 감싸는 역할을 합니다. Pod 내부의 모든 컨테이너는 동일한 IP 주소를 부여받으며 localhost를 통해 형제 컨테이너와 통신할 수 있습니다.

단일 컨테이너 Pod가 가장 일반적인 패턴입니다. 멀티 컨테이너 Pod는 사이드카 시나리오에 사용되며, 로그 수집기, 서비스 메시, 또는 메인 프로세스 시작 전에 파일 시스템을 준비하는 init 컨테이너 등이 해당됩니다.

# api-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: api-server
  labels:
    app: api
    version: v2
spec:
  containers:
    - name: api
      image: registry.example.com/api:3.1.0
      ports:
        - containerPort: 8080
      resources:
        requests:
          cpu: "250m"
          memory: "256Mi"
        limits:
          cpu: "500m"
          memory: "512Mi"
      readinessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 20

resources 블록은 면접에서 핵심적인 부분입니다. requests는 스케줄링을 결정하며, 스케줄러는 충분한 가용 용량이 있는 노드에 Pod를 배치합니다. limits는 런타임 상한선을 적용하며, 메모리 제한을 초과하면 OOMKill이 발생하고 CPU 제한을 초과하면 스로틀링이 발생합니다.

Pod 라이프사이클 단계와 재시작 정책

Kubernetes는 모든 Pod를 다섯 가지 단계로 추적합니다: Pending, Running, Succeeded, Failed, Unknown. 면접관은 각 전환이 어떤 상황에서 발생하는지 자주 질문합니다.

| 단계 | 의미 | 일반적인 원인 | |------|------|---------------| | Pending | 스케줄링되었지만 실행되지 않음 | 이미지 풀링, 리소스 부족 | | Running | 하나 이상의 컨테이너가 활성 상태 | 정상 운영 | | Succeeded | 모든 컨테이너가 종료 코드 0으로 종료 | 배치 작업, init 컨테이너 | | Failed | 하나 이상의 컨테이너가 0이 아닌 코드로 종료 | 애플리케이션 크래시, OOMKill | | Unknown | 노드 통신 두절 | 네트워크 파티션, 노드 장애 |

restartPolicy 필드는 컨테이너 종료 후 동작을 제어합니다. Always(Deployment의 기본값)는 종료 코드에 관계없이 재시작합니다. OnFailure는 0이 아닌 종료 코드에서만 재시작하며, Job에 유용합니다. Never는 컨테이너를 종료 상태로 유지하며, 일회성 디버그 Pod에 사용됩니다.

# batch-job-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: data-migration
spec:
  restartPolicy: OnFailure
  containers:
    - name: migrate
      image: registry.example.com/migrate:1.0.0
      command: ["python", "migrate.py"]
      env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: connection-string

valueFrom.secretKeyRef 패턴은 민감한 데이터를 매니페스트 밖에 보관합니다. Kubernetes Secret은 기본적으로 base64 인코딩되어 있을 뿐 암호화되지 않습니다. 프로덕션 환경에서는 EncryptionConfiguration API를 통해 저장 시 암호화를 활성화하거나 HashiCorp Vault 같은 외부 시크릿 관리자를 사용해야 합니다.

Kubernetes Deployment: 선언적 롤아웃과 스케일링

Deployment는 ReplicaSet을 생성하고 관리하며, ReplicaSet은 다시 Pod를 관리합니다. Deployment 컨트롤러는 원하는 상태(desired state)를 감시하고 현실과 조정(reconcile)합니다. 스케일 업 시 Pod를 추가하고, 롤아웃 중에 Pod를 교체하며, 헬스 체크 실패 시 롤백을 수행합니다.

프로덕션에서 Pod를 직접 생성하는 것은 거의 적절하지 않습니다. Deployment는 레플리카 관리, 롤링 업데이트, 롤백 히스토리, 일시 중지/재개 기능을 제공합니다.

# api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api
spec:
  replicas: 3
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      app: api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: api
        version: v2
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

strategy.rollingUpdate 섹션은 무중단 배포 동작을 정의합니다. maxUnavailable: 1과 maxSurge: 1을 설정하면, Kubernetes는 새로운 Pod 하나를 생성하고 readiness 체크를 통과할 때까지 기다린 후 이전 Pod 하나를 종료합니다. 이 과정이 모든 레플리카가 새 버전으로 실행될 때까지 반복됩니다.

실패한 Kubernetes Deployment 롤백하기

롤백은 면접에서 매우 자주 출제되는 주제입니다. Deployment 컨트롤러는 이전 ReplicaSet을 보관하므로(revisionHistoryLimit로 제어) 롤백이 즉시 가능하며, 이미지를 다시 빌드할 필요가 없습니다.

# Check rollout status
kubectl rollout status deployment/api-server

# View revision history
kubectl rollout history deployment/api-server

# Roll back to previous version
kubectl rollout undo deployment/api-server

# Roll back to specific revision
kubectl rollout undo deployment/api-server --to-revision=3

undo 명령은 대상 리비전의 Pod 템플릿과 일치하도록 Deployment 스펙을 패치합니다. 이후 롤링 업데이트 전략이 정상적으로 적용되어 현재 Pod를 롤백 버전으로 점진적으로 교체합니다.

Kubernetes Service: 동적 Pod를 위한 안정적인 네트워킹

Pod는 임시적(ephemeral)입니다. 재시작할 때마다 새로운 IP 주소를 부여받습니다. Service는 안정적인 가상 IP(ClusterIP)와 DNS 이름을 제공하여 레이블 셀렉터에 매칭되는 정상 Pod로 트래픽을 라우팅함으로써 이 문제를 해결합니다.

각 노드의 kube-proxy 컴포넌트가 iptables 또는 IPVS 규칙을 프로그래밍하여 백엔드 Pod 간에 트래픽을 분산합니다. Pod가 readiness probe에 실패하면 Endpoints 컨트롤러가 해당 Pod를 Service에서 제거하여 비정상 인스턴스에는 트래픽이 도달하지 않습니다.

# api-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: ClusterIP
  selector:
    app: api
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP

생성 후 클러스터 내 모든 Pod는 api-service.default.svc.cluster.local(동일 네임스페이스 내에서는 api-service만으로도 가능)로 이 Service에 접근할 수 있습니다. CoreDNS가 이름 해석을 담당합니다.

Service 유형: ClusterIP, NodePort, LoadBalancer

면접관은 지원자가 세 가지 주요 Service 유형과 각각의 적용 시나리오를 설명할 수 있기를 기대합니다.

| 유형 | 접근 범위 | 사용 사례 | |------|----------|----------| | ClusterIP | 클러스터 내부 전용 | 백엔드 API, 데이터베이스, 캐시 | | NodePort | <NodeIP>:<Port>를 통한 외부 접근 | 개발 환경, 베어메탈 클러스터 | | LoadBalancer | 클라우드 로드 밸런서를 통한 외부 접근 | AWS/GCP/Azure 프로덕션 트래픽 |

# api-loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-public
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - name: https
      port: 443
      targetPort: 8080
      protocol: TCP

LoadBalancer 유형은 클라우드 프로바이더의 로드 밸런서 컨트롤러를 트리거하여 외부 엔드포인트를 프로비저닝합니다. AWS에서는 어노테이션에 따라 NLB 또는 ALB가 생성됩니다. 클라우드 통합이 없는 베어메탈 클러스터에서는 MetalLB나 kube-vip이 이 역할을 대신합니다.

Deployment와 Service를 레이블 셀렉터로 연결하기

Deployment와 Service 사이의 연결은 레이블 셀렉터뿐이며, 두 오브젝트 간에 명시적 참조는 존재하지 않습니다. Service는 spec.selector와 레이블이 매칭되는 Pod를 감시하고 자동으로 Endpoints 목록을 유지합니다.

이 분리된 아키텍처 덕분에 하나의 Service가 여러 Deployment의 Pod로 트래픽을 라우팅할 수 있으며(카나리 릴리스에 유용), 하나의 Deployment가 여러 Service에 의해 노출될 수도 있습니다(서로 다른 포트, 서로 다른 접근 수준).

# canary-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
        version: v3-canary
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.2.0-rc1
          ports:
            - containerPort: 8080

메인 Deployment가 3개의 레플리카를, 카나리가 1개의 레플리카를 실행하면 Service는 약 25%의 트래픽을 카나리로 분배합니다. Service 설정 변경 없이 레이블 매칭이 모든 것을 처리합니다.

Kubernetes Deployment를 위한 Horizontal Pod Autoscaling

고정된 레플리카 수는 트래픽이 적을 때 리소스를 낭비하고 급증 시 과부하를 초래합니다. HorizontalPodAutoscaler(HPA)는 관측된 메트릭을 기반으로 레플리카 수를 조정합니다.

# api-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300

HPA는 기본적으로 15초마다 메트릭 서버를 폴링합니다. Kubernetes v1.35에서는 하드코딩된 10% 임계값을 대체하는 설정 가능한 HPA 허용 오차가 도입되었습니다. 이로 인해 지연에 민감한 워크로드를 운영하는 팀은 더 세밀한 스케일링 트리거를 설정할 수 있게 되었습니다.

behavior.scaleDown.stabilizationWindowSeconds는 버스트 트래픽 패턴으로 인한 급격한 스케일 업/다운 사이클인 플래핑(flapping)을 방지합니다.

Kubernetes 면접 빈출 질문과 답변

아래 질문들은 DevOps 및 플랫폼 엔지니어링 면접에서 반복적으로 출제됩니다. 각 답변은 면접관이 기대하는 수준의 깊이를 목표로 합니다.

Pod가 메모리 제한을 초과하면 어떻게 됩니까? kubelet이 OOM killer를 통해 SIGKILL을 전송합니다. 컨테이너는 종료 코드 137로 종료됩니다. Deployment 컨트롤러가 실패한 Pod를 감지하고 재시작 정책 및 백오프 지연에 따라 대체 Pod를 생성합니다.

카나리 릴리스 중 Kubernetes는 어떻게 특정 Pod 버전으로 트래픽을 라우팅합니까? Service 셀렉터는 공유 레이블(예: app: api)에 매칭됩니다. 안정 버전과 카나리 Deployment 모두 이 레이블을 사용합니다. 트래픽 분배는 준비 완료된 엔드포인트 수에 비례합니다. 안정 레플리카 3개와 카나리 레플리카 1개이면 카나리 트래픽은 약 25%가 됩니다. 정밀한 트래픽 분할(예: 5%)이 필요한 경우 가중치 백엔드를 가진 Gateway API HTTPRoute를 사용합니다.

readinessProbe와 livenessProbe의 차이점은 무엇입니까? readiness probe는 Pod가 Service로부터 트래픽을 수신할지 여부를 제어합니다. readiness probe 실패 시 Pod가 Endpoints 목록에서 제거되지만 재시작되지는 않습니다. liveness probe는 컨테이너의 재시작 여부를 제어합니다. liveness probe 실패 시 컨테이너가 재시작됩니다. 두 프로브 모두 HTTP, TCP, exec 체크를 사용할 수 있습니다.

롤링 업데이트는 어떻게 무중단을 보장합니까? Deployment 컨트롤러는 maxSurge와 maxUnavailable에 의해 제어되며, 이전 Pod를 종료하기 전에 새로운 Pod를 먼저 생성합니다. 새로운 Pod는 이전 Pod가 드레인되기 전에 readiness probe를 통과해야 합니다. terminationGracePeriodSeconds(기본값: 30초)는 SIGKILL 전에 진행 중인 요청이 완료될 시간을 제공합니다.

Kubernetes 면접 준비는 이론만이 아닌 실전 YAML 작성 연습이 필요합니다. SharpSkill의 DevOps 면접 질문에서 이러한 주제를 인터랙티브 드릴로 학습할 수 있습니다.

결론

• Pod는 스케줄링의 단위입니다. 항상 리소스 requests와 limits를 설정하고, readiness probe와 liveness probe를 모두 구성해야 합니다
• Deployment는 ReplicaSet을 통해 레플리카 수, 롤링 업데이트, 롤백 히스토리를 관리합니다. 프로덕션에서 Pod를 직접 생성하는 것은 절대 지양해야 합니다
• Service는 레이블 셀렉터와 가상 IP를 통해 안정적인 네트워킹을 제공합니다. 내부 트래픽에는 ClusterIP를, 외부 트래픽에는 LoadBalancer를 사용합니다
• Deployment와 Service 간의 연결은 순수하게 레이블 기반이므로 설정 변경 없이 카나리 패턴을 구현할 수 있습니다
• HPA는 CPU/메모리 메트릭을 기반으로 Deployment를 스케일링합니다. 플래핑 방지를 위해 stabilizationWindowSeconds를 활용합니다
• Gateway API는 Kubernetes v1.35부터 Ingress NGINX를 대체합니다. 신규 프로젝트는 처음부터 Gateway API를 도입해야 합니다
• 정의를 암기하는 것보다 실제 YAML 매니페스트와 kubectl 명령어로 연습하는 것이 효과적입니다