Soluciona problemas de contención de recursos

En esta página, se describe cómo identificar y solucionar problemas de contención de recursos en tu entorno de GKE on VMware.

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.

Descripción general

A veces, tu GKE en VMware puede experimentar una contención de recursos, lo que provoca que tus contenedores se ralenticen, tengan un rendimiento inferior o se cierren. Esto puede ocurrir debido al alto consumo de memoria o CPU por parte de los contenedores.

Cómo funciona la administración de memoria y CPU

  • CPU:

    • Un Pod se programa en un nodo en función de las solicitudes de CPU especificadas por los contenedores en el Pod.
    • Un contenedor de un Pod no puede usar más CPU que el límite especificado por el contenedor
    • El uso de CPU del contenedor se limita según el límite de CPU.
    • Si se limita el uso de la CPU a nivel del nodo, a los contenedores se les asignan automáticamente los ciclos de CPU proporcionales a las solicitudes.

    Obtén más información sobre cómo se programan los Pods con solicitudes de recursos.

  • Memoria:

    • Un Pod se programa en un nodo en función de las solicitudes de memoria que especifican los contenedores del Pod.
    • Un contenedor no puede usar más memoria que el límite que especifica el contenedor.
    • Si no se especifica un límite de memoria, un contenedor puede consumir toda la memoria disponible de un nodo. Luego, el sistema podría activar el OOM-Killer (Out Of Memory Killer) y expulsar los Pods de baja prioridad.

Para obtener más información, consulta Asigna recursos de CPU, Asigna recursos de memoria en Kubernetes y Métricas de GKE Enterprise.

Problemas

El contenedor se vuelve lento

Los problemas de contención de CPU pueden hacer que los contenedores se vuelvan lentos. A continuación, se indican algunos de los motivos posibles:

Uso elevado de CPU en el contenedor:

Un contenedor puede volverse lento si no obtiene ciclos de CPU proporcionales a las solicitudes de CPU o si las solicitudes de CPU se configuraron en un valor demasiado bajo de lo que necesita el contenedor. Por lo tanto, verifica la proporción entre el límite de CPU y el uso de CPU del contenedor.

En la consola de Google Cloud > Supervisión > Explorador de métricas, en el editor de MQL, ejecuta la siguiente consulta:

  fetch k8s_container
  | metric 'kubernetes.io/anthos/container/cpu/limit_utilization'
  | group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]
  | filter resource.cluster_name == 'CLUSTER_NAME'
  | filter resource.container_name == 'CONTAINER_NAME'
  | filter resource.pod_name == 'POD_NAME'
  | filter resource.namespace_name == 'NAMESPACE_NAME'
  | every 1m

A continuación, realiza una de las siguientes acciones:

Uso alto de CPU en el nodo

Si la proporción entre el límite de CPU y el uso no es alta para ningún contenedor individual del Pod, es posible que el nodo no tenga suficientes ciclos de CPU para asignar al conjunto de contenedores que se ejecutan en él. Por lo tanto, sigue estos pasos para comprobar la proporción entre el uso real de CPU y las CPU asignables en el nodo:

  1. Obtén el nodo del Pod que funciona con lentitud:

    kubectl get pod –kubeconfig CLUSTER_KUBECONFIG --namespace NAMESPACE POD --output wide

  2. En la consola de Google Cloud > Supervisión > Explorador de métricas, en el editor de MQL, ejecuta la siguiente consulta:

    fetch k8s_node
| metric 'kubernetes.io/anthos/node/cpu/allocatable_utilization'
| group_by 1m,
    [value_allocatable_utilization_mean: mean(value.allocatable_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.node_name == 'NODE_NAME'
| every 1m

    Si esta proporción es alta (>=0.8), significa que el nodo no tiene suficientes ciclos de CPU y está suscrito en exceso. Por lo tanto, sigue estos pasos para verificar el uso de CPU de todos los demás Pods en ese nodo y, luego, investiga si hay otro contenedor que use más CPU.

    1. Obtén todos los Pods del nodo:
    kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME
    1. Verifica el uso de CPU en cada contenedor:
    fetch k8s_container
| metric 'kubernetes.io/anthos/container/cpu/limit_utilization'
| group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.container_name == 'CONTAINER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| every 1m

    Si hay otro contenedor que usa una capacidad de CPU alta en el nodo, aumenta las solicitudes de CPU y los límites en el contenedor que funciona con lentitud. De esta manera, se recreará el Pod en otro nodo para obtener los ciclos de CPU requeridos.

Si el Pod del sistema funciona lento, comunícate con el equipo de Atención al cliente de Google.

Sobresuscripción de CPU a nivel de vSphere

Si el consumo de CPU no es alto en el nodo o en el Pod, y el contenedor aún es lento, es posible que la VM esté suscrita de más en el nivel de vSphere. Por lo tanto, el nodo no puede obtener los ciclos de CPU esperados de la virtualización subyacente.

Sigue estos pasos para verificar si la VM está demasiado suscrita. Si se detecta un exceso de suscripciones, prueba lo siguiente:

  • Traslada algunas VMs a otros hosts.
  • Evaluar y disminuir la cantidad de CPU virtuales por VM para el host
  • Asigna más recursos a las VMs de GKE Enterprise.
  • Aumenta las solicitudes de CPU y los límites del contenedor. De esta manera, se recreará el Pod en otro nodo para obtener los ciclos de CPU requeridos.

Se elimina el OOM del Pod (se desactiva la memoria).

Los Pods pueden obtener OOMKilled debido a las fugas de memoria o a la mala configuración de las solicitudes de memoria y los límites en los contenedores. A continuación, se indican algunos de los motivos posibles:

Uso elevado de memoria en el contenedor

Un Pod puede inhabilitarse si algún contenedor del Pod consume demasiado la memoria asignada total. Por lo tanto, verifica la proporción entre las solicitudes de memoria y los límites de memoria del contenedor.

En la consola de Google Cloud > Supervisión > Explorador de métricas, en el editor de MQL, ejecuta la siguiente consulta:

fetch k8s_container
| metric 'kubernetes.io/anthos/container/memory/limit_utilization'
| filter (metric.memory_type == 'non-evictable')
| group_by 1m, [value_limit_utilization_mean: mean(value.limit_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.container_name == 'CONTAINER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| every 1m

A continuación, realiza una de las siguientes acciones:

Uso elevado de memoria en el nodo

Un Pod puede perderse si el uso de memoria de todos los Pods que se ejecutan en el nodo supera la memoria disponible. Por lo tanto, verifica si la condición MemoryPressure del nodo es True.

  1. Ejecuta el siguiente comando y, luego, inspecciona la sección Conditions:

    kubectl describe nodes --kubeconfig CLUSTER_KUBECONFIG NODE-NAME

  2. Si la condición MemoryPressure es True, verifica el uso de memoria en el nodo:

    fetch k8s_node
| metric 'kubernetes.io/anthos/node/memory/allocatable_utilization'
| filter (metric.memory_type == 'non-evictable')
| group_by 1m,
    [value_allocatable_utilization_mean: mean(value.allocatable_utilization)]
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.node_name = 'NODE_NAME'
| every 1m

    Si esta proporción es alta (>= 0.8), significa que el nodo no tiene suficiente memoria para asignar al Pod, posiblemente debido a que algunos procesos o algún otro Pod consumen mucha memoria.

  3. En la consola de Google Cloud > Supervisión > Explorador de métricas, en el editor de MQL, ejecuta la siguiente consulta para verificar el uso de memoria de los contenedores en el nodo:

    fetch k8s_node
| metric 'kubernetes.io/anthos/container_memory_usage_bytes'
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.node_name == 'NODE_NAME'
| group_by 1m,
    [value_container_memory_usage_bytes_mean:
      mean(value.container_memory_usage_bytes)]
| every 1m

    Si hay un contenedor que usa memoria alta, investiga su funcionamiento o aumenta la solicitud de memoria del contenedor, si es necesario.

Si se trata de un Pod del sistema que consume mucha memoria, comunícate con el equipo de Atención al cliente de Google.

Además, puedes habilitar la función de ajuste de escala automático en GKE en VMware para aumentar o reducir la escala verticalmente de forma automática de los grupos de nodos según las demandas de tus cargas de trabajo.

Obtén información sobre cómo habilitar el escalador automático.

Problemas con etcd

A veces, tus clústeres de Anthos alojados en VMware pueden experimentar fallas de contenedor debido a los problemas del servidor etcd, y es posible que observes lo siguiente:

  • Registros repetidos del servidor de la API con el siguiente formato:

    etcdserver: request timed out y etcdserver: leader changed

  • Registros de etcd repetidos con el formato:

    W | wal: sync duration of 2.466870869s, expected less than 1s y W | etcdserver: read-only range request * took too long

A continuación, se indican algunos de los motivos posibles:

Limitación de la CPU

El servidor de etcd puede ser lento debido a la limitación de la CPU en el Pod del servidor de etcd o en el nodo en el que se ejecuta el servidor de etcd. Consulta los pasos en la sección El contenedor se vuelve lento para verificar cualquier problema de contención de la CPU.

Si detectas la contención de la CPU en el Pod del servidor ectd o en el nodo, agrega las CPU al nodo del plano de control del clúster de usuario. Usa gkectl update para editar el campo cpus en el archivo de configuración del clúster de usuario.

OOM del Pod de Etcd

El Pod de etcd podría inhabilitarse debido a problemas de contención de recursos. Consulta los pasos de la sección El Pod se elimina (sin memoria) para verificar si hay problemas de contención de memoria con el Pod del servidor de etcd o con el nodo en el que se ejecuta el servidor de etcd.

Si detectas OOMkills para el Pod de etcd, aumenta la memoria disponible para el nodo del plano de control del clúster de usuario. Usa gkectl update para editar el campo memoryMB en el archivo de configuración del clúster de usuario.

Lentitud del disco

Si no hay problemas con el consumo de CPU o memoria en el nodo o el Pod del servidor de etcd, el etcd puede ser lento si el almacén de datos subyacente es lento o limitado.

Verifica los siguientes problemas:

  • Para verificar si el servidor de etcd tarda demasiado en leer o escribir en el disco subyacente, sigue estos pasos:

    1. Obtén los registros de etcd:

      kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n ETCD_POD_NAMESPACE ETCD_POD

    2. Busca las entradas del siguiente patrón para detectar si etcd tarda demasiado en leer desde el disco:

      W | etcdserver: read-only range request "key:\"/registry/configmaps/default/clusterapi-vsphere-controller-manager-leader-election\" " with result "range_response_count:1 size:685" took too long (6.893127339s) to execute

    3. Busca las entradas del siguiente patrón para detectar si etcd tarda demasiado en escribir en el disco:

      W | wal: sync duration of 2.466870869s, expected less than 1s

    Si alguno de los patrones de registro anteriores o ambos se muestran con frecuencia en los registros de etcd, esto indica que el disco es lentitud. Luego, verifica el rendimiento del almacén de datos y de los discos.

  • Para verificar las métricas de etcd, haz lo siguiente:

    1. Recupera las latencias de sincronización de WAL de etcd:

      En la consola de Google Cloud > Supervisión > Explorador de métricas, en el editor de MQL, ejecuta la siguiente consulta:

      fetch k8s_container::kubernetes.io/anthos/etcd_disk_wal_fsync_duration_seconds
| every 1m
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| percentile 99

    2. Recupera las latencias de escritura de etcd:

      En la consola de Google Cloud > Supervisión > Explorador de métricas, en el editor de MQL, ejecuta la siguiente consulta:

      fetch k8s_container::kubernetes.io/anthos/etcd_disk_backend_commit_duration_seconds
| every 1m
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.pod_name == 'POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| percentile 99

    Si p99 para etcd_disk_wal_fsync_duration_seconds supera continuamente 10 ms o si p99 para etcd_disk_backend_commit_duration_seconds supera continuamente 25 ms, significa que el disco es lento. Luego, verifica el rendimiento del almacén de datos y de los discos.

Latencias de lectura/escritura en el disco de la VM

Sigue estos pasos para verificar las latencias de lectura/escritura en el disco virtual de la VM

  1. Identifica el nodo del Pod de etcd lento:

    kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods -n ETCD_POD_NAMESPACE ETCD_POD -owide

  2. Accede a vSphere y selecciona la VM identificada en el paso anterior. En vSphere, ve a Monitor > Performance > Advanced y selecciona Virtual Disk en la sección View para identificar las latencias de lectura y escritura de los discos virtuales.

    Si la latencia de lectura o escritura del disco virtual es alta, haz lo siguiente:

    • Examina otras VMs que se ejecuten en el almacén de datos para verificar el alto uso de operaciones de entrada y salida por segundo (IOPS). Si alguna VM tiene aumentos repentinos en las IOPS, evalúa su funcionamiento.
    • Consulte con su equipo de laboratorio o infraestructura para asegurarse de que el ancho de banda de lectura y escritura no esté limitado ni limitado en ningún momento.
    • Consulta al equipo de laboratorio o de infraestructura para identificar los problemas de rendimiento del disco y rendimiento del almacenamiento, si corresponde.

Si deseas obtener más información, consulta las prácticas recomendadas para escalar tus recursos.

Problemas con el servidor de la API

Si los contenedores de tu GKE en VMware experimentan latencia mientras se comunican con el servidor de la API, o los comandos de Kubectl fallan o tardan demasiado en responder, esto podría indicar que hay problemas con el servidor de la API.

A continuación, se indican algunos de los motivos posibles:

Gran volumen de solicitudes a la API

Es posible que el servidor de la API responda lento si la frecuencia y el volumen de las solicitudes que recibe son demasiado altos. El tiempo de respuesta lento puede persistir incluso después de que el servidor de la API comienza a limitar las solicitudes. Así que verifica la tasa de solicitudes a la API en el servidor de la API.

En la consola de Google Cloud > Supervisión > Explorador de métricas, en el editor de MQL, ejecuta la siguiente consulta:

fetch k8s_container::kubernetes.io/anthos/apiserver_request_total
| filter resource.cluster_name == 'CLUSTER_NAME'
| filter resource.pod_name == 'APISERVER_POD_NAME'
| filter resource.namespace_name == 'NAMESPACE_NAME'
| align rate(1m)
| every 1m
| group_by [metric.verb]

Si hay un aumento inesperado en las solicitudes a la API, usa Cloud Audit Logging para identificar el Pod que podría estar consultando al servidor de la API con demasiada frecuencia.

  • Si se trata de un Pod del sistema, comunícate con el equipo de Atención al cliente de Google.
  • Si se trata de un Pod de usuario, investiga más a fondo para determinar si se esperan las solicitudes a la API.

Limitación de la CPU

Una tasa alta de solicitudes en el servidor de la API puede provocar la limitación de la CPU. Entonces, el servidor de la API podría volverse lento debido a la contención de la CPU en el Pod del servidor de la API o en el nodo.

Consulta la sección El contenedor se vuelve lento para verificar cualquier problema de contención de la CPU con el Pod o el nodo.

Pod del servidor de la API finalizado en OOM

El Pod del servidor de la API podría finalizarse en OOM debido a problemas de contención de recursos. Consulta los pasos en la sección El Pod se elimina (sin memoria) para verificar si hay problemas de contención de memoria con el Pod o el nodo.

Respuestas lentas de etcd

El servidor de la API depende de la comunicación con el clúster de etcd para entregar solicitudes de lectura y escritura a los clientes. Si el etcd es lento o no responde, el servidor de la API también se vuelve lento.

Recupera los registros del servidor de la API para verificar si el servidor de la API es lento debido a los problemas de etcd:

kubectl –kubeconfig ADMIN_CLUSTER_KUBECONFIG logs -n APISERVER_NAMESPACE APISERVER_POD_NAME

Si observas registros recurrentes, como etcdserver: request timedout o etcdserver: leader changed, sigue los pasos que se indican en Problemas de Etcd para resolver cualquier problema relacionado con los discos.

¿Qué sigue?

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.