Résoudre les problèmes de stockage dans GKE

Cette page explique comment résoudre les problèmes liés aux volumes déployés sur vos clusters Google Kubernetes Engine (GKE).

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 un disque persistant régional sont planifiés sur un pool de nœuds. qui ne sont pas 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 de 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 de type pd-standard de 100 Go et un PersistentVolume de type 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 aura é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 solutions suivantes pour résoudre ce problème :

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

Problème constaté et diagnostic

Exemple d'erreur dans les journaux de l'environnement d'exécution du conteneur k8s_node :

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

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

Corrigé

Ce problème est maintenant corrigé dans containerd 1.6.0+. Les versions de GKE contenant le 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 de conteneur

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

  • Si un objet 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 de mises à jour de l'objet PersistentVolumeClaim, ainsi que du champ status.capacity, cela peut entraîner des modifications de l'objet PersistentVolume mais pas de l'objet PersistentVolumeClaim, ni du système de fichiers du conteneur.

Atténuation

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

Après ces modifications, l'objet PersistentVolume, l'objet PersistentVolumeClaim et le système de fichiers de 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 au nombre de disques SSD locaux inclus dans le type de machine.

Atténuation

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 du disque SSD local et la valeur correcte sera configurée automatiquement.