앱 라이프사이클 관리

Kubernetes 기반 및 서드파티 도구를 사용하여 사용자를 위해 작동 중단 시간 없이 앱의 롤링 업데이트 및 롤백을 수행합니다.

전략 업데이트

앱을 업데이트하려면 다음과 같은 다양한 전략 중에서 선택할 수 있습니다. 더욱 복잡한 Canary 배치를 진행하기 전에 롤링 배치 또는 즉각적인 전환을 시작할 수 있습니다.

롤링 배치: Kubernetes 원시 기능을 사용하여 v2 배치를 작성하고 점진적으로 이전 v1 배치를 대체할 수 있습니다. 이 접근 방식을 사용하려면 v2 앱 버전을 제공 받는 사용자가 중요한 변경사항을 경험하지 않도록 앱이 이전 버전과 호환되어야 합니다. 자세한 정보는 앱 업데이트를 위한 롤링 배치 관리를 참조하십시오.
즉각적인 전환: 즉각적인 전환은 Blue-Green 배치라고도 하며, 두 개의 버전이 동시에 실행되도록 두 배 크기의 컴퓨팅 리소스가 필요합니다. 이 접근 방식을 사용하면 거의 실시간으로 사용자를 최신 버전으로 전환할 수 있습니다. 서비스 라벨 선택기(예: version: green 및 version: blue)를 사용하여 요청이 올바른 앱 버전으로 전송되는지 확인하세요. 새 version: green 배치를 작성할 수 있습니다. 준비가 될 때까지 기다린 후 version: blue 배치를 삭제하십시오. 또는 롤링 업데이트를 수행할 수 있지만 maxUnavailable 매개변수를 0%로 설정하고 maxSurge 매개변수를 100%로 설정하십시오.
Canary 또는 A/B 배치: 더욱 복잡한 업데이트 전략인 Canary 배치는 5%와 같은 사용자의 백분율을 선택하여 새 앱 버전으로 전송하는 경우에 수행됩니다. 새 앱 버전에서 수행되는 방식을 알아보기 위해 로깅 및 모니터링 도구에서 메트릭을 수집하고, A/B 테스트를 수행한 후 더 많은 사용자에게 업데이트를 롤아웃합니다. 모든 배치에서와 같이 앱(예: version: stable 및 version: canary)에 레이블을 지정하는 것이 중요합니다. 카나리아 배포를 관리하려면 관리형 Istio 애드온 서비스 메시를 설치하고, 클러스터에 Monitoring 을 설정한 다음, 이 블로그 게시물에 설명된 대로 A/B 테스트에 Istio 서비스 메시를 사용할 수 있습니다.

앱 스케일링

Kubernetes 을 사용하면 수평적 포드 자동 확장을 활성화하여 CPU에 따라 앱의 인스턴스 수를 자동으로 늘리거나 줄일 수 있습니다.

팟(Pod) 대신 작업자 노드를 스케일링하시겠습니까? 클러스터 오토스케일러를 확인하십시오.

시작하기 전에

계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.
네임스페이스에서 Kubernetes 리소스 관련 작업을 수행할 수 있도록 적절한 Kubernetes RBAC 역할을 부여하는 서비스 액세스 역할이 지정되어 있는지 확인하십시오.

앱을 확장하려면:

CLI에서 클러스터에 앱을 배치하십시오. 보다 복잡한 배치를 위해서는 구성 파일을 작성해야 할 수 있습니다.
```
kubectl create deployment <app_name> --image=<image>
```
배치에 실행되는 컨테이너에 대한 CPU 리소스 한계(밀리초)를 설정하십시오(예: 100m). 메모리 한계도 설정할 수 있지만 수평 팟(Pod) 오토스케일러는 스케일링 목적으로 CPU 리소스 한계만 고려합니다. 자세한 내용은 kubectl set resources 문서를 참조하세요.
```
kubectl set resources deployment <app_name> --limits=cpu=100m
```

수평 팟(Pod) 오토스케일러를 작성하고 정책을 정의하십시오. 자세한 정보는 kubectl autoscale 문서를 참조하십시오.

kubectl autoscale deployment <deployment_name> --cpu-percent=<percentage> --min=<min_value> --max=<max_value>

명령 옵션 이해
옵션	설명
`--cpu-percent`	Horizontal Pod Autoscaler에서 유지하는 평균 CPU 사용률(백분율로 지정됨)입니다.
`--min`	지정된 CPU 사용 백분율을 유지하기 위해 사용되는 배치된 팟(Pod)의 최소 수입니다.
`--max`	지정된 CPU 사용 백분율을 유지하기 위해 사용되는 배치된 팟(Pod)의 최대 수입니다.

앱 업데이트를 위한 롤링 배치 관리

배치와 같은 팟(Pod) 템플리트를 포함하는 워크로드에 대해 자동화되고 제어 가능한 방식으로 앱 변경사항의 롤아웃을 관리할 수 있습니다. 롤아웃이 계획대로 진행되지 않으면 배치를 이전 개정으로 롤백할 수 있습니다.

롤링 업데이트 중에 작동 중단 시간이 발생하지 않도록 하려고 하십니까? 가장 최근에 업데이트된 팟(Pod)이 준비되면 다음 앱으로 롤아웃을 진행할 수 있도록 배치에 준비 상태 프로브를 지정하십시오.

시작하기 전에

계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.
배치를 작성하십시오.
네임스페이스에서 Kubernetes 리소스 관련 작업을 수행할 수 있도록 적절한 Kubernetes RBAC 역할을 부여하는 서비스 액세스 역할이 있는지 확인하십시오.

앱에 대한 롤링 업데이트를 관리하려면 다음을 수행하십시오.

컨테이너가 실행 중이고 요청을 대한 준비가 된 경우에만 배치가 준비로 표시되는지 확인하려면 활성 상태 및 준비 상태 프로브를 배치에 추가하십시오.
업데이트 중에 최대 갑작스러운 증가 및 사용 불가능한 팟(Pod) 또는 팟(Pod)의 백분율을 지정하는 롤링 업데이트 전략을 포함하도록 배치를 업데이트하십시오.
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
spec:
  replicas: 10
  selector:
    matchLabels:
      service: http-server
  minReadySeconds: 5
  progressDeadlineSeconds: 600
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 50%
      maxSurge: 2
...
```
spec.minReadySeconds

기본적으로 배치는 팟(Pod)이 롤아웃을 계속하도록 ready로 표시될 때까지 대기합니다. 최신 팟(Pod)의 앱이 아직 준비되지 않은 경우에도 배치가 계속해서 팟(Pod)을 작성하는 경우 이 필드를 사용하여 배치 롤아웃의 속도를 늦추십시오. 예를 들어, 5를 지정하는 경우 배치는 팟(Pod)이 다음 팟(Pod)을 작성하기 전에 ready가 된 후 5초를 기다립니다.

spec.progressDeadlineSeconds

배치가 실패로 간주되기 전에 제한시간(초)를 설정하십시오. 예를 들어, 제한시간 없이 새 앱 버전에 버그가 있고 즉시 정지되는 경우 팟(Pod)이 ready 상태에 도달하지 않으므로 롤아웃을 계속할 수 없습니다. 이 제한시간을 600초로 설정하는 경우 롤아웃의 단계에서 10초 동안 진행하는 데 실패하는 경우 배치는 실패로 표시되고 롤아웃이 중지됩니다.

spec.strategy.type

RollingUpdate 전략 유형을 지정하십시오.

spec.strategy.rollingUpdate.maxUnavailable

업데이트 중에 사용하지 못할 수 있는 팟(Pod)의 최대 수를 숫자(2) 또는 백분율(50%)로 설정하십시오. 일반적으로 하나의 팟(Pod)만 한 번에 작동 중지할 수 있도록 롤아웃을 제한하지 않는 한 복제본의 수를 나중에 변경하는 경우 여기서 숫자를 업데이트하는 것을 기억할 필요가 없도록 백분율을 사용하십시오. 100% 용량에 미치지 않으려면 이 값을 0% 으로 설정하고 spec.strategy.type.rollingUpdate.maxSurge 매개 변수를 지정하세요.

spec.strategy.rollingUpdate.maxSurge

배치가 롤아웃 중에 사용할 수 있는 추가 리소스의 최대 수를 숫자(2) 또는 백분율(50%)로 설정하십시오. 예를 들어, 배치가 10개의 복제본을 지정하고 maxSurge를 2로 설정하는 경우 롤아웃 중에 두 개의 새 복제본이 작성됩니다. 이제 12개의 복제본(10개의 기존 복제본, 2개의 신규 복제본)을 보유하게 됩니다. 두 개의 새 복제본이 준비된 후에는 지정된 10개의 복제본을 맞추기 위해 배치가 이전 복제본을 8개로 스케일링 다운합니다. 이 프로세스는 롤아웃이 완료되고 모든 10개의 복제본이 새 버전을 실행할 때까지 계속됩니다.

Blue-Green 간의 즉각적인 전환 스타일 업데이트를 수행하려면 maxSurge를 100%로 설정하십시오. 배치는 새 필수 복제본을 모두 작성한 후 이전 버전 복제본을 0으로 축소합니다.
변경사항을 롤아웃 하십시오. 예를 들어, 초기 배치에 사용된 이미지를 변경할 수 있습니다.
1. 배치 이름을 가져오십시오.
```
kubectl get deployments
```
2. 팟(Pod) 이름을 가져오십시오.
```
kubectl get pods
```
3. 팟(Pod)에서 실행하는 컨테이너의 이름을 가져오십시오.
```
kubectl describe pod <pod_name>
```
4. 사용할 배치에 대해 새 이미지를 설정하십시오.
```
kubectl set image deployment/<deployment_name><container_name>=<image_name>
```
명령을 실행하면 변경사항이 즉시 적용되며 롤아웃 히스토리에 로깅됩니다.
배치의 상태를 확인하십시오.
```
kubectl rollout status deployments/<deployment_name>
```
상태에서 추적할 시간이 필요한 항목을 발견한 경우 다음 명령을 사용하여 롤아웃을 일시정지하고 재개할 수 있습니다.
```
kubectl rollout pause deployment <deployment_name>
```
```
kubectl rollout resume deployment <deployment_name>
```
변경사항을 롤백하십시오.
1. 배치의 롤아웃 히스토리를 보고 마지막 배치의 개정 번호를 식별하십시오.
```
kubectl rollout history deployment/<deployment_name>
```
  팁: 특정 개정에 대한 세부사항을 보려면 개정 번호를 포함하십시오.
```
kubectl rollout history deployment/<deployment_name> --revision=<number>
```
2. 이전 버전으로 롤백하거나 개정을 지정하십시오. 이전 버전으로 롤백하려면 다음 명령을 사용하십시오.
```
kubectl rollout undo deployment/<depoyment_name> --to-revision=<number>
```

지속적 통합 및 딜리버리 설정

IBM Cloud 및 기타 오픈 소스 도구를 사용하면 지속적 통합 및 딜리버리(CI/CD), 버전 제어, 도구 체인 등을 설정하여 앱 개발 및 배치를 자동화할 수 있습니다.

지속적 딜리버리 파이프라인을 설정하기 위해 지원되는 통합 및 단계의 목록을 보려면 지속적 통합 및 딜리버리 설정을 참조하십시오.

다른 클러스터에 배치 복사

Git 과 같은 버전 제어 시스템을 사용하면 다음과 같은 구성 관리 프로젝트가 수행됩니다. kustomize 클러스터에 지속적인 배포 도구가 있으면 앱 구성 파일을 클러스터 간에 빠르게 배포할 수 있습니다. 클러스터에서 테스트한 배치가 몇 개뿐이고 이러한 배치를 복사하여 다른 클러스터에서 다시 배치하는 것을 선호하는 경우가 있습니다.

시작하기 전에 하나의 클러스터에서 모든 리소스를 복사하여 다른 클러스터에 배치할 수 있도록 두 개의 클러스터 및 두 개의 클러스터에 있는 모든 네임스페이스에 대한 관리자 서비스 액세스 역할이 필요합니다.

계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.

클러스터의 모든 구성 파일을 나열하고 이러한 구성을 복사할 것인지 확인하십시오.

kubectl get all

출력 예

NAME                                   READY   STATUS             RESTARTS   AGE
pod/java-web-6955bdbcdf-l756b          1/1     Running            0          59d

NAME                                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/java-web                       NodePort    172.21.xxx.xxx   <none>        8080:30889/TCP   59d

NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/java-web               1/1     1            1           59d

NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/java-web-6955bdbcdf    1         1         1       59d

클러스터의 구성 파일을 로컬 디렉토리로 복사하십시오. --export 옵션은 구성 파일에서 클러스터 관련 정보를 제거합니다.
```
kubectl get all -o yaml --export > myconfigs.yaml
```
계정에 로그인하십시오. If applicable, target the appropriate resource group. 클러스터에 대한 컨텍스트를 설정하십시오.
선택 사항: 클러스터에서 여러 네임스페이스를 사용하는 경우 표준 클러스터에 동일한 네임스페이스를 만들고 이미지 풀 시크릿을 각 네임스페이스에 복사합니다.
복사한 구성 파일을 클러스터에 배치하십시오. 구성 파일에 적용할 수 없는 특정 정보가 있는 경우, 구성 파일을 업데이트한 후 다시 적용해야 할 수도 있습니다.
```
kubectl apply -f myconfigs.yaml
```
출력 예
```
pod/java-web-6955bdbcdf-l756b created
service/java-web created
deployment.apps/java-web created
replicaset.apps/java-web-6955bdbcdf created
```
구성 파일이 적용되었는지 확인하십시오.
```
kubectl get all
```