Kapitan al timón de Kubernetes

Conoce a Kapitan Le ayuda a aportar belleza y orden a su configuración de Kubernetes .

Kapitan se gana una reputación gracias a las críticas de los usuarios satisfechos y, por lo tanto, prescinde de una extensa documentación y un costoso marketing. Tenemos suficientes estrellas y un par de menciones de los bloggers y predicadores de Kubernetes. Kapitan incluso se convirtió en el protagonista de un capítulo entero en el libro . Lo más importante, atrajo la atención de varias compañías prometedoras, porque Kapitan, como nadie más, es capaz de desentrañar la configuración vinculada al nudo marino .

En kubernetes.slack.com #kapitan logró reunir una comunidad pequeña pero dedicada (¡únete!), Así que estamos orgullosos de nuestro trabajo :)

Muchos todavía creen que Kapitan es una mezcla de jsonnet y jinja, pero se equivocan.
En esta publicación, te diré cómo Kapitan gestiona los despliegues de Kubernetes, pero en general es capaz de más que eso. Esto es importante: Kapitan es universal y no está fijado en un Kubernetes. Kubernetes es simplemente uno de los muchos usos.

Esto no es una guía (aunque prometo una guía también). Solo quiero decirle por qué lo hicimos y qué problemas con las implementaciones de configuraciones de Kubernetes debería resolver.

Lo que no me gustó

Comencé a experimentar con Kubernetes en 2015 e inmediatamente me enamoré.
Es cierto que hay varios inconvenientes que no quiero soportar:

• Contexto Para mí, este es uno de los conceptos más difíciles de entender Kubernetes , y uno de los más peligrosos. El contexto se refiere al cliente, es difícil de entender, se le llama confusamente y crea confusión al ejecutar los comandos de kubectl . ¡Odio los contextos en kubectl!
• Configuración anidada detallada (¡yaml!) . Tuve que sudar para descubrir cada nivel de configuración de YAML en el manifiesto. ¿Cuál es el punto de repetir etiquetas dos o tres veces en varios lugares?
• Un desastre con equipos imperativos y declarativos . Se anima a los recién llegados a Kubernetes a aprender por equipos imperativos, aunque está claro que las personas normales no los usan. En mi opinión, es más difícil adaptar a Kubernetes a la estrategia de implementación adecuada para su empresa. Spoiler: No existe una única "estrategia correcta".
• Configuración de tiempo de ejecución . Jesse Suen tiene razón cuando aconseja no pasar los parámetros de configuración a la línea de comando del timón (o kubectl y otros por el estilo). Con los parámetros, el mismo comando se puede ejecutar de manera diferente cada vez.
• Configuración de la aplicación Aprendimos a manejar los manifiestos de yaml en Kubernetes, somos geniales. Eso es justo debajo e Implementar: este es un recipiente vacío. Todavía tiene que hacer flotar la aplicación con toda su configuración.
• Los desarrolladores quieren unas vacaciones , y el flujo de trabajo en Kubernetes todavía es un poco lento. Los fanáticos de Kubernetes están obligando a todos a hacerlo allí mismo. ¿Es necesario? Obedecer Kelsey Hightower!
• Operadores Tengo sentimientos encontrados por ellos, así que por ahora deja este tema :) Solo puedo decir que a menudo se abusa de ellos.
• Idempotencia . Más bien, su ausencia. Si sumamos todas las deficiencias anteriores, obtenemos flujos de trabajo insuficientemente idempotentes, lo cual es triste para Kubernetes.

Que hacer

Traté de resolver estos problemas y armé un pequeño sistema de plantillas que usaba j2cli y un par de scripts bash para administrar las configuraciones de Kubernetes.

El sistema puso todo en el archivo environmentA.yaml y lo usó en la plantilla Jinja2. La implementación de aplicaciones de estilo microservicio desde varios componentes fue posible con un simple comando:

bin/apply.sh environments/environmentA.yaml 

Genial! Yaml tenía que ver con el despliegue. Es muy conveniente, porque podría usar el mismo archivo como fuente de información para otra cosa. Digamos por ... ¡ guiones bash !

Descubrí cómo importar valores de yaml a scripts para ejecutar comandos similares:

 bin/create_kafka_topics.sh environments/environmentA.yaml 

Y luego todo se salió de control de una vez :

• No pude hacer nada con la estructura en el archivo yaml. Era una mezcla de los mismos campos, valores, configuración confusa.
• Nunca sabrá cómo comportarse la implementación en el entorno hasta que lo intente. A menudo, esto se debió a cambios en las plantillas de jinja2 debido a un nuevo valor de inventario (por ejemplo, feature_X) que no funcionó en entornos donde esta función no está definida.
• El mismo problema con los scripts: si no lo intentas, no lo sabes.
• A veces, Kubernetes cambió tan rápido que me molestó cambiar constantemente los manifiestos para diferentes versiones, especialmente jugando con anotaciones a los valores.
• Factor externo : el equipo de desarrollo cambió de archivos de configuración a parámetros de línea de comando. Un cambio tan pequeño nos confundió todas las cartas, y tuvimos que pensar en una nueva solución.
• Lo más importante : ¡crear plantillas de yaml con Jinja (o plantillas Go) NO ES DIVERTIDO! Luego tuvimos un enigma: “ ¿Qué parece texto, se lee como texto, huele a texto, pero no a texto? ". O, como Lee Briggs lo dijo acertadamente: “ ¿Por qué demonios somos plantilla yaml? "

Kapitan: convertirse

Reunimos toda nuestra amarga experiencia y, junto con Ricardo Amaro, comenzamos a fantasear con un sistema de gestión de configuración ideal. Entonces todavía no teníamos una imagen clara, pero sabíamos que amamos y que no amamos.

Amor

• Git
• Patrones en general: datos / valores separados de patrones.
• Valores separados para diferentes aspectos (aplicación, Kubernetes, tiempo de ejecución ...).
• Enfoque orientado a objetos.
• YAML simplificado como una interfaz donde ocultar la complejidad de Kubernetes.
• Una comprensión clara de lo que está sucediendo y por qué.
• Reutilización de valores en diferentes componentes.
• Y los scripts deberían tener acceso a los valores.

No nos gusta :

• Contextos de Kubectl
• Motores de plantillas de texto para crear yaml.
• Conteo de sangría: {{ toYaml .Values.resources | indent 10 }} {{ toYaml .Values.resources | indent 10 }} .
• Magia: todo debe ser claro y claro. No hay trucos
• Gestión manual de contraseñas y secretos de la aplicación.
• Enfoque Tiller: Queríamos controlar el uso de manifiestos.
• Enfoque Git-crypt: los secretos en el disco no están encriptados.
• Tubería de plantilla directamente a kubectl.
• Pasando opciones de línea de comando.

Y luego sucedieron dos cosas :

1. Descubrimos la jsonnet de Dave Cunningham para crear plantillas de yaml / json en un lenguaje orientado a objetos.
2. Gustavo Buriola nos mostró la reclasificación , y sin él no habríamos ido muy lejos.

Ricardo Amaro se puso a trabajar y pronto todo el equipo se sentó en Kapitan: algunos trabajaron en la funcionalidad básica, otros en su uso en nuestros proyectos internos. Gestión de secretos, soporte gpg \ kms, funciones definidas por el usuario: ahora Kapitan es un producto completo que hace más de lo prometido.

Quien es Kapitan?

Kapitan está tratando de resolver todos (o casi todos) los problemas de los que hablé.

Desde un punto de vista técnico, Kapitan es muy simple:

• Inventario : una colección jerárquica de valores que describe la implementación basada en yaml. Basado en reclases. Como hiera.
• Motores de plantilla : ahora es Jinja2, Jsonnet, Kadet. Ellos hacen un inventario y crean archivos (yaml, json, documentación o scripts bash).
• Secretos : secretos de plantillas, y Kapitan se ocupará de ellos.

Estamos usando jsonnet para crear manifiestos y Jinja para hacer el resto.

A veces, las personas se quejan de que el archivo jsonnet es completamente diferente del mismo yaml, por lo que les resulta difícil cambiar a jsonnet.

Intentamos resolver este problema con Kadet envolviendo yaml en Python. Tome su yaml favorito como base y agréguele Python.

¡Considera esto un exoesqueleto de Python para yaml! De alguna manera hablaré sobre esto.

En el flujo de trabajo, Kapitan muestra inmediatamente el personaje:

• Libertad de elección : no imponemos ningún proceso de trabajo y tecnología, pero generalmente trabajamos en los principios que se describen a continuación. De hecho, Kapitan puede usarse como quieras. No es necesario que use git, no debe compilar archivos en él, ¡e incluso puede hacerlo sin jsonnet! Haz lo que quieras.
• GitOps hasta el hueso: todo en git, todo en una luz maestra que refleja nuestra intención.
• Declarabilidad : Kapitan agradece la compilación de plantillas de manifiesto en representaciones específicas. Y compilas tus guiones.
• Contexto controlado : utilizamos scripts compilados para simplificar nuestro trabajo, por ejemplo, al establecer contextos y configurar clústeres.
  Configuración de Kubernetes: compiled/target_A/setup/setup.sh
  Aplicar cambios: compiled/target_A/setup/apply.sh
• Idempotencia : Kapitan le permite cambiar plantillas y herramientas de refactorización de código. Los manifiestos y el código compilados no cambiarán sin su comando, por lo que no tiene nada que temer al refactorizar.
• Causa y efecto : estamos a favor de un flujo de trabajo donde los cambios en el inventario o las plantillas y los archivos compilados se incluyen en una solicitud de fusión. Por lo tanto, el revisor podrá evaluar sus cambios y sus consecuencias reales. Es bueno saber si un cambio en la plantilla afectará a uno, dos o más objetivos.
• Y finalmente : Kapitan no está apegado a Kubernetes. Simplemente crea archivos. El despliegue de cambios implicó kubectl . Solo damos un shell para que los comandos se ejecuten de manera consistente.

¿Lo necesito?

Dejémoslo claro : probablemente no necesites Kapitan (todavía).

Pero todo depende de lo que intente hacer y de lo complicado que sea su sistema.

Kapitan es una poderosa herramienta de inversión. Úselo en escenarios complejos donde tiene que implementar un montón de aplicaciones en un montón de clústeres.

Si tiene aplicaciones estándar, solo está aprendiendo Kubernetes o ya está satisfecho con su flujo de trabajo, entonces Helm o su alternativa actual funcionarán.

Me imagino a Helm como apto para Kubernetes , y Kapitan es algo así como Puppet .

En la próxima publicación daré ejemplos específicos y describiré en detalle el inventario. Escriba sobre lo que quiere saber o con lo que está de acuerdo / en desacuerdo en esta publicación.

Gracias a Jacek Gruzewski .