ノードのリソースが不足している場合のKubernetesノードのスケーリング
ドキュメントから、ポッドのリソース要求を尊重するのに十分な空きリソースがあるノードがないためにポッドが保留状態にあるときはいつでも、クラスターオートスケーラーはポッドの作成から30秒以内に別のノードを作成することが明らかです（適度なサイズのクラスターの場合） 。
ただし、ノードがかなりパックされている場合を考えてみます。ノードに2つのCPUコアがあり、0.5CPU要求と1.0CPU制限を定義する4つのポッドが含まれているとします。突然負荷がかかり、4つのポッドすべてが突然追加の0.5 CPUを要求しますが、そのCPUはすべて実行中の4つのポッドによってすでに使用されているため、ノードはそれを提供できません。
この状況では、Kubernetesは、提供できないポッドを実行することで保留中のリソースリクエストがあることを「理解」し、それらのポッドを、リクエスト（およびリソース）を尊重できる別のノードに「移動」（破棄および作成）することを期待します。現在使用しています）。そのようなノードが存在しない場合、Kubernetesが追加のノードを作成し、そこにポッドを移動することを期待していました。
しかし、私はこれが起こっているのを見ていません。尊重できないリソース要求に関係なく、ポッドは同じノードで実行されていることがわかります（ノードはオーバープロビジョニングされていると言えます）。その結果、パフォーマンスが低下します。
私の質問は、ポッドリソース要求と制限の比率を1：1（ポッドが最初に割り当てられたよりも多くのリソースを要求できない場合）に設定する以外に、この動作を回避できるかどうかです。明らかに、プロビジョニング不足を回避し、必要以上に支払うために、リクエストと制限を同じに設定することは避けたいと思います。
回答
ここrequestで、PodSpecのCPUと、プロセスが使用しようとしているCPUの量との違いを認識することが重要です。Kubernetesのプロビジョニングとクラスターの自動スケーリングはrequest、PodSpecのにのみ基づいています。実際の使用は、これらの決定には関係ありません。
あなたが説明している場合、ポッドはまだ0.5CPUしか要求しません-そのフィールドは不変です。プロセスは現在1つのCPUを使用しようとしていますが、これは考慮されていません。
CPU制限が要求よりも高い場合、その容量を最大限に活用できますが、ご覧のとおり、これは保証ではありません。
このシナリオでは、Horizontal PodAutoscalerとクラスターオートスケーラーの両方を使用することをお勧めします。負荷が増加した状況（requestたとえば、ポッドがCPUの80％を超えて使用し始める場合）では、HPAは、需要を処理するために、サービスのポッドの数を増やします。その場合、それらのポッドに収まる場所がない場合、クラスターオートスケーラーはより多くのノードをプロビジョニングします。このようにして、ポッドは引き続きリクエスト値まで使用できます。ポッドがそれに近づき始めたときにのみ、より多くのノードがプロビジョニングされるため、事前にリソースを過剰にプロビジョニングすることはありません。