GCP/GKE – Nuevo sistema de logging

Introducción

Es muy probable que tengas un clúster de GKE en la versión v1.15 y durante varios meses no hayas sufrido problemas cuando, de repente, los logs han dejado de recibirse. Estás usando el sistema de logging que provee el sistema por defecto, por lo que compruebas la página de status de GCP pero todo está funcionando correctamente. Además sabes que no has modificado nada en el clúster antes de que se detuviese la recepción de logs, pero al mismo tiempo sospechas que tiene que estás causado por algo en tu parte (en nuestro caso nos dimos cuenta de que no estaba sucediendo en otros clústeres que gestionamos).

Si la anterior historia te resulta familiar, continúa leyendo ya que este artículo cubrirá desde cómo detectarlo hasta la solución que hará que los logs del clúster se vuelvan a recibir.

1. Síntomas

    1. – El síntoma principal que verás es la repentina y completa ausencia de logs en Stackdriver, los cuales deberían estar recibiéndose -como de costumbre- desde los pods de tu clúster.

 

  1. – Además del hecho anterior, podrás descubrir que ya no hay agentes de Fluentd en tu clúster.
    $ kubectl get daemonset -n kube-system | grep -i fluentd
    
    
  2. – Por otra parte todos los nodos de tu clúster tienen la etiqueta («label») beta.kubernetes.io/fluentd-ds-ready=true, la cual es requerida por los agentes de Fluentd para saber en qué nodos deben desplegarse.
    $ kubectl get nodes
    NAME                           STATUS   ROLES    AGE     VERSION
    gke-cluster-node-93c020-7rjq   Ready    none     14h     v1.15.11-gke.15
    gke-cluster-node-93c020-9w22   Ready    none     23h     v1.15.11-gke.15
    gke-cluster-node-93c020-jdbt   Ready    none     47h     v1.15.11-gke.15
    gke-cluster-node-93c020-jvcl   Ready    none     3h17m   v1.15.11-gke.15
    
    $ kubectl describe node gke-cluster-node-93c020-7rjq | grep -i fluentd-ds-ready
           beta.kubernetes.io/fluentd-ds-ready=true
    
    $ # Haz lo mismo para los nodos restantes para asegurar que todos ellos están adecuadamente etiquetados
  3. – Tu clúster de GKE está actualmente en la versión v1.15 o superior.

2. Diagnóstico

Lo que está sucediendo es que Google está descatalogando a marchas forzadas el antiguo sistema de monitorización/logging. El nuevo sistema que lo reemplaza se llama Cloud Operations for GKE que (para nuestro caso) hace básicamente lo mismo. Una vez dicho eso, cabe mencionar que hay algunas diferencias que deberás tener en cuenta cuando realices búsquedas (como por ejemplo cambios en los nombres de las métricas), y que todas ellas las encontrarás en la guía de migración.

3. Tratamiento

Etiquetar los nodos del clúster

Si te encontraste en pasos previos que uno o varios de los nodos de tu clúster no están etiquetados, ¡hazlo ahora!

$ kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true

Obtén el nombre de tu clúster

Lista los clústeres disponibles.

$ gcloud container clusters list
NAME        LOCATION        MASTER_VERSION  MASTER_IP    MACHINE_TYPE   NODE_VERSION    NUM_NODES  STATUS
my-cluster  europe-east1-a  1.15.12-gke.2   34.35.36.37  n1-standard-2  1.15.11-gke.15  4          RUNNING

Deshabilita el servicio de logging para tu clúster

Actualiza la configuración de tu clúster para establecer el servicio de logging al valor none.

$ gcloud container clusters update my-cluster --logging-service none

Habilita de nuevo el servicio de logging para tu clúster

Actualiza la configuración de tu clúster para volver a establecer el servicio de logging al que hay por defecto.

$ gcloud container clusters update my-cluster --logging-service logging.googleapis.com

ATENCIÓN: Obtendrás un mensaje de error informándote que no es posible habilitarlo debido a la descatalogación. Esta es la forma por la que finalmente nos dimos cuenta dónde estaba el problema. Simplemente sigue adelante, vas en la dirección correcta.

Verifica que el estado de la migración es el esperado

Abre la sección de monitorización (monitoring) de interfaz web de GCP y dirígete a la sub-sección de configuración (Settings). Encontrarás una pestaña llamada «Kubernetes Migration Status» que debería verse como a continuación.

Habilitar completamente el servicio de loggin y monitorización para tu clúster

Abre la lista de clústeres de GKE haz clic en el nombre del clúster donde quieres configurar el nuevo sistema de logging. Una vez veas la configuración del clúster, haz clic en el botón EDITAR como se muestra a continuación.

Desliza hacia abajo hasta encontrar el parámetro Kubernetes Engine Monitoring y, haciendo clic en el desplegable, selecciona la opción Almacenamiento de registros y supervisión del sistema y las cargas de trabajo (System and workload logging and monitoring).

IMPORTANTE: No olvides guardas los cambios usando el botón que hay al final.

Y ya está! Tu clúster volverá a recibir de nuevo los logs!

 

Conclusión

Como probablemente ya sabrás Google Cloud Platform está todavía en fase beta, por lo que habitualmente encontrarás algunos cambios que harán que fallen tus sistemas en funcionamiento. Tienes dos opciones en este punto: Por un lado puedes mantenerte actualizado acerca de todos los cambios y descatalogaciones futuras. Por otro, puedes limitarte a ir arreglar las cosas según vayan surgiendo, pero ten en cuenta que siempre estarás luchando contra los problemas a ciegas.

Hay una tercera opción (que podría ser la primera), que consiste en consultar regularmente el blog de Geko y verificar si ya nos hemos tratado con el problema que te estás encontrando. El equipo de Geko siempre estará contento de verte aquí 🙂

Contáctanos para más información!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *