디플로이먼트 스케일링과 롤아웃

쿠버네티스 공식문서를 확인하며 디플로이먼트의 스케일링과 롤아웃에 대해서 기억해야 하는 부분을 기록한다.

디플로이먼트 스케일링

kubectl scale deployment/nginx-deployment --replicas=10 커맨드를 실행하여 수동으로 스케일 할 수 있으며 정상적으로 스케일되면 아래와 같이 출력된다.
```
  deployment.apps/nginx-deployment scaled
```
클러스터에서 horizontal Pod autoscaling를 설정 한 경우 디플로이먼트에 대한 오토스케일러를 설정할 수 있으며 기존 파드의 CPU 사용률을 기준으로 생성할 최소 파드 및 최대 파드의 수를 선택할 수 있다.
```
  kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80 // 실행 커맨드

  deployment.apps/nginx-deployment scaled // 출력
```

비례적 스케일링(Proportional Scaling)

디플로이먼트 롤링업데이트는 여러 버전의 애플리케이션을 동시에 실행할 수 있도록 지원한다.
사용자 또는 오토스케일러가 롤아웃 중에 있는 디플로이먼트 롤링 업데이트를 스케일링 하는 경우, 디플로이먼트 컨트롤러는 위험을 줄이기 위해 기존 활성화된 레플리카셋의 추가 레플리카의 균형을 조절하며 이를 “proportional scaling”이라 부른다.
10개의 레플리카를 디플로이먼트로 maxSurge=3, maxUnavailable=2로 실행하는 상황을 가정해 본다.
- kubectl get deploy 커맨드를 입력하여 10개의 레플리카가 실행되고 있는지 확인한다.
```
NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment     10        10        10           10          50s
```
- kubectl set image deployment/nginx-deployment nginx=nginx:sometag 커맨드를 실행하여 클러스터 내부에서 확인할 수 없는 새 이미지로 업데이트한다.
```
deployment.apps/nginx-deployment image updated
```
- 이미지 업데이트는 레플리카셋 nginx-deployment-1989198191으로 새로운 롤 아웃이 시작하지만, maxUnavailable의 요구 사항으로 인해 차단된다. kubectl get rs를 입력하여 롤아웃 상태를 확인해 본다.
```
NAME                          DESIRED   CURRENT   READY     AGE
nginx-deployment-1989198191   5         5         0         9s
nginx-deployment-618515232    8         8         8         1m
```
- 디플로이먼트에 대한 새로운 스케일링 요청이 함께 따라오고 오토스케일러는 디플로이먼트 레플리카를 15로 증가시킨다.
- 디플로이먼트 컨트롤러는 새로운 5개의 레플리카의 추가를 위한 위치를 결정해야 한다.
- 만약 비례적 스케일링을 사용하지 않으면 5개 모두 새 레플리카셋에 추가되고, 비례적 스케일링을 사용하게 되면 추가 레플리카를 모든 레플리카셋에 걸쳐 분산할 수 있다.
- 비율이 높을수록 가장 많은 레플리카가 있는 레플리카셋으로 이동하고, 비율이 낮을 수록 적은 레플리카셋으로 이동한다.
- 남은 것들은 대부분의 레플리카가 있는 레플리카셋에 추가되고 레플리카가 있는 레플리카셋은 스케일 업되지 않는다.
- 위에서 알아본 것처럼 작동하는지 확인하는 과정을 가져본다. 기존 레플리카셋에 3개의 레플리카가 추가되고, 2개의 레플리카는 새 레플리카에 추가된다. 결국 롤아웃 프로세스는 새 레플리카가 정상이라고 가정하면 모든 레플리카를 새 레플리카셋으로 이동시킨다. kubectl get deploy를 입력하여 출력을 확인해 본다.
```
NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment     15        18        7            8           7m
```
- kubectl get rs를 입력하여 레플리카가 각 레플리카셋에 어떻게 추가되었는지 롤아웃 상태를 확인한다.
```
NAME                          DESIRED   CURRENT   READY     AGE
nginx-deployment-1989198191   7         7         0         7m
nginx-deployment-618515232    11        11        11        7m
```

[정리]

비례적 스케일링은 Proportional scailing이라고 하며 비례적 스케일링을 사용하는 경우 기존의 레플리카셋과 새로운 레플리카셋 모두에 걸쳐 분산할 수 있다. 만약 비례적 스케일링을 사용하지 않는 경우 새로운 레플리카셋에만 새로운 레플리카가 배정된다.

디플로이먼트 롤아웃 일시 중지와 재개

디플로이먼트를 업데이트할 때, 하나 이상의 업데이트를 트리거하기 전에 해당 디플로이먼트에 대한 롤아웃을 일시 중지할 수 있고 변경 사항을 적용할 준비가 되면, 디플로이먼트 롤아웃을 재개한다.
이러한 방법으로, 불필요한 롤아웃을 트리거하지 않고 롤아웃 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다.
- kubectl rollout pause deployment/nginx-deployment 커맨드를 실행하면 롤아웃을 일시정지할 수 있다.
```
deployment.apps/nginx-deployment paused
```
- kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 커맨드를 실행하여 디플로이먼트의 이미지를 변경하면 정상적으로 변경되었다는 문구가 출력된다.
```
deployment.apps/nginx-deployment image updated
```
- kubectl rollout history deployment/nginx-deployment커맨드를 실행하여 새로운 롤아웃이 멈춰있는지 확인해 본다.
```
deployments "nginx"
REVISION  CHANGE-CAUSE
1   <none>
```
- 이미지 변경과 같이 kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi 커맨드를 실행하여 리소스를 업데이트 할 수 있다.
```
deployment.apps/nginx-deployment resource requirements updated
```
- 디플로이먼트 롤아웃을 일시 중지하기 전 디플로이먼트의 초기 상태는 해당 기능을 지속한다. 그러나 디플로이먼트 롤아웃이 일시 중지한 상태에서는 디플로이먼트의 새 업데이트에 영향을 주지 않는다. 결국, 디플로이먼트 롤아웃을 재개하고 새로운 레플리카셋이 새로운 업데이트를 제공하는 것을 관찰한다.
- kubectl rollout resume deployment/nginx-deployment 커맨드를 실행하여 일시중지된 롤아웃을 재개할 수 있다.
```
deployment.apps/nginx-deployment resumed
```
- kubectl get rs -w 커맨드를 실행하면 아래와 같이 실시간으로 레플리카셋의 실시간 변경사항을 확인할 수 있다.
```
NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   2         2         2         2m
nginx-3926361531   2         2         0         6s
nginx-3926361531   2         2         1         18s
nginx-2142116321   1         2         2         2m
nginx-2142116321   1         2         2         2m
nginx-3926361531   3         2         1         18s
nginx-3926361531   3         2         1         18s
nginx-2142116321   1         1         1         2m
nginx-3926361531   3         3         1         18s
nginx-3926361531   3         3         2         19s
nginx-2142116321   0         1         1         2m
nginx-2142116321   0         1         1         2m
nginx-2142116321   0         0         0         2m
nginx-3926361531   3         3         3         20s
```

[정리]

디플로이먼트의 롤아웃은 중간에 정지될 수 있다. 정지된 상태에서 이미지나 리소스의 정보를 변경할 수 있다. 일시정지된 롤아웃은 사용자가 재개(Resume)하지 않는 이상 다시 실행되지 않는다. 사용자가 재개하게 되면 중간에 변경되 사항을 반영하여 새롭게 롤아웃된다. 일시 중지된 디플로이먼트는 재개할 때까지 롤백할 수 없다.

디플로이먼트 상태

디플로이먼트는 라이프사이클 동안 다양한 상태로 전환되며, 이는 새 레플리카셋을 롤아웃하는 동안 진행 중이 될 수 있고, 완료나 진행 실패 상태가 될 수도 있다.

디플로이먼트 진행 중

쿠버네티스는 아래의 작업 중에 하나를 수행할 때 디플로이먼트를 진행 중으로 표시한다.
- 디플로이먼트로 새 레플리카셋을 생성.
- 디플로이먼트로 새로운 레플리카셋을 스케일 업.
- 드플로이먼트로 기존 레플리카셋을 스케일 다운.
- 새 파드가 준비되거나 이용할 수 있는 상태.
롤아웃이 “진행 중” 상태가 되면, 디플로이먼트 컨트롤러는 디플로이먼트의 .status.conditions에 아래의 속성을 포함하는 컨디션을 추가한다.
- type: Progressing
- status: "True"
- reason: NewReplicaSetCreated | reason: FoundNewReplicaSet | reason: ReplicaSetUpdated
kubectl rollout status를 사용해서 디플로이먼트의 진행사항을 모니터링 할 수 있다.

디플로이먼트 완료

쿠버네티스는 아래와 같은 특성을 가지게 되면 디플로이먼트를 “완료”로 표시한다.
- 디플로이먼트와 관련된 모든 레플리카가 지정된 최신 버전으로 업데이트 되어 요청한 모든 업데이트가 완료되었을 때.
- 디플로이먼트와 관련한 모든 레플리카를 사용할 수 있을 때.
- 디플로이먼트에 대해 이전 복제본이 실행되고 있지 않을 때.
롤아웃이 “완료” 상태가 되면, 디플로이먼트 컨트롤러는 디플로이먼트의 .status.conditions에 아래의 속성을 포함하는 컨디션을 추가한다.
- type: Progressing
- status: "True"
- reason: NewReplicaSetAvailable
Progressing 컨디선은 새로운 롤아웃이 시작되기 전까지는 "True" 상태값을 유지할 것이며 레플리카의 가용성이 변경되는 경우에도 컨디션은 유지된다.
kubectl rollout status를 사용해서 디플로이먼트가 완료되었는지 확인할 수 있고, 롤아웃이 성공적으로 완료되면 kubectl rollout status는 종료 코드로 0이 반환된다.

디플로이먼트 실패

디플로이먼트 시 새 레플리카셋이 완료되지 않은 상태에서 배포를 시도하면 아래와 같은 이유로 고착될 수 있다.
- 할당량 부족
- 준비성 프로브의 실패
- 이미지 풀 에러
- 권한 부족
- 범위 제한
- 애플리케이션 런타임의 잘못된 구성
이러한 조건을 찾을 수 있는 한 가지 방법은 디플로이먼트 스펙에서 데드라인 파라미터(.spec.progressDeadlineSeconds)를 지정하는 것이다. 데드라인 파라미터는 디플로이먼트 상태에서 디플로이먼트의 진행이 정지되었음을 나타내는 시간(초)를 나타낸다.
아래의 커맨드를 실행하면 progressDeadlineSeconds가 설정되어 10분 후 디플로이먼트 롤아웃에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다.

kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'

만약 데드라인을 넘어서면 디플로이먼트 컨트롤러는 디플로이먼트의 .status.conditions 속성에 아래의 디플로이먼트 컨디션(DeploymentCondition)을 추가한다.
- type: Progressing
- status: "False"
- reason: ProgressDeadlineExceeded
디플로이먼트 컨디션은 일찍 실패할 수도 있으며 이러한 경우 ReplicaSetCreateError를 이유로 상태값을 "False"로 설정한다. 또한, 디플로이먼트 롤아웃이 완료되면 데드라인은 더 이상 고려되지 않는다.
쿠버네티스는 reason: ProgressDeadlineExceeded과 같은 상태 조건을 보고하는 것 이외에 정지된 디플로이먼트에 대해 조치를 취하지 않는다. 더 높은 수준의 오케스트레이터는 이를 활용할 수 있으며, 예를 들어 디플로이먼트를 이전 버전으로 롤백할 수 있다.
만약 디플로이먼트 롤아웃을 일시 중지하면 쿠버네티스는 지정된 데드라인과 비교하여 진행 상황을 확인하지 않는다. 롤아웃 중에 디플로이먼트 롤아웃을 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고 재개할 수 있다.
타임아웃이 낮거나 일시적으로 처리될 수 있는 다른 종료의 에러로 인해 디플로이먼트에 일시적인 에러가 발생할 수 있다. 할당량이 부족한 상황을 가정하고 확인하는 방법에 대해서 알아보도록 한다.
kubectl describe deployment nginx-deployment 커맨드를 실행하여 출력을 확인해 본다.
```
  <...>
  Conditions:
    Type            Status  Reason
    ----            ------  ------
    Available       True    MinimumReplicasAvailable
    Progressing     True    ReplicaSetUpdated
    ReplicaFailure  True    FailedCreate
  <...>
```
- kubectl get deployment nginx-deployment -o yaml 커맨드를 실행하면 아래와 같은 출력을 확인할 수 있다.
```
status:
availableReplicas: 2
conditions:
- lastTransitionTime: 2016-10-04T12:25:39Z
  lastUpdateTime: 2016-10-04T12:25:39Z
  message: Replica set "nginx-deployment-4262182780" is progressing.
  reason: ReplicaSetUpdated
  status: "True"
  type: Progressing
- lastTransitionTime: 2016-10-04T12:25:42Z
  lastUpdateTime: 2016-10-04T12:25:42Z
  message: Deployment has minimum availability.
  reason: MinimumReplicasAvailable
  status: "True"
  type: Available
- lastTransitionTime: 2016-10-04T12:25:39Z
  lastUpdateTime: 2016-10-04T12:25:39Z
  message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota:
    object-counts, requested: pods=1, used: pods=3, limited: pods=2'
  reason: FailedCreate
  status: "True"
  type: ReplicaFailure
observedGeneration: 3
replicas: 2
unavailableReplicas: 2
```
- 결국, 디플로이먼트 진행 데드라인을 넘어서면, 쿠버네티스는 진행 컨디션의 상태와 이유를 아래와 같이 업데이트 한다.
```
<...>
Conditions:
Type            Status  Reason
----            ------  ------
Available       True    MinimumReplicasAvailable
Progressing     True    ReplicaSetUpdated
ReplicaFailure  True    FailedCreate
<...>
```
- 디플로이먼트를 스케일 다운하거나, 실행 중인 다른 컨트롤러를 스케일 다운하거나, 네임스페이스에서 할당량을 늘려서 할당량이 부족한 문제를 해결할 수 있다. 만약 할당량 컨디션과 디플로이먼트 롤아웃이 완료되어 디플로이먼트 컨트롤러를 만족한다면 성공한 컨디션의 디플로이먼트 상태가 업데이트 된 것을 볼 수 있다.
```
Conditions:
Type          Status  Reason
----          ------  ------
Available     True    MinimumReplicasAvailable
Progressing   True    NewReplicaSetAvailable
```
- type: Available과 status: "True"는 디플로이먼트가 최소한의 가용성을 가지고 있는 것을 의미한다. 최소한의 가용성은 디플로이먼트 계획에 명시된 파라미터에 의해 결정된다.
- type: Progressing과 status: "True"는 디플로이먼트가 롤아웃 도중에 진행 중이거나, 성공적으로 완료되었으며, 진행 중 최소한으로 필요한 새로운 레플리카를 이용 가능하다는 것을 의미한다.
- kubectl rollout status를 사용해서 디플로이먼트의 진행이 실패되었는지 확인할 수 있다. kubectl rollout status는 디플로이먼트의 진행 데드라인을 초과하면 0이 아는 종료 코드를 반환한다.

실패한 디플로이먼트에서의 운영

완료된 디플로이먼트에 적용되는 모든 행동은 실패한 디플로이먼트에도 적용된다.
디플로이먼트 파드 템플릿에서 여러 개의 수정사항을 적용해야 하는 경우 스케일업 또는 다운을 하거나, 이전 버전으로 롤백 또는 일시 중지를 할 수 있다.

[정리]

디플로이먼트는 라이프사이클 동안 “진행 중”, “완료”, “실패”와 같은 상태를 가질 수 있다. 여러가지 이유로 “실패”상태가 될 수 있으며 사용자가 직접 핸들링해야 하기 때문에 중요한 상태라고 볼 수 있다.

.spec.progressDeadlineSeconds를 통하여 디플로이먼트의 롤아웃에 대한 진행 상태를 확인하여 부족에 대한 리포트를 확인할 수 있다. 다만, 쿠버네티스는 리포트를 확인하여 직접 조치를 취하지는 않는다.

리소스가 부족하여 상태가 실패인 경우 스케일 다운이나, 네임스페이스 할당되는 리소스의 양을 늘려서 할당량이 부족한 문제를 해결할 수 있다.

정책 초기화

디플로이먼트의 .spec.revisionHistoryLimit 필드를 설정(기본값: 10)해서 디플로이먼트에서 유지해야 하는 이전 레플리카셋의 수를 명시할 수 있고 나머지는 백그라운드에서 가비지-수집이 진행된다.

카나리 디플로이먼트

디플로이먼트를 이용해서 일부 사용자 또는 서버에 릴리즈를 롤아웃 하기 위해서는 리소스 관리에 설명된 카나리 패턴에 따라 각 릴리즈 마다 하나씩 여러 디플로이먼트를 생성할 수 있다.

디플로이먼트 사양 작성

모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 .apiVersion, .kind 그리고 .metadata 필드가 필요하다.

파드 템플릿

.spec.template과 .spec.selector은 .spec에서 유일한 필수 필드이다.
.spec.template는 파드 템플릿이다. 이것은 파드와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 apiVersion과 kind를 가지고 있지 않는다.
파드에 필요한 필드외에 디플로이먼트 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 명시해야 하며 레이블의 경우 다른 컨트롤러와 겹치지 않도록 해야 한다.
.spec.template.spec.restartPolicy에는 오직 Always만 허용되고, 명시되지 않으면 기본값이 된다.

레플리카

.spec.replicas은 필요한 파드의 수를 지정하는 선택적 필드이며 기본값은 1이다.
kubectl scale deployment deployment --replicas=X 명령으로 디플로이먼트의 크기를 수동으로 조정한 뒤, 매니페스트를 이용하여 디플로이먼트를 업데이트(kubectl apply -f deployment.yaml)하면, 수동으로 설정했던 디플로이먼트의 크기가 오버라이드된다.
HorizontalPodAutoscaler가 디플로이먼트를 관리하고 있다면, .spec.replicas를 수동으로 설정해서는 안되며 쿠버네티스 컨트롤 플레인에 의해 자동으로 관리되도록 해야 한다.

셀렉터

.spec.selector는 디플로이먼트의 대상이 되는 파드에 대해 레이블 셀렉터를 지정하는 필수 필드다.
.spec.selector는 .spec.template.metadata.labels과 일치해야 하며, 그렇지 않으면 API에 의해 거부된다.
API 버전 apps/v1에서는 .spec.selector와 .metadata.lables이 설정되지 않으면 .spec.template.metadata.lables은 기본 설정되지 않는다. 이것들은 명시적으로 설정되어야 하며 app/v1 에서는 디플로이먼트를 생성한 후에는 .spec.selector이 변경되지 않는 점을 참고해야 한다.
디플로이먼트는 템플릿의 .spec.template와 다르거나 파드의 수가 .spec.replicas를 초과할 경우 셀렉터와 일치하는 레이블을 가진 파드를 종료할 수 있다. 파드의 수가 의도한 수량보다 적은 경우 spec.template에 맞는 새 파드를 띄운다.
다른 디플로이먼트를 생성하거나, 레플리카셋 또는 레플리케이션 컨트롤러와 같은 다른 컨트롤러를 사용해서 직접적으로 레이블과 셀렉터가 일치하는 다른 파드를 생성하면 안된다. 만약 이렇게 하면 첫 번째 디플로이먼트는 다른 파드를 만들었다고 가정하기 때문이다.
만약 셀렉터가 겹치는 컨트롤러가 여러 개 있는 경우, 컨트롤러는 경쟁하게 되고 올바르게 작동하지 않는다.

전략

.spec.strategy는 이전 파드를 새로운 파드로 대체하는 전략을 명시한다. spec.strategy.type은 “재생성” 또는 “롤링업데이트”가 될 수 있고 기본값은 “롤링업데이트”다.

디플로이먼트 재생성

기존의 모든 파드는 .spec.strategy.type==Recreate이면 새 파드가 생성되기 전에 죽는다.
이렇게 하면 업그레이드를 생성하기 전에 파드 종료를 보장할 수 있다. 디플로이먼트를 업그레이드하면, 이전 버전의 모든 파드가 즉시 종료된다.
신규 버전의 파드가 생성되기 전에 성공적으로 제거가 완료되기를 대기한다.
파드를 수동으로 삭제하면, 라이프사이클은 레플리카셋에 의해 제어되며 교체용 파드가 즉시 생성된다. 파드에 대해 “최대” 보장이 필요한 경우 스테이트풀셋의 사용을 고려해야 한다.

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

디플로이먼트는 .spec.strategy.type==RollingUpdate이면 파드를 롤링 업데이트 방식으로 업데이트 한다. maxUnavailable와 maxSurge를 명시해서 롤링 업데이트 프로세스를 제어할 수 있다.

최대 불가(Max Unavailable)

spec.strategy.rollingUpdate.maxUnavailable은 업데이트 프로세스 중에 사용할 수 없는 최대 파드의 수를 지정하는 선택적 필드다. 이 값은 절대 숫자 또는 의도한 파드 비율이 될 수 있다.
절대값은 내림해서 백분율로 계산하고 만약 .specstrategy.rollingUpdate.maxSurge가 0이면 값이 0이 될 수 없으며 기본 값은 25%다.
만약 값을 30%로 설정하면 롤링업데이트 시작 시 즉각 이전 레플리카셋의 크기를 의도한 파드 중 70%를 스케일 다운할 수 있다. 새 파드가 준비되면 기존 레플리카셋을 스케일 다운할 수 있으며, 업데이트 중에 항상 사용 가능한 전체 파드의 수는 의도한 파드 수의 70% 이상이 되도록 새 레플리카셋을 스케일업 할 수 있다.

최대 서지(Max Surge)

.spec.strategy.rollingUpdate.maxSurge는 의도한 파드의 수에 대해 생성할 수 있는 최대 파드의 수를 지정하는 선택적 필드이며 절대 숫자나 의도한 비율이 될 수 없다.
만약 값을 30%로 설정하면 롤링업데이트 시작 시 새 레필르카셋의 크기를 즉시 조정해서 기존 및 새 파드의 전체 갯수를 의도한 파드의 130%를 넘지 않도록 한다.
기존 파드가 죽으면 새로운 레플리카셋은 스케일 업할 수 있으며, 업데이트하는 동안 항상 실행하는 총 파드의 수는 최대 의도한 파드의 수의 130%가 되도록 보장한다.

진행 기간 시간(초)

spec.progressDeadlineSeconds는 디플로이먼트가 표면적으로 type: Progressing, status: "False"의 상태 그리고 리소스가 reason: ProgressDeadlineExceeded 상태로 진행 실패를 보고하기 전에 디플로이먼트가 진행되는 것을 대기시키는 시간(초)를 명시하는 선택적 필드다.
디플로이먼트 컨트롤러는 디플로이먼트를 계속 재시도 하며 기본값은 600(초)이다.
미래에 자동화된 롤백이 구현된다면 디플로이먼트 컨트롤런느 상태를 관찰하고, 그 즉시 디플로이먼트를 롤백할 것이다.

최소 대기 시간(초)

.spec.minReadySeconds는 새롭게 생성된 파드의 컨테이너가 어떤 것과도 충돌하지 않고 사용할 수 있도록 준비되어야 하는 최소 시간(초)을 지정하는 선택적 필드다.
기본 값은 0으로 파드는 준비되는 즉시 사용할 수 있는 것으로 간주된다.

수정 버전 기록 제한

디플로이먼트의 수정 버전 기록은 자신이 컨트롤하는 레플리카셋에 저장된다.
.spec.revisionHistoryLimit은 롤백을 허용하기 위해 보존할 이전 레플리카셋의 수를 지정하는 선택정 필드다.
이전 레플리카셋은 etcd의 리소스를 소비하고, kubectl get rs의 결과를 가득차게 만든다.
각 디플로이먼트의 구성은 디플로이먼트의 레플리카셋에 저장된다. 이전 레플리카셋이 삭제되면 해당 디플로이먼트 수정 버전으로 롤백할 수 있는 기능이 사라진다.
기본적으로 10개의 기존 레플리카셋이 유지되지만 이상적인 값은 새로운 디플로이먼트의 빈도와 안정성에 따라 달라진다.
이 필드를 0으로 설정하면 레플리카가 0이 되며 이전 레플리카셋은 정리된다. 이러한 경우 새로운 디플로이먼트 롤아웃을 취소하고 롤백할 수 없다.

일시 정지

.spec.paused는 디플로이먼트를 일시 중지나 재개하기 위한 선택적 필드다.
일시 중지된 디플로이먼트와 일시 중지되지 않은 디플로이먼트 사이의 유일한 차이점은 일시 중지된 디플로이먼트는 PodTemplateSpec에 대한 변경 사항이 일시중지 된 경우 새 롤아웃을 트리거 하지 않는다.
디플로이먼트는 생성시 기본적으로 일시 중지되지 않는다.

[정리]

디플로이먼트에는 .apiVersion, .kind, .metadata 필드를 필수로 입력해야 한다.

파드 템플릿은 파드와 정확하게 동일한 스키마를 가지고 있으며 파드에 필요한 필드외에 적절한 레이블과 재시작 정책을 명시해야 하며 다른 컨트롤러와 겹치지 않도록 해야 한다.

레플리카는 필요한 파드의 수를 지정할 수 있는 선택적 필드이며 기본값은 1이기 때문에 따로 설정하지 않는다면 하나의 레플리카만 생성된다.

셀렉터는 디플로이먼트의 대상이 되는 파드에 대해 레이블 셀렉터를 지정하는 필수 필드다. 셀렉터 필드의 값은 .labels의 값과 정확하게 일치해야 한다.

전략(strategy)는 이전 파드를 새로운 파드로 대체할 때의 전략을 의미한다. 재생성 또는 롤링업데이트가 될 수 있고 기본값은 롤링업데이트다.

.spec.strategy.type==Recreate로 설정하는 경우 기존의 파드는 새로운 파드가 생성되기 전에 전부 종료된다. 업그레이드를 생성하기 전에 기존 파드가 종료되는 것을 보장되기를 바랄 때 사용한다. 서비스의 중단이 있더라도 구버전과 신버전이 공존하면 안되는 경우 사용될 것으로 예상된다.

디플로이먼트 재실행 전략을 롤링업데이트로 하는 경우 maxUnavailable 값과 maxSurbe 를 지정하여 원하는 비율로 서비스를 순차적으로 업데이트 할 수 있다. maxUnavailable는 업데이트 중에 사용할 수 없는 최대 파드의 수를 의미하며 maxSurge는 최대로 생성할 수 있는 파드의 수를 의미한다.

진행 기한 시간을 의미하는 progressDeadlineSeconds는 디플로이먼트가 진행 실패를 보고하기 전에 진행되는 것을 대기시키는 시간이다. 디플로이먼트 컨트롤러는 디플로이먼트에 실패하는 경우 지속적으로 재시도한다. 재시도 간의 간격으로 보면 좋을듯 하다.

최소 대기 시간을 의미하는 minReadySeconds는 새롭게 생성된 파드가 실행되고 나서 정상적으로 작동하기 위해 준비되는 시간을 의미한다. 만약 충분한 시간이 할당하지 않고 애플리케이션이 정상적으로 실행되지 않은 상태에서 파드가 실행됨과 동시에 고객이 요청을 보내기 시작한다면 고객들은 502 Bad Gateway 에러를 만나게 될 것이다.

수정 버전 기록 제한은 과거의 몇 버전까지 롤백을 할 수 있도록 기록할 것인지를 결정하는 값이다. 기본 값은 10이며 0으로 설정하는 경우 롤백이 불가능해 진다.

일시 정지는 .spec.paused 필드의 값을 의미하며 디플로이먼트를 일시 중지나 재개하기 위한 필드다.

참고 자료

https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/

저작자표시

'Infrastructure > Kubernetes' 카테고리의 다른 글

[워크로드 리소스] 스테이트풀셋 (0)	2022.10.20
[워크로드 리소스] 레플리카셋 (0)	2022.10.20
[워크로드 리소스] 디플로이먼트 업데이트와 롤백 (0)	2022.10.18
[Pod] 다운워드(Downward) API (0)	2022.10.18
[Pod] 사용자 네임스페이스 (0)	2022.10.18

RoyOps

[워크로드 리소스] 디플로이먼트 스케일리와 롤아웃

디플로이먼트 스케일링과 롤아웃