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

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

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

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

1.7.1. クラスターライフサイクルのアーキテクチャー
リンクのコピー

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

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

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

次の図は、クラスター管理用の multicluster engine for Kubernetes Operator とともにインストールされるコンポーネントを示しています。

Cluster lifecycle architecture diagram

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

1.7.1.1. ハブクラスター
リンクのコピー

  • マネージドクラスターのインポートコントローラー は、klusterlet Operator をマネージドクラスターにデプロイします。
  • Hive コントローラー は、multicluster engine for Kubernetes Operator を使用して作成したクラスターをプロビジョニングします。また、Hive コントローラーは、multicluster engine for Kubernetes Operator によって作成されたマネージドクラスターを破棄します。
  • クラスターキュレーターコントローラー は、マネージドクラスターの作成またはアップグレード時にクラスターインフラストラクチャー環境を設定するためのプレフックまたはポストフックとして Ansible ジョブを作成します。
  • マネージドクラスターアドオンがハブクラスターで有効になると、その アドオンハブコントローラー がハブクラスターにデプロイされます。アドオンハブコントローラー は、アドオンエージェント をマネージドクラスターにデプロイします。

1.7.1.2. マネージドクラスター
リンクのコピー

  • klusterlet Operator マネージドクラスターに登録およびワークコントローラーをデプロイします。

  • 登録エージェント は、マネージドクラスターとマネージドクラスターアドオンをハブクラスターに登録します。また、登録エージェントは、マネージドクラスターとマネージドクラスターアドオンのステータスを維持します。次のアクセス許可が Clusterrole 内に自動的に作成され、マネージドクラスターがハブクラスターにアクセスできるようになります。

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

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

1.7.2. リリースイメージ
リンクのコピー

クラスターをビルドするときは、リリースイメージで指定されているバージョンの Red Hat OpenShift Container Platform を使用します。デフォルトでは、OpenShift Container Platform は clusterImageSets リソースを使用して、サポートされているリリースイメージのリストを取得します。

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

1.7.2.1. リリースイメージの指定
リンクのコピー

multicluster engine for Kubernetes Operator を使用してプロバイダー上にクラスターを作成する場合は、新しいクラスターに使用するリリースイメージを指定します。リリースイメージを指定するには、次のトピックを参照してください。

1.7.2.1.1. ClusterImageSets の検索
リンクのコピー

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

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

quay.io/openshift-release-dev/ocp-release:4.15.1-x86_64

コンソールには最新バージョンが表示され、最新のリリースイメージを使用してクラスターを作成するのに役立ちます。特定のバージョンのクラスターを作成する必要がある場合は、古いリリースイメージバージョンも利用できます。

注記: コンソールでクラスターを作成する場合は、visible: 'true' ラベルを持つイメージのみを選択できます。ClusterImageSet リソース内のこのラベルの例は、以下の内容で提供されます。4.x.1 は、製品の最新バージョンに置き換えます。 

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: fast
    visible: 'true'
  name: img4.x.1-x86-64-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.x.1-x86_64
Copy to Clipboard Toggle word wrap

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

oc get clusterimageset
Copy to Clipboard Toggle word wrap

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

  • Fast: サポート対象の各 OpenShift Container Platform バージョンのリリースイメージの内、最新バージョンを参照するファイルが含まれます。このフォルダー内のリリースイメージはテストされ、検証されており、サポートされます。

  • Releases: 各 OpenShift Container Platform バージョン (stable、fast、および candidate チャネル) のリリースイメージすべてを参照するファイルが含まれます。

    注記: これらのリリースすべてがテストされおらず、安定版とみなされているわけではありません。

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

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

1.7.2.1.2. ClusterImageSets の設定
リンクのコピー

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

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

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

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

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

OpenShift Container Platform では、デフォルトで複数のアーキテクチャーがサポートされます。以下の clusterImageSet を使用してクラスターをプロビジョニングできます。4.x.0 は、現在サポートされているバージョンに置き換えます。 

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: fast
    visible: 'true'
  name: img4.x.0-multi-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.x.0-multi
Copy to Clipboard Toggle word wrap

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

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

    1. 以下のコマンド例を実行して、Quay リポジトリー から環境内の両方のアーキテクチャーのマニフェストリストをプルします。4.x.1 は、製品の最新バージョンに置き換えます。 

      podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-x86_64
podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-ppc64le
podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-s390x
podman pull quay.io/openshift-release-dev/ocp-release:4.x.1-aarch64
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、イメージを管理するプライベートリポジトリーにログインします。<private-repo> は、リポジトリーへのパスに置き換えます。 

      podman login <private-repo>
      Copy to Clipboard Toggle word wrap

    3. 環境に適用される以下のコマンドを実行して、リリースイメージマニフェストをプライベートリポジトリーに追加します。4.x.1 は、製品の最新バージョンに置き換えます。<private-repo> は、リポジトリーへのパスに置き換えます。 

      podman push quay.io/openshift-release-dev/ocp-release:4.x.1-x86_64 <private-repo>/ocp-release:4.x.1-x86_64
podman push quay.io/openshift-release-dev/ocp-release:4.x.1-ppc64le <private-repo>/ocp-release:4.x.1-ppc64le
podman push quay.io/openshift-release-dev/ocp-release:4.x.1-s390x <private-repo>/ocp-release:4.x.1-s390x
podman push quay.io/openshift-release-dev/ocp-release:4.x.1-aarch64 <private-repo>/ocp-release:4.x.1-aarch64
      Copy to Clipboard Toggle word wrap

    4. 次のコマンドを実行して、新しい情報のマニフェストを作成します。 

      podman manifest create mymanifest
      Copy to Clipboard Toggle word wrap

    5. 次のコマンドを実行して、両方のリリースイメージへの参照をマニフェストリストに追加します。4.x.1 は、製品の最新バージョンに置き換えます。<private-repo> は、リポジトリーへのパスに置き換えます。 

      podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-x86_64
podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-ppc64le
podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-s390x
podman manifest add mymanifest <private-repo>/ocp-release:4.x.1-aarch64
      Copy to Clipboard Toggle word wrap

    6. 次のコマンドを実行して、マニフェストリスト内のリストを既存のマニフェストとマージします。<private-repo> は、リポジトリーへのパスに置き換えます。4.x.1 は、最新バージョンに置き換えます。 

      podman manifest push mymanifest docker://<private-repo>/ocp-release:4.x.1
      Copy to Clipboard Toggle word wrap

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

    1. 以下の例のような情報を含む YAML ファイルを作成します。<private-repo> は、リポジトリーへのパスに置き換えます。4.x.1 は、最新バージョンに置き換えます。 

      apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: fast
    visible: "true"
  name: img4.x.1-appsub
spec:
  releaseImage: <private-repo>/ocp-release:4.x.1
      Copy to Clipboard Toggle word wrap

    2. ハブクラスターで以下のコマンドを実行し、変更を適用します。<file-name> を、先の手順で作成した YAML ファイルの名前に置き換えます。 

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

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

1.7.2.1.4. 関連情報
リンクのコピー

1.7.2.2. 接続環境におけるリリースイメージのカスタムリストの管理
リンクのコピー

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

  1. acm-hive-openshift-releases GitHub をフォークします。
  2. クラスターの作成時に使用できるイメージの YAML ファイルを追加します。Git コンソールまたはターミナルを使用して、イメージを ./clusterImageSets/stable/ または ./clusterImageSets/fast/ ディレクトリーに追加します。
  3. cluster-image-set-git-repo という名前の multicluster-engine namespace に ConfigMap を作成します。次の例を参照してください。ただし、2.x は 2.7 に置き換えてください。 
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.x>
  gitRepoPath: clusterImageSets
  channel: <fast or stable>
Copy to Clipboard Toggle word wrap

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

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

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

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

    oc get clusterImageSets
oc delete clusterImageSet <clusterImageSet_NAME>
    Copy to Clipboard Toggle word wrap

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

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

1.7.2.3. 非接続環境におけるリリースイメージのカスタムリストの管理
リンクのコピー

場合によっては、ハブクラスターにインターネット接続がないときに、リリースイメージのカスタムリストを管理する必要があります。リリースイメージの独自のカスタムリストを作成しておくと、クラスターの作成時にそのリストを使用できます。非接続環境で利用可能なリリースイメージを管理するには、次の手順を実行します。

  1. オンラインのシステムの場合は、acm-hive-openshift-releases GitHub リポジトリー に移動して、利用可能なクラスターイメージセットにアクセスします。
  2. clusterImageSets ディレクトリーを、非接続の multicluster engine 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: img<4.x.x>-x86-64-appsub
spec:
  releaseImage: IMAGE_REGISTRY_IPADDRESS_or__DNSNAME/REPO_PATH/ocp-release@sha256:073a4e46289be25e2a05f5264c8f1d697410db66b960c9ceeddebd1c61e58717
    Copy to Clipboard Toggle word wrap
  6. YAML ファイルで参照されているオフラインイメージレジストリーにイメージがロードされていることを確認します。

  7. 次のコマンドを実行して、イメージダイジェストを取得します。 

    oc adm release info <tagged_openshift_release_image> | grep "Pull From"
    Copy to Clipboard Toggle word wrap

    <tagged_openshift_release_image> は、サポートされている OpenShift Container Platform バージョンのタグ付きイメージに置き換えます。以下の出力例を参照してください。 

    Pull From: quay.io/openshift-release-dev/ocp-release@sha256:69d1292f64a2b67227c5592c1a7d499c7d00376e498634ff8e1946bc9ccdddfe
    Copy to Clipboard Toggle word wrap

    イメージタグとダイジェストの詳細は、イメージストリームでのイメージの参照 を参照してください。

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

    oc create -f <clusterImageSet_FILE>
    Copy to Clipboard Toggle word wrap

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

    oc create -f img4.11.9-x86_64.yaml
    Copy to Clipboard Toggle word wrap

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

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

1.7.2.4. 利用可能なリリースイメージの同期
リンクのコピー

MultiClusterHub Operator を使用してハブクラスターコンポーネントを管理、アップグレード、およびインストールする Red Hat Advanced Cluster Management ハブクラスターがある場合は、リリースイメージのリストを同期して、利用可能な最新バージョンを選択できるようします。リリースイメージは acm-hive-openshift-releases リポジトリーで入手でき、頻繁に更新されます。

1.7.2.4.1. 安定性レベル
リンクのコピー

リリースイメージの安定性には、次の表に示すように 3 つのレベルがあります。

Expand
表1.5 リリースイメージの安定性レベル
カテゴリー説明

candidate

最新のイメージ。テストされていないため、バグがある可能性があります。

fast

部分的にテストされたイメージですが、stable バージョンよりも安定性が低い可能性があります。

stable

完全にテストされたイメージ。これらのイメージは、クラスターを正しくインストールおよび構築できることが確認されています。

1.7.2.4.2. リリースイメージリストの更新
リンクのコピー

Linux または Mac オペレーティングシステムを使用してイメージのリストを更新および同期するには、次の手順を実行します。

  1. インストーラーが管理する acm-hive-openshift-releases サブスクリプションが有効になっている場合は、MultiClusterHub リソースの disableUpdateClusterImageSets の値を true に設定してサブスクリプションを無効にします。
  2. acm-hive-openshift-releases の GitHub リポジトリーをクローンします。

  3. 次のコマンドを実行して、サブスクリプションを削除します。 

    oc delete -f subscribe/subscription-fast
    Copy to Clipboard Toggle word wrap

  4. candidate リリースイメージを同期して表示するには、Linux または Mac オペレーティングシステムを使用して次のコマンドを実行します。 

    make subscribe-candidate
    Copy to Clipboard Toggle word wrap

    約 1 分後に、candidate リリースイメージの最新リストが利用可能になります。

  5. fast リリースイメージを同期して表示するには、以下のコマンドを実行します。 

    make subscribe-fast
    Copy to Clipboard Toggle word wrap

    約 1 分後に、fast リリースイメージの最新リストが利用可能になります。

  6. stable リリースイメージに接続し、Red Hat Advanced Cluster Management ハブクラスターを同期します。Linux または Mac オペレーティングシステムを使用して次のコマンドを実行します。 

    make subscribe-stable
    Copy to Clipboard Toggle word wrap

    利用可能な candidate、fast、および stable リリースイメージのリストが、現在利用可能なイメージで約 1 分ほどで更新されます。

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

  8. 更新の表示を停止するには、次のコマンドを実行して、これらのチャネルのいずれかから登録を解除します。 

    oc delete -f subscribe/subscription-fast
    Copy to Clipboard Toggle word wrap

1.7.3. クラスターの作成
リンクのコピー

multicluster engine Operator を使用して、複数のクラウドプロバイダーに Red Hat OpenShift Container Platform クラスターを作成する方法を説明します。

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

1.7.3.1. CLI を使用したクラスターの作成
リンクのコピー

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

1.7.3.1.1. 前提条件
リンクのコピー

  • クラスターを作成する前に、clusterImageSets リポジトリーのクローンを作成し、ハブクラスターに適用しておく。以下の手順を実行します。

    1. クローンするには、次のコマンドを実行します。ただし、2.x は、multicluster engine Operator のバージョンに置き換えます。 

      git clone https://github.com/stolostron/acm-hive-openshift-releases.git
cd acm-hive-openshift-releases
git checkout origin/backplane-<2.x>
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行して、ハブクラスターに適用します。 
    find clusterImageSets/fast -type d -exec oc apply -f {} \; 2> /dev/null
    Copy to Clipboard Toggle word wrap

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

    注記: Nutanix プラットフォームを使用する場合は、ClusterImageSet リソースの releaseImage に x86_64 アーキテクチャーを使用し、visible のラベル値を 'true' に設定してください。以下の例を参照してください。 

    apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: stable
    visible: 'true'
  name: img4.x.47-x86-64-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.x.47-x86_64
    Copy to Clipboard Toggle word wrap
  • ハブクラスターの KubeAPIServer 証明書検証ストラテジーを確認し、デフォルトの UseAutoDetectedCABundle ストラテジーが機能することを確認する。ストラテジーを手動で変更する必要がある場合は、ハブクラスターの KubeAPIServer 検証ストラテジーの設定 を参照してください。
1.7.3.1.2. ClusterDeployment を使用してクラスターを作成する
リンクのコピー

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

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

1.7.3.1.3. ClusterPool を使用してクラスターを作成
リンクのコピー

ClusterPool は、複数のクラスターを作成するために使用される Hive カスタムリソースでもあります。

Cluster Pools のドキュメントに従って、Hive ClusterPool API でクラスターを作成します。

1.7.3.2. クラスター作成時の追加のマニフェストの設定
リンクのコピー

追加の Kubernetes リソースマニフェストは、クラスター作成のインストールプロセス中に設定できます。これは、ネットワークの設定やロードバランサーの設定など、シナリオの追加マニフェストを設定する必要がある場合に役立ちます。

1.7.3.2.1. 前提条件
リンクのコピー

追加のリソースマニフェストが含まれる config map リソースを指定する ClusterDeployment リソースへの参照を追加する。

注記: ClusterDeployment リソースと config map は同じ namespace にある必要があります。

1.7.3.2.2. 例を使用してクラスター作成中に追加のマニフェストを設定する
リンクのコピー

リソースマニフェストを含む config map を使用して追加のマニフェストを設定する場合は、次の手順を実行します。

  1. 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"
    Copy to Clipboard Toggle word wrap

    注記: サンプル ConfigMap には、別の ConfigMap リソースを含むマニフェストが含まれています。リソースマニフェストの ConfigMap には、data.<resource_name>\.yaml というパターンでリソース設定を追加することにより、複数のキーを含めることができます。

  2. 以下のコマンドを実行してこのファイルを適用します。 

    oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

    リソースマニフェストの ConfigMap を参照して ClusterDeployment を使用して追加のマニフェストを設定する場合は、次の手順を実行します。

  3. YAML ファイルを作成し、次のサンプルコンテンツを追加します。リソースマニフェスト ConfigMap は spec.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>
    Copy to Clipboard Toggle word wrap

  4. 以下のコマンドを実行してこのファイルを適用します。 

    oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

1.7.3.3. Amazon Web Services でのクラスターの作成
リンクのコピー

multicluster engine Operator コンソールを使用して、Amazon Web Services (AWS) 上に Red Hat OpenShift Container Platform クラスターを作成できます。

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

1.7.3.3.1. 前提条件
リンクのコピー

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

  • ハブクラスターをデプロイしている。
  • AWS 認証情報がある。詳細は、Amazon Web Services の認証情報の作成 を参照してください。
  • AWS で設定されたドメインがある。ドメインの設定方法は、AWS アカウントの設定 を参照してください。
  • ユーザー名、パスワード、アクセスキー ID およびシークレットアクセスキーなど、Amazon Web Services (AWS) のログイン認証情報がある。Understanding and Getting Your Security Credentials を参照してください。

  • OpenShift Container Platform イメージのプルシークレットがある。イメージプルシークレットの使用 を参照してください。

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

1.7.3.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 アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64、ppc64le、s390x、および arm64 です。
    • ゾーン: コントロールプレーンプールを実行する場所を指定します。より分散されているコントロールプレーンノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
    • インスタンスタイプ: コントロールプレーンノードのインスタンスタイプを指定します。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。
    • ルートストレージ: クラスターに割り当てるルートストレージの量を指定します。

  • ワーカープールにワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。オプションの情報には以下のフィールドが含まれます。

    • ゾーン: ワーカープールを実行する場所を指定します。より分散されているノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
    • インスタンスタイプ: ワーカープールのインスタンスタイプを指定します。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。
    • ノード数: ワーカープールのノード数を指定します。ワーカープールを定義する場合にこの設定は必須です。
    • ルートストレージ: ワーカープールに割り当てるルートストレージの量を指定します。ワーカープールを定義する場合にこの設定は必須です。
  • クラスターにはネットワークの詳細が必要であり、IPv6 を使用するには複数のネットワークが必要です。Add network をクリックして、追加のネットワークを追加できます。

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

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

新しいクラスターを作成するには、次の手順を参照してください。代わりに既存のクラスターを インポート する場合は、クラスターのインポート を参照してください。

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

  1. Infrastructure > Clusters に移動します。
  2. Clusters ページで、以下を実行します。Cluster > Create cluster をクリックし、コンソールで手順を完了します。
  3. 任意: コンソールに情報を入力するときにコンテンツの更新を表示するには、YAML: On を選択します。

認証情報を作成する必要がある場合は、Amazon Web Services の認証情報の作成 を参照してください。

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

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスターの klusterlet を特定のノードで実行するように設定する場合は、オプション: 特定のノードで実行するように klusterlet を設定する で必要な手順を参照してください。

1.7.3.3.4. 関連情報
リンクのコピー

1.7.3.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 の government リージョンへのクラスターのインストール を参照して、プロセスの詳細を確認してください。以下のセクションでは、AWS GovCloud でクラスターを作成する手順を説明します。

1.7.3.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 でリソースを作成するためにアクセスできる必要があります。

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

1.7.3.4.2. Hive を AWS GovCloud にデプロイするように設定します。
リンクのコピー

AWS GovCloud でのクラスターの作成は、標準の AWS でクラスターを作成することとほぼ同じですが、AWS GovCloud でクラスターの AWS PrivateLink を準備するために追加の手順を実行する必要があります。

1.7.3.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
    Copy to Clipboard Toggle word wrap 
    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
    Copy to Clipboard Toggle word wrap
  4. すべてのハブクラスター (ハブクラスター VPC) に、ピアリング、転送ゲートウェイ、およびすべての DNS 設定が有効になっている VPC エンドポイント用に作成した VPC へのネットワーク接続があることを確認します。
  5. AWS GovCloud 接続に必要な AWS PrivateLink の DNS 設定を解決するために必要な VPC のリストを収集します。これには、少なくとも設定中の multicluster engine Operator インスタンスの VPC を含めます。さまざまな Hive コントローラーが存在するすべての VPC のリストを含めることもできます。
1.7.3.4.2.2. VPC エンドポイントのセキュリティーグループの設定
リンクのコピー

AWS の各 VPC エンドポイントには、エンドポイントへのアクセスを制御するためにセキュリティーグループが割り当てられます。Hive が VPC エンドポイントを作成する場合、セキュリティーグループは指定しません。VPC のデフォルトのセキュリティーグループは VPC エンドポイントに割り当てられます。VPC のデフォルトのセキュリティーグループには、VPC エンドポイントが Hive インストーラー Pod から作成されるトラフィックを許可するルールが必要です。詳細は、AWS ドキュメントの エンドポイントポリシーを使用した VPC エンドポイントへのアクセスの制御 を参照してください。

たとえば、Hive が hive-vpc (10.1.0.0/16) で実行されている場合は、VPC エンドポイントが作成される VPC のデフォルトセキュリティーグループに、10.1.0.0/16 からのイングレスを許可するルールが必要です。

1.7.3.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 アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64、ppc64le、s390x、および 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 コマンドを実行する必要はありません。クラスターを作成すると、そのクラスターは multicluster engine for Kubernetes Operator の管理下で自動的に設定されます。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスターの klusterlet を特定のノードで実行するように設定する場合は、オプション: 特定のノードで実行するように klusterlet を設定する で必要な手順を参照してください。

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

1.7.3.5. Microsoft Azure でのクラスターの作成
リンクのコピー

multicluster engine Operator コンソールを使用して、Microsoft Azure または Microsoft Azure Government に Red Hat OpenShift Container Platform クラスターをデプロイできます。

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

1.7.3.5.1. 前提条件
リンクのコピー

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

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

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

multicluster engine 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 アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64、ppc64le、s390x、および arm64 です。

クラスターの作成後に、コントロールプレーンプールのタイプおよびルートストレージの割り当て (必須) を変更できます。

ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。情報には以下のフィールドが含まれます。

  • ゾーン: ワーカープールを実行することを指定します。より分散されているノードグループでは、リージョンで複数のゾーンを選択できます。ゾーンが近くにある場合はパフォーマンスの速度が向上しますが、ゾーンの距離が離れると、より分散されます。
  • インスタンスタイプ: インスタンスのタイプとサイズは、作成後に変更できます。

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

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

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

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

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスターの klusterlet を特定のノードで実行するように設定する場合は、オプション: 特定のノードで実行するように klusterlet を設定する で必要な手順を参照してください。

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

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

1.7.3.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.7.3.6.1. 前提条件
リンクのコピー

GCP でクラスターを作成する前に、次の前提条件を確認してください。

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

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

multicluster engine 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 アーキテクチャー: マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64、ppc64le、s390x、および arm64 です。

コントロールプレーンプールのインスタンスタイプを指定できます。インスタンスの作成後にインスタンスのタイプやサイズを変更できます。

ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。情報には以下のフィールドが含まれます。

  • インスタンスタイプ: インスタンスのタイプとサイズは、作成後に変更できます。
  • ノード数: ワーカープールを定義するときに必要な設定です。

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

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

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

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

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスターの klusterlet を特定のノードで実行するように設定する場合は、オプション: 特定のノードで実行するように klusterlet を設定する で必要な手順を参照してください。

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

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

1.7.3.7. VMware vSphere でのクラスターの作成
リンクのコピー

multicluster engine Operator コンソールを使用して、VMware vSphere に Red Hat OpenShift Container Platform クラスターをデプロイできます。

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

1.7.3.7.1. 前提条件
リンクのコピー

vSphere でクラスターを作成する前に、次の前提条件を確認してください。

  • サポートされている OpenShift Container Platform バージョンにハブクラスターがデプロイされている。
  • vSphere 認証情報がある。詳細は、VMware vSphere の認証情報の作成 を参照してください。
  • OpenShift Container Platform イメージプルシークレットがある。イメージプルシークレットの使用 を参照してください。

  • デプロイする VMware インスタンスについて、以下の情報がある。

    • API および Ingress インスタンスに必要な静的 IP アドレス

    • 以下の DNS レコード。

      • 次の API ベースドメインは静的 API VIP を指す必要があります。 

        api.<cluster_name>.<base_domain>
        Copy to Clipboard Toggle word wrap

      • 次のアプリケーションベースドメインは、Ingress VIP の静的 IP アドレスを指す必要があります。 

        *.apps.<cluster_name>.<base_domain>
        Copy to Clipboard Toggle word wrap
1.7.3.7.2. コンソールを使用したクラスターの作成
リンクのコピー

multicluster engine 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.15 以降のリリースイメージがサポートされています。

ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。この情報には、CPU アーキテクチャー フィールドが含まれます。次のフィールドの説明を表示します。

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

ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。この情報には、ソケットあたりのコア数、CPU、Memory_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 をクリックして、非接続インストールを定義します。VMware vSphere プロバイダーと切断されたインストールを使用してクラスターを作成する場合、ミラーレジストリーにアクセスするために証明書が必要な場合は、認証情報の設定時に Configuration for disconnected installation セクションの Additional trust bundle フィールドに証明書を入力するか、クラスターを作成する際の Disconnected installation セクション の Disconnected installation セクションに証明書を入力する必要があります。

Add automation template をクリックしてテンプレートを作成できます。

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

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスターの klusterlet を特定のノードで実行するように設定する場合は、オプション: 特定のノードで実行するように klusterlet を設定する で必要な手順を参照してください。

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

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

1.7.3.8. Red Hat OpenStack Platform でのクラスターの作成
リンクのコピー

multicluster engine Operator コンソールを使用して、Red Hat OpenStack Platform に Red Hat OpenShift Container Platform クラスターをデプロイできます。

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

1.7.3.8.1. 前提条件
リンクのコピー

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

  • OpenShift Container Platform バージョン 4.6 以降にデプロイされたハブクラスターが必要です。
  • Red Hat OpenStack Platform の認証情報がある。詳細は、Red Hat OpenStack Platform の認証情報の作成 を参照してください。
  • OpenShift Container Platform イメージプルシークレットがある。イメージプルシークレットの使用 を参照してください。

  • デプロイする Red Hat OpenStack Platform インスタンスに関する以下の情報がある。

    • コントロールプレーンとワーカーインスタンスのフレーバー名 (例:m1.xlarge)
    • Floating IP アドレスを提供する外部ネットワークのネットワーク名
    • API および Ingress インスタンスに必要な静的 IP アドレス

    • 以下の DNS レコード。

      • 次の API ベースドメインは、API のフローティング IP アドレスを指す必要があります。 

        api.<cluster_name>.<base_domain>
        Copy to Clipboard Toggle word wrap

      • 次のアプリケーションベースドメインは、ingress:app-name のフローティング IP アドレスを指す必要があります。 

        *.apps.<cluster_name>.<base_domain>
        Copy to Clipboard Toggle word wrap
1.7.3.8.2. コンソールを使用したクラスターの作成
リンクのコピー

multicluster engine 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 以降のリリースイメージのみがサポートされます。

ノードプールには、コントロールプレーンプールとワーカープールが含まれます。コントロールプレーンノードは、クラスターアクティビティーの管理を共有します。マネージドクラスターのアーキテクチャータイプがハブクラスターのアーキテクチャーと同じでない場合は、プール内のマシンの命令セットアーキテクチャーの値を入力します。有効な値は amd64、ppc64le、s390x、および arm64 です。

コントロールプレーンプールのインスタンスタイプを追加する必要がありますが、インスタンスの作成後にインスタンスのタイプとサイズを変更できます。

ワーカープールに 1 つまたは複数のワーカーノードを作成し、クラスターのコンテナーワークロードを実行できます。ワーカーノードは、1 つのワーカープールに属することも、複数のワーカープールに分散させることもできます。ワーカーノードが指定されていない場合は、コントロールプレーンノードもワーカーノードとして機能します。情報には以下のフィールドが含まれます。

  • インスタンスタイプ: インスタンスのタイプとサイズは、作成後に変更できます。
  • ノード数: ワーカープールのノード数を指定します。ワーカープールを定義する場合にこの設定は必須です。

クラスターにはネットワークの詳細が必要です。IPv4 ネットワーク用に 1 つ以上のネットワークの値を指定する必要があります。IPv6 ネットワークの場合は、複数のネットワークを定義する必要があります。

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

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

  • HTTP プロキシー: HTTP トラフィックのプロキシーとして使用する URL を指定します。
  • HTTPS プロキシー: HTTPS トラフィックに使用するセキュアなプロキシー URL。値が指定されていない場合、HTTP Proxy と同じ値が HTTP と HTTPS の両方に使用されます。
  • プロキシーなし: プロキシーをバイパスする必要のあるサイトのコンマ区切りリストを定義します。ドメイン名をピリオド (.) で開始し、そのドメインにあるすべてのサブドメインを組み込みます。アステリスク (*) を追加し、すべての宛先のプロキシーをバイパスします。
  • 追加の信頼バンドル: 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----
    Copy to Clipboard Toggle word wrap

  2. 以下の例のように、Hive ClusterDeployment オブジェクトを変更して、spec.platform.openstack に certificatesSecretRef の値を指定します。 

    platform:
  openstack:
    certificatesSecretRef:
      name: ocp3-openstack-trust
    credentialsSecretRef:
      name: ocp3-openstack-creds
    cloud: openstack
    Copy to Clipboard Toggle word wrap

    上記の例では、clouds.yaml ファイルのクラウド名が openstack であることを前提としています。

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスターの klusterlet を特定のノードで実行するように設定する場合は、オプション: 特定のノードで実行するように klusterlet を設定する で必要な手順を参照してください。

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

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

1.7.3.9. オンプレミス環境でのクラスターの作成
リンクのコピー

コンソールを使用して、オンプレミスの Red Hat OpenShift Container Platform クラスターを作成できます。クラスターは、VMware vSphere、Red Hat OpenStack、Nutanix、またはベアメタル環境上のシングルノード OpenShift クラスター、マルチノードクラスター、およびコンパクトな 3 ノードクラスターにすることができます。

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

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

1.7.3.9.1. 前提条件
リンクのコピー

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

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

  • 次の DNS レコードが必要です。

    • 次の API ベースドメインは静的 API VIP を指す必要があります。 

      api.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap

    • 次のアプリケーションベースドメインは、Ingress VIP の静的 IP アドレスを指す必要があります。 

      *.apps.<cluster_name>.<base_domain>
      Copy to Clipboard Toggle word wrap
  • ハブクラスターの KubeAPIServer 証明書検証ストラテジーを確認し、デフォルトの UseAutoDetectedCABundle ストラテジーが機能することを確認する。ストラテジーを手動で変更する必要がある場合は、ハブクラスターの KubeAPIServer 検証ストラテジーの設定 を参照してください。
1.7.3.9.2. コンソールを使用したクラスターの作成
リンクのコピー

コンソールからクラスターを作成するには、次の手順を実行します。

  1. Infrastructure > Clusters に移動します。
  2. Clusters ページで、Create cluster をクリックし、コンソールの手順を実行します。
  3. クラスターのタイプとして 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 を入力できます。詳細は、リリースイメージ を参照してください。

サポート対象の OpenShift Container Platform バージョンを選択すると、Install single node OpenShift を選択するオプションが表示されます。シングルノード OpenShift クラスターには、コントロールプレーンサービスとユーザーワークロードをホストするシングルノードが含まれます。シングルノード OpenShift クラスターの作成後にノードを追加する方法の詳細は、インフラストラクチャー環境へのホストのスケーリング を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

Red Hat Advanced Cluster Management for Kubernetes を使用しており、マネージドクラスターの klusterlet を特定のノードで実行するように設定する場合は、オプション: 特定のノードで実行するように klusterlet を設定する で必要な手順を参照してください。

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

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

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

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

1.7.3.9.3.1. namespace を作成します。
リンクのコピー

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

apiVersion: v1
kind: Namespace
metadata:
  name: sample-namespace
Copy to Clipboard Toggle word wrap
1.7.3.9.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
Copy to Clipboard Toggle word wrap
1 1
プルシークレットの内容を追加します。たとえば、これには cloud.openshift.com、quay.io、または registry.redhat.io 認証を含めることができます。
1.7.3.9.3.3. ClusterImageSet の生成
リンクのコピー

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

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  name: openshift-v4.15.0
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.15.0-rc.0-x86_64
Copy to Clipboard Toggle word wrap

注記: ハブクラスターとは異なるアーキテクチャーを持つマネージドクラスターをインストールする場合は、マルチアーキテクチャーの ClusterImageSet を作成する必要があります。詳細は、別のアーキテクチャーにクラスターをデプロイするためのリリースイメージの作成 を参照してください。

1.7.3.9.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
Copy to Clipboard Toggle word wrap
1
AgentClusterInstall リソースの名前を使用します。
2
Add the pull secret to the namespace でダウンロードしたプルシークレットを使用します。
1.7.3.9.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.15.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
Copy to Clipboard Toggle word wrap
1
クラスターが作成される環境のプラットフォームタイプを指定します。有効な値は、BareMetal、None、VSphere、Nutanix、または External です。
2
ClusterDeployment リソースに使用したものと同じ名前を使用します。
3
Generate a ClusterImageSet で生成した ClusterImageSet を使用します。
4
SSH 公開鍵を指定すると、インストール後にホストにアクセスできるようになります。
1.7.3.9.3.6. オプション: NMStateConfig カスタムリソースを作成する
リンクのコピー

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

次の例のような NMStateConfig カスタムリソースを作成して適用します。必要に応じて値を置き換えます。 

apiVersion: agent-install.openshift.io/v1beta1
kind: NMStateConfig
metadata:
  name: <mynmstateconfig>
  namespace: <demo-worker4>
  labels:
    demo-nmstate-label: <value>
spec:
  config:
    interfaces:
      - name: eth0
        type: ethernet
        state: up
        mac-address: 02:00:00:80:12:14
        ipv4:
          enabled: true
          address:
            - ip: 192.168.111.30
              prefix-length: 24
          dhcp: false
      - name: eth1
        type: ethernet
        state: up
        mac-address: 02:00:00:80:12:15
        ipv4:
          enabled: true
          address:
            - ip: 192.168.140.30
              prefix-length: 24
          dhcp: false
    dns-resolver:
      config:
        server:
          - 192.168.126.1
    routes:
      config:
        - destination: 0.0.0.0/0
          next-hop-address: 192.168.111.1
          next-hop-interface: eth1
          table-id: 254
        - destination: 0.0.0.0/0
          next-hop-address: 192.168.140.1
          next-hop-interface: eth1
          table-id: 254
  interfaces:
    - name: "eth0"
      macAddress: "02:00:00:80:12:14"
    - name: "eth1"
      macAddress: "02:00:00:80:12:15"
Copy to Clipboard Toggle word wrap

重要:

  • InfraEnv カスタムリソースの spec.nmStateConfigLabelSelector.matchLabels フィールドに、demo-nmstate-label ラベル名と値を含める必要があります。
  • DHCP または静的ネットワークプロトコルを使用する場合は、MAC アドレスを追加する必要があります。

spec.config フィールドに追加できる NMState の追加の例を表示するには、OpenShift Container Platform の Assisted Installer ドキュメントの 追加の NMState 設定例 を参照してください。

1.7.3.9.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>
  nmStateConfigLabelSelector:
    matchLabels:
      demo-nmstate-label: value
  proxy:
    httpProxy: http://USERNAME:PASSWORD@proxy.example.com:PORT
    httpsProxy: https://USERNAME:PASSWORD@proxy.example.com:PORT
    noProxy: .example.com,172.22.0.0/24,10.10.0.0/24
Copy to Clipboard Toggle word wrap
1
Create the ClusterDeployment の clusterDeployment リソース名を置き換えます。
2
ClusterDeployment の作成 の clusterDeployment リソース namespace を置き換えます。
1.7.3.9.3.7.1. InfraEnv のフィールドの表
リンクのコピー
Expand
フィールド任意または必須説明

sshAuthorizedKey

任意

SSH 公開鍵を指定できます。指定すると、検出 ISO イメージからホストを起動するときにホストにアクセスできるようになります。

nmStateConfigLabelSelector

任意

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

proxy

任意

proxy セクションでは、検出中にホストに必要なプロキシー設定を指定できます。

注記: IPv6 を使用してプロビジョニングする場合、noProxy 設定で CIDR アドレスブロックを定義することはできません。各アドレスを個別に定義する必要があります。

1.7.3.9.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}")
    Copy to Clipboard Toggle word wrap
  2. 検出イメージを仮想メディア、USB ドライブ、または別の保管場所に移動し、ダウンロードしたディスカバリーイメージからホストを起動します。

  3. Agent リソースは自動的に作成されます。これはクラスターに登録されており、検出イメージから起動したホストを表します。次のコマンドを実行して、Agent のカスタムリソースを承認し、インストールを開始します。 

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

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

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

1.7.3.9.4. 関連情報
リンクのコピー

1.7.3.10. プロキシー環境でのクラスターの作成
リンクのコピー

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

  • multicluster engine 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>
    Copy to Clipboard Toggle word wrap

    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.7.3.10.1. 関連情報
リンクのコピー
  • プロバイダーを選択するには、クラスターの作成 を参照してください。
  • クラスターのデプロイ後に設定を変更する方法は、Pod ポリシー を参照してください。

1.7.3.11. AgentClusterInstall プロキシーの設定
リンクのコピー

AgentClusterInstall プロキシーフィールドは、インストール中のプロキシー設定を決定し、作成されたクラスターにクラスター全体のプロキシーリソースを作成するために使用されます。

1.7.3.11.1. AgentClusterInstall の設定
リンクのコピー

AgentClusterInstall プロキシーを設定するには、プロキシー 設定を AgentClusterInstall リソースに追加します。httpProxy、httpsProxy、noProxy を使用した次の YAML サンプルを参照してください。 

apiVersion: extensions.hive.openshift.io/v1beta1
kind: AgentClusterInstall
spec:
  proxy:
    httpProxy: http://<username>:<password>@<proxy.example.com>:<port>
1 

    httpsProxy: https://<username>:<password>@<proxy.example.com>:<port>
2 

    noProxy: <wildcard-of-domain>,<provisioning-network/CIDR>,<BMC-address-range/CIDR>
3
Copy to Clipboard Toggle word wrap
1
httpProxy は、HTTP リクエストのプロキシーの URL です。ユーザー名とパスワードの値は、プロキシーサーバーの認証情報に置き換えます。proxy.example.com は、プロキシーサーバーのパスに置き換えます。
2
httpsProxy は、HTTPS リクエストのプロキシーの URL です。値を自分の認証情報に置き換えます。port は、プロキシーサーバーとの通信ポートに置き換えます。
3
noProxy は、プロキシーを使用しないドメインと CIDR のコンマ区切りリストです。wildcard-of-domain は、プロキシーをバイパスするドメインのエントリーに置き換えます。provisioning-network/CIDR は、プロビジョニングネットワークの IP アドレスと割り当てられた IP アドレスの数 (CIDR 表記) に置き換えます。BMC-address-range/CIDR は、BMC アドレスおよびアドレス数 (CIDR 表記) に置き換えます。
1.7.3.11.2. 関連情報
リンクのコピー

1.7.4. クラスターのインポート
リンクのコピー

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

  • ハブクラスターは 他 のハブクラスターの管理はできず、自己管理のみが可能です。ハブクラスターは、自動的にインポートして自己管理できるように設定されています。ハブクラスターは手動でインポートする必要はありません。
  • ハブクラスターを削除して再度インポートする場合は、local-cluster:true ラベルを ManagedCluster リソースに追加する必要があります。

重要: クラスターライフサイクルで、Cloud Native Computing Foundation (CNCF) Kubernetes Conformance Program を通じて認定されたすべてのプロバイダーがサポートされるようになりました。ハイブリッドクラウドマルチクラスター管理には、CNFC が認定したベンダーを選択してください。

CNFC プロバイダーの使用は、次の情報を参照してください。

クラスターを管理できるようにクラスターをインポートする方法の詳細は、次のトピックを参照してください。

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

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

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

1.7.4.1.1. 前提条件
リンクのコピー
  • デプロイされたハブクラスター。ベアメタルクラスターをインポートする場合、サポートされている Red Hat OpenShift Container Platform バージョンにハブクラスターがインストールされている。
  • 管理するクラスター。
  • base64 コマンドラインツール。
  • OpenShift Container Platform によって作成されていないクラスターをインポートする場合、定義された multiclusterhub.spec.imagePullSecret。このシークレットは、multicluster engine for Kubernetes Operator のインストール時に作成済みである可能性があります。このシークレットを定義する方法の詳細は、カスタムイメージプルシークレット を参照してください。
  • ハブクラスターの KubeAPIServer 証明書検証ストラテジーを確認し、デフォルトの UseAutoDetectedCABundle ストラテジーが機能することを確認する。ストラテジーを手動で変更する必要がある場合は、ハブクラスターの KubeAPIServer 検証ストラテジーの設定 を参照してください。

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

1.7.4.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
    Copy to Clipboard Toggle word wrap

    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 を作成するための権限がすべて含まれているわけではありません。multicluster engine Operator を使用してクラスターをインポートおよび管理するには、cluster-admin 権限が必要です。
1.7.4.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 クラスターをグループとして取得できます。

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

Expand

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 アドレスを設定するには、任意: Configuring the cluster API address を参照してください。

マネージドクラスター klusterlet を特定のノードで実行するように設定するには、オプション: 特定のノードで実行するように klusterlet を設定する を参照してください。

1.7.4.1.3.1. オプション: クラスター API アドレスの設定
リンクのコピー

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

  1. cluster-admin 権限がある ID でハブクラスターにログインします。
  2. ターゲットに設定されたマネージドクラスターの kubeconfig ファイルを設定します。

  3. 次のコマンドを実行して、インポートするクラスターのマネージドクラスターエントリーを編集します。cluster -name をマネージドクラスターの名前に置き換えます。 

    oc edit managedcluster <cluster-name>
    Copy to Clipboard Toggle word wrap

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

    spec:
  hubAcceptsClient: true
  managedClusterClientConfigs:
  - url: <https://api.new-managed.dev.redhat.com>
    1
    Copy to Clipboard Toggle word wrap
    1
    URL の値を、インポートするマネージドクラスターへの外部アクセスを提供する URL に置き換えます。
1.7.4.1.3.2. オプション: 特定のノードで実行するように klusterlet を設定する
リンクのコピー

マネージドクラスターの nodeSelector と tolerations アノテーションを設定することで、マネージドクラスター klusterlet を実行するノードを指定できます。これらを設定するには、次の手順を実行します。

  1. コンソールのクラスターページから、更新するマネージドクラスターを選択します。

  2. YAML コンテンツを表示するには、YAML スイッチを On に設定します。

    注記: YAML エディターは、クラスターをインポートまたは作成するときにのみ使用できます。インポートまたは作成後にマネージドクラスターの YAML 定義を編集するには、OpenShift Container Platform コマンドラインインターフェイスまたは Red Hat Advanced Cluster Management 検索機能を使用する必要があります。

  3. nodeSelector アノテーションをマネージドクラスターの YAML 定義に追加します。このアノテーションのキーは、open-cluster-management/nodeSelector です。このアノテーションの値は、JSON 形式の文字列マップです。

  4. tolerations エントリーをマネージドクラスターの YAML 定義に追加します。このアノテーションのキーは、open-cluster-management/tolerations です。このアノテーションの値は、JSON 形式の toleration リストを表します。結果の YAML は次の例のようになります。 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    open-cluster-management/nodeSelector: '{"dedicated":"acm"}'
    open-cluster-management/tolerations: '[{"key":"dedicated","operator":"Equal","value":"acm","effect":"NoSchedule"}]'
    Copy to Clipboard Toggle word wrap

KlusterletConfig を使用して、マネージドクラスターの nodeSelector と tolerations を設定することもできます。これらを設定するには、次の手順を実行します。

注: KlusterletConfig を使用する場合、マネージドクラスターは、マネージドクラスターのアノテーションの設定ではなく、KlusterletConfig 設定の構成を使用します。

  1. 次のサンプル YAML の内容を適用します。必要に応じて値を置き換えます。 

    apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: <klusterletconfigName>
spec:
  nodePlacement:
    nodeSelector:
      dedicated: acm
    tolerations:
      - key: dedicated
        operator: Equal
        value: acm
        effect: NoSchedule
    Copy to Clipboard Toggle word wrap
  2. agent.open-cluster-management.io/klusterlet-config: `<klusterletconfigName> アノテーションをマネージドクラスターに追加し、<klusterletconfigName> を KlusterletConfig の名前に置き換えます。
1.7.4.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`
Copy to Clipboard Toggle word wrap

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

1.7.4.1.4.1. 関連情報
リンクのコピー

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

multicluster engine for Kubernetes Operator をインストールしたら、Red Hat OpenShift Container Platform CLI を使用して、クラスターをインポートおよび管理できるようになります。自動インポートシークレットを使用するか、man コマンドを使用して、CLI でマネージドクラスターをインポートする方法は、以下のトピックを参照してください。

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

1.7.4.2.1. 前提条件
リンクのコピー
  • デプロイされたハブクラスター。ベアメタルクラスターをインポートする場合、サポートされている OpenShift Container Platform バージョンにハブクラスターがインストールされている。
  • 管理する別のクラスター。
  • OpenShift Container Platform CLI。OpenShift Container Platform CLI のインストールと設定については、OpenShift CLI の使用を開始する を参照してください。
  • OpenShift Container Platform によって作成されていないクラスターをインポートする場合、定義された multiclusterhub.spec.imagePullSecret。このシークレットは、multicluster engine for Kubernetes Operator のインストール時に作成済みである可能性があります。このシークレットを定義する方法の詳細は、カスタムイメージプルシークレット を参照してください。
  • ハブクラスターの KubeAPIServer 証明書検証ストラテジーを確認し、デフォルトの UseAutoDetectedCABundle ストラテジーが機能することを確認する。ストラテジーを手動で変更する必要がある場合は、ハブクラスターの KubeAPIServer 検証ストラテジーの設定 を参照してください。
1.7.4.2.2. サポートされているアーキテクチャー
リンクのコピー
  • Linux (x86_64, s390x, ppc64le)
  • macOS
1.7.4.2.3. クラスターインポートの準備
リンクのコピー

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

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

    oc login
    Copy to Clipboard Toggle word wrap

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

    oc new-project <cluster_name>
    Copy to Clipboard Toggle word wrap

    重要: 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
    Copy to Clipboard Toggle word wrap

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

    cloud: Amazon
vendor: OpenShift
    Copy to Clipboard Toggle word wrap

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

    oc apply -f managed-cluster.yaml
    Copy to Clipboard Toggle word wrap

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

1.7.4.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
      Copy to Clipboard Toggle word wrap

    2. 以下のコマンドを実行して、<cluster_name> namespace に YAML ファイルを適用します。 

      oc apply -f auto-import-secret.yaml
      Copy to Clipboard Toggle word wrap

      注記: デフォルトでは、自動インポートシークレットは 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=""
      Copy to Clipboard Toggle word wrap

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

    oc get managedcluster <cluster_name>
    Copy to Clipboard Toggle word wrap

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

    oc login
    Copy to Clipboard Toggle word wrap

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

    oc get pod -n open-cluster-management-agent
    Copy to Clipboard Toggle word wrap

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

1.7.4.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
    Copy to Clipboard Toggle word wrap

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

    oc get secret <cluster_name>-import -n <cluster_name> -o jsonpath={.data.import\\.yaml} | base64 --decode > import.yaml
    Copy to Clipboard Toggle word wrap

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

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

    oc login
    Copy to Clipboard Toggle word wrap

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

    oc apply -f klusterlet-crd.yaml
    Copy to Clipboard Toggle word wrap

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

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

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

    oc get managedcluster <cluster_name>
    Copy to Clipboard Toggle word wrap

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

1.7.4.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
  policyController:
    enabled: true
  searchCollector:
    enabled: true
    Copy to Clipboard Toggle word wrap
  2. ファイルは klusterlet-addon-config.yaml として保存します。

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

    oc apply -f klusterlet-addon-config.yaml
    Copy to Clipboard Toggle word wrap

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

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

    oc get pod -n open-cluster-management-agent-addon
    Copy to Clipboard Toggle word wrap
1.7.4.2.7. コマンドラインインターフェイスを使用したインポート済みクラスターの削除
リンクのコピー

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

oc delete managedcluster <cluster_name>
Copy to Clipboard Toggle word wrap

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

1.7.4.3. エージェント登録を使用したマネージドクラスターのインポート
リンクのコピー

multicluster engine for Kubernetes Operator をインストールしたら、エージェント登録エンドポイントを使用して、クラスターをインポートおよび管理できるようになります。エージェント登録エンドポイントを使用してマネージドクラスターをインポートする方法は、次のトピックをそのまま参照してください。

1.7.4.3.1. 前提条件
リンクのコピー
  • デプロイされたハブクラスター。ベアメタルクラスターをインポートする場合、サポートされている OpenShift Container Platform バージョンにハブクラスターがインストールされている。
  • 管理するクラスター。
  • base64 コマンドラインツール。

  • OpenShift Container Platform によって作成されていないクラスターをインポートする場合、定義された multiclusterhub.spec.imagePullSecret。このシークレットは、multicluster engine for Kubernetes Operator のインストール時に作成済みである可能性があります。このシークレットを定義する方法の詳細は、カスタムイメージプルシークレット を参照してください。

    新規シークレットを作成する必要がある場合は、新規プルシークレットの作成 を参照してください。

1.7.4.3.2. サポートされているアーキテクチャー
リンクのコピー
  • Linux (x86_64, s390x, ppc64le)
  • macOS
1.7.4.3.3. クラスターのインポート
リンクのコピー

エージェント登録エンドポイントを使用してマネージドクラスターをインポートするには、次の手順を実行します。

  1. ハブクラスターで次のコマンドを実行して、エージェント登録サーバーの URL を取得します。 

    export agent_registration_host=$(oc get route -n multicluster-engine agent-registration -o=jsonpath="{.spec.host}")
    Copy to Clipboard Toggle word wrap

    注: ハブクラスターがクラスター全体のプロキシーを使用している場合は、マネージドクラスターがアクセスできる URL を使用していることを確認してください。

  2. 次のコマンドを実行して、cacert を取得します。 

    oc get configmap -n kube-system kube-root-ca.crt -o=jsonpath="{.data['ca\.crt']}" > ca.crt_
    Copy to Clipboard Toggle word wrap

    注記: kube-root-ca 発行エンドポイントを使用していない場合は、kube-root-ca CA の代わりにパブリック agent-registration API エンドポイント CA を使用してください。

  3. 次の YAML コンテンツを適用して、エージェント登録サーバーが承認するトークンを取得します。 

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: managed-cluster-import-agent-registration-sa
  namespace: multicluster-engine
---
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: managed-cluster-import-agent-registration-sa-token
  namespace: multicluster-engine
  annotations:
    kubernetes.io/service-account.name: "managed-cluster-import-agent-registration-sa"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: managedcluster-import-controller-agent-registration-client
rules:
- nonResourceURLs: ["/agent-registration/*"]
  verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: managed-cluster-import-agent-registration
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: managedcluster-import-controller-agent-registration-client
subjects:
  - kind: ServiceAccount
    name: managed-cluster-import-agent-registration-sa
    namespace: multicluster-engine
    Copy to Clipboard Toggle word wrap

  4. 以下のコマンドを実行してトークンをエクスポートします。 

    export token=$(oc get secret -n multicluster-engine managed-cluster-import-agent-registration-sa-token -o=jsonpath='{.data.token}' | base64 -d)
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを実行して、自動承認を有効にし、コンテンツを cluster-manager にパッチを適用します。 

    oc patch clustermanager cluster-manager --type=merge -p '{"spec":{"registrationConfiguration":{"featureGates":[
{"feature": "ManagedClusterAutoApproval", "mode": "Enable"}], "autoApproveUsers":["system:serviceaccount:multicluster-engine:agent-registration-bootstrap"]}}}'
    Copy to Clipboard Toggle word wrap

    注: 自動承認を無効にして、マネージドクラスターからの証明書署名リクエストを手動で承認することもできます。

  6. 次のコマンドを実行して、マネージドクラスターに切り替え、cacert を取得します。 

    curl --cacert ca.crt -H "Authorization: Bearer $token" https://$agent_registration_host/agent-registration/crds/v1 | oc apply -f -
    Copy to Clipboard Toggle word wrap

  7. 次のコマンドを実行して、マネージドクラスターをハブクラスターにインポートします。<clusterName> は、クラスターの名前に置き換えます。<duration> は、時間値に置き換えます。たとえば、4h などに置き換えます。

    オプション: <klusterletconfigName> は KlusterletConfig の名前に置き換えます。 

    curl --cacert ca.crt -H "Authorization: Bearer $token" https://$agent_registration_host/agent-registration/manifests/<clusterName>?klusterletconfig=<klusterletconfigName>&duration=<duration> | oc apply -f -
    Copy to Clipboard Toggle word wrap

    注記: 期間を設定しないと、klusterlet マニフェストの kubeconfig ブートストラップは期限切れになりません。

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

1.7.4.4.1. 前提条件
リンクのコピー
  • Central Infrastructure Management 機能を有効にします。
1.7.4.4.2. クラスターのインポート
リンクのコピー

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

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

    apiVersion: v1
kind: Namespace
metadata:
  name: managed-cluster
    Copy to Clipboard Toggle word wrap

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

    apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  name: openshift-v4.15
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release@sha256:22e149142517dfccb47be828f012659b1ccf71d26620e6f62468c264a7ce7863
    Copy to Clipboard Toggle word wrap

  3. 次の YAML コンテンツを適用して、イメージにアクセスするためのプルシークレットを追加します。 

    apiVersion: v1
kind: Secret
type: kubernetes.io/dockerconfigjson
metadata:
  name: pull-secret
  namespace: managed-cluster
stringData:
  .dockerconfigjson: <pull-secret-json>
    1
    Copy to Clipboard Toggle word wrap
    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
      Copy to Clipboard Toggle word wrap

      注記: クラスター API にカスタムドメイン経由でアクセスする場合は、まずこの kubeconfig を編集して、certificate-authority-data フィールドにカスタム証明書を追加し、server フィールドをカスタムドメインに合わせて変更する必要があります。

    2. 次のコマンドを実行して、kubeconfig をハブクラスターにコピーします。kubeconfig がハブクラスターとして設定されていることを確認します。 

      oc -n managed-cluster create secret generic some-other-cluster-admin-kubeconfig --from-file=kubeconfig=/tmp/kubeconfig.some-other-cluster
      Copy to Clipboard Toggle word wrap

  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:
    2 
    
  sshPublicKey: <"">
    3
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
    1
    クラスターの名前を選択します。
    2
    baseDomain が OpenShift Container Platform クラスターに使用しているドメインと一致していることを確認してください。
    3
    OpenShift Container Platform クラスターを実稼働環境のクラスターとして自動的にインポートするには、true に設定します。
    4
    ステップ 4 で作成した kubeconfig を参照します。
    5 6
    実稼働環境では、clusterID と infraID は空のままにしておきます。

  7. 次の YAML コンテンツを適用することで、InfraEnv カスタムリソースを追加して、クラスターに追加する新しいホストを検出します。必要に応じて値を置き換えます。

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

    apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: your-infraenv
  namespace: managed-cluster
spec:
  clusterRef:
    name: your-cluster-name
    namespace: managed-cluster
  pullSecretRef:
    name: pull-secret
  sshAuthorizedKey: ""
    Copy to Clipboard Toggle word wrap
Expand
表1.6 InfraEnv のフィールドの表
フィールド任意または必須説明

clusterRef

任意

遅延バインディングを使用している場合、clusterRef フィールドはオプションです。遅延バインディングを使用していない場合は、clusterRef を追加する必要があります。

sshAuthorizedKey

任意

トラブルシューティングのためにノードにログインできるように、オプションの sshAuthorizedKey フィールド

  1. インポートに成功すると、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
    Copy to Clipboard Toggle word wrap
  2. オプション: OpenShift Container Platform クラスターで、ポリシーなどの Red Hat Advanced Cluster Management 機能を使用する場合は、ManagedCluster リソースを作成します。ManagedCluster リソースの名前は、ClusterDeplpoyment リソースの名前と一致させてください。ManagedCluster リソースがない場合、コンソールではクラスターのステータスが detached になります。
1.7.4.4.3. クラスターリソースのインポート
リンクのコピー

OpenShift Container Platform マネージドクラスターを Assisted Installer によってインストールした場合、あるハブクラスターから別のハブクラスターにマネージドクラスターとそのリソースを移動できます。

元のリソースのコピーを保存し、それを新しいハブクラスターに適用し、元のリソースを削除することで、新しいハブクラスターからクラスターを管理できます。その後、新しいハブクラスターからマネージドクラスターをスケールダウンまたはスケールアップできます。

重要: インポートした OpenShift Container Platform マネージドクラスターは、Assisted Installer によってインストールされたものである場合にのみスケールダウンできます。

次のリソースをインポートできます。これらのリソースを使用してクラスターの管理を継続できます。

Expand
表1.7 マネージドクラスターリソースの表
リソース任意または必須説明

Agent

必須

 

AgentClassification

任意

フィルタークエリーを使用してエージェントを分類する場合は必須です。

AgentClusterInstall

必須

 

BareMetalHost

任意

baremetal プラットフォームを使用している場合は必須です。

ClusterDeployment

必須

 

InfraEnv

必須

 

NMStateConfig

任意

ホストにネットワーク設定を適用する場合は必須です。

ManagedCluster

必須

 

Secret

必須

admin-kubeconfig シークレットが必要です。bmc-secret シークレットは、BareMetalHosts を使用している場合にのみ必要です。

1.7.4.4.3.1. マネージドクラスターリソースの保存と適用
リンクのコピー

マネージドクラスターリソースのコピーを保存し、リソースを新しいハブクラスターに適用するには、次の手順を実行します。

  1. 次のコマンドを実行して、ソースハブクラスターからリソースを取得します。必要に応じて値を置き換えます。 

    oc –kubeconfig <source_hub_kubeconfig> -n <managed_cluster_name> get <resource_name> <cluster_provisioning_namespace> -oyaml > <resource_name>.yaml
    Copy to Clipboard Toggle word wrap
    1. <resource_name> をリソースの名前に置き換えて、インポートするリソースごとにこのコマンドを繰り返し実行します。

  2. 次のコマンドを実行して、次のリソースから ownerReferences プロパティーを削除します。

    1. AgentClusterInstall 

      yq --in-place -y 'del(.metadata.ownerReferences)' AgentClusterInstall.yaml
      Copy to Clipboard Toggle word wrap

    2. Secret (admin-kubeconfig) 

      yq --in-place -y 'del(.metadata.ownerReferences)' AdminKubeconfigSecret.yaml
      Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、マネージドクラスターをソースハブクラスターからデタッチします。必要に応じて値を置き換えます。 

    oc –kubeconfig <target_hub_kubeconfig> delete ManagedCluster <cluster_name>
    Copy to Clipboard Toggle word wrap
  4. マネージドクラスターのターゲットハブクラスターに namespace を作成します。ソースハブクラスターと同様の名前を使用します。

  5. 次のコマンドを実行して、保存したリソースをターゲットハブクラスターに個別に適用します。必要に応じて値を置き換えます。

    注記: すべてのリソースを個別ではなく一括で適用する場合は、<resource_name>.yaml を . に置き換えてください。 

    oc –kubeconfig <target_hub_kubeconfig> apply -f <resource_name>.yaml
    Copy to Clipboard Toggle word wrap
1.7.4.4.3.2. ソースハブクラスターからのマネージドクラスターの削除
リンクのコピー

クラスターリソースをインポートした後、次の手順を実行して、ソースハブクラスターからマネージドクラスターを削除します。

  1. ClusterDeployment カスタムリソースで spec.preserveOnDelete パラメーターを true に設定し、マネージドクラスターの破棄を防止します。
  2. 管理からのクラスターの削除 の手順を完了します。

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

インポートしているマネージドクラスターのイメージレジストリーを上書きする必要がある場合があります。これには、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>
1 

  pullSecret:
    name: <pullSecretName>
2 

  registries:
3 

  - mirror: <mirrored-image-registry-address>
    source: <image-registry-address>
  - mirror: <mirrored-image-registry-address>
    source: <image-registry-address>
Copy to Clipboard Toggle word wrap
1
マネージドクラスターのセットを選択するのと同じ namespace 内の配置の名前に置き換えます。
2
カスタムイメージレジストリーからイメージをプルするために使用されるプルシークレットの名前に置き換えます。
3
ソース および ミラー レジストリーのそれぞれの値をリスト表示します。mirrored-image-registry-address および image-registry-address は、レジストリーの各 ミラー および ソース 値に置き換えます。
  • 例 1: registry.redhat.io/rhacm2 という名前のソースイメージレジストリーを localhost:5000/rhacm2 に、registry.redhat.io/multicluster-engine を localhost:5000/multicluster-engine に置き換えるには、以下の例を使用します。 
registries:
- mirror: localhost:5000/rhacm2/
    source: registry.redhat.io/rhacm2
- mirror: localhost:5000/multicluster-engine
    source: registry.redhat.io/multicluster-engine
Copy to Clipboard Toggle word wrap

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

    registries:
- mirror: localhost:5000/rhacm2-registration-rhel8-operator
    source: registry.redhat.io/rhacm2/registration-rhel8-operator
    Copy to Clipboard Toggle word wrap

重要: エージェント登録を使用してマネージドクラスターをインポートする場合は、イメージレジストリーを含む KlusterletConfig を作成する必要があります。以下の例を参照してください。必要に応じて値を置き換えます。 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: <klusterletconfigName>
spec:
  pullSecret:
    namespace: <pullSecretNamespace>
    name: <pullSecretName>
  registries:
    - mirror: <mirrored-image-registry-address>
      source: <image-registry-address>
    - mirror: <mirrored-image-registry-address>
      source: <image-registry-address>
Copy to Clipboard Toggle word wrap

詳細は、エージェント登録エンドポイントを使用したマネージドクラスターのインポート を参照してください。

1.7.4.5.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>
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    注記: 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
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap
  5. コンソールからマネージドクラスターをインポートし、マネージドクラスターセットに追加します。
  6. open-cluster-management.io/image-registry=myNamespace.myImageRegistry ラベルをマネージドクラスターに追加した後に、マネージドクラスターで import コマンドをコピーして実行します。

1.7.5. クラスターへのアクセス
リンクのコピー

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

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

  2. Reveal credentials を選択し、クラスターのユーザー名およびパスワードを表示します。クラスターにログインする際に使用するため、この値を書き留めてください。

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

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

1.7.6. マネージドクラスターのスケーリング
リンクのコピー

作成したクラスターは、仮想マシンのサイズやノード数など、マネージドクラスターの仕様をカスタマイズおよびサイズ変更できます。インストーラーでプロビジョニングされたインフラストラクチャーをクラスターデプロイメントに使用している場合は、次のオプションを参照してください。

クラスターのデプロイメントに Central Infrastructure Management を使用している場合は、次のオプションを参照してください。

1.7.6.1. MachinePool によるスケーリング
リンクのコピー

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

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

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

      oc edit machinepool <MachinePool-resource-name> -n <managed-cluster-namespace>
      Copy to Clipboard Toggle word wrap
      • MachinePool-resource-name は MachinePool リソースの名前に置き換えます。
      • managed-cluster-namespace はマネージドクラスターの namespace の名前に置き換えます。
    3. YAML ファイルから spec.replicas フィールドを削除します。
    4. spec.autoscaling.minReplicas 設定および spec.autoscaling.maxReplicas フィールドをリソース YAML に追加します。
    5. レプリカの最小数を minReplicas 設定に追加します。
    6. レプリカの最大数を maxReplicas 設定に追加します。
    7. ファイルを保存して変更を送信します。
1.7.6.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>
      Copy to Clipboard Toggle word wrap

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

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

      oc edit machinepool <name-of-MachinePool-resource> -n <namespace-of-managed-cluster>
      Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

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

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

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

    oc get machinepools.hive.openshift.io -n <managed-cluster-namespace>
    Copy to Clipboard Toggle word wrap

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

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

1.7.6.2. OpenShift Container Platform クラスターへのワーカーノードの追加
リンクのコピー

Central Infrastructure Management を使用している場合は、実稼働環境ノードを追加することで OpenShift Container Platform クラスターをカスタマイズできます。

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

1.7.6.2.1. 前提条件
リンクのコピー

マネージドクラスター API を信頼するために必要な新しい CA 証明書が必要です。

1.7.6.2.2. 有効な kubeconfig の作成
リンクのコピー

実稼働環境のワーカーノードを OpenShift Container Platform クラスターに追加する前に、有効な kubeconfig があるかどうかを確認する必要があります。

マネージドクラスターの API 証明書が変更された場合は、次の手順を実行して、kubeconfig を新しい CA 証明書で更新します。

  1. 次のコマンドを実行して、clusterDeployment の kubeconfig が有効かどうかを確認します。<kubeconfig_name> を現在の kubeconfig の名前に置き換え、<cluster_name> をクラスターの名前に置き換えます。 

    export <kubeconfig_name>=$(oc get cd $<cluster_name> -o "jsonpath={.spec.clusterMetadata.adminKubeconfigSecretRef.name}")
oc extract secret/$<kubeconfig_name> --keys=kubeconfig --to=- > original-kubeconfig
oc --kubeconfig=original-kubeconfig get node
    Copy to Clipboard Toggle word wrap

  2. 次のエラーメッセージが表示された場合は、kubeconfig シークレットを更新する必要があります。エラーメッセージが表示されない場合は、ワーカーノードの追加 に進みます。 

    Unable to connect to the server: tls: failed to verify certificate: x509: certificate signed by unknown authority
    Copy to Clipboard Toggle word wrap

  3. kubeconfig の certificate-authority-data フィールドから base64 でエンコードされた証明書バンドルを取得し、次のコマンドを実行してデコードします。 

    echo <base64 encoded blob> | base64 --decode > decoded-existing-certs.pem
    Copy to Clipboard Toggle word wrap

  4. 元のファイルをコピーして、更新された kubeconfig ファイルを作成します。次のコマンドを実行し、<new_kubeconfig_name> を新しい kubeconfig ファイルの名前に置き換えます。 

    cp original-kubeconfig <new_kubeconfig_name>
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを実行して、デコードされた pem に新しい証明書を追加します。 

    cat decoded-existing-certs.pem new-ca-certificate.pem | openssl base64 -A
    Copy to Clipboard Toggle word wrap
  6. テキストエディターを使用して、前のコマンドの base64 出力を新しい kubeconfig ファイルの certificate-authority-data キーの値として追加します。

  7. 新しい kubeconfig を使用して API をクエリーし、新しい kubeconfig が有効かどうかを確認します。以下のコマンドを実行します。<new_kubeconfig_name> を新しい kubeconfig ファイルの名前に置き換えます。 

    KUBECONFIG=<new_kubeconfig_name> oc get nodes
    Copy to Clipboard Toggle word wrap

    成功した出力を受け取った場合、kubeconfig は有効です。

  8. 次のコマンドを実行して、Red Hat Advanced Cluster Management ハブクラスターの kubeconfig シークレットを更新します。<new_kubeconfig_name> を新しい kubeconfig ファイルの名前に置き換えます。 

    oc patch secret $original-kubeconfig --type='json' -p="[{'op': 'replace', 'path': '/data/kubeconfig', 'value': '$(openssl base64 -A -in <new_kubeconfig_name>)'},{'op': 'replace', 'path': '/data/raw-kubeconfig', 'value': '$(openssl base64 -A -in <new_kubeconfig_name>)'}]"
    Copy to Clipboard Toggle word wrap
1.7.6.2.3. ワーカーノードの追加
リンクのコピー

有効な kubeconfig がある場合は、以下の手順を実行して、実稼働環境のワーカーノードを OpenShift Container Platform クラスターに追加します。

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

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

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

    watch -n 5 "oc get agent -n managed-cluster"
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

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

1.7.6.3. マネージドクラスターへのコントロールプレーンノードの追加
リンクのコピー

問題のあるコントロールプレーンを置き換えるには、コントロールプレーンノードを正常または正常でないマネージドクラスターに追加します。

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

1.7.6.3.1. 正常なマネージドクラスターへのコントロールプレーンノードの追加
リンクのコピー

以下の手順を実行して、コントロールプレーンノードを正常なマネージドクラスターに追加します。

  1. 新規コントロールプレーンノードの OpenShift Container Platform クラスターへのワーカーノードの追加 の手順を実行します。

  2. Discovery ISO を使用してノードを追加する場合は、エージェントを承認する前にエージェントを master に設定します。以下のコマンドを実行します。 

    oc patch agent <AGENT-NAME> -p '{"spec":{"role": "master"}}' --type=merge
    Copy to Clipboard Toggle word wrap

    注記: CSR は自動的に承認されません。

  3. BareMetalHost を使用してノードを追加する場合は、BareMetalHost リソースの作成時に、BareMetalHost アノテーションに次の行を追加します。 

        bmac.agent-install.openshift.io/role: master
    Copy to Clipboard Toggle word wrap
  4. OpenShift Container Platform の Assisted Installer ドキュメントの 正常なクラスターへのプライマリーコントロールプレーンノードのインストール の手順に従ってください。
1.7.6.3.2. 正常でないマネージドクラスターへのコントロールプレーンノードの追加
リンクのコピー

以下の手順を実行して、コントロールプレーンノードを正常でないマネージドクラスターに追加します。

  1. 正常でないコントロールプレーンノードのエージェントを削除します。
  2. デプロイメントにゼロタッチプロビジョニングフローを使用した場合は、ベアメタルホストを削除します。
  3. 新規コントロールプレーンノードの OpenShift Container Platform クラスターへのワーカーノードの追加 の手順を実行します。

  4. 次のコマンドを実行して、エージェントを承認する前にエージェントを master に設定します。 

    oc patch agent <AGENT-NAME> -p '{"spec":{"role": "master"}}' --type=merge
    Copy to Clipboard Toggle word wrap

    注記: CSR は自動的に承認されません。

  5. OpenShift Container Platform の Assisted Installer ドキュメントの 正常でないクラスターへのプライマリーコントロールプレーンノードのインストール の手順に従ってください。

1.7.7. 作成されたクラスターの休止
リンクのコピー

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

  • Amazon Web Services
  • Microsoft Azure
  • Google Cloud Platform

1.7.7.1. コンソールを使用したクラスターの休止
リンクのコピー

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

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

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

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

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

1.7.7.2. CLI を使用したクラスターの休止
リンクのコピー

CLI を使用して、multicluster engine Operator によって作成されたクラスターを休止状態にするには、次の手順を実行します。

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

    oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>
    Copy to Clipboard Toggle word wrap

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

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

  2. spec.powerState の値は Hibernating に変更します。

  3. 以下のコマンドを実行して、クラスターのステータスを表示します。 

    oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml
    Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

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

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

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

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

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

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

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

    oc edit clusterdeployment <name-of-cluster> -n <namespace-of-cluster>
    Copy to Clipboard Toggle word wrap

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

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

  2. spec.powerState の値を Running に変更します。

  3. 以下のコマンドを実行して、クラスターのステータスを表示します。 

    oc get clusterdeployment <name-of-cluster> -n <namespace-of-cluster> -o yaml
    Copy to Clipboard Toggle word wrap

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

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

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

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

1.7.8. クラスターのアップグレード
リンクのコピー

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

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

1.7.8.1. 前提条件
リンクのコピー

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

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

  • OpenShift Container Platform マネージドクラスターが、Ready 状態である。

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

1.7.8.2. オンライン環境でのクラスターのアップグレード
リンクのコピー

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

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

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

1.7.8.3. チャネルの選択
リンクのコピー

コンソールを使用して、OpenShift Container Platform でクラスターをアップグレードするためのチャネルを選択できます。チャネルを選択すると、エラータバージョンとリリースバージョンの両方で利用可能なクラスターアップグレードが自動的に通知されます。

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

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

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

1.7.8.4. オフラインクラスターのアップグレード
リンクのコピー

multicluster engine Operator と OpenShift Update Service を使用し、オフライン環境でクラスターをアップグレードできます。

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

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

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

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

1.7.8.4.1. 前提条件
リンクのコピー

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

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

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

  • ハブクラスターによって管理される OpenShift Container Platform クラスター

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

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

1.7.8.4.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}
    Copy to Clipboard Toggle word wrap
    1
    path-to-pull-secret は、OpenShift Container Platform のプルシークレットへのパスに置き換えます。

  2. スクリプトを実行して、イメージのミラーリング、設定の設定、リリースイメージとリリースコンテンツの分離を行います。

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

1.7.8.4.3. OpenShift Update Service の Operator のデプロイ
リンクのコピー

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

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

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

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

1.7.8.4.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
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

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

    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
    Copy to Clipboard Toggle word wrap
    1
    path_to_Dockerfile を、直前の手順で作成したファイルへのパスに置き換えます。
    2
    ${DISCONNECTED_REGISTRY}/cincinnati/cincinnati-graph-data-container は、ローカルグラフデータ init container へのパスに置き換えます。
    3
    /path/to/pull_secret は、プルシークレットへのパスに置き換えます。

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

1.7.8.4.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-----
    Copy to Clipboard Toggle word wrap

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

    oc patch image.config.openshift.io cluster -p '{"spec":{"additionalTrustedCA":{"name":"trusted-ca"}}}' --type merge
    Copy to Clipboard Toggle word wrap

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

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

1.7.8.4.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 Operator セクションで、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
    Copy to Clipboard Toggle word wrap
    1
    spec.registry の値は、イメージの非接続環境にあるローカルレジストリーへのパスに置き換えます。
    2
    spec.graphDataImage の値は、グラフデータ init container へのパスに置き換えます。これは、podman push コマンドを使用して、グラフデータ init container をプッシュする時に使用した値と同じです。
  5. Create を選択してインスタンスを作成します。
  6. ハブクラスター CLI で oc get pods コマンドを入力し、インスタンス作成のステータスを表示します。時間がかかる場合がありますが、コマンド結果でインスタンスと Operator が実行中である旨が表示されたらプロセスは完了です。
1.7.8.4.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
    Copy to Clipboard Toggle word wrap
    1
    your-local-mirror-name をローカルミラーの名前に置き換えます。
    2
    your-registry をローカルミラーリポジトリーへのパスに置き換えます。

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

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

    oc apply -f mirror.yaml
    Copy to Clipboard Toggle word wrap
1.7.8.4.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
    Copy to Clipboard Toggle word wrap
    1
    spec.image の値を、ローカルの制約付きカタログソースイメージへのパスに置き換えます。

  2. マネージドクラスターのコマンドラインで、次のコマンドを実行してカタログソースを変更します。 

    oc apply -f source.yaml
    Copy to Clipboard Toggle word wrap
1.7.8.4.9. マネージドクラスターのパラメーターを変更する
リンクのコピー

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

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

    oc get clusterversion -o yaml
    Copy to Clipboard Toggle word wrap

    サポートされているバージョンとして 4.x が設定されている場合、次のような内容が返されます。 

    apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: ClusterVersion
[..]
  spec:
    channel: stable-4.x
    upstream: https://api.openshift.com/api/upgrades_info/v1/graph
    Copy to Clipboard Toggle word wrap

  2. ハブクラスターから、次のコマンドを入力して、OpenShift Update Service オペランドへのルート URL を特定します。 

    oc get routes
    Copy to Clipboard Toggle word wrap

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

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

    oc edit clusterversion version
    Copy to Clipboard Toggle word wrap

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

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

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

      oc get routes -A
      Copy to Clipboard Toggle word wrap
    2. cincinnati へのパスを見つけます。オペランドのパスは、HOST/PORT フィールドの値です。

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

    oc get clusterversion -o yaml
    Copy to Clipboard Toggle word wrap

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

    apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
  kind: ClusterVersion
[..]
  spec:
    channel: stable-4.x
    upstream: https://<hub-cincinnati-uri>/api/upgrades_info/v1/graph
    Copy to Clipboard Toggle word wrap
1.7.8.4.10. 利用可能なアップグレードの表示
リンクのコピー

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

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

1.7.8.4.11. チャネルの選択
リンクのコピー

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

1.7.8.4.12. クラスターのアップグレード
リンクのコピー

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

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

マネージドクラスターは、選択したバージョンに更新されます。

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

1.7.9. クラスタープロキシーアドオンの使用
リンクのコピー

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

重要: ハブクラスター上にクラスター全体のプロキシー設定を配置しないようにしてください。

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

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

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

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

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

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

        export KUBECONFIG=<managed-cluster-kubeconfig>
        Copy to Clipboard Toggle word wrap

      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
        Copy to Clipboard Toggle word wrap

      3. 次のコマンドを実行して、サービスアカウントトークンのシークレットを見つけます。 

        oc get secret -n default | grep <default-token>
        Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

        oc config view --minify --raw=true > cluster-proxy.kubeconfig
        Copy to Clipboard Toggle word wrap

      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
        Copy to Clipboard Toggle word wrap

      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
        Copy to Clipboard Toggle word wrap

      4. サービスアカウントのトークンを追加します。 

        sed -i'' -e '$a\    token: '"$MANAGED_CLUSTER_TOKEN"'' cluster-proxy.kubeconfig
        Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、ターゲットマネージドクラスターのターゲット namespace にあるすべての Pod をリスト表示します。 

    oc get pods --kubeconfig=cluster-proxy.kubeconfig -n <default>
    Copy to Clipboard Toggle word wrap

    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)
      Copy to Clipboard Toggle word wrap

    • ハブクラスターから、以下のコマンドを実行して認証局をファイルに変換します。 

      oc get configmap kube-root-ca.crt -o=jsonpath='{.data.ca\.crt}' > hub-ca.crt
      Copy to Clipboard Toggle word wrap

  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"
    Copy to Clipboard Toggle word wrap

1.7.9.1. クラスタープロキシーアドオンのプロキシー設定
リンクのコピー

マネージドクラスターが HTTP および HTTPS プロキシーサーバー経由でハブクラスターと通信できるように、クラスタープロキシーアドオンのプロキシー設定を指定できます。クラスタープロキシーアドオンエージェントがプロキシーサーバー経由でハブクラスターにアクセスする必要がある場合は、プロキシー設定が必要な可能性があります。

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

  1. ハブクラスターに AddOnDeploymentConfig リソースを作成し、spec.proxyConfig パラメーターを追加します。以下の例を参照してください。 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: AddOnDeploymentConfig
metadata:
  name: <name>
    1 
    
  namespace: <namespace>
    2 
    
spec:
  agentInstallNamespace: open-cluster-management-agent-addon
  proxyConfig:
    httpsProxy: "http://<username>:<password>@<ip>:<port>"
    3 
    
    noProxy: ".cluster.local,.svc,172.30.0.1"
    4 
    
    caBundle: <value>
    5
    Copy to Clipboard Toggle word wrap
    1
    アドオンのデプロイメント設定名を追加します。
    2
    マネージドクラスター名を追加します。
    3
    HTTP プロキシーまたは HTTPS プロキシーのいずれかを指定します。
    4
    kube-apiserver の IP アドレスを追加します。IP アドレスを取得するには、マネージドクラスターで oc -n default describe svc kubernetes | grep IP: コマンドを実行します。
    5
    httpsProxy フィールドで HTTPS プロキシーを指定する場合は、プロキシーサーバー CA バンドルを設定します。

  2. 作成した AddOnDeploymentConfig リソースを参照して、ManagedClusterAddOn リソースを更新します。以下の例を参照してください。 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: ManagedClusterAddOn
metadata:
  name: cluster-proxy
  namespace: <namespace>
    1 
    
spec:
installNamespace: open-cluster-management-addon
configs:
  group: addon.open-cluster-management.io
  resource: addondeploymentconfigs
  name: <name>
    2 
    
  namespace: <namespace>
    3
    Copy to Clipboard Toggle word wrap
1
マネージドクラスター名を追加します。
2
アドオンのデプロイメント設定名を追加します。
3
マネージドクラスター名を追加します。
  1. open-cluster-management-addon namespace 内のクラスタープロキシーエージェント Pod に、マネージドクラスターの HTTPS_PROXY または NO_PROXY 環境変数があるかどうかを確認して、プロキシー設定を検証します。

1.7.10. マネージドクラスターで実行する Ansible Automation Platform タスクの設定
リンクのコピー

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

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

1.7.10.1. 前提条件
リンクのコピー

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

  • OpenShift Container Platform をインストールする。
  • Ansible Automation Platform Resource Operator をインストールして、Ansible ジョブを Git サブスクリプションのライフサイクルに接続している。自動化テンプレートを使用して Ansible Automation Platform ジョブを起動する場合に最良の結果を得るには、Ansible Automation Platform ジョブテンプレートを実行時にべき等にする必要があります。Ansible Automation Platform Resource Operator は、OpenShift Container Platform OperatorHub ページから検索できます。
  • Ansible Automation Platform Resource Operator をインストールするときに、*-cluster-scoped チャネルを選択し、all namespaces インストールモードを選択する。

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

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

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

1.7.10.3. 自動化テンプレートの作成
リンクのコピー

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

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

  1. ナビゲーションから Infrastructure > Automation を選択します。

  2. 状況に適したパスを選択します。

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

  5. 認証情報を選択した後、すべてのジョブに使用する Ansible インベントリーを選択できます。Ansible 認証情報を Ansible テンプレートにリンクするには、以下の手順を実行します。

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

  7. 表示されるモーダルで Job template または Workflow job template を選択します。job_tags、Skip_tags、およびワークフロータイプを追加することもできます。

    • Extra variables フィールドを使用して、キー=値 ペアの形式でデータを AnsibleJob リソースに渡します。
    • 特殊キーの cluster_deployment と install_config は、追加の変数として自動的に渡されます。こちらには、クラスターに関する一般情報とクラスターのインストール設定に関する詳細が含まれています。
  8. クラスターのインストールまたはアップグレードに追加するプリフックおよびポストフックの Ansible ジョブの名前を選択します。
  9. 必要に応じて、Ansible ジョブをドラッグして、順番を変更します。
  10. インストール後の自動化テンプレート セクション、アップグレード前の自動化テンプレート セクション、および アップグレード後の自動化テンプレート セクションでクラスターのインストール後に開始するすべての自動化テンプレートに手順 5 〜 7 を繰り返します。クラスターをアップグレードする場合、Extra variables フィールドを使用して、key=value ペアの形式で AnsibleJob リソースにデータを渡すことができます。cluster_deployment 特殊キーおよび install_config 特殊キーに加えて、cluster_info 特殊キーも、ManagedClusterInfo リソースからのデータを含む追加変数として自動的に渡されます。

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

1.7.10.4. Ansible ジョブのステータスの表示
リンクのコピー

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

  1. メニューで、Infrastructure > Clusters を選択して、Clusters ページにアクセスします。
  2. クラスターの名前を選択して、その詳細を表示します。

  3. クラスター情報で Ansible ジョブの最後の実行ステータスを表示します。エントリーには、以下のステータスの 1 つが表示されます。

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

1.7.10.5. 失敗した Ansible ジョブを再度実行する
リンクのコピー

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

時間を節約するために、クラスター自動化テンプレートの一部である失敗した Ansible ポストフックのみを実行できるようになりました。アップグレード全体を再試行せずに、ポストフックのみを再度実行するには、次の手順を実行します。

  1. 次のコンテンツを ClusterCurator リソースのルートに追加して、インストールポストフックを再度実行します。 

    operation:
  retryPosthook: installPosthook
    Copy to Clipboard Toggle word wrap

  2. 次のコンテンツを ClusterCurator リソースのルートに追加して、アップグレードポストフックを再度実行します。 

    operation:
  retryPosthook: upgradePosthook
    Copy to Clipboard Toggle word wrap

コンテンツを追加すると、Ansible ポストフックを実行するための新しいジョブが作成されます。

1.7.10.6. すべてのジョブに使用する Ansible インベントリーの指定
リンクのコピー

ClusterCurator リソースを使用して、すべてのジョブに使用する Ansible インベントリーを指定できます。以下の例を参照してください。channel と desiredUpdate を ClusterCurator の正しい値に置き換えます。 

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: test-inno
  namespace: test-inno
spec:
  desiredCuration: upgrade
  destroy: {}
  install: {}
  scale: {}
  upgrade:
    channel: stable-4.x
    desiredUpdate: 4.x.1
    monitorTimeout: 150
    posthook:
    - extra_vars: {}
      clusterName: test-inno
      type: post_check
      name: ACM Upgrade Checks
    prehook:
    - extra_vars: {}
      clusterName: test-inno
      type: pre_check
      name: ACM Upgrade Checks
    towerAuthSecret: awx
    inventory: Demo Inventory
Copy to Clipboard Toggle word wrap

注記: サンプルリソースを使用するには、インベントリーが Ansible にすでに存在している必要があります。

コンソールから利用可能な Ansible インベントリーのリストを確認すると、インベントリーが作成されていることを確認できます。

1.7.10.7. ClusterCurator リソースから自動化ジョブ Pod へのカスタムラベルのプッシュ
リンクのコピー

ClusterCurator リソースを使用して、カスタムラベルを Cluster Curator によって作成された自動化ジョブ Pod にプッシュできます。カスタムラベルをすべてのキュレーションタイプにプッシュできます。以下の例を参照してください。 

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: cluster1
{{{}  namespace: cluster1
  labels:
    test1: test1
    test2: test2
{}}}spec:
  desiredCuration: install
  install:
    jobMonitorTimeout: 5
    posthook:
      - extra_vars: {}
        name: Demo Job Template
        type: Job
    prehook:
      - extra_vars: {}
        name: Demo Job Template
        type: Job
    towerAuthSecret: toweraccess
Copy to Clipboard Toggle word wrap

1.7.10.8. Extended Update Support (EUS) アップグレードに ClusterCurator を使用する
リンクのコピー

ClusterCurator リソースを使用すると、EUS リリース間のアップグレードをより簡単に自動で実行できます。

  1. spec.upgrade.intermediateUpdate を ClusterCurator リソースに追加し、中間リリースの値を指定します。次のサンプルを参照してください。中間リリースは 4.14.x で、desiredUpdate は 4.15.x です。 

    spec:
  desiredCuration: upgrade
  upgrade:
    intermediateUpdate: 4.14.x
    desiredUpdate: 4.15.x
    monitorTimeout: 120
    Copy to Clipboard Toggle word wrap

  2. オプション: machineconfigpools を一時停止すると、中間リリースをスキップしてアップグレードを迅速化できます。posthook ジョブに Unpause machinepool と入力し、prehook ジョブに pause machinepool と入力します。以下の例を参照してください。 

        posthook:
      - extra_vars: {}
        name: Unpause machinepool
        type: Job
    prehook:
      - extra_vars: {}
        name: Pause machinepool
        type: Job
    Copy to Clipboard Toggle word wrap

EUS から EUS にアップグレードするように設定された ClusterCurator の完全な例を次に示します。 

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  annotations:
    cluster.open-cluster-management.io/upgrade-clusterversion-backoff-limit: "10"
  name: your-name
  namespace: your-namespace
spec:
  desiredCuration: upgrade
 upgrade:
    intermediateUpdate: 4.14.x
    desiredUpdate: 4.15.x
    monitorTimeout: 120
    posthook:
      - extra_vars: {}
        name: Unpause machinepool
        type: Job
    prehook:
      - extra_vars: {}
        name: Pause machinepool
        type: Job
Copy to Clipboard Toggle word wrap

1.7.11. Ansible Automation Platform ジョブをホステッドクラスター上で実行されるように設定
リンクのコピー

Red Hat Ansible Automation Platform は multicluster engine Operator と統合されているため、ホステッドクラスターの作成または更新の前後に実行される prehook および posthook Ansible Automation Platform ジョブインスタンスを作成できます。

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

1.7.11.1. 前提条件
リンクのコピー

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

  • サポートされているバージョンの OpenShift Container Platform
  • Ansible Automation Platform Resource Operator をインストールして、Ansible Automation Platform ジョブを Git サブスクリプションのライフサイクルに接続する。Automation テンプレートを使用して Ansible Automation Platform ジョブを開始する場合は、実行時に Ansible Automation Platform ジョブテンプレートが冪等である。Ansible Automation Platform Resource Operator は、OpenShift Container Platform OperatorHub ページから検索できます。

1.7.11.2. Ansible Automation Platform ジョブを実行してホステッドクラスターをインストールする
リンクのコピー

ホステッドクラスターをインストールする Ansible Automation Platform ジョブを開始するには、次の手順を実行します。

  1. pausedUntil: true フィールドを含む HostedCluster および NodePool リソースを作成します。hcp create cluster コマンドラインインターフェイスコマンドを使用する場合は、--pausedUntil: true フラグを指定できます。

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

    apiVersion: hypershift.openshift.io/v1beta1
kind: HostedCluster
metadata:
  name: my-cluster
  namespace: clusters
spec:
  pausedUntil: 'true'
    Copy to Clipboard Toggle word wrap 
    apiVersion: hypershift.openshift.io/v1beta1
kind: NodePool
metadata:
  name: my-cluster-us-east-2
  namespace: clusters
spec:
  pausedUntil: 'true'
    Copy to Clipboard Toggle word wrap

  2. HostedCluster リソースと同じ名前と HostedCluster リソースと同じ namespace で、ClusterCurator リソースを作成します。以下の例を参照してください。 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: my-cluster
  namespace: clusters
  labels:
    open-cluster-management: curator
spec:
  desiredCuration: install
  install:
    jobMonitorTimeout: 5
    prehook:
      - name: Demo Job Template
        extra_vars:
          variable1: something-interesting
          variable2: 2
      - name: Demo Job Template
    posthook:
      - name: Demo Job Template
    towerAuthSecret: toweraccess
    Copy to Clipboard Toggle word wrap

  3. Ansible Automation Platform Tower で認証が必要な場合は、シークレットリソースを作成します。以下の例を参照してください。 

    apiVersion: v1
kind: Secret
metadata:
  name: toweraccess
  namespace: clusters
stringData:
  host: https://my-tower-domain.io
  token: ANSIBLE_TOKEN_FOR_admin
    Copy to Clipboard Toggle word wrap

1.7.11.3. Ansible Automation Platform ジョブを実行してホステッドクラスターを更新する
リンクのコピー

ホステッドクラスターを更新する Ansible Automation Platform ジョブを実行するには、更新するホステッドクラスターの ClusterCurator リソースを編集します。以下の例を参照してください。 

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: my-cluster
  namespace: clusters
  labels:
    open-cluster-management: curator
spec:
  desiredCuration: upgrade
  upgrade:
    desiredUpdate: 4.15.1
1 

    monitorTimeout: 120
    prehook:
      - name: Demo Job Template
        extra_vars:
          variable1: something-interesting
          variable2: 2
      - name: Demo Job Template
    posthook:
      - name: Demo Job Template
    towerAuthSecret: toweraccess
Copy to Clipboard Toggle word wrap
1
サポート対象バージョンの詳細は、Hosted Control Plane を参照してください。

注: この方法でホステッドクラスターを更新すると、Hosted Control Plane とノードプールの両方が同じバージョンに更新されます。Hosted Control Plane とノードプールを別のバージョンに更新することはサポートされていません。

1.7.11.4. Ansible Automation Platform ジョブを実行してホステッドクラスターを削除する
リンクのコピー

ホステッドクラスターを削除する Ansible Automation Platform ジョブを実行するには、削除するホステッドクラスターの ClusterCurator リソースを編集します。以下の例を参照してください。 

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ClusterCurator
metadata:
  name: my-cluster
  namespace: clusters
  labels:
    open-cluster-management: curator
spec:
  desiredCuration: destroy
  destroy:
    jobMonitorTimeout: 5
    prehook:
      - name: Demo Job Template
        extra_vars:
          variable1: something-interesting
          variable2: 2
      - name: Demo Job Template
    posthook:
      - name: Demo Job Template
    towerAuthSecret: toweraccess
Copy to Clipboard Toggle word wrap

注記: AWS 上のホステッドクラスターの削除はサポートされていません。

1.7.11.5. 関連情報
リンクのコピー

1.7.12. ClusterClaims
リンクのコピー

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

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

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

次の表は、multicluster engine Operator が管理するクラスターの定義済み ClusterClaim のリストを示しています。

Expand
要求名予約変更可能説明

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 リソースのステータスと同期されます。以下に示す ManagedCluster の clusterClaims の例を参照してください。4.x は、OpenShift Container Platform のサポートされているバージョンに置き換えます。 

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.x'
  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
Copy to Clipboard Toggle word wrap

1.7.12.1. カスタム ClusterClaims の作成
リンクのコピー

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

apiVersion: cluster.open-cluster-management.io/v1alpha1
kind: ClusterClaim
metadata:
  name: <custom_claim_name>
spec:
  value: <custom_claim_value>
Copy to Clipboard Toggle word wrap

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

1.7.12.2. 既存の ClusterClaim の表示
リンクのコピー

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

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

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

kubectl get clusterclaims.cluster.open-cluster-management.io
Copy to Clipboard Toggle word wrap

1.7.13. ManagedClusterSets
リンクのコピー

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

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

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

1.7.13.1. ManagedClusterSet の作成
リンクのコピー

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

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

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

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

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

  • global と呼ばれる ManagedClusterSet。
  • open-cluster-management-global-set という namespace。

  • global と呼ばれる ManagedClusterSetBinding は、global ManagedClusterSet を open-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
    Copy to Clipboard Toggle word wrap
1.7.13.1.1. CLI を使用した ManagedClusterSet の作成
リンクのコピー

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

apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSet
metadata:
  name: <cluster_set>
Copy to Clipboard Toggle word wrap

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

1.7.13.1.2. クラスターの ManagedClusterSet への追加
リンクのコピー

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

1.7.13.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"]
    Copy to Clipboard Toggle word wrap

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

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

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

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: <cluster_name>
spec:
  hubAcceptsClient: true
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

1.7.13.2. ManagedClusterSet への RBAC 権限の割り当て
リンクのコピー

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

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

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

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

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 ロールを選択して、選択したユーザーまたはグループに付与します。詳細は、multicluster engine Operator のロールベースのアクセス制御 の ロールの概要 を参照してください。
  8. Add を選択して変更を送信します。

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

placement 情報は、ManagedCusterSets からの ManagedClusters のフィルタリング を参照してください。

1.7.13.3. ManagedClusterSetBinding リソースの作成
リンクのコピー

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

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

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

1.7.13.3.1. コンソールを使用した ManagedClusterSetBinding の作成
リンクのコピー

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

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

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

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

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

    apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSetBinding
metadata:
  namespace: <namespace>
  name: <cluster_set>
spec:
  clusterSet: <cluster_set>
    Copy to Clipboard Toggle word wrap

  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"]
    Copy to Clipboard Toggle word wrap

1.7.13.4. taint と toleration を使用したマネージドクラスターの配置
リンクのコピー

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

1.7.13.4.1. マネージドクラスターへの taint の追加
リンクのコピー

taint はマネージドクラスターのプロパティーで指定され、placement がマネージドクラスターまたはマネージドクラスターのセットを除外できます。

taint セクションが存在しない場合は、次の例のようなコマンドを実行して、マネージドクラスターに taint を追加できます。 

oc patch managedcluster <managed_cluster_name> -p '{"spec":{"taints":[{"key": "key", "value": "value", "effect": "NoSelect"}]}}' --type=merge
Copy to Clipboard Toggle word wrap

または、次の例のようなコマンドを実行して、既存の taint に taint を追加することもできます。 

oc patch managedcluster <managed_cluster_name> --type='json' -p='[{"op": "add", "path": "/spec/taints/-", "value": {"key": "key", "value": "value", "effect": "NoSelect"}}]'
Copy to Clipboard Toggle word wrap

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.7.13.4.2. マネージドクラスターのステータスを反映させる組み込み taint の特定
リンクのコピー

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

  • cluster.open-cluster-management.io/unavailable: この taint は、ステータスが False の ManagedClusterConditionAvailable の条件がある場合にマネージドクラスターに追加されます。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'
    Copy to Clipboard Toggle word wrap

  • 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'
    Copy to Clipboard Toggle word wrap
1.7.13.4.3. toleration の placement への追加
リンクのコピー

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

  • (任意) Key: キーは placement ができるように taint キーに一致します。
  • (任意) Value: toleration の値は、placement を許可する toleration の taint の値と一致する必要があります。

  • (任意) Operator: 演算子はキーと値の関係を表します。有効な演算子は equal と exists です。デフォルト値は equal です。toleration は、キーが同じ場合、効果が同じ場合、さらび Operator が以下の値のいずれかである場合に、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'
    Copy to Clipboard Toggle word wrap

  • 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
    Copy to Clipboard Toggle word wrap

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

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

1.7.13.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'
Copy to Clipboard Toggle word wrap

以下の例のように、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
Copy to Clipboard Toggle word wrap

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

1.7.13.4.5. 関連情報
リンクのコピー

1.7.13.5. ManagedClusterSet からのマネージドクラスターの削除
リンクのコピー

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

注記:

  • マネージドクラスターはすべて、マネージドクラスターセットに割り当てる必要があります。ManagedClusterSet からマネージドクラスターを削除し、別の ManagedClusterSet に割り当てない場合は、そのクラスターは default のマネージドクラスターセットに自動的に追加されます。
  • Submariner アドオンがマネージドクラスターにインストールされている場合は、アドオンをアンインストールしてから、マネージドクラスターを ManagedClusterSet から削除する必要があります。
1.7.13.5.1. コンソールを使用した ManagedClusterSet からのクラスターの削除
リンクのコピー

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

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

  4. Manage resource assignments ページで、クラスターセットから削除するリソースのチェックボックスをオフにします。

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

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

1.7.13.5.2. CLI を使用した ManagedClusterSet からのクラスターの削除
リンクのコピー

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

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

    oc get managedclusters -l cluster.open-cluster-management.io/clusterset=<cluster_set>
    Copy to Clipboard Toggle word wrap

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

  2. 削除するクラスターのエントリーを見つけます。

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

    labels:
   cluster.open-cluster-management.io/clusterset: clusterset1
    Copy to Clipboard Toggle word wrap

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

1.7.14. Placement
リンクのコピー

placement リソースは、placement namespace にバインドされている ManagedClusterSets から ManagedClusters のセットを選択するルールを定義する、namespace スコープのリソースです。

必要なアクセス権: クラスター管理者、クラスターセット管理者

プレースメントの使用方法の詳細は、読み続けてください。

1.7.14.1. Placement の概要
リンクのコピー

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

  • Kubernetes クラスターは、cluster スコープの ManagedClusters としてハブクラスターに登録されます。
  • ManagedClusters は、クラスタースコープの ManagedClusterSets に編成されます。
  • ManagedClusterSets はワークロード namespace にバインドされます。
  • namespace スコープの placement では、潜在的な ManagedClusters の作業セットを選択する ManagedClusterSets の一部を指定します。
  • placement は、labelSelector と claimSelector を使用して、ManagedClusterSets から ManagedClusters をフィルター処理します。
  • ManagedClusters の placement は、taint と toleration を使用して制御できます。
  • placement は、Prioritizers スコアによってクラスターを並べ替え、そのグループから上位 n 個のクラスターを選択します。n は numberOfClusters で定義できます。
  • 配置では、削除するマネージドクラスターは選択されません。

注記:

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

1.7.14.2. ManagedClusterSets から ManagedClusters を選択する
リンクのコピー

labelSelector または claimSelector を使用して、フィルタリングする ManagedClusters を選択できます。両方のフィルターの使用方法は、次の例を参照してください。

  • 次の例では、labelSelector はラベル vendor: OpenShift を持つクラスターのみを照合します。 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchLabels:
            vendor: OpenShift
    Copy to Clipboard Toggle word wrap

  • 次の例では、claimSelector は、region.open-cluster-management.io と us-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
    Copy to Clipboard Toggle word wrap

    • また、clusterSets パラメーターを使用して、特定のクラスターセットから ManagedClusters をフィルター処理することもできます。次の例では、claimSelector はクラスターセット 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
      Copy to Clipboard Toggle word wrap

また、numberOfClusters パラメーターを使用して、フィルタリングする ManagedClusters の数を選択することもできます。以下の例を参照してください。 

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  numberOfClusters: 3
1 

  predicates:
    - requiredClusterSelector:
        labelSelector:
          matchLabels:
            vendor: OpenShift
        claimSelector:
          matchExpressions:
            - key: region.open-cluster-management.io
              operator: In
              values:
                - us-west-1
Copy to Clipboard Toggle word wrap
1
選択する ManagedClusters の数を指定します。前の例では 3 に設定されています。
1.7.14.2.1. placement を使用して toleration を定義することで ManagedClusters をフィルタリングする
リンクのコピー

一致するテイントを使用して ManagedClusters をフィルタリングする方法は、次の例を参照してください。

  • デフォルトでは、次の例では、placement で cluster1 を選択できません。 

    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'
    Copy to Clipboard Toggle word wrap

    cluster1 を選択するには、許容範囲を定義する必要があります。以下の例を参照してください。 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  tolerations:
    - key: gpu
      value: "true"
      operator: Equal
    Copy to Clipboard Toggle word wrap

tolerationSeconds パラメーターを使用して、指定した期間、一致するテイントを持つ ManagedClusters を選択することもできます。tolerationSeconds は、許容がテイントにバインドされ続ける期間を定義します。tolerationSeconds は、指定された時間が経過すると、オフラインになったクラスターにデプロイされたアプリケーションを別のマネージドクラスターに自動的に転送できます。

次の例を見て、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'
    Copy to Clipboard Toggle word wrap

    tolerationSeconds を使用して配置を定義すると、ワークロードは別の使用可能なマネージドクラスターに転送されます。以下の例を参照してください。 

    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
    Copy to Clipboard Toggle word wrap
    1
    何秒後にワークロードを転送するかを指定します。
1.7.14.2.2. アドオンのステータスに基づき ManagedClusters をフィルタリングする
リンクのコピー

デプロイされているアドオンのステータスに基づいて、プレースメント用のマネージドクラスターを選択することもできます。たとえば、マネージドクラスターで有効になっている特定のアドオンがある場合にのみ、placement にマネージドクラスターを選択できます。

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

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

addon_name を選択したマネージドクラスターで有効にするアドオンの名前に置き換えます。

status_of_addon をマネージドクラスターが選択されている場合にアドオンに設定するステータスに置き換えます。

status_of_addon に指定できる値は、次の表を参照してください。

Expand
値説明

available

アドオンは有効化されており、利用可能です。

unhealthy

アドオンは有効ですが、リースは継続的に更新されません。

unreachable

アドオンは有効ですが、そのアドオンのリースが見つかりません。これは、マネージドクラスターがオフライン時にも発生する可能性があります。

たとえば、使用可能な application-manager. アドオンは、マネージドクラスター上の次のようなラベルで表されます。 

feature.open-cluster-management.io/addon-application-manager: available
Copy to Clipboard Toggle word wrap

アドオンとそのステータスに基づいて placement を作成する方法は、次の例を参照してください。

  • 次の placement 例には、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
    Copy to Clipboard Toggle word wrap

  • 次の placement 例には、application-manager が available ステータスで有効になっているすべてのマネージドクラスターが含まれています。 

    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"
    Copy to Clipboard Toggle word wrap

  • 次の placement 例には、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
    Copy to Clipboard Toggle word wrap

次の例を参照して、prioritizerPolicy パラメーターと配置を使用して ManagedClusters に優先順位を付ける方法を学習します。

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

    注記: 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
    Copy to Clipboard Toggle word wrap

  • 次の例では、割り当て可能な最大の 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
    Copy to Clipboard Toggle word wrap

  • 次の例では、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
    Copy to Clipboard Toggle word wrap
1.7.14.2.4. 関連情報
リンクのコピー

1.7.14.3. PlacementDecisions を使用して選択した ManagedClusters を確認する
リンクのコピー

ラベル cluster.open-cluster-management.io/placement={placement_name} を持つ 1 つ以上の PlacementDecision 種類が、プレースメントによって選択された ManagedClusters を表すために作成されます。

ManagedCluster を選択して PlacementDecision に追加すると、この placement を使用するコンポーネントがこの ManagedCluster にワークロードを適用する可能性があります。

ManagedCluster を選択せずに PlacementDecision から削除すると、この ManagedCluster に適用されているワークロードが削除されます。toleration を定義することで、ワークロードの削除を回避できます。

toleration の定義の詳細は、placement を使用して toleration を定義することで ManagedClusters をフィルタリングする を参照してください。

次の 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: ''
Copy to Clipboard Toggle word wrap
1.7.14.3.1. 関連情報
リンクのコピー

1.7.15. クラスタープールの管理 (テクノロジープレビュー)
リンクのコピー

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

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

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

1.7.15.1. クラスタープールの作成
リンクのコピー

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

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

1.7.15.1.1. 前提条件
リンクのコピー

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

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

注記: この手順でクラスタープールを追加すると、プールからクラスターを要求するときに、multicluster engine Operator で管理するために、クラスターを自動的にインポートするようにクラスタープールが設定されます。クラスター要求を使用して管理するために、要求されたクラスターを自動的にインポートしないクラスタープールを作成する場合は、clusterClaim リソースに次のアノテーションを追加してください。 

kind: ClusterClaim
metadata:
  annotations:
    cluster.open-cluster-management.io/createmanagedcluster: "false"
1
Copy to Clipboard Toggle word wrap
1
文字列であることを示すには、"false" という単語を引用符で囲む必要があります。
1.7.15.1.2. クラスタープールを作成する
リンクのコピー

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

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

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

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

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

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

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

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

1.7.15.2. クラスタープールからのクラスターの要求
リンクのコピー

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

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

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

1.7.15.2.1. 前提条件
リンクのコピー

使用可能なクラスターの有無にかかわらず、クラスタープールが必要です。クラスタープールに利用可能なクラスターがある場合、利用可能なクラスターが要求されます。クラスタープールに利用可能なクラスターがない場合は、要求を満たすためにクラスターが作成されます。クラスタープールの作成方法は、クラスタープールの作成 を参照してください。

1.7.15.2.2. クラスタープールからのクラスターの要求
リンクのコピー

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

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

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

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

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

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

1.7.15.3. クラスタープールリリースイメージの更新
リンクのコピー

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

必要なアクセス: 編集

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

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

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

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

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

1.7.15.4. Scaling cluster pools (Technology Preview)
リンクのコピー

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

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

クラスタープールのクラスター数を変更するには、以下の手順を実行します。

  1. ナビゲーションメニューから Infrastructure > Clusters をクリックします。
  2. Cluster pools タブを選択します。
  3. 変更するクラスタープールの Options メニューで、Scale cluster pool を選択します。
  4. プールサイズの値を変更します。
  5. オプションで、実行中のクラスターの数を更新して、要求時にすぐに利用可能なクラスター数を増減できます。

クラスタープールは、新しい値を反映するようにスケーリングされます。

1.7.15.5. クラスタープールの破棄
リンクのコピー

クラスタープールを作成し、不要になった場合は、そのクラスタープールを破棄できます。

重要: クラスター要求がないクラスタープールのみ破棄できます。

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

クラスタープールを破棄するには、以下の手順を実行します。

  1. ナビゲーションメニューから Infrastructure > Clusters をクリックします。
  2. Cluster pools タブを選択します。

  3. 削除するクラスタープールの Options メニューで、確認ボックスに confirm と入力して Destroy を選択します。

    注記:

    • クラスタープールにクラスター要求がある場合、Destroy ボタンは無効になります。
    • クラスタープールを含む namespace は削除されません。namespace を削除すると、これらのクラスターのクラスター要求リソースが同じ namespace で作成されるため、クラスタープールから要求されたクラスターが破棄されます。

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

1.7.16. ManagedServiceAccount アドオンの有効化
リンクのコピー

サポートされているバージョンの multicluster engine Operator をインストールすると、ManagedServiceAccount アドオンがデフォルトで有効になります。

重要: ハブクラスターを multicluster engine Operator バージョン 2.4 からアップグレードし、アップグレード前に ManagedServiceAccount アドオンを有効にしていなかった場合は、アドオンを手動で有効にする必要があります。

ManagedServiceAccount を使用すると、マネージドクラスターでサービスアカウントを作成または削除できます。

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

ManagedServiceAccount カスタムリソースがハブクラスターの <managed_cluster> namespace に作成されると、ServiceAccount がマネージドクラスターに作成されます。

TokenRequest は、マネージドクラスターの ServiceAccount を使用して、マネージドクラスターの Kubernetes API サーバーに対して行われます。トークンは、ハブクラスターの <target_managed_cluster> namespace の Secret に保存されます。

注記 トークンは期限切れになり、ローテーションされる可能性があります。トークンリクエストの詳細は、TokenRequest を参照してください。

1.7.16.1. 前提条件
リンクのコピー

  • サポートされている Red Hat OpenShift Container Platform 環境がある。
  • multicluster engine Operator がインストールされている。

1.7.16.2. ManagedServiceAccount の有効化
リンクのコピー

ハブクラスターとマネージドクラスターの ManagedServiceAccount アドオンを有効にするには、次の手順を実行します。

  1. ハブクラスターで ManagedServiceAccount アドオンを有効にします。詳細は、詳細設定 を参照してください。

  2. ManagedServiceAccount アドオンをデプロイし、それをターゲットのマネージドクラスターに適用します。次の YAML ファイルを作成し、target_managed_cluster を Managed-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
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを実行して、ファイルを適用します。 

    oc apply -f -
    Copy to Clipboard Toggle word wrap

    これで、マネージドクラスターの ManagedServiceAccount プラグインが有効になりました。ManagedServiceAccount を設定するには、次の手順を参照してください。

  4. 次の YAML ソースを使用して ManagedServiceAccount カスタムリソースを作成します。 

    apiVersion: authentication.open-cluster-management.io/v1alpha1
kind: ManagedServiceAccount
metadata:
  name: <managedserviceaccount_name>
  namespace: <target_managed_cluster>
spec:
  rotation: {}
    Copy to Clipboard Toggle word wrap
    • managed_serviceaccount_name を ManagedServiceAccount の名前に置き換えます。
    • target_managed_cluster を、ManagedServiceAccount を適用するマネージドクラスターの名前に置き換えます。

  5. 確認するには、ManagedServiceAccount オブジェクトのステータスで tokenSecretRef 属性を表示して、シークレット名と namespace を見つけます。アカウントとクラスター名を使用して次のコマンドを実行します。 

    oc get managedserviceaccount <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml
    Copy to Clipboard Toggle word wrap

  6. マネージドクラスターで作成された ServiceAccount に接続されている取得されたトークンを含む Secret を表示します。以下のコマンドを実行します。 

    oc get secret <managed_serviceaccount_name> -n <target_managed_cluster> -o yaml
    Copy to Clipboard Toggle word wrap

1.7.17. クラスターのライフサイクルの詳細設定
リンクのコピー

一部のクラスター設定は、インストール中またはインストール後に設定できます。

1.7.17.1. API サーバー証明書のカスタマイズ
リンクのコピー

マネージドクラスターは、OpenShift Kube API サーバーの外部ロードバランサーとの相互接続を介してハブクラスターと通信します。デフォルトの OpenShift Kube API サーバー証明書は、OpenShift Container Platform のインストール時に内部 Red Hat OpenShift Container Platform クラスター認証局 (CA) によって発行されます。必要に応じて、証明書を追加または変更できます。

API サーバー証明書を変更すると、マネージドクラスターとハブクラスター間の通信に影響を与える可能性があります。製品をインストールする前に名前付き証明書を追加すると、マネージドクラスターがオフライン状態になる可能性がある問題を回避できます。

次のリストには、証明書の更新が必要となる場合の例がいくつか含まれています。

  • 外部ロードバランサーのデフォルトの API サーバー証明書を独自の証明書に置き換える必要がある。OpenShift Container Platform ドキュメントの API サーバー証明書の追加 のガイダンスに従い、ホスト名 api.<cluster_name>.<base_domain> の名前付き証明書を追加して、外部ロードバランサーのデフォルトの API サーバー証明書を置き換えることができます。証明書を置き換えると、マネージドクラスターの一部がオフライン状態に移行する可能性があります。証明書のアップグレード後にクラスターがオフライン状態になった場合は、Troubleshooting imported clusters offline after certificate change のトラブルシューティング手順に従って問題を解決してください。

    注記: 製品をインストールする前に名前付き証明書を追加すると、クラスターがオフライン状態に移行するのを回避できます。

  • 外部ロードバランサーの名前付き証明書の有効期限が切れているため、証明書を置き換える必要がある。中間証明書の数に関係なく、古い証明書と新しい証明書の両方が同じルート CA 証明書を共有する場合は、OpenShift Container Platform ドキュメントの API サーバー証明書の追加 のガイダンスに従って、新しい証明書の新しいシークレットを作成できます。次に、ホスト名 api.<cluster_name>.<base_domain> のサービス証明書参照を APIServer カスタムリソース内の新しいシークレットに更新します。それ以外の場合、古い証明書と新しい証明書に異なるルート CA 証明書がある場合は、次の手順を実行して証明書を置き換えます。

    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
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、既存の証明書と新しい証明書の内容を含む新しいシークレットを openshift-config namespace に作成します。

      1. 古い証明書を新しい証明書にコピーします。 

        cp old.crt combined.crt
        Copy to Clipboard Toggle word wrap

      2. 新しい証明書の内容を古い証明書のコピーに追加します。 

        cat new.crt >> combined.crt
        Copy to Clipboard Toggle word wrap

      3. 結合した証明書を適用してシークレットを作成します。 

        oc create secret tls combined-certs-secret --cert=combined.crt --key=old.key -n openshift-config
        Copy to Clipboard Toggle word wrap

    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
      Copy to Clipboard Toggle word wrap
    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}
      Copy to Clipboard Toggle word wrap

    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
      Copy to Clipboard Toggle word wrap

      約 15 分後、古い証明書が CA バンドルから削除され、変更がマネージドクラスターに自動的に伝播されます。

注記: マネージドクラスターは、ホスト名 api.<cluster_name>.<base_domain> を使用してハブクラスターにアクセスする必要があります。他のホスト名で設定された名前付き証明書は使用できません。

1.7.17.2. ハブクラスターとマネージドクラスター間のプロキシーの設定
リンクのコピー

マネージドクラスターを multicluster engine for Kubernetes Operator に登録するには、マネージドクラスターを multicluster engine Operator ハブクラスターに転送する必要があります。場合によっては、マネージドクラスターが multicluster engine Operator ハブクラスターに直接アクセスできないことがあります。この例では、マネージドクラスターからの通信が HTTP または HTTPS プロキシーサーバー経由で multicluster engine Operator ハブクラスターにアクセスできるようにプロキシー設定を指定します。

たとえば、multicluster engine Operator ハブクラスターはパブリッククラウドにあり、マネージドクラスターはファイアウォールの背後にあるプライベートクラウド環境にあります。プライベートクラウドからの通信は、HTTP または HTTPS プロキシーサーバーのみを経由できます。

1.7.17.2.1. 前提条件
リンクのコピー
  • HTTP トンネルをサポートする HTTP または HTTPS プロキシーサーバーが実行されている。(例: HTTP connect メソッド)
  • HTTP または HTTPS プロキシーサーバーに到達できるマネージドクラスターがあり、プロキシーサーバーが multicluster engine Operator ハブクラスターにアクセスできる。

ハブクラスターとマネージドクラスターとの間でプロキシー設定を指定するには、以下の手順を実行します。

  1. プロキシー設定を使用して KlusterConfig リソースを作成します。

    1. 以下の HTTP プロキシー設定を参照してください。 

      apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: http-proxy
spec:
  hubKubeAPIServerConfig:
    proxyURL: "http://<username>:<password>@<ip>:<port>"
      Copy to Clipboard Toggle word wrap

    2. 以下の HTTPS プロキシー設定を参照してください。 

      apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: https-proxy
spec:
  hubKubeAPIServerConfig:
    proxyURL: "https://<username>:<password>@<ip>:<port>"
    trustedCABundles:
    - name: "proxy-ca-bundle"
      caBundle:
        name: <configmap-name>
        namespace: <configmap-namespace>
      Copy to Clipboard Toggle word wrap

      注記: HTTPS プロキシーには CA バンドルが必要です。CA バンドルとは、1 つまたは複数の CA 証明書を含む ConfigMap を指します。この ConfigMap は次のコマンドを実行すると作成できます。 

      oc create -n <configmap-namespace> configmap <configmap-name> --from-file=ca.crt=/path/to/ca/file
      Copy to Clipboard Toggle word wrap

  2. マネージドクラスターの作成時に、KlusterletConfig リソースを参照するアノテーションを追加して、KlusterletConfig リソースを選択します。以下の例を参照してください。 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    agent.open-cluster-management.io/klusterlet-config: <klusterlet-config-name>
  name:<managed-cluster-name>
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60
    Copy to Clipboard Toggle word wrap

    注記:

    • multicluster engine Operator コンソールで操作する場合、YAML ビューを切り替えて、ManagedCluster リソースにアノテーションを追加することが必要になる場合があります。
    • グローバルの KlusterletConfig を使用して、バインドにアノテーションを使用せずにすべてのマネージドクラスターで設定を有効化できます。
1.7.17.2.2. ハブクラスターとマネージドクラスター間のプロキシーの無効化
リンクのコピー

開発が変更された場合は、HTTP または HTTPS プロキシーを無効にする必要がある場合があります。

  1. ManagedCluster リソースに移動します。
  2. agent.open-cluster-management.io/klusterlet-config アノテーションを削除します。
1.7.17.2.3. オプション: 特定のノードで実行するように klusterlet を設定する
リンクのコピー

Red Hat Advanced Cluster Management for Kubernetes を使用してクラスターを作成する場合、マネージドクラスターの nodeSelector および tolerations アノテーションを設定することで、マネージドクラスター klusterlet を実行するノードを指定できます。これらを設定するには、次の手順を実行します。

  1. コンソールのクラスターページから、更新するマネージドクラスターを選択します。

  2. YAML コンテンツを表示するには、YAML スイッチを On に設定します。

    注記: YAML エディターは、クラスターをインポートまたは作成するときにのみ使用できます。インポートまたは作成後にマネージドクラスターの YAML 定義を編集するには、OpenShift Container Platform コマンドラインインターフェイスまたは Red Hat Advanced Cluster Management 検索機能を使用する必要があります。

  3. nodeSelector アノテーションをマネージドクラスターの YAML 定義に追加します。このアノテーションのキーは、open-cluster-management/nodeSelector です。このアノテーションの値は、JSON 形式の文字列マップです。

  4. tolerations エントリーをマネージドクラスターの YAML 定義に追加します。このアノテーションのキーは、open-cluster-management/tolerations です。このアノテーションの値は、JSON 形式の toleration リストを表します。結果の YAML は次の例のようになります。 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    open-cluster-management/nodeSelector: '{"dedicated":"acm"}'
    open-cluster-management/tolerations: '[{"key":"dedicated","operator":"Equal","value":"acm","effect":"NoSchedule"}]'
    Copy to Clipboard Toggle word wrap
  5. コンテンツが正しいノードにデプロイされていることを確認するには、klusterlet アドオンの nodeSelectors と tolerations の設定 の手順を完了します。

マネージドクラスターとハブクラスターの間に中間コンポーネントが存在する場合、multicluster engine Operator ハブクラスターにマネージドクラスターを登録できない可能性があります。中間コンポーネントの例には、仮想 IP、ロードバランサー、リバースプロキシー、API ゲートウェイなどがあります。中間コンポーネントがある場合は、マネージドクラスターをインポートするときに、ハブクラスター API サーバーのカスタムサーバー URL と CA バンドルを使用する必要があります。

1.7.17.3.1. 前提条件
リンクのコピー
  • マネージドクラスターからハブクラスター API サーバーにアクセスできるように、中間コンポーネントを設定する必要があります。

  • 中間コンポーネントがマネージドクラスターとハブクラスター API サーバー間の SSL 接続を終端する場合は、SSL 接続をブリッジし、元のリクエストからの認証情報をハブクラスター API サーバーのバックエンドに渡す必要があります。Kubernetes API サーバーのユーザー偽装機能を使用すると、SSL 接続をブリッジできます。

    中間コンポーネントは、元のリクエストからクライアント証明書を抽出し、証明書サブジェクトのコモンネーム (CN) と組織 (O) を偽装ヘッダーとして追加し、変更された偽装リクエストをハブクラスター API サーバーのバックエンドに転送します。

    注記: SSL 接続をブリッジすると、クラスタープロキシーアドオンが機能しなくなります。

1.7.17.3.2. サーバー URL とハブクラスター CA バンドルのカスタマイズ
リンクのコピー

マネージドクラスターをインポートするときにカスタムハブ API サーバー URL と CA バンドルを使用するには、次の手順を実行します。

  1. カスタムのハブクラスター API サーバー URL と CA バンドルを使用して KlusterConfig リソースを作成します。以下の例を参照してください。 

    apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: <name>
    1 
    
spec:
  hubKubeAPIServerConfig:
    url: "https://api.example.com:6443"
    2 
    
    serverVerificationStrategy: UseCustomCABundles
    trustedCABundles:
    - name: <custom-ca-bundle>
    3 
    
      caBundle:
        name: <custom-ca-bundle-configmap>
    4 
    
        namespace: <multicluster-engine>
    5
    Copy to Clipboard Toggle word wrap
    1
    klusterlet 設定名を追加します。
    2
    カスタムサーバー URL を追加します。
    3
    カスタム CA バンドル名を追加します。内部使用のために予約されている auto-detected 以外の任意の値を使用できます。
    4
    CA バンドル ConfigMap の名前を追加します。ConfigMap を作成するには、コマンド oc create -n <configmap-namespace> configmap <configmap-name> --from-file=ca.crt=/path/to/ca/file を実行します。
    5
    CA バンドル ConfigMap の namespace を追加します。

  2. マネージドクラスターを作成するときに、リソースを参照するアノテーションを追加して KlusterletConfig リソースを選択します。以下の例を参照してください。 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    agent.open-cluster-management.io/klusterlet-config:
    1 
    
  name:
    2 
    
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60
    Copy to Clipboard Toggle word wrap
    1
    klusterlet 設定名を追加します。
    2
    クラスター名を追加します。

    注記:

    • コンソールを使用する場合は、ManagedCluster リソースにアノテーションを追加するために、YAML ビューを有効にする必要がある場合があります。
    • グローバルの KlusterletConfig を使用して、バインドにアノテーションを使用せずにすべてのマネージドクラスターで設定を有効化できます。
1.7.17.3.3. グローバル KlusterletConfig の設定
リンクのコピー

KlusterletConfig リソースを作成し、名前を global に設定すると、グローバル KlusterletConfig 内の設定が全マネージドクラスターに自動的に適用されます。

グローバルの KlusterletConfig がある環境では、agent.open-cluster-management.io/klusterlet-config: <klusterletconfig-name> アノテーションを ManagedCluster リソースに追加することで、クラスター固有の KlusterletConfig を作成し、それをマネージドクラスターにバインドすることもできます。同じフィールドに異なる値を設定した場合、クラスター固有の KlusterletConfig の値によってグローバルの KlusterletConfig の値がオーバーライドされます。

次の例では、hubKubeAPIServerURL フィールドに、KlusterletConfig とグローバル KlusterletConfig で異なる値が設定されています。"https://api.example.test.com:6443" 値によって "https://api.example.global.com:6443" 値がオーバーライドされます。

非推奨: hubKubeAPIServerURL フィールドは非推奨です。 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: test
spec:
  hubKubeAPIServerConfig:
    url: "https://api.example.test.com:6443"
---
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerConfig:
    url: "https://api.example.global.com:6443"
Copy to Clipboard Toggle word wrap

マネージドクラスターにバインドされたクラスター固有の KlusterletConfig がない場合、またはクラスター固有の KlusterletConfig に同じフィールドが存在しないか値がない場合には、グローバル KlusterletConfig の値が使用されます。

次の例を参照してください。ここでは、グローバル KlusterletConfig の hubKubeAPIServerURL フィールドの "example.global.com" 値が KlusterletConfig をオーバーライドします。 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: test
spec:
  hubKubeAPIServerURL: ""
—
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerURL: "example.global.com"
Copy to Clipboard Toggle word wrap

次の例を参照してください。ここでは、グローバル KlusterletConfig の hubKubeAPIServerURL フィールドの "example.global.com" 値が KlusterletConfig をオーバーライドします。 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: test
—
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerURL: "example.global.com"
Copy to Clipboard Toggle word wrap

1.7.17.4. ハブクラスターの KubeAPIServer 検証ストラテジーの設定
リンクのコピー

マネージドクラスターは、OpenShift Container Platform KubeAPIServer の外部ロードバランサーとの相互接続を介してハブクラスターと通信します。OpenShift Container Platform をインストールすると、内部の OpenShift Container Platform クラスター認証局 (CA) がデフォルトの OpenShift Container Platform KubeAPIServer 証明書を発行します。multicluster engine for Kubernetes Operator は、証明書を自動的に検出して bootstrap-kubeconfig-secret namespace 内のマネージドクラスターに追加します。

自動的に検出された証明書が機能しない場合は、KlusterletConfig リソースでストラテジー設定を手動で設定できます。ストラテジーを手動で設定すると、ハブクラスターの KubeAPIServer 証明書の検証方法を制御できます。

ストラテジーを手動で設定する方法は、次の 3 つのストラテジーのいずれかの例を参照してください。

1.7.17.4.1. UseAutoDetectedCABundle を使用したストラテジーの設定
リンクのコピー

デフォルトの設定ストラテジーは UseAutoDetectedCABundle です。multicluster engine Operator は、ハブクラスター上の証明書を自動的に検出し、trustedCABundles リストの config map 参照に設定されている証明書を実際の CA バンドル (存在する場合) にマージします。

次の例では、ハブクラスターから自動的に検出された証明書と、new-ocp-ca config map で設定した証明書をマージし、両方をマネージドクラスターに追加します。 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
 name: ca-strategy
spec:
 hubKubeAPIServerConfig:
   serverVerificationStrategy: UseAutoDetectedCABundle
   trustedCABundles:
   - name: new-ca
     caBundle:
       name: new-ocp-ca
       namespace: default
Copy to Clipboard Toggle word wrap
1.7.17.4.2. UseSystemTruststore を使用したストラテジーの設定
リンクのコピー

UseSystemTruststore を使用すると、multicluster engine Operator は証明書を検出せず、trustedCABundles パラメーターセクションで設定された証明書を無視します。この設定では、マネージドクラスターに証明書は渡されません。代わりに、マネージドクラスターは、マネージドクラスターのシステムトラストストアからの証明書を使用して、ハブクラスター API サーバーを検証します。これは、Let’s Encrypt などのパブリック CA がハブクラスター証明書を発行する場合に該当します。UseSystemTruststore を使用する次の例を参照してください。 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
 name: ca-strategy
spec:
 hubKubeAPIServerConfig:
   serverVerificationStrategy: UseSystemTruststore
Copy to Clipboard Toggle word wrap
1.7.17.4.3. UseCustomCABundles を使用したストラテジーの設定
リンクのコピー

ハブクラスター API サーバーの CA がわかっていて、multicluster engine Operator にそれを自動的に検出させない場合は、UseCustomCABundles を使用できます。このストラテジーでは、multicluster engine Operator が、設定された証明書を trustedCABundles パラメーターからマネージドクラスターに追加します。UseCustomCABundles の使用方法は、次の例を参照してください。 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
 name: ca-strategy
spec:
 hubKubeAPIServerConfig:
   serverVerificationStrategy: UseCustomCABundles
   trustedCABundles:
   - name: ca
     caBundle:
       name: ocp-ca
       namespace: default
Copy to Clipboard Toggle word wrap

通常、このポリシーは各マネージドクラスターで同じです。ハブクラスター管理者は、multicluster engine Operator をインストールするとき、またはハブクラスター証明書が変更されたときに、global という名前の KlusterletConfig を設定して、各マネージドクラスターのポリシーをアクティブ化できます。以下の例を参照してください。 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
 name: global
spec:
 hubKubeAPIServerConfig:
   serverVerificationStrategy: UseSystemTruststore
Copy to Clipboard Toggle word wrap

マネージドクラスターで別のストラテジーを使用する必要がある場合は、別の KlusterletConfig を作成し、マネージドクラスターで agent.open-cluster-management.io/klusterlet-config アノテーションを使用して特定のストラテジーを指定することもできます。以下の例を参照してください。 

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
 name: test-ca
spec:
 hubKubeAPIServerConfig:
   serverVerificationStrategy: UseCustomCABundles
   trustedCABundles:
   - name: ca
     caBundle:
       name: ocp-ca
       namespace: default
--
apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    agent.open-cluster-management.io/klusterlet-config: test-ca
  name: cluster1
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60
Copy to Clipboard Toggle word wrap

1.7.17.5. 関連情報
リンクのコピー

1.7.18. 管理からのクラスターの削除
リンクのコピー

multicluster engine Operator で作成された OpenShift Container Platform クラスターを管理から削除する場合は、クラスターを デタッチ または 破棄 することができます。クラスターをデタッチするとマネージメントから削除されますが、完全には削除されません。管理する場合には、もう一度インポートし直すことができます。このオプションは、クラスターが Ready 状態にある場合にだけ利用できます。

次の手順により、次のいずれかの状況でクラスターが管理から削除されます。

  • すでにクラスターを削除しており、削除したクラスターを Red Hat Advanced Cluster Management から削除したいと考えています。
  • クラスターを管理から削除したいが、クラスターを削除していない。

重要:

1.7.18.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`
Copy to Clipboard Toggle word wrap

ネットワーク接続時のオンラインインストール で説明されているように、disableHubSelfManagement の値を true に変更して、自動的にインポートされないようにハブクラスターの値を変更できます。

1.7.18.2. コマンドラインを使用したクラスターの削除
リンクのコピー

ハブクラスターのコマンドラインを使用してマネージドクラスターをデタッチするには、以下のコマンドを実行します。 

oc delete managedcluster $CLUSTER_NAME
Copy to Clipboard Toggle word wrap

切断後にマネージドクラスターを破棄するには、次のコマンドを実行します。 

oc delete clusterdeployment <CLUSTER_NAME> -n $CLUSTER_NAME
Copy to Clipboard Toggle word wrap

注記:

  • マネージドクラスターの破壊を防ぐには、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`
    Copy to Clipboard Toggle word wrap

    disableHubSelfManagement の値を true に指定して、自動的にインポートされないように、ハブクラスターの値を変更できます。ネットワーク接続時のオンラインインストール を参照してください。

1.7.18.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
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを使用して、klusterlet カスタムリソースを削除します。 

    oc get klusterlet | grep klusterlet | awk '{print $1}' | xargs oc patch klusterlet --type=merge -p '{"metadata":{"finalizers": []}}'
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、残りのリソースを削除します。 

    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": []}}'
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを実行して、namespaces と開いているすべてのクラスター管理 crds の両方が削除されていることを確認します。 

    oc get crds | grep open-cluster-management.io | awk '{print $1}'
oc get ns | grep open-cluster-management-agent
    Copy to Clipboard Toggle word wrap

1.7.18.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.7.18.4.1. 前提条件
リンクのコピー
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
1.7.18.4.2. 手順
リンクのコピー

  1. etcd 履歴を圧縮します。

    1. 次に、etcd メンバーへのリモートシェルセッションを開きます。 

      $ oc rsh -n openshift-etcd etcd-control-plane-0.example.com etcdctl endpoint status --cluster -w table
      Copy to Clipboard Toggle word wrap

    2. 以下のコマンドを実行して etcd 履歴を圧縮します。 

      sh-4.4#etcdctl compact $(etcdctl endpoint status --write-out="json" |  egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*' -m1)
      Copy to Clipboard Toggle word wrap

      出力例

      $ compacted revision 158774421
      Copy to Clipboard Toggle word wrap

  2. etcd データのデフラグの説明に従って、etcd データベースをデフラグし、NOSPACE アラームをクリアします。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat