쿠버네티스 이해

쿠버네티스는 컨테이너 오케스트레이션을 위한 플랫폼이다. 여러 노드에서 실행되는 애플리케이션의 원하는 상태를 선언하고, 실제 상태가 그 상태에 가까워지도록 조정한다.

오케스트레이션(Orchestration)은 배치, 실행, 교체, 확장 같은 단계를 함께 관리한다는 뜻이다. 예를 들어 “웹 서버를 3개 실행한다”라고 Deployment에 기록해 두면, Pod 하나가 종료됐을 때 컨트롤러가 새 Pod를 만들도록 조정한다. 그러나 애플리케이션의 데이터 무결성이나 올바른 응답까지 보장하는 것은 아니다.

flowchart LR
    A[관리자: 원하는 상태 선언] --> B[API 서버]
    B --> C[etcd: 클러스터 상태 저장]
    B --> D[스케줄러: 실행할 노드 결정]
    B --> E[컨트롤러: 상태 차이 조정]
    D --> F[워커 노드의 Pod]
    E --> F
    F --> B

관리자는 API 서버를 통해 설정을 전달한다. 컨트롤 플레인의 스케줄러와 컨트롤러는 Pod가 어느 노드에서 실행되어야 하는지, 부족한 Pod가 있는지 살핀다. 워커 노드의 kubelet과 컨테이너 런타임이 실제 컨테이너를 실행한다. 공식 구성 요소 설명에서 각 역할을 확인할 수 있다.

가장 먼저 구분할 객체

객체	역할	예
Pod	함께 배치되는 컨테이너의 실행 단위	웹 서버 컨테이너 한 개
Deployment	Pod 복제 수와 배포 버전 관리	웹 서버 3개 유지
Service	교체되는 Pod에 안정적인 접근 경로 제공	웹 API 내부 주소

Pod의 IP는 재생성 시 바뀔 수 있다. 그래서 사용자가 Pod 주소를 직접 기억하는 방식보다 Service를 통해 접근하는 방식이 일반적이다. Pod가 계속 재시작한다면 kubectl get pods, kubectl describe pod, kubectl logs로 상태와 이벤트, 로그를 차례로 확인한다.

쿠버네티스 구성방법

메모에 적어 둔 방법은 관리 책임에 따라 세 갈래로 나눌 수 있다.

관리형 서비스: EKS, AKS, GKE처럼 클라우드 사업자가 컨트롤 플레인 운영의 일부를 맡는다. 운영 부담을 줄일 수 있지만 비용과 권한 모델을 알아야 한다. 학습에도 사용할 수 있으며, 실습 목적과 예산에 따라 선택하면 된다.
배포 플랫폼: Rancher, OpenShift처럼 설치와 운영 기능을 함께 제공하는 제품이 있다. 비용과 제공 기능은 제품·배포 방식에 따라 다르므로 일괄적으로 “유료”라고 단정하지 않는다.
직접 구성: kubeadm, Kubespray, kops 등의 도구로 클러스터를 만든다. 네트워크, 인증서, 업그레이드, etcd 백업까지 직접 책임질 범위가 커진다. kubeadm 공식 안내는 처음 배우는 환경과 자동화의 기본 구성 요소로도 사용할 수 있다고 설명한다.

선택할 때는 “어디서 실행하나”보다 누가 컨트롤 플레인과 노드를 관리하는가를 먼저 생각한다. 학습 환경에서는 작은 클러스터로 Pod·Deployment·Service 관계를 확인하고, 운영 환경에서는 가용성·백업·업그레이드 계획까지 따져야 한다.

예전 자료의 “마스터 노드”는 현재 문서에서 보통 컨트롤 플레인 노드라고 부른다. 용어가 바뀌었어도 핵심은 같다. 컨트롤 플레인이 상태를 결정하고 워커 노드가 애플리케이션을 실행한다.

선언한 수와 실제 수가 다를 때

Deployment에 replicas: 3을 적었다고 즉시 정상적인 웹 서버 세 개가 생기는 것은 아니다. API 서버가 선언을 저장하고, Deployment 컨트롤러가 ReplicaSet을 만들며, 스케줄러가 Pod의 노드를 선택한다. 노드의 kubelet은 컨테이너 런타임을 통해 이미지를 받아 프로세스를 시작한다. 이 과정 중 이미지 다운로드 실패, CPU 부족, 잘못된 환경 변수로 Pod가 준비되지 않을 수 있다. 컨트롤러는 계속 원하는 상태에 가까워지도록 시도하지만 실패 원인을 사람에게 대신 고쳐 주지는 않는다.

kubectl get deployment web
kubectl get pods -l app=web -o wide
kubectl describe deployment web
kubectl describe pod <문제가-난-pod-이름>
kubectl logs <문제가-난-pod-이름>

get deployment의 READY는 준비된 복제 수와 원하는 복제 수를 비교한다. Pending이면 이벤트에서 스케줄 실패나 볼륨 문제를, ImagePullBackOff면 이미지 이름·인증을, CrashLoopBackOff면 이전 실행의 로그와 시작 설정을 확인한다. Running이어도 readiness probe가 실패하면 Service에서 정상 요청 대상이 되지 않을 수 있다. 진단은 kubectl describe의 Events와 kubectl logs --previous를 함께 본다.

Pod를 교체해도 주소가 유지되는 이유

Deployment가 새 버전으로 Pod를 교체하면 각 Pod의 이름과 IP는 달라질 수 있다. Service는 label selector로 현재 대상 Pod를 찾고 EndpointSlice를 통해 요청을 전달할 대상 집합을 관리한다. 그래서 클라이언트는 개별 Pod IP가 아니라 Service의 DNS 이름에 접속한다. Service가 있어도 selector가 실제 Pod label과 맞지 않으면 엔드포인트가 비어 응답을 받지 못한다.

flowchart LR
  U[클라이언트] --> S[Service: web]
  S --> P1[준비된 Pod A]
  S --> P2[준비된 Pod B]
  D[Deployment] --> R[ReplicaSet]
  R --> P1
  R --> P2

kubectl get service web으로 Service가 있는지 보고, kubectl get endpointslice -l kubernetes.io/service-name=web으로 준비된 대상이 잡혔는지 확인한다. 트래픽이 닿지 않으면 Service의 port와 targetPort, Pod가 실제로 수신하는 포트, selector의 label을 비교한다. Service는 클러스터 내부의 안정된 진입점이며 외부 노출에는 LoadBalancer, Gateway 또는 Ingress 같은 별도 구성이 필요하다.

배포 중에는 kubectl rollout status deployment/web으로 새 버전이 준비되는지 본다. readiness probe는 준비되지 않은 Pod로 정상 트래픽이 가는 것을 줄이는 데 도움이 된다. liveness probe는 프로세스가 복구 불가능한 상태인지 판단해 재시작에 사용하므로 실패 조건을 너무 공격적으로 만들면 부하가 큰 순간 오히려 재시작이 반복된다. 운영에서는 가용성, 리소스 요청/제한, 로그, 데이터 보존까지 함께 설계해야 한다.

참고: Kubernetes 컨트롤러, Deployment, Service, 프로브.