Actualizar tu cluster de GKE puede toparse con obstáculos inesperados. Este artículo analiza un caso real en el que una actualización aparentemente sencilla a la versión 1.27 quedó bloqueada por una "llamada a una API obsoleta".
GKE pausa las actualizaciones automáticas
Cuando GKE detecta el uso de una función o API obsoleta, pausa las actualizaciones automáticas para evitar que tu cluster termine en un estado defectuoso. Las actualizaciones a la siguiente versión menor de Kubernetes se pausan, pero GKE sigue aplicando parches al cluster dentro de la versión menor actual.
Si pasados 30 días GKE no detecta uso de la función obsoleta ni llamadas a APIs obsoletas, el cluster se actualiza automáticamente, siempre que la siguiente versión menor sea la versión por defecto del release channel del cluster.
Si GKE sigue detectando uso de la función obsoleta, mantiene el cluster en su versión menor actual hasta la fecha de end of life de esa versión. Una vez alcanzada esa fecha —que puedes consultar en el Release Schedule—, el cluster se actualiza automáticamente a la siguiente versión menor y el entorno podría verse afectado, ya que la función eliminada sigue en uso.
Actualización de GKE bloqueada
En este caso, GKE identificó una llamada a una API obsoleta como el motivo para impedir la actualización desde la versión 1.26. Pese a revisar el cluster, no había rastro del culpable: un "horizontalPodAutoscaler" que usaba una API obsoleta.
Pasos de la investigación
GKE Insights: Aunque GKE Insights mostraba la llamada a la API obsoleta (
horizontalPodAutoscalerv2beta2) y un user agent ("v2.3.0"), este último no aportaba información útil.API obsoleta: Al revisar la lista de APIs obsoletas de la versión 1.27, se observa que el HPA v2beta2 no estará disponible en clusters que ejecutan Kubernetes 1.26.
Admin Activity Audit Logs: La primera vía recomendada es localizar a los clientes API que realizan llamadas de escritura a la API obsoleta mediante la consulta de logs que aparece abajo. Para ejecutarla se requiere el rol roles/logging.viewer.
resource.type="k8s_cluster"
labels."k8s.io/removed-release"="1.26"
protoPayload.authenticationInfo.principalEmail:("system:serviceaccount" OR "@")
protoPayload.authenticationInfo.principalEmail!~("system:serviceaccount:kube-system:")
- Data Access Audit Logs : El siguiente paso es ubicar a los clientes API que hacen llamadas de lectura a APIs obsoletas. Primero hay que habilitar Kubernetes data read y Admin read. También puede ser necesario el rol roles/logging.privateLogViewer para poder ver los logs.
El culpable al descubierto
Tras esperar a que se poblaran los logs, apareció el culpable: ¡una versión desactualizada (2.3.0) de kube-state-metrics! Kube-state-metrics, un servicio de monitoreo para objetos de Kubernetes, estaba haciendo llamadas "list" a la API v2beta2 obsoleta, lo que disparaba el bloqueo de la actualización. Este caso deja claro lo interconectados que pueden estar los entornos cloud.
Si revisas el código fuente, podrás ver con exactitud desde dónde se origina la llamada.
La solución
Actualizar kube-state-metrics a una versión que ya no use la API obsoleta resolvió el problema y dejó el camino libre para una actualización fluida de GKE.
Conclusión
- Filtro de exclusión del bucket de logging: Revisa el filtro de exclusión del bucket de logging para asegurarte de que los data access audit logs no estén excluidos y así agilizar la investigación.
- Mantente al día con los cambios de API: Monitorea de forma proactiva los cambios en las APIs de Kubernetes para anticipar posibles bloqueos en las actualizaciones.
- Versiones estáticas vs. release channels: Evalúa los pros y contras entre versiones estáticas (estabilidad) y release channels (parches de seguridad automáticos) al definir tu estrategia de actualización.
- Gestiona las actualizaciones de forma estratégica: Aprovecha las exclusiones de auto-upgrade y de mantenimiento para controlar los tiempos de actualización, y considera permitir parches críticos de seguridad.
- Ten en cuenta el costo de los logs: Habilitar los data access audit logs puede generar costos adicionales. Evalúa tus necesidades antes de mantenerlos activos durante períodos prolongados.
Con estos consejos podrás afrontar las actualizaciones de GKE con mayor confianza y reducir al mínimo las interrupciones en tus operaciones cloud.
Si todavía no conoces a DoiT International, vale la pena que nos eches un vistazo. Nuestro equipo está listo para conocer más sobre ti y tus necesidades de cloud engineering. Formado exclusivamente por talento senior de engineering, nos especializamos en consultoría avanzada de cloud, diseño de arquitectura y asesoría en debugging. ¡Contáctanos y conversemos!
¡Espero que este artículo te haya resultado útil! Si tienes alguna duda, déjanos un comentario más abajo.