Red Hat OpenShift における容量管理とオーバーコミットに関するベストプラクティス

Red Hat OpenShift における容量管理とオーバーコミットは複雑に思われるかもしれませんが、いくつかの重要な概念を理解すればわかりやすくなります。ここでは、Pod リクエスト、制限、およびそれらを設定するためのベストプラクティスについて知っておく必要がある内容と、これらのトピックが効果的な容量管理とオーバーコミットにどのように役立つかについて説明します。

Pod リクエスト

Pod リクエストは、コンテナの実行に最低限必要なものとして指定したコンピュートリソース (メモリーや CPU など) の量です。たとえば、1 Gi のメモリーリクエストを設定した場合、スケジューラーは、Pod をノードに配置する前に少なくとも 1 Gi のメモリーを Pod が使用できるようにします。

容量管理のメリット：必須リソースが各 Pod に対して確保されるようにすることで、リソース不足を回避し、すべての Pod に効果的な運用に必要な最小限のリソースが割り当てることができます。

Pod 制限

それに対して Pod 制限は、Pod が使用できるリソースの最大量です。メモリー制限を 2 Gi に設定した場合、Pod は最大 2 Gi のメモリーを使用できますが、それ以上は使用できません。これは、カーネルによって cgroups を介して強制され、単一の Pod がリソースを消費しすぎて他の Pod に影響を与えることを防ぎます。

容量管理のメリット：個々の Pod によるリソースの使い過ぎを防ぎ、実行中のすべての Pod に対してリソースを均等に分散することができます。

オーバーコミット

オーバーコミットは、制限がリクエストを超えている状態です。たとえば、Pod のメモリーリクエストが 1 Gi で、制限が 2 Gi である場合、Pod は 1 Gi のリクエストに基づいてスケジュールされますが、最大 2 Gi まで使用できます。これは Pod が 200% オーバーコミットされることを意味します。保証されているメモリー量の 2 倍を使用できるからです。

容量管理のメリット：Pod が追加リソースを、利用可能な場合に、追加リソースの保証なしに使用できるようにすることで、クラスタリソースのより効率的な利用が可能になります。

リクエストと制限を設定しない場合の影響

リクエストと制限により、Red Hat OpenShift インスタンスが効率的かつ予測どおりに実行されるようになります。これらを定義しない場合には、次のような影響が出ます。

保証されたリソースがない

リソースリクエストを設定しない場合、スケジューラーは Pod に対して特定の量の CPU またはメモリーを保証しません。これにより、ノードの負荷が高いときにパフォーマンスが低下したり、Pod に障害が発生したりする可能性があります。

リソース使用量の上限がない

制限がなければ、コンテナは必要なだけ CPU とメモリーを使用できます。これにより、使用可能なすべてのリソースを 1 つのコンテナが使い果たすなどのリソースの枯渇が発生し、他のコンテナに障害が発生したり、それらのコンテナがエビクトされたりする可能性があります。

容量管理のメリット：リクエストと制限の両方を設定することで、リソース割り当てのバランスが維持され、アンダープロビジョニング (リソースの枯渇) とオーバープロビジョニング (リソースの占有) の両方を防ぐことができます。

リクエストと制限を設定する際のベストプラクティス

一般に、リクエストと制限を設定する際に適用できる 5 つのベストプラクティスがあります。

1. メモリーと CPU のリクエストを常に設定する
2. CPU の制限を設定しない (スロットリングにつながる可能性があるため)
3. ワークロードを監視する。一定期間の平均使用量に基づいてリクエストを設定する
4. メモリー制限をリクエストの倍数に設定する
5. Vertical Pod Autoscaler (VPA) を使用して、これらの値を徐々にチューニングし、調整する

容量管理のメリット：これらのプラクティスにより、過剰な割り当てを回避しながら、各 Pod に必要なリソースを確実に確保できるため、効率的なリソース使用とクラスタのパフォーマンス向上につながります。

Vertical Pod Autoscaler (VPA) を使用して適切なサイズを設定

Red Hat OpenShift の Vertical Pod Autoscaler (VPA) コンポーネントは、Pod がより多くのリソースを必要とする場合、その Pod に割り当てられる CPU およびメモリーの量を調整します。VPA を使用する際は、次のガイダンスに留意してください。

• VPA を推奨 (Recommendation) モードのみでインストールして設定する
• Pod での実際の負荷をシミュレーションする
• 推奨値を観察し、それに応じて Pod リソースを調整する

推奨 (Recommendation) モードのみで使用する理由

VPA を自動 (Automatic) モードに設定すると、Pod が再起動されて推奨値に調整されます。Red Hat OpenShift 4.16 の時点で、インプレース VPA (再起動なし) はアルファ版で利用できます。

推奨機能の監視期間の調整

VPA はカスタムの推奨機能をサポートしており、ユーザーのニーズに応じて監視期間を 1 日、1 週間、または 1 カ月のいずれかに設定できます。詳細については、「Vertical Pod Autoscaler を使用した Pod リソースレベルの自動調整」を参照してください。

容量管理のメリット：VPA は、実際の使用パターンに基づいてリソースリクエストと制限を動的に調整するのに役立ちます。これにより、最適なリソース割り当てが確保され、オーバーコミットが最小限に抑えられます。

Red Hat OpenShift のシステム予約済みリソース

リソースをシステム予約済みとして指定することができます。つまり、Red Hat OpenShift は、kubelet やコンテナランタイムなどのシステムレベルのプロセスのために、ノードリソース (CPU およびメモリー) の一部を割り当てます。これには、次のような多くのメリットがあります。

• システムプロセス専用のリソースを確保し、アプリケーション・ワークロードとの競合を防ぐ
• 重要なシステムサービスのリソース枯渇を回避することで、ノードの安定性とパフォーマンスを向上させる
• クラスタの信頼性の高い動作と予測可能なパフォーマンスを維持する

OpenShift のドキュメントの自己管理型 OpenShift クラスタの手順に従うことで、ノードの自動リソース割り当てを有効にすることができます。Red Hat OpenShift Service on AWS (ROSA) のようなマネージド型 OpenShift インスタンスが、これらを管理します。

容量管理のメリット：システムプロセスにリソースを割り当てることで、重要なサービスがスムーズに実行され、システムレベルのリソース競合によるアプリケーション・パフォーマンスの中断を防ぎます。

クラスタ自動スケーラー

クラスタ自動スケーラーは、必要に応じて自動的にノードを追加または削除します。これは、Horizontal Pod Autoscaler (HPA) と連携します。詳細については、OpenShift クラスタ自動スケーラーガイドおよび自動スケーリングに関する OpenShift ドキュメントを参照してください。

容量管理のメリット：クラスタ自動スケーラーは、クラスタが現在のワークロードを処理するのに適切な数のノードを持ち、必要に応じて自動的にスケールアップまたはスケールダウンできるようにします。これにより、最適なリソース使用率とコスト効率を維持できます。

ClusterResourceOverride Operator (CRO)

ClusterResourceOverride Operator は、リソース割り当てを最適化し、クラスタ全体でバランスの取れた効率的な使用を確保します。

構成例：

• CPU リクエスト：100 ミリコア (0.1 コア)
• メモリーリクエスト：200 MiB (メガバイト)
• CPU 制限：200 ミリコア (0.2 コア)
• メモリー制限：400 MiB

オーバーライド：

• CPU リクエストのオーバーライド：リクエストの 50%
• メモリーリクエストのオーバーライド：リクエストの 75%
• CPU 制限のオーバーライド：リクエストの 2 倍
• メモリー制限のオーバーライド：リクエストの 2 倍

リソースの調整：

• CPU リクエスト：100 ミリコア × 50% = 50 ミリコア (0.05 コア)
• メモリーリクエスト：200 MiB × 75% = 150 MiB
• CPU 制限：50 ミリコア × 2 = 100 ミリコア (0.1 コア)
• メモリー制限：150 MiB × 2 = 300 MiB

詳細については、「Cluster Resource Override Operator を使用したクラスタレベルのオーバーコミット」を参照してください。

容量管理のメリット：デフォルトのリソースリクエストと制限をオーバーライドすることによって、リソースが効率的に割り当てられ、リソースの活用が不十分な状態およびオーバーコミットの両方を防ぐことができます。

スケーラビリティのエンベロープ

私はスケーラビリティのエンベロープを高次元の立方体として捉えています。エンベロープの範囲を超えなければ、パフォーマンスのサービスレベル目標 (SLO) を満たし、Red Hat OpenShift クラスタは円滑に機能します。1 つの次元に沿って動かすと、他の次元の容量が減少します。OpenShift ダッシュボードを使用して、グリーンゾーン (クラスタオブジェクトのスケーリングを安全に行える) とレッドゾーン (これを超えてクラスタオブジェクトをスケーリングしてはいけない) を監視できます。

詳細については、ノードメトリクス・ダッシュボードを参照してください。

容量管理のメリット：スケーラビリティのエンベロープを理解し、その範囲内で運用することで、さまざまな負荷の下でもクラスタが確実に動作し、リソースのボトルネックを回避して一貫したパフォーマンスを維持できるようになります。

Pod の自動スケーリング

Red Hat OpenShift では、Pod を自動スケーリングする方法がいくつかあります。Vertical Pod Autoscaler (VPA) についてはすでに説明しましたが、他の戦略もあります。

Horizontal Pod Autoscaler (HPA)

HPA は、レプリカをさらに追加することで、Pod を水平方向にスケーリングします。これは、実稼働環境のステートレス・アプリケーションに役立ちます。負荷処理を改善し、メモリー不足 (OOM) による強制終了を回避することで、アプリケーションのパフォーマンスと稼働時間が向上します。詳細については、「Horizontal Pod Autoscaler での Pod の自動スケーリング」を参照してください。

Custom Metric Autoscaler

ユーザー定義のメトリクスに基づいて Pod をスケーリングします。プロダクション、テスト、開発などのさまざまな環境に適しています。特定の圧力ポイントに基づいた監視とスケーリングにより、アプリケーションのアップタイムとパフォーマンスを向上させます。詳細については、「Custom Metrics Autoscaler Operator の概要」を参照してください。

容量管理のメリット：ワークロードの需要に基づいた自動スケーリングにより、アプリケーションはさまざまな負荷の処理に必要なリソースを常に確保できるようになり、パフォーマンスとリソースの効率が向上します。

OpenShift スケジューラー

OpenShift スケジューラーの LowNodeUtilization プロファイルは、Pod をノード間で均等に分散して、各ノードのリソース使用率を低くします。以下のようなメリットがあります。

• 必要なノード数を最小限に抑えることで、クラウド環境のコスト効率を実現
• クラスタ全体のリソース割り当てを改善
• データセンターのエネルギー効率を改善
• ノードの過負荷を防ぎパフォーマンスを強化
• ワークロードの負荷分散によるリソース枯渇を防止

詳細については、「スケジューラープロファイルを使用した Pod のスケジューリング」を参照してください。

容量管理のメリット：リソースを均等に分散することで、スケジューラーはホットスポットや使用率の低いノードを回避し、よりバランスの取れた効率的なクラスタを実現します。

OpenShift Descheduler

AffinityAndTaints プロファイルは、Pod 間のアンチアフィニティ、ノードアフィニティ、ノードテイントに違反する Pod を除去します。以下のようなメリットがあります。

• 最適ではない Pod 配置の修正
• ノードアフィニティとアンチアフィニティの適用
• ノードテイントの変更に対応して、互換性のある Pod のみがノードに残るようにする

詳細については、「Descheduler を使用した Pod のエビクト」を参照してください。

容量管理のメリット：Descheduler により、最適な Pod 配置を長期間にわたって維持し、クラスタの変化に適応して、アフィニティとテイントの制約を尊重しながらリソースを効率的に使用することができます。

これらのベストプラクティスに従い、OpenShift で利用可能なツールを使用することで、容量とオーバーコミットを効果的に管理し、アプリケーションをスムーズかつ効率的に実行できます。

Red Hat Advanced Cluster Management Right Sizing

Red Hat Advanced Cluster Management for Kubernetes - Right Sizing が、強化された開発者プレビューとして利用可能になりました。RHACM Right Sizing の目的は、プラットフォーム・エンジニアリング・チームに CPU とメモリーベースの namespace  レベルの推奨事項を提供することです。RHACM Right Sizing は現在、Prometheus の記録ルールによって機能しており、さまざまな集計期間 (1、2、5、10、30、60、90 日) にわたって最大値とピーク値のロジックを適用できます。

RHACM Right Sizing を使用すると、次のようなメリットがあります。

1. リソースの最大の問題点を特定する (十分に活用されていない領域など)
2. 組織全体に透明性を促進し、関連する会話を始めるためのきっかけとなる
3. RHACM によってフリート管理を改善し、デプロイする必要があるマネージドクラスタの数に関係なくコスト効率とリソースの最適化を実現する
4. RHACM コンソールの一部として提供される専用の Grafana ダッシュボードのシンプルなユーザーナビゲーション

容量管理のメリット：RHACM Right Sizing 機能により、プラットフォーム・エンジニアは、専用の Grafana ダッシュボード (Red Hat Advanced Cluster Management for Kubernetes コンソールの一部) に表示される CPU とメモリーベースの適切なサイズ設定に関する推奨事項にアクセスできます。これにより、時間の経過とともに変化する使用率に応じて、より長いタイムフレームなど、さまざまな集約期間に基づいて主要な推奨事項にアクセスできます。これらの推奨事項はユーザーにとって使いやすく、簡単に使用できます (以下の図を参照)。

セットアップ方法

前提条件とインストール手順の詳細については、それらを説明したブログをご覧ください。以下の GitHub リポジトリも参考になります。私たちはテクノロジープレビューのリリースに向けて作業を進めながら、さまざまなレベルでの推奨事項の提供についても評価しています。Insights のコスト管理リソース最適化機能 (下記を参照) とは異なり、RHACM のサイズ調整は分析データを Red Hat に共有する必要がないソリューションです。

Red Hat Insights コスト管理を使用した OpenShift のリソース最適化

定義

Red Hat Insights cost management は、オンプレミスを含め、クラウドと OpenShift のあらゆる支出を一元管理する SaaS ソリューションです。

Red Hat Insights cost management の一部である Resource Optimization for OpenShift の一般提供が先頃開始されました。Red Hat Insights のリソース最適化機能の目的は、CPU とメモリーに関する具体的で実用的な推奨事項を開発チームに提供することです。この機能は Kruize オープンソース・プロジェクトによって提供されています。

メリット

OpenShift のリソース最適化は、コンテナ、デプロイメント、DeploymentConfig、StatefulSets、ReplicaSets など、コンテナレベルの推奨事項を開発者に提供します。

2 つの推奨事項のセットが生成されます。

• コストに関する推奨事項：コストを節約したい場合、または namespace のクォータ、ノードのサイズまたはノード数を調整してクラスタの使用率を最大化したい場合は、これらの推奨事項を確認してください。
• パフォーマンスに関する推奨事項：アプリケーションのパフォーマンスをハードウェアでできる限り高めることを最優先事項とする場合は、これらの推奨事項を確認してください。

現在、どちらのタイプの推奨事項も、基準となる観察期間が 24 時間、7 日間、15 日間という 3 つの時間枠で生成されます。

Red Hat Insights cost management によって生成される OpenShift のリソース最適化推奨事項は、コストを削減し、アプリケーションのパフォーマンスを最適化するために役立ちます。これらの推奨事項はコンテキストに沿って、ワークロードの金銭的コストとともに確認できます。

セットアップ方法

OpenShift のリソース最適化推奨事項は、Red Hat Insights cost management のもう 1 つの機能です。Red Hat Insights cost management チートシートに従ってセットアップし、機能の充実した Cost Management API を使用して、Microsoft Excel、Power BI または Grafana など、好みのビジネス・インテリジェンス・ツールまたは可視化ツールで独自のダッシュボードを作成できます。複雑な設定をしたり、処理のために高価なリソースを割り当てたりする必要はありません。Cost Management Metrics Operator は、使用量データを Red Hat Hybrid Cloud Console に送信して分析し、コストとリソースに関するインサイトを生成します (クラスタがインターネットに接続されていない場合は、ネットワークが制限された環境に関するドキュメントを確認してください)。