클러스터 업데이트

1. 대상 버전은 웹 콘솔 또는 CLI를 통해 관리할 수 있는 ClusterVersion 리소스의 spec.desiredUpdate.version 필드에 저장됩니다.
2. CVO(Cluster Version Operator)는 ClusterVersion 리소스의 desiredUpdate 가 현재 클러스터 버전과 다른 것을 감지합니다. OpenShift Update Service의 그래프 데이터를 사용하여 CVO는 원하는 클러스터 버전을 릴리스 이미지의 가져오기 사양으로 확인합니다.
3. CVO는 릴리스 이미지의 무결성 및 진위 여부를 검증합니다. Red Hat은 이미지 SHA 다이제스트를 고유하고 변경할 수 없는 릴리스 이미지 식별자로 사용하여 사전 정의된 위치에서 게시된 릴리스 이미지에 대해 암호화 방식으로 서명합니다. CVO는 기본 제공 공개 키 목록을 사용하여 선택한 릴리스 이미지와 일치하는 문의 존재 및 서명을 검증합니다.
4. CVO는 openshift-cluster-version 네임스페이스에 version-$version-$hash 라는 작업을 생성합니다. 이 작업은 릴리스 이미지를 실행하는 컨테이너를 사용하므로 클러스터는 컨테이너 런타임을 통해 이미지를 다운로드합니다. 그런 다음 이 작업은 릴리스 이미지의 매니페스트 및 메타데이터를 CVO에 액세스할 수 있는 공유 볼륨으로 추출합니다.
5. CVO는 추출된 매니페스트 및 메타데이터의 유효성을 검사합니다.
6. CVO는 일부 사전 조건을 검사하여 클러스터에서 문제가 있는 상태가 탐지되지 않도록 합니다. 특정 조건은 업데이트가 진행되지 않도록 할 수 있습니다. 이러한 조건은 CVO 자체에 의해 결정되거나, Operator가 업데이트에 문제가 있다고 간주하는 클러스터에 대한 몇 가지 세부 정보를 감지하는 개별 클러스터 Operator에 의해 보고됩니다.
7. CVO는 허용되는 릴리스를 status.desired 에 기록하고 새 업데이트에 대한 status.history 항목을 생성합니다.
8. CVO는 릴리스 이미지에서 매니페스트를 조정하기 시작합니다. 클러스터 Operator는 Runlevels라는 별도의 단계에서 업데이트되며 CVO는 다음 단계로 진행하기 전에 Runlevel 완료 업데이트의 모든 Operator를 확인합니다.
9. CVO 자체에 대한 매니페스트는 프로세스 초기에 적용됩니다. CVO 배포가 적용되면 현재 CVO Pod가 중지되고 새 버전을 사용하는 CVO Pod가 시작됩니다. 새 CVO는 나머지 매니페스트를 조정합니다.
10. 업데이트는 전체 컨트롤 플레인이 새 버전으로 업데이트될 때까지 진행됩니다. 개별 클러스터 Operator는 클러스터 도메인에서 업데이트 작업을 수행할 수 있으며 이렇게 하는 동안 Progressing=True 조건을 통해 상태를 보고합니다.
11. MCO(Machine Config Operator) 매니페스트는 프로세스 종료에 적용됩니다. 그런 다음 업데이트된 MCO는 모든 노드의 시스템 구성 및 운영 체제를 업데이트하기 시작합니다. 워크로드를 다시 수락하기 전에 각 노드를 드레이닝, 업데이트 및 재부팅할 수 있습니다.

1. 노드를 차단하고 드레이닝

   참고

   노드가 차단되면 워크로드를 예약할 수 없습니다.

2. 노드의 시스템 구성 및 운영 체제(OS) 업데이트
3. 노드 재부팅
4. 노드 차단 해제

1. MCO는 1, 2, 3 노드를 차단하고 드레이닝하기 시작합니다.
2. 노드 2 드레이닝, 재부팅 및 다시 사용할 수 있게 됩니다. MCO는 노드 4를 차단하고 드레이닝을 시작합니다.
3. 노드 1이 드레이닝, 재부팅 및 다시 사용할 수 있게 됩니다. MCO 노드 5를 차단하고 드레이닝을 시작합니다.
4. 노드 3은 드레이닝을 완료, 재부팅, 다시 사용할 수 있게 됩니다.
5. 노드 5 드레이닝, 재부팅 및 다시 사용할 수 있게 됩니다.
6. 노드 4 드레이닝, 재부팅 및 다시 사용할 수 있게 됩니다.

프로세스

1. 다음 명령을 실행하여 적용할 업데이트에 대한 pull 사양을 가져옵니다.

   $ oc adm upgrade

   이 명령의 출력에는 다음과 유사한 사용 가능한 업데이트에 대한 가져오기 사양이 포함됩니다.

   부분 예제 출력

   ...
   Recommended updates:
   
   VERSION IMAGE
   4.17.0  quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032
   ...

2. 다음 명령을 실행하여 사용할 릴리스 이미지로 $RELEASE_IMAGE 변수를 설정합니다.

   $ RELEASE_IMAGE=<update_pull_spec>

   여기서 <update_pull_spec >은 사용하려는 릴리스 이미지의 풀 사양입니다. 예를 들면 다음과 같습니다.

   quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032

3. 다음 명령을 실행하여 OpenShift Container Platform 릴리스 이미지에서 CredentialsRequest CR(사용자 정의 리소스) 목록을 추출합니다.

   $ oc adm release extract \
     --from=$RELEASE_IMAGE \
     --credentials-requests \
     --included \1
     --to=<path_to_directory_for_credentials_requests> 2

   1

   --included 매개변수에는 대상 릴리스에 필요한 특정 클러스터 구성에 필요한 매니페스트만 포함됩니다.

   2

   CredentialsRequest 오브젝트를 저장할 디렉터리의 경로를 지정합니다. 지정된 디렉터리가 없으면 이 명령이 이를 생성합니다.

   이 명령을 수행하면 각 CredentialsRequest 오브젝트에 대해 YAML 파일이 생성됩니다.

4. 릴리스 이미지의 각 CredentialsRequest CR에 대해 spec.secretRef.namespace 필드의 텍스트와 일치하는 네임스페이스가 클러스터에 있는지 확인합니다. 이 필드에는 인증 정보 구성을 보유하는 생성된 시크릿이 저장됩니다.

   샘플 AWS CredentialsRequest 오브젝트

   apiVersion: cloudcredential.openshift.io/v1
   kind: CredentialsRequest
   metadata:
     name: cloud-credential-operator-iam-ro
     namespace: openshift-cloud-credential-operator
   spec:
     providerSpec:
       apiVersion: cloudcredential.openshift.io/v1
       kind: AWSProviderSpec
       statementEntries:
       - effect: Allow
         action:
         - iam:GetUser
         - iam:GetUserPolicy
         - iam:ListAccessKeys
         resource: "*"
     secretRef:
       name: cloud-credential-operator-iam-ro-creds
       namespace: openshift-cloud-credential-operator 1

   1

   이 필드는 생성된 보안을 유지하기 위해 존재해야 하는 네임스페이스를 나타냅니다.

   다른 플랫폼의 CredentialsRequest CR에는 다른 플랫폼별 값이 있는 유사한 형식이 있습니다.

5. 클러스터에 spec.secretRef.namespace 에 지정된 이름의 네임스페이스가 아직 없는 CredentialsRequest CR의 경우 다음 명령을 실행하여 네임스페이스를 생성합니다.

   $ oc create namespace <component_namespace>

프로세스

1. 다음 명령을 실행하여 OpenShift Container Platform 릴리스 이미지의 변수를 설정합니다.

   $ RELEASE_IMAGE=$(oc get clusterversion -o jsonpath={..desired.image})

2. 다음 명령을 실행하여 OpenShift Container Platform 릴리스 이미지에서 CCO 컨테이너 이미지를 가져옵니다.

   $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)

   참고

   $RELEASE_IMAGE 의 아키텍처가 ccoctl 툴을 사용할 환경의 아키텍처와 일치하는지 확인합니다.

3. 다음 명령을 실행하여 OpenShift Container Platform 릴리스 이미지 내에서 ccoctl 바이너리를 추출합니다.

   $ oc image extract $CCO_IMAGE \
     --file="/usr/bin/ccoctl.<rhel_version>" \1
     -a ~/.pull-secret

   1

   & lt;rhel_version > 의 경우 호스트가 사용하는 RHEL(Red Hat Enterprise Linux) 버전에 해당하는 값을 지정합니다. 값을 지정하지 않으면 기본적으로 ccoctl.rhel8 이 사용됩니다. 다음 값이 유효합니다.

   • rhel8: RHEL 8을 사용하는 호스트에 대해 이 값을 지정합니다.
   • rhel9: RHEL 9를 사용하는 호스트에 대해 이 값을 지정합니다.

4. 다음 명령을 실행하여 ccoctl 을 실행할 수 있도록 권한을 변경합니다.

   $ chmod 775 ccoctl.<rhel_version>

프로세스

1. ccoctl 툴을 사용하여 클라우드 공급자에 대해 명령을 실행하여 모든 CredentialsRequest 오브젝트를 처리합니다. 다음 명령은 CredentialsRequest 오브젝트를 처리합니다.

   예 2.1. AWS(Amazon Web Services)

   $ ccoctl aws create-all \1
     --name=<name> \2
     --region=<aws_region> \3
     --credentials-requests-dir=<path_to_credentials_requests_directory> \4
     --output-dir=<path_to_ccoctl_output_dir> \5
     --create-private-s3-bucket 6

   1

   AWS 리소스를 개별적으로 생성하려면 "사용자 지정" 컨텐츠로 "AWS에 클러스터 설치" 절차의 "AWS 리소스 생성" 절차를 사용하십시오. 이 옵션은 AWS 리소스를 수정하기 전에 ccoctl 툴에서 생성하는 JSON 파일을 검토해야 하거나 ccoctl 툴에서 AWS 리소스 를 생성하는 데 사용하는 프로세스가 조직의 요구 사항을 자동으로 충족하지 않는 경우 유용할 수 있습니다.

   2

   추적을 위해 생성된 클라우드 리소스에 태그를 지정하는 데 사용되는 이름을 지정합니다.

   3

   클라우드 리소스가 생성될 AWS 리전을 지정합니다.

   4

   구성 요소 CredentialsRequest 오브젝트에 대한 파일이 포함된 디렉터리를 지정합니다.

   5

   선택 사항: ccoctl 유틸리티에서 오브젝트를 생성할 디렉터리를 지정합니다. 기본적으로 유틸리티는 명령이 실행되는 디렉터리에 오브젝트를 생성합니다.

   6

   선택사항: 기본적으로 ccoctl 유틸리티는 공개 S3 버킷에 OIDC(OpenID Connect) 구성 파일을 저장하고 공개 OIDC 엔드포인트로 S3 URL을 사용합니다. OIDC 구성을 공용 CloudFront 배포 URL을 통해 IAM ID 공급자가 액세스하는 개인 S3 버킷에 저장하려면 --create-private-s3-bucket 매개변수를 사용합니다.

   예 2.2. GCP(Google Cloud Platform)

   $ ccoctl gcp create-all \
     --name=<name> \1
     --region=<gcp_region> \2
     --project=<gcp_project_id> \3
     --credentials-requests-dir=<path_to_credentials_requests_directory> \4
     --output-dir=<path_to_ccoctl_output_dir> 5

   1

   추적에 사용되는 모든 생성된 GCP 리소스의 사용자 정의 이름을 지정합니다.

   2

   클라우드 리소스가 생성될 GCP 리전을 지정합니다.

   3

   클라우드 리소스가 생성될 GCP 프로젝트 ID를 지정합니다.

   4

   GCP 서비스 계정을 생성하려면 CredentialsRequest 매니페스트 파일이 포함된 디렉터리를 지정합니다.

   5

   선택 사항: ccoctl 유틸리티에서 오브젝트를 생성할 디렉터리를 지정합니다. 기본적으로 유틸리티는 명령이 실행되는 디렉터리에 오브젝트를 생성합니다.

   예 2.3. IBM Cloud

   $ ccoctl ibmcloud create-service-id \
     --credentials-requests-dir=<path_to_credential_requests_directory> \1
     --name=<cluster_name> \2
     --output-dir=<installation_directory> \3
     --resource-group-name=<resource_group_name> 4

   1

   구성 요소 CredentialsRequest 오브젝트에 대한 파일이 포함된 디렉터리를 지정합니다.

   2

   OpenShift Container Platform 클러스터의 이름을 지정합니다.

   3

   선택 사항: ccoctl 유틸리티에서 오브젝트를 생성할 디렉터리를 지정합니다. 기본적으로 유틸리티는 명령이 실행되는 디렉터리에 오브젝트를 생성합니다.

   4

   선택 사항: 액세스 정책의 범위를 지정하는 데 사용되는 리소스 그룹의 이름을 지정합니다.

   예 2.4. Microsoft Azure

   $ ccoctl azure create-managed-identities \
     --name <azure_infra_name> \1
     --output-dir ./output_dir \
     --region <azure_region> \2
     --subscription-id <azure_subscription_id> \3
     --credentials-requests-dir <path_to_directory_for_credentials_requests> \
     --issuer-url "${OIDC_ISSUER_URL}" \4
     --dnszone-resource-group-name <azure_dns_zone_resourcegroup_name> \5
     --installation-resource-group-name "${AZURE_INSTALL_RG}" 6

   1

   name 매개변수의 값은 Azure 리소스 그룹을 생성하는 데 사용됩니다. 새 Azure 리소스 그룹을 생성하는 대신 기존 Azure 리소스 그룹을 사용하려면 기존 그룹 이름을 값으로 사용하여 --oidc-resource-group-name 인수를 지정합니다.

   2

   기존 클러스터의 리전을 지정합니다.

   3

   기존 클러스터의 서브스크립션 ID를 지정합니다.

   4

   기존 클러스터의 OIDC 발행자 URL을 지정합니다. 다음 명령을 실행하여 이 값을 가져올 수 있습니다.

   $ oc get authentication cluster \
     -o jsonpath \
     --template='{ .spec.serviceAccountIssuer }'

   5

   DNS 영역을 포함하는 리소스 그룹의 이름을 지정합니다.

   6

   Azure 리소스 그룹 이름을 지정합니다. 다음 명령을 실행하여 이 값을 가져올 수 있습니다.

   $ oc get infrastructure cluster \
     -o jsonpath \
     --template '{ .status.platformStatus.azure.resourceGroupName }'

   예 2.5. Nutanix

   $ ccoctl nutanix create-shared-secrets \
     --credentials-requests-dir=<path_to_credentials_requests_directory> \1
     --output-dir=<ccoctl_output_dir> \2
     --credentials-source-filepath=<path_to_credentials_file> 3

   1

   구성 요소 CredentialsRequests 오브젝트의 파일이 포함된 디렉터리의 경로를 지정합니다.

   2

   선택 사항: ccoctl 유틸리티에서 오브젝트를 생성할 디렉터리를 지정합니다. 기본적으로 유틸리티는 명령이 실행되는 디렉터리에 오브젝트를 생성합니다.

   3

   선택 사항: 인증 정보 데이터 YAML 파일이 포함된 디렉터리를 지정합니다. 기본적으로 ccoctl 은 이 파일이 < home_directory>/.nutanix/credentials 에 있을 것으로 예상합니다.

   각 CredentialsRequest 오브젝트에 대해 ccoctl 은 OpenShift Container Platform 릴리스 이미지에서 각 CredentialsRequest 오브젝트에 정의된 대로 필요한 공급자 리소스 및 권한 정책을 생성합니다.

2. 다음 명령을 실행하여 클러스터에 보안을 적용합니다.

   $ ls <path_to_ccoctl_output_dir>/manifests/*-credentials.yaml | xargs -I{} oc apply -f {}

프로세스

1. 새 릴리스 이미지가 추가하는 CredentialsRequest 사용자 정의 리소스에 대한 시크릿을 사용하여 YAML 파일을 생성합니다. 시크릿은 각 CredentialsRequest 오브젝트의 spec.secretRef에 정의된 네임 스페이스 및 시크릿 이름을 사용하여 저장해야 합니다.

   예 2.6. AWS YAML 파일 샘플

   보안이 포함된 샘플 AWS CredentialsRequest 오브젝트

   apiVersion: cloudcredential.openshift.io/v1
   kind: CredentialsRequest
   metadata:
     name: <component_credentials_request>
     namespace: openshift-cloud-credential-operator
     ...
   spec:
     providerSpec:
       apiVersion: cloudcredential.openshift.io/v1
       kind: AWSProviderSpec
       statementEntries:
       - effect: Allow
         action:
         - s3:CreateBucket
         - s3:DeleteBucket
         resource: "*"
         ...
     secretRef:
       name: <component_secret>
       namespace: <component_namespace>
     ...

   샘플 AWS Secret 오브젝트

   apiVersion: v1
   kind: Secret
   metadata:
     name: <component_secret>
     namespace: <component_namespace>
   data:
     aws_access_key_id: <base64_encoded_aws_access_key_id>
     aws_secret_access_key: <base64_encoded_aws_secret_access_key>

   예 2.7. Azure YAML 파일 샘플

   참고

   글로벌 Azure 및 Azure Stack Hub는 동일한 CredentialsRequest 오브젝트 및 시크릿 형식을 사용합니다.

   보안이 포함된 샘플 Azure CredentialsRequest 오브젝트

   apiVersion: cloudcredential.openshift.io/v1
   kind: CredentialsRequest
   metadata:
     name: <component_credentials_request>
     namespace: openshift-cloud-credential-operator
     ...
   spec:
     providerSpec:
       apiVersion: cloudcredential.openshift.io/v1
       kind: AzureProviderSpec
       roleBindings:
       - role: Contributor
         ...
     secretRef:
       name: <component_secret>
       namespace: <component_namespace>
     ...

   Azure Secret 오브젝트 샘플

   apiVersion: v1
   kind: Secret
   metadata:
     name: <component_secret>
     namespace: <component_namespace>
   data:
     azure_subscription_id: <base64_encoded_azure_subscription_id>
     azure_client_id: <base64_encoded_azure_client_id>
     azure_client_secret: <base64_encoded_azure_client_secret>
     azure_tenant_id: <base64_encoded_azure_tenant_id>
     azure_resource_prefix: <base64_encoded_azure_resource_prefix>
     azure_resourcegroup: <base64_encoded_azure_resourcegroup>
     azure_region: <base64_encoded_azure_region>

   예 2.8. GCP YAML 파일 샘플

   보안이 포함된 샘플 GCP CredentialsRequest 오브젝트

   apiVersion: cloudcredential.openshift.io/v1
   kind: CredentialsRequest
   metadata:
     name: <component_credentials_request>
     namespace: openshift-cloud-credential-operator
     ...
   spec:
     providerSpec:
       apiVersion: cloudcredential.openshift.io/v1
       kind: GCPProviderSpec
         predefinedRoles:
         - roles/iam.securityReviewer
         - roles/iam.roleViewer
         skipServiceCheck: true
         ...
     secretRef:
       name: <component_secret>
       namespace: <component_namespace>
     ...

   샘플 GCP Secret 오브젝트

   apiVersion: v1
   kind: Secret
   metadata:
     name: <component_secret>
     namespace: <component_namespace>
   data:
     service_account.json: <base64_encoded_gcp_service_account_file>

2. 시크릿에 저장된 기존 인증 정보에 대한 CredentialsRequest 사용자 정의 리소스에 변경된 권한 요구 사항이 있는 경우 필요에 따라 권한을 업데이트합니다.

프로세스

1. cluster-admin 역할의 사용자로 클러스터에서 oc 에 로그인합니다.

2. CloudCredential 리소스를 편집하여 다음 명령을 실행하여 metadata 필드 내에 upgradeable-to 주석을 추가합니다.

   $ oc edit cloudcredential cluster

   추가할 텍스트

   ...
     metadata:
       annotations:
         cloudcredential.openshift.io/upgradeable-to: <version_number>
   ...

   여기서 <version_number>는 x.y.z 형식으로 업그레이드할 버전입니다. 예를 들어 OpenShift Container Platform 4.12.2에는 4.12.2를 사용합니다.

   주석을 추가한 후 업그레이드 가능 상태가 변경되는 데 몇 분이 소요될 수 있습니다.

검증

1. 웹 콘솔의 관리자 화면에서 관리자 → 클러스터 설정으로 이동합니다.

2. CCO 상태 세부 정보를 보려면 Cluster Operators 목록에서 cloud-credential을 클릭합니다.

   • Conditions 섹션의 Upgradeable 상태가 False인 경우 upgradeable-to 주석에 오타 오류가 없는지 확인합니다.
3. Conditions 섹션의 Upgradeable 상태가 True 인 경우 OpenShift Container Platform 업그레이드를 시작합니다.

1. 이미지 검증 단계
2. 빌드 검증 단계
3. 검증 단계 서명

프로세스

1. 일시 중지하려는 사용 가능한 MachineHealthCheck 리소스를 모두 나열하려면 다음 명령을 실행합니다.

   $ oc get machinehealthcheck -n openshift-machine-api

2. 머신 상태 점검을 일시 중지하려면 cluster.x-k8s.io/paused="" 주석을 MachineHealthCheck 리소스에 추가합니다. 다음 명령을 실행합니다.

   $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused=""

   주석이 지정된 MachineHealthCheck 리소스는 다음 YAML 파일과 유사합니다.

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineHealthCheck
   metadata:
     name: example
     namespace: openshift-machine-api
     annotations:
       cluster.x-k8s.io/paused: ""
   spec:
     selector:
       matchLabels:
         role: worker
     unhealthyConditions:
     - type:    "Ready"
       status:  "Unknown"
       timeout: "300s"
     - type:    "Ready"
       status:  "False"
       timeout: "300s"
     maxUnhealthy: "40%"
   status:
     currentHealthy: 5
     expectedMachines: 5

   중요

   클러스터를 업데이트한 후 머신 상태 점검을 다시 시작합니다. 검사를 다시 시작하려면 다음 명령을 실행하여 MachineHealthCheck 리소스에서 일시 중지 주석을 제거합니다.

   $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused-

프로세스

1. 사용 가능한 업데이트를 확인하고 적용하려는 업데이트의 버전 번호를 기록해 둡니다.

   $ oc adm upgrade

   출력 예

   Cluster version is 4.13.10
   Upstream is unset, so the cluster will use an appropriate default.
   Channel: stable-4.13 (available channels: candidate-4.13, candidate-4.14, fast-4.13, stable-4.13)
   Recommended updates:
     VERSION     IMAGE
     4.13.14     quay.io/openshift-release-dev/ocp-release@sha256:406fcc160c097f61080412afcfa7fd65284ac8741ac7ad5b480e304aba73674b
     4.13.13     quay.io/openshift-release-dev/ocp-release@sha256:d62495768e335c79a215ba56771ff5ae97e3cbb2bf49ed8fb3f6cefabcdc0f17
     4.13.12     quay.io/openshift-release-dev/ocp-release@sha256:73946971c03b43a0dc6f7b0946b26a177c2f3c9d37105441315b4e3359373a55
     4.13.11     quay.io/openshift-release-dev/ocp-release@sha256:e1c2377fdae1d063aaddc753b99acf25972b6997ab9a0b7e80cfef627b9ef3dd

   참고
   • 권장 업데이트가 없는 경우 알려진 문제가 있는 업데이트를 계속 사용할 수 있습니다. 자세한 내용은 조건부 업데이트 경로를 따라업데이트를 참조하십시오.
   • 컨트롤 플레인만 업데이트하는 방법에 대한 자세한 내용 및 자세한 내용은 추가 리소스 섹션에 나열된 컨트롤 플레인만 업데이트 준비 페이지를 참조하십시오.

2. 조직 요구 사항에 따라 적절한 업데이트 채널을 설정합니다. 예를 들어 채널을 stable-4.13 또는 fast-4.13 으로 설정할 수 있습니다. 채널에 대한 자세한 내용은 추가 리소스 섹션에 나열된 업데이트 채널 및 릴리스 이해 를 참조하십시오.

   $ oc adm upgrade channel <channel>

   예를 들어 채널을 stable-4.17 로 설정하려면 다음을 수행합니다.

   $ oc adm upgrade channel stable-4.17

   중요

   프로덕션 클러스터의 경우 stable-*, eus-* 또는 fast-* 채널에 가입해야 합니다.

   참고

   다음 마이너 버전으로 이동할 준비가 되면 해당 마이너 버전에 해당하는 채널을 선택합니다. 업데이트 채널이 더 빨리 선언될수록 클러스터가 대상 버전으로의 경로를 업데이트하는 것이 좋습니다. 클러스터는 사용 가능한 모든 업데이트를 평가하고 선택할 수 있는 최상의 업데이트 권장 사항을 제공하는 데 시간이 걸릴 수 있습니다. 업데이트 권장 사항은 당시 사용할 수 있는 업데이트 옵션을 기반으로 하므로 시간이 지남에 따라 변경될 수 있습니다.

   대상 마이너 버전에 대한 업데이트 경로가 표시되지 않는 경우 경로에서 다음 마이너 버전을 사용할 수 있을 때까지 현재 버전의 최신 패치 릴리스로 클러스터를 계속 업데이트합니다.

3. 업데이트를 적용합니다.

   • 최신 버전으로 업데이트하려면 다음을 수행합니다.

     $ oc adm upgrade --to-latest=true 1

   • 특정 버전으로 업데이트하려면 다음을 수행합니다.

     $ oc adm upgrade --to=<version> 1

     1 1

     <version >은 oc adm upgrade 명령의 출력에서 얻은 업데이트 버전입니다.

     중요

     oc adm upgrade --help 를 사용하는 경우 --force 에 대한 나열된 옵션이 있습니다. --force 옵션을 사용하면 릴리스 확인 및 사전 조건 검사를 포함하여 클러스터 측 가드를 우회하므로 이는 바람직 하지 않습니다. --force 를 사용하면 성공적인 업데이트가 보장되지 않습니다. 가드를 우회하면 클러스터가 위험하게 됩니다.

4. 클러스터 버전 Operator의 상태를 확인합니다.

   $ oc adm upgrade

5. 업데이트가 완료되면 클러스터 버전이 새 버전으로 업데이트되었는지 확인합니다.

   $ oc adm upgrade

   출력 예

   Cluster version is <version>
   
   Upstream is unset, so the cluster will use an appropriate default.
   Channel: stable-<version> (available channels: candidate-<version>, eus-<version>, fast-<version>, stable-<version>)
   
   No updates available. You may force an update to a specific release image, but doing so might not be supported and might result in downtime or data loss.

6. 클러스터를 버전 X.y에서 X.(y+1)로 업데이트하는 경우 새 기능을 사용하는 워크로드를 배포하기 전에 노드가 업데이트되었는지 확인하는 것이 좋습니다.

   $ oc get nodes

   출력 예

   NAME                           STATUS   ROLES    AGE   VERSION
   ip-10-0-168-251.ec2.internal   Ready    master   82m   v1.30.3
   ip-10-0-170-223.ec2.internal   Ready    master   82m   v1.30.3
   ip-10-0-179-95.ec2.internal    Ready    worker   70m   v1.30.3
   ip-10-0-182-134.ec2.internal   Ready    worker   70m   v1.30.3
   ip-10-0-211-16.ec2.internal    Ready    master   82m   v1.30.3
   ip-10-0-250-100.ec2.internal   Ready    worker   69m   v1.30.3

프로세스

1. 다음 명령을 실행하여 OC_ENABLE_CMD_UPGRADE_STATUS 환경 변수를 true 로 설정합니다.

   $ export OC_ENABLE_CMD_UPGRADE_STATUS=true

2. oc adm upgrade status 명령을 실행합니다.

   $ oc adm upgrade status

   예 3.1. 성공적으로 진행 중인 업데이트 출력 예

   = Control Plane =
   Assessment:      Progressing
   Target Version:  4.14.1 (from 4.14.0)
   Completion:      97%
   Duration:        54m
   Operator Status: 32 Healthy, 1 Unavailable
   
   Control Plane Nodes
   NAME                                        ASSESSMENT    PHASE      VERSION   EST    MESSAGE
   ip-10-0-53-40.us-east-2.compute.internal    Progressing   Draining   4.14.0    +10m
   ip-10-0-30-217.us-east-2.compute.internal   Outdated      Pending    4.14.0    ?
   ip-10-0-92-180.us-east-2.compute.internal   Outdated      Pending    4.14.0    ?
   
   = Worker Upgrade =
   
   = Worker Pool =
   Worker Pool:     worker
   Assessment:      Progressing
   Completion:      0%
   Worker Status:   3 Total, 2 Available, 1 Progressing, 3 Outdated, 1 Draining, 0 Excluded, 0 Degraded
   
   Worker Pool Nodes
   NAME                                        ASSESSMENT    PHASE      VERSION   EST    MESSAGE
   ip-10-0-4-159.us-east-2.compute.internal    Progressing   Draining   4.14.0    +10m
   ip-10-0-20-162.us-east-2.compute.internal   Outdated      Pending    4.14.0    ?
   ip-10-0-99-40.us-east-2.compute.internal    Outdated      Pending    4.14.0    ?
   
   = Worker Pool =
   Worker Pool:     infra
   Assessment:      Progressing
   Completion:      0%
   Worker Status:   1 Total, 0 Available, 1 Progressing, 1 Outdated, 1 Draining, 0 Excluded, 0 Degraded
   
   Worker Pool Node
   NAME                                             ASSESSMENT    PHASE      VERSION   EST    MESSAGE
   ip-10-0-4-159-infra.us-east-2.compute.internal   Progressing   Draining   4.14.0    +10m
   
   = Update Health =
   SINCE   LEVEL   IMPACT   MESSAGE
   14m4s   Info    None     Update is proceeding well

   이 정보를 사용하면 업데이트를 진행하는 방법에 대한 정보에 입각한 결정을 내릴 수 있습니다.

프로세스

1. 위험이 적용될 수 있으므로 권장되지 않는 경우 업데이트 설명을 보려면 다음 명령을 실행합니다.

   $ oc adm upgrade --include-not-recommended

2. 클러스터 관리자가 알려진 위험을 평가하고 현재 클러스터에 대해 허용 가능한 것으로 결정하는 경우 관리자는 안전 가드를 포기하고 다음 명령을 실행하여 업데이트를 진행할 수 있습니다.

   $ oc adm upgrade --allow-not-recommended --to <version> <.>

   <.> <version>은 이전 명령의 출력에서 얻은 업데이트 버전입니다. 이는 지원되지만 알려진 문제 또는 위험도 있습니다.

프로세스

1. 관리 → 클러스터 설정으로 이동하여 버전을 클릭합니다.

2. YAML 탭을 클릭한 다음 업스트림 매개변수 값을 편집합니다.

   출력 예

     ...
     spec:
       clusterID: db93436d-7b05-42cc-b856-43e11ad2d31a
       upstream: '<update-server-url>' 1
     ...

   1

   <update-server-url> 변수는 업데이트 서버의 URL을 지정합니다.

   기본 upstream은 https://api.openshift.com/api/upgrades_info/v1/graph입니다.

3. 저장을 클릭합니다.

프로세스

1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
2. Compute → MachineHealthChecks 로 이동합니다.

3. 머신 상태 점검을 일시 중지하려면 cluster.x-k8s.io/paused="" 주석을 각 MachineHealthCheck 리소스에 추가합니다. 예를 들어 machine-api-termination-handler 리소스에 주석을 추가하려면 다음 단계를 완료합니다.

   1. machine-api-termination-handler 옆에 있는 옵션 메뉴 를 클릭하고 주석 편집을 클릭합니다.
   2. 주석 편집 대화 상자에서 추가 를 클릭합니다.
   3. 키 및 값 필드에 cluster.x-k8s.io/paused 및 "" 값을 각각 추가하고 저장을 클릭합니다.

프로세스

1. 웹 콘솔에서 Administration → Cluster Settings을 클릭하고 Details 탭의 내용을 확인합니다.

2. 프로덕션 클러스터의 경우 stable-4.17 과 같이 업데이트할 버전에 대해 Channel 이 올바른 채널로 설정되어 있는지 확인합니다.

   중요

   프로덕션 클러스터의 경우 stable-*, eus-* 또는 fast-* 채널에 가입해야 합니다.

   참고

   다음 마이너 버전으로 이동할 준비가 되면 해당 마이너 버전에 해당하는 채널을 선택합니다. 업데이트 채널이 더 빨리 선언될수록 클러스터가 대상 버전으로의 경로를 업데이트하는 것이 좋습니다. 클러스터는 사용 가능한 모든 업데이트를 평가하고 선택할 수 있는 최상의 업데이트 권장 사항을 제공하는 데 시간이 걸릴 수 있습니다. 업데이트 권장 사항은 당시 사용할 수 있는 업데이트 옵션을 기반으로 하므로 시간이 지남에 따라 변경될 수 있습니다.

   대상 마이너 버전에 대한 업데이트 경로가 표시되지 않는 경우 경로에서 다음 마이너 버전을 사용할 수 있을 때까지 현재 버전의 최신 패치 릴리스로 클러스터를 계속 업데이트합니다.

   • Update status 가 Updates available 이 아닌 경우 클러스터를 업데이트할 수 없습니다.
   • Select channel은 클러스터가 실행 중이거나 업데이트 중인 클러스터 버전을 나타냅니다.

3. 업데이트할 버전을 선택하고 저장을 클릭합니다.

   입력 채널 Update Status가 Update to <product-version> in progress로 변경되고 Operator 및 노드의 진행률을 확인하여 클러스터 업데이트의 진행 상황을 검토할 수 있습니다.

   참고

   예를 들어 버전 4.10에서 4.11로 클러스터를 업데이트하는 경우 새 기능을 사용하는 워크로드를 배포하기 전에 노드가 업데이트되었는지 확인합니다. 아직 업데이트되지 않은 작업자 노드가 있는 풀은 클러스터 설정 페이지에 표시됩니다.

4. 업데이트가 완료되고 Cluster Version Operator가 사용 가능한 업데이트를 새로 고침한 후 현재 채널에서 사용 가능한 추가 업데이트가 있는지 확인합니다.

   • 업데이트가 있는 경우 더 이상 업데이트할 수 없을 때까지 현재 채널에서 업데이트를 계속 수행합니다.
   • 사용 가능한 업데이트가 없는 경우 채널을 다음 마이너 버전의 stable-*, eus-* 또는 fast-* 채널로 변경하고 해당 채널에서 원하는 버전으로 업데이트합니다.

   필요한 버전에 도달할 때까지 여러 중간 업데이트를 수행해야 할 수도 있습니다.

프로세스

1. 웹 콘솔에서 관리 → 클러스터 설정 페이지를 클릭하고 세부 정보 탭의 내용을 검토합니다.

2. 업데이트 클러스터 모달의 새 버전 선택 드롭다운에서 알려진 문제 기능이 있는 버전 포함 기능을 활성화하여 드롭다운 목록을 조건부 업데이트로 채울 수 있습니다.

   참고

   알려진 문제가 있는 버전을 선택하면 해당 버전과 관련된 잠재적인 위험이 더 많은 정보가 제공됩니다.

3. 업데이트할 잠재적인 위험을 자세히 설명하는 알림을 검토하십시오.

1. 작업자 풀을 기반으로 사용자 지정 MCP(머신 구성 풀)를 생성합니다.

   참고

   MCP에서 maxUnavailable 설정을 변경하여 언제든지 업데이트할 수 있는 머신 수를 지정할 수 있습니다. 기본값은 1입니다.

   주의

   maxUnavailable 의 기본 설정은 OpenShift Container Platform의 모든 머신 구성 풀에 대해 1 입니다. 이 값을 변경하지 않고 한 번에 하나의 컨트롤 플레인 노드를 업데이트하는 것이 좋습니다. 컨트롤 플레인 풀의 경우 이 값을 3 으로 변경하지 마십시오.

2. 사용자 지정 MCP에 노드 선택기를 추가합니다. 나머지 클러스터와 동시에 업데이트하지 않으려는 각 노드에 대해 일치하는 레이블을 노드에 추가합니다. 이 레이블은 노드를 MCP에 연결합니다.

   중요

   노드에서 기본 작업자 레이블을 제거하지 마십시오. 노드에는 클러스터에서 제대로 작동하려면 역할 레이블이 있어야 합니다.

3. 업데이트 프로세스의 일부로 업데이트하지 않으려는 MCP를 일시 중지합니다.
4. 클러스터 업데이트를 수행합니다. 업데이트 프로세스는 컨트롤 플레인 노드를 포함하여 일시 중지되지 않은 MCP를 업데이트합니다.
5. 업데이트된 노드에서 애플리케이션을 테스트하여 애플리케이션이 예상대로 작동하는지 확인합니다.
6. 나머지 MCP 중 일시 중지를 해제하고 해당 풀의 노드가 업데이트가 완료될 때까지 기다린 후 해당 노드에서 애플리케이션을 테스트합니다. 모든 작업자 노드가 업데이트될 때까지 이 프로세스를 반복합니다.
7. 선택 사항: 업데이트된 노드에서 사용자 지정 레이블을 제거하고 사용자 지정 MCP를 삭제합니다.

프로세스

1. 다음 명령을 실행하여 클러스터의 작업자 노드를 나열합니다.

   $ oc get -l 'node-role.kubernetes.io/master!=' -o 'jsonpath={range .items[*]}{.metadata.name}{"\n"}{end}' nodes

   출력 예

   ci-ln-pwnll6b-f76d1-s8t9n-worker-a-s75z4
   ci-ln-pwnll6b-f76d1-s8t9n-worker-b-dglj2
   ci-ln-pwnll6b-f76d1-s8t9n-worker-c-lldbm

2. 지연할 각 노드에 대해 다음 명령을 실행하여 노드에 사용자 정의 라벨을 추가합니다.

   $ oc label node <node_name> node-role.kubernetes.io/<custom_label>=

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

   $ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary=

   출력 예

   node/ci-ln-gtrwm8t-f76d1-spbl7-worker-a-xk76k labeled

3. 새 MCP를 생성합니다.

   1. MCP YAML 파일을 생성합니다.

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

      1

      MCP의 이름을 지정합니다.

      2

      worker 및 사용자 지정 MCP 이름을 지정합니다.

      3

      이 풀에서 원하는 노드에 추가한 사용자 지정 라벨을 지정합니다.

   2. 다음 명령을 실행하여 MachineConfigPool 오브젝트를 생성합니다.

      $ oc create -f <file_name>

      출력 예

      machineconfigpool.machineconfiguration.openshift.io/workerpool-canary created

4. 다음 명령을 실행하여 클러스터의 MCP 목록과 현재 상태를 확인합니다.

   $ oc get machineconfigpool

   출력 예

   NAME              CONFIG                                                        UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master            rendered-master-b0bb90c4921860f2a5d8a2f8137c1867              True      False      False      3              3                   3                     0                      97m
   workerpool-canary rendered-workerpool-canary-87ba3dec1ad78cb6aecebf7fbb476a36   True      False      False      1              1                   1                     0                      2m42s
   worker            rendered-worker-87ba3dec1ad78cb6aecebf7fbb476a36              True      False      False      2              2                   2                     0                      97m

   새 머신 구성 풀 workerpool-canary가 생성되고 사용자 정의 레이블을 추가한 노드 수가 머신 수에 표시됩니다. 작업자 MCP 머신 수는 동일한 수만큼 줄어듭니다. 시스템 수를 업데이트하는 데 몇 분이 걸릴 수 있습니다. 이 예에서는 하나의 노드가 worker MCP에서 workerpool-canary MCP로 이동되었습니다.

프로세스

1. 다음 두 단계에 설명된 대로 보조 MCP를 생성합니다.

   1. 다음 구성 파일을 machineConfigPool.yaml 로 저장합니다.

      Example machineConfigPool YAML

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

   2. 다음 명령을 실행하여 새 머신 구성 풀을 생성합니다.

      $ oc create -f machineConfigPool.yaml

      출력 예

      machineconfigpool.machineconfiguration.openshift.io/worker-perf created

2. 보조 MCP에 일부 머신을 추가합니다. 다음 예제에서는 작업자 노드 worker-a,worker-b, worker-c 를 MCP worker-perf 로 레이블을 지정합니다.

   $ oc label node worker-a node-role.kubernetes.io/worker-perf=''

   $ oc label node worker-b node-role.kubernetes.io/worker-perf=''

   $ oc label node worker-c node-role.kubernetes.io/worker-perf=''

3. 다음 두 단계에 설명된 대로 MCP worker-perf 의 새 MachineConfig 를 생성합니다.

   1. 다음 MachineConfig 예제를 new-machineconfig.yaml 이라는 파일로 저장합니다.

      MachineConfig YAML의 예

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: worker-perf
        name: 06-kdump-enable-worker-perf
      spec:
        config:
          ignition:
            version: 3.2.0
          systemd:
            units:
            - enabled: true
              name: kdump.service
        kernelArguments:
          - crashkernel=512M
      # ...

   2. 다음 명령을 실행하여 MachineConfig 를 적용합니다.

      $ oc create -f new-machineconfig.yaml

4. 새 카나리아 MCP를 생성하고 이전 단계에서 생성한 MCP에서 머신을 추가합니다. 다음 예제에서는 worker-perf-canary 라는 MCP를 생성하고 미리 생성한 worker-perf MCP에서 머신을 추가합니다.

   1. 다음 명령을 실행하여 카나리아 작업자 노드 worker-a 에 레이블을 지정합니다.

      $ oc label node worker-a node-role.kubernetes.io/worker-perf-canary=''

   2. 다음 명령을 실행하여 카나리아 작업자 노드 worker-a 를 원래 MCP에서 제거합니다.

      $ oc label node worker-a node-role.kubernetes.io/worker-perf-

   3. 다음 파일을 machineConfigPool-Canary.yaml 로 저장합니다.

      Example machineConfigPool-Canary.yaml file

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

      1

      선택적 값입니다. 이 예제에는 worker-perf-canary 가 추가 값으로 포함됩니다. 이 방법으로 값을 사용하여 추가 MachineConfig 의 멤버를 구성할 수 있습니다.

   4. 다음 명령을 실행하여 새 worker-perf-canary 를 생성합니다.

      $ oc create -f machineConfigPool-Canary.yaml

      출력 예

      machineconfigpool.machineconfiguration.openshift.io/worker-perf-canary created

5. MachineConfig 가 worker-perf-canary 에 상속되었는지 확인합니다.

   1. 다음 명령을 실행하여 MCP의 성능이 저하되지 않았는지 확인합니다.

      $ oc get mcp

      출력 예

      NAME                  CONFIG                                                          UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
      master                rendered-master-2bf1379b39e22bae858ea1a3ff54b2ac                True      False      False      3              3                   3                     0                      5d16h
      worker                rendered-worker-b9576d51e030413cfab12eb5b9841f34                True      False      False      0              0                   0                     0                      5d16h
      worker-perf          rendered-worker-perf-b98a1f62485fa702c4329d17d9364f6a          True      False      False      2              2                   2                     0                      56m
      worker-perf-canary   rendered-worker-perf-canary-b98a1f62485fa702c4329d17d9364f6a   True      False      False      1              1                   1                     0                      44m

   2. 시스템이 worker-perf에서 worker- perf -canary 로 상속되었는지 확인합니다.

      $ oc get nodes

      출력 예

      NAME       STATUS   ROLES                        AGE     VERSION
      ...
      worker-a   Ready    worker,worker-perf-canary   5d15h   v1.27.13+e709aa5
      worker-b   Ready    worker,worker-perf          5d15h   v1.27.13+e709aa5
      worker-c   Ready    worker,worker-perf          5d15h   v1.27.13+e709aa5

   3. 다음 명령을 실행하여 worker-a 에서 kdump 서비스가 활성화되어 있는지 확인합니다.

      $ systemctl status kdump.service

      출력 예

      NAME       STATUS   ROLES                        AGE     VERSION
      ...
      kdump.service - Crash recovery kernel arming
           Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; preset: disabled)
           Active: active (exited) since Tue 2024-09-03 12:44:43 UTC; 10s ago
          Process: 4151139 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
         Main PID: 4151139 (code=exited, status=0/SUCCESS)

   4. 다음 명령을 실행하여 MCP가 crashkernel 을 업데이트했는지 확인합니다.

      $ cat /proc/cmdline

      출력에는 업데이트된 crashekernel 값이 포함되어야 합니다. 예를 들면 다음과 같습니다.

      출력 예

      crashkernel=512M

6. 선택 사항: 업그레이드에 만족하는 경우 worker-a 를 worker-perf 로 반환할 수 있습니다.

   1. 다음 명령을 실행하여 worker-a 를 worker-perf 로 반환합니다.

      $ oc label node worker-a node-role.kubernetes.io/worker-perf=''

   2. 다음 명령을 실행하여 카나리아 MCP에서 worker-a 를 제거합니다.

      $ oc label node worker-a node-role.kubernetes.io/worker-perf-canary-

프로세스

1. 다음 명령을 실행하여 일시 중지하려는 MCP를 패치합니다.

   $ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":true}}' --type=merge

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

   $  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":true}}' --type=merge

   출력 예

   machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

프로세스

1. 일시 중지 해제할 MCP를 패치합니다.

   $ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":false}}' --type=merge

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

   $  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":false}}' --type=merge

   출력 예

   machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

2. 선택 사항: 다음 옵션 중 하나를 사용하여 업데이트 진행 상황을 확인합니다.

   1. 관리 → 클러스터 설정을 클릭하여 웹 콘솔에서 진행 상황을 확인합니다.

   2. 다음 명령을 실행하여 진행 상황을 확인합니다.

      $ oc get machineconfigpools

3. 업데이트된 노드에서 애플리케이션을 테스트하여 애플리케이션이 예상대로 작동하는지 확인합니다.
4. 일시 중지된 다른 MCP에 대해 한 번에 하나씩 이 프로세스를 반복합니다.

프로세스

1. 사용자 지정 MCP의 각 노드에 대해 다음 명령을 실행하여 노드에서 사용자 지정 레이블을 제거합니다.

   $ oc label node <node_name> node-role.kubernetes.io/<custom_label>-

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

   $ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary-

   출력 예

   node/ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz labeled

   Machine Config Operator는 노드를 원래 MCP로 다시 이동하고 노드를 MCP 구성으로 조정합니다.

2. 노드가 사용자 지정 MCP에서 제거되었는지 확인하려면 다음 명령을 실행하여 클러스터의 MCP 목록과 현재 상태를 확인합니다.

   $ oc get mcp

   출력 예

   NAME                CONFIG                                                   UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master              rendered-master-1203f157d053fd987c7cbd91e3fbc0ed         True      False      False      3              3                   3                     0                      61m
   workerpool-canary   rendered-mcp-noupdate-5ad4791166c468f3a35cd16e734c9028   True      False      False      0              0                   0                     0                      21m
   worker              rendered-worker-5ad4791166c468f3a35cd16e734c9028         True      False      False      3              3                   3                     0                      61m

   노드가 사용자 지정 MCP에서 제거되고 원래 MCP로 다시 이동하면 시스템 수를 업데이트하는 데 몇 분이 걸릴 수 있습니다. 이 예에서는 하나의 노드가 제거된 workerpool-canary MCP에서 worker MCP로 이동되었습니다.

3. 선택 사항: 다음 명령을 실행하여 사용자 지정 MCP를 삭제합니다.

   $ oc delete mcp <mcp_name>

프로세스

1. 웹 콘솔에서 Administration → Cluster Settings을 클릭하고 Details 탭의 내용을 확인합니다.

2. 프로덕션 클러스터의 경우 stable-4.17 과 같이 업데이트할 버전에 대해 Channel 이 올바른 채널로 설정되어 있는지 확인합니다.

   중요

   프로덕션 클러스터의 경우 stable-*, eus-* 또는 fast-* 채널에 가입해야 합니다.

   참고

   다음 마이너 버전으로 이동할 준비가 되면 해당 마이너 버전에 해당하는 채널을 선택합니다. 업데이트 채널이 더 빨리 선언될수록 클러스터가 대상 버전으로의 경로를 업데이트하는 것이 좋습니다. 클러스터는 사용 가능한 모든 업데이트를 평가하고 선택할 수 있는 최상의 업데이트 권장 사항을 제공하는 데 시간이 걸릴 수 있습니다. 업데이트 권장 사항은 당시 사용할 수 있는 업데이트 옵션을 기반으로 하므로 시간이 지남에 따라 변경될 수 있습니다.

   대상 마이너 버전에 대한 업데이트 경로가 표시되지 않는 경우 경로에서 다음 마이너 버전을 사용할 수 있을 때까지 현재 버전의 최신 패치 릴리스로 클러스터를 계속 업데이트합니다.

   • Update status 가 Updates available 이 아닌 경우 클러스터를 업데이트할 수 없습니다.
   • Select channel은 클러스터가 실행 중이거나 업데이트 중인 클러스터 버전을 나타냅니다.

3. 업데이트할 버전을 선택하고 저장을 클릭합니다.

   입력 채널 Update Status가 Update to <product-version> in progress로 변경되고 Operator 및 노드의 진행률을 확인하여 클러스터 업데이트의 진행 상황을 검토할 수 있습니다.

   참고

   예를 들어 버전 4.10에서 4.11로 클러스터를 업데이트하는 경우 새 기능을 사용하는 워크로드를 배포하기 전에 노드가 업데이트되었는지 확인합니다. 아직 업데이트되지 않은 작업자 노드가 있는 풀은 클러스터 설정 페이지에 표시됩니다.

4. 업데이트가 완료되고 Cluster Version Operator가 사용 가능한 업데이트를 새로 고침한 후 현재 채널에서 사용 가능한 추가 업데이트가 있는지 확인합니다.

   • 업데이트가 있는 경우 더 이상 업데이트할 수 없을 때까지 현재 채널에서 업데이트를 계속 수행합니다.
   • 사용 가능한 업데이트가 없는 경우 채널을 다음 마이너 버전의 stable-*, eus-* 또는 fast-* 채널로 변경하고 해당 채널에서 원하는 버전으로 업데이트합니다.

   필요한 버전에 도달할 때까지 여러 중간 업데이트를 수행해야 할 수도 있습니다.

   중요

   RHEL (Red Hat Enterprise Linux) 작업자 시스템이 포함된 클러스터를 업데이트하면 업데이트 프로세스 중에 해당 작업자를 일시적으로 사용할 수 없게 됩니다. 클러스터가 NotReady 상태가 되면 각 RHEL 머신에 대해 업데이트 플레이북을 실행하여 업데이트를 완료해야 합니다.

프로세스

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

   # systemctl disable --now firewalld.service

   참고

   기본적으로 "최소" 설치 옵션이 있는 기본 OS RHEL에서는 firewalld 서비스를 활성화합니다. 호스트에서 firewalld 서비스를 활성화하면 작업자의 OpenShift Container Platform 로그에 액세스할 수 없습니다. 작업자의 OpenShift Container Platform 로그에 계속 액세스하려면 나중에 firewalld를 활성화하지 마십시오.

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

   1. Ansible Playbook을 실행하는 컴퓨터에서 필요한 리포지토리를 업데이트합니다.

      # subscription-manager repos --disable=rhocp-4.16-for-rhel-8-x86_64-rpms \
                                   --enable=rhocp-4.17-for-rhel-8-x86_64-rpms

      중요

      OpenShift Container Platform 4.11부터 Ansible 플레이북은 RHEL 8에만 제공됩니다. RHEL 7 시스템이 OpenShift Container Platform 4.10 Ansible 플레이북의 호스트로 사용된 경우 Ansible 호스트를 RHEL 8로 업데이트하거나 RHEL 8 시스템에서 새 Ansible 호스트를 생성하고 이전 Ansible 호스트의 인벤토리를 통해 복사해야 합니다.

   2. Ansible 플레이북을 실행하는 시스템에서 Ansible 패키지를 업데이트합니다.

      # yum swap ansible ansible-core

   3. Ansible Playbook을 실행하는 시스템에서 openshift-ansible을 포함하여 필요한 패키지를 업데이트합니다.

      # yum update openshift-ansible openshift-clients

   4. 각 RHEL 컴퓨팅 노드에 필요한 리포지토리를 업데이트합니다.

      # subscription-manager repos --disable=rhocp-4.16-for-rhel-8-x86_64-rpms \
                                   --enable=rhocp-4.17-for-rhel-8-x86_64-rpms

3. RHEL 작업자 시스템을 업데이트합니다.

   1. 다음 예와 같이 /<path>/inventory/hosts 에서 Ansible 인벤토리 파일을 검토하고 RHEL 8 시스템이 [workers] 섹션에 나열되도록 콘텐츠를 업데이트합니다.

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

   2. openshift-ansible 디렉토리로 변경합니다.

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

   3. upgrade Playbook을 실행합니다.

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

      1

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

      참고

      upgrade 플레이북은 OpenShift Container Platform 패키지만 업데이트합니다. 운영 체제 패키지를 업데이트하지 않습니다.

4. 모든 작업자를 업데이트한 후 모든 클러스터 노드가 새 버전으로 업데이트되었는지 확인합니다.

   # oc get node

   출력 예

   NAME                        STATUS                        ROLES    AGE    VERSION
   mycluster-control-plane-0   Ready                         master   145m   v1.30.3
   mycluster-control-plane-1   Ready                         master   145m   v1.30.3
   mycluster-control-plane-2   Ready                         master   145m   v1.30.3
   mycluster-rhel8-0           Ready                         worker   98m    v1.30.3
   mycluster-rhel8-1           Ready                         worker   98m    v1.30.3
   mycluster-rhel8-2           Ready                         worker   98m    v1.30.3
   mycluster-rhel8-3           Ready                         worker   98m    v1.30.3

5. 선택 사항: upgrade 플레이북에서 업데이트하지 않은 운영 체제 패키지를 업데이트합니다. 4.17에 없는 패키지를 업데이트하려면 다음 명령을 사용합니다.

   # yum update

   참고

   4.17을 설치할 때 사용한 것과 동일한 RPM 리포지토리를 사용하는 경우 RPM 패키지를 제외할 필요가 없습니다.

프로세스

1. 다음 명령을 실행하여 CVO(Cluster Version Operator)에서 RetrievedUpdates 조건이 True 인지 확인합니다.

   $ oc get clusterversion/version -o=jsonpath="{.status.conditions[?(.type=='RetrievedUpdates')].status}"

   RetrievedUpates 조건이 False 인 경우 다음 명령을 사용하여 실패에 대한 추가 정보를 찾을 수 있습니다.

   $ oc adm upgrade

   클러스터 버전 조건 유형에 대한 자세한 내용은 클러스터 버전 조건 유형 이해 를 참조하십시오.

2. RetrievedUpdates 조건이 False 인 경우 다음 명령을 사용하여 채널을 stable-<4.y > 또는 fast-<4.y >로 변경합니다.

   $ oc adm upgrade channel <channel>

   채널을 설정한 후 RetrievedUpdates 가 True 인지 확인합니다.

   채널에 대한 자세한 내용은 업데이트 채널 및 릴리스 이해 를 참조하십시오.

3. 다음 명령을 사용하여 다중 아키텍처 페이로드로 마이그레이션합니다.

   $ oc adm upgrade --to-multi-arch

1. 시스템 상태를 검사합니다.

   # bootupctl status

   x86_64출력 예

   Component EFI
     Installed: grub2-efi-x64-1:2.04-31.el8_4.1.x86_64,shim-x64-15-8.el8_1.x86_64
     Update: At latest version

   aarch64의 출력 예

   Component EFI
     Installed: grub2-efi-aa64-1:2.02-99.el8_4.1.aarch64,shim-aa64-15.4-2.el8_1.aarch64
     Update: At latest version

2. 초기 버전 4.4 이상에 OpenShift Container Platform 클러스터는 명시적 채택 단계가 필요합니다.

   시스템 상태가 Adoptable인 경우 채택을 수행합니다.

   # bootupctl adopt-and-update

   출력 예

   Updated: grub2-efi-x64-1:2.04-31.el8_4.1.x86_64,shim-x64-15-8.el8_1.x86_64

3. 업데이트를 사용할 수 있는 경우 다음 재부팅에 변경 사항이 적용되도록 업데이트를 적용합니다.

   # bootupctl update

   출력 예

   Updated: grub2-efi-x64-1:2.04-31.el8_4.1.x86_64,shim-x64-15-8.el8_1.x86_64

1. bootupctl-update.service systemd 장치의 내용을 포함하여 Butane 구성 파일 99-worker-bootupctl-update.bu 를 생성합니다.

   참고

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

   출력 예

   variant: openshift
   version: 4.17.0
   metadata:
     name: 99-worker-chrony 1
     labels:
       machineconfiguration.openshift.io/role: worker 2
   systemd:
     units:
     - name: bootupctl-update.service
       enabled: true
       contents: |
         [Unit]
         Description=Bootupd automatic update
   
         [Service]
         ExecStart=/usr/bin/bootupctl update
         RemainAfterExit=yes
   
         [Install]
         WantedBy=multi-user.target

   1 2

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

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

   $ butane 99-worker-bootupctl-update.bu -o 99-worker-bootupctl-update.yaml

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

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

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

     $ oc apply -f ./99-worker-bootupctl-update.yaml

절차

1. 다음 명령을 실행하여 OC_ENABLE_CMD_UPGRADE_STATUS 환경 변수를 true 로 설정합니다.

   $ export OC_ENABLE_CMD_UPGRADE_STATUS=true

2. oc adm upgrade status 명령을 실행합니다.

   $ oc adm upgrade status

   예 4.1. 성공적으로 진행 중인 업데이트 출력 예

   = Control Plane =
   Assessment:      Progressing
   Target Version:  4.14.1 (from 4.14.0)
   Completion:      97%
   Duration:        54m
   Operator Status: 32 Healthy, 1 Unavailable
   
   Control Plane Nodes
   NAME                                        ASSESSMENT    PHASE      VERSION   EST    MESSAGE
   ip-10-0-53-40.us-east-2.compute.internal    Progressing   Draining   4.14.0    +10m
   ip-10-0-30-217.us-east-2.compute.internal   Outdated      Pending    4.14.0    ?
   ip-10-0-92-180.us-east-2.compute.internal   Outdated      Pending    4.14.0    ?
   
   = Worker Upgrade =
   
   = Worker Pool =
   Worker Pool:     worker
   Assessment:      Progressing
   Completion:      0%
   Worker Status:   3 Total, 2 Available, 1 Progressing, 3 Outdated, 1 Draining, 0 Excluded, 0 Degraded
   
   Worker Pool Nodes
   NAME                                        ASSESSMENT    PHASE      VERSION   EST    MESSAGE
   ip-10-0-4-159.us-east-2.compute.internal    Progressing   Draining   4.14.0    +10m
   ip-10-0-20-162.us-east-2.compute.internal   Outdated      Pending    4.14.0    ?
   ip-10-0-99-40.us-east-2.compute.internal    Outdated      Pending    4.14.0    ?
   
   = Worker Pool =
   Worker Pool:     infra
   Assessment:      Progressing
   Completion:      0%
   Worker Status:   1 Total, 0 Available, 1 Progressing, 1 Outdated, 1 Draining, 0 Excluded, 0 Degraded
   
   Worker Pool Node
   NAME                                             ASSESSMENT    PHASE      VERSION   EST    MESSAGE
   ip-10-0-4-159-infra.us-east-2.compute.internal   Progressing   Draining   4.14.0    +10m
   
   = Update Health =
   SINCE   LEVEL   IMPACT   MESSAGE
   14m4s   Info    None     Update is proceeding well

   이 정보를 사용하면 업데이트를 진행하는 방법에 대한 정보에 입각한 결정을 내릴 수 있습니다.