Réservations de ressources de nœud dans Azure Kubernetes Service (AKS)

Dans cet article, vous découvrez les réservations de ressources de nœud dans Azure Kubernetes Service (AKS).

Réservations de ressources

AKS utilise des ressources de nœud pour permettre aux nœuds de fonctionner dans le cadre du cluster. Cette utilisation peut entraîner un écart entre les ressources totales du nœud et les ressources allouables dans AKS.

AKS réserve deux types de ressources, processeur et mémoire, sur chaque nœud pour conserver les fonctionnalités et les performances des nœuds. À mesure qu’un nœud augmente en ressources, les réservations de ressources augmentent aussi en raison d’un besoin accru pour gérer les pods déployés par l’utilisateur. Gardez à l’esprit que vous ne pouvez pas changer les réservations de ressources sur un nœud.

Réservations de CPU

Le processeur réservé dépend du type de nœud et de la configuration du cluster, ce qui peut rendre le processeur moins allouable en raison de l’exécution de fonctionnalités supplémentaires. Le tableau suivant montre les réservations de processeur en millicœurs :

Cœurs de processeur sur l’hôte 1 cœur 2 cœurs 4 cœurs 8 cœurs 16 cœurs 32 cœurs 64 cœurs
CPU réservé pour Kubernetes (millicores) 60 100 140 180 260 420 740

Réservations de mémoire

Dans AKS, la mémoire réservée correspond à la somme de deux valeurs :

AKS 1.29 et les versions ultérieures

  • Le kubelet démon dispose par défaut de la règle d’éviction memory.available < 100 Mi. Cette règle garantit qu’un nœud a toujours au moins 100 Mi allouables. Quand un hôte se trouve en dessous du seuil de mémoire disponible, kubelet déclenche l’arrêt d’un des pods en cours d’exécution et libère de la mémoire sur la machine hôte.

  • Un taux de réservations de mémoire est défini en fonction de la valeur la plus petite entre : 20 Mo * nombre maximal de pods pris en charge sur le nœud + 50 Mo ou 25 % des ressources de mémoire système totales.

    Exemples :

    • Si la machine virtuelle fournit 8 Go de mémoire et que le nœud prend en charge jusqu’à 30 pods, AKS réserve 20 Mo * 30 pods max. + 50 Mo = 650 Mo pour kube-reserved. Allocatable space = 8 GB - 0.65 GB (kube-reserved) - 0.1 GB (eviction threshold) = 7.25 GB or 90.625% allocatable.
    • Si la machine virtuelle fournit 4 Go de mémoire et que le nœud prend en charge jusqu’à 70 pods, AKS réserve 25 % * 4 Go = 1 000 Mo pour kube-reserved, car la valeur est inférieure à 20 Mo * 70 pods max. + 50 Mo = 1 450 Mo.

    Pour plus d’informations, consultez Configurer le nombre maximal de pods pour un cluster AKS.

Remarque

Pour personnaliser les kubeReserved valeurs du processeur et de la mémoire ou hardEvictionThreshold sur les pools de nœuds Linux, utilisez les paramètres de préversion de configuration personnalisée des nœuds et enregistrez l’indicateur de fonctionnalité AKSNodeCustomizationPreview. Pour plus d’informations, consultez Personnaliser la configuration des nœuds des pools de nœuds Azure Kubernetes Service (AKS).

Versions AKS antérieures à 1.29

  • Le démon kubelet utilise par défaut la règle d’éviction memory.available < 750 Mi. Cette règle garantit qu’un nœud a toujours au moins 750 Mi allouables. Quand un hôte est en dessous du seuil de mémoire disponible, kubelet déclenche l’arrêt d’un des pods en cours d’exécution et libère de la mémoire sur la machine hôte.
  • Un taux régressif de réservations de mémoire pour le bon fonctionnement du démon kubelet (kube-reserved).
    • 25 % des 4 premiers Go de mémoire
    • 20 % des 4 Go suivants de mémoire (jusqu’à 8 Go)
    • 10 % des 8 Go suivants de mémoire (jusqu’à 16 Go)
    • 6 % des 112 Go suivants de mémoire (jusqu’à 128 Go)
    • 2 % de la mémoire supérieure à 128 Go

Remarque

AKS réserve 2 Go supplémentaires pour les processus système sur les nœuds Windows, qui ne sont pas inclus dans la mémoire calculée.

Les règles d’allocation de mémoire et de processeur sont conçues avec les objectifs suivants :

  • Maintenez l’intégrité des nœuds d’agent, avec quelques blocs de système d’hébergement critiques pour l’intégrité du cluster.
  • Faire en sorte que le nœud indique moins de mémoire et de processeur allouable qu’il ne le ferait s’il ne faisait pas partie d’un cluster Kubernetes.

Par exemple, si un nœud offre 7 Go, il signale 34 % de la mémoire non allouable incluant le seuil d’éviction dur de 750 Mi.

0.75 + (0.25*4) + (0.20*3) = 0.75 GB + 1 GB + 0.6 GB = 2.35 GB / 7 GB = 33.57% reserved

En plus des réservations pour Kubernetes lui-même, le système d’exploitation du nœud sous-jacent réserve également une quantité de ressources de processeur et de mémoire pour gérer les fonctions du système d’exploitation.

Pour connaître les meilleures pratiques associées, consultez la section Meilleures pratiques relatives aux fonctionnalités de base du planificateur dans AKS.

Étapes suivantes

  • Last updated on