[kubernetes] deployment

Deployment 

Deployment는 Kubernetes에서 애플리케이션을 선언적으로 배포하고 관리하는 방법을 제공한다. 이를 통해 파드(Pod)와 레플리카셋(ReplicaSet)에 대한 자동화된 관리와 업데이트를 지원한다. Deployment는 의도된 상태(desired state)를 설정하고, 이를 실제 클러스터 상태에 맞게 조정하여 애플리케이션을 지속적으로 실행하고 안정적으로 유지한다. 

Deployment의 주요 기능

• 롤아웃 (Rollout): 새로운 버전의 애플리케이션을 배포하면서 점진적으로 파드를 업데이트한다.
• 롤백 (Rollback): 새로운 배포가 실패할 경우 이전 안정적인 상태로 되돌릴 수 있다.
• 스케일링 (Scaling): 애플리케이션의 부하를 처리하기 위해 파드의 수를 동적으로 늘리거나 줄일 수 있다.
• 배포 전략: 애플리케이션의 특성에 맞게 다양한 배포 전략을 사용할 수 있다.

Deployment 사용 사례

• 레플리카셋 롤아웃: 새로운 레플리카셋을 생성하고 롤아웃 상태를 체크하여 성공 여부를 확인환다
• 파드 상태 업데이트: 파드의 상태를 변경하고, Deployment는 이를 새로운 레플리카셋으로 이동시키는 작업을 관리한다.
• 롤백: 현재 상태가 안정적이지 않으면 이전 버전으로 롤백할 수 있다.
• 스케일업: 더 많은 리소스를 필요로 하는 경우 파드의 수를 늘려서 처리할 수 있다.
• 배포 일시 중지 및 재개: 롤아웃을 잠시 멈추고 여러 수정 사항을 적용한 뒤, 다시 롤아웃을 재개할 수 있다.

애플리케이션 배포 전략

Recreate 

Recreate 전략은 애플리케이션을 전부 업데이트하기 전에 기존 애플리케이션을 완전히 종료한 뒤, 새로운 버전의 애플리케이션을 배포하는 방식이다. 이 방식은 설정이 간단하고 애플리케이션 상태를 완전히 갱신할 수 있지만, 배포 중에 다운 타임이 발생하기 때문에 계획된 시간에만 사용된다.

Ramped(롤링 업데이트) 

Ramped(롤링 업데이트) 전략은 기존의 레플리카셋과 새로운 레플리카셋이 동시에 존재하며, 파드를 하나씩 순차적으로 업데이트하는 방식이다. 이 방식은 배포가 점진적으로 이루어지기 때문에 무중단 시스템을 제공하며, 상태 저장 애플리케이션에서 유용하게 사용된다. 그러나 롤아웃이나 롤백이 다소 시간이 걸리고, 트래픽을 제어하는데 어려움이 있을 수 있다.

Blue/Green 

Blue/Green 전략은 새 버전의 애플리케이션을 배포할 새로운 리소스를 미리 준비한 후, 트래픽을 전환하는 방식이다. 이 방식은 롤아웃과 롤백을 즉시 수행할 수 있어 빠른 배포가 가능하고, 버전 관리가 수월하다. 하지만, 두 가지 버전을 동시에 운영해야 하므로 리소스 사용이 많아지고, 전체 시스템에 대한 적절한 테스트가 필요하다.

Canary 

Canary 전략은 새 버전의 애플리케이션을 일부 사용자에게만 배포하여 테스트를 진행하고, 문제가 없으면 점차 트래픽을 늘려가는 방식이다. 이 방식은 문제를 빠르게 발견할 수 있고, 오류가 발생할 경우 빠르게 롤백할 수 있다. 그러나 트래픽을 늘려가는 과정이 느리기 때문에, 빠른 배포가 필요할 때는 적합하지 않을 수 있다.

A/B Testing 

A/B Testing 전략은 두 개 이상의 버전을 병렬로 실행하여, 사용자 그룹에 따라 다른 버전을 배포하는 방식이다. 이 방식은 각 버전이 다양한 사용자 환경에서 어떻게 동작하는지 테스트할 수 있으며, 트래픽을 세밀하게 제어할 수 있다. 하지만 이를 구현하려면 로드 밸런서가 지능적으로 트래픽을 분배해야 하고, 분산 추적을 통해 오류를 해결해야 하는 복잡성이 따른다.

Shadow

Shadow 전략은 현재 운영 중인 애플리케이션과 업데이트된 버전으로 트래픽을 동시에 보내어 성능을 비교하는 방식이다. 이 방식은 실제 사용자의 트래픽을 이용해 새로운 버전의 성능을 테스트할 수 있으며, 사용자가 업데이트된 버전을 경험하지 않기 때문에 안정적인 테스트가 가능하다. 하지만, 두 배의 리소스를 사용하기 때문에 비용이 많이 들고, 실제 사용자가 아닌 테스트이기 때문에 오해를 불러일으킬 수 있다.

Deployment 흐름도

Deployment → ReplicaSet → Pod

1. Deployment가 생성되면, Deployment는 자동으로 ReplicaSet을 생성한다. 
2. ReplicaSet은 지정된 수의 Pod를 실행하고 관리한다. 
3. Deployment는 업데이트 시 새로운 ReplicaSet을 생성하고, 새로운 버전의 Pod를 배포하여 기존 Pod를 교체한다. 

애플리케이션 롤아웃

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: nginx
        image: nginx:1.14
        ports:
        - containerPort: 80

 

위에서 정의된 배포가 완료된 후, 새로운 버전의 이미지를 배포하려면 kubectl rollout 명령어를 사용할 수 있다. 예를 들어, nginx 이미지를 nginx:1.16으로 업데이트하려면 다음과 같이 한다.

kubectl set image deployment/my-app nginx=nginx:1.16

nginx 컨테이너의 이미지를 nginx:1.16으로 업데이트하고, 새로운 버전의 파드를 배포한다. 

 

롤아웃 상태 확인

kubectl rollout status deployment/my-app

만약 새 버전의 애플리케이션이 문제가 있을 경우, 롤백을 사용하여 이전 버전으로 되돌릴 수 있다.

kubectl rollout undo deployment/my-app

Deployment 전략 

공식문서: https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/

.spec.strategy (배포 전략)

• .spec.strategy는 애플리케이션을 새로운 파드로 대체하는 전략을 명시한다. type은 "Recreate" 또는 "RollingUpdate"로 설정할 수 있습니다. 기본값은 "RollingUpdate"이다."RollingUpdate" 방식은 점진적으로 파드를 업데이트하는 방식이다. 

디플로이먼트 롤링 업데이트

• .spec.strategy.type이 RollingUpdate로 설정되면, 디플로이먼트는 파드를 롤링 업데이트 방식으로 점진적으로 교체한다.이때, maxUnavailable와 maxSurge를 설정하여 롤링 업데이트를 제어할 수 있다. 

최대 불가 (Max Unavailable)

• .spec.strategy.rollingUpdate.maxUnavailable는 업데이트 중에 사용할 수 없는 최대 파드의 수를 설정한다. 값은 절대 숫자(예: 5)나 비율(예: 10%)로 지정할 수 있다. 절대 숫자는 비율로 변환하여 계산한다.기본값은 25%이다.
• 예를 들어, maxUnavailable를 30%로 설정하면, 롤링 업데이트 시 기존 레플리카셋의 크기가 의도한 파드의 70%로 스케일 다운된다. 새 파드가 준비되면 기존 파드를 종료하고, 새 레플리카셋의 수를 늘릴 수 있다.

최대 서지 (Max Surge)

• .spec.strategy.rollingUpdate.maxSurge는 의도한 파드의 수를 기준으로 생성할 수 있는 최대 파드 수를 지정한다. 이 값은 절대 숫자(예: 5)나 비율(예: 10%)로 설정할 수 있다.. 기본값은 25%이다.
• maxSurge가 30%로 설정되면, 롤링 업데이트 시 새 레플리카셋의 크기가 기존과 새로운 파드를 합쳐 의도한 파드 수의 130%를 넘지 않도록 제한된다. 

진행 기한 시간 (Progress Deadline)

• .spec.progressDeadlineSeconds는 디플로이먼트가 롤아웃 중 실패할 경우, 진행 상태를 "False"로 표시하고 실패 원인으로 ProgressDeadlineExceeded를 보고하기 전에 대기하는 시간(초)을 지정한다. 기본값은 600초입니다. 이 필드는 .spec.minReadySeconds보다 커야 한다. 

최소 대기 시간 (Min Ready Seconds)

• .spec.minReadySeconds는 새로 생성된 파드가 준비되기 전에 최소한 대기해야 하는 시간(초)을 설정한다.  기본값은 0이며, 이는 파드가 준비되면 즉시 사용할 수 있다는 의미입니다. 파드가 준비된 시점은 컨테이너 프로브를 기준으로 판단한다. 

수정 버전 기록 제한 (Revision History Limit)

• .spec.revisionHistoryLimit은 롤백을 위해 보존할 이전 레플리카셋의 수를 설정한다. 기본값은 10이다. 
• 이전 레플리카셋은 etcd 리소스를 차지하고, kubectl get rs 명령의 결과에 포함된다. 이 필드를 0으로 설정하면, 레플리카셋이 삭제되며 롤백이 불가능하다.

일시 정지 (Paused)

• .spec.paused는 디플로이먼트를 일시 중지하거나 재개하기 위한 선택적 부울 필드이다. 일시 중지된 디플로이먼트는 PodTemplateSpec에 대한 변경 사항을 적용해도 새 롤아웃을 트리거하지 않는다.디플로이먼트는 기본적으로 일시 중지되지 않는다. 

예시 : 롤링 업데이트와 진행 기한, 최소 대기 시간 설정

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy
  annotations:
    kubernetes.io/change-cause: "Update application to version 3.0"
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
  replicas: 5
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp-container
          image: ghcr.io/myorg/myapp:v3.0
          ports:
            - containerPort: 8080
  progressDeadlineSeconds: 300  # 5분간 진행되지 않으면 실패로 간주
  minReadySeconds: 10  # 파드가 준비되기 전에 최소 10초 대기

• maxSurge: 2: 새 파드를 최대 2개까지 추가로 생성할 수 있다.
• maxUnavailable: 1: 업데이트 중에 최대 1개의 파드만 사용할 수 없는 상태가 될 수 있다.
• replicas: 5: 총 5개의 파드가 실행된다.
• progressDeadlineSeconds: 300: 롤아웃이 5분 동안 진행되지 않으면 실패로 간주하고, ProgressDeadlineExceeded 상태로 전환된다.
• minReadySeconds: 10: 새로 생성된 파드가 준비되기 전에 최소 10초 동안 대기해야 한다. 

예시 : 수정 버전 기록 제한과 일시 정지 설정

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myservice-deploy
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  replicas: 4
  selector:
    matchLabels:
      app: myservice
  template:
    metadata:
      labels:
        app: myservice
    spec:
      containers:
        - name: myservice-container
          image: ghcr.io/myorg/myservice:v2.0
          ports:
            - containerPort: 8080
  revisionHistoryLimit: 3  # 이전 레플리카셋 3개만 보존
  paused: true  # 디플로이먼트 일시 중지

• maxSurge: 1: 롤링 업데이트 중에 새 파드를 최대 1개까지 추가 생성할 수 있다. 
• maxUnavailable: 0: 업데이트 중에 기존 파드가 사용 불가능한 상태가 되지 않도록 한다. 
• replicas: 4: 총 4개의 파드가 실행된다. 
• revisionHistoryLimit: 3: 롤백을 위해 이전 레플리카셋을 최대 3개까지 보존한다. 
• paused: true: 디플로이먼트가 일시 중지 상태이므로, PodTemplateSpec에 변경 사항이 있어도 새로운 롤아웃이 트리거되지 않는다.