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

시작하기 전에, ‘운영자’ 또는 ‘관리자’ IAM 플랫폼 액세스 역할을 보유하고 있는지 확인하십시오. 자신의 액세스 역할이 확실하지 않다면, IBM Cloud 콘솔에서 [ 관리] → [액세스(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 클라이언트 버전은 지원되지 않습니다. 로컬 구성을 새로 고치려면 ibmcloud oc cluster config -c CLUSTER_NAME_OR_ID을 실행한 다음, ` `oc version --client을 통해 확인하십시오.

마스터 업데이트가 완료되면 워커 노드를 업데이트하십시오. 이 방법은 사용 중인 인프라 유형에 따라 달라집니다:

1. 기존 워커 노드 업데이트 — ConfigMap 및 worker update 명령어로 제어되는 롤링 업데이트 방식을 사용합니다.
2. VPC 워커 노드 업데이트 — VPC 베어 메탈 워커는 worker reload 를 사용하여 현장에서 업데이트되며, VPC VSI 워커는 worker replace --update 를 사용해야 합니다. ConfigMap 의 롤링 업데이트 절차는 아직 VPC 워커 노드에서 지원되지 않습니다.

전제조건

기존 인프라 워커 노드를 업데이트하기 전에 다음 필수 전제 조건을 완료하십시오.

워커 노드 업데이트 과정에서 워커 노드 시스템에 대한 이미지 재설치가 수행되며, 영구 저장소에 저장되지 않은 모든 데이터는 영구적으로 삭제됩니다. 시작하기 전에, 보존해야 할 데이터가 모두 워커 노드 외부에 저장되어 있는지 확인하십시오.

클러스터에 Portworx 이 설치되어 있는 경우, 워커 노드를 업데이트하기 전에 Portworx 구성을 업데이트해야 합니다.

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

ConfigMap 를 사용하여 기존 워커 노드에 대한 롤링 업데이트를 수행하십시오. ConfigMap 를 사용하면 구역(zone) 또는 리전(region)별로 한 번에 사용 불가능한 노드의 수를 제어할 수 있습니다. 클러스터에 기본값인 20% 가용성 제한 규칙이 적합하다면, 3단계와 4단계( ConfigMap 생성)를 건너뛰고 5단계로 바로 넘어가 기본 동작을 사용하여 업데이트를 적용할 수 있습니다.

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. 구성 맵을 작성하고 작업자 노드에 대한 비가용성 규칙을 정의하십시오. ConfigMap 는 최대 15개의 명명된 검사를 지원합니다. 각 검사는 레이블을 기준으로 일련의 워커 노드를 대상으로 하며, 해당 노드 중 한 번에 사용 불가능한 상태일 수 있는 최대 비율을 설정합니다. 다음 예제에서는 영역 검사(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 상태가 표시된 중복된 워커 노드가 나열되기도 합니다. 중복 항목을 제거하려면 문제점 해결을 참조하십시오.

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

ConfigMap 을 처음 설정한 후에는 IBM Cloud 콘솔을 사용하여 워커 노드를 업데이트할 수 있습니다. 콘솔은 ConfigMap 에서 정의한 사용 불가 규칙을 준수합니다.

1. 필수 전제 단계를 완료하고, 워커 노드의 업데이트 방식을 제어하기 위해 ConfigMap 를 설정하십시오.
2. IBM Cloud 콘솔 메뉴 클릭하고 컨테이너 > 클러스터를 클릭합니다.
3. 클러스터 페이지에서 클러스터를 클릭하십시오.
4. 작업자 노드 탭에서 업데이트하려는 각 작업자 노드의 선택란을 선택하십시오. 표 헤더 행 위에 조치 표시줄이 표시됩니다.
5. 조치 표시줄에서 업데이트를 클릭하십시오.

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

전제조건

VPC 인프라 워커 노드를 업데이트하기 전에 다음 필수 사전 단계를 완료하십시오.

VPC VSI 워커의 경우, 워커 노드가 삭제되고 새로운 노드로 대체됩니다. VPC 베어 메탈 작업자의 경우, 노드가 해당 위치에서 다시 로드됩니다. 두 경우 모두, 영구 저장소에 저장되지 않은 데이터는 영구적으로 삭제됩니다. 시작하기 전에, 보존해야 할 데이터가 모두 워커 노드 외부에 저장되어 있는지 확인하십시오.

클러스터에 Portworx 가 배포되어 있는 경우, 이 페이지에 설명된 단계 대신 다음 단계를 따라 VPC 워커 노드를 Portworx 볼륨으로 업데이트하십시오.

VPC 베어 메탈 워커 재시작 중 펌웨어 업데이트

VPC 베어메탈 워커 노드를 재시작하면, ‘ IBM Cloud ’ 인프라가 해당 서버에 적용해야 할 펌웨어 업데이트가 있는지 자동으로 확인하고, 재시작 과정의 일환으로 이를 적용합니다. 펌웨어 업데이트를 시작하기 위해 별도의 조치가 필요하지 않습니다.

VPC 베어 메탈 워커 노드를 재부팅할 때는 다음 사항을 유의하십시오:

재장전 시간 연장

재장전 중에 펌웨어 업데이트가 적용될 경우, 전체 재장전 시간이 일반적인 재장전 소요 시간보다 30분 이상 크게 늘어날 수 있습니다. 이에 따라 유지보수 기간을 계획하십시오.

예정된 업데이트에 대한 사전 확인 기능 없음

reload 명령을 실행하기 전에는 워커 노드에 펌웨어 업데이트가 대기 중인지 여부를 확인할 수 없습니다.

데이터 손실 위험

모든 VPC 베어 메탈 워커 재로딩과 마찬가지로, 펌웨어 업데이트가 적용되든 안 되든 상관없이 재로딩 과정에서 로컬 디스크의 데이터는 삭제됩니다. 다시 로드하기 전에 영구 저장소에 저장되지 않은 모든 데이터를 백업하십시오.

펌웨어 업데이트로 인한 재시작 실패

경우에 따라 펌웨어 업데이트가 실패할 수 있으며, 이로 인해 워커 노드가 ‘ reload_failed ’ 상태(Failed to reload worker)로 전환되고, 상태 세부 정보는 The infrastructure firmware update has failed. (P4056) 로 표시됩니다. 메모리가 부족할 경우

1. 몇 분 정도 기다린 후, ibmcloud oc worker reload --cluster CLUSTER --worker WORKER-NODE-ID 을 다시 실행하여 재로드를 시도해 보세요.
2. 2~3회 시도해도 오류가 계속 발생하면 IBM Cloud 에서 지원 요청을 제출하십시오.

시작하기 전에

• Red Hat OpenShift 클러스터에 액세스하십시오.
• 보존해야 할 모든 데이터가 워커 노드 외부의 영구 저장소에 저장되어 있는지 확인하십시오. 워커 노드에만 저장된 데이터는 손실되며 복구할 수 없습니다.
• 운영자 또는 관리자 IAM 플랫폼 액세스 역할 가 설치되어 있는지 확인하십시오. 자신의 액세스 역할이 확실하지 않다면, IBM Cloud 콘솔에서 [ 관리] → [액세스(IAM)] → [사용자 ]로 이동하거나 계정 관리자에게 문의하세요.

맛을 업데이트하려면

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

   1. 클러스터에서 사용 가능한 작업자 풀을 나열하십시오.

       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   2. 작업자 풀의 작업자 노드를 나열하십시오. **ID** 및 **사설 IP**를 기록해 두십시오.
   ```sh {: pre}
       ibmcloud oc worker ls --cluster CLUSTER --worker-pool WORKER-POOL
       ```
   3. 작업자 노드에 대한 세부사항을 가져오십시오. 출력에서 구역 및 클래식 클러스터의 사설 및 공용 VLAN ID 또는 VPC 클러스터의 서브넷 ID를 기록하십시오.
   ```sh {: pre}
       ibmcloud oc worker get --cluster CLUSTER --worker WORKER-ID
       ```
   

2. 구역에서 사용 가능한 특성을 나열하십시오.

   ibmcloud oc flavors --zone <zone>
   

3. 새 머신 유형으로 작업자 노드를 작성하십시오.

   1. 대체할 작업자 노드의 수로 작업자 풀을 작성하십시오.
      • 클래식 클러스터:

        ibmcloud oc worker-pool create classic --name WORKER-POOL --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE
        

      • VPC 2세대 클러스터:

        ibmcloud oc worker-pool create vpc-gen2 --name NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE --label LABEL
        

   2. 작업자 풀이 작성되었는지 확인하십시오.

       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   3. 이전에 검색한 작업자 풀에 구역을 추가하십시오. 구역을 추가하면 작업자 풀에서 정의된 작업자 노드가 구역에서 프로비저닝되며 향후 워크로드 스케줄을 위해 고려됩니다. 다중 구역에 작업자 노드를 분산시키려면 [클래식](/docs/openshift?topic=openshift-regions-and-zones#zones-mz) 또는 [VPC](/docs/openshift?topic=openshift-regions-and-zones#zones-vpc) 다중 구역 위치를 선택하십시오.
       * 클래식 클러스터:
           ```sh {: pre}
           ibmcloud oc zone add classic --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --private-vlan PRIVATE-VLAN-ID --public-vlan PUBLIC-VLAN-ID
           ```
       * VPC 클러스터:
           ```sh {: pre}
           ibmcloud oc zone add vpc-gen2 --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --subnet-id VPC-SUBNET-ID
           ```
   

4. 작업자 노드가 배치될 때까지 대기하십시오. 작업자 노드 상태가 **정상(Normal)**으로 변경되면 배치가 완료된 것입니다.

   ibmcloud oc worker ls --cluster CLUSTER
   

5. 기존 워커 풀을 제거하십시오. (월별 청구되는) Classic 베어 메탈 플레어를 해지하는 경우, 월 중순에 해지하더라도 해당 월의 요금이 전액 청구됩니다. 베어 메탈을 포함한 VPC 작업에 대해서는 시간당 요금이 청구됩니다.

   1. 이전 머신 유형의 작업자 풀을 제거하십시오. 작업자 풀을 제거하면 모든 구역의 풀에서 모든 작업자 노드가 제거됩니다. 이 프로세스는 완료하는 데 몇 분 정도 소요될 수 있습니다.

       ibmcloud oc worker-pool rm --worker-pool WORKER-POOL --cluster CLUSTER
       ```
   2. 작업자 풀이 제거되었는지 확인하십시오.
   ```sh {: pre}
       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   

6. 작업자 노드가 클러스터에서 제거되었는지 확인하십시오.

   ibmcloud oc worker ls --cluster CLUSTER
   

7. 이러한 단계를 반복하여 기타 작업자 풀 또는 독립형 작업자 노드를 다른 특성으로 업데이트하십시오.

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

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

다음 명령을 실행하려면 클러스터에 대한 ‘Administrator IBM Cloud ’ IAM 플랫폼 액세스 역할이 있어야 합니다.

Fluentd 컴포넌트의 자동 업데이트는 다음 방법으로 관리할 수 있습니다.

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

      ibmcloud oc logging autoupdate enable --cluster CLUSTER
      ```
  * `--force-update` 옵션이 포함된 로깅 명령을 사용할 때 일회성 업데이트를 강제 실행합니다. 포드는 ‘ 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 라이프사이클 관리를 참조하십시오.