Soluciona problemas de almacenamiento en GKE

En esta página, se muestra cómo resolver problemas con volúmenes implementados en tus clústeres de Google Kubernetes Engine (GKE).

Error 400: No se puede adjuntar RePD a una VM optimizada

Los discos persistentes regionales están restringidos para que no se usen con máquinas con optimización de memoria o máquinas optimizadas para procesamiento.

Considera usar una clase de almacenamiento de disco persistente no regional si el uso de un disco persistente regional no es un requisito difícil. Si usar un disco persistente regional es un requisito difícil, considera programar estrategias, como taints y tolerancias, para asegurarte de que los pods que necesitan PD regional se programen en un grupo de nodos que no sean máquinas optimizadas.

Soluciona problemas con el rendimiento del disco

El rendimiento del disco de arranque es importante porque el disco de arranque de los nodos de GKE no solo se usa para el sistema operativo, sino también para lo siguiente:

  • docker images
  • El sistema de archivos del contenedor para lo que no está activado como un volumen (es decir, el sistema de archivos superpuesto) y, a menudo, incluye directorios como /tmp.
  • Los volúmenes emptyDir respaldados por discos, a menos que el nodo use SSD locales.

El rendimiento del disco se comparte para todos los discos del mismo tipo de disco en un nodo. Por ejemplo, si tienes un disco de arranque pd-standard de 100 GB y un PersistentVolume pd-standard de 100 GB con mucha actividad, el rendimiento del disco de arranque será el de un disco de 200 GB. Además, si hay mucha actividad en el PersistentVolume, esto también afectará el rendimiento del disco de arranque.

Si encuentras mensajes similares a los siguientes en tus nodos, estos podrían ser síntomas de bajo rendimiento de disco:

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

Para resolver estos problemas, revisa lo siguiente:

Activar un volumen deja de responder debido a la configuración de fsGroup

Un problema que puede hacer que la activación de PersistentVolume falle es un Pod que se configura con la configuración fsGroup. Por lo general, las activaciones se reintentan automáticamente y la falla de activación se resuelve a sí misma. Sin embargo, si PersistentVolume tiene una gran cantidad de archivos, kubelet intentará cambiar la propiedad en cada archivo del sistema de archivos, lo que puede aumentar la latencia de activación de volumen.

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

Para confirmar si un error de activación con errores se debe a la configuración fsGroup, puedes verificar los registros del Pod. Si el problema está relacionado con la configuración fsGroup, verás la siguiente entrada de registro:

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 no se activa en unos minutos, intenta lo siguiente para resolver este problema:

Las operaciones de discos lentos provocan fallas en la creación de Pods

Para obtener más información, consulta el problema #4604 de containerd.

Versiones de nodos de GKE afectados: de 1.18, 1.19, 1.20.0 a 1.20.15-gke.2100, de 1.21.0 a 1.21.9-gke.2000, de 1.21.10 a 1.21.10-gke.100, de 1.22.0 a 1.22.6-gke.2000, de 1.22.7 a 1.22.7-gke.100, de 1.23.0 a 1.23.3-gke.700, de 1.23.4 a 1.23.4-gke.100

Síntoma y diagnóstico

Ejemplo de error en los registros del entorno de ejecución del contenedor de 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"

Mitigación

  1. Si los Pods fallan, considera usar restartPolicy:Always o restartPolicy:OnFailure en tu PodSpec.
  2. Aumenta las IOPS del disco de arranque (por ejemplo, actualiza el tipo de disco o aumenta el tamaño del disco).

Corregir

Este problema se solucionó en containerd 1.6.0+, y las versiones de GKE que incluyen la corrección son 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+ y 1.23.4-gke.100+

Los cambios de expansión de volumen no se reflejan en el sistema de archivos del contenedor

Cuando realices la expansión de volumen, siempre asegúrate de actualizar PersistentVolumeClaim. Si cambias un PersistentVolume directamente, es posible que no se expanda el volumen. Esto podría generar una de las siguientes situaciones:

  • Si se modifica un objeto PersistentVolume directamente, los valores de PersistentVolume y PersistentVolumeClaim se actualizan a un valor nuevo, pero el tamaño del sistema de archivos no se refleja en el contenedor y aún usa el tamaño del volumen anterior.

  • Si se modifica un objeto PersistentVolume de forma directa, seguido de actualizaciones en la PersistentVolumeClaim donde el campo status.capacity se actualiza a un nuevo tamaño, se pueden generar cambios en el PersistentVolume, pero no en el PersistentVolumeClaim o el sistema de archivos del contenedor.

Mitigación

  1. Mantén el objeto PersistentVolume modificado como estaba.
  2. Edita el objeto PersistentVolumeClaim y configura spec.resources.requests.storage con un valor superior al que se usó en el PersistentVolume.
  3. Verifica si se cambió el tamaño del PersistentVolume al valor nuevo.

Luego de estos cambios, kubelet debe cambiar el tamaño de PersistentVolume, PersistentVolumeClaim y el sistema de archivos de contenedor de forma automática.

  • Verifica si los cambios se reflejan en el Pod.
   kubectl exec POD_NAME  -- /bin/bash -c "df -h"

Reemplaza POD_NAME con el Pod adjunto a PersistentVolumeClaim.

El tipo de máquina seleccionado debe tener discos SSD locales.

Puedes encontrar el siguiente error cuando creas un clúster o un grupo de nodos que usa 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.

En el mensaje de error, es posible que veas LocalNvmeSsdBlockConfig en lugar de EphemeralStorageLocalSsdConfig, según lo que hayas especificado.

Este error se produce cuando la cantidad de discos SSD locales especificada no coincide con la cantidad de discos SSD locales incluidos en el tipo de máquina.

Mitigación

Para resolver este problema, especifica una cantidad de discos SSD locales que coincida con el tipo de máquina que deseas. Para la serie de máquinas de tercera generación, debes omitir la marca count de SSD local y el valor correcto se configurará automáticamente.