Soluciona problemas de observabilidad de Google Distributed Cloud

En este documento, se ayuda a solucionar problemas de visibilidad en Google Distributed Cloud. Si tienes alguno de estos problemas, revisa las correcciones y soluciones alternativas sugeridas.

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

No se recopilan los registros de auditoría de Cloud

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 el motivo más común por el que no se recopilan los registros. En esta situación, los mensajes de error de permiso denegado se muestran en el contenedor de proxy de los Registros de auditoría de Cloud.

El contenedor de proxy de los 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.

Otra posible causa es que tu proyecto haya alcanzado el límite de cuentas de servicio compatibles. Consulta Fuga de la cuenta de servicio de los registros de auditoría de Cloud.

No se recopilan las métricas de kube-state-metrics

kube-state-metrics (KSM) se ejecuta como una sola implementación de 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_ son del controlador de 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 la API de resumen, como kubernetes.io/anthos/container/... . Esta es una canalización independiente con KSM. Confirma que el Pod de KSM no esté limitado por no tener suficientes recursos.
    • Si estas métricas de API de resumen 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 del Pod de gke-metrics-agent en el mismo nodo con KSM.

Fallas de kube-state-metrics que se repiten

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 con grandes cantidades de recursos. KSM se ejecuta como una sola implementación de 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 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 ocurrir en cualquier versión de Google Distributed Cloud.

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

Solución y solución alternativa

Para comprobar si el problema se debe a la falta de memoria, revisa los siguientes pasos:

  • Usa kubectl describe pod o kubectl get pod -o yaml y revisa el mensaje de estado de error.
  • Verifica la métrica de consumo y utilización de memoria de KSM y confirma si está llegando al 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 para KSM.

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

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

    • Para las versiones de Google Distributed Cloud 1.10.7 o posteriores, 1.11.3 o posteriores, 1.12.2 o posteriores, y 1.13 o 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 las cantidades 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 borrando el Pod de KSM con el siguiente comando:

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

    • Para 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, haz lo siguiente:

      • No hay una buena solución a largo plazo. Si editas el recurso relacionado con KSM, monitoring-operator revertirá los cambios automáticamente.
      • Puedes reducir la escala verticalmente 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 nuevas versiones de parches con monitoring-operator. Recuerda escalar la copia de seguridad de monitoring-operator después de que el clúster se actualice a una versión posterior con la corrección.

  • Reduce la cantidad de métricas de KSM.

    En Google Distributed Cloud 1.13, KSM solo expone una cantidad menor de métricas llamadas Métricas principales de forma predeterminada. Este comportamiento 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 la cantidad de métricas de KSM.

    En el caso de las versiones de Google Distributed Cloud anteriores a la 1.13, KSM usa las marcas predeterminadas. Esta configuración expone una gran cantidad de métricas.

Fallas de gke-metrics-agent que se repiten

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

En el caso de los problemas que no están relacionados con eventos de falta de memoria, consulta los registros de Pods de gke-metric-agent. Para ajustar la CPU y la memoria de todos los Pods gke-metrics-agent, agrega el campo resourceAttrOverride al recurso personalizado de Stackdriver.

Fallas de stackdriver-metadata-agent que se repiten

Síntoma

No hay ninguna etiqueta de metadatos del sistema disponible cuando se filtran métricas en Cloud Monitoring.

Causa

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

Versión afectada

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

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

Solución y solución alternativa

Para comprobar si el problema se debe a la falta de memoria, revisa los siguientes pasos:

  • Usa kubectl describe pod o kubectl get pod -o yaml y verifica el mensaje de estado de error.
  • Verifica la métrica de consumo y utilización de la memoria de stackdriver-metadata-agent y confirma si alcanza 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.

Fallas de metrics-server que se repiten

Síntoma

El 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 memoria insuficiente en clústeres grandes o en clústeres con alta densidad de Pods.

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

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, el espacio de nombres de metrics-server y su configuración se movieron de kube-system a gke-managed-metrics-server.

No se quitan todos los recursos durante la eliminación de la cuenta de servicio de los registros de auditoría de Cloud

Cuando borras una cuenta de servicio que se usa para los registros de auditoría de Cloud, no se borran todos los recursos Google Cloud. Si borras y vuelves a crear de forma periódica las cuentas de servicio que se usan para los registros de auditoría de Cloud, con el tiempo, el registro de auditoría comenzará a fallar.

Síntoma

Los mensajes de error de permiso denegado se muestran en el contenedor de 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

Reemplaza PROJECT_NUMBER por el número del proyecto.

La respuesta muestra todas las cuentas de servicio que se usan con los registros de auditoría de Cloud en el proyecto, incluidas las cuentas de servicio que se borraron.

Causa y versiones afectadas

No se quitan todos los Google Cloud recursos cuando borras una cuenta de servicio que se usa para los registros de auditoría de Cloud, y, con el tiempo, alcanzas el límite de 1,000 cuentas de servicio para el proyecto.

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

Solución y solución alternativa

  1. Crea una variable de entorno que contenga una lista separada por comas de todas las cuentas de servicio que deseas conservar. Rodea cada correo electrónico de la cuenta de servicio con comillas simples y rodea toda la lista con comillas dobles. Puedes usar lo siguiente como punto de partida:

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

    Reemplaza lo siguiente:

    • PROJECT_ID: el ID de tu 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 de registros de auditoría de Cloud 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

    Reemplaza lo siguiente:

    • PROJECT_NUMBER: Número del proyecto
    • FLEET_REGION: Es la ubicación de la membresía de 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 membresía.

    Este comando borra 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 desees 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]}}}'

¿Qué sigue?

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