3.4. 카나리아 롤아웃 업데이트 수행

카나리아 업데이트는 작업자 노드 업데이트가 모든 작업자 노드를 동시에 업데이트하지 않고 순차적 단계로 수행되는 업데이트 전략입니다. 이 전략은 다음 시나리오에서 유용할 수 있습니다.

업데이트 프로세스로 인해 애플리케이션이 실패하더라도 전체 업데이트 중에 미션 크리티컬 애플리케이션을 계속 사용할 수 있도록 작업자 노드 업데이트 롤아웃을 보다 제어해야 합니다.
작업자 노드의 작은 하위 집합을 업데이트하고 일정 기간 동안 클러스터 및 워크로드 상태를 평가한 다음 나머지 노드를 업데이트하려고 합니다.
호스트 재부팅이 필요한 작업자 노드 업데이트에 맞게 한 번에 전체 클러스터를 업데이트할 수 없는 경우 정의된 더 작은 유지 관리 창으로 전환해야 합니다.

이러한 시나리오에서는 클러스터를 업데이트할 때 특정 작업자 노드가 업데이트되지 않도록 여러 MCP(사용자 정의 머신 구성 풀)를 생성할 수 있습니다. 나머지 클러스터가 업데이트되면 적절한 시간에 배치로 해당 작업자 노드를 업데이트할 수 있습니다.

3.4.1. Canary 업데이트 전략의 예

다음 예에서는 초과 용량이 10%인 클러스터가 있고 4시간을 초과해서는 안 되는 유지 관리 기간이 있으며 작업자 노드를 드레이닝하고 재부팅하는 데 8분 이상 걸리는 카나리아 업데이트 전략을 설명합니다.

참고

이전 값은 예제일 뿐입니다. 노드를 드레이닝하는 데 걸리는 시간은 워크로드와 같은 요인에 따라 다를 수 있습니다.

사용자 정의 머신 구성 풀 정의

작업자 노드 업데이트를 별도의 단계로 구성하기 위해 다음 MCP를 정의하여 시작할 수 있습니다.

workerpool-canary 10 nodes
30개의 노드가 있는 workerpool-A
30개의 노드가 있는 workerpool-B
30개의 노드가 있는 workerpool-C

카나리아 작업자 풀 업데이트

첫 번째 유지 관리 기간 동안 workerpool-A,workerpool-B, workerpool-C 에 대한 MCP를 일시 중지한 다음 클러스터 업데이트를 시작합니다. 이렇게 하면 OpenShift Container Platform에서 실행되는 구성 요소와 일시 중지되지 않은 workerpool-canary MCP의 일부인 10개의 노드가 업데이트되었습니다. 나머지 3개의 MCP는 일시 중지되었으므로 업데이트되지 않습니다.

나머지 작업자 풀 업데이트를 진행할지 여부 확인

어떤 이유로 workerpool-canary 업데이트의 클러스터 또는 워크로드 상태가 부정적인 영향을 미치는 경우 문제를 진단하고 해결할 때까지 해당 풀의 모든 노드를 차단하고 드레이닝하고 드레이닝합니다. 모든 것이 예상대로 작동하면 일시 중지를 해제하기 전에 클러스터 및 워크로드 상태를 평가하여 각 추가 유지 관리 기간 동안 연속으로 workerpool-A,workerpool-B 및 workerpool-C 를 업데이트합니다.

사용자 지정 MCP를 사용하여 작업자 노드 업데이트를 관리하면 유연성을 제공하지만 여러 명령을 실행해야 하는 시간이 많이 걸리는 프로세스일 수 있습니다. 이러한 복잡성으로 인해 전체 클러스터에 영향을 줄 수 있는 오류가 발생할 수 있습니다. 시작하기 전에 조직의 요구 사항을 신중하게 고려하고 프로세스 구현을 신중하게 계획하는 것이 좋습니다.

중요

머신 구성 풀을 일시 중지하면 Machine Config Operator가 연결된 노드에 구성 변경 사항을 적용할 수 없습니다. MCP를 일시 중지하면 kube-apiserver-to-kubelet-signer CA 인증서의 자동 CA 교체를 포함하여 자동으로 순환된 인증서가 연결된 노드로 푸시되지 않습니다.

kube-apiserver-to-kubelet-signer CA 인증서가 만료되고 MCO가 인증서를 자동으로 갱신하려고 하면 MCO는 새로 교체된 인증서를 해당 노드로 푸시할 수 없습니다. 이로 인해 oc debug, oc logs,oc exec, oc attach 를 비롯한 여러 oc 명령에 오류가 발생합니다. 인증서가 순환될 때 MCP가 일시 중지되면 OpenShift Container Platform 웹 콘솔의 경고 UI에 경고가 표시됩니다.

MCP 일시 중지는 kube-apiserver-to-kubelet-signer CA 인증서 만료에 대해 신중하게 고려하여 단기간 동안만 수행해야 합니다.

참고

MCP를 다른 OpenShift Container Platform 버전으로 업데이트하지 않는 것이 좋습니다. 예를 들어 한 MCP를 4.y.10에서 4.y.11로 다른 MCP를 4.y.12로 업데이트하지 마십시오. 이 시나리오는 테스트되지 않아 정의되지 않은 클러스터 상태가 될 수 있습니다.

3.4.2. 카나리아 롤아웃 업데이트 프로세스 및 MCP 정보

OpenShift Container Platform에서 노드는 개별적으로 간주되지 않습니다. 대신 MCP(Machine config pool)로 그룹화됩니다. 기본적으로 OpenShift Container Platform 클러스터의 노드는 두 개의 MCP로 그룹화됩니다. 하나는 컨트롤 플레인 노드용이고 하나는 작업자 노드용입니다. OpenShift Container Platform 업데이트는 모든 MCP에 동시에 영향을 미칩니다.

업데이트 중에 최대 수가 지정된 경우 MCO(Machine Config Operator)는 MCP 내의 모든 노드를 지정된 maxUnavailable 노드 수까지 드레이닝하고 차단합니다. 기본적으로 maxUnavailable 은 1 로 설정됩니다. 노드를 드레이닝하고 차단하면 노드의 모든 Pod 예약이 취소되고 노드가 예약 불가능으로 표시됩니다.

노드를 드레이닝한 후 Machine Config Daemon은 OS(운영 체제) 업데이트를 포함할 수 있는 새 머신 구성을 적용합니다. OS를 업데이트하려면 호스트가 재부팅해야 합니다.

사용자 정의 머신 구성 풀 사용

특정 노드가 업데이트되지 않도록 사용자 지정 MCP를 생성할 수 있습니다. MCO는 일시 중지된 MCP 내에서 노드를 업데이트하지 않으므로 클러스터 업데이트를 시작하기 전에 업데이트하지 않으려는 노드가 포함된 MCP를 일시 중지할 수 있습니다.

하나 이상의 사용자 지정 MCP를 사용하면 작업자 노드를 업데이트하는 시퀀스를 더 많이 제어할 수 있습니다. 예를 들어 첫 번째 MCP에서 노드를 업데이트한 후 애플리케이션 호환성을 확인한 다음 나머지 노드를 새 버전으로 점진적으로 업데이트할 수 있습니다.

주의

maxUnavailable 의 기본 설정은 OpenShift Container Platform의 모든 머신 구성 풀에 대해 1 입니다. 이 값을 변경하지 않고 한 번에 하나의 컨트롤 플레인 노드를 업데이트하는 것이 좋습니다. 컨트롤 플레인 풀의 경우 이 값을 3 으로 변경하지 마십시오.

참고

컨트롤 플레인의 안정성을 보장하기 위해 컨트롤 플레인 노드에서 사용자 정의 MCP를 생성하는 것은 지원되지 않습니다. MCO(Machine Config Operator)는 컨트롤 플레인 노드에 대해 생성된 사용자 정의 MCP를 무시합니다.

사용자 정의 머신 구성 풀을 사용할 때 고려 사항

워크로드 배포 토폴로지에 따라 생성하는 MCP 수와 각 MCP의 노드 수를 신중하게 고려합니다. 예를 들어 특정 유지 관리 창에 업데이트를 조정해야 하는 경우 지정된 기간 내에 OpenShift Container Platform을 업데이트할 수 있는 노드 수를 알아야 합니다. 이 숫자는 고유한 클러스터 및 워크로드 특성에 따라 달라집니다.

또한 각 MCP 내의 사용자 지정 MCP 수와 노드 양을 결정하기 위해 클러스터에서 사용할 수 있는 추가 용량을 고려해야 합니다. 새로 업데이트된 노드에서 애플리케이션이 예상대로 작동하지 않는 경우 풀의 해당 노드를 차단하고 드레이닝하여 애플리케이션 Pod를 다른 노드로 이동할 수 있습니다. 그러나 나머지 MCP에서 사용 가능한 노드가 애플리케이션에 충분한 QoS(Quality of Service)를 제공할 수 있는지 확인해야 합니다.

참고

이 업데이트 프로세스를 문서화된 모든 OpenShift Container Platform 업데이트 프로세스와 함께 사용할 수 있습니다. 그러나 이 프로세스는 Ansible 플레이북을 사용하여 업데이트되는 RHEL(Red Hat Enterprise Linux) 시스템에서는 작동하지 않습니다.

3.4.3. 카나리아 롤아웃 업데이트 수행 정보

다음 단계에서는 카나리아 롤아웃 업데이트 프로세스의 상위 수준 워크플로를 간략하게 설명합니다.

작업자 풀을 기반으로 사용자 지정 MCP(머신 구성 풀)를 생성합니다.
참고
MCP에서 maxUnavailable 설정을 변경하여 언제든지 업데이트할 수 있는 머신 수를 지정할 수 있습니다. 기본값은 1입니다.
주의
maxUnavailable 의 기본 설정은 OpenShift Container Platform의 모든 머신 구성 풀에 대해 1 입니다. 이 값을 변경하지 않고 한 번에 하나의 컨트롤 플레인 노드를 업데이트하는 것이 좋습니다. 컨트롤 플레인 풀의 경우 이 값을 3 으로 변경하지 마십시오.
사용자 지정 MCP에 노드 선택기를 추가합니다. 나머지 클러스터와 동시에 업데이트하지 않으려는 각 노드에 대해 일치하는 레이블을 노드에 추가합니다. 이 레이블은 노드를 MCP에 연결합니다.
중요
노드에서 기본 작업자 레이블을 제거하지 마십시오. 노드에는 클러스터에서 제대로 작동하려면 역할 레이블이 있어야 합니다.
업데이트 프로세스의 일부로 업데이트하지 않으려는 MCP를 일시 중지합니다.
클러스터 업데이트를 수행합니다. 업데이트 프로세스는 컨트롤 플레인 노드를 포함하여 일시 중지되지 않은 MCP를 업데이트합니다.
업데이트된 노드에서 애플리케이션을 테스트하여 애플리케이션이 예상대로 작동하는지 확인합니다.
나머지 MCP 중 일시 중지를 해제하고 해당 풀의 노드가 업데이트가 완료될 때까지 기다린 후 해당 노드에서 애플리케이션을 테스트합니다. 모든 작업자 노드가 업데이트될 때까지 이 프로세스를 반복합니다.
선택 사항: 업데이트된 노드에서 사용자 지정 레이블을 제거하고 사용자 지정 MCP를 삭제합니다.

3.4.4. 카나리아 롤아웃 업데이트를 수행할 머신 구성 풀 생성

카나리아 롤아웃 업데이트를 수행하려면 먼저 하나 이상의 사용자 지정 MCP(Machine config pool)를 생성해야 합니다.

프로세스

다음 명령을 실행하여 클러스터의 작업자 노드를 나열합니다.

$ oc get -l 'node-role.kubernetes.io/master!=' -o 'jsonpath={range .items[*]}{.metadata.name}{"\n"}{end}' nodes

출력 예

ci-ln-pwnll6b-f76d1-s8t9n-worker-a-s75z4
ci-ln-pwnll6b-f76d1-s8t9n-worker-b-dglj2
ci-ln-pwnll6b-f76d1-s8t9n-worker-c-lldbm

지연할 각 노드에 대해 다음 명령을 실행하여 노드에 사용자 정의 라벨을 추가합니다.

$ oc label node <node_name> node-role.kubernetes.io/<custom_label>=

예를 들면 다음과 같습니다.

$ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary=

출력 예

node/ci-ln-gtrwm8t-f76d1-spbl7-worker-a-xk76k labeled

새 MCP를 생성합니다.

MCP YAML 파일을 생성합니다.

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: workerpool-canary 1
spec:
  machineConfigSelector:
    matchExpressions:
      - {
         key: machineconfiguration.openshift.io/role,
         operator: In,
         values: [worker,workerpool-canary] 2
        }
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/workerpool-canary: "" 3

1: MCP의 이름을 지정합니다.
2: worker 및 사용자 지정 MCP 이름을 지정합니다.
3: 이 풀에서 원하는 노드에 추가한 사용자 지정 라벨을 지정합니다.

다음 명령을 실행하여 MachineConfigPool 오브젝트를 생성합니다.

$ oc create -f <file_name>

출력 예

machineconfigpool.machineconfiguration.openshift.io/workerpool-canary created

다음 명령을 실행하여 클러스터의 MCP 목록과 현재 상태를 확인합니다.

$ oc get machineconfigpool

출력 예

NAME              CONFIG                                                        UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master            rendered-master-b0bb90c4921860f2a5d8a2f8137c1867              True      False      False      3              3                   3                     0                      97m
workerpool-canary rendered-workerpool-canary-87ba3dec1ad78cb6aecebf7fbb476a36   True      False      False      1              1                   1                     0                      2m42s
worker            rendered-worker-87ba3dec1ad78cb6aecebf7fbb476a36              True      False      False      2              2                   2                     0                      97m

새 머신 구성 풀 workerpool-canary가 생성되고 사용자 정의 레이블을 추가한 노드 수가 머신 수에 표시됩니다. 작업자 MCP 머신 수는 동일한 수만큼 줄어듭니다. 시스템 수를 업데이트하는 데 몇 분이 걸릴 수 있습니다. 이 예에서는 하나의 노드가 worker MCP에서 workerpool-canary MCP로 이동되었습니다.

3.4.5. 작업자 풀 카나리아에 대한 머신 구성 상속 관리

기존 MCP에 할당된 MachineConfig 를 상속하도록 MCP(Machine config pool) canary를 구성할 수 있습니다. 이 구성은 MCP 카나리아를 사용하여 기존 MCP의 노드를 하나씩 업데이트할 때 유용합니다.

사전 요구 사항

MCP를 하나 이상 생성했습니다.

프로세스

다음 두 단계에 설명된 대로 보조 MCP를 생성합니다.

다음 구성 파일을 machineConfigPool.yaml 로 저장합니다.

Example machineConfigPool YAML

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-perf
spec:
  machineConfigSelector:
    matchExpressions:
      - {
         key: machineconfiguration.openshift.io/role,
         operator: In,
         values: [worker,worker-perf]
        }
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-perf: ""
# ...

다음 명령을 실행하여 새 머신 구성 풀을 생성합니다.

$ oc create -f machineConfigPool.yaml

출력 예

machineconfigpool.machineconfiguration.openshift.io/worker-perf created

보조 MCP에 일부 머신을 추가합니다. 다음 예제에서는 작업자 노드 worker-a,worker-b, worker-c 를 MCP worker-perf 로 레이블을 지정합니다.

$ oc label node worker-a node-role.kubernetes.io/worker-perf=''

$ oc label node worker-b node-role.kubernetes.io/worker-perf=''

$ oc label node worker-c node-role.kubernetes.io/worker-perf=''

다음 두 단계에 설명된 대로 MCP worker-perf 의 새 MachineConfig 를 생성합니다.

다음 MachineConfig 예제를 new-machineconfig.yaml 이라는 파일로 저장합니다.

MachineConfig YAML의 예

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker-perf
  name: 06-kdump-enable-worker-perf
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
      - enabled: true
        name: kdump.service
  kernelArguments:
    - crashkernel=512M
# ...

다음 명령을 실행하여 MachineConfig 를 적용합니다.
```
$ oc create -f new-machineconfig.yaml
```

새 카나리아 MCP를 생성하고 이전 단계에서 생성한 MCP에서 머신을 추가합니다. 다음 예제에서는 worker-perf-canary 라는 MCP를 생성하고 미리 생성한 worker-perf MCP에서 머신을 추가합니다.
1. 다음 명령을 실행하여 카나리아 작업자 노드 worker-a 에 레이블을 지정합니다.
```
$ oc label node worker-a node-role.kubernetes.io/worker-perf-canary=''
```
2. 다음 명령을 실행하여 카나리아 작업자 노드 worker-a 를 원래 MCP에서 제거합니다.
```
$ oc label node worker-a node-role.kubernetes.io/worker-perf-
```
3. 다음 파일을 machineConfigPool-Canary.yaml 로 저장합니다.
  Example machineConfigPool-Canary.yaml file
```
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-perf-canary
spec:
  machineConfigSelector:
    matchExpressions:
      - {
         key: machineconfiguration.openshift.io/role,
         operator: In,
         values: [worker,worker-perf,worker-perf-canary] 1
        }
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-perf-canary: ""
```
  1
  선택적 값입니다. 이 예제에는 worker-perf-canary 가 추가 값으로 포함됩니다. 이 방법으로 값을 사용하여 추가 MachineConfig 의 멤버를 구성할 수 있습니다.
4. 다음 명령을 실행하여 새 worker-perf-canary 를 생성합니다.
```
$ oc create -f machineConfigPool-Canary.yaml
```
  출력 예
```
machineconfigpool.machineconfiguration.openshift.io/worker-perf-canary created
```

MachineConfig 가 worker-perf-canary 에 상속되었는지 확인합니다.

다음 명령을 실행하여 MCP의 성능이 저하되지 않았는지 확인합니다.

$ oc get mcp

출력 예

NAME                  CONFIG                                                          UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master                rendered-master-2bf1379b39e22bae858ea1a3ff54b2ac                True      False      False      3              3                   3                     0                      5d16h
worker                rendered-worker-b9576d51e030413cfab12eb5b9841f34                True      False      False      0              0                   0                     0                      5d16h
worker-perf          rendered-worker-perf-b98a1f62485fa702c4329d17d9364f6a          True      False      False      2              2                   2                     0                      56m
worker-perf-canary   rendered-worker-perf-canary-b98a1f62485fa702c4329d17d9364f6a   True      False      False      1              1                   1                     0                      44m

시스템이 worker-perf에서 worker- perf -canary 로 상속되었는지 확인합니다.

$ oc get nodes

출력 예

NAME       STATUS   ROLES                        AGE     VERSION
...
worker-a   Ready    worker,worker-perf-canary   5d15h   v1.27.13+e709aa5
worker-b   Ready    worker,worker-perf          5d15h   v1.27.13+e709aa5
worker-c   Ready    worker,worker-perf          5d15h   v1.27.13+e709aa5

다음 명령을 실행하여 worker-a 에서 kdump 서비스가 활성화되어 있는지 확인합니다.

$ systemctl status kdump.service

출력 예

NAME       STATUS   ROLES                        AGE     VERSION
...
kdump.service - Crash recovery kernel arming
     Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; preset: disabled)
     Active: active (exited) since Tue 2024-09-03 12:44:43 UTC; 10s ago
    Process: 4151139 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
   Main PID: 4151139 (code=exited, status=0/SUCCESS)

다음 명령을 실행하여 MCP가 crashkernel 을 업데이트했는지 확인합니다.
```
$ cat /proc/cmdline
```
출력에는 업데이트된 crashekernel 값이 포함되어야 합니다. 예를 들면 다음과 같습니다.
출력 예
```
crashkernel=512M
```

선택 사항: 업그레이드에 만족하는 경우 worker-a 를 worker-perf 로 반환할 수 있습니다.
1. 다음 명령을 실행하여 worker-a 를 worker-perf 로 반환합니다.
```
$ oc label node worker-a node-role.kubernetes.io/worker-perf=''
```
2. 다음 명령을 실행하여 카나리아 MCP에서 worker-a 를 제거합니다.
```
$ oc label node worker-a node-role.kubernetes.io/worker-perf-canary-
```

3.4.6. 머신 구성 풀 일시 중지

MCP(사용자 정의 머신 구성 풀)를 생성한 후 해당 MCP를 일시 중지합니다. MCP를 일시 중지하면 MCO(Machine Config Operator)가 해당 MCP와 연결된 노드를 업데이트할 수 없습니다.

프로세스

다음 명령을 실행하여 일시 중지하려는 MCP를 패치합니다.

$ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":true}}' --type=merge

예를 들면 다음과 같습니다.

$  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":true}}' --type=merge

출력 예

machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

3.4.7. 클러스터 업데이트 수행

MCP(머신 구성 풀)가 준비 상태가 되면 클러스터 업데이트를 수행할 수 있습니다. 클러스터에 적합한 다음 업데이트 방법 중 하나를 참조하십시오.

클러스터 업데이트가 완료되면 MCP의 일시 중지를 한 번에 하나씩 해제할 수 있습니다.

3.4.8. 머신 구성 풀 일시 중지 해제

OpenShift Container Platform 업데이트가 완료되면 MCP(사용자 정의 머신 구성 풀)를 한 번에 하나씩 일시 중지 해제합니다. MCP의 일시 중지를 해제하면 MCO(Machine Config Operator)가 해당 MCP와 연결된 노드를 업데이트할 수 있습니다.

프로세스

일시 중지 해제할 MCP를 패치합니다.

$ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":false}}' --type=merge

예를 들면 다음과 같습니다.

$  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":false}}' --type=merge

출력 예

machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

선택 사항: 다음 옵션 중 하나를 사용하여 업데이트 진행 상황을 확인합니다.
1. 관리 클러스터 설정을 클릭하여 웹 콘솔에서 진행 상황을 확인합니다.
2. 다음 명령을 실행하여 진행 상황을 확인합니다.
```
$ oc get machineconfigpools
```
업데이트된 노드에서 애플리케이션을 테스트하여 애플리케이션이 예상대로 작동하는지 확인합니다.
일시 중지된 다른 MCP에 대해 한 번에 하나씩 이 프로세스를 반복합니다.

참고

업데이트된 노드에서 작동하지 않는 애플리케이션 등의 오류가 발생하는 경우 풀의 노드를 차단하고 드레이닝하여 애플리케이션 pod를 다른 노드로 이동하여 애플리케이션의 서비스 품질을 유지 관리할 수 있습니다. 첫 번째 MCP는 초과 용량보다 크지 않아야 합니다.

3.4.9. 노드를 원래 머신 구성 풀로 이동

MCP(사용자 정의 머신 구성 풀)의 노드에서 애플리케이션을 업데이트하고 확인한 후 노드에 추가한 사용자 지정 레이블을 제거하여 노드를 원래 MCP로 다시 이동합니다.

중요

노드에는 클러스터에서 제대로 작동하는 역할이 있어야 합니다.

프로세스

사용자 지정 MCP의 각 노드에 대해 다음 명령을 실행하여 노드에서 사용자 지정 레이블을 제거합니다.
```
$ oc label node <node_name> node-role.kubernetes.io/<custom_label>-
```
예를 들면 다음과 같습니다.
```
$ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary-
```
출력 예
```
node/ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz labeled
```
Machine Config Operator는 노드를 원래 MCP로 다시 이동하고 노드를 MCP 구성으로 조정합니다.

노드가 사용자 지정 MCP에서 제거되었는지 확인하려면 다음 명령을 실행하여 클러스터의 MCP 목록과 현재 상태를 확인합니다.

$ oc get mcp

출력 예

NAME                CONFIG                                                   UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master              rendered-master-1203f157d053fd987c7cbd91e3fbc0ed         True      False      False      3              3                   3                     0                      61m
workerpool-canary   rendered-mcp-noupdate-5ad4791166c468f3a35cd16e734c9028   True      False      False      0              0                   0                     0                      21m
worker              rendered-worker-5ad4791166c468f3a35cd16e734c9028         True      False      False      3              3                   3                     0                      61m

노드가 사용자 지정 MCP에서 제거되고 원래 MCP로 다시 이동하면 시스템 수를 업데이트하는 데 몇 분이 걸릴 수 있습니다. 이 예에서는 하나의 노드가 제거된 workerpool-canary MCP에서 worker MCP로 이동되었습니다.

선택 사항: 다음 명령을 실행하여 사용자 지정 MCP를 삭제합니다.
```
$ oc delete mcp <mcp_name>
```

3.4. 카나리아 롤아웃 업데이트 수행

3.4.1. Canary 업데이트 전략의 예

사용자 정의 머신 구성 풀 정의

카나리아 작업자 풀 업데이트

나머지 작업자 풀 업데이트를 진행할지 여부 확인

3.4.2. 카나리아 롤아웃 업데이트 프로세스 및 MCP 정보

사용자 정의 머신 구성 풀 사용

사용자 정의 머신 구성 풀을 사용할 때 고려 사항

3.4.3. 카나리아 롤아웃 업데이트 수행 정보

3.4.4. 카나리아 롤아웃 업데이트를 수행할 머신 구성 풀 생성

3.4.5. 작업자 풀 카나리아에 대한 머신 구성 상속 관리

3.4.6. 머신 구성 풀 일시 중지

3.4.7. 클러스터 업데이트 수행

3.4.8. 머신 구성 풀 일시 중지 해제

3.4.9. 노드를 원래 머신 구성 풀로 이동

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links