DevOps

쿠버네티스(Kubernetes)에 대해서 설명해주세요

Docker만으로 부족한 이유, 클러스터 아키텍처, Pod·Deployment·Service 핵심 오브젝트, Desired State 철학, 롤링 업데이트와 HPA까지 인터랙티브 시각화로 완전 정복합니다.

2026년 3월 15일 · 약 14분 읽기

Q. "쿠버네티스가 무엇인지, 그리고 Docker와 어떻게 다른지 설명해주세요."

예상 꼬리질문

답변 가이드

"쿠버네티스는 컨테이너 오케스트레이션 플랫폼입니다. Docker가 컨테이너를 실행한다면, K8s는 수백 개의 컨테이너를 자동으로 배포·스케일링·자가 치유합니다."

"클러스터는 Control Plane(API Server·etcd·Scheduler·Controller Manager)과 Worker Node(kubelet·Pod)로 구성됩니다. Pod는 최소 배포 단위이고, Deployment가 Pod 집합을 관리하며, Service가 고정 IP를 제공합니다."

"핵심 철학은 Desired State입니다. 원하는 상태를 선언하면 Controller Manager가 실제 상태를 맞춰 자가 치유합니다. 롤링 업데이트로 무중단 배포, HPA로 자동 스케일링을 실현합니다."

Docker로 컨테이너를 잘 쓰고 있는데 왜 쿠버네티스가 필요할까요? 컨테이너가 5개일 때는 Docker만으로 충분합니다. 하지만 수백 개의 컨테이너가 수십 대의 서버에 흩어져 있을 때 쿠버네티스가 필요합니다.

이 아티클에서는 면접의 꼬리질문 흐름을 따라가며, 각 개념을 직접 만져볼 수 있는 시각화로 체험합니다.

1. Docker만으로 부족한 이유

꼬리질문: "Docker만 있으면 되지 왜 쿠버네티스가 필요한가요?"

Docker는 컨테이너를 실행하는 도구입니다. 컨테이너가 죽으면 자동으로 재시작하거나, 트래픽에 맞게 수를 늘리거나, 여러 서버에 분산 배포하는 것은 Docker 단독으로는 어렵습니다.

이런 운영 자동화 — 자동 재시작(Self-Healing), 자동 스케일링(HPA), 무중단 배포(Rolling Update) — 를 제공하는 것이 쿠버네티스입니다.

Docker와 쿠버네티스의 역할 차이를 비교해 보세요.

카드를 클릭하면 Docker vs Kubernetes 대응 방식을 비교할 수 있습니다

💥
컨테이너 크래시
📈
트래픽 급증
🔄
버전 업데이트
🖥️
다중 서버 관리

2. 클러스터 아키텍처

꼬리질문: "Control Plane과 Worker Node의 역할을 설명해주세요"

K8s 클러스터는 Control Plane과 Worker Node로 구성됩니다. Control Plane의 API Server는 모든 요청의 진입점이고, etcd는 클러스터 전체 상태를 저장하는 분산 DB입니다.

Scheduler는 새 Pod를 어느 Node에 배치할지 결정하고, Controller Manager는 실제 상태가 원하는 상태와 일치하도록 조정합니다. Worker Node의 kubelet은 Control Plane 지시를 받아 실제로 컨테이너를 실행합니다.

클러스터 구성 요소와 요청 흐름을 직접 탐색해 보세요.

kubectl→API Server
Control Plane
API Server
etcd
Scheduler
Controller Manager
Worker Nodes
Node 1
kubelet
Pod APod B
Node 2
kubelet
Pod C
Node 3
kubelet
Pod DPod E

각 컴포넌트를 클릭하면 역할 설명이 표시됩니다

3. 핵심 오브젝트 — Pod, Deployment, Service

꼬리질문: "Pod, Deployment, Service의 차이를 설명해주세요"

Pod는 K8s의 최소 배포 단위입니다. 보통 컨테이너 1개를 담습니다. Deployment는 Pod 집합을 관리하고 원하는 수(replicas)를 유지합니다.

Service는 Pod 집합에 고정 IP와 DNS를 제공하여 Pod가 교체되어도 클라이언트가 항상 같은 주소로 접근할 수 있게 합니다.

각 오브젝트의 역할과 관계를 직접 탐색해 보세요.

YAML
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
동작 시각화
Pod: my-pod
nginx:1.25
:80
직접 생성 시 Pod 삭제되면 복구되지 않습니다. Deployment 사용을 권장합니다.
Pod는 K8s의 최소 배포 단위입니다. 하나 이상의 컨테이너가 같은 네트워크/스토리지를 공유합니다. 직접 생성하면 자동 복구가 되지 않아 보통 Deployment를 사용합니다.

4. Desired State 철학 — 선언적 관리

꼬리질문: "Desired State 철학이 무엇이고 어떤 장점이 있나요?"

쿠버네티스의 핵심 철학은 Desired State(원하는 상태)입니다. "Pod 3개를 유지하라"고 선언하면 Controller Manager가 실제 Pod 수를 지속적으로 감시합니다.

Pod가 죽으면 자동으로 새 Pod를 생성해 3개를 맞춥니다. 이것이 자가 치유(Self-Healing)입니다. 관리자가 "무엇을 해라"고 명령하는 것이 아니라 "어떤 상태이어야 한다"고 선언하면 K8s가 나머지를 처리합니다.

Pod를 삭제해 자가 치유가 동작하는 모습을 직접 체험해 보세요.

Node 1
Pod ✓
Node 2
Pod ✓
Node 3
Pod ✓
Controller Manager
Actual: 3 = Desired: 3 → 조화 상태
실제(Actual): 3 / 원하는(Desired): 3

5. 롤링 업데이트와 자동 스케일링(HPA)

꼬리질문: "롤링 업데이트와 HPA는 어떻게 동작하나요?"

롤링 업데이트는 Pod를 하나씩 새 버전으로 교체합니다. 전환 중에도 항상 최소 Pod 수를 유지하므로 서비스가 중단되지 않습니다. 문제가 발생하면 즉시 롤백할 수 있습니다.

HPA(Horizontal Pod Autoscaler)는 CPU 사용률, 메모리, 커스텀 메트릭을 기준으로 Pod 수를 자동으로 조절합니다. 트래픽이 몰리면 자동 확장, 줄어들면 자동 축소하여 비용을 최적화합니다.

롤링 업데이트 과정과 HPA 동작을 시뮬레이션해 보세요.

v1
Pod 1
v1
Pod 2
v1
Pod 3
롤링 업데이트: v1 Pod를 하나씩 v2로 교체합니다. 전체 교체 중에도 서비스가 유지됩니다.

면접 체크리스트

이 항목들을 자신 있게 설명할 수 있다면 쿠버네티스 질문은 준비 완료입니다.

  • - K8s의 역할: 컨테이너 오케스트레이션 — 자동 재시작, 스케일링, 무중단 배포
  • - 클러스터 구성: Control Plane(API Server·etcd·Scheduler·Controller Manager) + Worker Node(kubelet)
  • - 핵심 오브젝트: Pod(최소 단위) → Deployment(Pod 관리) → Service(고정 IP 제공)
  • - Desired State: 선언적 관리 + 자가 치유 — "원하는 상태"를 선언하면 K8s가 유지
  • - 롤링 업데이트 + HPA: 무중단 배포 + CPU 기반 자동 스케일링

참고 자료

의견을 들려주세요

서비스 개선에 큰 도움이 됩니다. 익명으로 자유롭게 남겨주세요.

0 / 1000