Soluciona problemas de almacenamiento en GKE

Autopilot Estándar

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

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.

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 discos persistentes regionales 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:

Imágenes de Docker.
El sistema de archivos de contenedores que corresponde a lo que no está activado como un volumen (es decir, el sistema de archivos de superposición) 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 es el de un disco de 200 GB. Además, si hay mucha actividad en el PersistentVolume, esto también afecta 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:

Asegúrate de haber consultado las comparaciones de tipo de disco de almacenamiento y elegido un tipo de disco persistente para satisfacer tus necesidades.
Este problema ocurre con frecuencia para los nodos que usan discos persistentes estándar con un tamaño inferior a 200 GB. Considera aumentar el tamaño de tus discos o cambiar a SSD, en especial para los clústeres que se usan en producción.
Considera habilitar un SSD local para el almacenamiento efímero en tus grupos de nodos. Esto es muy efectivo si tienes contenedores que usan volúmenes emptyDir con frecuencia.

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, prueba los siguientes pasos para resolver este problema:

Reduce la cantidad de archivos en el volumen.
Deja de usar la configuración [fsGroup].
Cambia la aplicación fsGroupChangePolicy a OnRootMismatch.

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

Los siguientes errores de ejemplo pueden mostrarse en los registros 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"

Mitigación

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

Corregir

Este problema está solucionado en containerd 1.6.0+. Las versiones de GKE con esta 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. Cambiar un PersistentVolume directamente puede dar como resultado que la expansión del volumen no se produzca. 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.

Para resolver este problema, realiza los siguientes pasos:

Mantén el objeto PersistentVolume modificado como estaba.
Edita el objeto PersistentVolumeClaim y configura spec.resources.requests.storage con un valor superior al que se usó en el PersistentVolume.
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.

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.

¿Qué sigue?