En DoiT International trabajamos con clientes de todos los tamaños y, cada cierto tiempo, detectamos problemas comunes, sobre todo entre los clientes de mayor escala. Queremos compartir un problema reciente al actualizar GKE de Google (Kubernetes administrado), por si estás planificando tus actualizaciones o te topas con algo similar.
Síntomas
Vale la pena aclarar que no todos los clientes lo presentan, pero estos son los síntomas que hemos observado:
- tras la actualización, la CLI de kubectl no logra interactuar con el cluster (el API-Server no responde)
- el proceso de actualización parece quedarse "colgado" y no se completa después de más de 20 minutos
- aparece un mensaje de error en la consola o en los logs con un texto similar a: "All cluster resources were brought up, but: component "kube-apiserver" from endpoint "gke-XXXXXXXX-XXXXXXX" is unhealthy."
Diagnóstico de riesgo
Aunque no le ocurre a todo el mundo, los puntos en común que hemos observado son:
- Versión del cluster de GKE inferior a 1.16
- Cluster zonal (master de zona única para el control plane)
- Workloads "conversadores" que interactúan de forma continua con el API-Server, como Istio, Flux o ArgoCD
- Actualizaciones entre versiones como 1.12 -> 1.13, 1.13 -> 1.14, 1.14 -> 1.15, 1.15 -> 1.16 (normalmente no se observa en actualizaciones de parches)
¿A quiénes podría afectar?
Insistimos en que hasta ahora solo lo hemos visto en unos pocos clientes, y la mayoría encaja en ese perfil: clusters zonales y workloads pesados que saturan el API-Server, lo que hace que tarde demasiado en pasar los health checks durante las actualizaciones y termine en un estado "colgado". Esperamos que esta información te sirva tanto para planificar futuras actualizaciones de versión como para diagnosticar problemas actuales.
Cómo solucionarlo
Caso de soporte con Google para ampliar el timeout del health check
Si ya estás presentando este problema, pero tus worker nodes siguen sirviendo tráfico (solo que sin acceso de kubectl al control plane), puedes abrir un caso con Google Support o con tu partner de soporte técnico (ojalá sea DoiT International) para ampliar el timeout del health check a 3 minutos. Así se le da más tiempo al API-Server para recuperarse y se evita un ciclo de health checks fallidos.
Reduce el tamaño del node pool y la carga sobre el API-Server
Si puedes asumir un posible downtime de los worker nodes, para aliviar la presión sobre el API-Server puedes desactivar los workloads "conversadores" y reducirlos por un tiempo, o directamente escalar el node pool a 0, dejar que se complete la actualización y volver a escalarlo después.
Otras posibles causas
Algunos de nuestros engineers se han topado con escenarios en los que el control plane quedaba inaccesible por una race condition provocada por la tabla netfilter/conntrack de Linux. Esto ya se corrigió, pero las versiones más antiguas eran susceptibles.
Solución a largo plazo
Los engineers de Google ya conocen el problema y tienen prevista una corrección durante el próximo mes para la versión 1.16 o posterior (actualización manual). Al momento de publicar este blog, no hay un enlace público al issue tracker.
Migra tu cluster de zonal a regional
Lamentablemente, no existe un "botón mágico" para migrar un cluster de zonal a regional, pero uno de nuestros cloud architects escribió un artículo que describe un enfoque para hacerlo con una herramienta open-source muy popular: Velero.