Solucionar problemas de almacenamiento en GKE

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

Error 400: no se puede adjuntar un RePD a una VM optimizada

Los discos persistentes regionales no se pueden usar con máquinas optimizadas para la memoria o para la computación.

Si no es estrictamente necesario usar un disco persistente regional, considera la posibilidad de usar una clase de almacenamiento de disco persistente no regional. Si es imprescindible usar un disco persistente regional, considera la posibilidad de programar estrategias como taints y tolerations para asegurarte de que los pods que necesiten discos persistentes regionales se programen en un grupo de nodos que no sean máquinas optimizadas.

Solucionar problemas de 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 del contenedor de lo que no está montado como volumen (es decir, el sistema de archivos de superposición). A menudo, incluye directorios como /tmp.
  • Volúmenes emptyDir respaldados por disco, a menos que el nodo use SSD local.

El rendimiento del disco se comparte entre todos los discos del mismo tipo de disco de un nodo. Por ejemplo, si tienes un disco de arranque pd-standard de 100 GB y un pd-standard PersistentVolume 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, también se verá afectado el rendimiento del disco de arranque.

Si ves mensajes similares a los siguientes en tus nodos, podría tratarse de síntomas de un rendimiento bajo del 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 solucionar estos problemas, consulta lo siguiente:

El montaje de un volumen deja de responder debido al ajuste fsGroup

Un problema que puede provocar que falle el montaje de PersistentVolume es un pod configurado con el ajuste fsGroup. Normalmente, los montajes se vuelven a intentar automáticamente y el error se resuelve solo. Sin embargo, si el PersistentVolume tiene un gran número de archivos, kubelet intentará cambiar la propiedad de cada archivo del sistema de archivos, lo que puede aumentar la latencia del montaje del volumen.

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

Para confirmar si un error de montaje se debe al ajuste fsGroup, puedes consultar los registros del pod. Si el problema está relacionado con el ajuste 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 el PersistentVolume no se monta en unos minutos, prueba los siguientes pasos para solucionar el problema:

Las operaciones de disco lentas provocan errores en la creación de pods

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

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

Es posible que se muestren los siguientes errores de ejemplo en los registros de 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"

Solució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, cambia el tipo de disco o aumenta su tamaño).

Solucionar

Este problema se ha solucionado en containerd 1.6.0 y versiones posteriores. Las versiones de GKE con esta solució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 en la expansión del volumen no se reflejan en el sistema de archivos del contenedor

Cuando amplíes el volumen, asegúrate siempre de actualizar el PersistentVolumeClaim. Si cambias un PersistentVolume directamente, es posible que el volumen no se amplíe. Esto puede dar lugar a una de las siguientes situaciones:

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

  • Si se modifica directamente un objeto PersistentVolume y, a continuación, se actualiza el PersistentVolumeClaim, donde el campo status.capacity se actualiza a un nuevo tamaño, esto puede provocar cambios en el PersistentVolume, pero no en el PersistentVolumeClaim ni en el sistema de archivos del contenedor.

Para solucionar este problema, siga estos pasos:

  1. Mantén el objeto PersistentVolume modificado tal como estaba.
  2. Edita el objeto PersistentVolumeClaim y asigna a spec.resources.requests.storage un valor superior al que se usó en PersistentVolume.
  3. Verifica si el PersistentVolume se ha redimensionado al nuevo valor.

Después de estos cambios, kubelet debería cambiar automáticamente el tamaño de PersistentVolume, PersistentVolumeClaim y el sistema de archivos del contenedor.

Comprueba si los cambios se reflejan en el pod.

kubectl exec POD_NAME  -- /bin/bash -c "df -h"

Sustituye POD_NAME por el pod asociado a PersistentVolumeClaim.

El tipo de máquina seleccionado debe tener SSDs locales

Puede que se produzca el siguiente error al crear un clúster o un grupo de nodos que utilice 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, puede que veas LocalNvmeSsdBlockConfig en lugar de EphemeralStorageLocalSsdConfig, en función de lo que hayas especificado.

Este error se produce cuando el número de discos SSD locales especificado no coincide con el número de discos SSD locales incluidos en el tipo de máquina.

Para solucionar este problema, especifique un número de discos SSD locales que coincida con el tipo de máquina que quiera. En el caso de las series de máquinas de tercera generación, debe omitir la marca count de SSD local y se configurará el valor correcto automáticamente.

Grupos de almacenamiento de Hyperdisk: no se puede crear un clúster o un grupo de nodos

Es posible que se produzca el error ZONE_RESOURCE_POOL_EXHAUSTED u otros errores de recursos de Compute Engine al intentar aprovisionar discos Hyperdisk Balanced como discos de arranque o conectados de tu nodo en un grupo de almacenamiento de Hyperdisk.

Esto ocurre cuando intentas crear un clúster o un grupo de nodos de GKE en una zona que tiene pocos recursos, por ejemplo:

  • Es posible que la zona no tenga suficientes discos Hyperdisk Balanced disponibles.
  • Es posible que la zona no tenga capacidad suficiente para crear los nodos del tipo de máquina que has especificado, como c3-standard-4.

Para solucionar este problema, sigue estos pasos:

  1. Selecciona una nueva zona de la misma región que tenga capacidad suficiente para el tipo de máquina que has elegido y en la que estén disponibles los grupos de almacenamiento Hyperdisk Balanced.
  2. Elimina el grupo de almacenamiento y vuelve a crearlo en la nueva zona. Esto se debe a que los grupos de almacenamiento son recursos de zona.
  3. Crea el clúster o el grupo de nodos en la nueva zona.

Siguientes pasos