미래 보안 강화: 에이전트 기반 설치 프로그램으로 Red Hat OpenShift 연결 해제된 설치 탐색

오늘날의 디지털 환경에서 신뢰성과 보안 컴플라이언스의 필요성은 그 어느 때보다 중요합니다. 인터넷 연결이 제한적이거나 취약한 환경에 있는 조직의 경우 표준 Red Hat OpenShift 설치와 연결 해제된 설치 또는 에어 갭(air-gap) 설치 중에서 어느 방법을 선택하느냐에 따라 혁신적인 변화를 가져올 수 있습니다. 연결 해제된 설치를 통해 기업은 격리된 보안 중심의 독립형 환경에서 OpenShift 클러스터를 구축하고 유지 관리할 수 있으므로 갈수록 복잡해지는 환경에서 성공하는 데 필요한 강력한 인프라를 확보할 수 있습니다.

이 문서에서는 이러한 필수 배포 및 운영 패러다임의 장점과 주요 고려 사항을 살펴봅니다.

설치 방법

먼저 자체 관리형 OpenShift 클러스터에 사용할 수 있는 각 설치 방법을 검토해 보겠습니다.

이미지-1: 다양한 설치 방법

설치 프로그램 프로비저닝 인프라(Installer-Provisioned Infrastructure, IPI)

IPI는 가장 간단한 설치 방법 중 하나입니다. 안내에 따른 자동화된 설치 경험을 원하는 사용자에게 적합합니다. IPI에서 OpenShift는 가상 머신 또는 물리적 하드웨어를 포함한 인프라를 프로비저닝합니다. 일반적으로 클라우드 공급업체와 함께 사용되지만 온프레미스 설치에도 사용할 수 있습니다.

지원 설치 프로그램(Assisted Installer, AI)

지원 설치 프로그램은 OpenShift 설치를 수행하는 웹 기반 인터랙티브 툴입니다. 인터넷에 연결된 네트워크가 있는 클러스터에 이상적인 접근 방식입니다. 또한 자동화 및 고급 구성 시나리오를 위한 RESTful API를 제공합니다. AI는 Red Hat Advanced Cluster Management의 일부이기도 합니다.

에이전트 기반 설치 프로그램(Agent Based Installer, ABI)

에이전트 기반 설치는 지원 디스커버리 에이전트와 지원 서비스를 포함하는 부팅 가능한 ISO로 구성됩니다. 에이전트 기반 설치는 OpenShift 설치 프로그램의 하위 명령입니다. 이는 사용 가능한 OpenShift 릴리스 이미지와 함께 OpenShift 클러스터를 배포하는 데 필요한 모든 자산을 포함하는 부팅 가능한 ISO 이미지를 생성합니다. 이 접근 방식은 에어 갭(air-gap) 환경, 연결이 해제되거나 제한된 환경에 적합합니다.

사용자 프로비저닝 인프라(User-Provisioned Infrastructure, UPI)

UPI는 온프레미스, 자체 데이터센터 또는 퍼블릭 클라우드 제공업체 등 자체 인프라를 관리하고자 하는 사용자를 위한 유연한 설치 방법입니다. UPI를 사용하면 사용자가 가상 머신, 스토리지, 그리고 로드 밸런서와 같은 네트워킹 구성 요소를 프로비저닝해야 합니다. 인프라 프로비저닝이 완료되면 OpenShift의 설치 프로그램을 사용하여 선택한 인프라에 OpenShift를 배포할 수 있습니다.

호스팅된 컨트롤 플레인(Hosted Control Plane, HCP)

OpenShift 클러스터는 독립 실행형 또는 호스팅된 컨트롤 플레인의 두 가지 컨트롤 플레인 구성을 사용하여 배포할 수 있습니다. 독립 실행형 구성에서는 전용 가상 머신 또는 물리적 머신을 사용하여 컨트롤 플레인을 호스팅합니다. OpenShift용 호스팅된 컨트롤 플레인을 사용하면 각 컨트롤 플레인의 전용 가상 머신 또는 물리적 머신 없이도 호스팅 클러스터에서 포드로서 컨트롤 플레인을 생성할 수 있습니다. 자세한 내용은 공식 HCP 도큐멘테이션 및 이 문서를 참조하세요.

연결 해제된 설치란?

시나리오에 따라 다양한 설치 유형이 있습니다. 활용 사례에 적합한 방법을 선택하는 것이 중요합니다. 연결 해제된 OpenShift 설치는 보안 컴플라이언스, 제어, 신뢰성이 가장 중요하고 직접적인 인터넷 연결이 제한되거나 바람직하지 않은 조직 및 환경에 중요한 솔루션입니다. 이는 격리된 보안 중심의 독립적인 네트워크에서 OpenShift 클러스터를 관리하고 유지보수하는 데 필요한 인프라를 제공합니다.

제한됨: 연결 해제된 환경

연결 해제된 환경 내에서 운영할 때 OpenShift 클러스터는 인터넷에 직접 연결되지 않으며, 프록시를 통해서도 연결되지 않습니다. 환경을 지원하는 모든 필수 콘텐츠는 로컬로 미러링해야 합니다. oc 툴 세트를 실행하는 머신은 OpenShift API와 함께 이미지 레지스트리에 대한 액세스 권한뿐만 아니라 프록시를 통해 직접 또는 간접적으로 인터넷에 액세스할 수 있어야 합니다.

이미지-2: 제한됨 - 연결 해제된 환경

이 블로그에서는 요새(bastion) 호스트를 통해 인터넷 연결이 가능하지만 연결 해제된/제한된 네트워크에서의 에이전트 기반 설치 방법에 중점을 둡니다.

제한됨: 에어 갭(air-gap) 환경

 RFC 4949에 따르면 '에어 갭(air-gap)'은 두 시스템이 물리적으로 연결되지 않고 논리적 연결이 자동화되지 않은 경우를 말합니다. 데이터는 사람의 개입을 통해 수동으로 전송됩니다.

이미지-3: 제한됨 - 에어 갭(air-gap) 환경

이 경우 OpenShift 클러스터는 인터넷에 직접 연결되지 않으며, 프록시를 통해서도 연결되지 않습니다. 환경을 지원하는 모든 필수 콘텐츠는 로컬로 미러링됩니다. 설치를 실행하는 머신은 OpenShift API뿐만 아니라 미러 레지스트리에도 액세스할 수 있지만 어떤 형태로든 인터넷에는 액세스할 수 없습니다. 모든 콘텐츠는 USB 스틱, 광 미디어 또는 기타 '오프라인' 수단을 통해 제공되어야 합니다.

요새(bastion) 호스트에 인터넷 연결이 없는 경우 공식 도큐멘테이션의 이 섹션을 참조하여 이미지 세트를 디스크에 미러링한 다음, 디스크의 이미지 세트 파일을 미러에 미러링하는 추가 단계를 수행합니다. 이 부분은 이 문서에서는 다루지 않습니다.

연결 해제된 설치를 수행하는 데 필요한 툴

에이전트 기반 설치 프로그램을 사용하여 실제 설치를 시작하기 전에, 연결 해제된 설치를 수행하는 데 필요한 툴을 살펴보겠습니다.

Red Hat OpenShift용 미러 레지스트리

OpenShift 설치 및 후속 제품 업데이트를 지원하는 데 필요한 이미지를 Red Hat Quay와 같이 Docker v2-2를 지원하는 컨테이너 미러 레지스트리로 미러링할 수 있습니다. 대규모 컨테이너 레지스트리에 액세스할 수 없는 경우, OpenShift 서브스크립션에 포함된 소규모 컨테이너 레지스트리인 Red Hat OpenShift용 미러 레지스트리를 사용할 수 있습니다.

OpenShift 클라이언트(oc) 미러 플러그인

oc-mirror 명령은 이미지를 미러링하는 데 사용할 수 있는 OpenShift CLI(oc) 플러그인입니다. 원래 소스에서 필수 콘텐츠를 다운로드하려면 인터넷에 연결된 시스템에서 oc-mirror를 실행해야 합니다.

미러 레지스트리 사전 요구 사항

• OpenShift 서브스크립션
• Podman 3.4.2 이상 및 OpenSSL이 설치된 Red Hat Enterprise Linux(RHEL) 8 또는 9
• DNS 서버를 통해 확인해야 하는 Red Hat Quay 서비스의 정규화된 도메인 이름
• 2개 이상의 vCPU
• 8GB RAM
• OpenShift 4.13 릴리스 이미지의 경우 약 17GB, 또는 OpenShift 4.13 릴리스 이미지 및 OpenShift 4.13 Red Hat Operator 이미지의 경우 약 358GB. 각 스트림에 대해 최대 1TB 이상이 권장됩니다.

설치 태스크

기본 RHEL VM이 설치되면 요새(bastion) 호스트에서 다음 툴을 다운로드합니다.

• Podman 3.4.2 이상

$ sudo dnf install -y podman

• OpenShift 클라이언트(oc CLI) 

$ wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz
$ tar --extract --file openshift-client-linux.tar.gz
$ chmod +x oc
$ sudo mv oc /usr/local/bin/

• 미러 레지스트리

$ wget https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/mirror-registry/latest/mirror-registry.tar.gz
$ tar --extract --file mirror-registry.tar.gz
$ chmod +x mirror-registry

• oc 미러

$ wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/oc-mirror.tar.gz
$ tar --extract --file oc-mirror.tar.gz
$ chmod +x oc-mirror
$ sudo mv oc-mirror /usr/local/bin/

미러 레지스트리 설치

미러 레지스트리는 단일 명령으로 설치할 수 있습니다.

$ ./mirror-registry install --quayHostname<hostname fqdn> \
--quayRoot /root/ocpmirror

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

$ sudo mirror-registry install \
--quayHostname bastion.j9287.dynamic.opentlc.com \
--quayRoot /root/ocpmirror

미러 레지스트리를 성공적으로 설치하면 다음과 같은 출력이 반환됩니다.

[...]
INFO[2023-10-31 11:17:28] Quay installed successfully, config data is stored in /root/ocpmirror
INFO[2023-10-31 11:17:28] Quay is available at https://bastion.j9287.dynamic.opentlc.com:8443 with credentials (init, 7HFdq385A9EG0ngVWo4cKeDtxRzp621N)

제공된 자격 증명의 URL을 사용하여 미러 레지스트리에 액세스할 수 있는지 확인합니다.

$ podman login -u init -p <password generated by installer> \
https://<hostname fqdn>:8443 \
--tls-verify=false

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

$ podman login -u init \
-p 7HFdq385A9EG0ngVWo4cKeDtxRzp621N \ https://bastion.j9287.dynamic.opentlc.com:8443 \
--tls-verify=false

미러 레지스트리는 사용자 정의 CA와 함께 제공되므로, 아래 변수를 내보내 레지스트리에 안전하게 액세스할 수 있습니다.

$ export SSL_CERT_DIR=/root/ocpmirror/quay-rootCA/
$ podman login -u init \
-p 7HFdq385A9EG0ngVWo4cKeDtxRzp621N \
https://bastion.j9287.dynamic.opentlc.com:8443

 https://console.redhat.com/openshift/downloads에서 OpenShift 풀 시크릿(pull secret)을 다운로드하고, 다운로드한 파일을 pull-secret으로 저장합니다.

홈 디렉터리에서 아래 명령을 실행하여 레지스트리 인증을 구성합니다.

$ cat pull-secret | jq . > pull-secret.json
$ mkdir .docker ; cp pull-secret.json ~/.docker/config.json
$ echo -n 'init:7HFdq385A9EG0ngVWo4cKeDtxRzp621N' | \
base64 -w0

이전 명령의 출력을 사용하여 ~/.docker/config.json에 로컬 미러 인증을 포함하도록 파일을 조정합니다.

"auths": {
 "bastion.j9287.dynamic.opentlc.com:8443": {
   "auth": "aW5pdDo3SEZkcTM3NUE5RUcwbmdWV280Y0tlRHR4UnpwNjIxTg==",
   "email": "email@example.com"
 },

이제 미러 레지스트리가 설치되고 구성되었습니다. 자세한 내용은 공식 도큐멘테이션을 참조하세요.

이미지 미러링

이 섹션에서는 필수 콘텐츠를 미러 레지스트리에 미러링하기 위해 oc mirror OpenShift CLI 플러그인을 사용합니다.

연결 해제된 환경에서는 대상 미러 레지스트리에 이미지 세트를 직접 미러링할 수 있습니다.

에어 갭(air-gap) 환경에서는 먼저 이미지 세트를 디스크에 미러링한 다음, 디스크의 이미지 세트 파일을 미러에 미러링해야 합니다.

먼저 ImageSetConfiguration에 대한 새 파일을 생성합니다.

kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
 registry:
   imageURL: bastion.j9287.dynamic.opentlc.com:8443/mirror/oc-mirror-metadata # Local mirror registry URL
   skipTLS: false
mirror:
 platform:
   channels:
   - name: stable-4.13    # Version of OpenShift to be mirrored
     minVersion: 4.13.17  # Minimum version of OpenShift to be mirrored
     maxVersion: 4.13.18  # Maximum version of OpenShift to be mirrored
     shortestPath: true
     type: ocp
   graph: true   # Useful when updating in disconnected setup with OSUS operator
 operators:
 - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.13 # Operators catalog to mirror
 additionalImages:
 - name: registry.redhat.io/ubi8/ubi:latest
 helm: {}

샘플 파일은 이 리포지토리에 제공되어 있습니다. 필요에 따라 이 파일을 조정할 수 있는 옵션의 전체 목록은 공식 도큐멘테이션을 참조하세요.
 

이 예제의 경우 ImageSetConfiguration 파일은 레지스트리 스토리지 백엔드(bastion.j9287.dynamic.opentlc.com:8443/mirror/oc-mirror-metadata)를 사용하며, 최소 버전 4.13.17부터 채널의 최신 버전인 4.13.18까지의 모든 OpenShift 버전을 포함합니다. 이 이미지 세트 구성을 사용하여 oc-mirror를 호출할 때마다 stable-4.13 채널의 최신 릴리스가 평가되므로 정기적으로 oc-mirror를 실행하면 자동으로 OpenShift 이미지의 최신 릴리스를 수신할 수 있습니다.

 ImageSetConfiguration 파일이 준비되면 다음 명령을 실행하여 콘텐츠를 레지스트리에 미러링합니다. 미러링 프로세스에 필요한 시간은 구성 및 연결 속도에 따라 달라집니다.

$ oc mirror --config=imageset-config.yaml \
docker://<hostname fqdn>:8443 

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

$ oc mirror --config=imageset-config.yaml \  docker://bastion.j9287.dynamic.opentlc.com:8443

선택적 매개 변수 --continue-on-error 및 --skip-missing 은 오류를 무시해야 하는 경우 유용할 수 있습니다.

이전 명령을 성공적으로 실행하면 다음과 같은 출력이 표시됩니다.

[...]
bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images:4.13.17-x86_64
bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images:4.13.18-x86_64
Writing image mapping to oc-mirror-workspace/results-1698872844/mapping.txt
Writing UpdateService manifests to oc-mirror-workspace/results-1698872844
Writing CatalogSource manifests to oc-mirror-workspace/results-1698872844
Writing ICSP manifests to oc-mirror-workspace/results-1698872844

일부 파일은 oc-mirror에 의해 생성됩니다. 여기에는 updateService가 포함됩니다.

apiVersion: updateservice.operator.openshift.io/v1
kind: UpdateService
metadata:
 name: update-service-oc-mirror
spec:
 graphDataImage: bastion.j9287.dynamic.opentlc.com:8443/openshift/graph-image@sha256:a8730004abd6a4c1d02f52d8052a69a014a4e3de677135b2dfe50259fb6b63fa
 releases: bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
 replicas: 2

파일 ImageContentSourcePolicy:

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
 name: release-0
spec:
 repositoryDigestMirrors:
 - mirrors:
   - bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
   source: quay.io/openshift-release-dev/ocp-release
 - mirrors:
   - bastion.j9287.dynamic.opentlc.com:8443/openshift/release
   source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

마지막으로, CatalogSource:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
 name: redhat-operator-index
 namespace: openshift-marketplace
spec:
 image: bastion.j9287.dynamic.opentlc.com:8443/redhat/redhat-operator-index:v4.13
 sourceType: grpc

이러한 파일은 나중에 설치를 위해 미러 레지스트리를 구성하고, 오퍼레이터 및 업데이트 서비스가 로컬 레지스트리를 사용하도록 지시하는 데 필요합니다.

또한 https://:8443으로 이동하여 미러 레지스트리 사용자 인터페이스에 로그인할 수도 있습니다.

에이전트 기반 설치

로컬 미러 레지스트리가 설치 및 구성된 상태에서 에이전트 기반 설치 프로그램을 사용하여 OpenShift 설치를 살펴볼 수 있습니다. 이 글을 작성하는 시점에 에이전트 기반 설치 프로그램은 다음 플랫폼을 지원합니다.

• baremetal
• vsphere
• none

에이전트 기반 설치에서는 지원 디스커버리 에이전트 및 지원 서비스를 포함하는 부팅 가능한 ISO를 사용합니다. 둘 다 클러스터 설치를 수행하는 데 필요하지만 후자는 호스트 중 하나에서만 실행됩니다.  openshift-install agent create image 하위 명령은 사용자가 제공하는 입력에 따라 임시 ISO를 생성합니다.

 install-config.yaml 파일에는 풀 시크릿(pull secret), 로컬 미러 레지스트리의 추가 인증서 신뢰 번들, 그리고 해당 로컬 미러를 가리키는 ImageContentSources를 포함해야 합니다.

 agent-config.yaml 파일에는 설치 중에 임시 부트스트랩 노드가 될 호스트의 IP 주소인 "rendezvousIP" 매개 변수를 포함해야 합니다. 이 IP 주소는 노드 중 하나와 일치해야 합니다.

에이전트 기반 설치 프로그램을 사용하는 설치 준비 단계의 전체 목록은 이 링크를 참조하세요. 샘플 install-config.yaml 및 agent-config.yaml은 이 리포지토리에서 확인할 수 있습니다.

ISO 생성

 install-config.yaml 및 agent-config.yaml 파일을 모두 조정한 후에는 ISO 이미지를 생성할 차례입니다.

먼저, nmstate 패키지를 설치합니다.

$ sudo dnf install /usr/bin/nmstatectl

그런 다음, OpenShift 설치 프로그램을 다운로드합니다. OpenShift 설치 프로그램 버전은 설치하려는 클러스터 버전과 일치해야 합니다. 이 문서에서는 Openshift 4.13.17을 사용하고 있으므로 먼저 이 버전을 설치한 다음, 클러스터를 4.13.18로 업데이트합니다.

$ wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/4.13.17/openshift-install-linux.tar.gz
$ tar --extract --file openshift-install-linux.tar.gz
$ chmod +x openshift-install
$ sudo mv openshift-install /usr/local/bin/

마지막으로, ISO를 생성합니다.

$ openshift-install agent create image --dir <directory>

다음과 유사한 출력이 표시됩니다.

INFO Configuration has 3 master replicas and 3 worker replicas
INFO The rendezvous host IP (node0 IP) is 192.168.94.21
INFO Extracting base ISO from release payload    
INFO Base ISO obtained from release and cached at [/root/.cache/agent/image_cache/coreos-x86_64.iso]
INFO Consuming Install Config from target directory
INFO Consuming Agent Config from target directory

플랫폼에 따라 컨트롤 플레인 및 컴퓨팅 노드에 대한 노드(베어메탈 또는 VM)를 준비해야 합니다. 클러스터의 모든 노드가 생성된 ISO 이미지에서 부팅되는지 확인합니다.

DNS 레코드 생성

DNS에서 두 개의 정적 IP 주소에 대한 DNS 레코드를 생성해야 합니다. 각 레코드에서 <cluster_name>은 클러스터 이름을 의미하며, <base_domain>은 클러스터를 설치할 때 지정한 클러스터 기본 도메인을 의미합니다. 전체 DNS 레코드는 다음과 같은 형식을 따릅니다. <component>.<cluster_name>.<base_domain>

API VIP - api.<cluster_name>.<base_domain>

Ingress VIP - *.apps.<cluster_name>.<base_domain>

OpenShift 클러스터 생성

가상 미디어, 부팅 가능한 USB 및 DVD를 포함하여 각 클러스터 호스트에서 ISO 이미지를 부팅합니다.

생성한 ISO 이미지에서 부팅하도록 노드를 구성합니다. 모든 노드가 ISO 이미지에서 부팅되면 아래 명령을 사용하여 설치를 모니터링할 수 있습니다.

$ openshift-install agent wait-for bootstrap-complete \
--dir <directory> --log-level=debug
[...]
INFO Cluster is ready for install                
INFO Cluster validation: All hosts in the cluster are ready to install.
INFO Preparing cluster for installation
INFO Cluster installation in progress
INFO Bootstrap configMap status is complete      
INFO cluster bootstrap is complete

부트스트랩 프로세스가 완료되면 다음 명령을 실행하여 추가 진행 상황을 모니터링할 수 있습니다.

$ openshift-install agent wait-for install-complete \
--dir <directory> --log-level=debug
[...]
INFO Cluster is installed                        
INFO Install complete!                           
INFO To access the cluster as the system:admin user when using 'oc', run
INFO     export KUBECONFIG=/root/auth/kubeconfig 
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.j9287.dynamic.opentlc.com
INFO Login to the console with user: "kubeadmin", and password: "HR377-xxxxx-yyyyy-ynxGC"

설치가 완료되었다는 메시지가 표시되면 oc 명령을 사용하여 클러스터에 로그인하고 OpenShift 클러스터의 버전을 확인할 수 있습니다.

$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.17   True        False         11m     Cluster version is 4.13.17

에이전트 기반 설치 프로그램에 대한 자세한 내용은 공식 OpenShift 도큐멘테이션을 참조하세요.

 ImageContentSourcePolicy를 확인하여 OpenShift 클러스터가 로컬 미러 레지스트리에서 이미지를 수신하고 있는지 확인할 수 있습니다.

$ oc get imagecontentsourcepolicy
NAME             AGE
image-policy-0   18h
image-policy-1   18h
$ oc describe imagecontentsourcepolicy image-policy-0 |grep -A4 Spec:
Spec:
 Repository Digest Mirrors:
   Mirrors:
     bastion.j9287.dynamic.opentlc.com:8443/openshift/release
   Source:  quay.io/openshift-release-dev/ocp-v4.0-art-dev
$ oc describe imagecontentsourcepolicy image-policy-1 |grep -A4 Spec:
Spec:
 Repository Digest Mirrors:
   Mirrors:
     bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
   Source:  quay.io/openshift-release-dev/ocp-release

클러스터가 인터넷에 연결되어 있지 않으므로 모든 기본 카탈로그 소스를 제거하려면 몇 가지 추가 구성을 수행해야 합니다. 다음 명령을 실행하여 기본 CatalogSources를 비활성화하도록 OperatorHub 리소스에 패치를 적용합니다.

$ oc get catsrc -A
NAMESPACE               NAME                  DISPLAY               TYPE   PUBLISHER   AGE
openshift-marketplace   certified-operators   Certified Operators   grpc   Red Hat     32m
openshift-marketplace   community-operators   Community Operators   grpc   Red Hat     32m
openshift-marketplace   redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     32m
openshift-marketplace   redhat-operators      Red Hat Operators     grpc   Red Hat     32m
$ oc patch OperatorHub cluster --type json \
-p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
operatorhub.config.openshift.io/cluster patched
$ oc get catsrc -A
No resources found

위의 이미지 미러링 섹션에서 CatalogSource.yaml을 적용하여 로컬 미러 레지스트리를 가리키는 새 CatalogSource 리소스를 생성합니다.

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
 name: redhat-operator-index
 namespace: openshift-marketplace
spec:
 image: bastion.j9287.dynamic.opentlc.com:8443/redhat/redhat-operator-index:v4.13
 sourceType: grpc
 
$ oc apply -f ./oc-mirror-workspace/results-1698872844/

$ oc apply -f ./oc-mirror-workspace/results-1698872844/release-signatures/

적용한 후, 이전에 시도한 검증 단계를 다시 실행합니다.

$ oc get po -n openshift-marketplace
NAME                                    READY   STATUS    RESTARTS   AGE
marketplace-operator-7bc7549555-4ckdm   1/1     Running   0          48m
redhat-operator-index-t4cgd             1/1     Running   0          75s

$ oc get catsrc -A
NAMESPACE               NAME                    DISPLAY   TYPE   PUBLISHER   AGE
openshift-marketplace   redhat-operator-index             grpc               82s

이 시점에서 다음 작업이 완료되었습니다.

• 에이전트 기반 설치 방법을 사용하여 새 OpenShift 클러스터가 설치되었습니다.
• 설치 이미지를 인터넷 대신 로컬 미러 레지스트리에서 가져왔습니다.
• Operator Hub가 로컬 미러 레지스트리를 사용하도록 구성되었습니다.

연결 해제된 환경에서 OpenShift 업데이트

블로그의 첫 번째 부분에서는 두 가지 버전의 OpenShift 4.13.17 및 4.13.18을 사용하여 로컬 레지스트리를 미러링했습니다( ImageSetConfiguration 파일의 내용 참조). 인터넷에 액세스할 수 있는 클러스터의 경우, Red Hat은 퍼블릭 API 뒤에 있는 호스팅 서비스로서 OSUS(OpenShift Update Service)를 사용하여 무선(OTA) 업데이트를 제공하지만, 이 예시에서는 연결 해제 모드에 중점을 둡니다. OSUS에 대한 자세한 내용은 클러스터 관리를 위한 OpenShift 업데이트 가이드에서 확인할 수 있습니다.

연결 해제된/에어 갭(air-gap) 환경에서 OpenShift 업데이트를 수행하는 방법에는 OSUS(OpenShift Update Service) Operator를 사용하지 않는 방법과 OSUS(OpenShift Update Service) Operator를 사용하는 방법이 있습니다.

OSUS(OpenShift Update Service) Operator를 사용하지 않는 방법

먼저, OpenShift 클러스터를 4.13.17에서 4.13.18로 업데이트하는 가장 간단한 옵션을 살펴보겠습니다.  oc 명령을 사용할 수 있고 인터넷 연결이 활성화된 노트북 또는 시스템에서 아래 명령을 실행합니다.

$ export OCP_RELEASE_VERSION=4.13.18
$ export ARCHITECTURE=x86_64
$ oc adm release info -o 'jsonpath={.digest}{"\n"}' quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_VERSION}-${ARCHITECTURE}
sha256:d0fd9d3ab8690605f816c879d74f4e6d6d9f72982f63a3e0ef3e027ecc512e1c

이전 명령의 출력을 사용하여 OpenShift 클러스터에 액세스할 수 있는 요새(bastion) 노드에서 OpenShift 클러스터를 업그레이드합니다.

$ oc adm upgrade --allow-explicit-upgrade \
--to-image quay.io/openshift-release-dev/ocp-release@sha256:d0fd9d3ab8690605f816c879d74f4e6d6d9f72982f63a3e0ef3e027ecc512e1c
Requested update to 4.13.18

$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.17   True        True          78m     Working towards 4.13.18: 106 of 843 done (12% complete), waiting up to 40 minutes on etcd, kube-apiserver

$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.18   True        False         5m25s   Cluster version is 4.13.18

OpenShift 업데이트에 대한 자세한 내용은 공식 도큐멘테이션을 참조하세요.

OSUS(OpenShift Update Service) Operator를 사용하는 방법

OSUS(OpenShift Update Service) Operator를 사용하려면, 설치에 사용한 레지스트리와 다른 경우 보안 레지스트리에 대한 액세스를 구성해야 합니다. 이 문서에서는 로컬 미러 레지스트리를 사용했기 때문에 해당 사항은 적용되지 않습니다.

또한 설치에 사용한 레지스트리와 다른 경우, 미러 레지스트리에 액세스하려면 글로벌 클러스터 풀 시크릿을 업데이트해야 합니다. 이 문서에서는 로컬 미러 레지스트리를 사용했기 때문에 해당 사항은 적용되지 않습니다.

OSUS를 사용하려면 먼저 Operator Hub에서 OSUS Operator를 설치해야 합니다.

그런 다음, OpenShift Update Service에 대한 그래프 데이터 컨테이너 이미지를 생성합니다. 이 문서의 예시에서는 이미지 미러링에 oc mirror를 사용하고 미러링하는 동안 ImageSetConfiguration 파일에 graph: true를 포함했기 때문에 이 단계는 필요하지 않습니다.

이 과정이 완료되면 OSUS 애플리케이션을 설치하고 클러스터가 로컬 OpenShift Update Service를 사용하도록 구성합니다.  UpdateService.yaml을 사용하여 필요한 구성을 적용합니다. 예를 들면 다음과 같습니다.

apiVersion: updateservice.operator.openshift.io/v1
kind: UpdateService
metadata:
 name: update-service-oc-mirror
spec:
 graphDataImage: bastion.j9287.dynamic.opentlc.com:8443/openshift/graph-image@sha256:a8730004abd6a4c1d02f52d8052a69a014a4e3de677135b2dfe50259fb6b63fa
 releases: bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
 replicas: 2

OSUS 애플리케이션이 설치되면, 다음 명령을 실행하여 CVO(Cluster Version Operator)가 인터넷 대신 로컬에 설치된 OSUS에서 그래프 데이터를 가져오도록 합니다.

$ export NAMESPACE=openshift-update-service
$ export NAME=update-service-oc-mirror
$ export POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice "${NAME}")"
$ export PATCH="{\"spec\":{\"upstream\":\"${POLICY_ENGINE_GRAPH_URI}\"}}"
$ oc patch clusterversion version -p $PATCH --type merge

 oc adm upgrade 명령을 실행할 때 인증서 오류가 반환되는 경우, 클러스터 전체 프록시를 사용하도록 설정했는지 확인하고 업데이트 서버를 신뢰하도록 CA를 구성합니다.

마지막으로, 이전 섹션에서 설명한 대로 업데이트 절차를 수행합니다. OpenShift Update Service Operator에 대한 자세한 내용은 도큐멘테이션을 참조하세요.

결론

이 블로그에서는 미러 레지스트리 및 oc mirror와 같은 툴을 사용하여 연결 해제된/에어 갭(air-gap) 설치를 위한 로컬 리포지토리를 설정하는 방법에 대한 자세한 지침을 살펴보았습니다. 이 지식을 바탕으로 OpenShift 관리자는 로컬로 미러링된 이미지를 사용하여 OpenShift 클러스터를 설치할 뿐만 아니라 업그레이드 및 업데이트할 수 있습니다.