IBM Cloud CLI를 사용하여 버전 업데이트를 사용할 수 있는지 확인

1. IBM Cloud에 로그인하십시오. 연합 계정이 있는 경우 --sso 옵션을 포함합니다.

   ibmcloud login [--sso]
   

2. 계정의 Satellite 클러스터를 나열합니다.

   ibmcloud ks cluster ls --provider satellite
   

3. 버전을 업데이트할 클러스터의 작업자 노드를 나열합니다. 출력에서 버전 업데이트를 사용할 수 있음을 표시하는 메시지와 함께 별표 *가 있는지 확인하십시오.

   ibmcloud ks worker ls -c CLUSTER_NAME_OR_ID
   

   출력 예

   ID                Primary IP       Flavor   State    Status   Zone     Version   
   sat-worker-<ID>   <IP_address>     upi      normal   Ready    zone-1   4.5.35_1534_openshift*   
   * To update to 4.5.37_1537_openshift version, run 'ibmcloud ks worker replace'. Review and make any required version changes before you update: 'https://ibm.biz/upworker'
   

IBM Cloud 콘솔에서 버전 업데이트를 사용할 수 있는지 확인

1. Satellite 콘솔에 로그인하십시오.
2. 업데이트할 호스트가 있는 위치를 클릭하십시오.
3. 호스트 탭을 클릭하십시오.
4. 호스트 목록에서 업데이트할 호스트의 클러스터 링크를 클릭하십시오. Red Hat OpenShift on IBM Cloud 클러스터 세부사항에 대한 새 탭이 열립니다.
5. 작업자 노드 탭을 클릭하십시오.
6. ‘버전’ 열에서, 아이콘을 클릭했을 때 ‘ Update available ’라고 표시되는 정보 아이콘이 있는지 확인하세요. 업데이트가 사용 가능하지 않은 경우 아이콘이 표시되지 않습니다.
7. 버전 업데이트가 주 업데이트, 부 업데이트 또는 패치 업데이트인지 판별하십시오.

한 번에 하나씩 작업자 노드 호스트에 버전 업데이트 적용

1. 선택사항: 기존 호스트가 업데이트되는 동안 계산 용량을 처리하려면 를 연결하고 추가 호스트를 서비스 클러스터에 지정하십시오.

2. 작업자 노드 호스트를 식별하십시오. 작업자 노드 호스트에는 출력의 Cluster 열에 나열된 infrastructure 가 없지만 대신 클러스터의 이름을 갖습니다.

3. ibmcloud ks worker update 명령을 실행하여 작업자 노드를 개별적으로 업데이트하십시오.

   ibmcloud ks worker update -c CLUSTER_NAME_OR_ID --worker WORKER_ID
   

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

   kubectl get nodes
   

   업데이트에 실패하면 호스트를 대체하여 버전 업데이트를 적용 해야 합니다.

ConfigMap 을 사용하여 작업자 노드 호스트에 버전 업데이트 적용

ConfigMap을 사용하여 모든 작업자 노드 호스트에 대한 업데이트를 롤아웃할 수 있습니다. 레이블을 사용하여 업데이트할 노드를 지정하십시오. 또한

1. 선택사항: 기존 호스트가 업데이트되는 동안 계산 용량을 처리하려면 를 연결하고 추가 호스트를 서비스 클러스터에 지정하십시오.

2. 작업자 노드 호스트를 식별하십시오. 작업자 노드 호스트가 Infrastructure 로 나열되지 않습니다.

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

   kubectl get nodes -o yaml
   

   출력 예

   labels:
     arch: amd64
     beta.kubernetes.io/arch: amd64
     beta.kubernetes.io/instance-type: upi
     beta.kubernetes.io/os: linux
     failure-domain.beta.kubernetes.io/region: us-east
     failure-domain.beta.kubernetes.io/zone: us-east-2
     ibm-cloud.kubernetes.io/iaas-provider: upi
     ibm-cloud.kubernetes.io/internal-ip: 10.241.0.4
     ibm-cloud.kubernetes.io/machine-type: upi
     ibm-cloud.kubernetes.io/os: REDHAT_8_64
     ibm-cloud.kubernetes.io/region: us-east
     ibm-cloud.kubernetes.io/worker-id: sat-satellitei-5bd83963cdfedc7668c9040879c88113a134c4e7
     ibm-cloud.kubernetes.io/worker-pool-id: cbtljodw089nltg8k210-9a3f763
     ibm-cloud.kubernetes.io/worker-pool-name: default
     ibm-cloud.kubernetes.io/worker-version: 4.7.59_1583_openshift
     ibm-cloud.kubernetes.io/zone: us-east-2
     kubernetes.io/arch: amd64
     kubernetes.io/hostname: satellite-ibm-host-3
     kubernetes.io/os: linux
     node-role.kubernetes.io/master: ""
     node-role.kubernetes.io/worker: ""
     node.kubernetes.io/instance-type: upi
     node.openshift.io/os_id: rhel
     privateVLAN: "1"
     topology.kubernetes.io/region: us-east
     topology.kubernetes.io/zone: us-east-2
   

4. ConfigMap 를 생성하고 워커 노드에 대한 가용성 제한 규칙을 정의하십시오. 다음 예시에는 ‘ defaultcheck.json ’과 수표 서식 두 가지가 나와 있습니다. 이 예제 검사를 사용하여 ConfigMap (defaultcheck.json) 에서 정의한 검사와 일치하지 않는 모든 작업자 노드에 대한 규칙을 정의할 수 있습니다. 검사 템플리트를 사용하여 사용자 고유의 검사를 작성하십시오. 모든 검사에 대해, 작업자 노드를 식별하려면 이전 단계에서 검색한 작업자 노드 레이블 중 하나를 선택해야 합니다.

   검사할 때마다 NodeSelectorKey 및 NodeSelectorValue에 대해 하나의 값만 설정할 수 있습니다. ConfigMap 에서 최대 10개의 검사를 정의할 수 있습니다. 검사를 더 추가하는 경우에 이는 무시됩니다.

   예

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-cluster-update-configuration
     namespace: kube-system
   data:
     drain_timeout_seconds: "120"
     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입니다.

   defaultcheck.json

   Satellite 호스트에서 작업자 노드를 업데이트할 때 클러스터에 있는 작업자 노드의 20%만 한 번에 사용 불가능할 수 있습니다.

   MaxUnavailablePercentage

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

   NodeSelectorKey

   해당 규칙을 설정하고자 하는 작업자 노드의 레이블 키입니다. 사용자는 IBM에서 제공한 기본 레이블과 자신이 작성한 작업자 노드 레이블에 대한 규칙을 설정할 수 있습니다.

   NodeSelectorValue

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

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

   kubectl apply -f <filepath/configmap.yaml>
   

6. ConfigMap 가 생성되었는지 확인하십시오.

   kubectl get configmap --namespace kube-system
   

7. 작업자 노드를 ID별로 나열하여 업데이트하십시오.

   ibmcloud ks worker update --cluster <cluster_name_or_ID> --worker <worker_node1_ID> --worker <worker_node2_ID>
   

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

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

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

   kubectl get nodes
   

   업데이트에 실패하면 호스트를 대체하여 버전 업데이트를 적용 해야 합니다.

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