콘텐츠로 이동

디플로이먼트와 스케일링

개요

파드 하나만으로는 서비스가 불안정해요. 죽으면 다시 살려야 하고, 요청이 늘면 개수를 늘려야 하고, 새 버전을 내려야 할 때도 있죠. 이 모든 것을 선언적으로 관리해 주는 게 디플로이먼트(Deployment)예요. "이 이미지로 N개를 유지해줘"라고 적어 두면, 쿠버네티스가 그 상태를 계속 맞춰요.

상위 문서: Kubernetes · 파드 · ConfigMap

핵심 개념

선언적 업데이트. 디플로이먼트는 레플리카셋(ReplicaSet)을 만들고, 레플리카셋이 파드 개수를 유지해요. 파드 템플릿(이미지 등)을 바꾸면 디플로이먼트가 새 레플리카셋을 만들고, 기존 것을 조금씩 줄이면서 교체해요. 이게 롤링 업데이트예요.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  labels:
    app: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: harbor.local/api:abc1234
          ports:
            - containerPort: 8080

롤링 업데이트와 롤백. 새 버전을 한꺼번에 바꾸지 않고 조금씩 교체해서 서비스가 끊기지 않게 해요. maxSurge는 여유분을 얼마나 더 띄울지, maxUnavailable은 동시에 몇 대가 내려가도 되는지를 정해요. 문제가 생기면 kubectl rollout undo로 이전 리비전으로 되돌아갈 수 있어요. 롤백할 수 있는 과거 리비전 수는 revisionHistoryLimit으로 제한해요(기본 10개).

스케일링. replicas를 바꾸면 파드 개수가 조정돼요. 평상시엔 사람이 정하지만, 부하에 따라 스스로 늘리고 줄이는 HPA(Horizontal Pod Autoscaler)를 쓰면 CPU 등 지표를 보고 개수를 조절해요.

선택자(selector)의 역할. 디플로이먼트는 selector.matchLabels로 "내가 관리할 파드"를 식별해요. 그래서 파드 템플릿의 라벨이 선택자와 겹치지 않게 설계해야 해요. .spec.template(파드 템플릿)이 바뀔 때만 롤아웃이 일어나고, 단순 replica 수 변경은 롤아웃을 트리거하지 않아요.

실제 적용(데이터스케쳐스)

우리 모든 서비스를 디플로이먼트가 관리해요. 각 네임스페이스(마케팅·위키·백엔드)마다 디플로이먼트가 있고, 부하가 늘면 HPA가 파드를 늘려요. 새 이미지가 준비되면 ArgoCD가 디플로이먼트의 파드 템플릿을 갱신하고, 쿠버네티스가 롤링 업데이트로 끊김 없이 교체해요. 문제가 생기면 이전 리비전으로 롤백하죠.

더 알아보기