Solucionar problemas con las métricas del sistema

En esta página se explica cómo resolver problemas relacionados con las métricas del sistema en los clústeres de Google Kubernetes Engine (GKE).

Las métricas de tu clúster no aparecen en Cloud Monitoring

Asegúrate de haber habilitado la API Monitoring y la API Logging en tu proyecto. También debes confirmar que puedes ver tu proyecto en la vista general de Cloud Monitoring de la consola deGoogle Cloud .

Si el problema no se resuelve, comprueba si se da alguna de estas causas:

  • ¿Has habilitado la monitorización en tu clúster?

    La monitorización está habilitada de forma predeterminada en los clústeres creados desde la Google Cloud consola y desde la CLI de Google Cloud, pero puedes verificarlo haciendo clic en los detalles del clúster en la Google Cloud consola ejecutando el siguiente comando:

    gcloud container clusters describe CLUSTER_NAME

    El resultado de este comando debe incluir SYSTEM_COMPONENTS en la lista de enableComponents en la sección monitoringConfig, como en el siguiente ejemplo:

    monitoringConfig:
  componentConfig:
    enableComponents:
    - SYSTEM_COMPONENTS

    Si la monitorización no está habilitada, ejecuta el siguiente comando para habilitarla:

    gcloud container clusters update CLUSTER_NAME --monitoring=SYSTEM

  • ¿Cuánto tiempo ha pasado desde que se creó tu clúster o se habilitó la monitorización?

    Las métricas de un clúster nuevo pueden tardar hasta una hora en empezar a aparecer en Cloud Monitoring.

  • ¿Se está ejecutando un heapster o un gke-metrics-agent (el recopilador de OpenTelemetry) en tu clúster en el espacio de nombres kube-system?

    Es posible que este pod no pueda programar cargas de trabajo porque tu clúster se está quedando sin recursos. Para comprobar si Heapster u OpenTelemetry se están ejecutando, ejecuta kubectl get pods --namespace=kube-system y busca pods con heapster o gke-metrics-agent en el nombre.

  • ¿Puede comunicarse el plano de control de tu clúster con los nodos?

    Cloud Monitoring depende de esa comunicación. Puedes comprobar si el plano de control se comunica con los nodos ejecutando el siguiente comando:

    kubectl logs POD_NAME

    Si este comando devuelve un error, es posible que los túneles SSH estén causando el problema. Para ver los pasos de solución de problemas, consulta Solucionar problemas de SSH.

Identificar y solucionar problemas de permisos para escribir métricas

GKE usa cuentas de servicio de gestión de identidades y accesos que están asociadas a tus nodos para ejecutar tareas del sistema, como el registro y la monitorización. Como mínimo, estas cuentas de servicio de nodo deben tener el rol Cuenta de servicio de nodo predeterminada de Kubernetes Engine (roles/container.defaultNodeServiceAccount) en tu proyecto. De forma predeterminada, GKE usa la cuenta de servicio predeterminada de Compute Engine, que se crea automáticamente en tu proyecto, como cuenta de servicio del nodo.

Si tu organización aplica la restricción de política de organización iam.automaticIamGrantsForDefaultServiceAccounts, es posible que la cuenta de servicio predeterminada de Compute Engine de tu proyecto no obtenga automáticamente los permisos necesarios para GKE.

  • Para identificar el problema, comprueba si hay errores de 401 en la carga de trabajo de monitorización del sistema de tu clúster:

    [[ $(kubectl logs -l k8s-app=gke-metrics-agent -n kube-system -c gke-metrics-agent | grep -cw "Received 401") -gt 0 ]] && echo "true" || echo "false"

    Si el resultado es true, significa que la carga de trabajo del sistema está experimentando errores 401, que indican una falta de permisos. Si el resultado es false, salta el resto de estos pasos y prueba con otro procedimiento para solucionar problemas.

Para asignar el rol roles/container.defaultNodeServiceAccount a la cuenta de servicio predeterminada de Compute Engine, sigue estos pasos:

consola

  1. Ve a la página Bienvenida:

    Ir a Bienvenida

  2. En el campo Número de proyecto, haz clic en Copiar en el portapapeles.
  3. Ve a la página Gestión de identidades y accesos:

    Ir a IAM

  4. Haz clic en Conceder acceso.
  5. En el campo Nuevos principales, especifique el siguiente valor: 
    PROJECT_NUMBER-compute@developer.gserviceaccount.com
     Sustituye PROJECT_NUMBER por el número de proyecto que has copiado.
  6. En el menú Seleccionar un rol, elige el rol Cuenta de servicio de nodo predeterminada de Kubernetes Engine.
  7. Haz clic en Guardar.

gcloud

  1. Busca tu Google Cloud número de proyecto: 
    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

    Sustituye PROJECT_ID por el ID del proyecto.

    El resultado debería ser similar al siguiente:

    12345678901
  2. Asigna el rol roles/container.defaultNodeServiceAccount a la cuenta de servicio predeterminada de Compute Engine: 
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

    Sustituye PROJECT_NUMBER por el número de proyecto del paso anterior.

Confirma que el agente de métricas tiene suficiente memoria

Si has probado los pasos anteriores para solucionar problemas y las métricas siguen sin aparecer, es posible que el agente de métricas no tenga suficiente memoria.

En la mayoría de los casos, la asignación predeterminada de recursos al agente de métricas de GKE es suficiente. Sin embargo, si el DaemonSet falla repetidamente, puedes consultar el motivo de la finalización siguiendo estas instrucciones:

  1. Obtén los nombres de los pods del agente de métricas de GKE:

    kubectl get pods -n kube-system -l component=gke-metrics-agent

  2. Busca el pod con el estado CrashLoopBackOff.

    El resultado debería ser similar al siguiente:

    NAME                    READY STATUS           RESTARTS AGE
gke-metrics-agent-5857x 0/1   CrashLoopBackOff 6        12m

  3. Describe el Pod que tiene el estado CrashLoopBackOff:

    kubectl describe pod POD_NAME -n kube-system

    Sustituye POD_NAME por el nombre del pod del paso anterior.

    Si el motivo de la finalización del pod es OOMKilled, el agente necesita memoria adicional.

    El resultado debería ser similar al siguiente:

      containerStatuses:
  ...
  lastState:
    terminated:
      ...
      exitCode: 1
      finishedAt: "2021-11-22T23:36:32Z"
      reason: OOMKilled
      startedAt: "2021-11-22T23:35:54Z"

  4. Añade una etiqueta de nodo al nodo con el agente de métricas que falla. Puedes usar una etiqueta de nodo persistente o temporal. Te recomendamos que pruebes a añadir 20 MB más. Si el agente sigue fallando, puedes volver a ejecutar este comando y sustituir la etiqueta del nodo por una que solicite una cantidad mayor de memoria adicional.

    Para actualizar un grupo de nodos con una etiqueta persistente, ejecuta el siguiente comando:

    gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --node-labels=ADDITIONAL_MEMORY_NODE_LABEL \
    --location=COMPUTE_LOCATION

    Haz los cambios siguientes:

    • NODEPOOL_NAME: el nombre del grupo de nodos.
    • CLUSTER_NAME: el nombre del clúster.
    • ADDITIONAL_MEMORY_NODE_LABEL: una de las etiquetas de nodo de memoria adicionales. Usa uno de los siguientes valores:
      • Para añadir 10 MB, sigue estos pasos: cloud.google.com/gke-metrics-agent-scaling-level=10
      • Para añadir 20 MB: cloud.google.com/gke-metrics-agent-scaling-level=20
      • Para añadir 50 MB: cloud.google.com/gke-metrics-agent-scaling-level=50
      • Para añadir 100 MB: cloud.google.com/gke-metrics-agent-scaling-level=100
      • Para añadir 200 MB, haz lo siguiente: cloud.google.com/gke-metrics-agent-scaling-level=200
      • Para añadir 500 MB: cloud.google.com/gke-metrics-agent-scaling-level=500
    • COMPUTE_LOCATION: la ubicación de Compute Engine del clúster.

    También puedes añadir una etiqueta de nodo temporal que no se conserve después de una actualización con el siguiente comando:

    kubectl label node/NODE_NAME \
ADDITIONAL_MEMORY_NODE_LABEL --overwrite

    Haz los cambios siguientes:

    • NODE_NAME: el nombre del nodo del agente de métricas afectado.
    • ADDITIONAL_MEMORY_NODE_LABEL: una de las etiquetas de nodo de memoria adicionales. Utiliza uno de los valores del ejemplo anterior.

Siguientes pasos