Limites d'association de volumes persistants pour les nœuds GKE

Ce document vous aide à comprendre le fonctionnement des limites de connexion des volumes persistants pour les disques persistants Compute Engine et les hyperdisques sur les nœuds Google Kubernetes Engine (GKE). Pour planifier correctement les charges de travail et dimensionner les pools de nœuds, il est essentiel de comprendre le nombre maximal de volumes persistants pouvant être associé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 d'association variables sur une même instance, vous pouvez utiliser un libellé de nœud pour remplacer les limites d'association par défaut.

Ce document s'adresse 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 mentionnés dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de 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 par blocs est provisionné à partir du service de disque persistant Google Cloud .

Lorsque vous activez le pilote CSI de disque persistant Compute Engine (PDCSI) sur les clusters GKE, il calcule et signale la limite d'association de volumes persistants par nœud au kubelet. Sur la base 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é d'attachement. 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 l'état Pending. Cela peut se produire sur les types de machines de troisième génération, tels que C3, qui ont des limites d'association différentes pour les disques Hyperdisk et Persistent Disk.

Comprendre les limites de connexion des volumes persistants

Pour les générations de machines antérieures à la quatrième, le pilote PDCSI de 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 pièces jointes s'applique à la fois aux volumes Persistent Disk et Hyperdisk combinés. Pour Hyperdisk, la limite d'association est déterminée par le type de machine Compute Engine sous-jacent, le nombre de processeurs virtuels de la machine et le type Hyperdisk spécifique.

Exemple :

  • Pour les types de machines de quatrième génération comme C4, le pilote PDCSI indique avec précision une limite d'attachement par défaut à Kubernetes, calculée en fonction du nombre de processeurs virtuels du nœud. La limite de volumes persistants pouvant être associés est généralement comprise entre 8 et 128.
  • En revanche, pour les types de machines de troisième génération comme C3, le pilote PDCSI signale une limite d'association par défaut à Kubernetes comme étant 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 d'association par défaut à l'aide d'un libellé de nœud.

Consultez les ressources utiles suivantes dans la documentation Compute Engine :

Ignorer la limite de rattachement de volume persistant par défaut

Si vous avez des exigences ou des configurations de nœuds spécifiques pour lesquelles vous souhaitez associer un nombre spécifique de volumes persistants à vos nœuds, vous pouvez remplacer la limite par défaut de volumes persistants associés 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.1698000 ou version ultérieure.
  • 1.33.1-gke.1386000 ou version ultérieure.

Nouveau pool de nœuds

Pour créer un pool de nœuds avec une limite d'association de volumes persistants 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 actuelle de volumes persistants associés d'un pool de nœuds existant, procédez comme suit :

  1. Mettez à jour la limite d'association 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=VALUE

  2. Redémarrez le DaemonSet pdcsi-node :

    kubectl rollout restart ds pdcsi-node -n kube-system

    La nouvelle limite de pièces jointes s'applique une fois que les pods pdcsi-node sont à l'état Running.

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 entre 0 et 127 pour spécifier le nouveau nombre de volumes persistants pouvant être associés. Si vous spécifiez une valeur supérieure à 127, le libellé de nœud est ignoré et le pilote PDCSI utilise la limite par défaut de volumes persistants associés. 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 vCPU 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é des nœuds.

Dans les commandes suivantes, remplacez NODE_NAME par le nom d'un nœud qui fait partie du pool de nœuds spécifique auquel vous avez appliqué le libellé de nœud de remplacement.

  1. Vérifiez les libellés de nœuds :

    kubectl get node NODE_NAME --show-labels

    Le résultat doit inclure le libellé node-restriction.kubernetes.io/gke-volume-attach-limit-override.

  2. Vérifiez la capacité du nœud :

    kubectl describe node NODE_NAME

    Le 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.

Étapes suivantes