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. 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!

La entrada GCP/GKE – Nuevo sistema de logging se publicó primero en Geko Cloud.

De vez en cuando, Google introduce nuevas características y cambios que a veces también obligan a los módulos de Terraform a actualizarse. En Geko, estábamos usando el módulo GKE para la implementación y administración de clústeres públicos en la versión 5.x. Hace unos días, cuando planeamos actualizar algunos parámetros, descubrimos que Google había eliminado la compatibilidad con el panel de control de Kubernetes. Estaba completamente en desuso y el módulo estaba fallando debido a ello, por lo que nos vimos obligados a actualizar el módulo para cumplir con las nuevas condiciones. Hubo hasta 3 actualizaciones de versiones principales disponibles, por lo que decidimos probarlo y usar la última. Sin embargo, no era una solución independiente, ya que requería gestionar las incoherencias del estado de Terraform.

El objetivo de este laboratorio es aprender cómo actualizar el módulo oficial Terraform destinado a implementar y administrar un clúster GKE público. Nos ocuparemos especialmente de los cambios de ruptura del módulo (kubernetes-engine.beta-public-cluster), y lograremos obtener el estado consistente que teníamos antes de la falla que precedió a la actualización.

Tiempo estimado para terminar este laboratorio: ~ 20 minutos

1. Eliminar los recursos anteriores

¡Se recomienda encarecidamente realizar una copia de seguridad de archivos tfstate antes de continuar!

Es especialmente importante eliminar todos los recursos conflictivos del tfstate de Terraform ya que están vinculados entre ellos como dependencias. El objetivo aquí es eliminar cualquier enlace obsoleto antes de importarlo nuevamente desde la «imagen» actual que ya se ha desplegado.

Los componentes principales en un clúster de Kubernetes son las redes (y subredes), el grupo de nodos y el clúster en sí. Centrémonos en ellos.

terraform state rm module.gke.google_container_cluster.primary
terraform state rm module.gke.google_container_node_pool.pools[0]
terraform state rm module.vpc.google_compute_network.network
terraform state rm module.vpc.google_compute_subnetwork.subnetwork[0]
terraform state rm module.vpc.google_compute_subnetwork.subnetwork[1]

2. Actualizar versiones

Una vez eliminados los estados anteriores, el siguiente paso es configurar la última versión los módulos requeridos. Para el módulo GKE, la última versión disponible a fecha de hoy es 8.1.0, pero se permite aplicar automáticamente actualizaciones menores («~>»).

Actualizar el módulo clúster GKE

 module "gke" {
   source  = "terraform-google-modules/kubernetes-engine/google//modules/beta-public-cluster"
-  version = "~> 5.0"
+  version = "~> 8.1"

Actualizar el módulo VPC

 module "vpc" {
-  source  = "github.com/terraform-google-modules/terraform-google-network?ref=v1.1.0"
+  source  = "github.com/terraform-google-modules/terraform-google-network?ref=v2.3.0"

Comprobar los nuevos recursos

Para saber si los nuevos recursos han experimentado un cambio de nombre (debido a la actualización de los módulos), se recomienda encarecidamente lanzar un plan de Terraform.

En este caso, se ha encontrado que la jerarquía interna de algunos módulos y también los índices de la lista han cambiado.

  module.gke.google_container_cluster.primary
  
- module.gke.google_container_node_pool.pools[0]
+ module.gke.google_container_node_pool.pools["default-node-pool"]

  module.vpc.google_compute_network.network
  
- module.vpc.google_compute_subnetwork.subnetwork[0]
+ module.vpc.module.subnets.google_compute_subnetwork.subnetwork["southamerica-east1/my-cluster-public"]

- module.vpc.google_compute_subnetwork.subnetwork[1]
+ module.vpc.module.subnets.google_compute_subnetwork.subnetwork["southamerica-east1/my-cluster-private"]

3. Importar los nuevos recursos

Ten en cuenta que la zona/región depende del tipo de clúster. Si es de zona, debe usar la zona maestra (por ejemplo, southamerica-east1-a). Por otro lado, si se trata de un clúster regional, debe usar la región (por ejemplo, southamerica-east1). El siguiente ejemplo supone un clúster regional ubicado en southamerica-east1, en el proyecto «my-project» y con el nombre de clúster «my-cluster». Los nombres de red se configuraron de acuerdo con el nombre del clúster, simplemente agregando los sufijos «private» y «public» a las subredes para diferenciarlos adecuadamente.

Ten en cuenta también la nueva jerarquía de módulos e indexación.

# Global vars
REGION="southamerica-east1"
PROJECT="my-project"
CLUSTER="my-cluster"

# Cluster
CLUSTER_LOCAL="module.gke.google_container_cluster.primary"
CLUSTER_REMOTE="${PROJECT}/${REGION}/${CLUSTER}"
terraform import $CLUSTER_LOCAL $CLUSTER_REMOTE

# Node pool
POOL_LOCAL="module.gke.google_container_node_pool.pools["default-node-pool"]"
POOL_REMOTE="${CLUSTER_REMOTE}/default-node-pool"
terraform import $POOL_LOCAL $POOL_REMOTE

# Subnetworks
BASE_SUBNET_LOCAL="module.vpc.module.subnets.google_compute_subnetwork.subnetwork"

## Public
PUBLIC_SUBNET_LOCAL="${BASE_SUBNET_LOCAL}["${REGION}/${CLUSTER}-public"]"
PUBLIC_SUBNET_REMOTE="${CLUSTER_REMOTE}-public"
terraform import $PUBLIC_SUBNET_LOCAL $PUBLIC_SUBNET_REMOTE

## Private
PRIVATE_SUBNET_LOCAL="${BASE_SUBNET_LOCAL}["${REGION}/${CLUSTER}-private"]"
PRIVATE_SUBNET_REMOTE="${CLUSTER_REMOTE}-private"
terraform import $PRIVATE_SUBNET_LOCAL $PRIVATE_SUBNET_REMOTE

# Network
NETWORK_LOCAL="module.vpc.module.vpc.google_compute_network.network"
NETWORK_REMOTE="${PROJECT}/${CLUSTER}"
terraform import $NETWORK_LOCAL $NETWORK_REMOTE

 4. Actualizar parámetros

Es muy probable que encuentres que, después de lanzar un plan de Terraform, el recurso google_container_cluster todavía necesite actualizarse debido a un cambio en el parámetro de subred. Las nuevas claves de subred han hecho que los índices cambien su orden. Simplemente edita el módulo GKE para reemplazar el parámetro subnetwork como se muestra a continuación.

- subnetwork = module.vpc.subnets_names[0]
+ subnetwork = module.vpc.subnets_names[1]

Conclusión

Como habrás visto anteriormente, a veces, al depender de terceros, puede suceder que se introduzca un cambio importante y tengas problemas para recuperar el servicio nuevamente. Además de esto, la solución podría introducir daños colaterales que requerirán subsoluciones adicionales. En este caso particular con respecto a Terraform, lidiar con estados inconsistentes no es realmente común ni recomendado, pero es el único método que tiene disponible para resolverlos en su conjunto de herramientas.

Espero que hayas disfrutado de este post y te animo a que revises nuestro blog para leer otrosposts que puedan ser de tu interés. No dudes en contactarnos si deseas que te ayudemos en tus proyectos.

¡Nos vemos en la próxima entrada!

La entrada Actualización del módulo Terraform en los clústeres públicos de GKE se publicó primero en Geko Cloud.