Para resolver la visibilidad limitada en la capa del motor de contenedores, SysOM ofrece monitoreo de contenedores a nivel del kernel del sistema operativo. Esto mejora la observability de los problemas de memoria y facilita la migración de contenedores. Este tema explica cómo utilizar SysOM para diagnosticar problemas de memoria en contenedores, incluido el desglose del conjunto de trabajo más allá de las métricas estándar.
Requisitos previos
Asegúrese de cumplir con lo siguiente:
Un ACK Managed Cluster o un ACK Serverless Cluster creado después de octubre de 2021, que ejecute Kubernetes 1.18.8 o posterior. Si es necesario, actualice manualmente.
Prometheus Service for Alibaba Cloud habilitado.
ack-sysom-monitor feature está habilitado.
Facturación
Cuando se habilita, ack-sysom-monitor envía métricas de monitoreo a Prometheus Service for Alibaba Cloud. Estas métricas se facturan como Custom Metrics y generan costos adicionales.
Consulte la descripción general de facturación de Prometheus Service for Alibaba Cloud antes de habilitar esta función. Los costos dependen del tamaño del clúster y de la cantidad de aplicaciones. Utilice Resource Consumption para monitorear el uso.
Conceptos clave
Componentes de la memoria del contenedor
ACK proporciona monitoreo de contenedores a nivel del kernel del sistema operativo para rastrear con precisión el uso de memoria y prevenir problemas de OOM.
La memoria del contenedor se divide en tres categorías:
|
Categoría |
Subcategoría |
Descripción |
|
Memoria de aplicación |
Memoria anónima: segmentos de heap, pila y datos de un proceso, asignados mediante las llamadas al sistema |
Memoria utilizada por la aplicación en ejecución |
|
Caché de archivos: datos almacenados en caché para E/S de archivos. La caché de acceso frecuente ( |
||
|
Buffers: metadatos para dispositivos de bloque o sistemas de archivos |
||
|
HugeTLB: memoria asignada mediante HugePages |
||
|
Memoria del kernel |
Slab: pool de memoria para cachés de objetos del kernel |
Memoria utilizada por el kernel del sistema operativo |
|
Vmalloc: asigna bloques grandes de memoria virtual |
||
|
allocpage: asigna memoria local |
||
|
Otros: pila del kernel, tabla de páginas y memoria reservada |
||
|
Memoria libre |
— |
Memoria disponible y sin usar |
Conjunto de trabajo frente a RSS
Kubernetes rastrea dos métricas de memoria clave:
Conjunto de trabajo (Working set): memoria que un contenedor utiliza activamente:
working set = inactive_anon + active_anon + active_file. El OOM killer y Kubernetes usan este valor para decidir si desalojan o finalizan un contenedor.RSS (resident set size): memoria física mapeada en el espacio de direcciones del contenedor, excluyendo la caché de archivos. El RSS refleja la memoria real de la aplicación, pero excluye la memoria en caché que Kubernetes contabiliza dentro del límite.
Dado que Kubernetes utiliza el conjunto de trabajo para las decisiones de desalojo, la caché de archivos puede inflarlo silenciosamente y desencadenar terminaciones por OOM incluso cuando la memoria de la aplicación es estable. SysOM desglosa el conjunto de trabajo en sus componentes para identificar qué tipo de memoria causa el problema.
Funcionamiento
SysOM muestra métricas a nivel del kernel del sistema operativo en los paneles de Prometheus Monitoring dentro de la consola de ACK. Organiza la memoria del pod en componentes del conjunto de trabajo para rastrear el alto uso hasta tipos específicos de memoria.
Utilice estas fórmulas al diagnosticar problemas de memoria:
Total pod memory = RSS + Cache ≈ inactive_anon + active_anon + inactive_file + active_fileworking set = inactive_anon + active_anon + active_file
Localización y corrección de problemas de memoria en contenedores
Paso 1: Abrir el panel de SysOM
Inicie sesión en la ACK console. En el panel de navegación izquierdo, haga clic en Clusters.
En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, haga clic en Operations > Prometheus Monitoring.
En la página Prometheus Monitoring, haga clic en la pestaña SysOM y luego en SysOM - Pods.
Paso 2: Identificar el agujero negro de memoria
-
En la sección Pod Memory Monitor, aplique la fórmula de memoria total del pod para desglosar la memoria en caché y RSS. Revise las proporciones de caché (
active_file,inactive_file,shmem) y RSS (active_anon,inactive_anon). En este ejemplo,inactive_anonpredomina.
-
En la sección Pod Resource Analysis, utilice la clasificación superior para identificar el pod con mayor consumo de InactiveAnon. En este ejemplo, arms-prom tiene el consumo más alto.
-
En la sección Pod Memory Details, consulte la composición de memoria del pod identificado. Los componentes incluyen Pod Cache, InactiveFile (caché de archivos inactiva), InactiveAnon (memoria anónima inactiva) y memoria sucia (modificaciones no escritas). Utilice estos desgloses para localizar con precisión el agujero negro de memoria.
Paso 3: Investigar el uso de la caché de archivos
En la sección Pod File Cache, identifique qué impulsa el alto consumo de memoria en caché.
La caché de archivos no recuperable infla el conjunto de trabajo y se convierte en un agujero negro de memoria. Este se contabiliza dentro del límite de memoria del pod y puede desencadenar desalojos o terminaciones por OOM sin que aumente la memoria de la aplicación.
Paso 4: Corregir el agujero negro de memoria
Una vez identificado el agujero negro de memoria, resuélvalo mediante la programación detallada de ACK. Consulte Enable container memory QoS.
Siguientes pasos
Para consultar todas las métricas de SysOM, véase SysOM kernel-level container monitoring.
Para conocer las capacidades del kernel detrás de la QoS de memoria de ACK, consulte Overview of kernel features and interfaces.