Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

6.3. 非接続環境でベアメタルに Hosted Control Plane をデプロイする

Hosted Control Plane をベアメタルにプロビジョニングする場合は、Agent プラットフォームを使用します。Agent プラットフォームと multicluster engine for Kubernetes Operator が連携して、非接続デプロイメントを可能にします。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。Central Infrastructure Management の概要は、Central Infrastructure Management サービスの有効化 を参照してください。

6.3.1. ベアメタル向けの非接続環境のアーキテクチャー
リンクのコピー

以下の図は、非接続環境のアーキテクチャーの例を示しています。

Disconnected architecture diagram

  1. TLS サポートを備えたレジストリー証明書のデプロイメント、Web サーバー、DNS などのインフラストラクチャーサービスを設定して、非接続デプロイメントが確実に機能するようにします。

  2. openshift-config namespace に config map を作成します。この例では、config map の名前は registry-config になります。config map の内容はレジストリー CA 証明書です。config map の data フィールドには、次のキー/値が含まれている必要があります。

    • キー: <registry_dns_domain_name>..<port> (例: registry.hypershiftdomain.lab..5000:)ポートを指定するときは、レジストリー DNS ドメイン名の後に .. を配置するようにしてください。

    • 値: 証明書の内容

      config map の作成の詳細は、Hosted Control Plane の非接続インストールのために TLS 証明書を設定する を参照してください。

  3. images.config.openshift.io カスタムリソース (CR) 仕様を変更し、値が name: registry-config の additionalTrustedCA という名前の新規フィールドを追加します。

  4. 2 つのデータフィールドを含む config map を作成します。1 つのフィールドには RAW 形式の registries.conf ファイルが、もう 1 つのフィールドにはレジストリー CA が含まれ、ca-bundle.crt という名前が付けられます。config map は multicluster-engine namespace に属し、config map の名前は他のオブジェクトで参照されます。config map の例は、以下の設定例を参照してください。 

    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. multicluster engine Operator の namespace で、Agent と hypershift-addon アドオンの両方を有効にする multiclusterengine CR を作成します。multicluster engine Operator の namespace には、非接続デプロイメントでの動作を変更するための config map が含まれている必要があります。namespace には、multicluster-engine、assisted-service、および hypershift-addon-manager Pod も含まれます。

  6. ホステッドクラスターのデプロイに必要な次のオブジェクトを作成します。

    • シークレット: シークレットには、プルシークレット、SSH キー、etcd 暗号化キーが含まれます。
    • config map: config map には、プライベートレジストリーの CA 証明書が含まれています。
    • HostedCluster: HostedCluster リソースは、ユーザーが作成しようとしているクラスターの設定を定義します。
    • NodePool: NodePool リソースは、データプレーンに使用するマシンを参照するノードプールを識別します。
  7. ホステッドクラスターオブジェクトを作成した後、HyperShift Operator は、コントロールプレーン Pod に対応するために HostedControlPlane namespace を確立します。この namespace は、エージェント、ベアメタルホスト (BMH)、InfraEnv リソースなどのコンポーネントもホストします。その後、InfraEnv リソースを作成し、ISO の作成後に、Baseboard Management Controller (BMC) の認証情報を含む BMH とそのシークレットを作成します。
  8. openshift-machine-api namespace の Metal3 Operator は、新しい BMH を検査します。その後、Metal3 Operator は、multicluster engine Operator の namespace の AgentServiceConfig CR を通じて指定された設定済みの LiveISO および RootFS の値を使用して、BMC に接続して BMC を起動しようとします。
  9. HostedCluster リソースのワーカーノードが起動された後、エージェントコンテナーが起動されます。このエージェントは、デプロイメントを完了するためのアクションを調整する Assisted Service との接続を確立します。最初に、NodePool リソースを HostedCluster リソースのワーカーノードの数にスケーリングする必要があります。Assisted Service は残りのタスクを管理します。
  10. この時点で、デプロイメントプロセスが完了するまで待ちます。

6.3.2. 非接続環境でベアメタルに Hosted Control Plane をデプロイするための要件
リンクのコピー

オフライン環境で Hosted Control Plane を設定するには、次の前提条件を満たす必要があります。

  • CPU: 提供される CPU の数によって、同時に実行できるホステッドクラスターの数が決まります。通常、3 つのノードの場合、各ノードに 16 個の CPU を使用します。最小限の開発では、3 つのノードの場合、各ノードに 12 個の CPU を使用できます。
  • メモリー: RAM の容量は、ホストできるホステッドクラスターの数に影響します。各ノードに 48 GB の RAM を使用します。最小限の開発であれば、18 GB の RAM で十分です。

  • ストレージ: multicluster engine Operator には SSD ストレージを使用します。

    • 管理クラスター: 250 GB。
    • レジストリー: 必要なストレージは、ホストされているリリース、Operator、イメージの数によって異なります。許容可能な数値は 500 GB ですが、ホステッドクラスターをホストするディスクから分離することが望ましいです。
    • Web サーバー: 必要なストレージは、ホストされる ISO とイメージの数によって異なります。許容可能な数値は 500 GB です。

  • 実稼働環境: 実稼働環境の場合、管理クラスター、レジストリー、および Web サーバーを異なるディスク上に分離します。この例は、実稼働環境で可能な設定を示しています。

    • レジストリー: 2 TB
    • 管理クラスター: 500 GB
    • Web サーバー: 2 TB

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 サーバーに到達できる宛先を指す api.<hosted_cluster_name>.<base_domain> の DNS エントリーが存在する必要があります。

DNS エントリーは、ホステッドコントロールプレーンを実行している管理クラスター内のノードの 1 つを指すレコードのように単純なものにすることができます。エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。

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

6.3.5. 非接続環境で Hosted Control Plane のレジストリーをデプロイする
リンクのコピー

開発環境の場合は、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 ディレクトリー内にあり、次のサブディレクトリーが含まれています。

  • certs には TLS 証明書が含まれます。
  • auth には認証情報が含まれます。
  • data にはレジストリーイメージが含まれます。
  • conf にはレジストリー設定が含まれています。

6.3.6. 非接続環境で Hosted Control Plane の管理クラスターをデプロイする
リンクのコピー

OpenShift Container Platform の管理クラスターをセットアップするには、multicluster engine for Kubernetes Operator がインストールされていることを確認する必要があります。multicluster engine Operator は、複数のプロバイダーでクラスターをデプロイする場合に重要な役割を果たします。

前提条件

  • 管理クラスターとターゲットのベアメタルホスト (BMH) の Baseboard Management Controller (BMC) の間に双方向の接続がある。または、エージェントプロバイダーを通じて、自分自身でブートする方式を取ることもできます。

  • ホステッドクラスターが、管理クラスターのホスト名および *.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 クラスターに multicluster engine Operator 2.4 以降をインストールします。multicluster engine Operator は、OpenShift Container Platform OperatorHub から Operator としてインストールできます。HyperShift Operator は multicluster engine Operator に含まれています。multicluster engine Operator のインストールの詳細は、Red Hat Advanced Cluster Management ドキュメントの「multicluster engine Operator のインストールとアップグレード」を参照してください。
  2. HyperShift Operator がインストールされていることを確認します。HyperShift Operator は multicluster engine Operator とともに自動的に追加されます。手動でインストールする必要がある場合は、「local-cluster の hypershift-addon マネージドクラスターアドオンを手動で有効にする」の手順に従ってください。

次のステップ

次に、Web サーバーを設定します。

6.3.7. 非接続環境で Hosted Control Plane の Web サーバーを設定する
リンクのコピー

ホステッドクラスターとしてデプロイする OpenShift Container Platform リリースに関連付けられた Red Hat Enterprise Linux CoreOS (RHCOS) イメージをホストするには、追加の Web サーバーを設定する必要があります。

手順

Web サーバーを設定するには、以下の手順を実行します。

  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 Release ページにあります。
    2
    LIVE_ISO_URL 値は、OpenShift CI リリースページで確認できます。

ダウンロードが完了すると、コンテナーが実行され、Web サーバー上でイメージをホストします。このコンテナーは公式 HTTPd イメージのバリエーションを使用しているので、IPv6 ネットワークでの動作も可能になります。

6.3.8. 非接続環境で Hosted Control Plane のイメージミラーリングを設定する
リンクのコピー

イメージミラーリングは、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.19
      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.19
    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
    <4.x.y-build> は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。
    3
    KubeVirt プロバイダーの Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージのコンテナーディスクイメージもミラーリングする場合は、このオプションのフラグを 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

    ミラーリングプロセスが完了すると、mirror-file という名前の新しいフォルダーが作成されます。このフォルダーには、ImageDigestMirrorSet (IDMS)、ImageTagMirrorSet (ITMS)、およびホステッドクラスターに適用するカタログソースが含まれます。

  4. imagesetconfig.yaml ファイルを次のように設定して、OpenShift Container Platform のナイトリーバージョンまたは 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
    <4.x.y-build> は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。
    2
    KubeVirt プロバイダーの Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージのコンテナーディスクイメージもミラーリングする場合は、このオプションのフラグを 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. 非接続ネットワークへのインストール の手順に従って、最新の multicluster engine Operator イメージをミラーリングします。

6.3.9. 管理クラスターでのオブジェクトの適用
リンクのコピー

ミラーリングプロセスが完了したら、管理クラスターに 2 つのオブジェクトを適用する必要があります。

  • ImageContentSourcePolicy (ICSP) または ImageDigestMirrorSet (IDMS)
  • カタログソース

oc-mirror ツールを使用すると、出力アーティファクトは oc-mirror-workspace/results-XXXXXX/ という名前のフォルダーに保存されます。

ICSP または IDMS は、ノードを再起動せずに、各ノードの kubelet を再起動する MachineConfig の変更を開始します。ノードが READY としてマークされたら、新しく生成されたカタログソースを適用する必要があります。

カタログソースは、カタログイメージのダウンロードや処理を行い、そのイメージに含まれるすべての PackageManifests を取得するなど、openshift-marketplace Operator でアクションを開始します。

手順

  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 モードを使用する場合、OLM カタログに使用されるイメージストリームは、管理クラスター上の ICSP からのオーバーライド情報で自動的に修正されません。

    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 の更新を取得するために内部ミラーを更新するときに、アノテーションの値を更新する必要があります。

次のステップ

Hosted Control Plane の非接続インストールのために multicluster engine Operator をデプロイする の手順を実行して、multicluster engine Operator をデプロイします。

6.3.10. AgentServiceConfig リソースのデプロイ
リンクのコピー

AgentServiceConfig カスタムリソースは、multicluster engine Operator の一部である Assisted Service アドオンの重要なコンポーネントです。このリソースはベアメタルクラスターをデプロイします。アドオンが有効な場合に、AgentServiceConfig リソースをデプロイしてアドオンを設定します。

AgentServiceConfig リソースの設定に加えて、multicluster engine Operator が非接続環境で適切に機能するように、追加の config map を含める必要があります。

手順

  1. 次の config map を追加してカスタムレジストリーを設定します。これには、デプロイメントをカスタマイズするための非接続環境の情報が含まれています。 

    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 ベースドメイン名に置き換えます。

    オブジェクトには、以下の 2 つのフィールドが含まれます。

    • カスタム CA: このフィールドには、デプロイメントのさまざまなプロセスに読み込まれる認証局 (CA) が含まれます。
    • レジストリー: Registries.conf フィールドには、元のソースレジストリーではなくミラーレジストリーから使用する必要があるイメージと namespace に関する情報が含まれています。

  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 が動作をカスタマイズするために使用する config map 名を参照します。
    2
    spec.mirrorRegistryRef.name アノテーションは、Assisted Service Operator が使用する非接続のレジストリー情報を含む config map を指します。この config map は、デプロイメントプロセス中にこれらのリソースを追加します。
    3
    spec.osImages フィールドには、この Operator がデプロイできるさまざまなバージョンが含まれています。このフィールドは必須です。この例では、RootFS ファイルと LiveISO ファイルがすでにダウンロードされていることを前提としています。
    4
    デプロイする OpenShift Container Platform リリースごとに cpuArchitecture サブセクションを追加します。この例では、4.14 および 4.15 の cpuArchitecture サブセクションが含まれています。
    5
    rootFSUrl フィールド と url フィールドで、dns.base.domain.name を DNS ベースドメイン名に置き換えます。

  3. すべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに適用し、これらのオブジェクトをデプロイします。起動するには、以下のコマンドを実行します。 

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

    このコマンドは 2 つの 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 は、デプロイするクラスターごとにカスタマイズされた、Red Hat Enterprise Linux CoreOS (RHCOS) 起動イメージテンプレートを作成します。
    2
    assisted-service は Operator を参照します。

次のステップ

TLS 証明書を設定します。

6.3.11. Hosted Control Plane の非接続インストールのために TLS 証明書を設定する
リンクのコピー

非接続デプロイメントで適切な機能を確保するには、管理クラスターとホステッドクラスターのワーカーノードでレジストリー CA 証明書を設定する必要があります。

6.3.11.1. 管理クラスターにレジストリー CA を追加する
リンクのコピー

管理クラスターにレジストリー CA を追加するには、次の手順を実行します。

手順

  1. 次の例のような config map を作成します。 

    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
    config map の名前を指定します。
    2
    config map の namespace を指定します。
    3
    data フィールドには、レジストリー名とレジストリー証明書の内容を指定します。<port> は、レジストリーサーバーが実行されているポート (例: 5000) に置き換えます。
    4
    config map 内のデータは、| - などの他の方法ではなく、必ず | だけを使用して定義します。他の方法を使用すると、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 エントリーは、次の手順で作成する config map です。

  2. HostedCluster オブジェクトの作成先と同じ namespace で、user-ca-bundle config map を作成します。config map は次の例のようになります。 

    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 オブジェクトの作成先の namespace を指定します。

6.3.12. ベアメタルでのホステッドクラスターの作成
リンクのコピー

ホステッドクラスターは、コントロールプレーンと API エンドポイントが管理クラスターでホストされている OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。

6.3.12.1. ホステッドクラスターオブジェクトのデプロイ
リンクのコピー

通常、HyperShift Operator は HostedControlPlane namespace を作成します。ただし、この場合は、HyperShift Operator が HostedCluster オブジェクトの調整を開始する前に、すべてのオブジェクトを含める必要があります。その後、Operator がリコンシリエーションプロセスを開始すると、所定の場所にあるすべてのオブジェクトを見つけることができます。

手順

  1. namespace に関する次の情報を含めて、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
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。
    2
    <hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。

  2. config map とシークレットに関する次の情報を含む YAML ファイルを作成し、HostedCluster デプロイメントに追加します。 

    ---
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
    <hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
    2 4 6
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。

  3. RBAC ロールを含む YAML ファイルを作成し、Assisted Service エージェントが Hosted Control Plane と同じ HostedControlPlane namespace に配置し、引き続きクラスター API で管理されるようにします。 

    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
    <hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
    2
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。

  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
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。
    2 8
    <hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
    3
    imageContentSources セクションには、ホステッドクラスター内のユーザーワークロードのミラー参照が含まれます。
    4 5 6 10
    <dns.base.domain.name> は、DNS ベースドメイン名に置き換えます。
    11
    <4.x.y> は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。

  5. OpenShift Container Platform リリースの HyperShift Operator リリースを指すアノテーションを HostedCluster オブジェクトに追加します。

    1. 次のコマンドを入力して、イメージペイロードを取得します。 

      $ oc adm release info \
  registry.<dns.base.domain.name>:5000/openshift-release-dev/ocp-release:<4.x.y>-x86_64 \
  | grep hypershift
      Copy to Clipboard Toggle word wrap

      この場合の <dns.base.domain.name> は DNS ベースドメイン名で、<4.x.y> は使用するサポート対象の OpenShift Container Platform バージョンです。

      出力例

      hypershift        sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
      Copy to Clipboard Toggle word wrap

    2. OpenShift Container Platform Images namespace を使用して、次のコマンドを入力してダイジェストを確認します。 

      podman pull registry.<dns.base.domain.name>:5000/openshift-release-dev/ocp-v4.0-art-dev@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
      Copy to Clipboard Toggle word wrap

      dns.base.domain.name は DNS ベースドメイン名です。

      出力例

      podman pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
Trying to pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8...
Getting image source signatures
Copying blob d8190195889e skipped: already exists
Copying blob c71d2589fba7 skipped: already exists
Copying blob d4dc6e74b6ce skipped: already exists
Copying blob 97da74cc6d8f skipped: already exists
Copying blob b70007a560c9 done
Copying config 3a62961e6e done
Writing manifest to image destination
Storing signatures
3a62961e6ed6edab46d5ec8429ff1f41d6bb68de51271f037c6cb8941a007fde
      Copy to Clipboard Toggle word wrap

      HostedCluster オブジェクトに設定するリリースイメージでは、タグではなくダイジェストを使用する必要があります (例: quay.io/openshift-release-dev/ocp-release@sha256:e3ba11bd1e5e8ea5a0b36a75791c90f29afb0fdbe4125be4e48f69c76a5c47a0)。

  6. YAML ファイルで定義したすべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに対して適用して作成します。起動するには、以下のコマンドを実行します。 

    $ 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
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。
    2
    <hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
    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 つのノードプールレプリカを作成できます。

  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 などの重要な詳細を含む Assisted Service オブジェクトです。これらの詳細は、ホステッドクラスター用にカスタマイズされた Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージを作成するために使用されます。

複数の InfraEnv リソースをホストすることができます。各リソースは特定のタイプのホストを採用できます。たとえば、大きな RAM 容量を持つホスト間でサーバーファームを分割することができます。

手順

  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
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。
    2
    <hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
    3
    pullSecretRef は、プルシークレットが使用される InfraEnv と同じ namespace 内の config map を参照します。
    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. ホステッドクラスターのベアメタルホスト作成
リンクのコピー

ベアメタルホスト は、物理的な詳細と論理詳細を含む openshift-machine-api オブジェクトで、Metal3 Operator によって識別できるようになっています。これらの詳細は、agents と呼ばれる他の Assisted Service オブジェクトに関連付けられています。

前提条件

  • ベアメタルホストと宛先ノードを作成する前に、宛先マシンを準備しておく必要があります。
  • クラスターで使用するために、ベアメタルインフラストラクチャーに Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートマシンをインストールした。

手順

ベアメタルホストを作成するには、以下の手順を実行します。

  1. 次の情報を含む YAML ファイルを作成します。ベアメタルホストに関して入力する詳細情報については、「BMO を使用して、ユーザーがプロビジョニングしたクラスターで新しいホストをプロビジョニングする」を参照してください。

    ベアメタルホストの認証情報を保持するシークレットが 1 つ以上あるため、ワーカーノードごとに少なくとも 2 つのオブジェクトを作成する必要があります。 

    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
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。
    2 5
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。<hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
    3
    Baseboard Management Controller (BMC) のパスワードを Base64 形式で指定します。
    4
    BMC のユーザー名を Base64 形式で指定します。
    6
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。infraenvs.agent-install.openshift.io フィールドは、Assisted Installer と BareMetalHost オブジェクト間のリンクとして機能します。
    7
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。bmac.agent-install.openshift.io/hostname フィールドは、デプロイ時に採用されるノード名を表します。
    8
    automatedCleaningMode フィールドは、Metal3 Operator によってノードが消去されるのを防ぎます。
    9
    disableCertificateVerification フィールドを true に設定して、クライアントからの証明書検証を回避します。
    10
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。address フィールドは、ワーカーノードの BMC アドレスを示します。
    11
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。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 のエージェントに注目してください。

    出力例

    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、Provisioned に変わります。ノードは、エージェントの LiveISO と、agent という名前のデフォルトの Pod で始まります。このエージェントは、Assisted Service Operator から OpenShift Container Platform ペイロードをインストールする指示を受け取ります。

手順

  1. ノードプールをスケールアップするには、次のコマンドを入力します。 

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

    ここでは、以下のようになります。

    • <hosted_cluster_namespace> は、ホステッドクラスターの 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

    <4.x.y> は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。

  4. ノードがクラスターに参加するまで待ちます。プロセス中に、エージェントはステージとステータスに関する最新情報を提供します。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat