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

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
# ...
# ...
  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 の作成後に、ベースボード管理コントローラー (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"

    <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

6.3.4. Hosted Control Plane の非接続インストールのためにハイパーバイザーを設定する

以下の情報は、仮想マシン環境にのみ適用されます。

手順

  1. 仮想管理クラスターをデプロイするために、次のコマンドを入力して必要なパッケージにアクセスします。 

    $ sudo dnf install dnsmasq radvd vim golang podman bind-utils net-tools httpd-tools tree htop strace tmux -y

  2. 次のコマンドを入力して、Podman サービスを有効にして起動します。 

    $ systemctl enable --now podman

  3. kcli を使用して管理クラスターおよびその他の仮想コンポーネントをデプロイするために、次のコマンドを入力してハイパーバイザーをインストールおよび設定します。 

    $ sudo yum -y install libvirt libvirt-daemon-driver-qemu qemu-kvm
    $ sudo usermod -aG qemu,libvirt $(id -un)
    $ sudo newgrp libvirt
    $ sudo systemctl enable --now libvirtd
    $ sudo dnf -y copr enable karmab/kcli
    $ sudo dnf -y install kcli
    $ sudo kcli create pool -p /var/lib/libvirt/images default
    $ kcli create host kvm -H 127.0.0.1 local
    $ sudo setfacl -m u:$(id -un):rwx /var/lib/libvirt/images
    $ kcli create network  -c 192.168.122.0/24 default

  4. ネットワークマネージャーのディスパッチャーを有効にして、仮想マシンが必要なドメイン、ルート、およびレジストリーを解決できるようにします。ネットワークマネージャーのディスパッチャーを有効にするには、/etc/NetworkManager/dispatcher.d/ ディレクトリーに、次の内容を含む forcedns という名前のスクリプトを作成します。 

    #!/bin/bash

export IP="192.168.126.1" 1
export BASE_RESOLV_CONF="/run/NetworkManager/resolv.conf"

if ! [[ `grep -q "$IP" /etc/resolv.conf` ]]; then
export TMP_FILE=$(mktemp /etc/forcedns_resolv.conf.XXXXXX)
cp $BASE_RESOLV_CONF $TMP_FILE
chmod --reference=$BASE_RESOLV_CONF $TMP_FILE
sed -i -e "s/dns.base.domain.name//" -e "s/search /& dns.base.domain.name /" -e "0,/nameserver/s/nameserver/& $IP\n&/" $TMP_FILE 2
mv $TMP_FILE /etc/resolv.conf
fi
echo "ok"
    1
    OpenShift Container Platform 管理クラスターをホストするハイパーバイザーインターフェイスの IP アドレスを指すように IP 変数を変更します。
    2
    dns.base.domain.name は DNS ベースドメイン名に置き換えます。

  5. ファイルを作成したら、次のコマンドを入力してパーミッションを追加します。 

    $ chmod 755 /etc/NetworkManager/dispatcher.d/forcedns
  6. スクリプトを実行し、出力が ok を返すことを確認します。

  7. 仮想マシンのベースボード管理コントローラー (BMC) をシミュレートするように ksushy を設定します。次のコマンドを入力します。 

    $ sudo dnf install python3-pyOpenSSL.noarch python3-cherrypy -y
    $ kcli create sushy-service --ssl --ipv6 --port 9000
    $ sudo systemctl daemon-reload
    $ systemctl enable --now ksushy

  8. 次のコマンドを入力して、サービスが正しく機能しているかどうかをテストします。 

    $ systemctl status ksushy

  9. 開発環境で作業している場合は、環境内の各種仮想ネットワークを介したさまざまなタイプの接続を許可するようにハイパーバイザーシステムを設定します。

    注記

    実稼働環境で作業している場合は、セキュアな環境を確保するために、firewalld サービスの適切なルールを確立し、SELinux ポリシーを設定する必要があります。

    • SELinux の場合は、次のコマンドを入力します。 

      $ sed -i s/^SELINUX=.*$/SELINUX=permissive/ /etc/selinux/config; setenforce 0

    • firewalld の場合は、次のコマンドを入力します。 

      $ systemctl disable --now firewalld

    • libvirtd の場合は、以下のコマンドを入力します。 

      $ systemctl restart libvirtd
      $ systemctl enable --now libvirtd

6.3.5. ベアメタルでの DNS 設定

ホステッドクラスターの API サーバーは、NodePort サービスとして公開されます。API サーバーに到達できる宛先を指す api.<hosted_cluster_name>.<base_domain> の DNS エントリーが存在する必要があります。

DNS エントリーは、Hosted Control Plane を実行しているマネージドクラスター内のノードの 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

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

デュアルスタックネットワークの非接続環境で 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]

6.3.6. 非接続環境で 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
    1
    PULL_SECRET の場所は、設定に適した場所に置き換えます。

  2. スクリプトファイル registry.sh という名前を指定して保存します。スクリプトを実行すると、以下の情報がプルされます。

    • ハイパーバイザーのホスト名に基づくレジストリー名
    • 必要な認証情報およびユーザーアクセスの詳細

  3. 次のように実行フラグを追加して、パーミッションを調整します。 

    $ chmod u+x ${HOME}/registry.sh

  4. パラメーターを指定せずにスクリプトを実行するには、以下のコマンドを入力します。 

    $ ${HOME}/registry.sh

    このスクリプトはサーバーを起動します。このスクリプトは、管理目的で systemd サービスを使用します。

  5. スクリプトを管理する必要がある場合は、以下のコマンドを使用できます。 

    $ systemctl status
    $ systemctl start
    $ systemctl stop

レジストリーのルートフォルダーは /opt/registry ディレクトリー内にあり、次のサブディレクトリーが含まれています。

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

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

OpenShift Container Platform 管理クラスターを設定するには、dev-scripts を使用できます。または、仮想マシンをベースにしている場合は、kcli ツールを使用できます。以下は、kcli ツールに固有のものです。

手順

  1. ハイパーバイザーで使用するために適切なネットワークの準備が完了していることを確認します。ネットワークは、管理クラスターとホステッドクラスターの両方をホストします。以下の kcli コマンドを入力します。 

    $ kcli create network -c 192.168.126.0/24 -P dhcp=false -P dns=false -d 2620:52:0:1306::0/64 --domain dns.base.domain.name --nodhcp dual

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

    • -c は、ネットワークの CIDR を指定します。
    • -p dhcp=false は、設定した dnsmasq によって処理される DHCP を無効にするようにネットワークを設定します。
    • -P dns=false は、 DNS を無効にするようにネットワークを設定します。これも、設定した dnsmasq によって処理されます。
    • --domain は、検索するドメインを設定します。
    • dns.base.domain.name は DNS ベースドメイン名です。
    • dual は、作成するネットワークの名前です。

  2. ネットワークを作成したら、以下の出力を確認します。 

    [root@hypershiftbm ~]# kcli list network
Listing Networks...
+---------+--------+---------------------+-------+------------------+------+
| Network |  Type  |         Cidr        |  Dhcp |      Domain      | Mode |
+---------+--------+---------------------+-------+------------------+------+
| default | routed |   192.168.122.0/24  |  True |     default      | nat  |
| ipv4    | routed | 2620:52:0:1306::/64 | False | dns.base.domain.name | nat  |
| ipv4    | routed |   192.168.125.0/24  | False | dns.base.domain.name | nat  |
| ipv6    | routed | 2620:52:0:1305::/64 | False | dns.base.domain.name | nat  |
+---------+--------+---------------------+-------+------------------+------+
    [root@hypershiftbm ~]# kcli info network ipv6
Providing information about network ipv6...
cidr: 2620:52:0:1306::/64
dhcp: false
domain: dns.base.domain.name
mode: nat
plan: kvirt
type: routed

  3. OpenShift Container Platform 管理クラスターをデプロイできるように、プルシークレットと kcli プランファイルが配置されていることを確認します。

    1. プルシークレットが kcli プランと同じフォルダーにあり、プルシークレットファイルの名前が openshift_pull.json であることを確認します。

    2. OpenShift Container Platform 定義を含む kcli プランを mgmt-compact-hub-dual.yaml ファイルに追加します。ご使用の環境に合わせてファイルの内容を更新してください。 

      plan: hub-dual
force: true
version: stable
tag: "4.x.y-x86_64" 1
cluster: "hub-dual"
dualstack: true
domain: dns.base.domain.name
api_ip: 192.168.126.10
ingress_ip: 192.168.126.11
service_networks:
- 172.30.0.0/16
- fd02::/112
cluster_networks:
- 10.132.0.0/14
- fd01::/48
disconnected_url: registry.dns.base.domain.name:5000
disconnected_update: true
disconnected_user: dummy
disconnected_password: dummy
disconnected_operators_version: v4.14
disconnected_operators:
- name: metallb-operator
- name: lvms-operator
  channels:
  - name: stable-4.14
disconnected_extra_images:
- quay.io/user-name/trbsht:latest
- quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3
- registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
dualstack: true
disk_size: 200
extra_disks: [200]
memory: 48000
numcpus: 16
ctlplanes: 3
workers: 0
manifests: extra-manifests
metal3: true
network: dual
users_dev: developer
users_devpassword: developer
users_admin: admin
users_adminpassword: admin
metallb_pool: dual-virtual-network
metallb_ranges:
- 192.168.126.150-192.168.126.190
metallb_autoassign: true
apps:
- users
- lvms-operator
- metallb-operator
vmrules:
- hub-bootstrap:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:10:07
- hub-ctlplane-0:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:10:01
- hub-ctlplane-1:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:10:02
- hub-ctlplane-2:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:10:03
      1
      4.x.y を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

  4. 管理クラスターをプロビジョニングするには、以下のコマンドを入力します。 

    $ kcli create cluster openshift --pf mgmt-compact-hub-dual.yaml

次のステップ

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

6.3.8. 非接続環境で 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}"

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

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

6.3.9. 非接続環境で 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/v1alpha2
kind: ImageSetConfiguration
storageConfig:
  registry:
    imageURL: registry.<dns.base.domain.name>:5000/openshift/release/metadata:latest 1
mirror:
  platform:
    channels:
    - name: candidate-4.17
      minVersion: 4.x.y-build  2
      maxVersion: 4.x.y-build 3
      type: ocp
    kubeVirtContainer: true 4
    graph: true
  additionalImages:
  - name: quay.io/karmab/origin-keepalived-ipfailover:latest
  - name: quay.io/karmab/kubectl:latest
  - name: quay.io/karmab/haproxy:latest
  - name: quay.io/karmab/mdns-publisher:latest
  - name: quay.io/karmab/origin-coredns:latest
  - name: quay.io/karmab/curl:latest
  - name: quay.io/karmab/kcli:latest
  - name: quay.io/user-name/trbsht:latest
  - name: quay.io/user-name/hypershift:BMSelfManage-v4.17
  - name: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.17
    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 5
    1
    <dns.base.domain.name> は、DNS ベースドメイン名に置き換えます。
    2 3
    4.x.y-build は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。
    4
    KubeVirt プロバイダーの Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージのコンテナーディスクイメージもミラーリングする場合は、このオプションのフラグを true に設定します。このフラグは oc-mirror v2 でのみ使用できます。
    5
    KubeVirt プロバイダーを使用するデプロイメントの場合は、この行を含めます。

  3. 次のコマンドを入力して、ミラーリングプロセスを開始します。 

    $ oc-mirror --v2 --config imagesetconfig.yaml docker://${REGISTRY}

    ミラーリングプロセスが完了すると、oc-mirror-workspace/results-XXXXXX/ という名前の新しいフォルダーが作成されます。このフォルダーには、ホステッドクラスターに適用する IDMS とカタログソースが含まれています。

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

  5. 次のコマンドを入力して、ファイルに変更を適用します。 

    $ oc-mirror --v2 --config imagesetconfig.yaml docker://${REGISTRY}
  6. 非接続ネットワークへのインストール の手順に従って、最新の multicluster engine Operator イメージをミラーリングします。

6.3.10. 管理クラスターでのオブジェクトの適用

ミラーリングプロセスが完了したら、管理クラスターに 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

  2. アーティファクトを適用するには、次の手順を実行します。

    1. 次のコマンドを入力して、ICSP または IDMS アーティファクトを作成します。 

      $ oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml

    2. ノードの準備が完了するまで待ってから、次のコマンドを入力します。 

      $ oc apply -f catalogSource-XXXXXXXX-index.yaml

  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.11. Hosted Control Plane の非接続インストールのために multicluster engine Operator をデプロイする

multicluster engine for Kubernetes Operator は、複数のプロバイダーでクラスターをデプロイする場合に重要な役割を果たします。multicluster engine Operator がインストールされていない場合は、次のドキュメントを参照して、インストールの前提条件と手順を確認してください。

6.3.11.1. 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
    # ...
    # ...
    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
    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

    このコマンドは 2 つの Pod をトリガーします。

    出力例

    assisted-image-service-0                               1/1     Running   2             11d 1
assisted-service-668b49548-9m7xw                       2/2     Running   5             11d 2

    1
    assisted-image-service Pod は、デプロイするクラスターごとにカスタマイズされた、Red Hat Enterprise Linux CoreOS (RHCOS) 起動イメージテンプレートを作成します。
    2
    assisted-service は Operator を参照します。

次のステップ

Hosted Control Plane の非接続インストールのために TLS 証明書を設定する の手順を完了して、TLS 証明書を設定します。

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

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

6.3.12.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-----
    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

    このパッチの結果、コントロールプレーンノードがプライベートレジストリーからイメージを取得できるようになります。また、HyperShift Operator がホステッドクラスターのデプロイメント用の OpenShift Container Platform ペイロードを抽出できるようになります。

    オブジェクトにパッチを適用するプロセスが完了するまでに数分かかる場合があります。

6.3.12.2. ホステッドクラスターのワーカーノードにレジストリー CA を追加する

ホステッドクラスターのデータプレーンワーカーがプライベートレジストリーからイメージを取得できるようにするために、ワーカーノードにレジストリー CA を追加する必要があります。

手順

  1. hc.spec.additionalTrustBundle ファイルに次の仕様を追加します。 

    spec:
  additionalTrustBundle:
    - name: user-ca-bundle 1
    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
    1
    HostedCluster オブジェクトの作成先の namespace を指定します。

6.3.13. ベアメタルでのホステッドクラスターの作成

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

6.3.13.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: {}
    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
    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:
  - '*'
    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
    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

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

      出力例

      hypershift        sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8

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

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

      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

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

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

    $ oc apply -f 01-4.14-hosted_cluster-nodeport.yaml

    出力例

    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

    ホステッドクラスターが利用可能な場合、出力は次の例のようになります。

    出力例

    NAMESPACE   NAME         VERSION   KUBECONFIG                PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
clusters    hosted-dual            hosted-admin-kubeconfig   Partial    True          False         The hosted control plane is available

6.3.13.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
    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

    出力例

    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

6.3.13.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
    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

    出力例

    NAMESPACE              NAME     ISO CREATED AT
clusters-hosted-dual   hosted   2023-09-11T15:14:10Z

6.3.13.4. ホステッドクラスター用のワーカーノードの作成

ベアメタルプラットフォームで作業している場合、BareMetalHost の詳細が正しく設定されていることを確認するためにワーカーノードを作成することが重要です。

仮想マシンを使用している場合は、次の手順を実行して、Metal3 Operator が使用する空のワーカーノードを作成できます。これには、kcli ツールを使用します。

手順

  1. ワーカーノードを作成するのが初めてではない場合は、まず以前の設定を削除する必要があります。これには、次のコマンドを入力してプランを削除します。 

    $ kcli delete plan <hosted_cluster_name> 1
    1
    <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。
    1. プランを削除するかどうかを確認するプロンプトが表示されたら、y と入力します。
    2. プランが削除されたことを示すメッセージが表示されることを確認します。

  2. 次のコマンドを入力して仮想マシンを作成します。

    1. 次のコマンドを入力して、1 つ目の仮想マシンを作成します。 

      $ kcli create vm \
  -P start=False \1
  -P uefi_legacy=true \2
  -P plan=<hosted_cluster_name> \3
  -P memory=8192 -P numcpus=16 \4
  -P disks=[200,200] \5
  -P nets=["{\"name\": \"<network>\", \"mac\": \"aa:aa:aa:aa:11:01\"}"] \6
  -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa1101 \
  -P name=<hosted_cluster_name>-worker0 7
      1
      仮想マシン (VM) の作成時に自動的に起動しないようにする場合は、start=False を含めます。
      2
      uefi_legacy=true を追加して、以前の UEFI 実装との互換性を確保するために UEFI レガシーブートを使用することを指定します。
      3
      <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。plan=<hosted_cluster_name> ステートメントは、マシンのグループをクラスターとして識別するプラン名を示します。
      4
      memory=8192 および numcpus=16 パラメーターを追加して、RAM や CPU などの仮想マシンのリソースを指定します。
      5
      disks=[200,200] を追加して、仮想マシンに 2 つのシンプロビジョニングディスクを作成することを指定します。
      6
      nets=[{"name": "<network>", "mac": "aa:aa:aa:aa:02:13"}] を追加して、接続先のネットワーク名、ネットワークの種類 (ipv4、ipv6、または dual)、プライマリーインターフェイスの MAC アドレスなど、ネットワークの詳細を指定します。
      7
      <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。

    2. 次のコマンドを入力して、2 つ目の仮想マシンを作成します。 

      $ kcli create vm \
  -P start=False \1
  -P uefi_legacy=true \2
  -P plan=<hosted_cluster_name> \3
  -P memory=8192 -P numcpus=16 \4
  -P disks=[200,200] \5
  -P nets=["{\"name\": \"<network>\", \"mac\": \"aa:aa:aa:aa:11:02\"}"] \6
  -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa1102
  -P name=<hosted_cluster_name>-worker1 7
      1
      仮想マシン (VM) の作成時に自動的に起動しないようにする場合は、start=False を含めます。
      2
      uefi_legacy=true を追加して、以前の UEFI 実装との互換性を確保するために UEFI レガシーブートを使用することを指定します。
      3
      <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。plan=<hosted_cluster_name> ステートメントは、マシンのグループをクラスターとして識別するプラン名を示します。
      4
      memory=8192 および numcpus=16 パラメーターを追加して、RAM や CPU などの仮想マシンのリソースを指定します。
      5
      disks=[200,200] を追加して、仮想マシンに 2 つのシンプロビジョニングディスクを作成することを指定します。
      6
      nets=[{"name": "<network>", "mac": "aa:aa:aa:aa:02:13"}] を追加して、接続先のネットワーク名、ネットワークの種類 (ipv4、ipv6、または dual)、プライマリーインターフェイスの MAC アドレスなど、ネットワークの詳細を指定します。
      7
      <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。

    3. 次のコマンドを入力して、3 つ目の仮想マシンを作成します。 

      $ kcli create vm \
  -P start=False \1
  -P uefi_legacy=true \2
  -P plan=<hosted_cluster_name> \3
  -P memory=8192 -P numcpus=16 \4
  -P disks=[200,200] \5
  -P nets=["{\"name\": \"<network>\", \"mac\": \"aa:aa:aa:aa:11:03\"}"] \6
  -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa1103
  -P name=<hosted_cluster_name>-worker2 7
      1
      仮想マシン (VM) の作成時に自動的に起動しないようにする場合は、start=False を含めます。
      2
      uefi_legacy=true を追加して、以前の UEFI 実装との互換性を確保するために UEFI レガシーブートを使用することを指定します。
      3
      <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。plan=<hosted_cluster_name> ステートメントは、マシンのグループをクラスターとして識別するプラン名を示します。
      4
      memory=8192 および numcpus=16 パラメーターを追加して、RAM や CPU などの仮想マシンのリソースを指定します。
      5
      disks=[200,200] を追加して、仮想マシンに 2 つのシンプロビジョニングディスクを作成することを指定します。
      6
      nets=[{"name": "<network>", "mac": "aa:aa:aa:aa:02:13"}] を追加して、接続先のネットワーク名、ネットワークの種類 (ipv4、ipv6、または dual)、プライマリーインターフェイスの MAC アドレスなど、ネットワークの詳細を指定します。
      7
      <hosted_cluster_name> は、ホステッドクラスターの名前に置き換えます。

  3. restart ksushy コマンドを入力して ksushy ツールを再起動し、追加した仮想マシンがツールによって検出されるようにします。 

    $ systemctl restart ksushy

    出力例

    +---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
|         Name        | Status |         Ip        |                       Source                       |     Plan    | Profile |
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
|    hosted-worker0   |  down  |                   |                                                    | hosted-dual |  kvirt  |
|    hosted-worker1   |  down  |                   |                                                    | hosted-dual |  kvirt  |
|    hosted-worker2   |  down  |                   |                                                    | hosted-dual |  kvirt  |
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+

6.3.13.5. ホステッドクラスターのベアメタルホスト作成

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

前提条件

ベアメタルホストと宛先ノードを作成する前に、宛先マシンを準備しておく必要があります。

手順

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

  1. 次の情報を使用して YAML ファイルを作成します。

    ベアメタルホストの認証情報を保持するシークレットが 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
    1
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。
    2 5
    <hosted_cluster_name> は、ホステッドクラスターに置き換えます。<hosted_cluster_namespace> は、ホステッドクラスターの namespace の名前に置き換えます。
    3
    ベースボード管理コントローラー (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

    プロセス中に、次の出力が確認できます。

    • この出力は、プロセスがノードに到達しようとしていることを示しています。

      出力例

      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

    • この出力は、ノードが起動していることを示しています。

      出力例

      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

    • この出力は、ノードが正常に起動したことを示しています。

      出力例

      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

  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

    エージェントは、インストールに使用できるノードを表します。ホステッドクラスターにノードを割り当てるには、ノードプールをスケールアップします。

6.3.13.6. ノードプールのスケールアップ

ベアメタルホストを作成すると、そのステータスが 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

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

    • <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

  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

    4.x.y を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

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

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.