Si la anterior historia te resulta familiar, contin\u00faa leyendo ya que este art\u00edculo cubrir\u00e1 desde c\u00f3mo detectarlo hasta la soluci\u00f3n que har\u00e1 que los logs del cl\u00faster se vuelvan a recibir.<\/p>\n
1. S\u00edntomas<\/h2>\n\n- \n
\n- – El s\u00edntoma principal que ver\u00e1s es la repentina y completa ausencia de logs en Stackdriver<\/a>, los cuales deber\u00edan estar recibi\u00e9ndose -como de costumbre- desde los pods de tu cl\u00faster.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
<\/p>\n
\n- – Adem\u00e1s del hecho anterior, podr\u00e1s descubrir que ya no hay agentes de Fluentd<\/a> en tu cl\u00faster.\n\n
$ kubectl get daemonset -n kube-system | grep -i fluentd\r\n\r\n<\/pre>\n<\/div>\n<\/li>\n
- – Por otra parte todos los nodos de tu cl\u00faster tienen la etiqueta (\u00ablabel\u00bb) beta.kubernetes.io\/fluentd-ds-ready=true<\/strong>, la cual es requerida por los agentes de Fluentd para saber en qu\u00e9 nodos deben desplegarse.\n\n
$ kubectl get nodes\r\nNAME STATUS ROLES AGE VERSION\r\ngke-cluster-node-93c020-7rjq Ready none 14h v1.15.11-gke.15\r\ngke-cluster-node-93c020-9w22 Ready none 23h v1.15.11-gke.15\r\ngke-cluster-node-93c020-jdbt Ready none 47h v1.15.11-gke.15\r\ngke-cluster-node-93c020-jvcl Ready none 3h17m v1.15.11-gke.15\r\n\r\n$ kubectl describe node gke-cluster-node-93c020-7rjq | grep -i fluentd-ds-ready\r\n beta.kubernetes.io\/fluentd-ds-ready=true\r\n\r\n$ # Haz lo mismo para los nodos restantes para asegurar que todos ellos est\u00e1n adecuadamente etiquetados<\/pre>\n<\/div>\n<\/li>\n
- – Tu cl\u00faster de GKE est\u00e1 actualmente en la versi\u00f3n v1.15 o superior.<\/li>\n<\/ol>\n
2. Diagn\u00f3stico<\/h2>\n
Lo que est\u00e1 sucediendo es que Google est\u00e1 descatalogando a marchas forzadas el antiguo sistema de monitorizaci\u00f3n\/logging. El nuevo sistema que lo reemplaza se llama Cloud Operations for GKE<\/a> que (para nuestro caso) hace b\u00e1sicamente lo mismo. Una vez dicho eso, cabe mencionar que hay algunas diferencias que deber\u00e1s tener en cuenta cuando realices b\u00fasquedas (como por ejemplo cambios en los nombres de las m\u00e9tricas), y que todas ellas las encontrar\u00e1s en la gu\u00eda de migraci\u00f3n<\/a>.<\/p>\n3. Tratamiento<\/h2>\nEtiquetar los nodos del cl\u00faster<\/h3>\n
Si te encontraste en pasos previos que uno o varios de los nodos de tu cl\u00faster no est\u00e1n etiquetados, \u00a1hazlo ahora!<\/p>\n
\n$ kubectl label node $NODE_NAME beta.kubernetes.io\/fluentd-ds-ready=true<\/pre>\n<\/div>\nObt\u00e9n el nombre de tu cl\u00faster<\/h3>\n
Lista los cl\u00fasteres disponibles.<\/p>\n
\n$ gcloud container clusters list\r\nNAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS\r\nmy-cluster europe-east1-a 1.15.12-gke.2 34.35.36.37 n1-standard-2 1.15.11-gke.15 4 RUNNING\r\n<\/pre>\n<\/div>\nDeshabilita el servicio de logging para tu cl\u00faster<\/h3>\n
Actualiza la configuraci\u00f3n de tu cl\u00faster para establecer el servicio de logging al valor none.<\/em><\/p>\n\n$ gcloud container clusters update my-cluster --logging-service none<\/pre>\n<\/div>\nHabilita de nuevo el servicio de logging para tu cl\u00faster<\/h3>\n
Actualiza la configuraci\u00f3n de tu cl\u00faster para volver a establecer el servicio de logging al que hay por defecto.<\/p>\n
\n$ gcloud container clusters update my-cluster --logging-service logging.googleapis.com<\/pre>\n<\/div>\nATENCI\u00d3N:<\/strong> Obtendr\u00e1s un mensaje de error inform\u00e1ndote que no es posible habilitarlo debido a la descatalogaci\u00f3n. Esta es la forma por la que finalmente nos dimos cuenta d\u00f3nde estaba el problema. Simplemente sigue adelante, vas en la direcci\u00f3n correcta.<\/p>\nVerifica que el estado de la migraci\u00f3n es el esperado<\/h3>\n
Abre la secci\u00f3n de monitorizaci\u00f3n (monitoring) de interfaz web de GCP<\/a> y dir\u00edgete a la sub-secci\u00f3n de configuraci\u00f3n (Settings). Encontrar\u00e1s una pesta\u00f1a llamada \u00abKubernetes Migration Status\u00bb que deber\u00eda verse como a continuaci\u00f3n.<\/p>\n![\"\"](\"https:\/\/geko2.factoryfy.com\/wp-content\/uploads\/kubernetes-migration-dashboard.png\")
<\/p>\n
Habilitar completamente el servicio de loggin y monitorizaci\u00f3n para tu cl\u00faster<\/h3>\n
Abre la lista de cl\u00fasteres de GKE<\/a> haz clic en el nombre del cl\u00faster donde quieres configurar el nuevo sistema de logging. Una vez veas la configuraci\u00f3n del cl\u00faster, haz clic en el bot\u00f3n EDITAR como se muestra a continuaci\u00f3n.<\/p>\n![\"\"](\"https:\/\/geko2.factoryfy.com\/wp-content\/uploads\/edit-cluster.png\")
<\/p>\n
Desliza hacia abajo hasta encontrar el par\u00e1metro Kubernetes Engine Monitoring<\/strong> y, haciendo clic en el desplegable, selecciona la opci\u00f3n Almacenamiento de registros y supervisi\u00f3n del sistema y las cargas de trabajo<\/strong> (System and workload logging and monitoring)<\/strong>.<\/span><\/span><\/p>\n![\"\"](\"https:\/\/geko2.factoryfy.com\/wp-content\/uploads\/monitoring-dropdown.png\")
<\/p>\n
IMPORTANTE: <\/strong>No olvides guardas los cambios usando el bot\u00f3n que hay al final.<\/p>\nY ya est\u00e1! Tu cl\u00faster volver\u00e1 a recibir de nuevo los logs!<\/h5>\n
<\/p>\n
Conclusi\u00f3n<\/h2>\n
Como probablemente ya sabr\u00e1s Google Cloud Platform est\u00e1 todav\u00eda en fase beta, por lo que habitualmente encontrar\u00e1s algunos cambios que har\u00e1n 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\u00fan vayan surgiendo, pero ten en cuenta que siempre estar\u00e1s luchando contra los problemas a ciegas.<\/p>\n
Hay una tercera opci\u00f3n (que podr\u00eda ser la primera), que consiste en consultar regularmente el blog de Geko<\/a> y verificar si ya nos hemos tratado con el problema que te est\u00e1s encontrando. El equipo de Geko siempre estar\u00e1 contento de verte aqu\u00ed \ud83d\ude42<\/p>\n
- \n
- – El s\u00edntoma principal que ver\u00e1s es la repentina y completa ausencia de logs en Stackdriver<\/a>, los cuales deber\u00edan estar recibi\u00e9ndose -como de costumbre- desde los pods de tu cl\u00faster.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
<\/p>\n
- \n
- – Adem\u00e1s del hecho anterior, podr\u00e1s descubrir que ya no hay agentes de Fluentd<\/a> en tu cl\u00faster.\n\n
$ kubectl get daemonset -n kube-system | grep -i fluentd\r\n\r\n<\/pre>\n<\/div>\n<\/li>\n
- – Por otra parte todos los nodos de tu cl\u00faster tienen la etiqueta (\u00ablabel\u00bb) beta.kubernetes.io\/fluentd-ds-ready=true<\/strong>, la cual es requerida por los agentes de Fluentd para saber en qu\u00e9 nodos deben desplegarse.\n
\n$ kubectl get nodes\r\nNAME STATUS ROLES AGE VERSION\r\ngke-cluster-node-93c020-7rjq Ready none 14h v1.15.11-gke.15\r\ngke-cluster-node-93c020-9w22 Ready none 23h v1.15.11-gke.15\r\ngke-cluster-node-93c020-jdbt Ready none 47h v1.15.11-gke.15\r\ngke-cluster-node-93c020-jvcl Ready none 3h17m v1.15.11-gke.15\r\n\r\n$ kubectl describe node gke-cluster-node-93c020-7rjq | grep -i fluentd-ds-ready\r\n beta.kubernetes.io\/fluentd-ds-ready=true\r\n\r\n$ # Haz lo mismo para los nodos restantes para asegurar que todos ellos est\u00e1n adecuadamente etiquetados<\/pre>\n<\/div>\n<\/li>\n
- – Tu cl\u00faster de GKE est\u00e1 actualmente en la versi\u00f3n v1.15 o superior.<\/li>\n<\/ol>\n
2. Diagn\u00f3stico<\/h2>\n
Lo que est\u00e1 sucediendo es que Google est\u00e1 descatalogando a marchas forzadas el antiguo sistema de monitorizaci\u00f3n\/logging. El nuevo sistema que lo reemplaza se llama Cloud Operations for GKE<\/a> que (para nuestro caso) hace b\u00e1sicamente lo mismo. Una vez dicho eso, cabe mencionar que hay algunas diferencias que deber\u00e1s tener en cuenta cuando realices b\u00fasquedas (como por ejemplo cambios en los nombres de las m\u00e9tricas), y que todas ellas las encontrar\u00e1s en la gu\u00eda de migraci\u00f3n<\/a>.<\/p>\n
3. Tratamiento<\/h2>\n
Etiquetar los nodos del cl\u00faster<\/h3>\n
Si te encontraste en pasos previos que uno o varios de los nodos de tu cl\u00faster no est\u00e1n etiquetados, \u00a1hazlo ahora!<\/p>\n
\n$ kubectl label node $NODE_NAME beta.kubernetes.io\/fluentd-ds-ready=true<\/pre>\n<\/div>\n
Obt\u00e9n el nombre de tu cl\u00faster<\/h3>\n
Lista los cl\u00fasteres disponibles.<\/p>\n
\n$ gcloud container clusters list\r\nNAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS\r\nmy-cluster europe-east1-a 1.15.12-gke.2 34.35.36.37 n1-standard-2 1.15.11-gke.15 4 RUNNING\r\n<\/pre>\n<\/div>\n
Deshabilita el servicio de logging para tu cl\u00faster<\/h3>\n
Actualiza la configuraci\u00f3n de tu cl\u00faster para establecer el servicio de logging al valor none.<\/em><\/p>\n
\n$ gcloud container clusters update my-cluster --logging-service none<\/pre>\n<\/div>\n
Habilita de nuevo el servicio de logging para tu cl\u00faster<\/h3>\n
Actualiza la configuraci\u00f3n de tu cl\u00faster para volver a establecer el servicio de logging al que hay por defecto.<\/p>\n
\n$ gcloud container clusters update my-cluster --logging-service logging.googleapis.com<\/pre>\n<\/div>\n
ATENCI\u00d3N:<\/strong> Obtendr\u00e1s un mensaje de error inform\u00e1ndote que no es posible habilitarlo debido a la descatalogaci\u00f3n. Esta es la forma por la que finalmente nos dimos cuenta d\u00f3nde estaba el problema. Simplemente sigue adelante, vas en la direcci\u00f3n correcta.<\/p>\n
Verifica que el estado de la migraci\u00f3n es el esperado<\/h3>\n
Abre la secci\u00f3n de monitorizaci\u00f3n (monitoring) de interfaz web de GCP<\/a> y dir\u00edgete a la sub-secci\u00f3n de configuraci\u00f3n (Settings). Encontrar\u00e1s una pesta\u00f1a llamada \u00abKubernetes Migration Status\u00bb que deber\u00eda verse como a continuaci\u00f3n.<\/p>\n
<\/p>\nHabilitar completamente el servicio de loggin y monitorizaci\u00f3n para tu cl\u00faster<\/h3>\n
Abre la lista de cl\u00fasteres de GKE<\/a> haz clic en el nombre del cl\u00faster donde quieres configurar el nuevo sistema de logging. Una vez veas la configuraci\u00f3n del cl\u00faster, haz clic en el bot\u00f3n EDITAR como se muestra a continuaci\u00f3n.<\/p>\n
<\/p>\nDesliza hacia abajo hasta encontrar el par\u00e1metro Kubernetes Engine Monitoring<\/strong> y, haciendo clic en el desplegable, selecciona la opci\u00f3n Almacenamiento de registros y supervisi\u00f3n del sistema y las cargas de trabajo<\/strong> (System and workload logging and monitoring)<\/strong>.<\/span><\/span><\/p>\n
<\/p>\nIMPORTANTE: <\/strong>No olvides guardas los cambios usando el bot\u00f3n que hay al final.<\/p>\n
Y ya est\u00e1! Tu cl\u00faster volver\u00e1 a recibir de nuevo los logs!<\/h5>\n
<\/p>\n
Conclusi\u00f3n<\/h2>\n
Como probablemente ya sabr\u00e1s Google Cloud Platform est\u00e1 todav\u00eda en fase beta, por lo que habitualmente encontrar\u00e1s algunos cambios que har\u00e1n 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\u00fan vayan surgiendo, pero ten en cuenta que siempre estar\u00e1s luchando contra los problemas a ciegas.<\/p>\n
Hay una tercera opci\u00f3n (que podr\u00eda ser la primera), que consiste en consultar regularmente el blog de Geko<\/a> y verificar si ya nos hemos tratado con el problema que te est\u00e1s encontrando. El equipo de Geko siempre estar\u00e1 contento de verte aqu\u00ed \ud83d\ude42<\/p>\n
- – Por otra parte todos los nodos de tu cl\u00faster tienen la etiqueta (\u00ablabel\u00bb) beta.kubernetes.io\/fluentd-ds-ready=true<\/strong>, la cual es requerida por los agentes de Fluentd para saber en qu\u00e9 nodos deben desplegarse.\n
- – Adem\u00e1s del hecho anterior, podr\u00e1s descubrir que ya no hay agentes de Fluentd<\/a> en tu cl\u00faster.\n