検索

クラスター

download PDF
Red Hat Advanced Cluster Management for Kubernetes 2.8

クラスター管理

概要

クラスターライフサイクルとマルチクラスターエンジンにより、クラスターを作成および管理できます。クラスターライフサイクルは、マルチクラスターエンジン Operator から入手できます。

第1章 マルチクラスターエンジン Operator を使用したクラスターライフサイクルについて

マルチクラスターエンジン Operator は、OpenShift Container Platform および Red Hat Advanced Cluster Management ハブクラスターにクラスター管理機能を提供するクラスターライフサイクル Operator です。ハブクラスターから、クラスターを作成および管理し、作成したクラスターを破棄できます。クラスターを休止、再開、およびデタッチすることもできます。クラスターライフサイクル機能の詳細は、以下のドキュメントを参照してください。

情報:

クラスターライフサイクル管理アーキテクチャーのコンポーネントは、クラスターライフサイクルアーキテクチャー に含まれています。

1.1. リリースノート

現在のリリースについて学びます。

非推奨: マルチクラスターエンジン Operator の 2.2 以前のバージョンはサポートされなくなりました。ドキュメントはそのまま利用できますが、エラータやその他の更新は提供されません。

現在サポートされているリリースのいずれか、製品ドキュメントで問題が発生した場合は、Red Hat サポート にアクセスして、トラブルシューティングを行ったり、ナレッジベースの記事を表示したり、サポートチームに連絡したり、ケースを開いたりすることができます。認証情報でログインする必要があります。

Red Hat Customer Portal FAQ で、カスタマーポータルのドキュメントの詳細を確認することもできます。

1.1.1. マルチクラスターエンジン Operator を使用したクラスターライフサイクルの新機能

重要: 一部の機能およびコンポーネントは テクノロジープレビュー として指定され、リリースされます。

詳細は、本リリースの新機能を参照してください。

1.1.1.1. インストール

OpenShift Container Platform または Red Hat Advanced Cluster Management をインストールした場合、マルチクラスターエンジン Operator は自動的に受信されます。マルチクラスターエンジン Operator のインストールにのみ新機能が存在する場合は、このセクションで表示できます。

Operator Lifecycle Manager の OperatorCondition リソースを使用して、マルチクラスターエンジンの operator のアップグレード手順を強制できるようになりました。これにより、リリースをスキップしようとするエラーを防止できます。

1.1.1.2. Cluster lifecycle

マルチクラスターエンジン Operator とクラスターライフサイクルに関連する新機能について説明します。

  • コンソールの Credentials から Amazon Simple Storage Service (S3) シークレットを作成できるようになりました。Creating an S3 secret を参照してください。
  • iPXE を使用してインフラストラクチャー環境にホストを追加できるようになりました。
  • 時間を節約するために、クラスター自動化テンプレートの一部である失敗した Ansible ポストフックのみを実行できるようになりました。詳細は 失敗した Ansible ジョブの再実行 を参照してください。
  • klusterlet の実行場所をより詳細に制御するために、nodeSelector および tolerations の値を指定することで、マネージドクラスター klusterlet を特定のノードで実行するように設定できるようになりました。詳細は オプション: 特定のノードで実行するための klusterlet の設定 を参照してください。
  • 便宜上、プルシークレットと SSH 公開キーをホストインベントリー認証情報に追加し、オンプレミス環境でクラスターを作成するときにクラスターを選択することで、これらのフィールドに自動的に値を入力できます。詳細は、Creating a credential for an on-premises environment を参照してください。
  • ClusterCurator リソースを使用して、すべてのジョブに使用する Ansible インベントリーを指定します。これは、マルチクラスターエンジン Operator ユーザーもコンソールで利用できます。詳細は、すべてのジョブに使用する Ansible インベントリーの指定 を参照してください。
  • Central Infrastructure Management (CIM) 機能を使用して、Nutanix 上にベアメタル OpenShift Container Platform クラスターを作成できます。コマンドラインを使用したクラスターの作成 を参照してください。
  • OpenShift Container Platform バージョン 4.13 以降を使用している場合は、GitOps を使用してワーカーノードを削除できるようになりました。
1.1.1.3. Hosted Control Plane

1.1.2. クラスターライフサイクルの既知の問題

マルチクラスターエンジン Operator を使用したクラスターライフサイクルの既知の問題を確認します。以下のリストには、本リリースの既知の問題、または以前のリリースから持ち越された既知の問題が記載されています。OpenShift Container Platform クラスターについては、OpenShift Container Platform リリースノート を参照してください。

1.1.2.1. クラスター管理

クラスターライフサイクルの既知の問題と制限は、マルチクラスターエンジン Operator のドキュメントを使用したクラスターライフサイクルの一部です。

1.1.2.1.1. アドオンの削除時にマネージドクラスターで必要な VolSync CSV の手動削除

ハブクラスターから VolSync ManagedClusterAddOn を削除すると、マネージドクラスターの VolSync Operator サブスクリプションが削除されますが、クラスターサービスバージョン (CSV) は削除されません。マネージドクラスターから CSV を削除するには、VolSync を削除する各マネージドクラスターで以下のコマンドを実行します。

oc delete csv -n openshift-operators volsync-product.v0.6.0

別のバージョンの VolSync がインストールされている場合は、v0.6.0 をインストール済みバージョンに置き換えます。

1.1.2.1.2. マネージドクラスターセットを削除してもそのラベルが自動的に削除されない

ManagedClusterSet を削除した後に、クラスターセットに関連付ける各マネージドクラスターに追加されるラベルは自動的に削除されません。削除したマネージドクラスターセットに含まれる各マネージドクラスターからラベルを手動で削除します。ラベルは cluster.open-cluster-management.io/clusterset:<ManagedClusterSet Name> のようになります。

1.1.2.1.3. ClusterClaim エラー

ClusterPool に対して Hive ClusterClaim を作成し、ClusterClaimspec ライフタイムフィールドを無効な golang 時間値に手動で設定すると、製品は不正な要求だけでなく、すべての ClusterClaims を満たし、調整を停止します。

このエラーが発生すると、clusterclaim-controller Pod ログに以下の内容が表示されます。これは、プール名と、無効な有効期限が含まれた特定の例です。

E0203 07:10:38.266841       1 reflector.go:138] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:224: Failed to watch *v1.ClusterClaim: failed to list *v1.ClusterClaim: v1.ClusterClaimList.Items: []v1.ClusterClaim: v1.ClusterClaim.v1.ClusterClaim.Spec: v1.ClusterClaimSpec.Lifetime: unmarshalerDecoder: time: unknown unit "w" in duration "1w", error found in #10 byte of ...|time":"1w"}},{"apiVe|..., bigger context ...|clusterPoolName":"policy-aas-hubs","lifetime":"1w"}},{"apiVersion":"hive.openshift.io/v1","kind":"Cl|...

無効な要求を削除できます。

不正な要求が削除されると、要求は追加の対話なしに正常に調整を開始します。

1.1.2.1.4. 製品チャネルが、プロビジョニングされたクラスターと同期されない

clusterimagesetfast チャネルに置かれますが、プロビジョニングされたクラスターは stable チャネルにあります。現時点で、製品は channel をプロビジョニングされた OpenShift Container Platform クラスターと同期しません。

OpenShift Container Platform コンソールで適切なチャネルに切り替えます。Administration > Cluster Settings > Details Channel の順にクリックします。

1.1.2.1.5. カスタム CA 証明書を使用したマネージドクラスターの、復元されたハブクラスターへの接続の復元は失敗する可能性がある

カスタム CA 証明書を使用してクラスターを管理したハブクラスターのバックアップを復元した後、マネージドクラスターとハブクラスター間の接続が失敗する場合があります。これは、復元されたハブクラスターで CA 証明書がバックアップされなかったためです。接続を復元するには、マネージドクラスターの namespace にあるカスタム CA 証明書情報を、復元されたハブクラスターの <managed_cluster>-admin-kubeconfig シークレットにコピーします。

ヒント: バックアップコピーを作成する前にこの CA 証明書をハブクラスターにコピーする場合は、バックアップコピーにシークレット情報が含まれます。将来、バックアップコピーを使用して復元する場合、ハブとマネージドクラスター間の接続は自動的に完了します。

1.1.2.1.6. local-cluster が自動的に再作成されない場合がある

disableHubSelfManagementfalse に設定されている場合、local-cluster は MulticlusterHub Operator によって再作成されます。local-cluster をデタッチした後、local-cluster が自動的に再作成されない場合があります。

  • この問題を解決するには、MulticlusterHub によって監視されるリソースを変更します。以下の例を参照してください。

    oc delete deployment multiclusterhub-repo -n <namespace>
  • local-cluster を適切にデタッチするには、MultiClusterHubdisableHubSelfManagement を true に設定します。
1.1.2.1.7. オンプレミスクラスターを作成する場合は、サブネットを選択する必要がある

コンソールを使用してオンプレミスクラスターを作成する場合は、クラスターで利用可能なサブネットを選択する必要があります。必須フィールドとしてマークされていません。

1.1.2.1.8. Infrastructure Operator を使用したクラスターのプロビジョニングに失敗する

Infrastructure Operator を使用して OpenShift Container Platform クラスターを作成する場合、ISO イメージのファイル名は長すぎる可能性があります。長いイメージ名により、イメージのプロビジョニングとクラスターのプロビジョニングが失敗します。この問題が生じるかどうかを確認するには、以下の手順を実行します。

  1. 以下のコマンドを実行して、プロビジョニングするクラスターのベアメタルホスト情報を表示します。

    oc get bmh -n <cluster_provisioning_namespace>
  2. describe コマンドを実行して、エラー情報を表示します。

    oc describe bmh -n <cluster_provisioning_namespace> <bmh_name>
  3. 以下の例と同様のエラーは、ファイル名の長さが問題であることを示します。

    Status:
      Error Count:    1
      Error Message:  Image provisioning failed: ... [Errno 36] File name too long ...

この問題が発生する場合、これは通常 OpenShift Container Platform の以下のバージョンで発生します。インフラストラクチャー Operator がイメージサービスを使用していないためです。

  • 4.8.17 以前
  • 4.9.6 以前

このエラーを回避するには、OpenShift Container Platform をバージョン 4.8.18 以降、または 4.9.7 以降にアップグレードしてください。

1.1.2.1.9. 別の名前で再インポートした後に local-cluster のステータスがオフラインになる

local-cluster という名前のクラスターを、誤って別の名前のクラスターとして再インポートしようとすると、local-cluster と再インポートしたクラスターのステータスが offline と表示されます。

このケースから回復するには、以下の手順を行います。

  1. ハブクラスターで以下のコマンドを実行して、ハブクラスターの自己管理の設定を一時的に編集します。

    oc edit mch -n open-cluster-management multiclusterhub
  2. spec.disableSelfManagement=true の設定を追加します。
  3. ハブクラスターで以下のコマンドを実行し、local-cluster を削除し、再デプロイします。

    oc delete managedcluster local-cluster
  4. 以下のコマンドを実行して local-cluster 管理設定を削除します。

    oc edit mch -n open-cluster-management multiclusterhub
  5. 前の手順で追加した spec.disableSelfManagement=true を削除します。
1.1.2.1.10. Ansible 自動化を使用したクラスタープロビジョニングがプロキシー環境で失敗する

マネージドクラスターを自動的にプロビジョニングするように設定された自動化テンプレートは、次の両方の条件が満たされた場合に失敗する可能性があります。

  • ハブクラスターで、クラスター全体のプロキシーが有効になっている。
  • Ansible Automation Platform には、プロキシー経由でのみアクセスできます。
1.1.2.1.11. klusterlet Operator のバージョンは、ハブクラスターと同じである必要がある

klusterlet Operator をインストールしてマネージドクラスターをインポートする場合には、klusterlet Operator のバージョンは、ハブクラスターのバージョンと同じでなければなりません。そうでないと、klusterlet Operator は動作しません。

1.1.2.1.12. マネージドクラスター namespace を手動で削除できない

マネージドクラスターの namespace を手動で削除できません。マネージドクラスター namespace は、マネージドクラスターの割り当てを解除した後に自動的に削除されます。マネージドクラスターの割り当てを解除する前に手動でマネージドクラスター namespace を削除する場合は、マネージドクラスターの削除後にマネージドクラスターに継続的な終了ステータスが表示されます。この終了マネージドクラスターを削除するには、割り当てを解除したマネージドクラスターからファイナライザーを手動で削除します。

1.1.2.1.13. ハブクラスターとマネージドクラスターのクロックが同期されない

ハブクラスターおよびマネージドクラスターの時間が同期されず、コンソールで unknown と表示され、最数的に、数分以内に available と表示されます。OpenShift Container Platform ハブクラスターの時間が正しく設定されていることを確認します。ノードのカスタマイズ を参照してください。

1.1.2.1.14. IBM OpenShift Container Platform Kubernetes Service クラスターの特定のバージョンのインポートはサポートされていない

IBM OpenShift Container Platform Kubernetes Service バージョン 3.11 のクラスターをインポートすることはできません。IBM OpenShift Kubernetes Service の 3.11 よりも後のバージョンはサポート対象です。

1.1.2.1.15. プロビジョニングされたクラスターのシークレットの自動更新はサポートされていない

クラウドプロバイダー側でクラウドプロバイダーのアクセスキーを変更する場合は、マルチクラスターエンジン Operator のコンソールでこのクラウドプロバイダーの対応する認証情報を更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。

1.1.2.1.17. クラスターを破棄するプロセスが完了しない

マネージドクラスターを破棄してから 1 時間経過してもステータスが Destroying のままで、クラスターが破棄されません。この問題を解決するには、以下の手順を実行します。

  1. クラウドに孤立したリソースがなく、マネージドクラスターに関連付けられたプロバイダーリソースがすべて消去されていることを確認します。
  2. 以下のコマンドを入力して、削除するマネージドクラスターの ClusterDeployment 情報を開きます。

    oc edit clusterdeployment/<mycluster> -n <namespace>

    mycluster は、破棄するマネージドクラスターの名前に置き換えます。

    namespace は、マネージドクラスターの namespace に置き換えます。

  3. hive.openshift.io/deprovision ファイナライザーを削除し、クラウドのクラスターリソースを消去しようとするプロセスを強制的に停止します。
  4. 変更を保存して、ClusterDeployment が削除されていることを確認します。
  5. 以下のコマンドを実行してマネージドクラスターの namespace を手動で削除します。

    oc delete ns <namespace>

    namespace は、マネージドクラスターの namespace に置き換えます。

1.1.2.1.18. OpenShift Container Platform Dedicated でコンソールを使用して OpenShift Container Platform マネージドクラスターをアップグレードできない

Red Hat Advanced Cluster Management コンソールを使用して、OpenShift Container Platform Dedicated 環境にある OpenShift Container Platform マネージドクラスターをアップグレードすることはできません。

1.1.2.1.20. Red Hat OpenShift Container Platform 以外のマネージドクラスターでは、LoadBalancer が有効にされている必要がある

Red Hat OpenShift Container Platform および OpenShift Container Platform 以外のクラスターの両方は Pod ログ機能をサポートしますが、OpenShift Container Platform 以外のクラスターでは、この機能を使用できるように LoadBalancer が有効にされている必要があります。LoadBalancer を有効にするには、以下の手順を実行します。

  1. クラウドプロバイダーごとに LoadBalancer 設定が異なります。詳細は、クラウドプロバイダーのドキュメントを参照してください。
  2. managedClusterInfo のステータスで loggingEndpoint をチェックして、LoadBalancer が Red Hat Advanced Cluster Management で有効にされているかどうかを確認します。
  3. 以下のコマンドを実行して、loggingEndpoint.IP または loggingEndpoint.Host に有効な IP アドレスまたはホスト名が設定されていることを確認します。

    oc get managedclusterinfo <clusterName> -n <clusterNamespace> -o json | jq -r '.status.loggingEndpoint'

LoadBalancer のタイプについての詳細は、Kubernetes のドキュメントService ページを参照してください。

1.1.2.1.21. OpenShift Container Platform 4.10.z では、プロキシー設定を使用する Hosted Control Plane クラスターはサポートされません

OpenShift Container Platform 4.10.z でクラスター全体のプロキシー設定を使用してホスティングサービスクラスターを作成すると、nodeip-configuration.service サービスがワーカーノードで開始されません。

1.1.2.1.22. Azure で OpenShift Container Platform 4.11 クラスターをプロビジョニングできない

Azure で OpenShift Container Platform 4.11 クラスターをプロビジョニングすると、認証 Operator のタイムアウトエラーが原因で失敗します。この問題を回避するには、install-config.yaml ファイルで別のワーカーノードタイプを使用するか、vmNetworkingType パラメーターを Basic に設定します。次の install-config.yaml の例を参照してください。

compute:
- hyperthreading: Enabled
  name: 'worker'
  replicas: 3
  platform:
    azure:
      type:  Standard_D2s_v3
      osDisk:
        diskSizeGB: 128
      vmNetworkingType: 'Basic'
1.1.2.1.23. クライアントが iPXE スクリプトにアクセスできない

iPXE は、オープンソースのネットワークブートファームウェアです。詳細は、iPXE を参照してください。

ノードの起動時に、一部の DHCP サーバーの URL の長さ制限により、InfraEnv カスタムリソース定義の ipxeScript URL が切り取られ、コンソールに次のエラーメッセージが表示されます。

起動可能なデバイスがありません

この問題を回避するには、以下の手順を実行します。

  1. 自動インストールを使用して bootArtifacts を公開する場合は、InfraEnv カスタムリソース定義を適用します。これは次のファイルのようになります。

    status:
      agentLabelSelector:
        matchLabels:
          infraenvs.agent-install.openshift.io: qe2
      bootArtifacts:
        initrd: https://assisted-image-service-multicluster-engine.redhat.com/images/0000/pxe-initrd?api_key=0000000&arch=x86_64&version=4.11
        ipxeScript: https://assisted-service-multicluster-engine.redhat.com/api/assisted-install/v2/infra-envs/00000/downloads/files?api_key=000000000&file_name=ipxe-script
        kernel: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.11/latest/rhcos-live-kernel-x86_64
        rootfs: https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.11/latest/rhcos-live-rootfs.x86_64.img
  2. 短い URL で bootArtifacts を公開するプロキシーサーバーを作成します。
  3. 次のコマンドを実行して、bootArtifacts をコピーし、プロキシーに追加します。

    for artifact in oc get infraenv qe2 -ojsonpath="{.status.bootArtifacts}" | jq ". | keys[]" | sed "s/\"//g"
    do curl -k oc get infraenv qe2 -ojsonpath="{.status.bootArtifacts.${artifact}}"` -o $artifact
  4. ipxeScript アーティファクトプロキシー URL を libvirt.xmlbootp パラメーターに追加します。
1.1.2.1.24. Red Hat Advanced Cluster Management のアップグレード後に ClusterDeployment を削除できない

Red Hat Advanced Cluster Management 2.6 で削除された BareMetalAssets API を使用している場合、BareMetalAssets API が ClusterDeployment にバインドされているため、Red Hat Advanced Cluster Management 2.7 にアップグレードした後に ClusterDeployment を削除することはできません。

この問題を回避するには、以下のコマンドを実行して、Red Hat Advanced Cluster Management 2.7 にアップグレードする前に finalizers を削除します。

oc patch clusterdeployment <clusterdeployment-name> -p '{"metadata":{"finalizers":null}}' --type=merge
1.1.2.1.25. Central Infrastructure Management サービスを使用して非接続環境にデプロイされたクラスターがインストールされない場合がある

Central Infrastructure Management サービスを使用して非接続環境でクラスターをデプロイすると、クラスターノードのインストールが開始されない場合があります。

この問題は、OpenShift Container Platform バージョン 4.12.0 から 4.12.2 に同梱されている Red Hat Enterprise Linux CoreOS ライブ ISO イメージから作成された検出 ISO イメージをクラスターが使用するために発生します。イメージには、registry.redhat.io および registry.access.redhat.com から取得したイメージの署名を必要とする制限付きの /etc/containers/policy.json ファイルが含まれています。非接続環境では、ミラーリングされたイメージにミラーリングされた署名がない場合があり、その結果、クラスターノードの検出時にイメージのプルが失敗します。Agent イメージがクラスターノードとの接続に失敗するため、Assisted Service との通信が失敗します。

この問題を回避するには、/etc/containers/policy.json ファイルを制限なしに設定する ignition オーバーライドをクラスターに適用します。ignition オーバーライドは、InfraEnv カスタムリソース定義で設定できます。次の例は、オーバーライドを使用した InfraEnv カスタムリソース定義を示しています。

apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: cluster
  namespace: cluster
spec:
  ignitionConfigOverride: '{"ignition":{"version":"3.2.0"},"storage":{"files":[{"path":"/etc/containers/policy.json","mode":420,"overwrite":true,"contents":{"source":"data:text/plain;charset=utf-8;base64,ewogICAgImRlZmF1bHQiOiBbCiAgICAgICAgewogICAgICAgICAgICAidHlwZSI6ICJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIgogICAgICAgIH0KICAgIF0sCiAgICAidHJhbnNwb3J0cyI6CiAgICAgICAgewogICAgICAgICAgICAiZG9ja2VyLWRhZW1vbiI6CiAgICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgIiI6IFt7InR5cGUiOiJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIn1dCiAgICAgICAgICAgICAgICB9CiAgICAgICAgfQp9"}}]}}'

次の例は、作成される制限なしのファイルを示しています。

{
    "default": [
        {
            "type": "insecureAcceptAnything"
        }
    ],
    "transports": {
        "docker-daemon": {
        "": [
        {
            "type": "insecureAcceptAnything"
        }
        ]
    }
    }
}

この設定を変更すると、クラスターがインストールされます。

1.1.2.1.26. マネージドクラスターがデプロイ後に Pending ステータスのままになる

Assisted Installer エージェントの起動が遅く、マネージドクラスターをデプロイすると、マネージドクラスターが Pending ステータスのままになり、エージェントリソースがなくなる可能性があります。この問題は、統合フローを無効にすることで回避できます。以下の手順を実行します。

  1. ハブクラスター上に次の ConfigMap を作成します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: my-assisted-service-config
      namespace: multicluster-engine
    data:
      ALLOW_CONVERGED_FLOW: "false"
  2. 次のコマンドを実行して、ConfigMap を適用します。

    oc annotate --overwrite AgentServiceConfig agent unsupported.agent-install.openshift.io/assisted-service-configmap=my-assisted-service-config
1.1.2.1.27. ハブクラスター通信の制限

ハブクラスターがマネージドクラスターにアクセスできない、またはマネージドクラスターと通信できない場合、次の制限が発生します。

  • コンソールを使用して新しいマネージドクラスターを作成できません。コマンドラインインターフェイスを使用するか、コンソールで Run import commands manually オプションを使用して、マネージドクラスターを手動でインポートできます。
  • コンソールを使用してアプリケーションまたはアプリケーションセットをデプロイする場合、またはマネージドクラスターを ArgoCD にインポートする場合、ハブクラスター ArgoCD コントローラーはマネージドクラスター API サーバーを呼び出します。AppSub または ArgoCD pull モデルを使用して問題を回避できます。
  • Pod ログのコンソールページは機能せず、以下のようなエラーメッセージが表示されます。

    Error querying resource logs:
    Service unavailable
1.1.2.1.28. カスタム Ingress ドメインが正しく適用されない

マネージドクラスターのインストール中に ClusterDeployment リソースを使用してカスタム Ingress ドメインを指定できますが、変更はインストール後に SyncSet リソースを使用してのみ適用されます。その結果、clusterdeployment.yaml ファイルの spec フィールドには、指定したカスタム Ingress ドメインが表示されますが、status には引き続きデフォルトのドメインが表示されます。

1.1.2.2. ホステッドコントロールプレーン
1.1.2.2.1. コンソールにホステッドクラスターが Pending import として表示される

アノテーションと ManagedCluster 名が一致しない場合、コンソールはクラスターを Pending import と表示します。クラスターはマルチクラスターエンジン Operator では使用できません。アノテーションがなく、ManagedCluster 名が HostedCluster リソースの Infra-ID 値と一致しない場合は、同じ問題が発生します。

1.1.2.2.2. コンソールは、ホステッドクラスターにノードプールを追加する際に、同じバージョンを複数回、一覧表示する場合があります。

コンソールを使用して既存のホステッドクラスターに新規ノードプールを追加すると、同じバージョンの OpenShift Container Platform がオプションの一覧に複数回、表示される可能性があります。必要なバージョンの一覧で任意のインスタンスを選択できます。

1.1.2.2.3. ManagedClusterSet API 仕様の制限

ManagedClusterSet API を使用する場合、selectorType: LaberSelector 設定はサポートされません。selectorType: ExclusiveClusterSetLabel 設定がサポートされています。

1.1.3. エラータの更新

マルチクラスターエンジン Operator の場合、エラータの更新はリリース時に自動的に適用されます。

重要: 参照できるように、エラータ リンクと GitHub 番号がコンテンツに追加され、内部で使用される可能性があります。ユーザーは、アクセス権が必要なリンクを利用できない可能性があります。

非推奨: マルチクラスターエンジン Operator の 2.2 以前のバージョンはサポートされなくなりました。ドキュメントはそのまま利用できますが、エラータやその他の更新は提供されません。

FIPS の通知: spec.ingress.sslCiphers で独自の暗号を指定しない場合、multiclusterhub-operator は暗号のデフォルトリストを提供します。2.4 の場合には、このリストには、FIPS 承認されていない暗号が 2 つ含まれます。バージョン 2.4.x 以前からアップグレードし、FIPS コンプライアンスが必要な場合は、multiclusterhub リソースから、以下の 2 つの暗号 (ECDHE-ECDSA-CHACHA20-POLY1305 および ECDHE-RSA-CHACHA20-POLY1305) を削除します。

1.1.3.1. Errata 2.11.1
  • 1 つ以上の製品コンテナーイメージに更新を配信します。
1.1.3.2. Errata 2.11.1
  • 1 つ以上の製品コンテナーイメージに更新を配信します。
1.1.3.3. Errata 2.11.1
  • 誤ったリージョンとゾーンが表示される問題を修正します。(ACM-12712)
  • 1 つ以上の製品コンテナーイメージに更新を配信します。
1.1.3.4. Errata 2.11.1
  • 1 つ以上の製品コンテナーイメージに更新を配信します。
1.1.3.5. エラータ 2.3.3
  • 1 つ以上の製品コンテナーイメージとセキュリティー修正プログラムの更新を提供します。
1.1.3.6. エラータ 2.3.2
  • 1 つ以上の製品コンテナーイメージとセキュリティー修正プログラムの更新を提供します。
1.1.3.7. エラータ 2.3.1
  • 大量のシークレットとデプロイメントで klusterlet が失敗する原因となった問題を修正しました。(ACM-12712)
  • 1 つ以上の製品コンテナーイメージとセキュリティー修正プログラムの更新を提供します。

1.1.4. 非推奨と削除

製品の一部が非推奨またはマルチクラスターエンジン Operator から削除されるタイミングを確認します。推奨アクション および詳細にある、代わりのアクションを検討してください。これについては、現在のリリースおよび、1 つ前のリリースと 2 つ前のリリースの表に記載されています。

1.1.4.1. API の非推奨と削除

マルチクラスターエンジン Operator は、Kubernetes の API 非推奨ガイドラインに従います。そのポリシーに関する詳細は、Kubernetes の非推奨ポリシー を参照してください。マルチクラスターエンジン Operator API は、以下のタイムライン外でのみ非推奨または削除されます。

  • V1 API はすべて、12 ヶ月間またはリリース 3 回分 (いずれか長い方) の期間は一般公開され、サポート対象となります。V1 API は削除されませんが、この期間を過ぎると非推奨になる可能性があります。
  • Beta 版 API はすべて、9 ヶ月間またはリリース 3 回分 (いずれか長い方) の期間は一般公開されます。Beta 版 API は、この期間を過ぎても削除されません。
  • alpha 版 API はサポートの必要はありませんが、ユーザーにとってメリットがある場合には、非推奨または削除予定として記載される場合があります。
1.1.4.1.1. API の非推奨化

製品またはカテゴリー

影響を受けるアイテム

バージョン

推奨されるアクション

詳細およびリンク

1.1.4.1.2. API の削除

製品またはカテゴリー

影響を受けるアイテム

バージョン

推奨されるアクション

詳細およびリンク

1.1.4.2. マルチクラスターエンジン Operator の非推奨化

非推奨 のコンポーネント、機能またはサービスはサポートされますが、使用は推奨されておらず、今後のリリースで廃止される可能性があります。以下の表に記載されている 推奨アクション と詳細の代替アクションについて検討してください。

製品またはカテゴリー

影響を受けるアイテム

バージョン

推奨されるアクション

詳細およびリンク

1.1.4.3. 削除

通常、削除 された項目は、以前のリリースで非推奨となった機能で、製品では利用できなくなっています。削除された機能には、代わりの方法を使用する必要があります。以下の表に記載されている 推奨アクション と詳細の代替アクションについて検討してください。

製品またはカテゴリー

影響を受けるアイテム

バージョン

推奨されるアクション

詳細およびリンク

1.2. マルチクラスターエンジン Operator を使用したクラスターライフサイクルについて

Kubernetes Operator のマルチクラスターエンジンは、Red Hat OpenShift Container Platform および Red Hat Advanced Cluster Management ハブクラスターにクラスター管理機能を提供するクラスターライフサイクル Operator です。Red Hat Advanced Cluster Management をインストールした場合は、自動的にインストールされるため、マルチクラスターエンジン Operator をインストールする必要はありません。

サポート情報の詳細は、Kubernetes オペレータ用マルチクラスターエンジン 2.3 サポートマトリックス および以下のドキュメントを参照してください。

続行するには、マルチクラスターエンジン Operator を使用したクラスターライフサイクルについて で、残りのクラスターライフスタイルドキュメントを参照してください。

1.2.1. 要件および推奨事項

マルチクラスターエンジン Operator をインストールする前に、次のシステム設定要件と設定を確認してください。

重要: 2.5 より前の Red Hat Advanced Cluster Management for Kubernetes がインストールされていないクラスターにマルチクラスターエンジン Operator をインストールする必要があります。バージョン 2.5 以降で Red Hat Advanced Cluster Management を使用している場合、Kubernetes 用のマルチクラスターエンジンはすでにクラスターにインストールされています。

Kubernetes オペレータ用マルチクラスターエンジン 2.3 サポートマトリックス で、サポートされているブラウザーと機能に関する重要な情報を参照してください。

1.2.2. コンソールの概要

OpenShift Container Platform コンソールプラグインは OpenShift Container Platform 4.10 Web コンソールで利用可能であり、統合することができます。この機能を使用するには、コンソールプラグインを有効にしておく必要があります。マルチクラスターエンジンの Operator は、Infrastructure および Credentials のナビゲーション項目から特定のコンソール機能を表示します。Red Hat Advanced Cluster Management をインストールすると、より多くのコンソール機能が表示されます。

注記:プラグインが有効になっている OpenShift Container Platform 4.10 の場合は、ドロップダウンメニューから All Clusters を選択することにより、クラスタースイッチャーから OpenShift Container Platform コンソール内で Red Hat Advanced Cluster Management にアクセスできます。

  1. プラグインを無効にするには、OpenShift Container Platform コンソールの Administrator パースペクティブにいることを確認してください。
  2. ナビゲーションで Administration を探し、Cluster Settings をクリックし、続いて Configuration タブをクリックします。
  3. Configuration resources のリストから、operator.openshift.io API グループが含まれる Console リソースをクリックします。この API グループには、Web コンソールのクラスター全体の設定が含まれています。
  4. Console plug-ins タブをクリックします。mce プラグインがリスト表示されます。注記: Red Hat Advanced Cluster Management がインストールされている場合は、acm としても表示されます。
  5. テーブルからプラグインのステータスを変更します。しばらくすると、コンソールを更新するように求められます。

1.2.3. マルチクラスターエンジン Operator のロールベースのアクセス制御

RBAC はコンソールレベルと API レベルで検証されます。コンソール内のアクションは、ユーザーのアクセスロールの権限に基づいて有効化/無効化できます。製品の特定ライフサイクルの RBAC の詳細は、以下のセクションを参照してください。

1.2.3.1. ロールの概要

クラスター別の製品リソースと、スコープに namespace が指定されている製品リソースがあります。アクセス制御に一貫性を持たせるため、クラスターのロールバインディングと、namespace のロールバインディングをユーザーに適用する必要があります。サポートされている次のロール定義の表リストを表示します。

1.2.3.1.1. ロール定義表
ロール定義

cluster-admin

これは OpenShift Container Platform のデフォルトのロールです。cluster-admin ロールへのクラスターバインディングがあるユーザーは、すべてのアクセス権限を持つ OpenShift Container Platform のスーパーユーザーです。

open-cluster-management:cluster-manager-admin

open-cluster-management:cluster-manager-admin ロールにクラスターをバインドするユーザーは、すべてのアクセス権を持つスーパーユーザーです。このロールを指定すると、ユーザーは ManagedCluster リソースを作成できます。

open-cluster-management:admin:<managed_cluster_name>

open-cluster-management:admin:<managed_cluster_name> ロールへのクラスターバインディングがあるユーザーには、<managed_cluster_name> という名前の ManagedCluster リソースに管理者アクセス権が付与されます。ユーザーにマネージドクラスターがある場合は、このロールが自動的に作成されます。

open-cluster-management:view:<managed_cluster_name>

open-cluster-management:view:<managed_cluster_name> ロールへのクラスターバインディングがあるユーザーには、<managed_cluster_name> という名前の ManagedCluster リソースの表示権限が付与されます。

open-cluster-management:managedclusterset:admin:<managed_clusterset_name>

open-cluster-management:managedclusterset:admin:<managed_clusterset_name> ロールへのクラスターバインディングがあるユーザーには、<managed_clusterset_name> という名前の ManagedCluster リソースの管理者アクセス権が付与されます。また、ユーザーには managedcluster.cluster.open-cluster-management.ioclusterclaim.hive.openshift.ioclusterdeployment.hive.openshift.io および clusterpool.hive.openshift.io リソースへの管理者アクセスがあり、cluster.open-cluster-management.ioclusterset=<managed_clusterset_name> のマネージドクラスターセットのラベルが付いています。ロールバインディングは、クラスターセットの使用時に自動的に生成されます。リソースの管理方法については、ManagedClusterSet の作成 を参照してください。

open-cluster-management:managedclusterset:view:<managed_clusterset_name>

open-cluster-management:managedclusterset:view:<managed_clusterset_name> ロールへのクラスターバインディングがあるユーザーには、<managed_clusterset_name>` という名前の ManagedCluster リソースへの表示権限が付与されます。また、ユーザーには managedcluster.cluster.open-cluster-management.ioclusterclaim.hive.openshift.ioclusterdeployment.hive.openshift.io および clusterpool.hive.openshift.io リソースの表示権限があります。これには、cluster.open-cluster-management.ioclusterset=<managed_clusterset_name> のマネージドクラスターセットのラベルが付いています。ママネージドクラスターセットのリソース管理方法の詳細は、ManagedClusterSet の作成 を参照してください。

admin、edit、view

admin、edit、および view は OpenShift Container Platform のデフォルトロールです。これらのロールに対して namespace に限定されたバインディングが指定されているユーザーは、特定の namespace 内の open-cluster-management リソースにアクセスでき、同じロールに対してクラスター全体のバインディングが指定されている場合は、クラスター全体の全 open-cluster-management リソースにアクセスできます。

重要:

  • ユーザーは OpenShift Container Platform からプロジェクトを作成できます。これにより、namespace の管理者ロール権限が付与されます。
  • ユーザーにクラスターへのロールアクセスがない場合、クラスター名は表示されません。クラスター名は、- の記号で表示されます。

RBAC はコンソールレベルと API レベルで検証されます。コンソール内のアクションは、ユーザーのアクセスロールの権限に基づいて有効化/無効化できます。製品の特定ライフサイクルの RBAC の詳細は、以下のセクションを参照してください。

1.2.3.2. クラスターライフサイクル RBAC

以下のクラスターライフサイクル RBAC 操作を確認してください。

  • すべてのマネージドクラスターのクラスターロールバインドを作成および管理します。たとえば、以下のコマンドを入力してクラスターロール open-cluster-management:cluster-manager-admin にバインドするクラスターロールを作成します。

    oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:cluster-manager-admin --user=<username>

    このロールはスーパーユーザーであるため、すべてのリソースとアクションにアクセスできます。このロールを使用すると、クラスターレベルの managedcluster リソース、マネージドクラスターを管理するリソースの namespace、namespace 内のリソースを作成できます。権限エラーを回避するために、ロールの関連付けが必要な ID の username を追加する必要がある場合があります。

  • 以下のコマンドを実行して、cluster-name という名前のマネージドクラスターのクラスターロールバインドを管理します。

    oc create clusterrolebinding (role-binding-name) --clusterrole=open-cluster-management:admin:<cluster-name> --user=<username>

    このロールを使用すると、クラスターレベルの managedcluster リソースに読み取り/書き込みアクセスができるようになります。managedcluster はクラスターレベルのリソースで、namespace レベルのリソースではないので、このロールが必要です。

    • 以下のコマンドを入力して、クラスターロール admin にバインドする namespace ロールを作成します。

      oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=admin --user=<username>

      このロールでは、マネージドクラスターの namespace 内にあるリソースに対して読み取り/書き込みアクセスができるようになります。

  • open-cluster-management:view:<cluster-name> クラスターロールのクラスターロールバインドを作成して、cluster-name という名前のマネージドクラスターを表示します。次のコマンドを入力します。

    oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:view:<cluster-name> --user=<username>

    このロールを使用すると、クラスターレベルの managedcluster リソースに読み取りアクセスができるようになります。これは、managedcluster がクラスタースコープのリソースであるために必要です。

  • 以下のコマンドを入力して、クラスターロール view にバインドする namespace ロールを作成します。

    oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=view --user=<username>

    このロールでは、マネージドクラスターの namespace 内にあるリソースに対して読み取り専用アクセスができるようになります。

  • 以下のコマンドを入力して、アクセス可能なマネージドクラスターの一覧を表示します。

    oc get managedclusters.clusterview.open-cluster-management.io

    このコマンドは、クラスター管理者権限なしで、管理者およびユーザーが使用できます。

  • 以下のコマンドを入力して、アクセス可能なマネージドクラスターセットの一覧を表示します。

    oc get managedclustersets.clusterview.open-cluster-management.io

    このコマンドは、クラスター管理者権限なしで、管理者およびユーザーが使用できます。

1.2.3.2.1. クラスタープール RBAC

以下のクラスタープール RBAC 操作を確認します。

  • クラスター管理者は、クラスタープールのプロビジョニングクラスターを使用して、マネージドクラスターセットを作成し、ロールをグループに追加して管理者権限をロールに付与します。以下の例を参照してください。

    • 以下のコマンドを使用して、server-foundation-clusterset マネージドクラスターセットに admin 権限を付与します。

      oc adm policy add-cluster-role-to-group open-cluster-management:clusterset-admin:server-foundation-clusterset
      server-foundation-team-admin
    • 以下のコマンドを使用して、server-foundation-clusterset マネージドクラスターセットに view 権限を付与します。

      oc adm policy add-cluster-role-to-group open-cluster-management:clusterset-view:server-foundation-clusterset server-foundation-team-user
  • クラスタープールの namespace (server-foundation-clusterpool) を作成します。ロール権限を付与するには、以下の例を参照してください。

    • 以下のコマンドを実行して、server-foundation-team-adminserver-foundation-clusterpooladmin 権限を付与します。

      oc adm new-project server-foundation-clusterpool
      
      oc adm policy add-role-to-group admin server-foundation-team-admin --namespace  server-foundation-clusterpool
  • チーム管理者として、クラスタープール namespace にクラスターセットラベル cluster.open-cluster-management.io/clusterset=server-foundation-clusterset を使用して ocp46-aws-clusterpool という名前のクラスタープールを作成します。

    • server-foundation-webhook は、クラスタープールにクラスターセットラベルがあるかどうか、またユーザーにクラスターセットのクラスタープールを作成する権限があるかどうかを確認します。
    • server-foundation-controller は、server-foundation-team-userserver-foundation-clusterpool namespace に view 権限を付与します。
  • クラスタープールが作成されると、クラスタープールは clusterdeployment を作成します。詳細は、以下を参照してください。

    • server-foundation-controller は、server-foundation-team-adminclusterdeployment namespace に admin 権限を付与します。
    • server-foundation-controller は、server-foundation-team-userclusterdeployment namespace に view 権限を付与します。

      注記: team-admin および team-user には、clusterpoolclusterdeployment、および clusterclaim への admin 権限があります。

1.2.3.2.2. クラスターライフサイクルのコンソールおよび API RBAC の表

クラスターライフサイクルの以下のコンソールおよび API RBAC の表を表示します。

表1.1 クラスターライフサイクルのコンソール RBAC の表
リソース管理編集表示

クラスター

read, update, delete

-

read

クラスターセット

get, update, bind, join

編集ロールなし

get

マネージドクラスター

read, update, delete

編集ロールなし

get

プロバイダー接続

create, read, update, delete

-

read

表1.2 クラスターライフサイクルの API RBAC の表
API管理編集表示

managedclusters.cluster.open-cluster-management.io

この API のコマンドでは、mcl (単数) または mcls (複数) を使用できます。

create, read, update, delete

read, update

read

managedclusters.view.open-cluster-management.io

この API のコマンドでは、mcv (単数) または mcvs (複数) を使用できます。

read

read

read

managedclusters.register.open-cluster-management.io/accept

update

update

 

managedclusterset.cluster.open-cluster-management.io

この API のコマンドでは、mclset (単数) または mclsets (複数) を使用できます。

create, read, update, delete

read, update

read

managedclustersets.view.open-cluster-management.io

read

read

read

managedclustersetbinding.cluster.open-cluster-management.io

この API のコマンドでは、mclsetbinding (単数) または mclsetbindings (複数) を使用できます。

create, read, update, delete

read, update

read

klusterletaddonconfigs.agent.open-cluster-management.io

create, read, update, delete

read, update

read

managedclusteractions.action.open-cluster-management.io

create, read, update, delete

read, update

read

managedclusterviews.view.open-cluster-management.io

create, read, update, delete

read, update

read

managedclusterinfos.internal.open-cluster-management.io

create, read, update, delete

read, update

read

manifestworks.work.open-cluster-management.io

create, read, update, delete

read, update

read

submarinerconfigs.submarineraddon.open-cluster-management.io

create, read, update, delete

read, update

read

placements.cluster.open-cluster-management.io

create, read, update, delete

read, update

read

1.2.3.2.3. 認証情報ロールベースのアクセス制御

認証情報へのアクセスは Kubernetes で制御されます。認証情報は Kubernetes Secret として保存され、セキュリティーを確保します。以下の権限は、Red Hat Advanced Cluster Management for Kubernetes のシークレットのアクセスに関係します。

  • namespace でシークレットの作成権限のあるユーザーは認証情報を作成できます。
  • namespace でシークレットの読み取り権限のあるユーザーは、認証情報を表示することもできます。
  • Kubernetes ロール admin および edit のあるユーザーは、シークレットの作成と編集が可能です。
  • Kubernetes クラスターロール view のあるユーザーは、シークレットの内容を読み取ると、サービスアカウントの認証情報にアクセスできるようになるため、シークレットを表示できません。

1.2.4. ネットワーク設定

接続を許可するようにネットワーク設定を設定します。

重要: 信頼できる CA バンドルはマルチクラスターエンジン Operator namespace で利用できますが、その拡張にはネットワークへの変更が必要です。信頼できる CA バンドル ConfigMap は、trusted-ca-bundle のデフォルト名を使用します。この名前は、TRUSTED_CA_BUNDLE という名前の環境変数で Operator に提供すると変更できます。詳細は、Red Hat OpenShift Container Platform の ネットワーク セクションで クラスター全体のプロキシーの設定 を参照してください。

注記: マネージドクラスターの Registration Agent および Work Agent は、プロキシーを通過できない mTLS 接続の確立によりハブクラスターの apiserver と通信するため、プロキシー設定をサポートしません。

マルチクラスターエンジン Operator のクラスターネットワーク要件については、次の表を参照してください。

方向プロトコル接続ポート (指定されている場合)

Outbound

 

プロビジョニングしたマネージドクラスターの Kubernetes API サーバー

6443

OpenShift Container Platform マネージドクラスターからハブクラスターへの送信

TCP

ironic エージェントとハブクラスター上のベアメタルオペレーター間の通信

6180、6183、6385、5050

ハブクラスターからマネージドクラスターの Ironic Python Agent (IPA) への送信

TCP

IPA が実行されているベアメタルノードと Ironic conductor サービス間の通信

9999

送信および受信

 

マネージドクラスターの WorkManager サービスルート

443

受信

 

マネージドクラスターからの Kubernetes Operator クラスター用マルチクラスターエンジンの Kubernetes API サーバー

6443

注記: マネージドクラスターは、ハブクラスターのコントロールプレーンノードの IP アドレスに到達できる必要があります。

1.3. マルチクラスターエンジン Operator のインストールとアップグレード

マルチクラスターエンジン Operator は、クラスターフリート管理を強化するソフトウェア Operator です。マルチクラスターエンジン Operator は、クラウドおよびデータセンター全体の Red Hat OpenShift Container Platform および Kubernetes クラスターライフサイクル管理をサポートします。

非推奨: マルチクラスターエンジン Operator の 2.2 以前のバージョンはサポートされなくなりました。ドキュメントはそのまま利用できますが、エラータやその他の更新は提供されません。

以下のドキュメントを参照してください。

1.3.1. ネットワーク接続時のオンラインインストール

マルチクラスターエンジン Operator は、マルチクラスターエンジン Operator を含むコンポーネントのインストール、アップグレード、および削除を管理する Operator Lifecycle Manager でインストールされます。

必要なアクセス権限: クラスターの管理者

重要:

  • OpenShift Container Platform 専用環境の場合は、cluster-admin 権限が必要です。デフォルトで、dedicated-admin ロールには OpenShift Container Platform Dedicated 環境で namespace を作成するために必要な権限がありません。
  • デフォルトでは、マルチクラスターエンジン Operator コンポーネントは追加設定なしで OpenShift Container Platform クラスターのワーカーノードにインストールされます。OpenShift Container Platform OperatorHub Web コンソールインターフェイスを使用するか、OpenShift Container Platform CLI を使用してマルチクラスターエンジン Operator をワーカーノードにインストールできます。
  • OpenShift Container Platform クラスターをインフラストラクチャーノードで設定している場合は、追加のリソースパラメーターを使用して、OpenShift Container Platform CLI を使用してマルチクラスターエンジン Operator をそれらのインフラストラクチャーノードにインストールできます。すべてのマルチクラスターエンジン Operator コンポーネントでインフラストラクチャーノードがサポートされるわけではないため、インフラストラクチャーノードにマルチクラスターエンジン Operator をインストールする場合は、一部のワーカーノードが必要になります。詳細については、インフラストラクチャーノードへのマルチクラスターエンジンのインストール セクションを参照してください。
  • OpenShift Container Platform または Kubernetes のマルチクラスターエンジンによって作成されていない Kubernetes クラスターをインポートする場合は、イメージプルシークレットを設定する必要があります。イメージプルシークレットおよびその他の高度な設定方法については、このドキュメントの 詳細設定 セクションのオプションを参照してください。

1.3.1.1. 前提条件

Kubernetes 用のマルチクラスターエンジンをインストールする前に、次の要件を確認してください。

  • Red Hat OpenShift Container Platform クラスターは、OpenShift Container Platform コンソールから OperatorHub カタログのマルチクラスターエンジン Operator にアクセスできる必要があります。
  • catalog.redhat.com へのアクセスがある。
  • お使いの環境に OpenShift Container Platform バージョン 4.8 以降をデプロイし、OpenShift Container Platform CLI でログインしている。以下の OpenShift Container Platform のインストールドキュメントを参照してください。

  • OpenShift Container Platform のコマンドラインインターフェイス (CLI) は、oc コマンドを実行できるように設定している。Red Hat OpenShift CLI のインストールおよび設定の詳細は、CLI の使用方法 を参照してください。
  • namespace の作成が可能な OpenShift Container Platform のパーミッションを設定している。
  • operator の依存関係にアクセスするには、インターネット接続が必要。
  • OpenShift Container Platform Dedicated 環境にインストールするには、以下を参照してください。

    • OpenShift Container Platform Dedicated 環境が設定され、実行している。
    • エンジンのインストール先の OpenShift Container Platform Dedicated 環境での cluster-admin がある。
  • Red Hat OpenShift Container Platform で提供される Assisted Installer を使用してマネージドクラスターを作成する予定の場合は、OpenShift Container Platform ドキュメントの アシステッドインストーラーを使用したインストールの準備 トピックを参照してください。
1.3.1.2. OpenShift Container Platform インストールの確認

レジストリー、ストレージサービスなど、サポート対象の OpenShift Container Platform バージョンがインストールされ、機能する状態である必要があります。OpenShift Container Platform のインストールの詳細は、OpenShift Container Platform のドキュメントを参照してください。

  1. マルチクラスターエンジン Operator が OpenShift Container Platform クラスターにインストールされていないことを確認します。マルチクラスターエンジン Operator は、各 OpenShift Container Platform クラスターで 1 つのインストールのみを許可します。インストールがない場合は、次の手順に進みます。
  2. OpenShift Container Platform クラスターが正しく設定されていることを確認するには、以下のコマンドを使用して OpenShift Container Platform Web コンソールにアクセスします。

    kubectl -n openshift-console get route console

    以下の出力例を参照してください。

    console console-openshift-console.apps.new-coral.purple-chesterfield.com
    console   https   reencrypt/Redirect     None
  3. ブラウザーで URL を開き、結果を確認します。コンソール URL の表示が console-openshift-console.router.default.svc.cluster.local の場合は、OpenShift Container Platform のインストール時に openshift_master_default_subdomain を設定します。https://console-openshift-console.apps.new-coral.purple-chesterfield.com の例を参照してください。

マルチクラスターエンジン Operator のインストールに進むことができます。

1.3.1.3. OperatorHub Web コンソールインターフェイスからのインストール

ベストプラクティス: OpenShift Container Platform ナビゲーションの Administrator ビューから、OpenShift Container Platform で提供される OperatorHub Web コンソールインターフェイスをインストールします。

  1. Operators > OperatorHub を選択して利用可能な operator のリストにアクセスし、multicluster engine for Kubernetes Operator を選択します。
  2. Install をクリックします。
  3. Operator Installation ページで、インストールのオプションを選択します。

    • Namespace:

      • マルチクラスターエンジン Operator エンジンは、独自の namespace またはプロジェクトにインストールする必要があります。
      • デフォルトでは、OperatorHub コンソールのインストールプロセスにより、multicluster-engine という名前の namespace が作成されます。ベストプラクティス: multicluster-engine namespace が使用可能な場合は、引き続き使用します。
      • multicluster-engine という名前の namespace が存在する場合は、別の namespace を選択してください。
    • チャネル: インストールするリリースに対応するチャネルを選択します。チャネルを選択すると、指定のリリースがインストールされ、そのリリース内の今後のエラータ更新が取得されます。
    • 承認ストラテジー: 承認ストラテジーでは、サブスクライブ先のチャネルまたはリリースに更新を適用するのに必要な人の間のやり取りを特定します。

      • そのリリース内の更新が自動的に適用されるようにするには、デフォルトで選択されている Automatic を選択します。
      • Manual を選択して、更新が利用可能になると通知を受け取ります。更新がいつ適用されるかについて懸念がある場合は、これがベストプラクティスになる可能性があります。

    注記: 次のマイナーリリースにアップグレードするには、OperatorHub ページに戻り、最新リリースの新規チャネルを選択する必要があります。

  4. Install を選択して変更を適用し、Operator を作成します。
  5. MultiClusterEngine カスタムリソースを作成するには、次のプロセスを参照してください。

    1. OpenShift Container Platform コンソールナビゲーションで、Installed Operators > multicluster engine for Kubernetes を選択します。
    2. MultiCluster Engine タブを選択します。
    3. Create MultiClusterEngine を選択します。
    4. YAML ファイルのデフォルト値を更新します。このドキュメントの MultiClusterEngine advanced configuration のオプションを参照してください。

      • 次の例は、エディターにコピーできるデフォルトのテンプレートを示しています。
      apiVersion: multicluster.openshift.io/v1
      kind: MultiClusterEngine
      metadata:
        name: multiclusterengine
      spec: {}
  6. Create を選択して、カスタムリソースを初期化します。マルチクラスターエンジン Operator エンジンがビルドおよび起動するまで最長 10 分かかる場合があります。

    MultiClusterEngine リソースが作成されると、リソースのステータスが MultiCluster Engine タブで Available になります。

1.3.1.4. OpenShift Container Platform CLI からのインストール
  1. Operator 要件を満たしたマルチクラスターエンジン Operator エンジン namespace を作成します。次のコマンドを実行します。ここで、namespace は、Kubernetes エンジン namespace のマルチクラスターエンジンの名前です。namespace の値は、OpenShift Container Platform 環境では プロジェクト と呼ばれる場合があります。

    oc create namespace <namespace>
  2. プロジェクトの namespace を、作成した namespace に切り替えます。namespace は、手順 1 で作成した Kubernetes エンジン用のマルチクラスターエンジンの namespace の名前に置き換えてください。

    oc project <namespace>
  3. OperatorGroup リソースを設定するために YAML ファイルを作成します。namespace ごとに割り当てることができる Operator グループは 1 つだけです。default はお使いの operator グループ名に置き換えます。namespace はお使いのプロジェクトの namespace 名に置き換えます。以下の例を参照してください。

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: <default>
      namespace: <namespace>
    spec:
      targetNamespaces:
      - <namespace>
  4. 以下のコマンドを実行して OperatorGroup リソースを作成します。operator-group は、作成した operator グループの YAML ファイル名に置き換えます。

    oc apply -f <path-to-file>/<operator-group>.yaml
  5. OpenShift Container Platform サブスクリプションを設定するための YAML ファイルを作成します。ファイルは以下の例のようになります。

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: multicluster-engine
    spec:
      sourceNamespace: openshift-marketplace
      source: redhat-operators
      channel: stable-2.1
      installPlanApproval: Automatic
      name: multicluster-engine

    注記: インフラストラクチャーノードに Kubernetes エンジン用のマルチクラスターエンジンをインストールする場合は、Operator Lifecycle Manager サブスクリプションの追加設定 セクションを参照してください。

  6. 以下のコマンドを実行して OpenShift Container Platform サブスクリプションを作成します。subscription は、作成したサブスクリプションファイル名に置き換えます。

    oc apply -f <path-to-file>/<subscription>.yaml
  7. YAML ファイルを作成して、MultiClusterEngine カスタムリソースを設定します。デフォルトのテンプレートは、以下の例のようになります。

    apiVersion: multicluster.openshift.io/v1
    kind: MultiClusterEngine
    metadata:
      name: multiclusterengine
    spec: {}

    注記: インフラストラクチャーノードにマルチクラスターエンジン Operator をインストールする場合は、MultiClusterEngine カスタムリソースの追加設定 セクションを参照してください。

  8. 次のコマンドを実行して、MultiClusterEngine カスタムリソースを作成します。custom-resource は、カスタムリソースファイル名に置き換えます。

    oc apply -f <path-to-file>/<custom-resource>.yaml

    以下のエラーで、この手順に失敗した場合でも、リソースは作成され、適用されます。リソースが作成されてから数分後にもう一度コマンドを実行します。

    error: unable to recognize "./mce.yaml": no matches for kind "MultiClusterEngine" in version "operator.multicluster-engine.io/v1"
  9. 以下のコマンドを実行してカスタムリソースを編集します。次のコマンドを実行した後、MultiClusterEngine カスタムリソースステータスが status.phase フィールドに Available として表示されるまでに最大 10 分かかる場合があります。

    oc get mce -o=jsonpath='{.items[0].status.phase}'

マルチクラスターエンジン Operator を再インストールし、Pod が起動しない場合は、この問題の回避手順について 再インストールに失敗する場合のトラブルシューティング を参照してください。

注記:

  • ClusterRoleBinding が指定された ServiceAccount は、クラスター管理者権限をマルチクラスターエンジン Operator と、マルチクラスターエンジン Operator をインストールする namespace にアクセスできるすべてのユーザー認証情報に自動的に付与します。
1.3.1.5. インフラストラクチャーノードへのインストール

OpenShift Container Platform クラスターを、承認された管理コンポーネントを実行するためのインフラストラクチャーノードを組み込むように設定できます。インフラストラクチャーノードでコンポーネントを実行すると、それらの管理コンポーネントを実行しているノードの OpenShift Container Platform サブスクリプションクォータの割り当てる必要がなくなります。

OpenShift Container Platform クラスターにインフラストラクチャーノードを追加した後に、OpenShift Container Platform CLI からのインストール 手順に従い、以下の設定を Operator Lifecycle Manager サブスクリプションおよび MultiClusterEngine カスタムリソースに追加します。

1.3.1.5.1. インフラストラクチャーノードを OpenShift Container Platform クラスターに追加する

OpenShift Container Platform ドキュメントの インフラストラクチャーマシンセットの作成 で説明されている手順に従います。インフラストラクチャーノードは、Kubernetes の taint および label で設定され、管理以外のワークロードがそれらで稼働し続けます。

マルチクラスターエンジン Operator が提供するインフラストラクチャーノードの有効化と互換性を持たせるには、インフラストラクチャーノードに次の taintlabel が適用されていることを確認します。

metadata:
  labels:
    node-role.kubernetes.io/infra: ""
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/infra
1.3.1.5.2. Operator Lifecycle Manager サブスクリプションの追加設定

Operator Lifecycle Manager サブスクリプションを適用する前に、以下の追加設定を追加します。

spec:
  config:
    nodeSelector:
      node-role.kubernetes.io/infra: ""
    tolerations:
    - key: node-role.kubernetes.io/infra
      effect: NoSchedule
      operator: Exists
1.3.1.5.3. MultiClusterEngine カスタムリソースの追加設定

MultiClusterEngine カスタムリソースを適用する前に、以下の設定を追加します。

spec:
  nodeSelector:
    node-role.kubernetes.io/infra: ""

1.3.2. ネットワーク切断状態でのインストール

インターネットに接続されていない Red Hat OpenShift Container Platform クラスターにマルチクラスターエンジン Operator をインストールする必要がある場合があります。ネットワーク接続のないエンジンにインストールする手順でも一部、オンラインインストールと同じ手順が必要になります。

重要: 2.5 より前の Red Hat Advanced Cluster Management for Kubernetes がインストールされていないクラスターにマルチクラスターエンジン Operator をインストールする必要があります。マルチクラスターエンジン Operator は、同じ管理コンポーネントの一部を提供するため、2.5 より前のバージョンでは Red Hat Advanced Cluster Management for Kubernetes と共存できません。Red Hat Advanced Cluster Management をインストールしたことがないクラスターにマルチクラスターエンジン Operator をインストールすることが推奨されます。バージョン 2.5.0 以降で Red Hat Advanced Cluster Management for Kubernetes を使用している場合、マルチクラスターエンジン Operator はすでにクラスターにインストールされています。

インストール時にネットワークから直接パッケージにアクセスするのではなく、パッケージをダウンロードしておき、インストール時にアクセスできるようにする必要があります。

1.3.2.1. 前提条件

マルチクラスターエンジン Operator をインストールする前に、次の要件を満たしている必要があります。

  • お使いの環境に Red Hat OpenShift Container Platform バージョン 4.8 以降をインストールし、コマンドラインインターフェイス (CLI) でログインしている。
  • catalog.redhat.com にアクセスできる。

    注記: ベアメタルクラスターを管理する場合は、Red Hat OpenShift Container Platform バージョン 4.8 以降が必要です。

    OpenShift Container Platform version 4.10OpenShift Container Platform version 4.8 を参照してください。

  • Red Hat OpenShift Container Platform の CLI バージョンは 4.8 以降を使用し、oc コマンドを実行できるように設定している。Red Hat OpenShift CLI のインストールおよび設定の詳細は、CLI の使用方法 を参照してください。
  • namespace の作成が可能な Red Hat OpenShift Container Platform の権限を設定している。
  • Operator の依存関係をダウンロードするために、インターネット接続のあるワークステーションが必要。
1.3.2.2. OpenShift Container Platform インストールの確認
  • レジストリー、ストレージサービスなど、サポート対象の OpenShift Container Platform バージョンがクラスターにインストールされ、機能する状態である必要があります。OpenShift Container Platform バージョン 4.8 の詳細は、OpenShift Container Platform documentation を参照してください。
  • 接続されている場合は、以下のコマンドを使用して OpenShift Container Platform Web コンソールにアクセスすることにより、OpenShift Container Platform クラスターが正しく設定されていることを確認できます。

    kubectl -n openshift-console get route console

    以下の出力例を参照してください。

    console console-openshift-console.apps.new-coral.purple-chesterfield.com
    console   https   reencrypt/Redirect     None

    この例のコンソール URL は https:// console-openshift-console.apps.new-coral.purple-chesterfield.com です。ブラウザーで URL を開き、結果を確認します。

    コンソール URL の表示が console-openshift-console.router.default.svc.cluster.local の場合は、OpenShift Container Platform のインストール時に openshift_master_default_subdomain を設定します。

1.3.2.3. 非接続環境でのインストール

重要: 必要なイメージをミラーリングレジストリーにダウンロードし、非接続環境で Operator をインストールする必要があります。ダウンロードがないと、デプロイメント時に ImagePullBackOff エラーが表示される可能性があります。

以下の手順に従って、非接続環境にマルチクラスターエンジン Operator をインストールします。

  1. ミラーレジストリーを作成します。ミラーレジストリーがまだない場合は、OpenShift Container Platform ドキュメントの 非接続インストールのミラーリング の手順を実行してミラーレジストリーを作成してください。

    ミラーレジストリーがすでにある場合は、既存のレジストリーを設定して使用できます。

  2. 注記: ベアメタルの場合のみ、install-config.yaml ファイルに、接続なしのレジストリーの証明書情報を指定する必要があります。保護された非接続レジストリー内のイメージにアクセスするには、マルチクラスターエンジン Operator がレジストリーにアクセスできるように、証明書情報を指定する必要があります。

    1. レジストリーから証明書情報をコピーします。
    2. エディターで install-config.yaml ファイルを開きます。
    3. additionalTrustBundle: | のエントリーを検索します。
    4. additionalTrustBundle の行の後に証明書情報を追加します。追加後の内容は以下の例のようになります。

      additionalTrustBundle: |
        -----BEGIN CERTIFICATE-----
        certificate_content
        -----END CERTIFICATE-----
      sshKey: >-
  3. 重要: 以下のガバナンスポリシーが必要な場合は、非接続イメージレジストリーの追加ミラーが必要です。

    • Container Security Operator ポリシー: registry.redhat.io/quay ソースでイメージを見つけます。
    • Compliance Operator ポリシー: registry.redhat.io/compliance ソースでイメージを見つけます。
    • Gatekeeper Operator ポリシー: registry.redhat.io/rhacm2 ソース内のイメージを見つけます。

      3 つのすべての Operator については、以下のミラー一覧を参照してください。

        - mirrors:
          - <your_registry>/rhacm2
          source: registry.redhat.io/rhacm2
        - mirrors:
          - <your_registry>/quay
          source: registry.redhat.io/quay
        - mirrors:
          - <your_registry>/compliance
          source: registry.redhat.io/compliance
  4. install-config.yaml ファイルを保存します。
  5. mce-policy.yaml という名前の ImageContentSourcePolicy を含む YAML ファイルを作成します。注記: 実行中のクラスターでこれを変更すると、すべてのノードのローリング再起動が実行されます。

    apiVersion: operator.openshift.io/v1alpha1
    kind: ImageContentSourcePolicy
    metadata:
      name: mce-repo
    spec:
      repositoryDigestMirrors:
      - mirrors:
        - mirror.registry.com:5000/multicluster-engine
        source: registry.redhat.io/multicluster-engine
  6. 以下のコマンドを入力して ImageContentSourcePolicy ファイルを適用します。

    oc apply -f mce-policy.yaml
  7. ネットワーク接続されていない Operator Lifecycle Manager の Red Hat Operator とコミュニティーの Operator を有効にします。

    マルチクラスターエンジン Operator は Operator Lifecycle Manager Red Hat Operator カタログに含まれます。

  8. Red Hat Operator カタログの非接続 Operator Lifecycle Manager を設定します。Red Hat OpenShift Container Platform ドキュメントの ネットワークが制限された環境での Operator Lifecycle Manager の使用 の手順を実行します。
  9. 非接続の Operator Lifecycle Manager にイメージを取得したので、引き続き Operator Lifecycle Manager カタログから Kubernetes 用のマルチクラスターエンジン Operator をインストールします。

必要な手順については、ネットワーク接続時のオンラインインストール を参照してください。

1.3.2.4. 自動インストーラー使用時のイメージのミラーリング

Assisted-service を使用してマネージドクラスターをデプロイする場合、Red Hat OpenShift Container Platform イメージは切断された環境では自動的にミラーリングされません。マネージドクラスターをインストールするには、一致する OpenShift Container Platform Ironic エージェントイメージを使用する必要があります。ハブクラスターの OpenShift Container Platform バージョンによって、どの Ironic エージェントイメージを使用するかが決まります。切断された環境では、OpenShift Container Platform イメージを手動でミラーリングする必要があります。

1.3.2.4.1. 一致する CPU アーキテクチャー上でイメージを手動でミラーリングする

ハブクラスターとマネージドクラスターが同じ CPU アーキテクチャーを使用している場合は、次の手順を実行して、Ironic エージェントイメージを手動でミラーリングします。

  1. 次のコマンドを実行して、一致する Ironic エージェントイメージのバージョンを見つけます。<hub-release-image> は、ハブクラスターリリースのイメージに置き換えます。

    oc adm release info --image-for=ironic-agent <hub-release-image>
  2. 次のコマンドを実行して、Ironic エージェントイメージをミラーリングします。

    skopeo copy <image-from-oc-adm-output> <mirror>

    <image-from-oc-adm-output> は、ステップ 1 の出力のイメージに置き換えます。

    <mirror> は、ミラーリングされたイメージに置き換えます。

1.3.2.4.2. 異なる CPU アーキテクチャー上でイメージを手動でミラーリングする

ハブクラスターとマネージドクラスターが異なる CPU アーキテクチャーを使用している場合は、デフォルトの Ironic エージェントイメージが使用されます。正しいデフォルトの Ironic エージェントイメージを手動でミラーリングするには、次の手順を実行します。

  1. ハブクラスターで arm64 CPU を実行し、マネージドクラスターで x86_64 CPU を実行している場合は、quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:d3f1d4d3cd5fbcf1b9249dd71d01be4b901d337fdc5f8f66569eb71df4d9d446 のイメージを使用します。
  2. ハブクラスターで x86_64 CPU を実行し、マネージドクラスターで arm64 CPU を実行している場合は、quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:cb0edf19fffc17f542a7efae76939b1e9757dc75782d4727fb0aa77ed5809b43 のイメージを使用します。
  3. 次のコマンドを実行して、Ironic エージェントイメージをミラーリングします。

    skopeo copy <default-image> <mirror>

    <default-image> は、今CPU アーキテクチャーの組み合わせに応じて、ステップ 1 またはステップ 2 のイメージに置き換えます。

    <mirror> は、ミラーリングされたイメージに置き換えます。

1.3.3. 詳細設定

マルチクラスターエンジン Operator は、必要なすべてのコンポーネントをデプロイする Operator を使用してインストールされます。マルチクラスターエンジン Operator は、インストール中またはインストール後に、MultiClusterEngine カスタムリソースに次の属性の 1 つ以上を追加して、さらに設定できます。

1.3.3.1. local-cluster の有効化

デフォルトでは、マルチクラスターエンジン Operator を実行しているクラスターが自身を管理します。クラスター自身を管理せずに、マルチクラスターエンジン Operator をインストールするには、MultiClusterEngine セクションの spec.overrides.components 設定で次の値を指定します。

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  overrides:
    components:
    - name: local-cluster
      enabled: false
  • name 値は、ハブクラスターを local-cluster として識別します。
  • enabled 設定は、機能を有効にするか無効にするかを指定します。値が true の場合、ハブクラスターは自身を管理します。値が false の場合、ハブクラスターは自身を管理しません。

自己管理されるハブクラスターは、クラスターの一覧で local-cluster として指定されます。

1.3.3.2. カスタムイメージプルシークレット

OpenShift Container Platform またはマルチクラスターエンジン Operator によって作成されていない Kubernetes クラスターをインポートする予定の場合は、OpenShift Container Platform プルシークレット情報を含むシークレットを生成して、ディストリビューションレジストリーから資格のあるコンテンツにアクセスします。

OpenShift Container Platform クラスターのシークレット要件は、OpenShift Container Platform および multicluster engine for Kubernetes により自動で解決されるため、他のタイプの Kubernetes クラスターをインポートして管理しない場合には、このシークレットを作成する必要はありません。

重要: これらのシークレットは namespace に依存するため、エンジンに使用する namespace にいることを確認してください。

  1. cloud.redhat.com/openshift/install/pull-secret から Download pull secret を選択して、OpenShift Container Platform のプルシークレットファイルをダウンロードします。OpenShift Container Platform プルシークレットは Red Hat カスタマーポータル ID に関連しており、すべての Kubernetes プロバイダーで同じです。
  2. 以下のコマンドを実行してシークレットを作成します。

    oc create secret generic <secret> -n <namespace> --from-file=.dockerconfigjson=<path-to-pull-secret> --type=kubernetes.io/dockerconfigjson
    • secret は作成するシークレット名に置き換えます。
    • シークレットは namespace 固有であるため、namespace はプロジェクトの namespace に置き換えます。
    • path-to-pull-secret はダウンロードした OpenShift Container Platform のプルシークレットへのパスに置き換えます。

以下の例では、カスタムプルシークレットを使用する場合に使用する spec.imagePullSecret テンプレートを表示しています。secret は、プルシークレット名に置き換えます。

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  imagePullSecret: <secret>
1.3.3.3. ターゲット namespace

MultiClusterEngine カスタムリソースで場所を指定することにより、指定された namespace にオペランドをインストールできます。この namespace は、MultiClusterEngine カスタムリソースの適用時に作成されます。

重要: ターゲット namespace が指定されていない場合、Operator は multicluster-engine namespace にインストールし、MultiClusterEngine カスタムリソース仕様で設定します。

次の例は、ターゲット namespace を指定するために使用できる spec.targetNamespace テンプレートを示しています。target を宛先 namespace の名前に置き換えます。注記: target namespace を default namespace にすることはできません。

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  targetNamespace: <target>
1.3.3.4. availabilityConfig

ハブクラスターには、HighBasic の 2 つの可用性があります。デフォルトでは、ハブクラスターには High の可用性があります。これにより、ハブクラスターコンポーネントに replicaCount 2 が提供されます。これにより、フェイルオーバー時のサポートが向上しますが、Basic 可用性よりも多くのリソースを消費します。これにより、コンポーネントには replicaCount 1 が提供されます。

以下の例は、Basic の可用性のある spec.availabilityConfig テンプレートを示しています。

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  availabilityConfig: "Basic"
1.3.3.5. nodeSelector

MultiClusterEngine でノードセレクターのセットを定義して、クラスター上の特定のノードにインストールできます。次の例は、ラベル node-role.kubernetes.io/infra を持つノードに Pod を割り当てる spec.nodeSelector を示しています。

spec:
  nodeSelector:
    node-role.kubernetes.io/infra: ""
1.3.3.6. toleration

許容範囲のリストを定義して、MultiClusterEngine がクラスターで定義された特定の taint を許容できるようにすることができます。以下の例は、node-role.kubernetes.io/infra taint に一致する spec.tolerations を示しています。

spec:
  tolerations:
  - key: node-role.kubernetes.io/infra
    effect: NoSchedule
    operator: Exists

以前の infra-node toleration は、設定に toleration を指定せずにデフォルトで Pod に設定されます。設定で許容値をカスタマイズすると、このデフォルトの動作が置き換えられます。

1.3.3.7. ManagedServiceAccount アドオン (テクノロジープレビュー)

デフォルトでは、Managed-ServiceAccount アドオンは無効になっています。このコンポーネントを有効にすると、マネージドクラスターでサービスアカウントを作成または削除できます。このアドオンを有効にしてインストールするには、spec.overridesMultiClusterEngine 仕様に以下を含めます。

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  overrides:
    components:
    - name: managedserviceaccount-preview
      enabled: true

Managed-ServiceAccount アドオンは、MultiClusterEngine の作成後に、コマンドラインでリソースを編集し、managedserviceaccount-preview コンポーネントを enabled: true に設定することで有効にできます。または、次のコマンドを実行して、<multiclusterengine-name> を MultiClusterEngine リソースの名前に置き換えることもできます。

oc patch MultiClusterEngine <multiclusterengine-name> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"managedserviceaccount-preview","enabled":true}}]'
1.3.3.8. hypershift アドオン (テクノロジープレビュー)

デフォルトでは、Hypershift アドオンは無効になっています。このアドオンを有効にしてインストールするには、spec.overridesMultiClusterEngine 値に以下を含めます。

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  overrides:
    components:
    - name: hypershift-preview
      enabled: true

Hypershift アドオンは、MultiClusterEngine の作成後に、コマンドラインでリソースを編集し、hypershift-preview コンポーネントを enabled: true に設定することで有効にできます。または、次のコマンドを実行して、<multiclusterengine-name> を MultiClusterEngine リソースの名前に置き換えることもできます。

oc patch MultiClusterEngine <multiclusterengine-name> --type=json -p='[{"op": "add", "path": "/spec/overrides/components/-","value":{"name":"hypershift-preview","enabled":true}}]'

1.3.4. アンインストール

Kubernetes のマルチクラスターエンジンをアンインストールすると、プロセスの 2 つの異なるレベルが表示されます。custom resource removalcomplete operator uninstall です。アンインストールプロセスの完了に最長 5 分かかる可能性があります。

  • カスタムリソースの削除は、最も基本的なアンインストールの種類で、MultiClusterEngine インスタンスのカスタムリソースを削除しますが、他の必要なコンポーネントが残されたままになります。このレベルのアンインストールは、同じ設定とコンポーネントを使用して再インストールする予定の場合に役立ちます。
  • 2 番目のレベルは、より完全なアンインストールで、カスタムリソース定義などのコンポーネントを除き、ほとんどの Operator コンポーネントを削除します。この手順を続行すると、カスタムリソースの削除で削除されていないコンポーネントおよびサブスクリプションがすべて削除されます。アンインストールが済むと、カスタムリソースの前に Operator を再インストールする必要があります。
1.3.4.1. 前提条件: 有効化されたサービスのデタッチ

Kubernetes エンジンのマルチクラスターエンジンをアンインストールする前に、そのエンジンによって管理されているすべてのクラスターをデタッチする必要があります。エラーを回避するには、エンジンによって管理されているすべてのクラスターをデタッチしてから、アンインストールを再試行してください。

  • マネージドクラスターがアタッチされている場合は、以下のメッセージが表示される可能性があります。

    Cannot delete MultiClusterEngine resource because ManagedCluster resource(s) exist

    クラスターのデタッチの詳細は、クラスターの作成 でお使いのプロバイダーの情報を選択して、マネージメントからのクラスターの削除 セクションを参照してください。

1.3.4.2. コマンドを使用したリソースの削除
  1. まだの場合には、oc コマンドが実行できるように、OpenShift Container Platform CLI が設定されていることを確認してください。oc コマンドの設定方法は、Red Hat OpenShift Container Platform ドキュメントの OpenShift CLI の使用方法 を参照してください。
  2. 以下のコマンドを入力してプロジェクトの namespace に移動します。namespace はお使いのプロジェクトの namespace 名に置き換えます。

    oc project <namespace>
  3. 次のコマンドを入力して、MultiClusterEngine カスタムリソースを削除します。

    oc delete multiclusterengine --all

    以下のコマンドを入力して進捗を表示できます。

    oc get multiclusterengine -o yaml
  4. 以下のコマンドを入力し、インストールされている namespace の multicluster-engine ClusterServiceVersion を削除します。
❯ oc get csv
NAME                         DISPLAY                              VERSION   REPLACES   PHASE
multicluster-engine.v2.0.0   multicluster engine for Kubernetes   2.0.0                Succeeded

❯ oc delete clusterserviceversion multicluster-engine.v2.0.0
❯ oc delete sub multicluster-engine

ここに表示されている CSV バージョンは異なる場合があります。

1.3.4.3. コンソールを使用したコンポーネントの削除

Red Hat OpenShift Container Platform コンソールを使用してアンインストールする場合に、Operator を削除します。コンソールを使用してアンインストールを行うには、以下の手順を実行します。

  1. OpenShift Container Platform コンソールナビゲーションで、Operators > Installed Operators > multicluster engine for Kubernetes を選択します。
  2. MultiClusterEngine カスタムリソースを削除します。

    1. Multiclusterengine のタブを選択します。
    2. MultiClusterEngine カスタムリソースの Options メニューを選択します。
    3. Delete MultiClusterEngine を選択します。
  3. 次のセクションの手順に従って、クリーンアップスクリプトを実行します。

    ヒント: Kubernetes バージョンで同じマルチクラスターエンジンを再インストールする場合は、この手順の残りの手順をスキップして、カスタムリソースを再インストールできます。

  4. Installed Operators に移動します。
  5. Options メニューから Uninstall operator を選択して、_ multicluster engine for Kubernetes_ Operator を削除してください。
1.3.4.4. トラブルシューティングアンインストール

マルチクラスターエンジンのカスタムリソースが削除されていない場合は、クリーンアップスクリプトを実行して、残っている可能性のあるアーティファクトをすべて削除します。

  1. 以下のスクリプトをファイルにコピーします。

    #!/bin/bash
    oc delete apiservice v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io
    oc delete validatingwebhookconfiguration multiclusterengines.multicluster.openshift.io
    oc delete mce --all

詳細は 切断されたインストールのミラーリング を参照してください。

1.4. 認証情報の管理

マルチクラスターエンジン Operator を使用してクラウドサービスプロバイダーで Red Hat OpenShift Container Platform クラスターを作成および管理するには、認証情報 が必要です。認証情報では、クラウドプロバイダーのアクセス情報を保存します。1 つのプロバイダーのドメインごとに独自の認証情報が必要になるのと同様に、プロバイダーアカウントごとに独自の認証情報が必要です。

クラスターの認証情報を作成して管理できます。認証情報は Kubernetes Secret として保存されます。シークレットはマネージドクラスターの namespace にコピーされ、マネージドクラスターのコントローラーがシークレットにアクセスできるようになります。認証情報が更新されると、シークレットのコピーはマネージドクラスターの namespace で自動的に更新されます。

注記: クラウドプロバイダーの認証情報のプルシークレット、SSH キー、またはベースドメインへの変更は、元の認証情報を使用してすでにプロビジョニングされているため、既存のマネージドクラスターには反映されません。

必要なアクセス権限: 編集

1.4.1. Amazon Web Services の認証情報の作成

マルチクラスターエンジン Operator コンソールを使用して、Amazon Web Services (AWS) で Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、認証情報が必要です。

必要なアクセス権限: 編集

注記: この手順は、マルチクラスターエンジン Operator でクラスターを作成する前に実行する必要があります。

1.4.1.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • デプロイされたマルチクラスターエンジン Operator ハブクラスター
  • Amazon Web Services (AWS) で Kubernetes クラスターを作成できるようにするマルチクラスターエンジン Operator ハブクラスターのインターネットアクセス
  • アクセスキー ID およびシークレットアクセスキーなど、AWS のログイン認証情報。Understanding and getting your security credentials を参照してください。
  • AWS でクラスターをインストールできるようにするアカウントの権限。Configuring an AWS account は、AWS アカウントの設定を参照してください。
1.4.1.2. コンソールを使用した認証情報の管理

マルチクラスターエンジン Operator コンソールから認証情報を作成するには、コンソールで手順を実行します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー上、認証情報のホスト専用の namespace を作成します。

オプションで、認証情報の ベース DNS ドメイン を追加できます。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。以下の手順を参照してください。

  1. AWS アカウントの AWS アクセスキー ID を追加します。ID を確認するには、Log in to AWS を参照してください。
  2. 新しい AWS Secret Access Key の内容を提供します。
  3. プロキシーを有効にする必要がある場合は、プロキシー情報を入力します。

    • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL。
    • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
    • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
    • 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
  4. Red Hat OpenShift プルシークレットを入力します。プルシークレットをダウンロードするには、Download your Red Hat OpenShift pull secret を参照してください。
  5. SSH 秘密鍵SSH 公開鍵 を追加し、クラスターに接続できるようにします。既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。

Amazon Web Services でのクラスターの作成 または Amazon Web Services GovCloud でのクラスターの作成 の手順を完了することで、この認証情報を使用するクラスターを作成できます。

コンソールで認証情報を編集できます。このプロバイダー接続を使用してクラスターが作成された場合には、<cluster-namespace> からの <cluster-name>-aws-creds> シークレットが新規の認証情報に更新されます。

注記: クラスタープールが要求したクラスターでは、認証情報は更新されません。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.4.1.2.1. S3 シークレットの作成

Amazon Simple Storage Service (S3) シークレットを作成するには、コンソールから次のタスクを実行します。

  1. Add credential > AWS > S3 Bucket をクリックします。For Hosted Control Plane の場合をクリックすると、名前とネームスペースが提供されます。
  2. 表示される次のフィールドに情報を入力します。

    • bucket name: S3 バケットの名前を追加します。
    • aws_access_key_id: AWS アカウントの AWS アクセスキー ID を追加します。AWS にログインして ID を見つけます。
    • aws_secret_access_key: 新しい AWS シークレットアクセスキーの内容を指定します。
    • Region: AWS リージョンを入力します。
1.4.1.3. API を使用した不透明なシークレットの作成

API を使用して Amazon Web Services の不透明なシークレットを作成するには、次の例のような YAML プレビューウィンドウで YAML コンテンツを適用します。

kind: Secret
metadata:
    name: <managed-cluster-name>-aws-creds
    namespace: <managed-cluster-namespace>
type: Opaque
data:
    aws_access_key_id: $(echo -n "${AWS_KEY}" | base64 -w0)
    aws_secret_access_key: $(echo -n "${AWS_SECRET}" | base64 -w0)

注記:

  • 不透明なシークレットはコンソールに表示されません。
  • 不透明なシークレットは、選択したマネージドクラスターの namespace に作成されます。Hive は不透明なシークレットを使用してクラスターをプロビジョニングします。Red Hat Advanced Cluster Management コンソールを使用してクラスターをプロビジョニングすると、事前に作成された認証情報は、不透明なシークレットとしてマネージドクラスターの namespace にコピーされます。
1.4.1.4. 関連情報

1.4.2. Microsoft Azure の認証情報の作成

マルチクラスターエンジン Operator コンソールを使用して、Microsoft Azure または Microsoft Azure Government で Red Hat OpenShift Container Platform クラスターを作成および管理するには、認証情報が必要です。

必要なアクセス権限: 編集

注記: この手順は、マルチクラスターエンジン Operator を使用してクラスターを作成するための前提条件です。

1.4.2.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • デプロイされたマルチクラスターエンジン Operator ハブクラスター。
  • Azure で Kubernetes クラスターを作成できるようにするマルチクラスターエンジン Operator ハブクラスターのインターネットアクセス。
  • ベースドメインのリソースグループおよび Azure Service Principal JSON などの Azure ログイン認証情報。ログイン認証情報を取得するには、Microsoft Azure ポータル を参照してください。
  • Azure でクラスターがインストールできるようにするアカウントの権限。詳細は、How to configure Cloud Services および Azure アカウントの設定 を参照してください。
1.4.2.2. コンソールを使用した認証情報の管理

マルチクラスターエンジン Operator コンソールから認証情報を作成するには、コンソールで手順を実行します。ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー上、認証情報のホスト専用の namespace を作成します。

  1. オプション: 認証情報の ベース DNS ドメイン を追加します。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。
  2. クラスターの環境が AzurePublicCloud または、AzureUSGovernmentCloud であるかを選択します。この設定は Azure Government 環境とは異なるため、これが正しく設定されていることを確認します。
  3. Azure アカウントの ベースドメインリソースグループ名 を追加します。このエントリーは、Azure アカウントで作成したリソース名です。Azure インターフェイスで Home > DNS Zones を選択することで、ベースドメインのリソースグループ名を検索できます。ベースドメインリソースグループ名を見つけるには、Create an Azure service principal with the Azure CLI を参照してください。
  4. クライアント ID の内容を入力します。この値は、以下のコマンドを使用してサービスプリンシパルを作成すると、appId プロパティーとして設定されます。

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

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

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

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

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

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

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

    az account show
  8. プロキシーを有効にする場合は、プロキシー情報を入力します。

    • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL。
    • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
    • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
    • 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
  9. Red Hat OpenShift pull secret を入力します。プルシークレットをダウンロードするには、Download your Red Hat OpenShift pull secret を参照してください。
  10. クラスターへの接続に使用する SSH 秘密鍵SSH 公開鍵 を追加します。既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。

Microsoft Azure でのクラスターの作成 の手順を実行して、この認証情報を使用するクラスターを作成します。

コンソールで認証情報を編集できます。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.4.2.3. API を使用した不透明なシークレットの作成

コンソールの代わりに API を使用して Microsoft Azure の不透明なシークレットを作成するには、次の例のような YAML プレビューウィンドウで YAML コンテンツを適用します。

kind: Secret
metadata:
    name: <managed-cluster-name>-azure-creds
    namespace: <managed-cluster-namespace>
type: Opaque
data:
    baseDomainResourceGroupName: $(echo -n "${azure_resource_group_name}" | base64 -w0)
    osServicePrincipal.json: $(base64 -w0 "${AZURE_CRED_JSON}")

注記:

  • 不透明なシークレットはコンソールに表示されません。
  • 不透明なシークレットは、選択したマネージドクラスターの namespace に作成されます。Hive は不透明なシークレットを使用してクラスターをプロビジョニングします。Red Hat Advanced Cluster Management コンソールを使用してクラスターをプロビジョニングすると、事前に作成された認証情報は、不透明なシークレットとしてマネージドクラスターの namespace にコピーされます。
1.4.2.4. 関連情報

1.4.3. Google Cloud Platform の認証情報の作成

マルチクラスターエンジン Operator コンソールを使用して、Google Cloud Platform (GCP) で Red Hat OpenShift Container Platform クラスターを作成および管理するには、認証情報が必要です。

必要なアクセス権限: 編集

注記: この手順は、マルチクラスターエンジン Operator を使用してクラスターを作成するための前提条件です。

1.4.3.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • デプロイされたマルチクラスターエンジン Operator ハブクラスター
  • GCP で Kubernetes クラスターを作成できるようにするマルチクラスターエンジン Operator ハブクラスターのインターネットアクセス
  • ユーザーの Google Cloud Platform プロジェクト ID および Google Cloud Platform サービスアカウント JSON キーなど、GCP ログインの認証情報。Creating and managing projects を参照してください。
  • GCP でクラスターがインストールできるようにするアカウントの権限。アカウントの設定方法は、GCP プロジェクトの設定 を参照してください。
1.4.3.2. コンソールを使用した認証情報の管理

マルチクラスターエンジン Operator コンソールから認証情報を作成するには、コンソールで手順を実行します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー上、認証情報のホスト専用の namespace を作成します。

オプションで、認証情報の ベース DNS ドメイン を追加できます。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。以下の手順を参照してください。

  1. GCP アカウントの Google Cloud Platform project ID を追加します。設定を取得するには、Log in to GCP を参照してください。
  2. Google Cloud Platform service account JSON key を追加します。サービスアカウントの JSON キーを作成するには、サービスアカウントの作成 に関するドキュメントを参照してください。GCP コンソールの手順に従います。
  3. 新しい Google Cloud Platform サービスアカウントの JSON キー の内容を提供します。
  4. プロキシーを有効にする場合は、プロキシー情報を入力します。

    • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL。
    • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
    • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
    • 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
  5. Red Hat OpenShift プルシークレットを入力します。プルシークレットをダウンロードするには、Download your Red Hat OpenShift pull secret を参照してください。
  6. クラスターにアクセスできるように SSH 秘密鍵SSH 公開鍵 を追加します。既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。

Google Cloud Platform でのクラスターの作成 の手順を実行することで、クラスターの作成時にこの接続を使用できます。

コンソールで認証情報を編集できます。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.4.3.3. API を使用した不透明なシークレットの作成

コンソールの代わりに API を使用して Google Cloud Platform の不透明なシークレットを作成するには、次の例のような YAML プレビューウィンドウで YAML コンテンツを適用します。

kind: Secret
metadata:
    name: <managed-cluster-name>-gcp-creds
    namespace: <managed-cluster-namespace>
type: Opaque
data:
    osServiceAccount.json: $(base64 -w0 "${GCP_CRED_JSON}")

注記:

  • 不透明なシークレットはコンソールに表示されません。
  • 不透明なシークレットは、選択したマネージドクラスターの namespace に作成されます。Hive は不透明なシークレットを使用してクラスターをプロビジョニングします。Red Hat Advanced Cluster Management コンソールを使用してクラスターをプロビジョニングすると、事前に作成された認証情報は、不透明なシークレットとしてマネージドクラスターの namespace にコピーされます。
1.4.3.4. 関連情報

Google Cloud Platform の認証情報の作成 に戻ります。

1.4.4. VMware vSphere の認証情報の作成

マルチクラスターエンジン Operator コンソールを使用して、VMware vSphere で Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、認証情報が必要です。

必要なアクセス権限: 編集

注記:

  • マルチクラスターエンジンオペレータを使用してクラスターを作成する前に、VMware vSphere の認証情報を作成する必要があります。
  • OpenShift Container Platform バージョン 4.5.x 以降のみがサポートされます。
1.4.4.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • OpenShift Container Platform バージョン 4.6 以降にデプロイされたハブクラスター。
  • VMware vSphere に Kubernetes クラスターを作成できるようにするハブクラスターのインターネットアクセス。
  • インストーラーでプロビジョニングされるインフラストラクチャーを使用する場合に OpenShift Container Platform 向けに設定された VMware vSphere ログイン認証情報および vCenter 要件。カスタマイズを使用した vSphere へのクラスターのインストール を参照してください。これらの認証除法には、以下の情報が含まれます。

    • vCenter アカウントの権限
    • クラスターリソース
    • DHCP が利用できる
    • 時間を同期した ESXi ホスト (例: NTP)
1.4.4.2. コンソールを使用した認証情報の管理

マルチクラスターエンジン Operator コンソールから認証情報を作成するには、コンソールで手順を実行します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー上、認証情報のホスト専用の namespace を作成します。

オプションで、認証情報の ベース DNS ドメイン を追加できます。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。以下の手順を参照してください。

  1. VMware vCenter サーバーの完全修飾ホスト名または IP アドレス を追加します。値は vCenter サーバーのルート CA 証明書に定義する必要があります。可能な場合は、完全修飾ホスト名を使用します。
  2. VMware vCenter のユーザー名 を追加します。
  3. VMware vCenter パスワード を追加します。
  4. VMware vCenter ルート CA 証明書 を追加します。

    1. VMware vCenter サーバー (https://<vCenter_address>/certs/download.zip) から download.zip として証明書をダウンロードできます。vCenter_address は、vCenter サーバーのアドレスに置き換えます。
    2. download.zip のパッケージを展開します。
    3. 拡張子が .0certs/<platform> ディレクトリーの証明書を使用します。

      ヒント: ls certs/<platform> コマンドを使用して、お使いのプラットフォームで使用可能な全証明書を一覧表示できます。

      <platform> は、linmac、または win など、お使いのプラットフォームに置き換えます。

      例: certs/lin/3a343545.0

      ベストプラクティス: cat certs/lin/*.0 > ca.crt コマンドを実行して、拡張子 .0 を持つ複数の証明書をリンクします。

    4. VMware vSphere クラスター名 を追加します。
    5. VMware vSphere データセンター を追加します。
    6. VMware vSphere デフォルトデータストア を追加します。
    7. VMware vSphere ディスクタイプ を追加します。
    8. VMware vSphere フォルダー を追加します。
    9. VMware vSphere リソースプール を追加します。
  5. オフラインインストールのみ: Configuration for disconnected installation サブセクションのフィールドに必要な情報を入力します。

    • Image content source: この値には、オフラインのレジストリーパスが含まれます。このパスには、オフラインインストールに使用する全インストールイメージのホスト名、ポート、レジストリーパスが含まれます。たとえば、repository.com:5000/openshift/ocp-release となります。

      このパスは、Red Hat OpenShift Container Platform リリースイメージに対して、install-config.yaml のイメージコンテンツソースポリシーのマッピングを作成します。たとえば、repository.com:5000 は以下の imageContentSource コンテンツを作成します。

      - mirrors:
        - registry.example.com:5000/ocp4
        source: quay.io/openshift-release-dev/ocp-release-nightly
      - mirrors:
        - registry.example.com:5000/ocp4
        source: quay.io/openshift-release-dev/ocp-release
      - mirrors:
        - registry.example.com:5000/ocp4
        source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
    • Additional trust bundle: この値で、ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツを指定します。

      注記: 非接続環境にあるハブクラスターからマネージドクラスターをデプロイして、インストール後の設定を自動的にインポートする場合は、YAML エディターを使用してイメージコンテンツソースポリシーを install-config.yaml ファイルに追加します。エントリーの例を以下に示します。

      - mirrors:
        - registry.example.com:5000/rhacm2
        source: registry.redhat.io/rhacm2
  6. プロキシーを有効にする場合は、プロキシー情報を入力します。

    • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL。
    • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
    • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
    • 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
  7. Red Hat OpenShift プルシークレットを入力します。プルシークレットをダウンロードするには、Download your Red Hat OpenShift pull secret を参照してください。
  8. SSH 秘密鍵SSH 公開鍵 を追加し、クラスターに接続できるようにします。

    既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。

VMware vSphere でのクラスターの作成 の手順を完了することで、この認証情報を使用するクラスターを作成できます。

コンソールで認証情報を編集できます。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.4.4.3. API を使用した不透明なシークレットの作成

コンソールの代わりに API を使用して VMware vSphere の不透明なシークレットを作成するには、次の例のような YAML プレビューウィンドウで YAML コンテンツを適用します。

kind: Secret
metadata:
    name: <managed-cluster-name>-vsphere-creds
    namespace: <managed-cluster-namespace>
type: Opaque
data:
    username: $(echo -n "${VMW_USERNAME}" | base64 -w0)
    password.json: $(base64 -w0 "${VMW_PASSWORD}")

注記:

  • 不透明なシークレットはコンソールに表示されません。
  • 不透明なシークレットは、選択したマネージドクラスターの namespace に作成されます。Hive は不透明なシークレットを使用してクラスターをプロビジョニングします。Red Hat Advanced Cluster Management コンソールを使用してクラスターをプロビジョニングすると、事前に作成された認証情報は、不透明なシークレットとしてマネージドクラスターの namespace にコピーされます。
1.4.4.4. 関連情報

1.4.5. Red Hat OpenStack の認証情報の作成

マルチクラスターエンジン Operator コンソールを使用して、Red Hat OpenStack Platform で Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、認証情報が必要です。

注記:

  • マルチクラスターエンジンオペレーターを使用してクラスターを作成する前に、Red Hat OpenStack Platform の認証情報を作成する必要があります。
  • OpenShift Container Platform バージョン 4.5.x 以降のみがサポートされます。
1.4.5.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • OpenShift Container Platform バージョン 4.6 以降にデプロイされたハブクラスター。
  • Red Hat OpenStack Platform で Kubernetes クラスターを作成できるようにするハブクラスターのインターネットアクセス。
  • インストーラーでプロビジョニングされるインフラストラクチャーを使用する場合に OpenShift Container Platform 向けに設定された Red Hat OpenStack Platform ログイン認証情報および Red Hat OpenStack Platform の要件。カスタマイズを使用した OpenStack へのクラスターのインストール を参照してください。
  • CloudStack API にアクセスするための clouds.yaml ファイルをダウンロードまたは作成する。clouds.yaml ファイルで以下を行います。

    • 使用する cloud auth セクション名を決定します。
    • username 行の直後に、password の行を追加します。
1.4.5.2. コンソールを使用した認証情報の管理

マルチクラスターエンジン Operator コンソールから認証情報を作成するには、コンソールで手順を実行します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。セキュリティーと利便性を強化するために、認証情報をホストするためだけに namespace を作成できます。

  1. オプション: 認証情報のベース DNS ドメインを追加できます。ベース DNS ドメインを追加すると、この認証情報を使用してクラスターを作成するときに、正しいフィールドに自動的に入力されます。
  2. Red Hat OpenStack Platform の clouds.yaml ファイルの内容を追加します。パスワードを含む clouds.yaml ファイルの内容で、Red Hat OpenStack Platform サーバーへの接続に必要な情報を提供します。ファイルの内容には、username の直後に新たに追加したパスワードを含める必要があります。
  3. Red Hat OpenStack Platform クラウド名を追加します。このエントリーは、Red Hat OpenStack Platform サーバーへの通信確立に使用する clouds.yaml の cloud セクションで指定した名前です。
  4. オプション: 内部認証局を使用する設定の場合は、内部 CA 証明書 フィールドに証明書を入力して、証明書情報で clouds.yaml を自動的に更新します。
  5. オフラインインストールのみ: Configuration for disconnected installation サブセクションのフィールドに必要な情報を入力します。

    • Cluster OS image: この値には、Red Hat OpenShift Container Platform クラスターマシンに使用するイメージの URL が含まれます。
    • イメージコンテンツソース: この値には、オフラインのレジストリーパスが含まれます。このパスには、オフラインインストールに使用する全インストールイメージのホスト名、ポート、レジストリーパスが含まれます。たとえば、repository.com:5000/openshift/ocp-release となります。

      このパスは、Red Hat OpenShift Container Platform リリースイメージに対して、install-config.yaml のイメージコンテンツソースポリシーのマッピングを作成します。たとえば、repository.com:5000 は以下の imageContentSource コンテンツを作成します。

      - mirrors:
        - registry.example.com:5000/ocp4
        source: quay.io/openshift-release-dev/ocp-release-nightly
      - mirrors:
        - registry.example.com:5000/ocp4
        source: quay.io/openshift-release-dev/ocp-release
      - mirrors:
        - registry.example.com:5000/ocp4
        source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
    • Additional trust bundle: この値で、ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツを指定します。

      注記: 非接続環境にあるハブクラスターからマネージドクラスターをデプロイして、インストール後の設定を自動的にインポートする場合は、YAML エディターを使用してイメージコンテンツソースポリシーを install-config.yaml ファイルに追加します。エントリーの例を以下に示します。

      - mirrors:
        - registry.example.com:5000/rhacm2
        source: registry.redhat.io/rhacm2
  6. プロキシーを有効にする必要がある場合は、プロキシー情報を入力します。

    • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL。
    • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
    • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
    • 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
  7. Red Hat OpenShift プルシークレットを入力します。プルシークレットをダウンロードするには、Download your Red Hat OpenShift pull secret を参照してください。
  8. SSH 秘密鍵と SSH 公開鍵を追加し、クラスターに接続できるようにします。既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。
  9. Create をクリックします。
  10. 新規の認証情報を確認し、Add をクリックします。認証情報を追加すると、認証情報のリストに追加されます。

Red Hat OpenStack Platform でのクラスターの作成 の手順を実行して、この認証情報を使用するクラスターを作成します。

コンソールで認証情報を編集できます。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.4.5.3. API を使用した不透明なシークレットの作成

コンソールの代わりに API を使用して Red Hat OpenStack Platform の不透明なシークレットを作成するには、次の例のような YAML プレビューウィンドウで YAML コンテンツを適用します。

kind: Secret
metadata:
    name: <managed-cluster-name>-osp-creds
    namespace: <managed-cluster-namespace>
type: Opaque
data:
    clouds.yaml: $(base64 -w0 "${OSP_CRED_YAML}") cloud: $(echo -n "openstack" | base64 -w0)

注記:

  • 不透明なシークレットはコンソールに表示されません。
  • 不透明なシークレットは、選択したマネージドクラスターの namespace に作成されます。Hive は不透明なシークレットを使用してクラスターをプロビジョニングします。Red Hat Advanced Cluster Management コンソールを使用してクラスターをプロビジョニングすると、事前に作成された認証情報は、不透明なシークレットとしてマネージドクラスターの namespace にコピーされます。
1.4.5.4. 関連情報

1.4.6. Red Hat Virtualization の認証情報の作成

マルチクラスターエンジン Operator コンソールを使用して、Red Hat Virtualization で Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、認証情報が必要です。

注記: この手順は、マルチクラスターエンジン Operator でクラスターを作成する前に実行する必要があります。

1.4.6.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • OpenShift Container Platform バージョン 4.7 以降にデプロイされたハブクラスター。
  • Red Hat Virtualization で Kubernetes クラスターを作成できるようにするハブクラスターのインターネットアクセス。
  • 設定済み Red Hat Virtualization 環境の Red Hat Virtualization ログイン認証情報。Red Hat Virtualization ドキュメントの インストールガイド を参照してください。以下のリストは、必要な情報を示しています。

    • oVirt URL
    • oVirt 完全修飾ドメイン名 (FQDN)
    • oVirt ユーザー名
    • oVirt パスワード
    • oVirt CA/証明書
  • オプション: プロキシーを有効にした場合にはプロキシー情報。
  • Red Hat OpenShift Container Platform のプルシークレット情報。Pull secret からプルシークレットをダウンロードします。
  • 最終的なクラスターの情報を転送するための SSH 秘密鍵と公開鍵。
  • oVirt でクラスターをインストールできるようにするアカウントの権限。
1.4.6.2. コンソールを使用した認証情報の管理

マルチクラスターエンジン Operator コンソールから認証情報を作成するには、コンソールで手順を実行します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー向上のため、認証情報のホスト専用の namespace を作成します。

  1. 新しい認証情報の基本情報を追加します。オプションで、この認証情報を使用してクラスターを作成すると自動的に正しいフィールドにデータが投入される Base DNS ドメインを追加できます。認証情報に追加しない場合は、クラスターの作成時に追加できます。
  2. Red Hat Virtualization 環境に必要な情報を追加します。
  3. プロキシーを有効にする必要がある場合は、プロキシー情報を入力します。

    • HTTP Proxy URL: HTTP トラフィックのプロキシーとして使用する URL。
    • HTTPS Proxy URL: HTTPS トラフィックに使用する必要のあるセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
    • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  4. Red Hat OpenShift Container Platform プルシークレットを入力します。Pull secret からプルシークレットをダウンロードします。
  5. SSH 秘密鍵と SSH 公開鍵を追加し、クラスターに接続できるようにします。既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。詳細は、クラスターノードの SSH アクセス用のキーペアの生成 を参照してください。
  6. 新規の認証情報を確認し、Add をクリックします。認証情報を追加すると、認証情報の一覧に追加されます。

Red Hat Virtualization でのクラスターの作成 の手順を実行して、この認証情報を使用するクラスターを作成します。

コンソールで認証情報を編集できます。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.4.7. Red Hat OpenShift Cluster Manager の認証情報の作成

クラスターを検出できるように OpenShift Cluster Manager の認証情報を追加します。

必要なアクセス権限: 管理者

1.4.7.1. 前提条件

console.redhat.com アカウントへのアクセスが必要です。console.redhat.com/openshift/token から取得できる値が後で必要になります。

1.4.7.2. コンソールを使用した認証情報の管理

クラスター検出用の認証情報を追加する必要があります。マルチクラスターエンジン Operator コンソールから認証情報を作成するには、コンソールで手順を実行します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー上、認証情報のホスト専用の namespace を作成します。

OpenShift Cluster Manager API トークンは、console.redhat.com/openshift/token から取得できます。

コンソールで認証情報を編集できます。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

認証情報が削除されるか、OpenShift Cluster Manager API トークンの有効期限が切れるか、取り消されると、関連付けられた検出クラスターが削除されます。

1.4.8. Ansible Automation Platform の認証情報の作成

マルチクラスターエンジン Operator コンソールを使用して、Red Hat Ansible Automation Platform を使用する Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、認証情報が必要です。

必要なアクセス権限: 編集

注記: この手順は、自動化テンプレートを作成して、クラスターで自動化を有効にする前に、実行する必要があります。

1.4.8.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • デプロイされたマルチクラスターエンジン Operator ハブクラスター
  • マルチクラスターエンジン Operator ハブクラスターのインターネットアクセス
  • Ansible Automation Platform ホスト名と OAuth トークンを含む Ansible ログイン認証情報。Ansible Automation Platform の認証情報 を参照してください。
  • ハブクラスターのインストールおよび Ansible 操作をできるようにするアカウント権限。Ansible ユーザー の詳細を確認してください。
1.4.8.2. コンソールを使用した認証情報の管理

マルチクラスターエンジン Operator コンソールから認証情報を作成するには、コンソールで手順を実行します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー上、認証情報のホスト専用の namespace を作成します。

Ansible 認証情報の作成時に指定する Ansible トークンとホストの URL は、認証情報の編集時にその認証情報を使用する自動化向けに、自動で更新されます。更新は、クラスターライフサイクル、ガバナンス、およびアプリケーション管理の自動化に関連するものなど、Ansible 認証情報を使用する自動化にコピーされます。これにより、認証情報の更新後も自動化が引き続き実行されます。

コンソールで認証情報を編集できます。Ansible 認証情報は、認証情報の更新時に、対象の認証情報を使用する自動化で、自動的に更新されあす。

マネージドクラスターで実行する Ansible Automation Platform タスクの設定 の手順を完了することで、この認証情報を使用する Ansible ジョブを作成できます。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.4.9. オンプレミス環境の認証情報の作成

コンソールを使用してオンプレミス環境で Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、認証情報が必要です。認証情報では、クラスターに使用される接続を指定します。

必要なアクセス権限: 編集

1.4.9.1. 前提条件

認証情報を作成する前に、以下の前提条件を満たす必要があります。

  • デプロイされたハブクラスター。
  • インフラストラクチャー環境に Kubernetes クラスターを作成できるようにするハブクラスターのインターネットアクセス。
  • オフライン環境では、クラスター作成用のリリースイメージをコピーできるミラーレジストリーを設定している。詳細は、OpenShift Container Platform ドキュメントの 非接続インストールのイメージのミラーリング を参照してください。
  • オンプレミス環境でのクラスターのインストールをサポートするアカウントの権限。
1.4.9.2. コンソールを使用した認証情報の管理

コンソールから認証情報を作成するには、コンソールで手順を完了します。

ナビゲーションメニューから開始します。Credentials をクリックし、既存の認証情報オプションから選択します。ヒント: 便宜上およびセキュリティー上、認証情報のホスト専用の namespace を作成します。

  1. 認証情報の種類に Host inventory を選択します。
  2. オプションで、認証情報の ベース DNS ドメイン を追加できます。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。DNS ドメインを追加していない場合は、クラスターの作成時に追加できます。
  3. Red Hat OpenShift pull secret を入力します。このプルシークレットは、クラスターを作成してこの認証情報を指定すると、自動的に入力されます。Pull secret からプルシークレットをダウンロードします。プルシークレットの詳細は、イメージプルシークレットの使用 を参照してください。
  4. SSH public key を入力します。この SSH public key クラスターを作成してこの認証情報を指定するときにも自動的に入力されます。
  5. Add を選択して認証情報を作成します。

オンプレミス環境でのクラスターの作成 の手順を完了することで、この認証情報を使用するクラスターを作成できます。

認証情報を使用するクラスターの管理を終了する場合は、認証情報を削除して認証情報内にある情報を保護します。Actions を選択して、一括削除するか、削除する認証情報の横にあるオプションメニューを選択します。

1.5. クラスターライフサイクルの概要

マルチクラスターエンジン Operator は、OpenShift Container Platform および Red Hat Advanced Cluster Management ハブクラスターにクラスター管理機能を提供するクラスターライフサイクル Operator です。マルチクラスターエンジン Operator は、クラスターフリート管理を強化し、クラウドおよびデータセンター全体の OpenShift Container Platform クラスターライフサイクル管理をサポートするソフトウェア Operator です。Red Hat Advanced Cluster Management の有無にかかわらず、マルチクラスターエンジン Operator を使用できます。Red Hat Advanced Cluster Management は、マルチクラスターエンジン Operator を自動的にインストールし、さらにマルチクラスター機能を提供します。

以下のドキュメントを参照してください。

1.5.1. クラスターライフサイクルのアーキテクチャー

クラスターライフサイクルには、ハブクラスターマネージドクラスター の 2 種類のクラスターが必要です。

ハブクラスターは、マルチクラスターエンジン Operator が自動的にインストールされる OpenShift Container Platform (または Red Hat Advanced Cluster Management) メインクラスターです。ハブクラスターを使用して他の Kubernetes クラスターの作成、管理、および監視を行うことができます。ハブクラスターを使用してクラスターを作成できますが、ハブクラスターが管理する既存のクラスターをインポートすることもできます。

マネージドクラスターを作成すると、クラスターは Red Hat OpenShift Container Platform クラスターインストーラーと Hive リソースを使用して作成されます。OpenShift Container Platform インストーラーでクラスターをインストールするプロセスについての詳細は、OpenShift Container Platform ドキュメントの OpenShift Container Platform インストールの概要 を参照してください。

次の図は、クラスター管理に使用する Kubernetes Operator 用のマルチクラスターエンジンと共にインストールされるコンポーネントを示しています。

Cluster lifecycle architecture diagram

クラスターライフサイクル管理のアーキテクチャーのコンポーネントには、以下の項目が含まれます。

1.5.1.1. ハブクラスター
  • マネージドクラスターのインポートコントローラー は、klusterlet Operator をマネージドクラスターにデプロイします。
  • Hive コントローラー は、Kubernetes Operator 用のマルチクラスターエンジンを使用して作成したクラスターをプロビジョニングします。また、Hive コントローラーは、Kubernetes Operator 用のマルチクラスターエンジンによって作成されたマネージドクラスターを破棄します。
  • クラスターキュレーターコントローラー は、マネージドクラスターの作成またはアップグレード時にクラスターインフラストラクチャー環境を設定するためのプレフックまたはポストフックとして Ansible ジョブを作成します。
  • マネージドクラスターアドオンがハブクラスターで有効になると、その アドオンハブコントローラー がハブクラスターにデプロイされます。アドオンハブコントローラー は、アドオンエージェント をマネージドクラスターにデプロイします。
1.5.1.2. マネージドクラスター
  • klusterlet Operator マネージドクラスターに登録およびワークコントローラーをデプロイします。
  • 登録エージェント は、マネージドクラスターとマネージドクラスターアドオンをハブクラスターに登録します。また、登録エージェントは、マネージドクラスターとマネージドクラスターアドオンのステータスを維持します。次のパーミッションがクラスターロール内に自動的に作成され、マネージドクラスターがハブクラスターにアクセスできるようになります。

    • エージェントは、ハブクラスターが管理する所有クラスターを取得または更新できます。
    • エージェントが、ハブクラスターが管理する所有クラスターのステータスを更新できるようにします。
    • エージェントが証明書をローテーションできるようにします。
    • エージェントが coordination.k8s.io リースを get または update できるようにします。
    • エージェントがマネージドクラスターアドオンを get できるようにします。
    • エージェントがマネージドクラスターアドオンのステータスを更新できるようにします。
  • ワークエージェント は、アドオンエージェントをマネージドクラスターに適用します。マネージドクラスターによるハブクラスターへのアクセスを許可する権限は、Clusterrole 内に自動的に作成され、エージェントはイベントをハブクラスターに送信できます。

クラスターの追加と管理を続行するには、クラスターライフサイクルの概要 を参照してください。

1.5.2. リリースイメージ

マルチクラスターエンジン Operator を使用してプロバイダーにクラスターを作成する場合は、新しいクラスターに使用するリリースイメージを指定する必要があります。リリースイメージでは、クラスターのビルドに使用する Red Hat OpenShift Container Platform のバージョンを指定します。デフォルトでは、clusterImageSets リソースは、サポートされているリリースイメージのリストを取得するために OpenShift Container Platform によって使用されます。

acm-hive-openshift-releases GitHub リポジトリーには、 OpenShift Container Platform でサポートされる clusterImageSets の YAML ファイルが含まれています。この Git リポジトリーの内容は、OpenShift Container Platform のバージョンとリリースチャネル値 (faststablecandidate) に基づいてイメージを分離するディレクトリー構造を使用して編成されています。Git リポジトリー内のブランチは OpenShift Container Platform リリースにマップされ、各ブランチには、対応する OpenShift Container Platform リリースでサポートされる clusterImageSets YAML ファイルが含まれます。

マルチクラスターエンジンオペレーターにおいて、ハブクラスター上で実行されるクラスターイメージセットコントローラー。このコントローラーは、設定された間隔で acm-hive-openshift-releases GitHub リポジトリー にクエリーを実行して、新しい clusterImageSets YAML ファイルを取得します。デフォルトでは、コントローラーは backplane-2.3 ブランチの fast チャネルと同期します。

次のオプションを使用して clusterImageSets を設定できます。

  • オプション 1: クラスターの作成時にコンソールで使用する特定の ClusterImageSet のイメージ参照を指定します。指定する新規エントリーはそれぞれ保持され、将来のすべてのクラスタープロビジョニングで利用できます。次のエントリーの例を参照してください。

    quay.io/openshift-release-dev/ocp-release:4.12.8-x86_64
  • オプション 2: GitHub リポジトリー acm-hive-openshift-releases から YAML ファイル ClusterImageSets を手動で作成し、適用します。
  • オプション 3: cluster-image-set-controller GitHub リポジトリーREADME.md に従って、フォークされた GitHub リポジトリーからの clusterImageSets の自動更新を有効にします。

クラスターイメージセットコントローラーは、clusterImageSets の Synchronization に他の Git リポジトリーを使用するように設定できます。コントローラーは、multicluster-engine namespace の cluster-image-set-git-repo ConfigMap から Git リポジトリー設定を読み取ります。この ConfigMap を使用して、コントローラーによる clusterImageSets の同期を一時停止できます。これは、以下に示すように、gitRepoUrl フィールドに存在しない/無効な URL を指定することによって実現されます。

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-image-set-git-repo
  namespace: multicluster-engine
data:
  gitRepoUrl: https://github.com/stolostron/bad-acm-hive-openshift-releases.git
  gitRepoBranch: backplane-2.3
  gitRepoPath: clusterImageSets
  channel: fast

注記: コンソールでクラスターの作成時に選択できるのは、visible: 'true' のラベルが付いたリリースイメージのみです。ClusterImageSet リソースのこのラベルの例は以下の内容で提供されます。

apiVersion: config.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: fast
    visible: 'true'
  name: img4.13.8-x86-64-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.12.8-x86_64

追加のリリースイメージは保管されますが、コンソールには表示されません。利用可能なすべてのリリースイメージを表示するには、kubectl get clusterimageset を実行します。

リリースイメージの詳細については、読み続けてください。

1.5.2.1. リリースイメージの指定

マルチクラスターエンジン Operator を使用してプロバイダーにクラスターを作成する場合は、新しいクラスターに使用するリリースイメージを指定する必要があります。リリースイメージでは、クラスターのビルドに使用する Red Hat OpenShift Container Platform のバージョンを指定します。デフォルトでは、clusterImageSets リソースは、サポートされているリリースイメージのリストを取得するために OpenShift Container Platform によって使用されます。

ClusterImageSet の検索ClusterImageSet の設定異なるアーキテクチャーにクラスターをデプロイするためのリリースイメージの作成

1.5.2.1.1. ClusterImageSets の検索

リリースイメージを参照するファイルは acm-hive-openshift-releases GitHub リポジトリー GitHub リポジトリーで維持される YAML ファイルです。これらのファイルは、コンソールで利用可能なリリースイメージの一覧を作成します。これには、OpenShift Container Platform における最新の fast チャネルイメージが含まれます。

コンソールには、OpenShift Container Platform の 3 つの最新バージョンの最新リリースイメージのみが表示されます。たとえば、コンソールオプションに以下のリリースイメージが表示される可能性があります。

  • quay.io/openshift-release-dev/ocp-release:4.6.23-x86_64
  • quay.io/openshift-release-dev/ocp-release:4.10.1-x86_64

最新のリリースイメージでクラスターを作成することが推奨されるため、コンソールには最新バージョンのみがあります。特定バージョンのクラスター作成が必要となる場合があります。そのため、古いバージョンが利用可能となっています。

注意: コンソールでクラスターを作成するときに選択できるのは visible: 'true' ラベルが表示されているリリースイメージのみです。ClusterImageSet リソースのこのラベルの例は以下の内容で提供されます。

apiVersion: config.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: fast
    visible: 'true'
  name: img4.10.1-x86-64-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.10.1-x86_64

追加のリリースイメージは保管されますが、コンソールには表示されません。利用可能なすべてのリリースイメージを表示するには、CLI で kubectl get clusterimageset を実行します。

リポジトリーには、clusterImageSets ディレクトリーが含まれています。これは、リリースイメージを操作するときに使用するディレクトリーです。clusterImageSets ディレクトリーには以下のディレクトリーが含まれます。

  • Fast: サポート対象の各 OpenShift Container Platform バージョンのリリースイメージの内、最新バージョンを参照するファイルが含まれます。このフォルダー内のリリースイメージはテストされ、検証されており、サポートされます。
  • Releases: 各 OpenShift Container Platform バージョン (stable、fast、および candidate チャネル) のリリースイメージをすべて参照するファイルが含まれます。注記: このリリースはすべてテストされ、安定していると判別されているわけではありません。

    • Stable: サポート対象の各 OpenShift Container Platform バージョンのリリースイメージの内、最新の安定版 2 つを参照するファイルが含まれます。

注記: デフォルトでは、リリースイメージの現在のリストは 1 時間ごとに更新されます。製品をアップグレードした後、リストに製品の新しいバージョンの推奨リリースイメージバージョンが反映されるまでに最大 1 時間かかる場合があります。

1.5.2.1.2. clusterImageSets の設定

次のオプションを使用して clusterImageSets を設定できます。

  • オプション 1: クラスターの作成時にコンソールで使用する特定の ClusterImageSet のイメージ参照を指定します。指定する新規エントリーはそれぞれ保持され、将来のすべてのクラスタープロビジョニングで利用できます。次のエントリーの例を参照してください。

    quay.io/openshift-release-dev/ocp-release:4.6.8-x86_64
  • オプション 2: GitHub リポジトリー acm-hive-openshift-releases から YAML ファイル ClusterImageSets を手動で作成し、適用します。
  • オプション 3: cluster-image-set-controller GitHub リポジトリーREADME.md に従って、フォークされた GitHub リポジトリーからの clusterImageSets の自動更新を有効にします。
1.5.2.1.3. 別のアーキテクチャーにクラスターをデプロイするためのリリースイメージの作成

両方のアーキテクチャーのファイルを含むリリースイメージを手動で作成することで、ハブクラスターのアーキテクチャーとは異なるアーキテクチャーでクラスターを作成できます。

たとえば、ppc64leaarch64、または s390x アーキテクチャーで実行されているハブクラスターから x86_64 クラスターを作成する必要があるとします。両方のファイルセットでリリースイメージを作成する場合に、新規のリリースイメージにより OpenShift Container Platform リリースレジストリーがマルチアーキテクチャーイメージマニフェストを提供できるので、クラスターの作成は成功します。

OpenShift Container Platform 4.11 以降は、デフォルトで複数のアーキテクチャーをサポートします。以下の clusterImageSet を使用してクラスターをプロビジョニングできます。

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: fast
    visible: 'true'
  name: img4.13.0-multi-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.12.0-multi

複数のアーキテクチャーをサポートしない OpenShift Container Platform イメージのリリースイメージを作成するには、アーキテクチャータイプについて以下のような手順を実行します。

  1. OpenShift Container Platform リリースレジストリー から、x86_64s390xaarch64、および ppc64le リリースイメージを含む マニフェスト一覧 を作成します。

    1. 以下のコマンド例を使用して、Quay リポジトリー から環境内の両方のアーキテクチャーのマニフェストリストをプルします。

      podman pull quay.io/openshift-release-dev/ocp-release:4.10.1-x86_64
      podman pull quay.io/openshift-release-dev/ocp-release:4.10.1-ppc64le
      podman pull quay.io/openshift-release-dev/ocp-release:4.10.1-s390x
      podman pull quay.io/openshift-release-dev/ocp-release:4.10.1-aarch64
    2. イメージを管理するプライベートリポジトリーにログインします。

      podman login <private-repo>

      private-repo は、リポジトリーへのパスに置き換えます。

    3. 環境に適用される以下のコマンドを実行して、リリースイメージマニフェストをプライベートリポジトリーに追加します。

      podman push quay.io/openshift-release-dev/ocp-release:4.10.1-x86_64 <private-repo>/ocp-release:4.10.1-x86_64
      podman push quay.io/openshift-release-dev/ocp-release:4.10.1-ppc64le <private-repo>/ocp-release:4.10.1-ppc64le
      podman push quay.io/openshift-release-dev/ocp-release:4.10.1-s390x <private-repo>/ocp-release:4.10.1-s390x
      podman push quay.io/openshift-release-dev/ocp-release:4.10.1-aarch64 <private-repo>/ocp-release:4.10.1-aarch64

      private-repo は、リポジトリーへのパスに置き換えます。

    4. 新規情報のマニフェストを作成します。

      podman manifest create mymanifest
    5. 両方のリリースイメージへの参照をマニフェスト一覧に追加します。

      podman manifest add mymanifest <private-repo>/ocp-release:4.10.1-x86_64
      podman manifest add mymanifest <private-repo>/ocp-release:4.10.1-ppc64le
      podman manifest add mymanifest <private-repo>/ocp-release:4.10.1-s390x
      podman manifest add mymanifest <private-repo>/ocp-release:4.10.1-aarch64

      private-repo は、リポジトリーへのパスに置き換えます。

    6. マニフェストリストの一覧を既存のマニフェストにマージします。

      podman manifest push mymanifest docker://<private-repo>/ocp-release:4.10.1

      private-repo は、リポジトリーへのパスに置き換えます。

  2. ハブクラスターで、リポジトリーのマニフェストを参照するリリースイメージを作成します。

    1. 以下の例のような情報を含む YAML ファイルを作成します。

      apiVersion: hive.openshift.io/v1
      kind: ClusterImageSet
      metadata:
        labels:
          channel: fast
          visible: "true"
        name: img4.10.1-appsub
      spec:
        releaseImage: <private-repo>/ocp-release:4.10.1

      private-repo は、リポジトリーへのパスに置き換えます。

    2. ハブクラスターで以下のコマンドを実行し、変更を適用します。

      oc apply -f <file-name>.yaml

      file-name を、先の手順で作成した YAML ファイルの名前に置き換えます。

  3. OpenShift Container Platform クラスターの作成時に新規リリースイメージを選択します。
  4. Red Hat Advanced Cluster Management コンソールを使用してマネージドクラスターをデプロイする場合は、クラスター作成のプロセス時に Architecture フィールドにマネージドクラスターのアーキテクチャーを指定します。

作成プロセスでは、マージされたリリースイメージを使用してクラスターを作成します。

1.5.2.2. 接続時におけるリリースイメージのカスタム一覧の管理

すべてのクラスターに同じリリースイメージを使用することもできます。クラスターの作成時に利用可能なリリースイメージのカスタムリストを作成し、作業を簡素化します。利用可能なリリースイメージを管理するには、以下の手順を実行します。

  1. acm-hive-openshift-releases GitHub repository 2.7 branch をフォークします。
  2. クラスターの作成時に使用できるイメージの YAML ファイルを追加します。Git コンソールまたはターミナルを使用して、イメージを ./clusterImageSets/stable/ または ./clusterImageSets/fast/ ディレクトリーに追加します。
  3. cluster-image-set-git-repo という名前の multicluster-engine 名前空間に ConfigMap を作成します。以下の例を参照してください。
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-image-set-git-repo
  namespace: multicluster-engine
data:
  gitRepoUrl: <forked acm-hive-openshift-releases repository URL>
  gitRepoBranch: backplane-2.3
  gitRepoPath: clusterImageSets
  channel: <fast or stable>

次の手順でフォークされたリポジトリーに変更をマージすることで、メインリポジトリーから利用可能な YAML ファイルを取得できます。

  1. フォークしたリポジトリーに変更をコミットし、マージします。
  2. acm-hive-openshift-releases リポジトリーのクローンを作成した後に高速リリースイメージのリストを同期するには、cluster-image-set-git-repo ConfigMap の channel フィールドの値を fast に更新します。
  3. 安定版リリースイメージを同期して表示するには、cluster-image-set-git-repo ConfigMap の Channel フィールドの値を stable に更新します。

ConfigMap を更新すると、約 1 分以内に、利用可能な安定リリースイメージのリストが現在利用可能なイメージで更新されます。

  1. 以下のコマンドを使用して、利用可能ものを表示し、デフォルトの設定を削除します。<clusterImageSet_NAME> を正しい名前に置き換えます。

    oc get clusterImageSets
    oc delete clusterImageSet <clusterImageSet_NAME>

クラスターの作成時に、コンソールで現在利用可能なリリースイメージの一覧を表示します。

ConfigMap を通じて利用できる他のフィールドについては、cluster-image-set-controller GitHub リポジトリーの README を参照してください。

1.5.2.3. 非接続時におけるリリースイメージのカスタム一覧の管理

ハブクラスターにインターネット接続がない場合は、リリースイメージのカスタムリストを管理しないといけない場合があります。クラスターの作成時に利用可能なリリースイメージのカスタムリストを作成します。非接続時に、利用可能なリリースイメージを管理するには、以下の手順を実行します。

  1. オンラインシステムを使用している場合は、acm-hive-openshift-releases GitHub repository に移動し、バージョン 2.8 で利用可能なクラスターイメージセットにアクセスします。
  2. clusterImageSets ディレクトリーを非接続マルチクラスターエンジン Operator クラスターにアクセスできるシステムにコピーします。
  3. マネージドクラスターに合わせて次の手順を実行して、クラスターイメージセットを含むオフラインリポジトリーとマネージドクラスター間のマッピングを追加します。

  4. コンソールまたは CLI を使用して、clusterImageSet YAML コンテンツを手動で追加することにより、クラスターを作成するときに使用できるイメージの YAML ファイルを追加します。
  5. 残りの OpenShift Container Platform リリースイメージの clusterImageSet YAML ファイルを、イメージの保存先の正しいオフラインリポジトリーを参照するように変更します。更新内容は次の例のようになります。ここでは、spec.releaseImage が使用しているイメージレジストリーを参照しています。

    apiVersion: hive.openshift.io/v1
    kind: ClusterImageSet
    metadata:
      labels:
        channel: fast
      name: img4.13.8-x86-64-appsub
    spec:
      releaseImage: IMAGE_REGISTRY_IPADDRESS_or_DNSNAME/REPO_PATH/ocp-release:4.12.8-x86_64

    YAML ファイルで参照されているオフラインイメージレジストリーにイメージがロードされていることを確認します。

  6. 各 YAML ファイルに以下のコマンドを入力して、各 clusterImageSets を作成します。

    oc create -f <clusterImageSet_FILE>

    clusterImageSet_FILE を、クラスターイメージセットファイルの名前に置き換えます。以下に例を示します。

    oc create -f img4.11.9-x86_64.yaml

    追加するリソースごとにこのコマンドを実行すると、使用可能なリリースイメージのリストが表示されます。

  7. または、クラスターの作成コンソールに直接イメージ URL を貼り付けることもできます。イメージ URL を追加すると、新しい clusterImageSets が存在しない場合に作成されます。
  8. クラスターの作成時に、コンソールで現在利用可能なリリースイメージの一覧を表示します。

1.5.3. ホストインベントリーの概要

ホストインベントリー管理とオンプレミスクラスターのインストールは、マルチクラスターエンジン Operator の Central Infrastructure Management 機能を使用して利用できます。Central Infrastructure Management は、Assisted Installer (infrastructure Operator とも呼ばれる) をハブクラスターの Operator として実行します。

コンソールを使用してホストインベントリーを作成できます。これは、オンプレミスの OpenShift Container Platform クラスターの作成に使用できるベアメタルまたは仮想マシンのプールです。これらのクラスターには、コントロールプレーン専用のマシンを備えたスタンドアロンと、コントロールプレーンがハブクラスター上の Pod として実行される Hosted Control Plane があります。

スタンドアロンクラスターは、コンソール、API、またはゼロタッチプロビジョニング (ZTP) を使用する GitOps を使用してインストールできます。詳細は、Red Hat OpenShift Container Platform ドキュメントの 非接続環境での GitOps ZTP のインストール を参照してください。

マシンは、Discovery Image で起動した後、ホストインベントリーに参加します。Discovery Image は、以下を含む Red Hat CoreOS ライブイメージです。

  • 検出、検証、およびインストールタスクを実行するエージェント。
  • ハブクラスター上のサービスにアクセスするために必要な設定 (該当する場合、エンドポイント、トークン、静的ネットワーク設定など)。

通常、インフラストラクチャー環境ごとに 1 つの Discovery Image があり、これは共通のプロパティーセットを共有するホストのセットです。InfraEnv カスタムリソース定義は、このインフラストラクチャー環境と関連する Discovery Image を表します。使用されるイメージは OpenShift Container Platform のバージョンに基づいており、選択したオペレーティングシステムのバージョンが決まります。

ホストが起動し、エージェントがサービスに接続すると、サービスはそのホストを表すハブクラスター上に新しい Agent カスタムリソースを作成します。Agent リソースはホストインベントリーを設定します。

後でホストを OpenShift ノードとしてインベントリーにインストールできます。エージェントは、必要な設定とともにオペレーティングシステムをディスクに書き込み、ホストを再起動します。

ホストインベントリーと central infrastructure management の詳細は、以下を参照してください。

1.5.3.1. Central Infrastructure Management サービスの有効化

Central Infrastructure Management サービスはマルチクラスターエンジン Operator とともに提供され、OpenShift Container Platform クラスターをデプロイします。ハブクラスターで MultiClusterHub Operator を有効にすると、Central Infrastructure Management が自動的にデプロイされますが、サービスを手動で有効にする必要があります。

1.5.3.1.1. 前提条件

Central Infrastructure Management サービスを有効にする前に、次の前提条件を確認してください。

  • サポートされているバージョンの Red Hat Advanced Cluster Management for Kubernetes を備えた OpenShift Container Platform 4.13 以降にハブクラスターがデプロイされている。
  • クラスターを作成するために必要なイメージを取得するためのハブクラスターへのインターネットアクセス (接続済み)、あるいはインターネットへの接続がある内部またはミラーレジストリーへの接続 (非接続) がある。
  • ベアメタルプロビジョニングに必要なポートが開いている。OpenShift Container Platform ドキュメントの 必要なポートが開放されていることの確認 を参照してください。
  • ベアメタルホストのカスタムリソース定義がある。
  • OpenShift Container Platform プルシークレット がある。詳細は、イメージプルシークレットの使用 を参照してください。
  • 設定済みのデフォルトのストレージクラスがある。
  • 非接続環境の場合のみ、OpenShift Container Platform ドキュメントの ネットワーク遠端のクラスター に関する手順を完了してください。
1.5.3.1.2. ベアメタルホストのカスタムリソース定義の作成

Central Infrastructure Management サービスを有効にする前に、ベアメタルホストのカスタムリソース定義が必要です。

  1. 次のコマンドを実行して、ベアメタルホストのカスタムリソース定義がすでに存在するかどうかを確認します。

    oc get crd baremetalhosts.metal3.io
    • ベアメタルホストのカスタムリソース定義がある場合、出力にはリソースが作成された日付が表示されます。
    • リソースがない場合は、次のようなエラーが表示されます。

      Error from server (NotFound): customresourcedefinitions.apiextensions.k8s.io "baremetalhosts.metal3.io" not found
  2. ベアメタルホストのカスタムリソース定義がない場合は、metal3.io_baremetalhosts.yaml ファイルをダウンロードし、次のコマンドを実行することでコンテンツを適用して、リソースを作成します。

    oc apply -f
1.5.3.1.3. Provisioning リソースの作成または変更

Central Infrastructure Management サービスを有効にする前に、Provisioning リソースが必要です。

  1. 次のコマンドを実行して、Provisioning リソースがあるかどうかを確認します。

    oc get provisioning
    • すでに Provisioning リソースがある場合は、Provisioning リソースの変更 に進みます。
    • Provisioning リソースがない場合は、No resources found というエラーが表示されます。Provisioning リソースの作成 に進みます。
1.5.3.1.3.1. Provisioning リソースの変更

すでに Provisioning リソースがある場合は、ハブクラスターが次のいずれかのプラットフォームにインストールされている場合、リソースを変更する必要があります。

  • ベアメタル
  • Red Hat OpenStack Platform
  • VMware vSphere
  • ユーザープロビジョニングインフラストラクチャー (UPI) 方式とプラットフォームは None です

ハブクラスターが別のプラットフォームにインストールされている場合は、非接続環境での Central Infrastructure Management の有効化 または 接続環境での Central Infrastructure Management の有効化 に進みます。

  1. provisioning リソースを変更し、以下のコマンドを実行してベアメタル Operator がすべての namespace を監視できるようにします。

    oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'
1.5.3.1.3.2. Provisioning リソースの作成

Provisioning リソースがない場合は、次の手順を実行します。

  1. 次の YAML コンテンツを追加して、Provisioning リソースを作成します。

    apiVersion: metal3.io/v1alpha1
    kind: Provisioning
    metadata:
      name: provisioning-configuration
    spec:
      provisioningNetwork: "Disabled"
      watchAllNamespaces: true
  2. 次のコマンドを実行してコンテンツを適用します。

    oc apply -f
1.5.3.1.4. 非接続環境での Central Infrastructure Management の有効化

非接続環境で Central Infrastructure Management を有効にするには、以下の手順を実行します。

  1. インフラストラクチャー Operator と同じ namespace に ConfigMap を作成し、ミラーレジストリーの ca-bundle.crt および registries.conf の値を指定します。ファイルの ConfigMap は次の例のようになります。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: <mirror-config>
      namespace: multicluster-engine
      labels:
        app: assisted-service
    data:
      ca-bundle.crt: |
        <certificate-content>
      registries.conf: |
        unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
        [[registry]]
           prefix = ""
           location = "registry.redhat.io/multicluster-engine"
           mirror-by-digest-only = true
           [[registry.mirror]]
           location = "mirror.registry.com:5000/multicluster-engine"

    unqualified-search-registries のリストにあるレジストリーは、PUBLIC_CONTAINER_REGISTRIES 環境変数の認証無視リストに自動的に追加されます。マネージドクラスターのプルシークレットの検証時に、指定されたレジストリーは認証を必要としません。

  2. 次の YAML コンテンツを agent_service_config.yaml ファイルに保存して、AgentServiceConfig カスタムリソースを作成します。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: AgentServiceConfig
    metadata:
     name: agent
    spec:
      databaseStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <db_volume_size>
      filesystemStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <fs_volume_size>
      mirrorRegistryRef:
        name: <mirror_config> 1
      unauthenticatedRegistries:
        - <unauthenticated_registry> 2
      imageStorage:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <img_volume_size> 3
      osImages:
        - openshiftVersion: "<ocp_version>" 4
          version: "<ocp_release_version>" 5
          url: "<iso_url>" 6
          cpuArchitecture: "x86_64"
    1
    mirror_config は、ミラーレジストリー設定の詳細が含まれる ConfigMap の名前に置き換えます。
    2
    認証を必要としないミラーレジストリーを使用している場合は、オプションの unauthenticated_registry パラメーターを含めます。このリストのエントリーは検証されず、プルシークレットにエントリーを含める必要はありません。
    3
    img_volume_sizeimageStorage フィールドのボリュームのサイズに置き換えます (例: オペレーティングシステムイメージごとに 10Gi)。最小値は 10Gi ですが、推奨される値は 50Gi 以上です。この値は、クラスターのイメージに割り当てられるストレージの量を指定します。実行中の Red Hat Enterprise Linux CoreOS の各インスタンスに 1 GB のイメージストレージを許可する必要があります。Red Hat Enterprise Linux CoreOS のクラスターおよびインスタンスが多数ある場合は、より高い値を使用する必要がある場合があります。
    4
    ocp_version は、インストールする OpenShift Container Platform バージョンに置き換えます (例: 4.13)。
    5
    ocp_release_version は、特定のインストールバージョン (例: 49.83.2021032516400) に置き換えます。
    6

重要: 遅延バインディング機能を使用しており、AgentServiceConfig カスタムリソースの spec.osImages リリースがバージョン 4.13 以降である場合、クラスターの作成時に使用する OpenShift Container Platform リリースイメージはバージョン 4.13 以降である必要があります。バージョン 4.13 以降の Red Hat Enterprise Linux CoreOS イメージは、バージョン 4.13 より前のイメージとは互換性がありません。

assisted-service デプロイメントおよび assisted-image-service デプロイメントをチェックし、その Pod が準備ができており実行中であることを確認することで、中央インフラストラクチャー管理サービスが正常であることを確認できます。

1.5.3.1.5. 接続環境での Central Infrastructure Management の有効化

接続環境で中央インフラストラクチャー管理を有効にするには、以下の YAML コンテンツを agent_service_config.yaml ファイルに保存して、AgentServiceConfig カスタムリソースを作成します。

apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
 name: agent
spec:
  databaseStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <db_volume_size> 1
  filesystemStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <fs_volume_size> 2
  imageStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <img_volume_size> 3
1
db_volume_sizedatabaseStorage フィールドのボリュームサイズに置き換えます (例: 10Gi )。この値は、クラスターのデータベーステーブルやデータベースビューなどのファイルを格納するために割り当てられるストレージの量を指定します。必要な最小値は 1Gi です。クラスターが多い場合は、より高い値を使用する必要がある場合があります。
2
fs_volume_sizefilesystemStorage フィールドのボリュームのサイズに置き換えます (例: クラスターごとに 200M、サポートされる OpenShift Container Platform バージョンごとに 2-3Gi)。必要な最小値は 1Gi ですが、推奨される値は 100Gi 以上です。この値は、クラスターのログ、マニフェスト、および kubeconfig ファイルを保存するために割り当てられるストレージのサイズを指定します。クラスターが多い場合は、より高い値を使用する必要がある場合があります。
3
img_volume_sizeimageStorage フィールドのボリュームのサイズに置き換えます (例: オペレーティングシステムイメージごとに 10Gi)。最小値は 10Gi ですが、推奨される値は 50Gi 以上です。この値は、クラスターのイメージに割り当てられるストレージの量を指定します。実行中の Red Hat Enterprise Linux CoreOS の各インスタンスに 1 GB のイメージストレージを許可する必要があります。Red Hat Enterprise Linux CoreOS のクラスターおよびインスタンスが多数ある場合は、より高い値を使用する必要がある場合があります。

Central Infrastructure Management サービスが設定されている。assisted-serviceassisted-image-service デプロイメントをチェックして、Pod の準備ができ、実行されていることを確認して、正常性を検証できます。

1.5.3.1.6. 関連情報
1.5.3.2. Amazon Web Services での Central Infrastructure Management の有効化

Amazon Web Services でハブクラスターを実行していて、Central Infrastructure Management サービスを有効にする場合は、Central Infrastructure Management を central infrastructure management の有効化 後に、次の手順を実行します。

  1. ハブクラスターにログインしていることを確認し、次のコマンドを実行して、assisted-image-service で設定された一意のドメインを見つけます。

    oc get routes --all-namespaces | grep assisted-image-service

    ドメインは assisted-image-service-multicluster-engine.apps.<yourdomain>.com のようになります。

  2. ハブクラスターにログインしていることを確認し、NLB type パラメーターを使用して一意のドメインで新しい IngressController を作成します。以下の例を参照してください。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: ingress-controller-with-nlb
      namespace: openshift-ingress-operator
    spec:
      domain: nlb-apps.<domain>.com
      routeSelector:
          matchLabels:
            router-type: nlb
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: External
          providerParameters:
            type: AWS
            aws:
              type: NLB
  3. nlb-apps.<domain>.com<domain><yourdomain> に置き換えて、IngressControllerdomain パラメーターに <yourdomain> を追加します。
  4. 次のコマンドを実行して、新しい IngressController を適用します。

    oc apply -f ingresscontroller.yaml
  5. 次の手順を実行して、新しい IngressControllerspec.domain パラメーターの値が既存の IngressController と競合していないことを確認します。

    1. 次のコマンドを実行して、すべての IngressController を一覧表示します。

      oc get ingresscontroller -n openshift-ingress-operator
    2. 先ほど作成した ingress-controller-with-nlb を除く各 IngressControllers で次のコマンドを実行します。

      oc edit ingresscontroller <name> -n openshift-ingress-operator

      spec.domain レポートが見つからない場合は、nlb-apps.<domain>.com を除く、クラスターで公開されているすべてのルートに一致するデフォルトドメインを追加します。

      spec.domain レポートが提供されている場合は、指定された範囲から nlb-apps.<domain>.com ルートが除外されていることを確認してください。

  6. 次のコマンドを実行して、assisted-image-service ルートを編集し、nlb-apps の場所を使用します。

    oc edit route assisted-image-service -n <namespace>

    デフォルトの namespace は、マルチクラスターエンジン Operator をインストールした場所です。

  7. 次の行を assisted-image-service ルートに追加します。

    metadata:
      labels:
        router-type: nlb
      name: assisted-image-service
  8. assisted-image-service ルートで、spec.host の URL 値を見つけます。URL は次の例のようになります。

    assisted-image-service-multicluster-engine.apps.<yourdomain>.com
  9. URL 内の appsnlb-apps に置き換えて、新しい IngressController で設定されたドメインと一致させます。
  10. Central Infrastructure Management サービスが Amazon Web Services で有効になっていることを確認するには、次のコマンドを実行して Pod が正常であることを確認します。

    oc get pods -n multicluster-engine | grep assist
  11. 新しいホストインベントリーを作成し、ダウンロード URL が新しい nlb-apps URL を使用していることを確認します。
1.5.3.3. コンソールを使用したホストインベントリーの作成

ホストインベントリー (インフラストラクチャー環境) を作成して、OpenShift Container Platform クラスターをインストールできる物理マシンまたは仮想マシンを検出できます。

1.5.3.3.1. 前提条件
  • Central Infrastructure Management サービスを有効にする。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
1.5.3.3.2. ホストインベントリーの作成

コンソールを使用してホストインベントリーを作成するには、次の手順を実行します。

  1. コンソールから、Infrastructure > Host inventory に移動して、Create infrastructure environment をクリックします。
  2. 次の情報をホストインベントリー設定に追加します。

    • 名前: インフラストラクチャー環境の一意の名前。コンソールを使用してインフラストラクチャー環境を作成すると、選択した名前で InfraEnv リソースの新しい namespace も作成されます。コマンドラインインターフェイスを使用して InfraEnv リソースを作成し、コンソールでリソースを監視する場合は、namespace と InfraEnv に同じ名前を使用します。
    • ネットワークタイプ: インフラストラクチャー環境に追加するホストが DHCP または静的ネットワークを使用するかどうかを指定します。静的ネットワーク設定には、追加の手順が必要です。
    • 場所: ホストの地理的な場所を指定します。地理的なロケーションを使用して、ホストが配置されているデータセンターを定義できます。
    • ラベル: このインフラストラクチャー環境で検出されたホストにラベルを追加できるオプションのフィールド。指定した場所はラベルのリストに自動的に追加されます。
    • インフラストラクチャープロバイダーの認証情報: インフラストラクチャープロバイダーの認証情報を選択すると、プルシークレットおよび SSH 公開鍵フィールドに認証情報内の情報が自動的に入力されます。詳細は、オンプレミス環境の認証情報の作成 を参照してください。
    • プルシークレット: OpenShift Container Platform リソースへのアクセスを可能にする OpenShift Container Platform プルシークレット。インフラストラクチャープロバイダーの認証情報を選択した場合、このフィールドには自動的に入力されます。
    • SSH 公開鍵: ホストとのセキュアな通信を可能にする SSH キー。これを使用してホストに接続し、トラブルシューティングを行うことができます。クラスターをインストールした後は、SSH 鍵を使用してホストに接続できなくなります。通常、鍵は id_rsa.pub ファイルにあります。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。SSH 公開鍵の値を含むインフラストラクチャープロバイダーの認証情報を選択した場合、このフィールドには自動的に入力されます。
    • ホストのプロキシー設定を有効にする場合は、有効にする設定を選択し、次の情報を入力します。

      • HTTP プロキシー URL: HTTP リクエストのプロキシーの URL。
      • HTTPS プロキシー URL: HTTP リクエストのプロキシーの URL。URL は HTTP で始まる必要があります。HTTPS はサポートされていません。値を指定しない場合、デフォルトで HTTP 接続と HTTPS 接続の両方に HTTP プロキシー URL が使用されます。
      • プロキシーなしドメイン: プロキシーを使用しないドメインのコンマ区切りのリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
    • 必要に応じて、NTP プールまたはサーバーの IP 名またはドメイン名のコンマ区切りリストを指定して、独自のネットワークタイムプロトコル (NTP) ソースを追加します。

コンソールでは使用できない詳細な設定オプションが必要な場合は、コマンドラインインターフェイスを使用したホストインベントリーの作成 に進みます。

高度な設定オプションが必要ない場合は、必要に応じて静的ネットワークの設定を続行し、インフラストラクチャー環境へのホストの追加を開始できます。

1.5.3.3.3. ホストインベントリーへのアクセス

ホストインベントリーにアクセスするには、コンソールで Infrastructure > Host inventory を選択します。一覧からインフラストラクチャー環境を選択し、詳細とホストを表示します。

1.5.3.3.4. 関連情報
1.5.3.4. コマンドラインインターフェイスを使用したホストインベントリーの作成

ホストインベントリー (インフラストラクチャー環境) を作成して、OpenShift Container Platform クラスターをインストールできる物理マシンまたは仮想マシンを検出できます。自動化されたデプロイメントや、以下の高度な設定オプションには、コンソールの代わりにコマンドラインインターフェイスを使用します。

  • 検出されたホストを既存のクラスター定義に自動的にバインドする
  • Discovery Image の Ignition 設定をオーバーライドする
  • iPXE の動作を制御する
  • Discovery Image のカーネル引数を変更する
  • 検出フェーズ中にホストに信頼させる追加の証明書を渡す
  • 最新バージョンのデフォルトオプションではない、テスト用に起動する Red Hat CoreOS バージョンを選択する
1.5.3.4.1. 前提条件
  • Central Infrastructure Management サービスを有効にする。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
1.5.3.4.2. ホストインベントリーの作成

コマンドラインインターフェイスを使用してホストインベントリー (インフラストラクチャー環境) を作成するには、次の手順を実行します。

  1. 次のコマンドを実行して、ハブクラスターにログインします。

    oc login
  2. リソースの namespace を作成します。

    1. namespace.yaml ファイルを作成し、以下の内容を追加します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: <your_namespace> 1
      1
      コンソールでインベントリーを監視するには、namespace とインフラストラクチャー環境に同じ名前を使用します。
    2. 以下のコマンドを実行して YAML コンテンツを適用します。

      oc apply -f namespace.yaml
  3. OpenShift Container Platform プルシークレット を含む Secret カスタムリソースを作成します。

    1. pull-secret.yaml ファイルを作成し、以下の内容を追加します。

      apiVersion: v1
      kind: Secret
      type: kubernetes.io/dockerconfigjson
      metadata:
        name: pull-secret 1
        namespace: <your_namespace>
      stringData:
        .dockerconfigjson: <your_pull_secret> 2
      1
      namesapce を追加します。
      2
      プルシークレットを追加します。
    2. 以下のコマンドを実行して YAML コンテンツを適用します。

      oc apply -f pull-secret.yaml
  4. インフラストラクチャー環境を作成します。

    1. infra-env.yaml ファイルを作成し、以下の内容を追加します。必要に応じて値を置き換えます。

      apiVersion: agent-install.openshift.io/v1beta1
      kind: InfraEnv
      metadata:
        name: myinfraenv
        namespace: <your_namespace>
      spec:
        proxy:
          httpProxy: <http://user:password@ipaddr:port>
          httpsProxy: <http://user:password@ipaddr:port>
          noProxy:
        additionalNTPSources:
        sshAuthorizedKey:
        pullSecretRef:
          name: <name>
        agentLabels:
          <key>: <value>
        nmStateConfigLabelSelector:
          matchLabels:
            <key>: <value>
        clusterRef:
          name: <cluster_name>
          namespace: <project_name>
        ignitionConfigOverride: '{"ignition": {"version": "3.1.0"}, …}'
        cpuArchitecture: x86_64
        ipxeScriptType: DiscoveryImageAlways
        kernelArguments:
          - operation: append
            value: audit=0
        additionalTrustBundle: <bundle>
        osImageVersion: <version>
表1.3 InfraEnv のフィールドの表
フィールド任意または必須設定

proxy

任意

InfraEnv リソースを使用するエージェントとクラスターのプロキシー設定を定義します。proxy の値を設定しない場合、エージェントはプロキシーを使用するように設定されません。

httpProxy

任意

HTTP リクエストのプロキシーの URLURL は http で開始する必要があります。HTTPS はサポートされていません。

httpsProxy

任意

HTTP リクエストのプロキシーの URLURL は http で開始する必要があります。HTTPS はサポートされていません。

noProxy

任意

プロキシーを使用しない場合は、コンマで区切られたドメインおよび CIDR のリスト。

additionalNTPSources

任意

すべてのホストに追加するネットワークタイムプロトコル (NTP) ソース (ホスト名または IP) のリスト。これらは、DHCP などの他のオプションを使用して設定された NTP ソースに追加されます。

sshAuthorizedKey

任意

検出フェーズ中のデバッグに使用するためにすべてのホストに追加される SSH 公開鍵。検出フェーズは、ホストを Discovery Image を起動するときです。

name

必須

プルシークレットが含まれる Kubernetes シークレットの名前。

agentLabels

任意

InfraEnv で検出されたホストを表す Agent リソースに自動的に追加されるラベル。キーと値を必ず追加してください。

nmStateConfigLabelSelector

任意

ホストの静的 IP、ブリッジ、ボンディングなどの高度なネットワーク設定を統合します。ホストネットワーク設定は、選択したラベルを持つ 1 つ以上の NMStateConfig リソースで指定されます。nmStateConfigLabelSelector プロパティーは、選択したラベルと一致する Kubernetes ラベルセレクターです。このラベルセレクターに一致するすべての NMStateConfig ラベルのネットワーク設定は、Discovery Image に含まれています。起動時に、各ホストは各設定をそのネットワークインターフェイスと比較し、適切な設定を適用します。高度なネットワーク設定の詳細は、ホストインベントリーの高度なネットワークの設定 セクションへのリンクを参照してください。

clusterRef

任意

スタンドアロンのオンプレミスクラスターを記述する既存の ClusterDeployment リソースを参照します。デフォルトでは設定されません。clusterRef が設定されていない場合は、後でホストを 1 つ以上のクラスターにバインドできます。あるクラスターからホストを削除し、別のクラスターに追加できます。clusterRef が設定されている場合、InfraEnv で検出されたすべてのホストが、指定されたクラスターに自動的にバインドされます。クラスターがまだインストールされていない場合は、検出されたすべてのホストがそのインストールに含まれます。クラスターがすでにインストールされている場合は、検出されたすべてのホストが追加されます。

ignitionConfigOverride

任意

ファイルの追加など、Red Hat CoreOS ライブイメージの Ignition 設定を変更します。必要に応じて ignitionConfigOverride のみを使用してください。クラスターのバージョンに関係なく、ignition バージョン 3.1.0 を使用する必要があります。

cpuArchitecture

任意

サポートされている CPU アーキテクチャー x86_64、aarch64、ppc64le、または s390x のいずれかを選択します。デフォルト値は x86_64 です。

ipxeScriptType

任意

起動に iPXE を使用している場合に、デフォルト値である DiscoveryImageAlways に設定すると、イメージサービスが常に iPXE スクリプトを提供するようになります。その結果、ホストがネットワーク検出イメージから起動します。値を BootOrderControl に設定すると、イメージサービスがホストの状態に応じて iPXE スクリプトを返すタイミングを決定するようになります。その結果、ホストがプロビジョニングされていてクラスターの一部になっている場合、ホストはディスクから起動します。

kernelArguments

任意

Discovery Image の起動時にカーネル引数を変更できます。operation に使用できる値は、appendreplace、または delete です。

additionalTrustBundle

任意

PEM エンコードされた X.509 証明書バンドル。通常、ホストが再暗号化中間者 (MITM) プロキシーを備えたネットワーク内にある場合、またはコンテナーイメージレジストリーなど、他の目的でホストが証明書を信頼しなければならない場合に必要です。InfraEnv によって検出されたホストは、このバンドル内の証明書を信頼します。InfraEnv によって検出されたホストから作成されたクラスターは、このバンドル内の証明書も信頼します。

osImageVersion

任意

InfraEnv に使用する Red Hat CoreOS イメージのバージョン。バージョンが AgentServiceConfig.spec.osImages またはデフォルトの OS イメージのリストで指定された OS イメージを参照していることを確認してください。各リリースには、特定の Red Hat CoreOS イメージバージョンのセットがあります。OSImageVersion は、OS イメージリストの OpenShift Container Platform バージョンと一致する必要があります。OSImageVersionClusterRef を同時に指定できません。デフォルトでは存在しない別のバージョンの Red Hat CoreOS イメージを使用する場合は、AgentServiceConfig.spec.osImages でそのバージョンを指定して、手動で追加する必要があります。バージョンの追加に関する詳細は、中央インフラストラクチャー管理サービスの有効化 を参照してください。

  1. 以下のコマンドを実行して YAML コンテンツを適用します。

    oc apply -f infra-env.yaml
  2. ホストインベントリーが作成されたことを確認するには、次のコマンドでステータスを確認します。

    oc describe infraenv myinfraenv -n <your_namespace>

重要なプロパティーのリストは次のとおりです。

  • conditions: イメージが正常に作成されたかどうかを示す標準の Kubernetes 条件。
  • isoDownloadURL: Discovery Image をダウンロードするための URL。
  • createdTime: イメージが最後に作成された時刻。InfraEnv を変更する場合は、新しいイメージをダウンロードする前にタイムスタンプが更新されていることを確認してください。

注: InfraEnv リソースを変更する場合は、createdTime プロパティーを確認して、InfraEnv が新しい Discovery Image を作成したことを確認してください。すでにホストを起動している場合は、最新の Discovery Image でホストを再起動します。

必要に応じて静的ネットワークを設定し、インフラストラクチャー環境へのホストの追加を開始することで続行できます。

1.5.3.4.3. 関連情報
1.5.3.5. インフラストラクチャー環境用の高度なネットワークの設定

1 つのインターフェイスで DHCP 以外のネットワークを必要とするホストの場合は、高度なネットワークを設定する必要があります。必要な設定には、1 つ以上のホストのネットワークを記述する NMStateConfig リソースの 1 つ以上のインスタンスの作成が含まれます。

NMStateConfig リソースには、InfraEnv リソースの nmStateConfigLabelSelector に一致するラベルが含まれている必要があります。nmStateConfigLabelSelector の詳細は、コマンドラインインターフェイスを使用したホストインベントリーの作成 を参照してください。

Discovery Image には、参照されているすべての NMStateConfig リソースで定義されたネットワーク設定が含まれています。起動後、各ホストは各設定をそのネットワークインターフェイスと比較し、適切な設定を適用します。

1.5.3.5.1. 前提条件
  • Central Infrastructure Management サービスを有効にする。
  • ホストインベントリーを作成する。
1.5.3.5.2. コマンドラインインターフェイスを使用した高度なネットワークの設定

コマンドラインインターフェイスを使用してインフラストラクチャー環境の詳細ネットワークを設定するには、以下の手順を実行します。

  1. nmstateconfig.yaml という名前のファイルを作成し、以下のテンプレートのようなコンテンツを追加します。必要に応じて値を置き換えます。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: NMStateConfig
    metadata:
      name: mynmstateconfig
      namespace: <your-infraenv-namespace>
      labels:
        some-key: <some-value>
    spec:
      config:
        interfaces:
          - name: eth0
            type: ethernet
            state: up
            mac-address: 02:00:00:80:12:14
            ipv4:
              enabled: true
              address:
                - ip: 192.168.111.30
                  prefix-length: 24
              dhcp: false
          - name: eth1
            type: ethernet
            state: up
            mac-address: 02:00:00:80:12:15
            ipv4:
              enabled: true
              address:
                - ip: 192.168.140.30
                  prefix-length: 24
              dhcp: false
        dns-resolver:
          config:
            server:
              - 192.168.126.1
        routes:
          config:
            - destination: 0.0.0.0/0
              next-hop-address: 192.168.111.1
              next-hop-interface: eth1
              table-id: 254
            - destination: 0.0.0.0/0
              next-hop-address: 192.168.140.1
              next-hop-interface: eth1
              table-id: 254
      interfaces:
        - name: "eth0"
          macAddress: "02:00:00:80:12:14"
        - name: "eth1"
          macAddress: "02:00:00:80:12:15"
表1.4 NMStateConfig のフィールドの表
フィールド任意または必須設定

name

必須

設定しているホストに関連した名前を使用してください。

namespace

必須

namespace は、InfraEnv リソースの namespace と一致する必要があります。

some-key

必須

nmStateConfigLabelSelector に一致する 1 つ以上のラベルを InfraEnv リソースに追加します。

config

任意

NMstate 形式のネットワーク設定を説明します。形式の指定と追加の例については、Declarative Network API を参照してください。この設定は、ホストごとに 1 つの NMStateConfig リソースがある単一のホストに適用することも、単一の NMStateConfig リソースで複数のホストのインターフェイスを記述することもできます。

interfaces

任意

指定された NMstate 設定で見つかったインターフェイス名とホストで見つかった MAC アドレスの間のマッピングを記述します。マッピングがホスト上に存在する物理インターフェイスを使用していることを確認してください。たとえば、NMState 設定でボンドまたは VLAN が定義されている場合、マッピングには親インターフェイスのエントリーのみが含まれます。マッピングには次の目的があります。* ホスト上のインターフェイス名と一致しないインターフェイス名を設定で使用できるようにします。オペレーティングシステムによりインターフェイス名 (これは予測できない) が選択されるので、便利な場合があります。* 起動後に検索する MAC アドレスをホストに指示し、正しい NMstate 設定を適用します。

注: イメージサービスは、InfraEnv プロパティーを更新するか、そのラベルセレクターに一致する NMStateConfig リソースを変更すると、新しいイメージを自動的に作成します。InfraEnv リソースの作成後に NMStateConfig リソースを追加する場合は、InfraEnvcreatedTime プロパティーを確認して、InfraEnv が新しい Discovery Image を作成していることを確認してください。すでにホストを起動している場合は、最新の Discovery Image でホストを再起動します。

  1. 以下のコマンドを実行して YAML コンテンツを適用します。

    oc apply -f nmstateconfig.yaml
1.5.3.5.3. 関連情報
1.5.3.6. Discovery Image を使用したホストのホストインベントリーへの追加

ホストインベントリー (インフラストラクチャー環境) を作成した後、ホストを検出してインベントリーに追加できます。インベントリーにホストを追加するには、ISO をダウンロードし、各サーバーにアタッチする方法を選択します。たとえば、仮想メディアを使用するか、ISO を USB ドライブに書き込むことで、ISO をダウンロードできます。

重要: インストールが失敗しないようにするには、インストールプロセス中は Discovery ISO メディアをデバイスに接続したままにし、各ホストがデバイスから 1 回起動するように設定します。

1.5.3.6.1. 前提条件
  • Central Infrastructure Management サービスを有効にする。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
  • ホストインベントリーを作成する。詳細は、コンソールを使用したホストインベントリーの作成 を参照してください。
1.5.3.6.2. コンソールを使用したホストの追加

以下の手順を実行して ISO をダウンロードします。

  1. コンソールで Infrastructure > Host inventory を選択します。
  2. 一覧からお使いのインフラストラクチャー環境を選択します。
  3. Add hosts をクリックし、With Discovery ISO を選択します。

ISO をダウンロードするための URL が表示されます。ブートされたホストがホストインベントリーテーブルに表示されます。ホストが表示されるまでに数分かかる場合があります。使用する前に、各ホストを承認する必要があります。Actions をクリックして Approve を選択し、インベントリーテーブルからホストを選択できます。

1.5.3.6.3. コマンドラインインターフェイスを使用したホストの追加

ISO をダウンロードするための URL は、InfraEnv リソースのステータスの isoDownloadURL プロパティーで確認できます。InfraEnv リソースの詳細は、コマンドラインインターフェイスを使用したホストインベントリーの作成を参照してください。

起動したホストごとに、同じ namespace に Agent リソースを作成します。使用する前に、各ホストを承認する必要があります。

1.5.3.6.4. 関連情報
1.5.3.7. ベアメタルホストのホストインベントリーへの自動追加

ホストインベントリー (インフラストラクチャー環境) を作成した後、ホストを検出してインベントリーに追加できます。各ホストの BareMetalHost リソースおよび関連する BMC シークレットを作成することで、ベアメタル Operator が各ベアメタルホストのベースボード管理コントローラー (BMC) と通信できるようにすることで、インフラストラクチャー環境の Discovery Image の起動を自動化できます。自動化は、インフラストラクチャー環境を参照する BareMetalHost のラベルによって設定されます。

自動化により以下のアクションが実行されます。

  • インフラストラクチャー環境で表される Discovery Image を使用して、各ベアメタルホストを起動します。
  • インフラストラクチャー環境または関連するネットワーク設定が更新された場合に、各ホストを最新の Discovery Image で再起動します。
  • 検出時に各 Agent リソースを対応する BareMetalHost リソースに関連付けます。
  • BareMetalHost からの情報 (ホスト名、ロール、インストールディスクなど) に基づいて Agent リソースのプロパティーを更新します。
  • Agent をクラスターノードとして使用することを承認します。
1.5.3.7.1. 前提条件
  • Central Infrastructure Management サービスを有効にする。
  • ホストインベントリーを作成する。
1.5.3.7.2. コンソールを使用したベアメタルホストの追加

コンソールを使用してベアメタルホストをホストインベントリーに自動的に追加するには、次の手順を実行します。

  1. コンソールで Infrastructure > Host inventory を選択します。
  2. 一覧からお使いのインフラストラクチャー環境を選択します。
  3. Add hosts をクリックし、With BMC Form を選択します。
  4. 必要な情報を追加し、Create をクリックします。
1.5.3.7.3. コマンドラインインターフェイスを使用したベアメタルホストの追加

コマンドラインインターフェイスを使用してベアメタルホストをホストインベントリーに自動的に追加するには、以下の手順を実施します。

  1. 次の YAML コンテンツを適用し、必要に応じて値を置き換えて、BMC シークレットを作成します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: <bmc-secret-name>
      namespace: <your_infraenv_namespace> 1
    type: Opaque
    data:
      username: <username>
      password: <password>
    1
    namespace は InfraEnv の namespace と同じである必要があります。
  2. 以下の YAML コンテンツを適用し、必要に応じて値を置き換えてベアメタルホストを作成します。

    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    metadata:
      name: <bmh-name>
      namespace: <your_infraenv_namespace> 1
      annotations:
        inspect.metal3.io: disabled
      labels:
        infraenvs.agent-install.openshift.io: <your-infraenv> 2
    spec:
      online: true
      automatedCleaningMode: disabled 3
      bootMACAddress: <your-mac-address>  4
      bmc:
        address: <machine-address> 5
        credentialsName: <bmc-secret-name> 6
      rootDeviceHints:
        deviceName: /dev/sda 7
    1
    namespace は InfraEnv の namespace と同じである必要があります。
    2
    この名前は InfrEnv の名前と一致し、同じ namespace に存在する必要があります。
    3
    値を設定しない場合、metadata の値が自動的に使用されます。
    4
    MAC アドレスがホスト上のいずれかのインターフェイスの MAC アドレスと一致することを確認してください。
    5
    BMC のアドレスを使用します。詳細は 帯域外管理 IP アドレスのポートアクセス を参照してください。
    6
    credentialsName の値が、作成した BMC シークレットの名前と一致していることを確認してください。
    7
    オプション: インストールディスクを選択します。利用可能なルートデバイスのヒントについては、BareMetalHost spec を参照してください。ホストが Discovery Image で起動され、対応する Agent リソースが作成された後、このヒントに従ってインストールディスクが設定されます。

ホストの電源をオンにすると、イメージのダウンロードが開始されます。これには数分かかる場合があります。ホストが検出されると、Agent カスタムリソースが自動的に作成されます。

1.5.3.7.4. 関連情報
1.5.3.8. ホストインベントリーの管理

コンソールまたはコマンドラインインターフェイスを使用して、Agent リソースの編集、ホストインベントリーの管理、既存のホストの編集が可能です。

1.5.3.8.1. コンソールを使用したホストインベントリーの管理

Discovery ISO で正常に起動した各ホストは、ホストインベントリーの行として表示されます。コンソールを使用してホストを編集および管理できます。ホストを手動で起動し、ベアメタル Operator の自動化を使用していない場合は、使用する前にコンソールでホストを承認する必要があります。OpenShift ノードとしてインストールできるホストが Available ステータスになっています。

1.5.3.8.2. コマンドラインインターフェイスを使用したホストインベントリーの管理

Agent リソースは、各ホストを表します。Agent リソースで次のプロパティーを設定できます。

  • clusterDeploymentName

    このプロパティーは、クラスターにノードとしてインストールする場合に使用する ClusterDeployment の namespace および名前に設定します。

  • 任意: role

    クラスター内のホストのロールを設定します。使用できる値は、masterworker、および auto-assign です。デフォルト値は auto-assign です。

  • hostname

    ホストのホスト名を設定します。ホストに有効なホスト名が自動的に割り当てられる場合は任意です (例: DHCP を使用)。

  • approved

    ホストを OpenShift ノードとしてインストールできるかどうかを示します。このプロパティーは、デフォルト値が False のブール値です。ホストを手動で起動しており、ベアメタル Operator の自動化を使用していない場合は、ホストをインストールする前にこのプロパティーを True に設定する必要があります。

  • installation_disk_id

    ホストのインベントリーに表示されるインストールディスクの ID。

  • installerArgs

    ホストの coreos-installer 引数のオーバーライドが含まれる JSON 形式の文字列。このプロパティーを使用して、カーネル引数を変更できます。構文例を以下に示します。

    ["--append-karg", "ip=192.0.2.2::192.0.2.254:255.255.255.0:core0.example.com:enp1s0:none", "--save-partindex", "4"]
  • ignitionConfigOverrides

    ホストの Ignition 設定のオーバーライドが含まれる JSON 形式の文字列。このプロパティーを使用して、ignition を使用してファイルをホストに追加できます。構文例を以下に示します。

    {"ignition": "version": "3.1.0"}, "storage": {"files": [{"path": "/tmp/example", "contents": {"source": "data:text/plain;base64,aGVscGltdHJhcHBlZGluYXN3YWdnZXJzcGVj"}}]}}
  • nodeLabels

    ホストのインストール後にノードに適用されるラベルのリスト。

Agent リソースの status には、以下のプロパティーがあります。

  • role

    クラスター内のホストのロールを設定します。これまでに Agent リソースで role をしたことがある場合は、その値が status に表示されます。

  • inventory

    ホスト上で実行されているエージェントが検出するホストプロパティーが含まれます。

  • progress

    ホストのインストールの進行状況。

  • ntpSources

    ホストの設定済みの Network Time Protocol (NTP) ソース。

  • conditions

    次の標準 Kubernetes 条件 (True または False 値) が含まれます。

    • SpecSynced: 指定されたすべてのプロパティーが正常に適用される場合は True。何らかのエラーが発生した場合は、False
    • Connected: インストールサービスへのエージェント接続が禁止されていない場合は True。エージェントがしばらくの間インストールサービスに接続していない場合は False
    • RequirementsMet: ホストがインストールを開始する準備ができている場合は True
    • Validated: すべてのホスト検証に合格した場合は True
    • installed: ホストが OpenShift ノードとしてインストールされている場合は True
    • Bound: ホストがクラスターにバインドされている場合は True
    • Cleanup: Agent リソースの削除リクエストが失敗した場合は False
  • debugInfo

    インストールログおよびイベントをダウンロードするための URL が含まれています。

  • validationsInfo

    ホストの検出後にインストールが成功したことを確認するためにエージェントが実行する検証の情報が含まれます。値が False の場合は、トラブルシューティングを行ってください。

  • installation_disk_id

    ホストのインベントリーに表示されるインストールディスクの ID。

1.5.3.8.3. 関連情報

1.5.4. クラスターの作成

マルチクラスターエンジン Operator を使用して、クラウドプロバイダー全体で Red Hat OpenShift Container Platform クラスターを作成する方法を説明します。

マルチクラスターエンジン Operator は、OpenShift Container Platform で提供される Hive Operator を使用して、オンプレミスクラスターと Hosted Control Plane を除くすべてのプロバイダーのクラスターをプロビジョニングします。オンプレミスクラスターをプロビジョニングする場合、マルチクラスターエンジン Operator は OpenShift Container Platform で提供される Central Infrastructure Management および Assisted Installer 機能を使用します。Hosted Control Plane のホステッドクラスターは、HyperShift Operator を使用してプロビジョニングされます。

1.5.4.1. CLI を使用したクラスターの作成

Kubernetes のマルチクラスターエンジンは、内部 Hive コンポーネントを使用して Red Hat OpenShift Container Platform クラスターを作成します。クラスターの作成方法については、以下の情報を参照してください。

1.5.4.1.1. 前提条件

クラスターを作成する前に、clusterImageSets リポジトリーのクローンを作成し、ハブクラスターに適用する必要があります。以下の手順を参照してください。

  1. 次のコマンドを実行してクローンを作成します。

    git clone https://github.com/stolostron/acm-hive-openshift-releases.git
    cd acm-hive-openshift-releases
    git checkout origin/backplane-2.3
  2. 次のコマンドを実行して、ハブクラスターに適用します。

    find clusterImageSets/fast -type d -exec oc apply -f {} \; 2> /dev/null

クラスターを作成するときに、Red Hat OpenShift Container Platform リリースイメージを選択します。

1.5.4.1.2. ClusterDeployment を使用してクラスターを作成する

ClusterDeployment は、クラスターのライフサイクルを制御するために使用される Hive カスタムリソースです。

Using Hive のドキュメントに従って ClusterDeployment カスタムリソースを作成し、個別のクラスターを作成します。

1.5.4.1.3. ClusterPool を使用してクラスターを作成

ClusterPool は、複数のクラスターを作成するために使用される Hive カスタムリソースでもあります。

Cluster Pools のドキュメントに従って、Hive ClusterPool API でクラスターを作成します。

1.5.4.2. クラスター作成時の追加のマニフェストの設定

追加の Kubernetes リソースマニフェストは、クラスター作成のインストールプロセス中に設定できます。これは、ネットワークの設定やロードバランサーの設定など、シナリオの追加マニフェストを設定する必要がある場合に役立ちます。

クラスターを作成する前に、追加のリソースマニフェストが含まれる ConfigMap を指定する ClusterDeployment リソースへの参照を追加する必要があります。

注記: ClusterDeployment リソースと ConfigMap は同じ namespace にある必要があります。以下の例で、どのような内容かを紹介しています。

  • リソースマニフェストを含む ConfigMap

    ConfigMap リソースが別のマニフェストが含まれる ConfigMap。リソースマニフェストの ConfigMap には、data.<resource_name>\.yaml パターンに追加されたリソース設定が指定されたキーを複数含めることができます。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: <my-baremetal-cluster-install-manifests>
      namespace: <mynamespace>
    data:
      99_metal3-config.yaml: |
        kind: ConfigMap
        apiVersion: v1
        metadata:
          name: metal3-config
          namespace: openshift-machine-api
        data:
          http_port: "6180"
          provisioning_interface: "enp1s0"
          provisioning_ip: "172.00.0.3/24"
          dhcp_range: "172.00.0.10,172.00.0.100"
          deploy_kernel_url: "http://172.00.0.3:6180/images/ironic-python-agent.kernel"
          deploy_ramdisk_url: "http://172.00.0.3:6180/images/ironic-python-agent.initramfs"
          ironic_endpoint: "http://172.00.0.3:6385/v1/"
          ironic_inspector_endpoint: "http://172.00.0.3:5150/v1/"
          cache_url: "http://192.168.111.1/images"
          rhcos_image_url: "https://releases-art-rhcos.svc.ci.openshift.org/art/storage/releases/rhcos-4.3/43.81.201911192044.0/x86_64/rhcos-43.81.201911192044.0-openstack.x86_64.qcow2.gz"
  • リソースマニフェスト ConfigMap が参照される ClusterDeployment

    リソースマニフェスト ConfigMapspec.provisioning.manifestsConfigMapRef で参照されます。

    apiVersion: hive.openshift.io/v1
    kind: ClusterDeployment
    metadata:
      name: <my-baremetal-cluster>
      namespace: <mynamespace>
      annotations:
        hive.openshift.io/try-install-once: "true"
    spec:
      baseDomain: test.example.com
      clusterName: <my-baremetal-cluster>
      controlPlaneConfig:
        servingCertificates: {}
      platform:
        baremetal:
          libvirtSSHPrivateKeySecretRef:
            name: provisioning-host-ssh-private-key
      provisioning:
        installConfigSecretRef:
          name: <my-baremetal-cluster-install-config>
        sshPrivateKeySecretRef:
          name: <my-baremetal-hosts-ssh-private-key>
        manifestsConfigMapRef:
          name: <my-baremetal-cluster-install-manifests>
        imageSetRef:
          name: <my-clusterimageset>
        sshKnownHosts:
        - "10.1.8.90 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXvVVVKUYVkuyvkuygkuyTCYTytfkufTYAAAAIbmlzdHAyNTYAAABBBKWjJRzeUVuZs4yxSy4eu45xiANFIIbwE3e1aPzGD58x/NX7Yf+S8eFKq4RrsfSaK2hVJyJjvVIhUsU9z2sBJP8="
      pullSecretRef:
        name: <my-baremetal-cluster-pull-secret>
1.5.4.3. Amazon Web Services でのクラスターの作成

マルチクラスターエンジン Operator コンソールを使用して、Amazon Web Services (AWS) に Red Hat OpenShift Container Platform クラスターを作成できます。

クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの AWS へのインストール でプロセスの詳細を確認してください。

1.5.4.3.1. 前提条件

AWS でクラスターを作成する前に、以下の前提条件を確認してください。

  • ハブクラスターをデプロイしている。
  • AWS 認証情報がある。詳細は、Amazon Web Services の認証情報の作成 を参照してください。
  • AWS で設定されたドメインがある。ドメインの設定方法は、AWS アカウントの設定 を参照してください。
  • ユーザー名、パスワード、アクセスキー ID およびシークレットアクセスキーなど、Amazon Web Services (AWS) のログイン認証情報がある。Understanding and Getting Your Security Credentials を参照してください。
  • OpenShift Container Platform イメージのプルシークレットがある。イメージプルシークレットの使用 を参照してください。

    注記: クラウドプロバイダーでクラウドプロバイダーのアクセスキーを変更する場合は、コンソールでクラウドプロバイダーの対応する認証情報を手動で更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。

1.5.4.3.2. AWS クラスターの作成

AWS クラスターの作成に関する次の重要な情報を参照してください。

  • クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML: On を選択して、パネルに install-config.yaml ファイルの内容を表示できます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。
  • クラスターを作成すると、コントローラーはクラスターとリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。
  • クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。
  • クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。
  • 指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。
  • マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。
  • AWS アカウントで設定した、選択した認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。この名前はクラスターのホスト名で使用されます。
  • このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。利用可能なイメージのリストからイメージを選択します。使用したいイメージがない場合は、使用したいイメージの URL を入力します。
  • ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。情報には以下のフィールドが含まれます。

    • region: ノードプールが必要なリージョンを指定します。
    • CPU アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64ppc64les390x、および arm64 です。
    • ゾーン: コントロールプレーンプールを実行する場所を指定します。より分散されているコントロールプレーンノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
    • インスタンスタイプ: コントロールプレーンノードのインスタンスタイプを指定します。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。
    • ルートストレージ: クラスターに割り当てるルートストレージの量を指定します。
  • ワーカープールにワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。オプションの情報には以下のフィールドが含まれます。

    • ゾーン: ワーカープールを実行する場所を指定します。より分散されているノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
    • インスタンスタイプ: ワーカープールのインスタンスタイプを指定します。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。
    • ノード数: ワーカープールのノード数を指定します。ワーカープールを定義する場合にこの設定は必須です。
    • ルートストレージ: ワーカープールに割り当てるルートストレージの量を指定します。ワーカープールを定義する場合にこの設定は必須です。
  • クラスターにはネットワークの詳細が必要であり、IPv6 を使用するには複数のネットワークが必要です。Add network をクリックして、追加のネットワークを追加できます。
  • 認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。

    • HTTP プロキシー: HTTP トラフィックのプロキシーとして使用する URL を指定します。
    • HTTPS プロキシー: HTTPS トラフィックに使用するセキュアなプロキシー URL を指定します。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
    • プロキシーサイトなし: プロキシーをバイパスする必要のあるサイトのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
    • 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
1.5.4.3.3. コンソールを使用したクラスターの作成

新しいクラスターを作成するには、次の手順を参照してください。代わりに import したい既存のクラスターがある場合は、ハブクラスターへのターゲットマネージドクラスターのインポート を参照してください。

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

  1. Infrastructure > Clusters に移動します。
  2. Clusters ページで、以下を実行します。Cluster > Create cluster をクリックし、コンソールで手順を完了します。
  3. 任意: コンソールに情報を入力するときにコンテンツの更新を表示するには、YAML: On を選択します。

認証情報を作成する必要がある場合は、Amazon Web Services の認証情報の作成 を参照してください。

クラスターの名前はクラスターのホスト名で使用されます。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスター klusterlet を特定のノードで実行するように設定したい場合は、必要な手順について オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。

1.5.4.3.4. 関連情報
1.5.4.4. Amazon Web Services GovCloud でのクラスターの作成

コンソールを使用して、Amazon Web Services (AWS) または AWS GovCloud で Red Hat OpenShift Container Platform クラスターを作成できます。この手順では、AWS GovCloud でクラスターを作成する方法を説明します。AWS でクラスターを作成する手順については、Amazon Web Services でのクラスターの作成 を参照してください。

AWS GovCloud は、政府のドキュメントをクラウドに保存するために必要な追加の要件を満たすクラウドサービスを提供します。AWS GovCloud でクラスターを作成する場合、環境を準備するために追加の手順を実行する必要があります。

クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について質問がある場合は、プロセスの詳細について、OpenShift Container Platform ドキュメントの AWS 上のクラスターを政府リージョンにインストールする を参照してください。以下のセクションでは、AWS GovCloud でクラスターを作成する手順を説明します。

1.5.4.4.1. 前提条件

AWS GovCloud クラスターを作成する前に、以下の前提条件を満たす必要があります。

  • ユーザー名、パスワード、アクセスキー ID、およびシークレットアクセスキーなどの AWS ログイン認証情報が必要です。Understanding and Getting Your Security Credentials を参照してください。
  • AWS 認証情報がある。詳細は、Amazon Web Services の認証情報の作成 を参照してください。
  • AWS で設定されたドメインがある。ドメインの設定方法は、AWS アカウントの設定 を参照してください。
  • OpenShift Container Platform イメージのプルシークレットがある。イメージプルシークレットの使用 を参照してください。
  • ハブクラスター用の既存の Red Hat OpenShift Container Platform クラスターを備えた Amazon Virtual Private Cloud (VPC) が必要です。この VPC は、マネージドクラスターリソースまたはマネージドクラスターサービスエンドポイントに使用される VPC とは異なる必要があります。
  • マネージドクラスターリソースがデプロイされる VPC が必要です。これは、ハブクラスターまたはマネージドクラスターサービスエンドポイントに使用される VPC と同じにすることはできません。
  • マネージドクラスターサービスエンドポイントを提供する 1 つ以上の VPC が必要です。これは、ハブクラスターまたはマネージドクラスターリソースに使用される VPC と同じにすることはできません。
  • Classless Inter-Domain Routing (CIDR) によって指定される VPC の IP アドレスが重複しないようにしてください。
  • Hive namespace 内で認証情報を参照する HiveConfig カスタムリソースが必要です。このカスタムリソースは、マネージドクラスターサービスエンドポイント用に作成した VPC でリソースを作成するためにアクセスできる必要があります。

注記: クラウドプロバイダーでクラウドプロバイダーのアクセスキーを変更する場合は、マルチクラスターエンジン Operator コンソールでクラウドプロバイダーの対応する認証情報を手動で更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。

1.5.4.4.2. Hive を AWS GovCloud にデプロイするように設定します。

AWS GovCloud でのクラスターの作成は、標準の AWS でクラスターを作成することとほぼ同じですが、AWS GovCloud でクラスターの AWS PrivateLink を準備するために追加の手順を実行する必要があります。

1.5.4.4.2.1. リソースおよびエンドポイントの VPC の作成

前提条件に記載されているように、ハブクラスターが含まれる VPC に加えて、2 つの VPC が必要です。VPC を作成する具体的な手順については、Amazon Web Services ドキュメントの VPC の作成 を参照してください。

  1. プライベートサブネットを使用してマネージドクラスターの VPC を作成します。
  2. プライベートサブネットを使用して、マネージドクラスターサービスエンドポイントの 1 つ以上の VPC を作成します。リージョンの各 VPC には 255 VPC エンドポイントの制限があるため、そのリージョン内の 255 を超えるクラスターをサポートするには、複数の VPC が必要です。
  3. 各 VPC について、リージョンのサポートされるすべてのアベイラビリティーゾーンにサブネットを作成します。コントローラーの要件があるため、各サブネットには少なくとも 255 以上の使用可能な IP アドレスが必要です。

    以下の例は、us-gov-east-1 リージョンに 6 つのアベイラビリティーゾーンを持つ VPC のサブネットを設定する方法を示しています。

    vpc-1 (us-gov-east-1) : 10.0.0.0/20
      subnet-11 (us-gov-east-1a): 10.0.0.0/23
      subnet-12 (us-gov-east-1b): 10.0.2.0/23
      subnet-13 (us-gov-east-1c): 10.0.4.0/23
      subnet-12 (us-gov-east-1d): 10.0.8.0/23
      subnet-12 (us-gov-east-1e): 10.0.10.0/23
      subnet-12 (us-gov-east-1f): 10.0.12.0/2
    vpc-2 (us-gov-east-1) : 10.0.16.0/20
      subnet-21 (us-gov-east-1a): 10.0.16.0/23
      subnet-22 (us-gov-east-1b): 10.0.18.0/23
      subnet-23 (us-gov-east-1c): 10.0.20.0/23
      subnet-24 (us-gov-east-1d): 10.0.22.0/23
      subnet-25 (us-gov-east-1e): 10.0.24.0/23
      subnet-26 (us-gov-east-1f): 10.0.28.0/23
  4. すべてのハブクラスター (ハブクラスター VPC) に、ピアリング、転送ゲートウェイ、およびすべての DNS 設定が有効になっている VPC エンドポイント用に作成した VPC へのネットワーク接続があることを確認します。
  5. AWS GovCloud 接続に必要な AWS PrivateLink の DNS 設定を解決するために必要な VPC の一覧を収集します。これには、設定しているマルチクラスターエンジン Operator インスタンスの VPC が少なくとも含まれ、さまざまな Hive コントローラーが存在するすべての VPC の一覧を含めることができます。
1.5.4.4.2.2. VPC エンドポイントのセキュリティーグループの設定

AWS の各 VPC エンドポイントには、エンドポイントへのアクセスを制御するためにセキュリティーグループが割り当てられます。Hive が VPC エンドポイントを作成する場合、セキュリティーグループは指定しません。VPC のデフォルトのセキュリティーグループは VPC エンドポイントに割り当てられます。VPC のデフォルトのセキュリティーグループには、VPC エンドポイントが Hive インストーラー Pod から作成されるトラフィックを許可するルールが必要です。詳細については、AWS ドキュメントの エンドポイントポリシーを使用した VPC エンドポイントへのアクセスの制御 を参照してください。

たとえば、Hive が hive-vpc (10.1.0.0/16) で実行されている場合は、VPC エンドポイントが作成される VPC のデフォルトセキュリティーグループに、10.1.0.0/16 からのイングレスを許可するルールが必要です。

1.5.4.4.3. コンソールを使用したクラスターの作成

コンソールからクラスターを作成するには、Infrastructure > Clusters > Create cluster AWS > Standalone に移動して、コンソールで手順を実行します。

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

AWS GovCloud クラスターを作成する場合、選択する認証情報は AWS GovCloud リージョンのリソースにアクセスできる必要があります。クラスターをデプロイするために必要な権限を持つ場合は、Hive namespace にある AWS GovCloud シークレットを使用できます。コンソールに既存の認証情報が表示されます。認証情報を作成する必要がある場合は、Amazon Web Services の認証情報の作成 を参照してください。

クラスターの名前はクラスターのホスト名で使用されます。

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

AWS または AWS GovCloud アカウントで設定した、選択した認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。この名前はクラスターのホスト名で使用されます。詳細は、AWS アカウントの設定 を参照してください。

このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細については、リリースイメージ を参照してください。

ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。情報には以下のフィールドが含まれます。

  • リージョン: クラスターリソースを作成するリージョン。AWS GovCloud プロバイダーでクラスターを作成する場合、ノードプールの AWS GovCloud リージョンを含める必要があります。たとえば、us-gov-west-1 です。
  • CPU アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64ppc64les390x、および arm64 です。
  • ゾーン: コントロールプレーンプールを実行する場所を指定します。より分散されているコントロールプレーンノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
  • インスタンスタイプ: コントロールプレーンノードのインスタンスタイプを指定します。これは、以前に指定した CPU アーキテクチャー と同じにする必要があります。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。
  • ルートストレージ: クラスターに割り当てるルートストレージの量を指定します。

ワーカープールにワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。オプションの情報には以下のフィールドが含まれます。

  • プール名: プールの一意の名前を指定します。
  • ゾーン: ワーカープールを実行する場所を指定します。より分散されているノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
  • インスタンスタイプ: ワーカープールのインスタンスタイプを指定します。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。
  • ノード数: ワーカープールのノード数を指定します。ワーカープールを定義する場合にこの設定は必須です。
  • ルートストレージ: ワーカープールに割り当てるルートストレージの量を指定します。ワーカープールを定義する場合にこの設定は必須です。

クラスターにはネットワークの詳細が必要であり、IPv6 を使用するには複数のネットワークが必要です。AWS GovCloud クラスターの場合は、Machine CIDR フィールドに Hive VPC のアドレスのブロックの値を入力します。Add network をクリックして、追加のネットワークを追加できます。

認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。

  • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL を指定します。
  • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL を指定します。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
  • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  • 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。

AWS GovCloud クラスターを作成するか、プライベート環境を使用する場合は、AMI ID およびサブネット値を使用して、AWS プライベート設定 ページのフィールドに入力します。ClusterDeployment.yaml ファイルで spec:platform:aws:privateLink:enabled の値が true に設定されていることを確認します。これは、Use private configuration を選択すると自動的に設定されます。

クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML: On を選択して、パネルに install-config.yaml ファイルの内容を表示できます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。

注記: クラスターのインポートには、クラスターの詳細で提示された oc コマンドを実行する必要はありません。クラスターを作成すると、Kubernetes Operator のマルチクラスターエンジンの管理下に自動的に設定されます。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスター klusterlet を特定のノードで実行するように設定したい場合は、必要な手順について オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。

クラスターにアクセスする 手順については、クラスターへのアクセスに進みます。

1.5.4.5. Microsoft Azure でのクラスターの作成

マルチクラスターエンジン Operator コンソールを使用して、Microsoft Azure または Microsoft Azure Government に Red Hat OpenShift Container Platform クラスターをデプロイできます。

クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの Azure へのインストール でプロセスの詳細を確認してください。

1.5.4.5.1. 前提条件

Azure でクラスターを作成する前に、以下の前提条件を確認してください。

注記: クラウドプロバイダーでクラウドプロバイダーのアクセスキーを変更する場合は、マルチクラスターエンジン Operator のコンソールでクラウドプロバイダーの対応する認証情報を手動で更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。

1.5.4.5.2. コンソールを使用したクラスターの作成

マルチクラスターエンジン Operator コンソールからクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。

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

認証情報を作成する必要がある場合は、詳細について Microsoft Azure の認証情報の作成 を参照してください。

クラスターの名前はクラスターのホスト名で使用されます。

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

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

このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細については、リリースイメージ を参照してください。

ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。この情報には、次のオプションフィールドが含まれます。

  • リージョン: ノードプールを実行するリージョンを指定します。より分散されているコントロールプレーンノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
  • CPU アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64ppc64les390x、および arm64 です。

クラスターの作成後に、コントロールプレーンプールのタイプおよびルートストレージの割り当て (必須) を変更できます。

ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。情報には以下のフィールドが含まれます。

  • ゾーン: ワーカープールを実行することを指定します。より分散されているノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
  • インスタンスタイプ: インスタンスのタイプとサイズは、作成後に変更できます。

Add network をクリックして、追加のネットワークを追加できます。IPv6 アドレスを使用している場合は、複数のネットワークが必要です。

認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。

  • HTTP プロキシー: HTTP トラフィックのプロキシーとして使用する URL。
  • HTTPS プロキシー: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
  • プロキシーなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  • 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。

クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML スイッチをクリックして On にすると、パネルに install-config.yaml ファイルの内容が表示されます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスター klusterlet を特定のノードで実行するように設定したい場合は、必要な手順について オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。

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

クラスターにアクセスする 手順については、クラスターへのアクセスに進みます。

1.5.4.6. Google Cloud Platform でのクラスターの作成

Google Cloud Platform (GCP) で Red Hat OpenShift Container Platform クラスターを作成する手順に従います。GCP の詳細については、Google Cloud Platform を参照してください。

クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの GCP のインストール でプロセスの詳細を確認してください。

1.5.4.6.1. 前提条件

GCP でクラスターを作成する前に、次の前提条件を確認してください。

注記: クラウドプロバイダーでクラウドプロバイダーのアクセスキーを変更する場合は、マルチクラスターエンジン Operator のコンソールでクラウドプロバイダーの対応する認証情報を手動で更新する必要もあります。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。

1.5.4.6.2. コンソールを使用したクラスターの作成

マルチクラスターエンジン Operator コンソールからクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。

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

認証情報を作成する必要がある場合は、Google Cloud Platform の認証情報の作成 を参照してください。

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

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

選択した GCP アカウントの認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。詳細は、Setting up a custom domain を参照してください。この名前はクラスターのホスト名で使用されます。

このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細については、リリースイメージ を参照してください。

ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。情報には以下のフィールドが含まれます。

  • リージョン: コントロールプレーンプールを実行するリージョンを指定します。リージョンが近くにある場合はパフォーマンスの速度が向上しますが、リージョンの距離が離れると、より分散されます。
  • CPU アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64ppc64les390x、および arm64 です。

コントロールプレーンプールのインスタンスタイプを指定できます。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。

ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。情報には以下のフィールドが含まれます。

  • インスタンスタイプ: インスタンスのタイプとサイズは、作成後に変更できます。
  • ノード数: ワーカープールを定義するときに必要な設定です。

ネットワークの詳細が必要であり、IPv6 アドレスを使用するには複数のネットワークが必要です。Add network をクリックして、追加のネットワークを追加できます。

認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。

  • HTTP プロキシー: HTTP トラフィックのプロキシーとして使用する URL。
  • HTTPS プロキシー: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
  • プロキシーサイトなし: プロキシーをバイパスする必要のあるサイトのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  • 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。

クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML: On を選択して、パネルに install-config.yaml ファイルの内容を表示できます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスター klusterlet を特定のノードで実行するように設定したい場合は、必要な手順について オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。

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

クラスターにアクセスする 手順については、クラスターへのアクセスに進みます。

1.5.4.7. VMware vSphere でのクラスターの作成

マルチクラスターエンジン Operator コンソールを使用して、VMware vSphere に Red Hat OpenShift Container Platform クラスターをデプロイできます。

クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの vSphere のインストール でプロセスの詳細を確認してください。

1.5.4.7.1. 前提条件

vSphere でクラスターを作成する前に、次の前提条件を確認してください。

  • OpenShift Container Platform バージョン 4.6 以降にデプロイされたハブクラスターが必要です。
  • vSphere 認証情報がある。詳細は、VMware vSphere の認証情報の作成 を参照してください。
  • OpenShift Container Platform イメージプルシークレットがある。イメージプルシークレットの使用 を参照してください。
  • デプロイする VMware インスタンスについて、以下の情報がある。

    • API および Ingress インスタンスに必要な静的 IP アドレス
    • 以下の DNS レコード。

      • 次の API ベースドメインは静的 API VIP を指す必要があります。

        api.<cluster_name>.<base_domain>
      • 次のアプリケーションベースドメインは、Ingress VIP の静的 IP アドレスを指す必要があります。

        *.apps.<cluster_name>.<base_domain>
1.5.4.7.2. コンソールを使用したクラスターの作成

マルチクラスターエンジン Operator コンソールからクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。

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

認証情報を作成する必要がある場合は、認証情報の作成の詳細について、VMware vSphere の認証情報の作成 を参照してください。

クラスターの名前はクラスターのホスト名で使用されます。

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

vSphere アカウントで設定した、選択した認証情報に関連付けられているベースドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。詳細は、カスタマイズによる vSphere へのクラスターのインストール を参照してください。値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。この名前はクラスターのホスト名で使用されます。

このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細については、リリースイメージ を参照してください。

注記: OpenShift Container Platform バージョン 4.5.x 以降のリリースイメージのみがサポートされます。

ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。この情報には、CPU アーキテクチャー フィールドが含まれます。次のフィールドの説明を表示します。

  • CPU アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64ppc64les390x、および arm64 です。

ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。この情報には、ソケットあたりのコア数CPUMemory_min MiB、GiB 単位の _Disk サイズ、および ノード数 が含まれます。

ネットワーク情報が必要です。IPv6 を使用するには、複数のネットワークが必要です。必要なネットワーク情報の一部は、次のフィールドに含まれています。

  • vSphere ネットワーク名: VMware vSphere ネットワーク名を指定します。
  • API VIP: 内部 API 通信に使用する IP アドレスを指定します。

    注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して api. が正しく解決されるようにします。

  • Ingress VIP: Ingress トラフィックに使用する IP アドレスを指定します。

    注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して test.apps. が正しく解決されるようにします。

Add network をクリックして、追加のネットワークを追加できます。IPv6 アドレスを使用している場合は、複数のネットワークが必要です。

認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。

  • HTTP プロキシー: HTTP トラフィックのプロキシーとして使用する URL を指定します。
  • HTTPS プロキシー: HTTPS トラフィックに使用するセキュアなプロキシー URL を指定します。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
  • プロキシーサイトなし: プロキシーをバイパスする必要のあるサイトのコンマ区切りリストを指定します。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  • 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。

Disconnected installation をクリックして、オフラインインストールイメージを定義できます。Red Hat OpenStack Platform プロバイダーとオフラインインストールを使用してクラスターを作成する際に、ミラーレジストリーにアクセスするための証明書が必要な場合は、クラスターを作成する際の認証情報または Disconnected installation セクションを設定するときに、Configuration for disconnected installation セクションの Additional trust bundle フィールドにその証明書を入力する必要があります。

Add automation template をクリックしてテンプレートを作成できます。

クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML スイッチをクリックして On にすると、パネルに install-config.yaml ファイルの内容が表示されます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスター klusterlet を特定のノードで実行するように設定したい場合は、必要な手順について オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。

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

クラスターにアクセスする 手順については、クラスターへのアクセスに進みます。

1.5.4.8. Red Hat OpenStack Platform でのクラスターの作成

マルチクラスターエンジン Operator コンソールを使用して、Red Hat OpenStack Platform に Red Hat OpenShift Container Platform クラスターをデプロイできます。

クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの OpenStack のインストール でプロセスの詳細を確認してください。

1.5.4.8.1. 前提条件

Red Hat OpenStack Platform でクラスターを作成する前に、以下の前提条件を確認してください。

  • OpenShift Container Platform バージョン 4.6 以降にデプロイされたハブクラスターが必要です。
  • Red Hat OpenStack Platform の認証情報がある。詳細は、Red Hat OpenStack Platform の認証情報の作成 を参照してください。
  • OpenShift Container Platform イメージプルシークレットがある。イメージプルシークレットの使用 を参照してください。
  • デプロイする Red Hat OpenStack Platform インスタンスに関する以下の情報がある。

    • コントロールプレーンとワーカーインスタンスのフレーバー名 (例:m1.xlarge)
    • Floating IP アドレスを提供する外部ネットワークのネットワーク名
    • API および Ingress インスタンスに必要な静的 IP アドレス
    • 以下の DNS レコード。

      • 次の API ベースドメインは、API のフローティング IP アドレスを指す必要があります。

        api.<cluster_name>.<base_domain>
      • 次のアプリケーションベースドメインは、ingress:app-name のフローティング IP アドレスを指す必要があります。

        *.apps.<cluster_name>.<base_domain>`
1.5.4.8.2. コンソールを使用したクラスターの作成

マルチクラスターエンジン Operator コンソールからクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。

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

認証情報を作成する必要がある場合は、Red Hat OpenStack Platform の認証情報の作成 を参照してください。

クラスターの名前はクラスターのホスト名で使用されます。名前には 15 文字以上指定できません。値は、認証情報の要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

Red Hat OpenStack Platform アカウントで設定した、選択した認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は、上書きすると変更できます。詳細は、Red Hat OpenStack Platform ドキュメントの ドメインの管理 を参照してください。この名前はクラスターのホスト名で使用されます。

このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細については、リリースイメージ を参照してください。OpenShift Container Platform バージョン 4.6.x 以降のリリースイメージのみがサポートされます。

ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64ppc64les390x、および arm64 です。

コントロールプレーンプールのインスタンスタイプを追加する必要がありますが、インスタンスの作成後にインスタンスのタイプとサイズを変更できます。

ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。情報には以下のフィールドが含まれます。

  • インスタンスタイプ: インスタンスのタイプとサイズは、作成後に変更できます。
  • ノード数: ワーカープールのノード数を指定します。ワーカープールを定義する場合にこの設定は必須です。

クラスターにはネットワークの詳細が必要です。IPv4 ネットワーク用に 1 つ以上のネットワークの値を指定する必要があります。IPv6 ネットワークの場合は、複数のネットワークを定義する必要があります。

Add network をクリックして、追加のネットワークを追加できます。IPv6 アドレスを使用している場合は、複数のネットワークが必要です。

認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。

  • HTTP プロキシー: HTTP トラフィックのプロキシーとして使用する URL を指定します。
  • HTTPS プロキシー: HTTPS トラフィックに使用するセキュアなプロキシー URL。値が指定されていない場合、HTTP Proxy と同じ値が HTTPHTTPS の両方に使用されます。
  • プロキシーなし: プロキシーをバイパスする必要のあるサイトのコンマ区切りリストを定義します。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  • 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。

Disconnected installation をクリックして、オフラインインストールイメージを定義できます。Red Hat OpenStack Platform プロバイダーとオフラインインストールを使用してクラスターを作成する際に、ミラーレジストリーにアクセスするための証明書が必要な場合は、クラスターを作成する際の認証情報または Disconnected installation セクションを設定するときに、Configuration for disconnected installation セクションの Additional trust bundle フィールドにその証明書を入力する必要があります。

クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML スイッチをクリックして On にすると、パネルに install-config.yaml ファイルの内容が表示されます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。

内部認証局 (CA) を使用するクラスターを作成する場合、以下の手順を実行してクラスターの YAML ファイルをカスタマイズする必要があります。

  1. レビューステップで YAML スイッチをオンにし、CA 証明書バンドルを使用してリストの上部に Secret オブジェクトを挿入します。注記: Red Hat OpenStack Platform 環境が複数の機関によって署名された証明書を使用してサービスを提供する場合、バンドルには、必要なすべてのエンドポイントを検証するための証明書を含める必要があります。ocp3 という名前のクラスターの追加は以下の例のようになります。

    apiVersion: v1
    kind: Secret
    type: Opaque
    metadata:
      name: ocp3-openstack-trust
      namespace: ocp3
    stringData:
      ca.crt: |
        -----BEGIN CERTIFICATE-----
        <Base64 certificate contents here>
        -----END CERTIFICATE-----
        -----BEGIN CERTIFICATE-----
        <Base64 certificate contents here>
        -----END CERTIFICATE----
  2. 以下の例のように、Hive ClusterDeployment オブジェクトを変更して、spec.platform.openstackcertificatesSecretRef の値を指定します。

    platform:
      openstack:
        certificatesSecretRef:
          name: ocp3-openstack-trust
        credentialsSecretRef:
          name: ocp3-openstack-creds
        cloud: openstack

    上記の例では、clouds.yaml ファイルのクラウド名が openstack であることを前提としています。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスター klusterlet を特定のノードで実行するように設定したい場合は、必要な手順について オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。