非常に単純なシナリオがあると思います。ノードごとに1つ実行し、ノードで使用可能な残りのすべてのリソースを使用するポッドを使用して、Google KubernetesEngineで自動スケーリングする必要があります。
「残りの」リソースとは、ロギングやメトリックなど、要求されたリソースを必要とする特定の基本的なポッドサービスが各ノードで実行されていることを意味します。しかし、残っているものはすべてこの特定のポッドに移動する必要があります。これは実際、私のクラスターのメインWebサービスです。
また、これらの残りのリソースは、ポッドの再起動による垂直方向の自動スケーリングではなく、ポッドのコンテナの起動時に利用可能である必要があります。その理由は、コンテナには再起動をある程度高価にする特定の制約があるためです。重いディスクキャッシュ、および私が使用する一部のサードパーティソフトウェアのライセンスに関する問題です。ですから、確かにコンテナ/ポッドは再起動可能ですが、ローリングアップデートを除いては避けたいと思います。
CPU使用率が高くなりすぎた場合（たとえば、70％）、クラスターはノードをスケーリングする必要があります。また、ノードのポッドの要求されたCPU使用率を意味するのではなく、実際の使用率を意味します。これは主にWebサービスの負荷によって決定されます。
このシナリオでクラスターをどのように構成する必要がありますか？クラスターの自動スケーリング、垂直ポッドの自動スケーリング、および水平ポッドの自動スケーリングがあることを確認しました。DaemonSetはスケーリングが必要なポッド用に設計されているようには見えませんが、Deployment vsDaemonSetもあります。したがって、デプロイメントが必要になる可能性があると思いますが、ノードごとに1つのWebサービスポッドを制限する方法で（ポッドのアンチアフィニティ??）。
これらすべてをどのように組み合わせるのですか？
単一ノードの割り当て可能なリソース（つまり、合計リソースから前述の補助サービスを差し引いたもの）に等しいリソース要求を使用してデプロイメントをセットアップできます。次に、水平ポッド自動スケーリングを構成して、CPU要求の使用率が70％を超えたときにデプロイメントをスケールアップします。この場合、リクエストの使用率は基本的にノードのリソース使用率の合計と同じであるため、これでうまくいくはずです。ただし、実際のノードのCPU使用率に基づいてスケーリングを行う場合は、常に外部メトリックによるスケーリングがあります。
技術的には、デプロイメントのリソース要求は残りのリソースと正確に等しい必要はありません。むしろ、2つのポッドが同じノードで実行されるのを防ぐのに十分な大きさのリクエストで十分です。それが事実であり、リソース制限がない限り、ポッドは利用可能なすべてのノードリソースを消費することになります。
最後に、GKEノードプールでクラスターの自動スケーリングを構成します。これで準備は完了です。ポッドリソースリクエストは一定のままであるため、垂直ポッド自動スケーリングは実際には機能しません。また、前述のようにHPAを介してスケーラブルではないため、デーモンセットは適用できません。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加