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

Azure Kubernetes Service (AKS) でクラスターを管理する際は、多くの場合、チームとワークロードを分離する必要があります。As you manage clusters in Azure Kubernetes Service (AKS), you often need to isolate teams and workloads. Kubernetes のスケジューラで提供されている機能を使用すると、コンピューティング リソースの分散を制御したり、メンテナンス イベントの影響を制限したりすることができます。The Kubernetes scheduler provides features that let you control the distribution of compute resources, or limit the impact of maintenance events.

このベスト プラクティス記事では、クラスター オペレーター向けに Kubernetes の基本的なスケジュール機能について説明します。This best practices article focuses on basic Kubernetes scheduling features for cluster operators. この記事では、次のことについて説明します。In this article, you learn how to:

  • リソース クォータを使用して、チームやワークロードに固定量のリソースを提供するUse resource quotas to provide a fixed amount of resources to teams or workloads
  • ポッド中断バジェットを使用して、予定メンテナンスの影響を制限するLimit the impact of scheduled maintenance using pod disruption budgets
  • kube-advisor ツールを使用して、ポッド リソースの足りない要求と制限を調べるCheck for missing pod resource requests and limits using the kube-advisor tool

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

ベスト プラクティス ガイダンス - 名前空間レベルでリソース クォータを計画して適用します。Best practice guidance - Plan and apply resource quotas at the namespace level. ポッドでリソースの要求と制限が定義されていない場合は、デプロイを拒否します。If pods don't define resource requests and limits, reject the deployment. リソースの使用状況を監視し、必要に応じてクォータを調整します。Monitor resource usage and adjust quotas as needed.

リソースの要求と制限は、ポッドの仕様に配置されます。Resource requests and limits are placed in the pod specification. これらの制限は、クラスターで使用可能なノードを見つけるために、Kubernetes スケジューラによってデプロイ時に使用されます。These limits are used by the Kubernetes scheduler at deployment time to find an available node in the cluster. これらの制限と要求は、個々のポッド レベルで機能します。These limits and requests work at the individual pod level. これらの値を定義する方法について詳しくは、「ポッドのリソースの要求と制限を定義する」をご覧くださいFor more information about how to define these values, see Define pod resource requests and limits

開発チームまたはプロジェクト全体でリソースを予約および制限する手段を提供するには、"リソース クォータ" を使用する必要があります。To provide a way to reserve and limit resources across a development team or project, you should use resource quotas. これらのクォータは名前空間で定義され、次の基準でクォータを設定するために使用できます。These quotas are defined on a namespace, and can be used to set quotas on the following basis:

  • コンピューティング リソース: CPU とメモリ、GPU など。Compute resources, such as CPU and memory, or GPUs.
  • ストレージ リソース: ボリュームの総数または特定のストレージ クラスのディスク領域の量が含まれます。Storage resources, includes the total number of volumes or amount of disk space for a given storage class.
  • オブジェクト数: シークレット、サービス、ジョブの最大数などを作成できます。Object count, such as maximum number of secrets, services, or jobs can be created.

Kubernetes では、リソースはオーバーコミットされません。Kubernetes doesn't overcommit resources. リソースの要求または制限の累積合計が、割り当てられたクォータを超えると、それ以上のデプロイは成功しません。Once the cumulative total of resource requests or limits passes the assigned quota, no further deployments are successful.

リソース クォータを定義するときは、名前空間内で作成されるすべてのポッドのポッド仕様で、制限または要求を指定する必要があります。When you define resource quotas, all pods created in the namespace must provide limits or requests in their pod specifications. これらの値が指定されていない場合は、デプロイを拒否できます。If they don't provide these values, you can reject the deployment. 代わりに、名前空間に対して既定の要求と制限を構成することができます。Instead, you can configure default requests and limits for a namespace.

次に示す dev-app-team-quotas.yaml という名前の YAML マニフェストの例では、CPU、メモリ、ポッドの総量のハード制限が、それぞれ 10 個、20 Gi10 個に設定されています。The following example YAML manifest named dev-app-team-quotas.yaml sets a hard limit of a total of 10 CPUs, 20Gi of memory, and 10 pods:

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

dev-apps などの名前空間を指定することで、このリソース クォータを適用できます。This resource quota can be applied by specifying the namespace, such as dev-apps:

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

アプリケーションの開発者や所有者と協力してニーズを把握し、適切なリソース クォータを適用します。Work with your application developers and owners to understand their needs and apply the appropriate resource quotas.

使用可能なリソース オブジェクト、スコープ、優先順位について詳しくは、Kubernetes でのリソース クォータに関する記事をご覧ください。For more information about available resource objects, scopes, and priorities, see Resource quotas in Kubernetes.

ポッド中断バジェットを使用して可用性を計画するPlan for availability using pod disruption budgets

ベスト プラクティス ガイダンス - アプリケーションの可用性を維持するには、ポッド中断バジェット (PDB) を定義して、最低限の数のポッドをクラスターで使用できるようにします。Best practice guidance - To maintain the availability of applications, define Pod Disruption Budgets (PDBs) to make sure that a minimum number of pods are available in the cluster.

ポッドが削除される原因になる 2 つの中断イベントがあります。There are two disruptive events that cause pods to be removed:

  • "非自発的な中断" は、クラスター オペレーターまたはアプリケーション所有者の一般的な制御が及ばないイベントです。Involuntary disruptions are events beyond the typical control of the cluster operator or application owner.
    • このような非自発的な中断としては、物理マシンでのハードウェア障害、カーネル パニック、ノード VM の削除などがありますThese involuntary disruptions include a hardware failure on the physical machine, a kernel panic, or the deletion of a node VM
  • "自発的な中断" は、クラスター オペレーターまたはアプリケーション所有者によって要求されるイベントです。Voluntary disruptions are events requested by the cluster operator or application owner.
    • このような自発的な中断としては、クラスターのアップグレード、更新されたデプロイ テンプレート、ポッドの誤った削除などがあります。These voluntary disruptions include cluster upgrades, an updated deployment template, or accidentally deleting a pod.

非自発的な中断は、ポッドの複数のレプリカをデプロイで使用することにより軽減できます。The involuntary disruptions can be mitigated by using multiple replicas of your pods in a deployment. AKS クラスターで複数のノードを実行することも、これらの非自発的な中断に役立ちます。Running multiple nodes in the AKS cluster also helps with these involuntary disruptions. 自発的な中断については、Kubernetes で提供されている "ポッド中断バジェット" を使用することで、クラスター オペレーターは使用可能な最小限の、または最大限のリソース数を定義できます。For voluntary disruptions, Kubernetes provides pod disruption budgets that let the cluster operator define a minimum available or maximum unavailable resource count. これらのポッド中断バジェットにより、自発的な中断イベントが発生したときのデプロイまたはレプリカ セットの応答方法を計画できます。These pod disruption budgets let you plan for how deployments or replica sets respond when a voluntary disruption event occurs.

クラスターをアップグレードする場合、またはデプロイ テンプレートを更新する場合、Kubernetes スケジューラは、自発的中断イベントを続行する前に、他のノードで追加のポッドがスケジュールされていることを確認します。If a cluster is to be upgraded or a deployment template updated, the Kubernetes scheduler makes sure additional pods are scheduled on other nodes before the voluntary disruption events can continue. スケジューラは、クラスター内の他のノードで定義されている数のポッドが正常にスケジュールされるまで、ノードの再起動を待機します。The scheduler waits before a node is rebooted until the defined number of pods are successfully scheduled on other nodes in the cluster.

5 個のポッドで NGINX を実行するレプリカ セットの例を見てみましょう。Let's look at an example of a replica set with five pods that run NGINX. レプリカ セット内のポッドには、ラベル app: nginx-frontend が割り当てられています。The pods in the replica set are assigned the label app: nginx-frontend. クラスターのアップグレードのような自発的中断イベントの間に、少なくとも 3 個のポッドが実行し続けるようにしたいと思います。During a voluntary disruption event, such as a cluster upgrade, you want to make sure at least three pods continue to run. PodDisruptionBudget オブジェクトに対する YAML マニフェストでは、次の要件を定義します。The following YAML manifest for a PodDisruptionBudget object defines these requirements:

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

60% のような割合を定義することもできます。そうすると、レプリカ セットでポッドの数がスケールアップされるときに自動的に補正できます。You can also define a percentage, such as 60%, which allows you to automatically compensate for the replica set scaling up the number of pods.

レプリカ セットで利用できないインスタンスの最大数を定義できます。You can define a maximum number of unavailable instances in a replica set. この場合も、利用できないポッドの割合の最大値を定義できます。Again, a percentage for the maximum unavailable pods can also be defined. 次に示すポッド中断バジェットの YAML マニフェストでは、レプリカ セットで使用できないポッドが 2 個より多くならないように定義されています。The following pod disruption budget YAML manifest defines that no more than two pods in the replica set be unavailable:

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

ポッド中断バジェットを定義した後は、他の Kubernetes オブジェクトと同じように、AKS クラスター内でそれを作成します。Once your pod disruption budget is defined, you create it in your AKS cluster as with any other Kubernetes object:

kubectl apply -f nginx-pdb.yaml

アプリケーションの開発者や所有者と協力してニーズを把握し、適切なポッド中断バジェットを適用します。Work with your application developers and owners to understand their needs and apply the appropriate pod disruption budgets.

ポッド中断バジェットの使用について詳しくは、「Specifying a Disruption Budget for your Application」 (アプリケーションに対する中断バジェットの指定) をご覧ください。For more information about using pod disruption budgets, see Specify a disruption budget for your application.

kube-advisor を使用してクラスターの問題を定期的に確認するRegularly check for cluster issues with kube-advisor

ベスト プラクティス ガイダンス - 最新バージョンの kube-advisor オープン ソース ツールを定期的に実行して、クラスターでの問題を検出します。Best practice guidance - Regularly run the latest version of kube-advisor open source tool to detect issues in your cluster. 既存の AKS クラスターでリソース クォータを適用する場合は、まず、kube-advisor を実行し、リソースの要求と制限が定義されていないポッドを見つけます。If you apply resource quotas on an existing AKS cluster, run kube-advisor first to find pods that don't have resource requests and limits defined.

kube-advisor ツールでは、Kubernetes クラスターをスキャンし、見つかった問題について報告する、関連する AKS オープンソース プロジェクトです。The kube-advisor tool is an associated AKS open source project that scans a Kubernetes cluster and reports on issues that it finds. 確認の際に、リソースの要求と制限が存在しないポッドの特定もできるため便利です。One useful check is to identify pods that don't have resource requests and limits in place.

kube-advisor ツールは、PodSpecs for Windows アプリケーションおよび Linux アプリケーションに欠けているリソース要求と制限を報告することができますが、kube-advisor ツール自体は Linux ポッドでスケジュールする必要があります。The kube-advisor tool can report on resource request and limits missing in PodSpecs for Windows applications as well as Linux applications, but the kube-advisor tool itself must be scheduled on a Linux pod. ポッドの構成でノード セレクターを使用して、特定の OS のノード プールで実行するようにポッドをスケジュールすることができます。You can schedule a pod to run on a node pool with a specific OS using a node selector in the pod's configuration.

複数の開発チームとアプリケーションをホストする AKS クラスターでは、これらのリソースの要求と制限が設定されていないポッドを追跡するのは困難な場合があります。In an AKS cluster that hosts multiple development teams and applications, it can be hard to track pods without these resource requests and limits set. ベスト プラクティスとしては、AKS クラスターで kube-advisor を定期的に実行します (特に、リソース クォータを名前空間に割り当てていない場合)。As a best practice, regularly run kube-advisor on your AKS clusters, especially if you don't assign resource quotas to namespaces.

次のステップNext steps

この記事では、Kubernetes の基本的なスケジューラ機能に注目しました。This article focused on basic Kubernetes scheduler features. AKS でのクラスター操作の詳細については、次のベスト プラクティスを参照してください。For more information about cluster operations in AKS, see the following best practices: