앱 라이프사이클 관리

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) 대신 작업자 노드를 스케일링하시겠습니까? 클러스터 오토스케일러를 확인하십시오.

시작하기 전에:

Red Hat OpenShift 클러스터에 액세스하십시오.
프로젝트에서 Kubernetes 리소스에 대해 작업할 수 있도록 적절한 Kubernetes RBAC 역할을 부여하는 서비스 액세스 역할이 지정되어 있는지 확인하십시오.

앱을 확장하려면:

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

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

oc 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)이 준비되면 다음 앱으로 롤아웃을 진행할 수 있도록 배치에 준비 상태 프로브를 지정하십시오.

시작하기 전에:

Red Hat OpenShift 클러스터에 액세스하십시오.
배치를 작성하십시오.
프로젝트에서 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으로 축소합니다.

변경사항을 롤아웃 하십시오. 예를 들어, 초기 배치에 사용된 이미지를 변경할 수 있습니다.

배치 이름을 가져오십시오.

    oc get deployments
    ```
2. 팟(Pod) 이름을 가져오십시오.

```sh {: pre}
    oc get pods
    ```
3. 팟(Pod)에서 실행하는 컨테이너의 이름을 가져오십시오.

```sh {: pre}
    oc describe pod <pod_name>
    ```
4. 사용할 배치에 대해 새 이미지를 설정하십시오.

```sh {: pre}
    oc set image deployment/<deployment_name> <container_name>=<image_name>
    ```
명령을 실행하면 변경사항이 즉시 적용되며 롤아웃 히스토리에 로깅됩니다.

배치의 상태를 확인하십시오.
```
oc rollout status deployments/<deployment_name>
```
상태에서 추적할 시간이 필요한 항목을 발견한 경우 다음 명령을 사용하여 롤아웃을 일시정지하고 재개할 수 있습니다.
```
oc rollout pause deployment <deployment_name>
```
```
oc rollout resume deployment <deployment_name>
```

변경사항을 롤백하십시오.

배치의 롤아웃 히스토리를 보고 마지막 배치의 개정 번호를 식별하십시오.

    oc rollout history deployment/<deployment_name>
    ```
    특정 개정에 대한 세부사항을 보려면 개정 번호를 포함하십시오.
    {: tip}

    ```sh {: pre}
    oc rollout history deployment/<deployment_name> --revision=<number>
    ```
2. 이전 버전으로 롤백하거나 개정을 지정하십시오. 이전 버전으로 롤백하려면 다음 명령을 사용하십시오.

```sh {: pre}
    oc rollout undo deployment/<deployment_name> --to-revision=<number>
    ```

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

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

지원되는 통합 목록과 지속적 배포 파이프라인 설정 단계를 보려면 IBM Cloud 콘솔 및 관련 클러스터 설명서에서 사용 가능한 통합을 검토하세요.

다른 클러스터에 배치 복사

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

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

Red Hat OpenShift 클러스터에 액세스하십시오.

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

oc 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

클러스터의 구성 파일을 로컬 디렉토리로 복사하십시오. 그런 다음, 파일을 다른 클러스터에 적용하기 전에 내보낸 YAML 파일에서 resourceVersion, uid, creationTimestamp, status 와 같은 클러스터별 필드를 수동으로 제거하십시오.
```
oc get all -o yaml > myconfigs.yaml
```
Red Hat OpenShift 클러스터에 액세스하십시오.
선택사항: 클러스터에서 여러 개의 프로젝트를 사용한 경우 표준 클러스터에 동일한 프로젝트를 작성하고 이미지 풀 시크릿을 각 프로젝트에 복사하십시오.
복사한 구성 파일을 클러스터에 배치하십시오. 구성 파일에 적용할 수 없는 특정 정보가 있는 경우, 구성 파일을 업데이트한 후 다시 적용해야 할 수도 있습니다.
```
oc 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
```
구성 파일이 적용되었는지 확인하십시오.
```
oc get all
```