コンテナとKubernetesによる無限のスケーリング（後半）
総合的な視点から
長い記事なので、前半と後半の２つに分けて投稿いたします。今回は後半です。
ポッドのオートスケール ：スタティックサイジング枠を超える
多くの読者は、手に負えないワークロードに対処するための通常の回避策の準備ができていることでしょう。
HPAはデプロイメント内のポッドレプリカの数を変更でき、VPAはポッドのリソースリクエストと制限を変更できます。このKubernetes Enhancement ProposalがKubernetesに追加されるまで、VPAでポッドを変更するとポッドが再起動されることに注意してください。
容量を自動的に拡張する機能はありますが、これらのコンポーネントは、ワークロードの運用範囲を正確に定義することを見送るフリーパスではありません。たとえば、ポッド内のコンテナがそのメトリックに対するリソースリクエストを持っていない場合、HPAはそのメトリックに対するアクションを取りません。また、HPAは、クラスタ内のポッドの特定のレプリカ数に依存したデプロイメントを行うシナリオにも不向きです。
VPAは、固定数のレプリカを必要とするワークロードや、ワークロードにプリセットの制限がない場合に有効です。ただし、制限事項のリストが比較的長いのが難点です。また、制限の範囲を使用する場合、考慮すべき事柄がかなり多くなる可能性があります。
結局のところ、ワークロードの自動スケーリングにおけるこれらのツールの有効性は、開発中によく研究されたリソース要求と制限を定義するために費やされたプロファイリングの労力にかかっています。ここで、VPAが配備の運用リソース範囲を「学習」する能力を備えていることは、特に評価すべき点です。
Auto Pilotのオペレーター:SRE
Kubernetesのオペレーターは、アプリケーションとワークロードを管理するために、カスタムリソースの概念を導入しています。概念的には、オペレータはカスタムリソースを継続的に監視し、その内容をワークロードリソースにマッピングします。
