에듀테크 프로젝트 대시보드
쿠버네티스 기초
컨테이너 하나를 docker run으로 띄우는 건 쉽지만, 컨테이너가 수십~수백 개가 되면
"어디서 실행하지?", "죽으면 누가 다시 살리지?", "트래픽은 어떻게 나누지?"가 문제가 된다.
쿠버네티스는 이걸 사람 대신 자동으로 관리해 주는 컨테이너 오케스트레이션(orchestration) 도구다.
쿠버네티스 클러스터는 "두뇌" 역할의 컨트롤 플레인과, 실제 컨테이너가 돌아가는 여러 대의 워커 노드로 이루어진다. 사람은 "이렇게 있어줘"라는 바라는 상태(desired state)만 선언하고, 나머지는 컨트롤 플레인이 계속 지켜본다.
Pod는 컨테이너를 담는 가장 작은 배포 단위, Deployment는 "이 Pod를 항상 N개 유지해줘"라고 선언하는 객체, Service는 그 Pod들 앞에서 요청을 나눠주는 고정된 창구다. 아래에서 Pod를 강제로 죽여 보거나 replica 수를 바꿔 보자 — 컨트롤 플레인이 몇 초 안에 실제 상태를 바라는 상태로 되돌린다.
쿠버네티스 최소 배포 단위. 컨테이너 1개(보통) 또는 밀접한 여러 개를 감싸며, 자체 IP를 하나 받는다. Pod는 일회용 — 죽으면 재사용 안 하고 새로 만든다.
"Pod를 N개 유지해줘"를 담당. Deployment는 ReplicaSet을 감싸서
버전 업그레이드·롤백 기능까지 더한 상위 객체다.
Pod는 죽고 다시 태어날 때마다 IP가 바뀐다. Service는 바뀌지 않는 이름 + 가상 IP로 그 뒤의 Pod 집합을 자동으로 찾아 로드밸런싱한다.
kubectl apply -f app.yaml처럼 "명령"이 아니라 "원하는 결과"를 적으면,
컨트롤 플레인이 현재 상태와 diff를 계속 맞춰 나간다(reconcile loop).
| 명령 | 설명 |
|---|---|
kubectl apply -f app.yaml | YAML에 적힌 바라는 상태를 클러스터에 반영 |
kubectl get pods | 현재 실행 중인 Pod 목록과 상태 확인 |
kubectl scale deploy/my-app --replicas=5 | Deployment의 replica 수를 즉시 변경 |
kubectl delete pod <name> | Pod 강제 종료 — Deployment가 있으면 즉시 새로 생성됨 |
kubectl logs -f <pod> | Pod 안 컨테이너의 표준출력 로그 실시간 확인 |
kubectl rollout undo deploy/my-app | 방금 배포한 버전을 이전 버전으로 롤백 |
systemd 서비스 5개로 직접 관리하고 있다(재시작·헬스체크도 수동).
쿠버네티스로 옮기면 각 앱을 Deployment로 선언해 Pod 수·자동 재시작·롤링 업데이트를 맡길 수 있지만,
클러스터 자체를 운영하는 학습·인프라 비용이 새로 생겨서 이 정도 규모에서는 오히려 과할 수 있다.