第1章 インストールとアップグレード
Red Hat Advanced Cluster Management for Kubernetes をインストールすると、マルチノードクラスターの実稼働環境が設定されます。Red Hat Advanced Cluster Management for Kubernetes は、標準または高可用性設定のいずれかでインストールできます。
インストールする前に、各製品に必要なハードウェアおよびシステム設定を確認してください。サポートされているバージョンの Red Hat OpenShift Container Platform を使用して、Linux にオンラインでインストールできます。
サポートされているバージョンの OpenShift Container Platform が必要です。たとえば、Red Hat OpenShift Service on AWS または Red Hat OpenShift Dedicated を使用できます。Kubernetes Operator 用のマルチクラスターエンジンをインストールする必要があります。
非推奨： Red Hat Advanced Cluster Management 2.7 以前のバージョンはサポートされなくなりました。ドキュメントはそのまま利用できますが、エラータやその他の更新は提供されません。
ベストプラクティス: 最新バージョンにアップグレードします。
FIPS の通知: spec.ingress.sslCiphers で独自の暗号を指定しない場合、multiclusterhub-operator は暗号のデフォルトリストを提供します。アップグレードして FIPS に準拠させるには、multiclusterhub リソースから ECDHE-ECDSA-CHACHA20-POLY1305 および ECDHE-RSA-CHACHA20-POLY1305 の 2 つの暗号を削除します。
このドキュメントは、特定のコンポーネントまたは機能が導入され、より新しいバージョンの OpenShift Container Platform でのみテストされない限り、サポートされる最も早い OpenShift Container Platform バージョンを参照します。
完全なサポート情報については、サポートマトリックス および Red Hat Advanced Cluster Management for Kubernetes のライフサイクルおよび更新ポリシー を参照してください。
インストール手順の詳細は、以下のドキュメントを参照してください。
1.1. パフォーマンスおよびスケーラビリティー
Red Hat Advanced Cluster Management for Kubernetes は、特定のスケーラビリティーおよびパフォーマンスデータを判断するのにテストされています。テストしたエリアは、主にクラスターのスケーラビリティーと検索パフォーマンスです。この情報は、環境を計画するときに使用できます。
注記: データは、テスト時のラボ環境から取得した結果をもとにしています。
Red Hat Advanced Cluster Management は、ベアメタルマシン上の 3 ノードハブクラスターを使用してテストされます。テスト時には、ソフトウェアコンポーネント制限の特定に十分な量のリソース容量 (CPU、メモリー、ディスク) が存在するようにします。結果は、お使いの環境、ネットワークの速度、および製品への変更により、異なる可能性があります。
1.1.1. マネージドクラスターの最大数
Red Hat Advanced Cluster Management が管理できるクラスターの最大数は、以下のような複数の要因により異なります。
- クラスター内のリソース数。この数はデプロイするポリシーやアプリケーションの数などの要素により異なります。
- スケーリングに使用する Pod 数など、ハブクラスターの設定。
マネージドクラスターは、Red Hat Enterprise Linux ハイパーバイザーでホストされるシングルノードの OpenShift 仮想マシンです。仮想マシンは、テストベッド内の単一のベアメタルマシンごとに高密度のクラスター数を実現するために使用されます。Sushy-emulator は、Redfish API を使用してアクセス可能なベアメタルクラスターを仮想マシンに持たせるために、libvirt とともに使用されます。次の Operator は、Topology Aware Lifecycle Manager、Local Storage Operator、および Red Hat OpenShift GitOps のテストインストールの一部です。次の表は、ラボ環境のスケーリング情報を示しています。
| ノード | 数 | オペレーティングシステム | ハードウェア | CPU コア数 | メモリー | ディスク |
|---|---|---|---|---|---|---|
| ハブクラスターのコントロールプレーン | 3 | OpenShift Container Platform | ベアメタル | 112 | 512 GiB | 446 GB SSD, 2.9 TB NVMe, 2 x 1.8 TB SSD |
| マネージドクラスター | 3500 | シングルノード OpenShift | 仮想マシン | 8 | 18 GiB | 120 GB |
1.1.2. スケーラビリティーの検索
検索コンポーネントのスケーラビリティーは、データストアのパフォーマンスにより異なります。クエリーの実行時間は、検索パフォーマンスを分析する際の重要な変数です。
1.1.2.1. クエリー実行時の考慮事項
クエリーを実行して結果が返されるまでの所要時間に、影響を与える事項が複数あります。環境のプランニングおよび設定時に、以下の項目を考慮してください。
キーワードの検索は効率的ではない。
多数のクラスターを管理している場合に
RedHatと検索すると、検索結果を受け取るのに時間がかかる場合があります。- 最初の検索は、ユーザーロールベースのアクセス制御ルールを収集するのに時間が余計にかかるため、2 番目以降の検索よりも時間がかかる。
要求の完了にかかる時間は、ユーザーのアクセスが許可されている namespace とリソースの数に比例する。
注記: 検索クエリーを保存して他のユーザーと共有する場合に、返される結果は、対象のユーザーのアクセスレベルにより異なります。ロールアクセスの詳細は、OpenShift Container Platform ドキュメントの RBAC の仕様によるパーミッションの定義および適用 を参照してください。
- 要求が全 namespace または全マネージドクラスターにアクセス権限のある非管理者ユーザーからの場合に、最も悪いパフォーマンスが確認された。
1.1.3. 可観測性のスケーラビリティー
可観測性サービスを有効にして使用する場合は、環境のプランニングが必要です。可観測性コンポーネントのインストール先である OpenShift Container Platform プロジェクトで、後ほど消費するリソースを確保します。使用予定の値は、可観測性コンポーネント全体での使用量合計です。
注記: データは、テスト時のラボ環境から取得した結果をもとにしています。結果は、お使いの環境、ネットワークの速度、および製品への変更により、異なる可能性があります。
1.1.3.1. 可観測性環境の例
このサンプル環境では、Amazon Web Service クラウドプラットフォームにハブクラスターとマネージドクラスターが配置されており、以下のトポロジーおよび設定が指定されています。
| ノード | フレーバー | 仮想 CPU | RAM (GiB) | ディスクタイプ | ディスクサイズ (GiB) | 数 | リージョン |
|---|---|---|---|---|---|---|---|
| マスターノード | m5.4xlarge | 16 | 64 | gp2 | 100 | 3 | sa-east-1 |
| ワーカーノード | m5.4xlarge | 16 | 64 | gp2 | 100 | 3 | sa-east-1 |
高可用性環境用に、可観測性のデプロイメントを設定します。高可用性環境の場合は、Kubernetes デプロイメントごとにインスタンスが 2 つ、StatefulSet ごとにインスタンスが 3 つ含まれます。
サンプルテストでは、さまざまな数のマネージドクラスターがメトリックのプッシュをシミュレーションし、各テストは 24 時間実行されます。以下のスループットを参照してください。
1.1.3.2. 書き込みスループット
| Pod | 間隔 (分) | 時系列 (分) |
|---|---|---|
| 400 | 1 | 83000 |
1.1.3.3. CPU 使用率 (ミリコア)
テスト時の CPU の使用率は安定しています。
| サイズ | CPU の使用率 |
|---|---|
| 10 クラスター | 400 |
| 20 クラスター | 800 |
1.1.3.4. RSS およびワーキングセットメモリー
RSS およびワーキングセットメモリーに関する以下の説明を参照してください。
-
メモリー使用量 RSS:
container_memory_rssのメトリックから取得。テスト時の安定性を維持します。 -
メモリー使用量のワーキングセット:
container_memory_working_set_bytesのメトリクスから取得。テストの進捗に合わせて増加します。
24 時間のテストで、以下の結果が得られました。
| サイズ | メモリー使用量 RSS | メモリー使用量のワーキングセット |
|---|---|---|
| 10 クラスター | 9.84 | 4.93 |
| 20 クラスター | 13.10 | 8.76 |
1.1.3.5. thanos-receive コンポーネントの永続ボリューム
重要: メトリックは、保持期間 (4 日) に達するまで thanos-receive に保管されます。他のコンポーネントでは、thanos-receive コンポーネントと同じボリューム数は必要ありません。
ディスクの使用量は、テストが進むに連れて増加します。データは 1 日経過後のディスク使用量であるため、最終的なディスク使用量は 4 倍にします。
以下のディスク使用量を参照してください。
| サイズ | ディスク使用量 (GiB) |
|---|---|
| 10 クラスター | 2 |
| 20 クラスター | 3 |
1.1.3.6. ネットワーク転送
テスト中、ネットワーク転送で安定性を確保します。サイズおよびネットワーク転送の値を確認します。
| サイズ | 受信ネットワーク転送 | 送信ネットワーク転送 |
|---|---|---|
| 10 クラスター | 1 秒あたり 6.55 MB | 1 秒あたり 5.80 MB |
| 20 クラスター | 1 秒あたり 13.08 MB | 1 秒あたり 10.9 MB |
1.1.3.7. Amazon Simple Storage Service (S3)
Amazon Simple Storage Service (S3) の合計使用量は増加します。メトリックデータは、デフォルトの保持期間 (5 日) に達するまで S3 に保存されます。以下のディスク使用量を参照してください。
| サイズ | ディスク使用量 (GiB) |
|---|---|
| 10 クラスター | 16.2 |
| 20 クラスター | 23.8 |
1.1.4. バックアップおよび復元のスケーラビリティー
大規模な環境で実行されたテストには、バックアップおよび復元用に以下のデータが表示されます。
| バックアップ | 所要時間 | リソース数 | バックアップメモリー |
|---|---|---|---|
| credentials | 2 分 5 秒 | リソース 18272 件 | バックアップサイズ 55MiB |
| managed clusters | 3 分 22 秒 | リソース 58655 件 | バックアップサイズ 38MiB |
| resources | 1 分 34 秒 | リソース 1190 件 | バックアップサイズ 1.7MiB |
| generic/user | 2 分 56 秒 | リソース 0 件 | バックアップサイズ 16.5KiB |
バックアップ合計時間は 10m です。
| バックアップ | 所要時間 | リソース数 |
|---|---|---|
| redentials | 47 分 8 秒 | リソース 18272 件 |
| resources | 3 分 10 秒 | リソース 1190 件 |
| generic/user backup | 0 分 | リソース 0 件 |
復元合計時間は 50m18s です。
バックアップファイルの数は、BackupSchedule の作成時に設定された veleroTtl パラメーターオプションを使用してプルーニングされます。指定された TTL (存続期間) よりも作成時刻が古いバックアップは期限切れになり、Velero によって保管場所から自動的に削除されます。
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: BackupSchedule metadata: name:schedule-acm namespace:open-cluster-management-backup spec: veleroSchedule:0 */1 * * * veleroTtl:120h
1.1.5. クラスターのサイジング
Red Hat Advanced Cluster Management for Kubernetes クラスターは一意で、以下のガイドラインは一意のデプロイメントサイズを提供します。推奨事項は、サイズと目的で分類されています。
Red Hat Advanced Cluster Management は、サポートサービスのサイジングおよび配置に以下の条件が適用されます。
- クラスター全体で障害の発生する可能性のあるドメインを分離する アベイラビリティーゾーン。一般的なクラスターは、3 つ以上のアベイラビリティゾーンでほぼ同等のワーカーノード容量を備えています。
- 仮想 CPU の予約と制限 をもとに、コンテナーに割り当てるワーカーノードの仮想 CPU 容量が確立されます。仮想 CPU は Kubernetes のコンピュートユニットと同じです。詳細は、Kubernetes の Meaning of CPU を参照してください。
- メモリーの予約と制限 をもとに、コンテナーに割り当てるワーカーノードのメモリー容量が確立されます。
- 永続データ は製品によって管理され、Kubernetes によって使用される etcd クラスターに保存されます。
重要: OpenShift Container Platform の場合、クラスターのマスターノードを 3 つのアベイラビリティーゾーンに分散します。
1.1.5.1. 製品環境
注記: 以下の要件は、最小要件ではありません。
| ノードのタイプ | アベイラビリティーゾーン | etcd | 総予約メモリー | 予約済み CPU の合計 |
|---|---|---|---|---|
| マスター | 3 | 3 | OpenShift Container Platform のサイジングガイドライン別 | OpenShift Container Platform のサイジングガイドライン別 |
| ワーカーまたはインフラストラクチャー | 3 | 1 | 12 GB | 6 |
OpenShift Container Platform クラスターは、Red Hat Advanced Cluster Management に加え、追加のサービスを実行してクラスター機能をサポートします。詳細は、インフラストラクチャーノードへの Red Hat Advanced Cluster Management ハブクラスターのインストール を参照してください。
1.1.5.1.1. 追加サービスの OpenShift Container Platform
クラスター全体で障害の発生する可能性のあるドメインを分離する アベイラビリティーゾーン。
| サービス | ノード数 | アベイラビリティーゾーン | インスタンスサイズ | 仮想 CPU | メモリー | ストレージサイズ | リソース |
|---|---|---|---|---|---|---|---|
| Amazon Web Services 上の OpenShift Container Platform | 3 | 3 | m5.xlarge | 4 | 16 GB | 120 GB | 詳細は、OpenShift Container Platform 製品ドキュメントの カスタマイズによる AWS へのクラスターのインストール を参照してください。 また、マシンタイプ についても確認してください。 |
| OpenShift Container Platform on Google Cloud Platform | 3 | 3 | N1-standard-4 (0.95–6.5 GB) | 4 | 15 GB | 120 GB | クォータの詳細は、Google Cloud Platform の製品ドキュメント を参照してください。 また、マシンタイプ についても確認してください。 |
| OpenShift Container Platform on Microsoft Azure | 3 | 3 | Standard_D4_v3 | 4 | 16 GB | 120 GB | 詳細は、OpenShift Container Platform ドキュメントの Azure アカウントの設定 を参照してください。 |
| VMware vSphere 上の OpenShift Container Platform | 3 | 3 | 4 2 ソケットごとのコア) | 16 GB | 120 GB | 詳細は、以下の 製品ドキュメント を参照してください。 | |
| IBM Z システムの OpenShift Container Platform | 3 | 3 | 10 | 16 GB | 100 GB | 詳細は、OpenShift Container Platform ドキュメントの クラスターの IBM Z システムへのインストール を参照してください。 IBM Z システムには、同時マルチスレッド (SMT) を設定する機能があり、各コアで実行できる仮想 CPU の数を拡張します。SMT を設定している場合は、1 つの物理コア (IFL) は 2 つの論理コア (スレッド) を提供します。ハイパーバイザーは、2 つ以上の仮想 CPU を提供できます。 1 個の仮想 CPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、数式「(コアごとのスレッド × コア数) × ソケット数 = 仮想 CPU」を使用して対応する比率を計算します。 SMT の詳細は、Simultaneous multithreading を参照してください。 | |
| IBM Power Systems 上の OpenShift Container Platform | 3 | 3 | 16 | 16 GB | 120 GB | 詳細は、OpenShift Container Platform ドキュメントの クラスターの Power システムへのインストール を参照してください。 IBM Power システムには、同時マルチスレッド (SMT) を設定する機能があり、各コアで実行できる仮想 CPU の数を拡張します。SMT を設定した場合、その SMT レベルでは仮想 CPU 16 個という要件を満たす方法が決まります。以下は、最も一般的な設定です。 SMT-8 (IBM Power VM を実行しているシステムのデフォルト設定) で実行しているコア 2 つでは、必要とされる 16 個の仮想 CPU を提供します。 SMT-4 で実行しているコア 4 つでは、必要とされる 16 個の仮想 CPU を提供します。 SMT の詳細は、Simultaneous multithreading を参照してください。 | |
| OpenShift Container Platform オンプレミス | 3 | 4 | 16 GB | 120 GB | 詳細は、以下の 製品ドキュメント を参照してください。 Red Hat Advanced Cluster Management for Kubernetes ハブクラスターは、OpenShift Container Platform ベアメタルにインストールし、サポートできます。ハブクラスターは、スケジュール可能な 3 つのコントロールプレーンノードがあり、追加のワーカーが 0 の、コンパクトなベアメタルトポロジーで実行できます。 |
1.1.5.1.2. シングルノードの OpenShift Container Platform クラスターの作成および管理
要件は、単一ノードへのインストール を参照してください。各クラスターは固有であるため、次のガイドラインでは、サイズと目的によって分類されたデプロイメント要件のサンプルのみを提供します。
クラスター全体で障害の発生する可能性のあるドメインを分離する アベイラビリティーゾーン。一般的なクラスターは、3 つ以上のアベイラビリティゾーンでほぼ同等のワーカーノード容量を備えています。高可用性はサポートされていません。
重要: OpenShift Container Platform の場合、クラスターのマスターノードを 3 つのアベイラビリティーゾーンに分散します。
3500 個のシングルノード OpenShift Container Platform クラスターを作成および管理するための要件の例を参照してください。Red Hat Advanced Cluster Management を使用してシングルノードの OpenShift クラスター (同時に 230 個以上がプロビジョニングされる) を作成し、それらのシングルノードの OpenShift クラスターをハブクラスターで管理するための最小要件を確認します。
| ノード数 | メモリー (クラスターのピーク使用量) | メモリー (シングルノードの最小値から最大値) | CPU クラスター | CPU シングルノード |
|---|---|---|---|---|
| 3 | 289 GB | 64 GB - 110 GB | 90 | 44 |
