클러스터 업데이트

절차

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

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

   중요

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

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

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

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

   참고

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

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

   • 업데이트가 있는 경우 더 이상 업데이트할 수 없을 때까지 현재 채널에서 업데이트를 계속 수행합니다.
   • 사용 가능한 업데이트가 없는 경우 Channel 을 다음 마이너 버전의 stable-* 또는 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. 클러스터를 사용할 수 있는지 확인합니다.

   $ oc get clusterversion

   출력 예

   NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
   version   4.5.4     True        False         158m    Cluster version is 4.5.4

2. 현재 업데이트 채널 정보를 확인하고 채널이 stable-4.6으로 설정되어 있는지 확인합니다.

   $ oc get clusterversion -o json|jq ".items[0].spec"

   출력 예

   {
     "channel": "stable-4.6",
     "clusterID": "990f7ab8-109b-4c95-8480-2bd1deec55ff",
     "upstream": "https://api.openshift.com/api/upgrades_info/v1/graph"
   }

   중요

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

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

   $ oc adm upgrade

   출력 예

   Cluster version is 4.1.0
   
   Updates:
   
   VERSION IMAGE
   4.1.2   quay.io/openshift-release-dev/ocp-release@sha256:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b

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

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

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

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

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

     1 1

     <version>은 이전 명령의 출력에서 얻을 수 있는 업데이트 버전입니다.

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

   $ oc get clusterversion -o json|jq ".items[0].spec"

   출력 예

   {
     "channel": "stable-4.6",
     "clusterID": "990f7ab8-109b-4c95-8480-2bd1deec55ff",
     "desiredUpdate": {
       "force": false,
       "image": "quay.io/openshift-release-dev/ocp-release@sha256:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b",
       "version": "4.6.3" 1
     },
     "upstream": "https://api.openshift.com/api/upgrades_info/v1/graph"
   }

   1

   desiredUpdate 부분의 version 번호가 지정한 값과 일치하는 경우 업데이트가 진행 중입니다.

6. 클러스터 버전 상태 기록에서 업데이트 상태를 모니터링합니다. 모든 개체가 업데이트를 완료하는 데 시간이 걸릴 수 있습니다.

   $ oc get clusterversion -o json|jq ".items[0].status.history"

   출력 예

   [
     {
       "completionTime": null,
       "image": "quay.io/openshift-release-dev/ocp-release@sha256:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b",
       "startedTime": "2020-11-10T20:30:50Z",
       "state": "Partial",
       "verified": true,
       "version": "4.1.2"
     },
     {
       "completionTime": "2020-11-10T20:30:50Z",
       "image": "quay.io/openshift-release-dev/ocp-release@sha256:b8307ac0f3ec4ac86c3f3b52846425205022da52c16f56ec31cbe428501001d6",
       "startedTime": "2020-11-10T17:38:10Z",
       "state": "Completed",
       "verified": false,
       "version": "4.1.0"
     }
   ]

   기록에는 클러스터에 적용된 최신 버전 목록이 포함되어 있습니다. 이 값은 CVO가 업데이트를 적용할 때 업데이트됩니다. 목록은 날짜순으로 정렬되며 최신 업데이트가 목록의 맨 처음에 표시됩니다. 롤아웃이 완료되면 기록의 업데이트 상태는 Completed로 표시되고 업데이트가 실패하거나 완료되지 않은 경우 Partial로표시됩니다.

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

   $ oc get clusterversion

   출력 예

   NAME      VERSION     AVAILABLE   PROGRESSING   SINCE     STATUS
   version   4.6.3       True        False         2m        Cluster version is 4.6.3

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

   $ oc get nodes

   출력 예

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

절차

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

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

   중요

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

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

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

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

   참고

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

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

   • 업데이트가 있는 경우 더 이상 업데이트할 수 없을 때까지 현재 채널에서 업데이트를 계속 수행합니다.
   • 사용 가능한 업데이트가 없는 경우 Channel 을 다음 마이너 버전의 stable-* 또는 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.6에 필요한 리포지토리를 활성화합니다.

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

      # subscription-manager repos --disable=rhel-7-server-ose-4.5-rpms \
                                   --enable=rhel-7-server-ansible-2.9-rpms \
                                   --enable=rhel-7-server-ose-4.6-rpms

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

      # yum update openshift-ansible openshift-clients

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

      # subscription-manager repos --disable=rhel-7-server-ose-4.5-rpms \
                                   --enable=rhel-7-server-ose-4.6-rpms  \
                                   --enable=rhel-7-fast-datapath-rpms   \
                                   --enable=rhel-7-server-optional-rpms

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

   1. 현재 노드 상태를 확인하고 업데이트할 RHEL 작업자를 결정합니다.

      # oc get node

      출력 예

      NAME                        STATUS                        ROLES    AGE    VERSION
      mycluster-control-plane-0   Ready                         master   145m   v1.19.0
      mycluster-control-plane-1   Ready                         master   145m   v1.19.0
      mycluster-control-plane-2   Ready                         master   145m   v1.19.0
      mycluster-rhel7-0           NotReady,SchedulingDisabled   worker   98m    v1.14.6+97c81d00e
      mycluster-rhel7-1           Ready                         worker   98m    v1.14.6+97c81d00e
      mycluster-rhel7-2           Ready                         worker   98m    v1.14.6+97c81d00e
      mycluster-rhel7-3           Ready                         worker   98m    v1.14.6+97c81d00e

      NotReady, SchedulingDisabled 상태인 시스템을 확인합니다.

   2. 다음 예와 같이 /<path>/inventory/hosts에서 Ansible 인벤토리 파일을 확인하고 NotReady, SchedulingDisabled 상태인 시스템만 [workers] 섹션에 나열되도록 내용을 업데이트합니다.

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

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

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

   4. upgrade Playbook을 실행합니다.

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

      1

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

      참고

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

4. 이전 단계의 프로세스에 따라 클러스터의 각 RHEL 작업자 시스템을 업데이트합니다.

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

   # oc get node

   출력 예

   NAME                        STATUS                        ROLES    AGE    VERSION
   mycluster-control-plane-0   Ready                         master   145m   v1.19.0
   mycluster-control-plane-1   Ready                         master   145m   v1.19.0
   mycluster-control-plane-2   Ready                         master   145m   v1.19.0
   mycluster-rhel7-0           NotReady,SchedulingDisabled   worker   98m    v1.19.0
   mycluster-rhel7-1           Ready                         worker   98m    v1.19.0
   mycluster-rhel7-2           Ready                         worker   98m    v1.19.0
   mycluster-rhel7-3           Ready                         worker   98m    v1.19.0

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

   # yum update

   참고

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

1. Red Hat OpenShift Cluster Manager에서 registry.redhat.io 풀 시크릿 을 다운로드하여 .json 파일에 저장합니다.

2. 미러 레지스트리에 대한 base64로 인코딩된 사용자 이름 및 암호 또는 토큰을 생성합니다.

   $ echo -n '<user_name>:<password>' | base64 -w0 1
   BGVtbYk3ZHAtqXs=

   1

   <user_name> 및 <password>의 경우 레지스트리에 설정한 사용자 이름 및 암호를 지정합니다.

3. 풀 시크릿을 JSON 형식으로 복사합니다.

   $ cat ./pull-secret.text | jq .  > <path>/<pull_secret_file_in_json>1

   1

   풀 시크릿을 저장할 폴더의 경로와 생성한 JSON 파일의 이름을 지정합니다.

   파일의 내용은 다음 예와 유사합니다.

   {
     "auths": {
       "cloud.openshift.com": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "quay.io": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "registry.connect.redhat.com": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       },
       "registry.redhat.io": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       }
     }
   }

4. 새 파일을 편집하고 레지스트리를 설명하는 섹션을 추가합니다.

     "auths": {
       "<mirror_registry>": { 1
         "auth": "<credentials>", 2
         "email": "you@example.com"
     },

   1

   <mirror_registry>의 경우 미러 레지스트리가 콘텐츠를 제공하는데 사용하는 레지스트리 도메인 이름 및 포트 (선택 사항)를 지정합니다. 예: registry.example.com 또는 registry.example.com:8443

   2

   <credentials>의 경우 미러 레지스트리에 대해 base64로 인코딩된 사용자 이름 및 암호를 지정합니다.

   파일은 다음 예제와 유사합니다.

   {
     "auths": {
       "registry.example.com": {
         "auth": "BGVtbYk3ZHAtqXs=",
         "email": "you@example.com"
       },
       "cloud.openshift.com": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "quay.io": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "registry.connect.redhat.com": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       },
       "registry.redhat.io": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       }
     }
   }

프로세스

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. 미러링할 저장소 이름을 내보냅니다.

      $ PRODUCT_REPO='openshift-release-dev'

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

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

      $ LOCAL_SECRET_JSON='<path_to_pull_secret>'

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

      참고

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

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

      $ RELEASE_NAME="ocp-release"

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

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

      $ ARCHITECTURE=<server_architecture>

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

      $ 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 ).

   • 로컬 컨테이너 레지스트리와 클러스터가 미러 호스트에 연결된 경우 릴리스 이미지를 로컬 레지스트리로 직접 푸시하고 다음 명령을 사용하여 config map을 클러스터에 적용합니다.

     $ 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을 작성하지 않습니다.

프로세스

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
       source: registry.access.redhat.com/ubi8/ubi-minimal 2
     - mirrors:
       - example.com/example/ubi-minimal
       source: registry.access.redhat.com/ubi8/ubi-minimal
     - mirrors:
       - mirror.example.com/redhat
       source: registry.redhat.io/openshift4 3

   1

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

   2

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

   3

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

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.19.0
      ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.19.0
      ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.19.0
      ip-10-0-147-35.ec2.internal    Ready,SchedulingDisabled   worker   7m   v1.19.0
      ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.19.0
      ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.19.0

      변경 사항이 적용되어 있기 때문에 각 작업자 노드의 예약이 비활성화되어 있음을 알 수 있습니다.

   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. 노드의 파일에 액세스합니다.

      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"]
      [[registry]]
        location = "registry.access.redhat.com/ubi8/"
        insecure = false
        blocked = false
        mirror-by-digest-only = true
        prefix = ""
      
        [[registry.mirror]]
          location = "example.io/example/ubi8-minimal"
          insecure = false
      
        [[registry.mirror]]
          location = "example.com/example/ubi8-minimal"
          insecure = false

   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.6).

   <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