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 balanceados 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.

¿Qué sigue?