topic★★★★★난이도 · 약 20분
Kubernetes 맛보기 — Pod·Deployment·Service·Ingress
컨테이너 여러 개를 자동 배치·복구·확장. 바이브코더는 언제 K8s를 선택할지 감만 잡는다.
#Kubernetes#K8s#Pod#Deployment#Service
왜 배우는가
대부분의 바이브코더 프로젝트에 K8s는 과하다. 하지만 팀 합류·면접·아키텍처 토론에서 용어가 나오면 당황한다. 개념 4개만 익히자.
Kubernetes(K8s)는 컨테이너 오케스트레이터. 수십~수만 컨테이너를 선언적 설정으로 배치·복구·확장. Google이 Borg 기반으로 2014년 오픈소스화.
| 객체 | 역할 | 비유 |
|---|---|---|
| Pod | 컨테이너 1~N개 묶음 (최소 실행 단위) | 아파트 한 채 |
| ReplicaSet | Pod N개 유지 | 같은 동 N호 복제 |
| Deployment | ReplicaSet + 배포·롤링 업데이트 관리 | 주택단지 관리자 |
| Service | Pod들을 하나의 네트워크 주소로 | 우편배달 입구 |
| Ingress | 외부→Service 라우팅 (도메인·HTTPS) | 정문 게이트 |
| ConfigMap/Secret | 설정·비밀 주입 | 열쇠·지침 |
| Namespace | 논리적 구획 | 구역 |
yaml
# 가장 자주 보는 최소 예시 — Deployment + Service
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3 # Pod 3개 유지
selector:
matchLabels: { app: myapp }
template:
metadata: { labels: { app: myapp } }
spec:
containers:
- name: web
image: myapp:1.0
ports: [{ containerPort: 3000 }]
env:
- name: DATABASE_URL
valueFrom: { secretKeyRef: { name: db-secret, key: url } }
resources:
requests: { cpu: "100m", memory: "256Mi" }
limits: { cpu: "500m", memory: "512Mi" }
readinessProbe: # 준비됐는가?
httpGet: { path: /healthz, port: 3000 }
livenessProbe: # 살아있는가?
httpGet: { path: /healthz, port: 3000 }
---
apiVersion: v1
kind: Service
metadata: { name: myapp }
spec:
selector: { app: myapp }
ports: [{ port: 80, targetPort: 3000 }]
type: ClusterIP이 파일을 `kubectl apply -f` 하면 K8s가 Pod 3개 띄우고, 하나 죽으면 자동 재생성. 트래픽은 Service가 로드밸런싱.
K8s는 언제 과한가. 일일 활성 유저 수천 명 이하·단일 지역·단일 서비스면 Vercel·Railway·Fly.io가 훨씬 쉽고 싸다. K8s는 수십 개 서비스·멀티 클러스터·복잡 네트워크가 필요할 때 진가.
관리형 K8s를 쓰면 대부분 복잡도가 숨겨진다. AWS EKS·Google GKE·Azure AKS. 클러스터 제어 평면은 클라우드가 관리, 바이브코더는 Deployment·Service YAML만 작성.
대안 — Vercel·Railway·Fly.io·Render. "컨테이너 운영을 몰라도 되는" PaaS. 스타트업·바이브코더에게 현실적. K8s는 문제가 K8s로만 풀릴 때 선택.
실기 드릴 2문항
edit실기 드릴 · 단답형
K8s에서 컨테이너를 감싸는 최소 실행 단위의 이름은?
check_circle실기 드릴 · OX
소규모 스타트업 앱도 K8s로 배포하는 것이 항상 최적이다.