Résoudre les problèmes de stockage dans GKE

Cette page explique comment résoudre les problèmes liés au stockage sur vos clusters Google Kubernetes Engine (GKE).

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.

Erreur 400 : impossible d'associer un disque persistant à une VM optimisée

Les disques persistants régionaux ne peuvent pas être utilisés avec des machines à mémoire optimisée ou des machines optimisées pour le calcul.

Pensez à utiliser une classe de stockage sur disque persistant non régional si l'utilisation d'un disque persistant régional n'est pas une exigence absolue. Si c'est le cas, envisagez des stratégies de planification telles que les rejets et tolérances pour vous assurer que les pods nécessitant des disques persistants régionaux sont planifiés sur un pool de nœuds (autres que des machines optimisées).

Résoudre les problèmes de performances des disques

Les performances du disque de démarrage sont importantes, car le disque de démarrage des nœuds GKE est utilisé non seulement pour le système d'exploitation, mais également pour les éléments suivants :

Images Docker.
Le système de fichiers du conteneur pour un élément qui n'est pas installé en tant que volume (c'est-à-dire le système de fichiers de superposition), qui inclut souvent des répertoires tels que /tmp.
Les volumes emptyDir sauvegardés sur disque, sauf si le nœud utilise un disque SSD local.

Les performances des disques sont partagées par tous les disques ayant le même type de disque sur un nœud. Par exemple, si vous avez un disque de démarrage pd-standard de 100 Go et un PersistentVolume pd-standard de 100 Go présentant une activité importante, les performances du disque de démarrage sont égales à celles d'un disque de 200 Go. Par ailleurs, si le PersistentVolume est très sollicité, cela a également une incidence sur les performances du disque de démarrage.

Si des messages semblables à ceux-ci apparaissent sur vos nœuds, ils peuvent être le symptôme de faibles performances du disque :

INFO: task dockerd:2314 blocked for more than 300 seconds.

fs: disk usage and inodes count on following dirs took 13.572074343s

PLEG is not healthy: pleg was last seen active 6m46.842473987s ago; threshold is 3m0s

Pour vous aider à résoudre ces problèmes, consultez les ressources suivantes :

Assurez-vous d'avoir consulté les comparaisons des types de disques de stockage et choisi un type de disque persistant adapté à vos besoins.
Ce problème survient fréquemment pour les nœuds qui utilisent des disques persistants standards dont la taille est inférieure à 200 Go. Envisagez d'augmenter la taille de vos disques ou de passer à des disques SSD, en particulier pour les clusters utilisés en production.
Envisagez d'activer le stockage SSD local pour le stockage éphémère sur vos pools de nœuds. Cette méthode est particulièrement efficace si vous avez des conteneurs utilisant fréquemment des volumes emptyDir.

L'installation d'un volume cesse de répondre en raison du paramètre `fsGroup`

Un pod configuré avec le paramètre fsGroup est l'un des problèmes pouvant entraîner l'échec de l'installation d'un PersistentVolume. Normalement, les installations effectuent automatiquement de nouvelles tentatives et l'échec de l'installation se résout automatiquement. Toutefois, si l'objet PersistentVolume contient un grand nombre de fichiers, kubelet tente de modifier la propriété de chaque fichier sur le système de fichiers, ce qui peut augmenter la latence d'installation du volume.

Unable to attach or mount volumes for pod; skipping pod ... timed out waiting for the condition

Pour confirmer si une erreur liée à l'échec d'installation est due au paramètre fsGroup, vous pouvez vérifier les journaux du pod. Si le problème est lié au paramètre fsGroup, l'entrée de journal suivante s'affiche :

Setting volume ownership for /var/lib/kubelet/pods/POD_UUID and fsGroup set. If the volume has a lot of files then setting volume ownership could be slow, see https://github.com/kubernetes/kubernetes/issues/69699

Si PersistentVolume ne s'installe pas dans les quelques minutes qui suivent, essayez les opérations suivantes pour résoudre ce problème :

Réduisez le nombre de fichiers dans le volume.
Cessez d'utiliser le paramètre [fsGroup].
Remplacez l'application fsGroupChangePolicy par OnRootMismatch.

Des opérations lentes sur le disque entraînent des échecs de création de pod

Pour plus d'informations, reportez-vous au problème containerd #4604.

Versions de nœuds GKE concernées : 1.18, 1.19, 1.20.0 à 1.20.15-gke.2100, 1.21.0 à 1.21.9-gke.2000, 1.21.10 à 1.21.10-gke.100, 1.22.0 à 1.22.6-gke.2000, 1.22.7 à 1.22.7-gke.100, 1.23.0 à 1.23.3-gke.700, 1.23.4 à 1.23.4-gke.100

Les exemples d'erreurs suivants peuvent s'afficher dans les journaux k8s_node container-runtime :

Error: failed to reserve container name "container-name-abcd-ef12345678-91011_default_12131415-1234-5678-1234-12345789012_0": name "container-name-abcd-ef12345678-91011_default_12131415-1234-5678-1234-12345789012_0" is reserved for "1234567812345678123456781234567812345678123456781234567812345678"

Atténuation

Si les pods échouent, envisagez d'utiliser restartPolicy:Always ou restartPolicy:OnFailure dans votre PodSpec.
Augmentez les IOPS du disque de démarrage (par exemple, mettez à niveau le type de disque ou augmentez la taille du disque).

Corriger

Ce problème est résolu dans containerd 1.6.0+. Les versions de GKE dotées de ce correctif sont les suivantes : 1.20.15-gke.2100+, 1.21.9-gke.2000+, 1.21.10-gke.100+, 1.22.6-gke.2000+, 1.22.7-gke.100+, 1.23.3-gke.1700+ et 1.23.4-gke.100+.

Les modifications d'expansion de volume ne se reflètent pas dans le système de fichiers du conteneur

Lorsque vous effectuez une expansion de volume, veillez à toujours mettre à jour la PersistentVolumeClaim. La modification directe d'un PersistentVolume peut entraîner l'échec de l'expansion de volume. Vous pouvez rencontrer l'un des cas suivants :

Si un PersistentVolume est modifié directement, les valeurs PersistentVolume et PersistentVolumeClaim sont mises à jour vers une nouvelle valeur, mais la taille du système de fichiers n'est pas reflétée dans le conteneur et utilise toujours l'ancienne taille de volume.
Si un objet PersistentVolume est modifié directement, suivi des mises à jour de la PersistentVolumeClaim, ainsi que du champ status.capacity, cela peut entraîner des modifications du PersistentVolume mais pas de la PersistentVolumeClaim, ni du système de fichiers du conteneur.

Pour résoudre ce problème, procédez comme suit :

Conservez l'objet PersistentVolume modifié tel quel.
Modifiez l'objet PersistentVolumeClaim et définissez spec.resources.requests.storage sur une valeur supérieure à celle utilisée dans le PersistentVolume.
Assurez-vous que l'objet PersistentVolume affiche la nouvelle valeur.

Après ces modifications, le PersistentVolume, la PersistentVolumeClaim et le système de fichiers du conteneur doivent être automatiquement redimensionnés par le kubelet.

Vérifiez que les modifications s'affichent dans le pod.

kubectl exec POD_NAME  -- /bin/bash -c "df -h"

Remplacez POD_NAME par le pod associé à l'objet PersistentVolumeClaim.

Le type de machine sélectionné doit disposer de disques SSD locaux

L'erreur suivante peut se produire lors de la création d'un cluster ou d'un pool de nœuds utilisant un disque SSD local :

The selected machine type (c3-standard-22-lssd) has a fixed number of local SSD(s): 4. The EphemeralStorageLocalSsdConfig's count field should be left unset or set to 4, but was set to 1.

Dans le message d'erreur, vous pouvez voir LocalNvmeSsdBlockConfig au lieu de EphemeralStorageLocalSsdConfig en fonction de ce que vous avez spécifié.

Cette erreur se produit lorsque le nombre de disques SSD locaux spécifié ne correspond pas à celui inclus dans le type de machine.

Pour résoudre ce problème, spécifiez un nombre de disques SSD locaux correspondant au type de machine souhaité. Pour les séries de machines de troisième génération, vous devez omettre l'option count des disques SSD locaux, et la valeur correcte sera configurée automatiquement.

Pools de stockage Hyperdisk : échec de la création d'un cluster ou d'un pool de nœuds

Vous pouvez rencontrer l'erreur ZONE_RESOURCE_POOL_EXHAUSTED ou des erreurs de ressource Compute Engine similaires lorsque vous essayez de provisionner des disques Hyperdisk Balanced en tant que disques de démarrage ou disques associés de votre nœud dans un pool de stockage Hyperdisk.

Cela se produit lorsque vous essayez de créer un cluster ou un pool de nœuds GKE dans une zone qui manque de ressources, par exemple :

Il est possible que la zone ne dispose pas de suffisamment de disques Hyperdisk équilibrés.
La zone peut ne pas disposer de la capacité suffisante pour créer les nœuds du type de machine que vous avez spécifié, comme c3-standard-4.

Pour remédier à ce problème :

Sélectionnez une nouvelle zone dans la même région, avec une capacité suffisante pour le type de machine choisi et où les pools de stockage Hyperdisk Balanced sont disponibles.
Supprimez le pool de stockage existant et recréez-le dans la nouvelle zone. En effet, les pools de stockage sont des ressources zonales.
Créez votre cluster ou votre pool de nœuds dans la nouvelle zone.

Étape suivante