Si ha trabajado con versiones recientes de IBM Maximo Application Suite (MAS), es posible que haya encontrado un problema en el que el pod admin-build-config entra repetidamente en un estado Evicted .

A primera vista, todo parece correcto. La utilización de la CPU es baja, el uso de la memoria parece razonable y el almacenamiento persistente tiene mucha capacidad disponible. Sin embargo, el pod sigue fallando y reiniciándose, impidiendo que el entorno MAS se construya.

Recientemente, he notado que este problema se ha vuelto más común en las versiones más recientes de MAS, y en muchos casos la causa raíz no es la CPU, la memoria o el almacenamiento persistente en absoluto.

Es el almacenamiento efímero.

Comprendiendo el almacenamiento efímero

A diferencia de los volúmenes persistentes, el almacenamiento efímero existe solo durante la vida útil del pod. Dado que reside en el propio nodo de trabajo, Kubernetes monitorea de cerca el consumo y puede desalojar pods cuando se superan los límites configurados.

Para muchos administradores, el almacenamiento efímero es fácil de pasar por alto porque no suele formar parte de las discusiones rutinarias sobre capacidad. Nos centramos en el tamaño de la CPU, la memoria y los PVC, pero las cargas de trabajo de compilación pueden consumir cantidades significativas de espacio temporal en disco.

Un desencadenante común: Múltiples archivos de personalización

Un patrón que he observado es que este problema ocurre con mayor frecuencia en entornos con varios (o simplemente muy grandes) archivos de personalización configurados para su despliegue.

Durante el proceso de compilación de administración, MAS descarga y extrae cada archivo de personalización antes de añadir el contenido a la compilación. Si bien un solo archivo puede tener un impacto mínimo, múltiples archivos pueden aumentar significativamente el consumo de almacenamiento temporal... ¡y rápidamente!

Lo que sorprende a muchos administradores es que el espacio requerido suele ser mucho mayor que el tamaño combinado de los propios archivos ZIP. Durante la extracción y el procesamiento, se crean y almacenan archivos temporales dentro del almacenamiento efímero del pod. A medida que aumenta el número y el tamaño de los paquetes de personalización, también lo hace el requisito de almacenamiento temporal. El proceso de compilación excede rápidamente el límite de almacenamiento efímero configurado, lo que resulta en la expulsión del pod antes de su finalización.

Síntomas

Cuando el almacenamiento efímero es el problema, Kubernetes es muy explícito al respecto en los mensajes de evento. Si el pod admin-build-config está en estado Evicted, haga clic en la pestaña Events y busque un mensaje como este:
‍

‍

Resolución del problema

Cuando la carga de trabajo de compilación del administrador excede la asignación predeterminada, aumentar la solicitud y el límite de almacenamiento efímero para el Admin Build Config resolverá el problema.
‍

Revise su configuración actual en la manageWorkspace Definición de Recurso Personalizado (CRD). Los valores predeterminados de fábrica (OOTB) se muestran a continuación:
‍

‍

En la de IBM documentación, el manageWorkspace CRD puede supuestamente actualizarse a través de la UI de la consola de OpenShift modificando la sección spec.settings.deployment.ephemeralStorage. Sin embargo, los intentos de actualizar estos valores a través de la UI no tuvieron éxito. La configuración volvía repetidamente a los ajustes predeterminados.
‍

El único método fiable que encontré fue aplicar el cambio usando un comando oc patch:
‍

oc patch manageworkspace a311833-mas -n mas-a311833-manage --type='merge' -p '{"spec":{"settings":{"deployment":{"ephemeralStorage":{"limits":{"adminBuild":"200Gi"},"requests":{"adminBuild":"50Gi"}}}}}}' 

‍
Después de aplicar el parche, permita que el proceso de reconciliación se complete. Una vez finalizada la reconciliación, se creará un nuevo pod de compilación. Abra el YAML del pod admin-build-config y verifique que los valores actualizados de almacenamiento efímero estén presentes. Buscar el término ephemeral en el YAML facilita la confirmación de que los cambios se aplicaron correctamente.
‍