Azure Kubernetes Service (AKS) での基本的なスケジューラ機能に関するベスト プラクティス

Azure Kubernetes Service (AKS) でクラスターを管理する際は、多くの場合、チームとワークロードを分離する必要があります。 Kubernetes スケジューラを使用すると、コンピューティング リソースの分散を制御し、メンテナンス イベントの影響を制限できます。

このベスト プラクティス記事では、クラスター オペレーター向けに Kubernetes の基本的なスケジュール機能について説明します。 この記事では、次のことについて説明します。

  • リソース クォータを使用して、チームまたはワークロードに一定量のリソースを提供する
  • ポッド中断予算を使用して、スケジュールされたメンテナンスの影響を制限する

リソース クォータを適用する

ベスト プラクティスのガイダンス

名前空間レベルでリソース クォータを計画して適用します。 クォータと制限範囲を使用して、ポッドの既定のリソース要求と制限を要求または提供します。 リソースの使用状況を監視し、必要に応じてクォータを調整します。

ポッド仕様でリソース要求とリソース制限を設定します。 リソース要求は、Kubernetes スケジューラがポッドを配置するために使用する CPU またはメモリの量です。 リソース制限により、コンテナーで使用できるリソースの量が制限されます。 システムは調整によって CPU 制限を適用し、メモリ不足 (OOM) 終了を通じてメモリ制限を事後対応的に適用します。 詳細については、「 ポッド リソースの要求と制限の定義」を参照してください。

リソース クォータを使用して、開発チームまたはプロジェクトの総リソース消費量を制限します。 次の名前空間レベルでクォータを定義します。

  • コンピューティング リソース: CPU とメモリ、GPU など。
  • ストレージ リソース: ボリュームの総数または特定のストレージ クラスのディスク領域の量が含まれます。
  • 作成できるシークレット、サービス、ジョブの最大数などのオブジェクト数。

Kubernetes スケジューラは、リソース要求を使用してポッドを配置します。 コンテナーでは、容量が使用可能な場合に、要求よりも多くの CPU またはメモリを使用でき、リソースの制限が要求を超える可能性があります。 リソース クォータでは、集計名前空間の使用量が個別に制限されます。 リソースの作成または更新がハード クォータを超える場合、API サーバーは HTTP 403 Forbidden 応答で要求を拒否します。 クォータによってコントローラーが要求されたすべてのポッドを作成できない場合でも、Deployment などのワークロード オブジェクトを作成できます。

リソース クォータが CPU またはメモリを追跡する場合、新しいポッドごとに、そのリソースの要求または制限を指定する必要があります。 そうしないと、API サーバーがポッドを拒否する可能性があります。 LimitRange を使用して 、名前空間の既定の要求と制限を構成 できます。

次に示す dev-app-team-quotas.yaml という名前の YAML マニフェストの例では、CPU、メモリ、ポッドの総量のハード制限が、それぞれ 10 個、20 Gi、10 個に設定されています。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-app-team
spec:
  hard:
    cpu: "10"
    memory: 20Gi
    pods: "10"

このクォータ上限は、CPU 要求を 10 CPU で集計し、メモリ要求を 20Gi で集計し、名前空間内の非終端ポッドの数を 10 に制限します。

dev-apps などの名前空間にこのリソース クォータを適用します。

kubectl apply -f dev-app-team-quotas.yaml --namespace dev-apps

アプリケーションの開発者や所有者と協力してニーズを把握し、適切なリソース クォータを適用します。

使用可能なリソース オブジェクト、スコープ、優先順位について詳しくは、Kubernetes でのリソース クォータに関する記事をご覧ください。

ポッド中断予算 (PDB) を使用して中断の影響を制限する

ベスト プラクティスのガイダンス

レプリケートされたアプリケーションのポッド中断予算 (PDB) を定義して、AKS ノードのドレインなどのイベント中の同時の自発的な削除を制限します。 十分な正常なレプリカを維持し、ワークロードで許可されたときに少なくとも 1 つの中断を許可して、クラスターのメンテナンスを続行できるようにします。

ポッドを削除する破壊的イベントは、次の 2 つのカテゴリに分類されます。

非自発的な中断

"非自発的な中断" は、クラスター オペレーターまたはアプリケーション所有者の一般的な制御が及ばないイベントです。 その例は次のとおりです。

  • 物理マシンのハードウェア障害
  • カーネルのパニック
  • ノード VM の削除

次の方法で、不本意な中断を軽減できます。

  • デプロイメントの中でポッドの複数のレプリカを使用する。
  • AKS クラスターで複数のノードを実行する。

自発的な中断

_ 任意disruptions_は、クラスターオペレーターまたはアプリケーション所有者が要求するイベントです。 その例は次のとおりです。

  • クラスターのアップグレード中のノードのドレイン
  • デプロイ テンプレートの更新
  • ポッドを直接削除する

すべての自発的な中断が PDB によって制約されるわけではありません。 ポッドまたはワークロード オブジェクトを直接削除すると PDB がバイパスされ、デプロイや StatefulSet などのワークロード コントローラーは、ローリング更新中に PDB によって制限されません。 アプリケーションの更新中に可用性を維持するために、ワークロードのロールアウト戦略を個別に構成します。 詳細については、「 Kubernetes の中断」を参照してください。

PDB は、Kubernetes Eviction API を使用して、選択したポッドの同時自発的な削除を制限します。 AKS ローリング アップグレード中、AKS はノード プールの設定に従ってサージ容量を追加し、ノードを切断してドレインした後、ドレインされたノードを再イメージ化または交換します。 削除 API は、ドレイン中に PDB を評価します。 削除後、ワークロード コントローラーによって代替ポッドが作成され、スケジューラによって使用可能な容量のノードに配置されます。 制限の厳しい PDB、不十分な正常なレプリカ、またはクラスターの容量が不足すると、ドレインが遅延またはブロックされる可能性があります。

使用可能なポッドの最小数を設定する

app: nginx-frontendというラベルが付いた 5 つの NGINX ポッドを持つ ReplicaSet について考えてみます。 クラスターのアップグレードなどの自発的な中断イベント中は、少なくとも 3 つのポッドを引き続き使用できる必要があります。 次の PodDisruptionBudget マニフェストは、この要件を定義します。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  minAvailable: 3
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels:
      app: nginx-frontend

この予算では、ラベル app: nginx-frontend を持つ少なくとも 3 つのポッドが、自発的な削除中も正常な状態を維持する必要があります。

割合 (60%など) を指定して、ReplicaSet のスケーリング時に予算が調整されるようにすることができます。

使用できないポッドの最大数を設定する

PDB では、 minAvailable または maxUnavailableを定義できますが、両方を定義することはできません。 使用できないポッドに基づいて自発的な削除を制限するには、 maxUnavailable を整数またはパーセンテージとして指定します。 次のマニフェストでは、削除後に ReplicaSet 内の 2 つ以下のポッドが使用できない場合にのみ、自発的な削除が許可されます。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  maxUnavailable: 2
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels:
      app: nginx-frontend

この予算では、ラベル app: nginx-frontend を持つポッドが削除後に使用できないポッドが 2 つ以下の場合にのみ、自発的な削除が許可されます。 不本意な中断によって、可用性がこのしきい値を下回る可能性があります。

AlwaysAllow異常なポッドの削除ポリシーを使用すると、正常でないポッドを実行しているポッドをドレイン削除できます。 この設定がないと、既定の IfHealthyBudget ポリシーは、異常なポッドが正常になるのを待っている間にドレインをブロックできます。 異常なポッドに回復時間を与えるよりも、ドレイン可能性が重要な場合は、 AlwaysAllow を使用します。

nginx-pdb.yaml として使用する PDB マニフェストを保存し、それを AKS クラスターに適用します。

kubectl apply -f nginx-pdb.yaml

クラスターのメンテナンスの前に、各 PDB で想定される削除が許可されていることを確認します。

kubectl get poddisruptionbudgets --namespace <namespace>

0のALLOWED DISRUPTIONS値は、AKS ノードのドレインをブロックできます。 アプリケーション開発者や所有者と協力して、十分な正常なレプリカを維持し、アプリケーションの可用性とメンテナンス要件のバランスを取る予算を選択します。

ポッド中断バジェットの使用について詳しくは、「Specifying a Disruption Budget for your Application」 (アプリケーションに対する中断バジェットの指定) をご覧ください。

関連するコンテンツ

この記事では、Kubernetes スケジューラの基本的な機能について説明します。 AKS でのクラスター操作の詳細については、次のベスト プラクティスに関する記事を参照してください。

  • Last updated on