Le pod Kubernetes échoue avec "Impossible d'attacher ou de monter les volumes"

Question

Après la mise à jour de Kubernetes de 1.18.13 à 1.19.5, j'obtiens l'erreur ci-dessous pour certains pods de manière aléatoire. Après un certain temps, le pod échoue à démarrer (c'est un pod simple, il ne fait pas partie d'un déploiement)

  Avertissement  Échec de montage  99s   kubelet  Impossible d'attacher ou de monter les volumes : volumes non montés=[red-tmp data logs docker src red-conf], volumes non attachés=[red-tmp data logs docker src red-conf] : délai d'attente dépassé en attendant la condition

• Sur la version 1.18, nous n'avons pas ce problème, et pendant la mise à niveau, K8S ne montre aucune erreur ou message d'incompatibilité.
• Aucun journal supplémentaire d'autres composants K8S (j'ai essayé d'augmenter le niveau de verbosité pour kubelet)
• Tout va bien en termes d'espace disque et d'autres métriques de l'hôte comme la charge, la RAM
• Pas de stockages en réseau, uniquement des données locales
• Les PV et PVC sont créés avant les pods et nous ne les modifions pas
• J'ai essayé d'utiliser des versions K8S plus récentes mais sans succès

Nous avons une configuration assez standard sans personnalisations spéciales :

• Réseau : Flannel
• Runtime : Docker
• Un seul nœud en tant que maître et travailleur
• 16 cœurs et 32 Go de RAM

Exemple de définition de pod :

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: provision
    ver: latest
  name: provision
  namespace: red
spec:
  containers:
  - args:
    - wait
    command:
    - provision.sh
    image: app-tests
    imagePullPolicy: IfNotPresent
    name: provision
    volumeMounts:
    - mountPath: /opt/app/be
      name: src
    - mountPath: /opt/app/be/conf
      name: red-conf
    - mountPath: /opt/app/be/tmp
      name: red-tmp
    - mountPath: /var/lib/app
      name: data
    - mountPath: /var/log/app
      name: logs
    - mountPath: /var/run/docker.sock
      name: docker
  dnsConfig:
    options:
    - name: ndots
      value: "2"
  dnsPolicy: ClusterFirst
  enableServiceLinks: false
  restartPolicy: Never
  volumes:
  - hostPath:
      path: /opt/agent/projects/app-backend
      type: Directory
    name: src
  - name: red-conf
    persistentVolumeClaim:
      claimName: conf
  - name: red-tmp
    persistentVolumeClaim:
      claimName: tmp
  - name: data
    persistentVolumeClaim:
      claimName: data
  - name: logs
    persistentVolumeClaim:
      claimName: logs
  - hostPath:
      path: /var/run/docker.sock
      type: Socket
    name: docker

PV

apiVersion: v1
kind: PersistentVolume
metadata:
  name: red-conf
  labels:
    namespace: red
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 2Gi
  hostPath:
    path: /var/lib/docker/k8s/red-conf
  persistentVolumeReclaimPolicy: Retain
  storageClassName: red-conf
  volumeMode: Filesystem

PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: conf
  namespace: red
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 2Gi
  storageClassName: red-conf
  volumeMode: Filesystem
  volumeName: red-conf

tmp data logs pv ont la même configuration que conf à l'exception du chemin. Ils ont des dossiers séparés :

/var/lib/docker/k8s/red-tmp
/var/lib/docker/k8s/red-data
/var/lib/docker/k8s/red-logs

Actuellement, je n'ai aucune idée pour diagnostiquer le problème :(

Je serais ravi de recevoir des conseils. Merci d'avance.

Answer 1

Vous devez utiliser des volumes locaux. Suivez le lien ci-dessous pour comprendre comment créer une classe de stockage, des PV et des PVC lorsque vous utilisez des volumes locaux.

https://kubernetes.io/blog/2019/04/04/kubernetes-1.14-local-persistent-volumes-ga/

Answer 2

Je vous recommande de commencer le dépannage en passant en revue les événements VolumeAttachment par rapport au nœud auquel le PV est attaché, peut-être que votre volume est encore lié à un nœud qui était dans un état d'éviction et a été remplacé par un nouveau.

Vous pouvez utiliser cette commande pour vérifier le nom et l'état de votre PV:

kubectl get pv

Ensuite, pour vérifier quel nœud a le volumeattachment correct, vous pouvez utiliser la commande suivante:

kubectl get volumeattachment

Une fois que vous avez le nom de votre PV et à quel nœud il est attaché, vous pourrez voir si le PV est attaché au bon nœud ou s'il est peut-être attaché à un nœud précédent qui ne fonctionne pas ou a été supprimé. Le nœud est évacué et planifié sur un nouveau nœud disponible dans le pool; pour savoir quels nœuds sont prêts et opérationnels, vous pouvez utiliser cette commande:

kubectl get nodes

Si vous constatez que votre PV est attaché au nœud qui n'existe plus, vous devrez supprimer le VolumeAttachment avec la commande suivante:

kubectl delete volumeattachment [csi-volumeattachment_name] 

Si vous avez besoin de consulter un guide détaillé pour ce dépannage, vous pouvez suivre ce lien.