Bonnes pratiques relatives aux fonctionnalités de base du planificateur dans Azure Kubernetes Service (AKS)Best practices for basic scheduler features in Azure Kubernetes Service (AKS)

Quand vous gérez des clusters dans Azure Kubernetes Service (AKS), il est souvent nécessaire d’isoler les équipes et les charges de travail.As you manage clusters in Azure Kubernetes Service (AKS), you often need to isolate teams and workloads. Le planificateur Kubernetes offre des fonctionnalités qui vous permettent de contrôler la distribution des ressources de calcul ou de limiter l’impact des événements de maintenance.The Kubernetes scheduler provides features that let you control the distribution of compute resources, or limit the impact of maintenance events.

Cet article traite des bonnes pratiques relatives aux fonctionnalités de planification Kubernetes de base pour les opérateurs de clusters.This best practices article focuses on basic Kubernetes scheduling features for cluster operators. Dans cet article, vous apprendrez comment :In this article, you learn how to:

  • Utiliser des quotas d’utilisation de ressources pour fournir une quantité fixe de ressources à des équipes ou charges de travailUse resource quotas to provide a fixed amount of resources to teams or workloads
  • Limiter l’impact de la maintenance planifiée à l’aide de budgets de perturbation de podLimit the impact of scheduled maintenance using pod disruption budgets
  • Rechercher les pods dépourvus de demandes et de limites de ressources à l’aide de l’outil kube-advisorCheck for missing pod resource requests and limits using the kube-advisor tool

Appliquer des quotas de ressourcesEnforce resource quotas

Guide de bonne pratique : planifiez et appliquez des quotas de ressources au niveau de l’espace de noms.Best practice guidance - Plan and apply resource quotas at the namespace level. Si les pods ne définissent pas de demandes ni de limites de ressources, rejetez le déploiement.If pods don't define resource requests and limits, reject the deployment. Supervisez l’utilisation des ressources et ajustez les quotas en fonction des besoins.Monitor resource usage and adjust quotas as needed.

Les demandes et limites de ressources sont placées dans la spécification de pod.Resource requests and limits are placed in the pod specification. Ces limites sont utilisées par le planificateur Kubernetes au moment du déploiement pour rechercher un nœud disponible dans le cluster.These limits are used by the Kubernetes scheduler at deployment time to find an available node in the cluster. Ces demandes et limites s’appliquent au niveau de chaque pod.These limits and requests work at the individual pod level. Pour plus d’informations sur la façon de définir ces valeurs, consultez Définir des demandes et limites de pod.For more information about how to define these values, see Define pod resource requests and limits

Pour fournir un moyen de réserver et de limiter les ressources à l’échelle d’un projet ou d’une équipe de développement, vous devez utiliser des quotas de ressources.To provide a way to reserve and limit resources across a development team or project, you should use resource quotas. Ces quotas sont définis sur un espace de noms et peuvent être définis en fonction des éléments suivants :These quotas are defined on a namespace, and can be used to set quotas on the following basis:

  • Ressources de calcul (par exemple, le processeur et la mémoire ou des GPU).Compute resources, such as CPU and memory, or GPUs.
  • Ressources de stockage (inclut le nombre total de volumes ou la quantité d’espace disque pour une classe de stockage donnée).Storage resources, includes the total number of volumes or amount of disk space for a given storage class.
  • Nombre d’objets (par exemple, le nombre maximal de secrets, de services ou de travaux pouvant être créés).Object count, such as maximum number of secrets, services, or jobs can be created.

Kubernetes ne sollicite pas excessivement les ressources.Kubernetes doesn't overcommit resources. Si le total cumulé des demandes ou des limites de ressources dépasse le quota affecté, tout nouveau déploiement échoue.Once the cumulative total of resource requests or limits passes the assigned quota, no further deployments are successful.

Quand vous définissez des quotas de ressources, tous les pods créés dans l’espace de noms doivent fournir des demandes ou des limites dans leurs spécifications de pod.When you define resource quotas, all pods created in the namespace must provide limits or requests in their pod specifications. S’ils ne fournissent pas ces valeurs, vous pouvez refuser le déploiement.If they don't provide these values, you can reject the deployment. Au lieu de cela, vous pouvez configurer des demandes et limites par défaut pour un espace de noms.Instead, you can configure default requests and limits for a namespace.

L’exemple de manifeste YAML suivant nommé dev-app-team-quotas.yaml définit une limite inconditionnelle avec, au total, 10 processeurs, 20Gi de mémoire et 10 pods :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"

Ce quota de ressources peut être appliqué en spécifiant l’espace de noms, par exemple 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

Collaborez avec les propriétaires et développeurs d’application pour comprendre leurs besoins et appliquer les quotas de ressources appropriés.Work with your application developers and owners to understand their needs and apply the appropriate resource quotas.

Pour plus d’informations sur les objets de ressource, étendues et priorités disponibles, consultez Quotas de ressources dans Kubernetes.For more information about available resource objects, scopes, and priorities, see Resource quotas in Kubernetes.

Planifier la disponibilité à l’aide de budgets de perturbation de podPlan for availability using pod disruption budgets

Guide de bonne pratique : pour assurer la disponibilité des applications, définissez des budgets de perturbation de pod (PDB). Ceux-ci garantissent un nombre minimal de pods disponibles dans le cluster.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.

Deux événements perturbateurs peuvent entraîner la suppression de pods :There are two disruptive events that cause pods to be removed:

  • Perturbations involontaires : il s’agit d’événements qui échappent généralement au contrôle de l’opérateur de cluster ou du propriétaire d’application.Involuntary disruptions are events beyond the typical control of the cluster operator or application owner.
    • Citons en exemple une défaillance matérielle sur la machine physique, une alerte sur le noyau ou la suppression d’une machine virtuelle de nœud.These involuntary disruptions include a hardware failure on the physical machine, a kernel panic, or the deletion of a node VM
  • Perturbations volontaires : il s’agit d’événements demandés par l’opérateur de cluster ou le propriétaire d’application.Voluntary disruptions are events requested by the cluster operator or application owner.
    • Citons en exemple la mise à niveau d’un cluster, la mise à jour d’un modèle de déploiement ou la suppression accidentelle d’un pod.These voluntary disruptions include cluster upgrades, an updated deployment template, or accidentally deleting a pod.

Pour atténuer les perturbations involontaires, vous pouvez utiliser plusieurs réplicas de vos pods dans un déploiement.The involuntary disruptions can be mitigated by using multiple replicas of your pods in a deployment. L’exécution de plusieurs nœuds dans le cluster AKS peut aussi contribuer à réduire les perturbations involontaires.Running multiple nodes in the AKS cluster also helps with these involuntary disruptions. Pour les perturbations volontaires, Kubernetes fournit des budgets de perturbation de pod. Ceux-ci permettent à l’opérateur de cluster de définir le nombre minimal de ressources disponibles ou le nombre maximal de ressources indisponibles.For voluntary disruptions, Kubernetes provides pod disruption budgets that let the cluster operator define a minimum available or maximum unavailable resource count. Les budgets de perturbation de pod vous permettent de planifier la réponse des déploiements ou des jeux de réplicas à la suite d’un événement perturbateur.These pod disruption budgets let you plan for how deployments or replica sets respond when a voluntary disruption event occurs.

Si un cluster doit être mis à niveau ou qu’un modèle de déploiement doit être mis à jour, le planificateur Kubernetes fait en sorte que des pods supplémentaires sont planifiés sur d’autres nœuds avant que les événements perturbateurs volontaires ne se poursuivent.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. Avant le redémarrage d’un nœud, le planificateur attend que le nombre défini de pods soit correctement planifié sur d’autres nœuds du cluster.The scheduler waits before a node is rebooted until the defined number of pods are successfully scheduled on other nodes in the cluster.

Examinons un exemple de jeu de réplicas avec cinq pods qui exécutent NGINX.Let's look at an example of a replica set with five pods that run NGINX. Les pods dans le jeu de réplicas se voient affecter l’étiquette app: nginx-frontend.The pods in the replica set are assigned the label app: nginx-frontend. Durant un événement perturbateur volontaire comme une mise à niveau de cluster, vous devez veiller à ce qu’au moins trois pods s’exécutent.During a voluntary disruption event, such as a cluster upgrade, you want to make sure at least three pods continue to run. Le manifeste YAML suivant pour un objet PodDisruptionBudget définit ces exigences :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

Vous pouvez également définir un pourcentage (par exemple, 60 % ), pour compenser automatiquement le scale-up du nombre de pods par le jeu de réplicas.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.

Vous pouvez définir le nombre maximal d’instances non disponibles dans un jeu de réplicas.You can define a maximum number of unavailable instances in a replica set. Là encore, vous pouvez définir un pourcentage indiquant le nombre maximal de pods indisponibles.Again, a percentage for the maximum unavailable pods can also be defined. Selon le manifeste YAML du budget de perturbation de pod suivant, il ne peut pas y avoir plus de deux pods indisponibles dans le jeu de réplicas :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

Une fois votre budget de perturbation de pod défini, vous le créez dans votre cluster AKS comme tout autre objet Kubernetes :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

Collaborez avec les propriétaires et développeurs d’application pour comprendre leurs besoins et appliquer les budgets de perturbation de pod appropriés.Work with your application developers and owners to understand their needs and apply the appropriate pod disruption budgets.

Pour plus d’informations sur l’utilisation de budgets de perturbation de pod, consultez Spécifier un budget de perturbation pour votre application.For more information about using pod disruption budgets, see Specify a disruption budget for your application.

Rechercher régulièrement les problèmes liés au cluster avec kube-advisorRegularly check for cluster issues with kube-advisor

Meilleure pratique : exécutez régulièrement la dernière version de l’outil open source kube-advisor pour détecter les problèmes dans votre cluster.Best practice guidance - Regularly run the latest version of kube-advisor open source tool to detect issues in your cluster. Si vous appliquez des quotas de ressources sur un cluster AKS existant, exécutez d’abord kube-advisor pour rechercher les pods dont les demandes et limites de ressources ne sont pas définies.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.

L’outil kube-advisor est un projet open source AKS associé qui analyse un cluster Kubernetes et signale les problèmes trouvés.The kube-advisor tool is an associated AKS open source project that scans a Kubernetes cluster and reports on issues that it finds. Une vérification utile consiste à identifier les pods dépourvus de demandes et de limites de ressources.One useful check is to identify pods that don't have resource requests and limits in place.

L’outil kube-advisor peut rendre compte des limites et demandes de ressources manquantes dans PodSpecs pour les applications Windows et Linux, mais l’outil kube-advisor proprement dit doit être planifié sur un pod 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. Vous pouvez planifier un pod pour qu’il s’exécute sur un pool de nœuds avec un système d’exploitation spécifique à l’aide d’un sélecteur de nœud dans la configuration du pod.You can schedule a pod to run on a node pool with a specific OS using a node selector in the pod's configuration.

Dans un cluster AKS qui héberge plusieurs applications et équipes de développement, il peut être difficile de suivre les pods sans ces demandes et limites de ressources.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. Une bonne pratique consiste à exécuter régulièrement kube-advisor sur vos clusters AKS, surtout si vous n’affectez pas de quotas de ressources aux espaces de noms.As a best practice, regularly run kube-advisor on your AKS clusters, especially if you don't assign resource quotas to namespaces.

Étapes suivantesNext steps

Dans cet article, nous avons traité des fonctionnalités de base du planificateur Kubernetes.This article focused on basic Kubernetes scheduler features. Pour plus d’informations sur les opérations liées aux clusters dans AKS, consultez les bonnes pratiques suivantes :For more information about cluster operations in AKS, see the following best practices: