Nota perev. : En la comunidad de Kubernetes, una tendencia llamada GitOps está ganando popularidad, como vimos personalmente al visitar KubeCon Europe 2019. Este término fue acuñado relativamente recientemente por el jefe de Weaveworks, Alexis Richardson, y significa el uso de herramientas familiares para desarrolladores (principalmente Git, de ahí el nombre mismo) para resolver problemas operativos. En particular, estamos hablando de explotar Kubernetes mediante el almacenamiento de sus configuraciones en Git y la implementación automática de cambios en el clúster. Matthias Jg habla sobre dos enfoques para este lanzamiento en este artículo.
El año pasado
(de hecho, formalmente esto sucedió en agosto de 2017 - aprox. Transl.) , Apareció un nuevo enfoque para implementar aplicaciones en Kubernetes. Se llama GitOps y se basa en la idea básica de que el seguimiento de la versión de implementación se realiza en un entorno seguro de repositorio de Git.
Las principales ventajas de este enfoque son las siguientes :
- Implementaciones de versiones e historial de cambios . El estado de todo el clúster se almacena en el repositorio de Git, y las implementaciones solo se actualizan mediante confirmaciones. Además, todos los cambios se pueden rastrear utilizando el historial de confirmación.
- Contragolpes utilizando comandos familiares de Git . Un simple
git reset permite descartar cambios en la implementación; los estados pasados siempre están disponibles. - Listo control de acceso . Por lo general, un sistema Git contiene muchos datos confidenciales, por lo que la mayoría de las empresas prestan especial atención a su protección. En consecuencia, esta protección se extiende a las operaciones con implementaciones.
- Políticas de despliegues . La mayoría de los sistemas Git inicialmente admiten políticas para diferentes sucursales; por ejemplo, solo las solicitudes de extracción pueden actualizar el maestro y otro miembro del equipo debe verificar y aceptar los cambios. Al igual que con el control de acceso, se aplican las mismas políticas a las actualizaciones de implementación.
Como puede ver, el método GitOps tiene muchas ventajas. Durante el año pasado, dos enfoques han ganado particular popularidad. Uno se basa en empujar, el otro en tirar. Antes de mirarlos, veamos cómo son las implementaciones típicas de Kubernetes.
Métodos de implementación
En los últimos años, se han establecido varios métodos y herramientas de implementación en Kubernetes:
- Basado en plantillas nativas de Kubernetes / Kustomize . Esta es la forma más fácil de implementar aplicaciones en Kubernetes. El desarrollador crea los archivos YAML básicos y los aplica. Para deshacerse de la constante reescritura de los mismos patrones, se desarrolló Kustomize (convierte los patrones de Kubernetes en módulos). Nota perev. : Kustomize se ha integrado en kubectl con el lanzamiento de Kubernetes 1.14 .
- Gráficos Helm . Los gráficos de timón le permiten crear conjuntos de plantillas, contenedores de inicio, sidecar'ov, etc., que se utilizan para implementar aplicaciones con opciones de configuración más flexibles que en el enfoque basado en plantillas. Este método se basa en archivos YAML de plantilla. Helm los llena con varios parámetros y luego los envía a Tiller, el componente del clúster, que los implementa en el clúster y permite actualizaciones y retrocesos. Lo importante es que, de hecho, Helm simplemente inserta los valores necesarios en las plantillas y luego los aplica de la misma manera que en el enfoque tradicional (para obtener más detalles sobre cómo funciona todo esto y cómo puede usarlo, lea nuestro artículo sobre Helm - aprox. .) . Hay una gran variedad de gráficos de Helm listos para usar que cubren una amplia gama de tareas.
- Herramientas alternativas Hay muchas herramientas alternativas. Todos ellos están unidos por el hecho de que convierten algunos archivos de plantilla en archivos YAML amigables para Kubernetes y luego los aplican.
En nuestro trabajo, utilizamos constantemente gráficos de Helm para herramientas importantes (ya que muchas de ellas ya están listas, lo que simplifica enormemente la vida) y los archivos YAML "limpios" de Kubernetes para implementar nuestras propias aplicaciones.
Tirar y empujar
En una de mis publicaciones de blog recientes,
presenté la herramienta
Weave Flux , que le permite enviar plantillas al repositorio de Git y actualizar la implementación después de cada confirmación o contenedor de inserción. Mi experiencia muestra que esta herramienta es una de las principales para promover el enfoque de extracción, por lo que a menudo me referiré a ella. Si desea saber más sobre cómo usarlo, aquí hay un
enlace al artículo .
NB! Todos los beneficios de usar GitOps se conservan para ambos enfoques.Enfoque basado en tracción
El enfoque de extracción se basa en el hecho de que todos los cambios se aplican desde dentro del clúster. Dentro del clúster, hay un operador que verifica regularmente los repositorios Git y Docker Registry asociados. Si se produce algún cambio en ellos, el estado del clúster se actualiza internamente. Por lo general, se considera que dicho proceso es muy seguro, ya que ningún cliente externo tiene acceso a los derechos de administrador del clúster.
Pros:- Ningún cliente externo tiene derecho a realizar cambios en el clúster; todas las actualizaciones se envían desde el interior.
- Algunas herramientas también le permiten sincronizar las actualizaciones de los gráficos Helm y vincularlas a un clúster.
- Docker Registry puede escanearse en busca de nuevas versiones. Si aparece una nueva imagen, el repositorio y la implementación de Git se actualizan a la nueva versión.
- Las herramientas de extracción se pueden distribuir en diferentes espacios de nombres con diferentes repositorios y permisos de Git. Gracias a esto, es posible utilizar el modelo multiempresa. Por ejemplo, el equipo A puede usar el espacio de nombres A, el equipo B puede usar el espacio de nombres B y un equipo de infraestructura puede usar el espacio global.
- Como regla general, las herramientas son muy livianas.
- En combinación con herramientas como la declaración de secretos sellados de Bitnami , los secretos se pueden almacenar cifrados en el repositorio de Git y recuperarse dentro del clúster.
- No hay comunicación con las canalizaciones de CD, ya que las implementaciones ocurren dentro del clúster.
Contras :
- La gestión de los secretos de implementación de los gráficos Helm es más complicada de lo habitual, ya que primero tiene que generarlos, por ejemplo, en secretos sellados, luego descifrarlos con un operador interno y solo después de que estén disponibles para la herramienta de extracción. Luego puede lanzar el lanzamiento en Helm con valores en secretos ya implementados. La forma más fácil es crear un secreto con todos los valores de Helm utilizados para la implementación, descifrarlo y confirmar en Git.
- Usando el enfoque pull, te encuentras atado a herramientas que operan en pull. Esto limita la capacidad de personalizar el proceso de implementación de implementación en el clúster. Por ejemplo, trabajar con Kustomize es complicado por el hecho de que debe ejecutarse antes de que las plantillas finales lleguen a Git. No digo que no pueda usar herramientas individuales, pero son más difíciles de integrar en el proceso de implementación.
Enfoque basado en empuje
En el enfoque de inserción, un sistema externo (principalmente canalizaciones de CD) comienza a implementarse en el clúster después de comprometerse con el repositorio de Git o en caso de ejecución exitosa de la canalización de CI anterior. En este enfoque, el sistema tiene acceso al clúster.
Pros :
- La seguridad está determinada por el repositorio de Git y la canalización de compilación.
- La implementación de gráficos de Helm es más fácil; hay soporte para los complementos de Helm.
- Los secretos son más fáciles de administrar, porque los secretos se pueden usar en canalizaciones, así como almacenarse en Git de forma encriptada (dependiendo de las preferencias del usuario).
- Falta de vinculación a una herramienta específica, ya que se puede usar cualquiera de sus tipos.
- Las actualizaciones de la versión del contenedor pueden ser activadas por la tubería de ensamblaje.
Contras :
- Los datos para acceder al clúster se encuentran dentro del sistema de compilación.
- La actualización de los contenedores de implementación es aún más fácil de hacer con el proceso de extracción.
- Depende mucho del sistema de CD, porque las tuberías que necesitamos probablemente estén escritas originalmente para Gitlab Runners, y luego el equipo decide cambiar a Azure DevOps o Jenkins ... y tendrá que migrar una gran cantidad de tuberías de compilación.
En pocas palabras: empujar o tirar?
Como de costumbre, cada enfoque tiene sus pros y sus contras. Algunas tareas son más fáciles de realizar con una y más difíciles con la otra. Al principio, pasé las implementaciones manualmente, pero después de encontrar varios artículos sobre Weave Flux, decidí implementar procesos GitOps para todos los proyectos. Para las plantillas básicas, resultó ser fácil, pero luego comencé a encontrar dificultades para trabajar con los gráficos de Helm. En ese momento, Weave Flux solo ofrecía una versión rudimentaria de Helm Chart Operator, pero incluso ahora algunas tareas son más complicadas debido a la necesidad de crear manualmente secretos y aplicarlos. Puede decir que el enfoque de extracción es mucho más seguro, ya que las credenciales del clúster no están disponibles fuera de él, y esto aumenta la seguridad tanto que cuesta un esfuerzo adicional.
Después de pensar un poco, llegué a la conclusión inesperada de que esto no es así. Si hablamos de componentes que requieren la máxima protección, esta lista incluirá el almacenamiento de secretos y sistemas CI / CD, repositorios Git. La información dentro de ellos es muy vulnerable y necesita la máxima protección. Además, si alguien ingresa a su repositorio Git y puede empujar el código allí, podrá desplegar lo que quiera (independientemente del enfoque elegido, será jalar o empujar) e infiltrarse en los sistemas de clúster. Por lo tanto, los componentes más importantes que requieren protección son el repositorio Git y los sistemas CI / CD, no las credenciales del clúster. Si tiene políticas y medidas de seguridad bien ajustadas para sistemas de este tipo, y las credenciales de clúster se recuperan en tuberías solo como secretos, la seguridad adicional del enfoque de extracción puede no ser tan valiosa como se pretendía originalmente.
Entonces, si el enfoque de extracción requiere más tiempo y no brinda una ganancia en seguridad, ¿no es lógico usar solo el enfoque de inserción? Pero alguien puede decir que en el enfoque de inserción está demasiado vinculado al sistema de CD y, tal vez, es mejor no hacerlo para facilitar las migraciones en el futuro.
En mi opinión (como siempre), debe usar lo que sea más adecuado para un caso particular o combinar. Personalmente, utilizo ambos enfoques: Weave Flux para implementaciones basadas en extracción que incluyen principalmente nuestros propios servicios, y un enfoque de inserción con Helm y complementos que simplifica la aplicación de cartas Helm al clúster y le permite crear fácilmente secretos. Creo que nunca habrá una solución única que sea adecuada para todos los casos, porque siempre hay muchos matices y dependen de la aplicación específica. Al mismo tiempo, recomiendo GitOps: simplifica enormemente la vida y mejora la seguridad.
Espero que mi experiencia en este tema ayude a determinar qué método es más adecuado para su tipo de implementación, y me complacerá saber su opinión.
PD Nota del traductor
En las desventajas del modelo de extracción, hay un punto sobre el hecho de que es difícil poner manifiestos renderizados en Git, sin embargo, no hay menos que la tubería de CD en el modelo de extracción vive por separado del despliegue y, de hecho, se convierte en una
tubería de categoría de
Aplicación Continua . Por lo tanto, se requerirán aún más esfuerzos para recopilar su estado de todas las implementaciones y de alguna manera dar acceso a los registros / estado, y preferiblemente con referencia al sistema de CD.
En este sentido, el modelo de empuje le permite dar al menos un cierto despliegue de garantía, ya que la vida útil de la tubería puede ser igual a la vida útil del despliegue.
Probamos ambos modelos y llegamos a las mismas conclusiones que el autor del artículo:
- El modelo pull es adecuado para nosotros para organizar actualizaciones de componentes del sistema en una gran cantidad de clústeres (consulte el artículo sobre addon-operator ).
- El modelo de inserción basado en CI de GitLab es muy adecuado para implementar aplicaciones que utilizan gráficos Helm. En este despliegue, el despliegue'ov dentro de las tuberías se supervisa utilizando la herramienta werf . Por cierto, en el contexto de nuestro proyecto, escuchamos el constante "GitOps" cuando discutimos los problemas apremiantes de los ingenieros de DevOps en nuestro stand en KubeCon Europe'19.
PPS del traductor
Lea también en nuestro blog: