클러스터 업데이트

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. cordon 모든 노드를 드레인 및 드레인
2. 운영 체제 업데이트 (OS)
3. 노드 재부팅
4. 모든 노드를 분리하고 노드의 워크로드를 예약

절차

1. 웹 콘솔의 관리자 화면을 사용하여 모든 OLM(Operator Lifecycle Manager) Operator를 업데이트된 버전과 호환되는 버전으로 업데이트합니다. "설치된 Operator 업데이트"에서 이 작업을 수행하는 방법에 대한 자세한 내용은 "ECDHE 리소스"를 참조하십시오.

2. 모든 머신 구성 풀의 상태가 Up to date 로 표시되고 머신 구성 풀이 UPDATING 상태를 표시하지 않는지 확인합니다.

   모든 머신 구성 풀의 상태를 보려면 Compute → MachineConfigPools 를 클릭하고 Update status 열의 내용을 확인합니다.

   참고

   머신 구성 풀의 상태가 Updating 인 경우 이 상태가 Up to date 로 변경될 때까지 기다립니다. 이 프로세스에는 몇 분이 걸릴 수 있습니다.

3. 채널을 eus-<4.y+2>로 설정합니다.

   채널을 설정하려면 Administration → Cluster Settings → Channel 을 클릭합니다. 현재 하이퍼링크된 채널을 클릭하여 채널을 편집할 수 있습니다.

4. 마스터 풀을 제외한 모든 작업자 머신 풀을 일시 중지합니다. Compute 페이지의 MachineConfigPools 탭에서 이 작업을 수행할 수 있습니다. 일시 정지하고 업데이트 일시 정지를 클릭합니다.
5. 버전 <4.y+1>으로 업데이트하고 저장 단계를 완료합니다. 웹 콘솔을 사용하여 "클러스터 업데이트"에서 이러한 작업을 수행하는 방법에 대한 자세한 내용은 "해결 리소스"를 참조하십시오.
6. 마지막 완료된 버전의 클러스터를 확인하여 <4.y+1> 업데이트가 완료되었는지 확인합니다. 이 정보는 세부 정보 탭의 클러스터 설정 페이지에서 확인할 수 있습니다.
7. 필요한 경우 웹 콘솔의 관리자 화면을 사용하여 OLM Operator를 업데이트합니다. 이러한 작업을 수행하는 방법에 대한 자세한 내용은 "설치된 Operator 업데이트"를 참조하십시오. "ECDHE 리소스"를 참조하십시오.
8. 버전 <4.y+2>로 업데이트하고 저장 단계를 완료합니다. 웹 콘솔을 사용하여 "클러스터 업데이트"에서 이러한 작업을 수행하는 방법에 대한 자세한 내용은 "해결 리소스"를 참조하십시오.
9. 클러스터의 마지막 완료된 버전을 확인하여 <4.y+2> 업데이트가 완료되었는지 확인합니다. 이 정보는 세부 정보 탭의 클러스터 설정 페이지에서 확인할 수 있습니다.

10. 이전에 일시 중지한 모든 머신 구성 풀의 일시 정지를 해제합니다. Compute 페이지의 MachineConfigPools 탭에서 이 작업을 수행할 수 있습니다. 일시 정지 해제를 원하는 머신 구성 풀 옆에 있는 수직을 선택하고 업데이트 일시 정지 해제 를 클릭합니다.

    중요

    풀이 일시 중지되지 않는 경우 클러스터는 향후 마이너 버전으로 업그레이드할 수 없으며 인증서 교체와 같은 유지 관리 작업이 금지됩니다. 이로 인해 클러스터가 향후 저하될 위험이 있습니다.

11. 이전에 일시 중지된 풀이 업데이트되고 클러스터가 <4.y+2> 버전으로 업데이트를 완료했는지 확인합니다.

    Update status 의 값이 Up to date 인지 확인하여 Compute 페이지의 MachineConfigPools 탭에서 풀이 업데이트되었는지 확인할 수 있습니다.

    마지막으로 완료된 클러스터 버전을 확인하여 클러스터가 업데이트를 완료 했는지 확인할 수 있습니다. 이 정보는 세부 정보 탭의 클러스터 설정 페이지에서 확인할 수 있습니다.

절차

1. 웹 콘솔의 관리자 화면을 사용하여 모든 OLM(Operator Lifecycle Manager) Operator를 업데이트된 버전과 호환되는 버전으로 업데이트합니다. "설치된 Operator 업데이트"에서 이 작업을 수행하는 방법에 대한 자세한 내용은 "ECDHE 리소스"를 참조하십시오.

2. 모든 머신 구성 풀에 UPDATED 상태를 표시하고 머신 구성 풀이 UPDATING 상태를 표시하지 않는지 확인합니다. 모든 머신 구성 풀의 상태를 보려면 다음 명령을 실행합니다.

   $ oc get mcp

   출력 예

   NAME     CONFIG                                         	UPDATED   UPDATING
   master   rendered-master-ecbb9582781c1091e1c9f19d50cf836c       True  	  False
   worker   rendered-worker-00a3f0c68ae94e747193156b491553d5       True  	  False

3. 현재 버전은 <4.y>이며 원하는 버전은 <4.y+2>입니다. 다음 명령을 실행하여 eus-<4.y+2 > 채널로 변경합니다.

   $ oc adm upgrade channel eus-<4.y+2>

   참고

   eus-<4.y+2 >가 사용 가능한 채널 중 하나가 아님을 나타내는 오류 메시지가 표시되면 Red Hat이 여전히 EUS 버전 업데이트를 롤아웃하고 있음을 나타냅니다. 이 롤아웃 프로세스는 일반적으로 GA 날짜로부터 45-90일이 소요됩니다.

4. 다음 명령을 실행하여 마스터 풀을 제외한 모든 작업자 머신 풀을 일시 중지합니다.

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

   참고

   마스터 풀을 일시 중지할 수 없습니다.

5. 다음 명령을 실행하여 최신 버전으로 업데이트합니다.

   $ oc adm upgrade --to-latest

   출력 예

   Updating to latest version <4.y+1.z>

6. 클러스터 버전을 검토하여 다음 명령을 실행하여 업데이트가 완료되었는지 확인합니다.

   $ oc adm upgrade

   출력 예

   Cluster version is <4.y+1.z>
   ...

7. 다음 명령을 실행하여 버전 <4.y+2>로 업데이트합니다.

   $ oc adm upgrade --to-latest

8. 클러스터 버전을 검색하여 다음 명령을 실행하여 <4.y+2> 업데이트가 완료되었는지 확인합니다.

   $ oc adm upgrade

   출력 예

   Cluster version is <4.y+1.z>
   ...

9. 작업자 노드를 <4.y+2>로 업데이트하려면 다음 명령을 실행하여 이전에 일시 중지된 모든 머신 구성 풀의 일시 중지를 해제합니다.

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

   중요

   풀이 일시 중지되지 않은 경우 클러스터는 향후 마이너 버전으로 업데이트할 수 없으며 인증서 교체와 같은 유지 관리 작업이 차단됩니다. 이로 인해 클러스터가 향후 저하될 위험이 있습니다.

10. 다음 명령을 실행하여 이전에 일시 중지된 풀이 업데이트되고 버전 <4.y+2>로 업데이트가 완료되었는지 확인합니다.

    $ oc get mcp

    출력 예

    NAME 	   CONFIG                                            UPDATED     UPDATING
    master   rendered-master-52da4d2760807cb2b96a3402179a9a4c    True  	 False
    worker   rendered-worker-4756f60eccae96fb9dcb4c392c69d497    True 	 False

1. OLM을 통해 이전에 설치된 모든 Operator가 최신 채널의 최신 버전으로 업데이트되었는지 확인합니다. Operator를 업데이트하면 클러스터 업데이트 중에 기본 OperatorHub 카탈로그가 현재 마이너 버전에서 다음 버전으로 전환될 때 유효한 업데이트 경로가 제공됩니다. Operator 업데이트 방법에 대한 자세한 내용은 "ECDHE 리소스"에서 "Operator 업데이트 준비"를 참조하십시오.
2. 현재 및 의도된 Operator 버전 간의 클러스터 버전 호환성을 확인합니다. Red Hat OpenShift Container Platform Operator Update Information Checker 를 사용하여 OLM Operator가 호환되는 버전을 확인할 수 있습니다.

워크플로 예

1. 작업자 시스템 풀을 일시 중지합니다.
2. 업그레이드 OpenShift <4.y> → OpenShift <4.y+1>.
3. 업그레이드 ODF <4.y> → ODF <4.y+1>.
4. Upgrade OpenShift <4.y+1> → OpenShift <4.y+2>.
5. ODF <4.y+2>로 업그레이드
6. 작업자 시스템 풀의 일시 정지를 해제합니다.

절차

1. cluster-admin 역할의 사용자로 OpenShift Container Platform 웹 콘솔에 로그인합니다.
2. Administration → Cluster Settings으로 이동합니다.
3. 클러스터 설정 페이지에서 구성 탭을 선택합니다.
4. Configuration 리소스 에서 CloudCredential 를 선택합니다.
5. CloudCredential 세부 정보 페이지에서 YAML 탭을 선택합니다.

6. YAML 블록에서 spec.credentialsMode 의 값을 확인합니다. 다음 값이 모든 플랫폼에서 지원되지는 않지만 모두 지원되는 것은 아닙니다.

   • '': CCO가 기본 모드에서 작동합니다. 이 구성에서 CCO는 설치 중에 제공된 인증 정보에 따라 Mint 또는 passthrough 모드에서 작동합니다.
   • Mint: CCO가 Mint 모드에서 작동합니다.
   • passthrough: CCO가 passthrough 모드에서 작동합니다.
   • Manual: CCO가 수동 모드에서 작동합니다.
   중요

   '', Mint 또는 Manual 의 spec.credentialsMode 가 있는 AWS 또는 GCP 클러스터의 특정 구성을 확인하려면 추가 조사를 수행해야 합니다.

   AWS 및 GCP 클러스터는 루트 시크릿이 삭제된 상태에서 Mint 모드 사용을 지원합니다. 클러스터가 특별히 Mint 모드를 사용하도록 구성된 경우 또는 기본적으로 Mint 모드를 사용하는 경우 업데이트하기 전에 root 시크릿이 클러스터에 있는지 확인해야 합니다.

   수동 모드를 사용하는 AWS 또는 GCP 클러스터는 AWS STS(Security Token Service) 또는 GCP 워크로드 ID를 사용하여 클러스터 외부에서 클라우드 인증 정보를 생성하고 관리하도록 구성할 수 있습니다. cluster Authentication 오브젝트를 검사하여 클러스터에서 이 전략을 사용하는지 확인할 수 있습니다.

7. AWS 또는 GCP 클러스터만 Mint 모드를 사용하는: 클러스터가 루트 시크릿없이 작동하는지 확인하려면 워크로드 → 시크릿으로 이동하여 클라우드 공급자의 루트 시크릿을 찾습니다.

   참고

   프로젝트 드롭다운이 All Projects 로 설정되어 있는지 확인합니다.

   플랫폼	시크릿 이름
   AWS	aws-creds
   GCP	gcp-credentials

   • 이러한 값 중 하나가 표시되면 클러스터에서 root 시크릿이 있는 mint 또는 passthrough 모드를 사용하는 것입니다.
   • 이러한 값이 표시되지 않으면 클러스터는 루트 시크릿이 제거된 Mint 모드에서 CCO를 사용하는 것입니다.

8. AWS 또는 GCP 클러스터만 사용하는: 클러스터 외부에서 클라우드 인증 정보를 생성하고 관리하도록 클러스터가 구성되었는지 확인하려면 클러스터 인증 오브젝트 YAML 값을 확인해야 합니다.

   1. Administration → Cluster Settings으로 이동합니다.
   2. 클러스터 설정 페이지에서 구성 탭을 선택합니다.
   3. Configuration 리소스 에서 인증을 선택합니다.
   4. 인증 세부 정보 페이지에서 YAML 탭을 선택합니다.

   5. YAML 블록에서 .spec.serviceAccountIssuer 매개변수 값을 확인합니다.

      • 클라우드 공급자와 연결된 URL이 포함된 값은 CCO가 AWS STS 또는 GCP 워크로드 ID와 함께 수동 모드를 사용하여 클러스터 외부에서 클라우드 인증 정보를 생성하고 관리하는 것을 나타냅니다. 이러한 클러스터는 ccoctl 유틸리티를 사용하여 구성됩니다.
      • 빈 값('')은 클러스터가 수동 모드에서 CCO를 사용하고 있지만 ccoctl 유틸리티를 사용하여 구성되지 않았음을 나타냅니다.

절차

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

2. CCO가 사용하도록 구성된 모드를 결정하려면 다음 명령을 입력합니다.

   $ oc get cloudcredentials cluster \
     -o=jsonpath={.spec.credentialsMode}

   다음 출력 값을 사용할 수 있지만 모든 플랫폼에서 모두 지원되는 것은 아닙니다.

   • '': CCO가 기본 모드에서 작동합니다. 이 구성에서 CCO는 설치 중에 제공된 인증 정보에 따라 Mint 또는 passthrough 모드에서 작동합니다.
   • Mint: CCO가 Mint 모드에서 작동합니다.
   • passthrough: CCO가 passthrough 모드에서 작동합니다.
   • Manual: CCO가 수동 모드에서 작동합니다.
   중요

   '', Mint 또는 Manual 의 spec.credentialsMode 가 있는 AWS 또는 GCP 클러스터의 특정 구성을 확인하려면 추가 조사를 수행해야 합니다.

   AWS 및 GCP 클러스터는 루트 시크릿이 삭제된 상태에서 Mint 모드 사용을 지원합니다. 클러스터가 특별히 Mint 모드를 사용하도록 구성된 경우 또는 기본적으로 Mint 모드를 사용하는 경우 업데이트하기 전에 root 시크릿이 클러스터에 있는지 확인해야 합니다.

   수동 모드를 사용하는 AWS 또는 GCP 클러스터는 AWS STS(Security Token Service) 또는 GCP 워크로드 ID를 사용하여 클러스터 외부에서 클라우드 인증 정보를 생성하고 관리하도록 구성할 수 있습니다. cluster Authentication 오브젝트를 검사하여 클러스터에서 이 전략을 사용하는지 확인할 수 있습니다.

3. AWS 또는 GCP 클러스터만 Mint 모드를 사용하는: 클러스터가 루트 시크릿없이 작동하는지 확인하려면 다음 명령을 실행합니다.

   $ oc get secret <secret_name> \
     -n=kube-system

   여기서 & lt;secret_name >은 AWS의 aws-creds 이거나 GCP의 gcp-credentials 입니다.

   루트 시크릿이 있으면 이 명령의 출력에서 보안에 대한 정보를 반환합니다. root 보안이 클러스터에 존재하지 않음을 나타내는 오류가 있습니다.

4. 수동 모드를 사용하는 AWS 또는 GCP 클러스터: 클러스터 외부에서 클라우드 인증 정보를 생성하고 관리하도록 클러스터가 구성되었는지 확인하려면 다음 명령을 실행합니다.

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

   이 명령은 클러스터 인증 오브젝트에서 .spec.serviceAccountIssuer 매개변수 값을 표시합니다.

   • 클라우드 공급자와 연결된 URL의 출력은 CCO가 AWS STS 또는 GCP 워크로드 ID와 함께 수동 모드를 사용하여 클러스터 외부에서 클라우드 인증 정보를 생성하고 관리하는 것을 나타냅니다. 이러한 클러스터는 ccoctl 유틸리티를 사용하여 구성됩니다.
   • 빈 출력은 클러스터가 수동 모드에서 CCO를 사용하고 있지만 ccoctl 유틸리티를 사용하여 구성되지 않았음을 나타냅니다.

프로세스

1. 후크를 설계한 후 Ansible 작업을 정의하는 YAML 파일을 만듭니다. 이 파일은 다음 예와 같이 Playbook이 아닌 일련의 작업으로 구성되어 있어야 합니다.

   ---
   # Trivial example forcing an operator to acknowledge the start of an upgrade
   # file=/home/user/openshift-ansible/hooks/pre_compute.yml
   
   - name: note the start of a compute machine update
     debug:
         msg: "Compute machine upgrade of {{ inventory_hostname }} is about to start"
   
   - name: require the user agree to start an upgrade
     pause:
         prompt: "Press Enter to start the compute machine update"

2. hosts Ansible 인벤토리 파일을 수정하여 후크 파일을 지정합니다. 후크 파일은 다음과 같이 [all : vars] 섹션에서 매개 변수 값으로 지정됩니다.

   인벤토리 파일에서 후크 정의의 예

   [all:vars]
   openshift_node_pre_upgrade_hook=/home/user/openshift-ansible/hooks/pre_node.yml
   openshift_node_post_upgrade_hook=/home/user/openshift-ansible/hooks/post_node.yml

   후크 경로의 모호성을 피하려면 정의에서 상대 경로 대신 절대 경로를 사용합니다.

프로세스

1. Red Hat OpenShift Container Platform Upgrade Graph 시각화 프로그램 및 업데이트 플래너 를 사용하여 한 버전에서 다른 버전으로의 업데이트를 계획합니다. OpenShift Upgrade Graph는 채널 그래프와 현재 클러스터 버전과 예약된 클러스터 버전 간의 업데이트 경로가 있는지 확인하는 방법을 제공합니다.

2. 필요한 환경 변수를 설정합니다.

   1. 릴리스 버전을 내보냅니다.

      $ export OCP_RELEASE=<release_version>

      & lt;release_version >에 대해 업데이트할 OpenShift Container Platform 버전에 해당하는 태그를 지정합니다 (예: 4.5.4 ) .

   2. 로컬 레지스트리 이름 및 호스트 포트를 내보냅니다.

      $ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'

      <local_registry_host_name>의 경우 미러 저장소의 레지스트리 도메인 이름을 지정하고 <local_registry_host_port>의 경우 콘텐츠를 제공하는데 사용되는 포트를 지정합니다.

   3. 로컬 저장소 이름을 내보냅니다.

      $ LOCAL_REPOSITORY='<local_repository_name>'

      <local_repository_name>의 경우 레지스트리에 작성할 저장소 이름 (예: ocp4/openshift4)을 지정합니다.

   4. OpenShift Update Service를 사용하는 경우 릴리스 이미지를 포함하도록 추가 로컬 리포지토리 이름을 내보냅니다.

      $ LOCAL_RELEASE_IMAGES_REPOSITORY='<local_release_images_repository_name>'

      <local_release_images_repository_name>의 경우 레지스트리에 작성할 저장소 이름 (예: ocp4/openshift4-release-images)을 지정합니다.

   5. 미러링할 저장소 이름을 내보냅니다.

      $ PRODUCT_REPO='openshift-release-dev'

      프로덕션 환경의 릴리스의 경우 openshift-release-dev를 지정해야 합니다.

   6. 레지스트리 풀 시크릿의 경로를 내보냅니다.

      $ LOCAL_SECRET_JSON='<path_to_pull_secret>'

      생성한 미러 레지스트리에 대한 풀 시크릿의 절대 경로 및 파일 이름을 <path_to_pull_secret>에 지정합니다.

      참고

      클러스터에서 ImageContentSourcePolicy 오브젝트를 사용하여 저장소 미러링을 구성하는 경우 미러링된 레지스트리에 대한 글로벌 풀 시크릿만 사용할 수 있습니다. 프로젝트에 풀 시크릿을 추가할 수 없습니다.

   7. 릴리스 미러를 내보냅니다.

      $ RELEASE_NAME="ocp-release"

      프로덕션 환경의 릴리스의 경우 ocp-release를 지정해야 합니다.

   8. 서버의 아키텍처 유형 (예: x86_64)을 내보냅니다.

      $ ARCHITECTURE=<server_architecture>

   9. 미러링된 이미지를 호스트할 디렉터리의 경로를 내보냅니다.

      $ REMOVABLE_MEDIA_PATH=<path> 1

      1

      초기 슬래시 (/) 문자를 포함하여 전체 경로를 지정합니다.

3. 미러링할 이미지 및 설정 매니페스트를 확인합니다.

   $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run

4. 버전 이미지를 미러 레지스트리에 미러링합니다.

   • 미러 호스트가 인터넷에 액세스할 수 없는 경우 다음 작업을 수행합니다.

     1. 이동식 미디어를 인터넷에 연결된 시스템에 연결합니다.

     2. 이미지 및 설정 매니페스트를 이동식 미디어의 디렉토리에 미러링합니다.

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}

     3. 미디어를 연결이 끊긴 환경으로 가져와서 이미지를 로컬 컨테이너 레지스트리에 업로드합니다.

        $ oc image mirror  -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} 1

        1

        REMOVABLE_MEDIA_PATH의 경우 이미지를 미러링 할 때 지정한 것과 동일한 경로를 사용해야 합니다.

     4. oc CLI(명령줄 인터페이스)를 사용하여 업그레이드 중인 클러스터에 로그인합니다.

     5. 미러링된 릴리스 이미지 서명 config map을 연결된 클러스터에 적용합니다.

        $ oc apply -f ${REMOVABLE_MEDIA_PATH}/mirror/config/<image_signature_file> 1

        1

        < image_signature_file >은 파일의 경로와 이름을 지정합니다(예: signature-sha256-81154f5c03294534.yaml ).

     6. OpenShift Update Service를 사용하는 경우 릴리스 이미지를 별도의 저장소에 미러링합니다.

        $ oc image mirror -a ${LOCAL_SECRET_JSON} ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} ${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}

   • 로컬 컨테이너 레지스트리와 클러스터가 미러 호스트에 연결된 경우 다음 작업을 수행합니다.

     1. 릴리스 이미지를 로컬 레지스트리로 직접 푸시하고 다음 명령을 사용하여 구성 맵을 클러스터에 적용합니다.

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
          --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} --apply-release-image-signature

        참고

        --apply-release-image-signature 옵션이 포함된 경우 이미지 서명 확인을 위해 config map을 작성하지 않습니다.

     2. OpenShift Update Service를 사용하는 경우 릴리스 이미지를 별도의 저장소에 미러링합니다.

        $ oc image mirror -a ${LOCAL_SECRET_JSON} ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} ${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}

프로세스

1. 선택 사항: 기존 풀 시크릿에 새 풀 시크릿을 추가하려면 다음 단계를 완료합니다.

   1. 다음 명령을 입력하여 풀 시크릿을 다운로드합니다.

      $ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' ><pull_secret_location> 1

      1

      풀 시크릿 파일에 경로를 제공합니다.

   2. 다음 명령을 입력하여 새 풀 시크릿을 추가합니다.

      $ oc registry login --registry="<registry>" \ 1
      --auth-basic="<username>:<password>" \ 2
      --to=<pull_secret_location> 3

      1

      새 레지스트리를 제공합니다. 동일한 레지스트리에 여러 리포지토리를 포함할 수 있습니다 (예: --registry="<registry/my-namespace/my-repository&gt;).

      2

      새 레지스트리의 인증 정보를 제공합니다.

      3

      풀 시크릿 파일에 경로를 제공합니다.

      또는 가져오기 시크릿 파일에 대한 수동 업데이트를 수행할 수 있습니다.

2. 다음 명령을 입력하여 클러스터의 글로벌 풀 시크릿을 업데이트합니다.

   $ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location> 1

   1

   새 풀 시크릿 파일의 경로를 제공합니다.

   이 업데이트는 모든 노드로 롤아웃되며 클러스터 크기에 따라 작업에 약간의 시간이 걸릴 수 있습니다.

   참고

   OpenShift Container Platform 4.7.4부터 글로벌 풀 시크릿을 변경해도 더 이상 노드 드레이닝 또는 재부팅이 트리거되지 않습니다.

프로세스

1. 다음을 포함하는 Dockerfile(예: ./Dockerfile )을 생성합니다.

   FROM registry.access.redhat.com/ubi8/ubi:8.1
   
   RUN curl -L -o cincinnati-graph-data.tar.gz https://api.openshift.com/api/upgrades_info/graph-data
   
   RUN mkdir -p /var/lib/cincinnati-graph-data && tar xvzf cincinnati-graph-data.tar.gz -C /var/lib/cincinnati-graph-data/ --no-overwrite-dir --no-same-owner
   
   CMD ["/bin/bash", "-c" ,"exec cp -rp /var/lib/cincinnati-graph-data/* /var/lib/cincinnati/graph-data"]

2. 위 단계에서 생성된 Docker 파일을 사용하여 graph-data 컨테이너 이미지(예: registry.example.com/openshift/graph-data:latest )를 빌드합니다.

   $ podman build -f ./Dockerfile -t registry.example.com/openshift/graph-data:latest

3. 이전 단계에서 생성된 graph-data 컨테이너 이미지를 OpenShift Update Service에 액세스할 수 있는 리포지토리(예: registry.example.com/openshift/graph-data:latest ):

   $ podman push registry.example.com/openshift/graph-data:latest

   참고

   연결이 끊긴 환경의 로컬 레지스트리로 그래프 데이터 이미지를 푸시하려면 OpenShift Update Service에서 액세스할 수 있는 리포지토리에 이전 단계에서 생성한 graph-data 컨테이너 이미지를 복사합니다. 사용 가능한 옵션에 oc image mirror --help 를 실행합니다.

프로세스

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 release info -o 'jsonpath={.digest}{"\n"}' quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_VERSION}-${ARCHITECTURE}

   {OCP_RELEASE_VERSION} 의 경우 4.10.16 과 같이 업데이트할 OpenShift Container Platform 버전을 지정합니다.

   {ARCHITECTURE} 의 경우 x86_64,aarch64,s390x, ppc64le 과 같은 클러스터의 아키텍처를 지정합니다.

   출력 예

   sha256:a8bfba3b6dddd1a2fbbead7dac65fe4fb8335089e4e7cae327f3bad334add31d

2. 클러스터를 업데이트할 때 사용할 sha256 다이제스트를 복사합니다.

프로세스

1. 미러링된 저장소를 설정합니다.

   • Red Hat Quay Repository Mirroring에 설명된대로 Red Hat Quay를 사용하여 미러링된 저장소를 설정합니다. Red Hat Quay를 사용하면 한 저장소에서 다른 저장소로 이미지를 복사하고 시간이 지남에 따라 해당 저장소를 반복해서 자동으로 동기화할 수 있습니다.

   • skopeo와 같은 툴을 사용하여 소스 디렉토리에서 미러링된 저장소로 이미지를 수동으로 복사합니다.

     예를 들어, Red Hat Enterprise Linux(RHEL) 7 또는 RHEL 8 시스템에 skopeo RPM 패키지를 설치한 후 다음 예와 같이 skopeo 명령을 사용합니다.

     $ skopeo copy \
     docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \
     docker://example.io/example/ubi-minimal

     이 예제에는 example.io라는 컨테이너 이미지 레지스트리가 있으며, registry.access.redhat.com에서 ubi8/ubi-minimal 이미지를 복사할 example이라는 이미지 저장소가 있습니다. 레지스트리를 생성한 후 OpenShift Container Platform 클러스터를 설정하여 소스 저장소의 요청을 미러링된 저장소로 리디렉션할 수 있습니다.

2. OpenShift Container Platform 클러스터에 로그인합니다.

3. ImageContentSourcePolicy 파일(예: registryrepomirror.yaml)을 생성하고 소스 및 미러를 특정 레지스트리 및 저장소 쌍과 이미지로 교체합니다.

   apiVersion: operator.openshift.io/v1alpha1
   kind: ImageContentSourcePolicy
   metadata:
     name: ubi8repo
   spec:
     repositoryDigestMirrors:
     - mirrors:
       - example.io/example/ubi-minimal 1
       - example.com/example/ubi-minimal 2
       source: registry.access.redhat.com/ubi8/ubi-minimal 3
     - mirrors:
       - mirror.example.com/redhat
       source: registry.redhat.io/openshift4 4
     - mirrors:
       - mirror.example.com
       source: registry.redhat.io 5
     - mirrors:
       - mirror.example.net/image
       source: registry.example.com/example/myimage 6
     - mirrors:
       - mirror.example.net
       source: registry.example.com/example 7
     - mirrors:
       - mirror.example.net/registry-example-com
       source: registry.example.com 8

   1

   이미지 레지스트리 및 저장소의 이름을 가리킵니다.

   2

   각 대상 저장소에 대해 여러 미러 저장소를 나타냅니다. 하나의 미러가 다운되면 대상 저장소에서 다른 미러를 사용할 수 있습니다.

   3

   미러링된 컨텐츠를 포함하는 레지스트리 및 저장소를 가리킵니다.

   4

   해당 네임스페이스의 이미지를 사용하도록 레지스트리 내에서 네임스페이스를 구성할 수 있습니다. 레지스트리 도메인을 소스로 사용하는 경우 ImageContentSourcePolicy 리소스가 레지스트리의 모든 리포지토리에 적용됩니다.

   5

   레지스트리 이름을 구성하면 소스 레지스트리의 모든 리포지토리에 ImageContentSourcePolicy 리소스가 미러 레지스트리에 적용됩니다.

   6

   mirror.example.net/image@sha256:…​ 이미지를 가져옵니다.

   7

   미러 mirror.example.net/ myimage @sha256:…​ 에서 소스 레지스트리 네임스페이스의 myimage 이미지를 가져옵니다.

   8

   미러 레지스트리 mirror.example.net/registry-com/example/sha256:…​에서 이미지 registry .example.net/registry-com/example/myimage@sha256:…​에서 이미지 registry.example.com/example/myimage:…​ 를 가져옵니다. ImageContentSourcePolicy 리소스는 소스 레지스트리의 모든 리포지토리에 적용되며 미러 레지스트리 mirror.example.net/registry-example-com 에 적용됩니다.

4. 새 ImageContentSourcePolicy 개체를 생성합니다.

   $ oc create -f registryrepomirror.yaml

   ImageContentSourcePolicy 개체가 생성된 후 새 설정이 각 노드에 배포된 클러스터는 소스 저장소에 대한 요청에 미러링된 저장소를 사용하기 시작합니다.

5. 미러링된 설정이 적용되었는지 확인하려면 노드 중 하나에서 다음을 수행하십시오.

   1. 노드를 나열합니다.

      $ oc get node

      출력 예

      NAME                           STATUS                     ROLES    AGE  VERSION
      ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.24.0
      ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.24.0
      ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.24.0
      ip-10-0-147-35.ec2.internal    Ready                      worker   7m   v1.24.0
      ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.24.0
      ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.24.0

      Imagecontentsourcepolicy 리소스에서 노드를 재시작하지 않습니다.

   2. 디버깅 프로세스를 시작하고 노드에 액세스합니다.

      $ oc debug node/ip-10-0-147-35.ec2.internal

      출력 예

      Starting pod/ip-10-0-147-35ec2internal-debug ...
      To use host binaries, run `chroot /host`

   3. 루트 디렉토리를 /host 로 변경합니다.

      sh-4.2# chroot /host

   4. /etc/containers/registries.conf 파일을 체크하여 변경 사항이 적용되었는지 확인합니다.

      sh-4.2# cat /etc/containers/registries.conf

      출력 예

      unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
      short-name-mode = ""
      
      [[registry]]
        prefix = ""
        location = "registry.access.redhat.com/ubi8/ubi-minimal"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "example.io/example/ubi-minimal"
      
        [[registry.mirror]]
          location = "example.com/example/ubi-minimal"
      
      [[registry]]
        prefix = ""
        location = "registry.example.com"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "mirror.example.net/registry-example-com"
      
      [[registry]]
        prefix = ""
        location = "registry.example.com/example"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "mirror.example.net"
      
      [[registry]]
        prefix = ""
        location = "registry.example.com/example/myimage"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "mirror.example.net/image"
      
      [[registry]]
        prefix = ""
        location = "registry.redhat.io"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "mirror.example.com"
      
      [[registry]]
        prefix = ""
        location = "registry.redhat.io/openshift4"
        mirror-by-digest-only = true
      
        [[registry.mirror]]
          location = "mirror.example.com/redhat"

   5. 소스의 이미지 다이제스트를 노드로 가져와 실제로 미러링에 의해 해결되는지 확인합니다. ImageContentSourcePolicy 개체는 이미지 태그가 아닌 이미지 다이제스트만 지원합니다.

      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6

프로세스

1. <local_registry>, <pull_spec>, 및 <pull_secret_file>에 대한 값을 지정하여 다음 명령을 실행합니다.

   $ oc adm catalog mirror <local_registry>/<pull_spec> <local_registry> -a <pull_secret_file> --icsp-scope=registry

   다음과 같습니다.

   <local_registry>

   연결이 끊긴 클러스터에 대해 구성한 로컬 레지스트리입니다 (예: local.registry:5000).

   <pull_spec>

   연결이 끊긴 레지스트리에 구성된 풀 사양입니다(예: redhat/redhat-operator-index:v4.10

   <pull_secret_file>

   은 .json 파일 형식의 registry.redhat.io 풀 시크릿입니다. Red Hat OpenShift Cluster Manager에서 풀 시크릿을 다운로드할 수 있습니다.

   oc adm catalog mirror 명령은 /redhat-operator-index-manifests 디렉터리를 생성하고 imageContentSourcePolicy.yaml,catalogSource.yaml 및 mapping.txt 파일을 생성합니다.

2. 새 ImageContentSourcePolicy 리소스를 클러스터에 적용합니다.

   $ oc apply -f imageContentSourcePolicy.yaml

프로세스

1. 클러스터의 컨트롤 플레인 노드를 나열합니다.

   $ oc get nodes -l node-role.kubernetes.io/master

   출력 예

   NAME                    STATUS   ROLES    AGE   VERSION
   control-plane-node-0    Ready    master   75m   v1.23.0
   control-plane-node-1    Ready    master   75m   v1.23.0
   control-plane-node-2    Ready    master   75m   v1.23.0

   컨트롤 플레인 노드의 이름을 확인합니다.

2. 컨트롤 플레인 노드를 예약할 수 없음으로 표시합니다.

   $ oc adm cordon <control_plane_node>

3. 컨트롤 플레인 노드와 연결된 VM(가상 머신)을 종료합니다. VM을 마우스 오른쪽 버튼으로 클릭하고 Power → Shut Down Guest OS를 선택하여 vSphere 클라이언트에서 이 작업을 수행합니다. 안전하게 종료되지 않을 수 있으므로 Power Off (전원 끄기)를 사용하여 VM을 종료하지 마십시오.
4. vSphere 클라이언트에서 VM 업그레이드. 자세한 내용은 가상 머신을 VMware 설명서의 최신 하드웨어 버전으로 업그레이드를 참조하십시오.
5. 컨트롤 플레인 노드와 연결된 VM의 전원을 켭니다. VM을 마우스 오른쪽 버튼으로 클릭하고 Power On을 선택하여 vSphere 클라이언트에서 이 작업을 수행합니다.

6. 노드가 Ready로 보고될 때까지 기다립니다.

   $ oc wait --for=condition=Ready node/<control_plane_node>

7. 컨트롤 플레인 노드를 다시 예약 가능으로 표시합니다.

   $ oc adm uncordon <control_plane_node>

8. 클러스터의 각 컨트롤 플레인 노드에 대해 이 절차를 반복합니다.

프로세스

1. 클러스터의 컴퓨팅 노드를 나열합니다.

   $ oc get nodes -l node-role.kubernetes.io/worker

   출력 예

   NAME              STATUS   ROLES    AGE   VERSION
   compute-node-0    Ready    worker   30m   v1.23.0
   compute-node-1    Ready    worker   30m   v1.23.0
   compute-node-2    Ready    worker   30m   v1.23.0

   컴퓨팅 노드의 이름을 확인합니다.

2. 컴퓨팅 노드를 예약 불가로 표시합니다.

   $ oc adm cordon <compute_node>

3. 컴퓨팅 노드에서 pod를 비웁니다. 이 작업을 수행하는 방법에는 여러 가지가 있습니다. 예를 들어 노드의 모든 Pod 또는 선택한 Pod를 비울 수 있습니다.

   $ oc adm drain <compute_node> [--pod-selector=<pod_selector>]

   노드에서 pod를 비우기 위한 다른 옵션은 "노드에서 pod를 비우는 방법 이해" 섹션을 참조하십시오.

4. 컴퓨팅 노드와 연결된 VM(가상 머신)을 종료합니다. VM을 마우스 오른쪽 버튼으로 클릭하고 Power → Shut Down Guest OS를 선택하여 vSphere 클라이언트에서 이 작업을 수행합니다. 안전하게 종료되지 않을 수 있으므로 Power Off (전원 끄기)를 사용하여 VM을 종료하지 마십시오.
5. vSphere 클라이언트에서 VM 업그레이드. 자세한 내용은 가상 머신을 VMware 설명서의 최신 하드웨어 버전으로 업그레이드를 참조하십시오.
6. 컴퓨팅 노드와 연결된 VM의 전원을 켭니다. VM을 마우스 오른쪽 버튼으로 클릭하고 Power On을 선택하여 vSphere 클라이언트에서 이 작업을 수행합니다.

7. 노드가 Ready로 보고될 때까지 기다립니다.

   $ oc wait --for=condition=Ready node/<compute_node>

8. 컴퓨팅 노드를 다시 예약 가능으로 표시합니다.

   $ oc adm uncordon <compute_node>

9. 클러스터의 각 컴퓨팅 노드에 대해 이 절차를 반복합니다.

프로세스

1. RHCOS 템플릿이 vSphere 템플릿으로 구성된 경우 다음 단계 전에 VMware 문서의 가상 머신으로 템플릿을 변환합니다.

   참고

   템플릿에서 변환되면 가상 머신의 전원을 켜지 마십시오.

2. vSphere 클라이언트에서 VM을 업데이트합니다. 자세한 내용은 가상 머신을 VMware 설명서의 최신 하드웨어 버전으로 업그레이드를 참조하십시오.
3. vSphere 클라이언트의 VM을 VM에서 템플릿으로 변환합니다. 자세한 내용은 VMware 문서의 vSphere Client의 템플릿으로 가상 머신을 변환합니다.