Se usó la API de Cloud Translation para traducir esta página.

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 Google Distributed Cloud.

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

Descripción general

En ocasiones, tu Google Distributed Cloud puede experimentar contención de recursos, lo que hace que tus contenedores se ralenticen, tengan un rendimiento deficiente o se cierren. Esto puede ocurrir debido al alto consumo de CPU o memoria 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 que especifican los contenedores del Pod.
- Un contenedor de un Pod no puede usar más CPU que el límite que especifica el contenedor
- El uso de CPU del contenedor se limita al límite de CPU.
- Si el uso de CPU se limita al 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 en el 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 en un nodo. Luego, el sistema podría activar el optimizador de OOM (Eliminador de memoria insuficiente) 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.

Con problemas

El contenedor se vuelve lento

Los problemas de contención de CPU pueden hacer que los contenedores se vuelvan lentos. Estos son algunos de los posibles motivos:

Alto uso 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 con un valor demasiado bajo de lo que el contenedor necesita. Así que 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:

Si esta proporción es alta (>=0.8), significa que el límite de CPU del contenedor es bajo y que Kubernetes limita los ciclos de CPU del contenedor para mantener el uso de CPU dentro del límite. Para resolver este problema, aumenta el límite de CPU del contenedor.
Si esta proporción no es alta (<0.8), verifica si el uso de CPU es alto en el nodo.

Uso de CPU alto 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 asignarse al conjunto de contenedores que se ejecutan en él. Por lo tanto, sigue estos pasos para verificar la proporción entre el uso de CPU real y las CPU asignables en el nodo:

Obtén el nodo del Pod que está funcionando lento:

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

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á demasiado suscrito. Por lo tanto, sigue estos pasos para verificar el uso de CPU de todos los otros Pods de ese nodo y, luego, investiga si hay otro contenedor que usa más CPU.

Obtén todos los Pods del nodo:

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

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 y los límites de CPU del contenedor que está funcionando lento. Esto recreará el Pod en otro nodo para obtener los ciclos de CPU requeridos.

En caso de que se trate de un Pod del sistema que funciona con lentitud, comunícate con el equipo de Atención al cliente de Google.

Exceso de suscripció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 tenga una suscripción excesiva a 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 comprobar si la VM tiene una suscripción excesiva. Si se detecta un exceso de suscripción, prueba lo siguiente:

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

Se elimina la OOM al Pod (se agota la memoria)

Los Pods pueden quedar OOMKilled debido a las fugas de memoria o a una configuración deficiente de las solicitudes y los límites de memoria en los contenedores. Estos son algunos de los posibles motivos:

Uso elevado de memoria en el contenedor

Un Pod puede eliminarse si algún contenedor de un Pod consume más de 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:

Si esta proporción es alta (>= 0.8), aumenta el límite de memoria del contenedor.
Si esta proporción no es alta (<0.8), verifica si el uso de memoria del nodo es alto.

Uso elevado de memoria en el nodo

Un Pod puede eliminarse 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.

Ejecuta el siguiente comando y, luego, inspecciona la sección Conditions:
```
kubectl describe nodes --kubeconfig CLUSTER_KUBECONFIG NODE-NAME
```

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 asignarse al Pod, posiblemente debido a que algunos procesos o Pods consumen mucha memoria.

En la consola de Google Cloud > Monitoring > Explorador de métricas, en el Editor de MQL, ejecuta la siguiente consulta para verificar el uso de memoria de los contenedores del 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 mucha memoria, investiga su funcionamiento o aumenta la solicitud de memoria del contenedor, si es necesario.

Si es 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 Google Distributed Cloud para escalar verticalmente y reducir la escala automáticamente de los grupos de nodos según las demandas de tus cargas de trabajo.

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

Problemas de etcd

En ocasiones, los clústeres de Anthos alojados en VMware pueden experimentar fallas de contenedores debido a 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 siguiente formato:

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

Estos son algunos de los posibles motivos:

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 si hay problemas de contención de la CPU.

Si detectas la contención de la CPU en el Pod del servidor conectado 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.

Pod de Etcd OOMkilled

El Pod de etcd podría eliminarse debido a problemas de contención de recursos. Consulta los pasos en la sección El Pod se elimina por OOMkill (por falta de memoria) para verificar si hay problemas de contención de memoria con el Pod del servidor de etcd o 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 memoria o CPU en el Pod del servidor de etcd o en el nodo, 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 etcd tarda demasiado en leer o escribir en el disco subyacente, haz lo siguiente:
1. Recupera 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, significa que el disco está lento. Luego, verifica el rendimiento del almacén de datos y los discos.
Para verificar las métricas de etcd, sigue estos pasos:
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 p99 para etcd_disk_backend_commit_duration_seconds supera continuamente los 25 ms, indica lentitud del disco. Luego, verifica el rendimiento del almacén de datos y los discos.

Latencias de lectura/escritura en el disco de la VM

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

Identifica el nodo para el Pod de etcd lento:

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

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 y escritura del disco virtual es alta, haz lo siguiente:
- Examina otras VMs que se estén ejecutando en el almacén de datos para comprobar el alto uso de operaciones de entrada y salida por segundo (IOPS). Si alguna VM muestra aumentos repentinos en las IOPS, evalúa su funcionamiento.
- Consulta con tu equipo de infraestructura o lab para asegurarte de que el ancho de banda de lectura y escritura no se limite ni se limite en ningún momento.
- Comunícate con tu equipo de lab o infraestructura para identificar los problemas de rendimiento del disco y del rendimiento del almacenamiento, si los hubiera.

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 en tu Google Distributed Cloud experimentan latencia mientras se comunican con el servidor de la API, o si los comandos de Kubectl fallan o tardan demasiado en responder, esto podría indicar problemas con el servidor de la API.

Estos son algunos de los posibles motivos:

Gran volumen de solicitudes a la API

El servidor de la API podría tardar en responder si la frecuencia y el volumen de solicitudes son demasiado altos. El tiempo de respuesta lento puede persistir incluso después de que el servidor de la API comience 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 el registro de auditoría de Cloud para identificar el Pod que podría estar haciendo consultas al servidor de la API con demasiada frecuencia.

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

Limitación de la CPU

Un porcentaje de solicitudes alto en el servidor de la API puede limitar 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 si hay problemas de contención de la CPU con el Pod o el nodo.

Pod del servidor de la API OOMkilled

El Pod del servidor de la API podría eliminarse debido a problemas de contención de recursos. Consulta los pasos en la sección El Pod se elimina por OOMkill (por eliminación de 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 este está 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 el disco.

¿Qué sigue?

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