프로세스

1. 각 MCP(머신 구성 풀)에 대해 클러스터에서 사용 가능한 MCO 관리 노드 수를 보려면 다음 명령을 실행합니다.

   $ oc get machineconfigpool

   출력 예

   NAME      CONFIG                    UPDATED  UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT  AGE
   master    rendered-master-06c9c4…   True     False      False     3             3                  3                   0                     4h42m
   worker    rendered-worker-f4b64…    False    True       False     3             2                  2                   0                     4h42m

   다음과 같습니다.

   UPDATED

   True 상태는 MCO가 현재 머신 구성을 해당 MCP의 노드에 적용했음을 나타냅니다. 현재 머신 구성은 oc get mcp 출력의 STATUS 필드에 지정됩니다. False 상태는 MCP의 노드가 업데이트 중임을 나타냅니다.

   업데이트

   True 상태는 MachineConfigPool 사용자 정의 리소스에 지정된 대로 MCO가 해당 MCP의 노드 중 하나 이상에 지정된 대로 원하는 머신 구성을 적용함을 나타냅니다. 원하는 머신 구성은 새로 편집된 머신 구성입니다. 업데이트 중인 노드를 예약에 사용할 수 없을 수 있습니다. False 상태는 MCP의 모든 노드가 업데이트되었음을 나타냅니다.

   DEGRADED

   True 상태는 MCO가 현재 또는 원하는 머신 구성을 해당 MCP의 노드 중 하나 이상에 적용하지 못하거나 구성이 실패함을 나타냅니다. 성능이 저하된 노드는 스케줄링에 사용할 수 없을 수 있습니다. False 상태는 MCP의 모든 노드가 준비되었음을 나타냅니다.

   MACHINECOUNT

   해당 MCP의 총 머신 수를 나타냅니다.

   READYMACHINECOUNT

   예약할 준비가 된 MCP의 총 머신 수를 나타냅니다.

   UPDATEDMACHINECOUNT

   현재 머신 구성이 있는 MCP의 총 머신 수를 나타냅니다.

   DEGRADEDMACHINECOUNT

   degraded 또는 Unreconcilable으로 표시된 MCP의 총 머신 수를 나타냅니다.

   이전 출력에는 컨트롤 플레인 (마스터) 노드와 3 개의 작업자 노드가 있습니다. 컨트롤 플레인 MCP 및 관련 노드가 현재 머신 구성으로 업데이트됩니다. 작업자 MCP의 노드가 원하는 머신 구성으로 업데이트되고 있습니다. 작업자 MCP의 노드 중 두 개가 업데이트되어 UPDATEDMACHINECOUNT 가 2 로 표시된 대로 계속 업데이트됩니다. DEGRADEDMACHINECOUNT 가 0 이고 DEGRADED 가 False 인 경우 문제가 없습니다.

   MCP의 노드가 업데이트되는 동안 CONFIG 아래에 나열된 머신 구성은 현재 머신 구성으로, MCP가 업데이트되고 있습니다. 업데이트가 완료되면 나열된 머신 구성이 MCP를 업데이트한 원하는 머신 구성입니다.

   참고

   노드가 차단되는 경우 해당 노드는 READYMACHINECOUNT 에 포함되지 않지만 MACHINECOUNT 에 포함됩니다. 또한 MCP 상태는 UPDATING 으로 설정됩니다. 노드에 현재 머신 구성이 있으므로 UPDATEDMACHINECOUNT 합계에 계산됩니다.

   출력 예

   NAME      CONFIG                    UPDATED  UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT  AGE
   master    rendered-master-06c9c4…   True     False      False     3             3                  3                   0                     4h42m
   worker    rendered-worker-c1b41a…   False    True       False     3             2                  3                   0                     4h42m

2. MachineConfigPool 사용자 정의 리소스를 검사하여 MCP의 노드 상태를 확인하려면 다음 명령을 실행합니다.

   $ oc describe mcp worker

   출력 예

   ...
     Degraded Machine Count:     0
     Machine Count:              3
     Observed Generation:        2
     Ready Machine Count:        3
     Unavailable Machine Count:  0
     Updated Machine Count:      3
   Events:                       <none>

   참고

   노드가 차단 중이면 노드가 Ready 머신 수에 포함되지 않습니다. Unavailable Machine Count 에 포함되어 있습니다:

   출력 예

   ...
     Degraded Machine Count:     0
     Machine Count:              3
     Observed Generation:        2
     Ready Machine Count:        2
     Unavailable Machine Count:  1
     Updated Machine Count:      3

3. 기존 MachineConfig 오브젝트를 보려면 다음 명령을 실행합니다.

   $ oc get machineconfigs

   출력 예

   NAME                             GENERATEDBYCONTROLLER          IGNITIONVERSION  AGE
   00-master                        2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
   00-worker                        2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
   01-master-container-runtime      2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
   01-master-kubelet                2c9371fbb673b97a6fe8b1c52…     3.2.0            5h18m
   ...
   rendered-master-dde...           2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
   rendered-worker-fde...           2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m

   rendered 로 나열된 MachineConfig 오브젝트는 변경하거나 삭제할 수 없습니다.

4. 특정 머신 구성의 내용을 보려면 (이 경우 01-master-kubelet) 다음 명령을 실행합니다.

   $ oc describe machineconfigs 01-master-kubelet

   명령의 출력에는 이 MachineConfig 오브젝트에 구성 파일(cloud.conf 및 kubelet.conf)과 systemd 서비스(Kubernetes Kubelet)가 모두 포함되어 있음을 보여줍니다.

   출력 예

   Name:         01-master-kubelet
   ...
   Spec:
     Config:
       Ignition:
         Version:  3.2.0
       Storage:
         Files:
           Contents:
             Source:   data:,
           Mode:       420
           Overwrite:  true
           Path:       /etc/kubernetes/cloud.conf
           Contents:
             Source:   data:,kind%3A%20KubeletConfiguration%0AapiVersion%3A%20kubelet.config.k8s.io%2Fv1beta1%0Aauthentication%3A%0A%20%20x509%3A%0A%20%20%20%20clientCAFile%3A%20%2Fetc%2Fkubernetes%2Fkubelet-ca.crt%0A%20%20anonymous...
           Mode:       420
           Overwrite:  true
           Path:       /etc/kubernetes/kubelet.conf
       Systemd:
         Units:
           Contents:  [Unit]
   Description=Kubernetes Kubelet
   Wants=rpc-statd.service network-online.target crio.service
   After=network-online.target crio.service
   
   ExecStart=/usr/bin/hyperkube \
       kubelet \
         --config=/etc/kubernetes/kubelet.conf \ ...

프로세스

1. chrony.conf 파일의 내용을 포함하여 Butane config를 만듭니다. 예를 들어 작업자 노드에 chrony를 구성하려면 99-worker-chrony.bu 파일을 만듭니다.

   참고

   Butane에 대한 자세한 내용은 “Butane 을 사용하여 머신 구성 생성”을 참조하십시오.

   variant: openshift
   version: 4.12.0
   metadata:
     name: 99-worker-chrony 1
     labels:
       machineconfiguration.openshift.io/role: worker 2
   storage:
     files:
     - path: /etc/chrony.conf
       mode: 0644 3
       overwrite: true
       contents:
         inline: |
           pool 0.rhel.pool.ntp.org iburst 4
           driftfile /var/lib/chrony/drift
           makestep 1.0 3
           rtcsync
           logdir /var/log/chrony

   1 2

   컨트롤 플레인 노드에서 두 위치에 있는 master를 worker로 대체합니다.

   3

   시스템 구성 파일에서 mode 필드의 8진수 값 모드를 지정합니다. 파일을 만들고 변경 사항을 적용하면 mode가 10진수 값으로 변환됩니다. oc get mc <mc-name> -o yaml 명령을 사용하여 YAML 파일을 확인할 수 있습니다.

   4

   DHCP 서버에서 제공하는 것과 같은 유효한 시간 소스를 지정합니다. 다른 방법으로 1.rhel.pool.ntp.org, 2.rhel.pool.ntp.org 또는 3.rhel.pool.ntp.org의 NTP 서버 중 하나를 지정할 수 있습니다.

2. Butane을 사용하여 노드에 전달할 구성이 포함된 MachineConfig 파일 99-worker-chrony.yaml을 생성합니다.

   $ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml

3. 다음 두 가지 방법 중 하나로 설정을 적용하십시오.

   • 클러스터가 아직 실행되지 않은 경우 매니페스트 파일을 생성한 후 <installation_directory>/openshift 디렉터리에 MachineConfig 개체 파일을 추가한 다음 클러스터를 계속 작성합니다.

   • 클러스터가 이미 실행중인 경우 다음과 같은 파일을 적용합니다.

     $ oc apply -f ./99-worker-chrony.yaml

절차

1. 지정된 노드 역할에 대해 chronyd를 비활성화하는 MachineConfig CR을 만듭니다.

   1. 다음 YAML을 disable-chronyd.yaml 파일에 저장합니다.

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: <node_role> 1
        name: disable-chronyd
      spec:
        config:
          ignition:
            version: 3.2.0
          systemd:
            units:
              - contents: |
                  [Unit]
                  Description=NTP client/server
                  Documentation=man:chronyd(8) man:chrony.conf(5)
                  After=ntpdate.service sntp.service ntpd.service
                  Conflicts=ntpd.service systemd-timesyncd.service
                  ConditionCapability=CAP_SYS_TIME
                  [Service]
                  Type=forking
                  PIDFile=/run/chrony/chronyd.pid
                  EnvironmentFile=-/etc/sysconfig/chronyd
                  ExecStart=/usr/sbin/chronyd $OPTIONS
                  ExecStartPost=/usr/libexec/chrony-helper update-daemon
                  PrivateTmp=yes
                  ProtectHome=yes
                  ProtectSystem=full
                  [Install]
                  WantedBy=multi-user.target
                enabled: false
                name: "chronyd.service"

      1

      chronyd를 비활성화하려는 노드 역할(예: master)입니다.

   2. 다음 명령을 실행하여 MachineConfig CR을 생성합니다.

      $ oc create -f disable-chronyd.yaml

프로세스

1. OpenShift Container Platform 클러스터의 기존 MachineConfig 오브젝트를 나열하고 머신 구성에 라벨을 지정하는 방법을 결정합니다.

   $ oc get MachineConfig

   출력 예

   NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
   00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-ssh                                                                                 3.2.0             40m
   99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-worker-ssh                                                                                 3.2.0             40m
   rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

2. 커널 인수를 식별하는 MachineConfig 파일을 만듭니다 (예: 05-worker-kernelarg-selinuxpermissive.yaml).

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker1
     name: 05-worker-kernelarg-selinuxpermissive2
   spec:
     kernelArguments:
       - enforcing=03

   1

   새 커널 인수를 작업자 노드에만 적용합니다.

   2

   머신 구성(05) 중 적합한 위치와 어떤 기능 (SELinux 허용 모드를 구성하기 위해 커널 매개변수 추가)을 하는지 식별하기 위해 이름이 지정됩니다.

   3

   정확한 커널 인수를 enforcing=0으로 식별합니다.

3. 새 머신 구성을 생성합니다.

   $ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml

4. 머신 구성에서 새 구성이 추가되었는지 확인합니다.

   $ oc get MachineConfig

   출력 예

   NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
   00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   05-worker-kernelarg-selinuxpermissive                                                         3.2.0             105s
   99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-ssh                                                                                 3.2.0             40m
   99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-worker-ssh                                                                                 3.2.0             40m
   rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

5. 노드를 확인합니다.

   $ oc get nodes

   출력 예

   NAME                           STATUS                     ROLES    AGE   VERSION
   ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.25.0
   ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.25.0
   ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.25.0
   ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.25.0
   ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.25.0
   ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.25.0

   변경 사항이 적용되어 있기 때문에 각 작업자 노드의 예약이 비활성화되어 있음을 알 수 있습니다.

6. 작업자 노드 중 하나로 이동하여 커널 명령 행 인수 (호스트의 /proc/cmdline 에 있음)를 나열하여 커널 인수가 작동하는지 확인합니다.

   $ oc debug node/ip-10-0-141-105.ec2.internal

   출력 예

   Starting pod/ip-10-0-141-105ec2internal-debug ...
   To use host binaries, run `chroot /host`
   
   sh-4.2# cat /host/proc/cmdline
   BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8
   rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16...
   coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 enforcing=0
   
   sh-4.2# exit

   enforcing=0 인수가 다른 커널 인수에 추가된 것을 확인할 수 있습니다.

절차

1. 컨트롤 플레인 노드에서 다중 경로 설치 후 활성화하려면 다음을 수행합니다.

   • 다음과 같이 클러스터에 master 레이블를 추가하도록 지시하고 다중 경로 커널 인수를 식별하는 99-master-kargs-mpath.yaml과 같은 머신 구성 파일을 만듭니다.

     apiVersion: machineconfiguration.openshift.io/v1
     kind: MachineConfig
     metadata:
       labels:
         machineconfiguration.openshift.io/role: "master"
       name: 99-master-kargs-mpath
     spec:
       kernelArguments:
         - 'rd.multipath=default'
         - 'root=/dev/disk/by-label/dm-mpath-root'

2. 작업자 노드에서 다중 경로 설치 후 활성화하려면 다음을 수행합니다.

   • 다음과 같은 99-worker-kargs-mpath.yaml 과 같은 머신 구성 파일을 생성하여 클러스터에 worker 레이블을 추가하고 다중 경로 커널 인수를 식별합니다.

     apiVersion: machineconfiguration.openshift.io/v1
     kind: MachineConfig
     metadata:
       labels:
         machineconfiguration.openshift.io/role: "worker"
       name: 99-worker-kargs-mpath
     spec:
       kernelArguments:
         - 'rd.multipath=default'
         - 'root=/dev/disk/by-label/dm-mpath-root'

3. 이전에 작성한 마스터 또는 작업자 YAML 파일을 사용하여 새 머신 구성을 생성합니다.

   $ oc create -f ./99-worker-kargs-mpath.yaml

4. 머신 구성에서 새 구성이 추가되었는지 확인합니다.

   $ oc get MachineConfig

   출력 예

   NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
   00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-master-ssh                                                                                 3.2.0             40m
   99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   99-worker-kargs-mpath                              52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             105s
   99-worker-ssh                                                                                 3.2.0             40m
   rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
   rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m

5. 노드를 확인합니다.

   $ oc get nodes

   출력 예

   NAME                           STATUS                     ROLES    AGE   VERSION
   ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.25.0
   ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.25.0
   ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.25.0
   ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.25.0
   ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.25.0
   ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.25.0

   변경 사항이 적용되어 있기 때문에 각 작업자 노드의 예약이 비활성화되어 있음을 알 수 있습니다.

6. 작업자 노드 중 하나로 이동하여 커널 명령 행 인수 (호스트의 /proc/cmdline 에 있음)를 나열하여 커널 인수가 작동하는지 확인합니다.

   $ oc debug node/ip-10-0-141-105.ec2.internal

   출력 예

   Starting pod/ip-10-0-141-105ec2internal-debug ...
   To use host binaries, run `chroot /host`
   
   sh-4.2# cat /host/proc/cmdline
   ...
   rd.multipath=default root=/dev/disk/by-label/dm-mpath-root
   ...
   
   sh-4.2# exit

   추가된 커널 인수가 표시되어야 합니다.

절차

1. 실시간 커널의 머신 구성을 만듭니다. realtime 커널 유형의 MachineConfig 개체가 포함된 YAML 파일 (예: 99-worker-realtime.yaml)을 만듭니다. 다음 예에서는 모든 작업자 노드에 대해 실시간 커널을 사용하도록 클러스터에 지시합니다.

   $ cat << EOF > 99-worker-realtime.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: "worker"
     name: 99-worker-realtime
   spec:
     kernelType: realtime
   EOF

2. 머신 구성을 클러스터에 추가합니다. 다음을 입력하여 머신 구성을 클러스터에 추가합니다.

   $ oc create -f 99-worker-realtime.yaml

3. 실시간 커널을 확인합니다 : 영향을 받는 각 노드가 재부팅되면 클러스터에 로그인하고 다음 명령을 실행하여 실시간 커널이 구성된 노드 세트의 일반 커널을 대체하고 있는지 확인합니다.

   $ oc get nodes

   출력 예

   NAME                                        STATUS  ROLES    AGE   VERSION
   ip-10-0-143-147.us-east-2.compute.internal  Ready   worker   103m  v1.25.0
   ip-10-0-146-92.us-east-2.compute.internal   Ready   worker   101m  v1.25.0
   ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.25.0

   $ oc debug node/ip-10-0-143-147.us-east-2.compute.internal

   출력 예

   Starting pod/ip-10-0-143-147us-east-2computeinternal-debug ...
   To use host binaries, run `chroot /host`
   
   sh-4.4# uname -a
   Linux <worker_node> 4.18.0-147.3.1.rt24.96.el8_1.x86_64 #1 SMP PREEMPT RT
           Wed Nov 27 18:29:55 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

   커널 이름에는 rt 및 "PREEMPT RT"라는 텍스트가 포함되어 이것이 실시간 커널임을 나타냅니다.

4. 일반 커널로 돌아가려면 MachineConfig 객체를 삭제합니다.

   $ oc delete -f 99-worker-realtime.yaml

절차

1. 필요한 설정과 함께 /etc/systemd/journald.conf 파일을 포함하는 Butane 구성 파일 40-worker-custom-journald.bu를 만듭니다.

   참고

   Butane에 대한 자세한 내용은 “Butane 을 사용하여 머신 구성 생성”을 참조하십시오.

   variant: openshift
   version: 4.12.0
   metadata:
     name: 40-worker-custom-journald
     labels:
       machineconfiguration.openshift.io/role: worker
   storage:
     files:
     - path: /etc/systemd/journald.conf
       mode: 0644
       overwrite: true
       contents:
         inline: |
           # Disable rate limiting
           RateLimitInterval=1s
           RateLimitBurst=10000
           Storage=volatile
           Compress=no
           MaxRetentionSec=30s

2. Butane을 사용하여 작업자 노드로 전달할 구성이 포함된 MachineConfig 개체 파일 40-worker-custom-journald.yaml을 생성합니다.

   $ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml

3. 머신 구성을 풀에 적용합니다.

   $ oc apply -f 40-worker-custom-journald.yaml

4. 새 머신 구성이 적용되고 노드가 저하된 상태에 있는지 확인합니다. 이 작업을 수행하는 데 몇 분 정도 걸릴 수 있습니다. 각 노드에 새 머신 구성이 성공적으로 적용되어 작업자 풀에 진행중인 업데이트가 표시됩니다.

   $ oc get machineconfigpool
   NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
   master rendered-master-35 True    False    False    3            3                 3                   0                    34m
   worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m

5. 변경 사항이 적용되었는지 확인하려면 작업자 노드에 로그인합니다.

   $ oc get node | grep worker
   ip-10-0-0-1.us-east-2.compute.internal   Ready    worker   39m   v0.0.0-master+$Format:%h$
   $ oc debug node/ip-10-0-0-1.us-east-2.compute.internal
   Starting pod/ip-10-0-141-142us-east-2computeinternal-debug ...
   ...
   sh-4.2# chroot /host
   sh-4.4# cat /etc/systemd/journald.conf
   # Disable rate limiting
   RateLimitInterval=1s
   RateLimitBurst=10000
   Storage=volatile
   Compress=no
   MaxRetentionSec=30s
   sh-4.4# exit

절차

1. 확장 기능을 위한 머신 구성을 만듭니다. MachineConfig extensions 개체를 포함하는 YAML 파일 (예 : 80-extensions.yaml)을 만듭니다. 이 예에서는 클러스터에 usbguard 확장 기능을 추가하도록 지시합니다.

   $ cat << EOF > 80-extensions.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 80-worker-extensions
   spec:
     config:
       ignition:
         version: 3.2.0
     extensions:
       - usbguard
   EOF

2. 머신 구성을 클러스터에 추가합니다. 다음을 입력하여 머신 구성을 클러스터에 추가합니다.

   $ oc create -f 80-extensions.yaml

   이렇게하면 모든 작업자 노드에 usbguard의 rpm 패키지가 설치됩니다.

3. 확장 기능이 적용되었는지 확인합니다.

   $ oc get machineconfig 80-worker-extensions

   출력 예

   NAME                 GENERATEDBYCONTROLLER IGNITIONVERSION AGE
   80-worker-extensions                       3.2.0           57s

4. 새 머신 구성이 적용되고 노드가 저하된 상태에 있는지 확인합니다. 이 작업을 수행하는 데 몇 분 정도 걸릴 수 있습니다. 각 머신에 새 머신 구성이 성공적으로 적용되면 작업자 풀에 진행중인 업데이트가 표시됩니다.

   $ oc get machineconfigpool

   출력 예

   NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
   master rendered-master-35 True    False    False    3            3                 3                   0                    34m
   worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m

5. 확장 기능을 확인합니다. 확장 기능이 적용되었는지 확인하려면 다음을 실행하십시오.

   $ oc get node | grep worker

   출력 예

   NAME                                        STATUS  ROLES    AGE   VERSION
   ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.25.0

   $ oc debug node/ip-10-0-169-2.us-east-2.compute.internal

   출력 예

   ...
   To use host binaries, run `chroot /host`
   sh-4.4# chroot /host
   sh-4.4# rpm -q usbguard
   usbguard-0.7.4-4.el8.x86_64.rpm

절차

1. 로컬 스토리지에 루트 소유 및 쓰기 가능을 위해 검색 경로를 업데이트하는 Butane 구성 파일 98-worker-firmware-blob.bu 를 만듭니다. 다음 예제에서는 사용자 지정 Blob 파일을 로컬 워크스테이션의 노드에 /var/lib/firmware 아래에 배치합니다.

   참고

   Butane에 대한 자세한 내용은 “Butane 을 사용하여 머신 구성 생성”을 참조하십시오.

   사용자 지정 펌웨어 Blob용 Butane 구성 파일

   variant: openshift
   version: 4.12.0
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 98-worker-firmware-blob
   storage:
     files:
     - path: /var/lib/firmware/<package_name> 1
       contents:
         local: <package_name> 2
       mode: 0644 3
   openshift:
     kernel_arguments:
       - 'firmware_class.path=/var/lib/firmware' 4

   1

   펌웨어 패키지가 복사되는 노드의 경로를 설정합니다.

   2

   Butane을 실행하는 시스템의 로컬 파일 디렉터리에서 읽은 내용을 사용하여 파일을 지정합니다. 로컬 파일의 경로는 다음 단계에서 Butane과 함께 -- files-dir 옵션을 사용하여 지정해야 하는 files-dir 디렉터리를 기준으로 합니다.

   3

   RHCOS 노드에 파일에 대한 권한을 설정합니다. 0644 권한을 설정하는 것이 좋습니다.

   4

   firmware_class.path 매개 변수는 로컬 워크스테이션에서 노드의 루트 파일 시스템에 복사되었던 사용자 지정 펌웨어 Blob을 찾을 위치의 커널 검색 경로를 사용자 지정합니다. 이 예에서는 /var/lib/firmware 를 사용자 지정된 경로로 사용합니다.

2. Butane을 실행하여 98-worker-firmware-blob.yaml 이라는 로컬 워크스테이션에서 펌웨어 Blob의 사본을 사용하는 MachineConfig 오브젝트 파일을 생성합니다. 펌웨어 Blob에는 노드에 전달할 구성이 포함되어 있습니다. 다음 예제에서는 --files-dir 옵션을 사용하여 로컬 파일 또는 파일이 있는 워크스테이션의 디렉터리를 지정합니다.

   $ butane 98-worker-firmware-blob.bu -o 98-worker-firmware-blob.yaml --files-dir <directory_including_package_name>

3. 다음 두 가지 방법 중 하나로 노드에 구성을 적용합니다.

   • 클러스터가 아직 실행되지 않은 경우 매니페스트 파일을 생성한 후 <installation_directory>/openshift 디렉터리에 MachineConfig 개체 파일을 추가한 다음 클러스터를 계속 작성합니다.

   • 클러스터가 이미 실행중인 경우 다음과 같은 파일을 적용합니다.

     $ oc apply -f 98-worker-firmware-blob.yaml

     머신 구성을 완료하기 위해 MachineConfig 오브젝트 YAML 파일이 생성됩니다.

4. 향후 MachineConfig 오브젝트를 업데이트해야 하는 경우 Butane 구성을 저장합니다.

사전 요구 사항

1. 구성하려는 노드 유형의 정적 MachineConfigPool CR와 연관된 라벨을 가져옵니다. 다음 중 하나를 실행합니다.

   1. Machine config pool을 표시합니다.

      $ oc describe machineconfigpool <name>

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

      $ oc describe machineconfigpool worker

      출력 예

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        creationTimestamp: 2019-02-08T14:52:39Z
        generation: 1
        labels:
          custom-kubelet: set-max-pods 1

      1

      라벨이 추가되면 labels 아래에 표시됩니다.

   2. 라벨이 없으면 키/값 쌍을 추가합니다.

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

절차

1. 이 명령은 선택할 수 있는 사용 가능한 머신 구성 오브젝트를 표시합니다.

   $ oc get machineconfig

   기본적으로 두 개의 kubelet 관련 구성은 01-master-kubelet 및 01-worker-kubelet입니다.

2. 노드당 최대 Pod의 현재 값을 확인하려면 다음을 실행합니다.

   $ oc describe node <node_name>

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

   $ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94

   Allocatable 스탠자에서 value: pods: <value>를 찾습니다.

   출력 예

   Allocatable:
    attachable-volumes-aws-ebs:  25
    cpu:                         3500m
    hugepages-1Gi:               0
    hugepages-2Mi:               0
    memory:                      15341844Ki
    pods:                        250

3. 작업자 노드에서 노드당 최대 Pod 수를 설정하려면 kubelet 구성이 포함된 사용자 정의 리소스 파일을 생성합니다.

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: set-max-pods
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: set-max-pods 1
     kubeletConfig:
       maxPods: 500 2

   1

   머신 구성 풀에서 레이블을 입력합니다.

   2

   kubelet 구성을 추가합니다. 이 예에서는 maxPods를 사용하여 노드당 최대 Pod를 설정합니다.

   참고

   kubelet이 API 서버와 통신하는 속도는 QPS(초당 쿼리) 및 버스트 값에 따라 달라집니다. 노드마다 실행되는 Pod 수가 제한된 경우 기본 값인 50(kubeAPIQPS인 경우) 및 100(kubeAPIBurst인 경우)이면 충분합니다. 노드에 CPU 및 메모리 리소스가 충분한 경우 kubelet QPS 및 버스트 속도를 업데이트하는 것이 좋습니다.

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: set-max-pods
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: set-max-pods
     kubeletConfig:
       maxPods: <pod_count>
       kubeAPIBurst: <burst_rate>
       kubeAPIQPS: <QPS>

   1. 라벨을 사용하여 작업자의 머신 구성 풀을 업데이트합니다.

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

   2. KubeletConfig 오브젝트를 생성합니다.

      $ oc create -f change-maxPods-cr.yaml

   3. KubeletConfig 오브젝트가 생성되었는지 확인합니다.

      $ oc get kubeletconfig

      출력 예

      NAME                AGE
      set-max-pods        15m

      클러스터의 작업자 노드 수에 따라 작업자 노드가 하나씩 재부팅될 때까지 기다립니다. 작업자 노드가 3개인 클러스터의 경우 약 10~15분이 걸릴 수 있습니다.

4. 변경 사항이 노드에 적용되었는지 확인합니다.

   1. 작업자 노드에서 maxPods 값이 변경되었는지 확인합니다.

      $ oc describe node <node_name>

   2. Allocatable 스탠자를 찾습니다.

       ...
      Allocatable:
        attachable-volumes-gce-pd:  127
        cpu:                        3500m
        ephemeral-storage:          123201474766
        hugepages-1Gi:              0
        hugepages-2Mi:              0
        memory:                     14225400Ki
        pods:                       500 1
       ...

      1

      이 예에서 pods 매개변수는 KubeletConfig 오브젝트에 설정한 값을 보고해야 합니다.

5. KubeletConfig 오브젝트에서 변경 사항을 확인합니다.

   $ oc get kubeletconfigs set-max-pods -o yaml

   다음 예와 같이 True 및 type:Success 상태가 표시되어야 합니다.

   spec:
     kubeletConfig:
       maxPods: 500
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: set-max-pods
   status:
     conditions:
     - lastTransitionTime: "2021-06-30T17:04:07Z"
       message: Success
       status: "True"
       type: Success

1. ContainerRuntimeConfig CR의 YAML 파일을 생성합니다.

   apiVersion: machineconfiguration.openshift.io/v1
   kind: ContainerRuntimeConfig
   metadata:
    name: overlay-size
   spec:
    machineConfigPoolSelector:
      matchLabels:
        pools.operator.machineconfiguration.openshift.io/worker: '' 1
    containerRuntimeConfig: 2
      pidsLimit: 2048
      logLevel: debug
      overlaySize: 8G
      logSizeMax: "-1"

   1

   수정할 머신 구성 풀의 레이블을 지정합니다.

   2

   필요에 따라 매개변수를 설정합니다.

2. ContainerRuntimeConfig CR을 생성합니다.

   $ oc create -f <file_name>.yaml

3. CR이 생성되었는지 확인합니다.

   $ oc get ContainerRuntimeConfig

   출력 예

   NAME           AGE
   overlay-size   3m19s

4. 새 containerruntime 머신 구성이 생성되었는지 확인합니다.

   $ oc get machineconfigs | grep containerrun

   출력 예

   99-worker-generated-containerruntime   2c9371fbb673b97a6fe8b1c52691999ed3a1bfc2  3.2.0  31s

5. 모두 준비 상태로 표시될 때까지 머신 구성 풀을 모니터링합니다.

   $ oc get mcp worker

   출력 예

   NAME    CONFIG               UPDATED  UPDATING  DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT  DEGRADEDMACHINECOUNT  AGE
   worker  rendered-worker-169  False    True      False     3             1                  1                    0                     9h

6. 설정이 CRI-O에 적용되었는지 확인하려면 다음을 실행합니다.

   1. 머신 구성 풀의 노드에 oc debug 세션을 열고 chroot /host를 실행합니다.

      $ oc debug node/<node_name>

      sh-4.4# chroot /host

   2. crio.conf 파일의 변경 사항을 확인합니다.

      sh-4.4# crio config | egrep 'log_level|pids_limit|log_size_max'

      출력 예

      pids_limit = 2048
      log_size_max = -1
      log_level = "debug"

   3. 'storage.conf' 파일의 변경 사항을 확인합니다.

      sh-4.4# head -n 7 /etc/containers/storage.conf

      출력 예

      [storage]
        driver = "overlay"
        runroot = "/var/run/containers/storage"
        graphroot = "/var/lib/containers/storage"
        [storage.options]
          additionalimagestores = []
          size = "8G"

절차

1. 구성 오브젝트를 생성합니다.

   $ oc apply -f overlaysize.yml

2. 새 CRI-O 구성을 작업자 노드에 적용하려면 작업자 머신 구성 풀을 편집합니다.

   $ oc edit machineconfigpool worker

3. ContainerRuntimeConfig CRD에서 설정한 matchLabels 이름을 기반으로 custom-crio 레이블을 추가합니다.

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfigPool
   metadata:
     creationTimestamp: "2020-07-09T15:46:34Z"
     generation: 3
     labels:
       custom-crio: overlay-size
       machineconfiguration.openshift.io/mco-built-in: ""

4. 변경 사항을 저장한 다음 머신 구성을 확인합니다.

   $ oc get machineconfigs

   새로운 99-worker-generated-containerruntime 및 rendered-worker-xyz 오브젝트가 생성됩니다.

   출력 예

   99-worker-generated-containerruntime  4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m42s
   rendered-worker-xyz                   4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m36s

5. 해당 오브젝트가 생성된 후 적용할 변경 사항이 있는지 머신 구성 풀을 모니터링합니다.

   $ oc get mcp worker

   작업자 노드는 UPDATING을 True로 표시하고 머신 수, 업데이트된 수 및 기타 세부 정보를 표시합니다.

   출력 예

   NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   worker rendered-worker-xyz False True False     3             2                   2                    0                      20h

   완료 후 작업자 노드는 UPDATING에서 다시 False로 변환되고 UPDATEDMACHINECOUNT의 수는 MACHINECOUNT의 ​​수와 일치합니다.

   출력 예

   NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   worker   rendered-worker-xyz   True      False      False      3         3            3             0           20h

   작업자 머신을 보면 새로운 8GB 최대 크기 구성이 모든 작업자에 적용되는 것을 확인할 수 있습니다.

   출력 예

   head -n 7 /etc/containers/storage.conf
   [storage]
     driver = "overlay"
     runroot = "/var/run/containers/storage"
     graphroot = "/var/lib/containers/storage"
     [storage.options]
       additionalimagestores = []
       size = "8G"

   컨테이너 내부를 보면 루트 파티션이 이제 8GB가 됩니다.

   출력 예

   ~ $ df -h
   Filesystem                Size      Used Available Use% Mounted on
   overlay                   8.0G      8.0K      8.0G   0% /

절차

1. 다음 명령을 실행하여 클러스터에 있는 컴퓨팅 머신 세트를 확인합니다.

   $ oc get machinesets -n openshift-machine-api

   컴퓨팅 머신 세트는 < clusterid>-worker-<aws-region-az> 형식으로 나열됩니다.

2. 다음 명령을 실행하여 클러스터에 있는 컴퓨팅 시스템을 확인합니다.

   $ oc get machine -n openshift-machine-api

3. 다음 명령을 실행하여 삭제할 컴퓨팅 머신에 주석을 설정합니다.

   $ oc annotate machine/<machine_name> -n openshift-machine-api machine.openshift.io/delete-machine="true"

4. 다음 명령 중 하나를 실행하여 컴퓨팅 머신 세트를 확장합니다.

   $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

   또는 다음을 수행합니다.

   $ oc edit machineset <machineset> -n openshift-machine-api

   작은 정보

   다음 YAML을 적용하여 컴퓨팅 머신 세트를 확장할 수 있습니다.

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     name: <machineset>
     namespace: openshift-machine-api
   spec:
     replicas: 2

   컴퓨팅 머신 세트를 확장 또는 축소할 수 있습니다. 새 머신을 사용할 수 있을 때 까지 몇 분 정도 소요됩니다.

   중요

   기본적으로 머신 컨트롤러는 성공할 때까지 머신이 지원하는 노드를 드레이닝하려고 합니다. Pod 중단 예산을 잘못 구성하는 등 일부 상황에서는 드레이닝 작업이 성공하지 못할 수 있습니다. 드레이닝 작업이 실패하면 머신 컨트롤러에서 머신 제거를 진행할 수 없습니다.

   특정 머신에서 machine.openshift.io/exclude-node-draining 에 주석을 달아 노드 드레이닝을 건너뛸 수 있습니다.

1. Scheduler Operator CR을 편집하여 기본 클러스터 수준 노드 선택기를 추가합니다.

   $ oc edit scheduler cluster

   노드 선택기를 사용하는 Scheduler Operator CR의 예

   apiVersion: config.openshift.io/v1
   kind: Scheduler
   metadata:
     name: cluster
   ...
   spec:
     defaultNodeSelector: type=user-node,region=east 1
     mastersSchedulable: false

   1

   적절한 <key>:<value> 쌍을 사용하여 노드 선택기를 추가합니다.

   변경 후 openshift-kube-apiserver 프로젝트의 pod가 재배포될 때까지 기다립니다. 이 작업은 몇 분 정도 걸릴 수 있습니다. 기본 클러스터 수준 노드 선택기는 Pod가 재배포된 후 적용됩니다.

2. 컴퓨팅 머신 세트를 사용하거나 노드를 직접 편집하여 노드에 라벨을 추가합니다.

   • 노드를 생성할 때 컴퓨팅 머신 세트에서 관리하는 노드에 라벨을 추가하려면 컴퓨팅 머신 세트를 사용합니다.

     1. 다음 명령을 실행하여 MachineSet 오브젝트에 라벨을 추가합니다.

        $ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api 1

        1

        각 라벨에 <key>/<value> 쌍을 추가합니다.

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

        $ oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api

        작은 정보

        또는 다음 YAML을 적용하여 컴퓨팅 머신 세트에 라벨을 추가할 수 있습니다.

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        metadata:
          name: <machineset>
          namespace: openshift-machine-api
        spec:
          template:
            spec:
              metadata:
                labels:
                  region: "east"
                  type: "user-node"

     2. oc edit 명령을 사용하여 라벨이 MachineSet 오브젝트에 추가되었는지 확인합니다.

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

        $ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

        MachineSet 오브젝트의 예

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
          ...
        spec:
          ...
          template:
            metadata:
          ...
            spec:
              metadata:
                labels:
                  region: east
                  type: user-node
          ...

     3. 0 으로 축소하고 노드를 확장하여 해당 컴퓨팅 머신 세트와 관련된 노드를 재배포합니다.

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

        $ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

        $ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

     4. 노드가 준비되고 사용 가능한 경우 oc get 명령을 사용하여 라벨이 노드에 추가되었는지 확인합니다.

        $ oc get nodes -l <key>=<value>

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

        $ oc get nodes -l type=user-node

        출력 예

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.25.0

   • 라벨을 노드에 직접 추가합니다.

     1. 노드의 Node 오브젝트를 편집합니다.

        $ oc label nodes <name> <key>=<value>

        예를 들어 노드에 라벨을 지정하려면 다음을 수행합니다.

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east

        작은 정보

        다음 YAML을 적용하여 노드에 라벨을 추가할 수 있습니다.

        kind: Node
        apiVersion: v1
        metadata:
          name: <node_name>
          labels:
            type: "user-node"
            region: "east"

     2. oc get 명령을 사용하여 노드에 라벨이 추가되었는지 확인합니다.

        $ oc get nodes -l <key>=<value>,<key>=<value>

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

        $ oc get nodes -l type=user-node,region=east

        출력 예

        NAME                                       STATUS   ROLES    AGE   VERSION
        ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.25.0

프로세스

1. 로컬 영역 서브넷에서 작동하는 에지 작업자 노드에 배포할 예제 애플리케이션에 대한 배포 리소스 YAML 파일을 생성합니다. 에지 작업자 노드의 테인트와 일치하는 올바른 톨러레이션을 지정해야 합니다.

   로컬 영역 서브넷에서 작동하는 에지 작업자 노드에 대해 구성된 배포 리소스의 예

   kind: Namespace
   apiVersion: v1
   metadata:
     name: <local_zone_application_namespace>
   ---
   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: <pvc_name>
     namespace: <local_zone_application_namespace>
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 10Gi
     storageClassName: gp2-csi 1
     volumeMode: Filesystem
   ---
   apiVersion: apps/v1
   kind: Deployment 2
   metadata:
     name: <local_zone_application> 3
     namespace: <local_zone_application_namespace> 4
   spec:
     selector:
       matchLabels:
         app: <local_zone_application>
     replicas: 1
     template:
       metadata:
         labels:
           app: <local_zone_application>
           zone-group: ${ZONE_GROUP_NAME} 5
       spec:
         securityContext:
           seccompProfile:
             type: RuntimeDefault
         nodeSelector: 6
           machine.openshift.io/zone-group: ${ZONE_GROUP_NAME}
         tolerations: 7
         - key: "node-role.kubernetes.io/edge"
           operator: "Equal"
           value: ""
           effect: "NoSchedule"
         containers:
           - image: openshift/origin-node
             command:
              - "/bin/socat"
             args:
               - TCP4-LISTEN:8080,reuseaddr,fork
               - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
             imagePullPolicy: Always
             name: echoserver
             ports:
               - containerPort: 8080
             volumeMounts:
               - mountPath: "/mnt/storage"
                 name: data
         volumes:
         - name: data
           persistentVolumeClaim:
             claimName: <pvc_name>

   1

   storageClassName: 로컬 영역 구성의 경우 gp2-csi 를 지정해야 합니다.

   2

   kind: 배포 리소스를 정의합니다.

   3

   Name: Local Zone 애플리케이션의 이름을 지정합니다. 예를 들면 local-zone-demo-app-nyc-1 입니다.

   4

   namespace: 사용자 워크로드를 실행할 AWS 로컬 영역의 네임스페이스를 정의합니다. 예: local-zone-app-nyc-1a.

   5

   zone-group: 영역이 속한 그룹을 정의합니다. 예를 들면 us-east-1-iah-1 입니다.

   6

   nodeSelector: 지정된 라벨과 일치하는 에지 작업자 노드를 대상으로 합니다.

   7

   tolerations: 로컬 영역 노드의 MachineSet 매니페스트에 정의된 테인트 와 일치하는 값을 설정합니다.

2. 노드에 대한 서비스 리소스 YAML 파일을 생성합니다. 이 리소스는 대상 에지 작업자 노드의 Pod를 로컬 영역 네트워크 내에서 실행되는 서비스에 노출합니다.

   로컬 영역 서브넷에서 작동하는 에지 작업자 노드에 대한 구성된 서비스 리소스의 예

   apiVersion: v1
   kind: Service 1
   metadata:
     name:  <local_zone_application>
     namespace: <local_zone_application_namespace>
   spec:
     ports:
       - port: 80
         targetPort: 8080
         protocol: TCP
     type: NodePort
     selector: 2
       app: <local_zone_application>

   1

   kind: 서비스 리소스를 정의합니다.

   2

   selector: 관리 Pod에 적용되는 레이블 유형을 지정합니다.

1. 중간 작업자 대기 시간 프로파일로 이동합니다.

   1. node.config 오브젝트를 편집합니다.

      $ oc edit nodes.config/cluster

   2. spec.workerLatencyProfile 추가: MediumUpdateAverageReaction:

      node.config 오브젝트의 예

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: MediumUpdateAverageReaction 1
      
       ...

      1

      중간 작업자 대기 시간 정책을 지정합니다.

      변경 사항이 적용되므로 각 작업자 노드에서 예약이 비활성화됩니다.

      모든 노드가 Ready 상태로 돌아 오면 다음 명령을 사용하여 Kubernetes 컨트롤러 관리자를 확인하여 적용되었는지 확인할 수 있습니다.

      $ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5

      출력 예

       ...
          - lastTransitionTime: "2022-07-11T19:47:10Z"
            reason: ProfileUpdated
            status: "False"
            type: WorkerLatencyProfileProgressing
          - lastTransitionTime: "2022-07-11T19:47:10Z" 1
            message: all static pod revision(s) have updated latency profile
            reason: ProfileUpdated
            status: "True"
            type: WorkerLatencyProfileComplete
          - lastTransitionTime: "2022-07-11T19:20:11Z"
            reason: AsExpected
            status: "False"
            type: WorkerLatencyProfileDegraded
          - lastTransitionTime: "2022-07-11T19:20:36Z"
            status: "False"
       ...

      1

      프로필이 적용되고 활성 상태가 되도록 지정합니다.

2. 선택 사항: 작업자 대기 시간이 짧은 프로필로 이동합니다.

   1. node.config 오브젝트를 편집합니다.

      $ oc edit nodes.config/cluster

   2. spec.workerLatencyProfile 값을 LowUpdateSlowReaction 으로 변경합니다.

      node.config 오브젝트의 예

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: LowUpdateSlowReaction 1
      
       ...

      1

      낮은 작업자 대기 시간 정책을 사용하도록 지정합니다.

      변경 사항이 적용되므로 각 작업자 노드에서 예약이 비활성화됩니다.

절차

1. 컴퓨팅 머신 세트 CR(사용자 정의 리소스) 샘플이 포함된 새 YAML 파일을 만들고 < file_name>.yaml 이라는 이름을 지정합니다.

   <clusterID> 및 <role> 매개 변수 값을 설정해야 합니다.

2. 선택 사항: 특정 필드에 설정할 값이 확실하지 않은 경우 클러스터에서 기존 컴퓨팅 머신 세트를 확인할 수 있습니다.

   1. 클러스터의 컴퓨팅 머신 세트를 나열하려면 다음 명령을 실행합니다.

      $ oc get machinesets -n openshift-machine-api

      출력 예

      NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
      agl030519-vplxk-worker-us-east-1a   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1b   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1c   1         1         1       1           55m
      agl030519-vplxk-worker-us-east-1d   0         0                             55m
      agl030519-vplxk-worker-us-east-1e   0         0                             55m
      agl030519-vplxk-worker-us-east-1f   0         0                             55m

   2. 특정 컴퓨팅 머신 세트 CR(사용자 정의 리소스)의 값을 보려면 다음 명령을 실행합니다.

      $ oc get machineset <machineset_name> \
        -n openshift-machine-api -o yaml

      출력 예

      apiVersion: machine.openshift.io/v1beta1
      kind: MachineSet
      metadata:
        labels:
          machine.openshift.io/cluster-api-cluster: <infrastructure_id> 1
        name: <infrastructure_id>-<role> 2
        namespace: openshift-machine-api
      spec:
        replicas: 1
        selector:
          matchLabels:
            machine.openshift.io/cluster-api-cluster: <infrastructure_id>
            machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
        template:
          metadata:
            labels:
              machine.openshift.io/cluster-api-cluster: <infrastructure_id>
              machine.openshift.io/cluster-api-machine-role: <role>
              machine.openshift.io/cluster-api-machine-type: <role>
              machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>
          spec:
            providerSpec: 3
              ...

      1

      클러스터 인프라 ID입니다.

      2

      기본 노드 레이블입니다.

      참고

      사용자 프로비저닝 인프라가 있는 클러스터의 경우 컴퓨팅 머신 세트는 작업자 및 인프라 유형 머신만 생성할 수 있습니다.

      3

      컴퓨팅 머신 세트 CR의 &lt ;providerSpec > 섹션에 있는 값은 플랫폼에 따라 다릅니다. CR의 &lt ;providerSpec > 매개변수에 대한 자세한 내용은 공급자의 샘플 컴퓨팅 머신 세트 CR 구성을 참조하십시오.

3. 다음 명령을 실행하여 MachineSet CR을 생성합니다.

   $ oc create -f <file_name>.yaml

절차

1. 애플리케이션 노드 역할을 수행할 작업자 노드에 레이블을 추가합니다.

   $ oc label node <node-name> node-role.kubernetes.io/app=""

2. 인프라 노드 역할을 수행할 작업자 노드에 레이블을 추가합니다.

   $ oc label node <node-name> node-role.kubernetes.io/infra=""

3. 해당 노드에 infra 역할 및 app 역할이 있는지 확인합니다.

   $ oc get nodes

4. 기본 클러스터 수준 노드 선택기를 생성합니다. 기본 노드 선택기는 모든 네임스페이스에서 생성된 Pod에 적용됩니다. 이렇게 하면 Pod의 기존 노드 선택기와 교차점이 생성되어 Pod의 선택기가 추가로 제한됩니다.

   중요

   기본 노드 선택기 키가 Pod 라벨 키와 충돌하는 경우 기본 노드 선택기가 적용되지 않습니다.

   그러나 Pod를 예약할 수 없게 만들 수 있는 기본 노드 선택기를 설정하지 마십시오. 예를 들어 Pod의 라벨이 node-role.kubernetes.io/master=""와 같은 다른 노드 역할로 설정된 경우 기본 노드 선택기를 node-role.kubernetes.io/infra=""와 같은 특정 노드 역할로 설정하면 Pod를 예약할 수 없게 될 수 있습니다. 따라서 기본 노드 선택기를 특정 노드 역할로 설정할 때 주의해야 합니다.

   또는 프로젝트 노드 선택기를 사용하여 클러스터 수준 노드 선택기 키 충돌을 방지할 수 있습니다.

   1. Scheduler 오브젝트를 편집합니다.

      $ oc edit scheduler cluster

   2. 적절한 노드 선택기를 사용하여 defaultNodeSelector 필드를 추가합니다.

      apiVersion: config.openshift.io/v1
      kind: Scheduler
      metadata:
        name: cluster
      ...
      spec:
        defaultNodeSelector: topology.kubernetes.io/region=us-east-1 1
      ...

      1

      이 예제 노드 선택기는 기본적으로 us-east-1 리전의 노드에 Pod를 배포합니다.

   3. 파일을 저장하여 변경 사항을 적용합니다.

절차

1. 특정 레이블이 있는 인프라 노드로 할당하려는 노드에 레이블을 추가합니다.

   $ oc label node <node_name> <label>

   $ oc label node ci-ln-n8mqwr2-f76d1-xscn2-worker-c-6fmtx node-role.kubernetes.io/infra=

2. 작업자 역할과 사용자 지정 역할을 모두 포함하는 머신 구성 풀을 머신 구성 선택기로 생성합니다.

   $ cat infra.mcp.yaml

   출력 예

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

   1

   작업자 역할 및 사용자 지정 역할을 추가합니다.

   2

   노드에 추가한 레이블을 nodeSelector로 추가합니다.

   참고

   사용자 지정 머신 구성 풀은 작업자 풀의 머신 구성을 상속합니다. 사용자 지정 풀은 작업자 풀을 대상으로 하는 머신 구성을 사용하지만 사용자 지정 풀을 대상으로 하는 변경 사항만 배포할 수 있는 기능을 추가합니다. 사용자 지정 풀은 작업자 풀에서 리소스를 상속하므로 작업자 풀을 변경하면 사용자 지정 풀에도 영향을 줍니다.

3. YAML 파일이 있으면 머신 구성 풀을 생성할 수 있습니다.

   $ oc create -f infra.mcp.yaml

4. 머신 구성을 확인하고 인프라 구성이 성공적으로 렌더링되었는지 확인합니다.

   $ oc get machineconfig

   출력 예

   NAME                                                        GENERATEDBYCONTROLLER                      IGNITIONVERSION   CREATED
   00-master                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   00-worker                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-master-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-master-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-worker-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   01-worker-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   99-master-1ae2a1e0-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   99-master-ssh                                                                                          3.2.0             31d
   99-worker-1ae64748-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             31d
   99-worker-ssh                                                                                          3.2.0             31d
   rendered-infra-4e48906dca84ee702959c71a53ee80e7             365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             23m
   rendered-master-072d4b2da7f88162636902b074e9e28e            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-master-3e88ec72aed3886dec061df60d16d1af            02c07496ba0417b3e12b78fb32baf6293d314f79   3.2.0             31d
   rendered-master-419bee7de96134963a15fdf9dd473b25            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             17d
   rendered-master-53f5c91c7661708adce18739cc0f40fb            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             13d
   rendered-master-a6a357ec18e5bce7f5ac426fc7c5ffcd            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             7d3h
   rendered-master-dc7f874ec77fc4b969674204332da037            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-worker-1a75960c52ad18ff5dfa6674eb7e533d            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-worker-2640531be11ba43c61d72e82dc634ce6            5b6fb8349a29735e48446d435962dec4547d3090   3.2.0             31d
   rendered-worker-4e48906dca84ee702959c71a53ee80e7            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             7d3h
   rendered-worker-4f110718fe88e5f349987854a1147755            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             17d
   rendered-worker-afc758e194d6188677eb837842d3b379            02c07496ba0417b3e12b78fb32baf6293d314f79   3.2.0             31d
   rendered-worker-daa08cc1e8f5fcdeba24de60cd955cc3            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   3.2.0             13d

   rendered-infra-* 접두사가 있는 새 머신 구성이 표시되어야 합니다.

5. 선택 사항: 사용자 지정 풀에 변경 사항을 배포하려면 infra와 같은 사용자 지정 풀 이름을 레이블로 사용하는 머신 구성을 생성합니다. 필수 사항은 아니며 지침 용도로만 표시됩니다. 이렇게 하면 인프라 노드에 고유한 사용자 지정 구성을 적용할 수 있습니다.

   참고

   새 머신 구성 풀을 생성한 후 MCO는 해당 풀에 대해 새로 렌더링된 구성과 해당 풀의 관련 노드를 다시 부팅하여 새 구성을 적용합니다.

   1. 머신 구성을 생성합니다.

      $ cat infra.mc.yaml

      출력 예

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        name: 51-infra
        labels:
          machineconfiguration.openshift.io/role: infra 1
      spec:
        config:
          ignition:
            version: 3.2.0
          storage:
            files:
            - path: /etc/infratest
              mode: 0644
              contents:
                source: data:,infra

      1

      노드에 추가한 레이블을 nodeSelector로 추가합니다.

   2. 머신 구성을 인프라 레이블 노드에 적용합니다.

      $ oc create -f infra.mc.yaml

6. 새 머신 구성 풀을 사용할 수 있는지 확인합니다.

   $ oc get mcp

   출력 예

   NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   infra    rendered-infra-60e35c2e99f42d976e084fa94da4d0fc    True      False      False      1              1                   1                     0                      4m20s
   master   rendered-master-9360fdb895d4c131c7c4bebbae099c90   True      False      False      3              3                   3                     0                      91m
   worker   rendered-worker-60e35c2e99f42d976e084fa94da4d0fc   True      False      False      2              2                   2                     0                      91m

   이 예에서는 작업자 노드가 인프라 노드로 변경되었습니다.

절차

1. 인프라 노드에 테인트를 추가하여 사용자 워크로드를 예약하지 않도록합니다.

   1. 노드에 테인트가 있는지 확인합니다.

      $ oc describe nodes <node_name>

      샘플 출력

      oc describe node ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
      Name:               ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l
      Roles:              worker
       ...
      Taints:             node-role.kubernetes.io/infra:NoSchedule
       ...

      이 예에서는 노드에 테인트가 있음을 보여줍니다. 다음 단계에서 Pod에 허용 오차를 추가할 수 있습니다.

   2. 사용자 워크로드를 예약하지 않도록 테인트를 구성하지 않은 경우 다음을 수행합니다.

      $ oc adm taint nodes <node_name> <key>=<value>:<effect>

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

      $ oc adm taint nodes node1 node-role.kubernetes.io/infra=reserved:NoExecute

      작은 정보

      다음 YAML을 적용하여 테인트를 추가할 수 있습니다.

      kind: Node
      apiVersion: v1
      metadata:
        name: <node_name>
        labels:
          ...
      spec:
        taints:
          - key: node-role.kubernetes.io/infra
            effect: NoExecute
            value: reserved
        ...

      이 예에서는 키node-role.kubernetes.io/infra 및 taint 효과 NoSchedule이 있는 node1에 taint를 배치합니다. NoSchedule 효과가 있는 노드는 taint를 허용하는 pod만 예약하지만 기존 pod는 노드에서 예약된 상태를 유지할 수 있습니다.

      참고

      descheduler를 사용하면 노드 taint를 위반하는 pod가 클러스터에서 제거될 수 있습니다.

2. 라우터, 레지스트리 및 모니터링 워크로드와 같이 인프라 노드에서 예약하려는 pod 구성에 대한 허용 오차를 추가합니다. 다음 코드를 Pod 개체 사양에 추가합니다.

   tolerations:
     - effect: NoExecute 1
       key: node-role.kubernetes.io/infra 2
       operator: Exists 3
       value: reserved 4

   1

   노드에 추가한 효과를 지정합니다.

   2

   노드에 추가한 키를 지정합니다.

   3

   노드에 elasticsearch 키가 있는 taint를 요구하도록 Exists Operator를 지정합니다.

   4

   노드에 추가한 키-값 쌍 테인트의 값을 지정합니다.

   이 허용 오차는 oc adm taint 명령으로 생성된 taint와 일치합니다. 이 허용 오차가 있는 pod를 인프라 노드에 예약할 수 있습니다.

   참고

   OLM을 통해 설치된 Operator의 pod를 인프라 노드로 이동할 수는 없습니다. Operator pod를 이동하는 기능은 각 Operator의 구성에 따라 다릅니다.

3. 스케줄러를 사용하여 pod를 인프라 노드에 예약합니다. 자세한 내용은 노드에서 pod 배치 제어에 대한 설명서를 참조하십시오.

프로세스

1. 라우터 Operator의 IngressController 사용자 정의 리소스를 표시합니다.

   $ oc get ingresscontroller default -n openshift-ingress-operator -o yaml

   명령 출력은 다음 예제와 유사합니다.

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     creationTimestamp: 2019-04-18T12:35:39Z
     finalizers:
     - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller
     generation: 1
     name: default
     namespace: openshift-ingress-operator
     resourceVersion: "11341"
     selfLink: /apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default
     uid: 79509e05-61d6-11e9-bc55-02ce4781844a
   spec: {}
   status:
     availableReplicas: 2
     conditions:
     - lastTransitionTime: 2019-04-18T12:36:15Z
       status: "True"
       type: Available
     domain: apps.<cluster>.example.com
     endpointPublishingStrategy:
       type: LoadBalancerService
     selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller=default

2. ingresscontroller 리소스를 편집하고 infra 레이블을 사용하도록 nodeSelector를 변경합니다.

   $ oc edit ingresscontroller default -n openshift-ingress-operator

     spec:
       nodePlacement:
         nodeSelector: 1
           matchLabels:
             node-role.kubernetes.io/infra: ""
         tolerations:
         - effect: NoSchedule
           key: node-role.kubernetes.io/infra
           value: reserved
         - effect: NoExecute
           key: node-role.kubernetes.io/infra
           value: reserved

   1

   적절한 값이 설정된 nodeSelector 매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로 nodeSelector를 사용하거나 노드에 지정된 값에 따라 <key>: <value> 쌍을 사용할 수 있습니다. 인프라 노드에 테인트를 추가한 경우 일치하는 허용 오차도 추가합니다.

3. 라우터 pod가 infra 노드에서 실행되고 있는지 확인합니다.

   1. 라우터 pod 목록을 표시하고 실행중인 pod의 노드 이름을 기록해 둡니다.

      $ oc get pod -n openshift-ingress -o wide

      출력 예

      NAME                              READY     STATUS        RESTARTS   AGE       IP           NODE                           NOMINATED NODE   READINESS GATES
      router-default-86798b4b5d-bdlvd   1/1      Running       0          28s       10.130.2.4   ip-10-0-217-226.ec2.internal   <none>           <none>
      router-default-955d875f4-255g8    0/1      Terminating   0          19h       10.129.2.4   ip-10-0-148-172.ec2.internal   <none>           <none>

      이 예에서 실행중인 pod는 ip-10-0-217-226.ec2.internal 노드에 있습니다.

   2. 실행중인 pod의 노드 상태를 표시합니다.

      $ oc get node <node_name> 1

      1

      pod 목록에서 얻은 <node_name>을 지정합니다.

      출력 예

      NAME                          STATUS  ROLES         AGE   VERSION
      ip-10-0-217-226.ec2.internal  Ready   infra,worker  17h   v1.25.0

      역할 목록에 infra가 포함되어 있으므로 pod가 올바른 노드에서 실행됩니다.

프로세스

1. config/instance 개체를 표시합니다.

   $ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml

   출력 예

   apiVersion: imageregistry.operator.openshift.io/v1
   kind: Config
   metadata:
     creationTimestamp: 2019-02-05T13:52:05Z
     finalizers:
     - imageregistry.operator.openshift.io/finalizer
     generation: 1
     name: cluster
     resourceVersion: "56174"
     selfLink: /apis/imageregistry.operator.openshift.io/v1/configs/cluster
     uid: 36fd3724-294d-11e9-a524-12ffeee2931b
   spec:
     httpSecret: d9a012ccd117b1e6616ceccb2c3bb66a5fed1b5e481623
     logging: 2
     managementState: Managed
     proxy: {}
     replicas: 1
     requests:
       read: {}
       write: {}
     storage:
       s3:
         bucket: image-registry-us-east-1-c92e88cad85b48ec8b312344dff03c82-392c
         region: us-east-1
   status:
   ...

2. config/instance 개체를 편집합니다.

   $ oc edit configs.imageregistry.operator.openshift.io/cluster

   spec:
     affinity:
       podAntiAffinity:
         preferredDuringSchedulingIgnoredDuringExecution:
         - podAffinityTerm:
             namespaces:
             - openshift-image-registry
             topologyKey: kubernetes.io/hostname
           weight: 100
     logLevel: Normal
     managementState: Managed
     nodeSelector: 1
       node-role.kubernetes.io/infra: ""
     tolerations:
     - effect: NoSchedule
       key: node-role.kubernetes.io/infra
       value: reserved
     - effect: NoExecute
       key: node-role.kubernetes.io/infra
       value: reserved

   1

   적절한 값이 설정된 nodeSelector 매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로 nodeSelector를 사용하거나 노드에 지정된 값에 따라 <key>: <value> 쌍을 사용할 수 있습니다. 인프라 노드에 테인트를 추가한 경우 일치하는 톨러레이션도 추가합니다.

3. 레지스트리 pod가 인프라 노드로 이동되었는지 검증합니다.

   1. 다음 명령을 실행하여 레지스트리 pod가 있는 노드를 식별합니다.

      $ oc get pods -o wide -n openshift-image-registry

   2. 노드에 지정된 레이블이 있는지 확인합니다.

      $ oc describe node <node_name>

      명령 출력을 확인하고 node-role.kubernetes.io/infra가 LABELS 목록에 있는지 확인합니다.

절차

1. cluster-monitoring-config 구성 맵을 편집하고 infra 레이블을 사용하도록 nodeSelector 를 변경합니다.

   $ oc edit configmap cluster-monitoring-config -n openshift-monitoring

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |+
       alertmanagerMain:
         nodeSelector: 1
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       prometheusK8s:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       prometheusOperator:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       k8sPrometheusAdapter:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       kubeStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       telemeterClient:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       openshiftStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       thanosQuerier:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute

   1

   적절한 값이 설정된 nodeSelector 매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로 nodeSelector를 사용하거나 노드에 지정된 값에 따라 <key>: <value> 쌍을 사용할 수 있습니다. 인프라 노드에 테인트를 추가한 경우 일치하는 톨러레이션도 추가합니다.

2. 모니터링 pod가 새 머신으로 이동하는 것을 확인합니다.

   $ watch 'oc get pod -n openshift-monitoring -o wide'

3. 구성 요소가 infra 노드로 이동하지 않은 경우 이 구성 요소가 있는 pod를 제거합니다.

   $ oc delete pod -n openshift-monitoring <pod>

   삭제된 pod의 구성 요소가 infra 노드에 다시 생성됩니다.

프로세스

1. openshift-logging 프로젝트에서 ClusterLogging 사용자 정의 리소스(CR)를 편집합니다.

   $ oc edit ClusterLogging instance

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   
   ...
   
   spec:
     collection:
       logs:
         fluentd:
           resources: null
         type: fluentd
     logStore:
       elasticsearch:
         nodeCount: 3
         nodeSelector: 1
           node-role.kubernetes.io/infra: ''
         tolerations:
         - effect: NoSchedule
           key: node-role.kubernetes.io/infra
           value: reserved
         - effect: NoExecute
           key: node-role.kubernetes.io/infra
           value: reserved
         redundancyPolicy: SingleRedundancy
         resources:
           limits:
             cpu: 500m
             memory: 16Gi
           requests:
             cpu: 500m
             memory: 16Gi
         storage: {}
       type: elasticsearch
     managementState: Managed
     visualization:
       kibana:
         nodeSelector: 2
           node-role.kubernetes.io/infra: ''
         tolerations:
         - effect: NoSchedule
           key: node-role.kubernetes.io/infra
           value: reserved
         - effect: NoExecute
           key: node-role.kubernetes.io/infra
           value: reserved
         proxy:
           resources: null
         replicas: 1
         resources: null
       type: kibana
   
   ...

   1 2

   적절한 값이 설정된 nodeSelector 매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로 nodeSelector를 사용하거나 노드에 지정된 값에 따라 <key>: <value> 쌍을 사용할 수 있습니다. 인프라 노드에 테인트를 추가한 경우 일치하는 톨러레이션도 추가합니다.

절차

1. 사용자 정의된 리소스 정의가 포함된 ClusterAutoscaler리소스의 YAML 파일을 만듭니다.

2. 클러스터에서 리소스를 생성합니다.

   $ oc create -f <filename>.yaml 1

   1

   <filename>은 사용자 정의 리소스 파일의 이름입니다.

절차

1. 사용자 정의된 리소스 정의가 포함된 MachineAutoscaler 리소스의 YAML 파일을 생성합니다.

2. 클러스터에서 리소스를 생성합니다.

   $ oc create -f <filename>.yaml 1

   1

   <filename>은 사용자 정의 리소스 파일의 이름입니다.

1. OpenShift Container Platform 웹 콘솔에서 관리 → 사용자 지정 리소스 정의 페이지로 전환합니다.
2. 사용자 지정 리소스 정의 페이지에서 FeatureGate를 클릭합니다.
3. 사용자 정의 리소스 정의 세부 정보 페이지에서 인스턴스 탭을 클릭합니다.
4. 클러스터 기능 게이트를 클릭한 다음 YAML 탭을 클릭합니다.

5. 특정 기능 세트를 추가하려면 클러스터 인스턴스를 편집합니다.

   주의

   클러스터에서 TechPreviewNoUpgrade 기능 세트를 활성화하면 취소할 수 없으며 마이너 버전 업데이트를 방지할 수 없습니다. 프로덕션 클러스터에서 이 기능 세트를 활성화해서는 안 됩니다.

   FeatureGate 사용자 지정 리소스 샘플

   apiVersion: config.openshift.io/v1
   kind: FeatureGate
   metadata:
     name: cluster 1
   ....
   
   spec:
     featureSet: TechPreviewNoUpgrade 2

   1

   FeatureGate CR의 이름은 cluster이어야 합니다.

   2

   활성화할 기능 세트를 추가합니다.

   • TechPreviewNoUpgrade를 사용하면 특정 기술 프리뷰 기능을 사용할 수 있습니다.

   변경 사항을 저장하면 새 머신 구성이 생성되면 머신 구성 풀이 업데이트되고 변경 사항이 적용되는 동안 각 노드에 대한 스케줄링이 비활성화됩니다.

1. 웹 콘솔의 관리자 화면에서 컴퓨팅 → 노드로 이동합니다.
2. 노드를 선택합니다.
3. 노드 세부 정보 페이지에서 터미널 을 클릭합니다.

4. 터미널 창에서 root 디렉토리를 /host:로 변경합니다.

   sh-4.2# chroot /host

5. kubelet.conf 파일을 확인합니다.

   sh-4.2# cat /etc/kubernetes/kubelet.conf

   샘플 출력

    ...
   featureGates:
     InsightsOperatorPullingSCA: true,
     LegacyNodeRoleBehavior: false
    ...

   true 로 나열된 기능은 클러스터에서 활성화되어 있습니다.

   참고

   나열된 기능은 OpenShift Container Platform 버전에 따라 다릅니다.

1. cluster라는 FeatureGate CR을 편집합니다.

   $ oc edit featuregate cluster

   주의

   클러스터에서 TechPreviewNoUpgrade 기능 세트를 활성화하면 취소할 수 없으며 마이너 버전 업데이트를 방지할 수 없습니다. 프로덕션 클러스터에서 이 기능 세트를 활성화해서는 안 됩니다.

   FeatureGate 사용자 지정 리소스 샘플

   apiVersion: config.openshift.io/v1
   kind: FeatureGate
   metadata:
     name: cluster 1
   spec:
     featureSet: TechPreviewNoUpgrade 2

   1

   FeatureGate CR의 이름은 cluster이어야 합니다.

   2

   활성화할 기능 세트를 추가합니다.

   • TechPreviewNoUpgrade를 사용하면 특정 기술 프리뷰 기능을 사용할 수 있습니다.

   변경 사항을 저장하면 새 머신 구성이 생성되면 머신 구성 풀이 업데이트되고 변경 사항이 적용되는 동안 각 노드에 대한 스케줄링이 비활성화됩니다.

1. 웹 콘솔의 관리자 화면에서 컴퓨팅 → 노드로 이동합니다.
2. 노드를 선택합니다.
3. 노드 세부 정보 페이지에서 터미널 을 클릭합니다.

4. 터미널 창에서 root 디렉토리를 /host:로 변경합니다.

   sh-4.2# chroot /host

5. kubelet.conf 파일을 확인합니다.

   sh-4.2# cat /etc/kubernetes/kubelet.conf

   샘플 출력

    ...
   featureGates:
     InsightsOperatorPullingSCA: true,
     LegacyNodeRoleBehavior: false
    ...

   true 로 나열된 기능은 클러스터에서 활성화되어 있습니다.

   참고

   나열된 기능은 OpenShift Container Platform 버전에 따라 다릅니다.

프로세스

1. APIServer 오브젝트를 수정합니다.

   $ oc edit apiserver

2. 암호화 필드 유형을 aescbc로 설정합니다.

   spec:
     encryption:
       type: aescbc 1

   1

   aescbc 유형은 PKCS# 7 패딩 및 32바이트 키가 있는 AES-CBC가 암호화를 수행하는 데 사용됨을 나타냅니다.

3. 파일을 저장하여 변경 사항을 적용합니다.

   암호화 프로세스가 시작됩니다. 클러스터 크기에 따라 이 프로세스를 완료하는 데 20분 이상 걸릴 수 있습니다.

4. etcd 암호화에 성공했는지 확인합니다.

   1. OpenShift API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스가 성공적으로 암호화되었는지 확인합니다.

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      암호화에 성공하면 출력에 EncryptionCompleted가 표시됩니다.

      EncryptionCompleted
      All resources encrypted: routes.route.openshift.io

      출력에 EncryptionInProgress가 표시되는 경우에도 암호화는 계속 진행 중입니다. 몇 분 기다린 후 다시 시도합니다.

   2. 쿠버네티스 API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스가 성공적으로 암호화되었는지 확인합니다.

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      암호화에 성공하면 출력에 EncryptionCompleted가 표시됩니다.

      EncryptionCompleted
      All resources encrypted: secrets, configmaps

      출력에 EncryptionInProgress가 표시되는 경우에도 암호화는 계속 진행 중입니다. 몇 분 기다린 후 다시 시도합니다.

   3. OpenShift OAuth API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스가 성공적으로 암호화되었는지 확인합니다.

      $ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      암호화에 성공하면 출력에 EncryptionCompleted가 표시됩니다.

      EncryptionCompleted
      All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io

      출력에 EncryptionInProgress가 표시되는 경우에도 암호화는 계속 진행 중입니다. 몇 분 기다린 후 다시 시도합니다.

프로세스

1. APIServer 오브젝트를 수정합니다.

   $ oc edit apiserver

2. 암호화 필드 유형을 identity로 설정합니다.

   spec:
     encryption:
       type: identity 1

   1

   identity 유형이 기본값이며, 이는 암호화가 수행되지 않음을 의미합니다.

3. 파일을 저장하여 변경 사항을 적용합니다.

   암호 해독 프로세스가 시작됩니다. 클러스터 크기에 따라 이 프로세스를 완료하는 데 20분 이상 걸릴 수 있습니다.

4. etcd 암호 해독에 성공했는지 확인합니다.

   1. OpenShift API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스의 암호가 성공적으로 해독되었는지 확인합니다.

      $ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      암호 해독에 성공하면 출력에 DecryptionCompleted가 표시됩니다.

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      출력에 DecryptionInProgress가 표시되면 암호 해독이 여전히 진행 중임을 나타냅니다. 몇 분 기다린 후 다시 시도합니다.

   2. 쿠버네티스 API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스의 암호가 성공적으로 해독되었는지 확인합니다.

      $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      암호 해독에 성공하면 출력에 DecryptionCompleted가 표시됩니다.

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      출력에 DecryptionInProgress가 표시되면 암호 해독이 여전히 진행 중임을 나타냅니다. 몇 분 기다린 후 다시 시도합니다.

   3. OpenShift API 서버의 Encrypted 상태 조건을 검토하여 해당 리소스의 암호가 성공적으로 해독되었는지 확인합니다.

      $ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'

      암호 해독에 성공하면 출력에 DecryptionCompleted가 표시됩니다.

      DecryptionCompleted
      Encryption mode set to identity and everything is decrypted

      출력에 DecryptionInProgress가 표시되면 암호 해독이 여전히 진행 중임을 나타냅니다. 몇 분 기다린 후 다시 시도합니다.

절차

1. 컨트롤 플레인 노드의 디버그 세션을 시작합니다.

   $ oc debug node/<node_name>

2. 루트 디렉토리를 /host 로 변경합니다.

   sh-4.2# chroot /host

3. 클러스터 전체의 프록시가 활성화되어 있는 경우 NO_PROXY, HTTP_PROXY 및 https_proxy 환경 변수를 내보내고 있는지 확인합니다.

4. cluster-backup.sh 스크립트를 실행하고 백업을 저장할 위치를 입력합니다.

   작은 정보

   cluster-backup.sh 스크립트는 etcd Cluster Operator의 구성 요소로 유지 관리되며 etcdctl snapshot save 명령 관련 래퍼입니다.

   sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup

   스크립트 출력 예

   found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6
   found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7
   found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6
   found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3
   ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1
   etcdctl version: 3.4.14
   API version: 3.4
   {"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"}
   {"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"}
   {"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"}
   {"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"}
   {"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459}
   {"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"}
   Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db
   {"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336}
   snapshot db and kube resources are successfully saved to /home/core/assets/backup

   이 예제에서는 컨트롤 플레인 호스트의 /home/core/assets/backup/ 디렉토리에 두 개의 파일이 생성됩니다.

   • snapshot_<datetimestamp>.db:이 파일은 etcd 스냅샷입니다. cluster-backup.sh 스크립트는 유효성을 확인합니다.

   • static_kuberesources_<datetimestamp>.tar.gz: 이 파일에는 정적 pod 리소스가 포함되어 있습니다. etcd 암호화가 활성화되어 있는 경우 etcd 스냅 샷의 암호화 키도 포함됩니다.

     참고

     etcd 암호화가 활성화되어 있는 경우 보안상의 이유로 이 두 번째 파일을 etcd 스냅 샷과 별도로 저장하는 것이 좋습니다. 그러나 이 파일은 etcd 스냅 샷에서 복원하는데 필요합니다.

     etcd 암호화는 키가 아닌 값만 암호화합니다. 즉, 리소스 유형, 네임 스페이스 및 개체 이름은 암호화되지 않습니다.

절차

1. 복구 호스트로 사용할 컨트롤 플레인 호스트를 선택합니다. 이는 복구 작업을 실행할 호스트입니다.

2. 복구 호스트를 포함하여 각 컨트롤 플레인 노드에 SSH 연결을 설정합니다.

   복구 프로세스가 시작된 후에는 Kubernetes API 서버에 액세스할 수 없으므로 컨트롤 플레인 노드에 액세스할 수 없습니다. 따라서 다른 터미널에서 각 컨트롤 플레인 호스트에 대한 SSH 연결을 설정하는 것이 좋습니다.

   중요

   이 단계를 완료하지 않으면 컨트롤 플레인 호스트에 액세스하여 복구 프로세스를 완료할 수 없으며 이 상태에서 클러스터를 복구할 수 없습니다.

3. etcd 백업 디렉토리를 복구 컨트롤 플레인 호스트에 복사합니다.

   이 단계에서는 etcd 스냅샷 및 정적 pod의 리소스가 포함된 backup 디렉터리를 복구 컨트롤 플레인 호스트의 /home/core/ 디렉터리에 복사하는 것을 전제로하고 있습니다.

4. 다른 컨트롤 플레인 노드에서 고정 Pod를 중지합니다.

   참고

   복구 호스트에서 pod를 수동으로 중지할 필요는 없습니다. 복구 스크립트는 복구 호스트에서 pod를 중지합니다.

   1. 복구 호스트가 아닌 컨트롤 플레인 호스트에 액세스합니다.

   2. kubelet 매니페스트 디렉토리에서 기존 etcd pod 파일을 이동합니다.

      $ sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp

   3. etcd pod가 중지되었는지 확인합니다.

      $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

      이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.

   4. kubelet 매니페스트 디렉토리에서 기존 Kubernetes API 서버 pod 파일을 이동합니다.

      $ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp

   5. Kubernetes API 서버 pod가 중지되었는지 확인합니다.

      $ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"

      이 명령의 출력은 비어 있어야합니다. 비어 있지 않은 경우 몇 분 기다렸다가 다시 확인하십시오.

   6. etcd 데이터 디렉토리를 다른 위치로 이동합니다.

      $ sudo mv /var/lib/etcd/ /tmp

   7. 복구 호스트가 아닌 다른 컨트롤 플레인 호스트에서 이 단계를 반복합니다.
5. 복구 컨트롤 플레인 호스트에 액세스합니다.

6. 클러스터 전체의 프록시가 활성화되어 있는 경우 NO_PROXY, HTTP_PROXY 및 https_proxy 환경 변수를 내보내고 있는지 확인합니다.

   작은 정보

   oc get proxy cluster -o yaml의 출력을 확인하여 프록시가 사용 가능한지 여부를 확인할 수 있습니다. httpProxy, httpsProxy 및 noProxy 필드에 값이 설정되어 있으면 프록시가 사용됩니다.

7. 복구 컨트롤 플레인 호스트에서 복원 스크립트를 실행하고 etcd 백업 디렉터리에 경로를 전달합니다.

   $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/backup

   스크립트 출력 예

   ...stopping kube-scheduler-pod.yaml
   ...stopping kube-controller-manager-pod.yaml
   ...stopping etcd-pod.yaml
   ...stopping kube-apiserver-pod.yaml
   Waiting for container etcd to stop
   .complete
   Waiting for container etcdctl to stop
   .............................complete
   Waiting for container etcd-metrics to stop
   complete
   Waiting for container kube-controller-manager to stop
   complete
   Waiting for container kube-apiserver to stop
   ..........................................................................................complete
   Waiting for container kube-scheduler to stop
   complete
   Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup
   starting restore-etcd static pod
   starting kube-apiserver-pod.yaml
   static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml
   starting kube-controller-manager-pod.yaml
   static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml
   starting kube-scheduler-pod.yaml
   static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml

   참고

   마지막 etcd 백업 후 노드 인증서가 업데이트된 경우 복원 프로세스를 통해 노드가 NotReady 상태를 입력할 수 있습니다.

8. 노드가 Ready 상태에 있는지 확인합니다.

   1. 다음 명령을 실행합니다.

      $ oc get nodes -w

      샘플 출력

      NAME                STATUS  ROLES          AGE     VERSION
      host-172-25-75-28   Ready   master         3d20h   v1.25.0
      host-172-25-75-38   Ready   infra,worker   3d20h   v1.25.0
      host-172-25-75-40   Ready   master         3d20h   v1.25.0
      host-172-25-75-65   Ready   master         3d20h   v1.25.0
      host-172-25-75-74   Ready   infra,worker   3d20h   v1.25.0
      host-172-25-75-79   Ready   worker         3d20h   v1.25.0
      host-172-25-75-86   Ready   worker         3d20h   v1.25.0
      host-172-25-75-98   Ready   infra,worker   3d20h   v1.25.0

      모든 노드가 상태를 보고하는 데 몇 분이 걸릴 수 있습니다.

   2. NotReady 상태인 노드가 있는 경우 노드에 로그인하고 각 노드의 /var/lib/kubelet/pki 디렉터리에서 모든 PEM 파일을 삭제합니다. 노드에 SSH를 사용하거나 웹 콘솔에서 터미널 창을 사용할 수 있습니다.

      $  ssh -i <ssh-key-path> core@<master-hostname>

      pki 디렉터리 샘플

      sh-4.4# pwd
      /var/lib/kubelet/pki
      sh-4.4# ls
      kubelet-client-2022-04-28-11-24-09.pem  kubelet-server-2022-04-28-11-24-15.pem
      kubelet-client-current.pem              kubelet-server-current.pem

9. 모든 컨트롤 플레인 호스트에서 kubelet 서비스를 다시 시작합니다.

   1. 복구 호스트에서 다음 명령을 실행합니다.

      $ sudo systemctl restart kubelet.service

   2. 다른 모든 컨트롤 플레인 호스트에서 이 단계를 반복합니다.

10. 보류 중인 CSR을 승인합니다.

    참고

    3개의 스케줄링 가능한 컨트롤 플레인 노드로 구성된 단일 노드 클러스터 또는 클러스터와 같이 작업자 노드가 없는 클러스터에는 승인할 보류 중인 CSR이 없습니다. 이러한 시나리오에서는 이 단계를 건너뛸 수 있습니다.

    1. 현재 CSR의 목록을 가져옵니다.

       $ oc get csr

       출력 예

       NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
       csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 1
       csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 2
       csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 3
       csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 4
       ...

       1 1 2

       보류 중인 kubelet 서비스 CSR(사용자 프로비저닝 설치용)입니다.

       3 4

       보류 중인 node-bootstrapper CSR입니다.

    2. CSR의 세부 사항을 검토하여 CSR이 유효한지 확인합니다.

       $ oc describe csr <csr_name> 1

       1

       <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.

    3. 각각의 유효한 node-bootstrapper CSR을 승인합니다.

       $ oc adm certificate approve <csr_name>

    4. 사용자 프로비저닝 설치의 경우 각 유효한 kubelet 서비스 CSR을 승인합니다.

       $ oc adm certificate approve <csr_name>

11. 단일 멤버 컨트롤 플레인이 제대로 시작되었는지 확인합니다.

    1. 복구 호스트에서 etcd 컨테이너가 실행 중인지 확인합니다.

       $ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"

       출력 예

       3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0

    2. 복구 호스트에서 etcd pod가 실행 중인지 확인합니다.

       $ oc -n openshift-etcd get pods -l k8s-app=etcd

       참고

       이 명령을 실행하기 전에 oc login을 실행하여 다음 오류가 발생하면 인증 컨트롤러가 시작될 때까지 잠시 기다렸다가 다시 시도하십시오.

       Unable to connect to the server: EOF

       출력 예

       NAME                                             READY   STATUS      RESTARTS   AGE
       etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s

       Pending 상태에 있거나 출력에 여러 실행중인 etcd pod가 나열되어 있는 경우 몇 분 기다렸다가 다시 확인합니다.

    참고

    OVNKubernetes 네트워크 플러그인을 사용하는 경우에만 다음 단계를 수행합니다.

12. 복구 컨트롤 플레인 호스트가 아닌 컨트롤 플레인 호스트와 연결된 노드 오브젝트를 삭제합니다.

    $ oc delete node <non-recovery-controlplane-host-1> <non-recovery-controlplane-host-2>

13. CNO(Cluster Network Operator)에서 OVN-Kubernetes 컨트롤 플레인을 재배포하고 더 이상 잘못된 컨트롤러 IP 주소를 참조하지 않는지 확인합니다. 이 결과를 확인하려면 다음 명령의 출력을 정기적으로 확인하십시오. 다음 단계를 진행하기 전에 빈 결과가 반환될 때까지 기다립니다.

    $ oc -n openshift-ovn-kubernetes get ds/ovnkube-master -o yaml | grep -E '<wrong_master_ip_1>|<wrong_master_ip_2>'

    참고

    OVN-Kubernetes 컨트롤 플레인을 재배포하고 이전 명령을 사용하여 빈 출력을 반환하는 데 최소 5-10 분이 걸릴 수 있습니다.

14. 다음 명령을 입력하여 쿼럼 감시를 끕니다.

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    이 명령을 사용하면 시크릿을 성공적으로 다시 생성하고 정적 Pod를 롤아웃할 수 있습니다.

15. 모든 호스트에서 OVN(Open Virtual Network) Kubernetes Pod를 재시작합니다.

    참고

    승인 Webhook 확인 및 변경은 Pod를 거부할 수 있습니다. failurePolicy 를 Fail 로 설정하여 추가 Webhook를 추가하는 경우 Pod를 거부하고 복원 프로세스가 실패할 수 있습니다. 클러스터 상태를 복원하는 동안 Webhook를 저장하고 삭제하여 이 문제를 방지할 수 있습니다. 클러스터 상태가 성공적으로 복원되면 Webhook를 다시 활성화할 수 있습니다.

    또는 클러스터 상태를 복원하는 동안 failurePolicy 를 Ignore 로 일시적으로 설정할 수 있습니다. 클러스터 상태가 성공적으로 복원된 후 failurePolicy 를 Fail 로 설정할 수 있습니다.

    1. northbound 데이터베이스(nbdb) 및 southbound 데이터베이스(sbdb)를 제거합니다. SSH(Secure Shell)를 사용하여 복구 호스트 및 나머지 컨트롤 플레인 노드에 액세스하고 다음 명령을 실행합니다.

       $ sudo rm -f /var/lib/ovn/etc/*.db

    2. 다음 명령을 실행하여 모든 OVN-Kubernetes 컨트롤 플레인 Pod를 삭제합니다.

       $ oc delete pods -l app=ovnkube-master -n openshift-ovn-kubernetes

    3. 모든 OVN-Kubernetes 컨트롤 플레인 Pod가 다시 배포되어 다음 명령을 실행하여 Running 상태인지 확인합니다.

       $ oc get pods -l app=ovnkube-master -n openshift-ovn-kubernetes

       출력 예

       NAME                   READY   STATUS    RESTARTS   AGE
       ovnkube-master-nb24h   4/4     Running   0          48s
       ovnkube-master-rm8kw   4/4     Running   0          47s
       ovnkube-master-zbqnh   4/4     Running   0          56s

    4. 다음 명령을 실행하여 ovnkube-node Pod를 모두 삭제합니다.

       $ oc get pods -n openshift-ovn-kubernetes -o name | grep ovnkube-node | while read p ; do oc delete $p -n openshift-ovn-kubernetes ; done

    5. 모든 ovnkube-node Pod가 다시 배포되어 다음 명령을 실행하여 Running 상태인지 확인합니다.

       $ oc get  pods -n openshift-ovn-kubernetes | grep ovnkube-node

16. 복구되지 않는 다른 컨트롤 플레인 시스템을 삭제하고 하나씩 다시 생성합니다. 머신을 다시 생성한 후 새 버전이 강제되고 etcd가 자동으로 확장됩니다.

    • 사용자가 프로비저닝한 베어 메탈 설치를 사용하는 경우 원래 사용했던 것과 동일한 방법을 사용하여 컨트롤 플레인 시스템을 다시 생성할 수 있습니다. 자세한 내용은 " 베어 메탈에 사용자 프로비저닝 클러스터 설치"를 참조하십시오.

      주의

      복구 호스트의 시스템을 삭제하고 다시 생성하지 마십시오.

    • 설치 관리자 프로비저닝 인프라를 실행 중이거나 Machine API를 사용하여 머신을 생성한 경우 다음 단계를 따르십시오.

      주의

      복구 호스트의 시스템을 삭제하고 다시 생성하지 마십시오.

      설치 관리자 프로비저닝 인프라에 베어 메탈 설치의 경우 컨트롤 플레인 머신이 다시 생성되지 않습니다. 자세한 내용은 " 베어 메탈 컨트롤 플레인 노드 교체"를 참조하십시오.

      1. 손실된 컨트롤 플레인 호스트 중 하나에 대한 시스템을 가져옵니다.

         cluster-admin 사용자로 클러스터에 액세스할 수 있는 터미널에서 다음 명령을 실행합니다.

         $ oc get machines -n openshift-machine-api -o wide

         출력 예:

         NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
         clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 1
         clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
         clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
         clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
         clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
         clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

         1

         이는 손실된 컨트롤 플레인 호스트 ip-10-0-131-183.ec2.internal 의 컨트롤 플레인 시스템입니다.

      2. 시스템 설정을 파일 시스템의 파일에 저장합니다.

         $ oc get machine clustername-8qw5l-master-0 \ 1
             -n openshift-machine-api \
             -o yaml \
             > new-master-machine.yaml

         1

         손실된 컨트롤 플레인 호스트의 컨트롤 플레인 시스템의 이름을 지정합니다.

      3. 이전 단계에서 만든 new-master-machine.yaml 파일을 편집하여 새 이름을 할당하고 불필요한 필드를 제거합니다.

         1. 전체 status 섹션을 삭제합니다.

            status:
              addresses:
              - address: 10.0.131.183
                type: InternalIP
              - address: ip-10-0-131-183.ec2.internal
                type: InternalDNS
              - address: ip-10-0-131-183.ec2.internal
                type: Hostname
              lastUpdated: "2020-04-20T17:44:29Z"
              nodeRef:
                kind: Node
                name: ip-10-0-131-183.ec2.internal
                uid: acca4411-af0d-4387-b73e-52b2484295ad
              phase: Running
              providerStatus:
                apiVersion: awsproviderconfig.openshift.io/v1beta1
                conditions:
                - lastProbeTime: "2020-04-20T16:53:50Z"
                  lastTransitionTime: "2020-04-20T16:53:50Z"
                  message: machine successfully created
                  reason: MachineCreationSucceeded
                  status: "True"
                  type: MachineCreation
                instanceId: i-0fdb85790d76d0c3f
                instanceState: stopped
                kind: AWSMachineProviderStatus

         2. metadata.name 필드를 새 이름으로 변경합니다.

            이전 시스템과 동일한 기본 이름을 유지하고 마지막 번호를 사용 가능한 다음 번호로 변경하는 것이 좋습니다. 이 예에서 clustername-8qw5l-master-0 은 clustername-8qw5l-master-3 으로 변경되었습니다.

            apiVersion: machine.openshift.io/v1beta1
            kind: Machine
            metadata:
              ...
              name: clustername-8qw5l-master-3
              ...

         3. spec.providerID 필드를 삭제합니다.

            providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f

         4. metadata.annotations 및 metadata.generation 필드를 제거합니다.

            annotations:
              machine.openshift.io/instance-state: running
            ...
            generation: 2

         5. metadata.resourceVersion 및 metadata.uid 필드를 제거합니다.

            resourceVersion: "13291"
            uid: a282eb70-40a2-4e89-8009-d05dd420d31a

      4. 손실된 컨트롤 플레인 호스트의 시스템을 삭제합니다.

         $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1

         1

         손실된 컨트롤 플레인 호스트의 컨트롤 플레인 시스템의 이름을 지정합니다.

      5. 시스템이 삭제되었는지 확인합니다.

         $ oc get machines -n openshift-machine-api -o wide

         출력 예:

         NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
         clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
         clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal   aws:///us-east-1c/i-02626f1dba9ed5bba  running
         clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
         clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
         clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

      6. new-master-machine.yaml 파일을 사용하여 시스템을 생성합니다.

         $ oc apply -f new-master-machine.yaml

      7. 새 시스템이 생성되었는지 확인합니다.

         $ oc get machines -n openshift-machine-api -o wide

         출력 예:

         NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
         clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
         clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
         clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running 1
         clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
         clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
         clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

         1

         새 시스템 clustername-8qw5l-master-3 이 생성되고 단계가 Provisioning 에서 Running 으로 변경된 후 준비 상태가 됩니다.

         새 시스템을 만드는 데 몇 분이 소요될 수 있습니다. etcd 클러스터 Operator는 머신 또는 노드가 정상 상태로 돌아 오면 자동으로 동기화됩니다.

      8. 복구 호스트가 아닌 각 손실된 컨트롤 플레인 호스트에 대해 이 단계를 반복합니다.

17. 별도의 터미널 창에서 다음 명령을 입력하여 cluster-admin 역할의 사용자로 클러스터에 로그인합니다.

    $ oc login -u <cluster_admin> 1

    1

    <cluster_admin>은 cluster-admin 역할을 사용하여 사용자 이름을 지정합니다.

18. etcd를 강제로 재배포합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1

    1

    forceRedeploymentReason 값은 고유해야하므로 타임 스탬프가 추가됩니다.

    etcd 클러스터 Operator가 재배포를 실행하면 기존 노드가 초기 부트 스트랩 확장과 유사한 새 pod를 사용하기 시작합니다.

19. 다음 명령을 입력하여 쿼럼 감시를 다시 설정합니다.

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'

20. 다음 명령을 입력하여 unsupportedConfigOverrides 섹션이 오브젝트에서 제거되었는지 확인할 수 있습니다.

    $ oc get etcd/cluster -oyaml

21. 모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

    etcd의 NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.

    AllNodesAtLatestRevision
    3 nodes are at revision 7 1

    1

    이 예에서 최신 버전 번호는 7입니다.

    출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

22. etcd를 재배포한 후 컨트롤 플레인에 새 롤아웃을 강제 실행합니다. kubelet이 내부 로드 밸런서를 사용하여 API 서버에 연결되어 있으므로 Kubernetes API 서버는 다른 노드에 다시 설치됩니다.

    cluster-admin 사용자로 클러스터에 액세스할 수있는 터미널에서 다음 명령을 실행합니다.

    1. Kubernetes API 서버에 대해 새 롤아웃을 강제 적용합니다.

       $ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

       모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

       $ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       이 예에서 최신 버전 번호는 7입니다.

       출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

    2. Kubernetes 컨트롤러 관리자의 새 롤아웃을 강제 적용합니다.

       $ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

       모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

       $ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       이 예에서 최신 버전 번호는 7입니다.

       출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

    3. Kubernetes 스케줄러에 새 롤아웃을 강제 적용합니다.

       $ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge

       모든 노드가 최신 버전으로 업데이트되었는지 확인합니다.

       $ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'

       NodeInstallerProgressing 상태 조건을 확인하고 모든 노드가 최신 버전인지 확인합니다. 업데이트가 성공적으로 실행되면 출력에 AllNodesAtLatestRevision이 표시됩니다.

       AllNodesAtLatestRevision
       3 nodes are at revision 7 1

       1

       이 예에서 최신 버전 번호는 7입니다.

       출력에 2 nodes are at revision 6; 1 nodes are at revision 7와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

23. 모든 컨트롤 플레인 호스트가 클러스터를 시작하여 참여하고 있는지 확인합니다.

    클러스터에 액세스할 수 있는 터미널에서 cluster-admin 사용자로 다음 명령을 실행합니다.

    $ oc -n openshift-etcd get pods -l k8s-app=etcd

    출력 예

    etcd-ip-10-0-143-125.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-154-194.ec2.internal                2/2     Running     0          9h
    etcd-ip-10-0-173-171.ec2.internal                2/2     Running     0          9h

1. 다음과 같은 오브젝트 정의를 사용하여 YAML 파일을 만듭니다.

   apiVersion: policy/v1 1
   kind: PodDisruptionBudget
   metadata:
     name: my-pdb
   spec:
     minAvailable: 2  2
     selector:  3
       matchLabels:
         foo: bar

   1

   PodDisruptionBudget 은 policy/v1 API 그룹의 일부입니다.

   2

   동시에 사용할 수 필요가 있는 최소 pod 수 입니다. 정수 또는 백분율 (예: 20 %)을 지정하는 문자열을 사용할 수 있습니다.

   3

   리소스 집합에 대한 라벨 쿼리입니다. matchLabels 및 matchExpressions의 결과는 논리적으로 결합됩니다. 이 paramter(예: selector {} )를 비워 두고 프로젝트의 모든 포드를 선택합니다.

   또는 다음을 수행합니다.

   apiVersion: policy/v1 1
   kind: PodDisruptionBudget
   metadata:
     name: my-pdb
   spec:
     maxUnavailable: 25% 2
     selector: 3
       matchLabels:
         foo: bar

   1

   PodDisruptionBudget 은 policy/v1 API 그룹의 일부입니다.

   2

   동시에 사용할 수없는 최대 pod 수입니다. 정수 또는 백분율 (예: 20 %)을 지정하는 문자열을 사용할 수 있습니다.

   3

   리소스 집합에 대한 라벨 쿼리입니다. matchLabels 및 matchExpressions의 결과는 논리적으로 결합됩니다. 이 paramter(예: selector {} )를 비워 두고 프로젝트의 모든 포드를 선택합니다.

2. 다음 명령을 실행하여 오브젝트를 프로젝트에 추가합니다.

   $ oc create -f </path/to/file> -n <project_name>

절차

1. 웹 콘솔의 Administrator 모드에서 Workloads → Secrets로 이동합니다.

2. Secrets 페이지의 표에서 클라우드 공급자의 루트 시크릿을 찾습니다.

   플랫폼	시크릿 이름
   AWS	aws-creds
   Azure	azure-credentials
   GCP	gcp-credentials
   RHOSP	openstack-credentials
   RHV	ovirt-credentials
   VMware vSphere	vsphere-creds

3. 시크릿과 동일한 행에서 옵션 메뉴 를 클릭하고 시크릿 편집을 선택합니다.
4. Value 필드의 내용을 기록합니다. 이 정보를 사용하여 인증서를 업데이트한 후 값이 다른지 확인할 수 있습니다.
5. 클라우드 공급자에 대한 새로운 인증 정보를 사용하여 Value 필드의 텍스트를 업데이트한 다음 저장을 클릭합니다.

6. vSphere CSI Driver Operator가 활성화되어 있지 않은 vSphere 클러스터의 인증 정보를 업데이트하는 경우 Kubernetes 컨트롤러 관리자의 롤아웃을 강제 적용하여 업데이트된 인증 정보를 적용해야 합니다.

   참고

   vSphere CSI Driver Operator가 활성화된 경우 이 단계가 필요하지 않습니다.

   업데이트된 vSphere 인증 정보를 적용하려면 OpenShift Container Platform CLI에 cluster-admin 역할의 사용자로 로그인하고 다음 명령을 실행합니다.

   $ oc patch kubecontrollermanager cluster \
     -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date )"'"}}' \
     --type=merge

   인증 정보가 출시되는 동안 Kubernetes Controller Manager Operator의 상태는 Progressing=true 로 보고합니다. 상태를 보려면 다음 명령을 실행합니다.

   $ oc get co kube-controller-manager

7. 클러스터의 CCO가 Mint 모드를 사용하도록 구성된 경우 개별 CredentialsRequest 오브젝트에서 참조하는 각 구성 요소 시크릿을 삭제합니다.

   1. cluster-admin 역할의 사용자로 OpenShift Container Platform CLI에 로그인합니다.

   2. 참조되는 모든 구성 요소 시크릿의 이름과 네임스페이스를 가져옵니다.

      $ oc -n openshift-cloud-credential-operator get CredentialsRequest \
        -o json | jq -r '.items[] | select (.spec.providerSpec.kind=="<provider_spec>") | .spec.secretRef'

      여기서 <provider_spec >은 클라우드 공급자의 해당 값입니다.

      • AWS: AWSProviderSpec
      • GCP: GCPProviderSpec

      AWS의 부분 예제 출력

      {
        "name": "ebs-cloud-credentials",
        "namespace": "openshift-cluster-csi-drivers"
      }
      {
        "name": "cloud-credential-operator-iam-ro-creds",
        "namespace": "openshift-cloud-credential-operator"
      }

   3. 참조된 각 구성 요소 시크릿을 삭제합니다.

      $ oc delete secret <secret_name> \1
        -n <secret_namespace> 2

      1

      보안 이름을 지정합니다.

      2

      보안이 포함된 네임스페이스를 지정합니다.

      AWS 시크릿 삭제 예

      $ oc delete secret ebs-cloud-credentials -n openshift-cluster-csi-drivers

      공급자 콘솔에서 인증 정보를 수동으로 삭제할 필요가 없습니다. 참조된 구성 요소 시크릿을 삭제하면 CCO가 플랫폼에서 기존 인증 정보를 삭제하고 새 인증서를 생성합니다.

1. 웹 콘솔의 Administrator 모드에서 Workloads → Secrets로 이동합니다.
2. Value 필드의 콘텐츠가 변경되었는지 확인합니다.

절차

1. 웹 콘솔의 Administrator 모드에서 Workloads → Secrets로 이동합니다.

2. Secrets 페이지의 표에서 클라우드 공급자의 루트 시크릿을 찾습니다.

   플랫폼	시크릿 이름
   AWS	aws-creds
   GCP	gcp-credentials

3. 시크릿과 동일한 행에서 옵션 메뉴 를 클릭하고 시크릿 삭제를 선택합니다.

프로세스

1. 미러링할 특정 이미지 스트림의 이미지에 액세스합니다. 예를 들면 다음과 같습니다.

   $ oc get is <imagestream> -n openshift -o json | jq .spec.tags[].from.name | grep registry.redhat.io

2. 제한된 네트워크 환경에서 필요한 모든 이미지 스트림과 관련된 registry.redhat.io의 이미지를 지정된 미러 중 하나로 미러링합니다.

   $ oc image mirror registry.redhat.io/rhscl/ruby-25-rhel7:latest ${MIRROR_ADDR}/rhscl/ruby-25-rhel7:latest

3. 클러스터의 이미지 구성 오브젝트를 생성합니다.

   $ oc create configmap registry-config --from-file=${MIRROR_ADDR_HOSTNAME}..5000=$path/ca.crt -n openshift-config

4. 클러스터의 이미지 설정 오브젝트에서 미러에 필요한 신뢰할 수 있는 CA를 추가합니다.

   $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-config"}}}' --type=merge

5. 미러 설정에 정의된 미러 위치의 hostname 부분을 포함하도록 Cluster Samples Operator 설정 오브젝트에서 samplesRegistry 필드를 업데이트합니다.

   $ oc edit configs.samples.operator.openshift.io -n openshift-cluster-samples-operator

   참고

   현재 이미지 스트림 가져오기 프로세스에서 미러 또는 검색 메커니즘이 사용되지 않기 때문에 이 작업이 필요합니다.

6. Cluster Samples Operator 구성 오브젝트의 skippedImagestreams 필드에 미러링되지 않은 이미지 스트림을 추가합니다. 또는 샘플 이미지 스트림을 모두 지원할 필요가 없는 경우 Cluster Samples Operator 구성 오브젝트에서 Cluster Samples Operator를 Removed 로 설정합니다.

   참고

   이미지 스트림 가져오기가 실패했으나 Cluster Samples Operator가 주기적으로 재시도하거나 재시도하지 않는 것처럼 보이면 Cluster Samples Operator는 경고를 발행합니다.

   openshift 네임스페이스의 여러 템플릿은 이미지 스트림을 참조합니다. 따라서 Removed를 사용하여 이미지 스트림과 템플릿을 모두 제거하면 누락된 이미지 스트림으로 인해 기능이 제대로 작동하지 않을 경우 템플릿을 사용할 가능성이 없어집니다.

절차

1. 미러 레지스트리의 신뢰할 수 있는 CA를 Cluster Samples Operator 설정의 일부로 클러스터의 이미지 구성 오브젝트에 추가하지 않은 경우 다음 단계를 수행합니다.

   1. 클러스터의 이미지 구성 오브젝트를 생성합니다.

      $ oc create configmap registry-config --from-file=${MIRROR_ADDR_HOSTNAME}..5000=$path/ca.crt -n openshift-config

   2. 클러스터의 이미지 설정 오브젝트에서 미러에 필요한 신뢰할 수 있는 CA를 추가합니다.

      $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-config"}}}' --type=merge

2. 설치 페이로드에서 기본 must-gather 이미지를 가져옵니다.

   $ oc import-image is/must-gather -n openshift

절차

1. 클러스터의 kubeconfig 파일 및 클러스터 설치에 사용된 설치 프로그램이 RHEL 8 머신에 있는지 확인합니다. 이를 수행하는 한 가지 방법으로 클러스터 설치에 사용된 머신과 동일한 머신을 사용하는 것입니다.
2. 컴퓨팅 머신으로 사용하려는 모든 RHEL 호스트에 액세스하도록 머신을 구성합니다. SSH 프록시 또는 VPN을 사용하는 Bastion를 포함하여 회사에서 허용하는 모든 방법을 사용할 수 있습니다.

3. Playbook을 실행하는 머신에서 모든 RHEL 호스트에 대한 SSH 액세스 권한이있는 사용자를 구성하십시오.

   중요

   SSH 키 기반 인증을 사용하는 경우 SSH 에이전트를 사용하여 키를 관리해야합니다.

4. 아직 등록하지 않은 경우 RHSM으로 머신을 등록하고 OpenShift 서브스크립션이 있는 풀을 머신에 연결합니다.

   1. RHSM으로 머신를 등록합니다.

      # subscription-manager register --username=<user_name> --password=<password>

   2. RHSM에서 최신 서브스크립션 데이터를 가져옵니다.

      # subscription-manager refresh

   3. 사용 가능한 서브스크립션을 나열하십시오.

      # subscription-manager list --available --matches '*OpenShift*'

   4. 이전 명령의 출력에서 OpenShift Container Platform 서브스크립션의 풀 ID를 찾아서 이를 연결합니다.

      # subscription-manager attach --pool=<pool_id>

5. OpenShift Container Platform 4.12에 필요한 리포지토리를 활성화합니다.

   # subscription-manager repos \
       --enable="rhel-8-for-x86_64-baseos-rpms" \
       --enable="rhel-8-for-x86_64-appstream-rpms" \
       --enable="rhocp-4.12-for-rhel-8-x86_64-rpms"

6. openshift-ansible을 포함한 필수 패키지를 설치합니다.

   # yum install openshift-ansible openshift-clients jq

   openshift-ansible 패키지는 설치 프로그램 유틸리티를 제공하고 Ansible, Playbook 및 관련 구성 파일과 같이 RHEL 컴퓨팅 노드를 클러스터에 추가하는데 필요한 다른 패키지를 가져옵니다. openshift-clients는 oc CLI를 제공하고 jq 패키지는 명령 행에서 JSON 출력 표시 방법을 개선할 수 있습니다.

1. 각 호스트에서 RHSM으로 동륵합니다.

   # subscription-manager register --username=<user_name> --password=<password>

2. RHSM에서 최신 서브스크립션 데이터를 가져옵니다.

   # subscription-manager refresh

3. 사용 가능한 서브스크립션을 나열하십시오.

   # subscription-manager list --available --matches '*OpenShift*'

4. 이전 명령의 출력에서 OpenShift Container Platform 서브스크립션의 풀 ID를 찾아서 이를 연결합니다.

   # subscription-manager attach --pool=<pool_id>

5. 모든 yum 저장소를 비활성화합니다.

   1. 활성화된 모든 RHSM 저장소를 비활성화합니다.

      # subscription-manager repos --disable="*"

   2. 나머지 yum 저장소를 나열하고 repo id 아래에 해당 이름을 적어 둡니다.

      # yum repolist

   3. yum-config-manager를 사용하여 나머지 yum 리포지토리를 비활성화합니다.

      # yum-config-manager --disable <repo_id>

      또는 모든 리포지토리를 비활성화합니다.

      # yum-config-manager --disable \*

      사용 가능한 리포지토리가 많으면 몇 분의 시간이 소요될 수 있습니다.

6. OpenShift Container Platform 4.12에 필요한 리포지토리만 활성화합니다.

   # subscription-manager repos \
       --enable="rhel-8-for-x86_64-baseos-rpms" \
       --enable="rhel-8-for-x86_64-appstream-rpms" \
       --enable="rhocp-4.12-for-rhel-8-x86_64-rpms" \
       --enable="fast-datapath-for-rhel-8-x86_64-rpms"

7. 호스트에서 firewalld를 중지하고 비활성화합니다.

   # systemctl disable --now firewalld.service

   참고

   나중에 firewalld를 활성화할 수 없습니다. 활성화하면 작업자의 OpenShift Container Platform 로그에 액세스할 수 없습니다.

1. 컴퓨팅 머신 호스트 및 필수 변수를 정의하는 /<path>/inventory/hosts라는 Ansible 인벤토리 파일을 만듭니다.

   [all:vars]
   ansible_user=root 1
   #ansible_become=True 2
   
   openshift_kubeconfig_path="~/.kube/config" 3
   
   [new_workers] 4
   mycluster-rhel8-0.example.com
   mycluster-rhel8-1.example.com

   1

   원격 컴퓨팅 머신에서 Ansible 태스크를 실행하는 사용자 이름을 지정합니다.

   2

   ansible_user의 root를 지정하지 않으면 ansible_become을 True로 설정하고 사용자 sudo 권한을 지정해야합니다.

   3

   클러스터 kubeconfig 파일의 경로와 파일 이름을 지정합니다.

   4

   클러스터에 추가할 각 RHEL 머신을 나열합니다. 각 호스트에 대해 정규화된 도메인 이름을 지정해야합니다. 이 이름은 클러스터가 시스템에 액세스하는 데 사용하는 호스트 이름이므로 올바른 공용 또는 개인 이름을 설정하여 시스템에 액세스합니다.

2. Ansible Playbook 디렉토리로 이동합니다.

   $ cd /usr/share/ansible/openshift-ansible

3. Playbook을 실행합니다.

   $ ansible-playbook -i /<path>/inventory/hosts playbooks/scaleup.yml 1

   1

   <path>에 대해 생성한 Ansible 인벤토리 파일의 경로를 지정합니다.

프로세스

1. 머신 목록을 표시하고 RHCOS 컴퓨팅 머신의 노드 이름을 기록합니다.

   $ oc get nodes -o wide

2. 각 RHCOS 컴퓨팅 머신의 노드를 제거합니다.

   1. oc adm cordon 명령을 실행하여 노드를 스케줄 예약 해제로 표시합니다.

      $ oc adm cordon <node_name> 1

      1

      RHCOS 컴퓨팅 머신의 노드 이름을 지정합니다.

   2. 노드에서 모든 pod를 드레인합니다.

      $ oc adm drain <node_name> --force --delete-emptydir-data --ignore-daemonsets 1

      1

      분리 한 RHCOS 컴퓨팅 머신의 노드 이름을 지정합니다.

   3. 노드를 제거합니다.

      $ oc delete nodes <node_name> 1

      1

      드레인한 RHCOS 컴퓨팅 머신의 노드 이름을 지정합니다.

3. 컴퓨팅 머신 목록을 확인하고 RHEL 노드만 남아 있는지 확인합니다.

   $ oc get nodes -o wide

4. 클러스터 컴퓨팅 머신의 로드 밸런서에서 RHCOS 머신을 제거합니다. 가상 머신을 삭제하거나 RHCOS 컴퓨팅 머신의 실제 하드웨어를 다시 이미지화 할 수 있습니다.

절차

1. ISO 파일을 사용하여 추가 컴퓨팅 머신에 RHCOS를 설치합니다. 클러스터를 설치하기 전에 머신을 만들 때 사용한 것과 동일한 방법을 사용합니다.

   • ISO 이미지를 디스크에 굽고 직접 부팅합니다.
   • LOM 인터페이스에서 ISO 리디렉션을 사용합니다.

2. 옵션을 지정하거나 라이브 부팅 시퀀스를 중단하지 않고 RHCOS ISO 이미지를 부팅합니다. 설치 프로그램이 RHCOS 라이브 환경에서 쉘 프롬프트로 부팅될 때까지 기다립니다.

   참고

   커널 인수를 추가하기 위해 RHCOS 설치 부팅 프로세스를 중단할 수 있습니다. 그러나 이 ISO 프로세스에서는 커널 인수를 추가하는 대신 다음 단계에 설명된 대로 coreos-installer 명령을 사용해야 합니다.

3. coreos-installer 명령을 실행하고 설치 요구 사항을 충족하는 옵션을 지정합니다. 최소한 노드 유형에 대한 Ignition 구성 파일과 설치할 장치를 가리키는 URL을 지정해야 합니다.

   $ sudo coreos-installer install --ignition-url=http://<HTTP_server>/<node_type>.ign <device> --ignition-hash=sha512-<digest> 12

   1

   core 사용자에게 설치를 수행하는 데 필요한 root 권한이 없으므로 sudo를 사용하여 coreos-installer 명령을 실행해야 합니다.

   2

   클러스터 노드에서 Ignition 구성 파일을 HTTP URL을 통해 가져오려면 --ignition-hash 옵션이 필요합니다. <digest>는 이전 단계에서 얻은 Ignition 구성 파일 SHA512 다이제스트입니다.

   참고

   TLS를 사용하는 HTTPS 서버를 통해 Ignition 구성 파일을 제공하려는 경우 coreos-installer를 실행하기 전에 내부 인증 기관(CA)을 시스템 신뢰 저장소에 추가할 수 있습니다.

   다음 예제에서는 /dev/sda 장치에 부트스트랩 노드 설치를 초기화합니다. 부트스트랩 노드의 Ignition 구성 파일은 IP 주소 192.168.1.2가 있는 HTTP 웹 서버에서 가져옵니다.

   $ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b

4. 머신 콘솔에서 RHCOS 설치 진행률을 모니터링합니다.

   중요

   OpenShift Container Platform 설치를 시작하기 전에 각 노드에서 성공적으로 설치되었는지 확인합니다. 설치 프로세스를 관찰하면 발생할 수 있는 RHCOS 설치 문제의 원인을 파악하는 데 도움이 될 수 있습니다.

5. 계속해서 클러스터에 추가 컴퓨팅 머신을 만듭니다.