Se usó la API de Cloud Translation para traducir esta página.

Soluciona problemas del sistema de métricas

Autopilot estándar

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

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

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

Si el problema persiste, verifica alguna de las posibles causas siguientes:

¿Habilitaste la supervisión en tu clúster?

Monitoring está habilitado de forma predeterminada para los clústeres creados desde la consola de Google Cloud y desde Google Cloud CLI, pero puedes verificarlo si haces clic en los detalles del clúster en la consola de Google Cloud o si ejecutas 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, similar al siguiente ejemplo:
```
monitoringConfig:
  componentConfig:
    enableComponents:
    - SYSTEM_COMPONENTS
```
Si la supervisión no está habilitada, ejecuta el siguiente comando para habilitarla:
```
gcloud container clusters update CLUSTER_NAME --monitoring=SYSTEM
```
¿Cuánto tiempo pasó desde que se creó el clúster o se habilitó la supervisión?

Puede tomar hasta una hora para que las métricas de un clúster nuevo comiencen a aparecer en Cloud Monitoring.
¿Hay un heapster o gke-metrics-agent (el recopilador de OpenTelemetry) ejecutándose 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 OpenTelemetry o Heapster están en ejecución, puedes ejecutar kubectl get pods --namespace=kube-system y buscar Pods con heapster o gke-metrics-agent en el nombre.
¿El plano de control del clúster puede comunicarse con los nodos?

Cloud Monitoring depende de esa comunicación. Para verificar si el plano de control se comunica con los nodos, ejecuta el siguiente comando:
```
kubectl logs POD_NAME
```
Si este comando muestra un error, es posible que los túneles SSH causen el problema. Si quieres conocer los pasos para solucionar problemas, consulta Soluciona problemas de SSH.

Identifica y corrige problemas de permisos para escribir métricas

GKE usa cuentas de servicio de IAM que se adjuntan a tus nodos para ejecutar tareas del sistema, como el registro y la supervisión. Como mínimo, estas cuentas de servicio de nodo deben tener el rol de cuenta de servicio de nodo predeterminado 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 la cuenta de servicio del nodo.

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

Para identificar el problema, busca errores de 401 en la carga de trabajo de supervisió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, la carga de trabajo del sistema está experimentando errores 401, lo que indica una falta de permisos. Si el resultado es false, omite el resto de estos pasos y prueba otro procedimiento de solución de problemas.

Para otorgar el rol roles/container.defaultNodeServiceAccount a la cuenta de servicio predeterminada de Compute Engine, completa los siguientes pasos:

Console

Ve a la página Bienvenido:
Ir a Bienvenida
En el campo Número del proyecto, haz clic en Copiar en el portapapeles.
Ve a la página IAM:
Ir a IAM
Haz clic en Grant access.
En el campo Principales nuevas, especifica el siguiente valor:
```
PROJECT_NUMBER-compute@developer.gserviceaccount.com
```
Reemplaza PROJECT_NUMBER por el número de proyecto que copiaste.
En el menú Selecciona un rol, selecciona el rol de Cuenta de servicio de nodo predeterminado de Kubernetes Engine.
Haz clic en Guardar.

gcloud

Busca tu Google Cloud número de proyecto:
```
gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"
```
Reemplaza PROJECT_ID con el ID del proyecto.

El resultado es similar a este:
```
12345678901
```

Otorga 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"

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

Confirma que el agente de métricas tenga suficiente memoria

Si probaste los pasos anteriores para solucionar problemas y las métricas aún no aparecen, 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 de forma repetida, puedes verificar el motivo de la finalización con las siguientes instrucciones:

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

Busca el Pod con el estado CrashLoopBackOff.

El resultado es similar a este:

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

Describe el Pod que tiene el estado CrashLoopBackOff:

kubectl describe pod POD_NAME -n kube-system

Reemplaza POD_NAME por el nombre del Pod del paso anterior.

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