インストール

Red Hat Advanced Cluster Management for Kubernetes 2.1

インストール

概要

Red Hat Advanced Cluster Management for Kubernetes のインストール

第1章 インストール

Red Hat Advanced Cluster Management for Kubernetes のインストールとアンインストールの方法を説明します。Red Hat Advanced Cluster Management for Kubernetes をインストールする前に、各製品に必要なハードウェアおよびシステム設定を確認してください。

Red Hat Advanced Cluster Management for Kubernetes は、サポート対象の Red Hat OpenShift Container Platform を使用して Linux 上にオンラインインストールできます。

インストールフローの概要:

  1. サポートされているバージョンの OpenShift Container Platform のインストールと設定が完了している必要があります。
  2. カタログから Red Hat Advanced Cluster Management for Kubernetes の Operator をインストールします。

Red Hat Advanced Cluster Management for Kubernetes のインストールおよびデプロイ後に、各種機能の使用方法のドキュメントを参照してください。

Red Hat Advanced Cluster Management for Kubernetes をインストールすると、マルチノードクラスターの実稼働環境が設定されます。Red Hat Advanced Cluster Management for Kubernetes は、標準または高可用性設定のいずれかでインストールできます。

1.1. 要件および推奨事項

Red Hat Advanced Cluster Management for Kubernetes をインストールする前に、システム設定の要件およびオプションを確認します。

1.1.1. サポート対象のオペレーティングシステムおよびプラットフォーム

サポート対象のオペレーティングシステムについては、以下の表を参照してください。

プラットフォームオペレーティングシステムRed Hat OpenShift Container Platform バージョン

Linux x86_64

Red Hat Enterprise Linux 7.6 以降

サポートされる OpenShift Container Platform プラットフォームの最新の一覧については、「 Red Hat Advanced Cluster Management 2.1 サポートマトリックス」 を参照してください。

1.1.2. サポート対象のブラウザー

Red Hat Advanced Cluster Management コンソールには、Mozilla Firefox、Google Chrome、Microsoft Edge、および Safari からアクセスできます。以下は、テスト済みでサポートされるバージョンです。

プラットフォームサポート対象のブラウザー

Microsoft Windows

Microsoft Edge: 44 以降、Mozilla Firefox: 82.0 以降、Google Chrome: バージョン 86.0 以降

Linux

Mozilla Firefox: 82.0 以降、Google Chrome: バージョン 86.0 以降

macOS

Mozilla Firefox: 82.0 以降、Google Chrome: バージョン 86.0 以降、Safari: 14.0 以降

詳細は、「Red Hat Advanced Cluster Management for Kubernetes 2.1 Support Matrix」を参照してください。

1.1.3. ネットワーク設定

以下の接続を許可するようにネットワーク設定を行います。

ハブクラスター:

  • クラウドプロバイダーの API への送信接続
  • ポート 6443 でプロビジョニングされたマネージドクラスターの Kubernetes API サーバーへの送信接続
  • ハブクラスターからチャネルソース (GitHub、オブジェクトストア、Helm リポジトリーなど) への送信接続。この送信接続は、アプリケーションライフサイクルを使用してこのようなソースに接続する場合にのみ必要です。
  • ポート 443 のマネージドクラスター上の WorkManager サービスルートへの送信および受信接続
  • ポート 6443 のマネージドクラスターからハブクラスターの kube API サーバーへの受信接続
  • GitHub からハブクラスターへの post-commit フックの受信接続。この設定は、特定のアプリケーション管理機能を使用する場合にのみ必要です。

マネージドクラスター:

  • ポート 6443 のハブクラスターから Kubernetes API サーバーへの受信接続
  • ポート 443 のハブクラスターからの WorkManager サービスエンドポイントへの受信接続
  • ポート 6443 のハブクラスターの Kubernetes API サーバーへの送信接続
  • マネージドクラスターからチャネルソース (GitHub、Object Store、Helm リポジトリーなど) への送信接続。この送信接続は、アプリケーションライフサイクルを使用してこのようなソースに接続する場合にのみ必要です。

詳細は、「Red Hat Advanced Cluster Management for Kubernetes 2.1 Support Matrix」を参照してください。

1.2. パフォーマンスおよびスケーラビリティー

Red Hat Advanced Cluster Management for Kubernetes は、特定のスケーラビリティーおよびパフォーマンスデータを判断するためにテストされています。テストしたエリアは、主にクラスターのスケーラビリティーと検索パフォーマンスです。

この情報を使用すると、お使いの環境のプランニングに役立ちます。

注記: データは、テスト時のラボ環境から取得した結果をもとにしています。結果は、お使いの環境、ネットワークの速度、および製品への変更により、異なる可能性があります。

1.2.1. マネージドクラスターの最大数

Red Hat Advanced Cluster Management が管理できるクラスターの最大数は、以下のような複数の要因により異なります。

  • クラスター内のリソース数。この数はデプロイするポリシーやアプリケーションの数などの要素により異なります。
  • スケーリングに使用する Pod 数など、ハブクラスターの設定。

以下の表は、今回のテストに使用した Amazon Web Services クラウドプラットフォームのクラスターの設定情報を示しています。

ノードフレーバーvCPURAM (GiB)ディスクタイプディスクサイズ (GiB)/IOSカウントリージョン

マスター

m5.2xlarge

8

32

gp2

100

3

us-east-1

ワーカー

m5.2xlarge

8

32

gp2

100

ノード 3 つまたは 5 つ

us-east-1

1.2.2. スケーラビリティーの検索

検索コンポーネントのスケーラビリティーは、データストアのパフォーマンスにより異なります。検索パフォーマンスの分析には、以下の変数が重要です。

  • 物理メモリー
  • 書き込みスループット (キャッシュのリカバリー時間)
  • クエリー実行時間

1.2.2.1. 物理メモリー

検索は、データをインメモリーに保持し、応答時間を早めます。必要なメモリーは、クラスター内の Kubernetes リソース数とその関係に比例します。

クラスターKubernetes リソース関係確認済みのサイズ(シミュレーションデータあり)

medium 1 台

5000

9500

50 MB

medium 5 台

25,000

75,000

120 MB

medium 15 台

75,000

20,0000

263 MB

medium 30 台

150,000

450,000

492 MB

medium 50 台

250,000

750,000

878 MB

デフォルトでは、データストアは 1 GB のメモリー制限でデプロイされます。これ以上規模の大きいクラスターを管理する場合には、ハブクラスター namespace の search-prod-xxxxx-redisgraph という名前のデプロイメントを編集して、このメモリー制限を増やす必要があります。

1.2.2.2. 書き込みスループット (キャッシュのリカバリー時間)

安定状態のクラスターの多くは、少数のリソース更新を生成します。RedisGraph データの消去時には、更新の割合が高くなり、その結果、ほぼ同時にリモートのコレクターが完全な状態を同期します。

クラスターKubernetes リソース関係シミュレーションからの平均リカバリー時間

medium 1 台

5000

9500

2 秒未満

medium 5 台

25,000

75,000

15 秒未満

medium 15 台

75,000

200,000

2 分 40 秒

medium 30 台

150,000

450,000

5-8 分

注記: ハブへのネットワーク接続の速度が遅いクラスターの場合は、所要時間が伸びる可能性があります。

1.2.2.3. クエリー実行に関する考慮事項

クエリーを実行して結果が返されるまでの所要時間に、影響を与える事項が複数あります。環境のプランニングおよび設定時に、以下の項目を考慮してください。

  • キーワードの検索は効率的ではない。
  • 最初の検索は、ユーザーのアクセスルールを収集するのに時間が余計にかかるため、2 番目以降の検索よりも時間がかかる。
  • 要求の完了にかかる時間は、ユーザーのアクセスが許可されている namespace とリソースの数に比例する。
  • 要求が全 namespace または全マネージドクラスターにアクセス権限のある非管理者ユーザーからの場合に、最も悪いパフォーマンスが確認された。

1.2.3. 可観測性のスケーリング

可観測性サービスを有効にして使用する場合には、環境のプランニングが必要です。可観測性コンポーネントのインストール先である OpenShift Container Platform プロジェクトで、後ほど消費するリソースを確保します。使用予定の値は、可観測性コンポーネント全体での使用量合計です。

注記: データは、テスト時のラボ環境から取得した結果をもとにしています。結果は、お使いの環境、ネットワークの速度、および製品への変更により、異なる可能性があります。

1.2.3.1. 可観測性環境の例

このサンプル環境では、Amazon Web Service クラウドプラットフォームにハブクラスターとマネージドクラスターが配置されており、以下のトポロジーおよび設定が指定されています。

ノードフレーバーvCPURAM (GiB)ディスクタイプディスクサイズ (GiB)/IOSカウントリージョン

マスターノード

m5.4xlarge

16

64

gp2

100

3

sa-east-1

ワーカーノード

m5.4xlarge

16

64

gp2

100

3

sa-east-1

高可用性環境用に、可観測性のデプロイメントを設定します。高可用性環境の場合は、Kubernetes デプロイメントごとにインスタンスが 2 つ、ステートフルセットごとにインスタンスが 3 つ含まれます。

サンプルテストでは、さまざまな数のマネージドクラスターがメトリクスのプッシュをシミュレーションし、各テストは 24 時間実行されます。以下のスループットを参照してください。

1.2.3.2. 書き込みスループット

Pod間隔 (分)時系列 (分)

400

1

83000

1.2.3.3. CPU 使用率 (ミリコア)

テスト時の CPU の使用率は安定しています。

サイズCPU の使用率

10 x クラスター

400

20 x クラスター

800

1.2.3.4. RSS およびワーキングセットメモリー

メモリー使用量 RSS: container_memory_rss のメトリクスから取得。テスト時の安定性を維持します。

メモリー使用量のワーキングセット: container_memory_working_set_bytes のメトリクスから取得。テストの進捗に合わせて増加します。

24 時間のテストで、以下の結果が得られました。

サイズメモリー使用量 RSSメモリー使用量のワーキングセット

10 x クラスター

9.84

4.83

20 x クラスター

13.10

8.76

1.2.3.5. thanos-receive コンポーネントの永続ボリューム

重要: メトリクスは、保持期間 (4 日) に達するまで thanos-receive に保管されます。他のコンポーネントでは、thanos-receive コンポーネントと同じボリューム数は必要ありません。

ディスクの使用量は、テストが進むに連れて増加します。データは 1 日経過後のディスク使用量であるため、最終的なディスク使用量は 4 倍にします。

以下のディスク使用量を参照してください。

サイズディスク使用量 (GiB)

10 x クラスター

2

20 x クラスター

3

1.2.3.6. ネットワーク転送

テスト中、ネットワーク転送で安定性を確保します。サイズおよびネットワーク転送の値を確認します。

サイズ受信ネットワーク転送送信ネットワーク転送

10 x クラスター

1 秒あたり 6.55 MB

1 秒あたり 5.80 MB

20 x クラスター

1 秒あたり 13.08 MB

1 秒あたり 10.9 MB

1.2.3.7. Amazon Simple Storage Service (S3)

Amazon Simple Storage Service (S3) の合計使用量は増加します。メトリクスデータは、デフォルトの保持期間 (5 日) に達するまで S3 に保存されます。以下のディスク使用量を参照してください。

サイズディスク使用量 (GiB)

10 x クラスター

16.2

20 x クラスター

23.8

1.3. インストールに向けたハブクラスターの準備

Red Hat Advanced Cluster Management for Kubernetes をインストールする前に、以下のインストール要件とハブクラスター設定の推奨事項を確認してください。

1.3.1. OpenShift Container Platform インストールの確認

  • レジストリー、ストレージサービスなど、サポート対象の Red Hat OpenShift Container Platform バージョンがクラスターにインストールされ、機能する状態である必要があります。OpenShift Container Platform のインストール方法の詳細は、Red Hat OpenShift Container Platform のドキュメントを参照してください。
  • Red Hat OpenShift Container Platform バージョン 4.3 の場合は、Red Hat OpenShift Container Platform 4.3 ドキュメント を参照してください。
  • Red Hat OpenShift Container Platform クラスターが正しく設定されていることを確認するには、Red Hat OpenShift Container Platform Web コンソールにアクセスします。

    kubectl -n openshift-console get route コマンドを実行して、Red Hat OpenShift Container Platform の Web コンソールにアクセスします。以下の出力例を参照してください。

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

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

ハブクラスターの容量の設定に関する詳細は、「クラスターのサイジング」を参照してください。

1.3.2. クラスターのサイジング

Red Hat Advanced Cluster Management for Kubernetes クラスターごとに独自の特徴があります。デプロイメントサイズの例を提供するガイドラインがあります。推奨事項は、サイズと目的で分類されています。

Red Had Advanced Cluster Management は、サポートサービスのサイジングと配置に以下の 3 つの条件が適用されます。

  • クラスター全体で障害の発生する可能性のあるドメインを分離するアベイラビリティーゾーン。通常のクラスターには、3 つ以上のアベイラビリティーゾーンでほぼ同等の容量のワーカーノードが必要です。
  • vCPU の予約と制限をもとに、コンテナーに割り当てるワーカーノードの vCPU 容量が確立されます。vCPU は Kubernetes のコンピュートユニットと同じです。詳細は、Kubernetes の Meaning of CPU を参照してください。
  • メモリーの予約と制限をもとに、コンテナーに割り当てるワーカーノードのメモリー容量が確立されます。予約は CPU またはメモリーの下限を、制限は上限を決定します。

当製品が管理する永続データは、Kubernetes が使用する etcd クラスターに保存されます。OpenShift のベストプラクティスでは、3 つのアベイラビリティーゾーンにクラスターのマスターノードを分散させることを推奨します。

注記: 記載されている要件は、最小要件ではありません。

1.3.2.1. Red Hat Advanced Cluster Management for Kubernetes の環境

OpenShift ノードロールアベイラビリティーゾーンデータストア予約済みメモリーの合計 (下限)予約済み CPU の合計 (下限) 

マスター

3

etcd x 3

OpenShift のサイジングガイドライン別

OpenShift のサイジングガイドライン別

 

ワーカー

3

redisgraph/redis x 1

12Gi

6 CPU

 

Red Hat OpenShift Container Platform クラスターは、Red Hat Advanced Cluster Management for Kubernetes に加え、追加のサービスを実行してクラスター機能をサポートします。以下のノードサイズ (以下の記載している 3 種のノードは、3 つのアベイラビリティーゾーンに均等に分散) を推奨します。

1.3.2.1.1. Amazon Web Services での OpenShift クラスターの作成

詳細は、OpenShift Container Platform 製品ドキュメントの Amazon Web Services の情報 を参照してください。また、マシンタイプ についても確認してください。

  • ノード数: 3
  • アベイラビリティーゾーン: 3
  • インスタンスサイズ: m5.xlarge

    • vCPU: 4
    • メモリー: 16 GB
    • ストレージサイズ: 120 GB
1.3.2.1.2. Google Cloud Platform での OpenShift クラスターの作成設定

クォータの詳細は、Google Cloud Platform の製品ドキュメント を参照してください。また、マシンタイプ についても確認してください。

  • ノード数: 3
  • アベイラビリティーゾーン: 3
  • インスタンスサイズ: N1-standard-4 (0.95–6.5 GB)

    • vCPU: 4
    • メモリー: 15 GB
    • ストレージサイズ: 120 GB
1.3.2.1.3. Microsoft Azure での OpenShift クラスターの作成設定

詳細は、以下の 製品ドキュメント を参照してください。

  • ノード数: 3
  • アベイラビリティーゾーン: 3
  • インスタンスサイズ: Standard_D4_v3

    • vCPU: 4
    • メモリー: 16 GB
    • ストレージサイズ: 120 GB
1.3.2.1.4. VMware vSphere での OpenShift クラスターの作成設定

詳細は、以下の 製品ドキュメント を参照してください。

  • ソケットごとのコア: 1
  • CPU: 2
  • メモリー: 8 GB
  • ストレージサイズ: 120 GB
1.3.2.1.5. ベアメタルでの OpenShift クラスターの作成設定

詳細は、以下の 製品ドキュメント を参照してください。

  • CPU: 6 (最小)
  • メモリー: 16 GB (最小)
  • ストレージサイズ: 50 GB (最小)

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

Red Hat Advanced Cluster Management for Kubernetes は、必要なコンポーネントすべてをデプロイする Operator でインストールします。

1.4.1. 前提条件

Red Hat Advanced Cluster Management をインストールする前に、以下の要件を満たす必要があります。

  • Red Hat OpenShift Container Platform は、OperatorHub カタログで Red Hat Advanced Cluster Management Operator にアクセスできる必要がある。
  • お使いの環境に OpenShift Container Platform バージョン 4.3 以降をインストールし、CLI でログインしている必要がある。OpenShift Container Platform バージョン 4.4 のドキュメントOpenShift バージョン 4.5 のドキュメント、または OpenShift バージョン 4.6 ドキュメント を参照してください。
  • OpenShift Container Platform のコマンドラインインターフェース (CLI) はバージョン 4.3 以降を使用し、oc コマンドを実行できるように設定しておく必要がある。Red Hat OpenShift CLI のインストールおよび設定の詳細は、「 CLI の使用方法」を参照してください。
  • namespace の作成が可能な OpenShift Container Platform のパーミッションを設定しておく必要がある。
  • operator の依存関係にアクセスするには、インターネット接続が必要である。

1.4.2. OperatorHub からのインストール

OpenShift Container Platform に同梱される OperatorHub を使用してインストールすると、最も簡単に Red Hat Advanced Cluster Management をインストールできます。

  1. OpenShift Container Platform ナビゲーションで、Operators > OperatorHub を選択して、利用可能な Operator のリストにアクセスします。
  2. Red Hat Advanced Cluster Management for Kubernetes Operator を見つけて、選択します。
  3. Operator サブスクリプション ページで、インストールのオプションを選択します。

    • namespace: Red Hat Advanced Cluster Management は、独自の namespace またはプロジェクトにインストールする必要があります。デフォルト値では、インストールプロセスで open-cluster-management という名前の namespace を作成し、その namespace にインストールします。open-cluster-management という名前の namespace がすでにある場合は、そのオプションでインストールを完了できません。この場合には、既存の namespace へのインストールオプションを使用し、そのオプションを一覧から選択する必要があります。

      重要: ClusterRoleBinding が指定された ServiceAccount には、Red Hat Advanced Cluster Management がインストールされている namespace にアクセス権があるユーザー認証情報および、Red Hat Advanced Cluster Management に対して、クラスター管理者権限が割り当てられます。このインストールでは、local-cluster という名前の namespace も作成されます。この namespace は、単独で管理できるようにハブクラスター向けに確保されます。local-cluster という既存の namespace を含めることはできません。セキュリティーの理由上、クラスター管理者のアクセス権がないユーザーには、local-cluster namespace へのアクセス権を割り当てないようにしてください。

    • チャネル: インストールするリリースに対応するチャネルを選択します。チャネルを選択すると、指定のリリースがインストールされ、そのリリース内の今後の z-stream 更新が取得されます。
    • 承認ストラテジー: 承認ストラテジーでは、サブスクライブ先のチャネルまたはリリースに更新を適用するのに必要な人の間のやり取りを特定します。Automatic 更新を選択すると、対象のリリース内の更新が自動的に適用されます。更新を適用するタイミングに懸念がある場合には、Manual を選択して、更新が利用可能になった時点で通知を受け取ることができます。

      注記; 自動アップグレードは、メジャーリリース (例: 2.0 から 2.1) のバージョンを超えて行われることはありません。次のメジャーリリースにアップグレードするには、OperatorHub ページに戻り、最新リリースの新規チャネルを選択する必要があります。

  4. Subscribe を選択して変更を適用し、Operator を作成します。
  5. OpenShift Container Platform または Red Hat Advanced Cluster Management で作成されていない Kubernetes クラスターをインポートする予定の場合には、OpenShift Container Platform プルシークレットを含むシークレットを作成して、ディストリビューションレジストリーから資格のあるコンテンツにアクセスします。OpenShift Container Platform クラスターのシークレット要件は、OpenShift Container Platform および Red Hat Advanced Cluster Management により自動で解決されるので、他のタイプの Kubernetes クラスターをインポートして管理しない場合には、このシークレットを作成する必要はありません。

    1. cloud.redhat.com/openshift/install/pull-secret から Copy pull secret を選択して、OpenShift Container Platform のプルシークレットをコピーします。この手順の後半で、このプルシークレットのコンテンツを使用します。OpenShift Container Platform プルシークレットは Red Hat カスタマーポータル ID に関連しており、すべての Kubernetes プロバイダーで同じです。
    2. OpenShift Container Platform コンソールナビゲーションで、Workloads > Secrets を選択します。
    3. Create > Image Pull Secret を選択します。
    4. シークレットの名前を入力します。
    5. 認証タイプとして Upload Configuration File を選択します。
    6. Configuration file フィールドに cloud.redhat.com からコピーしたプルシークレットを貼り付けます。
    7. Create を選択してシークレットを作成します。
  6. MultiClusterHub のカスタムリソースを作成します。

    1. OpenShift Container Platform コンソールのナビゲーションで Installed Operators > Advanced Cluster Management for Kubernetes を選択します。
    2. MultiClusterHub タブを選択します。
    3. Create MultiClusterHub を選択します。
    4. 必要に応じて、.yaml ファイルのデフォルト値を更新します。

      • 以下の例は、イメージプルシークレットを作成していない場合のデフォルトのテンプレートです。

        apiVersion: operator.open-cluster-management.io/v1
        kind: MultiClusterHub
        metadata:
          name: multiclusterhub
          namespace: <namespace>

        namespace がお使いのプロジェクトの namespace であることを確認します。

      • 以下の例は、イメージプルシークレットを作成している場合のデフォルトのテンプレートです。

        apiVersion: operator.open-cluster-management.io/v1
        kind: MultiClusterHub
        metadata:
          name: multiclusterhub
          namespace: <namespace>
        spec:
          imagePullSecret: <secret>

        secret は作成したプルシークレット名に置き換えます。namespace がお使いのプロジェクトの namespace であることを確認します。

        重要: local-cluster namespace は、インポートされた自己管理のハブクラスターに使用します。インストール前に、クラスターに local-cluster namespace を含めることはできません。ハブクラスターに local-cluster namespace が作成されると、local-cluster namespace へのアクセス権があるユーザーには自動的に cluster administrator のアクセス権が付与されます。セキュリティーの理由上、クラスター管理者のアクセス権がないユーザーには、local-cluster namespace へのアクセス権を割り当てないようにしてください。

    5. オプション: 必要に応じて、ハブの自己管理を無効にします。デフォルトでは、ハブクラスターは他のクラスターと同様に自動的にインポートされ、管理されます。ハブクラスターでの自己管理をしない場合は、disableHubSelfManagement の設定を false から true に変更します。この設定に、カスタムリソースを定義する .yaml ファイルが含まれていない場合は、直前の手順例のように追加します。以下の例は、ハブの自己管理機能を無効にする場合に使用するデフォルトのテンプレートです。

      apiVersion: operator.open-cluster-management.io/v1
      kind: MultiClusterHub
      metadata:
        name: multiclusterhub
        namespace: <namespace>
      spec:
        disableHubSelfManagement: true

      namespace はお使いのプロジェクトの namespace 名に置き換えます。

  7. Create を選択して、カスタムリソースを初期化します。ハブのビルドと起動に、最長で 10 分程度かかる場合があります。

    ハブの作成後、Operator のステータスは、Installed Operators ページで Running になります。

  8. ハブのコンソールにアクセスします。

    1. OpenShift Container Platform コンソールナビゲーションで Networking > Routes を選択します。
    2. リストでハブの URL を確認して、その URL に移動してハブのコンソールにアクセスします。

Red Hat Advanced Cluster Management を再インストールして、Pod が起動しない場合には、この問題の回避手順について「再インストールに失敗する場合のトラブルシューティング」を参照してください。

1.4.3. CLI からのインストール

  1. Operator 要件を満たしたハブクラスター namespace を作成します。

    oc create namespace <namespace>

    namespace はお使いのハブクラスター namespace 名に置き換えます。注記:: namespace の値は、Red Hat OpenShift Container Platform 環境では プロジェクト と呼ばれる場合があります。

    重要: ClusterRoleBinding が指定された ServiceAccount には、Red Hat Advanced Cluster Management がインストールされている namespace にアクセス権があるユーザー認証情報および、Red Hat Advanced Cluster Management に対して、クラスター管理者権限が割り当てられます。このインストールでは、local-cluster という名前の namespace も作成されます。この namespace は、単独で管理できるようにハブクラスター向けに確保されます。local-cluster という既存の namespace を含めることはできません。セキュリティーの理由上、クラスター管理者のアクセス権がないユーザーには、local-cluster namespace へのアクセス権を割り当てないようにしてください。

  2. プロジェクトの namespace を、作成した namespace に切り替えます。

    oc project <namespace>

    namespace は、手順 1 で作成したハブクラスター namespace 名に置き換えます。

  3. OpenShift Container Platform または Red Hat Advanced Cluster Management で作成されていない Kubernetes クラスターをインポートする予定の場合には、OpenShift Container Platform プルシークレットの情報を含むシークレットを生成して、ディストリビューションレジストリーから資格のあるコンテンツにアクセスしますOpenShift Container Platform クラスターのシークレット要件は、OpenShift Container Platform および Red Hat Advanced Cluster Management により自動で解決されるので、他のタイプの Kubernetes クラスターをインポートして管理しない場合には、このシークレットを作成する必要はありません。重要: これらのシークレットは、namespace ごとに異なるので、手順 1 で作成した namespace で操作を行うようにしてください。

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

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

      secret は作成するシークレット名に置き換えます。namespace はプロジェクトの namespace に置き換えます。path-to-pull-secret はダウンロードする OpenShift Container Platform のプルシークレットへのパスに置き換えます。

  4. Operator グループを作成します。namespace ごとに割り当てることのできる Operator グループ は 1 つだけです。

    1. Operator グループを定義する .yaml ファイルを作成します。ファイルは以下の例のようになります。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <default>
      spec:
        targetNamespaces:
        - <namespace>

      default はお使いの operator グループ名に置き換えます。namespace はお使いのプロジェクトの namespace に置き換えます。

    2. 作成したファイルを適用して Operator グループを定義します。

      oc apply -f local/<operator-group>.yaml

      operator-group は、作成した operator グループの .yaml ファイル名に置き換えます。

  5. サブスクリプションを適用します。

    1. サブスクリプションを定義する .yaml ファイルを作成します。ファイルは以下の例のようになります。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: acm-operator-subscription
      spec:
        sourceNamespace: openshift-marketplace
        source: redhat-operators
        channel: release-2.1
        installPlanApproval: Automatic
        name: advanced-cluster-management
    2. サブスクリプションを適用します。

      oc apply -f local/<subscription>.yaml

      subscription は、作成したサブスクリプションファイルの名前に置き換えます。

  6. MultiClusterHub のカスタムリソースを適用します。

    1. カスタムリソースを定義する .yaml ファイルを作成します。

      • プルシークレットを作成していない場合のデフォルトのテンプレートは、以下の例のようになります。

        apiVersion: operator.open-cluster-management.io/v1
        kind: MultiClusterHub
        metadata:
          name: multiclusterhub
          namespace: <namespace>

        namespace はお使いのプロジェクトの namespace 名に置き換えます。

      • プルシークレットを作成している場合のデフォルトのテンプレートは、以下の例のようになります。

        apiVersion: operator.open-cluster-management.io/v1
        kind: MultiClusterHub
        metadata:
          name: multiclusterhub
          namespace: <namespace>
        spec:
          imagePullSecret: <secret>

        namespace はお使いのプロジェクトの namespace 名に置き換えます。

        secret は、プルシークレット名に置き換えます。

    2. オプション: 必要に応じて、ハブの自己管理を無効にします。デフォルトでは、ハブクラスターは他のクラスターと同様に自動的にインポートされ、管理されます。ハブクラスターでの自己管理をしない場合は、disableHubSelfManagement の設定を false から true に変更します。プルシークレットを作成しており、disableHubSelfManagement 機能を有効にしている場合には、デフォルトのテンプレートは以下の例のようになります。

      apiVersion: operator.open-cluster-management.io/v1
      kind: MultiClusterHub
      metadata:
        name: multiclusterhub
        namespace: <namespace>
      spec:
        imagePullSecret: <secret>
        disableHubSelfManagement: true

      namespace はお使いのプロジェクトの namespace 名に置き換えます。

      secret は、プルシークレット名に置き換えます。

    3. カスタムリソースを適用します。

      oc apply -f local/<custom-resource>.yaml

      custom-resource は、カスタムリソースファイル名に置き換えます。

      重要: local-cluster namespace は、インポートされた自己管理のハブクラスターに使用します。インストール前に、クラスターに local-cluster namespace を含めることはできません。ハブクラスターに local-cluster namespace が作成されると、local-cluster namespace へのアクセス権があるユーザーには自動的に cluster administrator のアクセス権が付与されます。セキュリティーの理由上、クラスター管理者のアクセス権がないユーザーには、local-cluster namespace へのアクセス権を割り当てないようにしてください。

      以下のエラーで、この手順に失敗した場合でも、リソースは作成され、適用されます。

      error: unable to recognize "./mch.yaml": no matches for kind "MultiClusterHub" in version "operator.open-cluster-management.io/v1"

      リソースが作成されてから数分後にもう一度コマンドを実行します。

  7. 以下のコマンドを実行して、MultiClusterHub カスタムリソースのステータスが status.phase フィールドに Running と表示されるまで、最長 10 分の時間がかかる可能性があります。

    oc get mch -o=jsonpath='{.items[0].status.phase}'
  8. ステータスが Running になってから、ルートの一覧を確認してルートを探し出します。

    oc get routes

Red Hat Advanced Cluster Management を再インストールして、Pod が起動しない場合には、この問題の回避手順について「再インストールに失敗する場合のトラブルシューティング」を参照してください。

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

インターネットに接続していない Red Hat OpenShift クラスターに Red Hat Advanced Cluster Management for Kubernetes をインストールする必要がある場合があります。ネットワーク接続のないハブにインストールする手順でも一部、オンラインインストールと同じ手順が必要になります。インストール時にネットワークから直接パッケージにアクセスするのではなく、パッケージをダウンロードしておき、インストール時にアクセスできるようにする必要があります。

1.5.1. 非接続インストールの前提条件

Red Hat Advanced Cluster Management for Kubernetes をインストールする前に、以下の要件を満たす必要があります。

  • お使いの環境に Red Hat OpenShift Container Platform バージョン 4.3 以降をインストールし、コマンドラインインターフェース (CLI) でログインしている必要がある。注記: ベアメタルクラスターを管理する場合は、Red Hat OpenShift Container Platform バージョン 4.5 以降が必要です。OpenShift バージョン 4.3 のドキュメントOpenShift バージョン 4.4 のドキュメント、または OpenShift バージョン 4.5 ドキュメント を参照してください。
  • Red Hat OpenShift Container Platform の CLI はバージョン 4.3 以降を使用し、oc コマンドを実行できるように設定しておく必要がある。Red Hat OpenShift CLI のインストールおよび設定の詳細は、「CLI の使用方法」を参照してください。
  • namespace の作成が可能な Red Hat OpenShift Container Platform のパーミッションを設定しておく必要がある。
  • Operator の依存関係をダウンロードするには、インターネット接続のあるワークステーションが必要です。

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

以下の手順を実行して Red Hat Advanced Cluster Management を非接続環境でインストールします。

  1. 必要に応じてミラーレジストリーを作成します。

    ミラーレジストリーがまだない場合には、Red Hat OpenShift Container Platform ドキュメントの 「Creating a mirror registry for installation in a restricted network」トピックの手順を実行してミラーレジストリーを作成してください。

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

  2. ベアメタルのみ: install-config.yaml ファイルに、接続なしのレジストリーの証明書情報を指定します。保護されたオフラインレジストリーでイメージにアクセスするには、Red Hat Advanced Cluster Management がレジストリーにアクセスできるように証明書情報を指定する必要があります。

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

      additionalTrustBundle: |
        -----BEGIN CERTIFICATE-----
        certificate_content
        -----END CERTIFICATE-----
      sshKey: >-
    5. install-config.yaml ファイルを保存します。
  3. rhacm-policy.yaml という名前の ImageContentSourcePolicy を含めて yaml ファイルを作成します。重要: 実行中のクラスターでこれを変更すると、すべてのノードのローリング再起動が実行されます。

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

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

    Red Hat Advanced Cluster Management は OLM Red Hat Operator カタログに含まれます。

  6. Red Hat Operator カタログの非接続 OLM を設定します。Red Hat OpenShift Container Platform ドキュメントの「ネットワークが制限された環境での Operator Lifecylece Manage の使用」の手順を実行します。
  7. 非接続 OLM にイメージを設定したので、OLM カタログからの Advanced Cluster Management for Kubernetes のインストールを続行してください。必要な手順については、「 ネットワーク接続時のインストール 」の手順を参照してください。

1.6. Operator を使用したアップグレード

Red Hat OpenShift Container Platform コンソールの Operator サブスクリプション設定を使用して、Red Hat Advanced Cluster Management for Kubernetes のアップグレードを制御できます。Operator を使用して Red Hat Advanced Cluster Management の初回デプロ時に、以下の選択を行います。

  • Channel: インストールする製品のバージョンに合わせます。多くの場合、最初のチャネル設定は、インストール時に利用可能な最新のチャネルです。
  • Approval: チャネル内での更新に承認が必要であるか、または更新を自動で行うかを指定します。Automatic に設定されている場合には、選択したチャネルのマイナーリリースの更新は、管理者の介入なしにデプロイされます。Manual 設定を選択した場合は、チャネル内でマイナーリリースに更新するたびに、管理者が更新を承認する必要があります。

operator を使用して Red Hat Advanced Cluster Management をアップグレードする場合にも、上記の設定を使用します。

必要なアクセス: OpenShift Container Platform の管理者

以下の手順を実行して Operator をアップグレードします。

  1. OpenShift Container Platform 3 の Operator ハブにログインします。
  2. OpenShift Container Platform ナビゲーションで、Operators > Installed Operators に移動します。
  3. Red Hat Advanced Cluster Management for Kubernetes Operator を選択します。
  4. Subscription タブを選択して、サブスクリプション設定を編集します。
  5. Upgrade Status のラベルが Up to date であることを確認します。このステータスは、Operator が、選択したチャネルで利用可能な最新レベルであることを示します。Upgrade Status でアップグレード保留中と示されている場合には、以下の手順を実行して、チャネルで利用可能な最新のマイナーリリースに更新します。

    1. Approval フィールドの Manual 設定をクリックして、値を編集します。
    2. Automatic を選択して自動更新を有効にします。
    3. Save を選択して変更をコミットします。
    4. 自動更新が Operator に適用されるまで待ちます。更新すると、必要な更新が選択したチャネルの最新バージョンに自動的に追加されます。更新がすべて完了したら、Upgrade Status フィールドには Up to date と表示されます。

      ヒント: MultiClusterHub カスタムリソースのアップグレードが終了するまで最大 10 分かかる可能性があります。以下のコマンドを入力して、アップグレードが進行中であるかどうかを確認できます。

      oc get mch

      アップグレード時には、Status フィールドで Updating と表示されます。アップグレードが完了すると、Status フィールドで Running と表示されます。

  6. Upgrade StatusUp to date に なったので、Channel フィールドの値をクリックして編集します。
  7. 次に利用可能な機能リリースのチャネルを選択します。アップグレード時は、チャネルをスキップできません。

    重要: チャネルの選択で新しいチャネルにアップグレード後に、以前のチャネルに戻すことはできません。以前のバージョンを使用するには、Operator をアンインストールし、以前のバージョンで再インストールする必要があります。

  8. Save を選択して変更を保存します。
  9. 自動アップグレードが完了するまで待ちます。次の機能リリースへのアップグレードが完了すると、チャネル内の最新のパッチリリースへの更新がデプロイされます。

    ヒント: MultiClusterHub カスタムリソースのアップグレードが終了するまで最大 10 分かかる可能性があります。以下のコマンドを入力して、アップグレードが進行中であるかどうかを確認できます。

    oc get mch

    アップグレード時には、Status フィールドで Updating と表示されます。アップグレードが完了すると、Status フィールドで Running と表示されます。

  10. 以降の機能リリースにアップグレードする必要がある場合には、Operator が任意のチャネルで最新レベルになるまで、手順 7 から 9を繰り返します。すべてのパッチリリースが最終チャネルにデプロイされていることを確認します。
  11. オプション: チャネル内の今後の更新を手動で承認させる必要がある場合は、Approval 設定を Manual に設定できます。

Red Hat Advanced Cluster Management は、選択したチャンネルの最新バージョンで稼働しています。

Operator のアップグレードの詳細は、「Operator のクラスターへの追加」を参照してください。

1.7. OpenShift Container Platform のアップグレード

Red Hat Advanced Cluster Management for Kubernetes ハブクラスターをホストする Red Hat OpenShift Container Platform のバージョンをアップグレードしてください。クラスター全体のアップグレードを開始する前に、データをバックアップします。

OpenShift Container Platform バージョンのアップグレード時に、Red Hat Advanced Cluster Management Web コンソールに短期間、ページまたはデータを利用できないと表示されることがあります。インジケーターには、HTTP 500 (内部サーバーエラー)、HTTP 504 (ゲートウェイタイムアウトエラー) または、以前に利用できたデータが利用できないというエラーなどがあります。これも通常のアップグレードの一部で、このようなエラーが発生してもデータが失われることはありません。最終的にページまたはデータは利用できるようになります。

検索インデックスもこのアップグレード中に再ビルドされるため、アップグレード中に送信されるクエリーは完全でない可能性があります。

以下の表には、OpenShift Container Platform バージョン 4.4.3 から 4.4.10 へのアップグレードでの主な観察内容についてまとめています。

表1.1 OpenShift Container Platform バージョン 4.3.3 から 4.4.10 へのアップグレードでの観察内容の表

アップグレードプロセスの経過時間 (分 : 秒)確認された変化期間

03:40

ガバナンスおよびリスクコンソールで HTTP 500 の発生

サービスが 20 秒以内に復元

05:30

AppUI で HTTP 504 ゲートウェイタイムアウトの発生

サービスが 60 秒以内に復元

06:05

Cluster および Search コンソールでの HTTP 504 Gateway Timeout の発生

サービスが 20 秒以内に復元

07:00

Cluster および Search コンソールでの HTTP 504 Gateway Timeout の発生

サービスが 20 秒以内に復元

07:10

Topology および Cluster コンソール内でのエラーメッセージの表示

サービスが 20 秒以内に復元

07:35

多くのコンソールページでの HTTP 500

サービスが 60 秒以内に復元

08:30

全ページのサービスの復元

 

1.8. アンインストール

Red Hat Advanced Cluster Management for Kubernetes をアンインストールする場合に、2 種類のプロセスレベルが存在します。

最初のレベルはカスタムリソースの削除です。これは、最も基本的なアンインストールの種類で、MultiClusterHub インスタンスのカスタムリソースを削除しますが、他の必要なコンポーネントが残されたままになります。このレベルのアンインストールは、削除する内容と同じ設定とコンポーネントを使用して、別のインストールを行う予定の場合には便利です。他の全コンポーネントがすでにインストールされているので、次のバージョンのインストール時間が短縮されます。

次のレベルは、カスタムリソース定義などのいくつかの項目を除く、より完全なアンインストールです。このレベルでは、他の必須コンポーネントおよび設定が削除される項目に追加されます。この手順を続行すると、カスタムリソースの削除で削除されていないコンポーネントおよびサブスクリプションがすべて削除されます。このレベルのアンインストールを完了する場合には、カスタムリソースを再インストールする前に Operator の再インストールが必要です。

重要: Red Hat Advanced Cluster Management のハブクラスターをアンインストールする前に、ハブクラスターが管理するクラスターをすべてデタッチする必要があります。回避策については、「リソースが存在しないためにアンインストールに失敗する場合のトラブルシューティング」を参照してください。

1.8.1. コマンドを使用した MultiClusterHub インスタンスの削除

  1. MultiClusterObservability カスタムリソースを実行している場合は、これを無効にして削除します。

    1. ハブクラスターにログインします。
    2. 以下のコマンドを実行して MultiClusterObservability カスタムリソースを削除します。

      oc delete mco observability

      リソースを削除すると、Red Hat Advanced Cluster Management ハブクラスターの open-cluster-management-observability namespace の Pod と、全マネージドクラスターの open-cluster-management-addon-observability namespace の Pod が削除されます。

      重要: 可観測性サービスの削除によるオブジェクトストレージへの影響はありません。

  2. 以下のコマンドを入力してプロジェクトの namespace に移動します。

    oc project <namespace>

    namespace はお使いのプロジェクトの namespace に置き換えます。

  3. 以下のコマンドを実行して MultiClusterHub カスタムリソースを削除します。

    oc delete multiclusterhub --all

    アンインストールプロセスの完了に最長 20 分かかる可能性があります。以下のコマンドを入力して進捗を表示できます。

    oc get mch -o yaml
  4. clean-up スクリプトを実行して、残りのアーティファクトを削除します。

    1. Installing Helm」の手順に従い、Helm CLI バイナリーバージョン 3.2.0 以降をインストールします。
    2. oc コマンドが実行できるように、OpenShift Container Platform CLI が設定されていることを確認してください。oc コマンドの設定方法に関する詳細は、OpenShift Container Platform ドキュメントの「CLI の使用方法」を参照してください。
    3. 以下のスクリプトをファイルにコピーします。

      #!/bin/bash
      ACM_NAMESPACE=<namespace>
      oc delete mch --all -n $ACM_NAMESPACE
      helm ls --namespace $ACM_NAMESPACE | cut -f 1 | tail -n +2 | xargs -n 1 helm delete --namespace $ACM_NAMESPACE
      oc delete apiservice v1beta1.webhook.certmanager.k8s.io v1.admission.cluster.open-cluster-management.io v1.admission.work.open-cluster-management.io
      oc delete clusterimageset --all
      oc delete configmap -n $ACM_NAMESPACE cert-manager-controller cert-manager-cainjector-leader-election cert-manager-cainjector-leader-election-core
      oc delete consolelink acm-console-link
      oc delete crd klusterletaddonconfigs.agent.open-cluster-management.io placementbindings.policy.open-cluster-management.io policies.policy.open-cluster-management.io userpreferences.console.open-cluster-management.io searchservices.search.acm.com
      oc delete mutatingwebhookconfiguration cert-manager-webhook cert-manager-webhook-v1alpha1
      oc delete oauthclient multicloudingress
      oc delete rolebinding -n kube-system cert-manager-webhook-webhook-authentication-reader
      oc delete scc kui-proxy-scc
      oc delete validatingwebhookconfiguration cert-manager-webhook cert-manager-webhook-v1alpha1

      スクリプトの namespace は、Red Hat Advanced Cluster Management がインストールされている namespace 名に置き換えます。namespace が消去され、削除されるので、正しい namespace を指定するようにしてください。

    4. スクリプトを実行して、アーティファクトを以前のインストールから削除します。

      ヒント: 新しいバージョンを再インストールする予定で、他の情報を保存する場合には、残りの手順を省略し、再インストールしてください。

  5. 以下のコマンドを入力して、関連するコンポーネントおよびサブスクリプションをすべて削除します。

    oc delete subs --all
  6. 以下のコマンドを入力し、ClusterServiceVersion を削除します。

    oc delete clusterserviceversion --all

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

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

  1. OpenShift Container Platform コンソールのナビゲーションで、Operators > Installed Operators > Advanced Cluster Manager for Kubernetes を選択します。
  2. MultiClusterObservability カスタムリソースをインストールしている場合は、これを削除します。

    1. MultiClusterObservability カスタムリソースがインストールされている場合、MultiClusterObservability のタブを選択します。
    2. MultiClusterObservability カスタムリソースの Options メニューを選択します。
    3. Delete MultiClusterObservability を選択します。
  3. MultiClusterHub のカスタムリソースを削除します。

    1. Multiclusterhub のタブを選択します。
    2. MultiClusterHub カスタムリソースの Options メニューを選択します。
    3. Delete MultiClusterHub を選択します。

      アンインストールプロセスの完了に最長 20 分かかる可能性があります。

  4. コマンドを使用した MultiClusterHub インスタンスの削除」の手順にしたがって、クリーンアップスクリプトを実行します。

    ヒント: 新しいバージョンを再インストールする予定で、他の情報を保存する場合には、残りの手順を省略し、再インストールしてください。

  5. Installed Operators に移動します。
  6. Options メニュー、Uninstall operator の順に選択して、{product-short} operator を削除します。