En esta página, se muestra cómo resolver problemas relacionados con los paneles de supervisión para Google Kubernetes Engine (GKE).
Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.Los paneles de GKE no se enumeran en Cloud Monitoring
De forma predeterminada, Monitoring se habilita cuando creas un clúster. Si no ves los paneles de GKE cuando ves los paneles de Google Cloud proporcionados en Monitoring, Monitoring no está habilitado para los clústeres en el proyecto de Google Cloud seleccionado. Habilita la supervisión para ver estos paneles.
No hay recursos de Kubernetes en Mi panel
Si no ves ningún recurso de Kubernetes en tu panel de GKE, verifica lo siguiente:
Proyecto seleccionado de Google Cloud
Verifica que hayas seleccionado el proyecto de Google Cloud correcto de la lista desplegable en la barra de menú de la consola de Google Cloud para seleccionar un proyecto. Debes seleccionar el proyecto cuyos datos deseas ver.
Actividad de los clústeres
Si acabas de crear tu clúster, espera unos minutos para que se propague con los datos. Consulta Configura el registro y la supervisión para GKE para obtener más detalles.
Intervalo de tiempo
El intervalo de tiempo seleccionado puede ser demasiado reducido. Puedes usar el menú Tiempo en la barra de herramientas del panel para seleccionar otros intervalos de tiempo o definir un intervalo Personalizado.
Permisos para ver el panel
Si ves alguno de los siguientes mensajes de error de permiso denegado cuando revisas los detalles de implementación de un servicio o las métricas de un proyecto de Google Cloud, debes actualizar tu Identity and Access Management para incluir roles/monitoring.viewer o roles/viewer:
You do not have sufficient permissions to view this pageYou don't have permissions to perform the action on the selected resources
Para obtener más información, ve a Funciones predefinidas.
Permisos de la cuenta de servicio del nodo y del clúster para escribir datos en Monitoring y Logging
Si ves tasas de errores altas en la página API y servicios habilitados en la consola de Google Cloud, es posible que tu cuenta de servicio no tenga los siguientes roles:
roles/logging.logWriter: En la consola de Google Cloud, este rol se denomina Escritor de registros. Para obtener más información sobre las funciones de Logging, consulta la Guía de control de acceso de Logging.roles/monitoring.metricWriter: En la consola de Google Cloud, este rol se denomina Escritor de métricas de Monitoring. Para obtener más información sobre las funciones de Monitoring, consulta la Guía de control de acceso de Monitoring.roles/stackdriver.resourceMetadata.writer: En la consola de Google Cloud, este rol se denomina Escritor de metadatos de recursos de Stackdriver. Con esta función, se permite el acceso de solo escritura a los metadatos de recursos y se proporcionan los permisos necesarios para que los agentes envíen los metadatos. Para obtener más información sobre las funciones de Monitoring, consulta la Guía de control de acceso de Monitoring.
Para mostrar tus cuentas de servicio, en la consola de Google Cloud, ve a IAM y administración y, luego, selecciona Cuentas de servicio.
No se pueden ver los registros
Si no ves los registros en los paneles, verifica lo siguiente:
El agente está en ejecución y en buen estado
La versión de GKE 1.17 y versiones posteriores usan Fluent Bit para capturar registros. Fluent Bit es el agente de Logging que se ejecuta en los nodos de Kubernetes. Para verificar si el agente se ejecuta de forma correcta, sigue estos pasos:
Ejecuta el siguiente comando para verificar si el agente se reinicia:
kubectl get pods -l k8s-app=fluentbit-gke -n kube-systemSi no hay reinicios, el resultado es similar al siguiente:
NAME READY STATUS RESTARTS AGE fluentbit-gke-6zr6g 2/2 Running 0 44d fluentbit-gke-dzh9l 2/2 Running 0 44dEjecuta el siguiente comando para verificar las condiciones de estado del Pod:
JSONPATH='{range .items[*]};{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status},{end}{end};' \ && kubectl get pods -l k8s-app=fluentbit-gke -n kube-system -o jsonpath="$JSONPATH" | tr ";" "\n"Si la implementación está en buen estado, el resultado es similar al siguiente:
fluentbit-gke-nj4qs:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True, fluentbit-gke-xtcvt:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,Verifica el estado del Pod, que puede ayudarte a determinar si la implementación está en buen estado. Para ello, ejecuta el siguiente comando:
kubectl get daemonset -l k8s-app=fluentbit-gke -n kube-systemSi la implementación está en buen estado, el resultado es similar al siguiente:
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE fluentbit-gke 2 2 2 2 2 kubernetes.io/os=linux 5d19hEn este resultado de ejemplo, el estado deseado coincide con el estado actual.
Si el agente está en ejecución y en buen estado en estas situaciones y aún no ves todos tus registros, es posible que el agente esté sobrecargado y quitando registros.
El agente está sobrecargado y quitando registros
Una posible causa por la que no ves todos los registros es que el volumen de registros del nodo sobrecarga al agente. La configuración predeterminada del agente de Logging en GKE se ajusta a la tasa de 100 kiB por segundo para cada nodo. El agente puede comenzar a quitar registros si el volumen supera ese límite.
Para detectar si alcanzas este límite, busca cualquiera de los siguientes indicadores:
Consulta la métrica
kubernetes.io/container/cpu/core_usage_timecon el filtrocontainer_name=fluentbit-gkepara ver si el uso de CPU del agente de Logging está cerca del 100% o lo alcanzó.Observa la métrica
logging.googleapis.com/byte_countque agrupametadata.system_labels.node_namepara verificar si algún nodo alcanza los 100 kiB por segundo.
Si ves alguna de estas condiciones, puedes agregar más nodos al clúster a fin de reducir el volumen de registros de los nodos. Si todo el volumen de registro proviene de un solo Pod, deberás reducir su volumen.
Para obtener más información sobre cómo investigar y resolver problemas relacionados con el registro en GKE, consulta Soluciona problemas de registro en GKE.
El incidente no coincide con un recurso de GKE
Si tienes una condición de política de alertas que agrega métricas a diferentes recursos de GKE, es posible que debas editar la condición de la política para incluir más etiquetas de jerarquía de GKE a fin de asociar incidentes con entidades específicas.
Por ejemplo, puedes tener dos clústeres de GKE, uno para la producción y otro para la etapa de pruebas, cada uno con su propia copia de servicio lilbuddy-2. Cuando la condición de la política de alertas agrega una métrica a los contenedores en ambos clústeres, el panel de Monitoring de GKE no puede asociar este incidente de forma única con el servicio de producción o el servicio de etapa de pruebas.
Para resolver esta situación, orienta la política de alertas a un servicio específico mediante la adición de namespace, cluster y location al campo Agrupar por de la política. En la tarjeta del evento de la alerta, haz clic en el vínculo Update alert policy para abrir la página Editar política de alertas de la política de alertas pertinente. Desde aquí, puedes actualizar la política de alertas con información adicional para que el panel pueda encontrar el recurso asociado.
Después de actualizar la política de alertas, el panel de Monitoring de GKE puede asociar todos los incidentes futuros con un servicio único en un clúster específico, lo que te brinda información adicional para diagnosticar el problema.
Según el caso de uso, recomendamos filtrar algunas de estas etiquetas además de agregarlas al campo Agrupar por. Por ejemplo, si solo deseas recibir alertas para tu clúster de producción, puedes filtrar por cluster_name.