Cette page explique comment planifier la taille des nœuds dans les pools de nœuds Google Kubernetes Engine (GKE) Standard afin de réduire le risque d'interruption de charge de travail et d'arrêt en raison de manque de ressources.
Cette planification n'est pas nécessaire dans GKE Autopilot, car Google Cloud gère les nœuds à votre place. Toutefois, ce document aide les opérateurs de cluster Autopilot qui souhaitent comprendre la capacité de ressources d'un nœud disponible pour vos charges de travail.
Avantages des nœuds de taille adaptée
S'assurer que vos nœuds sont correctement dimensionnés pour gérer vos charges de travail et gérer les pics d'activité offre les avantages suivants :
- Meilleure fiabilité des charges de travail en raison d'un risque réduit d'éviction en raison de ressources insuffisantes.
- Amélioration de l'évolutivité pour le scaling des charges de travail lors des pics de trafic.
- Réduction des coûts, car les nœuds ne sont pas trop volumineux pour vos besoins, ce qui peut entraîner un gaspillage de ressources.
Ressources pouvant être allouées aux nœuds
Les nœuds GKE exécutent des composants système qui permettent au nœud de fonctionner comme partie intégrante de votre cluster. Ces composants utilisent des ressources de nœud, telles que le processeur et la mémoire. Vous remarquerez peut-être une différence entre le nombre total de ressources de votre nœud, qui est basé sur la taille de la machine virtuelle (VM) Compute Engine sous-jacente, et le nombre de ressources disponibles auxquelles vos charges de travail GKE peuvent faire appel. Cette différence est due au fait que GKE réserve une quantité prédéfinie de ressources pour les fonctionnalités système et la fiabilité des nœuds. L'espace disque réservé par GKE pour les ressources système varie en fonction de l'image de nœud. Les ressources restantes disponibles pour vos charges de travail sont appelées ressources pouvant être allouées.
Lorsque vous définissez des pods dans un fichier manifeste, vous pouvez spécifier des requêtes et des limites de ressources dans la spécification des pods. Lorsque GKE place les pods sur un nœud, ceux-ci demandent ces ressources spécifiées parmi les ressources pouvant être allouées sur le nœud. Lors de la planification de la taille des nœuds de vos pools de nœuds, vous devez prendre en compte le nombre de ressources dont vos charges de travail ont besoin pour fonctionner correctement.
Vérifier les ressources pouvant être allouées sur un nœud
Pour inspecter les ressources pouvant être allouées sur un nœud existant, exécutez la commande suivante :
kubectl get node NODE_NAME \
-o=yaml | grep -A 7 -B 7 capacity
Remplacez NODE_NAME par le nom du nœud.
Le résultat ressemble à ce qui suit :
allocatable:
attachable-volumes-gce-pd: "127"
cpu: 3920m
ephemeral-storage: "47060071478"
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 13498416Ki
pods: "110"
capacity:
attachable-volumes-gce-pd: "127"
cpu: "4"
ephemeral-storage: 98831908Ki
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 16393264Ki
pods: "110"
Dans ce résultat, les valeurs de la section allocatable correspondent aux ressources pouvant être allouées sur le nœud. Les valeurs de la section capacity correspondent au nombre total de ressources sur le nœud. Les unités du stockage éphémère sont les octets.
Réservations de ressources GKE
GKE réserve des quantités spécifiques de ressources de mémoire et de processeur sur les nœuds en fonction de la taille totale de la ressource disponible sur le nœud. Les types de machines plus volumineux exécutent plus de conteneurs et de pods. Ainsi, la quantité de ressources réservées par GKE évolue pour des machines plus volumineuses. Les nœuds Windows Server nécessitent également plus de ressources que les nœuds Linux équivalents, pour tenir compte de l'exécution du système d'exploitation Windows et des composants Windows Server qui ne peuvent pas être exécutés dans des conteneurs.
Réservations de mémoire et de processeur
Les sections suivantes décrivent les réservations de mémoire et de processeur par défaut en fonction du type de machine.
Réservations de mémoire
Pour les ressources de mémoire, GKE réserve les éléments suivants :
- 255 Mio de mémoire pour les machines dotées de moins de 1 Go de mémoire
- 25 % des 4 premiers Gio de mémoire
- 20 % des 4 Gio de mémoire suivants (jusqu'à 8 Gio)
- 10 % des 8 Gio de mémoire suivants (jusqu'à 16 Gio)
- 6 % des 112 Gio suivants de mémoire (jusqu'à 128 Gio)
- 2 % de toute la mémoire au-delà de 128 Gio
GKE réserve également 100 Mio de mémoire supplémentaires sur chaque nœud pour gérer l'éviction des pods.
Réservations de processeur
Pour les ressources du processeur, GKE réserve les éléments suivants :
- 6 % du premier cœur
- 1 % du cœur suivant (jusqu'à 2 cœurs)
- 0,5 % des 2 cœurs suivants (jusqu'à 4 cœurs)
- 0,25 % de tous les cœurs au-delà de 4 cœurs
Pour les types de machines E2 à cœur partagé, GKE réserve un total de 1 060 millicores.
Réservation d'espace de stockage éphémère local
GKE fournit des nœuds avec un stockage éphémère local, reposant sur des périphériques associés localement, tels que le disque de démarrage des nœuds ou les SSD locaux. Le stockage éphémère n'offre aucune garantie de disponibilité et les données qui y sont stockées peuvent être perdues en cas de défaillance et de suppression d'un nœud.
GKE réserve une partie du stockage éphémère total du nœud en tant que système de fichiers unique à utiliser par le kubelet lors de l'éviction des pods et pour d'autres composants système exécutés sur le nœud. Vous pouvez allouer le stockage éphémère restant à vos pods pour l'utiliser à des fins telles que les journaux. Pour savoir comment spécifier des requêtes et des limites de stockage éphémère dans vos pods, consultez la section Stockage éphémère local.
GKE calcule la réservation de stockage éphémère local comme suit :
EVICTION_THRESHOLD + SYSTEM_RESERVATION
Les valeurs réelles varient en fonction de la taille et du type d'appareil qui sauvegarde le stockage.
Stockage éphémère sauvegardé par le disque de démarrage des nœuds
Par défaut, le stockage éphémère est secondé par le disque de démarrage des nœuds. Dans ce cas, GKE détermine la valeur du seuil d'éviction comme suit :
EVICTION_THRESHOLD = 10% * BOOT_DISK_CAPACITY
Le seuil d'éviction est toujours de 10 % de la capacité totale du disque de démarrage.
GKE détermine la valeur de la réservation système comme suit :
SYSTEM_RESERVATION = Min(50% * BOOT_DISK_CAPACITY, 6GiB + 35% * BOOT_DISK_CAPACITY, 100 GiB)
La quantité de réservation système est la valeur la plus faible parmi les suivantes :
- 50 % de la capacité du disque de démarrage
- 35 % de la capacité du disque de démarrage + 6 Gio
- 100 Gio
Par exemple, si votre disque de démarrage est de 300 Gio, les valeurs suivantes s'appliquent :
- 50 % de la capacité : 150 Gio
- 35 % de la capacité + 6 Gio : 111 Gio
- 100 Gio
GKE réserve les éléments suivants :
- Réservation système : 100 Gio (valeur la plus faible)
- Seuil d'éviction : 30 Gio
L'espace de stockage éphémère total réservé est de 130 Gio. La capacité restante, 170 Gio, est un espace de stockage éphémère pouvant être alloué.
Stockage éphémère sauvegardé par les disques SSD locaux
Si votre stockage éphémère est sauvegardé par des disques SSD locaux, GKE calcule le seuil d'éviction comme suit :
EVICTION_THRESHOLD = 10% * SSD_NUMBER * 375 GiB
Dans ce calcul, SSD_NUMBER correspond au nombre de disques SSD locaux associés. La taille de tous les disques SSD locaux est de 375 Gio. Le seuil d'éviction est donc de 10 % de la capacité de stockage éphémère totale. Notez que ceci est calculé avant le formatage des disques. Par conséquent, la capacité utilisable est inférieure de plusieurs pourcentages, selon les versions de l'image de nœud.
GKE calcule la réservation système en fonction du nombre de disques SSD associés, comme suit :
| Nombre de disques SSD locaux | Réservation système (Gio) |
|---|---|
| 1 | 50 Gio |
| 2 | 75 Gio |
| 3 ou plus | 100 Gio |
Utiliser des réservations de ressources pour planifier la taille des nœuds
Tenez compte des besoins en ressources de vos charges de travail au moment du déploiement et en cas de charge élevée. Cela inclut les requêtes et les limites planifiées pour les charges de travail, ainsi que la surcharge pour prendre en charge le scaling à la hausse.
Déterminez si vous souhaitez utiliser un petit nombre de nœuds de grande taille ou un grand nombre de nœuds de petite taille pour exécuter vos charges de travail.
- Un petit nombre de nœuds de grande taille fonctionne bien pour les charges de travail exigeantes en ressources qui ne nécessitent pas de haute disponibilité. L'autoscaling des nœuds est moins agile, car un plus grand nombre de pods doivent être supprimés pour qu'un scaling à la baisse soit effectué.
- Un grand nombre de nœuds de petite taille fonctionne bien pour les charges de travail à disponibilité élevée qui ne consomment pas beaucoup de ressources. L'autoscaling des nœuds est plus flexible, car moins de pods doivent être supprimés pour qu'un scaling à la baisse soit effectué.
Utilisez le guide de comparaison des familles de machines Compute Engine pour déterminer la série et la famille de machines que vous souhaitez utiliser pour vos nœuds.
Tenez compte des exigences de stockage éphémère de vos charges de travail. Le disque de démarrage des nœuds est-il suffisant ? Avez-vous besoin de disques SSD locaux ?
Calculez les ressources pouvant être allouées sur le type de machine de votre choix à l'aide des informations fournies dans les sections précédentes. Comparez-les aux ressources et à la surcharge nécessaires.
- Si le type de machine que vous avez choisi est trop volumineux, envisagez d'utiliser une machine plus petite pour éviter de payer des ressources supplémentaires.
- Si le type de machine que vous avez choisi est trop petit, envisagez d'utiliser une machine plus grande pour réduire le risque d'interruption de charge de travail.