クラスター

Red Hat Advanced Cluster Management for Kubernetes 2.7

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

概要

クラスターライフサイクルおよびマルチクラスターエンジン Operator の詳細は、こちらを参照してください。

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

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

情報:

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

1.1. リリースノート

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

注記: Red Hat Advanced Cluster Management の 2.4 以前のバージョンはサービスから 削除 され、サポートされなくなりました。バージョン 2.4 以前のドキュメントは更新されていません。ドキュメントはそのまま利用できますが、エラータやその他の更新はなく、非推奨となります。

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

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

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

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

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

1.1.1.1. インストール

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

1.1.1.2. クラスターライフサイクル

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

  • cluster-proxy-addon を使用して、プロキシーを使用してマネージドクラスターの任意のサービスに接続できるようになりました。ハブからマネージドクラスターに直接到達して、一部のサービスと対話します。詳細は、クラスタープロキシーアドオンの使用 を参照してください。
  • Amazon Web Services GovCloud でクラスターを作成できるようになりました。詳細は、Amazon Web Services GovCloud でのクラスターの作成 を参照してください。

API - Clusterset: v1beta2 - ClustersetBinding: v1beta2 の新しいバージョンがあります。詳細は、API を参照してください。

  • hosted と standalone の 2 つのコントロールプレーンタイプを使用できます。スタンドアロン はコンソールウィザード機能であり、ホステッド は CLI からクラスターを作成できるように特定の手順およびガイダンスを提供します。
  • MultiClusterEngine カスタムリソースを更新して、ハブクラスターが自身を管理するかどうかを指定できるようになりました。詳細については、ローカルクラスターの有効化 を参照してください。
  • 非接続環境でインフラストラクチャー環境を作成するときに、ConfigMap および AgentServiceConfig ファイルの設定を変更して、非認証レジストリーを指定できます。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
  • MachinePool を使用したスケーリングが一般提供されるようになったため、自動スケーリングを簡単に設定してリソースをスケーリングできます。詳細は MachinePool によるスケーリング を参照してください。

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. ローカルクラスターが自動的に再作成されない場合がある

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

  • この問題を解決するには、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 ファイルが含まれています。非接続環境では、ミラーリングされたイメージにミラーリングされた署名がない場合があり、その結果、クラスターノードの検出時にイメージのプルが失敗します。エージェントイメージがクラスターノードとの接続に失敗するため、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.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. カスタム Ingress ドメインが正しく適用されない

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

1.1.2.2.4. ManagedClusterSet API 仕様の制限

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

1.1.3. エラータの更新

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

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

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. エラータ 2.9.1

  • 1 つ以上の製品コンテナーイメージに更新を配信します。
  • マネージドクラスターが非推奨のリージョンとゾーンラベルを使用した問題を修正しました。(ACM-8844)
  • Topology ビューでノードリージョンとゾーンが誤って表示される問題を修正しました。(ACM-9004)

1.1.3.2. エラータ 2.9.1

  • 1 つ以上の製品コンテナーイメージに更新を配信します。

1.1.3.3. エラータ 2.9.1

  • 1 つ以上の製品コンテナーイメージとセキュリティー修正プログラムの更新を提供します。

1.1.3.4. エラータ 2.2.8

  • 1 つ以上の製品コンテナーイメージとセキュリティー修正プログラムの更新を提供します。

1.1.3.5. エラータ 2.2.7

  • 1 つ以上の製品コンテナーイメージとセキュリティー修正プログラムの更新を提供します。
  • Hive MachinePools には含まれないマネージドクラスターにノードを追加するときにコンソールが誤ったスケーリングアラートを表示する問題が修正されました。(ACM-5169)

1.1.3.6. エラータ 2.2.6

  • シークレットのファイルサイズが大きすぎると klusterlet エージェントが失敗する原因となっていた問題を修正します。(ACM-5873)

1.1.3.7. エラータ 2.2.5

  • 1 つ以上の製品コンテナーイメージとセキュリティー修正プログラムの更新を提供します。

1.1.3.8. エラータ 2.2.4

  • 1 つ以上の製品コンテナーイメージとセキュリティー修正プログラムの更新を提供します。

1.1.3.9. エラータ 2.2.3

  • 1 つ以上の製品コンテナーイメージとセキュリティー修正プログラムの更新を提供します。

1.1.3.10. エラータ 2.2.2

  • 1 つ以上の製品コンテナーイメージとセキュリティー修正プログラムの更新を提供します。

1.1.3.11. エラータ 2.2.1

  • 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.2 サポートマトリックス を参照してください。

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

1.2.1. 要件および推奨事項

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

1.2.1.1. サポートされているブラウザーとプラットフォーム

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

1.2.1.2. ネットワーク設定

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

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

以下のセクションで接続を許可するようにネットワークを設定します。

1.2.1.2.1. マルチクラスターエンジン Operator のネットワーク要件

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

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

Outbound

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

6443

送信および受信

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

443

受信

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

6443

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

open-cluster-management:view:<managed_cluster_name>

open-cluster-management:view:<managed_cluster_name> ロールへのクラスターバインディングがあるユーザーには、managedcluster-<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.3. マルチクラスターエンジンオペレーターのインストールとアップグレード

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

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

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 Deplicated 環境での 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 の場合は、Red Hat 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 の場合は、Red Hat OpenShift Container Platform のインストール時に openshift_master_default_subdomain を設定します。

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

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

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

  1. ミラーレジストリーを作成します。ミラーレジストリーがまだない場合は、Red Hat 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.3. クラスターのアップグレード

マルチクラスターエンジン Operator で管理したい Red Hat OpenShift Container Platform クラスターを作成した後、マルチクラスターエンジン Operator コンソールを使用して、マネージドクラスターが使用するバージョンチャネルで利用できる最新のマイナーバージョンにこれらのクラスターをアップグレードすることができます。

接続された環境では、コンソールでアップグレードが必要な各クラスターに提供される通知によって、更新が自動的に識別されます。

注記:

メジャーバージョンへのアップグレードには、そのバージョンへのアップグレードの前提条件をすべて満たしていることを確認する必要があります。コンソールでクラスターをアップグレードする前に、マネージドクラスターのバージョンチャネルを更新する必要があります。

マネージドクラスターでバージョンチャネルを更新すると、マルチクラスターエンジン Operator コンソールに、アップグレードに使用できる最新バージョンが表示されます。

このアップグレードの手法は、ステータスが Ready の OpenShift Container Platform のマネージドクラスタークラスターでだけ使用できます。

重要: マルチクラスターエンジン Operator コンソールを使用して、Red Hat OpenShift Kubernetes Service マネージドクラスターまたは OpenShift Container Platform マネージドクラスターを Red Hat OpenShift Dedicated でアップグレードすることはできません。

オンライン環境でクラスターをアップグレードするには、以下の手順を実行します。

  1. ナビゲーションメニューから Infrastructure > Clusters に移動します。アップグレードが利用可能な場合には、Distribution version の列に表示されます。
  2. アップグレードする Ready 状態のクラスターを選択します。クラスターはコンソールを使用してアップグレードされる OpenShift Container Platform クラスターである必要があります。
  3. Upgrade を選択します。
  4. 各クラスターの新しいバージョンを選択します。
  5. Upgrade を選択します。

クラスターのアップグレードに失敗すると、Operator は通常アップグレードを数回再試行し、停止し、コンポーネントに問題があるステータスを報告します。場合によっては、アップグレードプロセスは、プロセスの完了を繰り返し試行します。アップグレードに失敗した後にクラスターを以前のバージョンにロールバックすることはサポートされていません。クラスターのアップグレードに失敗した場合は、Red Hat サポートにお問い合わせください。

1.3.3.1. チャネルの選択

コンソールを使用して、OpenShift Container Platform バージョン 4.6 以降でクラスターをアップグレードするためのチャネルを選択できます。チャネルを選択すると、エラータバージョン (4.8.1> 4.8.2> 4.8.3 など) とリリースバージョン (4.8> 4.9 など) の両方で使用できるクラスターアップグレードが自動的に通知されます。

クラスターのチャネルを選択するには、以下の手順を実行します。

  1. ナビゲーションメニューから infrastructure > Clusters をクリックします。
  2. 変更するクラスターの名前を選択して、Cluster details ページを表示します。クラスターに別のチャネルが利用可能な場合は、編集アイコンが Channel フィールドに表示されます。
  3. 編集アイコンをクリックして、フィールドの設定を変更します。
  4. New channel フィールドでチャネルを選択します。

利用可能なチャネル更新のリマインダーは、クラスターの Cluster details ページで見つけることができます。

1.3.3.2. オフラインクラスターのアップグレード

マルチクラスターエンジン Operator と Red Hat OpenShift Update Service を使用し、オフライン環境でクラスターをアップグレードできます。

セキュリティー上の理由で、クラスターがインターネットに直接接続できない場合があります。このような場合は、アップグレードが利用可能なタイミングや、これらのアップグレードの処理方法を把握するのが困難になります。OpenShift Update Service を設定すると便利です。

OpenShift Update Service は、個別の Operator および オペランドで、非接続環境で利用可能なマネージドクラスターを監視して、クラスターのアップグレードで利用できるようにします。OpenShift Update Service の設定後に、以下のアクションを実行できます。

  • オフラインのクラスター向けにいつアップグレードが利用できるかを監視します。
  • グラフデータファイルを使用してアップグレード用にどの更新がローカルサイトにミラーリングされているかを特定します。
  • コンソールを使用して、クラスターのアップグレードが利用可能であることを通知します。

次のトピックでは、オフラインクラスターをアップグレードする手順について説明します。

1.3.3.2.1. 前提条件

OpenShift Update Service を使用して非接続クラスターをアップグレードするには、以下の前提条件を満たす必要があります。

  • 制限付き OLM が設定された Red Hat OpenShift Container Platform バージョン 4.6 以降で実行されているデプロイ済みハブクラスター。制限付きの OLM の設定方法については、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。

    Note: 制限付きの OLM の設定時に、カタログソースイメージをメモします。

  • ハブクラスターによって管理される OpenShift Container Platform クラスター
  • クラスターイメージをミラーリング可能なローカルレジストリーにアクセスするための認証情報。このリポジトリーの作成方法について、詳細は 非接続インストールミラーリング を参照してください。

    注記: アップグレードするクラスターの現行バージョンのイメージは、ミラーリングされたイメージの 1 つとして常に利用可能でなければなりません。アップグレードに失敗すると、クラスターはアップグレード試行時のクラスターのバージョンに戻ります。

1.3.3.2.2. 非接続ミラーレジストリーの準備

ローカルのミラーリングレジストリーに、アップグレード前の現行のイメージと、アップグレード後のイメージの療法をミラーリングする必要があります。イメージをミラーリングするには以下の手順を実行します。

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

    UPSTREAM_REGISTRY=quay.io
    PRODUCT_REPO=openshift-release-dev
    RELEASE_NAME=ocp-release
    OCP_RELEASE=4.12.2-x86_64
    LOCAL_REGISTRY=$(hostname):5000
    LOCAL_SECRET_JSON=/path/to/pull/secret 1
    
    oc adm -a ${LOCAL_SECRET_JSON} release mirror \
    --from=${UPSTREAM_REGISTRY}/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE} \
    --to=${LOCAL_REGISTRY}/ocp4 \
    --to-release-image=${LOCAL_REGISTRY}/ocp4/release:${OCP_RELEASE}
    1
    path-to-pull-secret は、OpenShift Container Platform のプルシークレットへのパスに置き換えます。
  2. スクリプトを実行して、イメージのミラーリング、設定の設定、リリースイメージとリリースコンテンツの分離を行います。

    ImageContentSourcePolicy の作成時に、このスクリプトの最後の行にある出力を使用できます。

1.3.3.2.3. OpenShift Update Service の Operator のデプロイ

OpenShift Container Platform 環境で OpenShift Update Service の Operator をデプロイするには、以下の手順を実行します。

  1. ハブクラスターで、OpenShift Container Platform Operator のハブにアクセスします。
  2. Red Hat OpenShift Update Service Operator を選択して Operator をデプロイします。必要に応じてデフォルト値を更新します。Operator をデプロイすると、openshift-cincinnati という名前の新規プロジェクトが作成されます。
  3. Operator のインストールが完了するまで待ちます。

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

1.3.3.2.4. グラフデータの init コンテナーの構築

OpenShift Update Service はグラフデータ情報を使用して、利用可能なアップグレードを判別します。オンライン環境では、OpenShift Update Service は Cincinnati グラフデータの GitHub リポジトリー から直接利用可能なアップグレードがないか、グラフデータ情報をプルします。非接続環境を設定しているため、init container を使用してローカルリポジトリーでグラフデータを利用できるようにする必要があります。以下の手順を実行して、グラフデータの init container を作成します。

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

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

    FROM registry.access.redhat.com/ubi8/ubi:8.1 1
    
    RUN curl -L -o cincinnati-graph-data.tar.gz https://github.com/openshift/cincinnati-graph-data/archive/master.tar.gz 2
    
    RUN mkdir -p /var/lib/cincinnati/graph-data/ 3
    
    CMD exec /bin/bash -c "tar xvzf cincinnati-graph-data.tar.gz -C /var/lib/
    cincinnati/graph-data/ --strip-components=1"  4

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

    1
    FROM 値は、OpenShift Update Service がイメージを検索する先の外部レジストリーに置き換えます。
    2 3
    RUN コマンドはディレクトリーを作成し、アップグレードファイルをパッケージ化します。
    4
    CMD コマンドは、パッケージファイルをローカルリポジトリーにコピーして、ファイルをデプロイメントしてアップグレードします。
  3. 以下のコマンドを実行して、graph data init container をビルドします。

    podman build -f <path_to_Dockerfile> -t <${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container>:latest 1 2
    podman push <${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container><2>:latest --authfile=</path/to/pull_secret>.json 3
    1
    path_to_Dockerfile を、前の手順で作成したファイルへのパスに置き換えます。
    2
    ${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container は、ローカルグラフデータ init container へのパスに置き換えます。
    3
    /path/to/pull_secret は、プルシークレットへのパスに置き換えます。

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

1.3.3.2.5. ミラーリングされたレジストリーの証明書の設定

セキュアな外部コンテナーレジストリーを使用してミラーリングされた OpenShift Container Platform リリースイメージを保存する場合は、アップグレードグラフをビルドするために OpenShift Update Service からこのレジストリーへのアクセス権が必要です。OpenShift Update Service Pod と連携するように CA 証明書を設定するには、以下の手順を実行します。

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

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

  2. openshift-config namespace に ConfigMap を作成します。
  3. キー updateservice-registry の下に CA 証明書を追加します。OpenShift Update Service はこの設定を使用して、証明書を特定します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: trusted-ca
    data:
      updateservice-registry: |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----
  4. image.config.openshift.io API の cluster リソースを編集して、additionalTrustedCA フィールドを作成した ConfigMap 名に設定します。

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

    trusted-ca は、新しい ConfigMap へのパスに置き換えます。OpenShift Update Service Operator は、変更がないか、image.config.openshift.io API と、openshift-config namespace に作成した ConfigMap を監視し、CA 証明書が変更された場合はデプロイメントを再起動します。

1.3.3.2.6. OpenShift Update Service インスタンスのデプロイ

ハブクラスターへの OpenShift Update Service インスタンスのデプロイが完了したら、このインスタンスは、クラスターのアップグレードのイメージをミラーリングして非接続マネージドクラスターに提供する場所に配置されます。インスタンスをデプロイするには、以下の手順を実行します。

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

    1. OpenShift Container Platform ハブクラスターコンソールのナビゲーションメニューで、Administration > Namespaces を選択します。
    2. Create Namespace を選択します。
    3. namespace 名と、namespace のその他の情報を追加します。
    4. Create を選択して namespace を作成します。
  2. OpenShift Container Platform コンソールの Installed Operators セクションで、Red Hat OpenShift Update Service Operator を選択します。
  3. メニューから Create Instance を選択します。
  4. OpenShift Update Service インスタンスからコンテンツを貼り付けます。YAML ファイルは以下のマニフェストのようになります。

    apiVersion: cincinnati.openshift.io/v1beta2
    kind: Cincinnati
    metadata:
      name: openshift-update-service-instance
      namespace: openshift-cincinnati
    spec:
      registry: <registry_host_name>:<port> 1
      replicas: 1
      repository: ${LOCAL_REGISTRY}/ocp4/release
      graphDataImage: '<host_name>:<port>/cincinnati-graph-data-container'2
    1
    spec.registry の値は、イメージの非接続環境にあるローカルレジストリーへのパスに置き換えます。
    2
    spec.graphDataImage の値は、グラフデータ init container へのパスに置き換えます。これは、podman push コマンドを使用して、グラフデータ init container をプッシュする時に使用した値と同じです。
  5. Create を選択してインスタンスを作成します。
  6. ハブクラスター CLI で oc get pods コマンドを入力し、インスタンス作成のステータスを表示します。時間がかかる場合がありますが、コマンド結果でインスタンスと Operator が実行中である旨が表示されたらプロセスは完了です。
1.3.3.2.7. デフォルトのレジストリーの上書き (オプション)

注記: 本セクションの手順は、ミラーレジストリーにリリースをミラーリングした場合にのみ該当します。

OpenShift Container Platform にはイメージレジストリーのデフォルト値があり、この値でアップグレードパッケージの検索先を指定します。オフライン環境では、オーバーライドを作成して、その値をリリースイメージをミラーリングしたローカルイメージレジストリーへのパスに置き換えることができます。

デフォルトのレジストリーを上書きするには、次の手順を実行します。

  1. 次の内容のような、mirror.yaml という名前の YAML ファイルを作成します。

    apiVersion: operator.openshift.io/v1alpha1
    kind: ImageContentSourcePolicy
    metadata:
      name: <your-local-mirror-name>1
    spec:
      repositoryDigestMirrors:
        - mirrors:
            - <your-registry>2
          source: registry.redhat.io
    1
    your-local-mirror-name をローカルミラーの名前に置き換えます。
    2
    your-registry をローカルミラーリポジトリーへのパスに置き換えます。

    注記: oc adm release mirror コマンドを入力すると、ローカルミラーへのパスが分かります。

  2. マネージドクラスターのコマンドラインを使用して、次のコマンドを実行してデフォルトのレジストリーをオーバーライドします。

    oc apply -f mirror.yaml
1.3.3.2.8. オフラインカタログソースのデプロイ

マネージドクラスターで、デフォルトのカタログソースをすべて無効にし、新しいカタログソースを作成します。デフォルトの場所を接続された場所からオフラインローカルレジストリーに変更するには、次の手順を実行します。

  1. 次の内容のような、source.yaml という名前の YAML ファイルを作成します。

    apiVersion: config.openshift.io/v1
    kind: OperatorHub
    metadata:
      name: cluster
    spec:
      disableAllDefaultSources: true
    
    ---
    apiVersion: operators.coreos.com/v1alpha1
    kind: CatalogSource
    metadata:
      name: my-operator-catalog
      namespace: openshift-marketplace
    spec:
      sourceType: grpc
      image: '<registry_host_name>:<port>/olm/redhat-operators:v1'1
      displayName: My Operator Catalog
      publisher: grpc
    1
    spec.image の値を、ローカルの制約付きカタログソースイメージへのパスに置き換えます。
  2. マネージドクラスターのコマンドラインで、次のコマンドを実行してカタログソースを変更します。

    oc apply -f source.yaml
1.3.3.2.9. マネージドクラスターのパラメーターを変更する

マネージドクラスターの ClusterVersion リソース情報を更新して、アップグレードを取得するデフォルトの場所を変更します。

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

    oc get clusterversion -o yaml

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

    apiVersion: v1
    items:
    - apiVersion: config.openshift.io/v1
      kind: ClusterVersion
      [..]
      spec:
        channel: stable-4.12
        upstream: https://api.openshift.com/api/upgrades_info/v1/graph
  2. ハブクラスターから、次のコマンドを入力して、OpenShift Update Service オペランドへのルート URL を特定します。

    oc get routes

    後のステップのために戻り値に注意してください。

  3. マネージドクラスターのコマンドラインで、次のコマンドを入力して ClusterVersion リソースを編集します。

    oc edit clusterversion version

    spec.channel の値を新しいバージョンに置き換えます。

    spec.upstream の値は、ハブクラスター OpenShift Update Service オペランドへのパスに置き換えます。次の手順を実行して、オペランドへのパスを決定できます。

    1. ハブクラスターで以下のコマンドを実行してください。

      oc get routes -A
    2. cincinnati へのパスを見つけます。オペランドのパスは、HOST/PORT フィールドの値です。
  4. マネージドクラスターのコマンドラインで、次のコマンドを入力して、ClusterVersion のアップストリームパラメーターがローカルハブクラスターの OpenShift Update Service URL で更新されていることを確認します。

    oc get clusterversion -o yaml

    結果は次のような内容になります。

    apiVersion: v1
    items:
    - apiVersion: config.openshift.io/v1
      kind: ClusterVersion
      [..]
      spec:
        channel: stable-4.12
        upstream: https://<hub-cincinnati-uri>/api/upgrades_info/v1/graph
1.3.3.2.10. 利用可能なアップグレードの表示

Cluster ページでは、オフラインレジストリーにアップグレードがある場合、クラスターの Distribution version に、利用可能なアップグレードがあることが示されます。クラスターを選択し、Actions メニューから Upgrade clusters を選択すると、利用可能なアップグレードを表示できます。オプションのアップグレードパスが利用可能な場合は、利用可能なアップグレードがリストされます。

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

1.3.3.2.11. チャネルの選択

コンソールを使用して、OpenShift Container Platform バージョン 4.6 以降でクラスターをアップグレードするためのチャネルを選択できます。これらのバージョンはミラーレジストリーで利用可能である必要があります。Selecting a channel の手順を実行して、アップグレードチャネルを指定します。

1.3.3.2.12. クラスターのアップグレード

オフラインレジストリーを設定すると、マルチクラスターエンジンオペレーターと OpenShift Update Service はオフラインレジストリーを使用して、アップグレードが利用可能かどうかを判断します。利用可能なアップグレードが表示されない場合は、クラスターの現行のリリースイメージと、1 つ後のイメージがローカルリポジトリーにミラーリングされていることを確認します。クラスターの現行バージョンのリリースイメージが利用できないと、アップグレードは利用できません。

Cluster ページでは、オフラインレジストリーにアップグレードがある場合、クラスターの Distribution version に、利用可能なアップグレードがあることが示されます。イメージをアップグレードするには、Upgrade available をクリックし、アップグレードするバージョンを選択します。マネージドクラスターは、選択したバージョンに更新されます。

クラスターのアップグレードに失敗すると、Operator は通常アップグレードを数回再試行し、停止し、コンポーネントに問題があるステータスを報告します。場合によっては、アップグレードプロセスは、プロセスの完了を繰り返し試行します。アップグレードに失敗した後にクラスターを以前のバージョンにロールバックすることはサポートされていません。クラスターのアップグレードに失敗した場合は、Red Hat サポートにお問い合わせください。

1.3.4. 詳細設定

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

1.3.4.1. ローカルクラスターの有効化

デフォルトでは、マルチクラスターエンジン 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.4.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.4.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.4.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.4.5. nodeSelector

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

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

1.3.4.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.4.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.4.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.5. アンインストール

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

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

1.3.5.1. 前提条件: 有効化されたサービスのデタッチ

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

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

    Cannot delete MultiClusterEngine resource because ManagedCluster resource(s) exist

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

1.3.5.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.5.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.5.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

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.11/html/installing/disconnected-installation-mirroring

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 AWS credentials を参照してください。
  • AWS でクラスターをインストールできるようにするアカウントの権限。設定の方法は、AWS アカウントの設定 を参照してください。

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

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

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

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

  1. AWS アカウントの AWS アクセスキー ID を追加します。AWS にログインして ID を見つけます。
  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 pull secret を入力します。Pull secret からプルシークレットをダウンロードします。
  5. SSH 秘密鍵SSH 公開鍵 を追加し、クラスターに接続できるようにします。既存のキーペアを使用するか、キー生成プログラムで新しいキーを作成できます。

キー生成の方法は、SSH プライベートキーの生成およびエージェントへの追加 を参照してください。

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

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

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

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

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.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 ログイン認証情報。azure.microsoft.com を参照してください。
  • Azre でクラスターがインストールできるようにするアカウントの権限。詳細は、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 は、お使いのサービスプリンシパル名に置き換えます。詳細については、Create an Azure service principal with the Azure CLI を参照してください。

  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 を入力します。Pull secret からプルシークレットをダウンロードします。
  10. クラスターへの接続に使用する SSH 秘密鍵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.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 を追加します。GCP にログインして設定を取得します。
  2. Google Cloud Platform service account JSON key を追加します。https://cloud.google.com/iam/docs/creating-managing-service-accounts を参照して、サービスアカウントの 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 pull secret を入力します。Pull secret からプルシークレットをダウンロードします。
  6. クラスターにアクセスできるように SSH 秘密鍵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.4. VMware vSphere の認証情報の作成

マルチクラスターエンジン Operator コンソールを使用して、VMware vSphere で Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、認証情報が必要です。注記: OpenShift Container Platform バージョン 4.5.x 以降のみがサポートされます。

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

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

1.4.4.1. 前提条件

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

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

    • vCenter アカウントの権限
    • クラスターリソース
    • HDCP が利用できる
    • 時間を同期した 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

      ベストプラクティス: 以下のコマンドを使用して、拡張子が .0 の複数の証明書をリンクします。

      cat certs/lin/*.0 > ca.crt
  5. VMware vSphere クラスター名 を追加します。
  6. VMware vSphere データセンター を追加します。
  7. VMware vSphere デフォルトデータストア を追加します。
  8. VMware vSphere ディスクタイプ を追加します。
  9. VMware vSphere フォルダー を追加します。
  10. VMware vSphere リソースプール を追加します。
  11. オフラインインストールのみ: 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
  12. プロキシーを有効にする場合は、プロキシー情報を入力します。

    • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL。
    • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
    • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
    • 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。
  13. Red Hat OpenShift pull secret を入力します。Pull secret からプルシークレットをダウンロードします。
  14. SSH 秘密鍵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.5. Red Hat OpenStack の認証情報の作成

マルチクラスターエンジン Operator コンソールを使用して、Red Hat OpenStack Platform で Red Hat OpenShift Container Platform クラスターをデプロイおよび管理するには、認証情報が必要です。注記: OpenShift Container Platform バージョン 4.5.x 以降のみがサポートされます。

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

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. Red Hat OpenStack Platform の clouds.yaml ファイルの内容を追加します。パスワードを含む clouds.yaml ファイルの内容で、Red Hat OpenStack Platform サーバーへの接続に必要な情報を提供します。ファイルの内容には、username の直後に新たに追加したパスワードを含める必要があります。
  2. 内部認証局を使用する設定については、clouds.yaml ファイルを変更して、Hive デプロイヤー Pod 内の証明書バンドルの最終場所を参照します。Hive は、証明書バンドルシークレットをデプロイヤー Pod 内の /etc/openstack-ca にマウントします。そのディレクトリー内のファイルは、クラスターの作成時に提供されるシークレットのキーに対応します。

    シークレットでキー ca.crt が使用されている場合は、以下の例のように cacert パラメーターを clouds.yaml ファイルに追加します。

    clouds:
      openstack:
        auth:
          auth_url: https://openstack.example.local:13000
          username: "svc-openshift"
          project_id: aa0owet0wfwerj
          user_domain_name: "idm"
          password: REDACTED
          region_name: "regionOne"
          interface: "public"
          identity_api_version: 3
          cacert: /etc/openstack-ca/ca.crt
  3. Red Hat OpenStack Platform クラウド名を追加します。このエントリーは、Red Hat OpenStack Platform サーバーへの通信確立に使用する clouds.yaml の cloud セクションで指定した名前です。
  4. オプションで、認証情報のベース DNS ドメインを追加できます。ベース DNS ドメインを認証情報に追加した場合は、この認証情報でクラスターを作成すると、このベース DNS ドメインは自動的に正しいフィールドに設定されます。
  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 プルシークレットを入力します。Pull secret からプルシークレットをダウンロードします。
  8. SSH 秘密鍵と 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.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. 前提条件

cloud.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. 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 マネージドクラスターに登録およびワークコントローラーをデプロイします。
  • 登録エージェント は、マネージドクラスターとマネージドクラスターアドオンをハブクラスターに登録します。登録エージェントは、管理対象クラスターと管理対象クラスターアドオンのステータスも維持します。次のアクセス許可が Clusterrole 内に自動的に作成され、マネージドクラスターがハブクラスターにアクセスできるようになります。

    • エージェントは、ハブクラスターが管理する所有クラスターを取得または更新できます。
    • エージェントが、ハブクラスターが管理する所有クラスターのステータスを更新できるようにします。
    • エージェントが証明書をローテーションできるようにします。
    • エージェントが 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.2 ブランチの 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.2
  gitRepoPath: clusterImageSets
  channel: fast

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

apiVersion: config.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: fast
    visible: 'true'
  name: img4.12.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 ファイルです。Red Hat Advanced Cluster Management はこれらのファイルを使用して、コンソールで利用可能なリリースイメージの一覧を作成します。これには、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.12.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.2
  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 フィールドの値を steady に更新します。

ConfigMap を更新すると、約 1 分以内に、利用可能な安定リリースイメージのリストが現在利用可能なイメージで更新されます。デフォルトでは、Red Hat Advanced Cluster Management は、複数の ClusterImageSets を事前に読み込みます。

  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.7 で利用可能なクラスターイメージセットにアクセスします。
  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.12.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 クラスターの作成に使用できるベアメタルまたは仮想マシンのプールです。これらのクラスターは、コントロールプレーン専用のマシンまたは Hosted control plane を備えたスタンドアロンにすることができます。ここでは、コントロールプレーンはハブクラスター上の Pod として実行されれます。

スタンドアロンクラスターは、コンソール、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.12 以降にハブクラスターをデプロイしている。
  • クラスターを作成するために必要なイメージを取得するためのハブクラスターへのインターネットアクセス (接続済み)、あるいはインターネットへの接続がある内部またはミラーレジストリーへの接続 (非接続) がある。
  • ベアメタルプロビジョニングに必要なポートを開く必要があります。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-serviceassisted-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 ファイルを作成し、以下の内容を追加します。必要に応じて値を置き換えますが、spec フィールドで必要な唯一のプロパティーは pullSecretRef です。

      apiVersion: agent-install.openshift.io/v1beta1
      kind: InfraEnv
      metadata:
        name: myinfraenv
        namespace: <your_namespace>
      spec:
        proxy: 1
          httpProxy: <http://user:password@ipaddr:port> 2
          httpsProxy: <http://user:password@ipaddr:port> 3
          noProxy: 4
        additionalNTPSources: 5
        sshAuthorizedKey: 6
        pullSecretRef:
          name: <name> 7
        agentLabels: 8
          <key>: <value>
        nmStateConfigLabelSelector: 9
          matchLabels:
            <key>: <value>
        clusterRef: 10
          name: <cluster_name>
          namespace: <projecct_name>
        ignitionConfigOverride: '{"ignition": {"version": "3.1.0"}, …}' 11
        cpuArchitecture: x86_64 12
        ipxeScriptType: DiscoveryImageAlways 13
        kernelArguments: 14
          - operation: append
            value: audit=0
        additionalTrustBundle: <bundle> 15
        osImageVersion: <version> 16
      1
      InfraEnv リソースを使用するエージェントとクラスターのプロキシー設定を定義します。proxy の値を設定しない場合、エージェントはプロキシーを使用するように設定されません。
      2
      HTTP リクエストのプロキシーの URLURL は http で開始する必要があります。HTTPS はサポートされていません。
      3
      HTTP リクエストのプロキシーの URLURL は http で開始する必要があります。HTTPS はサポートされていません。
      4
      プロキシーを使用しない場合は、コンマで区切られたドメインおよび CIDR のリスト。
      5
      すべてのホストに追加するネットワークタイムプロトコル (NTP) ソース (ホスト名または IP) のリスト。これらは、DHCP などの他のオプションを使用して設定された NTP ソースに追加されます。
      6
      SSH 公開鍵。検出フェーズ (ホストが Discovery Image を起動するとき) 中にデバッグに使用するためにすべてのホストに追加されます。
      7
      プルシークレットが含まれる Kubernetes シークレットの名前。
      8
      InfraEnv で検出されたホストを表す Agent リソースに自動的に追加されるラベル。キーと値を必ず追加してください。
      9
      ホストの静的 IP、ブリッジ、ボンディングなどの高度なネットワーク設定を統合します。ホストネットワーク設定は、選択したラベルを持つ 1 つ以上の NMStateConfig リソースで指定されます。nmStateConfigLabelSelector プロパティーは、選択したラベルと一致する Kubernetes ラベルセレクターです。このラベルセレクターに一致するすべての NMStateConfig ラベルのネットワーク設定は、Discovery Image に含まれています。起動時に、各ホストは各設定をそのネットワークインターフェイスと比較し、適切な設定を適用します。高度なネットワーク設定の詳細は、ホストインベントリーの高度なネットワークの設定 セクションへのリンクを参照してください。
      10
      スタンドアロンのオンプレミスクラスターを記述する既存の ClusterDeployment リソースを参照します。デフォルトでは設定されません。clusterRef が設定されていない場合は、後でホストを 1 つ以上のクラスターにバインドできます。ホストは、あるクラスターから削除して別のクラスターに追加することもできます。ただし、clusterRef が設定されている場合、この InfraEnv で検出されたすべてのホストは、指定されたクラスターに自動的にバインドされます。クラスターがインストールされていない場合、すべての検出ホストがそのインストールの一部になります。クラスターがすでにインストールされている場合は、検出ホストが追加されます。
      11
      ファイルの追加など、Red Hat CoreOS ライブイメージの Ignition 設定を変更します。必要に応じて ignitionConfigOverride のみを使用してください。クラスターのバージョンに関係なく、ignition バージョン 3.1.0 を使用する必要があります。
      12
      サポートされている CPU アーキテクチャー x86_64、aarch64、ppc64le、または s390x のいずれかを選択します。デフォルト値は x86_64 です。
      13
      DiscoveryImageAlways のデフォルト値に設定されている場合、および iPXE を使用して起動している場合、イメージサービスは常に iPXE スクリプトを提供します。その結果、ホストはネットワーク検出イメージから起動します。値を BootOrderControl に設定すると、イメージサービスは、ホストの状態に応じて iPXE スクリプトを返すタイミングを決定します。これにより、ホストがプロビジョニングされ、クラスターの一部になっている場合には、ホストがディスクから起動します。
      14
      Discovery Image の起動時にカーネル引数を変更できます。operation に使用できる値は、appendreplace、または delete です。
      15
      PEM エンコードされた X.509 証明書バンドル。通常、ホストが再暗号化中間者 (MITM) プロキシーを備えたネットワーク内にある場合、またはコンテナーイメージレジストリーなど、他の目的でホストが証明書を信頼しなければならない場合に必要です。InfraEnv によって検出されたホストは、このバンドル内の証明書を信頼します。InfraEnv によって検出されたホストから作成されたクラスターは、このバンドル内の証明書も信頼します。
      16
      InfraEnv に使用する Red Hat CoreOS イメージのバージョン。バージョンが AgentServiceConfig.spec.osImages で指定された OS イメージを参照していること、および OSImageVersion が OS イメージリスト内の OpenShift Container Platform バージョンと一致していることを確認してください。OSImageVersionClusterRef を同時に指定できません。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
    2. 以下のコマンドを実行して YAML コンテンツを適用します。

      oc apply -f infra-env.yaml
    3. ホストインベントリーが作成されたことを確認するには、次のコマンドでステータスを確認します。
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 1
      namespace: <your-infraenv-namespace> 2
      labels:
        some-key: <some-value> 3
    spec:
      config: 4
        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: 5
        - name: "eth0"
          macAddress: "02:00:00:80:12:14"
        - name: "eth1"
          macAddress: "02:00:00:80:12:15"
    1
    設定しているホストに関連した名前を使用してください。
    2
    namespace は、InfraEnv リソースの namespace と一致する必要があります。
    3
    nmStateConfigLabelSelector に一致する 1 つ以上のラベルを InfraEnv リソースに追加します。
    4
    NMstate 形式のネットワーク設定について説明します。形式の指定と追加の例については、Declarative Network API を参照してください。この設定は、ホストごとに 1 つの NMStateConfig リソースがある単一のホストに適用することも、単一の NMStateConfig リソースで複数のホストのインターフェイスを記述することもできます。
    5
    指定された NMstate 設定で見つかったインターフェイス名とホストで見つかった MAC アドレスの間のマッピングを記述します。マッピングがホスト上に存在する物理インターフェイスを使用していることを確認してください。たとえば、NMState 設定でボンドまたは VLAN が定義されている場合、マッピングには親インターフェイスのエントリーのみが含まれます。マッピングの目的は以下のとおりです。
    • ホスト上のインターフェイス名と一致しないインターフェイス名を設定内で使用できるようにします。オペレーティングシステムによりインターフェイス名 (これは予測できない) が選択されるので、便利な場合があります。
    • 起動後に検索する MAC アドレスをホストに指示し、正しい NMstate 設定を適用します。

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

  2. 以下のコマンドを実行して 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.2
  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 の認証情報の作成 を参照してください。

クラスターの名前はクラスターのホスト名で使用されます。

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 ドキュメントの Control access to VPC endpoints using endpoint policies を参照してください。

たとえば、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 のマルチクラスターエンジンの管理下に自動的に設定されます。

クラスターにアクセスする 手順については、クラスターへのアクセスに進みます。

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 ファイルを編集できます。

注記: クラスターのインポートには、クラスターの詳細で提示された 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 ファイルを編集できます。

注記: クラスターのインポートには、クラスターの詳細で提示された 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 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 ファイルを編集できます。

注記: クラスターのインポートには、クラスターの詳細で提示された 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 の Floating IP アドレスを指す api.<cluster_name>.<base_domain>
      • Ingreess の Floating 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 であることを前提としています。

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

クラスターにアクセスする 手順については、クラスターへのアクセスに進みます。

1.5.4.9. Red Hat Virtualization でのクラスターの作成

マルチクラスターエンジン Operator コンソールを使用して、Red Hat Virtualization に Red Hat OpenShift Container Platform クラスターを作成できます。

クラスターを作成する場合、作成プロセスでは、Hive リソースを使用して OpenShift Container Platform インストーラーを使用します。この手順の完了後にクラスターの作成について不明な点がある場合は、OpenShift Container Platform ドキュメントの RHV へのインストール でプロセスの詳細を確認してください。

1.5.4.9.1. 前提条件

Red Hat Virtualization でクラスターを作成する前に、以下の前提条件を確認してください。

  • ハブクラスターをデプロイしている。
  • Red Hat Virtualization の認証情報がある。詳細は、Red Hat Virtualization の認証情報の作成 を参照してください。
  • oVirt Engine 仮想マシンに設定されたドメインおよび仮想マシンプロキシーがある。ドメインの設定方法は、Red Hat OpenShift Container Platform ドキュメントの RHV へのインストール を参照してください。
  • Red Hat Virtualization のログイン認証情報 (Red Hat カスタマーポータルのユーザー名およびパスワードを含む) がある。
  • OpenShift Container Platform イメージプルシークレットがある。Pull secret からプルシークレットをダウンロードします。プルシークレットの詳細は、イメージプルシークレットの使用 を参照してください。

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

1.5.4.9.2. コンソールを使用したクラスターの作成

マルチクラスターエンジン Operator コンソールからクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。

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

認証情報を作成する必要がある場合は Red Hat Virtualization の認証情報の作成 を参照してください。

クラスターの名前はクラスターのホスト名で使用されます。

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

Red Hat Virtualization アカウントで設定した、選択した認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値を上書きして変更できます。

このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細は、リリースイメージ を参照してください。

コントロールプレーンプールのコア、ソケット、メモリー、およびディスクサイズの数など、ノードプールの情報。3 つのコントロールプレーンノードは、クラスターアクティビティーの管理を共有します。この情報には、Architecture フィールドが含まれます。次のフィールドの説明を表示します。

  • CPU アーキテクチャー:マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64ppc64les390x、および arm64 です。

ワーカープール情報には、ワーカープールのプール名、コア数、メモリー割り当て、ディスクサイズ割り当て、およびノード数が必要です。ワーカープール内のワーカーノードは単一のワーカープールに配置するか、複数のワーカープールに分散できます。

事前設定された oVirt 環境には、以下のネットワークの詳細が必要です。

  • oVirt ネットワーク名
  • vNIC Profile ID: 仮想ネットワークインターフェイスカードのプロファイル ID を指定します。
  • API VIP: 内部 API 通信に使用する IP アドレスを指定します。

    注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して api. が正しく解決されるようにします。

  • Ingress VIP: Ingress トラフィックに使用する IP アドレスを指定します。

    注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して test.apps. が正しく解決されるようにします。

  • ネットワークタイプ: デフォルト値は OpenShiftSDN です。IPv6 を使用するには、OVNKubernetes の設定は必須です。
  • クラスターネットワーク CIDR: これは、Pod IP アドレスに使用できる IP アドレスの数およびリストです。このブロックは他のネットワークブロックと重複できません。デフォルト値は 10.128.0.0/14 です。
  • ネットワークホストの接頭辞: 各ノードのサブネット接頭辞の長さを設定します。デフォルト値は 23 です。
  • サービスネットワーク CIDR: サービスの IP アドレスのブロックを指定します。このブロックは他のネットワークブロックと重複できません。デフォルト値は 172.30.0.0/16 です。
  • マシン CIDR: OpenShift Container Platform ホストで使用される IP アドレスのブロックを指定します。このブロックは他のネットワークブロックと重複できません。デフォルト値は 10.0.0.0/16 です。

    Add network をクリックして、追加のネットワークを追加できます。IPv6 アドレスを使用している場合は、複数のネットワークが必要です。

認証情報で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。情報をそのまま使用することも、上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。

  • HTTP プロキシー: HTTP トラフィックのプロキシーとして使用する URL を指定します。
  • HTTPS プロキシー: HTTPS トラフィックに使用するセキュアなプロキシー URL を指定します。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
  • プロキシーサイトなし: プロキシーをバイパスする必要のあるサイトのコンマ区切りリストを指定します。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  • 追加の信頼バンドル: HTTPS 接続のプロキシーに必要な 1 つ以上の追加の CA 証明書。

クラスターを作成する前に情報を確認し、必要に応じてカスタマイズする場合は、YAML スイッチをクリックして On にすると、パネルに install-config.yaml ファイルの内容が表示されます。更新がある場合は、カスタム設定で YAML ファイルを編集できます。

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

クラスターにアクセスする 手順については、クラスターへのアクセスに進みます。

1.5.4.10. オンプレミス環境でのクラスターの作成

コンソールを使用して、オンプレミスの Red Hat OpenShift Container Platform クラスターを作成できます。

この手順を使用すると、VMware vSphere、Red Hat OpenStack、Red Hat Virtualization Platform、およびベアメタル環境で、単一ノード OpenShift (SNO) クラスター、マルチノードクラスター、およびコンパクトな 3 ノードクラスターを作成できます。

プラットフォームの値が platform=none に設定されているため、クラスターをインストールするプラットフォームとのプラットフォーム統合はありません。シングルノード OpenShift クラスターには、コントロールプレーンサービスとユーザーワークロードをホストするシングルノードのみが含まれます。この設定は、クラスターのリソースフットプリントを最小限に抑えたい場合に役立ちます。

Red Hat OpenShift Container Platform で利用できる機能であるゼロタッチプロビジョニング機能を使用して、エッジリソース上に複数のシングルノード OpenShift クラスターをプロビジョニングすることもできます。詳細は、OpenShift Container Platform ドキュメントの 非接続環境でのスケールでの分散ユニットのデプロイ を参照してください。

1.5.4.10.1. 前提条件

オンプレミス環境にクラスターを作成する前に、以下の前提条件を確認してください。

  • ハブクラスターが OpenShift Container Platform バージョン 4.9 以降にデプロイされている。
  • 設定済みホストのホストインベントリーを備えた設定済みインフラストラクチャー環境が必要です。
  • クラスターの作成に必要なイメージを取得するには、ハブクラスターのインターネットアクセス (接続)、またはインターネットへの接続 (切断) を持つ内部またはミラーレジストリーへの接続が必要です。
  • オンプレミス認証情報が設定されている。
  • OpenShift Container Platform イメージプルシークレットがある。詳細は、イメージプルシークレットの使用 を参照してください。
1.5.4.10.2. コンソールを使用したクラスターの作成

コンソールからクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。

  • クラスターのタイプとして Host inventory を選択します。

支援インストールでは、次のオプションを使用できます。

  • 既存の検出されたホストを使用する: 既存のホストインベントリーにあるホストのリストからホストを選択します。
  • 新規ホストの検出: 既存のインフラストラクチャー環境にないホストを検出します。インフラストラクチャー環境にあるものを使用するのではなく、独自のホストを検出します。

認証情報を作成する必要がある場合は オンプレミス環境の認証情報の作成 を参照してください。

クラスターの名前は、クラスターのホスト名で使用されます。

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

ヒント: YAML: On を選択すると、コンソールに情報を入力する際にコンテンツの更新が表示されます。

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットがない場合には、クラスター管理者に連絡して、任意のクラスターセットへの clusterset-admin 権限を受け取ってください。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

プロバイダーアカウントで設定した、選択した認証情報に関連付けられているベース DNS ドメインがすでに存在する場合、その値がフィールドに入力されます。値は上書きすると変更できますが、この設定はクラスターの作成後には変更できません。プロバイダーのベースドメインは、Red Hat OpenShift Container Platform クラスターコンポーネントへのルートの作成に使用されます。これは、クラスタープロバイダーの DNS で Start of Authority (SOA) レコードとして設定されます。

OpenShift version は、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。使用するバージョンが利用可能な場合は、イメージの一覧からイメージを選択できます。標準イメージ以外のイメージを使用する場合は、使用するイメージの URL を入力できます。リリースイメージの詳細は、リリースイメージ を参照してください。

4.9 以降の OpenShift バージョンを選択すると、Install single node OpenShift (SNO) を選択するオプションが表示されます。シングルノード OpenShift クラスターには、コントロールプレーンサービスとユーザーワークロードをホストするシングルノードが含まれます。

クラスターをシングルノード OpenShift クラスターにする場合は、シングルノード OpenShift オプションを選択します。以下の手順を実行することで、シングルノードの OpenShift クラスターにワーカーを追加できます。

  1. コンソールから、Infrastructure > Clusters に移動し、作成したクラスターまたはアクセスするクラスターの名前を選択します。
  2. Actions > Add hosts を選択して、ワーカーを追加します。

注記: シングルノード OpenShift コントロールプレーンには 8 つの CPU コアが必要ですが、マルチノードコントロールプレーンクラスターのコントロールプレーンノードには 4 つの CPU コアしか必要ありません。

クラスターを確認して保存すると、クラスターはドラフトクラスターとして保存されます。Clusters ページでクラスター名を選択すると、作成プロセスを閉じてプロセスを終了することができます。

既存のホストを使用している場合は、ホストを独自に選択するか、自動的に選択するかどうかを選択します。ホストの数は、選択したノード数に基づいています。たとえば、SNO クラスターではホストが 1 つだけ必要ですが、標準の 3 ノードクラスターには 3 つのホストが必要です。

このクラスターの要件を満たす利用可能なホストの場所は、ホストの場所 のリストに表示されます。ホストと高可用性設定の分散については、複数の場所を選択します。

既存のインフラストラクチャー環境がない新しいホストを検出する場合は、Discovery Image を使用したホストインベントリーへのホストの追加 の手順を実行します。

ホストがバインドされ、検証に合格したら、以下の IP アドレスを追加してクラスターのネットワーク情報を入力します。

  • API VIP: 内部 API 通信に使用する IP アドレスを指定します。

    注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して api. が正しく解決されるようにします。

  • Ingress VIP: Ingress トラフィックに使用する IP アドレスを指定します。

    注記: 値は、要件セクションに記載されている DNS レコードの作成に使用した名前と一致させる必要があります。指定しない場合は、DNS を事前設定して test.apps. が正しく解決されるようにします。

Clusters ナビゲーションページで、インストールのステータスを表示できます。

クラスターにアクセスする 手順については、クラスターへのアクセスに進みます。

1.5.4.10.3. コマンドラインを使用したクラスターの作成

Central Infrastructure Management 管理コンポーネント内のアシステッドインストーラー機能を使用して、コンソールを使用せずにクラスターを作成することもできます。この手順を完了したら、生成された検出イメージからホストを起動できます。通常、手順の順序は重要ではありませんが、順序が必要な場合は注意してください。

1.5.4.10.3.1. namespace を作成します。

リソースの namespace が必要です。すべてのリソースを共有 namespace に保持すると便利です。この例では、namespace の名前に sample-namespace を使用していますが、assisted-installer 以外の任意の名前を使用できます。次のファイルを作成して適用して namespace を作成します。

apiVersion: v1
kind: Namespace
metadata:
  name: sample-namespace
1.5.4.10.3.2. プルシークレットを namespace に追加する

以下のカスタムリソースを作成し、適用して プルシークレット を namespace に追加します。

apiVersion: v1
kind: Secret
type: kubernetes.io/dockerconfigjson
metadata:
  name: <pull-secret>
  namespace: sample-namespace
stringData:
  .dockerconfigjson: 'your-pull-secret-json' 1
1
プルシークレットの内容を追加します。たとえば、これには cloud.openshift.comquay.io、または registry.redhat.io 認証を含めることができます。
1.5.4.10.3.3. ClusterImageSet の生成

以下のカスタムリソースを作成して適用することで、CustomImageSet を生成してクラスターの OpenShift Container Platform のバージョンを指定します。

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  name: openshift-v4.12.0
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.12.0-rc.0-x86_64
1.5.4.10.3.4. ClusterDeployment カスタムリソースを作成します。

ClusterDeployment カスタムリソース定義は、クラスターのライフサイクルを制御する API です。これは、クラスターリソースを定義する spec.ClusterInstallRef 設定で AgentClusterInstall カスタムリソースを参照します。

以下の例に基づいて ClusterDeployment カスタムリソースを作成して適用します。

apiVersion: hive.openshift.io/v1
kind: ClusterDeployment
metadata:
  name: single-node
  namespace: demo-worker4
spec:
  baseDomain: hive.example.com
  clusterInstallRef:
    group: extensions.hive.openshift.io
    kind: AgentClusterInstall
    name: test-agent-cluster-install 1
    version: v1beta1
  clusterName: test-cluster
  controlPlaneConfig:
    servingCertificates: {}
  platform:
    agentBareMetal:
      agentSelector:
        matchLabels:
          location: internal
  pullSecretRef:
    name: <pull-secret> 2
1
AgentClusterInstall リソースの名前を使用します。
2
Add the pull secret to the namespace でダウンロードしたプルシークレットを使用します。
1.5.4.10.3.5. AgentClusterInstall カスタムリソースを作成します。

AgentClusterInstall カスタムリソースでは、クラスターの要件の多くを指定できます。たとえば、クラスターネットワーク設定、プラットフォーム、コントロールプレーンの数、およびワーカーノードを指定できます。

次の例のようなカスタムリソースを作成して追加します。

apiVersion: extensions.hive.openshift.io/v1beta1
kind: AgentClusterInstall
metadata:
  name: test-agent-cluster-install
  namespace: demo-worker4
spec:
  platformType: BareMetal 1
  clusterDeploymentRef:
    name: single-node 2
  imageSetRef:
    name: openshift-v4.12.0 3
  networking:
    clusterNetwork:
    - cidr: 10.128.0.0/14
      hostPrefix: 23
    machineNetwork:
    - cidr: 192.168.111.0/24
    serviceNetwork:
    - 172.30.0.0/16
  provisionRequirements:
    controlPlaneAgents: 1
  sshPublicKey: ssh-rsa <your-public-key-here> 4
1
クラスターが作成される環境のプラットフォームタイプを指定します。有効な値は、BareMetalNoneVSphere、または External です。
2
ClusterDeployment リソースに使用したものと同じ名前を使用します。
3
Generate a ClusterImageSet で生成した ClusterImageSet を使用します。
4
SSH 公開鍵を指定すると、インストール後にホストにアクセスできるようになります。
1.5.4.10.3.6. オプション: NMStateConfig カスタムリソースを作成する

NMStateConfig カスタムリソースは、静的 IP アドレスなどのホストレベルのネットワーク設定がある場合にのみ必要です。このカスタムリソースを含める場合は、InfraEnv カスタムリソースを作成する前にこの手順を完了する必要があります。NMStateConfig は、InfraEnv カスタムリソースの spec.nmStateConfigLabelSelector の値によって参照されます。

次の例のように、NMStateConfig カスタムリソースを作成して適用します。

apiVersion: agent-install.openshift.io/v1beta1
kind: NMStateConfig
metadata:
  name: mynmstateconfig
  namespace: demo-worker4
  labels:
    demo-nmstate-label: value 1
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"

demo-nmstate-label ラベル名とその値は、InfraEnv リソースの spec.nmStateConfigLabelSelector.matchLabels フィールドに含める必要があります。

1.5.4.10.3.7. InfraEnv カスタムリソースを作成します。

InfraEnv カスタムリソースは、検出 ISO を作成する設定を提供します。このカスタムリソース内で、プロキシー設定、Ignition オーバーライドの値を特定し、NMState ラベルを指定します。このカスタムリソースの spec.nmStateConfigLabelSelector の値は、NMStateConfig カスタムリソースを参照します。

注: オプションの NMStateConfig カスタムリソースを含める場合は、InfraEnv カスタムリソースでそちらを参照する必要があります。NMStateConfig カスタムリソースを作成する前に InfraEnv カスタムリソースを作成した場合は、InfraEnv カスタムリソースを編集して NMStateConfig カスタムリソースを参照し、参照の追加後に ISO をダウンロードします。

以下のカスタムリソースを作成して適用します。

apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: myinfraenv
  namespace: demo-worker4
spec:
  clusterRef:
    name: single-node  1
    namespace: demo-worker4 2
  pullSecretRef:
    name: pull-secret
    sshAuthorizedKey: <your_public_key_here> 3
  nmStateConfigLabelSelector:
    matchLabels:
      demo-nmstate-label: value 4
1 1
Create the ClusterDeploymentclusterDeployment リソース名を置き換えます。
2
ClusterDeployment の作成clusterDeployment リソース namespace を置き換えます。
3
オプション: SSH 公開鍵を指定できます。これにより、検出 ISO イメージからホストを起動するときにホストにアクセスできるようになります。
4
ラベル名とラベル値は オプション: NMStateConfig カスタムリソースの作成 で作成した NMStateConfig カスタムリソースの label セクションの値と一致する必要があります。
1.5.4.10.3.8. 検出イメージからホストを起動します。

残りの手順では、前の手順で取得した検出 ISO イメージからホストを起動する方法について説明します。

  1. 次のコマンドを実行して、namespace から検出イメージをダウンロードします。

    curl --insecure -o image.iso $(kubectl -n sample-namespace get infraenvs.agent-install.openshift.io myinfraenv -o=jsonpath="{.status.isoDownloadURL}")
  2. 検出イメージを仮想メディア、USB ドライブ、または別の保管場所に移動し、ダウンロードしたディスカバリーイメージからホストを起動します。
  3. Agent リソースは自動的に作成されます。これはクラスターに登録されており、検出イメージから起動したホストを表します。次のコマンドを実行して、エージェントの カスタムリソースを承認し、インストールを開始します。

    oc -n sample-namespace patch agents.agent-install.openshift.io 07e80ea9-200c-4f82-aff4-4932acb773d4 -p '{"spec":{"approved":true}}' --type merge

    エージェント名と UUID は、実際の値に置き換えます。

    前のコマンドの出力に、APPROVED パラメーターの値が true であるターゲットクラスターのエントリーが含まれている場合、承認されたことを確認できます。

1.5.4.11. 作成されたクラスターの休止 (テクノロジープレビュー)

マルチクラスターエンジン Operator を使用して作成されたクラスターを休止状態にし、リソースを節約できます。休止状態のクラスターに必要となるリソースは、実行中のものより少なくなるので、クラスターを休止状態にしたり、休止状態を解除したりすることで、プロバイダーのコストを削減できる可能性があります。この機能は、以下の環境のマルチクラスターエンジン Operator によって作成されたクラスターにのみ適用されます。

  • Amazon Web Services
  • Microsoft Azure
  • Google Cloud Platform
1.5.4.11.1. コンソールを使用したクラスターの休止

コンソールを使用して、マルチクラスターエンジン Operator によって作成されたクラスターを休止状態にするには、以下の手順を実行します。

  1. ナビゲーションメニューから Infrastructure > Clusters を選択します。Manage clusters タブが選択されていることを確認します。
  2. そのクラスターの Options メニューから Hibernate cluster を選択します。注記: Hibernate cluster オプションが利用できない場合には、クラスターを休止状態にすることはできません。これは、クラスターがインポートされ、マルチクラスターエンジン Operator によって作成されていない場合に発生する可能性があります。

Clusters ページのクラスターのステータスは、プロセスが完了すると Hibernating になります。

ヒント: Clusters ページで休止するするクラスターを選択し、Actions > Hibernate cluster を選択して、複数のクラスターを休止できます。

選択したクラスターが休止状態になりました。

1.5.4.11.2. CLI を使用したクラスターの休止

CLI を使用してマルチクラスターエンジン Operator によって作成されたクラスターを休止状態にするには、以下の手順を実行します。

  1. 以下のコマンドを入力して、休止するクラスターの設定を編集します。

    oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>

    name-of-cluster は、休止するクラスター名に置き換えます。

    namespace-of-cluster は、休止するクラスターの namespace に置き換えます。

  2. spec.powerState の値は Hibernating に変更します。
  3. 以下のコマンドを実行して、クラスターのステータスを表示します。

    oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml

    name-of-cluster は、休止するクラスター名に置き換えます。

    namespace-of-cluster は、休止するクラスターの namespace に置き換えます。

    クラスターを休止するプロセスが完了すると、クラスターのタイプの値は type=Hibernating になります。

選択したクラスターが休止状態になりました。

1.5.4.11.3. コンソールを使用して休止中のクラスターの通常操作を再開する手順

コンソールを使用して、休止中のクラスターの通常操作を再開するには、以下の手順を実行します。

  1. ナビゲーションメニューから Infrastructure > Clusters を選択します。Manage clusters タブが選択されていることを確認します。
  2. 再開するクラスターの Options メニューから Resume cluster を選択します。

プロセスを完了すると、Clusters ページのクラスターのステータスは Ready になります。

ヒント: Clusters ページで、再開するクラスターを選択し、Actions > Resume cluster の順に選択して、複数のクラスターを再開できます。

選択したクラスターで通常の操作が再開されました。

1.5.4.11.4. CLI を使用して休止中のクラスターの通常操作を再開する手順

CLI を使用して、休止中のクラスターの通常操作を再開するには、以下の手順を実行します。

  1. 以下のコマンドを入力してクラスターの設定を編集します。

    oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>

    name-of-cluster は、休止するクラスター名に置き換えます。

    namespace-of-cluster は、休止するクラスターの namespace に置き換えます。

  2. spec.powerState の値を Running に変更します。
  3. 以下のコマンドを実行して、クラスターのステータスを表示します。

    oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml

    name-of-cluster は、休止するクラスター名に置き換えます。

    namespace-of-cluster は、休止するクラスターの namespace に置き換えます。

    クラスターの再開プロセスが完了すると、クラスターのタイプの値は type=Running になります。

選択したクラスターで通常の操作が再開されました。

1.5.4.12. プロキシー環境でのクラスターの作成

ハブクラスターがプロキシーサーバー経由で接続されている場合は、Red Hat OpenShift Container Platform クラスターを作成できます。クラスターの作成を成功させるには、以下のいずれかの状況が true である必要があります。

  • マルチクラスターエンジン Operator に、作成するマネージドクラスターとのプライベートネットワーク接続があり、マネージドクラスターがプロキシーを使用してインターネットにアクセスできる。
  • マネージドクラスターはインフラストラクチャープロバイダーにあるが、ファイアウォールポートを使用することでマネージドクラスターからハブクラスターへの通信が可能になる。

プロキシーで設定されたクラスターを作成するには、以下の手順を実行します。

  1. シークレットに保存されている install-config YAML に次の情報を追加して、ハブクラスターで cluster-wide-proxy 設定を設定します。

    apiVersion: v1
    kind: Proxy
    baseDomain: <domain>
    proxy:
      httpProxy: http://<username>:<password>@<proxy.example.com>:<port>
      httpsProxy: https://<username>:<password>@<proxy.example.com>:<port>
      noProxy: <wildcard-of-domain>,<provisioning-network/CIDR>,<BMC-address-range/CIDR>

    username は、プロキシーサーバーのユーザー名に置き換えます。

    password は、プロキシーサーバーへのアクセス時に使用するパスワードに置き換えます。

    proxy.example.com は、プロキシーサーバーのパスに置き換えます。

    port は、プロキシーサーバーとの通信ポートに置き換えます。

    wildcard-of-domain は、プロキシーをバイパスするドメインのエントリーに置き換えます。

    provisioning-network/CIDR は、プロビジョニングネットワークの IP アドレスと割り当てられた IP アドレスの数 (CIDR 表記) に置き換えます。

    BMC-address-range/CIDR は、BMC アドレスおよびアドレス数 (CIDR 表記) に置き換えます。

    以前の値を追加すると、設定はクラスターに適用されます。

  2. クラスターの作成手順を実行してクラスターをプロビジョニングします。クラスターの作成 を参照してプロバイダーを選択します。

注: install-config YAML は、クラスターをデプロイする場合にのみ使用できます。クラスターをデプロイした後、install-config.yaml に加えた新しい変更は適用されません。導入後に設定を更新するには、ポリシーを作成する必要があります。詳細は、Pod ポリシー を参照してください。

1.5.5. ハブクラスターへのターゲットのマネージドクラスターのインポート

別の Kubernetes クラウドプロバイダーからクラスターをインポートできます。インポート後、ターゲットクラスターはマルチクラスターエンジン Operator ハブクラスターのマネージドクラスターになります。指定されていない場合は、ハブクラスターとターゲットのマネージドクラスターにアクセスできる場所で、インポートタスクを実行します。

ハブクラスターは のハブクラスターの管理はできず、自己管理のみが可能です。ハブクラスターは、自動的にインポートして自己管理できるように設定されています。ハブクラスターは手動でインポートする必要はありません。

ただし、ハブクラスターを削除して再度インポートする場合は、local-cluster:true ラベルを ManagedCluster リソースに追加する必要があります。

マネージドクラスターを設定するには、以下の手順から選択します。

必要なユーザータイプまたはアクセスレベル: クラスター管理者

1.5.5.1. コンソールを使用したマネージドクラスターのインポート

Kubernetes Operator 用のマルチクラスターエンジンをインストールすると、クラスターをインポートして管理できるようになります。コンソールを使用してマネージドクラスターをインポートする方法については、以下を参照してください。

1.5.5.1.1. 前提条件
  • デプロイされたハブクラスター。ベアメタルクラスターをインポートする場合は、ハブクラスターを Red Hat OpenShift Container Platform バージョン 4.8 以降にインストールする必要があります。
  • 管理するクラスター。
  • base64 コマンドラインツール。
  • OpenShift Container Platform によって作成されていないクラスターをインポートする場合、定義された multiclusterhub.spec.imagePullSecret。このシークレットは、Kubernetes Operator 用のマルチクラスターエンジンがインストールされたときに作成された可能性があります。このシークレットを定義する方法の詳細については、カスタムイメージプルシークレット を参照してください。

Required user type or access level: クラスター管理者

1.5.5.1.2. 新規プルシークレットの作成

新しいプルシークレットを作成する必要がある場合は、以下の手順を実行します。

  1. cloud.redhat.com から Kubernetes プルシークレットをダウンロードします。
  2. プルシークレットをハブクラスターの namespace に追加します。
  3. 次のコマンドを実行して、open-cluster-management namespace に新しいシークレットを作成します。

    oc create secret generic pull-secret -n <open-cluster-management> --from-file=.dockerconfigjson=<path-to-pull-secret> --type=kubernetes.io/dockerconfigjson

    open-cluster-management をハブクラスターの namespace の名前に置き換えます。ハブクラスターのデフォルトの namespace は open-cluster-management です。

    path-to-pull-secret を、ダウンロードしたプルシークレットへのパスに置き換えます。

    シークレットは、インポート時にマネージドクラスターに自動的にコピーされます。

    • 以前にインストールされたエージェントが、インポートするクラスターから削除されていることを確認します。エラーを回避するには、open-cluster-management-agent および open-cluster-management-agent-addon namespace を削除する必要があります。
    • Red Hat OpenShift Dedicated 環境にインポートする場合には、以下の注意点を参照してください。

      • ハブクラスターを Red Hat OpenShift Dedicated 環境にデプロイしている必要があります。
      • Red Hat OpenShift Dedicated のデフォルト権限は dedicated-admin ですが、namespace を作成するための権限がすべて含まれているわけではありません。マルチクラスターエンジン Operator を使用してクラスターをインポートおよび管理するには、cluster-admin 権限が必要です。
1.5.5.1.3. クラスターのインポート

利用可能なクラウドプロバイダーごとに、コンソールから既存のクラスターをインポートできます。

注記: ハブクラスターは別のハブクラスターを管理できません。ハブクラスターは、自動的にインポートおよび自己管理するように設定されるため、ハブクラスターを手動でインポートして自己管理する必要はありません。

デフォルトでは、namespace がクラスター名と namespace に使用されますが、これは変更できます。

重要: クラスターを作成すると、コントローラーはクラスターとそのリソースの namespace を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、クラスターは default マネージドクラスターセットに自動的に追加されます。

クラスターを別のクラスターセットに追加する場合は、クラスターセットへの clusterset-admin 権限が必要です。クラスターのインポート時に cluster-admin 権限がない場合は、clusterset-admin 権限を持つクラスターセットを選択する必要があります。指定されたクラスターセットに適切な権限がない場合、クラスターのインポートは失敗します。選択するクラスターセットが存在しない場合は、クラスター管理者に連絡して、クラスターセットへの clusterset-admin 権限を受け取ってください。

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

以下の表は、クラスターをインポートする方法を指定する インポートモード で使用できるオプションを示しています。

import コマンドの手動実行

Red Hat Ansible Automation Platform テンプレートなど、コンソールで情報を完了および送信した後に、提供されたコマンドをターゲットクラスターで実行してクラスターをインポートします。

既存クラスターのサーバー URL および API トークンを入力します。

インポートするクラスターのサーバー URL および API トークンを指定します。クラスターのアップグレード時に実行する Red Hat Ansible Automation Platform テンプレートを指定できます。

kubeconfig ファイルを指定します。

インポートするクラスターの kubeconfig ファイルの内容をコピーして貼り付けます。クラスターのアップグレード時に実行する Red Hat Ansible Automation Platform テンプレートを指定できます。

注記: Ansible Automation Platform ジョブを作成して実行するには、OperatorHub から Red Hat Ansible Automation Platform Resource Operator をインストールし、実行する必要があります。クラスター API アドレスを設定するには、オプション: クラスター API アドレスの設定 を参照してください。

1.5.5.1.3.1. インポートコマンドを手動で実行する追加手順

この方法では、ターゲットクラスター上で提供されたコマンドを実行してクラスターをインポートする必要があります。

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

  1. インポートコマンドを生成してコピーします。

    1. コンソールナビゲーションから Infrastructure > Clusters を選択します。
    2. Import cluster を選択します。
    3. フォームに DetailsAutomation 情報を入力します。Import mode の選択は Run import commands manually に設定したままにしてください。Generate command をクリックすると、クラスターの概要ページが表示されます。
    4. Copy command クリックして、生成されたコマンドをクリップボードにコピーします。
  2. OpenShift Container Platform Dedicated 環境のみの場合は、以下の手順を実行します (OpenShift Container Platform Dedicated 環境を使用していない場合は、手順 3 に進みます)。

    1. インポートするクラスターの OpenShift Container Platform コンソールにログインします。
    2. インポートするクラスター上に open-cluster-management-agent および open-cluster-management namespace またはプロジェクトを作成します。
    3. OpenShift Container Platform カタログで klusterlet Operator を検索します。
    4. 作成した open-cluster-management namespace またはプロジェクトにインストールします。

      重要: open-cluster-management-agent namespace に Operator をインストールしないでください。

    5. 以下の手順を実行して、import コマンドからブートストラップシークレットをデプロイメントします。

      1. import-command という名前で作成したファイルに、import コマンドを貼り付けます。
      2. 以下のコマンドを実行して、新しいファイルにコンテンツを挿入します。

        cat import-command | awk '{split($0,a,"&&"); print a[3]}' | awk '{split($0,a,"|"); print a[1]}' | sed -e "s/^ echo //" | base64 -d
      3. 出力で bootstrap-hub-kubeconfig という名前のシークレットを見つけ、コピーします。
      4. シークレットをマネージドクラスターの open-cluster-management-agent namespace に適用します。
      5. インストールされた Operator の例を使用して klusterlet リソースを作成します。clusterName 値をインポート時に設定されたクラスター名と同じ名前に変更します。

        注記: managedcluster リソースがハブに正常に登録されると、2 つの Klusterlet Operator がインストールされます。klusterlet Operator の 1 つは open-cluster-management namespace に、もう 1 つは open-cluster-management-agent namespace にあります。複数の Operator を使用しても、Klusterlet の機能には影響しません。

  3. 次のコマンドを入力して、インポートするクラスターに kubectl がログインしていることを確認します。

    kubectl cluster-info
  4. コピーしたコマンドを実行して open-cluster-management-agent-addon をマネージドクラスターにデプロイします。

クラスター API アドレスを設定する場合は、オプション: クラスター API アドレスを設定する の手順に進みます。

1.5.5.1.3.2. オプション: クラスター API アドレスの設定

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

  1. cluster-admin 権限がある ID でハブクラスターにログインします。
  2. ターゲットに設定されたマネージドクラスターの kubeconfig ファイルを設定します。
  3. 以下のコマンドを実行して、インポートするクラスターのマネージドクラスターエントリーを編集します。

    oc edit managedcluster <cluster-name>

    cluster-name をマネージドクラスターの名前に置き換えます。

  4. 以下の例のように、YAML ファイルの ManagedCluster 仕様に manageClusterClientConfigs セクションを追加します。

    spec:
      hubAcceptsClient: true
      managedClusterClientConfigs:
      - url: <https://api.new-managed.dev.redhat.com>

    URL の値を、インポートするマネージドクラスターへの外部アクセスを提供する URL に置き換えます。

1.5.5.1.4. インポートされたクラスターの削除

以下の手順を実行して、インポートされたクラスターと、マネージドクラスターで作成された open-cluster-management-agent-addon を削除します。

Clusters ページで、Actions > Detach cluster をクリックしてマネージメントからクラスターを削除します。

注記: local-cluster という名前のハブクラスターをデタッチしようとする場合は、デフォルトの disableHubSelfManagement 設定が false である点に注意してください。この設定が原因で、ハブクラスターがデタッチされると、自身を再インポートして管理し、MultiClusterHub コントローラーが調整されます。ハブクラスターがデタッチプロセスを完了して再インポートするのに時間がかかる場合があります。プロセスが完了するのを待たずにハブクラスターを再インポートする場合は、次のコマンドを実行して multiclusterhub-operator Pod を再起動し、再インポートを高速化できます。

oc delete po -n open-cluster-management `oc get pod -n open-cluster-management | grep multiclusterhub-operator| cut -d' ' -f1`

disableHubSelfManagement の値を true に指定して、自動的にインポートされないように、ハブクラスターの値を変更できます。詳細は、disableHubSelfManagement のトピックを参照してください。

1.5.5.1.4.1. 関連情報

1.5.5.2. CLI を使用したマネージドクラスターのインポート

Kubernetes Operator 用のマルチクラスターエンジンをインストールすると、Red Hat OpenShift Container Platform CLI を使用して、クラスターをインポートおよび管理する準備が整います。自動インポートシークレットを使用するか、man コマンドを使用して、CLI でマネージドクラスターをインポートする方法については、以下のトピックを参照してください。

重要: ハブクラスターは別のハブクラスターを管理できません。ハブクラスターは、ローカルクラスター として自動的にインポートおよび管理されるようにセットアップされます。ハブクラスターは、手動でインポートして自己管理する必要はありません。ハブクラスターを削除して再度インポートする場合は、local-cluster:true ラベルを追加する必要があります。

1.5.5.2.1. 前提条件
  • デプロイされたハブクラスター。ベアメタルクラスターをインポートする場合は、ハブクラスターを OpenShift Container Platform バージョン 4.6 以降にインストールする必要があります。
  • 管理する別のクラスター。
  • oc コマンドを実行する OpenShift Container Platform CLI バージョン 4.6 以降。OpenShift Container Platform CLI のインストールと設定については、OpenShift CLI の使用方法 を参照してください。
  • OpenShift Container Platform によって作成されていないクラスターをインポートする場合、定義された multiclusterhub.spec.imagePullSecret。このシークレットは、Kubernetes Operator 用のマルチクラスターエンジンがインストールされたときに作成された可能性があります。このシークレットを定義する方法の詳細については、カスタムイメージプルシークレット を参照してください。
1.5.5.2.2. サポートされているアーキテクチャー
  • Linux (x86_64, s390x, ppc64le)
  • MacOS
1.5.5.2.3. クラスターインポートの準備

CLI を使用してマネージドクラスターをインポートする前に、以下の手順を実行する必要があります。

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

    oc login
  2. ハブクラスターで次のコマンドを実行して、プロジェクトおよび namespace を作成します。<cluster_name> で定義されているクラスター名は、YAML ファイルとコマンドでクラスター namespace としても使用されます。

    oc new-project <cluster_name>

    重要: cluster.open-cluster-management.io/managedCluster ラベルは、マネージドクラスターの namespace に対して自動的に追加および削除されます。手動でマネージドクラスター namespace に追加したり、削除したりしないでください。

  3. 以下の内容例で managed-cluster.yaml という名前のファイルを作成します。

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

    cloud および vendor の値を auto-detect する場合、Red Hat Advanced Cluster Management はインポートしているクラスターからクラウドおよびベンダータイプを自動的に検出します。オプションで、auto-detect の値をクラスターのクラウドおよびベンダーの値に置き換えることができます。以下の例を参照してください。

    cloud: Amazon
    vendor: OpenShift
  4. 以下のコマンドを実行して、YAML ファイルを ManagedCluster リソースに適用します。

    oc apply -f managed-cluster.yaml

これで、自動インポートシークレットを使用してクラスターをインポートする か、手動でクラスターをインポートする のいずれかに進むことができます。

1.5.5.2.4. 自動インポートシークレットを使用したクラスターのインポート

自動インポートシークレットを使用してマネージドクラスターをインポートするには、クラスターの kubeconfig ファイルへの参照、またはクラスターの kube API サーバーとトークンのペアのいずれかの参照を含むシークレットを作成する必要があります。自動インポートシークレットを使用してクラスターをインポートするには、以下の手順を実行します。

  1. インポートするマネージドクラスターの kubeconfig ファイル、または kube API サーバーおよびトークンを取得します。kubeconfig ファイルまたは kube API サーバーおよびトークンの場所を特定する方法については、Kubernetes クラスターのドキュメントを参照してください。
  2. ${CLUSTER_NAME} namespace に auto-import-secret.yaml ファイルを作成します。

    1. 以下のテンプレートのようなコンテンツを使用して、auto-import-secret.yaml という名前の YAML ファイルを作成します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: auto-import-secret
        namespace: <cluster_name>
      stringData:
        autoImportRetry: "5"
        # If you are using the kubeconfig file, add the following value for the kubeconfig file
        # that has the current context set to the cluster to import:
        kubeconfig: |- <kubeconfig_file>
        # If you are using the token/server pair, add the following two values instead of
        # the kubeconfig file:
        token: <Token to access the cluster>
        server: <cluster_api_url>
      type: Opaque
    2. 以下のコマンドを実行して、<cluster_name> namespace に YAML ファイルを適用します。

      oc apply -f auto-import-secret.yaml

      注記: デフォルトでは、自動インポートシークレットは 1 回使用され、インポートプロセスが完了すると削除されます。自動インポートシークレットを保持する場合は、managedcluster-import-controller.open-cluster-management.io/keeping-auto-import-secret をシークレットに追加します。これを追加するには、以下のコマンドを実行します。

      oc -n <cluster_name> annotate secrets auto-import-secret managedcluster-import-controller.open-cluster-management.io/keeping-auto-import-secret=""
  3. インポートしたクラスターのステータス (JOINED および AVAILABLE) を確認します。ハブクラスターから以下のコマンドを実行します。

    oc get managedcluster <cluster_name>
  4. クラスターで以下のコマンドを実行して、マネージドクラスターにログインします。

    oc login
  5. 以下のコマンドを実行して、インポートするクラスターの Pod ステータスを検証できます。

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

klusterlet アドオンのインポート に進むことができます。

1.5.5.2.5. クラスターの手動インポート

重要: import コマンドには、インポートされた各マネージドクラスターにコピーされるプルシークレット情報が含まれます。インポートしたクラスターにアクセスできるユーザーであれば誰でも、プルシークレット情報を表示することもできます。

マネージドクラスターを手動でインポートするには、以下の手順を実行します。

  1. 以下のコマンドを実行して、ハブクラスターでインポートコントローラーによって生成された klusterlet-crd.yaml ファイルを取得します。

    oc get secret <cluster_name>-import -n <cluster_name> -o jsonpath={.data.crds\\.yaml} | base64 --decode > klusterlet-crd.yaml
  2. 以下のコマンドを実行して、ハブクラスターにインポートコントローラーによって生成された import.yaml ファイルを取得します。

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

    インポートするクラスターで次の手順を実行します。

  3. 次のコマンドを入力して、インポートするマネージドクラスターにログインします。

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

    oc apply -f klusterlet-crd.yaml
  5. 以下のコマンドを実行して、以前に生成した import.yaml ファイルを適用します。

    oc apply -f import.yaml
  6. ハブクラスターから次のコマンドを実行して、インポートするマネージドクラスターの JOINED および AVAILABLE ステータスを検証できます。

    oc get managedcluster <cluster_name>

klusterlet アドオンのインポート に進むことができます。

1.5.5.2.6. klusterlet アドオンのインポート

KlusterletAddonConfig klusterlet アドオン設定を実装して、マネージドクラスターで他のアドオンを有効にします。次の手順を実行して、設定ファイルを作成して適用します。

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

    apiVersion: agent.open-cluster-management.io/v1
    kind: KlusterletAddonConfig
    metadata:
      name: <cluster_name>
      namespace: <cluster_name>
    spec:
      applicationManager:
        enabled: true
      certPolicyController:
        enabled: true
      iamPolicyController:
        enabled: true
      policyController:
        enabled: true
      searchCollector:
        enabled: true
  2. ファイルは klusterlet-addon-config.yaml として保存します。
  3. 以下のコマンドを実行して YAML を適用します。

    oc apply -f klusterlet-addon-config.yaml

    アドオンは、インポートするマネージドクラスターのステータスが AVAILABLE になると、インストールされます。

  4. 以下のコマンドを実行して、インポートするクラスターのアドオンの Pod ステータスを検証できます。

    oc get pod -n open-cluster-management-agent-addon
1.5.5.2.7. コマンドラインインターフェイスを使用したインポート済みクラスターの削除

コマンドラインインターフェイスを使用してマネージドクラスターを削除するには、以下のコマンドを実行します。

oc delete managedcluster <cluster_name>

<cluster_name> をクラスターの名前に置き換えます。

1.5.5.3. オンプレミスの Red Hat OpenShift Container Platform クラスターの手動インポート

Kubernetes Operator 用のマルチクラスターエンジンをインストールすると、クラスターをインポートして管理できるようになります。既存の OpenShift Container Platform クラスターをインポートして、ノードを追加できます。詳細は、次のトピックを引き続きお読みください。

1.5.5.3.1. 前提条件
  • Central Infrastructure Management サービスの有効化
1.5.5.3.2. クラスターのインポート

静的ネットワークまたはベアメタルホストなしで OpenShift Container Platform クラスターを手動でインポートし、ノードを追加する準備をするには、以下の手順を実行します。

  1. 次の YAML コンテンツを適用して、インポートする OpenShift Container Platform クラスターの namespace を作成します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: managed-cluster
  2. 以下の YAML コンテンツを適用して、インポートしている OpenShift Container Platform クラスターに一致する ClusterImageSet が存在することを確認します。

    apiVersion: hive.openshift.io/v1
    kind: ClusterImageSet
    metadata:
      name: openshift-v4.11.18
    spec:
      releaseImage: quay.io/openshift-release-dev/ocp-release@sha256:22e149142517dfccb47be828f012659b1ccf71d26620e6f62468c264a7ce7863
  3. 次の YAML コンテンツを適用して、イメージにアクセスするためのプルシークレットを追加します。

    apiVersion: v1
    kind: Secret
    type: kubernetes.io/dockerconfigjson
    metadata:
      name: pull-secret
      namespace: managed-cluster
    stringData:
      .dockerconfigjson: <pull-secret-json> 1
    1
    <pull-secret-json> をプルシークレット JSON に置き換えます。
  4. kubeconfig を OpenShift Container Platform クラスターからハブクラスターにコピーします。

    1. 次のコマンドを実行して、OpenShift Container Platform クラスターから kubeconfig を取得します。kubeconfig がインポートされるクラスターとして設定されていることを確認します。

      oc get secret -n openshift-kube-apiserver node-kubeconfigs -ojson | jq '.data["lb-ext.kubeconfig"]' --raw-output | base64 -d > /tmp/kubeconfig.some-other-cluster
    2. 次のコマンドを実行して、kubeconfig をハブクラスターにコピーします。kubeconfig がハブクラスターとして設定されていることを確認します。

      oc -n managed-cluster create secret generic some-other-cluster-admin-kubeconfig --from-file=kubeconfig=/tmp/kubeconfig.some-other-cluster
  5. 次の YAML コンテンツを適用して、AgentClusterInstall カスタムリソースを作成します。必要に応じて値を置き換えます。

    apiVersion: extensions.hive.openshift.io/v1beta1
    kind: AgentClusterInstall
    metadata:
      name: your-cluster-name 1
      namespace: managed-cluster
    spec:
      networking:
        userManagedNetworking: true
      clusterDeploymentRef:
        name: your-cluster
      imageSetRef:
        name: openshift-v4.11.18
      provisionRequirements:
        controlPlaneAgents: 1 2
      sshPublicKey: "" 3
    1
    クラスターの名前を選択します。
    2
    シングルノード OpenShift クラスターを使用している場合は、1 を使用します。マルチノードクラスターを使用している場合は、3 を使用します。
    3
    オプションの sshPublicKey フィールドを使用して、トラブルシューティングの目的でノードにログインできます。
  6. 次の YAML コンテンツを適用して、ClusterDeployment を作成します。必要に応じて値を置き換えます。

    apiVersion: hive.openshift.io/v1
    kind: ClusterDeployment
    metadata:
      name: your-cluster-name 1
      namespace: managed-cluster
    spec:
      baseDomain: redhat.com 2
      installed: true 3
      clusterMetadata:
          adminKubeconfigSecretRef:
            name: your-cluster-name-admin-kubeconfig 4
          clusterID: "" 5
          infraID: "" 6
      clusterInstallRef:
        group: extensions.hive.openshift.io
        kind: AgentClusterInstall
        name: your-cluster-name-install
        version: v1beta1
      clusterName: your-cluster-name
      platform:
        agentBareMetal:
      pullSecretRef:
        name: pull-secret
    1
    クラスターの名前を選択します。
    2
    BaseDomain が OpenShift Container Platform クラスターに使用しているドメインと一致していることを確認してください。
    3
    OpenShift Container Platform クラスターは、installedtrue に設定されている場合にのみ、実稼働環境クラスターとして自動的にインポートされます。
    4
    手順 4 で作成した kubeconfig がadminKubeconfigSecretRef で参照されていることを確認してください。
    5 6
    運用環境では、clusterIDinfraID を空のままにすることができます。
  7. 次の YAML コンテンツを適用することで、InfraEnv カスタムリソースを追加して、クラスターに追加する新しいホストを検出します。必要に応じて値を置き換えます。

    注記: 静的 IP アドレスを使用していない場合、次の例では追加の設定が必要になる場合があります。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: InfraEnv
    metadata:
      name: your-infraenv
      namespace: managed-cluster
    spec:
      clusterRef: 1
        name: your-cluster-name
        namespace: managed-cluster
      pullSecretRef:
        name: pull-secret
      sshAuthorizedKey: "" 2
    1
    遅延バインディングを使用している場合、clusterRef フィールドはオプションです。遅延バインディングを使用していない場合は、例に示すように、clusterRef を追加する必要があります。
    2
    オプションの sshPublicKey フィールドを使用して、トラブルシューティングのためにノードにログインできます。
  8. インポートに成功すると、ISO ファイルをダウンロードする URL が表示されます。次のコマンドを実行して ISO ファイルをダウンロードします。<url> は表示される URL に置き換えます。

    注記: ベアメタルホストを使用すると、ホストの検出を自動化できます。

    oc get infraenv -n managed-cluster some-other-infraenv -ojson | jq ".status.<url>" --raw-output | xargs curl -k -o /storage0/isos/some-other.iso
1.5.5.3.3. OpenShift Container Platform クラスターへのワーカーノードの追加

実稼働環境のワーカーノードを OpenShift Container Platform クラスターに追加するには、以下の手順を実行します。

  1. ワーカーノードとして使用するマシンを、以前にダウンロードした ISO から起動します。

    注記: ワーカーノードが OpenShift Container Platform ワーカーノードの要件を満たしていることを確認してください。

  2. 次のコマンドを実行した後、エージェントが登録されるまで待ちます。

    watch -n 5 "oc get agent -n managed-cluster"
  3. エージェントの登録が成功すると、エージェントがリストされます。インストールのためにエージェントを承認します。これには数分かかる場合があります。

    注記: エージェントがリストにない場合は、Ctrl キーと C キーを押して watch コマンドを終了し、ワーカーノードにログインしてトラブルシューティングを行ってください。

  4. 遅延バインディングを使用している場合は、次のコマンドを実行して、保留中のバインドされていないエージェントを OpenShift Container Platform クラスターに関連付けます。遅延バインディングを使用していない場合は、ステップ 5 に進みます。

    oc get agent -n managed-cluster -ojson | jq -r '.items[] | select(.spec.approved==false) |select(.spec.clusterDeploymentName==null) | .metadata.name'| xargs oc -n managed-cluster patch -p '{"spec":{"clusterDeploymentName":{"name":"some-other-cluster","namespace":"managed-cluster"}}}' --type merge agent
  5. 次のコマンドを実行して、保留中のエージェントのインストールを承認します。

    oc get agent -n managed-cluster -ojson | jq -r '.items[] | select(.spec.approved==false) | .metadata.name'| xargs oc -n managed-cluster patch -p '{"spec":{"approved":true}}' --type merge agent

ワーカーノードのインストールを待ちます。ワーカーノードのインストールが完了すると、ワーカーノードは証明書署名要求 (CSR) を使用してマネージドクラスターに接続し、参加プロセスを開始します。CSR は自動的に署名されます。

1.5.5.4. インポート用のマネージドクラスターでのイメージレジストリーの指定

インポートしているマネージドクラスターのイメージレジストリーを上書きする必要がある場合があります。これには、ManagedClusterImageRegistry カスタムリソース定義を作成します。

ManagedClusterImageRegistry カスタムリソース定義は、namespace スコープのリソースです。

ManagedClusterImageRegistry カスタムリソース定義は、Placement が選択するマネージドクラスターのセットを指定しますが、カスタムイメージレジストリーとは異なるイメージが必要になります。マネージドクラスターが新規イメージで更新されると、識別用に各マネージドクラスターに、open-cluster-management.io/image-registry=<namespace>.<managedClusterImageRegistryName> のラベルが追加されます。

以下の例は、ManagedClusterImageRegistry カスタムリソース定義を示しています。

apiVersion: imageregistry.open-cluster-management.io/v1alpha1
kind: ManagedClusterImageRegistry
metadata:
  name: <imageRegistryName>
  namespace: <namespace>
spec:
  placementRef:
    group: cluster.open-cluster-management.io
    resource: placements
    name: <placementName>
  pullSecret:
    name: <pullSecretName>
  registries:
  - mirror: <mirrored-image-registry-address>
    source: <image-registry-address>
  - mirror: <mirrored-image-registry-address>
    source: <image-registry-address>

spec セクション:

  • placementName は、マネージドクラスターセットを選択する同じ namespace の Placement 名に置き換えます。
  • pullSecretName は、カスタムイメージレジストリーからイメージをプルするために使用されるプルシークレットの名前に置き換えます。
  • ソース および ミラー レジストリーのそれぞれの値をリスト表示します。mirrored-image-registry-address および image-registry-address は、レジストリーの各 ミラー および ソース 値に置き換えます。

    • 例 1: registry.redhat.io/rhacm2 という名前のソースイメージレジストリーを localhost:5000/rhacm2 に、registry.redhat.io/multicluster-enginelocalhost:5000/multicluster-engine に置き換えるには、以下の例を使用します。

      registries:
      - mirror: localhost:5000/rhacm2/
          source: registry.redhat.io/rhacm2
      - mirror: localhost:5000/multicluster-engine
          source: registry.redhat.io/multicluster-engine
    • 例 2: ソースイメージ registry.redhat.io/rhacm2/registration-rhel8-operatorlocalhost:5000/rhacm2-registration-rhel8-operator に置き換えるには、以下の例を使用します。

      registries:
      - mirror: localhost:5000/rhacm2-registration-rhel8-operator
          source: registry.redhat.io/rhacm2/registration-rhel8-operator
1.5.5.4.1. ManagedClusterImageRegistry を持つクラスターのインポート

ManagedClusterImageRegistry カスタムリソース定義でカスタマイズされるクラスターをインポートするには、以下の手順を実行します。

  1. クラスターをインポートする必要のある namespace にプルシークレットを作成します。これらの手順では、namespace は myNamespace です。

    $ kubectl create secret docker-registry myPullSecret \
      --docker-server=<your-registry-server> \
      --docker-username=<my-name> \
      --docker-password=<my-password>
  2. 作成した namespace に Placement を作成します。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: myPlacement
      namespace: myNamespace
    spec:
      clusterSets:
      - myClusterSet
      tolerations:
      - key: "cluster.open-cluster-management.io/unreachable"
        operator: Exists

    注記: Placement がクラスターを選択できるようにするには、Toleration を unreachable に指定する必要があります。

  3. ManagedClusterSet リソースを作成し、これを namespace にバインドします。

    apiVersion: cluster.open-cluster-management.io/v1beta2
    kind: ManagedClusterSet
    metadata:
      name: myClusterSet
    
    ---
    apiVersion: cluster.open-cluster-management.io/v1beta2
    kind: ManagedClusterSetBinding
    metadata:
      name: myClusterSet
      namespace: myNamespace
    spec:
      clusterSet: myClusterSet
  4. namespace に ManagedClusterImageRegistry カスタムリソース定義を作成します。

    apiVersion: imageregistry.open-cluster-management.io/v1alpha1
    kind: ManagedClusterImageRegistry
    metadata:
      name: myImageRegistry
      namespace: myNamespace
    spec:
      placementRef:
        group: cluster.open-cluster-management.io
        resource: placements
        name: myPlacement
      pullSecret:
        name: myPullSecret
      registry: myRegistryAddress
  5. コンソールからマネージドクラスターをインポートし、マネージドクラスターセットに追加します。
  6. open-cluster-management.io/image-registry=myNamespace.myImageRegistry ラベルをマネージドクラスターに追加した後に、マネージドクラスターで import コマンドをコピーして実行します。

1.5.6. クラスターへのアクセス

作成され、管理されている Red Hat OpenShift Container Platform クラスターにアクセスするには、以下の手順を実行します。

  1. コンソールから、Infrastructure > Clusters に移動し、作成したクラスターまたはアクセスするクラスターの名前を選択します。
  2. Reveal credentials を選択し、クラスターのユーザー名およびパスワードを表示します。クラスターにログインする際に使用するため、この値を書き留めてください。

    注記: インポートしたクラスターでは、Reveal credentials オプションは利用できません。

  3. クラスターにリンクする Console URL を選択します。
  4. 手順 3 で確認したユーザー ID およびパスワードを使用して、クラスターにログインします。

1.5.7. マネージドクラスターのスケーリング

作成したクラスターについては、仮想マシンのサイズやノード数など、マネージドクラスターの仕様をカスタマイズおよびサイズ変更できます。以下のオプションを参照してください。

1.5.7.1. MachinePool によるスケーリング

multicluster engine operator を使用してプロビジョニングするクラスターの場合、MachinePool リソースが自動的に作成されます。MachinePool を使用して、仮想マシンのサイズやノード数など、マネージドクラスターの仕様をさらにカスタマイズおよびサイズ変更できます。

  • MachinePool リソースの使用は、ベアメタルクラスターではサポートされていません。
  • MachinePool リソースは、ハブクラスター上の Kubernetes リソースで、MachineSet リソースをマネージドクラスターでグループ化します。
  • MachinePool リソースは、ゾーンの設定、インスタンスタイプ、ルートストレージなど、マシンリソースのセットを均一に設定します。
  • MachinePool では、マネージドクラスターで、必要なノード数を手動で設定したり、ノードの自動スケーリングを設定したりするのに役立ちます。
1.5.7.1.1. 自動スケーリングの設定

自動スケーリングを設定すると、トラフィックが少ない場合にリソースをスケールダウンし、多くのリソースが必要な場合に十分にリソースを確保できるようにスケールアップするなど、必要に応じてクラスターに柔軟性を持たせることができます。

  • コンソールを使用して MachinePool リソースで自動スケーリングを有効にするには、以下の手順を実行します。

    1. ナビゲーションで、Infrastructure > Clusters を選択します。
    2. ターゲットクラスターの名前をクリックし、Machine pools タブを選択します。
    3. マシンプールページのターゲットマシンプールの Options メニューから Enable autoscale を選択します。
    4. マシンセットレプリカの最小数および最大数を選択します。マシンセットレプリカは、クラスターのノードに直接マップします。

      Scale をクリックした後、変更がコンソールに反映されるまでに数分かかる場合があります。Machine pools タブの通知がある場合は、View machines をクリックしてスケーリング操作のステータスを表示できます。

  • コマンドラインを使用して MachinePool リソースで自動スケーリングを有効にするには、以下の手順を実行します。

    1. 次のコマンドを入力して、マシンプールのリストを表示します。このとき、managed-cluster-namespace は、ターゲットのマネージドクラスターの namespace に置き換えます。

      oc get machinepools -n <managed-cluster-namespace>
    2. 以下のコマンドを入力してマシンプールの YAML ファイルを編集します。

      oc edit machinepool <MachinePool-resource-name> -n <managed-cluster-namespace>
      • MachinePool-resource-nameMachinePool リソースの名前に置き換えます。
      • managed-cluster-namespace はマネージドクラスターの namespace の名前に置き換えます。
    3. YAML ファイルから spec.replicas フィールドを削除します。
    4. spec.autoscaling.minReplicas 設定および spec.autoscaling.maxReplicas フィールドをリソース YAML に追加します。
    5. レプリカの最小数を minReplicas 設定に追加します。
    6. レプリカの最大数を maxReplicas 設定に追加します。
    7. ファイルを保存して変更を送信します。
1.5.7.1.2. 自動スケーリングの無効化

コンソールまたはコマンドラインを使用して自動スケーリングを無効にできます。

  • コンソールを使用して自動スケーリングを無効にするには、次の手順を実行します。

    1. ナビゲーションで、Infrastructure > Clusters を選択します。
    2. ターゲットクラスターの名前をクリックし、Machine pools タブを選択します。
    3. マシンプールページから、ターゲットマシンプールの Options メニューから autoscale を無効にします。
    4. 必要なマシンセットのレプリカ数を選択します。マシンセットのレプリカは、クラスター上のノードを直接マップします。

      Scale をクリックした後、表示されるまでに数分かかる場合があります。Machine pools タブの通知で View machines をクリックすると、スケーリングの状態を表示できます。

  • コマンドラインを使用して自動スケーリングを無効にするには、以下の手順を実行します。

    1. 以下のコマンドを実行して、マシンプールのリストを表示します。

      oc get machinepools -n <managed-cluster-namespace>

      managed-cluster-namespace は、ターゲットのマネージドクラスターの namespace に置き換えます。

    2. 以下のコマンドを入力してマシンプールの YAML ファイルを編集します。

      oc edit machinepool <name-of-MachinePool-resource> -n <namespace-of-managed-cluster>

      name-of-MachinePool-resource は、MachinePool リソースの名前に置き換えます。

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

    3. YAML ファイルから spec.autoscaling フィールドを削除します。
    4. spec.replicas フィールドをリソース YAML に追加します。
    5. replicas の設定にレプリカ数を追加します。
    6. ファイルを保存して変更を送信します。
1.5.7.1.3. 手動スケーリングの有効化

コンソールおよびコマンドラインから手動でスケーリングできます。

1.5.7.1.3.1. コンソールでの手動スケーリングの有効化

コンソールを使用して MachinePool リソースをスケーリングするには、次の手順を実行します。

  1. 有効になっている場合は、MachinePool の自動スケーリングを無効にします。前の手順を参照してください。
  2. コンソールから、Infrastructure > Clusters をクリックします。
  3. ターゲットクラスターの名前をクリックし、Machine pools タブを選択します。
  4. マシンプールページで、対象のマシンプールの Options メニューから Scale machine pool を選択します。
  5. 必要なマシンセットのレプリカ数を選択します。マシンセットのレプリカは、クラスター上のノードを直接マップします。Scale をクリックした後、変更がコンソールに反映されるまでに数分かかる場合があります。マシンプールタブの通知から View machines をクリックすると、スケーリング操作の状態を表示できます。
1.5.7.1.3.2. コマンドラインでの手動スケーリングの有効化

コマンドラインを使用して MachinePool リソースをスケーリングするには、次の手順を実行します。

  1. 次のコマンドを入力して、マシンプールのリストを表示します。このとき、<managed-cluster-namespace> は、ターゲットのマネージドクラスターの namespace に置き換えます。

    oc get machinepools -n <managed-cluster-namespace>
  2. 以下のコマンドを入力してマシンプールの YAML ファイルを編集します。

    oc edit machinepool <MachinePool-resource-name> -n <managed-cluster-namespace>
    • MachinePool-resource-nameMachinePool リソースの名前に置き換えます。
    • managed-cluster-namespace はマネージドクラスターの namespace の名前に置き換えます。
  3. YAML ファイルから spec.autoscaling フィールドを削除します。
  4. YAML ファイルの spec.replicas フィールドを必要な数のレプリカに変更します。
  5. ファイルを保存して変更を送信します。

1.5.8. クラスタープロキシーアドオンの使用

一部の環境では、マネージドクラスターはファイアウォールの背後にあり、ハブクラスターから直接アクセスすることはできません。アクセスを取得するには、プロキシーアドオンを設定してマネージドクラスターの kube-apiserver にアクセスし、よりセキュアな接続を提供できます。

重要: ハブクラスターまたはマネージドクラスターに [cluster-wide proxy] (https://docs.openshift.com/container-platform/4.12/networking/enable-cluster-wide-proxy.html)設定がある場合は、cluster-proxy-addon は機能しません。

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

ハブクラスターとマネージドクラスターのクラスタープロキシーアドオンを設定するには、次の手順を実行します。

  1. 次の手順を実行してマネージドクラスター kube-apiserver にアクセスするように kubeconfig ファイルを設定します。

    1. マネージドクラスターに有効なアクセストークンを指定します。

      注記: サービスアカウントの対応するトークンを使用できます。デフォルトの namespace にあるデフォルトのサービスアカウントを使用することもできます。

      1. 次のコマンドを実行して、マネージドクラスターの kubeconfig ファイルをエクスポートします。

        export KUBECONFIG=<managed-cluster-kubeconfig>
      2. 次のコマンドを実行して、Pod へのアクセス権があるロールをサービスアカウントに追加します。

        oc create role -n default test-role --verb=list,get --resource=pods
        oc create rolebinding -n default test-rolebinding --serviceaccount=default:default --role=test-role
      3. 次のコマンドを実行して、サービスアカウントトークンのシークレットを見つけます。

        oc get secret -n default | grep <default-token>

        default-token は、シークレット名に置き換えます。

      4. 次のコマンドを実行して、トークンをコピーします。

        export MANAGED_CLUSTER_TOKEN=$(kubectl -n default get secret <default-token> -o jsonpath={.data.token} | base64 -d)

        default-token は、シークレット名に置き換えます。

    2. Red Hat Advanced Cluster Management ハブクラスターで kubeconfig ファイルを設定します。

      1. 次のコマンドを実行して、ハブクラスター上の現在の kubeconfig ファイルをエクスポートします。

        oc config view --minify --raw=true > cluster-proxy.kubeconfig
      2. エディターで server ファイルを変更します。この例では、sed の使用時にコマンドを使用します。OSX を使用している場合は、alias sed=gsed を実行します。

        export TARGET_MANAGED_CLUSTER=<managed-cluster-name>
        
        export NEW_SERVER=https://$(oc get route -n multicluster-engine cluster-proxy-addon-user -o=jsonpath='{.spec.host}')/$TARGET_MANAGED_CLUSTER
        
        sed -i'' -e '/server:/c\    server: '"$NEW_SERVER"'' cluster-proxy.kubeconfig
        
        export CADATA=$(oc get configmap -n openshift-service-ca kube-root-ca.crt -o=go-template='{{index .data "ca.crt"}}' | base64)
        
        sed -i'' -e '/certificate-authority-data:/c\    certificate-authority-data: '"$CADATA"'' cluster-proxy.kubeconfig
      3. 次のコマンドを入力して、元のユーザー認証情報を削除します。

        sed -i'' -e '/client-certificate-data/d' cluster-proxy.kubeconfig
        sed -i'' -e '/client-key-data/d' cluster-proxy.kubeconfig
        sed -i'' -e '/token/d' cluster-proxy.kubeconfig
      4. サービスアカウントのトークンを追加します。

        sed -i'' -e '$a\    token: '"$MANAGED_CLUSTER_TOKEN"'' cluster-proxy.kubeconfig
  2. 次のコマンドを実行して、ターゲットマネージドクラスターのターゲット namespace にあるすべての Pod をリスト表示します。

    oc get pods --kubeconfig=cluster-proxy.kubeconfig -n <default>

    default namespace は、使用する namespace に置き換えます。

  3. マネージドクラスター上の他のサービスにアクセスします。この機能は、マネージドクラスターが Red Hat OpenShift Container Platform クラスターの場合に利用できます。サービスは service-serving-certificate を使用してサーバー証明書を生成する必要があります。

    • マネージドクラスターから、以下のサービスアカウントトークンを使用します。

      export PROMETHEUS_TOKEN=$(kubectl get secret -n openshift-monitoring $(kubectl get serviceaccount -n openshift-monitoring prometheus-k8s -o=jsonpath='{.secrets[0].name}') -o=jsonpath='{.data.token}' | base64 -d)
    • ハブクラスターから、以下のコマンドを実行して認証局をファイルに変換します。

      oc get configmap kube-root-ca.crt -o=jsonpath='{.data.ca\.crt}' > hub-ca.crt
  4. 以下のコマンドを使用して、マネージドクラスターの Prometheus メトリックを取得します。

    export SERVICE_NAMESPACE=openshift-monitoring
    export SERVICE_NAME=prometheus-k8s
    export SERVICE_PORT=9091
    export SERVICE_PATH="api/v1/query?query=machine_cpu_sockets"
    curl --cacert hub-ca.crt $NEW_SERVER/api/v1/namespaces/$SERVICE_NAMESPACE/services/$SERVICE_NAME:$SERVICE_PORT/proxy-service/$SERVICE_PATH -H "Authorization: Bearer $PROMETHEUS_TOKEN"

1.5.9. マネージドクラスターで実行する Ansible Automation Platform タスクの設定

マルチクラスターエンジン Operator は Red Hat Ansible Automation Platform と統合されるため、クラスターの作成またはアップグレードの前後に発生するプリフックとポストフックの Ansible ジョブインスタンスを作成できます。クラスター破棄の prehook および posthook ジョブの設定やクラスターのスケールアクションはサポートされません。

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

1.5.9.1. 前提条件

クラスターで自動化テンプレートを実行するには、次の前提条件を満たす必要があります。

  • OpenShift Container Platform 4.6 以降
  • Ansible Automation Platform Resource Operator をインストールして、Ansible ジョブを Git サブスクリプションのライフサイクルに接続している。自動化テンプレートを使用して Ansible Automation Platform ジョブを起動する場合に最良の結果を得るには、Ansible Automation Platform ジョブテンプレートを実行時にべき等にする必要があります。Ansible Automation Platform Resource Operator は、Red Hat OpenShift Container Platform OperatorHub ページから検索できます。

1.5.9.2. コンソールを使用して、クラスターで実行するように、自動化テンプレートを設定する

クラスターの作成時、クラスターのインポート時、またはクラスターの作成後、クラスターに使用する自動化テンプレートを指定できます。

クラスターの作成時またはインポート時にテンプレートを指定するには、Automation の手順でクラスターに適用する Ansible テンプレートを選択します。自動化テンプレートがない場合は、Add automation template をクリックして作成します。

クラスターの作成後にテンプレートを指定するには、既存のクラスターのアクションメニューで Update automation template をクリックします。Update automation template オプションを使用して、既存の自動化テンプレートを更新することもできます。

1.5.9.3. 自動化テンプレートの作成

クラスターのインストールまたはアップグレードで Ansible ジョブを開始するには、自動化テンプレートを作成して、いつジョブを実行するかを指定する必要があります。これらは、クラスターのインストールまたはアップグレード前後に実行するように設定できます。

テンプレートの作成時に Ansible テンプレートの実行に関する詳細を指定するには、コンソールで以下の手順を実行します。

  1. ナビゲーションから Infrastructure > Automation を選択します。
  2. 状況に適したパスを選択します。

    • 新規テンプレートを作成する場合には、Create Ansible template をクリックして手順 3 に進みます。
    • 既存のテンプレートを変更する場合は、変更するテンプレートの Options メニューの Edit template をクリックして、手順 5 に進みます。
  3. 一意のテンプレート名を入力します。名前には小文字の英数字またはハイフン (-) を指定してください。
  4. 新規テンプレートの認証情報を選択します。Ansible 認証情報を Ansible テンプレートにリンクするには、以下の手順を実行します。

    1. ナビゲーションから Automation を選択します。認証情報にリンクされていないテンプレートの一覧内のテンプレートには、テンプレートを既存の認証情報にリンクするために使用できるリンク 認証情報へのリンク アイコンが含まれています。テンプレートと同じ namespace の認証情報のみが表示されます。
    2. 選択できる認証情報がない場合や、既存の認証情報を使用しない場合は、リンクするテンプレートの Options メニューから Edit template を選択します。
    3. 認証情報を作成する場合は、Add credential をクリックして、Ansible Automation Platform の認証情報の作成 の手順を行います。
    4. テンプレートと同じ namespace に認証情報を作成したら、テンプレートの編集時に Ansible Automation Platform credential フィールドで認証情報を選択します。
  5. クラスターをインストールする前に、Ansible ジョブを開始する場合は、Pre-install Automation templates セクションの Add an Automation template を選択します。
  6. prehook および posthook Ansible ジョブを選択するか、名前を入力して、クラスターのインストールまたはアップグレードに追加します。

    注記: 自動化テンプレート名 は、Ansible Automation Platform の Ansible ジョブの名前と一致している必要があります。

  7. 必要に応じて、Ansible ジョブをドラッグして、順番を変更します。
  8. インストール後の自動化テンプレート セクション、アップグレード前の自動化テンプレート セクション、および アップグレード後の自動化テンプレート セクションでクラスターのインストール後に開始するすべての自動化テンプレートに手順 5 〜 7 を繰り返します。

Ansible テンプレートは、指定のアクションが起こるタイミングで、このテンプレートを指定するクラスターで実行するように設定されます。

1.5.9.4. Ansible ジョブのステータスの表示

実行中の Ansible ジョブのステータスを表示して、起動し、正常に実行されていることを確認できます。実行中の Ansible ジョブの現在のステータスを表示するには、以下の手順を実行します。

  1. メニューで、Infrastructure > Clusters を選択して、Clusters ページにアクセスします。
  2. クラスターの名前を選択して、その詳細を表示します。
  3. クラスター情報で Ansible ジョブの最後の実行ステータスを表示します。エントリーには、以下のステータスの 1 つが表示されます。

    • インストール prehook または posthook ジョブが失敗すると、クラスターのステータスは Failed と表示されます。
    • アップグレード prehook または posthook ジョブが失敗すると、アップグレードに失敗した Distribution フィールドに警告が表示されます。

      ヒント: クラスターの prehook または posthook が失敗した場合は、Clusters ページからアップグレードを再試行できます。

1.5.10. ClusterClaims

ClusterClaim は、マネージドクラスター上のカスタムリソース定義 (CRD) です。ClusterClaim は、マネージドクラスターが要求する情報の一部を表します。ClusterClaim を使用して、ターゲットクラスターでのリソースの placement を解除できます。

以下の例は、YAML ファイルで特定された ClusterClaim を示しています。

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: ClusterClaim
metadata:
  name: id.openshift.io
spec:
  value: 95f91f25-d7a2-4fc3-9237-2ef633d8451c

次の表は、マルチクラスターエンジン Operator が管理するクラスターにある可能性がある定義済みの ClusterClaim を示しています。

要求名予約変更可能説明

id.k8s.io

true

false

アップストリームの提案で定義された ClusterID

kubeversion.open-cluster-management.io

true

true

Kubernetes バージョン

platform.open-cluster-management.io

true

false

AWS、GCE、Equinix Metal など、マネージドクラスターが稼働しているプラットフォーム

product.open-cluster-management.io

true

false

OpenShift、Anthos、EKS、および GKE などの製品名

id.openshift.io

false

false

OpenShift Container Platform クラスターでのみ利用できる OpenShift Container Platform 外部 ID

consoleurl.openshift.io

false

true

OpenShift Container Platform クラスターでのみ利用できる管理コンソールの URL

version.openshift.io

false

true

OpenShift Container Platform クラスターでのみ利用できる OpenShift Container Platform バージョン

マネージドクラスターで以前の要求が削除されるか、更新されると、自動的に復元またはロールバックされます。

マネージドクラスターがハブに参加すると、マネージドクラスターで作成された ClusterClaim は、ハブの ManagedCluster リソースのステータスと同期されます。ClusterClaims のマネージドクラスターは、以下の例のようになります。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  labels:
    cloud: Amazon
    clusterID: 95f91f25-d7a2-4fc3-9237-2ef633d8451c
    installer.name: multiclusterhub
    installer.namespace: open-cluster-management
    name: cluster1
    vendor: OpenShift
  name: cluster1
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60
status:
  allocatable:
    cpu: '15'
    memory: 65257Mi
  capacity:
    cpu: '18'
    memory: 72001Mi
  clusterClaims:
    - name: id.k8s.io
      value: cluster1
    - name: kubeversion.open-cluster-management.io
      value: v1.18.3+6c42de8
    - name: platform.open-cluster-management.io
      value: AWS
    - name: product.open-cluster-management.io
      value: OpenShift
    - name: id.openshift.io
      value: 95f91f25-d7a2-4fc3-9237-2ef633d8451c
    - name: consoleurl.openshift.io
      value: 'https://console-openshift-console.apps.xxxx.dev04.red-chesterfield.com'
    - name: version.openshift.io
      value: '4.5'
  conditions:
    - lastTransitionTime: '2020-10-26T07:08:49Z'
      message: Accepted by hub cluster admin
      reason: HubClusterAdminAccepted
      status: 'True'
      type: HubAcceptedManagedCluster
    - lastTransitionTime: '2020-10-26T07:09:18Z'
      message: Managed cluster joined
      reason: ManagedClusterJoined
      status: 'True'
      type: ManagedClusterJoined
    - lastTransitionTime: '2020-10-30T07:20:20Z'
      message: Managed cluster is available
      reason: ManagedClusterAvailable
      status: 'True'
      type: ManagedClusterConditionAvailable
  version:
    kubernetes: v1.18.3+6c42de8

1.5.10.1. 既存の ClusterClaim の表示

kubectl コマンドを使用して、マネージドクラスターに適用される ClusterClaim をリスト表示できます。これは、ClusterClaim をエラーメッセージと比較する場合に便利です。

注記: clusterclaims.cluster.open-cluster-management.io のリソースに list の権限があることを確認します。

以下のコマンドを実行して、マネージドクラスターにある既存の ClusterClaim のリストを表示します。

kubectl get clusterclaims.cluster.open-cluster-management.io

1.5.10.2. カスタム ClusterClaims の作成

ClusterClaim は、マネージドクラスターでカスタム名を使用して作成できるため、簡単に識別できます。カスタム ClusterClaim は、ハブクラスターの ManagedCluster リソースのステータスと同期されます。以下のコンテンツでは、カスタマイズされた ClusterClaim の定義例を示しています。

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: ClusterClaim
metadata:
  name: <custom_claim_name>
spec:
  value: <custom_claim_value>

spec.value フィールドの最大長は 1024 です。ClusterClaim を作成するには clusterclaims.cluster.open-cluster-management.io リソースの create 権限が必要です。

1.5.11. ManagedClusterSets

ManagedClusterSet は、マネージドクラスターのグループです。マネージドクラスターセット。すべてのマネージドクラスターへのアクセスを管理するのに役立ちます。ManagedClusterSetBinding リソースを作成して ManagedClusterSet リソースを namespace にバインドすることもできます。

各クラスターは、マネージドクラスターセットのメンバーである必要があります。ハブクラスターをインストールすると、default という名前の ManagedClusterSet リソースが作成されます。マネージドクラスターセットに割り当てられていないすべてのクラスターは、default マネージドクラスターセットに自動的に割り当てられます。default マネージドクラスターセットを削除または更新することはできません。

マネージドクラスターセットの作成および管理方法の詳細は、以下を参照してください。

1.5.11.1. ManagedClusterSet の作成

マネージドクラスターセットにマネージドクラスターをグループ化して、マネージドクラスターでのユーザーのアクセス権限を制限できます。

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

ManagedClusterSet は、クラスタースコープのリソースであるため、ManagedClusterSet の作成先となるクラスターで管理者権限が必要です。マネージドクラスターは、複数の ManagedClusterSet に追加できません。マネージドクラスターセットは、マルチクラスターエンジン Operator コンソールまたは CLI から作成できます。

注記: マネージドクラスターセットに追加されていないクラスタープールは、デフォルトの ManagedClusterSet リソースに追加されません。クラスターがクラスタープールから要求されると、クラスターはデフォルトの ManagedClusterSet に追加されます。

マネージドクラスターを作成すると、管理を容易にするために次のものが自動的に作成されます。

  • global と呼ばれる ManagedClusterSet
  • open-cluster-management-global-set という namespace。
  • global と呼ばれる ManagedClusterSetBinding は、global ManagedClusterSetopen-cluster-management-global-set namespace にバインドします。

    重要: global マネージドクラスターセットを削除、更新、または編集することはできません。global マネージドクラスターセットには、すべてのマネージドクラスターが含まれます。以下の例を参照してください。

    apiVersion: cluster.open-cluster-management.io/v1beta2
    kind: ManagedClusterSetBinding
    metadata:
      name: global
      namespace: open-cluster-management-global-set
    spec:
      clusterSet: global
1.5.11.1.1. CLI を使用した ManagedClusterSet の作成

CLI を使用してマネージドクラスターセットの定義を YAML ファイルに追加し、マネージドクラスターセットを作成します。

apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSet
metadata:
  name: <cluster_set>

<cluster_set> をマネージドクラスターセットの名前に置き換えます。

1.5.11.1.2. クラスターの ManagedClusterSet への追加

ManagedClusterSet の作成後に、コンソールまたは CLI を使用してクラスターをマネージドクラスターセットに追加できます。

1.5.11.1.3. CLI を使用したクラスターの ManagedClusterSet への追加

CLI を使用してクラスターをマネージドクラスターに追加するには、以下の手順を実行します。

  1. managedclustersets/join の仮想サブリソースに作成できるように、RBAC ClusterRole エントリーが追加されていることを確認します。

    注記: この権限がないと、マネージドクラスターを ManagedClusterSet に割り当てることはできません。このエントリーが存在しない場合は、YAML ファイルに追加します。以下の例を参照してください。

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: clusterrole1
    rules:
      - apiGroups: ["cluster.open-cluster-management.io"]
        resources: ["managedclustersets/join"]
        resourceNames: ["<cluster_set>"]
        verbs: ["create"]

    <cluster_set>ManagedClusterSet の名前に置き換えます。

    注記: マネージドクラスターを別の ManagedClusterSet に移動する場合には、両方のマネージドクラスターセットで権限の設定が必要です。

  2. YAML ファイルでマネージドクラスターの定義を検索します。以下の定義例を参照してください。

    apiVersion: cluster.open-cluster-management.io/v1
    kind: ManagedCluster
    metadata:
      name: <cluster_name>
    spec:
      hubAcceptsClient: true
  3. cluster.open-cluster-management.io/clusterset パラメーターを追加し、ManagedClusterSet の名前を指定します。以下の例を参照してください。

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

1.5.11.2. ManagedClusterSetへの RBAC 権限の割り当て

ハブクラスターに設定したアイデンティティープロバイダーが提供するクラスターセットに、ユーザーまたはグループを割り当てることができます。

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

ManagedClusterSet API RBAC 権限レベルは、以下の表を参照してください。

クラスターセットアクセス権限権限の作成

admin

マネージドクラスターセットに割り当てられたすべてのクラスターおよびクラスタープールリソースへのフルアクセス権限。

クラスターの作成、クラスターのインポート、クラスタープールの作成権限。権限は、作成時にマネージドクラスターセットに割り当てる必要があります。

bind

ManagedClusterSetBinding を作成してクラスターセットを namespace にバインドするアクセス許可。ユーザーまたはグループには、ターゲット namespace で ManagedClusterSetBinding を作成する権限も必要です。マネージドクラスターセットに割り当てられた、すべてのクラスターおよびクラスタープールリソースに対する読み取り専用の権限。

クラスターの作成、クラスターのインポート、またはクラスタープールの作成を実行する権限なし。

view

マネージドクラスターセットに割り当てられたすべてのクラスターおよびクラスタープールリソースに対する読み取り専用権限。

クラスターの作成、クラスターのインポート、またはクラスタープールの作成を実行する権限なし。

注意: グローバルクラスターセットにクラスターセット admin 権限を適用することはできません。

コンソールからマネージドクラスターセットにユーザーまたはグループを割り当てるには、次の手順を実行します。

  1. OpenShift Container Platform コンソールから、Infrastructure > Clusters に移動します。
  2. Cluster sets タブを選択します。
  3. ターゲットクラスターセットを選択します。
  4. Access management タブを選択します。
  5. Add user or group を選択します。
  6. アクセス権を割り当てるユーザーまたはグループを検索して選択します。
  7. Cluster set admin または Cluster set view ロールを選択して、選択したユーザーまたはグループに付与します。詳細については、マルチクラスターエンジン Operator のロールベースのアクセス制御ロールの概要 を参照してください。
  8. Add を選択して変更を送信します。

テーブルにユーザーまたはグループが表示されます。全マネージドクラスターセットリソースの権限の割り当てがユーザーまたはグループに伝播されるまでに数秒かかる場合があります。

配置情報については、配置での ManagedClusterSets の使用 を参照してください。

1.5.11.3. ManagedClusterSetBinding リソースの作成

ManagedClusterSetBinding リソースは、ManagedClusterSet リソースを namespace にバインドします。同じ namespace で作成されたアプリケーションおよびポリシーは、バインドされたマネージドクラスターセットリソースに含まれるクラスターにのみアクセスできます。

namespace へのアクセス権限は、その namespace にバインドされるマネージドクラスターセットに自動的に適用されます。その namespace へのアクセス権限を持つ場合、その namespace にバインドされるマネージドクラスターセットへのアクセス権限が自動的に付与されます。マネージドクラスターセットにアクセスする権限のみがある場合、namespace の他のマネージドクラスターセットにアクセスする権限は自動的に割り当てられません。

コンソールまたはコマンドラインを使用してマネージドクラスターセットバインドを作成できます。

1.5.11.3.1. コンソールを使用した ManagedClusterSetBinding の作成

コンソールを使用して ManagedClusterSetBinding を作成するには、以下の手順を実行します。

  1. OpenShift Container Platform コンソールから、Infrastructure > Clusters に移動し、Cluster sets タブを選択します。
  2. バインドを作成するクラスターセットの名前を選択します。
  3. Actions > Edit namespace bindings に移動します。
  4. Edit namespace bindings ページで、ドロップダウンメニューからクラスターセットをバインドする namespace を選択します。
1.5.11.3.2. CLI を使用した ManagedClusterSetBinding の作成

CLI を使用して ManagedClusterSetBinding を作成するには、以下の手順を実行します。

  1. YAML ファイルに ManagedClusterSetBinding リソースを作成します。

    注記: マネージドクラスターセットバインドを作成する場合、マネージドクラスターセットバインドの名前は、バインドするマネージドクラスターセットの名前と一致する必要があります。ManagedClusterSetBinding リソースは、以下の情報のようになります。

    apiVersion: cluster.open-cluster-management.io/v1beta2
    kind: ManagedClusterSetBinding
    metadata:
      namespace: <namespace>
      name: <cluster_name>
    spec:
      clusterSet: <cluster_set>
  2. ターゲットのマネージドクラスターセットでのバインド権限を割り当てておく必要があります。次の ClusterRole リソースの例を表示します。これには、ユーザーが <cluster_set> にバインドすることを許可するルールが含まれています。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: <clusterrole>
    rules:
      - apiGroups: ["cluster.open-cluster-management.io"]
        resources: ["managedclustersets/bind"]
        resourceNames: ["<cluster_set>"]
        verbs: ["create"]

1.5.11.4. Taint と Toleration を使用したマネージドクラスターの配置

Taint と Toleration を使用して、マネージドクラスターまたはマネージドクラスターセットの placement を制御できます。Taint と Toleration は、特定の placement でマネージドクラスターが選択されないようにする方法を提供します。この制御は、特定のマネージドクラスターが一部の placement に含まれないようにする場合に役立ちます。Taint をマネージドクラスターに、Toleration を placement に追加できます。Taint と Toleration が一致しない場合は、マネージドクラスターはその placement には選択されません。

1.5.11.4.1. マネージドクラスターへの Taint の追加

Taint はマネージドクラスターのプロパティーで指定され、 placement がマネージドクラスターまたはマネージドクラスターのセットを除外できます。以下の例のようなコマンドを入力して、Taint をマネージドクラスターに追加できます。

oc taint ManagedCluster <managed_cluster_name> key=value:NoSelect

Taint の仕様には以下のフィールドが含まれます。

  • (必須) key: クラスターに適用される Taint キー。この値は、その placement に追加される基準を満たすように、マネージドクラスターの Toleration の値と一致させる必要があります。この値は確認できます。たとえば、この値は bar または foo.example.com/bar です。
  • (オプション) Value: Taint キーのTaint値。この値は、その placement に追加される基準を満たすように、マネージドクラスターの Toleration の値と一致させる必要があります。たとえば、この値は value とすることができます。
  • (必須) Effect: Taint を許容しない placement における Taint の効果、または placement の Taint と Toleration が一致しないときに何が起こるか。effect の値は、以下のいずれかの値である必要があります。

    • NoSelect: placement は、この Taint を許容しない限り、クラスターを選択できません。Taint の設定前に placement でクラスターが選択された場合は、クラスターは placement の決定から削除されます。
    • NoSelectIfNew: スケジューラーは、クラスターが新しい場合にそのクラスターを選択できません。プレイスメントは、Taint を許容し、すでにクラスター決定にそのクラスターがある場合にのみ、そのクラスターを選択することができます。
  • (必須) TimeAdded: Taint を追加した時間。この値は自動的に設定されます。
1.5.11.4.2. マネージドクラスターのステータスを反映させる組み込み Taint の特定

マネージドクラスターにアクセスできない場合には、クラスターを placement に追加しないでください。以下の Taint は、アクセスできないマネージドクラスターに自動的に追加されます。

  • cluster.open-cluster-management.io/unavailable: この Taint は、ステータスが FalseManagedClusterConditionAvailable の条件がある場合にマネージドクラスターに追加されます。Taint には NoSelect と同じ効果があり、空の値を指定すると、利用不可のクラスターがスケジュールされないようにできます。この Taint の例は、以下の内容のようになります。

    apiVersion: cluster.open-cluster-management.io/v1
    kind: ManagedCluster
    metadata:
     name: cluster1
    spec:
     hubAcceptsClient: true
     taints:
       - effect: NoSelect
         key: cluster.open-cluster-management.io/unavailable
         timeAdded: '2022-02-21T08:11:54Z'
  • cluster.open-cluster-management.io/unreachable - ManagedClusterConditionAvailable の条件のステータスが Unknown であるか、条件がない場合に、この Taint はマネージドクラスターに追加されます。この Taint には NoSelect と同じ効果があり、空の値を指定すると、到達不可のクラスターがスケジュールされないようにできます。この Taint の例は、以下の内容のようになります。

    apiVersion: cluster.open-cluster-management.io/v1
    kind: ManagedCluster
    metadata:
      name: cluster1
    spec:
      hubAcceptsClient: true
      taints:
        - effect: NoSelect
          key: cluster.open-cluster-management.io/unreachable
          timeAdded: '2022-02-21T08:11:06Z'
1.5.11.4.3. Toleration の placement への追加

Toleration は placement に適用され、 placement の Toleration と Taint が同じでないマネージドクラスターを placement から除外できます。Toleration の仕様には以下のフィールドが含まれます。

  • (任意) Key: キーは placement ができるように Taint キーに一致します。
  • (任意) Value: toleration の値は、 placement を許可する Toleration の Taint の値と一致する必要があります。
  • (任意) Operator: 演算子はキーと値の関係を表します。有効な演算子は equalexists です。デフォルト値は equal です。Toleration は、キーが同じ場合、効果が同じ場合、さらび演算子が以下の値のいずれかである場合に、Taint にマッチします。

    • equal: Operator は equal で、値は Taint および Toleration と同じになります。
    • exists: 値のワイルドカード。これにより、 placement は特定のカテゴリーのすべての Taint を許容できます。
  • (任意) Effect: 一致する Taint の効果。空のままにすると、すべての Taint の効果と一致します。指定可能な値は、NoSelect または NoSelectIfNew です。
  • (任意) TolerationSeconds: マネージドクラスターを新しい placement に移動する前に、Taint を許容する時間の長さ (秒単位) です。effect 値が NoSelect または PreferNoSelect でない場合は、このフィールドは無視されます。デフォルト値は nil で、時間制限がないことを示します。TolerationSeconds のカウント開始時刻は、クラスターのスケジュール時刻や TolerationSeconds 加算時刻の値ではなく、自動的に Taint の TimeAdded の値として記載されます。

以下の例は、Taint が含まれるクラスターを許容する Toleration を設定する方法を示しています。

  • この例のマネージドクラスターの Taint:

    apiVersion: cluster.open-cluster-management.io/v1
    kind: ManagedCluster
    metadata:
      name: cluster1
    spec:
      hubAcceptsClient: true
      taints:
        - effect: NoSelect
          key: gpu
          value: "true"
          timeAdded: '2022-02-21T08:11:06Z'
  • Taint を許容できる placement の Toleration

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement1
      namespace: default
    spec:
      tolerations:
        - key: gpu
          value: "true"
          operator: Equal

    Toleration の定義例では、key: gpuvalue: "true" が一致するため、placement で cluster1 を選択できます。

注記: マネージドクラスターは、Taint の Toleration が含まれる placement に置かれる保証はありません。他の placement に同じ Toleration が含まれる場合には、マネージドクラスターはそれらの placement のいずれかに置かれる可能性があります。

1.5.11.4.4. 一時的な Toleration の指定

TolerationSeconds の値は、Toleration が Taint を許容する期間を指定します。この一時的な Toleration は、マネージドクラスターがオフラインで、このクラスターにデプロイされているアプリケーションを、許容時間中に別のマネージドクラスターに転送できる場合に役立ちます。

たとえば、以下の Taint を持つマネージドクラスターに到達できなくなります。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: cluster.open-cluster-management.io/unreachable
      timeAdded: '2022-02-21T08:11:06Z'

以下の例のように、TolerationSeconds の値で placement を定義すると、ワークロードは 5 分後に利用可能な別のマネージドクラスターに転送されます。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: demo4
  namespace: demo1
spec:
  tolerations:
    - key: cluster.open-cluster-management.io/unreachable
      operator: Exists
      tolerationSeconds: 300

マネージドクラスターに到達できなくなると、アプリケーションが 5 分間別のマネージドクラスターに移動されます。

1.5.11.5. ManagedClusterSet からのマネージドクラスターの削除

マネージドクラスターセットからマネージドクラスターを削除して別のマネージドクラスターセットに移動するか、セットの管理設定から削除する必要がある場合があります。コンソールまたは CLI を使用して、マネージドクラスターセットからマネージドクラスターを削除できます。

注記: マネージドクラスターはすべて、マネージドクラスターセットに割り当てる必要があります。ManagedClusterSet からマネージドクラスターを削除し、別の ManagedClusterSet に割り当てない場合は、そのクラスターは default のマネージドクラスターセットに自動的に追加されます。

1.5.11.5.1. コンソールを使用した ManagedClusterSet からのクラスターの削除

コンソールを使用してマネージドクラスターセットからクラスターを削除するには、次の手順を実行します。

  1. Infrastructure > Clusters をクリックし、Cluster sets タブが選択されていることを確認します。
  2. マネージドクラスターセットから削除するクラスターセットの名前を選択し、クラスターセットの詳細を表示します。
  3. Actions > Manage resource assignments を選択します。
  4. Manage resource assignments ページで、クラスターセットから削除するリソースのチェックボックスをオフにします。

    この手順では、すでにクラスターセットのメンバーであるリソースを削除します。マネージドクラスターの詳細を表示して、リソースがすでにクラスターセットのメンバーであるかどうかを確認できます。

注記: マネージドクラスターを別のマネージドクラスターセットに移動する場合には、マネージドクラスターセット両方で RBAC 権限の設定が必要です。

1.5.11.5.2. CLI を使用した ManagedClusterSet からのクラスターの削除

コマンドラインを使用してマネージドクラスターセットからクラスターを削除するには、以下の手順を実行します。

  1. 以下のコマンドを実行して、マネージドクラスターセットでマネージドクラスターのリストを表示します。

    oc get managedclusters -l cluster.open-cluster-management.io/clusterset=<cluster_set>

    <cluster_set> をマネージドクラスターセットの名前に置き換えます。

  2. 削除するクラスターのエントリーを見つけます。
  3. 削除するクラスターの YAML エントリーからラベルを削除します。ラベルの例については、以下のコードを参照してください。

    labels:
       cluster.open-cluster-management.io/clusterset: clusterset1

注記: マネージドクラスターを別のクラスターセットに移動する場合は、マネージドクラスターセット両方で RBAC 権限の設定が必要です。

1.5.12. Placement での ManagedClusterSets の使用

Placement リソースは、namespace レベルのリソースで、placement namespace にバインドされる ManagedClusterSets から ManagedClusters セットを選択するルールを定義します。

必要なアクセス権限: クラスター管理者またはクラスターセット管理者。

1.5.12.1. 配置の概要

マネージドクラスターを使用した配置がどのように機能するかについては、次の情報を参照してください。

  • Kubernetes クラスターは、cluster スコープの ManagedClusters としてハブクラスターに登録されます。
  • managedcluster は、クラスタースコープの ManagedClusterSets に編成されます。
  • ManagedClusterSets はワークロード namespace にバインドされます。
  • namespace スコープの Placements は、ManagedClusterSets の一部を指定して、ManagedClusters 候補の作業セットを選択します。
  • Placements は、ラベルおよびクレームセレクターを使用して、マネージドクラスターセットから ManagedClusters をフィルター処理します。
  • ManagedClusters の配置は、Taint と Toleration を使用して制御できます。詳細は、Taint と Toleration を使用したマネージドクラスターの配置 を参照してください。
  • Placements は、要件によってクラスターをランク付けし、そこからクラスターのサブセットを選択します。

注記:

  • namespace に ManagedClusterSetBinding を作成して、その namespace に ManagedClusterSet を最低でも 1 つバインドする必要があります。
  • managedclustersets/bind の仮想サブリソースの CREATE に対してロールベースのアクセスが必要です。

API の詳細については、Placements API を参照してください。

1.5.12.2. Placement LabelSelector および ClaimSelector

  • labelSelectorManagedClusters を選択します。以下の例では、labelSelector はラベル vendor: OpenShift のクラスターだけに一致します。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement
      namespace: ns1
    spec:
      predicates:
        - requiredClusterSelector:
            labelSelector:
              matchLabels:
                vendor: OpenShift
  • claimSelectorManagedClusters を選択します。以下の例では、claimSelectorregion.open-cluster-management.ious-west-1 のクラスターだけに一致します。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement
      namespace: ns1
    spec:
      predicates:
        - requiredClusterSelector:
            claimSelector:
              matchExpressions:
                - key: region.open-cluster-management.io
                  operator: In
                  values:
                    - us-west-1
  • clusterSets から ManagedClusters を選択します。以下の例では、claimSelectorclusterSets: clusterset1 clusterset2 だけに一致します。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement
      namespace: ns1
    spec:
      clusterSets:
        - clusterset1
        - clusterset2
      predicates:
        - requiredClusterSelector:
            claimSelector:
              matchExpressions:
                - key: region.open-cluster-management.io
                  operator: In
                  values:
                    - us-west-1
  • 任意の数の ManagedClusters を選択します。以下の例は、numberOfClusters3 の場合です。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement
      namespace: ns1
    spec:
      numberOfClusters: 3
      predicates:
        - requiredClusterSelector:
            labelSelector:
              matchLabels:
                vendor: OpenShift
            claimSelector:
              matchExpressions:
                - key: region.open-cluster-management.io
                  operator: In
                  values:
                    - us-west-1

1.5.12.3. 配置の Toleration

  • Taint が一致する ManagedClusters を選択します。

以下の例のように、マネージドクラスターに Taint があるとします。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: gpu
      value: "true"
      timeAdded: '2022-02-21T08:11:06Z'

デフォルトでは、以下の例のように Toleration を定義しないかぎり、配置はこのクラスターを選択できません。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  tolerations:
    - key: gpu
      value: "true"
      operator: Equal
  • 指定された期間、一致する Taint を持つ ManagedClusters を選択します。

TolerationSeconds の値は、Toleration が Taint を許容する時間の長さを表します。また、マネージドクラスターがオフラインの場合に便利です。ユーザーはこのクラスターにデプロイされたアプリケーションを、許容時間後に別のマネージドクラスターに転送できます。TolerationSeconds は、指定された時間が経過するとオフラインになるクラスターにデプロイされたアプリケーションを、別のマネージドクラスターに自動的に転送することができます。

たとえば、以下のサンプルの内容で定義されているマネージドクラスターは到達不能になります。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: cluster1
spec:
  hubAcceptsClient: true
  taints:
    - effect: NoSelect
      key: cluster.open-cluster-management.io/unreachable
      timeAdded: '2022-02-21T08:11:06Z'

以下の例のように、TolerationSeconds で配置を定義すると、ワークロードは 5 分後に利用可能な別のマネージドクラスターに転送されます。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  tolerations:
    - key: cluster.open-cluster-management.io/unreachable
      operator: Exists
      tolerationSeconds: 300

1.5.12.4. Placement PrioritizerPolicy

  • 割り当て可能なメモリーが最大のクラスターを選択します。

    注記: Kubernetes Node Allocatable と同様に、allocatable は、各クラスターの Pod で利用可能なコンピュートリソースの量として定義されます。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement
      namespace: ns1
    spec:
      numberOfClusters: 1
      prioritizerPolicy:
        configurations:
          - scoreCoordinate:
              builtIn: ResourceAllocatableMemory
  • 割り当て可能な CPU およびメモリーが最大のクラスターを選択し、配置がリソースの変更に厳密に対応するように設定します。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement
      namespace: ns1
    spec:
      numberOfClusters: 1
      prioritizerPolicy:
        configurations:
          - scoreCoordinate:
              builtIn: ResourceAllocatableCPU
            weight: 2
          - scoreCoordinate:
              builtIn: ResourceAllocatableMemory
            weight: 2
  • addOn スコアの CPU 比率が最大の 2 つのクラスターを選択し、配置の決定を固定します。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement
      namespace: ns1
    spec:
      numberOfClusters: 2
      prioritizerPolicy:
        mode: Exact
        configurations:
          - scoreCoordinate:
              builtIn: Steady
            weight: 3
          - scoreCoordinate:
              type: AddOn
              addOn:
                resourceName: default
                scoreName: cpuratio

1.5.12.5. 配置のデシジョン

ラベルが cluster.open-cluster-management.io/placement={placement name}PlacementDecisions が 1 つまたは複数作成され、Placement で選択された ManagedClusters を表します。

ManagedCluster が選択され、PlacementDecision に追加されると、この Placement を使用するコンポーネントは、ManagedCluster でワークロードを適用する可能性があります。ManagedCluster が選択されなくなり、PlacementDecisions から削除されると、この ManagedCluster に適用されるワークロードは削除される必要があります。

API の詳細については、PlacementDecisions API を参照してください。

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

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: PlacementDecision
metadata:
  labels:
    cluster.open-cluster-management.io/placement: placement1
  name: placement1-kbc7q
  namespace: ns1
  ownerReferences:
    - apiVersion: cluster.open-cluster-management.io/v1beta1
      blockOwnerDeletion: true
      controller: true
      kind: Placement
      name: placement1
      uid: 05441cf6-2543-4ecc-8389-1079b42fe63e
status:
  decisions:
    - clusterName: cluster1
      reason: ''
    - clusterName: cluster2
      reason: ''
    - clusterName: cluster3
      reason: ''

1.5.12.6. アドオンのステータス

デプロイ先のアドオンのステータスに合わせて、配置用のマネージドクラスターを選択できます。たとえば、クラスターで有効になっている特定のアドオンがある場合にのみ、配置のマネージドクラスターを選択します。

Placement を作成するときに、アドオンのラベルとそのステータスを指定します。クラスターでアドオンが有効になっている場合、ラベルは ManagedCluster リソースで自動的に作成されます。アドオンが無効になると、ラベルは自動的に削除されます。

各アドオンは、feature.open-cluster-management.io/addon-<addon_name>=<status_of_addon> の形式でラベルで表現します。

addon_name は、選択するマネージドクラスターで有効にする必要があるアドオンの名前に置き換えます。

status_of_addon は、クラスターが選択されている場合にアドオンに指定すべきステータスに置き換えます。status_of_addon の使用可能な値は以下のリストのとおりです。

  • Available: アドオンが有効で利用可能である。
  • unhealthy: アドオンは有効になっているが、リースは継続的に更新されない。
  • unreachable: アドオンは有効になっているが、リースが見つからない。これは、マネージドクラスターがオフライン時にも発生する可能性があります。

たとえば、利用可能な application-manager アドオンは、以下を読み取るマネージドクラスターのラベルで表されます。

feature.open-cluster-management.io/addon-application-manager: available

アドオンおよびそれらのステータスに基づいて配置を作成する以下の例を参照してください。

  • 以下の YAML コンテンツを追加して、application-manager を有効化したマネージドクラスターすべてを含む配置を作成できます。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement1
      namespace: ns1
    spec:
      predicates:
        - requiredClusterSelector:
            labelSelector:
              matchExpressions:
                - key: feature.open-cluster-management.io/addon-application-manager
                  operator: Exists
  • 以下の YAML コンテンツを追加して、application-manageravailable のステータスで有効化されているすべてのマネージドクラスターを含む配置を作成できます。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement2
      namespace: ns1
    spec:
      predicates:
        - requiredClusterSelector:
            labelSelector:
              matchLabels:
                "feature.open-cluster-management.io/addon-application-manager": "available"
  • 以下の YAML コンテンツを追加して、application-manager が無効にされているマネージドクラスターすべてを含む配置を作成できます。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Placement
    metadata:
      name: placement3
      namespace: ns1
    spec:
      predicates:
        - requiredClusterSelector:
            labelSelector:
              matchExpressions:
                - key: feature.open-cluster-management.io/addon-application-manager
                  operator: DoesNotExist

1.5.13. クラスタープールの管理 (テクノロジープレビュー)

クラスタープールは、Red Hat OpenShift Container Platform クラスターにオンデマンドで、スケーリングする場合に、迅速かつコスト効果を高く保ちながら、アクセスできるようにします。クラスタープールは、Amazon Web Services、Google Cloud Platform または Microsoft Azure で設定可能な数多くの OpenShift Container Platform クラスターをプロビジョニングします。このプールは、開発、継続統合、および実稼働のシナリオにおいてクラスター環境を提供したり、置き換えたりする場合に特に便利です。実行を継続するクラスターの数を指定して、すぐに要求できるようにすることができます。残りのクラスターは休止状態に保たれるため、数分以内に再開して要求できます。

ClusterClaim リソースは、クラスタープールからクラスターをチェックアウトするために使用されます。クラスター要求が作成されると、その要求にプールは実行中のクラスターを割り当てます。実行中のクラスターがない場合は、休止状態のクラスターを再開してクラスターを提供するか、新規クラスターをプロビジョニングします。クラスタープールは自動的に新しいクラスターを作成し、休止状態のクラスターを再開して、プール内で利用可能な実行中のクラスターの指定サイズおよび数を維持します。

クラスタープールを作成する手順は、クラスターの作成手順と似ています。クラスタープールのクラスターは、すぐ使用するために作成されるわけではありません。

1.5.13.1. クラスタープールの作成

クラスタープールを作成する手順は、クラスターの作成手順と似ています。クラスタープールのクラスターは、すぐ使用するために作成されるわけではありません。

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

1.5.13.1.1. 前提条件

クラスタープールを作成する前に、次の前提条件を参照してください。

  • マルチクラスターエンジン Operator ハブクラスターをデプロイする必要があります。
  • プロバイダー環境で Kubernetes クラスターを作成できるように、マルチクラスターエンジン Operator ハブクラスターのインターネットアクセスが必要です。
  • AWS、GCP、または Microsoft Azure プロバイダーのクレデンシャルが必要です。詳細は、認証情報の管理の概要 を参照してください。
  • プロバイダー環境で設定済みのドメインが必要です。ドメインの設定方法は、プロバイダーのドキュメントを参照してください。
  • プロバイダーのログイン認証情報が必要です。
  • OpenShift Container Platform イメージプルシークレットが必要です。イメージプルシークレットの使用 を参照してください。

注意: この手順でクラスタープールを追加すると、プールからクラスターを要求するときに、マルチクラスターエンジン Operator によって管理されるクラスターが自動的にインポートされるように設定されます。クラスター要求で管理用に、要求されたクラスターを自動的にインポートしないようにクラスタープールを作成する場合には、clusterClaim 理 s−すを以下ののテーションに追加します。

kind: ClusterClaim
metadata:
  annotations:
    cluster.open-cluster-management.io/createmanagedcluster: "false"

文字列であることを示すには、"false" という単語を引用符で囲む必要があります。

1.5.13.1.2. クラスタープールを作成する

クラスタープールを作成するには、ナビゲーションメニューで Infrastructure > Clusters を選択します。Cluster pools タブには、アクセス可能なクラスタープールがリスト表示されます。Create cluster pool を選択し、コンソールの手順を実行します。

クラスタープールに使用するインフラストラクチャー認証情報がない場合は、Add credential を選択して作成できます。

リストから既存の namespace を選択するか、作成する新規 namespace の名前を入力します。クラスタープールは、クラスターと同じ namespace に配置する必要はありません。

クラスタープールの RBAC ロールを使用して、既存クラスターセットのロール割り当てを共有する場合は、クラスターセット名を選択します。クラスタープールのクラスターセットは、クラスタープールの作成時にのみ設定できます。クラスタープールの作成後には、クラスタープールまたはクラスタープールのクラスターセットの関連付けを変更できません。クラスタープールから要求したクラスターは、クラスタープールと同じクラスターセットに自動的に追加されます。

注記: cluster admin の権限がない場合は、クラスターセットを選択する必要があります。この状況でクラスターセットの名前が含まれない場合は、禁止エラーで、クラスターセットの作成要求が拒否されます。選択できるクラスターセットがない場合は、クラスター管理者に連絡してクラスターセットを作成し、clusterset admin 権限を付与してもらいます。

cluster pool size は、クラスタープールにプロビジョニングするクラスターの数を指定し、クラスタープールの実行回数は、プールが実行を継続し、すぐに使用できるように要求できるクラスターの数を指定します。

この手順は、クラスターを作成する手順と非常に似ています。

プロバイダーに必要な固有の情報は、以下を参照してください。

1.5.13.2. クラスタープールからのクラスターの要求

ClusterClaim リソースは、クラスタープールからクラスターをチェックアウトするために使用されます。クラスターの稼働中で、クラスタープールで準備できると、要求が完了します。クラスタープールは、クラスタープールに指定された要件を維持するために、クラスタープールに新しい実行中およびハイバネートされたクラスターを自動的に作成します。

注記: クラスタープールから要求されたクラスターが不要になり、破棄されると、リソースは削除されます。クラスターはクラスタープールに戻りません。

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

1.5.13.2.1. 前提条件

クラスタープールからクラスターを要求する前に、以下を利用意する必要があります。

利用可能なクラスターのある/ないクラスタープール。クラスタープールに利用可能なクラスターがある場合、利用可能なクラスターが要求されます。クラスタープールに利用可能なクラスターがない場合は、要求を満たすためにクラスターが作成されます。クラスタープールの作成方法については、クラスタープールの作成 を参照してください。

1.5.13.2.2. クラスタープールからのクラスターの要求

クラスター要求の作成時に、クラスタープールから新規クラスターを要求します。クラスターが利用可能になると、クラスターはプールからチェックアウトされます。自動インポートを無効にしていない限り、要求されたクラスターはマネージドクラスターの 1 つとして自動的にインポートされます。

以下の手順を実行してクラスターを要求します。

  1. ナビゲーションメニューから Infrastructure > Clusters をクリックし、Cluster pools タブを選択します。
  2. クラスターを要求するクラスタープールの名前を見つけ、Claim cluster を選択します。

クラスターが利用可能な場合には、クラスターが要求され、マネージドクラスター タブにすぐに表示されます。利用可能なクラスターがない場合は、休止状態のクラスターの再開や、新しいクラスターのプロビジョニングに数分かかる場合があります。この間、要求のステータスは pending です。クラスタープールをデプロイメントして、保留中の要求を表示または削除します。

要求されたクラスターは、クラスタープールにあった時に関連付けられたクラスターセットに所属します。要求時には、要求したクラスターのクラスターセットは変更できません。

注記: クラウドプロバイダーの認証情報のプルシークレット、SSH キー、またはベースドメインへの変更は、クラスタープールから請求された既存のクラスターについては、元の認証情報を使用してすでにプロビジョニングされているため、反映されません。コンソールを使用してクラスタープール情報を編集することはできませんが、CLI インターフェイスを使用してその情報を更新することで更新できます。更新された情報を含む認証情報を使用して、新しいクラスタープールを作成することもできます。新しいプールで作成されるクラスターは、新しい認証情報で提供される設定を使用します。

1.5.13.3. クラスタープールリリースイメージの更新

クラスタープールのクラスターが一定期間、休止状態のままになると、クラスターの Red Hat OpenShift Container Platform リリースイメージがバックレベルになる可能性があります。このような場合は、クラスタープールにあるクラスターのリリースイメージのバージョンをアップグレードしてください。

必要なアクセス: 編集

クラスタープールにあるクラスターの OpenShift Container Platform リリースイメージを更新するには、以下の手順を実行します。

注記: この手順では、クラスタープールですでに要求されているクラスタープールからクラスターを更新しません。この手順を完了すると、リリースイメージの更新は、クラスタープールに関連する次のクラスターにのみ適用されます。

  • この手順でリリースイメージを更新した後にクラスタープールによって作成されたクラスター。
  • クラスタープールで休止状態になっているクラスター。古いリリースイメージを持つ既存の休止状態のクラスターは破棄され、新しいリリースイメージを持つ新しいクラスターがそれらを置き換えます。
  1. ナビゲーションメニューから infrastructure > Clusters をクリックします。
  2. Cluster pools タブを選択します。
  3. クラスタープール の表で、更新するクラスタープールの名前を見つけます。
  4. 表の Cluster poolsOptions メニューをクリックし、Update release image を選択します。
  5. このクラスタープールから今後、クラスターの作成に使用する新規リリースイメージを選択します。

クラスタープールのリリースイメージが更新されました。

ヒント: アクション 1 つで複数のクラスターのリリースイメージを更新するには、各クラスタープールのボックスを選択して Actions メニューを使用し、選択したクラスタープールのリリースイメージを更新します。

1.5.13.4. Scaling cluster pools (Technology Preview)

クラスタープールのクラスター数は、クラスタープールサイズのクラスター数を増やしたり、減らしたりして変更できます。

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

クラスタープールのクラスター数を変更するには、以下の手順を実行します。

  1. ナビゲーションメニューから infrastructure > Clusters をクリックします。
  2. Cluster pools タブを選択します。
  3. 変更するクラスタープールの Options メニューで、Scale cluster pool を選択します。
  4. プールサイズの値を変更します。
  5. オプションで、実行中のクラスターの数を更新して、要求時にすぐに利用可能なクラスター数を増減できます。

クラスタープールは、新しい値を反映するようにスケーリングされます。

1.5.13.5. クラスタープールの破棄

クラスタープールを作成し、不要になった場合は、そのクラスタープールを破棄できます。クラスタープールを破棄する時に、要求されていない休止状態のクラスターはすべて破棄され、そのリソースは解放されます。

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

クラスタープールを破棄するには、以下の手順を実行します。

  1. ナビゲーションメニューから infrastructure > Clusters をクリックします。
  2. Cluster pools タブを選択します。
  3. 削除するクラスタープールの Options メニューで、Destroy cluster pool を選択します。クラスタープールで要求されていないクラスターは破棄されます。すべてのリソースが削除されるまでに時間がかかる場合があります。また、クラスタープールは、すべてのリソースが削除されるまでコンソールに表示されたままになります。

    ClusterPool が含まれる namespace は削除されません。namespace を削除すると、これらのクラスターの ClusterClaim リソースは同じ namespace で作成されるため、ClusterPool から要求されたクラスターがすべて破棄されます。

ヒント: アクション 1 つで複数のクラスタープールを破棄するには、各クラスタープールのボックスを選択して Actions メニューを使用し、選択したクラスタープールを破棄します。

1.5.14. ManagedServiceAccount アドオンの有効化 (テクノロジープレビュー)

マルチクラスターエンジン Operator をインストールすると、ManagedServiceAccount アドオンはデフォルトで無効になります。このコンポーネントを有効にすると、マネージドクラスターでサービスアカウントを作成または削除できます。

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

ManagedServiceAccount カスタムリソースがハブクラスターの <managed_cluster> namespace に作成されると、ServiceAccount がマネージドクラスターに作成されます。

TokenRequest は、マネージドクラスターの ServiceAccount を使用して、マネージドクラスターの Kubernetes API サーバーに対して行われます。トークンは、ハブクラスターの <target_managed_cluster> namespace の Secret に保存されます。

注記 トークンは期限切れになり、ローテーションされる可能性があります。トークンリクエストの詳細については、TokenRequest を参照してください。

1.5.14.1. 前提条件

  • お使いの環境に Red Hat OpenShift Container Platform バージョン 4.11 以降をインストールし、コマンドラインインターフェイス (CLI) でログインしている。
  • マルチクラスターエンジン Operator がインストールされている必要がある。

1.5.14.2. ManagedServiceAccount の有効化

ハブクラスターとマネージドクラスターの Managed-ServiceAccount アドオンを有効にするには、次の手順を実行します。

  1. ハブクラスターで ManagedServiceAccount アドオンを有効にします。詳細は、詳細設定 を参照してください。
  2. ManagedServiceAccount アドオンをデプロイし、それをターゲットのマネージドクラスターに適用します。次の YAML ファイルを作成し、target_managed_clusterManaged-ServiceAccount アドオンを適用するマネージドクラスターの名前に置き換えます。

    apiVersion: addon.open-cluster-management.io/v1alpha1
    kind: ManagedClusterAddOn
    metadata:
      name: managed-serviceaccount
      namespace: <target_managed_cluster>
    spec:
      installNamespace: open-cluster-management-agent-addon
  3. 次のコマンドを実行して、ファイルを適用します。

    oc apply -f -

    これで、マネージドクラスターの Managed-ServiceAccount プラグインが有効になりました。ManagedServiceAccount を設定するには、次の手順を参照してください。

  4. 次の YAML ソースを使用して ManagedServiceAccount カスタムリソースを作成します。

    apiVersion: authentication.open-cluster-management.io/v1alpha1
    kind: ManagedServiceAccount
    metadata:
      name: <managed_serviceaccount_name>
      namespace: <target_managed_cluster>
    spec:
      rotation: {}
    • managed_serviceaccount_nameManagedServiceAccount の名前に置き換えます。
    • target_managed_cluster を、ManagedServiceAccount を適用するマネージドクラスターの名前に置き換えます。
  5. 確認するには、ManagedServiceAccount オブジェクトのステータスで tokenSecretRef 属性を表示して、シークレット名と namespace を見つけます。アカウントとクラスター名を使用して次のコマンドを実行します。

    oc get managedserviceaccount <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml
  6. マネージドクラスターで作成された ServiceAccount に接続されている取得されたトークンを含む Secret を表示します。以下のコマンドを実行します。

    oc get secret <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml

1.5.15. クラスターのライフサイクルの詳細設定

一部のクラスター設定は、インストール中またはインストール後に設定できます。

1.5.15.1. API サーバー証明書のカスタマイズ

マネージドクラスターは、OpenShift Kube API サーバーの外部ロードバランサーとの相互接続を介してハブクラスターと通信します。デフォルトの OpenShift Kube API サーバー証明書は、OpenShift Container Platform のインストール時に内部 Red Hat OpenShift Container Platform クラスター認証局 (CA) によって発行されます。必要に応じて、証明書を追加または変更できます。

証明書を変更すると、マネージドクラスターとハブクラスター間の通信に影響を与える可能性があります。製品をインストールする前に名前付き証明書を追加すると、マネージドクラスターがオフライン状態になる可能性がある問題を回避できます。

次のリストには、証明書の更新が必要となる場合の例がいくつか含まれています。

  • ロードバランサーのデフォルトの証明書を独自の証明書に置き換えたいと考えています。OpenShift Container Platform ドキュメントの API サーバー証明書の追加 のガイダンスに従い、ホスト名 api.<cluster_name>.<base_domain> の名前付き証明書を追加して、外部ロードバランサーのデフォルトの API サーバー証明書を置き換えることができます。証明書を置き換えると、マネージドクラスターの一部がオフライン状態に移行する可能性があります。証明書のアップグレード後にクラスターがオフライン状態になった場合は、Troubleshooting imported clusters offline after certificate change のトラブルシューティング手順に従って問題を解決してください。

    注記: 製品をインストールする前に名前付き証明書を追加すると、クラスターがオフライン状態に移行するのを回避できます。

  • 外部ロードバランサーの証明書の有効期限が切れているため、証明書を置き換える必要があります。証明書を置き換えるには、次の手順を実行します。

    1. 次の例のような APIServer カスタムリソースを見つけます。

      apiVersion: config.openshift.io/v1
      kind: APIServer
      metadata:
        name: cluster
      spec:
        audit:
          profile: Default
        servingCerts:
          namedCertificates:
          - names:
            - api.mycluster.example.com
            servingCertificate:
              name: old-cert-secret
    2. 次のコマンドを実行して、既存の証明書と新しい証明書の内容を含む新しいシークレットを openshift-config namespace に作成します。

      1. 古い証明書を新しい証明書にコピーします。

        cp old.crt combined.crt
      2. 新しい証明書の内容を古い証明書のコピーに追加します。

        cat new.crt >> combined.crt
      3. 結合した証明書を適用してシークレットを作成します。

        oc create secret tls combined-certs-secret --cert=combined.crt --key=old.key -n openshift-config
    3. APIServer リソースを更新して、結合された証明書を ServingCertificate として参照します。

      apiVersion: config.openshift.io/v1
      kind: APIServer
      metadata:
        name: cluster
      spec:
        audit:
          profile: Default
        servingCerts:
          namedCertificates:
          - names:
            - api.mycluster.example.com
            servingCertificate:
              name: combined-cert-secret
    4. 約 15 分後、新しい証明書と古い証明書の両方を含む CA バンドルがマネージドクラスターに伝播されます。
    5. 次のコマンドを入力して、新しい証明書情報のみを含む new-cert-secret という名前の別のシークレットを openshift-config namespace に作成します。

      oc create secret tls new-cert-secret --cert=new.crt --key=new.key -n openshift-config {code}
    6. new-cert-secret を参照するように servingCertificate の名前を変更して、APIServer リソースを更新します。リソースは以下の例のようになります。

      apiVersion: config.openshift.io/v1
      kind: APIServer
      metadata:
        name: cluster
      spec:
        audit:
          profile: Default
        servingCerts:
          namedCertificates:
          - names:
            - api.mycluster.example.com
            servingCertificate:
              name: new-cert-secret

約 15 分後、古い証明書が CA バンドルから削除され、変更がマネージドクラスターに自動的に伝播されます。

注記: マネージドクラスターは、ホスト名 api.<cluster_name>.<base_domain> を使用してハブクラスターにアクセスする必要があります。他のホスト名で設定された名前付き証明書は使用できません。

1.5.15.2. 関連情報

1.5.16. マネージメントからのクラスターの削除

マルチクラスターエンジン Operator で作成された OpenShift Container Platform クラスターを管理から削除する場合は、それを デタッチ または 破壊 することができます。クラスターをデタッチするとマネージメントから削除されますが、完全には削除されません。管理する場合には、もう一度インポートし直すことができます。このオプションは、クラスターが Ready 状態にある場合にだけ利用できます。

次の手順により、次のいずれかの状況でクラスターが管理から削除されます。

  • すでにクラスターを削除しており、削除したクラスターを Red Hat Advanced Cluster Management から削除したいと考えています。
  • クラスターを管理から削除したいが、クラスターを削除していない。

重要:

1.5.16.1. コンソールを使用したクラスターの削除

ナビゲーションメニューから、Infrastructure > Clusters に移動し、管理から削除するクラスターの横にあるオプションメニューから Destroy cluster または Detach cluster を選択します。

ヒント: 複数のクラスターをデタッチまたは破棄するには、デタッチまたは破棄するクラスターのチェックボックスを選択して、Detach または Destroy を選択します。

注記: local-cluster と呼ばれる管理対象時にハブクラスターをデタッチしようとすると、disableHubSelfManagement のデフォルト設定が false かどうかを確認してください。この設定が原因で、ハブクラスターはデタッチされると、自身を再インポートして管理し、MultiClusterHub コントローラーが調整されます。ハブクラスターがデタッチプロセスを完了して再インポートするのに時間がかかる場合があります。

プロセスが終了するのを待たずにハブクラスターを再インポートするには、以下のコマンドを実行して multiclusterhub-operator Pod を再起動して、再インポートの時間を短縮できます。

oc delete po -n open-cluster-management `oc get pod -n open-cluster-management | grep multiclusterhub-operator| cut -d' ' -f1`

ネットワーク接続時のオンラインインストール で説明されているように、disableHubSelfManagement の値を true に変更して、自動的にインポートされないようにハブクラスターの値を変更できます。

1.5.16.2. コマンドラインを使用したクラスターの削除

ハブクラスターのコマンドラインを使用してマネージドクラスターをデタッチするには、以下のコマンドを実行します。

oc delete managedcluster $CLUSTER_NAME

切断後にマネージドクラスターを破棄するには、次のコマンドを実行します。

oc delete clusterdeployment <CLUSTER_NAME> -n $CLUSTER_NAME

注記:

  • マネージドクラスターの破壊を防ぐには、ClusterDeployment カスタムリソースで spec.preserveOnDelete パラメーターを true に設定します。
  • disableHubSelfManagement のデフォルト設定は false です。false`setting causes the hub cluster, also called `local-cluster 切り離されたときに再インポートして管理し、MultiClusterHub コントローラーを調整します。

    切り離しと再インポートのプロセスには数時間かかる場合があり、ハブクラスターが完了するまでに数時間かかる場合があります。プロセスが終了するのを待たずにハブクラスターを再インポートする場合は、以下のコマンドを実行して multiclusterhub-operator Pod を再起動して、再インポートの時間を短縮できます。

    oc delete po -n open-cluster-management `oc get pod -n open-cluster-management | grep multiclusterhub-operator| cut -d' ' -f1`

    disableHubSelfManagement の値を true に指定して、自動的にインポートされないように、ハブクラスターの値を変更できます。ネットワーク接続時のオンラインインストール を参照してください。

1.5.16.3. クラスター削除後の残りのリソースの削除

削除したマネージドクラスターにリソースが残っている場合は、残りのすべてのコンポーネントを削除するための追加の手順が必要になります。これらの追加手順が必要な場合には、以下の例が含まれます。

  • マネージドクラスターは、完全に作成される前にデタッチされ、klusterlet などのコンポーネントはマネージドクラスターに残ります。
  • マネージドクラスターをデタッチする前に、クラスターを管理していたハブが失われたり、破棄されているため、ハブからマネージドクラスターをデタッチする方法はありません。
  • マネージドクラスターは、デタッチ時にオンライン状態ではありませんでした。

これらの状況の 1 つがマネージドクラスターのデタッチの試行に該当する場合は、マネージドクラスターから削除できないリソースがいくつかあります。マネージドクラスターをデタッチするには、以下の手順を実行します。

  1. oc コマンドラインインターフェイスが設定されていることを確認してください。
  2. また、マネージドクラスターに KUBECONFIG が設定されていることを確認してください。

    oc get ns | grep open-cluster-management-agent を実行すると、2 つの namespace が表示されるはずです。

    open-cluster-management-agent         Active   10m
    open-cluster-management-agent-addon   Active   10m
  3. 次のコマンドを実行して、残りのリソースを削除します。

    oc delete namespaces open-cluster-management-agent open-cluster-management-agent-addon --wait=false
    oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc delete crds --wait=false
    oc get crds | grep open-cluster-management.io | awk '{print $1}' | xargs oc patch crds --type=merge -p '{"metadata":{"finalizers": []}}'
  4. 次のコマンドを実行して、namespaces と開いているすべてのクラスター管理 crds の両方が削除されていることを確認します。

    oc get crds | grep open-cluster-management.io | awk '{print $1}'
    oc get ns | grep open-cluster-management-agent

1.5.16.4. クラスターの削除後の etcd データベースのデフラグ

マネージドクラスターが多数ある場合は、ハブクラスターの etcd データベースのサイズに影響を与える可能性があります。OpenShift Container Platform 4.8 では、マネージドクラスターを削除すると、ハブクラスターの etcd データベースのサイズは自動的に縮小されません。シナリオによっては、etcd データベースは領域不足になる可能性があります。etcdserver: mvcc: database space exceeded のエラーが表示されます。このエラーを修正するには、データベース履歴を圧縮し、etcd データベースのデフラグを実行して etcd データベースのサイズを縮小します。

注記: OpenShift Container Platform バージョン 4.9 以降では、etcd Operator はディスクを自動的にデフラグし、etcd 履歴を圧縮します。手動による介入は必要ありません。以下の手順は、OpenShift Container Platform 4.8 以前のバージョン向けです。

以下の手順を実行して、ハブクラスターで etcd 履歴を圧縮し、ハブクラスターで etcd データベースをデフラグします。

1.5.16.4.1. 前提条件
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
1.5.16.4.2. 手順
  1. etcd 履歴を圧縮します。

    1. 次に、etcd メンバーへのリモートシェルセッションを開きます。

      $ oc rsh -n openshift-etcd etcd-control-plane-0.example.com etcdctl endpoint status --cluster -w table
    2. 以下のコマンドを実行して etcd 履歴を圧縮します。

      sh-4.4#etcdctl compact $(etcdctl endpoint status --write-out="json" |  egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*' -m1)

      出力例

      $ compacted revision 158774421

  2. Defragmenting etcd data で説明されているように、etcd データベースを デフラグし、NOSPACE アラームを消去します。

1.6. Discovery サービスの概要

OpenShift Cluster Manager で利用可能な OpenShift 4 クラスターを検出できます。検出後に、クラスターをインポートして管理できます。Discovery サービスは、バックエンドおよびコンソールでの用途に Discover Operator を使用します。

OpenShift Cluster Manager 認証情報が必要になります。認証情報を作成する必要がある場合は、Red Hat OpenShift Cluster Manager の認証情報の作成 を参照してください。

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

1.6.1. コンソールでの検出の設定

製品のコンソールを使用して検出を有効にします。

必要なアクセス権: 認証情報が作成された namespace へのアクセス権。

1.6.1.1. 前提条件

1.6.1.2. 検出の設定

コンソールで検出を設定し、クラスターを検索します。個別の認証情報を使用して複数の DiscoveryConfig リソースを作成できます。コンソールの指示に従います。

1.6.1.3. 検出されたクラスターの表示

認証情報を設定してインポートするクラスターを検出した後に、コンソールで表示できます。

  1. Clusters > Discovered clustersの順にクリックします。
  2. 以下の情報が投入された表を確認してください。

    • name は、OpenShift Cluster Manager で指定された表示名です。クラスターに表示名がない場合は、クラスターコンソール URL をもとに生成された名前が表示されます。OpenShift Cluster Manager でコンソール URL がない場合や手動で変更された場合には、クラスターの外部 ID が表示されます。
    • Namespace は、認証情報および検出クラスターを作成した namespace です。
    • type は検出されたクラスターの Red Hat OpenShift タイプです。
    • distribution version は、検出されたクラスターの Red Hat OpenShift バージョンです。
    • infrastrcture provider は検出されたクラスターのクラウドプロバイダーです。
    • Last active は、検出されたクラスターが最後にアクティブであった時間です。
    • Created は検出クラスターが作成された時間です。
    • Discovered は検出クラスターが検出された時間です。
  3. 表の中にある情報はどれでも検索できます。たとえば、特定の namespace で Discovered clusters のみを表示するには、その namespace を検索します。
  4. Import cluster をクリックすると、マネージドクラスターを作成できます。検出クラスターのインポート を参照してください。

1.6.1.4. 検出クラスターのインポート

クラスターの検出後に、コンソールの Discovered clusters に表示されるクラスターをインポートできます。

1.6.1.5. 前提条件

検出の設定に使用した namespace へのアクセス権が必要である。

1.6.1.6. 検出クラスターのインポート

  1. 既存の Clusters ページに移動し、Discovered clusters タブをクリックします。
  2. Discovered Clusters の表から、インポートするクラスターを見つけます。
  3. オプションメニューから Import cluster を選択します。
  4. 検出クラスターの場合は、本書を使用して手動でインポートしたり、Import cluster を自動的に選択したりできます。
  5. 認証情報または Kubeconfig ファイルを使用して自動でインポートするには、コンテンツをコピーして貼り付けます。
  6. Import をクリックします。

1.6.2. CLI を使用した検出の有効化

CLI を使用して検出を有効にし、Red Hat OpenShift Cluster Manager が入手できるクラスターを見つけます。

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

1.6.2.1. 前提条件

  • Red Hat OpenShift Cluster Manager に接続するための認証情報を作成している。

1.6.2.2. 検出の設定とプロセス

注記: DiscoveryConfigdiscovery という名前に指定し、選択した credential と同じ namespace に作成する必要があります。以下の DiscoveryConfig のサンプルを参照してください。

apiVersion: discovery.open-cluster-management.io/v1
kind: DiscoveryConfig
metadata:
  name: discovery
  namespace: <NAMESPACE_NAME>
spec:
  credential: <SECRET_NAME>
  filters:
    lastActive: 7
    openshiftVersions:
    - "4.10"
    - "4.11"
    - "4.8"
  1. SECRET_NAME は、以前に設定した認証情報に置き換えます。
  2. NAMESPACE_NAMESECRET_NAME の namespace に置き換えます。
  3. クラスターの最後のアクティビティー (日数) からの最大時間を入力します。たとえば、lastActive: 7 では、過去 7 日間にアクティブなクラスターが検出されます。
  4. Red Hat OpenShift クラスターのバージョンを入力して、文字列の一覧として検出します。注記: openshiftVersions 一覧に含まれるエントリーはすべて、OpenShift のメジャーバージョンとマイナーバージョンを指定します。たとえば、"4.11" には OpenShift バージョン 4.11 のすべてのパッチリリース (4.11.14.11.2 など) が含まれます。

1.6.2.3. 検出されたクラスターの表示

検出されたクラスターを表示するには、oc get discoveredclusters -n <namespace> を実行して、namespace は検出認証情報が存在する namespace に置き換えます。

1.6.2.3.1. DiscoveredClusters

オブジェクトは Discovery コントローラーにより作成されます。このような DiscoveredClusters は、DiscoveryConfig discoveredclusters.discovery.open-cluster-management.io API で指定したフィルターと認証情報を使用して OpenShift Cluster Manager で検出されたクラスターを表します。name の値はクラスターの外部 ID です。

apiVersion: discovery.open-cluster-management.io/v1
kind: DiscoveredCluster
metadata:
  name: fd51aafa-95a8-41f7-a992-6fb95eed3c8e
  namespace: <NAMESPACE_NAME>
spec:
  activity_timestamp: "2021-04-19T21:06:14Z"
  cloudProvider: vsphere
  console: https://console-openshift-console.apps.qe1-vmware-pkt.dev02.red-chesterfield.com
  creation_timestamp: "2021-04-19T16:29:53Z"
  credential:
    apiVersion: v1
    kind: Secret
    name: <SECRET_NAME>
    namespace: <NAMESPACE_NAME>
  display_name: qe1-vmware-pkt.dev02.red-chesterfield.com
  name: fd51aafa-95a8-41f7-a992-6fb95eed3c8e
  openshiftVersion: 4.10
  status: Stale

1.7. ホステッドコントロールプレーン (テクノロジープレビュー)

マルチクラスターエンジン Operator クラスター管理では、スタンドアロンまたはホステッドコントロールプレーンの 2 つの異なるコントロールプレーン設定を使用して、OpenShift Container Platform クラスターをデプロイできます。スタンドアロン設定では、専用の仮想マシンまたは物理マシンを使用して、OpenShift Container Platform のコントロールプレーンをホストします。OpenShift Container Platform の Hosted control plane を使用すると、コントロールプレーンごとに専用の物理マシンを必要とせずに、ホスティングクラスター上にコントロールプレーンを Pod として作成できます。

OpenShift Container Platform のホステッドコントロールプレーンは、Amazon Web Services (AWS) およびベアメタルでテクノロジープレビュー機能として利用できます。コントロールプレーンは、OpenShift Container Platform バージョン 4.10.7 以降でホスティングできます。

注記: ホステッドコントロールプレーンの同じプラットフォームで、ハブクラスターとワーカーを実行します。

コントロールプレーンは、単一の namespace に含まれる Pod として実行され、Hosted control plane クラスターに関連付けられます。OpenShift Container Platform がこのタイプのホステッドクラスターを作成すると、コントロールプレーンから独立したワーカーノードが作成されます。

Hosted control plane クラスターには、いくつかの利点があります。

  • 専用コントロールプレーンノードをホストする必要がなくなるため、コストを節約できます。
  • コントロールプレーンとワークロードを分離することで、分離が改善され、変更が必要になる設定エラーが減少します。
  • コントロールプレーンノードのブートストラップの要件をなくすことで、クラスターの作成時間を短縮します。
  • ターンキーデプロイメントまたは完全にカスタマイズされた OpenShift Container Platform プロビジョニングをサポートします。

ホステッドコントロールプレーンの詳細については、以下のトピックを参照してください。

1.7.1. AWS でのホスティングクラスターの設定 (テクノロジープレビュー)

Hosted control plane を設定するには、ホスティングクラスターとホステッドクラスターが必要です。hypershift-addon マネージドクラスターアドオンを使用して既存のマネージドクラスターに HyperShift Operator をデプロイすることにより、そのクラスターをホスティングクラスターとして有効にして、ホステッドクラスターを作成し始めることができます。

マルチクラスターエンジン Operator 2.2 は、デフォルトの local-cluster とハブクラスターのみをホスティングクラスターとしてサポートします。

ホステッドコントロールプレーンはテクノロジープレビュー機能であるため、関連コンポーネントはデフォルトで無効になっています。

既存のクラスターをホスティングクラスターとして機能するように設定することで、Hosted control plane をデプロイできます。ホスティングクラスターは、コントロールプレーンがホストされている Red Hat OpenShift Container Platform クラスターです。Red Hat Advanced Cluster Management 2.7 は、local-cluster とも呼ばれるハブクラスターをホスティングクラスターとして使用できます。local-cluster をホスティングクラスターとして設定する方法については、次のトピックを参照してください。

ベストプラクティス: ホステッドコントロールプレーンでは、必ず同じプラットフォームでハブクラスターとワーカーを実行してください。

1.7.1.1. 前提条件

ホスティングクラスターを設定するには、次の前提条件を満たす必要があります。

  • OpenShift Container Platform クラスターにインストールされた Kubernetes Operator 2.2 以降のマルチクラスターエンジン。マルチクラスターエンジン Operator は、Red Hat Advanced Cluster Management をインストールすると自動的にインストールされます。マルチクラスターエンジン Operator は、Red Hat Advanced Cluster Management を使用せずに OpenShift Container Platform OperatorHub から Operator としてインストールすることもできます。
  • マルチクラスターエンジン Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。local-cluster は、マルチクラスターエンジン Operator 2.2 以降で自動的にインポートされます。local-cluster の詳細については、詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。

    oc get managedclusters local-cluster
  • HyperShift Operator を実行するための少なくとも 3 つのワーカーノードを含むホスティングクラスター。
  • AWS コマンドラインインターフェイス。

1.7.1.2. Amazon Web Services S3 バケットと S3 OIDC シークレットの作成

AWS でホステッドクラスターを作成および管理する予定の場合は、次の手順を実行します。

  1. クラスターの OIDC 検出ドキュメントをホストするためのパブリックアクセスを持つ S3 バケットを作成します。

    • us-east-1 リージョンにバケットを作成するには、次のコードを入力します。

      BUCKET_NAME=<your_bucket_name>
      aws s3api create-bucket --bucket $BUCKET_NAME
      aws s3api delete-public-access-block --bucket $BUCKET_NAME
      echo '{
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Principal": "*",
                  "Action": "s3:GetObject",
                  "Resource": "arn:aws:s3:::${BUCKET_NAME}/*"
              }
          ]
      }' | envsubst > policy.json
      aws s3api put-bucket-policy --bucket $BUCKET_NAME --policy file://policy.json
    • us-east-1 リージョン以外のリージョンにバケットを作成するには、次のコードを入力します。

      BUCKET_NAME=your-bucket-name
      REGION=us-east-2
      aws s3api create-bucket --bucket $BUCKET_NAME \
        --create-bucket-configuration LocationConstraint=$REGION \
        --region $REGION
      aws s3api delete-public-access-block --bucket $BUCKET_NAME
      echo '{
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Principal": "*",
                  "Action": "s3:GetObject",
                  "Resource": "arn:aws:s3:::${BUCKET_NAME}/*"
              }
          ]
      }' | envsubst > policy.json
      aws s3api put-bucket-policy --bucket $BUCKET_NAME --policy file://policy.json
  2. HyperShift Operator 用に hypershift-operator-oidc-provider-s3-credentials という名前の OIDC S3 シークレットを作成します。
  3. シークレットを local-cluster namespace に保存します。
  4. シークレットに以下のフィールドが含まれることを確認するには、以下の表を参照してください。

    フィールド名説明

    bucket

    HyperShift クラスターの OIDC 検出ドキュメントをホストするためのパブリックアクセスを備えた S3 バケットが含まれます。

    credentials

    バケットにアクセスできる default プロファイルの認証情報を含むファイルへの参照。デフォルトでは、HyperShift は default プロファイルのみを使用して バケット を操作します。

    region

    S3 バケットのリージョンを指定します。

    次の例は、サンプルの AWS シークレットテンプレートを示しています。

    oc create secret generic hypershift-operator-oidc-provider-s3-credentials --from-file=credentials=$HOME/.aws/credentials --from-literal=bucket=<s3-bucket-for-hypershift> --from-literal=region=<region> -n local-cluster

    注記: シークレットのリカバリーバックアップは自動的に有効になりません。以下のコマンドを実行して、障害復旧用に hypershift-operator-oidc-provider-s3-credentials シークレットのバックアップを有効にするラベルを追加します。

    oc label secret hypershift-operator-oidc-provider-s3-credentials -n local-cluster cluster.open-cluster-management.io/backup=true

1.7.1.3. ルーティング可能なパブリックゾーンの作成

ゲストクラスター内のアプリケーションにアクセスするには、パブリックゾーンがルーティング可能である必要があります。パブリックゾーンが存在する場合は、この手順を省略します。省力しない場合は、パブリックゾーンが既存の機能に影響を及ぼします。

次のコマンドを実行して、クラスター DNS レコードのパブリックゾーンを作成します。

BASE_DOMAIN=www.example.com
aws route53 create-hosted-zone --name $BASE_DOMAIN --caller-reference $(whoami)-$(date --rfc-3339=date)

1.7.1.4. 外部 DNS の有効化

ホステッドコントロールプレーンクラスターをサービスレベル DNS (外部 DNS) でプロビジョニングする予定の場合は、次の手順を実行します。

  1. HyperShift Operator の AWS 認証情報シークレットを作成し、local-cluster 名前空間で hypershift-operator-external-dns-credentials という名前を付けます。
  2. シークレットに必須フィールドが含まれていることを確認するには、以下の表を参照してください。

    フィールド名説明任意または必須

    provider

    サービスレベル DNS ゾーンを管理する DNS プロバイダー。

    必須

    domain-filter

    サービスレベルドメイン。

    必須

    credentials

    すべての外部 DNS タイプをサポートする認証情報ファイル。

    AWS キーを使用する場合のオプション

    aws-access-key-id

    認証情報アクセスキー ID。

    AWS DNS サービスを使用する場合のオプション

    aws-secret-access-key

    認証情報アクセスキーのシークレット。

    AWS DNS サービスを使用する場合のオプション

    詳細は、HyperShift ドキュメントの 外部 DNS を参照してください。次の例は、サンプルの hypershift-operator-external-dns-credentials シークレットテンプレートを示しています。

    oc create secret generic hypershift-operator-external-dns-credentials --from-literal=provider=aws --from-literal=domain-filter=service.my.domain.com --from-file=credentials=<credentials-file> -n local-cluster

    注記: シークレットのリカバリーバックアップは自動的に有効になりません。以下のコマンドを実行して、障害復旧用に hypershift-operator-external-dns-credentials シークレットのバックアップを有効にするラベルを追加します。

    oc label secret hypershift-operator-external-dns-credentials -n local-cluster cluster.open-cluster-management.io/backup=""

1.7.1.6. ホステッドコントロールプレーン機能の有効化

ホステッドコントロールプレーン機能はデフォルトで無効になっています。この機能を自動的に有効にすると、hypershift-addon マネージドクラスターアドオンも有効になります。次のコマンドを実行して、以下の機能を有効にすることができます。

oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-preview","enabled": true}]}}}'

次のコマンドを実行して、hypershift-preview および hypershift-local-hosting 機能が MultiClusterEngine カスタムリソースで有効になっていることを確認します。

oc get mce multiclusterengine -o yaml
apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  overrides:
    components:
    - name: hypershift-preview
      enabled: true
    - name: hypershift-local-hosting
      enabled: true
1.7.1.6.1. local-cluster の hypershift-addon マネージドクラスターアドオンを手動で有効にする

Hosted control plane 機能を有効にすると、hypershift-addon マネージドクラスターアドオンが自動的に有効になります。hypershift-addon マネージドクラスターアドオンを手動で有効にする必要がある場合は、次の手順を実行して hypershift-addon を使用し、HyperShift Operator を local-cluster にインストールします。

  1. 以下の例のようなファイルを作成して、ManagedClusterAddon HyperShift アドオンを作成します。

    apiVersion: addon.open-cluster-management.io/v1alpha1
    kind: ManagedClusterAddOn
    metadata:
      name: hypershift-addon
      namespace: local-cluster
    spec:
      installNamespace: open-cluster-management-agent-addon
  2. 以下のコマンドを実行してこのファイルを適用します。

    oc apply -f <filename>

    filename は、作成したファイル名に置き換えます。

  3. 以下のコマンドを実行して、hypershift-addon がインストールされていることを確認します。

    oc get managedclusteraddons -n local-cluster hypershift-addon
  4. アドオンがインストールされている場合、出力は以下の例のようになります。

    NAME               AVAILABLE   DEGRADED   PROGRESSING
    hypershift-addon   True

HyperShift アドオンがインストールされ、HyperShift クラスターを作成および管理するためのホスティングクラスターが利用できます。

1.7.1.7. ホステッドコントロールプレーン CLI のインストール

ホステッドコントロールプレーン (HyperShift) CLI は、OpenShift Container Platform のホステッドコントロールプレーンクラスターを作成および管理するために使用されます。ホステッドコントロールプレーン機能を有効にした後、次の手順を実行してホステッドコントロールプレーン CLI をインストールできます。

  1. OpenShift Container Platform コンソールから、Help icon > Command Line Tools をクリックします。
  2. お使いのプラットフォームの Download hypershift CLI をクリックします。

    注記: ダウンロードは hypershift-preview 機能を有効にしている場合にのみ表示されます。

  3. 次のコマンドを実行して、ダウンロードしたアーカイブを解凍します。

    tar xvzf hypershift.tar.gz
  4. 次のコマンドを実行して、バイナリーファイルを実行可能にします。

    chmod +x hypershift
  5. 次のコマンドを実行して、バイナリーファイルをパス内のディレクトリーに移動します。

    sudo mv hypershift /usr/local/bin/.

hypershift create cluster コマンドを使用して、ホステッドクラスターを作成および管理できるようになりました。次のコマンドを使用して、使用可能なパラメーターを一覧表示します。

hypershift create cluster aws --help

1.7.1.8. 関連情報

1.7.2. AWS でのホステッドコントロールプレーンクラスターの管理 (テクノロジープレビュー)

Kubernetes Operator コンソール用のマルチクラスターエンジンを使用して、Red Hat OpenShift Container Platform がホストするクラスターを作成できます。ホステッドコントロールプレーンは、Amazon Web Services (AWS) でテクノロジープレビューとして利用できます。AWS でホステッドコントロールプレーンを使用する場合、コンソールを使用してホステッドクラスターを作成するか、コンソールまたは CLI のいずれかを使用してホステッドクラスターをインポートすることができます。

1.7.2.1. 前提条件

ホステッドコントロールプレーンクラスターを作成する前に、ホステッドコントロールプレーンを設定する必要があります。詳細については、ホステッドコントロールプレーンの設定 (テクノロジープレビュー) を参照してください。

1.7.2.2. コンソールを使用した AWS でのホステッドコントロールプレーンクラスターの作成

マルチクラスターエンジン Operator コンソールからホステッドコントロールプレーンクラスターを作成するには、Infrastructure > Clusters に移動します。クラスター ページで、Create cluster > Amazon Web Services > Hosted をクリックし、コンソールで手順を完了します。

注記: コンソールにアクセスしたら、提供される基本情報を使用して、コマンドラインでクラスターを作成します。

1.7.2.3. コマンドラインを使用して AWS にホストされたクラスターをデプロイする

HyperShift コマンドラインインターフェイスをセットアップし、local-cluster をホスティングクラスターとして有効化したら、以下の手順を実行して、ホステッドクラスターを AWS にデプロイできます。

  1. 環境変数を次のように設定し、必要に応じて変数を認証情報に置き換えます。

    export REGION=us-east-1
    export CLUSTER_NAME=clc-name-hs1
    export INFRA_ID=clc-name-hs1
    export BASE_DOMAIN=dev09.red-chesterfield.com
    export AWS_CREDS=$HOME/name-aws
    export PULL_SECRET=/Users/username/pull-secret.txt
    export BUCKET_NAME=acmqe-hypershift
    export BUCKET_REGION=us-east-1
  2. CLUSTER_NAMEINFRA_ID の値が同じであることを確認してください。そうしないと、クラスターが Kubernetes Operator コンソールのマルチクラスターエンジンに正しく表示されない可能性があります。各変数の説明を表示するには、次のコマンドを実行します。

    hypershift create cluster aws --help
  3. ハブクラスターにログインしていることを確認します。
  4. 次のコマンドを実行して、ホステッドクラスターを作成します。

    hypershift create cluster aws \
        --name $CLUSTER_NAME \
        --infra-id $INFRA_ID \
        --aws-creds $AWS_CREDS \
        --pull-secret $PULL_SECRET \
        --region $REGION \
        --generate-ssh \
        --node-pool-replicas 3 \
        --namespace <hypershift-hosting-service-cluster>

    注記: デフォルトでは、HostedClusterNodePool のすべてのカスタムリソースが clusters namespace に作成されます。--namespace <namespace> パラメーターを指定すると、選択した namespace に HostedCluster および NodePool カスタムリソースが作成されます。

  5. 以下のコマンドを実行して、ホステッドクラスターのステータスを確認することもできます。

    oc get hostedclusters -n <hypershift-hosting-service-cluster>

1.7.2.4. ホストされたコントロールプレーンクラスターの AWS へのインポート

コンソールを使用して、ホストされたコントロールプレーンクラスターをインポートできます。

  1. Infrastructure > Clusters に移動し、インポート予定の、ホストされたクラスターを選択します。
  2. ホストされたクラスターのインポート をクリックします。

    注記: 検出された ホステッドクラスターについては、コンソールからインポートすることもできますが、クラスターはアップグレード可能な状態である必要があります。Hosted control plane を使用できないため、ホステッドクラスターがアップグレード可能な状態ではない場合、クラスターへのインポートは無効になります。Import をクリックして、プロセスを開始します。クラスターが更新を受信している間、ステータスは Importing であり、その後、Ready に変わります。

次の手順を完了し、CLI を使用して AWS でホストされたコントロールプレーンクラスターをインポートすることもできます。

  1. 以下のコマンドを実行して、アノテーションを HostedCluster カスタムリソースに追加します。

    oc edit hostedcluster <cluster_name> -n clusters

    <cluster_name> は、ホステッドクラスターの名前に置き換えます。

  2. 以下のコマンドを実行して、アノテーションを HostedCluster カスタムリソースに追加します。

    cluster.open-cluster-management.io/hypershiftdeployment: local-cluster/<cluster_name>
    cluster.open-cluster-management.io/managedcluster-name: <cluster_name>

    <cluster_name> は、ホステッドクラスターの名前に置き換えます。

  3. 以下のサンプル YAML ファイルを使用して、ManagedCluster リソースを作成します。

    apiVersion: cluster.open-cluster-management.io/v1
    kind: ManagedCluster
    metadata:
      annotations:
        import.open-cluster-management.io/hosting-cluster-name: local-cluster
        import.open-cluster-management.io/klusterlet-deploy-mode: Hosted
        open-cluster-management/created-via: other
      labels:
        cloud: auto-detect
        cluster.open-cluster-management.io/clusterset: default
        name: <cluster_name>
        vendor: OpenShift
      name: <cluster_name>
    spec:
      hubAcceptsClient: true
      leaseDurationSeconds: 60

    <cluster_name> は、ホステッドクラスターの名前に置き換えます。

  4. 以下のコマンドを実行してリソースを適用します。

    oc apply -f <file_name>

    <file_name> を、直前の手順で作成した YAML ファイル名に置き換えます。

  5. 以下のサンプル YAML ファイルを使用して、KlusterletAddonConfig リソースを作成します。これは、Red Hat Advanced Cluster Management にのみ適用されます。マルチクラスターエンジン Operator のみをインストールした場合は、この手順を省略します。

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

    <cluster_name> は、ホステッドクラスターの名前に置き換えます。

  6. 以下のコマンドを実行してリソースを適用します。

    oc apply -f <file_name>

    <file_name> を、直前の手順で作成した YAML ファイル名に置き換えます。

  7. インポートプロセスが完了すると、ホステッドクラスターがコンソールに表示されます。以下のコマンドを実行して、ホステッドクラスターのステータスを確認することもできます。

    oc get managedcluster <cluster_name>

1.7.2.5. AWS でのホスティングクラスターへのアクセス

ホステッドコントロールプレーンクラスターのアクセスシークレットは、hypershift-management-cluster 名前空間に格納されます。以下のシークレット名の形式を参照してください。

  • kubeconfig シークレット: <hostingNamespace>-<name>-admin-kubeconfig (clusters-hypershift-demo-admin-kubeconfig)
  • kubeadmin パスワードシークレット: <hostingNamespace>-<name>-kubeadmin-password (clusters-hypershift-demo-kubeadmin-password)

1.7.2.6. AWS でのホステッドクラスターの破棄

ホステッドクラスターとそのマネージドクラスターリソースを破棄するには、次の手順を実行します。

  1. 次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。

    hypershift destroy cluster aws --name <cluster_name> --infra-id <infra_id> --aws-creds <aws-credentials> --base-domain <base_domain> --destroy-cloud-resources

    必要に応じて名前を置き換えます。

  2. 次のコマンドを実行して、マルチクラスターエンジン Operator のマネージドクラスターリソースを削除します。

    oc delete managedcluster <cluster_name>

    cluster_name をクラスターの名前に置き換えます。

1.7.3. ベアメタルでのホスティングクラスターの設定 (テクノロジープレビュー)

ホステッドコントロールプレーンを設定するには、ホスティング クラスターと ホステッド クラスターが必要です。hypershift アドオンを使用してマネージドクラスターをホスティングクラスターとして有効にし、そのクラスターに HyperShift Operator をデプロイできます。その後、ホストされたクラスターの作成を開始できます。

マルチクラスターエンジン Operator 2.2 は、デフォルトの local-cluster とハブクラスターのみをホスティングクラスターとしてサポートします。

ホステッドコントロールプレーンはテクノロジープレビュー機能であるため、関連コンポーネントはデフォルトで無効になっています。

ホスティングクラスターとして機能するようにクラスターを設定することで、ホストされたコントロールプレーンをデプロイメントできます。ホスティングクラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。

Red Hat Advanced Cluster Management 2.7 では、local-cluster としても知られるマネージドハブクラスターをホスティングクラスターとして使用できます。

重要:

  • ホステッドコントロールプレーンの同じプラットフォームで、ハブクラスターとワーカーを実行します。
  • エージェントプラットフォームを使用して、Hosted control plane をベアメタルでプロビジョニングできます。エージェントプラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。
  • 各ベアメタルホストは、central infrastructure management が提供する検出イメージを使用して開始する必要があります。ホストは手動で起動することも、Cluster-Baremetal-Operator を使用して自動化することもできます。各ホストが起動すると、エージェントプロセスが実行され、ホストの詳細が検出され、インストールが完了します。Agent カスタムリソースは、各ホストを表します。
  • エージェントプラットフォームでホステッドクラスターを作成すると、HyperShift は Hosted Control Plane (HCP) namespace に Agent Cluster API プロバイダーをインストールします。
  • ノードプールをスケールアップすると、マシンが作成されます。Cluster API プロバイダーは、承認され、検証に合格し、現在使用されておらず、ノードプールの仕様で指定されている要件を満たすエージェントを見つけます。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
  • ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。クラスターを再利用する前に、検出イメージを使用してクラスターを再起動し、ノード数を更新する必要があります。

1.7.3.1. 前提条件

ホスティングクラスターを設定するには、次の前提条件を満たす必要があります。

  • OpenShift Container Platform クラスターにインストールされた Kubernetes Operator 2.2 以降のマルチクラスターエンジンが必要です。マルチクラスターエンジン Operator は、Red Hat Advanced Cluster Management をインストールすると自動的にインストールされます。OpenShift Container Platform OperatorHub から Operator として Red Hat Advanced Cluster Management を使用せずに、マルチクラスターエンジン Operator をインストールすることもできます。
  • マルチクラスターエンジン Operator には、1 つ以上の OpenShift Container Platform マネージドクラスターが必要です。local-cluster は、マルチクラスターエンジン Operator 2.2 以降で自動的にインポートされます。local-cluster の詳細については、詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。

    oc get managedclusters local-cluster
  • HyperShift Operator を実行するには、3 つ以上のワーカーノードを含むホスティングクラスターが必要です。
  • ホストされたコントロールプレーン機能を有効にする必要があります。詳細は、ホストされたコントロールプレーン機能の有効化 を参照してください。

1.7.3.2. DNS の設定

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

DNS エントリーは、Hosted control plane を実行しているマネージドクラスター内のノードの 1 つを指すレコードと同様、単純化できます。エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。

次の DNS 設定の例を参照してください。

api.example.krnl.es.    IN A 192.168.122.20
api.example.krnl.es.    IN A 192.168.122.21
api.example.krnl.es.    IN A 192.168.122.22
api-int.example.krnl.es.    IN A 192.168.122.20
api-int.example.krnl.es.    IN A 192.168.122.21
api-int.example.krnl.es.    IN A 192.168.122.22
`*`.apps.example.krnl.es. IN A 192.168.122.23

1.7.3.3. 関連情報

1.7.4. ベアメタルでのホステッドコントロールプレーンクラスターの管理 (テクノロジープレビュー)

Kubernetes Operator コンソール用のマルチクラスターエンジンを使用して、Red Hat OpenShift Container Platform のホステッドクラスターを作成および管理できます。ホステッドコントロールプレーンは、Amazon Web Services (AWS) およびベアメタルでテクノロジープレビューとして利用できます。

1.7.4.1. 前提条件

ホステッドコントロールプレーンクラスターを作成する前に、ベアメタル用のホステッドコントロールプレーンを設定する必要があります。詳細については、ベアメタルでのホスティングクラスターの設定 (テクノロジープレビュー) を参照してください。

1.7.4.2. コンソールを使用してベアメタルエージェント上にホストされたコントロールプレーンクラスターを作成する

マルチクラスターエンジン Operator コンソールからホステッドコントロールプレーンクラスターを作成するには、Infrastructure > Clusters に移動します。Clusters ページで、Create cluster > Host Inventory > Hosted control plane をクリックし、コンソールで手順を完了します。

重要: クラスターを作成すると、マルチクラスターエンジン Operator コントローラーは、クラスターとそのリソースのための名前空間を作成します。その namespace には、そのクラスターインスタンスのリソースのみを含めるようにしてください。クラスターを破棄すると、namespace とその中のすべてのリソースが削除されます。

クラスターを既存のクラスターセットに追加する場合は、そのクラスターセットで追加できる適切なパーミッションが必要です。クラスターの作成時に cluster-admin 権限がない場合に、clusterset-admin 権限があるクラスターセットを選択する必要があります。指定されたクラスターセットに対して適切なパーミッションがないと、クラスターの作成に失敗します。選択するクラスターセットオプションがない場合には、クラスター管理者に連絡して、clusterset-admin 権限を受け取ってください。

マネージドクラスターはすべて、マネージドクラスターセットに関連付けられている必要があります。マネージドクラスターを ManagedClusterSet に割り当てない場合は、デフォルト のマネージドクラスターセットに自動的に追加されます。

このリリースイメージで、クラスターの作成に使用される OpenShift Container Platform イメージのバージョンを特定します。ホステッドコントロールプレーンクラスターは、提供されたリリースイメージのいずれかを使用する必要があります。

インフラストラクチャー環境で提供されるプロキシー情報は、プロキシーフィールドに自動的に追加されます。既存の情報を使用することも、それを上書きすることも、プロキシーを有効にする場合に情報を追加することもできます。次のリストには、プロキシーの作成に必要な情報が含まれています。

  • HTTP プロキシー URL: HTTP トラフィックのプロキシーとして使用する URL。
  • HTTPS プロキシー URL: HTTPS トラフィックに使用するセキュアなプロキシー URL。値の指定がない場合は、HTTP Proxy URL と同じ値が HTTP および HTTPS の両方に使用されます。
  • プロキシードメインなし: プロキシーをバイパスする必要のあるドメインのコンマ区切りリスト。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  • 追加のトランスとバンドル: ミラーレジストリーへのアクセスに必要な証明書ファイルのコンテンツ。

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

1.7.4.3. コマンドラインを使用してベアメタル上にホストされたクラスターを作成する

クラスターにデフォルトのストレージクラスが設定されていることを確認します。設定されていない場合は、PVC が保留になる可能性があります。

  1. 次のコマンドを入力します。

    export CLUSTERS_NAMESPACE="clusters"
    export HOSTED_CLUSTER_NAME="example"
    export HOSTED_CONTROL_PLANE_NAMESPACE="${CLUSTERS_NAMESPACE}-${HOSTED_CLUSTER_NAME}"
    export BASEDOMAIN="krnl.es"
    export PULL_SECRET_FILE=$PWD/pull-secret
    export MACHINE_CIDR=192.168.122.0/24
    # Typically the namespace is created by the hypershift-operator
    # but agent cluster creation generates a capi-provider role that
    # needs the namespace to already exist
    oc create ns ${HOSTED_CONTROL_PLANE_NAMESPACE}
    
    hypershift create cluster agent \
        --name=${HOSTED_CLUSTER_NAME} \
        --pull-secret=${PULL_SECRET_FILE} \
        --agent-namespace=${HOSTED_CONTROL_PLANE_NAMESPACE} \
        --base-domain=${BASEDOMAIN} \
        --api-server-address=api.${HOSTED_CLUSTER_NAME}.${BASEDOMAIN} \
  2. しばらくしてから、次のコマンドを入力して、ホストされたコントロールプレーン Pod が稼働中であることを確認します。

    oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get pods

    出力例

    NAME                                             READY   STATUS    RESTARTS   AGE
    capi-provider-7dcf5fc4c4-nr9sq                   1/1     Running   0          4m32s
    catalog-operator-6cd867cc7-phb2q                 2/2     Running   0          2m50s
    certified-operators-catalog-884c756c4-zdt64      1/1     Running   0          2m51s
    cluster-api-f75d86f8c-56wfz                      1/1     Running   0          4m32s
    cluster-autoscaler-7977864686-2rz4c              1/1     Running   0          4m13s
    cluster-network-operator-754cf4ffd6-lwfm2        1/1     Running   0          2m51s
    cluster-policy-controller-784f995d5-7cbrz        1/1     Running   0          2m51s
    cluster-version-operator-5c68f7f4f8-lqzcm        1/1     Running   0          2m51s
    community-operators-catalog-58599d96cd-vpj2v     1/1     Running   0          2m51s
    control-plane-operator-f6b4c8465-4k5dh           1/1     Running   0          4m32s
    etcd-0                                           1/1     Running   0          4m13s
    hosted-cluster-config-operator-c4776f89f-dt46j   1/1     Running   0          2m51s
    ignition-server-7cd8676fc5-hjx29                 1/1     Running   0          4m22s
    ingress-operator-75484cdc8c-zhdz5                1/2     Running   0          2m51s
    konnectivity-agent-c5485c9df-jsm9s               1/1     Running   0          4m13s
    konnectivity-server-85dc754888-7z8vm             1/1     Running   0          4m13s
    kube-apiserver-db5fb5549-zlvpq                   3/3     Running   0          4m13s
    kube-controller-manager-5fbf7b7b7b-mrtjj         1/1     Running   0          90s
    kube-scheduler-776c59d757-kfhv6                  1/1     Running   0          3m12s
    machine-approver-c6b947895-lkdbk                 1/1     Running   0          4m13s
    oauth-openshift-787b87cff6-trvd6                 2/2     Running   0          87s
    olm-operator-69c4657864-hxwzk                    2/2     Running   0          2m50s
    openshift-apiserver-67f9d9c5c7-c9bmv             2/2     Running   0          89s
    openshift-controller-manager-5899fc8778-q89xh    1/1     Running   0          2m51s
    openshift-oauth-apiserver-569c78c4d-568v8        1/1     Running   0          2m52s
    packageserver-ddfffb8d7-wlz6l                    2/2     Running   0          2m50s
    redhat-marketplace-catalog-7dd77d896-jtxkd       1/1     Running   0          2m51s
    redhat-operators-catalog-d66b5c965-qwhn7         1/1     Running   0          2m51s

1.7.4.4. InfraEnv の作成

InfraEnv は、ライブ ISO を開始しているホストがエージェントとして参加できる環境です。この場合、エージェントはホステッドコントロールプレーンと同じ名前空間に作成されます。

  1. InfraEnv を作成するには、次のコマンドを入力します。

    export SSH_PUB_KEY=$(cat $HOME/.ssh/id_rsa.pub)
    
    envsubst <<"EOF" | oc apply -f -
    apiVersion: agent-install.openshift.io/v1beta1
    kind: InfraEnv
    metadata:
      name: ${HOSTED_CLUSTER_NAME}
      namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE}
    spec:
      pullSecretRef:
        name: pull-secret
      sshAuthorizedKey: ${SSH_PUB_KEY}
    EOF
  2. 仮想マシンまたはベアメタルマシンがエージェントとして参加できるようにするライブ ISO を生成するには、次のコマンドを入力します。

    oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get InfraEnv ${HOSTED_CLUSTER_NAME} -ojsonpath="{.status.isoDownloadURL}"

1.7.4.5. エージェントの追加

エージェントを追加するには、手動でマシンを設定してライブ ISO で開始するか、Metal3 を使用します。

  • エージェントを手動で追加するには、次の手順に従います。

    1. ライブ ISO をダウンロードし、それを使用してノード (ベアメタルまたは VM) を起動します。起動時に、ノードは Assisted Service と通信し、InfraEnv と同じ名前空間にエージェントとして登録します。
    2. 各エージェントが作成された後、オプションでその installation_disk_idhostname を仕様に設定することができます。次に、エージェントを使用する準備ができていることを示すためにこれを承認します。

      oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agents

      出力例

      NAME                                   CLUSTER   APPROVED   ROLE          STAGE
      86f7ac75-4fc4-4b36-8130-40fa12602218                        auto-assign
      e57a637f-745b-496e-971d-1abbf03341ba                        auto-assign

      oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} patch agent 86f7ac75-4fc4-4b36-8130-40fa12602218 -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' --type merge
      
      oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} patch agent 23d0c614-2caa-43f5-b7d3-0b3564688baa -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' --type merge
      oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agents

      出力例

      NAME                                   CLUSTER   APPROVED   ROLE          STAGE
      86f7ac75-4fc4-4b36-8130-40fa12602218             true       auto-assign
      e57a637f-745b-496e-971d-1abbf03341ba             true       auto-assign

  • Metal3 を使用してエージェントを追加するには、次の手順に従います。

    1. Assisted Service を使用してカスタム ISO を作成し、Baremetal Operator を使用してインストールを実行します。

      重要: BaremetalHost オブジェクトは、baremetal-operator 名前空間の外部に作成されるため、すべての名前空間を監視するように Operator を設定する必要があります。

      oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'

      metal3 Pod が openshift-machine-api 名前空間で再起動されます。

    2. metal3 Pod の準備が再び整うまで待ちます。

      until oc wait -n openshift-machine-api $(oc get pods -n openshift-machine-api -l baremetal.openshift.io/cluster-baremetal-operator=metal3-state -o name) --for condition=containersready --timeout 10s >/dev/null 2>&1 ; do sleep 1 ; done
    3. BaremetalHost オブジェクトを作成します。ベアメタルノードを起動するために必要ないくつかの変数を設定する必要があります。

      • BMC_USERNAME: BMC に接続するためのユーザー名。
      • BMC_PASSWORD: BMC に接続するためのパスワード。
      • BMC_IP: Metal3 が BMC に接続するために使用する IP。
      • WORKER_NAME: BaremetalHost オブジェクトの名前 (この値はホスト名としても使用されます)
      • BOOT_MAC_ADDRESS: MachineNetwork に接続されている NIC の MAC アドレス。
      • UUID: Redfish UUID (通常は 1)。suhy-tools を使用している場合は、この値は長い UUID になります。iDrac を使用している場合は、この値は System.Embedded.1 になります。ベンダーに確認することを推奨します。
      • REDFISH_SCHEME: 使用する Redfish プロバイダー。標準の Redfish 実装を使用するハードウェアを使用している場合、この値を redfish-virtualmedia に設定できます。iDRAC は idrac-virtualmedia を使用します。iLO5 は ilo5-virtualmedia を使用します。ベンダーに確認することを推奨します。
      • REDFISH: Redfish 接続エンドポイント。

        export BMC_USERNAME=$(echo -n "root" | base64 -w0)
        export BMC_PASSWORD=$(echo -n "calvin" | base64 -w0)
        export BMC_IP="192.168.124.228"
        export WORKER_NAME="ocp-worker-0"
        export BOOT_MAC_ADDRESS="aa:bb:cc:dd:ee:ff"
        export UUID="1"
        export REDFISH_SCHEME="redfish-virtualmedia"
        export REDFISH="${REDFISH_SCHEME}://${BMC_IP}/redfish/v1/Systems/${UUID}"
    4. 次の手順に従って BaremetalHost を作成します。

      1. BMC シークレットを作成します。

        oc apply -f -
        apiVersion: v1
        data:
          password: ${BMC_PASSWORD}
          username: ${BMC_USERNAME}
        kind: Secret
        metadata:
          name: ${WORKER_NAME}-bmc-secret
          namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE}
        type: Opaque
      2. BMH を作成します。

        注記: infraenvs.agent-install.openshift.io ラベルは、BMH の開始に使用される InfraEnv を指定するために使用されます。bmac.agent-install.openshift.io/hostname ラベルは、ホスト名を手動で設定するために使用されます。

        インストールディスクを手動で指定する場合は、BMH 仕様の rootDeviceHints を使用できます。rootDeviceHints が提供されていない場合、エージェントは、インストール要件により適したインストールディスクを選択します。rootDeviceHints の詳細は、BareMetalHost ドキュメントの rootDeviceHints セクションを参照してください。

        oc apply -f -
        apiVersion: metal3.io/v1alpha1
        kind: BareMetalHost
        metadata:
          name: ${WORKER_NAME}
          namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE}
          labels:
            infraenvs.agent-install.openshift.io: ${HOSTED_CLUSTER_NAME}
          annotations:
            inspect.metal3.io: disabled
            bmac.agent-install.openshift.io/hostname: ${WORKER_NAME}
        spec:
          automatedCleaningMode: disabled
          bmc:
            disableCertificateVerification: True
            address: ${REDFISH}
            credentialsName: ${WORKER_NAME}-bmc-secret
          bootMACAddress: ${BOOT_MAC_ADDRESS}
          online: true

        エージェントは自動的に承認されます。承認されない場合は、bootMACAddress が正しいことを確認してください。

        BMH がプロビジョニングされます。

        oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get bmh

        出力例

        NAME           STATE          CONSUMER   ONLINE   ERROR   AGE
        ocp-worker-0   provisioning              true             2m50s

        BMH は最終的に provisioned 状態に達します。

        oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get bmh

        出力例

        NAME           STATE          CONSUMER   ONLINE   ERROR   AGE
        ocp-worker-0   provisioned               true             72s

        プロビジョニング済み とは、ノードが virtualCD から正しく起動するように設定されたことを意味します。エージェントが表示されるまで少し時間がかかります。

        oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent

        出力例

        NAME                                   CLUSTER   APPROVED   ROLE          STAGE
        4dac1ab2-7dd5-4894-a220-6a3473b67ee6             true       auto-assign

        エージェントは自動的に承認されます。

      3. 他の 2 つのノードでこのプロセスを繰り返します。

        oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent

        出力例

        NAME                                   CLUSTER   APPROVED   ROLE          STAGE
        4dac1ab2-7dd5-4894-a220-6a3473b67ee6             true       auto-assign
        d9198891-39f4-4930-a679-65fb142b108b             true       auto-assign
        da503cf1-a347-44f2-875c-4960ddb04091             true       auto-assign

1.7.4.6. ホステッドクラスターへのアクセス

ホステッドコントロールプレーンが実行されており、エージェントはホステッドクラスターに参加する準備ができています。エージェントがホステッドクラスターに参加する前に、ホステッドクラスターにアクセスする必要があります。

  1. 次のコマンドを入力して、kubeconfig を生成します。

    hypershift create kubeconfig --namespace ${CLUSTERS_NAMESPACE} --name ${HOSTED_CLUSTER_NAME} > ${HOSTED_CLUSTER_NAME}.kubeconfig

    クラスターにアクセスすると、ノードがなく、ClusterVersion が Red Hat OpenShift Container Platform リリースを調整しようとしていることがわかります。

    oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get clusterversion,nodes

    出力例

    NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
    clusterversion.config.openshift.io/version             False       True          8m6s    Unable to apply 4.12z: some cluster operators have not yet rolled out

    クラスターを実行するには、クラスターにノードを追加する必要があります。

1.7.4.7. NodePool オブジェクトのスケーリング

NodePool オブジェクトをスケーリングして、ホステッドクラスターにノードを追加します。

  1. NodePool オブジェクトを 2 つのノードにスケーリングします。

    oc -n ${CLUSTERS_NAMESPACE} scale nodepool ${NODEPOOL_NAME} --replicas 2

    ClusterAPI Agent プロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。状態は、binding から discoveringinsufficientinstallinginstalling-in-progressadded-to-existing-cluster へと推移します。

    oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent

    出力例

    NAME                                   CLUSTER         APPROVED   ROLE          STAGE
    4dac1ab2-7dd5-4894-a220-6a3473b67ee6   hypercluster1   true       auto-assign
    d9198891-39f4-4930-a679-65fb142b108b                   true       auto-assign
    da503cf1-a347-44f2-875c-4960ddb04091   hypercluster1   true       auto-assign
    
    oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
    
    BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
    BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound
    BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient

  2. エージェントが added-to-existing-cluster 状態になったら、OpenShift Container Platform ノードが表示されることを確認します。

    oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes

    出力例

    NAME           STATUS   ROLES    AGE     VERSION
    ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f
    ocp-worker-2   Ready    worker   6m3s    v1.24.0+3882f8f

    ClusterOperators は、ワークロードをノードに追加することによって調整を開始します。NodePool オブジェクトをスケールアップしたときに、2 つのマシンが作成されたことも確認できます。

    oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get machines

    出力例

    NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
    hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.12z
    hypercluster1-c96b6f675-tl42p   hypercluster1-b2qhl   ocp-worker-2   agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6   Running   15m   4.12z

    clusterversion 調整は最終的に、Ingress および Console クラスター Operator のみが欠落しているポイントに到達します。

    oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get clusterversion,co
    
    NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
    clusterversion.config.openshift.io/version             False       True          40m     Unable to apply 4.12z: the cluster operator console has not yet successfully rolled out
    
    NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    clusteroperator.config.openshift.io/console                                    4.12z    False       False         False      11m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.hypercluster1.domain.com): Get "https://console-openshift-console.apps.hypercluster1.domain.com": dial tcp 10.19.3.29:443: connect: connection refused
    clusteroperator.config.openshift.io/csi-snapshot-controller                    4.12z    True        False         False      10m
    clusteroperator.config.openshift.io/dns                                        4.12z    True        False         False      9m16s
    clusteroperator.config.openshift.io/image-registry                             4.12z    True        False         False      9m5s
    clusteroperator.config.openshift.io/ingress                                    4.12z    True        False         True       39m     The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)
    clusteroperator.config.openshift.io/insights                                   4.12z    True        False         False      11m
    clusteroperator.config.openshift.io/kube-apiserver                             4.12z    True        False         False      40m
    clusteroperator.config.openshift.io/kube-controller-manager                    4.12z    True        False         False      40m
    clusteroperator.config.openshift.io/kube-scheduler                             4.12z    True        False         False      40m
    clusteroperator.config.openshift.io/kube-storage-version-migrator              4.12z    True        False         False      10m
    clusteroperator.config.openshift.io/monitoring                                 4.12z    True        False         False      7m38s
    clusteroperator.config.openshift.io/network                                    4.12z    True        False         False      11m
    clusteroperator.config.openshift.io/openshift-apiserver                        4.12z    True        False         False      40m
    clusteroperator.config.openshift.io/openshift-controller-manager               4.12z    True        False         False      40m
    clusteroperator.config.openshift.io/openshift-samples                          4.12z    True        False         False      8m54s
    clusteroperator.config.openshift.io/operator-lifecycle-manager                 4.12z    True        False         False      40m
    clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog         4.12z    True        False         False      40m
    clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver   4.12z    True        False         False      40m
    clusteroperator.config.openshift.io/service-ca                                 4.12z    True        False         False      11m
    clusteroperator.config.openshift.io/storage                                    4.12z    True        False         False      11m

1.7.4.8. Ingress の処理

すべての OpenShift Container Platform クラスターには、外部 DNS レコードが関連付けられていると想定されるデフォルトのアプリケーション Ingress コントローラーがセットアップされています。たとえば、ベースドメイン krnl.esexample という名前の HyperShift クラスターを作成する場合は、ワイルドカードドメイン *.apps.example.krnl.es がルーティング可能であると予想することができます。

*.apps のロードバランサーとワイルドカード DNS レコードをセットアップできます。このプロセスでは、MetalLB をデプロイし、Ingress デプロイメントにルーティングする新しいロードバランサーサービスを設定し、ワイルドカード DNS エントリーをロードバランサー IP アドレスに割り当てる必要があります。

  1. LoadBalancer タイプのサービスを作成するときに、MetalLB がサービスの外部 IP アドレスを追加するように、MetalLB をセットアップします。

    cat <<"EOF" | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f -
    ---
    apiVersion: v1
    kind: Namespace
    metadata:
      name: metallb
      labels:
        openshift.io/cluster-monitoring: "true"
      annotations:
        workload.openshift.io/allowed: management
    ---
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: metallb-operator-operatorgroup
      namespace: metallb
    ---
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: metallb-operator
      namespace: metallb
    spec:
      channel: "stable"
      name: metallb-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
  2. Operator の実行後、MetalLB インスタンスを作成します。

    cat <<"EOF" | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f -
    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb
    EOF
  3. 単一の IP アドレスで IPAddressPool を作成して、MetalLB Operator を設定します。この IP アドレスは、クラスターノードが使用するネットワークと同じサブネット上にある必要があります。

    重要: 環境のアドレスと一致するように INGRESS_IP 環境変数を変更します。

    export INGRESS_IP=192.168.122.23
    
    envsubst <<"EOF" | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f -
    apiVersion: metallb.io/v1beta1
    kind: IPAddressPool
    metadata:
      name: ingress-public-ip
      namespace: metallb
    spec:
      protocol: layer2
      autoAssign: false
      addresses:
        - ${INGRESS_IP}-${INGRESS_IP}
    ---
    apiVersion: metallb.io/v1beta1
    kind: L2Advertisement
    metadata:
      name: ingress-public-ip
      namespace: metallb
    spec:
      ipAddressPools:
        - ingress-public-ip
    EOF
  4. 以下の手順に従って、MetalLB を介して OpenShift Container Platform ルーターを公開します。

    1. Ingress トラフィックを Ingress デプロイメントにルーティングする LoadBalancer Service をセットアップします。

      cat <<"EOF" | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f -
      kind: Service
      apiVersion: v1
      metadata:
        annotations:
          metallb.universe.tf/address-pool: ingress-public-ip
        name: metallb-ingress
        namespace: openshift-ingress
      spec:
        ports:
          - name: http
            protocol: TCP
            port: 80
            targetPort: 80
          - name: https
            protocol: TCP
            port: 443
            targetPort: 443
        selector:
          ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        type: LoadBalancer
      EOF
    2. 次のコマンドを入力して、OpenShift Container Platform コンソールにアクセスします。

      curl -kI https://console-openshift-console.apps.example.krnl.es
      
      HTTP/1.1 200 OK
    3. clusterversionclusteroperator の値をチェックして、すべてが実行されていることを確認します。以下のコマンドを入力します。

      oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get clusterversion,co

      出力例

      NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
      clusterversion.config.openshift.io/version   4.12z    True        False         3m32s   Cluster version is 4.12z
      
      NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
      clusteroperator.config.openshift.io/console                                    4.12z    True        False         False      3m50s
      clusteroperator.config.openshift.io/csi-snapshot-controller                    4.12z    True        False         False      25m
      clusteroperator.config.openshift.io/dns                                        4.12z    True        False         False      23m
      clusteroperator.config.openshift.io/image-registry                             4.12z    True        False         False      23m
      clusteroperator.config.openshift.io/ingress                                    4.12z    True        False         False      53m
      clusteroperator.config.openshift.io/insights                                   4.12z    True        False         False      25m
      clusteroperator.config.openshift.io/kube-apiserver                             4.12z    True        False         False      54m
      clusteroperator.config.openshift.io/kube-controller-manager                    4.12z    True        False         False      54m
      clusteroperator.config.openshift.io/kube-scheduler                             4.12z    True        False         False      54m
      clusteroperator.config.openshift.io/kube-storage-version-migrator              4.12z    True        False         False      25m
      clusteroperator.config.openshift.io/monitoring                                 4.12z    True        False         False      21m
      clusteroperator.config.openshift.io/network                                    4.12z    True        False         False      25m
      clusteroperator.config.openshift.io/openshift-apiserver                        4.12z    True        False         False      54m
      clusteroperator.config.openshift.io/openshift-controller-manager               4.12z    True        False         False      54m
      clusteroperator.config.openshift.io/openshift-samples                          4.12z    True        False         False      23m
      clusteroperator.config.openshift.io/operator-lifecycle-manager                 4.12z    True        False         False      54m
      clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog         4.12z    True        False         False      54m
      clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver   4.12z    True        False         False      54m
      clusteroperator.config.openshift.io/service-ca                                 4.12z    True        False         False      25m
      clusteroperator.config.openshift.io/storage                                    4.12z    True        False         False      25m

1.7.4.9. ホステッドクラスターのノード自動スケーリングの有効化

ホステッドクラスターにさらに容量が必要で、予備のエージェントが利用可能な場合は、自動スケーリングを有効にして新しいエージェントをインストールできます。

  1. 自動スケーリングを有効にするには、次のコマンドを入力します。この場合、ノードの最小数は 2 で、最大数は 5 です。

    oc -n ${CLUSTERS_NAMESPACE} patch nodepool ${HOSTED_CLUSTER_NAME} --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'

    追加のキャパシティーを必要とせずに 10 分が経過すると、エージェントは廃止され、スペアキューに再び配置されます。

  2. 新しいノードを必要とするワークロードを作成します。

    cat <<EOF | oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig apply -f -
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      creationTimestamp: null
      labels:
        app: reversewords
      name: reversewords
      namespace: default
    spec:
      replicas: 40
      selector:
        matchLabels:
          app: reversewords
      strategy: {}
      template:
        metadata:
          creationTimestamp: null
          labels:
            app: reversewords
      spec:
        containers:
        - image: quay.io/mavazque/reversewords:latest
          name: reversewords
          resources:
            requests:
              memory: 2Gi
    status: {}
    EOF
  3. 次のコマンドを入力して、残りのエージェントがデプロイされていることを確認します。この例では、スペアエージェント d9198891-39f4-4930-a679-65fb142b108b がプロビジョニングされます。

    oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'

    出力例

    BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: added-to-existing-cluster
    BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: installing-in-progress
    BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: added-to-existing-cluster

  4. 次のコマンドを入力してノードを確認すると、新しいノードが出力に表示されます。この例では、ocp-worker-0 がクラスターに追加されています。

    oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes

    出力例

    NAME           STATUS   ROLES    AGE   VERSION
    ocp-worker-0   Ready    worker   35s   v1.24.0+3882f8f
    ocp-worker-1   Ready    worker   40m   v1.24.0+3882f8f
    ocp-worker-2   Ready    worker   41m   v1.24.0+3882f8f

  5. ノードを削除するには、次のコマンドを入力してワークロードを削除します。

    oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig -n default delete deployment reversewords
  6. 10 分間待機し、次のコマンドを入力してノードが削除されたことを確認します。

    oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes

    出力例

    NAME           STATUS   ROLES    AGE   VERSION
    ocp-worker-1   Ready    worker   51m   v1.24.0+3882f8f
    ocp-worker-2   Ready    worker   52m   v1.24.0+3882f8f

    oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
    
    BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: added-to-existing-cluster
    BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound
    BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: added-to-existing-cluster

1.7.4.10. ホステッドクラスター作成の確認

デプロイメントプロセスが完了したら、ホステッドクラスターが正常に作成されたことを確認できます。ホステッドクラスターの作成から数分後に、次の手順に従います。

  1. 次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。

    oc extract -n kni21 secret/kni21-admin-kubeconfig --to=- > kubeconfig-kni21
    # kubeconfig
  2. kubeconfig を使用して、ホステッドクラスターのクラスター Operator を表示します。以下のコマンドを入力します。

    oc get co --kubeconfig=kubeconfig-kni21

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    console                                    4.10.26   True        False         False      2m38s
    csi-snapshot-controller                    4.10.26   True        False         False      4m3s
    dns                                        4.10.26   True        False         False      2m52s
    image-registry                             4.10.26   True        False         False      2m8s
    ingress                                    4.10.26   True        False         False      22m
    kube-apiserver                             4.10.26   True        False         False      23m
    kube-controller-manager                    4.10.26   True        False         False      23m
    kube-scheduler                             4.10.26   True        False         False      23m
    kube-storage-version-migrator              4.10.26   True        False         False      4m52s
    monitoring                                 4.10.26   True        False         False      69s
    network                                    4.10.26   True        False         False      4m3s
    node-tuning                                4.10.26   True        False         False      2m22s
    openshift-apiserver                        4.10.26   True        False         False      23m
    openshift-controller-manager               4.10.26   True        False         False      23m
    openshift-samples                          4.10.26   True        False         False      2m15s
    operator-lifecycle-manager                 4.10.26   True        False         False      22m
    operator-lifecycle-manager-catalog         4.10.26   True        False         False      23m
    operator-lifecycle-manager-packageserver   4.10.26   True        False         False      23m
    service-ca                                 4.10.26   True        False         False      4m41s
    storage                                    4.10.26   True        False         False      4m43s

  3. 次のコマンドを入力して、ホストされたクラスター上で実行中の Pod を表示することもできます。

    oc get pods -A --kubeconfig=kubeconfig-kni21

    出力例

    NAMESPACE                                          NAME                                                      READY   STATUS             RESTARTS        AGE
    kube-system                                        konnectivity-agent-khlqv                                  0/1     Running            0               3m52s
    kube-system                                        konnectivity-agent-nrbvw                                  0/1     Running            0               4m24s
    kube-system                                        konnectivity-agent-s5p7g                                  0/1     Running            0               4m14s
    kube-system                                        kube-apiserver-proxy-asus3-vm1.kni.schmaustech.com        1/1     Running            0               5m56s
    kube-system                                        kube-apiserver-proxy-asus3-vm2.kni.schmaustech.com        1/1     Running            0               6m37s
    kube-system                                        kube-apiserver-proxy-asus3-vm3.kni.schmaustech.com        1/1     Running            0               6m17s
    openshift-cluster-node-tuning-operator             cluster-node-tuning-operator-798fcd89dc-9cf2k             1/1     Running            0               20m
    openshift-cluster-node-tuning-operator             tuned-dhw5p                                               1/1     Running            0               109s
    openshift-cluster-node-tuning-operator             tuned-dlp8f                                               1/1     Running            0               110s
    openshift-cluster-node-tuning-operator             tuned-l569k                                               1/1     Running            0               109s
    openshift-cluster-samples-operator                 cluster-samples-operator-6b5bcb9dff-kpnbc                 2/2     Running            0               20m
    openshift-cluster-storage-operator                 cluster-storage-operator-5f784969f5-vwzgz                 1/1     Running            1 (113s ago)    20m
    openshift-cluster-storage-operator                 csi-snapshot-controller-6b7687b7d9-7nrfw                  1/1     Running            0               3m8s
    openshift-cluster-storage-operator                 csi-snapshot-controller-6b7687b7d9-csksg                  1/1     Running            0               3m9s
    openshift-cluster-storage-operator                 csi-snapshot-controller-operator-7f4d9fc5b8-hkvrk         1/1     Running            0               20m
    openshift-cluster-storage-operator                 csi-snapshot-webhook-6759b5dc8b-7qltn                     1/1     Running            0               3m12s
    openshift-cluster-storage-operator                 csi-snapshot-webhook-6759b5dc8b-f8bqk                     1/1     Running            0               3m12s
    openshift-console-operator                         console-operator-8675b58c4c-flc5p                         1/1     Running            1 (96s ago)     20m
    openshift-console                                  console-5cbf6c7969-6gk6z                                  1/1     Running            0               119s
    openshift-console                                  downloads-7bcd756565-6wj5j                                1/1     Running            0               4m3s
    openshift-dns-operator                             dns-operator-77d755cd8c-xjfbn                             2/2     Running            0               21m
    openshift-dns                                      dns-default-jwjkz                                         2/2     Running            0               113s
    openshift-dns                                      dns-default-kfqnh                                         2/2     Running            0               113s
    openshift-dns                                      dns-default-xlqsm                                         2/2     Running            0               113s
    openshift-dns                                      node-resolver-jzxnd                                       1/1     Running            0               110s
    openshift-dns                                      node-resolver-xqdr5                                       1/1     Running            0               110s
    openshift-dns                                      node-resolver-zl6h4                                       1/1     Running            0               110s
    openshift-image-registry                           cluster-image-registry-operator-64fcfdbf5-r7d5t           1/1     Running            0               20m
    openshift-image-registry                           image-registry-7fdfd99d68-t9pq9                           1/1     Running            0               53s
    openshift-image-registry                           node-ca-hkfnr                                             1/1     Running            0               56s
    openshift-image-registry                           node-ca-vlsdl                                             1/1     Running            0               56s
    openshift-image-registry                           node-ca-xqnsw                                             1/1     Running            0               56s
    openshift-ingress-canary                           ingress-canary-86z6r                                      1/1     Running            0               4m13s
    openshift-ingress-canary                           ingress-canary-8jhxk                                      1/1     Running            0               3m52s
    openshift-ingress-canary                           ingress-canary-cv45h                                      1/1     Running            0               4m24s
    openshift-ingress                                  router-default-6bb8944f66-z2lxr                           1/1     Running            0               20m
    openshift-kube-storage-version-migrator-operator   kube-storage-version-migrator-operator-56b57b4844-p9zgp   1/1     Running            1 (2m16s ago)   20m
    openshift-kube-storage-version-migrator            migrator-58bb4d89d5-5sl9w                                 1/1     Running            0               3m30s
    openshift-monitoring                               alertmanager-main-0                                       6/6     Running            0               100s
    openshift-monitoring                               cluster-monitoring-operator-5bc5885cd4-dwbc4              2/2     Running            0               20m
    openshift-monitoring                               grafana-78f798868c-wd84p                                  3/3     Running            0               94s
    openshift-monitoring                               kube-state-metrics-58b8f97f6c-6kp4v                       3/3     Running            0               104s
    openshift-monitoring                               node-exporter-ll7cp                                       2/2     Running            0               103s
    openshift-monitoring                               node-exporter-tgsqg                                       2/2     Running            0               103s
    openshift-monitoring                               node-exporter-z99gr                                       2/2     Running            0               103s
    openshift-monitoring                               openshift-state-metrics-677b9fb74f-qqp6g                  3/3     Running            0               104s
    openshift-monitoring                               prometheus-adapter-f69fff5f9-7tdn9                        0/1     Running            0               17s
    openshift-monitoring                               prometheus-k8s-0                                          6/6     Running            0               93s
    openshift-monitoring                               prometheus-operator-6b9d4fd9bd-tqfcx                      2/2     Running            0               2m2s
    openshift-monitoring                               telemeter-client-74d599658c-wqw5j                         3/3     Running            0               101s
    openshift-monitoring                               thanos-querier-64c8757854-z4lll                           6/6     Running            0               98s
    openshift-multus                                   multus-additional-cni-plugins-cqst9                       1/1     Running            0               6m14s
    openshift-multus                                   multus-additional-cni-plugins-dbmkj                       1/1     Running            0               5m56s
    openshift-multus                                   multus-additional-cni-plugins-kcwl9                       1/1     Running            0               6m14s
    openshift-multus                                   multus-admission-controller-22cmb                         2/2     Running            0               3m52s
    openshift-multus                                   multus-admission-controller-256tn                         2/2     Running            0               4m13s
    openshift-multus                                   multus-admission-controller-mz9jm                         2/2     Running            0               4m24s
    openshift-multus                                   multus-bxgvr                                              1/1     Running            0               6m14s
    openshift-multus                                   multus-dmkdc                                              1/1     Running            0               6m14s
    openshift-multus                                   multus-gqw2f                                              1/1     Running            0               5m56s
    openshift-multus                                   network-metrics-daemon-6cx4x                              2/2     Running            0               5m56s
    openshift-multus                                   network-metrics-daemon-gz4jp                              2/2     Running            0               6m13s
    openshift-multus                                   network-metrics-daemon-jq9j4                              2/2     Running            0               6m13s
    openshift-network-diagnostics                      network-check-source-8497dc8f86-cn4nm                     1/1     Running            0               5m59s
    openshift-network-diagnostics                      network-check-target-d8db9                                1/1     Running            0               5m58s
    openshift-network-diagnostics                      network-check-target-jdbv8                                1/1     Running            0               5m58s
    openshift-network-diagnostics                      network-check-target-zzmdv                                1/1     Running            0               5m55s
    openshift-network-operator                         network-operator-f5b48cd67-x5dcz                          1/1     Running            0               21m
    openshift-sdn                                      sdn-452r2                                                 2/2     Running            0               5m56s
    openshift-sdn                                      sdn-68g69                                                 2/2     Running            0               6m
    openshift-sdn                                      sdn-controller-4v5mv                                      2/2     Running            0               5m56s
    openshift-sdn                                      sdn-controller-crscc                                      2/2     Running            0               6m1s
    openshift-sdn                                      sdn-controller-fxtn9                                      2/2     Running            0               6m1s
    openshift-sdn                                      sdn-n5jm5                                                 2/2     Running            0               6m
    openshift-service-ca-operator                      service-ca-operator-5bf7f9d958-vnqcg                      1/1     Running            1 (2m ago)      20m
    openshift-service-ca                               service-ca-6c54d7944b-v5mrw                               1/1     Running            0               3m8s

1.7.4.11. ベアメタルでのホステッドクラスターの破棄

コンソールを使用して、ベアメタルホステッドクラスターを破棄できます。ベアメタル上のホステッドクラスターを破壊するには、次の手順を実行します。

  1. コンソールで、Infrastructure > Clusters に移動します。
  2. Clusters ページで、破棄するクラスターを選択します。
  3. Actions メニューで Destroy clusters を選択し、クラスターを削除します。

1.7.4.12. 関連情報

1.7.5. ホステッドコントロールプレーン機能の無効化

HyperShift Operator をアンインストールして、Hosted control plane を無効にすることができます。ホステッドコントロールプレーンクラスター機能を無効にする場合は、ホステッドコントロールプレーンクラスターの管理 トピックで説明されているとおり、マルチクラスターエンジン Operator でホステッドクラスターとマネージドクラスターリソースを破棄する必要があります。

1.7.5.1. HyperShift Operator のアンインストール

HyperShift Operator をアンインストールし、local-cluster から hypershift-addon を無効にするには、以下の手順を実行します。

  1. 以下のコマンドを実行して、ホステッドクラスターが実行されていないことを確認します。

    oc get hostedcluster -A

    重要: ホステッドクラスターが実行されている場合、hypershift-addon が無効になっていても、HyperShift Operator はアンインストールされません。

  2. 以下のコマンドを実行して hypershift-addon を無効にします。

    oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": false}]}}}'

    ヒント: hypershift-addon を無効にした後、マルチクラスターエンジン Operator コンソールから local-clusterhypershift-addon を無効にすることもできます。

1.7.5.2. ホステッドコントロールプレーン機能の無効化

Hosted control plane 機能を無効にする前に、まず HyperShift Operator をアンインストールする必要があります。次のコマンドを実行して、ホステッドコントロールプレーン機能を無効にします。

oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-preview","enabled": false}]}}}'

次のコマンドを実行すると、MultiClusterEngine カスタムリソースで hypershift-preview および hypershift-local-hosting 機能が無効になっていることを確認できます。

oc get mce multiclusterengine -o yaml

hypershift-previewhypershift-local-hostingenabled: フラグが false に設定されている次の例を参照してください。

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

1.7.5.3. 関連情報

1.8. API

マルチクラスターエンジン Operator を使用して、クラスターのライフサイクル管理のために次の API にアクセスできます。ユーザーに必要なアクセス権限: ロールが割り当てられているアクションのみを実行できます。詳細は、以下の各リソースに関する API のドキュメントを参照してください。

1.8.1. Clusters API

1.8.1.1. 概要

このドキュメントは、Kubernetes のマルチクラスターエンジンのクラスターリソースを対象としています。クラスターリソースには、create、query、delete、update の 4 つの要求を使用できます。

1.8.1.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.8.1.1.2. タグ
  • cluster.open-cluster-management.io: クラスターを作成して管理します。

1.8.1.2. パス

1.8.1.2.1. 全クラスターのクエリー
GET /cluster.open-cluster-management.io/v1/managedclusters
1.8.1.2.1.1. 説明

クラスターに対してクエリーを実行して詳細を確認します。

1.8.1.2.1.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

1.8.1.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.1.2.1.4. 消費
  • cluster/yaml
1.8.1.2.1.5. タグ
  • cluster.open-cluster-management.io
1.8.1.2.2. クラスターの作成
POST /cluster.open-cluster-management.io/v1/managedclusters
1.8.1.2.2.1. 説明

クラスターの作成

1.8.1.2.2.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Body

body
必須

作成するクラスターを記述するパラメーター

クラスター

1.8.1.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.1.2.2.4. 消費
  • cluster/yaml
1.8.1.2.2.5. タグ
  • cluster.open-cluster-management.io
1.8.1.2.2.6. HTTP リクエストの例
1.8.1.2.2.6.1. 要求の body
{
  "apiVersion" : "cluster.open-cluster-management.io/v1",
  "kind" : "ManagedCluster",
  "metadata" : {
    "labels" : {
      "vendor" : "OpenShift"
    },
    "name" : "cluster1"
  },
  "spec": {
    "hubAcceptsClient": true,
    "managedClusterClientConfigs": [
      {
        "caBundle": "test",
        "url": "https://test.com"
      }
    ]
  },
  "status" : { }
}
1.8.1.2.3. 単一クラスターのクエリー
GET /cluster.open-cluster-management.io/v1/managedclusters/{cluster_name}
1.8.1.2.3.1. 説明

1 つのクラスターに対してクエリーを実行して詳細を確認します。

1.8.1.2.3.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

cluster_name
必須

問い合わせるクラスターの名前。

string

1.8.1.2.3.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.1.2.3.4. タグ
  • cluster.open-cluster-management.io
1.8.1.2.4. クラスターの削除
DELETE /cluster.open-cluster-management.io/v1/managedclusters/{cluster_name}
1.8.1.2.4.1. 説明

単一クラスターを削除します。

1.8.1.2.4.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

cluster_name
必須

削除するクラスターの名前。

string

1.8.1.2.4.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.1.2.4.4. タグ
  • cluster.open-cluster-management.io

1.8.1.3. 定義

1.8.1.3.1. クラスター
名前スキーマ

apiVersion
必須

string

kind
必須

string

metadata
必須

object

spec
必須

spec

spec

名前スキーマ

hubAcceptsClient
必須

bool

managedClusterClientConfigs
任意

< managedClusterClientConfigs > array

leaseDurationSeconds
任意

integer (int32)

managedClusterClientConfigs

名前説明スキーマ

URL
必須

 

string

CABundle
任意

パターン: "^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$"

string (バイト)

1.8.2. Clustersets API (v1beta2)

1.8.2.1. 概要

このドキュメントは、Kubernetes のマルチクラスターエンジンの Clusterset リソースを対象としています。Clusterset リソースには、create、query、delete、update の 4 つの要求を使用できます。

1.8.2.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.8.2.1.2. タグ
  • cluster.open-cluster-management.io: Clustersets を作成して管理します。

1.8.2.2. パス

1.8.2.2.1. 全 clusterset のクエリー
GET /cluster.open-cluster-management.io/v1beta2/managedclustersets
1.8.2.2.1.1. 説明

Clustersets に対してクエリーを実行して詳細を確認します。

1.8.2.2.1.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

1.8.2.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.2.2.1.4. 消費
  • clusterset/yaml
1.8.2.2.1.5. タグ
  • cluster.open-cluster-management.io
1.8.2.2.2. clusterset の作成
POST /cluster.open-cluster-management.io/v1beta2/managedclustersets
1.8.2.2.2.1. 説明

Clusterset を作成します。

1.8.2.2.2.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Body

body
必須

作成する clusterset を記述するパラメーター

Clusterset

1.8.2.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.2.2.2.4. 消費
  • clusterset/yaml
1.8.2.2.2.5. タグ
  • cluster.open-cluster-management.io
1.8.2.2.2.6. HTTP リクエストの例
1.8.2.2.2.6.1. 要求の body
{
  "apiVersion" : "cluster.open-cluster-management.io/v1beta2",
  "kind" : "ManagedClusterSet",
  "metadata" : {
    "name" : "clusterset1"
  },
  "spec": { },
  "status" : { }
}
1.8.2.2.3. 単一 clusterset のクエリー
GET /cluster.open-cluster-management.io/v1beta2/managedclustersets/{clusterset_name}
1.8.2.2.3.1. 説明

単一の clusterset に対してクエリーを実行して詳細を確認します。

1.8.2.2.3.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

clusterset_name
必須

問い合わせる clusterset の名前。

string

1.8.2.2.3.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.2.2.3.4. タグ
  • cluster.open-cluster-management.io
1.8.2.2.4. clusterset の削除
DELETE /cluster.open-cluster-management.io/v1beta2/managedclustersets/{clusterset_name}
1.8.2.2.4.1. 説明

単一 clusterset を削除します。

1.8.2.2.4.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

clusterset_name
必須

削除する clusterset の名前。

string

1.8.2.2.4.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.2.2.4.4. タグ
  • cluster.open-cluster-management.io

1.8.2.3. 定義

1.8.2.3.1. Clusterset
名前スキーマ

apiVersion
必須

string

kind
必須

string

metadata
必須

object

1.8.3. Clustersetbindings API (v1beta2)

1.8.3.1. 概要

このドキュメントは、Kubernetes のマルチクラスターエンジンの clustersetbinding リソースを対象としています。clustersetbinding リソースには、create、query、delete、update の 4 つの要求を使用できます。

1.8.3.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.8.3.1.2. タグ
  • cluster.open-cluster-management.io: clustersetbinding を作成して管理します。

1.8.3.2. パス

1.8.3.2.1. 全 clustersetbinding のクエリー
GET /cluster.open-cluster-management.io/v1beta2/namespaces/{namespace}/managedclustersetbindings
1.8.3.2.1.1. 説明

clustersetbinding に対してクエリーを実行して詳細を確認します。

1.8.3.2.1.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

namespace
必須

使用する namespace (例: default)

string

1.8.3.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.3.2.1.4. 消費
  • clustersetbinding/yaml
1.8.3.2.1.5. タグ
  • cluster.open-cluster-management.io
1.8.3.2.2. clustersetbinding の作成
POST /cluster.open-cluster-management.io/v1beta2/namespaces/{namespace}/managedclustersetbindings
1.8.3.2.2.1. 説明

clustersetbinding を作成します。

1.8.3.2.2.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

namespace
必須

使用する namespace (例: default)

string

Body

body
必須

作成する clustersetbinding を記述するパラメーター

Clustersetbinding

1.8.3.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.3.2.2.4. 消費
  • clustersetbinding/yaml
1.8.3.2.2.5. タグ
  • cluster.open-cluster-management.io
1.8.3.2.2.6. HTTP リクエストの例
1.8.3.2.2.6.1. 要求の body
{
  "apiVersion" : "cluster.open-cluster-management.io/v1",
  "kind" : "ManagedClusterSetBinding",
  "metadata" : {
    "name" : "clusterset1",
    "namespace" : "ns1"
  },
 "spec": {
    "clusterSet": "clusterset1"
  },
  "status" : { }
}
1.8.3.2.3. 単一 clustersetbinding のクエリー
GET /cluster.open-cluster-management.io/v1beta2/namespaces/{namespace}/managedclustersetbindings/{clustersetbinding_name}
1.8.3.2.3.1. 説明

単一の clustersetbinding に対してクエリーを実行して詳細を確認します。

1.8.3.2.3.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

namespace
必須

使用する namespace (例: default)

string

パス

clustersetbinding_name
必須

問い合わせる clustersetbinding の名前

string

1.8.3.2.3.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.3.2.3.4. タグ
  • cluster.open-cluster-management.io
1.8.3.2.4. clustersetbinding の削除
DELETE /cluster.open-cluster-management.io/v1beta2/managedclustersetbindings/{clustersetbinding_name}
1.8.3.2.4.1. 説明

単一 clustersetbinding を削除します。

1.8.3.2.4.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

namespace
必須

使用する namespace (例: default)

string

パス

clustersetbinding_name
必須

削除する clustersetbinding の名前

string

1.8.3.2.4.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.3.2.4.4. タグ
  • cluster.open-cluster-management.io

1.8.3.3. 定義

1.8.3.3.1. Clustersetbinding
名前スキーマ

apiVersion
必須

string

kind
必須

string

metadata
必須

object

spec
必須

spec

spec

名前スキーマ

clusterSet
必須

string

1.8.4. Clusterview API (v1alpha1)

1.8.4.1. 概要

このドキュメントは、Kubernetes のマルチクラスターエンジンの clusterview リソースを対象としています。clusterview リソースには、アクセス可能なマネージドクラスターおよびマネージドクラスターセットのリストを表示できる CLI コマンドが含まれます。使用できる要求は、list、get、および watch の 3 つです。

1.8.4.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.8.4.1.2. タグ
  • clusterview.open-cluster-management.io: お使いの ID がアクセスできるマネージドクラスターのリストを表示します。

1.8.4.2. パス

1.8.4.2.1. マネージドクラスターの取得
GET /managedclusters.clusterview.open-cluster-management.io
1.8.4.2.1.1. 説明

アクセス可能なマネージドクラスターのリストを表示します。

1.8.4.2.1.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

1.8.4.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.4.2.1.4. 消費
  • managedcluster/yaml
1.8.4.2.1.5. タグ
  • clusterview.open-cluster-management.io
1.8.4.2.2. マネージドクラスターのリスト表示
LIST /managedclusters.clusterview.open-cluster-management.io
1.8.4.2.2.1. 説明

アクセス可能なマネージドクラスターのリストを表示します。

1.8.4.2.2.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Body

body
任意

マネージドクラスターをリスト表示するユーザー ID の名前

string

1.8.4.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.4.2.2.4. 消費
  • managedcluster/yaml
1.8.4.2.2.5. タグ
  • clusterview.open-cluster-management.io
1.8.4.2.2.6. HTTP リクエストの例
1.8.4.2.2.6.1. 要求の body
{
  "apiVersion" : "clusterview.open-cluster-management.io/v1alpha1",
  "kind" : "ClusterView",
  "metadata" : {
    "name" : "<user_ID>"
  },
  "spec": { },
  "status" : { }
}
1.8.4.2.3. マネージドクラスターセットの監視
WATCH /managedclusters.clusterview.open-cluster-management.io
1.8.4.2.3.1. 説明

アクセス可能なマネージドクラスターを確認します。

1.8.4.2.3.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

clusterview_name
任意

監視するユーザー ID の名前

string

1.8.4.2.3.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.4.2.4. マネージドクラスターセットのリスト表示
GET /managedclustersets.clusterview.open-cluster-management.io
1.8.4.2.4.1. 説明

アクセス可能なマネージドクラスターをリスト表示します。

1.8.4.2.4.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

clusterview_name
任意

監視するユーザー ID の名前

string

1.8.4.2.4.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.4.2.5. マネージドクラスターセットのリスト表示
LIST /managedclustersets.clusterview.open-cluster-management.io
1.8.4.2.5.1. 説明

アクセス可能なマネージドクラスターをリスト表示します。

1.8.4.2.5.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

clusterview_name
任意

監視するユーザー ID の名前

string

1.8.4.2.5.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.4.2.6. マネージドクラスターセットの監視
WATCH /managedclustersets.clusterview.open-cluster-management.io
1.8.4.2.6.1. 説明

アクセス可能なマネージドクラスターを確認します。

1.8.4.2.6.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

clusterview_name
任意

監視するユーザー ID の名前

string

1.8.4.2.6.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.5. マネージドサービスアカウント (テクノロジープレビュー)

1.8.5.1. 概要

このドキュメントは、マルチクラスターエンジン Operator の ManagedServiceAccount リソースを対象としています。ManagedServiceAccount リソースには、create、query、delete、update の 4 つのリクエストがあります。

1.8.5.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.8.5.1.2. タグ
  • managedserviceaccounts.multicluster.openshift.io`: ManagedServiceAccounts を作成および管理します

1.8.5.2. パス

1.8.5.2.1. ManagedServiceAccount を作成する
POST /apis/multicluster.openshift.io/v1alpha1/ManagedServiceAccounts
1.8.5.2.1.1. 説明

ManagedServiceAccount を作成します。

1.8.5.2.1.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Body

body
必須

作成する ManagedServiceAccount を説明するパラメーター。

ManagedServiceAccount

1.8.5.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.5.2.1.4. 消費
  • managedserviceaccount/yaml
1.8.5.2.1.5. タグ
  • managedserviceaccount.multicluster.openshift.io
1.8.5.2.1.5.1. 要求のボディー
{
  "apiVersion": "apiextensions.k8s.io/v1",
  "kind": "CustomResourceDefinition",
  "metadata": {
    "annotations": {
      "controller-gen.kubebuilder.io/version": "v0.4.1"
    },
    "creationTimestamp": null,
    "name": "managedserviceaccount.authentication.open-cluster-management.io"
  },
  "spec": {
    "group": "authentication.open-cluster-management.io",
    "names": {
      "kind": "ManagedServiceAccount",
      "listKind": "ManagedServiceAccountList",
      "plural": "managedserviceaccounts",
      "singular": "managedserviceaccount"
    },
    "scope": "Namespaced",
    "versions": [
      {
        "name": "v1alpha1",
        "schema": {
          "openAPIV3Schema": {
            "description": "ManagedServiceAccount is the Schema for the managedserviceaccounts\nAPI",
            "properties": {
              "apiVersion": {
                "description": "APIVersion defines the versioned schema of this representation\nof an object. Servers should convert recognized schemas to the latest\ninternal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources",
                "type": "string"
              },
              "kind": {
                "description": "Kind is a string value representing the REST resource this\nobject represents. Servers may infer this from the endpoint the client\nsubmits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds",
                "type": "string"
              },
              "metadata": {
                "type": "object"
              },
              "spec": {
                "description": "ManagedServiceAccountSpec defines the desired state of ManagedServiceAccount",
                "properties": {
                  "rotation": {
                    "description": "Rotation is the policy for rotation the credentials.",
                    "properties": {
                      "enabled": {
                        "default": true,
                        "description": "Enabled prescribes whether the ServiceAccount token\nwill be rotated from the upstream",
                        "type": "boolean"
                      },
                      "validity": {
                        "default": "8640h0m0s",
                        "description": "Validity is the duration for which the signed ServiceAccount\ntoken is valid.",
                        "type": "string"
                      }
                    },
                    "type": "object"
                  },
                  "ttlSecondsAfterCreation": {
                    "description": "ttlSecondsAfterCreation limits the lifetime of a ManagedServiceAccount.\nIf the ttlSecondsAfterCreation field is set, the ManagedServiceAccount\nwill be automatically deleted regardless of the ManagedServiceAccount's\nstatus. When the ManagedServiceAccount is deleted, its lifecycle\nguarantees (e.g. finalizers) will be honored. If this field is unset,\nthe ManagedServiceAccount won't be automatically deleted. If this\nfield is set to zero, the ManagedServiceAccount becomes eligible\nfor deletion immediately after its creation. In order to use ttlSecondsAfterCreation,\nthe EphemeralIdentity feature gate must be enabled.",
                    "exclusiveMinimum": true,
                    "format": "int32",
                    "minimum": 0,
                    "type": "integer"
                  }
                },
                "required": [
                  "rotation"
                ],
                "type": "object"
              },
              "status": {
                "description": "ManagedServiceAccountStatus defines the observed state of\nManagedServiceAccount",
                "properties": {
                  "conditions": {
                    "description": "Conditions is the condition list.",
                    "items": {
                      "description": "Condition contains details for one aspect of the current\nstate of this API Resource. --- This struct is intended for direct\nuse as an array at the field path .status.conditions.  For example,\ntype FooStatus struct{     // Represents the observations of a\nfoo's current state.     // Known .status.conditions.type are:\n\"Available\", \"Progressing\", and \"Degraded\"     // +patchMergeKey=type\n    // +patchStrategy=merge     // +listType=map     // +listMapKey=type\n    Conditions []metav1.Condition `json:\"conditions,omitempty\"\npatchStrategy:\"merge\" patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n     // other fields }",
                      "properties": {
                        "lastTransitionTime": {
                          "description": "lastTransitionTime is the last time the condition\ntransitioned from one status to another. This should be when\nthe underlying condition changed.  If that is not known, then\nusing the time when the API field changed is acceptable.",
                          "format": "date-time",
                          "type": "string"
                        },
                        "message": {
                          "description": "message is a human readable message indicating\ndetails about the transition. This may be an empty string.",
                          "maxLength": 32768,
                          "type": "string"
                        },
                        "observedGeneration": {
                          "description": "observedGeneration represents the .metadata.generation\nthat the condition was set based upon. For instance, if .metadata.generation\nis currently 12, but the .status.conditions[x].observedGeneration\nis 9, the condition is out of date with respect to the current\nstate of the instance.",
                          "format": "int64",
                          "minimum": 0,
                          "type": "integer"
                        },
                        "reason": {
                          "description": "reason contains a programmatic identifier indicating\nthe reason for the condition's last transition. Producers\nof specific condition types may define expected values and\nmeanings for this field, and whether the values are considered\na guaranteed API. The value should be a CamelCase string.\nThis field may not be empty.",
                          "maxLength": 1024,
                          "minLength": 1,
                          "pattern": "^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$",
                          "type": "string"
                        },
                        "status": {
                          "description": "status of the condition, one of True, False, Unknown.",
                          "enum": [
                            "True",
                            "False",
                            "Unknown"
                          ],
                          "type": "string"
                        },
                        "type": {
                          "description": "type of condition in CamelCase or in foo.example.com/CamelCase.\n--- Many .condition.type values are consistent across resources\nlike Available, but because arbitrary conditions can be useful\n(see .node.status.conditions), the ability to deconflict is\nimportant. The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt)",
                          "maxLength": 316,
                          "pattern": "^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])$",
                          "type": "string"
                        }
                      },
                      "required": [
                        "lastTransitionTime",
                        "message",
                        "reason",
                        "status",
                        "type"
                      ],
                      "type": "object"
                    },
                    "type": "array"
                  },
                  "expirationTimestamp": {
                    "description": "ExpirationTimestamp is the time when the token will expire.",
                    "format": "date-time",
                    "type": "string"
                  },
                  "tokenSecretRef": {
                    "description": "TokenSecretRef is a reference to the corresponding ServiceAccount's\nSecret, which stores the CA certficate and token from the managed\ncluster.",
                    "properties": {
                      "lastRefreshTimestamp": {
                        "description": "LastRefreshTimestamp is the timestamp indicating\nwhen the token in the Secret is refreshed.",
                        "format": "date-time",
                        "type": "string"
                      },
                      "name": {
                        "description": "Name is the name of the referenced secret.",
                        "type": "string"
                      }
                    },
                    "required": [
                      "lastRefreshTimestamp",
                      "name"
                    ],
                    "type": "object"
                  }
                },
                "type": "object"
              }
            },
            "type": "object"
          }
        },
        "served": true,
        "storage": true,
        "subresources": {
          "status": {}
        }
      }
    ]
  },
  "status": {
    "acceptedNames": {
      "kind": "",
      "plural": ""
    },
    "conditions": [],
    "storedVersions": []
  }
}
1.8.5.2.2. 単一の ManagedServiceAccount をクエリーする
GET /cluster.open-cluster-management.io/v1alpha1/namespaces/{namespace}/managedserviceaccounts/{managedserviceaccount_name}
1.8.5.2.2.1. 説明

詳細については、単一の ManagedServiceAccount を照会してください。

1.8.5.2.2.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

managedserviceaccount_name
必須

照会する ManagedServiceAccount の名前。

string

1.8.5.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.5.2.2.4. タグ
  • cluster.open-cluster-management.io
1.8.5.2.3. ManagedServiceAccount を削除する
DELETE /cluster.open-cluster-management.io/v1alpha1/namespaces/{namespace}/managedserviceaccounts/{managedserviceaccount_name}
1.8.5.2.3.1. 説明

単一の ManagedServiceAccount を削除します。

1.8.5.2.3.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

managedserviceaccount_name
必須

削除する ManagedServiceAccount の名前。

string

1.8.5.2.3.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.5.2.3.4. タグ
  • cluster.open-cluster-management.io

1.8.5.3. 定義

1.8.5.3.1. ManagedServiceAccount
名前説明スキーマ

apiVersion
必須

ManagedServiceAccount のバージョン管理されたスキーマ。

string

kind
必須

REST リソースを表す文字列の値

string

metadata
必須

ManagedServiceAccount のメタデータ。

object

spec
必須

ManagedServiceAccount の仕様。

 

1.8.6. MultiClusterEngine API

1.8.6.1. 概要

このドキュメントは、Kubernetes のマルチクラスターエンジン用の MultiClusterEngine リソースを対象としています。MultiClusterEngine リソースには、create、query、delete、update の 4 つのリクエストがあります。

1.8.6.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.8.6.1.2. タグ
  • multiclusterengines.multicluster.openshift.io : MultiClusterEngine を作成および管理します。

1.8.6.2. パス

1.8.6.2.1. MultiClusterEngine を作成する
POST /apis/multicluster.openshift.io/v1alpha1/multiclusterengines
1.8.6.2.1.1. 説明

MultiClusterEngine を作成します。

1.8.6.2.1.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Body

body
必須

作成する MultiClusterEngine を説明するパラメーター。

MultiClusterEngine

1.8.6.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.6.2.1.4. 消費
  • MultiClusterEngines/yaml
1.8.6.2.1.5. タグ
  • multiclusterengines.multicluster.openshift.io
1.8.6.2.1.5.1. 要求のボディー
{
  "apiVersion": "apiextensions.k8s.io/v1",
  "kind": "CustomResourceDefinition",
  "metadata": {
    "annotations": {
      "controller-gen.kubebuilder.io/version": "v0.4.1"
    },
    "creationTimestamp": null,
    "name": "multiclusterengines.multicluster.openshift.io"
  },
  "spec": {
    "group": "multicluster.openshift.io",
    "names": {
      "kind": "MultiClusterEngine",
      "listKind": "MultiClusterEngineList",
      "plural": "multiclusterengines",
      "shortNames": [
        "mce"
      ],
      "singular": "multiclusterengine"
    },
    "scope": "Cluster",
    "versions": [
      {
        "additionalPrinterColumns": [
          {
            "description": "The overall state of the MultiClusterEngine",
            "jsonPath": ".status.phase",
            "name": "Status",
            "type": "string"
          },
          {
            "jsonPath": ".metadata.creationTimestamp",
            "name": "Age",
            "type": "date"
          }
        ],
        "name": "v1alpha1",
        "schema": {
          "openAPIV3Schema": {
            "description": "MultiClusterEngine is the Schema for the multiclusterengines\nAPI",
            "properties": {
              "apiVersion": {
                "description": "APIVersion defines the versioned schema of this representation\nof an object. Servers should convert recognized schemas to the latest\ninternal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources",
                "type": "string"
              },
              "kind": {
                "description": "Kind is a string value representing the REST resource this\nobject represents. Servers may infer this from the endpoint the client\nsubmits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds",
                "type": "string"
              },
              "metadata": {
                "type": "object"
              },
              "spec": {
                "description": "MultiClusterEngineSpec defines the desired state of MultiClusterEngine",
                "properties": {
                  "imagePullSecret": {
                    "description": "Override pull secret for accessing MultiClusterEngine\noperand and endpoint images",
                    "type": "string"
                  },
                  "nodeSelector": {
                    "additionalProperties": {
                      "type": "string"
                    },
                    "description": "Set the nodeselectors",
                    "type": "object"
                  },
                  "targetNamespace": {
                    "description": "Location where MCE resources will be placed",
                    "type": "string"
                  },
                  "tolerations": {
                    "description": "Tolerations causes all components to tolerate any taints.",
                    "items": {
                      "description": "The pod this Toleration is attached to tolerates any\ntaint that matches the triple <key,value,effect> using the matching\noperator <operator>.",
                      "properties": {
                        "effect": {
                          "description": "Effect indicates the taint effect to match. Empty\nmeans match all taint effects. When specified, allowed values\nare NoSchedule, PreferNoSchedule and NoExecute.",
                          "type": "string"
                        },
                        "key": {
                          "description": "Key is the taint key that the toleration applies\nto. Empty means match all taint keys. If the key is empty,\noperator must be Exists; this combination means to match all\nvalues and all keys.",
                          "type": "string"
                        },
                        "operator": {
                          "description": "Operator represents a key's relationship to the\nvalue. Valid operators are Exists and Equal. Defaults to Equal.\nExists is equivalent to wildcard for value, so that a pod\ncan tolerate all taints of a particular category.",
                          "type": "string"
                        },
                        "tolerationSeconds": {
                          "description": "TolerationSeconds represents the period of time\nthe toleration (which must be of effect NoExecute, otherwise\nthis field is ignored) tolerates the taint. By default, it\nis not set, which means tolerate the taint forever (do not\nevict). Zero and negative values will be treated as 0 (evict\nimmediately) by the system.",
                          "format": "int64",
                          "type": "integer"
                        },
                        "value": {
                          "description": "Value is the taint value the toleration matches\nto. If the operator is Exists, the value should be empty,\notherwise just a regular string.",
                          "type": "string"
                        }
                      },
                      "type": "object"
                    },
                    "type": "array"
                  }
                },
                "type": "object"
              },
              "status": {
                "description": "MultiClusterEngineStatus defines the observed state of MultiClusterEngine",
                "properties": {
                  "components": {
                    "items": {
                      "description": "ComponentCondition contains condition information for\ntracked components",
                      "properties": {
                        "kind": {
                          "description": "The resource kind this condition represents",
                          "type": "string"
                        },
                        "lastTransitionTime": {
                          "description": "LastTransitionTime is the last time the condition\nchanged from one status to another.",
                          "format": "date-time",
                          "type": "string"
                        },
                        "message": {
                          "description": "Message is a human-readable message indicating\ndetails about the last status change.",
                          "type": "string"
                        },
                        "name": {
                          "description": "The component name",
                          "type": "string"
                        },
                        "reason": {
                          "description": "Reason is a (brief) reason for the condition's\nlast status change.",
                          "type": "string"
                        },
                        "status": {
                          "description": "Status is the status of the condition. One of True,\nFalse, Unknown.",
                          "type": "string"
                        },
                        "type": {
                          "description": "Type is the type of the cluster condition.",
                          "type": "string"
                        }
                      },
                      "type": "object"
                    },
                    "type": "array"
                  },
                  "conditions": {
                    "items": {
                      "properties": {
                        "lastTransitionTime": {
                          "description": "LastTransitionTime is the last time the condition\nchanged from one status to another.",
                          "format": "date-time",
                          "type": "string"
                        },
                        "lastUpdateTime": {
                          "description": "The last time this condition was updated.",
                          "format": "date-time",
                          "type": "string"
                        },
                        "message": {
                          "description": "Message is a human-readable message indicating\ndetails about the last status change.",
                          "type": "string"
                        },
                        "reason": {
                          "description": "Reason is a (brief) reason for the condition's\nlast status change.",
                          "type": "string"
                        },
                        "status": {
                          "description": "Status is the status of the condition. One of True,\nFalse, Unknown.",
                          "type": "string"
                        },
                        "type": {
                          "description": "Type is the type of the cluster condition.",
                          "type": "string"
                        }
                      },
                      "type": "object"
                    },
                    "type": "array"
                  },
                  "phase": {
                    "description": "Latest observed overall state",
                    "type": "string"
                  }
                },
                "type": "object"
              }
            },
            "type": "object"
          }
        },
        "served": true,
        "storage": true,
        "subresources": {
          "status": {}
        }
      }
    ]
  },
  "status": {
    "acceptedNames": {
      "kind": "",
      "plural": ""
    },
    "conditions": [],
    "storedVersions": []
  }
}
1.8.6.2.2. すべての MultiClusterEngine をクエリーする
GET /apis/multicluster.openshift.io/v1alpha1/multiclusterengines
1.8.6.2.2.1. 説明

詳細については、マルチクラスターエンジンに問い合わせてください。

1.8.6.2.2.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

1.8.6.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.6.2.2.4. 消費
  • operator/yaml
1.8.6.2.2.5. タグ
  • multiclusterengines.multicluster.openshift.io
1.8.6.2.3. MultiClusterEngine Operator の削除
DELETE /apis/multicluster.openshift.io/v1alpha1/multiclusterengines/{name}
1.8.6.2.3.1. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Path

name
必須

削除するマルチクラスターエンジンの名前。

string

1.8.6.2.3.2. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.6.2.3.3. タグ
  • multiclusterengines.multicluster.openshift.io

1.8.6.3. 定義

1.8.6.3.1. MultiClusterEngine
名前説明スキーマ

apiVersion
必須

MultiClusterEngines のバージョン管理されたスキーマ。

string

kind
必須

REST リソースを表す文字列の値

string

metadata
必須

リソースを定義するルールを記述します。

object

spec
必須

MultiClusterEngineSpec は、MultiClusterEngine の望ましい状態を定義します。

仕様のリスト を参照してください。

1.8.6.3.2. 仕様のリスト
名前説明スキーマ

nodeSelector
任意

nodeselectors を設定します。

map[string]string

imagePullSecret
任意

MultiClusterEngine オペランドおよびエンドポイントイメージにアクセスするためのプルシークレットをオーバーライドします。

string

tolerations
任意

許容範囲により、すべてのコンポーネントがあらゆる Taint を許容します。

[]corev1.Toleration

targetNamespace
任意

MCE リソースが配置される場所。

string

1.8.7. Placements API (v1beta1)

1.8.7.1. 概要

このドキュメントは、Kubernetes のマルチクラスターエンジンの配置リソースに関するものです。Placement リソースには、create、query、delete、update の 4 つの要求を使用できます。

1.8.7.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.8.7.1.2. タグ
  • cluster.open-cluster-management.io: Placement を作成して管理します。

1.8.7.2. パス

1.8.7.2.1. 全 Placement のクエリー
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements
1.8.7.2.1.1. 説明

Placement に対してクエリーを実行して詳細を確認します。

1.8.7.2.1.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

1.8.7.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.7.2.1.4. 消費
  • placement/yaml
1.8.7.2.1.5. タグ
  • cluster.open-cluster-management.io
1.8.7.2.2. Placement の作成
POST /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements
1.8.7.2.2.1. 説明

Placement を作成します。

1.8.7.2.2.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Body

body
必須

作成する placement を記述するパラメーター

Placement

1.8.7.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.7.2.2.4. 消費
  • placement/yaml
1.8.7.2.2.5. タグ
  • cluster.open-cluster-management.io
1.8.7.2.2.6. HTTP リクエストの例
1.8.7.2.2.6.1. 要求の body
{
  "apiVersion" : "cluster.open-cluster-management.io/v1beta1",
  "kind" : "Placement",
  "metadata" : {
    "name" : "placement1",
    "namespace": "ns1"
  },
  "spec": {
    "predicates": [
      {
        "requiredClusterSelector": {
          "labelSelector": {
            "matchLabels": {
              "vendor": "OpenShift"
            }
          }
        }
      }
    ]
  },
  "status" : { }
}
1.8.7.2.3. 単一の Placement のクエリー
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements/{placement_name}
1.8.7.2.3.1. 説明

1 つの Placement に対してクエリーを実行して詳細を確認します。

1.8.7.2.3.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

placement_name
必須

問い合わせる Placement の名前

string

1.8.7.2.3.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.7.2.3.4. タグ
  • cluster.open-cluster-management.io
1.8.7.2.4. Placement の削除
DELETE /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placements/{placement_name}
1.8.7.2.4.1. 説明

単一の Placement を削除します。

1.8.7.2.4.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

placement_name
必須

削除する Placement の名前

string

1.8.7.2.4.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.7.2.4.4. タグ
  • cluster.open-cluster-management.io

1.8.7.3. 定義

1.8.7.3.1. Placement
名前説明スキーマ

apiVersion
必須

Placement のバージョンスキーマ

string

kind
必須

REST リソースを表す文字列の値

string

metadata
必須

Placement のメタデータ

object

spec
必須

Placement の仕様

spec

spec

名前説明スキーマ

ClusterSets
任意

ManagedClusters を選択する ManagedClusterSets のサブセット。空白の場合には、Placement namespace にバインドされる ManagedClusterSets から ManagedClusters が選択されます。それ以外の場合は、ManagedClusters がこのサブセットの交差部分から選択され、ManagedClusterSets は Placement namespace にバインドされます。

文字列配列

numberOfClusters
任意

選択する ManagedClusters の必要数

integer (int32)

predicates
任意

ManagedClusters を選択するクラスター述語のサブセット。条件ロジックは OR です。

clusterPredicate アレイ

clusterPredicate

名前説明スキーマ

requiredClusterSelector
任意

ラベルおよびクラスター要求のある ManagedClusters を選択するクラスターセレクター

clusterSelector

clusterSelector

名前説明スキーマ

labelSelector
任意

ラベル別の ManagedClusters のセレクター

object

claimSelector
任意

要求別の ManagedClusters のセレクター

clusterClaimSelector

clusterClaimSelector

名前説明スキーマ

matchExpressions
任意

クラスター要求のセレクター要件のサブセット。条件ロジックは AND です。

< オブジェクト > 配列

1.8.8. PlacementDecisions API (v1beta1)

1.8.8.1. 概要

このドキュメントは、Kubernetes のマルチクラスターエンジンの PlacementDecision リソースを対象としています。PlacementDecision リソースには、create、query、delete、update の 4 つの要求を使用できます。

1.8.8.1.1. URI スキーム

ベースパス: /kubernetes/apis
スキーム: HTTPS

1.8.8.1.2. タグ
  • cluster.open-cluster-management.io: PlacementDecision を作成して管理します。

1.8.8.2. パス

1.8.8.2.1. 全 PlacementDecision のクエリー
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions
1.8.8.2.1.1. 説明

PlacementDecisions に対してクエリーを実行して詳細を確認します。

1.8.8.2.1.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

1.8.8.2.1.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.8.2.1.4. 消費
  • placementdecision/yaml
1.8.8.2.1.5. タグ
  • cluster.open-cluster-management.io
1.8.8.2.2. PlacementDecision の作成
POST /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions
1.8.8.2.2.1. 説明

PlacementDecisions を作成します。

1.8.8.2.2.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

Body

body
必須

作成する PlacementDecision を記述するパラメーター

PlacementDecision

1.8.8.2.2.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.8.2.2.4. 消費
  • placementdecision/yaml
1.8.8.2.2.5. タグ
  • cluster.open-cluster-management.io
1.8.8.2.2.6. HTTP リクエストの例
1.8.8.2.2.6.1. 要求の body
{
  "apiVersion" : "cluster.open-cluster-management.io/v1beta1",
  "kind" : "PlacementDecision",
  "metadata" : {
    "labels" : {
      "cluster.open-cluster-management.io/placement" : "placement1"
    },
    "name" : "placement1-decision1",
    "namespace": "ns1"
  },
  "status" : { }
}
1.8.8.2.3. 単一の PlacementDecision のクエリー
GET /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions/{placementdecision_name}
1.8.8.2.3.1. 説明

1 つの PlacementDecisions に対してクエリーを実行して詳細を確認します。

1.8.8.2.3.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

placementdecision_name
必須

問い合わせる PlacementDecision の名前

string

1.8.8.2.3.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.8.2.3.4. タグ
  • cluster.open-cluster-management.io
1.8.8.2.4. PlacementDecision の削除
DELETE /cluster.open-cluster-management.io/v1beta1/namespaces/{namespace}/placementdecisions/{placementdecision_name}
1.8.8.2.4.1. 説明

単一の PlacementDecision を削除します。

1.8.8.2.4.2. パラメーター
名前説明スキーマ

Header

COOKIE
必須

Authorization: Bearer {ACCESS_TOKEN}。ACCESS_TOKEN はユーザーのアクセストークンに置き換えます。

string

パス

placementdecision_name
必須

削除する PlacementDecision の名前

string

1.8.8.2.4.3. レスポンス
HTTP コード説明スキーマ

200

成功

コンテンツなし

403

アクセス禁止

コンテンツなし

404

リソースが見つからない

コンテンツなし

500

内部サービスエラー

コンテンツなし

503

サービスが利用できない

コンテンツなし

1.8.8.2.4.4. タグ
  • cluster.open-cluster-management.io

1.8.8.3. 定義

1.8.8.3.1. PlacementDecision
名前説明スキーマ

apiVersion
必須

PlacementDecision のバージョンスキーマ

string

kind
必須

REST リソースを表す文字列の値

string

metadata
必須

PlacementDecision のメタデータ

object

1.9. トラブルシューティング

トラブルシューティングガイドをご使用の前に oc adm must-gather コマンドを実行して、詳細およびログを収集し、問題のデバッグ手順を行います。詳細は、must-gather コマンドを実行したトラブルシューティング を参照してください。

また、ロールベースのアクセス権限を確認してください。詳細は、マルチクラスターエンジン Operator のロールベースのアクセス制御 を参照してください。

1.9.1. 文書化されたトラブルシューティング

マルチクラスターエンジン Operator のトラブルシューティングトピックのリストを表示します。

インストール:

インストールタスクに関する主要なドキュメントを表示するには、マルチクラスターエンジンオペレータのインストールとアップグレード を参照してください。

クラスター管理:

クラスターの管理に関する主要なドキュメントを表示するには、クラスターライフサイクルの概要 を参照してください。

1.9.2. must-gather コマンドを実行したトラブルシューティング

トラブルシューティングを開始するには、問題のデバッグを行う must-gather コマンドを実行する場合のトラブルシューティングシナリオについて確認し、このコマンドの使用を開始する手順を参照してください。

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

1.9.2.1. Must-gather のシナリオ

  • シナリオ 1: 文書化されたトラブルシューティング セクションを使用して、問題の解決策がまとめられているかどうかを確認します。本ガイドは、製品の主な機能別に設定されています。

    このシナリオでは、解決策が本書にまとめられているかどうかを、本ガイドで確認します。

  • シナリオ 2: 問題の解決策の手順が文書にまとめられていない場合は、must-gather コマンドを実行し、その出力を使用して問題をデバッグします。
  • シナリオ 3: must-gather コマンドの出力を使用して問題をデバッグできない場合は、出力を Red Hat サポートに共有します。

1.9.2.2. Must-gather の手順

must-gather コマンドの使用を開始するには、以下の手順を参照してください。

  1. must-gather コマンドについて確認し、Red Hat OpenShift Container Platform の クラスターに関するデータの収集 に必要な前提条件をインストールします。
  2. クラスターにログインします。通常のユースケースでは、engine クラスターにログインして、must-gather を実行する必要があります。

    注記: マネージドクラスターを確認する場合は、cluster-scoped-resources ディレクトリーにある gather-managed.log ファイルを検索します。

    <your-directory>/cluster-scoped-resources/gather-managed.log>

    JOINED および AVAILABLE 列に True が設定されていないマネージドクラスターがないかを確認します。must-gather コマンドは、ステータスが True として関連付けられていないクラスター上で、実行できます。

  3. データとディレクトリーの収集に使用される Kubernetes イメージのマルチクラスターエンジンを追加します。以下のコマンドを実行して、出力用にイメージとディレクトリーを挿入します。

    oc adm must-gather --image=registry.redhat.io/multicluster-engine/must-gather-rhel8:v2.2 --dest-dir=<directory>
  4. 指定したディレクトリーに移動し、以下のレベルに整理されている出力を確認します。

    • ピアレベル 2 つ: cluster-scoped-resourcesnamespace のリソース
    • それぞれに対するサブレベル: クラスタースコープおよび namespace スコープの両方のリソースに対するカスタムリソース定義の API グループ。
    • それぞれに対する次のレベル: kind でソートされた YAML ファイル

1.9.2.3. 非接続環境での must-gather

非接続環境で must-gather コマンドを実行するには、次の手順を実行します。

  1. 非接続環境では、Red Hat Operator のカタログイメージをミラーレジストリーにミラーリングします。詳細は、ネットワーク切断状態でのインストール を参照してください。
  2. 次のコマンドを実行して、ミラーレジストリーからイメージを参照するログを抽出します。
REGISTRY=registry.example.com:5000
IMAGE=$REGISTRY/multicluster-engine/must-gather-rhel8@sha256:ff9f37eb400dc1f7d07a9b6f2da9064992934b69847d17f59e385783c071b9d8

oc adm must-gather --image=$IMAGE --dest-dir=./data

ここ で製品チームのバグを開くことができます。

1.9.3. 既存のクラスターに Day-2 ノードを追加するトラブルシューティングが保留中のユーザー操作で失敗する

インストール時に、ゼロタッチプロビジョニングまたはホストのインベントリー作成メソッドで Kubernetes Operator のマルチクラスターエンジンが作成した既存のクラスターにノードを追加したり、スケールアウトできません。インストールプロセスは、検出フェーズでは正しく機能しますが、インストールフェーズでは失敗します。

ネットワークの設定に失敗しています。統合コンソールのハブクラスターから、Pending のユーザーアクションが表示されます。説明から、再起動ステップで失敗していることがわかります。

インストールするホストで実行されているエージェントは情報を報告できないため、失敗に関するエラーメッセージはあまり正確ではありません。

1.9.3.1. 現象: Day 2 ワーカーのインストールが失敗する

検出フェーズの後、ホストは再起動してインストールを続行しますが、ネットワークを設定できません。以下の現象およびメッセージを確認します。

  • 統合コンソールのハブクラスターから、追加ノード上で Pending ユーザーアクションがないか、Rebooting インジケーターが付いているかどうかを確認します。

    This host is pending user action. Host timed out when pulling ignition. Check the host console... Rebooting
  • Red Hat OpenShift Container Platform 設定のマネージドクラスターから、既存のクラスターの MachineConfig を確認します。MachineConfig のいずれかが次のディレクトリーにファイルを作成しているかどうかを確認します。

    • /sysroot/etc/NetworkManager/system-connections/
    • /sysroot/etc/sysconfig/network-scripts/
  • インストールするホストの端末から、障害が発生したホストに次のメッセージが表示されているかどうかを確認します。journalctl を使用してログメッセージを確認できます。
info: networking config is defined in the real root

info: will not attempt to propagate initramfs networking

ログに最後のメッセージが表示された場合、現象 に記載されているフォルダーで既存のネットワーク設定がすでに見つかっているため、ネットワーク設定は伝播されません。

1.9.3.2. 問題の解決: ネットワーク設定をマージするノードを再作成します。

インストール中に適切なネットワーク設定を使用するには、次のタスクを実行します。

  1. ハブクラスターからノードを削除します。
  2. 同じようにノードをインストールするには、前のプロセスを繰り返します。
  3. 次のアノテーションを使用してノードの BareMetalHost オブジェクトを作成します。
"bmac.agent-install.openshift.io/installer-args": "[\"--append-karg\", \"coreos.force_persist_ip\"]"

ノードがインストールを開始します。検出フェーズの後、ノードは既存のクラスター上の変更と初期設定の間でネットワーク設定をマージします。

1.9.4. インストールステータスがインストールまたは保留中の状態のトラブルシューティング

マルチクラスターエンジン Operator をインストールするときに、MultiClusterEngineInstalling フェーズのままであるか、複数の Pod が Pending ステータスを維持します。

1.9.4.1. 現象: Pending 状態で止まる

MultiClusterEngine をインストールしてから、MultiClusterEngine リソースの status.components フィールドからのコンポーネントの 1 つ以上で ProgressDeadlineExceeded と報告したまま 10 分以上経過しています。クラスターのリソース制約が問題となっている場合があります。

MultiClusterEngine がインストールされた namespace で Pod を確認します。以下のようなステータスとともに Pending と表示される場合があります。

reason: Unschedulable
message: '0/6 nodes are available: 3 Insufficient cpu, 3 node(s) had taint {node-role.kubernetes.io/master:
        }, that the pod didn't tolerate.'

このような場合には、ワーカーノードにはクラスターでの製品実行に十分なリソースがありません。

1.9.4.2. 問題の解決: ワーカーノードのサイズの調整

この問題が発生した場合は、大規模なワーカーノードまたは複数のワーカーノードでクラスターを更新する必要があります。クラスターのサイジングのガイドラインについては、クラスターのサイジング を参照してください。

1.9.5. 再インストールに失敗する場合のトラブルシューティング

マルチクラスターエンジン Operator を再インストールすると、Pod が起動しません。

1.9.5.1. 現象: 再インストールの失敗

マルチクラスターエンジン Operator をインストールした後に Pod が起動しない場合は、マルチクラスターエンジン Operator の以前のインストールからの項目が、アンインストール時に正しく削除されなかったことが原因であることが多いです。

Pod はこのような場合に、インストールプロセスの完了後に起動しません。

1.9.5.2. 問題の解決: 再インストールの失敗

この問題が発生した場合は、以下の手順を実行します。

  1. アンインストール の手順に従い、現在のコンポーネントを削除し、アンインストールプロセスを実行します。
  2. Helm のインストール の手順に従い、Helm CLI バイナリーバージョン 3.2.0 以降をインストールします。
  3. oc コマンドが実行できるように、Red Hat OpenShift Container Platform CLI が設定されていることを確認してください。oc コマンドの設定方法は、Red Hat OpenShift Container Platform ドキュメントの OpenShift CLI の使用方法 を参照してください。
  4. 以下のスクリプトをファイルにコピーします。

    #!/bin/bash
    MCE_NAMESPACE=<namespace>
    oc delete multiclusterengine --all
    oc delete apiservice v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io
    oc delete crd discoveredclusters.discovery.open-cluster-management.io discoveryconfigs.discovery.open-cluster-management.io
    oc delete mutatingwebhookconfiguration ocm-mutating-webhook managedclustermutators.admission.cluster.open-cluster-management.io
    oc delete validatingwebhookconfiguration ocm-validating-webhook
    oc delete ns $MCE_NAMESPACE

    スクリプト内の <namespace> をマルチクラスターエンジン Operator がインストールされた namespace の名前に置き換えます。namespace が消去され削除されるため、正しい namespace を指定するようにしてください。

  5. スクリプトを実行して、アーティファクトを以前のインストールから削除します。
  6. インストールを実行します。ネットワーク接続時のオンラインインストール を参照してください。

1.9.6. オフラインクラスターのトラブルシューティング

クラスターのステータスがオフラインと表示される一般的な原因がいくつかあります。

1.9.6.1. 現象: クラスターのステータスがオフライン状態である

クラスターの作成手順を完了したら、Red Hat Advanced Cluster Management コンソールからアクセスできず、クラスターのステータスが offline と表示されます。

1.9.6.2. 問題の解決: クラスターのステータスがオフライン状態になっている

  1. マネージドクラスターが利用可能かどうかを確認します。これは、Red Hat Advanced Cluster Management コンソールの Clusters エリアで確認できます。

    利用不可の場合は、マネージドクラスターの再起動を試行します。

  2. マネージドクラスターのステータスがオフラインのままの場合は、以下の手順を実行します。

    1. ハブクラスターで oc get managedcluster <cluster_name> -o yaml コマンドを実行します。<cluster_name> は、クラスター名に置き換えます。
    2. status.conditions セクションを見つけます。
    3. type: ManagedClusterConditionAvailable のメッセージを確認して、問題を解決します。

1.9.7. マネージドクラスターのインポート失敗に関するトラブルシューティング

クラスターのインポートに失敗した場合は、クラスターのインポートが失敗した理由を判別するためにいくつかの手順を実行できます。

1.9.7.1. 現象: インポートされたクラスターを利用できない

クラスターをインポートする手順を完了すると、コンソールからクラスターにアクセスできなくなります。

1.9.7.2. 問題の解決: インポートされたクラスターが利用できない

インポートの試行後にインポートクラスターが利用できない場合には、いくつかの理由があります。クラスターのインポートに失敗した場合は、インポートに失敗した理由が見つかるまで以下の手順を実行します。

  1. ハブクラスターで、次のコマンドを実行して、インポートコントローラーが実行していることを確認します。

    kubectl -n multicluster-engine get pods -l app=managedcluster-import-controller-v2

    実行中の Pod が 2 つ表示されるはずです。Pod のいずれかが実行されていない場合には、以下のコマンドを実行してログを表示して理由を判別します。

    kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1
  2. ハブクラスターで次のコマンドを実行して、マネージドクラスターのインポートシークレットがインポートコントローラーによって正常に生成されたかどうかを確認します。

    kubectl -n <managed_cluster_name> get secrets <managed_cluster_name>-import

    インポートシークレットが存在しない場合は、以下のコマンドを実行してインポートコントローラーのログエントリーを表示し、作成されていない理由を判断します。

    kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 --tail=-1 | grep importconfig-controller
  3. ハブクラスターで、マネージドクラスターが local-cluster であるか、Hive によってプロビジョニングされているか、自動インポートシークレットがある場合は、次のコマンドを実行して、マネージドクラスターのインポートステータスを確認します。

    kubectl get managedcluster <managed_cluster_name> -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}' | grep ManagedClusterImportSucceeded

    ManagedClusterImportSucceededtrue でない場合には、コマンドの結果で失敗の理由が表示されます。

  4. マネージドクラスターの Klusterlet ステータスが degraded 状態でないかを確認します。Klusterlet のパフォーマンスが低下した理由を特定するには、degraded 状態にある Klusterlet のトラブルシューティング を参照してください。

1.9.8. クラスターの再インポートが不明な権限エラーで失敗する

マネージドクラスターをマルチクラスターエンジン Operator に再インポートするときに問題が発生した場合は、手順に従って問題をトラブルシューティングします。

1.9.8.1. 現象: クラスターの再インポートが不明な権限エラーで失敗する

マルチクラスターエンジン Operator を使用して OpenShift Container Platform クラスターをプロビジョニングした後に、API サーバー証明書を変更したり、OpenShift Container Platform クラスターに追加したりすると、x509: certificate signed by unknown authority エラーでクラスターの再インポートが失敗する場合があります。

1.9.8.2. 問題の特定: クラスターの再インポートが不明な権限エラーで失敗する

マネージドクラスターの再インポートに失敗した後、次のコマンドを実行して、マルチクラスターエンジン Operator ハブクラスターのインポートコントローラーログを取得します。

kubectl -n multicluster-engine logs -l app=managedcluster-import-controller-v2 -f

次のエラーログが表示される場合は、マネージドクラスター API サーバーの証明書が変更されている可能性があります。

ERROR Reconciler error {"controller": "clusterdeployment-controller", "object": {"name":"awscluster1","namespace":"awscluster1"}, "namespace": "awscluster1", "name": "awscluster1", "reconcileID": "a2cccf24-2547-4e26-95fb-f258a6710d80", "error": "Get \"https://api.awscluster1.dev04.red-chesterfield.com:6443/api?timeout=32s\": x509: certificate signed by unknown authority"}

マネージドクラスター API サーバー証明書が変更されたかどうかを確認するには、次の手順を実行します。

  1. 次のコマンドを実行して、your-managed-cluster-name をマネージドクラスターの名前に置き換えて、マネージドクラスターの名前を指定します。

    cluster_name=<your-managed-cluster-name>
  2. 次のコマンドを実行して、マネージドクラスター kubeconfig シークレット名を取得します。

    kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')
  3. 次のコマンドを実行して、kubeconfig を新しいファイルにエクスポートします。

    oc -n ${cluster_name} get secret ${kubeconfig_secret_name} -ojsonpath={.data.kubeconfig} | base64 -d > kubeconfig.old
    export KUBECONFIG=kubeconfig.old
  4. 次のコマンドを実行して、kubeconfig を使用してマネージドクラスターから namespace を取得します。

    oc get ns

次のメッセージのようなエラーが表示された場合は、クラスター API サーバーの証明書が変更になっており、kubeconfig ファイルが無効です。

Unable to connect to the server: x509: certificate signed by unknown authority

1.9.8.3. 問題の解決: クラスターの再インポートが不明な権限エラーで失敗する

マネージドクラスター管理者は、マネージドクラスター用に新しい有効な kubeconfig ファイルを作成する必要があります。

新しい kubeconfig を作成したら、次の手順を実行して、マネージドクラスターの新しい kubeconfig を更新します。

  1. 次のコマンドを実行して、kubeconfig ファイルパスとクラスター名を設定します。<path_to_kubeconfig> を新しい kubeconfig ファイルへのパスに置き換えます。<managed_cluster_name> をマネージドクラスターの名前に置き換えます。

    cluster_name=<managed_cluster_name>
    kubeconfig_file=<path_to_kubeconfig>
  2. 次のコマンドを実行して、新しい kubeconfig をエンコードします。

    kubeconfig=$(cat ${kubeconfig_file} | base64 -w0)

    注記: macOS では、代わりに次のコマンドを実行します。

    kubeconfig=$(cat ${kubeconfig_file} | base64)
  3. 次のコマンドを実行して、JSON パッチ kubeconfig を定義します。

    kubeconfig_patch="[\{\"op\":\"replace\", \"path\":\"/data/kubeconfig\", \"value\":\"${kubeconfig}\"}, \{\"op\":\"replace\", \"path\":\"/data/raw-kubeconfig\", \"value\":\"${kubeconfig}\"}]"
  4. 次のコマンドを実行して、マネージドクラスターから管理者の kubeconfig シークレット名を取得します。

    kubeconfig_secret_name=$(oc -n ${cluster_name} get clusterdeployments ${cluster_name} -ojsonpath='{.spec.clusterMetadata.adminKubeconfigSecretRef.name}')
  5. 次のコマンドを実行して、管理者の kubeconfig シークレットに新しい kubeconfig を適用します。

    oc -n ${cluster_name} patch secrets ${kubeconfig_secret_name} --type='json' -p="${kubeconfig_patch}"

1.9.9. Pending Import ステータスのクラスターのトラブルシューティング

クラスターのコンソールで継続的に Pending import と表示される場合は、以下の手順を実行して問題をトラブルシューティングしてください。

1.9.9.1. 現象: ステータスが Pending Import クラスター

Red Hat Advanced Cluster Management コンソールを使用してクラスターをインポートした後に、コンソールで、クラスターのステータスが Pending import と表示されます。

1.9.9.2. 問題の特定: ステータスが Pending Import クラスター

  1. マネージドクラスターで以下のコマンドを実行し、問題のある Kubernetes Pod 名を表示します。

    kubectl get pod -n open-cluster-management-agent | grep klusterlet-registration-agent
  2. マネージドクラスターで以下のコマンドを実行し、エラーのログエントリーを探します。

    kubectl logs <registration_agent_pod> -n open-cluster-management-agent

    registration_agent_pod は、手順 1 で特定した Pod 名に置き換えます。

  3. 返された結果に、ネットワーク接続の問題があったと示すテキストがないかどうかを検索します。たとえば、no such host です。

1.9.9.3. 問題の解決: ステータスが Pending Import クラスター

  1. ハブクラスターで以下のコマンドを実行して、問題のあるポート番号を取得します。

    oc get infrastructure cluster -o yaml | grep apiServerURL
  2. マネージドクラスターのホスト名が解決でき、ホストおよびポートへの送信接続が機能していることを確認します。

    マネージドクラスターで通信が確立できない場合は、クラスターのインポートが完了していません。マネージドクラスターのクラスターステータスは、Pending import になります。

1.9.10. 証明書を変更した後のインポート済みクラスターのオフラインでのトラブルシューティング

カスタムの apiserver 証明書のインストールはサポートされますが、証明書情報を変更する前にインポートされたクラスターの 1 つまたは複数でステータスが offline になる可能性があります。

1.9.10.1. 現象: 証明書の変更後にクラスターがオフラインになる

証明書シークレットを更新する手順を完了すると、オンラインだった 1 つ以上のクラスターがコンソールに offline ステータスを表示するようになります。

1.9.10.2. 問題の特定: 証明書の変更後にクラスターがオフラインになる

カスタムの API サーバー証明書の情報を更新すると、インポートされ、新しい証明書が追加される前に稼働していたクラスターのステータスが offline になります。

オフラインのマネージドクラスターの open-cluster-management-agent namespace にある Pod のログで、証明書に問題があるとのエラーが見つかります。以下の例のようなエラーがログに表示されます。

work-agent のログ:

E0917 03:04:05.874759       1 manifestwork_controller.go:179] Reconcile work test-1-klusterlet-addon-workmgr fails with err: Failed to update work status with err Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:05.874887       1 base_controller.go:231] "ManifestWorkAgent" controller failed to sync "test-1-klusterlet-addon-workmgr", err: Failed to update work status with err Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks/test-1-klusterlet-addon-workmgr": x509: certificate signed by unknown authority
E0917 03:04:37.245859       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManifestWork: failed to list *v1.ManifestWork: Get "api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/namespaces/test-1/manifestworks?resourceVersion=607424": x509: certificate signed by unknown authority

registration-agent のログ:

I0917 02:27:41.525026       1 event.go:282] Event(v1.ObjectReference{Kind:"Namespace", Namespace:"open-cluster-management-agent", Name:"open-cluster-management-agent", UID:"", APIVersion:"v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'ManagedClusterAvailableConditionUpdated' update managed cluster "test-1" available condition to "True", due to "Managed cluster is available"
E0917 02:58:26.315984       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1beta1.CertificateSigningRequest: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority
E0917 02:58:26.598343       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true": x509: certificate signed by unknown authority
E0917 02:58:27.613963       1 reflector.go:127] k8s.io/client-go@v0.19.0/tools/cache/reflector.go:156: Failed to watch *v1.ManagedCluster: failed to list *v1.ManagedCluster: Get "https://api.aaa-ocp.dev02.location.com:6443/apis/cluster.management.io/v1/managedclusters?allowWatchBookmarks=true&fieldSelector=metadata.name%3Dtest-1&resourceVersion=607408&timeout=9m33s&timeoutSeconds=573&watch=true"": x509: certificate signed by unknown authority

1.9.10.3. 問題の解決: 証明書の変更後にクラスターがオフラインになる

マネージドクラスターが local-cluster の場合、またはマルチクラスターエンジン Operator を使用してマネージドクラスターが作成された場合に、マネージドクラスターを再インポートするには 10 分以上待つ必要があります。

マネージドクラスターをすぐに再インポートするには、ハブクラスター上のマネージドクラスターのインポートシークレットを削除し、マルチクラスターエンジン Operator を使用して再インポートします。以下のコマンドを実行します。

oc delete secret -n <cluster_name> <cluster_name>-import

<cluster_name> を、インポートするマネージドクラスターの名前に置き換えます。

マルチクラスターエンジン Operator を使用してインポートされたマネージドクラスターを再インポートする場合は、次の手順を実行して、マネージドクラスターを再度インポートします。

  1. ハブクラスターで、次のコマンドを実行してマネージドクラスターのインポートシークレットを再作成します。

    oc delete secret -n <cluster_name> <cluster_name>-import

    <cluster_name> を、インポートするマネージドクラスターの名前に置き換えます。

  2. ハブクラスターで、次のコマンドを実行して、マネージドクラスターのインポートシークレットを YAML ファイルに公開します。

    oc get secret -n <cluster_name> <cluster_name>-import -ojsonpath='{.data.import\.yaml}' | base64 --decode  > import.yaml

    <cluster_name> を、インポートするマネージドクラスターの名前に置き換えます。

  3. マネージドクラスターで、次のコマンドを実行して import.yaml ファイルを適用します。

    oc apply -f import.yaml

注記: 前の手順では、マネージドクラスターがハブクラスターから切り離されません。この手順により、必要なマニフェストがマネージドクラスターの現在の設定 (新しい証明書情報を含む) で更新されます。

1.9.11. クラスターのステータスが offline から available に変わる場合のトラブルシューティング

マネージドクラスターのステータスは、環境またはクラスターを手動で変更することなく、offlineavailable との間で切り替わります。

1.9.11.1. 現象: クラスターのステータスが offline から available に変わる

マネージドクラスターからハブクラスターへのネットワーク接続が不安定な場合に、マネージドクラスターのステータスが offlineavailable との間で順に切り替わると、ハブクラスターにより報告されます。

1.9.11.2. 問題の解決: クラスターのステータスが offline から available に変わる

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

  1. 次のコマンドを入力して、ハブクラスターで ManagedCluster の仕様を編集します。

    oc edit managedcluster <cluster-name>

    cluster-name は、マネージドクラスターの名前に置き換えます。

  2. ManagedCluster 仕様の leaseDurationSeconds の値を増やします。デフォルト値は 5 分ですが、ネットワークの問題がある状態で接続を維持するには十分でない場合があります。リースの時間を長く指定します。たとえば、設定を 20 分に増やします。

1.9.12. VMware vSphere でのクラスター作成のトラブルシューティング

VMware vSphere で Red Hat OpenShift Container Platform クラスターを作成する時に問題が発生した場合は、以下のトラブルシューティング情報を参照して、この情報のいずれかが問題に対応しているかどうかを確認します。

注記: VMware vSphere でクラスター作成プロセスが失敗した場合に、リンクが有効にならずログが表示されないことがあります。上記が発生する場合は、hive-controllers Pod のログを確認して問題を特定できます。hive-controllers ログは hive namespace にあります。

1.9.12.1. 証明書 の IP SAN エラーでマネージドクラスターの作成に失敗する

1.9.12.1.1. 現象: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書 IP SAN エラーを示すエラーメッセージでクラスターに問題が発生します。

1.9.12.1.2. 問題の特定: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する

マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。

time="2020-08-07T15:27:55Z" level=error msg="Error: error setting up new vSphere SOAP client: Post https://147.1.1.1/sdk: x509: cannot validate certificate for xx.xx.xx.xx because it doesn't contain any IP SANs"
time="2020-08-07T15:27:55Z" level=error
1.9.12.1.3. 問題の解決: 証明書の IP SAN エラーでマネージドクラスターの作成に失敗する

認証情報の IP アドレスではなく VMware vCenter サーバー完全修飾ホスト名を使用します。また、VMware vCenter CA 証明書を更新して、IP SAN を組み込むこともできます。

1.9.12.2. 不明な証明局のエラーでマネージドクラスターの作成に失敗する

1.9.12.2.1. 現象: 不明な証明局のエラーでマネージドクラスターの作成に失敗する

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書が不明な証明局により署名されているのでクラスターに問題が発生します。

1.9.12.2.2. 問題の特定: 不明な証明局のエラーでマネージドクラスターの作成に失敗する

マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。

Error: error setting up new vSphere SOAP client: Post https://vspherehost.com/sdk: x509: certificate signed by unknown authority"
1.9.12.2.3. 問題の解決: 不明な証明局のエラーでマネージドクラスターの作成に失敗する

認証情報の作成時に認証局の正しい証明書が入力されていることを確認します。

1.9.12.3. 証明書の期限切れでマネージドクラスターの作成に失敗する

1.9.12.3.1. 現象: 証明書の期限切れでマネージドクラスターの作成に失敗する

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、証明書の期限が切れているか、有効にしていないため、クラスターに問題が発生します。

1.9.12.3.2. 問題の特定: 証明書の期限切れでマネージドクラスターの作成に失敗する

マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。

x509: certificate has expired or is not yet valid
1.9.12.3.3. 問題の解決: 証明書の期限切れでマネージドクラスターの作成に失敗する

ESXi ホストの時間が同期されていることを確認します。

1.9.12.4. タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する

1.9.12.4.1. 現象: タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、タグ付けの使用に十分な権限がないためクラスターに問題が発生します。

1.9.12.4.2. 問題の特定: タグ付けの権限が十分にないためにマネージドクラスターの作成に失敗する

マネージドクラスターのデプロイメントに失敗して、デプロイメントログに以下のエラーが返されます。

time="2020-08-07T19:41:58Z" level=debug msg="vsphere_tag_category.category: Creating..."
time="2020-08-07T19:41:58Z" level=error
time="2020-08-07T19:41:58Z" level=error msg="Error: could not create category: POST https://vspherehost.com/rest/com/vmware/cis/tagging/category: 403 Forbidden"
time="2020-08-07T19:41:58Z" level=error
time="2020-08-07T19:41:58Z" level=error msg="  on ../tmp/openshift-install-436877649/main.tf line 54, in resource \"vsphere_tag_category\" \"category\":"
time="2020-08-07T19:41:58Z" level=error msg="  54: resource \"vsphere_tag_category\" \"category\" {"
1.9.12.4.3. 問題の解決: タグ付けの権限が十分ではないためマネージドクラスターの作成に失敗する

VMware vCenter が必要とするアカウントの権限が正しいことを確認します。詳細は、インストール時に削除されたイメージレジストリー を参照してください。

1.9.12.5. 無効な dnsVIP でマネージドクラスターの作成に失敗する

1.9.12.5.1. 現象: 無効な dnsVIP でマネージドクラスターの作成に失敗する

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、dnsVIP が無効であるため、クラスターに問題が発生します。

1.9.12.5.2. 問題の特定: 無効な dnsVIP でマネージドクラスターの作成に失敗する

VMware vSphere で新しいマネージドクラスターをデプロイしようとして以下のメッセージが表示されるのは、VMware Installer Provisioned Infrastructure (IPI) をサポートしない以前の OpenShift Container Platform リリースイメージを使用しているためです。

failed to fetch Master Machines: failed to load asset \\\"Install Config\\\": invalid \\\"install-config.yaml\\\" file: platform.vsphere.dnsVIP: Invalid value: \\\"\\\": \\\"\\\" is not a valid IP
1.9.12.5.3. 問題の解決: 無効な dnsVIP でマネージドクラスターの作成に失敗する

VMware インストーラーでプロビジョニングされるインフラストラクチャーをサポートする OpenShift Container Platform で、新しいバージョンのリリースイメージを選択します。

1.9.12.6. ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する

1.9.12.6.1. 現象: ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、間違ったネットワークタイプが指定されているため、クラスターに問題が発生します。

1.9.12.6.2. 問題の特定: ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する

VMware vSphere で新しいマネージドクラスターをデプロイしようとして以下のメッセージが表示されるのは、VMware Installer Provisioned Infrastructure (IPI) をサポートしない以前の OpenShift Container Platform イメージを使用しているためです。

time="2020-08-11T14:31:38-04:00" level=debug msg="vsphereprivate_import_ova.import: Creating..."
time="2020-08-11T14:31:39-04:00" level=error
time="2020-08-11T14:31:39-04:00" level=error msg="Error: rpc error: code = Unavailable desc = transport is closing"
time="2020-08-11T14:31:39-04:00" level=error
time="2020-08-11T14:31:39-04:00" level=error
time="2020-08-11T14:31:39-04:00" level=fatal msg="failed to fetch Cluster: failed to generate asset \"Cluster\": failed to create cluster: failed to apply Terraform: failed to complete the change"
1.9.12.6.3. 問題の解決: ネットワークタイプが正しくないためマネージドクラスターの作成に失敗する

指定の VMware クラスターに対して有効な VMware vSphere ネットワークタイプを選択します。

1.9.12.7. ディスクの変更処理のエラーでマネージドクラスターの作成に失敗する

1.9.12.7.1. 現象: ディスクの変更処理のエラーが原因でマネージドクラスターの追加に失敗する

VMware vSphere で新規の Red Hat OpenShift Container Platform クラスターを作成した後に、ディスク変更処理時にエラーによりクラスターに問題が発生します。

1.9.12.7.2. 問題の特定: ディスクの変更処理のエラーが原因でマネージドクラスターの追加に失敗する

以下のようなメッセージがログに表示されます。

ERROR
ERROR Error: error reconfiguring virtual machine: error processing disk changes post-clone: disk.0: ServerFaultCode: NoPermission: RESOURCE (vm-71:2000), ACTION (queryAssociatedProfile): RESOURCE (vm-71), ACTION (PolicyIDByVirtualDisk)
1.9.12.7.3. 問題の解決: ディスクの変更処理のエラーが原因でマネージドクラスターの追加に失敗する

VMware vSphere クライアントを使用してユーザーに プロファイル駆動型のストレージ権限全権限 を割り当てます。

1.9.13. ステータスが Pending または Failed のクラスターのコンソールでのトラブルシューティング

作成してたクラスターのステータスがコンソールで Pending または Failed と表示されている場合は、以下の手順を実行して問題のトラブルシューティングを実行します。

1.9.13.1. 現象: コンソールでステータスが Pending または Failed のクラスターのトラブルシューティング

コンソールを使用して新しいクラスターを作成した後、クラスターは Pending のステータスを超えて進行しないか、Failed ステータスを表示します。

1.9.13.2. 問題の特定: コンソールでステータスが Pending または Failed のクラスター

クラスターのステータスが Failed と表示される場合は、クラスターの詳細ページに移動して、提供されたログへのリンクに進みます。ログが見つからない場合や、クラスターのステータスが Pending と表示される場合は、以下の手順を実行してログを確認します。

  • 手順 1

    1. ハブクラスターで以下のコマンドを実行し、新規クラスターの namespace に作成した Kubernetes Pod の名前を表示します。

      oc get pod -n <new_cluster_name>

      new_cluster_name は、作成したクラスター名に置き換えます。

    2. 名前に provision の文字列が含まれる Pod が表示されていない場合は、手順 2 に進みます。タイトルに provision が含まれる Pod があった場合は、ハブクラスターで以下のコマンドを実行して、その Pod のログを表示します。

      oc logs <new_cluster_name_provision_pod_name> -n <new_cluster_name> -c hive

      new_cluster_name_provision_pod_name は、作成したクラスター名の後に provision が含まれる Pod 名を指定するように置き換えます。

    3. ログでエラーを検索してください。この問題の原因が解明する場合があります。
  • 手順 2

    名前に provision が含まれる Pod がない場合は、問題がプロセスの初期段階で発生しています。ログを表示するには、以下の手順を実行します。

    1. ハブクラスターで以下のコマンドを実行してください。

      oc describe clusterdeployments -n <new_cluster_name>

      new_cluster_name は、作成したクラスター名に置き換えます。クラスターのインストールログの詳細は、Red Hat OpenShift ドキュメントの インストールログの収集 を参照してください。

    2. リソースの Status.Conditions.MessageStatus.Conditions.Reason のエントリーに問題に関する追加の情報があるかどうかを確認します。

1.9.13.3. 問題の解決: コンソールでステータスが Pending または Failed のクラスター

ログでエラーを特定した後に、エラーの解決方法を決定してから、クラスターを破棄して、作り直してください。

以下の例では、サポート対象外のゾーンを選択している可能性を示すログエラーと、解決に必要なアクションが提示されています。

No subnets provided for zones

クラスターの作成時に、サポートされていないリージョンにあるゾーンを 1 つ以上選択しています。問題解決用にクラスターを再作成する時に、以下のアクションの 1 つを実行します。

  • リージョン内の異なるゾーンを選択します。
  • 他のゾーンをリストしている場合は、サポートを提供しないゾーンを省略します。
  • お使いのクラスターに、別のリージョンを選択します。

ログから問題を特定した後に、クラスターを破棄し、再作成します。

クラスターの作成に関する詳細は、クラスターの作成 を参照してください。

1.9.14. OpenShift Container Platform バージョン 3.11 クラスターのインポートの失敗時のトラブルシューティング

1.9.14.1. 現象: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する

Red Hat OpenShift Container Platform バージョン 3.11 クラスターのインポートを試行すると、以下の内容のようなログメッセージでインポートに失敗します。

customresourcedefinition.apiextensions.k8s.io/klusterlets.operator.open-cluster-management.io configured
clusterrole.rbac.authorization.k8s.io/klusterlet configured
clusterrole.rbac.authorization.k8s.io/open-cluster-management:klusterlet-admin-aggregate-clusterrole configured
clusterrolebinding.rbac.authorization.k8s.io/klusterlet configured
namespace/open-cluster-management-agent configured
secret/open-cluster-management-image-pull-credentials unchanged
serviceaccount/klusterlet configured
deployment.apps/klusterlet unchanged
klusterlet.operator.open-cluster-management.io/klusterlet configured
Error from server (BadRequest): error when creating "STDIN": Secret in version "v1" cannot be handled as a Secret:
v1.Secret.ObjectMeta:
v1.ObjectMeta.TypeMeta: Kind: Data: decode base64: illegal base64 data at input byte 1313, error found in #10 byte of ...|dhruy45="},"kind":"|..., bigger context ...|tye56u56u568yuo7i67i67i67o556574i"},"kind":"Secret","metadata":{"annotations":{"kube|...

1.9.14.2. 問題の特定: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する

この問題は多くの場合、インストールされている kubectl コマンドラインツールのバージョンが 1.11 以前であるために発生します。以下のコマンドを実行して、実行中の kubectl コマンドラインツールのバージョンを表示します。

kubectl version

返されたデータがバージョンが 1.11 以前の場合は、問題の解決: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する に記載される修正のいずれかを実行します。

1.9.14.3. 問題の解決: OpenShift Container Platform バージョン 3.11 クラスターのインポートに失敗する

この問題は、以下のいずれかの手順を実行して解決できます。

  • 最新バージョンの kubectl コマンドラインツールをインストールします。

    1. kubectl ツールの最新バージョンを、Kubernetes ドキュメントの kubectl のインストールとセットアップ からダウンロードします。
    2. kubectl ツールのアップグレード後にクラスターを再度インポートします。
  • import コマンドが含まれるファイルを実行します。

    1. CLI を使用したマネージドクラスターのインポート の手順を開始します。
    2. クラスターの import コマンドを作成する場合には、この import コマンドを import.yaml という名前の YAML ファイルにコピーします。
    3. 以下のコマンドを実行して、ファイルからクラスターを再度インポートします。

      oc apply -f import.yaml

1.9.15. degraded 状態にある Klusterlet のトラブルシューティング

Klusterlet の状態が Degraded の場合は、マネージドクラスターの Klusterlet エージェントの状態を診断しやすくなります。Klusterlet の状態が Degraded になると、マネージドクラスターの Klusterlet エージェントで発生する可能性のあるエラーに対応する必要があります。Klusterlet の degraded の状態が True に設定されている場合は、以下の情報を参照します。

1.9.15.1. 現象: Klusterlet の状態が degraded である

マネージドクラスターで Klusterlet をデプロイした後に、KlusterletRegistrationDegraded または KlusterletWorkDegraded の状態が True と表示されます。

1.9.15.2. 問題の特定: Klusterlet の状態が degraded である

  1. マネージドクラスターで以下のコマンドを実行して、Klusterlet のステータスを表示します

    kubectl get klusterlets klusterlet -oyaml
  2. KlusterletRegistrationDegraded または KlusterletWorkDegraded をチェックして、状態が True に設定されいるかどうかを確認します。記載されている Degraded の状態は、問題の解決 に進みます。

1.9.15.3. 問題の解決: Klusterlet の状態が degraded である

ステータスが Degraded のリストおよびこれらの問題の解決方法を参照してください。

  • KlusterletRegistrationDegraded の状態が True で、この状態の理由が BootStrapSecretMissing の場合は、open-cluster-management-agent namespace にブートストラップのシークレットを作成する必要があります。
  • KlusterletRegistrationDegraded の状態が True と表示され、状態の理由が BootstrapSecretError または BootstrapSecretUnauthorized の場合は、現在のブートストラップシークレットが無効です。現在のブートストラップシークレットを削除して、open-cluster-management-agent namespace で有効なブートストラップシークレットをもう一度作成します。
  • KlusterletRegistrationDegraded および KlusterletWorkDegradedTrue と表示され、状態の理由が HubKubeConfigSecretMissing の場合は、Klusterlet を削除して作成し直します。
  • KlusterletRegistrationDegraded および KlusterletWorkDegradedTrue と表示され、状態の理由が ClusterNameMissingKubeConfigMissingHubConfigSecretError、または HubConfigSecretUnauthorized の場合は、open-cluster-management-agent namespace からハブクラスターの kubeconfig シークレットを削除します。登録エージェントは再度ブートストラップして、新しいハブクラスターの kubeconfig シークレットを取得します。
  • KlusterletRegistrationDegradedTrue と表示され、状態の理由が GetRegistrationDeploymentFailed または UnavailableRegistrationPod の場合は、状態のメッセージを確認して、問題の詳細を取得して解決してみてください。
  • KlusterletWorkDegradedTrue と表示され、状態の理由が GetWorkDeploymentFailed または UnavailableWorkPod の場合は、状態のメッセージを確認して、問題の詳細を取得し、解決してみてください。

1.9.16. クラスターの削除後も namespace が残る

マネージドクラスターを削除すると、通常 namespace はクラスターの削除プロセスの一部として削除されます。まれに namespace は一部のアーティファクトが含まれた状態で残る場合があります。このような場合は、namaspace を手動で削除する必要があります。

1.9.16.1. 現象: クラスターの削除後も namespace が残る

マネージドクラスターの削除後に namespace が削除されません。

1.9.16.2. 問題の解決: クラスターの削除後も namespace が残る

namespace を手作業で削除するには、以下の手順を実行します。

  1. 次のコマンドを実行して、<cluster_name> namespace に残っているリソースのリストを作成します。

    oc api-resources --verbs=list --namespaced -o name | grep -E '^secrets|^serviceaccounts|^managedclusteraddons|^roles|^rolebindings|^manifestworks|^leases|^managedclusterinfo|^appliedmanifestworks'|^clusteroauths' | xargs -n 1 oc get --show-kind --ignore-not-found -n <cluster_name>

    cluster_name は、削除を試みたクラスターの namespace 名に置き換えます。

  2. 以下のコマンドを入力してリストを編集し、ステータスが Delete ではないリストから特定したリソースを削除します。

    oc edit <resource_kind> <resource_name> -n <namespace>

    resource_kind は、リソースの種類に置き換えます。resource_name は、リソース名に置き換えます。namespace は、リソースの namespace に置き換えます。

  3. メタデータで finalizer 属性の場所を特定します。
  4. vi エディターの dd コマンドを使用して、Kubernetes 以外のファイナライザーを削除します。
  5. :wq コマンドを入力し、リストを保存して vi エディターを終了します。
  6. 以下のコマンドを入力して namespace を削除します。

    oc delete ns <cluster-name>

    cluster-name を、削除する namespace の名前に置き換えます。

1.9.17. クラスターのインポート時の auto-import-secret-exists エラー

クラスターのインポートは、auto import secret exists というエラーメッセージで失敗します。

1.9.17.1. 現象: クラスターのインポート時の Auto-import-secret-exists エラー

管理用のハイブクラスターをインポートすると、auto-import-secret already exists というエラーが表示されます。

1.9.17.2. 問題の解決: クラスターのインポート時の Auto-import-secret-exists エラー

この問題は、以前に管理されていたクラスターをインポートしようとすると発生します。これが生じると、クラスターを再インポートしようとすると、シークレットは競合します。

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

  1. 既存の auto-import-secret を手動で削除するには、ハブクラスターで以下のコマンドを実行します。

    oc delete secret auto-import-secret -n <cluster-namespace>

    namespace は、お使いのクラスターの namespace に置き換えます。

  2. ハブクラスターへのターゲットのマネージドクラスターのインポート の手順を使用して、クラスターを再度インポートします。

クラスターがインポートされました。

1.9.18. Troubleshooting missing PlacementDecision after creating Placement

Placement の作成後に PlacementDescision が生成されない場合は、手順に従って問題をトラブルシューティングしてください。

1.9.18.1. 事象: Placement の作成後に PlacementDecision が見つからない

Placement を作成した後、PlacementDescision は自動的に生成されません。

1.9.18.2. 問題の解決: Placement の作成後に PlacementDecision が見つからない

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

  1. 次のコマンドを実行して Placement 条件を確認します。

    kubectl describe placement <placement-name>

    placement-namePlacement の名前に置き換えます。

    出力は次の例のような内容になります。

    Name:         demo-placement
    Namespace:    default
    Labels:       <none>
    Annotations:  <none>
    API Version:  cluster.open-cluster-management.io/v1beta1
    Kind:         Placement
    Status:
      Conditions:
        Last Transition Time:       2022-09-30T07:39:45Z
        Message:                    Placement configurations check pass
        Reason:                     Succeedconfigured
        Status:                     False
        Type:                       PlacementMisconfigured
        Last Transition Time:       2022-09-30T07:39:45Z
        Message:                    No valid ManagedClusterSetBindings found in placement namespace
        Reason:                     NoManagedClusterSetBindings
        Status:                     False
        Type:                       PlacementSatisfied
      Number Of Selected Clusters:  0
  2. PlacementMisconfigured および PlacementSatisfiedStatus の出力を確認します。

    • PlacementMisconfigured Status が true の場合、Placement に設定エラーがあります。設定エラーの詳細とその解決方法については、含まれているメッセージを確認してください。
    • PlacementSatisfied Status が false の場合、Placement を満たすマネージドクラスターはありません。詳細とエラーの解決方法については、含まれているメッセージを確認してください。前の例では、placement namespace に ManagedClusterSetBindings が見つかりませんでした。
  3. Events で各クラスターのスコアを確認して、スコアの低い一部のクラスターが選択されていない理由を確認できます。出力は次の例のような内容になります。

    Name:         demo-placement
    Namespace:    default
    Labels:       <none>
    Annotations:  <none>
    API Version:  cluster.open-cluster-management.io/v1beta1
    Kind:         Placement
    Events:
      Type    Reason          Age   From                 Message
      ----    ------          ----  ----                 -------
      Normal  DecisionCreate  2m10s   placementController  Decision demo-placement-decision-1 is created with placement demo-placement in namespace default
      Normal  DecisionUpdate  2m10s   placementController  Decision demo-placement-decision-1 is updated with placement demo-placement in namespace default
      Normal  ScoreUpdate     2m10s   placementController  cluster1:0 cluster2:100 cluster3:200
      Normal  DecisionUpdate  3s      placementController  Decision demo-placement-decision-1 is updated with placement demo-placement in namespace default
      Normal  ScoreUpdate     3s      placementController  cluster1:200 cluster2:145 cluster3:189 cluster4:200

    注記: 配置コントローラーはスコアを割り当て、フィルター処理された ManagedCluster ごとにイベントを生成します。クラスタースコアが変化すると、配置コントローラーは新しいイベントを生成します。

1.9.19. Dell ハードウェアにおけるベアメタルホストの検出エラーのトラブルシューティング

Dell ハードウェアでベアメタルホストの検出が失敗した場合、Integrated Dell Remote Access Controller (iDRAC) が不明な認証局からの証明書を許可しないように設定されている可能性があります。

1.9.19.1. 現象: Dell ハードウェアでのベアメタルホストの検出エラー

ベースボード管理コントローラーを使用してベアメタルホストを検出する手順を完了すると、次のようなエラーメッセージが表示されます。

ProvisioningError 51s metal3-baremetal-controller Image provisioning failed: Deploy step deploy.deploy failed with BadRequestError: HTTP POST https://<bmc_address>/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia returned code 400. Base.1.8.GeneralError: A general error has occurred. See ExtendedInfo for more information Extended information: [
{"Message": "Unable to mount remote share https://<ironic_address>/redfish/boot-<uuid>.iso.", 'MessageArgs': ["https://<ironic_address>/redfish/boot-<uuid>.iso"], "MessageArgs@odata.count": 1, "MessageId": "IDRAC.2.5.RAC0720", "RelatedProperties": ["#/Image"], "RelatedProperties@odata.count": 1, "Resolution": "Retry the operation.", "Severity": "Informational"}
]

1.9.19.2. 問題の解決: Dell ハードウェアでのベアメタルホストの検出の失敗

iDRAC は、不明な認証局からの証明書を受け入れないように設定されています。

この問題を回避するには、次の手順を実行して、ホスト iDRAC のベースボード管理コントローラーで証明書の検証を無効にします。

  1. iDRAC コンソールで、 Configuration > Virtual media > Remote file share に移動します。
  2. Expired or invalid certificate action の値を Yes に変更します。

法律上の通知

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.