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
-
- – 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.
- – 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
- – 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 - – 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í 🙂