Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

6.3. 연결이 끊긴 환경의 베어 메탈에 호스팅된 컨트롤 플레인 배포

베어 메탈에서 호스팅되는 컨트롤 플레인을 프로비저닝할 때 에이전트 플랫폼을 사용합니다. Kubernetes Operator의 에이전트 플랫폼과 다중 클러스터 엔진은 함께 작동하여 연결이 끊긴 배포를 활성화합니다. 에이전트 플랫폼은 중앙 인프라 관리 서비스를 사용하여 호스트된 클러스터에 작업자 노드를 추가합니다. 중앙 인프라 관리 서비스에 대한 소개는 중앙 인프라 관리 서비스 활성화를 참조하십시오.

6.3.1. 베어 메탈의 연결이 끊긴 환경 아키텍처
링크 복사

다음 다이어그램은 연결이 끊긴 환경의 예제 아키텍처를 보여줍니다.

Disconnected architecture diagram

  1. 연결이 끊긴 배포가 작동하는지 확인하기 위해 TLS 지원, 웹 서버 및 DNS를 사용하여 레지스트리 인증서 배포를 포함한 인프라 서비스를 구성합니다.

  2. openshift-config 네임스페이스에 구성 맵을 생성합니다. 이 예에서 구성 맵의 이름은 registry-config 입니다. 구성 맵의 내용은 레지스트리 CA 인증서입니다. 구성 맵의 data 필드에는 다음 키/값이 포함되어야 합니다.

    • 키: < registry_dns_domain_name>..<port > (예: registry.hypershiftdomain.lab..5000: ). 포트를 지정할 때 레지스트리 DNS 도메인 이름 뒤에 .. 를 배치해야 합니다.

    • value: 인증서 콘텐츠

      구성 맵 생성에 대한 자세한 내용은 호스팅된 컨트롤 플레인의 연결이 끊긴 설치에 대한 TLS 인증서 구성 을 참조하십시오.

  3. images.config.openshift.io CR(사용자 정의 리소스) 사양을 수정하고 이름이 registry-config 인 additionalTrustedCA 라는 새 필드를 추가합니다.

  4. 두 개의 데이터 필드가 포함된 구성 맵을 생성합니다. 한 필드에는 RAW 형식의 registries.conf 파일이 포함되어 있고 다른 필드에는 레지스트리 CA가 포함되어 있으며 ca-bundle.crt 라는 이름이 있습니다. 구성 맵은 multicluster-engine 네임스페이스에 속하며 구성 맵 이름은 다른 오브젝트에서 참조됩니다. 구성 맵의 예는 다음 샘플 구성을 참조하십시오. 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-registries
  namespace: multicluster-engine
  labels:
    app: assisted-service
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    # ...
    -----END CERTIFICATE-----
  registries.conf: |
    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/openshift4"
    mirror-by-digest-only = true

    [[registry.mirror]]
      location = "registry.ocp-edge-cluster-0.qe.lab.redhat.com:5000/openshift4"

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/rhacm2"
    mirror-by-digest-only = true
# ...
# ...
    Copy to Clipboard Toggle word wrap
  5. 다중 클러스터 엔진 Operator 네임스페이스에서 Agent 및 hypershift-addon 애드온을 둘 다 활성화하는 multiclusterengine CR을 생성합니다. 다중 클러스터 엔진 Operator 네임스페이스에는 연결이 끊긴 배포에서 동작을 수정하려면 구성 맵이 포함되어야 합니다. 네임스페이스에는 multicluster-engine,assisted-service, hypershift-addon-manager Pod도 포함되어 있습니다.

  6. 호스팅된 클러스터를 배포하는 데 필요한 다음 오브젝트를 생성합니다.

    • 보안: 시크릿에는 풀 시크릿, SSH 키 및 etcd 암호화 키가 포함됩니다.
    • 구성 맵: 구성 맵에는 프라이빗 레지스트리의 CA 인증서가 포함되어 있습니다.
    • HostedCluster: HostedCluster 리소스는 사용자가 생성하려는 클러스터의 구성을 정의합니다.
    • NodePool: NodePool 리소스는 데이터 플레인에 사용할 머신을 참조하는 노드 풀을 식별합니다.
  7. 호스팅된 클러스터 오브젝트를 생성하면 HyperShift Operator에서 컨트롤 플레인 Pod를 수용하도록 HostedControlPlane 네임스페이스를 설정합니다. 네임스페이스는 에이전트, 베어 메탈 호스트(BMH) 및 InfraEnv 리소스와 같은 구성 요소도 호스팅합니다. 나중에 InfraEnv 리소스를 생성하고 ISO 생성 후 BMC(Baseboard Management Controller) 인증 정보가 포함된 BMH 및 해당 시크릿을 생성합니다.
  8. openshift-machine-api 네임스페이스의 Metal3 Operator는 새 BMH를 검사합니다. 그런 다음 Metal3 Operator는 다중 클러스터 엔진 Operator 네임스페이스에서 AgentServiceConfig CR을 통해 지정된 구성된 LiveISO 및 RootFS 값을 사용하여 BMC에 연결을 시도합니다.
  9. HostedCluster 리소스의 작업자 노드가 시작되면 에이전트 컨테이너가 시작됩니다. 이 에이전트는 배포를 완료하기 위한 작업을 오케스트레이션하는 지원 서비스와의 연락처를 설정합니다. 처음에 NodePool 리소스를 HostedCluster 리소스의 작업자 노드 수로 스케일링해야 합니다. 지원 서비스는 나머지 작업을 관리합니다.
  10. 이 시점에서 배포 프로세스가 완료될 때까지 기다립니다.

연결이 끊긴 환경에서 호스팅되는 컨트롤 플레인을 구성하려면 다음 사전 요구 사항을 충족해야 합니다.

  • cpu: 제공된 CPU 수에 따라 동시에 실행할 수 있는 호스트 클러스터 수가 결정됩니다. 일반적으로 노드 3개당 각 노드에 16개의 CPU를 사용합니다. 최소 개발의 경우 노드 3개에 각 노드에 12개의 CPU를 사용할 수 있습니다.
  • memory: 호스트할 수 있는 호스트 클러스터 수에 영향을 미칩니다. 각 노드에 48GB의 RAM을 사용합니다. 최소한의 개발의 경우 18GB의 RAM이면 충분합니다.

  • 스토리지: 다중 클러스터 엔진 Operator에 SSD 스토리지를 사용합니다.

    • 관리 클러스터: 250GB.
    • 레지스트리: 필요한 스토리지는 호스팅되는 릴리스, 운영자 및 이미지 수에 따라 다릅니다. 허용 가능한 숫자는 500GB일 수 있으며, 호스트 클러스터를 호스팅하는 디스크와 분리되는 것이 좋습니다.
    • 웹 서버: 필요한 스토리지는 호스팅되는 ISO 및 이미지 수에 따라 다릅니다. 허용 가능한 숫자는 500GB일 수 있습니다.

  • 프로덕션: 프로덕션 환경의 경우 관리 클러스터, 레지스트리 및 웹 서버를 다른 디스크에서 분리합니다. 이 예에서는 프로덕션에 대한 가능한 구성을 보여줍니다.

    • 레지스트리: 2TB
    • 관리 클러스터: 500GB
    • 웹 서버: 2TB

6.3.3. 릴리스 이미지 다이제스트 추출
링크 복사

태그된 이미지를 사용하여 OpenShift Container Platform 릴리스 이미지 다이제스트를 추출할 수 있습니다.

프로세스

  • 다음 명령을 실행하여 이미지 다이제스트를 가져옵니다. 

    $ oc adm release info <tagged_openshift_release_image> | grep "Pull From"
    Copy to Clipboard Toggle word wrap

    < tagged_openshift_release_image >를 지원되는 OpenShift Container Platform 버전에 대한 태그된 이미지로 바꿉니다(예: quay.io/openshift-release-dev/ocp-release:4.14.0-x8_64 ).

    출력 예

    Pull From: quay.io/openshift-release-dev/ocp-release@sha256:69d1292f64a2b67227c5592c1a7d499c7d00376e498634ff8e1946bc9ccdddfe
    Copy to Clipboard Toggle word wrap

6.3.4. 베어 메탈의 DNS 구성
링크 복사

호스팅된 클러스터의 API 서버는 NodePort 서비스로 노출됩니다. API Server에 연결할 수 있는 대상을 가리키는 api.<hosted_cluster_name>.<base_domain >에 대한 DNS 항목이 있어야 합니다.

DNS 항목은 호스팅된 컨트롤 플레인을 실행하는 관리 클러스터에서 노드 중 하나를 가리키는 레코드만큼 간단할 수 있습니다. 이 항목은 들어오는 트래픽을 인그레스 포드로 리디렉션하기 위해 배포된 로드 밸런서를 가리킬 수도 있습니다.

DNS 구성 예

api.example.krnl.es.    IN A 192.168.122.20
api.example.krnl.es.    IN A 192.168.122.21
api.example.krnl.es.    IN A 192.168.122.22
api-int.example.krnl.es.    IN A 192.168.122.20
api-int.example.krnl.es.    IN A 192.168.122.21
api-int.example.krnl.es.    IN A 192.168.122.22
`*`.apps.example.krnl.es. IN A 192.168.122.23
Copy to Clipboard Toggle word wrap

참고

이전 예에서 *.apps.example.krnl.es. IN A 192.168.122.23 은 구성된 경우 호스팅 클러스터 또는 로드 밸런서의 노드입니다.

IPv6 네트워크에서 연결이 끊긴 환경에 대해 DNS를 구성하는 경우 구성은 다음 예와 같습니다.

IPv6 네트워크의 DNS 구성 예

api.example.krnl.es.    IN A 2620:52:0:1306::5
api.example.krnl.es.    IN A 2620:52:0:1306::6
api.example.krnl.es.    IN A 2620:52:0:1306::7
api-int.example.krnl.es.    IN A 2620:52:0:1306::5
api-int.example.krnl.es.    IN A 2620:52:0:1306::6
api-int.example.krnl.es.    IN A 2620:52:0:1306::7
`*`.apps.example.krnl.es. IN A 2620:52:0:1306::10
Copy to Clipboard Toggle word wrap

듀얼 스택 네트워크에서 연결이 끊긴 환경에 대해 DNS를 구성하는 경우 IPv4 및 IPv6 모두에 대한 DNS 항목을 포함해야 합니다.

듀얼 스택 네트워크의 DNS 구성 예

host-record=api-int.hub-dual.dns.base.domain.name,192.168.126.10
host-record=api.hub-dual.dns.base.domain.name,192.168.126.10
address=/apps.hub-dual.dns.base.domain.name/192.168.126.11
dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,192.168.126.20
dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,192.168.126.21
dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,192.168.126.22
dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,192.168.126.25
dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,192.168.126.26

host-record=api-int.hub-dual.dns.base.domain.name,2620:52:0:1306::2
host-record=api.hub-dual.dns.base.domain.name,2620:52:0:1306::2
address=/apps.hub-dual.dns.base.domain.name/2620:52:0:1306::3
dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,[2620:52:0:1306::5]
dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,[2620:52:0:1306::6]
dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,[2620:52:0:1306::7]
dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,[2620:52:0:1306::8]
dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,[2620:52:0:1306::9]
Copy to Clipboard Toggle word wrap

개발 환경의 경우 Podman 컨테이너를 사용하여 소규모 자체 호스팅 레지스트리를 배포합니다. 프로덕션 환경의 경우 Red Hat Quay, Nexus 또는 Artifactory와 같은 엔터프라이즈 호스팅 레지스트리를 배포합니다.

프로세스

Podman을 사용하여 작은 레지스트리를 배포하려면 다음 단계를 완료합니다.

  1. 권한 있는 사용자로 ${HOME} 디렉터리에 액세스하고 다음 스크립트를 생성합니다. 

    #!/usr/bin/env bash

set -euo pipefail

PRIMARY_NIC=$(ls -1 /sys/class/net | grep -v podman | head -1)
export PATH=/root/bin:$PATH
export PULL_SECRET="/root/baremetal/hub/openshift_pull.json"
    1 
    

if [[ ! -f $PULL_SECRET ]];then
  echo "Pull Secret not found, exiting..."
  exit 1
fi

dnf -y install podman httpd httpd-tools jq skopeo libseccomp-devel
export IP=$(ip -o addr show $PRIMARY_NIC | head -1 | awk '{print $4}' | cut -d'/' -f1)
REGISTRY_NAME=registry.$(hostname --long)
REGISTRY_USER=dummy
REGISTRY_PASSWORD=dummy
KEY=$(echo -n $REGISTRY_USER:$REGISTRY_PASSWORD | base64)
echo "{\"auths\": {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\", \"email\": \"sample-email@domain.ltd\"}}}" > /root/disconnected_pull.json
mv ${PULL_SECRET} /root/openshift_pull.json.old
jq ".auths += {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\",\"email\": \"sample-email@domain.ltd\"}}" < /root/openshift_pull.json.old > $PULL_SECRET
mkdir -p /opt/registry/{auth,certs,data,conf}
cat <<EOF > /opt/registry/conf/config.yml
version: 0.1
log:
  fields:
    service: registry
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry
  delete:
    enabled: true
http:
  addr: :5000
  headers:
    X-Content-Type-Options: [nosniff]
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3
compatibility:
  schema1:
    enabled: true
EOF
openssl req -newkey rsa:4096 -nodes -sha256 -keyout /opt/registry/certs/domain.key -x509 -days 3650 -out /opt/registry/certs/domain.crt -subj "/C=US/ST=Madrid/L=San Bernardo/O=Karmalabs/OU=Guitar/CN=$REGISTRY_NAME" -addext "subjectAltName=DNS:$REGISTRY_NAME"
cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract
htpasswd -bBc /opt/registry/auth/htpasswd $REGISTRY_USER $REGISTRY_PASSWORD
podman create --name registry --net host --security-opt label=disable --replace -v /opt/registry/data:/var/lib/registry:z -v /opt/registry/auth:/auth:z -v /opt/registry/conf/config.yml:/etc/docker/registry/config.yml -e "REGISTRY_AUTH=htpasswd" -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry" -e "REGISTRY_HTTP_SECRET=ALongRandomSecretForRegistry" -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd -v /opt/registry/certs:/certs:z -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key docker.io/library/registry:latest
[ "$?" == "0" ] || !!
systemctl enable --now registry
    Copy to Clipboard Toggle word wrap
    1
    PULL_SECRET 위치를 설정에 적합한 위치로 교체합니다.

  2. 스크립트 파일 이름을 registry.sh 로 지정하고 저장합니다. 스크립트를 실행하면 다음 정보를 가져옵니다.

    • 하이퍼바이저 호스트 이름을 기반으로 하는 레지스트리 이름
    • 필요한 인증 정보 및 사용자 액세스 세부 정보

  3. 다음과 같이 실행 플래그를 추가하여 권한을 조정합니다. 

    $ chmod u+x ${HOME}/registry.sh
    Copy to Clipboard Toggle word wrap

  4. 매개변수 없이 스크립트를 실행하려면 다음 명령을 입력합니다. 

    $ ${HOME}/registry.sh
    Copy to Clipboard Toggle word wrap

    스크립트가 서버를 시작합니다. 스크립트는 관리 목적으로 systemd 서비스를 사용합니다.

  5. 스크립트를 관리해야 하는 경우 다음 명령을 사용할 수 있습니다. 

    $ systemctl status
    Copy to Clipboard Toggle word wrap 
    $ systemctl start
    Copy to Clipboard Toggle word wrap 
    $ systemctl stop
    Copy to Clipboard Toggle word wrap

레지스트리의 루트 폴더는 /opt/registry 디렉터리에 있으며 다음 하위 디렉터리가 포함되어 있습니다.

  • 인증서에는 TLS 인증서가 포함되어 있습니다.
  • auth 에는 인증 정보가 포함됩니다.
  • 데이터에 는 레지스트리 이미지가 포함되어 있습니다.
  • conf 에는 레지스트리 구성이 포함되어 있습니다.

OpenShift Container Platform 관리 클러스터를 설정하려면 Kubernetes Operator의 다중 클러스터 엔진이 설치되어 있는지 확인해야 합니다. 다중 클러스터 엔진 Operator는 공급자 전체에 클러스터를 배포하는 데 중요한 역할을 합니다.

사전 요구 사항

  • 관리 클러스터와 대상 베어 메탈 호스트(BMH)의 BMC(Baseboard Management Controller) 간에 양방향 연결이 있어야 합니다. 또는 에이전트 공급자를 통해 Boot It Yourself 접근 방식을 따릅니다.

  • 호스트된 클러스터는 관리 클러스터 호스트 이름 및 *.apps 호스트 이름의 API 호스트 이름을 확인하고 연결할 수 있어야 합니다. 다음은 관리 클러스터의 API 호스트 이름과 *.apps 호스트 이름의 예입니다.

    • api.management-cluster.internal.domain.com
    • console-openshift-console.apps.management-cluster.internal.domain.com

  • 관리 클러스터는 호스팅된 클러스터의 API 및 *.apps 호스트 이름을 확인하고 연결할 수 있어야 합니다. 다음은 호스팅된 클러스터의 API 호스트 이름과 *.apps 호스트 이름의 예입니다.

    • api.sno-hosted-cluster-1.internal.domain.com
    • console-openshift-console.apps.sno-hosted-cluster-1.internal.domain.com

프로세스

  1. OpenShift Container Platform 클러스터에 다중 클러스터 엔진 Operator 2.4 이상을 설치합니다. OpenShift Container Platform 소프트웨어 카탈로그에서 다중 클러스터 엔진 Operator를 Operator로 설치할 수 있습니다. HyperShift Operator는 다중 클러스터 엔진 Operator에 포함되어 있습니다. 다중 클러스터 엔진 Operator 설치에 대한 자세한 내용은 Red Hat Advanced Cluster Management 설명서의 "Multicluster 엔진 Operator 설치 및 업그레이드"를 참조하십시오.
  2. HyperShift Operator가 설치되어 있는지 확인합니다. HyperShift Operator는 멀티 클러스터 엔진 Operator에 자동으로 포함되지만 수동으로 설치해야 하는 경우 "local-cluster용 hypershift-addon 관리 클러스터 애드온 활성화"의 단계를 따르십시오.

다음 단계

다음으로 웹 서버를 구성합니다.

6.3.7. 연결이 끊긴 환경에서 호스팅된 컨트롤 플레인의 웹 서버 구성
링크 복사

호스트 클러스터로 배포 중인 OpenShift Container Platform 릴리스와 연결된 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 호스팅하도록 추가 웹 서버를 구성해야 합니다.

프로세스

웹 서버를 구성하려면 다음 단계를 완료합니다.

  1. 다음 명령을 입력하여 사용할 OpenShift Container Platform 릴리스에서 openshift-install 바이너리를 추출합니다. 

    $ oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install \
  "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"
    Copy to Clipboard Toggle word wrap

  2. 다음 스크립트를 실행합니다. 이 스크립트는 /opt/srv 디렉터리에 폴더를 생성합니다. 폴더에는 작업자 노드를 프로비저닝하는 RHCOS 이미지가 포함되어 있습니다. 

    #!/bin/bash

WEBSRV_FOLDER=/opt/srv
ROOTFS_IMG_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.pxe.rootfs.location')"
    1 
    
LIVE_ISO_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.iso.disk.location')"
    2 
    

mkdir -p ${WEBSRV_FOLDER}/images
curl -Lk ${ROOTFS_IMG_URL} -o ${WEBSRV_FOLDER}/images/${ROOTFS_IMG_URL##*/}
curl -Lk ${LIVE_ISO_URL} -o ${WEBSRV_FOLDER}/images/${LIVE_ISO_URL##*/}
chmod -R 755 ${WEBSRV_FOLDER}/*

## Run Webserver
podman ps --noheading | grep -q websrv-ai
if [[ $? == 0 ]];then
    echo "Launching Registry pod..."
    /usr/bin/podman run --name websrv-ai --net host -v /opt/srv:/usr/local/apache2/htdocs:z quay.io/alosadag/httpd:p8080
fi
    Copy to Clipboard Toggle word wrap
    1
    ROOTFS_IMG_URL 값은 OpenShift CI 릴리스 페이지에서 찾을 수 있습니다.
    2
    LIVE_ISO_URL 값은 OpenShift CI 릴리스 페이지에서 확인할 수 있습니다.

다운로드가 완료되면 컨테이너가 실행되어 웹 서버에서 이미지를 호스팅합니다. 컨테이너는 공식 HTTPd 이미지의 변형을 사용하여 IPv6 네트워크에서도 작업할 수 있습니다.

이미지 미러링은 registry.redhat.com 또는 quay.io 와 같은 외부 레지스트리에서 이미지를 가져와서 프라이빗 레지스트리에 저장하는 프로세스입니다.

다음 절차에서는 ImageSetConfiguration 오브젝트를 사용하는 바이너리인 oc-mirror 툴이 사용됩니다. 파일에서 다음 정보를 지정할 수 있습니다.

  • 미러링할 OpenShift Container Platform 버전입니다. 버전은 quay.io 에 있습니다.
  • 미러링할 추가 Operator입니다. 패키지를 개별적으로 선택합니다.
  • 리포지토리에 추가할 추가 이미지입니다.

사전 요구 사항

  • 미러링 프로세스를 시작하기 전에 레지스트리 서버가 실행 중인지 확인합니다.

프로세스

이미지 미러링을 구성하려면 다음 단계를 완료합니다.

  1. 이미지를 푸시하려는 프라이빗 레지스트리와 미러링할 레지스트리를 사용하여 ${HOME}/.docker/config.json 파일이 업데이트되었는지 확인합니다.

  2. 다음 예제를 사용하여 미러링에 사용할 ImageSetConfiguration 오브젝트를 만듭니다. 환경에 맞게 필요에 따라 값을 바꿉니다. 

    apiVersion: mirror.openshift.io/v2alpha1
kind: ImageSetConfiguration
mirror:
  platform:
    channels:
    - name: candidate-4.20
      minVersion: <4.x.y-build>
    1 
    
      maxVersion: <4.x.y-build>
    2 
    
      type: ocp
    kubeVirtContainer: true
    3 
    
    graph: true
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.20
    packages:
    - name: lvms-operator
    - name: local-storage-operator
    - name: odf-csi-addons-operator
    - name: odf-operator
    - name: mcg-operator
    - name: ocs-operator
    - name: metallb-operator
    - name: kubevirt-hyperconverged
    4
    Copy to Clipboard Toggle word wrap
    1 2
    & lt;4.x.y-build >를 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
    3
    KubeVirt 공급자의 RHCOS(Red Hat Enterprise Linux CoreOS) 부팅 이미지의 컨테이너 디스크 이미지도 미러링하려면 이 선택적 플래그를 true 로 설정합니다. 이 플래그는 oc-mirror v2에서만 사용할 수 있습니다.
    4
    KubeVirt 공급자를 사용하는 배포의 경우 이 행을 포함합니다.

  3. 다음 명령을 입력하여 미러링 프로세스를 시작합니다. 

    $ oc-mirror --v2 --config imagesetconfig.yaml \
  --workspace file://mirror-file docker://<registry>
    Copy to Clipboard Toggle word wrap

    미러링 프로세스가 완료되면 IDMS( ImageDigestMirrorSet ), ImageTagMirrorSet (ITMS) 및 호스팅된 클러스터에 적용할 카탈로그 소스가 포함된 mirror-file 이라는 새 폴더가 있습니다.

  4. imagesetconfig.yaml 파일을 다음과 같이 구성하여 OpenShift Container Platform의 Nightly 또는 CI 버전을 미러링합니다. 

    apiVersion: mirror.openshift.io/v2alpha1
kind: ImageSetConfiguration
mirror:
  platform:
    graph: true
    release: registry.ci.openshift.org/ocp/release:<4.x.y-build>
    1 
    
    kubeVirtContainer: true
    2 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    & lt;4.x.y-build >를 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
    2
    KubeVirt 공급자의 RHCOS(Red Hat Enterprise Linux CoreOS) 부팅 이미지의 컨테이너 디스크 이미지도 미러링하려면 이 선택적 플래그를 true 로 설정합니다. 이 플래그는 oc-mirror v2에서만 사용할 수 있습니다.

  5. 부분적으로 연결이 끊긴 환경이 있는 경우 다음 명령을 입력하여 이미지 세트 구성의 이미지를 레지스트리로 미러링합니다. 

    $ oc mirror -c imagesetconfig.yaml \
  --workspace file://<file_path> docker://<mirror_registry_url> --v2
    Copy to Clipboard Toggle word wrap

    자세한 내용은 "부분 연결이 끊긴 환경에서 이미지 세트 미러링"을 참조하십시오.

  6. 완전히 연결이 끊긴 환경이 있는 경우 다음 단계를 수행합니다.

    1. 다음 명령을 입력하여 지정된 이미지 세트 구성의 이미지를 디스크로 미러링합니다. 

      $ oc mirror -c imagesetconfig.yaml file://<file_path> --v2
      Copy to Clipboard Toggle word wrap

      자세한 내용은 "완전하게 연결이 끊긴 환경에서 이미지 세트 미러링"을 참조하십시오.

    2. 디스크에서 이미지 세트 파일을 처리하고 다음 명령을 입력하여 콘텐츠를 대상 미러 레지스트리에 미러링합니다. 

      $ oc mirror -c imagesetconfig.yaml \
  --from file://<file_path> docker://<mirror_registry_url> --v2
      Copy to Clipboard Toggle word wrap
  7. 연결이 끊긴 네트워크에 설치 단계에 따라 최신 다중 클러스터 엔진 Operator 이미지를 미러링합니다.

6.3.9. 관리 클러스터에 오브젝트 적용
링크 복사

미러링 프로세스가 완료되면 관리 클러스터에 두 개의 오브젝트를 적용해야 합니다.

  • ImageContentSourcePolicy (ICSP) 또는 ImageDigestMirrorSet (IDMS)
  • 카탈로그 소스

oc-mirror 툴을 사용하는 경우 출력 아티팩트는 oc-mirror-workspace/results-XXXXXX/ 이라는 폴더에 있습니다.

ICSP 또는 IDMS는 노드를 재시작하지 않고 각 노드에서 kubelet을 다시 시작하는 MachineConfig 변경을 시작합니다. 노드가 READY 로 표시되면 새로 생성된 카탈로그 소스를 적용해야 합니다.

카탈로그 소스는 카탈로그 이미지 다운로드 및 처리와 같은 openshift-marketplace Operator에서 작업을 시작하여 해당 이미지에 포함된 모든 PackageManifest 를 검색합니다.

프로세스

  1. 새 소스를 확인하려면 새 CatalogSource 를 소스로 사용하여 다음 명령을 실행합니다. 

    $ oc get packagemanifest
    Copy to Clipboard Toggle word wrap

  2. 아티팩트를 적용하려면 다음 단계를 완료합니다.

    1. 다음 명령을 입력하여 ICSP 또는 IDMS 아티팩트를 생성합니다. 

      $ oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
      Copy to Clipboard Toggle word wrap

    2. 노드가 준비될 때까지 기다린 다음 다음 명령을 입력합니다. 

      $ oc apply -f catalogSource-XXXXXXXX-index.yaml
      Copy to Clipboard Toggle word wrap

  3. OLM 카탈로그를 미러링하고 미러를 가리키도록 호스팅 클러스터를 구성합니다.

    관리 (기본값) OLMCatalogPlacement 모드를 사용하면 관리 클러스터의 ICSP에서 재정의 정보를 사용하여 OLM 카탈로그에 사용되는 이미지 스트림이 자동으로 수정되지 않습니다.

    1. 원래 이름 및 태그를 사용하여 OLM 카탈로그가 내부 레지스트리에 올바르게 미러링된 경우 hypershift.openshift.io/olm-catalogs-is-registry-overrides 주석을 HostedCluster 리소스에 추가합니다. 형식은 "sr1=dr1,sr2=dr2" 입니다. 여기서 소스 레지스트리 문자열은 키이고 대상 레지스트리는 값입니다.

    2. OLM 카탈로그 이미지 스트림 메커니즘을 바이패스하려면 HostedCluster 리소스에서 다음 4개의 주석을 사용하여 OLM Operator 카탈로그에 사용할 4개의 이미지의 주소를 직접 지정합니다.

      • hypershift.openshift.io/certified-operators-catalog-image
      • hypershift.openshift.io/community-operators-catalog-image
      • hypershift.openshift.io/redhat-marketplace-catalog-image
      • hypershift.openshift.io/redhat-operators-catalog-image

이 경우 이미지 스트림이 생성되지 않으며 Operator 업데이트를 가져오려면 내부 미러를 새로 고칠 때 주석 값을 업데이트해야 합니다.

다음 단계

호스팅된 컨트롤 플레인의 연결이 끊긴 설치를 위해 다중 클러스터 엔진 Operator 배포 단계를 완료하여 다중 클러스터 엔진 Operator를 배포합니다.

6.3.10. AgentServiceConfig 리소스 배포
링크 복사

AgentServiceConfig 사용자 정의 리소스는 다중 클러스터 엔진 Operator의 일부인 지원 서비스 애드온의 필수 구성 요소입니다. 베어 메탈 클러스터 배포를 담당합니다. 애드온이 활성화되면 AgentServiceConfig 리소스를 배포하여 애드온을 구성합니다.

AgentServiceConfig 리소스를 구성하는 것 외에도 연결이 끊긴 환경에서 다중 클러스터 엔진 Operator가 제대로 작동하는지 확인하기 위해 추가 구성 맵을 포함해야 합니다.

프로세스

  1. 배포를 사용자 지정하는 연결이 끊긴 세부 정보가 포함된 다음 구성 맵을 추가하여 사용자 정의 레지스트리를 구성합니다. 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-registries
  namespace: multicluster-engine
  labels:
    app: assisted-service
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
  registries.conf: |
    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/openshift4"
    mirror-by-digest-only = true

    [[registry.mirror]]
      location = "registry.dns.base.domain.name:5000/openshift4"
    1 
    

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/rhacm2"
    mirror-by-digest-only = true
    # ...
    # ...
    Copy to Clipboard Toggle word wrap
    1
    dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

    오브젝트에는 다음 두 개의 필드가 있습니다.

    • 사용자 정의 CA: 이 필드에는 배포의 다양한 프로세스에 로드되는 CA(인증 기관)가 포함되어 있습니다.
    • Registry: Registries.conf 필드에는 원래 소스 레지스트리가 아닌 미러 레지스트리에서 사용해야 하는 이미지 및 네임스페이스에 대한 정보가 포함되어 있습니다.

  2. 다음 예와 같이 AssistedServiceConfig 오브젝트를 추가하여 Assisted Service를 구성합니다. 

    apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
  annotations:
    unsupported.agent-install.openshift.io/assisted-service-configmap: assisted-service-config
    1 
    
  name: agent
  namespace: multicluster-engine
spec:
  mirrorRegistryRef:
    name: custom-registries
    2 
    
  databaseStorage:
    storageClassName: lvms-vg1
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi
  filesystemStorage:
    storageClassName: lvms-vg1
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 20Gi
  osImages:
    3 
    
  - cpuArchitecture: x86_64
    4 
    
    openshiftVersion: "4.14"
    rootFSUrl: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live-rootfs.x86_64.img
    5 
    
    url: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live.x86_64.iso
    version: 414.92.202308281054-0
  - cpuArchitecture: x86_64
   openshiftVersion: "4.15"
   rootFSUrl: http://registry.dns.base.domain.name:8080/images/rhcos-415.92.202403270524-0-live-rootfs.x86_64.img
   url: http://registry.dns.base.domain.name:8080/images/rhcos-415.92.202403270524-0-live.x86_64.iso
   version: 415.92.202403270524-0
    Copy to Clipboard Toggle word wrap
    1
    metadata.annotations["unsupported.agent-install.openshift.io/assisted-service-configmap"] 주석은 Operator가 동작을 사용자 정의하는 데 사용하는 구성 맵 이름을 참조합니다.
    2
    spec.mirrorRegistryRef.name 주석은 Assisted Service Operator가 사용하는 연결이 끊긴 레지스트리 정보가 포함된 구성 맵을 가리킵니다. 이 구성 맵은 배포 프로세스 중에 해당 리소스를 추가합니다.
    3
    spec.osImages 필드에는 이 Operator에서 배포할 수 있는 다양한 버전이 포함되어 있습니다. 이 필드는 필수입니다. 이 예제에서는 이미 RootFS 및 LiveISO 파일을 다운로드했다고 가정합니다.
    4
    배포하려는 모든 OpenShift Container Platform 릴리스에 대해 cpuArchitecture 하위 섹션을 추가합니다. 이 예에서는 cpuArchitecture 하위 섹션이 4.14 및 4.15에 포함되어 있습니다.
    5
    rootFSUrl 및 url 필드에서 dns.base.domain.name 을 DNS 기본 도메인 이름으로 교체합니다.

  3. 해당 오브젝트를 단일 파일에 연결하고 관리 클러스터에 적용하여 모든 오브젝트를 배포합니다. 이렇게 하려면 다음 명령을 입력합니다. 

    $ oc apply -f agentServiceConfig.yaml
    Copy to Clipboard Toggle word wrap

    명령은 두 개의 pod를 트리거합니다.

    출력 예

    assisted-image-service-0                               1/1     Running   2             11d
    1 
    
assisted-service-668b49548-9m7xw                       2/2     Running   5             11d
    2
    Copy to Clipboard Toggle word wrap

    1
    assisted-image-service Pod는 배포하는 각 클러스터에 대해 사용자 지정되는 RHCOS(Red Hat Enterprise Linux CoreOS) 부팅 이미지 템플릿을 생성합니다.
    2
    assisted-service 는 Operator를 나타냅니다.

다음 단계

TLS 인증서를 구성합니다.

연결이 끊긴 배포에서 제대로 작동하려면 관리 클러스터에서 레지스트리 CA 인증서와 호스팅된 클러스터의 작업자 노드를 구성해야 합니다.

6.3.11.1. 관리 클러스터에 레지스트리 CA 추가
링크 복사

레지스트리 CA를 관리 클러스터에 추가하려면 다음 단계를 완료합니다.

프로세스

  1. 다음 예와 유사한 구성 맵을 생성합니다. 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: <config_map_name>
    1 
    
  namespace: <config_map_namespace>
    2 
    
data:
    3 
    
  <registry_name>..<port>: |
    4 
    
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
  <registry_name>..<port>: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
  <registry_name>..<port>: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap
    1
    구성 맵 이름을 지정합니다.
    2
    구성 맵의 네임스페이스를 지정합니다.
    3
    data 필드에서 레지스트리 이름과 레지스트리 인증서 콘텐츠를 지정합니다. & lt;port& gt;를 레지스트리 서버가 실행 중인 포트(예: 5000 )로 바꿉니다.
    4
    | - 와 같은 다른 방법 대신 | 을 사용하여 구성 맵의 데이터를 정의해야 합니다. 다른 방법을 사용하는 경우 Pod에서 인증서를 읽을 때 문제가 발생할 수 있습니다.

  2. 클러스터 전체 오브젝트 image.config.openshift.io 를 패치하여 다음 사양을 포함합니다. 

    spec:
  additionalTrustedCA:
    - name: registry-config
    Copy to Clipboard Toggle word wrap

    이 패치로 인해 컨트롤 플레인 노드는 프라이빗 레지스트리에서 이미지를 검색할 수 있으며 HyperShift Operator는 호스팅된 클러스터 배포를 위해 OpenShift Container Platform 페이로드를 추출할 수 있습니다.

    오브젝트 패치 프로세스를 완료하는 데 몇 분이 걸릴 수 있습니다.

6.3.11.2. 호스트된 클러스터의 작업자 노드에 레지스트리 CA 추가
링크 복사

호스팅된 클러스터의 데이터 플레인 작업자가 프라이빗 레지스트리에서 이미지를 검색하려면 레지스트리 CA를 작업자 노드에 추가해야 합니다.

프로세스

  1. hc.spec.additionalTrustBundle 파일에서 다음 사양을 추가합니다. 

    spec:
  additionalTrustBundle:
    - name: user-ca-bundle
    1
    Copy to Clipboard Toggle word wrap
    1
    user-ca-bundle 항목은 다음 단계에서 생성하는 구성 맵입니다.

  2. HostedCluster 오브젝트가 생성된 동일한 네임스페이스에서 user-ca-bundle 구성 맵을 생성합니다. 구성 맵은 다음 예와 유사합니다. 

    apiVersion: v1
data:
  ca-bundle.crt: |
    // Registry1 CA
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----

    // Registry2 CA
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----

    // Registry3 CA
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----

kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: <hosted_cluster_namespace>
    1
    Copy to Clipboard Toggle word wrap
    1
    HostedCluster 오브젝트가 생성되는 네임스페이스를 지정합니다.

6.3.12. 베어 메탈에서 호스트 클러스터 생성
링크 복사

호스팅 클러스터는 관리 클러스터에서 호스팅되는 컨트롤 플레인 및 API 끝점이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 클러스터에는 컨트롤 플레인과 해당 데이터 플레인이 포함됩니다.

6.3.12.1. 호스트된 클러스터 오브젝트 배포
링크 복사

일반적으로 HyperShift Operator는 HostedControlPlane 네임스페이스를 생성합니다. 그러나 이 경우 HyperShift Operator가 HostedCluster 오브젝트를 조정하기 전에 모든 오브젝트를 포함해야 합니다. 그러면 Operator가 조정 프로세스를 시작하면 모든 오브젝트를 찾을 수 있습니다.

프로세스

  1. 네임스페이스에 대한 다음 정보를 사용하여 YAML 파일을 생성합니다. 

    ---
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: <hosted_cluster_namespace>-<hosted_cluster_name>
    1 
    
spec: {}
status: {}
---
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: <hosted_cluster_namespace>
    2 
    
spec: {}
status: {}
    Copy to Clipboard Toggle word wrap
    1
    &lt ;hosted_cluster_name&gt;을 호스팅된 클러스터로 바꿉니다.
    2
    & lt;hosted_cluster_namespace& gt;를 호스팅된 클러스터 네임스페이스의 이름으로 바꿉니다.

  2. HostedCluster 배포에 포함할 구성 맵 및 시크릿에 대한 다음 정보를 사용하여 YAML 파일을 생성합니다. 

    ---
apiVersion: v1
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: <hosted_cluster_namespace>
    1 
    
---
apiVersion: v1
data:
  .dockerconfigjson: xxxxxxxxx
kind: Secret
metadata:
  creationTimestamp: null
  name: <hosted_cluster_name>-pull-secret
    2 
    
  namespace: <hosted_cluster_namespace>
    3 
    
---
apiVersion: v1
kind: Secret
metadata:
  name: sshkey-cluster-<hosted_cluster_name>
    4 
    
  namespace: <hosted_cluster_namespace>
    5 
    
stringData:
  id_rsa.pub: ssh-rsa xxxxxxxxx
---
apiVersion: v1
data:
  key: nTPtVBEt03owkrKhIdmSW8jrWRxU57KO/fnZa8oaG0Y=
kind: Secret
metadata:
  creationTimestamp: null
  name: <hosted_cluster_name>-etcd-encryption-key
    6 
    
  namespace: <hosted_cluster_namespace>
    7 
    
type: Opaque
    Copy to Clipboard Toggle word wrap
    1 3 5 7
    & lt;hosted_cluster_namespace& gt;를 호스팅된 클러스터 네임스페이스의 이름으로 바꿉니다.
    2 4 6
    &lt ;hosted_cluster_name&gt;을 호스팅된 클러스터로 바꿉니다.

  3. 지원 서비스 에이전트가 호스팅된 컨트롤 플레인과 동일한 HostedControlPlane 네임스페이스에 있을 수 있고 클러스터 API에서 계속 관리할 수 있도록 RBAC 역할이 포함된 YAML 파일을 생성합니다. 

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: capi-provider-role
  namespace: <hosted_cluster_namespace>-<hosted_cluster_name>
    1
    2 
    
rules:
- apiGroups:
  - agent-install.openshift.io
  resources:
  - agents
  verbs:
  - '*'
    Copy to Clipboard Toggle word wrap
    1
    & lt;hosted_cluster_namespace& gt;를 호스팅된 클러스터 네임스페이스의 이름으로 바꿉니다.
    2
    &lt ;hosted_cluster_name&gt;을 호스팅된 클러스터로 바꿉니다.

  4. 필요에 따라 값을 교체하여 HostedCluster 오브젝트에 대한 정보를 사용하여 YAML 파일을 생성합니다. 

    apiVersion: hypershift.openshift.io/v1beta1
kind: HostedCluster
metadata:
  name: <hosted_cluster_name>
    1 
    
  namespace: <hosted_cluster_namespace>
    2 
    
spec:
  additionalTrustBundle:
    name: "user-ca-bundle"
  olmCatalogPlacement: guest
  imageContentSources:
    3 
    
  - source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
    mirrors:
    - registry.<dns.base.domain.name>:5000/openshift/release
    4 
    
  - source: quay.io/openshift-release-dev/ocp-release
    mirrors:
    - registry.<dns.base.domain.name>:5000/openshift/release-images
    5 
    
  - mirrors:
  ...
  ...
  autoscaling: {}
  controllerAvailabilityPolicy: SingleReplica
  dns:
    baseDomain: <dns.base.domain.name>
    6 
    
  etcd:
    managed:
      storage:
        persistentVolume:
          size: 8Gi
        restoreSnapshotURL: null
        type: PersistentVolume
    managementType: Managed
  fips: false
  networking:
    clusterNetwork:
    - cidr: 10.132.0.0/14
    - cidr: fd01::/48
    networkType: OVNKubernetes
    serviceNetwork:
    - cidr: 172.31.0.0/16
    - cidr: fd02::/112
  platform:
    agent:
      agentNamespace: <hosted_cluster_namespace>-<hosted_cluster_name>
    7
    8 
    
    type: Agent
  pullSecret:
    name: <hosted_cluster_name>-pull-secret
    9 
    
  release:
    image: registry.<dns.base.domain.name>:5000/openshift/release-images:<4.x.y>-x86_64
    10
    11 
    
  secretEncryption:
    aescbc:
      activeKey:
        name: <hosted_cluster_name>-etcd-encryption-key
    12 
    
    type: aescbc
  services:
  - service: APIServer
    servicePublishingStrategy:
      type: LoadBalancer
  - service: OAuthServer
    servicePublishingStrategy:
      type: Route
  - service: OIDC
    servicePublishingStrategy:
      type: Route
  - service: Konnectivity
    servicePublishingStrategy:
      type: Route
  - service: Ignition
    servicePublishingStrategy:
      type: Route
  sshKey:
    name: sshkey-cluster-<hosted_cluster_name>
    13 
    
status:
  controlPlaneEndpoint:
    host: ""
    port: 0
    Copy to Clipboard Toggle word wrap
    1 7 9 12 13
    &lt ;hosted_cluster_name&gt;을 호스팅된 클러스터로 바꿉니다.
    2 8
    & lt;hosted_cluster_namespace& gt;를 호스팅된 클러스터 네임스페이스의 이름으로 바꿉니다.
    3
    imageContentSources 섹션에는 호스팅된 클러스터 내의 사용자 워크로드에 대한 미러 참조가 포함되어 있습니다.
    4 5 6 10
    & lt;dns.base.domain.name&gt;을 DNS 기본 도메인 이름으로 바꿉니다.
    11
    & lt;4.x.y >를 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.

  5. YAML 파일에 정의된 모든 오브젝트를 파일에 연결하고 관리 클러스터에 적용하여 해당 오브젝트를 생성합니다. 이렇게 하려면 다음 명령을 입력합니다. 

    $ oc apply -f 01-4.14-hosted_cluster-nodeport.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                                  READY   STATUS    RESTARTS   AGE
capi-provider-5b57dbd6d5-pxlqc                        1/1     Running   0          3m57s
catalog-operator-9694884dd-m7zzv                      2/2     Running   0          93s
cluster-api-f98b9467c-9hfrq                           1/1     Running   0          3m57s
cluster-autoscaler-d7f95dd5-d8m5d                     1/1     Running   0          93s
cluster-image-registry-operator-5ff5944b4b-648ht      1/2     Running   0          93s
cluster-network-operator-77b896ddc-wpkq8              1/1     Running   0          94s
cluster-node-tuning-operator-84956cd484-4hfgf         1/1     Running   0          94s
cluster-policy-controller-5fd8595d97-rhbwf            1/1     Running   0          95s
cluster-storage-operator-54dcf584b5-xrnts             1/1     Running   0          93s
cluster-version-operator-9c554b999-l22s7              1/1     Running   0          95s
control-plane-operator-6fdc9c569-t7hr4                1/1     Running   0          3m57s
csi-snapshot-controller-785c6dc77c-8ljmr              1/1     Running   0          77s
csi-snapshot-controller-operator-7c6674bc5b-d9dtp     1/1     Running   0          93s
csi-snapshot-webhook-5b8584875f-2492j                 1/1     Running   0          77s
dns-operator-6874b577f-9tc6b                          1/1     Running   0          94s
etcd-0                                                3/3     Running   0          3m39s
hosted-cluster-config-operator-f5cf5c464-4nmbh        1/1     Running   0          93s
ignition-server-6b689748fc-zdqzk                      1/1     Running   0          95s
ignition-server-proxy-54d4bb9b9b-6zkg7                1/1     Running   0          95s
ingress-operator-6548dc758b-f9gtg                     1/2     Running   0          94s
konnectivity-agent-7767cdc6f5-tw782                   1/1     Running   0          95s
kube-apiserver-7b5799b6c8-9f5bp                       4/4     Running   0          3m7s
kube-controller-manager-5465bc4dd6-zpdlk              1/1     Running   0          44s
kube-scheduler-5dd5f78b94-bbbck                       1/1     Running   0          2m36s
machine-approver-846c69f56-jxvfr                      1/1     Running   0          92s
oauth-openshift-79c7bf44bf-j975g                      2/2     Running   0          62s
olm-operator-767f9584c-4lcl2                          2/2     Running   0          93s
openshift-apiserver-5d469778c6-pl8tj                  3/3     Running   0          2m36s
openshift-controller-manager-6475fdff58-hl4f7         1/1     Running   0          95s
openshift-oauth-apiserver-dbbc5cc5f-98574             2/2     Running   0          95s
openshift-route-controller-manager-5f6997b48f-s9vdc   1/1     Running   0          95s
packageserver-67c87d4d4f-kl7qh                        2/2     Running   0          93s
    Copy to Clipboard Toggle word wrap

    호스트 클러스터를 사용할 수 있으면 출력은 다음 예와 같습니다.

    출력 예

    NAMESPACE   NAME         VERSION   KUBECONFIG                PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
clusters    hosted-dual            hosted-admin-kubeconfig   Partial    True          False         The hosted control plane is available
    Copy to Clipboard Toggle word wrap

6.3.12.2. 호스트된 클러스터에 대한 NodePool 오브젝트 생성
링크 복사

NodePool 은 호스팅된 클러스터와 연결된 확장 가능한 작업자 노드 집합입니다. NodePool 머신 아키텍처는 특정 풀 내에서 일관되게 유지되며 컨트롤 플레인의 머신 아키텍처와 독립적입니다.

프로세스

  1. NodePool 오브젝트에 대한 다음 정보를 사용하여 YAML 파일을 생성하여 필요에 따라 값을 바꿉니다. 

    apiVersion: hypershift.openshift.io/v1beta1
kind: NodePool
metadata:
  creationTimestamp: null
  name: <hosted_cluster_name> \
    1 
    
  namespace: <hosted_cluster_namespace> \
    2 
    
spec:
  arch: amd64
  clusterName: <hosted_cluster_name>
  management:
    autoRepair: false \
    3 
    
    upgradeType: InPlace \
    4 
    
  nodeDrainTimeout: 0s
  platform:
    type: Agent
  release:
    image: registry.<dns.base.domain.name>:5000/openshift/release-images:4.x.y-x86_64 \
    5 
    
  replicas: 2
    6 
    
status:
  replicas: 2
    Copy to Clipboard Toggle word wrap
    1
    &lt ;hosted_cluster_name&gt;을 호스팅된 클러스터로 바꿉니다.
    2
    & lt;hosted_cluster_namespace& gt;를 호스팅된 클러스터 네임스페이스의 이름으로 바꿉니다.
    3
    노드가 제거되면 노드가 다시 생성되지 않기 때문에 autoRepair 필드가 false 로 설정됩니다.
    4
    upgradeType 은 업그레이드 중에 동일한 베어 메탈 노드가 재사용됨을 나타내는 InPlace 로 설정됩니다.
    5
    이 NodePool 에 포함된 모든 노드는 다음 OpenShift Container Platform 버전 4.x.y-x86_64 를 기반으로 합니다. < dns.base.domain.name > 값을 DNS 기본 도메인 이름으로 바꾸고 4.x.y 값을 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
    6
    replicas 값을 2 로 설정하여 호스팅된 클러스터에 두 개의 노드 풀 복제본을 생성할 수 있습니다.

  2. 다음 명령을 입력하여 NodePool 오브젝트를 생성합니다. 

    $ oc apply -f 02-nodepool.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    NAMESPACE   NAME          CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted-dual   hosted    0                               False         False        4.x.y-x86_64
    Copy to Clipboard Toggle word wrap

6.3.12.3. 호스트된 클러스터에 대한 InfraEnv 리소스 생성
링크 복사

InfraEnv 리소스는 pullSecretRef 및 sshAuthorizedKey 와 같은 필수 세부 정보를 포함하는 지원 서비스 오브젝트입니다. 이러한 세부 사항은 호스팅된 클러스터에 대해 사용자 지정된 RHCOS(Red Hat Enterprise Linux CoreOS) 부팅 이미지를 생성하는 데 사용됩니다.

둘 이상의 InfraEnv 리소스를 호스팅할 수 있으며 각각 특정 유형의 호스트를 채택할 수 있습니다. 예를 들어, RAM 용량이 큰 호스트 간에 서버 POD를 나눌 수 있습니다.

프로세스

  1. 필요에 따라 값을 교체하여 InfraEnv 리소스에 대한 다음 정보를 사용하여 YAML 파일을 생성합니다. 

    apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: <hosted_cluster_name>
  namespace: <hosted-cluster-namespace>-<hosted_cluster_name>
    1
    2 
    
spec:
  pullSecretRef:
    3 
    
    name: pull-secret
  sshAuthorizedKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDk7ICaUE+/k4zTpxLk4+xFdHi4ZuDi5qjeF52afsNkw0w/glILHhwpL5gnp5WkRuL8GwJuZ1VqLC9EKrdmegn4MrmUlq7WTsP0VFOZFBfq2XRUxo1wrRdor2z0Bbh93ytR+ZsDbbLlGngXaMa0Vbt+z74FqlcajbHTZ6zBmTpBVq5RHtDPgKITdpE1fongp7+ZXQNBlkaavaqv8bnyrP4BWahLP4iO9/xJF9lQYboYwEEDzmnKLMW1VtCE6nJzEgWCufACTbxpNS7GvKtoHT/OVzw8ArEXhZXQUS1UY8zKsX2iXwmyhw5Sj6YboA8WICs4z+TrFP89LmxXY0j6536TQFyRz1iB4WWvCbH5n6W+ABV2e8ssJB1AmEy8QYNwpJQJNpSxzoKBjI73XxvPYYC/IjPFMySwZqrSZCkJYqQ023ySkaQxWZT7in4KeMu7eS2tC+Kn4deJ7KwwUycx8n6RHMeD8Qg9flTHCv3gmab8JKZJqN3hW1D378JuvmIX4V0=
    4
    Copy to Clipboard Toggle word wrap
    1
    &lt ;hosted_cluster_name&gt;을 호스팅된 클러스터로 바꿉니다.
    2
    & lt;hosted_cluster_namespace& gt;를 호스팅된 클러스터 네임스페이스의 이름으로 바꿉니다.
    3
    pullSecretRef 는 가져오기 보안이 사용되는 InfraEnv 와 동일한 네임스페이스에서 구성 맵 참조를 나타냅니다.
    4
    sshAuthorizedKey 는 부팅 이미지에 배치된 SSH 공개 키를 나타냅니다. SSH 키를 사용하면 core 사용자로 작업자 노드에 액세스할 수 있습니다.

  2. 다음 명령을 입력하여 InfraEnv 리소스를 생성합니다. 

    $ oc apply -f 03-infraenv.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    NAMESPACE              NAME     ISO CREATED AT
clusters-hosted-dual   hosted   2023-09-11T15:14:10Z
    Copy to Clipboard Toggle word wrap

6.3.12.4. 호스트 클러스터를 위한 베어 메탈 호스트 생성
링크 복사

베어 메탈 호스트 는 Metal3 Operator가 식별할 수 있도록 물리적 및 논리 세부 정보를 포함하는 openshift-machine-api 오브젝트입니다. 이러한 세부 사항은 에이전트 라고 하는 기타 지원 서비스 오브젝트와 연결됩니다.

사전 요구 사항

  • 베어 메탈 호스트 및 대상 노드를 생성하기 전에 대상 머신이 준비되어 있어야 합니다.
  • 클러스터에서 사용할 베어 메탈 인프라에 RHCOS(Red Hat Enterprise Linux CoreOS) 컴퓨팅 머신을 설치했습니다.

프로세스

베어 메탈 호스트를 생성하려면 다음 단계를 완료합니다.

  1. 다음 정보를 사용하여 YAML 파일을 생성합니다. 베어 메탈 호스트에 입력할 세부 정보에 대한 자세한 내용은 "BMO를 사용하여 사용자 프로비저닝 클러스터에서 새 호스트 프로비저닝"을 참조하십시오.

    베어 메탈 호스트 인증 정보를 보유하는 시크릿이 하나 이상 있으므로 각 작업자 노드에 대해 두 개 이상의 오브젝트를 생성해야 합니다. 

    apiVersion: v1
kind: Secret
metadata:
  name: <hosted_cluster_name>-worker0-bmc-secret
    1 
    
  namespace: <hosted_cluster_namespace>-<hosted_cluster_name>
    2 
    
data:
  password: YWRtaW4=
    3 
    
  username: YWRtaW4=
    4 
    
type: Opaque
# ...
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: <hosted_cluster_name>-worker0
  namespace: <hosted_cluster_namespace>-<hosted_cluster_name>
    5 
    
  labels:
    infraenvs.agent-install.openshift.io: <hosted_cluster_name>
    6 
    
  annotations:
    inspect.metal3.io: disabled
    bmac.agent-install.openshift.io/hostname: <hosted_cluster_name>-worker0
    7 
    
spec:
  automatedCleaningMode: disabled
    8 
    
  bmc:
    disableCertificateVerification: true
    9 
    
    address: redfish-virtualmedia://[192.168.126.1]:9000/redfish/v1/Systems/local/<hosted_cluster_name>-worker0
    10 
    
    credentialsName: <hosted_cluster_name>-worker0-bmc-secret
    11 
    
  bootMACAddress: aa:aa:aa:aa:02:11
    12 
    
  online: true
    13
    Copy to Clipboard Toggle word wrap
    1
    &lt ;hosted_cluster_name&gt;을 호스팅된 클러스터로 바꿉니다.
    2 5
    &lt ;hosted_cluster_name&gt;을 호스팅된 클러스터로 바꿉니다. & lt;hosted_cluster_namespace& gt;를 호스팅된 클러스터 네임스페이스의 이름으로 바꿉니다.
    3
    베이스 보드 관리 컨트롤러 (BMC)의 암호를 Base64 형식으로 지정합니다.
    4
    BMC의 사용자 이름을 Base64 형식으로 지정합니다.
    6
    &lt ;hosted_cluster_name&gt;을 호스팅된 클러스터로 바꿉니다. infraenvs.agent-install.openshift.io 필드는 지원 설치 프로그램과 BareMetalHost 오브젝트 간의 링크 역할을 합니다.
    7
    &lt ;hosted_cluster_name&gt;을 호스팅된 클러스터로 바꿉니다. bmac.agent-install.openshift.io/hostname 필드는 배포 중에 채택된 노드 이름을 나타냅니다.
    8
    automatedCleaningMode 필드를 사용하면 Metal3 Operator에 의해 노드가 삭제되지 않습니다.
    9
    클라이언트에서 인증서 검증을 바이패스하려면 disableCertificateVerification 필드가 true 로 설정됩니다.
    10
    &lt ;hosted_cluster_name&gt;을 호스팅된 클러스터로 바꿉니다. address 필드는 작업자 노드의 BMC 주소를 나타냅니다.
    11
    &lt ;hosted_cluster_name&gt;을 호스팅된 클러스터로 바꿉니다. credentialsName 필드는 사용자 및 암호 인증 정보가 저장된 시크릿을 가리킵니다.
    12
    bootMACAddress 필드는 노드가 시작되는 인터페이스 MAC 주소를 나타냅니다.
    13
    online 필드는 BareMetalHost 개체가 생성된 후 노드의 상태를 정의합니다.

  2. 다음 명령을 입력하여 BareMetalHost 오브젝트를 배포합니다. 

    $ oc apply -f 04-bmh.yaml
    Copy to Clipboard Toggle word wrap

    프로세스 중에 다음 출력을 볼 수 있습니다.

    • 이 출력은 프로세스가 노드에 연결을 시도 중임을 나타냅니다.

      출력 예

      NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   registering              true             2s
clusters-hosted   hosted-worker1   registering              true             2s
clusters-hosted   hosted-worker2   registering              true             2s
      Copy to Clipboard Toggle word wrap

    • 이 출력은 노드가 시작됨을 나타냅니다.

      출력 예

      NAMESPACE         NAME             STATE          CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   provisioning              true             16s
clusters-hosted   hosted-worker1   provisioning              true             16s
clusters-hosted   hosted-worker2   provisioning              true             16s
      Copy to Clipboard Toggle word wrap

    • 이 출력은 노드가 성공적으로 시작되었음을 나타냅니다.

      출력 예

      NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   provisioned              true             67s
clusters-hosted   hosted-worker1   provisioned              true             67s
clusters-hosted   hosted-worker2   provisioned              true             67s
      Copy to Clipboard Toggle word wrap

  3. 노드가 시작된 후 다음 예와 같이 네임스페이스의 에이전트를 확인합니다.

    출력 예

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413             true       auto-assign
    Copy to Clipboard Toggle word wrap

    에이전트는 설치에 사용할 수 있는 노드를 나타냅니다. 호스트 클러스터에 노드를 할당하려면 노드 풀을 확장합니다.

6.3.12.5. 노드 풀 확장
링크 복사

베어 메탈 호스트를 생성한 후 해당 상태가 Registering 에서 Provisioning (프로비저닝)으로 변경됨. 노드는 에이전트의 LiveISO 및 에이전트 라는 기본 Pod로 시작합니다. 해당 에이전트는 OpenShift Container Platform 페이로드를 설치하기 위해 Assisted Service Operator에서 지침을 받습니다.

프로세스

  1. 노드 풀을 확장하려면 다음 명령을 입력합니다. 

    $ oc -n <hosted_cluster_namespace> scale nodepool <hosted_cluster_name> \
  --replicas 3
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    • <hosted_cluster_namespace >는 호스팅된 클러스터 네임스페이스의 이름입니다.
    • <hosted_cluster_name >은 호스팅된 클러스터의 이름입니다.

  2. 확장 프로세스가 완료되면 에이전트가 호스팅된 클러스터에 할당되어 있습니다.

    출력 예

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411   hosted    true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412   hosted    true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413   hosted    true       auto-assign
    Copy to Clipboard Toggle word wrap

  3. 또한 노드 풀 복제본이 설정되어 있습니다.

    출력 예

    NAMESPACE   NAME     CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION       UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted   hosted    3                               False         False        <4.x.y>-x86_64                                     Minimum availability requires 3 replicas, current 0 available
    Copy to Clipboard Toggle word wrap

    & lt;4.x.y >를 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.

  4. 노드가 클러스터에 참여할 때까지 기다립니다. 프로세스 중에 에이전트는 단계 및 상태에 대한 업데이트를 제공합니다.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat