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

> Kubernetes 면접에서 자주 출제되는 Pod, Service, Deployment의 핵심 개념을 YAML 예제와 함께 상세히 정리합니다. 2026년 최신 트렌드를 반영한 실전 대비 가이드입니다.

- Published: 2026-04-04
- Updated: 2026-04-04
- Author: SharpSkill
- Tags: kubernetes, devops, interview, containers, orchestration
- Reading time: 11 min

---

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

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

> **핵심 요약**
>
> Pod는 단일 노드에서 하나 이상의 컨테이너를 실행합니다. Deployment는 Pod 레플리카와 롤아웃을 관리합니다. Service는 해당 Pod에 접근할 수 있는 안정적인 네트워크 엔드포인트를 제공합니다. 이 세 가지 오브젝트가 Kubernetes v1.35 이상 클러스터에서 워크로드 관리의 80%를 담당합니다.

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

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

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

```yaml
# 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 제한을 초과하면 스로틀링이 발생합니다.

> **면접 빈출 함정**
>
> requests 없이 memory limits만 설정하면 예측 불가능한 스케줄링이 발생합니다. kubelet이 실제로 해당 워크로드를 감당할 수 없는 노드에 Pod를 배치할 수 있습니다. 프로덕션 Pod에는 반드시 `requests`와 `limits`를 모두 설정해야 합니다.

## 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에 사용됩니다.

```yaml
# 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](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)는 ReplicaSet을 생성하고 관리하며, ReplicaSet은 다시 Pod를 관리합니다. Deployment 컨트롤러는 원하는 상태(desired state)를 감시하고 현실과 조정(reconcile)합니다. 스케일 업 시 Pod를 추가하고, 롤아웃 중에 Pod를 교체하며, 헬스 체크 실패 시 롤백을 수행합니다.

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

```yaml
# 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`로 제어) 롤백이 즉시 가능하며, 이미지를 다시 빌드할 필요가 없습니다.

```bash
# 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](https://kubernetes.io/docs/concepts/services-networking/service/)는 안정적인 가상 IP(ClusterIP)와 DNS 이름을 제공하여 레이블 셀렉터에 매칭되는 정상 Pod로 트래픽을 라우팅함으로써 이 문제를 해결합니다.

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

```yaml
# 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 프로덕션 트래픽 |

```yaml
# 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이 이 역할을 대신합니다.

> **Ingress를 대체하는 Gateway API**
>
> Kubernetes v1.35부터 Ingress NGINX 컨트롤러가 공식적으로 은퇴했습니다. [Gateway API](https://gateway-api.sigs.k8s.io/)가 HTTP 라우팅, TLS 종료, 트래픽 분할을 위한 권장 접근 방식으로 자리잡았습니다. 새로운 클러스터는 처음부터 Gateway API를 도입하는 것이 바람직합니다.

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

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

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

```yaml
# 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](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)(HPA)는 관측된 메트릭을 기반으로 레플리카 수를 조정합니다.

```yaml
# 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 면접 질문](/technologies/devops/interview-questions/kubernetes-basics)에서 이러한 주제를 인터랙티브 드릴로 학습할 수 있습니다.

## 결론

- 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` 명령어로 연습하는 것이 효과적입니다

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/ko/blog/devops/kubernetes-interview-pods-services-deployments-explained