Bonnes pratiques relatives aux fonctionnalités de base du planificateur dans 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. Le planificateur Kubernetes vous permet de contrôler la distribution des ressources de calcul et de limiter l’impact des événements de maintenance.

Cet article traite des bonnes pratiques relatives aux fonctionnalités de planification Kubernetes de base pour les opérateurs de clusters. Dans cet article, vous apprendrez comment :

Appliquer des quotas de ressources

Conseils sur les bonnes pratiques

Planifiez et appliquez des quotas de ressources au niveau de l’espace de noms. Utilisez des quotas et des plages de limites pour exiger ou fournir des demandes et des limites de ressources par défaut pour les pods. Supervisez l’utilisation des ressources et ajustez les quotas en fonction des besoins.

Définissez les demandes de ressources et les limites de ressources dans la spécification du pod. Une demande de ressource correspond à la quantité de processeur ou de mémoire utilisée par le planificateur Kubernetes pour placer un pod. Une limite de ressources limite la quantité de cette ressource qu’un conteneur peut utiliser. Le système applique les limites du processeur en limitant, tandis qu’il applique des limites de mémoire réactivement par le biais d’un arrêt OOM (out-of-memory). Pour plus d’informations, consultez Définir les demandes et limites des ressources de pod.

Utilisez des quotas de ressources pour limiter la consommation de ressources agrégées pour une équipe de développement ou un projet. Définissez des quotas au niveau de l’espace de noms pour :

• Ressources de calcul (par exemple, le processeur et la mémoire ou des GPU).
• Ressources de stockage, y compris le nombre total de volumes ou la quantité d’espace disque pour une classe de stockage donnée.
• Nombre d’objets, tels que le nombre maximal de secrets, de services ou de travaux qui peuvent être créés.

Le planificateur Kubernetes utilise des demandes de ressources pour placer des pods. Les conteneurs peuvent utiliser plus de processeur ou de mémoire que demandé lorsque la capacité est disponible, et les limites de ressources peuvent dépasser les demandes. Un quota de ressources limite séparément la consommation d’espace de noms agrégée. Si la création ou la mise à jour d’une ressource dépasse un quota dur, le serveur d’API rejette la requête avec une réponse HTTP 403 Forbidden . Vous pouvez toujours créer un objet de charge de travail tel qu’un déploiement même lorsque le quota empêche son contrôleur de créer tous les pods demandés.

Si un quota de ressources effectue le suivi de l’UC ou de la mémoire, chaque nouveau pod doit spécifier une demande ou une limite pour cette ressource. Sinon, le serveur d’API peut rejeter le pod. Vous pouvez configurer des requêtes et des limites par défaut pour un espace de noms à l’aide d’un LimitRange.

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 :

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

Ce quota limite les demandes d’UC agrégées à 10 UC, les demandes de mémoire agrégées à 20Gi et le nombre de pods non déterminaux à 10 dans l’espace de noms.

Appliquez ce quota de ressources à un espace de noms, par exemple 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.

Pour plus d’informations sur les objets de ressource, étendues et priorités disponibles, consultez Quotas de ressources dans Kubernetes.

Limiter l’impact des interruptions à l’aide des budgets d’interruption de pod (PDB)

Conseils sur les bonnes pratiques

Définissez des budgets d’interruption de pod (PDB) pour les applications répliquées afin de limiter les évictions volontaires simultanées pendant des événements tels que les drains de nœud AKS. Maintenez suffisamment de réplicas sains et autorisez au moins une interruption lorsque la charge de travail autorise la maintenance du cluster afin que la maintenance du cluster puisse continuer.

Les événements perturbateurs qui suppriment les pods se trouvent dans deux catégories :

Perturbations involontaires

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. Voici quelques exemples :

• Défaillance matérielle sur la machine physique
• Panique au niveau du noyau
• Suppression d’une machine virtuelle de nœud

Vous pouvez atténuer les perturbations involontaires en :

• L’utilisation de réplicas de vos pods dans un déploiement.
• L’exécution de plusieurs nœuds dans le cluster AKS.

Perturbations volontaires

_ Les disruptions_ volontaires sont des événements que l’opérateur de cluster ou le propriétaire de l’application demande. Voici quelques exemples :

• Drainage d’un nœud pendant la mise à niveau d’un cluster
• Mise à jour d’un modèle de déploiement
• Suppression directe d’un pod

Toutes les perturbations volontaires ne sont pas limitées par les PDB. La suppression directe d’un pod ou d’un objet de charge de travail contourne les fichiers PDF, et les contrôleurs de charge de travail tels que les déploiements et les statefulSets ne sont pas limités par les PDB pendant les mises à jour propagées. Configurez séparément la stratégie de déploiement de la charge de travail pour maintenir la disponibilité pendant les mises à jour des applications. Pour plus d’informations, consultez Interruptions dans Kubernetes.

Les PDB limitent les évictions volontaires simultanées pour les pods sélectionnés via l’API Éviction Kubernetes. Pendant une mise à niveau propagée AKS, AKS ajoute une capacité d’augmentation en fonction des paramètres du pool de nœuds, des cordons et draine un nœud, puis réimage ou remplace le nœud drainé. L’API Éviction évalue la base de données PDB pendant le drainage. Après une éviction, le contrôleur de charge de travail crée un pod de remplacement et le planificateur le place sur un nœud avec une capacité disponible. Une base de données PDB restrictive, des réplicas sains insuffisants ou une capacité de cluster insuffisante peut retarder ou bloquer le drainage.

Définir un nombre minimal de pods disponibles

Considérez un ReplicaSet avec cinq pods NGINX étiquetés app: nginx-frontend. Lors d’un événement d’interruption volontaire, tel qu’une mise à niveau de cluster, au moins trois pods doivent rester disponibles. Le manifeste suivant PodDisruptionBudget définit cette exigence :

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

Ce budget nécessite au moins trois pods avec l’étiquette app: nginx-frontend pour rester en bonne santé lors d’une éviction volontaire.

Vous pouvez spécifier un pourcentage, tel que 60%, afin que le budget s’ajuste lorsque le ReplicaSet est mis à l’échelle.

Définir un nombre maximal de pods indisponibles

Une base de données PDB peut définir l’une ou l’autre minAvailable , maxUnavailablemais pas les deux. Pour limiter les évictions volontaires basées sur des pods indisponibles, spécifiez maxUnavailable un entier ou un pourcentage. Le manifeste suivant autorise une éviction volontaire uniquement lorsque plus de deux pods du ReplicaSet ne sont pas disponibles après l’éviction :

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

Ce budget autorise une éviction volontaire uniquement lorsque plus de deux pods avec l’étiquette app: nginx-frontend ne seraient pas disponibles après l’éviction. Les perturbations involontaires peuvent encore entraîner une baisse de la disponibilité au-dessous de ce seuil.

La AlwaysAllow stratégie d’éviction de pod non saine permet d’évacuer les pods en cours d’exécution qui ne sont pas sains. Sans ce paramètre, la stratégie par défaut IfHealthyBudget peut bloquer un drain en attendant que les pods défectueux deviennent sains. Utilisez AlwaysAllow quand la drainabilité est plus importante que de donner un pod non sain plus de temps pour récupérer.

Enregistrez le manifeste PDB que vous souhaitez utiliser comme nginx-pdb.yaml, puis appliquez-le à votre cluster AKS :

kubectl apply -f nginx-pdb.yaml

Avant la maintenance du cluster, vérifiez que chaque base de données PDB autorise l’éviction attendue :

kubectl get poddisruptionbudgets --namespace <namespace>

Une ALLOWED DISRUPTIONS valeur de 0 peut bloquer un drain de nœud AKS. Collaborez avec vos développeurs et propriétaires d’applications pour maintenir suffisamment de réplicas sains et choisissez un budget qui équilibre la disponibilité des applications avec les exigences de maintenance.

Pour plus d’informations sur l’utilisation de budgets de perturbation de pod, consultez Spécifier un budget de perturbation pour votre application.

Contenu connexe

Cet article se concentre sur les fonctionnalités du planificateur Kubernetes de base. Pour plus d’informations sur les opérations de cluster dans AKS, consultez les articles suivants sur les meilleures pratiques :

• Multilocation et isolation de cluster
• Fonctionnalités avancées du planificateur Kubernetes
• Authentification et autorisation