第6章 オブジェクトの最大値に合わせた環境計画

ノード数

2,000

2,000

Pod 数：footnote:numberofpodsmajorrelease[ここに記載の Pod 数は、テスト用の Pod 数です。実際の Pod 数は、アプリケーションのメモリー、CPU、ストレージ要件により異なります。]

150,000

150,000

ノードあたりの Pod 数

250

500 footnote:podspernodemajorrelease[これは、ワーカーノードごとに 500 の Pod を持つ 100 ワーカーノードを含むクラスターでテストされています。デフォルトの maxPods は 250 です。500 maxPods を取得するには、クラスターはカスタム KubeletConfig を使用して install-config.yaml ファイルで hostPrefix が 22 に指定され、maxPods が 500 に設定された状態で作成される必要があります。Persistant Volume Claim（永続ボリューム要求、PVC) が割り当てられている Pod の最大数は、PVC の割り当て元のストレージバックエンドによって異なります。このテストでは、OpenShift Container Storage v4 (OCS v4) のみが本書で説明されているノードごとの Pod 数に対応することができました。]

コアあたりの Pod 数

デフォルト値はありません。

デフォルト値はありません。

namespace 数 footnote:numberofnamepacesmajorrelease[有効なプロジェクトが多数ある場合、キースペースが過剰に拡大し、スペースのクォータを超過すると、etcd はパフォーマンスの低下による影響を受ける可能性があります。etcd ストレージを解放するために、デフラグを含む etcd の定期的なメンテナンスを行うことを強くお勧めします。]

10,000

10,000

ビルド数

10,000（デフォルト Pod RAM 512 Mi）- Pipeline ストラテジー

10,000（デフォルト Pod RAM 512 Mi）- Source-to-Image (S2I) ビルドストラテジー

namespace ごとの Pod 数footnote:objectpernamespacemajorrelease[これは、状態の変更に対する対応として、特定の namespace にある全オブジェクトに対して反復する必要のある、システム内のコントロールループ数のことです。単一の namespace に特定タイプのオブジェクトの数が多くなると、ループのコストが上昇し、特定の状態変更を処理する速度が低下します。この制限については、アプリケーションの各種要件を満たすのに十分な CPU、メモリー、およびディスクがシステムにあることが前提となっています。]

25,000

25,000

サービス数footnote:servicesandendpointsmajorrelease[iptables では、各サービスポートと各サービスのバックエンドに対応するエントリーが含まれます。特定のサービスのバックエンド数は、エンドポイントのオブジェクトサイズに影響があり、その結果、システム全体に送信されるデータサイズにも影響を与えます。]

10,000

10,000

namespace ごとのサービス数

5,000

5,000

サービスごとのバックエンド数

5,000

5,000

namespace ごとのデプロイメント数 footnote:objectpernamespacemajorrelease[]

2,000

2,000