オートスケーラのベスト・プラクティス

ベスト・プラクティス: クリティカルなクラスタ・アドオンのノード・プールを少なくとも1つ手動で管理

Kubernetes Cluster Autoscalerによって管理されていないノード・プールを常に少なくとも1つクラスタに配置することをお薦めします。クリティカルなクラスタ・アドオンを実行するには、このノード・プールが必要です。また、Kubernetes Cluster Autoscalerによって管理されないノード・プールを手動でスケーリングする必要があります。

また、アプリケーション・ポッドをユーザー・ノード・プールで実行するようにスケジュールし、専用システム・ノード・プールで重要なシステム・ポッド(corednsポッドなど)を実行することをお薦めします。このようにアプリケーション・ポッドとシステム・ポッドを分離することで、不正なアプリケーション・ポッドが誤ってシステム・ポッドを殺すのを防ぎます。システム・ノード・プールにCriticalAddonsOnly=true:NoSchedule色合いを使用して、この動作を実行します。

Kubernetes Cluster Autoscalerの使用を参照してください。

ベスト・プラクティス: 複数のレプリカの定義

構成ファイルで、Kubernetes Cluster Autoscalerデプロイメントの複数のレプリカを常に定義することをお薦めします。レプリカが1つしかなく、それを除去して再スケジュールできない場合、Kubernetes Cluster Autoscalerはそれ以上ワーカー・ノードを作成できません。

Kubernetes Cluster Autoscalerの使用を参照してください。

ベスト・プラクティス: max-node-provision-timeの設定

max-node-provision-timeは、構成ファイルで25分に設定することをお薦めします。通常、新しいワーカー・ノードがプロビジョニングされ、これよりも大幅に短い時間で「準備完了」状態に移行します。ただし、多数のノードが同時にノード・プールに追加されると、プロビジョニングに時間がかかる場合があります。コンソールのワーカー・ノードの横に、初期化に20分超かかることを示す警告が表示されることに注意してください。

Kubernetes Cluster Autoscalerの使用を参照してください。

ベスト・プラクティス: ノード・プール内のノードの最大数を指定します

構成ファイルのノード・プールで許可されるノードの最大数を指定することをお薦めします。指定するノードの最大数が、ノード・プールに定義されているワーカー・ノード・シェイプのテナンシ制限を超えないようにしてください。Kubernetes Cluster Autoscalerでは、テナンシ制限を超えるノードは作成されません。テナンシ制限より大きい数を指定すると、Kubernetes Cluster Autoscalerは定期的に追加のノードを作成しようとしますが、テナンシ制限が増加するまで作成しません。

Kubernetes Cluster Autoscalerで管理するクラスタを定義する場合は、ノード・プールごとに1つの可用性ドメインを指定して複数のノード・プールを作成することをお薦めします。

Kubernetes Cluster Autoscalerの使用を参照してください。

ベスト・プラクティス: ノード・プールごとに異なる可用性ドメインを持つ複数のノード・プールを指定します

Kubernetes Cluster Autoscalerで管理するクラスタを定義する場合は、複数のノード・プール(ノード・プールごとに異なる可用性ドメインを持つ)を指定することをお薦めします。

異なる可用性ドメインに複数のノード・プールを指定すると、選択したノード・シェイプが特定の可用性ドメインで使用できないため、Kubernetes Cluster Autoscalerがワーカー・ノードを作成できない可能性が低くなります。

Kubernetes Cluster Autoscalerの使用を参照してください。

ベスト・プラクティス: 容量予約を使用したワーカー・ノードのプロビジョニング

容量予約を使用してワーカー・ノードをプロビジョニングすることをお薦めします。容量予約を使用すると、ディザスタ・リカバリや予期しないワークロードの急増などのクリティカル・イベント中に必要な場合に、ワークロードに対してコンピュート容量を使用できるようになります。

容量予約を使用した管理対象ノードのプロビジョニングを参照してください。

ベスト・プラクティス: ポッド・ディスラプション予算を活用するアプリケーションを設計

Kubernetes Cluster Autoscalerがワーカー・ノードを削除するとき、または使用率の低いワーカー・ノードを削除する前にポッドを別のワーカー・ノードに移動するときに発生する可能性のある中断を許容するようにアプリケーションを設計することをお薦めします。

たとえば、ポッド中断予算を利用するアプリケーションを設計します。

Kubernetesドキュメントのアプリケーションの中断予算の指定を参照してください。

ベスト・プラクティス: Kubernetes Cluster Autoscalerによって管理されるノード・プールを手動で構成しないでください

Kubernetes Cluster Autoscalerによって管理されるノード・プールは手動で変更しないでください。たとえば、kubectlまたはコンソール(あるいはOracle Cloud Infrastructure CLIまたはAPI)を使用してノードを追加または削除しないでください。Kubernetes Cluster Autoscalerは、そのような変更をオーバーライドしたり、変更によってその動作が変更される可能性があります。

Kubernetes Cluster Autoscalerによって管理されているノード・プール内のすべてのノードを削除する場合は、常にKubernetes Cluster Autoscalerを使用してノード・プールをゼロにスケーリングします。

Kubernetes Cluster Autoscalerの使用を参照してください。

ベスト・プラクティス: Kubernetes Horizontal Pod AutoscalerとVertical Pod Autoscalerを同時に使用しないでください

Horizontal Pod AutoscalerとVertical Pod Autoscalerを同時に使用しないことをお薦めします。

Vertical Pod Autoscalerは、リクエストと制限の構成を自動的に調整し、オーバーヘッドを削減してコストを削減することを目指しています。

Horizontal Pod Autoscalerは、CPUまたはメモリー使用率または他のメトリックに基づいてポッド数をスケーリングします。Horizontal Pod Autoscalerは、ポッドの数を減らすのではなく、増加する可能性が高くなります。

Horizontal Pod AutoscalerとVertical Pod Autoscalerを一緒に使用する場合は、それぞれのポリシーが相互に干渉していないことを再確認してください。

ベスト・プラクティス: アプリケーション開発中に推奨事項を適用せずに推奨事項を作成します。

アプリケーションの記述の初期段階では、(ポッドを更新せずに)推奨を作成するのみで、Vertical Pod Autoscalerの使用を検討することをお薦めします。

推奨を適用せずに単に作成するには、VerticalPodAutoscalerマニフェストのupdatePolicyセクションでupdateMode: "Off"を設定します。ポッドの作成時、Vertical Pod AutoscalerはコンテナのCPUおよびメモリーのニーズを分析し、それらの推奨をStatusフィールドに記録します。Vertical Pod Autoscalerは、実行中のコンテナのリソース・リクエストを更新するアクションを実行しません。

Kubernetes Vertical Pod Autoscalerの使用を参照してください。