2.4. コントロールプレーンノードのサイジング

コントロールプレーンノードリソースの要件は、クラスター内のノード数によって異なります。コントロールプレーンノードのサイズについての以下の推奨内容は、テストに重点を置いた場合のコントロールプレーンの密度の結果に基づいています。コントロールプレーンのテストでは、ノード数に応じて各 namespace でクラスター全体に展開される以下のオブジェクトを作成します。

  • 12 イメージストリーム
  • 3 ビルド設定
  • 6 ビルド
  • それぞれに 2 つのシークレットをマウントする 2 Pod レプリカのある 1 デプロイメント
  • 2 つのシークレットをマウントする 1 Pod レプリカのある 2 デプロイメント
  • 先のデプロイメントを参照する 3 つのサービス
  • 先のデプロイメントを参照する 3 つのルート
  • 10 のシークレット (それらの内の 2 つは先ののデプロイメントでマウントされる)
  • 10 の設定マップ (それらの内の 2 つは先のデプロイメントでマウントされる)
ワーカーノードの数クラスターの負荷 (namespace)CPU コア数メモリー (GB)

25

500

4

16

100

1000

8

32

250

4000

16

96

3 つのコントロールプレーンノード (またはマスターノード) がある大規模で高密度のクラスターでは、いずれかのノードが停止、起動、または障害が発生すると、CPU とメモリーの使用量が急上昇します。障害は、コストを節約するためにシャットダウンした後にクラスターが再起動する意図的なケースに加えて、電源、ネットワーク、または基礎となるインフラストラクチャーの予期しない問題が発生することが原因である可能性があります。残りの 2 つのコントロールプレーン (別称マスター) ノードは、高可用性を実現するために負荷を処理する必要があります。これにより、リソース使用量が増加します。これは、マスターが遮断 (cordon)、ドレイン (解放) され、オペレーティングシステムおよびコントロールプレーン Operator の更新を適用するために順次再起動されるため、アップグレード時に想定される動作になります。障害が繰り返し発生しないようにするには、コントロールプレーンノード(別名マスターノード)で全体的な CPU およびメモリーリソースの使用量を最大でも利用可能な容量の半分に維持し、使用量の急増に対応できるようにします。リソース不足による潜在的なダウンタイムを回避するために、コントロールプレーンノードの CPU およびメモリーを適宜増やします。

重要

ノードのサイジングは、クラスター内のノードおよびオブジェクトの数によって異なります。また、オブジェクトがそのクラスター上でアクティブに作成されるかどうかによっても異なります。オブジェクトの作成時に、コントロールプレーンは、オブジェクトが running フェーズにある場合と比較し、リソースの使用状況においてよりアクティブな状態になります。

Operator Lifecycle Manager (OLM) はコントロールプレーンノードで実行され、OLM のメモリーフットプリントは OLM がクラスター上で管理する必要のある namespace およびユーザーによってインストールされる Operator の数によって異なります。OOM による強制終了を防ぐには、コントロールプレーンノードのサイズを適切に設定する必要があります。以下のデータポイントは、クラスター最大のテストの結果に基づいています。

namespace 数アイドル状態の OLM メモリー (GB)ユーザー Operator が 5 つインストールされている OLM メモリー (GB)

500

0.823

1.7

1000

1.2

2.5

1500

1.7

3.2

2000

2

4.4

3000

2.7

5.6

4000

3.8

7.6

5000

4.2

9.02

6000

5.8

11.3

7000

6.6

12.9

8000

6.9

14.8

9000

8

17.7

10,000

9.9

21.6

重要

インストール手法にインストーラーでプロビジョニングされるインフラストラクチャーを使用した場合には、実行中の OpenShift Container Platform 4.8 クラスターでコントロールプレーンノードのサイズを変更できません。その代わりに、ノードの合計数を見積もり、コントロールプレーンノードの推奨サイズをインストール時に使用する必要があります。

重要

この推奨事項は、ネットワークプラグインとして OpenShift SDN を使用して OpenShift Container Platform クラスターでキャプチャーされたデータポイントに基づいています。

注記

OpenShift Container Platform 4.8 では、デフォルトで CPU コア (500 ミリコア) の半分がシステムによって予約されます (OpenShift Container Platform 3.11 以前のバージョンと比較)。サイズはこれを考慮に入れて決定されます。

2.4.1. Amazon Web Services(AWS)マスターインスタンスのフレーバーサイズの拡大

クラスター内の AWS マスターノードがオーバーロードし、マスターノードでより多くのリソースが必要な場合は、マスターインスタンスのフレーバーサイズを増やすことができます。

注記

AWS マスターインスタンスのフレーバーサイズを増やす前に、etcd をバックアップすることが推奨されます。

前提条件

  • AWS の IPI(installer-provisioned infrastructure)または UPI(ユーザーによってプロビジョニングされるインフラストラクチャー)クラスターがある。

手順

  1. AWS コンソールを開き、マスターインスタンスを取得します。
  2. マスターインスタンスを 1 つ停止します。
  3. 停止するインスタンスを選択し、ActionsInstance SettingsChange instance type をクリックします。
  4. インスタンスをより大きなタイプに変更し、型が以前の選択と同じベースであることを確認し、変更を適用します。たとえば、m 5.xlarge を m 5.2xlarge または m5.4xlarge に変更することができます
  5. インスタンスをバックアップし、次のマスターインスタンスの手順を繰り返します。