第2章 Red Hat OpenShift Dev Spaces をスケーラブルに実行する

リソース量とオブジェクトの最大値

Kubernetes クラスター内のリソース数に厳密な制限はありませんが、大規模なクラスターでは考慮事項 がいくつかあります。

リソース要件

Kubernetes に Red Hat OpenShift Dev Spaces をデプロイする場合、リソース要件を正確に計算し、各 CDE のメモリーと CPU/GPU のニーズを決定して、クラスターの適切なサイズを決定することが重要です。一般に、CDE のサイズはワーカーノードのサイズによって制限され、それよりも大きくすることはできません。CDE のリソース要件は、特定のワークロードと設定によって大きく異なる場合があります。たとえば、単純な CDE では数百メガバイトのメモリーしか必要としませんが、より複雑な CDE では数ギガバイトのメモリーと複数の CPU コアが必要になります。

etcd の使用

Kubernetes クラスターの設定と状態の主なデータストアは etcd です。ノード、Pod、サービス、カスタムリソースに関する情報を含む、クラスターの状態と設定が保持されます。分散型キーバリューストアである etcd は、特定のしきい値を超えてスケーリングできず、etcd のサイズが大きくなるにつれてクラスターの負荷も大きくなり、安定性が損なわれるリスクがあります。

要因としてのオブジェクトサイズ

etcd に保存されるオブジェクトの総数だけでなくサイズも、パフォーマンスと安定性に大きな影響を与える重要な要素です。etcd に保存される各オブジェクトはスペースを消費し、オブジェクトの数が増えると、etcd の全体的なサイズも大きくなります。オブジェクトが大きくなればなるほど、etcd で占めるスペースも大きくなります。たとえば、etcd は、比較的大きな Kubernetes オブジェクトが数千個あるだけで過負荷になる可能性があります。

Dev Workspace オブジェクト

大規模な Kubernetes デプロイメント、特に CDE を表す DevWorkspace オブジェクトなどの多数のカスタムリソースが含まれるデプロイメントでは、etcd が重大なパフォーマンスのボトルネックになる可能性があります。

OLMConfig

Operator が Operator Lifecycle Manager (OLM) によってインストールされると、Operator が監視するように設定されているすべての namespace に、その CSV の簡素化されたコピーが作成されます。これらの簡素化された CSV は「Copied CSV」と呼ばれ、特定の namespace でどのコントローラーがリソースイベントをアクティブに調整しているかをユーザーに伝えます。特に大規模なクラスターでは、namespace とインストールされた Operator の数が数百または数千になる傾向があり、Copied CSV は、OLM メモリー使用量、クラスター etcd 制限、ネットワークなど、持続不可能な量のリソースを消費します。すべての namespace にコピーされる CSV を削除するには、OLMConfig オブジェクトを適切に設定します。

クラスターの自動スケーリング

クラスターの自動スケーリングは Kubernetes の強力な機能ですが、常にそれに頼れるわけではありません。環境上の負荷データを分析して毎日または毎週の使用パターンを検出することにより、常に予測スケーリングを検討する必要があります。ワークロードがパターンに従っており、1 日を通して急激なピークが発生する場合は、それに応じてワーカーノードをプロビジョニングすることを検討する必要があります。たとえば、ワークスペースの数が営業時間中に増加し、営業時間外に減少するという予測可能な負荷パターンがある場合、予測スケーリングを使用して、予想される負荷に基づいてワーカーノードの数を調整できます。これにより、オフピーク時のコストを最小限に抑えながら、ピーク負荷を処理するために十分なリソースを確保できるようになります。

マルチクラスター

設計上、Red Hat OpenShift Dev Spaces はマルチクラスターに対応しておらず、クラスターごとに 1 つのインスタンスしか持つことができません。ただし、Red Hat OpenShift Dev Spaces を各クラスターにデプロイし、ロードバランサーまたは DNS ベースのルーティングを使用して、ユーザーの場所やその他の基準に基づいてトラフィックを適切なインスタンスに振り分けることで、Red Hat OpenShift Dev Spaces をマルチクラスター環境で実行できます。このアプローチは、ワークロードを複数のクラスターに分散し、クラスター障害が発生した場合に冗長性を提供することで、パフォーマンスと信頼性の向上に貢献できます。