問題タブ [hpa]

HPA とオートスケーラーを使用して展開の 1 つをスケーリングするために、K8S で使用する信頼できるセットアップを決定しようとしています。オーバーコミットされるリソースの量を最小限に抑えたいが、必要に応じてスケールアップできるようにしたい。

REST API サービスを管理するデプロイメントがあります。ほとんどの場合、サービスの使用率は非常に低くなります (0m-5m cpu)。しかし、1 日または 1 週間を通して定期的に、5 ～ 10 個の CPU (5000m ～ 10000m) のオーダーで使用率がはるかに高くなります。

これを構成するときの私の最初のパスは次のとおりです。

• デプロイ: 1 つのレプリカ

• HPA:

これは、オートスケーラーが実行されている AWS EKS クラスターで実行されています。すべてのインスタンスには 2 つの CPU があります。目標は、CPU 使用率が上がると、HPA がスケジュール不可能な新しいポッドを割り当て、オートスケーラーが新しいノードを割り当てることです。サービスに負荷を加えると、最初のポッドの CPU 使用率が最大で約 90 ～ 95% まで急増します。

関連する 2 つの問題が発生しています。

1. 小さなリクエストサイズ

このような小さなリクエスト値 (cpu: 0.05) を使用することで、負荷が高い場合でも、新しくリクエストされたポッドを現在のノードで簡単にスケジュールできます。したがって、オートスケーラーは、スケジュールできないポッドを見つけることはなく、新しいノードを割り当てません。小さなリクエスト サイズを増やしてオーバーコミットすることもできますが、これは、負荷のない時間の大部分で、必要のないリソースを浪費することを意味します。

2. より多くのポッドが割り当てられると、平均 CPU が減少します

Pod はすべて同じノードに割り当てられるため、新しい Pod が割り当てられると、ノードの使用可能な 2 つの CPU の共有が開始されます。これにより、Pod が使用する CPU の量が減少し、平均値が 75% の目標を下回ります。

(例: 3 つのポッド、2 つの CPU ==> 最大 66% のポッドあたりの平均 CPU 使用率)

この問題についてどのように考えるべきかについて、ここでガイダンスを探しています。シンプルなものが欠けていると思います。

私の現在の考えは、私が探しているのは、Pod リソース要求値がより重い負荷の下で増加し、システムがそれを必要としないときに減少する方法であるということです。これは、VPA のようなものを使用することを示唆していますが、私が読んだすべてのことは、HPA と VPA を同時に使用すると非常に悪い結果になることを示しています。

リクエストを 0.05 から 0.20 のように増やすと、スケールアップのケースを処理できるようになると思います。しかし、これは多くのリソースを浪費し、スケジューラーが既存のポッドにスペースを見つけた場合に問題が発生する可能性があります。私の例は 1 つのサービスに関するものですが、運用環境の展開にはさらに多くのサービスがあります。コミットされたリソースを使用せずにノードを空のままにしたくありません。

ここで前進する最善の道は何ですか？

私は持っている：

1. k8s でのサービス A と B の展開
2. プロメテウス １D

サービス B のメトリック m1 が変更されたときに、サービス A をスケーリングしたい。私が見つけた、多かれ少なかれ適切ではないソリューション：

1. 仕様の次の部分を使用して、サービス A の HPA を定義できます。

技術的には、うまくいきます。ただし、k8s の動的な性質には適していません。また、HPA でポッド メトリック (metrics: - type: Pods pods:) を使用することはできません。これは、サービス A のポッドに対して m1 メトリックを要求するためです (明らかにこれはありません)。

2. サービス B のポッドから m1 メトリックを照会するプロメテウス アダプターでカスタム メトリックを定義します。

3. 外部指標も同様

非現実的なケースのようには見えないので、何かを見逃していると感じています:)それで、k8sであるサービスを別のサービスのメトリックでスケーリングする方法を教えてください。