Soluciona problemas de observabilidad de GKE en VMware

Este documento te ayuda a solucionar problemas de observabilidad en Google Distributed Cloud Virtual for VMware. Si tienes alguno de estos problemas, revisa las correcciones y las soluciones sugeridas.

Si necesitas más ayuda, comunícate con el equipo de Atención al cliente de Google.

Registros de auditoría de Cloud no se recopilan,

Verifica si los registros de auditoría de Cloud están habilitados en la sección cloudAuditLogging de la configuración del clúster. Verifica que el ID del proyecto, la ubicación y la clave de la cuenta de servicio estén configurados correctamente. El ID del proyecto debe ser el mismo que el ID del proyecto en gkeConnect.

Si los registros de auditoría de Cloud están habilitados, los permisos son la razón más común por la que no se recopilan registros. En esta situación, los mensajes de error de permiso denegado se muestran en el contenedor del proxy de registros de auditoría de Cloud.

El contenedor del proxy de Registros de auditoría de Cloud se ejecuta como una de las siguientes opciones:

  • Un Pod estático en el clúster de administrador o independiente.
  • Como contenedor de archivo adicional en el Pod kube-apiserver.

Si ves errores de permisos, sigue los pasos para solucionar problemas de permisos.

No se recopilaron kube-state-metrics métricas

kube-state-metrics (KSM) se ejecuta como una Deployment de una sola réplica en el clúster y genera métricas en casi todos los recursos del clúster. Cuando KSM y gke-metrics-agent se ejecutan en el mismo nodo, existe un mayor riesgo de interrupción entre los agentes de métricas en todos los nodos.

Las métricas de KSM tienen nombres que siguen el patrón de kube_<ResourceKind>, como kube_pod_container_info. Las métricas que comienzan con kube_onpremusercluster_ provienen del controlador del clúster local, no de KSM.

Si faltan métricas de KSM, revisa los siguientes pasos para solucionar problemas:

  • En Cloud Monitoring, verifica la CPU, la memoria y el recuento de reinicios de KSM con las métricas de resumen de la API, como kubernetes.io/anthos/container/... . Esta es una canalización independiente con KSM. Confirma que el Pod de KSM no está limitado por recursos insuficientes.
    • Si estas métricas de resumen de la API no están disponibles para KSM, es probable que gke-metrics-agent en el mismo nodo también tenga el mismo problema.
  • En el clúster, verifica el estado y los registros del Pod de KSM y el Pod gke-metrics-agent en el mismo nodo con KSM.

kube-state-metrics de fallas repetidas

Síntoma

No hay métricas de kube-state-metrics (KSM) disponibles en Cloud Monitoring.

Causa

Es más probable que esta situación ocurra en clústeres grandes o con grandes cantidades de recursos. KSM se ejecuta como un Deployment de una sola réplica y enumera casi todos los recursos del clúster, como Pods, Deployments, DaemonSets, ConfigMaps, Secrets y PersistentVolumes. Las métricas se generan en cada uno de estos objetos de recursos. Si alguno de los recursos tiene muchos objetos, como un clúster con más de 10,000 Pods, es posible que KSM se quede sin memoria.

Versiones afectadas

Este problema se puede experimentar en cualquier versión de Google Distributed Cloud Virtual for VMware.

El límite predeterminado de CPU y memoria aumentó en las últimas versiones de Google Distributed Cloud Virtual for VMware, por lo que estos problemas de recursos deberían ser menos comunes.

Solución y solución alternativa

Para verificar si el problema se debe a problemas de memoria insuficiente, sigue estos pasos:

  • Usa kubectl describe pod o kubectl get pod -o yaml y verifica el mensaje de estado de error.
  • Verifica la métrica de uso y consumo de memoria para KSM y confirma si está alcanzando el límite antes de reiniciarlo.

Si confirmas que el problema son los problemas de falta de memoria, usa una de las siguientes soluciones:

  • Aumenta la solicitud de memoria y el límite para KSM.

    Para ajustar la CPU y la memoria de KSM, haz lo siguiente:

    1. Para las versiones 1.9 y anteriores de Google Distributed Cloud Virtual for VMware, 1.10.6 o anteriores, 1.11.2 o anteriores y 1.12.1 o anteriores:

      1. No es una buena solución a largo plazo: si editas el recurso relacionado con KSM, monitoring-operator revierte los cambios automáticamente.

      2. Puedes reducir la escala de monitoring-operator a 0 réplicas y, luego, editar la implementación de KSM para ajustar su límite de recursos. Sin embargo, el clúster no recibirá parches de vulnerabilidad que entreguen las nuevas versiones de parches mediante monitoring-operator.

        Recuerda volver a escalar monitoring-operator después de que el clúster se actualice a una versión posterior con corrección.

    2. Para las versiones de Google Distributed Cloud Virtual para VMware 1.10.7 o posteriores, 1.11.3 o posteriores, 1.12.2 o posteriores y 1.13 y posteriores, crea un ConfigMap llamado kube-state-metrics-resizer-config en el espacio de nombres kube-system (gke-managed-metrics-server para 1.13 o posterior) con la siguiente definición. Ajusta los números de CPU y memoria como desees:

      apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-state-metrics-resizer-config
  namespace: kube-system
data:
  NannyConfiguration: |-
  apiVersion: nannyconfig/v1alpha1
  kind: NannyConfiguration
  baseCPU: 200m
  baseMemory: 1Gi
  cpuPerNode: 3m
  memoryPerNode: 20Mi

      1. Después de crear el ConfigMap, reinicia la implementación de KSM. Para ello, borra el pod de KSM con el siguiente comando:

          kubectl -n kube-system rollout restart deployment kube-state-metrics
  ```

  • Reduce la cantidad de métricas de KSM.

    En el caso de Google Distributed Cloud Virtual for VMware 1.13, KSM solo expone una cantidad menor de métricas llamadas Core Metrics de forma predeterminada. Este comportamiento significa que el uso de recursos es menor que las versiones anteriores, pero se puede seguir el mismo procedimiento para reducir aún más la cantidad de métricas de KSM.

    Para las versiones de Google Distributed Cloud Virtual for VMware anteriores a la 1.13, KSM usa las marcas predeterminadas. Esta configuración expone una gran cantidad de métricas.

gke-metrics-agent de fallas repetidas

Si gke-metrics-agent solo tiene problemas de memoria en el nodo en el que existe kube-state-metrics, la causa es una gran cantidad de métricas de kube-state-metrics. Para mitigar este problema, reduce verticalmente la escala de stackdriver-operator y modifica KSM para exponer un pequeño conjunto de métricas necesarias, como se detalla en la sección anterior. Recuerda escalar verticalmente stackdriver-operator después de actualizar el clúster a Google Distributed Cloud Virtual for VMware 1.13, donde KSM expone una cantidad menor de métricas principales de forma predeterminada.

Para los problemas que no están relacionados con eventos de memoria insuficiente, consulta los registros de Pods de gke-metric-agent. Puedes ajustar la CPU y la memoria para todos los Pods gke-metrics-agent si agregas el campo resourceAttrOverride al recurso personalizado de Stackdriver.

stackdriver-metadata-agent de fallas repetidas

Síntoma

No hay etiquetas de metadatos del sistema disponibles cuando se filtran métricas en Cloud Monitoring.

Causa

El caso más común de bucle de falla de stackdriver-metadata-agent se debe a eventos de memoria insuficiente. Este evento es similar a kube-state-metrics. Aunque stackdriver-metadata-agent no enumera todos los recursos, aún enumera todos los objetos para los tipos de recursos relevantes, como Pods, Deployments y NetworkPolicy. El agente se ejecuta como un Deployment de una sola réplica, lo que aumenta el riesgo de eventos sin memoria si la cantidad de objetos es demasiado grande.

Versión afectada

Este problema se puede experimentar en cualquier versión de Google Distributed Cloud Virtual for VMware.

El límite predeterminado de CPU y memoria aumentó en las últimas versiones de Google Distributed Cloud Virtual for VMware, por lo que estos problemas de recursos deberían ser menos comunes.

Solución y solución alternativa

Para verificar si el problema se debe a problemas de memoria insuficiente, sigue estos pasos:

  • Usa kubectl describe pod o kubectl get pod -o yaml y verifica el mensaje de estado de error.
  • Verifica la métrica de uso y consumo de memoria para stackdriver-metadata-agent y confirma si está alcanzando el límite antes de reiniciarlo.
Si confirmas que los problemas de memoria insuficiente causan problemas, aumenta el límite de memoria en el campo resourceAttrOverride del recurso personalizado de Stackdriver.

metrics-server de fallas repetidas

Síntoma

Horizontal Pod Autoscaler y kubectl top no funcionan en tu clúster.

Causa y versiones afectadas

Este problema no es muy común, pero se debe a errores de falta de memoria en clústeres grandes o en clústeres con alta densidad de Pods.

Este problema se puede experimentar en cualquier versión de Google Distributed Cloud Virtual for VMware.

Solución y solución alternativa

Aumenta los límites de recursos del servidor de métricas. En la versión 1.13 y posteriores de Google Distributed Cloud Virtual para VMware, el espacio de nombres de metrics-server y su configuración se trasladaron de kube-system a gke-managed-metrics-server.

¿Qué sigue?

Si necesitas más ayuda, comunícate con el equipo de Atención al cliente de Google.