Kubernetes Deployment와 Service 차이: 파드 교체와 네트워크 진입점을 나누는 법

Kubernetes에서 파드 IP를 직접 호출하면 처음에는 되지만 배포나 장애 복구 뒤 연결이 끊길 수 있다. 파드는 교체 가능한 실행 단위이고, Deployment와 Service는 그 변화를 각각 다른 책임으로 다룬다.

Deployment는 원하는 실행 상태를 선언한다

Deployment는 어떤 컨테이너 이미지를 몇 개 실행할지와 업데이트 전략을 관리한다. 파드가 죽으면 새 파드를 만들 수 있고, 새 버전 배포 때 점진적 교체를 수행한다. 애플리케이션은 시작·준비 상태를 정확히 보고해야 트래픽을 너무 이르게 받지 않는다.

예를 들어 Deployment의 Pod 템플릿에 app: web 라벨을 붙이고 복제 수를 2로 선언하면 컨트롤러는 그 상태를 유지하려고 한다. 여기서 Pod가 교체되면 개별 IP는 달라질 수 있다. 클라이언트가 Pod IP를 저장해 두지 않아야 하는 이유다.

Service는 라벨로 파드를 찾아 안정된 이름을 제공한다

Service는 selector로 대상 파드를 고르고, 클러스터 안에서 일정한 DNS 이름과 가상 IP를 제공한다. Service의 selector와 Deployment의 pod label이 어긋나면 대상 endpoint가 없는데도 YAML은 적용된 것처럼 보일 수 있다. 이 관계를 배포 확인 항목에 넣자.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

Deployment의 Pod 라벨과 Service의 selector가 모두 app: web이므로 두 리소스가 연결된다. 기본 Service 유형은 클러스터 내부용이므로 이 예시만으로 인터넷에 공개되지 않는다. 적용한 클러스터에서는 kubectl get pods --show-labels로 Pod 라벨을, kubectl get endpointslices -l kubernetes.io/service-name=web으로 연결 대상을 확인한다. Service에 대상이 없으면 먼저 라벨·selector를 대조하고, 대상은 있는데 응답이 실패하면 준비 상태와 targetPort를 확인하자.

핵심 요약

Deployment는 파드 수명과 업데이트, Service는 교체되는 파드 앞의 안정된 네트워크 진입점을 맡는다. 파드 IP를 계약으로 쓰지 말고, label·selector·readiness를 함께 확인하자. 선언한 리소스가 적용됐다는 것만으로 트래픽 경로가 정상이라는 뜻은 아니다.