Soluciona problemas de almacenamiento en GKE

Los problemas con el almacenamiento en los clústeres de Google Kubernetes Engine (GKE) pueden manifestarse de varias maneras, desde cuellos de botella en el rendimiento y fallas en el montaje de volúmenes hasta errores cuando se usan tipos de discos específicos con ciertos tipos de máquinas. Estos problemas pueden afectar la conservación del estado de la aplicación, la persistencia de los datos y el estado general de la carga de trabajo.

Usa este documento para resolver problemas comunes que afectan la funcionalidad de almacenamiento en tus clústeres. Encuentra orientación para solucionar problemas relacionados con el aprovisionamiento y la conexión de volúmenes, el acceso y el rendimiento de los datos, y la administración de la capacidad de almacenamiento.

Esta información es importante tanto para los administradores y operadores de la plataforma que administran la infraestructura y el almacenamiento del clúster como para los desarrolladores de aplicaciones cuyas cargas de trabajo dependen del almacenamiento persistente. Para obtener más información sobre los roles comunes y las tareas de ejemplo a los que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas comunes de los usuarios de 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 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:

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:

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

  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 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:

  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.

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.

Grupos de almacenamiento de Hyperdisk: Falla la creación del clúster o del grupo de nodos

Es posible que encuentres el error ZONE_RESOURCE_POOL_EXHAUSTED o errores de recursos de Compute Engine similares cuando intentes aprovisionar discos Hyperdisk Balanced como discos de arranque o adjuntos de tu nodo en un grupo de almacenamiento de Hyperdisk.

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

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

Para solucionar este problema, sigue estos pasos:

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

Se detectó una presión alta de almacenamiento del nodo

Si observas eventos o condiciones del nodo relacionados con StoragePressureRootFileSystem con el motivo StoragePressureDetected, esto indica que el sistema de archivos raíz del nodo o un punto de activación de almacenamiento crítico está experimentando un uso elevado del disco, que se acerca a su capacidad.

Cuando describas un nodo con el comando kubectl describe node NODE_NAME, es posible que veas un evento similar a este:

Events:
  Type     Reason                      Age   From                     Message
  ----     ------                      ----  ----                     -------
  ...
  Warning  StoragePressureDetected     46m   device-capacity-monitor  Node condition StoragePressureRootFileSystem is now: True, reason: StoragePressureDetected, message: "Disk /dev/nvme0n1 usage 89% exceeds threshold 85%"

Causa:

El motivo StoragePressureDetected significa que el uso del disco en el sistema de archivos raíz del nodo (a menudo, mnt/stateful_partition o unidades relacionadas) superó un umbral predefinido (por ejemplo, el 85%). Esto puede deberse a lo siguiente:

  • Cargas de trabajo que escriben datos excesivos en volúmenes emptyDir que no están respaldados por SSDs locales.
  • Se están extrayendo imágenes de contenedor grandes al nodo.
  • Archivos de registro que se acumulan en el nodo
  • Otros procesos que consumen espacio en disco

El uso continuo y elevado del disco puede provocar inestabilidad en los nodos, desalojos de Pods y fallas en las aplicaciones.

Depuración y resolución:

Identifica el uso del disco: Usa SSH para conectarte al nodo afectado y usa comandos como df -h para verificar el uso del disco en varios puntos de montaje, prestando especial atención a /mnt/stateful_partition y a cualquier montaje de almacenamiento efímero.

Analiza los patrones de almacenamiento de la carga de trabajo: Revisa las solicitudes de almacenamiento y los patrones de uso de los Pods que se ejecutan en el nodo. Identifica si alguna carga de trabajo específica consume una cantidad desproporcionada de almacenamiento efímero.

Aumenta la capacidad de almacenamiento de los nodos: Ten en cuenta que la resolución principal suele ser garantizar que tus nodos tengan la capacidad de almacenamiento adecuada para tus cargas de trabajo. Ten en cuenta lo siguiente:

  • Usa discos de arranque más grandes: Cuando crees grupos de nodos, selecciona un tamaño de disco de arranque más grande si tus cargas de trabajo requieren más almacenamiento efímero en el sistema de archivos raíz.
  • Utiliza SSD locales más grandes para el almacenamiento efímero: Para las cargas de trabajo que requieren almacenamiento efímero de alto rendimiento y baja latencia, configura tus grupos de nodos para que usen SSD locales. Esto proporciona una capacidad separada y mayor para los volúmenes de emptyDir.
  • Ajusta las solicitudes o los límites de la carga de trabajo: Asegúrate de que las especificaciones de tu Pod incluyan solicitudes y límites de almacenamiento efímero adecuados para ayudar al programador a colocar los Pods en nodos con espacio suficiente y evitar el uso descontrolado del disco.
  • Limpia los recursos no utilizados: Quita los archivos innecesarios, las imágenes de contenedor antiguas o los registros del nodo si contribuyen al alto uso del disco.

Si abordas la capacidad y el uso de almacenamiento en el nodo, puedes mitigar los problemas relacionados con StoragePressureDetected y ayudar a la operación del nodo.

¿Qué sigue?