프로세스

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.1.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 파일의 내용을 작성하고 base64로 인코딩하십시오. 예를 들면 다음과 같습니다.

   $ cat << EOF | base64
       pool 0.rhel.pool.ntp.org iburst 1
       driftfile /var/lib/chrony/drift
       makestep 1.0 3
       rtcsync
       logdir /var/log/chrony
   EOF

   1

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

   출력 예

   ICAgIHNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdAogICAgZHJpZnRmaWxlIC92YXIvbGli
   L2Nocm9ueS9kcmlmdAogICAgbWFrZXN0ZXAgMS4wIDMKICAgIHJ0Y3N5bmMKICAgIGxvZ2RpciAv
   dmFyL2xvZy9jaHJvbnkK

2. base64 문자열을 작성한 문자열로 바꾸어 MachineConfig 개체 파일을 만듭니다. 이 예제에서는 파일을 master 노드에 추가합니다. 이를 worker로 변경하거나 worker 역할의 추가 MachineConfig을 만들 수 있습니다. 클러스터가 사용하는 각 유형의 머신에 대해 MachineConfig 파일을 만듭니다.

   $ cat << EOF > ./99-masters-chrony-configuration.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 99-masters-chrony-configuration
   spec:
     config:
       ignition:
         config: {}
         security:
           tls: {}
         timeouts: {}
         version: 3.1.0
       networkd: {}
       passwd: {}
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64,ICAgIHNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdAogICAgZHJpZnRmaWxlIC92YXIvbGliL2Nocm9ueS9kcmlmdAogICAgbWFrZXN0ZXAgMS4wIDMKICAgIHJ0Y3N5bmMKICAgIGxvZ2RpciAvdmFyL2xvZy9jaHJvbnkK
           mode: 420 1
           overwrite: true
           path: /etc/chrony.conf
     osImageURL: ""
   EOF

   1

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

3. 설정 파일의 백업 사본을 만듭니다.

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

   • 클러스터가 아직 시작하지 않은 경우 매니페스트 파일을 생성하고 해당 파일을 <installation_directory>/openshift 디렉터리에 추가한 후 계속 클러스터를 작성합니다.

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

     $ oc apply -f ./99-masters-chrony-configuration.yaml

프로세스

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

   $ oc get MachineConfig

   출력 예

    NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
    00-master                                          5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    00-worker                                          5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-master-container-runtime                        5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-master-kubelet                                  5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-worker-container-runtime                        5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-worker-kubelet                                  5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    99-master-generated-registries                     5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    99-master-ssh                                                                                 3.1.0             77m
    99-worker-generated-registries                     5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    99-worker-ssh                                                                                 3.1.0             77m
    rendered-master-0f314bb55448c47e6776e16e608c5912   5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             42m
    rendered-master-c7761e6162e6c9538b0cdd7eef567d38   5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m

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:
     config:
       ignition:
         version: 3.1.0
     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                                          5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    00-worker                                          5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-master-container-runtime                        5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-master-kubelet                                  5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-worker-container-runtime                        5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    01-worker-kubelet                                  5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
   
    05-worker-kernelarg-selinuxpermissive                                                         3.1.0             105s
   
    99-master-generated-registries                     5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    99-master-ssh                                                                                 3.1.0             77m
    99-worker-generated-registries                     5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m
    99-worker-ssh                                                                                 3.1.0             77m
    rendered-master-0f314bb55448c47e6776e16e608c5912   5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             42m
    rendered-master-c7761e6162e6c9538b0cdd7eef567d38   5ce9351ceb24e721e28cd82de3a44fc7cc27137c   3.1.0             65m

5. 노드를 확인합니다.

   $ oc get nodes

   출력 예

   NAME                           STATUS                     ROLES    AGE   VERSION
   ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.19.0
   ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.19.0
   ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.19.0
   ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.19.0
   ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.19.0
   ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.19.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. 실시간 커널의 머신 구성을 생성합니다. 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.19.0
   ip-10-0-146-92.us-east-2.compute.internal   Ready   worker   101m  v1.19.0
   ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.19.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. chrony.conf 파일의 내용을 작성하고 이를 base64로 인코딩합니다. 예를 들면 다음과 같습니다.

   $ cat > /tmp/jrnl.conf <<EOF
   # Disable rate limiting
   RateLimitInterval=1s
   RateLimitBurst=10000
   Storage=volatile
   Compress=no
   MaxRetentionSec=30s
   EOF

2. 임시 journal.conf 파일을 base64로 변환하고 이를 변수 (jrnl_cnf)에 저장합니다.

   $ export jrnl_cnf=$( cat /tmp/jrnl.conf | base64 -w0 )
   $ echo $jrnl_cnf
   IyBEaXNhYmxlIHJhdGUgbGltaXRpbmcKUmF0ZUxpbWl0SW50ZXJ2YWw9MXMKUmF0ZUxpbWl0QnVyc3Q9MTAwMDAKU3RvcmFnZT12b2xhdGlsZQpDb21wcmVzcz1ubwpNYXhSZXRlbnRpb25TZWM9MzBzCg==

3. journald.conf (jrnl_cnf 변수)의 인코딩된 내용을 포함하여 머신 구성을 만듭니다.

   $ cat > /tmp/40-worker-custom-journald.yaml <<EOF
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 40-worker-custom-journald
   spec:
     config:
       ignition:
         config: {}
         security:
           tls: {}
         timeouts: {}
         version: 3.1.0
       networkd: {}
       passwd: {}
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64,${jrnl_cnf}
             verification: {}
           filesystem: root
           mode: 420
           path: /etc/systemd/journald.conf
       systemd: {}
     osImageURL: ""
   EOF

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

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

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

   $ 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

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

   $ 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. 해당 파일의 인코딩된 base64 콘텐츠를 포함하여 /etc/containers/registries.conf.d/99-worker-unqualified-search-registries.conf 파일의 콘텐츠를 저장할 YAML 파일(myregistry.yaml)을 만듭니다. 예를 들면 다음과 같습니다.

   $ cat > /tmp/myregistry.yaml <<EOF
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 99-worker-unqualified-search-registries
   spec:
     config:
       ignition:
         version: 3.1.0
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64,dW5xdWFsaWZpZWQtc2VhcmNoLXJlZ2lzdHJpZXMgPSBbJ3JlZ2lzdHJ5LmFjY2Vzcy5yZWRoYXQuY29tJywgJ2RvY2tlci5pbycsICdxdWF5LmlvJ10K
           filesystem: root
           mode: 0644
           path: /etc/containers/registries.conf.d/99-worker-unqualified-search-registries.conf
   EOF

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

   $ oc apply -f /tmp/myregistry.yaml

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

   $ 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

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

   $ 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/containers/registries.conf.d/99-worker-unqualified-search-registries.conf
   unqualified-search-registries = ['registry.access.redhat.com', 'docker.io', 'quay.io']
   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.1.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.1.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.18.3

   $ 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.9.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. 이 명령은 선택할 수 있는 사용 가능한 머신 구성 오브젝트를 표시합니다.

   $ oc get machineconfig

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

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

   # oc describe node <node-ip> | grep Allocatable -A6

   value: pods: <value>를 찾습니다.

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

   # oc describe node ip-172-31-128-158.us-east-2.compute.internal | grep Allocatable -A6

   출력 예

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

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

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

   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: large-pods
     kubeletConfig:
       maxPods: <pod_count>
       kubeAPIBurst: <burst_rate>
       kubeAPIQPS: <QPS>

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

      $ oc label machineconfigpool worker custom-kubelet=large-pods

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

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

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

      $ oc get kubeletconfig

      set-max-pods가 반환됩니다.

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

4. 작업자 노드의 maxPods 변경사항을 확인합니다.

   $ oc describe node

   1. 다음을 실행하여 변경사항을 검증합니다.

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

      True 및 type:Success 상태가 표시되어야 합니다.

1. worker 머신 구성 풀을 편집합니다.

   $ oc edit machineconfigpool worker

2. maxUnavailable을 원하는 값으로 설정합니다.

   spec:
     maxUnavailable: <node_count>

   중요

   값을 설정하는 경우 클러스터에서 실행 중인 애플리케이션에 영향을 미치지 않고 사용 가능한 상태로 둘 수 있는 작업자 노드 수를 고려하십시오.

절차

1. pidsLimit를 2048로 늘리려면 logLevel을 debug로 overlaySize를 8 GB로 설정하고 해당 설정이 포함된 CR 파일 (예: overlay-size.yaml)을 만듭니다.

   $ cat << EOF > /tmp/overlay-size.yaml
   apiVersion: machineconfiguration.openshift.io/v1
   kind: ContainerRuntimeConfig
   metadata:
    name: overlay-size
   spec:
    machineConfigPoolSelector:
      matchLabels:
        custom-crio: overlay-size
    containerRuntimeConfig:
      pidsLimit: 2048
      logLevel: debug
      overlaySize: 8G
   EOF

2. ContainerRuntimeConfig 개체 설정을 적용하려면 다음을 실행합니다.

   $ oc create -f /tmp/overlay-size.yaml

3. YAML 파일이 설정을 적용했는지 확인하려면 다음 명령을 실행합니다.

   $ oc get ContainerRuntimeConfig
   NAME           AGE
   overlay-size   3m19s

4. worker와 같은 머신 풀을 편집하려면 다음 명령을 실행하여 머신 설정풀을 엽니다.

   $ oc edit machineconfigpool worker

5. 새 containerruntime 개체가 machineconfigs 아래에 표시되었는지 확인합니다:

   $ oc get machineconfigs | grep containerrun
   99-worker-generated-containerruntime   2c9371fbb673b97a6fe8b1c52691999ed3a1bfc2  3.1.0  31s

6. 모두 준비 상태가 될 때까지 변경 사항이 머신으로 롤링될 때 machine config pool을 모니터링합니다.

   $ 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

7. 작업자 노드에 대한 oc 디버그 세션을 열고 chroot / host를 실행하십시오.

8. 다음을 실행하여 변경 사항을 확인합니다.

   $ crio config | egrep 'log_level|pids_limit'

   출력 예

   pids_limit = 2048
   log_level = "debug"

   $ 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   2.2.0             7m42s
   rendered-worker-xyz                   4173030d89fbf4a7a0976d1665491a4d9a6e54f1   2.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/cluster-api-delete-machine="true"

4. 삭제하려는 노드를 비우고 제외합니다.

   $ oc adm cordon <node_name>
   $ oc adm drain <node_name>

5. 머신 세트를 스케일링합니다.

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

   또는 다음을 수행합니다.

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

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

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
     policy:
       name: ""

   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

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

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

        $ oc edit MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

        출력 예

        apiVersion: machine.openshift.io/v1beta1
        kind: MachineSet
        metadata:
        ...
        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.18.3+002a51f

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

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

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

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

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 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.18.3+002a51f

절차

1. 머신 세트 CR(사용자 지정 리소스) 샘플이 포함된 이름이 <file_name>.yaml인 새 YAML 파일을 만듭니다.

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

   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. 특정 머신 세트의 값을 확인합니다.

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

      출력 예

      ...
      template:
          metadata:
            labels:
              machine.openshift.io/cluster-api-cluster: agl030519-vplxk 1
              machine.openshift.io/cluster-api-machine-role: worker 2
              machine.openshift.io/cluster-api-machine-type: worker
              machine.openshift.io/cluster-api-machineset: agl030519-vplxk-worker-us-east-1a

      1

      클러스터 ID입니다.

      2

      기본 노드 레이블입니다.

2. 새 MachineSet CR을 만듭니다.

   $ oc create -f <file_name>.yaml

3. 머신 세트 목록을 표시합니다.

   $ oc get machineset -n openshift-machine-api

   출력 예

   NAME                                DESIRED   CURRENT   READY   AVAILABLE   AGE
   agl030519-vplxk-infra-us-east-1a    1         1         1       1           11m
   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

   새 머신 세트가 사용 가능한 경우DESIRED 및 CURRENT 값이 일치합니다. 머신 세트를 사용할 수 없는 경우 몇 분 후에 명령을 다시 실행합니다.

절차

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   2.2.0             31d
   00-worker                                                   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
   01-master-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
   01-master-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
   01-worker-container-runtime                                 365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
   01-worker-kubelet                                           365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
   99-master-1ae2a1e0-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
   99-master-ssh                                                                                          2.2.0             31d
   99-worker-1ae64748-a115-11e9-8f14-005056899d54-registries   365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             31d
   99-worker-ssh                                                                                          2.2.0             31d
   rendered-infra-4e48906dca84ee702959c71a53ee80e7             365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             19s
   rendered-master-072d4b2da7f88162636902b074e9e28e            5b6fb8349a29735e48446d435962dec4547d3090   2.2.0             31d
   rendered-master-3e88ec72aed3886dec061df60d16d1af            02c07496ba0417b3e12b78fb32baf6293d314f79   2.2.0             31d
   rendered-master-419bee7de96134963a15fdf9dd473b25            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             17d
   rendered-master-53f5c91c7661708adce18739cc0f40fb            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             13d
   rendered-master-a6a357ec18e5bce7f5ac426fc7c5ffcd            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             7d3h
   rendered-master-dc7f874ec77fc4b969674204332da037            5b6fb8349a29735e48446d435962dec4547d3090   2.2.0             31d
   rendered-worker-1a75960c52ad18ff5dfa6674eb7e533d            5b6fb8349a29735e48446d435962dec4547d3090   2.2.0             31d
   rendered-worker-2640531be11ba43c61d72e82dc634ce6            5b6fb8349a29735e48446d435962dec4547d3090   2.2.0             31d
   rendered-worker-4e48906dca84ee702959c71a53ee80e7            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             7d3h
   rendered-worker-4f110718fe88e5f349987854a1147755            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.2.0             17d
   rendered-worker-afc758e194d6188677eb837842d3b379            02c07496ba0417b3e12b78fb32baf6293d314f79   2.2.0             31d
   rendered-worker-daa08cc1e8f5fcdeba24de60cd955cc3            365c1cfd14de5b0e3b85e0fc815b0060f36ab955   2.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.1.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>:<effect>

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

      $ oc adm taint nodes node1 node-role.kubernetes.io/infra:NoSchedule

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

      참고

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

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

   tolerations:
     - effect: NoSchedule 1
       key: node-role.kubernetes.io/infra 2
       operator: Exists 3

   1

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

   2

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

   3

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

   이 허용 오차는 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

   다음과 같이 infra 레이블을 참조하는 nodeSelector 부분을 spec 섹션에 추가합니다.

     spec:
       nodePlacement:
         nodeSelector:
           matchLabels:
             node-role.kubernetes.io/infra: ""

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.19.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

3. 다음 YAML과 동일하게 오브젝트의 spec 섹션을 수정합니다.

   spec:
     affinity:
       podAntiAffinity:
         preferredDuringSchedulingIgnoredDuringExecution:
         - podAffinityTerm:
             namespaces:
             - openshift-image-registry
             topologyKey: kubernetes.io/hostname
           weight: 100
     logLevel: Normal
     managementState: Managed
     nodeSelector:
       node-role.kubernetes.io/infra: ""

4. 레지스트리 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. 다음 ConfigMap 정의를 cluster-monitoring-configmap.yaml 파일로 저장합니다.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |+
       alertmanagerMain:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       prometheusK8s:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       prometheusOperator:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       grafana:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       k8sPrometheusAdapter:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       kubeStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       telemeterClient:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       openshiftStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
       thanosQuerier:
         nodeSelector:
           node-role.kubernetes.io/infra: ""

   이 구성 맵을 실행하면 모니터링 스택의 구성 요소가 인프라 노드에 재배포됩니다.

2. 새 구성 맵을 적용합니다.

   $ oc create -f cluster-monitoring-configmap.yaml

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

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

4. 구성 요소가 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
     curation:
       curator:
         nodeSelector: 1
           node-role.kubernetes.io/infra: ''
         resources: null
         schedule: 30 3 * * *
       type: curator
     logStore:
       elasticsearch:
         nodeCount: 3
         nodeSelector: 2
           node-role.kubernetes.io/infra: ''
         redundancyPolicy: SingleRedundancy
         resources:
           limits:
             cpu: 500m
             memory: 16Gi
           requests:
             cpu: 500m
             memory: 16Gi
         storage: {}
       type: elasticsearch
     managementState: Managed
     visualization:
       kibana:
         nodeSelector: 3
           node-role.kubernetes.io/infra: ''
         proxy:
           resources: null
         replicas: 1
         resources: null
       type: kibana
   
   ...

절차

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. cluster라는 FeatureGate CR을 편집합니다.

   $ oc edit featuregate cluster

   FeatureGate 사용자 지정 리소스 샘플

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

   1

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

   2

   듀얼 스택 네트워킹 모드를 활성화하려면 IPv6DualStackNoUpgrade 기능 세트를 추가합니다.

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

   참고

   IPv6DualStackNoUpgrade 기능 세트를 활성화하면 취소할 수 없으며 업데이트를 방지할 수 없습니다. 이 기능 세트는 프로덕션 클러스터에서는 권장되지 않습니다.

1. 노드의 디버그 세션을 시작합니다.

   $ oc debug node/<node_name>

2. 루트 디렉터리를 호스트로 변경하십시오.

   sh-4.2# chroot /host

3. 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, oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.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가 표시되면 암호화가 여전히 진행 중임을 나타냅니다. 몇 분 기다린 후 다시 시도합니다.

프로세스

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가 표시되면 암호 해독이 여전히 진행 중임을 나타냅니다. 몇 분 기다린 후 다시 시도합니다.

절차

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

   $ oc debug node/<node_name>

2. 루트 디렉터리를 호스트로 변경하십시오.

   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: 이 파일에는 정적 포드 리소스가 포함되어 있습니다. etcd 암호화가 활성화되어 있는 경우 etcd 스냅 샷의 암호화 키도 포함됩니다.

     참고

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

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

절차

1. 리더가 최종 조각화 처리를 수행하므로 어떤 etcd 멤버가 리더인지 확인합니다.

   1. etcd pod 목록을 가져옵니다.

      $ oc get pods -n openshift-etcd -o wide | grep -v quorum-guard | grep etcd

      출력 예

      etcd-ip-10-0-159-225.example.redhat.com                3/3     Running     0          175m   10.0.159.225   ip-10-0-159-225.example.redhat.com   <none>           <none>
      etcd-ip-10-0-191-37.example.redhat.com                 3/3     Running     0          173m   10.0.191.37    ip-10-0-191-37.example.redhat.com    <none>           <none>
      etcd-ip-10-0-199-170.example.redhat.com                3/3     Running     0          176m   10.0.199.170   ip-10-0-199-170.example.redhat.com   <none>           <none>

   2. Pod를 선택하고 다음 명령을 실행하여 어떤 etcd 멤버가 리더인지 확인합니다.

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table

      출력 예

      Defaulting container name to etcdctl.
      Use 'oc describe pod/etcd-ip-10-0-159-225.example.redhat.com -n openshift-etcd' to see all of the containers in this pod.
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
      | https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
      | https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.4.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

      이 출력의 IS LEADER 열에 따르면 https://10.0.199.170:2379 엔드 포인트가 리더입니다. 이전 단계의 출력과 이 앤드 포인트가 일치하면 리더의 Pod 이름은 etcd-ip-10-0199-170.example.redhat.com입니다.

2. etcd 멤버를 분리합니다.

   1. 실행중인 etcd 컨테이너에 연결하고 리더가 아닌 pod 이름을 전달합니다.

      $ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com

   2. ETCDCTL_ENDPOINTS 환경 변수를 설정 해제합니다.

      sh-4.4# unset ETCDCTL_ENDPOINTS

   3. etcd 멤버를 분리합니다.

      sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag

      출력 예

      Finished defragmenting etcd member[https://localhost:2379]

      시간 초과 오류가 발생하면 명령이 성공할 때까지 --command-timeout 의 값을 늘립니다.

   4. 데이터베이스 크기가 감소되었는지 확인합니다.

      sh-4.4# etcdctl endpoint status -w table --cluster

      출력 예

      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
      | https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.4.9 |   41 MB |     false |      false |         7 |      91624 |              91624 |        | 1
      | https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.4.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
      +---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

      이 예에서는 etcd 멤버의 데이터베이스 크기가 시작 크기인 104MB와 달리 현재 41MB임을 보여줍니다.

   5. 다음 단계를 반복하여 다른 etcd 멤버에 연결하고 조각 모음을 수행합니다. 항상 리더의 조각 모음을 마지막으로 수행합니다.

      etcd pod가 복구될 수 있도록 조각 모음 작업에서 1분 이상 기다립니다. etcd pod가 복구될 때까지 etcd 멤버는 응답하지 않습니다.

3. 공간 할당량을 초과하여 NOSPACE 경고가 발생하는 경우 이를 지우십시오.

   1. NOSPACE 경고가 있는지 확인합니다.

      sh-4.4# etcdctl alarm list

      출력 예

      memberID:12345678912345678912 alarm:NOSPACE

   2. 경고를 지웁니다.

      sh-4.4# etcdctl alarm disarm

프로세스

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 | grep -v operator

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

   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 | grep -v operator

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

   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.23.3+e419edf
      host-172-25-75-38   Ready   infra,worker   3d20h   v1.23.3+e419edf
      host-172-25-75-40   Ready   master         3d20h   v1.23.3+e419edf
      host-172-25-75-65   Ready   master         3d20h   v1.23.3+e419edf
      host-172-25-75-74   Ready   infra,worker   3d20h   v1.23.3+e419edf
      host-172-25-75-79   Ready   worker         3d20h   v1.23.3+e419edf
      host-172-25-75-86   Ready   worker         3d20h   v1.23.3+e419edf
      host-172-25-75-98   Ready   infra,worker   3d20h   v1.23.3+e419edf

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

   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을 승인합니다.

    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 | grep -v operator

       출력 예

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

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

       $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep 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가 나열되어 있는 경우 몇 분 기다렸다가 다시 확인합니다.

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

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

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

    1

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

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

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

    클러스터에 액세스할 수 있는 터미널에서 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와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

14. 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와 같은 여러 버전 번호가 표시되면 이는 업데이트가 아직 진행 중임을 의미합니다. 몇 분 기다린 후 다시 시도합니다.

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

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

    $ oc get pods -n openshift-etcd | grep -v etcd-quorum-guard | grep 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/v1beta1 1
   kind: PodDisruptionBudget
   metadata:
     name: my-pdb
   spec:
     minAvailable: 2  2
     selector:  3
       matchLabels:
         foo: bar

   1

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

   2

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

   3

   리소스 집합에 대한 라벨 쿼리입니다. matchLabels 및 matchExpressions의 결과는 논리적으로 결합됩니다.

   또는 다음을 수행합니다.

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

   1

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

   2

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

   3

   리소스 집합에 대한 라벨 쿼리입니다. matchLabels 및 matchExpressions의 결과는 논리적으로 결합됩니다.

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
   vSphere	vsphere-creds

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

6. 클러스터의 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> 은 클라우드 공급자의 해당 값입니다.

      플랫폼	<provider_spec>
      AWS	AWSProviderSpec
      Azure	AzureProviderSpec
      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> -n <secret_namespace>

      여기서 <secret_name>은 시크릿의 이름이며 <secret_namespace>는 시크릿이 포함된 네임스페이스입니다.

      AWS 시크릿 삭제 예

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

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

7. 인증 정보가 변경되었는지 확인하려면 다음을 수행하십시오.

   1. 웹 콘솔의 Administrator 모드에서 Workloads → Secrets로 이동합니다.
   2. Value 필드의 내용이 이전에 기록된 정보와 다른지 확인합니다.

절차

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

2. Secrets 페이지의 표에서 AWS의 aws-creds 루트 시크릿을 찾습니다.

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

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 파일 및 클러스터 설치에 사용된 설치 프로그램이 머신에 있는지 확인합니다. 이를 수행하는 한 가지 방법으로 클러스터 설치에 사용된 머신과 동일한 머신을 사용하는 것입니다.
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.6에 필요한 리포지토리를 활성화합니다.

   # subscription-manager repos \
       --enable="rhel-7-server-rpms" \
       --enable="rhel-7-server-extras-rpms" \
       --enable="rhel-7-server-ansible-2.9-rpms" \
       --enable="rhel-7-server-ose-4.6-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.6에 필요한 리포지토리를 활성화합니다.

   # subscription-manager repos \
       --enable="rhel-7-server-rpms" \
       --enable="rhel-7-fast-datapath-rpms" \
       --enable="rhel-7-server-extras-rpms" \
       --enable="rhel-7-server-optional-rpms" \
       --enable="rhel-7-server-ose-4.6-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-rhel7-0.example.com
   mycluster-rhel7-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-local-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. 인스턴스 시작 후 TAB 또는 E 키를 눌러 커널 명령 줄을 편집합니다.

3. 커널 명령 줄에 매개 변수를 추가합니다.

   coreos.inst.install_dev=sda 1
   coreos.inst.ignition_url=http://example.com/worker.ign 2

   1

   설치할 시스템의 블록 장치를 지정합니다.

   2

   컴퓨팅 Ignition 구성 파일의 URL을 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.

4. Enter를 눌러 설치를 완료합니다. RHCOS가 설치되면 시스템을 재부팅합니다. 시스템이 재부팅되는 동안 지정된 Ignition 구성 파일을 적용합니다.
5. 계속해서 클러스터에 추가 컴퓨팅 머신을 만듭니다.

프로세스

1. RHCOS 이미지의 PXE 또는 iPXE가 올바르게 설치되었는지 확인합니다.

   • PXE의 경우:

     DEFAULT pxeboot
     TIMEOUT 20
     PROMPT 0
     LABEL pxeboot
         KERNEL http://<HTTP_server>/rhcos-<version>-live-kernel-<architecture> 1
         APPEND initrd=http://<HTTP_server>/rhcos-<version>-live-initramfs.<architecture>.img coreos.inst.install_dev=/dev/sda coreos.inst.ignition_url=http://<HTTP_server>/worker.ign coreos.live.rootfs_url=http://<HTTP_server>/rhcos-<version>-live-rootfs.<architecture>.img 2

     1

     HTTP 서버에 업로드한 라이브 kernel 파일의 위치를 지정합니다.

     2

     HTTP 서버에 업로드한 RHCOS 파일의 위치를 지정합니다. initrd 매개변수 값은 initramfs 파일의 위치이고 coreos.inst.ignition_url 매개변수 값은 작업자 Ignition 설정 파일의 위치이며 coreos.live.rootfs_url 매개 변수 값은 라이브 rootfs 파일의 위치입니다. coreos.inst.ignition_url 및 coreos.live.rootfs_url 매개변수는 HTTP 및 HTTPS만 지원합니다.

1. PXE 또는 iPXE 인프라를 사용하여 클러스터에 필요한 컴퓨팅 머신을 만듭니다.

프로세스

1. 클러스터가 시스템을 인식하는지 확인합니다.

   $ oc get nodes

   출력 예

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.19.0
   master-1  Ready     master  63m  v1.19.0
   master-2  Ready     master  64m  v1.19.0

   출력에 생성된 모든 시스템이 나열됩니다.

   참고

   이전 출력에는 일부 CSR이 승인될 때까지 컴퓨팅 노드(작업자 노드라고도 함)가 포함되지 않을 수 있습니다.

2. 보류 중인 CSR을 검토하고 클러스터에 추가한 각 시스템에 대해 Pending 또는 Approved 상태의 클라이언트 및 서버 요청이 표시되는지 확인합니다.

   $ oc get csr

   출력 예

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   예에서는 두 시스템이 클러스터에 참여하고 있습니다. 목록에는 승인된 CSR이 더 많이 나타날 수도 있습니다.

3. CSR이 승인되지 않은 경우, 추가된 시스템에 대한 모든 보류 중인 CSR이 Pending 상태로 전환된 후 클러스터 시스템의 CSR을 승인합니다.

   참고

   CSR은 교체 주기가 자동으로 만료되므로 클러스터에 시스템을 추가한 후 1시간 이내에 CSR을 승인하십시오. 한 시간 내에 승인하지 않으면 인증서가 교체되고 각 노드에 대해 두 개 이상의 인증서가 표시됩니다. 이러한 인증서를 모두 승인해야 합니다. 클라이언트 CSR이 승인되면 Kubelet은 인증서에 대한 보조 CSR을 생성하므로 수동 승인이 필요합니다. 그러면 Kubelet에서 동일한 매개변수를 사용하여 새 인증서를 요청하는 경우 인증서 갱신 요청은 machine-approver에 의해 자동으로 승인됩니다.

   참고

   베어 메탈 및 기타 사용자 프로비저닝 인프라와 같이 머신 API를 사용하도록 활성화되지 않는 플랫폼에서 실행되는 클러스터의 경우 CSR(Kubelet service Certificate Request)을 자동으로 승인하는 방법을 구현해야 합니다. 요청이 승인되지 않으면 API 서버가 kubelet에 연결될 때 서비스 인증서가 필요하므로 oc exec, oc rsh, oc logs 명령을 성공적으로 수행할 수 없습니다. Kubelet 엔드 포인트에 연결하는 모든 작업을 수행하려면 이 인증서 승인이 필요합니다. 이 방법은 새 CSR을 감시하고 CSR이 system:node 또는 system:admin 그룹의 node-bootstrapper 서비스 계정에 의해 제출되었는지 확인하고 노드의 ID를 확인합니다.

   • 개별적으로 승인하려면 유효한 CSR 각각에 대해 다음 명령을 실행하십시오.

     $ oc adm certificate approve <csr_name> 1

     1

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

   • 보류 중인 CSR을 모두 승인하려면 다음 명령을 실행하십시오.

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

     참고

     일부 Operator는 일부 CSR이 승인될 때까지 사용할 수 없습니다.

4. 이제 클라이언트 요청이 승인되었으므로 클러스터에 추가한 각 머신의 서버 요청을 검토해야 합니다.

   $ oc get csr

   출력 예

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. 나머지 CSR이 승인되지 않고 Pending 상태인 경우 클러스터 머신의 CSR을 승인합니다.

   • 개별적으로 승인하려면 유효한 CSR 각각에 대해 다음 명령을 실행하십시오.

     $ oc adm certificate approve <csr_name> 1

     1

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

   • 보류 중인 CSR을 모두 승인하려면 다음 명령을 실행하십시오.

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

6. 모든 클라이언트 및 서버 CSR이 승인된 후 머신은 Ready 상태가 됩니다. 다음 명령을 실행하여 확인합니다.

   $ oc get nodes

   출력 예

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.20.0
   master-1  Ready     master  73m  v1.20.0
   master-2  Ready     master  74m  v1.20.0
   worker-0  Ready     worker  11m  v1.20.0
   worker-1  Ready     worker  11m  v1.20.0

   참고

   머신이 Ready 상태로 전환하는 데 서버 CSR의 승인 후 몇 분이 걸릴 수 있습니다.

프로세스

1. 머신 상태 점검 정의가 포함된 healthcheck.yml 파일을 생성합니다.

2. healthcheck.yml 파일을 클러스터에 적용합니다.

   $ oc apply -f healthcheck.yml

절차

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/cluster-api-delete-machine="true"

4. 삭제하려는 노드를 비우고 제외합니다.

   $ oc adm cordon <node_name>
   $ oc adm drain <node_name>

5. 머신 세트를 스케일링합니다.

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

   또는 다음을 수행합니다.

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

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

절차

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

   $ oc get machineconfig

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

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

   # oc describe node <node-ip> | grep Allocatable -A6

   value: pods: <value>를 찾습니다.

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

   # oc describe node ip-172-31-128-158.us-east-2.compute.internal | grep Allocatable -A6

   출력 예

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

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

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

   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: large-pods
     kubeletConfig:
       maxPods: <pod_count>
       kubeAPIBurst: <burst_rate>
       kubeAPIQPS: <QPS>

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

      $ oc label machineconfigpool worker custom-kubelet=large-pods

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

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

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

      $ oc get kubeletconfig

      set-max-pods가 반환됩니다.

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

4. 작업자 노드의 maxPods 변경사항을 확인합니다.

   $ oc describe node

   1. 다음을 실행하여 변경사항을 검증합니다.

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

      True 및 type:Success 상태가 표시되어야 합니다.

1. worker 머신 구성 풀을 편집합니다.

   $ oc edit machineconfigpool worker

2. maxUnavailable을 원하는 값으로 설정합니다.

   spec:
     maxUnavailable: <node_count>

   중요

   값을 설정하는 경우 클러스터에서 실행 중인 애플리케이션에 영향을 미치지 않고 사용 가능한 상태로 둘 수 있는 작업자 노드 수를 고려하십시오.

절차

1. 선택 사항: 노드에 레이블을 지정합니다.

   # oc label node perf-node.example.com cpumanager=true

2. CPU 관리자를 활성화해야 하는 노드의 MachineConfigPool을 편집합니다. 이 예에서는 모든 작업자의 CPU 관리자가 활성화됩니다.

   # oc edit machineconfigpool worker

3. 작업자 머신 구성 풀에 레이블을 추가합니다.

   metadata:
     creationTimestamp: 2020-xx-xxx
     generation: 3
     labels:
       custom-kubelet: cpumanager-enabled

4. KubeletConfig, cpumanager-kubeletconfig.yaml, CR(사용자 정의 리소스)을 생성합니다. 이전 단계에서 생성한 레이블을 참조하여 올바른 노드가 새 kubelet 구성으로 업데이트되도록 합니다. machineConfigPoolSelector 섹션을 참조하십시오.

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: cpumanager-enabled
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: cpumanager-enabled
     kubeletConfig:
        cpuManagerPolicy: static 1
        cpuManagerReconcilePeriod: 5s 2

   1

   정책을 지정합니다.

   • none. 이 정책은 기존 기본 CPU 선호도 체계를 명시적으로 활성화하여 스케줄러가 자동으로 수행하는 것 이상으로 선호도를 제공하지 않도록 합니다.
   • static. 이 정책을 사용하면 노드에서 특정 리소스 특성을 가진 Pod에 더 높은 CPU 선호도 및 배타성이 부여되도록 할 수 있습니다.

   2

   선택사항입니다. CPU 관리자 조정 빈도를 지정합니다. 기본값은 5s입니다.

5. 동적 kubelet 구성을 생성합니다.

   # oc create -f cpumanager-kubeletconfig.yaml

   그러면 kubelet 구성에 CPU 관리자 기능이 추가되고 필요한 경우 MCO(Machine Config Operator)가 노드를 재부팅합니다. CPU 관리자를 활성화하는 데는 재부팅이 필요하지 않습니다.

6. 병합된 kubelet 구성을 확인합니다.

   # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7

   출력 예

          "ownerReferences": [
               {
                   "apiVersion": "machineconfiguration.openshift.io/v1",
                   "kind": "KubeletConfig",
                   "name": "cpumanager-enabled",
                   "uid": "7ed5616d-6b72-11e9-aae1-021e1ce18878"
               }
           ]

7. 작업자에서 업데이트된 kubelet.conf를 확인합니다.

   # oc debug node/perf-node.example.com
   sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager

   출력 예

   cpuManagerPolicy: static        1
   cpuManagerReconcilePeriod: 5s   2

   1 2

   이러한 설정은 KubeletConfig CR을 생성할 때 정의됩니다.

8. 코어를 하나 이상 요청하는 Pod를 생성합니다. 제한 및 요청 둘 다 해당 CPU 값이 정수로 설정되어야 합니다. 해당 숫자는 이 Pod 전용으로 사용할 코어 수입니다.

   # cat cpumanager-pod.yaml

   출력 예

   apiVersion: v1
   kind: Pod
   metadata:
     generateName: cpumanager-
   spec:
     containers:
     - name: cpumanager
       image: gcr.io/google_containers/pause-amd64:3.0
       resources:
         requests:
           cpu: 1
           memory: "1G"
         limits:
           cpu: 1
           memory: "1G"
     nodeSelector:
       cpumanager: "true"

9. Pod를 생성합니다.

   # oc create -f cpumanager-pod.yaml

10. 레이블 지정한 노드에 Pod가 예약되어 있는지 검증합니다.

    # oc describe pod cpumanager

    출력 예

    Name:               cpumanager-6cqz7
    Namespace:          default
    Priority:           0
    PriorityClassName:  <none>
    Node:  perf-node.example.com/xxx.xx.xx.xxx
    ...
     Limits:
          cpu:     1
          memory:  1G
        Requests:
          cpu:        1
          memory:     1G
    ...
    QoS Class:       Guaranteed
    Node-Selectors:  cpumanager=true

11. cgroups가 올바르게 설정되었는지 검증합니다. pause 프로세스의 PID(프로세스 ID)를 가져옵니다.

    # ├─init.scope
    │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
    └─kubepods.slice
      ├─kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice
      │ ├─crio-b5437308f1a574c542bdf08563b865c0345c8f8c0b0a655612c.scope
      │ └─32706 /pause

    QoS(Quality of Service) 계층 Guaranteed의 Pod는 kubepods.slice에 있습니다. 다른 QoS 계층의 Pod는 kubepods의 하위 cgroups에 있습니다.

    # cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
    # for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; done

    출력 예

    cpuset.cpus 1
    tasks 32706

12. 작업에 허용되는 CPU 목록을 확인합니다.

    # grep ^Cpus_allowed_list /proc/32706/status

    출력 예

     Cpus_allowed_list:    1

13. Guaranteed Pod용으로 할당된 코어에서는 시스템의 다른 Pod(이 경우 burstable QoS 계층의 Pod)를 실행할 수 없는지 검증합니다.

    # cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
    0
    # oc describe node perf-node.example.com

    출력 예

    ...
    Capacity:
     attachable-volumes-aws-ebs:  39
     cpu:                         2
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      8162900Ki
     pods:                        250
    Allocatable:
     attachable-volumes-aws-ebs:  39
     cpu:                         1500m
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      7548500Ki
     pods:                        250
    -------                               ----                           ------------  ----------  ---------------  -------------  ---
      default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m
    
    Allocated resources:
      (Total limits may be over 100 percent, i.e., overcommitted.)
      Resource                    Requests          Limits
      --------                    --------          ------
      cpu                         1440m (96%)       1 (66%)

    이 VM에는 두 개의 CPU 코어가 있습니다. system-reserved 설정은 500밀리코어로 설정되었습니다. 즉, Node Allocatable 양이 되는 노드의 전체 용량에서 한 코어의 절반이 감산되었습니다. Allocatable CPU는 1500 밀리코어임을 확인할 수 있습니다. 즉, Pod마다 하나의 전체 코어를 사용하므로 CPU 관리자 Pod 중 하나를 실행할 수 있습니다. 전체 코어는 1000밀리코어에 해당합니다. 두 번째 Pod를 예약하려고 하면 시스템에서 해당 Pod를 수락하지만 Pod가 예약되지 않습니다.

    NAME                    READY   STATUS    RESTARTS   AGE
    cpumanager-6cqz7        1/1     Running   0          33m
    cpumanager-7qc2t        0/1     Pending   0          11s

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

   1. Machine config를 표시합니다:

      # oc describe machineconfig <name>

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

      # oc describe machineconfig 00-worker

      출력 예

      Name:         00-worker
      Namespace:
      Labels:       machineconfiguration.openshift.io/role=worker 1

      1

      장치 관리자에 필요한 라벨입니다.

프로세스

1. 구성 변경을 위한 사용자 정의 리소스 (CR)를 만듭니다.

   장치 관리자 CR의 설정 예

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: devicemgr 1
   spec:
     machineConfigPoolSelector:
       matchLabels:
          machineconfiguration.openshift.io: devicemgr 2
     kubeletConfig:
       feature-gates:
         - DevicePlugins=true 3

   1

   CR에 이름을 지정합니다.

   2

   Machine Config Pool에서 라벨을 입력합니다.

   3

   DevicePlugins를 'true'로 설정합니다.

2. 장치 관리자를 만듭니다.

   $ oc create -f devicemgr.yaml

   출력 예

   kubeletconfig.machineconfiguration.openshift.io/devicemgr created

3. 노드에서 /var/lib/kubelet/device-plugins/kubelet.sock이 작성되었는지 확인하여 장치 관리자가 실제로 사용 가능한지 확인합니다. 이는 장치 관리자의 gRPC 서버가 새 플러그인 등록을 수신하는 UNIX 도메인 소켓입니다. 이 소켓 파일은 장치 관리자가 활성화된 경우에만 Kubelet을 시작할 때 생성됩니다.

프로세스

1. tolerations 스탠자를 포함하도록 Pod 사양을 편집하여 Pod에 허용 오차를 추가합니다.

   Equal 연산자가 있는 Pod 구성 파일 샘플

   spec:
   ....
     template:
   ....
       spec:
         tolerations:
         - key: "key1" 1
           value: "value1"
           operator: "Equal"
           effect: "NoExecute"
           tolerationSeconds: 3600 2

   1

   테인트 및 허용 오차 구성 요소 테이블에 설명된 허용 오차 매개변수입니다.

   2

   tolerationSeconds 매개변수를 지정하여 pod가 제거되기 전까지 노드에 바인딩되는 시간을 설정합니다.

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

   Exists 연산자가 있는 Pod 구성 파일 샘플

   spec:
   ....
     template:
   ....
       spec:
         tolerations:
         - key: "key1"
           operator: "Exists" 1
           effect: "NoExecute"
           tolerationSeconds: 3600

   1

   Exists 연산자는 value를 사용하지 않습니다.

   이 예에서는 key key1, value value1, 테인트 effect NoExecute를 갖는 node1에 테인트를 배치합니다.

2. 테인트 및 허용 오차 구성 요소 테이블에 설명된 매개변수로 다음 명령을 사용하여 노드에 테인트를 추가합니다.

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

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

   $ oc adm taint nodes node1 key1=value1:NoExecute

   이 명령은 키가 key1, 값이 value1, 효과가 NoExecute인 node1에 테인트를 배치합니다.

   참고

   컨트롤 플레인 노드 (마스터 노드라고도 함)에 NoSchedule 테인트를 추가하는 경우 노드에 기본적으로 추가되는 node-role.kubernetes.io/master=:NoSchedule 테인트가 있어야 합니다.

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

   apiVersion: v1
   kind: Node
   metadata:
     annotations:
       machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
       machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
   ...
   spec:
     taints:
     - effect: NoSchedule
       key: node-role.kubernetes.io/master
   ...

   Pod의 허용 오차가 노드의 테인트와 일치합니다. 허용 오차 중 하나가 있는 Pod를 node1에 예약할 수 있습니다.

프로세스

1. tolerations 스탠자를 포함하도록 Pod 사양을 편집하여 Pod에 허용 오차를 추가합니다.

   Equal 연산자가 있는 Pod 구성 파일의 예

   spec:
   ....
     template:
   ....
       spec:
         tolerations:
         - key: "key1" 1
           value: "value1"
           operator: "Equal"
           effect: "NoExecute"
           tolerationSeconds: 3600 2

   1

   테인트 및 허용 오차 구성 요소 테이블에 설명된 허용 오차 매개변수입니다.

   2

   tolerationSeconds 매개변수는 Pod가 제거될 때까지 노드에 바인딩되는 시간을 지정합니다.

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

   Exists 연산자가 있는 pod 구성 파일의 예

   spec:
     tolerations:
     - key: "key1"
       operator: "Exists"
       effect: "NoExecute"
       tolerationSeconds: 3600

2. MachineSet 오브젝트에 테인트를 추가합니다.

   1. 테인트할 노드의 MachineSet YAML을 편집하거나 새 MachineSet 오브젝트를 생성할 수 있습니다.

      $ oc edit machineset <machineset>

   2. spec.template.spec 섹션에 테인트를 추가합니다.

      머신 세트 사양의 테인트 예

      spec:
      ....
        template:
      ....
          spec:
            taints:
            - effect: NoExecute
              key: key1
              value: value1
      ....

      이 예제에서는 키가 key1, 값이 value1, 테인트 효과가 NoExecute인 테인트를 노드에 배치합니다.

   3. 머신 세트를 0 으로 축소합니다.

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

      머신이 제거될 때까지 기다립니다.

   4. 필요에 따라 머신 세트를 확장합니다.

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

      머신이 시작될 때까지 기다립니다. 테인트는 MachineSet 오브젝트와 연결된 노드에 추가됩니다.

1. 해당 노드에 해당 테인트를 추가합니다.

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

   $ oc adm taint nodes node1 dedicated=groupName:NoSchedule

2. 사용자 정의 승인 컨트롤러를 작성하여 Pod에 허용 오차를 추가합니다.

1. 특수 하드웨어가 필요한 Pod에 허용 오차를 추가합니다.

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

   spec:
     tolerations:
       - key: "disktype"
         value: "ssd"
         operator: "Equal"
         effect: "NoSchedule"
         tolerationSeconds: 3600

2. 다음 명령 중 하나를 사용하여 특수 하드웨어가 있는 노드에 테인트를 설정합니다.

   $ oc adm taint nodes <node-name> disktype=ssd:NoSchedule

   또는 다음을 수행합니다.

   $ oc adm taint nodes <node-name> disktype=ssd:PreferNoSchedule

1. 노드에서 테인트를 제거하려면 다음을 수행합니다.

   $ oc adm taint nodes <node-name> <key>-

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

   $ oc adm taint nodes ip-10-0-132-248.ec2.internal key1-

   출력 예

   node/ip-10-0-132-248.ec2.internal untainted

2. Pod에서 Pod 사양을 편집하여 톨러레이션을 제거합니다.

   spec:
     tolerations:
     - key: "key2"
       operator: "Exists"
       effect: "NoExecute"
       tolerationSeconds: 3600

1. cpumanager-enabled CR(사용자 정의 리소스)에서 토폴로지 관리자 할당 정책을 구성합니다.

   $ oc edit KubeletConfig cpumanager-enabled

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: cpumanager-enabled
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: cpumanager-enabled
     kubeletConfig:
        cpuManagerPolicy: static 1
        cpuManagerReconcilePeriod: 5s
        topologyManagerPolicy: single-numa-node 2

   1

   이 매개변수는 static이어야 합니다.

   2

   선택한 토폴로지 관리자 할당 정책을 지정합니다. 여기서는 정책이 single-numa-node입니다. 사용할 수 있는 값은 default, best-effort, restricted, single-numa-node입니다.

1. OpenShift Container Platform 웹 콘솔에서 Home → Projects로 이동합니다.

   1. Create Project를 클릭합니다.
   2. clusterresourceoverride-operator를 프로젝트 이름으로 지정합니다.
   3. Create를 클릭합니다.

2. Operators → OperatorHub로 이동합니다.

   1. 사용 가능한 Operator 목록에서 ClusterResourceOverride Operator를 선택한 다음 Install을 클릭합니다.
   2. Operator 설치 페이지에서 설치 모드에 대해 클러스터의 특정 네임스페이스가 선택되어 있는지 확인합니다.
   3. Installed Namespace에 대해 clusterresourceoverride-operator가 선택되어 있는지 확인합니다.
   4. Update Channel 및 Approval Strategy를 선택합니다.
   5. 설치를 클릭합니다.

3. Installed Operators 페이지에서 ClusterResourceOverride를 클릭합니다.

   1. ClusterResourceOverride Operator 상세 페이지에서 Create Instance를 클릭합니다.

   2. Create ClusterResourceOverride 페이지에서 YAML 템플릿을 편집하여 필요에 따라 오버 커밋 값을 설정합니다.

      apiVersion: operator.autoscaling.openshift.io/v1
      kind: ClusterResourceOverride
      metadata:
        name: cluster 1
      spec:
        podResourceOverride:
          spec:
            memoryRequestToLimitPercent: 50 2
            cpuRequestToLimitPercent: 25 3
            limitCPUToMemoryPercent: 200 4

      1

      이름은 instance이어야 합니다.

      2

      선택 사항입니다. 컨테이너 메모리 제한을 덮어 쓰기하는 경우 1-100 사이의 백분율로 지정합니다. 기본값은 50입니다.

      3

      선택 사항입니다. 컨테이너 CPU 제한을 덮어 쓰기하는 경우 1-100 사이의 백분율로 지정합니다. 기본값은 25입니다.

      4

      선택 사항입니다. 컨테이너 메모리 제한을 덮어 쓰기하는 경우 백분율로 지정합니다 (사용되는 경우). 1Gi의 RAM을 100 %로 스케일링하는 것은 1 개의 CPU 코어와 같습니다. CPU 요청을 덮어 쓰기하기 전에 처리됩니다 (설정된 경우). 기본값은 200입니다.

   3. Create를 클릭합니다.

4. 클러스터 사용자 정의 리소스 상태를 확인하여 승인 Webhook의 현재 상태를 확인합니다.

   1. ClusterResourceOverride Operator 페이지에서 cluster를 클릭합니다.

   2. ClusterResourceOverride Details 페이지에서 YAML을 클릭합니다. webhook 호출 시 mutatingWebhookConfigurationRef 섹션이 표시됩니다.

      apiVersion: operator.autoscaling.openshift.io/v1
      kind: ClusterResourceOverride
      metadata:
        annotations:
          kubectl.kubernetes.io/last-applied-configuration: |
            {"apiVersion":"operator.autoscaling.openshift.io/v1","kind":"ClusterResourceOverride","metadata":{"annotations":{},"name":"cluster"},"spec":{"podResourceOverride":{"spec":{"cpuRequestToLimitPercent":25,"limitCPUToMemoryPercent":200,"memoryRequestToLimitPercent":50}}}}
        creationTimestamp: "2019-12-18T22:35:02Z"
        generation: 1
        name: cluster
        resourceVersion: "127622"
        selfLink: /apis/operator.autoscaling.openshift.io/v1/clusterresourceoverrides/cluster
        uid: 978fc959-1717-4bd1-97d0-ae00ee111e8d
      spec:
        podResourceOverride:
          spec:
            cpuRequestToLimitPercent: 25
            limitCPUToMemoryPercent: 200
            memoryRequestToLimitPercent: 50
      status:
      
      ....
      
          mutatingWebhookConfigurationRef: 1
            apiVersion: admissionregistration.k8s.io/v1beta1
            kind: MutatingWebhookConfiguration
            name: clusterresourceoverrides.admission.autoscaling.openshift.io
            resourceVersion: "127621"
            uid: 98b3b8ae-d5ce-462b-8ab5-a729ea8f38f3
      
      ....

      1

      ClusterResourceOverride 승인 Webhook 참조

1. Cluster Resource Override Operator의 네임스페이스를 생성합니다.

   1. Cluster Resource Override Operator의 Namespace 오브젝트 YAML 파일(예: cro-namespace.yaml)을 생성합니다.

      apiVersion: v1
      kind: Namespace
      metadata:
        name: clusterresourceoverride-operator

   2. 네임스페이스를 생성합니다.

      $ oc create -f <file-name>.yaml

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

      $ oc create -f cro-namespace.yaml

2. Operator 그룹을 생성합니다.

   1. Cluster Resource Override Operator의 OperatorGroup 오브젝트 YAML 파일(예: cro-og.yaml)을 생성합니다.

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: clusterresourceoverride-operator
        namespace: clusterresourceoverride-operator
      spec:
        targetNamespaces:
          - clusterresourceoverride-operator

   2. Operator 그룹을 생성합니다.

      $ oc create -f <file-name>.yaml

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

      $ oc create -f cro-og.yaml

3. 서브스크립션을 생성합니다.

   1. Cluster Resource Override Operator의 Subscription 오브젝트 YAML 파일(예: cro-sub.yaml)을 생성합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: clusterresourceoverride
        namespace: clusterresourceoverride-operator
      spec:
        channel: "4.6"
        name: clusterresourceoverride
        source: redhat-operators
        sourceNamespace: openshift-marketplace

   2. 서브스크립션을 생성합니다.

      $ oc create -f <file-name>.yaml

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

      $ oc create -f cro-sub.yaml

4. clusterresourceoverride-operator 네임 스페이스에서 ClusterResourceOverride 사용자 지정 리소스 (CR) 오브젝트를 만듭니다.

   1. clusterresourceoverride-operator 네임 스페이스로 변경합니다.

      $ oc project clusterresourceoverride-operator

   2. Cluster Resource Override Operator의 ClusterResourceOverride 오브젝트 YAML 파일 (예: cro-cr.yaml)을 만듭니다.

      apiVersion: operator.autoscaling.openshift.io/v1
      kind: ClusterResourceOverride
      metadata:
          name: cluster 1
      spec:
        podResourceOverride:
          spec:
            memoryRequestToLimitPercent: 50 2
            cpuRequestToLimitPercent: 25 3
            limitCPUToMemoryPercent: 200 4

      1

      이름은 instance이어야 합니다.

      2

      선택 사항입니다. 컨테이너 메모리 제한을 덮어 쓰기하는 경우 1-100 사이의 백분율로 지정합니다. 기본값은 50입니다.

      3

      선택 사항입니다. 컨테이너 CPU 제한을 덮어 쓰기하는 경우 1-100 사이의 백분율로 지정합니다. 기본값은 25입니다.

      4

      선택 사항입니다. 컨테이너 메모리 제한을 덮어 쓰기하는 경우 백분율로 지정합니다 (사용되는 경우). 1Gi의 RAM을 100 %로 스케일링하는 것은 1 개의 CPU 코어와 같습니다. CPU 요청을 덮어 쓰기하기 전에 처리됩니다 (설정된 경우). 기본값은 200입니다.

   3. ClusterResourceOverride 오브젝트를 만듭니다.

      $ oc create -f <file-name>.yaml

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

      $ oc create -f cro-cr.yaml

5. 클러스터 사용자 정의 리소스의 상태를 확인하여 승인 Webhook의 현재 상태를 확인합니다.

   $ oc get clusterresourceoverride cluster -n clusterresourceoverride-operator -o yaml

   webhook 호출 시 mutatingWebhookConfigurationRef 섹션이 표시됩니다.

   출력 예

   apiVersion: operator.autoscaling.openshift.io/v1
   kind: ClusterResourceOverride
   metadata:
     annotations:
       kubectl.kubernetes.io/last-applied-configuration: |
         {"apiVersion":"operator.autoscaling.openshift.io/v1","kind":"ClusterResourceOverride","metadata":{"annotations":{},"name":"cluster"},"spec":{"podResourceOverride":{"spec":{"cpuRequestToLimitPercent":25,"limitCPUToMemoryPercent":200,"memoryRequestToLimitPercent":50}}}}
     creationTimestamp: "2019-12-18T22:35:02Z"
     generation: 1
     name: cluster
     resourceVersion: "127622"
     selfLink: /apis/operator.autoscaling.openshift.io/v1/clusterresourceoverrides/cluster
     uid: 978fc959-1717-4bd1-97d0-ae00ee111e8d
   spec:
     podResourceOverride:
       spec:
         cpuRequestToLimitPercent: 25
         limitCPUToMemoryPercent: 200
         memoryRequestToLimitPercent: 50
   status:
   
   ....
   
       mutatingWebhookConfigurationRef: 1
         apiVersion: admissionregistration.k8s.io/v1beta1
         kind: MutatingWebhookConfiguration
         name: clusterresourceoverrides.admission.autoscaling.openshift.io
         resourceVersion: "127621"
         uid: 98b3b8ae-d5ce-462b-8ab5-a729ea8f38f3
   
   ....

   1

   ClusterResourceOverride 승인 Webhook 참조

1. ClusterResourceOverride CR을 편집합니다.

   apiVersion: operator.autoscaling.openshift.io/v1
   kind: ClusterResourceOverride
   metadata:
       name: cluster
   spec:
     podResourceOverride:
       spec:
         memoryRequestToLimitPercent: 50 1
         cpuRequestToLimitPercent: 25 2
         limitCPUToMemoryPercent: 200 3

   1

   선택 사항입니다. 컨테이너 메모리 제한을 덮어 쓰기하는 경우 1-100 사이의 백분율로 지정합니다. 기본값은 50입니다.

   2

   선택 사항입니다. 컨테이너 CPU 제한을 덮어 쓰기하는 경우 1-100 사이의 백분율로 지정합니다. 기본값은 25입니다.

   3

   선택 사항입니다. 컨테이너 메모리 제한을 덮어 쓰기하는 경우 백분율로 지정합니다 (사용되는 경우). 1Gi의 RAM을 100 %로 스케일링하는 것은 1 개의 CPU 코어와 같습니다. CPU 요청을 덮어 쓰기하기 전에 처리됩니다 (설정된 경우). 기본값은 200입니다.

2. Cluster Resource Override Operator가 오버 커밋을 제어해야 하는 각 프로젝트의 네임 스페이스 오브젝트에 다음 라벨이 추가되었는지 확인합니다.

   apiVersion: v1
   kind: Namespace
   metadata:
   
    ...
   
     labels:
       clusterresourceoverrides.admission.autoscaling.openshift.io/enabled: "true" 1
   
    ...

   1

   이 라벨을 각 프로젝트에 추가합니다.

사전 요구 사항

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

   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: small-pods 1

      1

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

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

      $ oc label machineconfigpool worker custom-kubelet=small-pods

프로세스

1. 구성 변경을 위한 사용자 정의 리소스 (CR)를 만듭니다.

   CPU 제한 비활성화를 위한 설정 예

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: disable-cpu-units 1
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: small-pods 2
     kubeletConfig:
       cpuCfsQuota: 3
         - "false"

   1

   CR에 이름을 지정합니다.

   2

   구성 변경 사항을 적용하려면 라벨을 지정합니다.

   3

   cpuCfsQuota 매개변수를 false로 설정합니다.

1. 프로젝트의 오브젝트 파일 편집합니다.

2. 다음 주석을 추가합니다.

   quota.openshift.io/cluster-resource-override-enabled: "false"

3. 프로젝트 오브젝트를 생성합니다.

   $ oc create -f <file-name>.yaml

1. 하나 이상의 Pod에서 현재 실행중인 이미지 목록입니다.
2. 호스트에서 사용 가능한 이미지 목록입니다.

사전 요구 사항

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

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

      $ oc describe machineconfigpool <name>

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

      $ oc describe machineconfigpool worker

      출력 예

      Name:         worker
      Namespace:
      Labels:       custom-kubelet=small-pods 1

      1

      레이블이 추가되면 Labels 아래에 표시됩니다.

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

      $ oc label machineconfigpool worker custom-kubelet=small-pods

프로세스

1. 구성 변경을 위한 사용자 정의 리소스 (CR)를 만듭니다.

   중요

   하나의 파일 시스템이 있거나 /var/lib/kubelet 및 /var/lib/containers/ 가 동일한 파일 시스템에 있는 경우 값이 가장 높은 설정이 먼저 충족되므로 제거를 트리거합니다. 파일 시스템이 제거를 트리거합니다.

   컨테이너 가비지 컬렉션 CR의 설정 예:

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: worker-kubeconfig 1
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: small-pods 2
     kubeletConfig:
       evictionSoft: 3
         memory.available: "500Mi" 4
         nodefs.available: "10%"
         nodefs.inodesFree: "5%"
         imagefs.available: "15%"
         imagefs.inodesFree: "10%"
       evictionSoftGracePeriod:  5
         memory.available: "1m30s"
         nodefs.available: "1m30s"
         nodefs.inodesFree: "1m30s"
         imagefs.available: "1m30s"
         imagefs.inodesFree: "1m30s"
       evictionHard: 6
         memory.available: "200Mi"
         nodefs.available: "5%"
         nodefs.inodesFree: "4%"
         imagefs.available: "10%"
         imagefs.inodesFree: "5%"
       evictionPressureTransitionPeriod: 0s 7
       imageMinimumGCAge: 5m 8
       imageGCHighThresholdPercent: 80 9
       imageGCLowThresholdPercent: 75 10

   1

   오브젝트의 이름입니다.

   2

   선택기 라벨입니다.

   3

   제거 유형: evictionSoft 또는 evictionHard.

   4

   특정 제거 트리거 신호에 따른 제거 임계값입니다.

   5

   소프트 제거의 유예 기간입니다. 이 매개변수는 eviction-hard에는 적용되지 않습니다.

   6

   특정 제거 트리거 신호에 따른 제거 임계값입니다. evictionHard 의 경우 이러한 모든 매개변수를 지정해야 합니다. 모든 매개변수를 지정하지 않으면 지정된 매개변수만 적용되고 가비지 컬렉션이 제대로 작동하지 않습니다.

   7

   제거 부족 상태에서 전환하기 전에 대기하는 시간입니다.

   8

   가비지 컬렉션에 의해 이미지가 제거되기 전에 사용되지 않은 이미지의 최소 보존 기간입니다.

   9

   이미지 가비지 컬렉션을 트리거하는 디스크 사용량의 백분율 (정수로 표시)입니다.

   10

   이미지 가비지 컬렉션이 해제하려고 하는 디스크 사용량의 백분율 (정수로 표시)입니다.

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

   $ oc create -f <file-name>.yaml

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

   $ oc create -f gc-container.yaml

   출력 예

   kubeletconfig.machineconfiguration.openshift.io/gc-container created

3. 가비지 컬렉션이 활성화되어 있는지 확인합니다. 사용자 지정 리소스에 지정한 Machine Config Pool은 변경 사항이 완전히 구현될 때까지 UPDATING과 함께 'true'로 표시됩니다.

   $ oc get machineconfigpool

   출력 예

   NAME     CONFIG                                   UPDATED   UPDATING
   master   rendered-master-546383f80705bd5aeaba93   True      False
   worker   rendered-worker-b4c51bb33ccaae6fc4a6a5   False     True

프로세스

1. 다음을 실행합니다.

   $ oc get Tuned/default -o yaml -n openshift-cluster-node-tuning-operator

절차

1. 다음과 같이 정책 규칙을 생성합니다.

   1. <policy_name>.yaml 파일을 생성합니다.

      $ touch <policy_name>.yaml

      다음과 같습니다.

      <policy_name>

      네트워크 정책 파일 이름을 지정합니다.

   2. 방금 만든 파일에서 다음 예와 같이 네트워크 정책을 정의합니다.

      모든 네임스페이스의 모든 Pod에서 수신 거부

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: deny-by-default
      spec:
        podSelector:
        ingress: []

      동일한 네임 스페이스에 있는 모든 Pod의 수신 허용

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}

2. 다음 명령을 실행하여 네트워크 정책 오브젝트를 생성합니다.

   $ oc apply -f <policy_name>.yaml -n <namespace>

   다음과 같습니다.

   <policy_name>

   네트워크 정책 파일 이름을 지정합니다.

   <namespace>

   선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 네임스페이스를 지정합니다.

   출력 예

   networkpolicy "default-deny" created

프로세스

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

   1. 이름이 allow-from-openshift-ingress인 정책입니다.

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-ingress
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                policy-group.network.openshift.io/ingress: ""
        podSelector: {}
        policyTypes:
        - Ingress
      EOF

   2. 이름이 allow-from-openshift-monitoring인 정책:

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-monitoring
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: monitoring
        podSelector: {}
        policyTypes:
        - Ingress
      EOF

   3. 이름이 allow-same-namespace인 정책:

      $ cat << EOF| oc create -f -
      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
      EOF

2. 선택 사항: 네트워크 정책이 현재 프로젝트에 있는지 확인하려면 다음 명령을 입력합니다.

   $ oc describe networkpolicy

   출력 예

   Name:         allow-from-openshift-ingress
   Namespace:    example1
   Created on:   2020-06-09 00:28:17 -0400 EDT
   Labels:       <none>
   Annotations:  <none>
   Spec:
     PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
     Allowing ingress traffic:
       To Port: <any> (traffic allowed to all ports)
       From:
         NamespaceSelector: network.openshift.io/policy-group: ingress
     Not affecting egress traffic
     Policy Types: Ingress
   
   
   Name:         allow-from-openshift-monitoring
   Namespace:    example1
   Created on:   2020-06-09 00:29:57 -0400 EDT
   Labels:       <none>
   Annotations:  <none>
   Spec:
     PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
     Allowing ingress traffic:
       To Port: <any> (traffic allowed to all ports)
       From:
         NamespaceSelector: network.openshift.io/policy-group: monitoring
     Not affecting egress traffic
     Policy Types: Ingress

프로세스

1. cluster-admin 권한이 있는 사용자로 로그인합니다.

2. 기본 프로젝트 템플릿을 생성합니다.

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. 텍스트 편집기를 사용하여 오브젝트를 추가하거나 기존 오브젝트를 수정하여 생성된 template.yaml 파일을 수정합니다.

4. 프로젝트 템플릿은 openshift-config 네임스페이스에서 생성해야 합니다. 수정된 템플릿을 불러옵니다.

   $ oc create -f template.yaml -n openshift-config

5. 웹 콘솔 또는 CLI를 사용하여 프로젝트 구성 리소스를 편집합니다.

   • 웹 콘솔에 액세스:

     1. 관리 → 클러스터 설정으로 이동합니다.
     2. 전역 구성을 클릭하여 모든 구성 리소스를 확인합니다.
     3. 프로젝트 항목을 찾아 YAML 편집을 클릭합니다.

   • CLI 사용:

     1. 다음과 같이 project.config.openshift.io/cluster 리소스를 편집합니다.

        $ oc edit project.config.openshift.io/cluster

6. projectRequestTemplate 및 name 매개변수를 포함하도록 spec 섹션을 업데이트하고 업로드된 프로젝트 템플릿의 이름을 설정합니다. 기본 이름은 project-request입니다.

   사용자 정의 프로젝트 템플릿이 포함된 프로젝트 구성 리소스

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestTemplate:
       name: <template_name>

7. 변경 사항을 저장한 후 새 프로젝트를 생성하여 변경 사항이 성공적으로 적용되었는지 확인합니다.