프로세스

1. 다음 명령을 실행하여 OpenShift Container Platform 릴리스 이미지를 가져옵니다.

   $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')

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 릴리스 이미지 내의 CCO 컨테이너 이미지에서 ccoctl 바이너리를 추출합니다.

   $ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret

4. 다음 명령을 실행하여 ccoctl 을 실행 가능하게 하려면 권한을 변경합니다.

   $ chmod 775 ccoctl

프로세스

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

   $ oc adm release extract --credentials-requests \
     --cloud=<provider_type> \
     --to=<path_to_directory_with_list_of_credentials_requests>/credrequests \
     quay.io/<path_to>/ocp-release:<version>

   다음과 같습니다.

   • <provider_type >은 클라우드 공급자의 값입니다. 유효한 값은 alibabacloud,aws,gcp,ibmcloud, nutanix 입니다.
   • credrequests 는 CredentialsRequest 오브젝트 목록이 저장되는 디렉터리입니다. 이 명령은 디렉터리가 없는 경우 해당 디렉터리를 생성합니다.

2. 릴리스 이미지의 각 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에는 다른 플랫폼별 값이 있는 유사한 형식이 있습니다.

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

   $ oc create namespace <component_namespace>

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

   • CloudEvent Cloud: ccoctl alibabacloud create-ram-users
   • Amazon Web Services (AWS): ccoctl aws create-iam-roles
   • GCP(Google Cloud Platform): ccoctl gcp create-all
   • IBM Cloud: ccoctl ibmcloud create-service-id
   • Nutanix: ccoctl nutanix create-shared-secrets
   중요

   필요한 인수 및 특수 고려 사항에 대한 중요한 플랫폼별 세부 사항은 클라우드 공급자의 설치 콘텐츠의 ccoctl 유틸리티 지침을 참조하십시오.

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

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

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

절차

1. 새 릴리스에 대한 CredentialsRequest 사용자 지정 리소스를 추출하고 검사합니다.

   클라우드 공급자의 설치 콘텐츠의 "Manually creating IAM" 섹션은 클라우드에 필요한 인증 정보를 얻고 사용하는 방법을 설명합니다.

2. 클러스터에서 수동으로 유지 관리되는 인증 정보를 업데이트합니다.

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

3. 클러스터에서 클러스터 기능을 사용하여 하나 이상의 선택적 구성 요소를 비활성화하는 경우 비활성화된 구성 요소에 대한 CredentialsRequest 사용자 정의 리소스를 삭제합니다.

   AWS의 OpenShift Container Platform 4.12에 대한 credrequests 디렉터리 콘텐츠 예

   0000_30_machine-api-operator_00_credentials-request.yaml 1
   0000_50_cloud-credential-operator_05-iam-ro-credentialsrequest.yaml 2
   0000_50_cluster-image-registry-operator_01-registry-credentials-request.yaml 3
   0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 4
   0000_50_cluster-network-operator_02-cncc-credentials.yaml 5
   0000_50_cluster-storage-operator_03_credentials_request_aws.yaml 6

   1

   Machine API Operator CR이 필요합니다.

   2

   Cloud Credential Operator CR이 필요합니다.

   3

   이미지 레지스트리 Operator CR이 필요합니다.

   4

   Ingress Operator CR이 필요합니다.

   5

   Network Operator CR이 필요합니다.

   6

   Storage Operator CR은 선택적 구성 요소이며 클러스터에서 비활성화할 수 있습니다.

   GCP의 OpenShift Container Platform 4.12에 대한 credrequests 디렉터리 콘텐츠 예

   0000_26_cloud-controller-manager-operator_16_credentialsrequest-gcp.yaml 1
   0000_30_machine-api-operator_00_credentials-request.yaml 2
   0000_50_cloud-credential-operator_05-gcp-ro-credentialsrequest.yaml 3
   0000_50_cluster-image-registry-operator_01-registry-credentials-request-gcs.yaml 4
   0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 5
   0000_50_cluster-network-operator_02-cncc-credentials.yaml 6
   0000_50_cluster-storage-operator_03_credentials_request_gcp.yaml 7

   1

   Cloud Controller Manager Operator CR이 필요합니다.

   2

   Machine API Operator CR이 필요합니다.

   3

   Cloud Credential Operator CR이 필요합니다.

   4

   이미지 레지스트리 Operator CR이 필요합니다.

   5

   Ingress Operator CR이 필요합니다.

   6

   Network Operator CR이 필요합니다.

   7

   Storage Operator CR은 선택적 구성 요소이며 클러스터에서 비활성화할 수 있습니다.

프로세스

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. 새 릴리스에 대한 CredentialsRequest 사용자 지정 리소스를 추출하고 검사합니다.

   클라우드 공급자의 설치 콘텐츠의 "Manually creating IAM" 섹션은 클라우드에 필요한 인증 정보를 얻고 사용하는 방법을 설명합니다.

2. 클러스터에서 수동으로 유지 관리되는 인증 정보를 업데이트합니다.

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

3. 클러스터에서 클러스터 기능을 사용하여 하나 이상의 선택적 구성 요소를 비활성화하는 경우 비활성화된 구성 요소에 대한 CredentialsRequest 사용자 정의 리소스를 삭제합니다.

   AWS의 OpenShift Container Platform 4.12에 대한 credrequests 디렉터리 콘텐츠 예

   0000_30_machine-api-operator_00_credentials-request.yaml 1
   0000_50_cloud-credential-operator_05-iam-ro-credentialsrequest.yaml 2
   0000_50_cluster-image-registry-operator_01-registry-credentials-request.yaml 3
   0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 4
   0000_50_cluster-network-operator_02-cncc-credentials.yaml 5
   0000_50_cluster-storage-operator_03_credentials_request_aws.yaml 6

   1

   Machine API Operator CR이 필요합니다.

   2

   Cloud Credential Operator CR이 필요합니다.

   3

   이미지 레지스트리 Operator CR이 필요합니다.

   4

   Ingress Operator CR이 필요합니다.

   5

   Network Operator CR이 필요합니다.

   6

   Storage Operator CR은 선택적 구성 요소이며 클러스터에서 비활성화할 수 있습니다.

   GCP의 OpenShift Container Platform 4.12에 대한 credrequests 디렉터리 콘텐츠 예

   0000_26_cloud-controller-manager-operator_16_credentialsrequest-gcp.yaml 1
   0000_30_machine-api-operator_00_credentials-request.yaml 2
   0000_50_cloud-credential-operator_05-gcp-ro-credentialsrequest.yaml 3
   0000_50_cluster-image-registry-operator_01-registry-credentials-request-gcs.yaml 4
   0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 5
   0000_50_cluster-network-operator_02-cncc-credentials.yaml 6
   0000_50_cluster-storage-operator_03_credentials_request_gcp.yaml 7

   1

   Cloud Controller Manager Operator CR이 필요합니다.

   2

   Machine API Operator CR이 필요합니다.

   3

   Cloud Credential Operator CR이 필요합니다.

   4

   이미지 레지스트리 Operator CR이 필요합니다.

   5

   Ingress Operator CR이 필요합니다.

   6

   Network Operator CR이 필요합니다.

   7

   Storage Operator CR은 선택적 구성 요소이며 클러스터에서 비활성화할 수 있습니다.

프로세스

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

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

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

프로세스

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

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

   중요

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

   참고

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

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

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

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

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

   참고

   클러스터를 버전 4.y에서 4.(y+1)로 업그레이드하는 경우 새 기능을 사용하는 워크로드를 배포하기 전에 노드가 업데이트되었는지 확인하는 것이 좋습니다. 아직 업데이트되지 않은 작업자 노드가 있는 풀은 클러스터 설정 페이지에 표시됩니다.

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

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

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

프로세스

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. 일시 중지하려는 사용 가능한 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.9.23
   Upstream is unset, so the cluster will use an appropriate default.
   Channel: stable-4.9 (available channels: candidate-4.10, candidate-4.9, fast-4.10, fast-4.9, stable-4.10, stable-4.9, eus-4.10)
   Recommended updates:
   VERSION IMAGE
   4.9.24  quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032
   4.9.25  quay.io/openshift-release-dev/ocp-release@sha256:2eafde815e543b92f70839972f585cc52aa7c37aa72d5f3c8bc886b0fd45707a
   4.9.26  quay.io/openshift-release-dev/ocp-release@sha256:3ccd09dd08c303f27a543351f787d09b83979cd31cf0b4c6ff56cd68814ef6c8
   4.9.27  quay.io/openshift-release-dev/ocp-release@sha256:1c7db78eec0cf05df2cead44f69c0e4b2c3234d5635c88a41e1b922c3bedae16
   4.9.28  quay.io/openshift-release-dev/ocp-release@sha256:4084d94969b186e20189649b5affba7da59f7d1943e4e5bc7ef78b981eafb7a8
   4.9.29  quay.io/openshift-release-dev/ocp-release@sha256:b04ca01d116f0134a102a57f86c67e5b1a3b5da1c4a580af91d521b8fa0aa6ec
   4.9.31  quay.io/openshift-release-dev/ocp-release@sha256:2a28b8ebb53d67dd80594421c39e36d9896b1e65cb54af81fbb86ea9ac3bf2d7
   4.9.32  quay.io/openshift-release-dev/ocp-release@sha256:ecdb6d0df547b857eaf0edb5574ddd64ca6d9aff1fa61fd1ac6fb641203bedfa

   참고

   • 사용 가능한 업데이트가 없는 경우 지원되지만 권장되지 않는 업데이트는 계속 사용할 수 있습니다. 자세한 내용은 조건부 업데이트 경로를 따라 업데이트를 참조하십시오.
   • EUS-to-EUS 채널 업데이트를 수행하는 방법에 대한 자세한 내용 및 자세한 내용은 추가 리소스 섹션에 나열된 EUS-to-EUS 업그레이드 준비 페이지를 참조하십시오.

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

   $ oc adm upgrade channel <channel>

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

   $ oc adm upgrade channel stable-4.12

   중요

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

   참고

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

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

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

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

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

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

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

     1 1

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

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

   $ oc adm upgrade

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

   $ oc get clusterversion

   출력 예

   Cluster version is <version>
   
   Upstream is unset, so the cluster will use an appropriate default.
   Channel: stable-4.10 (available channels: candidate-4.10, candidate-4.11, eus-4.10, fast-4.10, fast-4.11, stable-4.10)
   
   No updates available. You may force an upgrade 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.25.0
   ip-10-0-170-223.ec2.internal   Ready    master   82m   v1.25.0
   ip-10-0-179-95.ec2.internal    Ready    worker   70m   v1.25.0
   ip-10-0-182-134.ec2.internal   Ready    worker   70m   v1.25.0
   ip-10-0-211-16.ec2.internal    Ready    master   82m   v1.25.0
   ip-10-0-250-100.ec2.internal   Ready    worker   69m   v1.25.0

절차

1. 위험이 적용될 수 있으므로 업데이트에 대한 설명을 보려면 다음 명령을 실행합니다.

   $ oc adm upgrade --include-not-recommended

2. 클러스터 관리자가 잠재적인 알려진 위험을 평가하고 현재 클러스터에 적합한지 결정하는 경우 관리자는 다음 명령을 실행하여 안전 가드를 포기하고 업데이트를 진행할 수 있습니다.

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

   < . > <version>은 지원되지만 이전 명령의 출력에서 가져온 업데이트 버전은 권장되지 않습니다.

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

   참고

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

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

   중요

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

3. 업데이트 프로세스의 일부로 업데이트하지 않으려는 MCP를 일시 중지합니다.

   참고

   MCP를 일시 중지하면 kube-apiserver-to-kubelet-signer 자동 CA 인증서 교체도 일시 중지됩니다. 새 CA 인증서는 설치 날짜로부터 292일로 생성되며 이전 인증서는 설치 날짜로부터 365일에 제거됩니다. 다음 자동 CA 인증서 교체까지 남은 시간을 알아보려면 Red Hat OpenShift 4의 CA 인증서 자동 갱신 이해을 참조하십시오.

   CA 인증서 교체가 발생하면 풀이 일시 중지되지 않았는지 확인합니다. MCP가 일시 중지되면 MCO가 새로 순환된 인증서를 해당 노드로 내보낼 수 없습니다. 이로 인해 클러스터의 성능이 저하되고 oc debug, oc logs,oc exec, oc attach 를 포함한 여러 oc 명령에서 오류가 발생합니다. 인증서가 교체될 때 MCP가 일시 중지되면 OpenShift Container Platform 웹 콘솔의 경고 UI에 경고가 표시됩니다.

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를 패치합니다.

   $ 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. 시스템 상태를 검사합니다.

   # 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.12.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. 웹 콘솔에서 Administration → Cluster Settings을 클릭하고 Details 탭의 내용을 확인합니다.

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

   중요

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

   참고

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

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

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

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

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

   참고

   클러스터를 버전 4.y에서 4.(y+1)로 업그레이드하는 경우 새 기능을 사용하는 워크로드를 배포하기 전에 노드가 업데이트되었는지 확인하는 것이 좋습니다. 아직 업데이트되지 않은 작업자 노드가 있는 풀은 클러스터 설정 페이지에 표시됩니다.

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.12에 필요한 리포지토리를 활성화합니다.

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

      # subscription-manager repos --disable=rhocp-4.11-for-rhel-8-x86_64-rpms \
                                   --disable=ansible-2.9-for-rhel-8-x86_64-rpms \
                                   --enable=rhocp-4.12-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 Playbook을 실행하는 시스템에서 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.11-for-rhel-8-x86_64-rpms \
                                   --enable=rhocp-4.12-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.25.0
   mycluster-control-plane-1   Ready                         master   145m   v1.25.0
   mycluster-control-plane-2   Ready                         master   145m   v1.25.0
   mycluster-rhel8-0           Ready                         worker   98m    v1.25.0
   mycluster-rhel8-1           Ready                         worker   98m    v1.25.0
   mycluster-rhel8-2           Ready                         worker   98m    v1.25.0
   mycluster-rhel8-3           Ready                         worker   98m    v1.25.0

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

   # yum update

   참고

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

1. 릴리스 이미지를 검색하고 내보내는 데 사용되는 모든 장치에 OpenShift CLI(oc)를 설치합니다.
2. 레지스트리 풀 시크릿을 다운로드하여 클러스터에 추가합니다.

3. oc-mirror OpenShift CLI (oc) 플러그인 을 사용하는 경우 :

   1. 릴리스 이미지를 검색하고 내보내는 데 사용되는 모든 장치에 oc-mirror 플러그인을 설치합니다.
   2. 미러링할 릴리스 이미지를 결정할 때 사용할 플러그인의 이미지 세트 구성 파일을 생성합니다. 나중에 이 구성 파일을 편집하여 플러그인이 미러링하는 릴리스 이미지를 변경할 수 있습니다.
   3. 대상 릴리스 이미지를 미러 레지스트리 또는 이동식 미디어에 직접 미러링한 다음 미러 레지스트리에 미러링합니다.
   4. oc-mirror 플러그인에서 생성한 리소스를 사용하도록 클러스터를 구성합니다.
   5. 필요에 따라 이 단계를 반복하여 미러 레지스트리를 업데이트합니다.

4. oc adm release mirror 명령을 사용하는 경우 :

   1. 사용자 환경과 미러링할 릴리스 이미지에 해당하는 환경 변수를 설정합니다.
   2. 대상 릴리스 이미지를 미러 레지스트리 또는 이동식 미디어에 직접 미러링한 다음 미러 레지스트리에 미러링합니다.
   3. 필요에 따라 이 단계를 반복하여 미러 레지스트리를 업데이트합니다.

1. 보안 레지스트리에 대한 액세스를 구성합니다.
2. 미러 레지스트리에 액세스하려면 글로벌 클러스터 풀 시크릿을 업데이트합니다.
3. OSUS Operator를 설치합니다.
4. OpenShift Update Service의 그래프 데이터 컨테이너 이미지를 생성합니다.
5. OSUS 애플리케이션을 설치하고 로컬 OpenShift Update Service를 사용하도록 클러스터를 구성합니다.
6. 연결된 클러스터와 마찬가지로 문서에서 지원되는 업데이트 프로세스를 수행합니다.

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