Trident: El complemento Trident CSI Node no está registrado después de actualizar la versión de Kubernetes

Describa el error

El complemento Trident CSI Node ( csi.trident.netapp.io ) en un nodo ahora no está registrado después de que la versión de Kubernetes se actualizó de v1.18.9 a v1.19.4. Los pods en este nodo ya no pueden montar y desmontar volúmenes Trident.

Error de mensajes

Vemos los siguientes mensajes en el registro de kubelet.

Se anuló el registro csi.trident.netapp.io porque se eliminó el socket de registro ( /var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock ).

I1119 05:47:54.246972 6550 plugin_watcher.go:212] Eliminando la ruta del socket /var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock del caché de estado deseado
I1119 05:47:53.162305 6550 reconciler.go:139] operationExecutor.UnregisterPlugin iniciado para el complemento en "/var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock" (detalles del complemento: &{/var /lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock 2020-11-04 05:08:19.553684094 +0000 UTC m=+38.893901704 0x704c200 csi.trident.netapp.io})
I1119 05:47:53.163390 6550 csi_plugin.go:177] kubernetes.io/csi: registrationHandler.DeRegisterPlugin solicitud de complemento csi.trident.netapp.io

El pod no pudo desmontar el volumen porque no se encontró csi.trident.netapp.io .

E1119 09:02:52.819122 6550 nestedpendingoperations.go:301] Operación para "{v olumeName:kubernetes.io/csi/csi.trident.netapp.io ^pvc-75a6fd7f-7aee-45e8-a5fa-d4500272528e podName:ad18a7d1-4090 -4e0c-9e71-cba46dfc3657 nodeName:}" falló. No se permiten reintentos hasta el 2020-11-19 09:04:54.819071328 +0000 UTC m=+1310234.159288938 (durationBeforeRetry 2m2s). Error: "UnmountVolume.TearDown falló para el volumen "datos" (UniqueName: "kubernetes.io/csi/csi.trident.netapp.io^pvc-75a6fd7f-7aee-45e8-a5fa-d4500272528e") pod "ad18a7d1-4090-4e0c -9e71-cba46dfc3657" (UID: "ad18a7d1-4090-4e0c-9e71-cba46dfc3657"): kubernetes.io/csi: mounter.SetUpAt no pudo obtener el cliente CSI: el nombre del controlador csi.trident.netapp.io no se encuentra en la lista de controladores CSI registrados"

Dos trident-csi estaban funcionando simultáneamente

Descubrimos que dos pods trident-csi (Complemento de nodo) en este nodo se estaban ejecutando simultáneamente durante un tiempo muy breve y que el antiguo driver-registrar se había detenido después de que se iniciara uno nuevo.

driver-registrar elimina el socket de registro ( /var/lib/kubelet/plugins_registry/csi.trident.netapp.io-reg.sock ) cuando recibe SIGTERM ( node_register.go#L113-L116 ). Al eliminar el zócalo, el kubelet cancela el registro del complemento Trident. Creo que esta es la causa del problema.

DaemonSet fue recreado después de actualizar

Los pods Trident-csi (complemento de nodo) son administrados por DaemonSet. Normalmente, solo se ejecuta un pod en cada nodo. Pero después de la actualización de Kubernetes, trident-operator recreó trident-csi Daemonset. La eliminación de DaemonSet permite que dos pods (antiguo y nuevo) se ejecuten simultáneamente.

Confirmamos esto en el registro trident-operator .

Aquí, se eliminó el trident-csi Daemonset.

time="2020-11-19T05:47:45Z" level=debug msg="Kubernetes DaemonSet eliminado". DaemonSet=trident-csi espacio de nombres=trident

Poco después se creó trident-csi Daemonset.

time="2020-11-19T05:47:45Z" level=debug msg="Creando objeto". kind=DaemonSet name=trident-csi namespace=trident

Después de actualizar Kubernetes, el indicador shouldUpdate se estableció en verdadero ( controller.go#L1110 ). Parece que el indicador shouldUpdate #$9$#$ hace que se elimine el Daemonset trident-csi ( installer.go#L1489-L1494 ).

Ambiente

• Versión Trident: 20.10.0 con operador trident
• Indicadores de instalación Trident utilizados: silenceAutosupport: true (Operador Trident)
• Tiempo de ejecución del contenedor: Docker 19.03.13
• Versión de Kubernetes: v1.19.4
• Orquestador de Kubernetes: Kubernetes
• Puertas de características habilitadas para Kubernetes:
• Sistema operativo: Ubuntu 18.04
• Tipos de back-end de NetApp: ONTAP AFF 9.1P14
• Otro:

Reproducir

La actualización de la versión de Kubernetes puede reproducir este problema. Dado que la actualización de Kubernetes lleva mucho tiempo y no siempre sucede, confirmamos los siguientes comportamientos que causan este problema a través de diferentes demostraciones.

Dos trident-csi hacen que kubelet anule el registro del complemento Trident

1. Confirme que el controlador Trident CSI esté registrado en el nodo.

$ kubectl describe csinodes.storage.k8s.io <NODE_NAME>
...
Spec:
  Drivers:
    csi.trident.netapp.io:
      Node ID:        <NODE_NAME>
      Topology Keys:  [topology.kubernetes.io/zone]

1. Copie trident-csi DaemonSet para ejecutar dos pods trident-csi en cada nodo.

$ kubectl get ds -n trident trident-csi -o json | jq '.metadata.name|="trident-csi-2"' | kubectl apply -f -

1. Espere a que se ejecuten, luego elimine trident-csi-2 DaemonSet copiado.

$ kubectl delete ds -n trident trident-csi-2

1. Confirme que el controlador Trident CSI haya desaparecido en la sección Controladores del nodo. (Esto tomará algún tiempo)

$ kubectl describe csinodes.storage.k8s.io <NODE_NAME>
Spec:

La recreación de DaemonSet permite que dos pods (antiguo y nuevo) se ejecuten simultáneamente

1. Eliminar trident-csi DaemonSet. El DaemonSet será recreado poco después por el operador trident.

$ kubectl delete ds -n trident trident-csi

1. Verá dos trident-csi pods en cada nodo.

$ kubectl get pods -n trident -o wide

Comportamiento esperado
Los pods pueden montar y desmontar volúmenes Trident después de actualizar la versión de Kubernetes.

Contexto adicional
Ninguna