Ce document vous aide à comprendre le fonctionnement des limites de rattachement des volumes persistants pour les disques persistants et les Hyperdisks Compute Engine sur les nœuds Google Kubernetes Engine (GKE). Pour une planification appropriée des charges de travail et un dimensionnement adéquat des pools de nœuds, il est essentiel de comprendre le nombre maximal de volumes persistants pouvant être rattachés à un nœud GKE. Si vous souhaitez mieux contrôler la planification des charges de travail, en particulier lorsque vous utilisez plusieurs types de disques avec des limites de rattachement variables sur une seule instance, vous pouvez utiliser un libellé de nœud pour remplacer les limites de rattachement par défaut.
Ce document est destiné aux spécialistes du stockage qui créent et allouent du stockage, ainsi qu'aux administrateurs GKE qui gèrent la planification des charges de travail et le dimensionnement des pools de nœuds. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le Cloud de Confiance by S3NS contenu, consultez Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.
Présentation
Dans GKE, lorsque vous demandez un PersistentVolume (PV) à l'aide du pilote CSI de disque persistant Compute Engine (pd.csi.storage.gke.io), un volume de stockage de blocs est provisionné à partir du Cloud de Confiance service Persistent Disk.
Lorsque vous activez le pilote CSI de disque persistant Compute Engine (PDCSI) sur les clusters GKE, il calcule et signale la limite de rattachement des volumes persistants par nœud au kubelet. En fonction de ces informations, le planificateur Kubernetes prend des décisions de planification pour s'assurer qu'il ne planifie pas trop de pods nécessitant des volumes persistants sur un nœud ayant atteint sa capacité de rattachement. Si le pilote PDCSI a signalé des limites de rattachement inexactes, plus précisément un nombre supérieur à la limite réelle, les pods ne pourront pas être planifiés et resteront bloqués dans un état Pending. Cela peut se produire sur les types de machines de troisième génération, tels que C3, qui ont des limites de rattachement différentes pour les Hyperdisks et les disques persistants.
Comprendre les limites de rattachement des volumes persistants
Pour les générations de machines antérieures à la quatrième, le pilote PDCSI Compute Engine définit une limite de rattachement de volume persistant agrégée de 128 disques (127 disques de données plus un disque de démarrage) pour tous les types de machines. La limite de rattachement s'applique à la fois aux volumes Persistent Disk et Hyperdisk combinés. Pour Hyperdisk, la limite de rattachement est déterminée par le type de machine Compute Engine sous-jacent, le nombre de processeurs virtuels de la machine et le type d'Hyperdisk spécifique.
Exemple :
- Pour les types de machines de quatrième génération, tels que C4, le pilote PDCSI signale avec précision à Kubernetes une limite de rattachement par défaut calculée en fonction du nombre de processeurs virtuels du nœud. La limite de rattachement signalée se situe généralement entre 8 et 128 volumes persistants.
- En revanche, pour les types de machines de troisième génération, tels que C3, le pilote PDCSI signale à Kubernetes une limite de rattachement par défaut correspondant à la limite fixe de 128 disques, ce qui peut entraîner un échec de planification des pods, car la limite réelle peut être inférieure à 128 en fonction du nombre de processeurs virtuels.
Vous pouvez remplacer la limite de rattachement par défaut à l'aide d'un libellé de nœud.
Consultez les ressources utiles suivantes dans la documentation Compute Engine :
- Pour connaître les générations de machines Compute Engine disponibles, consultez le tableau de la section Terminologie Compute Engine.
- Pour obtenir la liste des types de machines et de leurs types de disques persistants compatibles, consultez la section Compatibilité des séries de machines.
- Pour connaître les limites de rattachement Hyperdisk maximales compatibles en fonction du nombre de processeurs de différents types d'Hyperdisk, consultez la section Nombre maximal de volumes Hyperdisk par VM.
- Pour comprendre comment les limites de rattachement Hyperdisk sont appliquées à un nœud, consultez la section Résumé des limites Hyperdisk par VM..
Remplacer la limite de rattachement des volumes persistants par défaut
Si vous avez des exigences ou des configurations de nœuds spécifiques dans lesquelles vous souhaitez rattacher un nombre spécifique de volumes persistants à vos nœuds, vous pouvez remplacer la limite de rattachement des volumes persistants par défaut pour un pool de nœuds à l'aide du libellé de nœud suivant : node-restriction.kubernetes.io/gke-volume-attach-limit-override: VALUE.
Vous pouvez utiliser ce libellé de nœud sur les versions GKE suivantes :
1.32.4-gke.1698000et versions ultérieures.1.33.1-gke.1386000et versions ultérieures.
Nouveau pool de nœuds
Pour créer un pool de nœuds avec une limite de rattachement de volume persistant spécifique, exécutez la commande suivante :
gcloud container node-pools create NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--node-labels=node-restriction.kubernetes.io/gke-volume-attach-limit-override=VALUE
Pool de nœuds existant
Pour modifier la limite de rattachement des volumes persistants actuelle d'un pool de nœuds existant, procédez comme suit :
Mettez à jour la limite de rattachement sur le pool de nœuds :
gcloud container node-pools update NODE_POOL_NAME \ --cluster=CLUSTER_NAME \ --node-labels=node-restriction.kubernetes.io/gke-volume-attach-limit-override=VALUERedémarrez le DaemonSet
pdcsi-node:kubectl rollout restart ds pdcsi-node -n kube-systemLa nouvelle limite de rattachement s'applique une fois que les pods
pdcsi-nodesont à l'étatRunning.
Remplacez les éléments suivants :
NODE_POOL_NAME: nom du pool de nœuds que vous souhaitez créer ou mettre à jour.CLUSTER_NAME: nom du cluster pour le pool de nœuds que vous souhaitez créer ou mettre à jour.VALUE: entier compris entre0et127pour spécifier le nouveau nombre de volumes persistants pouvant être rattachés. Si vous spécifiez une valeur supérieure à 127, le libellé de nœud est ignoré et le pilote PDCSI utilise la limite de rattachement des volumes persistants par défaut. La limite par défaut est de 128 pour les machines de troisième génération et d'une valeur basée sur le nombre de processeurs virtuels pour les machines de quatrième génération.
Vérifier le remplacement
Pour vérifier si le remplacement a été appliqué correctement, vérifiez les libellés et la capacité du nœud.
Dans les commandes suivantes, remplacez NODE_NAME par le nom d'un nœud qui fait partie du pool de nœuds spécifique dans lequel vous avez appliqué le libellé de nœud de remplacement.
Vérifiez les libellés de nœuds :
kubectl get node NODE_NAME --show-labelsLe résultat doit inclure le libellé
node-restriction.kubernetes.io/gke-volume-attach-limit-override.Vérifiez la capacité du nœud :
kubectl describe node NODE_NAMELe résultat doit inclure la capacité
attachable-volumes-gce-pd, qui doit correspondre à la valeur de remplacement que vous avez définie pour le pool de nœuds. Pour en savoir plus, consultez Vérifier les ressources pouvant être allouées sur un nœud.
Étape suivante
- Découvrez le stockage de volumes persistants GKE.
- Découvrez le fonctionnement du planificateur Kubernetes.