클러스터, 작업자 노드 및 클러스터 컴포넌트 업데이트

클러스터 마스터 업데이트 단계

시작하기 전에, ‘운영자’ 또는 ‘관리자’ IAM 플랫폼 액세스 역할을 보유하고 있는지 확인하십시오.

CA(인증 기관) 인증서 로테이션이 진행 중인 경우 클러스터 마스터에 대한 업데이트가 차단됩니다. 클러스터 마스터를 업데이트하기 전에 로테이션이 완료될 때까지 기다립니다.

Red Hat OpenShift 마스터 주 또는 부 버전을 업데이트하려면 다음 작업을 수행하십시오.

1. Red Hat OpenShift on IBM Cloud 버전 정보 를 검토하고 _마스터 이전에 업데이트_로 표시된 업데이트를 작성하십시오.

2. Kubernetes 유용한 주의사항(예: 사용 중단 공지 등)을 모두 검토하십시오.

3. 클러스터에 설치한 각 추가 기능 및 플러그인에 대해 클러스터 버전 업데이트로 인해 발생할 수 있는 영향을 확인하십시오.

   • 추가 기능 확인

     1. 클러스터 내의 추가 기능을 나열하십시오.

        ibmcloud oc cluster addon ls --cluster CLUSTER
        

     2. 설치된 각 추가 기능에 대해 지원되는 Red Hat OpenShift버전을 확인하십시오.

        ibmcloud oc addon-versions
        

     3. 클러스터를 업데이트하려는 Red Hat OpenShift 버전에서 실행되도록 추가 기능을 업데이트해야 하는 경우 추가 기능을 업데이트하십시오.

   • 플러그인 확인

     1. Helm 카탈로그에서 클러스터에 설치한 플러그인을 찾으십시오.
     2. 사이드 메뉴에서 소스 및 TAR 파일 섹션을 펼치십시오.
     3. 소스 코드를 다운로드하고 여십시오.
     4. 지원되는 버전에 대해서는 README.md 또는 RELEASENOTES.md 파일을 확인하십시오.
     5. 클러스터를 업데이트하려는 Red Hat OpenShift 버전에서 실행되도록 플러그인을 업데이트해야 하는 경우 플러그인 지침에 따라 플러그인을 업데이트하십시오.

4. IBM Cloud 콘솔을 사용하거나 CLI ibmcloud oc cluster master update 명령을 사용하여 API 서버 및 이와 연관된 마스터 컴포넌트를 업데이트하십시오.

5. 잠시 기다린 후에 업데이트가 완료되었는지 확인하십시오. IBM Cloud 클러스터 대시보드에서 API 서버 버전을 검토하거나 ibmcloud oc cluster ls를 실행하십시오.

6. 마스터에서 실행되는 API 서버 버전과 일치하는 oc cli의 버전을 설치하십시오. Kubernetes 서버 버전과 2개 이상의 버전 차이가 나는(n ± 2) oc 클라이언트 버전은 지원되지 않습니다.

마스터 업데이트가 완료되면, 보유한 클러스터 인프라 제공자 유형에 따라 작업자 노드를 업데이트할 수 있습니다.

• 클래식 작업자 노드 업데이트
• VPC 작업자 노드 업데이트

전제조건

클래식 인프라 작업자 노드를 업데이트하기 전에 전제조건 단계를 검토하십시오.

작업자 노드를 업데이트하면 앱과 서비스의 작동이 중단될 수 있습니다. 작업자 노드 머신이 다시 이미징되며, 팟(Pod)의 외부에 저장되지 않은 경우 데이터가 삭제됩니다.

• 최신 보안 패치 및 수정사항이 출시되면 작업자 노드를 최대한 빨리 최신 패치로 업데이트하십시오. 최신 업데이트에 대한 자세한 정보는 Red Hat OpenShift on IBM Cloud 버전 정보 를 검토하십시오.
• Red Hat OpenShift 클러스터에 액세스하십시오.
• 마스터를 업데이트하십시오. 작업자 노드 버전은 Kubernetes 마스터에서 실행되는 API 서버 버전보다 상위 버전일 수 없습니다.
• Red Hat OpenShift 버전 준비 안내서에서 _마스터 이후 업데이트_로 표시된 변경사항을 작성하십시오.
• 패치 업데이트를 적용하려면 Red Hat OpenShift on IBM Cloud 의 버전 정보를 확인하십시오.
• 업데이트 기간 동안 워크로드를 재스케줄링할 수 있을 만큼 클러스터에 충분한 용량이 확보되도록 워커 노드를 추가하는 것을 고려해 보십시오. 자세한 정보는 클래식 클러스터에 작업자 노드 추가 또는 VPC 클러스터에 작업자 노드 추가 를 참조하십시오.
• 운영자 또는 관리자 IAM 플랫폼 액세스 역할 가 설치되어 있는지 확인하십시오.

configmap을 사용하여 CLI에서 클래식 작업자 노드 업데이트

클래식 작업자 노드의 롤링 업데이트를 수행하도록 configmap을 설정하십시오.

1. 전제조건 단계를 완료하십시오.

2. 사용 가능한 작업자 노드를 나열하고 사설 IP 주소를 기록해 두십시오.

   ibmcloud oc worker ls --cluster CLUSTER
   

3. 작업자 노드의 레이블을 보십시오. CLI 출력의 Labels 섹션에서 작업자 노드 레이블을 찾을 수 있습니다. 모든 레이블은 NodeSelectorKey 및 NodeSelectorValue로 구성되어 있습니다.

   oc describe node PRIVATE-WORKER-IP
   

   출력 예

   NAME:               10.184.58.3
   Roles:              <none>
   Labels:             arch=amd64
                   beta.kubernetes.io/arch=amd64
                   beta.kubernetes.io/os=linux
                   failure-domain.beta.kubernetes.io/region=us-south
                   failure-domain.beta.kubernetes.io/zone=dal12
                   ibm-cloud.kubernetes.io/encrypted-docker-data=true
                   ibm-cloud.kubernetes.io/iaas-provider=softlayer
                   ibm-cloud.kubernetes.io/machine-type=u3c.2x4.encrypted
                   kubernetes.io/hostname=10.123.45.3
                   privateVLAN=2299001
                   publicVLAN=2299012
   Annotations:        node.alpha.kubernetes.io/ttl=0
                   volumes.kubernetes.io/controller-managed-attach-detach=true
   CreationTimestamp:  Tue, 03 Apr 2022 15:26:17 -0400
   Taints:             <none>
   Unschedulable:      false
   

4. 구성 맵을 작성하고 작업자 노드에 대한 비가용성 규칙을 정의하십시오. 다음 예는 네 개의 검사(zonecheck.json, regioncheck.json, defaultcheck.json 및 검사 템플리트)를 보여줍니다. 이러한 예제 검사를 사용하여 특정 구역(zonecheck.json), 지역(regioncheck.json)의 작업자 노드 또는 구성 맵(defaultcheck.json)에 정의한 검사와 일치하지 않는 모든 작업자 노드에 대해 규칙을 정의할 수 있습니다. 모든 검사에 대해, 작업자 노드를 식별하려면 이전 단계에서 검색한 작업자 노드 레이블 중 하나를 선택해야 합니다.

   검사할 때마다 NodeSelectorKey 및 NodeSelectorValue에 대해 하나의 값만 설정할 수 있습니다. 둘 이상의 지역, 구역 또는 기타 작업자 노드 레이블에 대해 규칙을 설정하려면 새 검사를 작성하십시오. 구성 맵에서 최대 15개의 검사를 정의할 수 있습니다. 검사를 더 추가하면 요청된 모든 작업자가 업데이트될 때까지 한 번에 하나의 작업자 노드만 다시 로드됩니다.

   예

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-cluster-update-configuration
     namespace: kube-system
   data:
     drain_timeout_seconds: "120"
     zonecheck.json: |
       {
         "MaxUnavailablePercentage": 30,
         "NodeSelectorKey": "failure-domain.beta.kubernetes.io/zone",
         "NodeSelectorValue": "dal13"
       }
     regioncheck.json: |
       {
         "MaxUnavailablePercentage": 20,
         "NodeSelectorKey": "failure-domain.beta.kubernetes.io/region",
         "NodeSelectorValue": "us-south"
       }
     defaultcheck.json: |
       {
         "MaxUnavailablePercentage": 20
       }
     <check_name>: |
       {
         "MaxUnavailablePercentage": <value_in_percentage>,
         "NodeSelectorKey": "<node_selector_key>",
         "NodeSelectorValue": "<node_selector_value>"
       }
   

   drain_timeout_seconds

   선택 사항: 드레인 작업이 완료될 때까지 기다릴 시간(초). 안전하게 작업자 노드의 드레인을 수행하면 작업자 노드에서 모든 기존 팟(Pod)이 제거되며 클러스터의 기타 작업자 노드로 팟(Pod)이 다시 스케줄됩니다. 허용되는 값은 1 - 180 범위의 정수입니다. 기본값은 30입니다.

   zonecheck.json 및 regioncheck.json

   지정된 NodeSelectorKey 및 NodeSelectorValue로 식별할 수 있는 작업자 노드 세트에 대한 규칙을 정의하는 두 개의 검사입니다. zonecheck.json은 해당 구역 레이블을 기반으로 작업자 노드를 식별하며, regioncheck.json은 프로비저닝 중에 모든 작업자 노드에 추가된 구역 레이블을 사용합니다. 이 예제에서는 자체 구역 레이블이 dal13인 모든 작업자 노드 중 30% 와 us-south의 모든 작업자 노드 중 20% 가 업데이트 중에 사용 불가능할 수 있습니다.

   defaultcheck.json

   구성 맵을 작성하지 않았거나 맵이 잘못 구성된 경우에는 Kubernetes 기본값이 적용됩니다. 기본적으로, 클러스터의 작업자 노드는 한 번에 20%만 사용 불가능 상태가 될 수 있습니다. 구성 맵에 기본 검사를 추가하여 기본값을 대체할 수 있습니다. 이 예제에서는 구역 및 지역 검사(dal13 또는 us-south)에서 지정되지 않은 모든 작업자 노드가 업데이트 중에 사용 불가능할 수 있습니다.

   MaxUnavailablePercentage

   지정된 레이블 키 및 값에 대해 사용 불가능 상태가 될 수 있는 노드의 최대 수이며 이는 백분율로 지정됩니다. 배치, 다시 로드 또는 프로비저닝 프로세스 중에는 작업자 노드를 사용할 수 없습니다. 정의된 최대 사용 불가능 백분율을 초과하면 큐에 지정된 작업자 노드가 업데이트로부터 차단됩니다.

   NodeSelectorKey

   해당 규칙을 설정하고자 하는 작업자 노드의 레이블 키입니다. 사용자는 IBM에서 제공한 기본 레이블과 자신이 작성한 작업자 노드 레이블에 대한 규칙을 설정할 수 있습니다. 하나의 작업자 풀에 속하는 작업자 노드에 대한 규칙을 추가하려는 경우에는 ibm-cloud.kubernetes.io/machine-type 레이블을 사용할 수 있습니다.

   NodeSelectorValue

   사용자가 정의한 규칙에 대해 고려되기 위해 작업자 노드가 보유해야 하는 레이블 값입니다.

5. 클러스터에서 구성 맵을 작성하십시오.

   oc apply -f <filepath/configmap.yaml>
   

6. 구성 맵이 작성되었는지 확인하십시오.

   oc get configmap --namespace kube-system
   

7. 작업자 노드를 업데이트하십시오.

   ibmcloud oc worker update --cluster CLUSTER --worker WORKER-NODE-1-ID --worker WORKER-NODE-2-ID
   

8. 선택사항: 발생하는 유효성 검증 오류 및 구성 맵에 의해 트리거되는 이벤트를 확인하십시오. 이벤트는 CLI 출력의 Events 섹션에서 검토가 가능합니다.

   oc describe -n kube-system cm ibm-cluster-update-configuration
   

9. 작업자 노드의 Kubernetes 버전을 검토하여 업데이트가 완료되었는지 확인하십시오.

   oc get nodes
   

10. 중복된 작업자 노드가 없는지 확인하십시오. 일부 경우에 업데이트 후 이전 클러스터가 NotReady 상태의 중복된 작업자 노드를 나열할 수 있습니다. 중복 항목을 제거하려면 문제점 해결을 참조하십시오.

다음 단계:

• 기타 작업자 풀에서 업데이트 프로세스를 반복하십시오.
• 클러스터에서 작업하는 개발자에게 oc CLI를 Kubernetes 마스터의 버전으로 업데이트하도록 알리십시오.
• Kubernetes 대시보드가 사용량 그래프를 표시하지 않는 경우에는 kube-dashboard 팟(Pod)을 삭제하십시오.

콘솔에서 클래식 작업자 노드 업데이트

ConfigMap을 처음 설정한 후에는 IBM Cloud 콘솔을 사용하여 작업자 노드를 업데이트할 수 있습니다.

콘솔에서 작업자 노드를 업데이트하려면 다음을 수행하십시오.

1. 전제조건 단계 및 구성 맵 설정을 완료하여 작업자 노드가 업데이트되는 방법을 제어하십시오.
2. IBM Cloud 콘솔 메뉴 클릭하고 컨테이너 > 클러스터를 클릭합니다.
3. 클러스터 페이지에서 클러스터를 클릭하십시오.
4. 작업자 노드 탭에서 업데이트하려는 각 작업자 노드의 선택란을 선택하십시오. 표 헤더 행 위에 조치 표시줄이 표시됩니다.
5. 조치 표시줄에서 업데이트를 클릭하십시오.

클러스터에 Portworx가 설치되어 있는 경우 업데이트된 작업자 노드에서 Portworx 팟(Pod)을 다시 시작해야 합니다. 자세한 정보는 Portworx 제한사항을 참조하십시오.

전제조건

VPC 인프라 작업자 노드를 업데이트하기 전에 전제조건 단계를 검토하십시오.

작업자 노드를 업데이트하면 앱과 서비스의 작동이 중단될 수 있습니다. 작업자 노드 머신이 제거되며, 팟(Pod)의 외부에 저장되지 않은 경우 데이터가 삭제됩니다.

• 최신 보안 패치 및 수정사항이 출시되면 작업자 노드를 최대한 빨리 최신 패치로 업데이트하십시오. 최신 업데이트에 대한 자세한 정보는 Red Hat OpenShift on IBM Cloud 버전 정보 를 검토하십시오.
• Red Hat OpenShift 클러스터에 액세스하십시오.
• 마스터를 업데이트하십시오. 작업자 노드 버전은 Kubernetes 마스터에서 실행되는 API 서버 버전보다 상위 버전일 수 없습니다.
• Red Hat OpenShift 버전 준비 안내서에서 _마스터 이후 업데이트_로 표시된 변경사항을 작성하십시오.
• 패치 업데이트를 적용하려면 Red Hat OpenShift on IBM Cloud 의 버전 정보를 확인하십시오.
• 운영자 또는 관리자 IAM 플랫폼 액세스 역할 가 설치되어 있는지 확인하십시오.

Fluentd에 대한 자동 업데이트 관리

외부 서버로 전달하기 위해 클러스터에 있는 소스의 로깅 구성을 작성하는 경우 Fluentd 컴포넌트가 클러스터에 작성됩니다. 로깅 또는 필터 구성을 변경하려면 Fluentd 컴포넌트가 최신 버전이어야 합니다. 기본적으로 이 컴포넌트에 대한 자동 업데이트는 사용으로 설정됩니다.

Fluentd 컴포넌트의 자동 업데이트는 다음 방법으로 관리할 수 있습니다. 참고: 다음 명령을 실행하려면 클러스터에 대해 관리자 IBM Cloud IAM 플랫폼 액세스 역할을 보유하고 있어야 합니다.

• ibmcloud oc logging autoupdate get --cluster CLUSTER 명령을 실행하여 자동 업데이트가 사용으로 설정되었는지 확인하십시오.
• ibmcloud oc logging autoupdate disable 명령을 실행하여 자동 업데이트를 사용 안함으로 설정하십시오.
• 자동 업데이트가 사용 안함으로 설정되어 있지만 구성을 변경해야 하는 경우에는 두 가지 옵션이 있습니다.
  • Fluentd 팟(Pod)에 대해 자동 업데이트를 켭니다.

      ibmcloud oc logging autoupdate enable --cluster CLUSTER
      ```
  * `--force-update` 옵션이 포함된 로깅 명령을 사용할 때 일회성 업데이트를 강제 실행합니다. **참고**: 팟(Pod)은 Fluentd 컴포넌트의 최신 버전으로 업데이트되지만 Fluentd는 자동으로 최신 버전으로 업데이트되지 않습니다.
          명령 예
  
  ```sh {: pre}
      ibmcloud oc logging config update --cluster CLUSTER --id LOG-CONFIG-ID --type LOG-TYPE --force-update
      ```
  

Ingress ALB에 대한 자동 업데이트 관리

Ingress 애플리케이션 로드 밸런서(ALB) 컴포넌트가 업데이트되는 시점을 제어하십시오. ALB를 최신 상태로 유지하는 방법에 대한 정보는 Ingress ALB 라이프사이클 관리를 참조하십시오.