第1章 インストールとアップグレード
Red Hat Advanced Cluster Management ハブクラスターを含むコンポーネントのインストール、アップグレード、および削除を管理する Operator Lifecycle Manage を使用して Red Hat Advanced Cluster Management for Kubernetes をインストールします。Red Hat Advanced Cluster Management は multicluster engine Operator に依存し、これを使用するため、インストール中に MultiClusterHub リソースを作成すると、Red Hat Advanced Cluster Management Operator は multicluster engine Operator を自動的にインストールし、MultiClusterEngine リソースを作成します。
Red Hat Advanced Cluster Management をインストールするには、サポートされているバージョンの OpenShift Container Platform が必要です。
インストールする前に、各製品に必要なハードウェアおよびシステム設定を確認してください。サポートされているバージョンの Red Hat OpenShift Container Platform を使用して、Linux にオンラインでインストールできます。
完全なサポート情報は、Red Hat Advanced Cluster Management サポートマトリックス と、Red Hat Advanced Cluster Management for Kubernetes のライフサイクルと更新ポリシー を参照してください。
非推奨: Red Hat Advanced Cluster Management 2.8 以前のバージョンはサポートされなくなりました。ドキュメントはそのまま利用できますが、エラータやその他の更新は提供されません。
ベストプラクティス: 最新バージョンにアップグレードします。
FIPS 通知: spec.ingress.sslCiphers で独自の暗号を指定しない場合は、multiclusterhub-operator によってデフォルトの暗号リストが提供されます。アップグレードして FIPS に準拠させるには、MultiClusterHub リソースから ECDHE-ECDSA-CHACHA20-POLY1305 と ECDHE-RSA-CHACHA20-POLY1305 の暗号を削除します。
このドキュメントでは、特定のコンポーネントまたは機能が OpenShift Container Platform のより新しいバージョンでのみデプロイおよびテストされている場合を除き、サポートされている最も古い OpenShift Container Platform バージョンを参照します。
Red Hat Advanced Cluster Management for Kubernetes をインストールすると、マルチノードクラスターの実稼働環境が設定されます。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. 検索のスケーラビリティー リンクのコピーリンクがクリップボードにコピーされました!
検索コンポーネントのスケーラビリティーは、データストアのパフォーマンスにより異なります。クエリーの実行時間は、検索パフォーマンスを分析する際の重要な変数です。
次のクエリーランタイムに関する考慮事項を参照してください。
クエリーを実行して結果が返されるまでの所要時間に、影響を与える事項が複数あります。環境のプランニングおよび設定時に、以下の項目を考慮してください。
キーワードの検索は効率的ではない。
多数のクラスターを管理している場合に
RedHatと検索すると、検索結果を受け取るのに時間がかかる場合があります。- 最初の検索は、ユーザーロールベースのアクセス制御ルールを収集するのに時間が余計にかかるため、2 番目以降の検索よりも時間がかかる。
要求の完了にかかる時間は、ユーザーのアクセスが許可されている namespace とリソースの数に比例する。
注記: 検索クエリーを保存して他のユーザーと共有する場合に、返される結果は、対象のユーザーのアクセスレベルにより異なります。ロールアクセスの詳細は、OpenShift Container Platform ドキュメントの RBAC の使用によるパーミッションの定義および適用 を参照してください。
- 要求が全 namespace または全マネージドクラスターにアクセス権限のある非管理者ユーザーからの場合に、最も悪いパフォーマンスが確認された。
1.1.3. 可観測性のスケーラビリティー リンクのコピーリンクがクリップボードにコピーされました!
可観測性サービスを有効にして使用する場合は、環境のプランニングが必要です。後のリソース消費は、可観測性コンポーネントがインストールされている OpenShift Container Platform プロジェクトによるものです。使用予定の値は、可観測性コンポーネント全体での使用量合計です。
注記: データは、テスト時のラボ環境から取得した結果をもとにしています。結果は、お使いの環境、ネットワークの速度、および製品への変更により、異なる可能性があります。
可観測性環境の例
このサンプル環境では、Amazon Web Service クラウドプラットフォームにハブクラスターとマネージドクラスターが配置されており、以下のトポロジーおよび設定が指定されています。
Expand 表1.2 サンプルの可観測性環境の表 ノード フレーバー 仮想 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 時間実行されます。以下のスループットを参照してください。
Expand 表1.3 書き込みスループットの表 Pod 間隔 (分) 時系列 (分) 400
1
83000
CPU 使用率 (ミリコア)
テスト中の CPU 使用率は以下のとおりです。
Expand 表1.4 CPU 使用量 (ミリコア) の表 サイズ CPU の使用率 10 クラスター
400
20 クラスター
800
RSS およびワーキングセットメモリー
-
メモリー使用量 RSS:
container_memory_rssのメトリックから取得。テスト時の安定性を維持します。 メモリー使用量のワーキングセット:
container_memory_working_set_bytesのメトリクスから取得。テストの進捗に合わせて増加します。24 時間のテストで、以下の結果が得られました。
Expand 表1.5 RSS とワーキングセットメモリーのテーブル サイズ メモリー使用量 RSS メモリー使用量のワーキングセット 10 クラスター
9.84
4.93
20 クラスター
13.10
8.76
-
メモリー使用量 RSS:
thanos-receiveコンポーネントの永続ボリューム重要: メトリックは、保持期間 (4 日) に達するまで
thanos-receiveに保管されます。他のコンポーネントでは、thanos-receiveコンポーネントと同じボリューム数は必要ありません。ディスクの使用量は、テストが進むに連れて増加します。データは 1 日経過後のディスク使用量であるため、最終的なディスク使用量は 4 倍にします。
Expand 表1.6 ディスク使用量の表 サイズ ディスク使用量 (GiB) 10 クラスター
2
20 クラスター
3
ネットワーク転送
テスト中、ネットワーク転送で安定性を確保します。サイズおよびネットワーク転送の値を確認します。
Expand 表1.7 テーブル形式のネットワーク転送 サイズ 受信ネットワーク転送 送信ネットワーク転送 10 クラスター
1 秒あたり 6.55 MB
1 秒あたり 5.80 MB
20 クラスター
1 秒あたり 13.08 MB
1 秒あたり 10.9 MB
Amazon Simple Storage Service (S3)
Amazon Simple Storage Service (S3) の合計使用量は増加します。メトリックデータは、デフォルトの保持期間 (5 日) に達するまで S3 に保存されます。以下のディスク使用量を参照してください。
Expand 表1.8 Amazon Simple Storage Service (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 によって保管場所から自動的に削除されます。