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:

  • Requisitos para abrir un caso de asistencia.
  • Herramientas para ayudarte a solucionar problemas, como la configuración de tu entorno, los registros y las métricas.
  • Componentes admitidos.

No se recogen registros de auditoría de Cloud

Los registros de auditoría de Cloud están habilitados de forma predeterminada, a menos que haya una marca disableCloudAuditLogging definida en la sección clusterOperations de la configuración del clúster.

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 Registros de auditoría de Cloud se ejecuta como un DaemonSet en todos los clústeres de Google Distributed Cloud.

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.

  • 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.

En Google Distributed Cloud, la edición de la configuración de nanny se revertiría en caso de que se actualizara o se mejorara el clúster. Tendrías que volver a aplicar los cambios de configuración. Para evitar esta limitación, reduce la escala metrics-server-operator y cambia manualmente el metrics-server pod.

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:

  • Requisitos para abrir un caso de asistencia.
  • Herramientas para ayudarte a solucionar problemas, como la configuración de tu entorno, los registros y las métricas.
  • Componentes admitidos.