Solucionar problemas de observabilidad de Google Distributed Cloud

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

Si necesitas más ayuda, ponte en contacto con el servicio de atención al cliente de Cloud.

También puedes consultar la sección Obtener asistencia para obtener más información sobre los recursos de asistencia, incluidos los siguientes:

No se recogen registros de auditoría de Cloud

Comprueba si Registros de auditoría de Cloud está habilitado 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 de proyecto debe ser el mismo que el ID de proyecto de gkeConnect.

Si los registros de auditoría de Cloud están habilitados, los permisos son el motivo más habitual por el que no se recogen los registros. En este caso, los mensajes de error de permiso denegado se muestran en el contenedor proxy de los registros de auditoría de Cloud.

El contenedor proxy de Cloud Audit Logs se ejecuta de una de las siguientes formas:

  • Un pod estático en el clúster independiente o de administrador.
  • Como contenedor secundario en un pod de kube-apiserver.

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

Otra posible causa es que tu proyecto haya alcanzado el límite de cuentas de servicio admitidas. Consulta Se ha filtrado la cuenta de servicio de Cloud Audit Logs.

No se recogen métricas de kube-state-metrics

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

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

Si faltan métricas de KSM, sigue estos pasos para solucionar el problema:

  • En Cloud Monitoring, comprueba la CPU, la memoria y el número de reinicios de KSM mediante las métricas de la API de resumen, como kubernetes.io/anthos/container/... . Se trata de una pipeline independiente con KSM. Confirma que el pod de KSM no esté limitado por no tener suficientes recursos.
    • Si estas métricas de la API de resumen no están disponibles para KSM, gke-metrics-agenten el mismo nodo probablemente también se produzca el mismo problema.
  • En el clúster, comprueba el estado y los registros del pod KSM y del pod gke-metrics-agent en el mismo nodo que KSM.

kube-state-metrics bucle de fallos

Síntoma

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

Causa

Es más probable que esta situación se produzca en clústeres grandes o en clústeres con grandes cantidades de recursos. KSM se ejecuta como un Deployment de una sola réplica y muestra 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 recurso. 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 puede producirse en cualquier versión de Google Distributed Cloud.

El límite predeterminado de CPU y memoria se ha aumentado en las últimas versiones de Google Distributed Cloud, por lo que estos problemas de recursos deberían ser menos habituales.

Solución y alternativa

Para comprobar si el problema se debe a problemas de falta de memoria, sigue estos pasos:

  • Usa kubectl describe pod o kubectl get pod -o yaml y comprueba el mensaje de estado del error.
  • Comprueba la métrica de consumo y utilización de memoria de KSM y confirma si alcanza el límite antes de reiniciarse.

Si confirmas que el problema es la falta de memoria, usa una de las siguientes soluciones:

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

    Para ajustar la CPU y la memoria de KSM, sigue estos pasos:

    • En las versiones 1.16.0 o posteriores de Google Distributed Cloud, Google Cloud Observability gestiona KSM. Para actualizar KSM, consulta Invalidar las solicitudes y los límites predeterminados de CPU y memoria de un componente de Stackdriver.

    • En las versiones de Google Distributed Cloud 1.10.7 o posteriores, 1.11.3 o posteriores, 1.12.2 o posteriores, 1.13 y posteriores, pero anteriores a 1.16.0, crea un ConfigMap para ajustar la CPU y la memoria:

      1. Crea un ConfigMap llamado kube-state-metrics-resizer-config en el espacio de nombres kube-system (gke-managed-metrics-server para la versión 1.13 o posterior) con la siguiente definición. Ajusta los números de CPU y memoria según sea necesario:

          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
  ```

      2. Después de crear el ConfigMap, reinicia la implementación de KSM eliminando el pod de KSM con el siguiente comando:

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

    • En las versiones 1.9 y anteriores, 1.10.6 y anteriores, 1.11.2 y anteriores, y 1.12.1 y anteriores de Google Distributed Cloud:

      • No es una buena solución a largo plazo: si editas el recurso relacionado con KSM, monitoring-operator deshace los cambios automáticamente.
      • Puedes reducir la escala monitoring-operator a 0 réplicas y, a continuación, editar la implementación de KSM para ajustar su límite de recursos. Sin embargo, el clúster no recibirá los parches de vulnerabilidades que se incluyan en las nuevas versiones de parches mediante monitoring-operator. Recuerda volver a aumentar la escala de monitoring-operator después de actualizar el clúster a una versión posterior con la corrección.

  • Reduce el número de métricas de KSM.

    En Google Distributed Cloud 1.13, KSM solo expone un número menor de métricas, llamadas métricas principales, de forma predeterminada. Esto significa que el uso de recursos es menor que en las versiones anteriores, pero se puede seguir el mismo procedimiento para reducir aún más el número de métricas de KSM.

    En las versiones de Google Distributed Cloud anteriores a la 1.13, KSM usa las marcas predeterminadas. Esta configuración expone un gran número de métricas.

gke-metrics-agent bucle de fallos

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

Si los problemas no están relacionados con eventos de falta de memoria, consulta los registros de los pods de gke-metric-agent. Puedes ajustar la CPU y la memoria de todos los gke-metrics-agentpods añadiendo el campo resourceAttrOverride al recurso personalizado de Stackdriver.

stackdriver-metadata-agent bucle de fallos

Síntoma

No hay ninguna etiqueta de metadatos del sistema disponible al filtrar métricas en Cloud Monitoring.

Causa

El caso más habitual de stackdriver-metadata-agent bucle de fallos se debe a eventos de falta de memoria. Este evento es similar a kube-state-metrics. Aunque stackdriver-metadata-agent no muestra todos los recursos, sí muestra todos los objetos de los tipos de recursos relevantes, como pods, implementaciones y NetworkPolicy. El agente se ejecuta como un único despliegue de réplica, lo que aumenta el riesgo de que se produzcan eventos de falta de memoria si el número de objetos es demasiado grande.

Versión afectada

Este problema puede producirse en cualquier versión de Google Distributed Cloud.

El límite predeterminado de CPU y memoria se ha aumentado en las últimas versiones de Google Distributed Cloud, por lo que estos problemas de recursos deberían ser menos habituales.

Solución y alternativa

Para comprobar si el problema se debe a problemas de falta de memoria, sigue estos pasos:

  • Usa kubectl describe pod o kubectl get pod -o yaml y comprueba el mensaje de estado del error.
  • Comprueba la métrica de consumo y utilización de memoria de stackdriver-metadata-agent y confirma si está alcanzando el límite antes de reiniciarse.
Si confirmas que los problemas de falta de memoria están causando problemas, aumenta el límite de memoria en el campo resourceAttrOverride del recurso personalizado de Stackdriver.

metrics-server bucle de fallos

Síntoma

La herramienta de adaptación dinámica horizontal de pods y kubectl top no funcionan en tu clúster.

Causa y versiones afectadas

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

Este problema puede producirse en cualquier versión de Google Distributed Cloud.

Solución y alternativa

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

No se eliminan todos los recursos al eliminar una cuenta de servicio de Registros de auditoría de Cloud

Cuando eliminas una cuenta de servicio que se usa para los registros de auditoría de Cloud, no se eliminan todos los recursos. Google Cloud Si sueles eliminar y volver a crear cuentas de servicio que se usan para Cloud Audit Logs, al final se producirán errores en el registro de auditoría.

Síntoma

Los mensajes de error de permiso denegado se muestran en el contenedor proxy de los registros de auditoría de Cloud.

Para confirmar que el error del registro de auditoría se debe a este problema, ejecuta el siguiente comando:

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/global/features/cloudauditlogging

Sustituye PROJECT_NUMBER por el número de tu proyecto.

La respuesta devuelve todas las cuentas de servicio que se han usado con Cloud Audit Logs en el proyecto, incluidas las cuentas de servicio que se han eliminado.

Causa y versiones afectadas

No se eliminan todos los recursos de Google Cloud cuando eliminas una cuenta de servicio que se usa en Cloud Audit Logs y, al final, alcanzas el límite de 1000 cuentas de servicio por proyecto.

Este problema puede producirse en cualquier versión de Google Distributed Cloud.

Solución y alternativa

  1. Crea una variable de entorno que contenga una lista separada por comas de todas las cuentas de servicio que quieras conservar. Escribe la dirección de correo de cada cuenta de servicio entre comillas simples y la lista completa entre comillas dobles. Puedes usar lo siguiente como punto de partida:

    SERVICE_ACCOUNT_EMAILS="'SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com'"

    Haz los cambios siguientes:

    • PROJECT_ID: tu ID de proyecto.
    • SERVICE_ACCOUNT_NAME: el nombre de la cuenta de servicio.

    La lista completada debería ser similar al siguiente ejemplo:

    "'sa_name1@example-project-12345.iam.gserviceaccount.com','sa_name2@example-project-12345.iam.gserviceaccount.com','sa_name3@example-project-12345.iam.gserviceaccount.com'"

  2. Ejecuta el siguiente comando para quitar la función Cloud Audit Logs del proyecto:

    curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION /features/cloudauditlogging

    Haz los cambios siguientes:

    • PROJECT_NUMBER: el número de proyecto.
    • FLEET_REGION: la ubicación de la pertenencia a la flota de tus clústeres. Puede ser una región específica, como us-central1 o global. Puedes ejecutar el comando gcloud container fleet memberships list para obtener la ubicación de la suscripción.

    Este comando elimina por completo todas las cuentas de servicio.

  3. Vuelve a crear la función Registros de auditoría de Cloud solo con las cuentas de servicio que quieras conservar:

    curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION/features?feature_id=cloudauditlogging \
    -d '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":[$SERVICE_ACCOUNT_EMAILS]}}}'

Siguientes pasos

Si necesitas más ayuda, ponte en contacto con el servicio de atención al cliente de Cloud.

También puedes consultar la sección Obtener asistencia para obtener más información sobre los recursos de asistencia, incluidos los siguientes: