./subscription/channel.yaml ファイルを更新して、sto lostron ではなくフォークしたリポジトリーの GitHub 名にアクセスするように spec: pathname を変更します。この手順では、ハブクラスターによるリリースイメージの取得先を指定します。更新後の内容は以下の例のようになります。

spec:
  type: GitHub
  pathname: https://github.com/<forked_content>/acm-hive-openshift-releases.git

forked_content はフォークしたリポジトリーのへのパスに置き換えます。

acm-hive-openshift-releases リポジトリーをクローンした後に stable リリースイメージの一覧を同期するには、以下のコマンドを入力して stable イメージを更新します。

make subscribe-stable

注記: この make コマンドは、Linux または MacOS のオペレーティングシステムを使用している場合のみ実行できます。

このコマンドを実行後に、利用可能な安定版のリリースイメージの一覧が、現在利用可能なイメージに約 1 分ほどで更新されます。

デフォルトでは、安定版のイメージのみが一覧表示されます。Fast リリースイメージを同期して表示するには、以下のコマンドを実行します。

make subscribe-fast

注記: この make コマンドは、Linux または MacOS のオペレーティングシステムを使用している場合のみ実行できます。

このコマンドを実行後に、利用可能な fast リリースイメージの一覧が、現在利用可能なイメージに約 1 分ほどで更新されます。

デフォルトではRed Hat Advanced Cluster Management は ClusterImageSets を複数事前に読み込みます。以下のコマンドを使用して、利用可能ものを表示し、デフォルトの設定を削除します。

oc get clusterImageSets
oc delete clusterImageSet <clusterImageSet_NAME>

注記: disableUpdateClusterImageSets の値を true に設定して、インストーラー管理の ClusterImageSets の自動更新をまだ無効にしていない場合は、削除するイメージが自動的に再作成されます。

clusterImageSets コマンドを作成します。

oc create -f <clusterImageSet_FILE>

追加するリソース毎にこのコマンドを実行すると、利用可能なリリースイメージの一覧が使用できるようになります。

Clusters ページで Provider connections タブを選択します。

既存のプロバイダー接続が表示されます。

一覧からプロバイダー接続の namespace を選択します。

ヒント: 便宜上およびセキュリティー上、プロバイダー接続のホスト専用の namespace を作成します。

Clusters ページで Provider connections タブを選択します。

既存のプロバイダー接続が表示されます。

一覧からプロバイダー接続の namespace を選択します。

ヒント: 便宜上およびセキュリティー上、プロバイダー接続のホスト専用の namespace を作成できます。

Client ID を追加します。この値は、以下のコマンドを使用してサービスプリンシパルを作成すると、 appId プロパティーとして設定されます。

az ad sp create-for-rbac --role Contributor --name <service_principal>

service_principal は、お使いのサービスプリンシパル名に置き換えます。

Client Secret を追加します。この値は、以下のコマンドを使用してサービスプリンシパルを作成すると、 password プロパティーとして設定されます。

az ad sp create-for-rbac --role Contributor --name <service_principal>

service_principal は、お使いのサービスプリンシパル名に置き換えます。

Subscription ID を追加します。以下のコマンドの出力では、この値は、id プロパティーになります。

az account show

Tenant ID を追加します。以下のコマンドの出力では、この値は、tenantId プロパティーになります。

az account show

Clusters ページで Provider connections タブを選択します。

既存のプロバイダー接続が表示されます。

一覧からプロバイダー接続の namespace を選択します。

Google Cloud Platform service account JSON key を追加します。適切なパーミッションでキーを作成するには、以下の手順を実行します。

Clusters ページで Provider connections タブを選択します。

既存のプロバイダー接続が表示されます。

一覧からプロバイダー接続の namespace を選択します。

ヒント: 便宜上およびセキュリティー上、プロバイダー接続のホスト専用の namespace を作成します。

VMware vCenter ルート CA 証明書を追加します。

root 以外のユーザー (user-name) を作成し、そのユーザーに sudo 権限に割り当てて、以下のコマンドを実行します。

useradd <user-name>
passwd <password>
echo "<user-name> ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/<user-name>
chmod 0440 /etc/sudoers.d/<user-name>

次のコマンドを入力して、新しいユーザーの SSH キーを作成します。

su - <user-name> -c "ssh-keygen -t rsa -f /home/<user-name>/.ssh/id_rsa -N ''"

プロビジョナーノードに、新しいユーザーとしてログインします。

su - <user-name>
[user-name@provisioner ~]$

Red Hat Subscription Manager を使用して、以下のコマンドを入力してプロビジョナーノードを登録します。

sudo subscription-manager register --username=<user-name> --password=<password> --auto-attach
sudo subscription-manager repos --enable=rhel-8-for-x86_64-appstream-rpms --enable=rhel-8-for-x86_64-baseos-rpms

Red Hat Subscription Manager の詳細は、Red Hat OpenShift Container Platform ドキュメントの「Subscription Manager の使用および設定」を参照してください。

以下のコマンドを実行して、必要なパッケージをインストールします。

sudo dnf install -y libvirt qemu-kvm mkisofs python3-devel jq ipmitool

ユーザーを変更して、新たに作成したユーザーに libvirt グループを追加します。

sudo usermod --append --groups libvirt <user-name>

以下のコマンドを入力して、firewalld を再起動し、http サービスを有効にします。

sudo systemctl start firewalld
sudo firewall-cmd --zone=public --add-service=http --permanent
sudo firewall-cmd --add-port=5000/tcp --zone=libvirt  --permanent
sudo firewall-cmd --add-port=5000/tcp --zone=public   --permanent
sudo firewall-cmd --reload

以下のコマンドを入力して、libvirtd サービスを起動し、有効にします。

sudo systemctl start libvirtd
sudo systemctl enable libvirtd --now

次のコマンドを入力して、デフォルトのストレージプールを作成し、起動します。

sudo virsh pool-define-as --name default --type dir --target /var/lib/libvirt/images
sudo virsh pool-start default
sudo virsh pool-autostart default

ネットワーク設定の以下の例を参照してください。

ssh を使用してプロビジョナーノードに再接続します (必要な場合)。

# ssh <user-name>@provisioner.<cluster-name>.<domain>

以下のコマンドを実行して、接続ブリッジが正しく作成されていることを確認します。

nmcli con show

検索結果は、以下のような内容になります。

以下の手順で pull-secret.txt ファイルを作成します。

vim pull-secret.txt

Clusters ページで Provider connections タブを選択します。

既存のプロバイダー接続が表示されます。

一覧からプロバイダー接続の namespace を選択します。

ヒント: 便宜上およびセキュリティー上、プロバイダー接続のホスト専用の namespace を作成します。

libvirt URI を追加します。libvirt URI は、ブートストラップノード向けに作成したプロビジョニングノードを追加してください。libvirt URI は以下の例のようになります。

<qemu+ssh>:://<user-name>@<provision-host.com>/system

オフラインインストールのみ: Configuration for disconnected installation サブセクションのフィールドに必要な情報を入力します。

Create a cluster を選択します。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合には、「 ハブクラスターへのターゲットのマネージドクラスターのインポート」の手順を参照してください。

クラスターの名前を入力します。この名前はクラスターのホスト名で使用されます。

ヒント: コンソールに情報を入力する時に yaml コンテンツの更新内容を表示するには、YAML を ON に切り替えるように設定します。

クラスターの ノードプール を設定します。

ノードプールは、クラスターに使用されるノードの場所とサイズを定義します。

Region は、ノードの地理的な配置場所を指定します。リージョンが近くにある場合にはパフォーマンスの速度が向上しますが、リージョンの距離が離れると、より分散されます。

Create をクリックします。作成およびインポートプロセスを完了すると、クラスターの詳細を表示できます。

注記: クラスターのインポートには、クラスターの詳細で提示された kubectl コマンドを実行する必要はありません。クラスターを作成すると、Red Hat Advanced Cluster Management で管理されるように自動的に設定されます。

アクセスするクラスターの Actions > Launch to cluster を選択します。

ヒント: ログイン認証情報がすでにわかっている場合は、アクセスしたいクラスターの Actions > Launch to cluster を選択することで、クラスターにアクセスできます。

Create a cluster を選択します。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合には、「 ハブクラスターへのターゲットのマネージドクラスターのインポート」の手順を参照してください。

クラスターの名前を入力します。この名前はクラスターのホスト名で使用されます。

ヒント: コンソールに情報を入力する時に yaml コンテンツの更新内容を表示するには、YAML を ON に切り替えるように設定します。

クラスターの ノードプール を設定します。

ノードプールは、クラスターに使用されるノードの場所とサイズを定義します。

Region は、ノードの地理的な配置場所を指定します。リージョンが近くにある場合にはパフォーマンスの速度が向上しますが、リージョンの距離が離れると、より分散されます。

必要なクラスターネットワークオプションを設定します。

Azure アカウントに設定したベー DNS 情報を入力します。選択したプロバイダー接続にベース DNS が紐付けされている場合は、その値がこのフィールドに設定されます。値を上書きすると変更できます。詳細は、Configuring a custom domain name for an Azure cloud service を参照してください。この名前はクラスターのホスト名で使用されます。

Create をクリックします。作成およびインポートプロセスを完了すると、クラスターの詳細を表示できます。

注記: クラスターのインポートには、クラスターの詳細で提示された kubectl コマンドを実行する必要はありません。クラスターを作成すると、Red Hat Advanced Cluster Management for Kubernetes で管理されるように自動的に設定されます。

アクセスするクラスターの Actions > Launch to cluster を選択します。

ヒント: ログイン認証情報がすでにわかっている場合は、アクセスしたいクラスターの Actions > Launch to cluster を選択することで、クラスターにアクセスできます。

Create a cluster を選択します。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合には、「 ハブクラスターへのターゲットのマネージドクラスターのインポート」の手順を参照してください。

クラスターの名前を入力します。この名前はクラスターのホスト名で使用されます。GCP クラスターの命名に適用される制限がいくつかあります。この制限には、名前を goog で開始しないことや、名前に google に類似する文字および数字のグループが含まれないことなどがあります。制限の完全な一覧は、「Bucket naming guidelines」を参照してください。

ヒント: コンソールに情報を入力する時に yaml コンテンツの更新内容を表示するには、YAML を ON に切り替えるように設定します。

クラスターの ノードプール を設定します。

ノードプールは、クラスターに使用されるノードの場所とサイズを定義します。

Region は、ノードの地理的な配置場所を指定します。リージョンが近くにある場合にはパフォーマンスの速度が向上しますが、リージョンの距離が離れると、より分散されます。

必要なクラスターネットワークオプションを設定します。

Google Cloud Platform アカウントに設定したベース DNS 情報を入力します。選択したプロバイダー接続にベースドメインが紐付けされている場合は、その値がこのフィールドに設定されます。値を上書きすると変更できます。詳細は、Setting up a custom domainを参照してください。この名前はクラスターのホスト名で使用されます。

アクセスするクラスターの Actions > Launch to cluster を選択します。

ヒント: ログイン認証情報がすでにわかっている場合は、アクセスしたいクラスターの Actions > Launch to cluster を選択することで、クラスターにアクセスできます。

Create a cluster を選択します。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合には、「 ハブクラスターへのターゲットのマネージドクラスターのインポート」の手順を参照してください。

クラスターの名前を入力します。この名前はクラスターのホスト名で使用されます。

注記: 値は、プロバイダー接続の要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。

ヒント: コンソールに情報を入力する時に yaml コンテンツの更新内容を表示するには、YAML を ON に切り替えるように設定します。

クラスターの ノードプール を設定します。

ノードプールは、クラスターに使用されるノードの場所とサイズを定義します。

ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、ワーカープール 1 つに所属することも、複数のワーカープールに分散させることもできます。

クラスターのネットワークオプションを設定します。これらのオプションについては以下のリストで紹介します。

Create をクリックします。作成およびインポートプロセスを完了すると、クラスターの詳細を表示できます。

注記: クラスターを作成すると、Red Hat Advanced Cluster Management で管理されるように自動的に設定されます。クラスターのインポートには、クラスターの詳細で提示された kubectl コマンドを実行する必要はありません。

ログイン認証情報が分からない場合:

アクセスするクラスターの Actions > Launch to cluster を選択します。

ヒント: ログイン認証情報がすでにわかっている場合は、アクセスしたいクラスターの Actions > Launch to cluster を選択することで、クラスターにアクセスできます。

Create a cluster を選択します。

注記: この手順では、クラスターを作成します。既存のクラスターをインポートする場合には、「 ハブクラスターへのターゲットのマネージドクラスターのインポート」の手順を参照してください。

クラスターの名前を入力します。ベアメタルクラスターの場合には、名前を任意で指定できません。この名前は、クラスター URL に関連付けられています。使用するクラスター名が DNS およびネットワーク設定と一致していることを確認します。

ヒント: コンソールに情報を入力する時に yaml コンテンツの更新内容を表示するには、YAML を ON に切り替えるように設定します。

プロバイダー接続に関連付けられたホスト一覧から、お使いのホストを選択します。ハイパーバイザーと同じブリッジネットワークにあるアセットを 3 つ以上選択します。

ホストの一覧は、既存のベアメタルアセットからコンパイルされます。ベアメタルアセットを作成していない場合は、作成プロセスを続行する前に作成またはインポートを行うことができます。Disable certificate verification を選択して要件を無視することができます。

クラスターネットワークオプションを設定します。

Create をクリックします。作成およびインポートプロセスを完了すると、クラスターの詳細を表示できます。

注記: クラスターのインポートには、クラスターの詳細で提示された kubectl コマンドを実行する必要はありません。クラスターを作成すると、Red Hat Advanced Cluster Management for Kubernetes で管理されるように自動的に設定されます。

アクセスするクラスターの Actions > Launch to cluster を選択します。

ヒント: ログイン認証情報がすでにわかっている場合は、アクセスしたいクラスターの Actions > Launch to cluster を選択することで、クラスターにアクセスできます。

オプション: ラベル を追加します。

注記: Red Hat OpenShift Dedicated クラスターをインポートし、vendor=OpenShiftDedicated のラベルを追加してベンダーが指定されないようにする場合、または vendor=auto-detect のラベルを追加する場合には managed-by=platform ラベルがクラスターに自動的に追加されます。この追加ラベルを使用して、クラスターを Red Hat OpenShift Dedicated クラスターとして識別し、Red Hat OpenShift Dedicated クラスターをグループとして取得できます。

オプション: oc get managedcluster コマンドを実行する際に、テーブルに表示される URL を設定して、クラスターの詳細ページにある Cluster API アドレス を設定します。

Import an existing cluster ウィンドウで Copy command を選択し、生成されたコマンドおよびトークンをクリップボードにコピーします。

重要: コマンドには、インポートした各クラスターにコピーされるプルシークレット情報が含まれます。インポートしたクラスターにアクセスできるユーザーであれば誰でも、プルシークレット情報を表示することもできます。https://cloud.redhat.com/ で 2 つ目のプルシークレットを作成することを検討するか、サービスアカウントを作成して個人の認証情報を保護してください。プルシークレットの詳細は、「イメージプルシークレットの使用」または「サービスアカウントの概要および作成」を参照してください。

Red Hat OpenShift Dedicated 環境のみ対象 : 以下の手順を実行します。

Red OpenShift Dedicated 環境に含まれていないクラスターのインポート: 以下の手順を実行します。

ハブクラスター にログインします。以下のコマンドを実行します。

oc login

ハブクラスターで以下のコマンドを実行して namespace を作成します。注記: <cluster_name> で定義したクラスター名は、.yaml ファイルおよびコマンドでクラスターの namespace としても使用します。

oc new-project ${CLUSTER_NAME}
oc label namespace ${CLUSTER_NAME} cluster.open-cluster-management.io/managedCluster=${CLUSTER_NAME}

以下の YAML 例のように、ManagedCluster の例を編集します。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: <cluster_name>
spec:
  hubAcceptsClient: true

以下のコマンドを使用して、YAML ファイルを適用します。

oc apply -f managed-cluster.yaml

klusterlet のアドオン設定ファイルを作成します。以下の YAML の例を入力します。

apiVersion: agent.open-cluster-management.io/v1
kind: KlusterletAddonConfig
metadata:
  name: <cluster_name>
  namespace: <cluster_name>
spec:
  clusterName: <cluster_name>
  clusterNamespace: <cluster_name>
  applicationManager:
    enabled: true
  certPolicyController:
    enabled: true
  clusterLabels:
    cloud: auto-detect
    vendor: auto-detect
  iamPolicyController:
    enabled: true
  policyController:
    enabled: true
  searchCollector:
    enabled: true
  version: 2.2.0

YAML を適用します。以下のコマンドを実行します。

oc apply -f klusterlet-addon-config.yaml

注記: Red Hat OpenShift Dedicated クラスターをインポートし、vendor=OpenShiftDedicated のラベルを追加してベンダーが指定されないようにする場合、または vendor=auto-detect のラベルを追加する場合には managed-by=platform ラベルがクラスターに自動的に追加されます。この追加ラベルを使用して、クラスターを Red Hat OpenShift Dedicated クラスターとして識別し、Red Hat OpenShift Dedicated クラスターをグループとして取得できます。

マネージドクラスターのインポートコントローラーによって生成された klusterlet-crd.yaml を取得します。

以下のコマンドを実行します。

oc get secret ${CLUSTER_NAME}-import -n ${CLUSTER_NAME} -o jsonpath={.data.crds\\.yaml} | base64 --decode > klusterlet-crd.yaml

マネージドクラスターのインポートコントローラーによって生成された import.yaml を取得します。以下のコマンドを実行します。

oc get secret ${CLUSTER_NAME}-import -n ${CLUSTER_NAME} -o jsonpath={.data.import\\.yaml} | base64 --decode > import.yaml

手順 1 で生成した klusterlet-crd.yaml を適用します。以下のコマンドを実行します。

kubectl apply -f klusterlet-crd.yaml

手順 2 で生成した import.yaml ファイルを適用します。以下のコマンドを実行します。

kubectl apply -f import.yaml

ターゲットのマネージドクラスターで Pod のステータスを検証します。以下のコマンドを実行します。

kubectl get pod -n open-cluster-management-agent

インポートしたクラスターのステータス (JOINED および AVAILABLE) を確認します。ハブ クラスターから以下のコマンドを実行します。

kubectl get managedcluster ${CLUSTER_NAME}

アドオンは、マネージドクラスターが AVAILABLE になってからインストールされます。ターゲットのマネージドクラスターでアドオンの Pod ステータスを確認します。以下のコマンドを実行します。

kubectl get pod -n open-cluster-management-agent-addon

以下のコマンドを入力してリソースを編集します。

kubectl edit klusterletaddonconfigs.agent.open-cluster-management.io <cluster-name> -n <cluster-name>

Google Cloud Platform で受信および送信のファイアウォールルールを作成し、IPsec IKE (デフォルトでは 500/UDP) および NAT トラバーサルポート (デフォルトでは 4500/UDP) を開き、Submariner 通信を有効にします。

$ gcloud compute firewall-rules create <name> --network=<network-name> --allow=udp:<ipsec-port> --direction=IN
$ gcloud compute firewall-rules create <rule-name> --network=<network-name> --allow=udp:<ipsec-port>  --direction=OUT

rule-name を、実際のルール名に置き換えます。

network-name を、Google Cloud Platform クラスターネットワーク名に置き換えます。

ipsec-port を、実際の IPsec ポートに置き換えます。

Google Cloud Platform で受信および送信のファイアウォールルールを作成し、4800/UDP ポートを開き、ワーカーノードおよびマスターノードから Submariner Gateway ノードに Pod トラフィックをカプセル化します。

$ gcloud compute firewall-rules create <name> --network=<network-name> --allow=udp:4800 --direction=IN
$ gcloud compute firewall-rules create <name> --network=<network-name> --allow=udp:4800 --direction=OUT

name を、実際のルール名に置き換えます。

network-name を、Google Cloud Platform クラスターネットワーク名に置き換えます。

Google Cloud Platform で受信および送信のファイアウォールルールを作成し、8080/TCP ポートを開き、Submariner Gateway ノードからメトリクスサービスをエクスポートします。

$ gcloud compute firewall-rules create <name> --network=<network-name> --allow=tcp:8080 --direction=IN
$ gcloud compute firewall-rules create <name> --network=<network-name> --allow=tcp:8080 --direction=OUT

name を、実際のルール名に置き換えます。

network-name を、Google Cloud Platform クラスターネットワーク名に置き換えます。

Microsoft Azure 環境で受信および送信のファイアウォールルールを作成し、IP セキュリティー IKE (デフォルトでは 500/UDP) および NAT トラバーサルポート (デフォルトでは 4500/UDP) を開き、Submariner 通信を有効にします。

# create inbound nat rule
$ az network lb inbound-nat-rule create --lb-name <lb-name> \
--resource-group <res-group> \
--name <name> \
--protocol Udp --frontend-port <ipsec-port> \
--backend-port <ipsec-port> \
--frontend-ip-name <frontend-ip-name>

# add your vm network interface to the created inbound nat rule
$ az network nic ip-config inbound-nat-rule add \
--lb-name <lb-name> --resource-group <res-group> \
--inbound-nat-rule <nat-name> \
--nic-name <nic-name> --ip-config-name <pipConfig>

lb-name を、ロードバランサー名に置き換えます。

res-group を、リソースグループ名に置き換えます。

nat-name を、ロードバランシングの受信 NAT ルール名に置き換えます。

ipsec-port を、実際の IPsec ポートに置き換えます。

pipConfig を、クラスターのフロントエンド IP 設定名に置き換えます。

nic-name を、実際のネットワークインターフェースカード (NIC) 名に置き換えます。

Submariner ゲートウェイメトリクス要求を転送する負荷分散の受信 NAT ルールを 1 つ作成します。

# create inbound nat rule
$ az network lb inbound-nat-rule create --lb-name <lb-name> \
--resource-group <res-group> \
--name <name> \
--protocol Tcp --frontend-port 8080 --backend-port 8080 \
--frontend-ip-name <frontend-ip-name>

# add your vm network interface to the created inbound nat rule
$ az network nic ip-config inbound-nat-rule add \
--lb-name <lb-name> --resource-group <res-group> \
--inbound-nat-rule <nat-name> \
--nic-name <nic-name> --ip-config-name <pipConfig>

lb-name を、ロードバランサー名に置き換えます。

res-group を、リソースグループ名に置き換えます。

nat-name を、ロードバランシングの受信 NAT ルール名に置き換えます。

pipConfig を、クラスターのフロントエンド IP 設定名に置き換えます。

nic-name を、実際のネットワークインターフェースカード (NIC) 名に置き換えます。

Azure でネットワークセキュリティーグループ {NSG) セキュリティールールを作成し、Submariner の IPsec IKE (デフォルトでは 500/UDP) および NAT トラバーサルポート (デフォルトでは 4500/UDP) を開きます。

$ az network nsg rule create --resource-group <res-group> \
--nsg-name <nsg-name> --priority <priority> \
--name <name> --direction Inbound --access Allow \
--protocol Udp --destination-port-ranges <ipsec-port>

$ az network nsg rule create --resource-group <res-group> \
--nsg-name <nsg-name> --priority <priority> \
--name <name> --direction Outbound --access Allow \
--protocol Udp --destination-port-ranges <ipsec-port>

res-group を、リソースグループ名に置き換えます。

nsg-name を、実際の NSG 名に置き換えます。

priority を、ルールの優先度に置き換えます。

name を、実際のルール名に置き換えます。

ipsec-port を、実際の IPsec ポートに置き換えます。

NSG ルールを作成し、4800/UDP ポートを開き、ワーカーノードおよびマスターノードから Submariner Gateway ノードに Pod トラフィックをカプセル化します。

$ az network nsg rule create --resource-group <res-group> \
--nsg-name <nsg-name> --priority <priority> \
--name <name> --direction Inbound --access Allow \
--protocol Udp --destination-port-ranges 4800 \

$ az network nsg rule create --resource-group <res-group> \
--nsg-name <nsg-name> --priority <priority> \
--name <name> --direction Outbound --access Allow \
--protocol Udp --destination-port-ranges 4800

res-group を、リソースグループ名に置き換えます。

nsg-name を、実際の NSG 名に置き換えます。

priority を、ルールの優先度に置き換えます。

name を、実際のルール名に置き換えます。

NSG ルールを作成して 8080/TCP ポートを開き、Submariner ゲートウェイノードからメトリクスサービスをエクスポートします。

$ az network nsg rule create --resource-group <res-group> \
--nsg-name <nsg-name> --priority <priority> \
--name <name> --direction Inbound --access Allow \
--protocol Tcp --destination-port-ranges 8080 \

$ az network nsg rule create --resource-group <res-group> \
--nsg-name <nsg-name> --priority <priority> \
--name <name> --direction Outbound --access Allow \
--protocol Udp --destination-port-ranges 8080

res-group を、リソースグループ名に置き換えます。

nsg-name を、実際の NSG 名に置き換えます。

priority を、ルールの優先度に置き換えます。

name を、実際のルール名に置き換えます。

クラスター管理者のパーミッションでハブクラスターにログインします。

Red Hat Advanced Cluster Management for Kubernetes で作成された AWS クラスターの場合は、以下の SubmarinerConfig コンテンツで submarinerconfig.yaml という名前のファイルを作成します。

apiVersion: submarineraddon.open-cluster-management.io/v1alpha1
kind: SubmarinerConfig
metadata:
  name: submariner
  namespace: <your-cluster-namespace>
spec:
  credentialsSecret:
    name: <your-cluster-name>-aws-creds
  subscriptionConfig:
    channel: alpha
    startingCSV: submariner.v0.8.1

OpenShift Container Platform で作成され、Red Hat Advanced Cluster Management にインポートされている AWS クラスターの場合は、aws-cloud-credentials を作成します。

以下のコマンドを入力して、ハブクラスターのマネージドクラスターに SubmarinerConfig リソースを適用します。

oc apply -f submarinerconfig.yaml

ハブクラスターに ManagedClusterSet を作成します。

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: ManagedClusterSet
metadata:
  name: my-clusterset

以下のコマンドを入力して、マネージドクラスターを ManagedClusterSet に追加します。

oc label managedclusters <managedcluster-name> "cluster.open-cluster-management.io/clusterset=<ManagedClusterSet-name>" --overwrite

以下のコマンドを実行して、Red Hat Advanced Cluster Management が Submariner:app-name を自動的にデプロイできるようにします。

oc label managedclusters <managedcluster-name> "cluster.open-cluster-management.io/submariner-agent=true" --overwrite

以下の例のような内容を含むスクリプトファイルを作成します。

UPSTREAM_REGISTRY=quay.io
PRODUCT_REPO=openshift-release-dev
RELEASE_NAME=ocp-release
OCP_RELEASE=4.5.2-x86_64
LOCAL_REGISTRY=$(hostname):5000
LOCAL_SECRET_JSON=/path/to/pull/secret

oc adm -a ${LOCAL_SECRET_JSON} release mirror \
--from=${UPSTREAM_REGISTRY}/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE} \
--to=${LOCAL_REGISTRY}/ocp4 \
--to-release-image=${LOCAL_REGISTRY}/ocp4/release:${OCP_RELEASE}

path-to-pull-secret は、OpenShift Container Platform のプルシークレットへのパスに置き換えます。

Operator のインストールが完了するまで待ちます。

ヒント: OpenShift Container Platform コマンドラインで oc get pods コマンドを入力して、インストールのステータスを確認できます。Operator の状態が running であることを確認します。

以下のコマンドを入力して、グラフデータ Git リポジトリーのクローンを作成します。

git clone https://github.com/openshift/cincinnati-graph-data

グラフデータの init の情報が含まれるファイルを作成します。このサンプル Dockerfile は、cincinnati-operator GitHub リポジトリーにあります。ファイルの内容は以下の例のようになります。

FROM registry.access.redhat.com/ubi8/ubi:8.1

RUN curl -L -o cincinnati-graph-data.tar.gz https://github.com/openshift/cincinnati-graph-data/archive/master.tar.gz

RUN mkdir -p /var/lib/cincinnati/graph-data/

CMD exec /bin/bash -c "tar xvzf cincinnati-graph-data.tar.gz -C /var/lib/
cincinnati/graph-data/ --strip-components=1"

この例では、以下のように設定されています。

以下のコマンドを実行して、グラフデータの init container をビルドします。

podman build -f <path_to_Dockerfile> -t ${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container:latest
podman push ${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container:latest --authfile=/path/to/pull_secret.json

path_to_Dockerfile は、直前の手順で作成したファイルへのパスに置き換えます。

${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container は、ローカルグラフデータ init container へのパスに置き換えます。

/path/to/pull_secret は、プルシークレットへのパスに置き換えます。

注記: podman がインストールされていない場合には、コマンドの podman を docker に置き換えることもできます。

image.config.openshift.io にある OpenShift Container Platform 外部レジストリー API を検索します。これは、外部レジストリーの CA 証明書の保存先です。

詳細は、OpenShift Container Platform ドキュメントの 「イメージレジストリーアクセス用の追加のトラストストアの設定」を参照してください。

CA 証明書をキーの cincinnati-registry に追加します。OpenShift Update Service はこの設定を使用して、証明書を特定します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: trusted-ca
data:
  cincinnati-registry: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

image.config.openshift.io API の cluster リソースを編集して、additionalTrustedCA フィールドを作成した ConfigMap 名に設定します。

oc patch image.config.openshift.io cluster -p '{"spec":{"additionalTrustedCA":{"name":"trusted-ca"}}}' --type merge

trusted-ca は、新しい ConfigMap へのパスに置き換えます。

デフォルトの Operator の namespace (openshift-cincinnati) を使用しない場合には、お使いの OpenShift Update Service インスタンスの namespace を作成します。

OpenShift Update Service インスタンスからコンテンツを貼り付けます。YAML ファイルは以下のマニフェストのようになります。

apiVersion: cincinnati.openshift.io/v1beta1
kind: Cincinnati
metadata:
  name: openshift-update-service-instance
  namespace: openshift-cincinnati
spec:
  registry: <registry_host_name>:<port>
  replicas: 1
  repository: ${LOCAL_REGISTRY}/ocp4/release
  graphDataImage: '<host_name>:<port>/cincinnati-graph-data-container'

spec.registry の値は、イメージの非接続環境にあるローカルレジストリーへのパスに置き換えます。

spec.graphDataImage の値は、グラフデータ init container へのパスに置き換えます。ヒント: これは、podman push コマンドを使用して、グラフデータ init container をプッシュする時に使用した値と同じです。

以下の YAML コンテンツをウィンドウに貼り付け、カスタムポリシーを作成します。

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-pod
  namespace: default
  annotations:
    policy.open-cluster-management.io/standards:
    policy.open-cluster-management.io/categories:
    policy.open-cluster-management.io/controls:
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-pod-sample-nginx-pod
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: v1
                kind: Pod
                metadata:
                  name: sample-nginx-pod
                  namespace: default
                status:
                  phase: Running
          remediationAction: inform
          severity: low
  remediationAction: enforce
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-pod
  namespace: default
placementRef:
  name: placement-policy-pod
  kind: PlacementRule
  apiGroup: apps.open-cluster-management.io
subjects:
- name: policy-pod
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-pod
  namespace: default
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      []  # selects all clusters if not specified

テンプレートの objectDefinition セクション内のコンテンツは、ImageContentSourcePolicy の設定を追加する以下の内容に置き換えます。

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: ImageContentSourcePolicy
spec:
  repositoryDigestMirrors:
  - mirrors:
    - <path-to-local-mirror>
    source: registry.redhat.io

以下の YAML コンテンツをウィンドウに貼り付け、カスタムポリシーを作成します。

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-pod
  namespace: default
  annotations:
    policy.open-cluster-management.io/standards:
    policy.open-cluster-management.io/categories:
    policy.open-cluster-management.io/controls:
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-pod-sample-nginx-pod
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: v1
                kind: Pod
                metadata:
                  name: sample-nginx-pod
                  namespace: default
                status:
                  phase: Running
          remediationAction: inform
          severity: low
  remediationAction: enforce
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-pod
  namespace: default
placementRef:
  name: placement-policy-pod
  kind: PlacementRule
  apiGroup: apps.open-cluster-management.io
subjects:
- name: policy-pod
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-pod
  namespace: default
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      []  # selects all clusters if not specified

以下の内容をポリシーに追加します。

apiVersion: config.openshift.io/vi
kind: OperatorHub
metadata:
 name: cluster
spec:
 disableAllDefaultSources: true

以下の内容を追加します。

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: my-operator-catalog
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: <registry_host_name>:<port>/olm/redhat-operators:v1
  displayName: My Operator Catalog
  publisher: grpc

spec.image の値は、ローカルの制約付きのカタログソースイメージへのパスに置き換えます。

マネージドクラスターから、以下のコマンドを入力して ClusterVersion アップストリームパラメーターがデフォルトの OpenShift Update Service オペランドであることを確認します。

oc get clusterversion -o yaml

返される内容は以下のようになります。

apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: ClusterVersion
[..]
  spec:
    channel: stable-4.4
    upstream: https://api.openshift.com/api/upgrades_info/v1/graph

ハブクラスターから、oc get routes というコマンドを入力して OpenShift Update Service オペランドへのルート URL を特定します。

ヒント: 今後の手順で使用できるようにこの値をメモします。

以下の YAML コンテンツをウィンドウに貼り付け、カスタムポリシーを作成します。

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-pod
  namespace: default
  annotations:
    policy.open-cluster-management.io/standards:
    policy.open-cluster-management.io/categories:
    policy.open-cluster-management.io/controls:
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-pod-sample-nginx-pod
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: v1
                kind: Pod
                metadata:
                  name: sample-nginx-pod
                  namespace: default
                status:
                  phase: Running
          remediationAction: inform
          severity: low
  remediationAction: enforce
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-pod
  namespace: default
placementRef:
  name: placement-policy-pod
  kind: PlacementRule
  apiGroup: apps.open-cluster-management.io
subjects:
- name: policy-pod
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-pod
  namespace: default
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      []  # selects all clusters if not specified

policy セクションの policy.spec に以下の内容を追加します。

apiVersion: config.openshift.io/v1
  kind: ClusterVersion
  metadata:
    name: version
  spec:
    channel: stable-4.4
    upstream: https://example-cincinnati-policy-engine-uri/api/upgrades_info/v1/graph

spec.upstream の値は、ハブクラスター OpenShift Update Service オペランドへのパスに置き換えます。

ヒント: 以下の手順を実行すると、オペランドへのパスを確認できます。

マネージドクラスター CLI で、ClusterVersion のアップストリームパラメーターがローカルハブクラスター OpenShift Update Service URL に更新されていることを確認します。これには以下のコマンドを入力します。

oc get clusterversion -o yaml

結果は、以下の内容のようになります。

apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: ClusterVersion
[..]
  spec:
    channel: stable-4.4
    upstream: https://<hub-cincinnati-uri>/api/upgrades_info/v1/graph

オプションのアップグレードパスが利用可能であることを確認します。

注記: 現行バージョンがローカルのイメージリポジトリーにミラーリングされていない場合には、利用可能なアップグレードバージョンは表示されません。