Kubernetes: cómo detectar y gestionar APIs obsoletas de forma automática

A medida que Kubernetes evoluciona y suma funcionalidades, sus APIs también tienen que evolucionar para acompañar esos cambios. Existen reglas que buscan garantizar la compatibilidad y la estabilidad¹. No pasa en cada release, pero tarde o temprano vas a tener que usar la nueva versión y formato de la API, porque la anterior dejará de tener soporte.

Algunas APIs obsoletas se mantuvieron durante las últimas versiones de K8s y, finalmente, se eliminan por completo en Kubernetes 1.16. En concreto, los siguientes API Groups y versiones:

• Deployment — extensions/v1beta1, apps/v1beta1 y apps/v1beta2
• NetworkPolicy — extensions/v1beta1
• PodSecurityPolicy — extensions/v1beta1
• DaemonSet — extensions/v1beta1 y apps/v1beta2
• StatefulSet — apps/v1beta1 y apps/v1beta2
• ReplicaSet — extensions/v1beta1, apps/v1beta1 y apps/v1beta2

Si intentas crear un recurso usando alguna de estas en 1.16, la operación simplemente fallará.

Puedes revisar a mano todos tus manifiestos, pero eso te puede llevar muchísimo tiempo. Es fácil que se te escape alguno y se vuelve poco práctico cuando hay varios equipos haciendo deploy al cluster, o cuando los manifiestos actuales no están todos en un mismo lugar. Ahí es donde entra Kube-No-Trouble, también conocido como kubent.

Normalmente no se puede acceder a la información sobre qué versión de la API se usó para crear un recurso, ya que el recurso siempre se convierte y se almacena internamente en la versión de almacenamiento preferida. Sin embargo, si usas kubectl o Helm para desplegar tus recursos, el manifiesto original también se guarda dentro del cluster y podemos sacarle provecho².

La forma más sencilla de instalarlo es:

sh -c "$(curl -sSL 'https://git.io/install-kubent')"

Esto instalará la última versión de kubent en /usr/local/bin ³.

Configura el contexto actual de kubectl para que apunte al cluster que quieres revisar y ejecuta la herramienta kubent:

Fig. 1: Ejemplo de salida de una ejecución de kubent

Kubent se conecta a tu cluster, recupera todos los recursos que podrían verse afectados, los analiza e imprime un resumen de los que sí lo están.

También puedes usar el flag -f json para obtener la salida en formato JSON, algo más cómodo si quieres integrarlo en tu pipeline de CI/CD o procesar los resultados después. Encontrarás más detalles sobre las opciones de configuración disponibles en el README del repo doitintl/kube-no-trouble.

En algunos casos basta con cambiar el apiVersion en tu manifiesto, pero en otros la estructura puede haber cambiado y habrá que ajustarla. Además, ten en cuenta que muchos valores por defecto cambiaron entre versiones⁴, por lo que cambiar solo el apiVersion y aplicar el mismo manifiesto te daría un resultado distinto. Por ejemplo, el updateStrategy.type de StatefulSet pasó de OnDelete a RollingUpdate, lo que cambia bastante el comportamiento.

El comando kubectl convert, que se usaba antes, ahora está obsoleto y puede no convertir correctamente tus recursos respecto a los valores por defecto que mencionamos.

Probablemente la mejor opción sea simplemente aplicar los recursos (ya los tienes si los detectaste con kubent) y obtener la nueva versión desde la API. Así te aseguras de que el recurso se transforme correctamente a la nueva versión. Habrás notado que kubectl no es del todo determinista respecto a la versión que devuelve. Para solicitar una versión específica de la API, usa la forma completa:

kubectl get ingress.v1beta1.extensions -o yaml

Ojalá esto te ayude a detectar y gestionar el uso de APIs obsoletas en tus clusters de Kubernetes antes de que te causen algún problema.

La herramienta kubent está aún en una fase muy temprana y me encantaría conocer tus comentarios, sugerencias y si te resulta útil. ¡Buen viento! ⛵⛵⛵

• [1] El documento Deprecation Policy de Kubernetes regula cómo distintas partes del sistema pueden quedar obsoletas y ser eliminadas.
• [2] Esto aparece como la anotación kubectl.kubernetes.io/last-applied-configuration en el caso de kubectl, o como un ConfigMap o Secret en el caso de Helm.
• [3] Si, igual que yo, no confías en scripts aleatorios que alguien publica en un blog, descarga el último release para tu plataforma y descomprímelo donde prefieras.
• [4] Un buen artículo sobre el tema es Kubernetes 1.16 API deprecations and changed defaults de David Schweikert.

Referencias adicionales:

• Kube-No-Trouble — repo de kubent en GitHub — https://github.com/doitintl/kube-no-trouble
• Deprecated APIs Removed In 1.16: Here's What You Need To Know, post de Vallery Lancey — https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/