Kubernetes Pod Service Deployment 심층 가이드

현대 소프트웨어 개발 환경에서 컨테이너 기술은 필수적인 요소로 자리 잡았습니다. 특히, 수많은 컨테이너를 효율적으로 관리하고 배포하는 컨테이너 오케스트레이션 플랫폼인 Kubernetes는 DevOps 엔지니어링의 핵심 역량으로 부상했습니다. 이 글에서는 Kubernetes의 가장 기본적인 세 가지 구성 요소인 Pod, Service, Deployment를 심층적으로 이해하고, 실제 예시와 CLI 명령어를 통해 이들이 어떻게 유기적으로 동작하는지 알아보겠습니다.

컨테이너 오케스트레이션과 Kubernetes의 등장

과거에는 애플리케이션을 배포하고 관리하는 과정이 복잡하고 비효율적이었습니다. 서버마다 환경을 설정하고 의존성을 관리하는 것은 개발과 운영 모두에게 큰 부담이었죠. Docker와 같은 컨테이너 기술은 애플리케이션과 그 의존성을 격리된 환경에 패키징하여 "한 번 빌드하면 어디서든 실행된다"는 혁신을 가져왔습니다. 이는 개발 환경과 운영 환경 간의 불일치를 줄이고, 배포 프로세스를 간소화하는 데 크게 기여했습니다.

하지만 수십, 수백 개의 컨테이너가 운영되는 대규모 시스템에서는 컨테이너의 배포, 스케일링, 로드 밸런싱, 자가 복구 등을 수동으로 관리하는 것이 거의 불가능해집니다. 이때 등장한 것이 바로 컨테이너 오케스트레이션 플랫폼입니다. 그중에서도 Google이 개발하고 오픈 소스로 공개한 Kubernetes는 강력한 기능과 유연성으로 업계 표준이 되었습니다. Kubernetes는 컨테이너화된 워크로드를 자동으로 배포하고 관리하며, 서비스 디스커버리, 로드 밸런싱, 스토리지 오케스트레이션, 자동 롤아웃 및 롤백, 자가 복구 등의 기능을 제공하여 복잡한 마이크로서비스 아키텍처를 효율적으로 운영할 수 있도록 돕습니다.

Kubernetes 핵심 구성 요소 개요

Kubernetes는 마스터 노드(Control Plane)와 워커 노드(Worker Node)로 구성된 클러스터 아키텍처를 가집니다. 각 노드는 여러 컴포넌트들로 이루어져 있으며, 이들이 협력하여 컨테이너화된 애플리케이션을 관리합니다.

• API Server: Kubernetes 클러스터의 프론트엔드 역할을 하며, 모든 통신과 데이터 저장을 담당합니다. kubectl 명령어는 API Server와 통신하여 클러스터를 제어합니다.
• etcd: 클러스터의 모든 상태 데이터(설정 정보, 상태, 메타데이터 등)를 저장하는 분산 키-값 저장소입니다.
• Scheduler: 새로 생성된 Pod를 실행할 최적의 워커 노드를 결정합니다.
• Controller Manager: 클러스터의 상태를 지속적으로 모니터링하고, 원하는 상태(Desired State)와 현재 상태(Current State)를 일치시키기 위한 다양한 컨트롤러를 실행합니다. 예를 들어, Deployment Controller는 Pod의 개수를 관리합니다.
• Kubelet: 각 워커 노드에서 실행되는 에이전트로, API Server로부터 Pod의 명령을 받아 컨테이너를 실행하고 관리합니다.
• Kube-proxy: 각 워커 노드에서 실행되며, 클러스터 내부 및 외부 네트워크 트래픽을 Pod로 라우팅하는 네트워크 프록시 및 로드 밸런서 역할을 합니다.

이러한 컴포넌트들이 복잡하게 얽혀 Kubernetes 클러스터의 안정적인 운영을 보장합니다. 이제 이 글의 핵심 주제인 Pod, Service, Deployment에 대해 자세히 살펴보겠습니다.

Pod 이해하기: Kubernetes의 최소 배포 단위

Kubernetes에서 애플리케이션을 실행하는 가장 기본적인 단위는 컨테이너가 아니라 Pod입니다. Pod는 하나 이상의 컨테이너 그룹과 스토리지, 네트워크 리소스, 컨테이너를 실행하는 방법에 대한 명세를 포함합니다.

왜 Pod을 사용하는가?

Docker 컨테이너가 애플리케이션의 독립적인 실행 단위를 제공하지만, 실제 서비스는 여러 컨테이너가 함께 동작해야 하는 경우가 많습니다. 예를 들어, 웹 서버와 로그 수집 사이드카 컨테이너가 하나의 논리적인 서비스로 묶여야 할 때 Pod는 이들을 함께 배포하고 관리하는 효율적인 방법을 제공합니다. Pod 내의 컨테이너들은:

• 동일한 네트워크 네임스페이스를 공유: localhost를 통해 서로 통신할 수 있습니다.
• 볼륨을 공유: 데이터 공유가 용이합니다.
• 동일한 라이프사이클을 가짐: 함께 생성되고 함께 소멸됩니다.

Pod YAML 파일 예시

다음은 nginx 컨테이너 하나를 포함하는 간단한 Pod의 YAML 정의 파일입니다.

# my-nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

• apiVersion: Kubernetes API 버전입니다.
• kind: 생성할 리소스의 종류를 나타냅니다 (여기서는 Pod).
• metadata: 리소스에 대한 메타데이터를 정의합니다. name은 Pod의 고유한 이름이며, labels는 Pod를 식별하고 그룹화하는 데 사용됩니다.
• spec: Pod의 상세 사양을 정의합니다.
  • containers: Pod 내부에 실행될 컨테이너 목록입니다.
    • name: 컨테이너의 이름입니다.
    • image: 사용할 Docker 이미지입니다.
    • ports: 컨테이너가 노출할 포트입니다.

Pod 생성 및 확인 CLI 명령어

Pod를 생성하고 상태를 확인하는 명령어는 다음과 같습니다.

# Pod 생성
kubectl apply -f my-nginx-pod.yaml

# 모든 Pod 목록 확인
kubectl get pods

# 특정 Pod의 상세 정보 확인
kubectl describe pod my-nginx-pod

# Pod의 로그 확인
kubectl logs my-nginx-pod

# Pod 삭제
kubectl delete -f my-nginx-pod.yaml

kubectl get pods 명령을 실행하면 Pod의 상태가 Running으로 표시되는 것을 확인할 수 있습니다. Pod는 생성되면 고유한 IP 주소를 할당받지만, 이 IP는 Pod가 재시작되거나 재생성될 때 변경될 수 있습니다. 따라서 안정적인 통신을 위해서는 Service가 필요합니다.

Service 이해하기: Pod 간의 통신과 외부 노출

앞서 언급했듯이 Pod는 일시적인 존재이며 IP 주소가 변경될 수 있습니다. 이러한 특성 때문에 다른 Pod나 외부에서 특정 Pod에 안정적으로 접근하려면 Service가 필요합니다. Service는 논리적인 Pod 집합에 대한 안정적인 네트워크 엔드포인트를 제공합니다.

Service는 Selector를 사용하여 특정 레이블을 가진 Pod들을 그룹화하고, 이 Pod들로 들어오는 네트워크 트래픽을 로드 밸런싱합니다. Pod가 사라지거나 새로 생성되어도 Service의 IP 주소는 변하지 않으므로, 클라이언트는 항상 동일한 엔드포인트를 통해 애플리케이션에 접근할 수 있습니다.

Service 타입

Kubernetes Service는 다양한 네트워크 접근 방식을 제공하기 위해 여러 타입을 지원합니다.

• ClusterIP: 클러스터 내부에서만 접근 가능한 가상 IP를 할당합니다. 기본 타입이며, 클러스터 내부의 다른 Pod들이 이 Service를 통해 통신할 때 사용됩니다.
• NodePort: 각 워커 노드의 특정 포트(NodePort)를 통해 Service를 외부에 노출합니다. NodeIP:NodePort 형식으로 외부에서 접근할 수 있습니다. 개발 또는 테스트 환경에서 유용합니다.
• LoadBalancer: 클라우드 제공업체(AWS, GCP, Azure 등)의 로드 밸런서를 프로비저닝하여 Service를 외부에 노출합니다. 프로덕션 환경에서 가장 일반적으로 사용됩니다.
• ExternalName: CNAME 레코드를 통해 Service를 외부 서비스에 매핑합니다. 프록시 없이 외부 서비스로 리디렉션하는 방식입니다.

Service YAML 파일 예시

my-nginx-pod에 접근할 수 있는 ClusterIP 타입의 Service를 정의해 보겠습니다.

# my-nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-nginx-service
spec:
  selector:
    app: nginx # 이 레이블을 가진 Pod를 찾아 연결합니다.
  ports:
    - protocol: TCP
      port: 80 # Service가 노출할 포트
      targetPort: 80 # Pod 컨테이너의 포트
  type: ClusterIP # 클러스터 내부에서만 접근 가능

이 Service는 app: nginx 레이블을 가진 모든 Pod에 대한 트래픽을 포트 80으로 라우팅합니다.

Service 생성 및 확인 CLI 명령어

Service를 생성하고 상태를 확인하는 명령어입니다.

# Service 생성
kubectl apply -f my-nginx-service.yaml

# 모든 Service 목록 확인
kubectl get services

# 특정 Service의 상세 정보 확인
kubectl describe service my-nginx-service

# Service 삭제
kubectl delete -f my-nginx-service.yaml

kubectl get services 명령을 실행하면 my-nginx-service에 CLUSTER-IP가 할당된 것을 볼 수 있습니다. 이 IP는 클러스터 내부에서 my-nginx-service에 접근할 때 사용됩니다.

Deployment 이해하기: 무중단 배포와 스케일링

Pod와 Service는 애플리케이션의 기본적인 실행과 접근을 담당하지만, 실제 운영 환경에서는 애플리케이션의 버전 관리, 무중단 배포, 스케일링(Pod 개수 조절), 롤백 등 복잡한 요구사항이 발생합니다. 이러한 요구사항을 선언적으로 관리하는 것이 바로 Deployment입니다.

Deployment는 ReplicaSet을 관리하고, ReplicaSet은 Pod를 관리하는 상위 레벨의 컨트롤러입니다. Deployment를 사용하면 원하는 Pod의 개수(replicas), 이미지 버전, 업데이트 전략 등을 YAML 파일에 명시함으로써 애플리케이션의 상태를 선언적으로 관리할 수 있습니다.

Deployment의 주요 기능

• 선언적 관리: 원하는 상태(Desired State)만 정의하면 Kubernetes가 자동으로 현재 상태를 원하는 상태로 유지합니다.
• 롤링 업데이트(Rolling Update): 새로운 버전의 애플리케이션을 배포할 때, 기존 Pod를 점진적으로 새 Pod로 교체하여 서비스 중단 없이 업데이트를 수행합니다.
• 롤백(Rollback): 업데이트 중 문제가 발생하거나 새로운 버전이 불안정할 경우, 이전 버전으로 쉽게 되돌릴 수 있습니다.
• 스케일링: replicas 값을 변경하여 Pod의 개수를 쉽게 늘리거나 줄일 수 있습니다.
• 자가 복구: Pod에 문제가 발생하면 Deployment는 자동으로 새 Pod를 생성하여 원하는 개수를 유지합니다.

Deployment YAML 파일 예시

nginx 웹 서버를 3개의 Pod로 구성하고, Service와 연결하여 무중단 배포가 가능한 Deployment를 만들어보겠습니다.

# my-nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3 # 3개의 Pod를 유지합니다.
  selector:
    matchLabels:
      app: nginx # 이 레이블을 가진 Pod를 관리합니다.
  template: # Pod 템플릿 정의
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.21.6 # 초기 이미지 버전
        ports:
        - containerPort: 80

이 Deployment는 app: nginx 레이블을 가진 3개의 Pod를 유지하도록 지시합니다. template 섹션은 Deployment가 생성할 Pod의 명세를 정의합니다. 이 Pod들은 my-nginx-service의 Selector(app: nginx)와 일치하므로, Service를 통해 접근 가능합니다.

Deployment 생성 및 확인 CLI 명령어

Deployment를 생성하고 관리하는 명령어입니다.

# Deployment 생성
kubectl apply -f my-nginx-deployment.yaml

# Deployment 목록 확인
kubectl get deployments

# Deployment가 관리하는 ReplicaSet 및 Pod 목록 확인
kubectl get replicasets
kubectl get pods -l app=nginx # 'app: nginx' 레이블을 가진 Pod만 필터링

# Deployment 상세 정보 확인
kubectl describe deployment my-nginx-deployment

# Deployment의 롤링 업데이트 상태 확인
kubectl rollout status deployment/my-nginx-deployment

# 이미지 버전 업데이트 (롤링 업데이트)
kubectl set image deployment/my-nginx-deployment nginx-container=nginx:latest

# 업데이트 기록 확인
kubectl rollout history deployment/my-nginx-deployment

# 이전 버전으로 롤백
kubectl rollout undo deployment/my-nginx-deployment

# Deployment 삭제
kubectl delete -f my-nginx-deployment.yaml

kubectl set image 명령을 통해 이미지 버전을 변경하면, Deployment는 자동으로 롤링 업데이트를 시작하여 기존 Pod를 새로운 버전의 Pod로 교체합니다. 이 과정에서 서비스 중단 없이 업데이트가 진행됩니다.

Pod, Service, Deployment 함께 사용하기

이제 Pod, Service, Deployment가 어떻게 상호작용하여 견고한 애플리케이션을 구성하는지 시나리오를 통해 살펴보겠습니다.

1. Deployment 생성: my-nginx-deployment.yaml 파일을 kubectl apply -f 명령으로 배포합니다. Kubernetes는 Deployment 정의에 따라 app: nginx 레이블을 가진 3개의 Pod를 생성하고 관리합니다.
2. Service 생성: my-nginx-service.yaml 파일을 배포합니다. 이 Service는 selector: app: nginx를 통해 Deployment가 생성한 Pod들을 자동으로 찾아 엔드포인트로 등록합니다.
3. 외부 접근: 만약 my-nginx-service가 NodePort 또는 LoadBalancer 타입으로 정의되었다면, 외부 클라이언트는 해당 Service의 IP/Port를 통해 Nginx 웹 서버에 접근할 수 있습니다. Service는 트래픽을 3개의 Nginx Pod 중 하나로 로드 밸런싱합니다.
4. 스케일링: kubectl scale deployment my-nginx-deployment --replicas=5 명령을 실행하면, Deployment는 자동으로 2개의 Nginx Pod를 추가로 생성하여 총 5개의 Pod를 유지합니다. Service는 새롭게 추가된 Pod들도 자동으로 감지하여 트래픽을 분산합니다.
5. 업데이트: kubectl set image deployment/my-nginx-deployment nginx-container=nginx:1.22.0 명령으로 Nginx 이미지 버전을 업데이트합니다. Deployment는 롤링 업데이트 전략에 따라 기존 Pod를 점진적으로 새 이미지의 Pod로 교체합니다. 이 과정에서 Service는 항상 가용한 Pod로만 트래픽을 보내므로, 사용자 입장에서는 서비스 중단을 느끼지 못합니다.
6. 자가 복구: 만약 어떤 이유로든 한 Pod가 비정상 종료되면, Deployment는 즉시 새로운 Pod를 생성하여 replicas 수(예: 3개)를 유지합니다. Service는 비정상 Pod를 엔드포인트 목록에서 자동으로 제거하고, 새로운 Pod를 추가합니다.

이러한 방식으로 Pod, Service, Deployment는 서로 협력하여 고가용성, 확장성, 안정성을 갖춘 애플리케이션 운영 환경을 제공합니다.

DevOps 관점에서 Kubernetes 활용 전략

Kubernetes는 단순한 컨테이너 오케스트레이션 도구를 넘어, DevOps 철학을 구현하는 강력한 플랫폼입니다.

• CI/CD 파이프라인 통합: Jenkins, GitLab CI/CD, Argo CD와 같은 도구와 연동하여 코드 변경 시 자동으로 이미지를 빌드하고, Kubernetes 클러스터에 배포하는 End-to-End CI/CD 파이프라인을 구축할 수 있습니다. Deployment의 롤링 업데이트 및 롤백 기능은 무중단 배포를 가능하게 하여 배포 빈도를 높이고 안정성을 확보합니다.
• GitOps 도입: 애플리케이션의 모든 구성(Pod, Service, Deployment 등)을 Git 저장소에 YAML 파일 형태로 관리하고, Git 저장소의 변경 사항이 감지되면 자동으로 클러스터에 적용되도록 합니다. 이는 "Infrastructure as Code"를 실현하고, 배포 프로세스의 투명성과 추적 가능성을 크게 향상시킵니다.
• 모니터링 및 로깅: Prometheus, Grafana를 이용한 클러스터 및 애플리케이션 메트릭 모니터링, ELK Stack(Elasticsearch, Logstash, Kibana) 또는 Loki, Grafana를 이용한 중앙 집중식 로깅 시스템 구축은 문제 발생 시 신속한 감지와 해결을 돕습니다.
• 자동화된 스케일링: Horizontal Pod Autoscaler(HPA)를 사용하여 CPU 사용량이나 사용자 정의 메트릭에 따라 Pod의 개수를 자동으로 조절하여 트래픽 변화에 유연하게 대응할 수 있습니다.
• 보안 강화: RBAC(Role-Based Access Control)를 통해 클러스터 리소스에 대한 접근 권한을 세밀하게 제어하고, 네트워크 정책을 사용하여 Pod 간의 통신을 제어하는 등 강력한 보안 기능을 활용할 수 있습니다.

Kubernetes를 통해 인프라 운영의 많은 부분을 자동화하고, 개발팀과 운영팀 간의 협업을 강화하여 더욱 빠르고 안정적인 서비스 제공이 가능해집니다.

마무리

Kubernetes는 현대적인 클라우드 네이티브 애플리케이션 개발 및 운영에 필수적인 도구입니다. 이 글에서는 Kubernetes의 핵심 구성 요소인 Pod, Service, Deployment가 어떻게 컨테이너화된 애플리케이션을 배포하고, 안정적으로 접근하며, 효율적으로 관리하는지 심층적으로 살펴보았습니다. 이 세 가지 개념을 명확히 이해하는 것은 Kubernetes를 활용하여 견고하고 확장 가능한 시스템을 구축하는 첫걸음이자 가장 중요한 기초가 됩니다. 앞으로는 Helm, Ingress, PersistentVolume 등 더 많은 Kubernetes 리소스들을 학습하며 DevOps 역량을 확장해 나가시길 바랍니다.