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

[アーティクル]
06/01/2023

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

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

リソースクォータを使用して、チームやワークロードに固定量のリソースを提供する
ポッド中断バジェットを使用して、予定メンテナンスの影響を制限する

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

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

名前空間レベルでリソースクォータを計画して適用します。ポッドでリソースの要求と制限が定義されていない場合は、デプロイを拒否します。リソースの使用状況を監視し、必要に応じてクォータを調整します。

リソースの要求と制限は、ポッドの仕様に配置されます。要求は、クラスターで使用可能なノードを見つけるために、Kubernetes スケジューラによってデプロイ時に使用されます。制限と要求は、個々のポッドレベルで機能します。これらの値を定義する方法の詳細については、「ポッドのリソースの要求と制限を定義する」を参照してください。

開発チームまたはプロジェクト全体でリソースを予約および制限する手段を提供するには、"リソースクォータ" を使用する必要があります。これらのクォータは名前空間で定義され、次の基準でクォータを設定するために使用できます。

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

Kubernetes では、リソースはオーバーコミットされません。累積リソース要求の合計が割り当てられたクォータを超えると、それ以降のすべてのデプロイは失敗します。

リソースクォータを定義するときは、名前空間内で作成されるすべてのポッドのポッド仕様で、制限または要求を指定する必要があります。これらの値が指定されていない場合は、デプロイを拒否できます。代わりに、名前空間に対して既定の要求と制限を構成することができます。

次に示す 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"

dev-apps などの名前空間を指定することで、このリソースクォータを適用できます。

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

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

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

ポッド中断バジェットを使用して可用性を計画する

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

アプリケーションの可用性を維持するには、ポッド中断バジェット (PDB) を定義して、最低限の数のポッドをクラスターで使用できるようにします。

ポッドが削除される原因になる 2 つの中断イベントがあります。

非自発的な中断

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

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

非自発的な中断は、次の方法で軽減できます。

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

自発的な中断

"自発的な中断" は、クラスターオペレーターまたはアプリケーション所有者によって要求されるイベントです。包含:

クラスターのアップグレード
展開テンプレートを更新した
ポッドを誤って削除した

Kubernetes には、自発的な中断に対して "ポッド中断バジェット" が用意されており、自発的な中断イベントが発生したときにデプロイまたはレプリカセットがどのように応答するかを計画することができます。クラスターオペレーターは、ポッド中断バジェットを使用して、使用できる最小または使用できない最大のリソース数を定義できます。

クラスターをアップグレードするか、展開テンプレートを更新すると、Kubernetes スケジューラによって他のノードに対する追加のポッドがスケジュールされ、自発的な中断イベントを続行できるようになります。スケジューラは、クラスター内の他のノードで定義されている数のポッドが正常にスケジュールされるまで、ノードの再起動を待機します。

5 個のポッドで NGINX を実行するレプリカセットの例を見てみましょう。レプリカセット内のポッドには、ラベル app: nginx-frontend が割り当てられています。クラスターのアップグレードのような自発的中断イベントの間に、少なくとも 3 個のポッドが実行し続けるようにしたいと思います。 PodDisruptionBudget オブジェクトに対する YAML マニフェストでは、次の要件を定義します。

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

60% のような割合を定義することもできます。そうすると、レプリカセットでポッドの数がスケールアップされるときに自動的に補正できます。

レプリカセットで利用できないインスタンスの最大数を定義できます。この場合も、利用できないポッドの割合の最大値を定義できます。次に示すポッド中断バジェットの YAML マニフェストでは、レプリカセットで使用できないポッドが 2 個より多くならないように定義されています。

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

ポッド中断バジェットを定義した後は、他の Kubernetes オブジェクトと同じように、AKS クラスター内でそれを作成します。

kubectl apply -f nginx-pdb.yaml

アプリケーションの開発者や所有者と協力してニーズを把握し、適切なポッド中断バジェットを適用します。

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

次のステップ

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

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

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