En esta página, se proporciona un punto de partida para ayudarte a planificar y diseñar canalizaciones de CI/CD GitOps para Kubernetes. GitOps, junto con herramientas como Config Sync, ofrece beneficios como una mayor estabilidad del código, mejor legibilidad y automatización.
GitOps es un enfoque de rápido crecimiento para administrar la configuración de Kubernetes a gran escala. Según los requisitos de tu canalización de CI/CD, existen muchas opciones para diseñar y organizar el código de configuración y de la aplicación. Si aprendes algunas prácticas recomendadas de GitOps, puedes crear una arquitectura estable, bien organizada y segura.
Esta página está destinada a administradores, arquitectos y operadores que desean implementar GitOps en su entorno. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas comunes de los usuarios de GKE.
Organiza tus repositorios
Cuando configures tu arquitectura de GitOps, separa tus repositorios según los tipos de archivos de configuración almacenados en cada uno. En un nivel alto, puedes considerar al menos cuatro tipos de repositorios:
- Es un repositorio de paquetes para grupos de configuraciones relacionadas.
- Es un repositorio de la plataforma para la configuración en toda la flota de clústeres y espacios de nombres.
- Es un repositorio de configuración de la aplicación.
- Un repositorio de código de la aplicación
En el siguiente diagrama, se muestra el diseño de estos repositorios:
En la figura 2:
- Los equipos de desarrollo envían código para las aplicaciones y las configuraciones de las aplicaciones a un repositorio.
- El código de las apps y las configuraciones se almacena en el mismo lugar, y los equipos de aplicaciones tienen control sobre estos repositorios.
- Los equipos de aplicaciones envían código a una compilación.
Usa un repositorio de paquetes privado y centralizado
Usa un repositorio central para paquetes públicos o internos, como gráficos de Helm,para ayudar a los equipos a encontrar paquetes. Por ejemplo, si el repositorio está estructurado de forma lógica o contiene un readme, usar repositorios de paquetes privados y centralizados puede ayudar a los equipos a encontrar información rápidamente. Puedes usar servicios como Artifact Registry o repositorios de Git para organizar tu repositorio central.
Por ejemplo, el equipo de la plataforma de tu organización puede implementar políticas en las que los equipos de aplicaciones solo puedan usar paquetes del repositorio central.
Puedes limitar los permisos de escritura del repositorio a una pequeña cantidad de ingenieros. El resto de la organización puede tener acceso de lectura. Te recomendamos que implementes un proceso para promover paquetes en el repositorio central y difundir actualizaciones.
Si bien administrar un repositorio central puede agregar cierta sobrecarga adicional, ya que alguien debe mantenerlo y se agrega un proceso adicional para los equipos de aplicaciones, este enfoque tiene muchos beneficios:
- Un equipo central puede optar por agregar paquetes públicos con una cadencia definida, lo que ayuda a evitar que se interrumpan por problemas de conectividad o rotación ascendente.
- Una combinación de revisores humanos y automatizados puede verificar si los paquetes tienen problemas antes de que estén disponibles para el público.
- El repositorio central proporciona una forma para que los equipos descubran qué se usa y qué se admite. Por ejemplo, los equipos pueden encontrar la implementación estándar de Redis almacenada en el repositorio central.
- Puedes automatizar los cambios en los paquetes upstream para garantizar que cumplan con los estándares internos, como los valores predeterminados, la adición de etiquetas y los repositorios de imágenes de contenedores.
Crea repositorios de WET
WET significa "Escribe todo dos veces". Se diferencia de DRY, que significa "No te repitas". Estos enfoques representan dos tipos diferentes de archivos de configuración:
- Configuraciones DRY, en las que un solo archivo de configuración se somete a una acción de transformación para propagar campos con diferentes valores para diferentes entornos. Por ejemplo, podrías tener una configuración de clúster compartida que se complete con una región diferente o con diferentes parámetros de configuración de seguridad para diferentes entornos.
- Configuraciones WET (o, a veces, "completamente hidratadas"), en las que cada archivo de configuración representa el estado final.
Si bien los repositorios WET pueden generar algunos archivos de configuración repetidos, tienen los siguientes beneficios para un flujo de trabajo de GitOps:
- Es más fácil para los miembros del equipo revisar los cambios.
- No se requiere ningún procesamiento para ver el estado previsto de un archivo de configuración.
Realiza pruebas antes cuando valides la configuración
Esperar hasta que el Sincronizador de configuración comience la sincronización para verificar si hay problemas puede generar confirmaciones de Git innecesarias y un ciclo de retroalimentación prolongado. Se pueden encontrar muchos problemas antes de que se aplique una configuración a un clúster con las funciones de validación de kpt.
Si bien debes agregar herramientas y lógica adicionales a tu proceso de confirmación, realizar pruebas antes de aplicar las configuraciones tiene los siguientes beneficios:
- Mostrar los cambios de configuración en una solicitud de cambio puede ayudar a evitar que los errores lleguen a un repositorio.
- Reduce el impacto de los problemas en las configuraciones compartidas.
Usa carpetas en lugar de ramas
Usa carpetas para las variantes de los archivos de configuración en lugar de ramas. Con las carpetas, puedes usar el comando tree para ver las variantes. Con las ramas, no puedes saber si la diferencia entre una rama de producción y una de desarrollo es un cambio de configuración próximo o una diferencia permanente entre cómo deberían verse los entornos de prod y dev.
La principal desventaja de este enfoque es que el uso de carpetas no te permite promover cambios de configuración con una solicitud de cambio a los mismos archivos. Sin embargo, usar carpetas en lugar de ramas tiene los siguientes beneficios:
- Es más fácil descubrir carpetas que ramas.
- Es posible comparar carpetas con muchas herramientas de CLI y GUI, mientras que la comparación de ramas es menos común fuera de los proveedores de Git.
- Con las carpetas, es más fácil diferenciar entre las diferencias permanentes y las que no se promocionan.
- Puedes implementar cambios en varios clústeres y espacios de nombres en una sola solicitud de cambio, mientras que las ramas requieren varias solicitudes de cambio a diferentes ramas.
Minimiza el uso de ClusterSelectors
ClusterSelectors te permite aplicar ciertas partes de una configuración a un subconjunto de clústeres. En lugar de configurar un objeto RootSync o RepoSync, puedes modificar el recurso que se aplica o agregar etiquetas a los clústeres. Si bien esta es una forma liviana de agregar atributos a un clúster, a medida que aumenta la cantidad de ClusterSelectors con el tiempo, puede resultar complicado comprender el estado final del clúster.
Dado que el Sincronizador de configuración te permite sincronizar varios objetos RootSync y RepoSync a la vez, puedes agregar la configuración pertinente a un repositorio independiente y, luego, sincronizarla con los clústeres que desees. Esto facilita la comprensión del estado final del clúster, y puedes ensamblar las configuraciones del clúster en una carpeta en lugar de aplicar esas decisiones de configuración directamente en el clúster.
Evita administrar trabajos con el Sincronizador de configuración
En la mayoría de los casos, los trabajos y otras tareas situacionales deben ser administrados por un servicio que controle su administración del ciclo de vida. Luego, puedes administrar ese servicio con Sincronizador de configuración, en lugar de los trabajos en sí.
Si bien el Sincronizador de configuración puede aplicar trabajos por ti, los trabajos no son adecuados para las implementaciones de GitOps por los siguientes motivos:
Campos inmutables: Muchos campos de Job son inmutables. Para cambiar un campo inmutable, el objeto debe borrarse y volver a crearse. Sin embargo, Sincronizador de configuración no borra el objeto a menos que lo quites de la fuente.
Ejecución no intencional de trabajos: Si sincronizas un trabajo con el Sincronizador de configuración y, luego, se borra del clúster, el Sincronizador de configuración considera que hay una desviación del estado elegido y vuelve a crear el trabajo. Si especificas un tiempo de tiempo de actividad (TTL) del trabajo, el Sincronizador de configuración borra automáticamente el trabajo y lo vuelve a crear y reiniciar automáticamente hasta que lo borres de la fuente de información.
Problemas de reconciliación: Por lo general, Sincronizador de configuración espera a que los objetos se reconcilien después de aplicarse. Sin embargo, los objetos Job se consideran conciliados cuando comienzan a ejecutarse. Esto significa que el Sincronizador de configuración no espera a que se complete el trabajo antes de seguir aplicando otros objetos. Sin embargo, si el trabajo falla más adelante, se considera que no se pudo conciliar. En algunos casos, esto puede impedir que se sincronicen otros recursos y provocar errores hasta que lo corrijas. En otros casos, la sincronización podría completarse correctamente y solo fallaría la conciliación.
Por estos motivos, no recomendamos sincronizar los trabajos con Sincronizador de configuración.
Usa repositorios no estructurados
El Sincronizador de configuración admite dos estructuras para organizar un repositorio: no estructurada y jerárquica.
El enfoque no estructurado es el recomendado porque te permite organizar un repositorio de la manera que te resulte más conveniente.
En comparación, los repositorios jerárquicos aplican una estructura específica, como las definiciones de recursos personalizados (CRD) en un directorio cluster.
Esto puede causar problemas cuando necesites compartir la configuración. Por ejemplo, si un equipo publica un paquete que contiene una CRD, otro equipo que necesite usar ese paquete deberá mover la CRD a un directorio cluster, lo que agregará más sobrecarga al proceso.
Usar un repositorio no estructurado facilita mucho compartir y reutilizar paquetes de configuración. Sin embargo, sin un proceso o lineamientos definidos para organizar los repositorios, las estructuras de los repositorios pueden variar entre los equipos, lo que puede dificultar la implementación de herramientas para toda la flota.
Para obtener información sobre cómo convertir un repositorio jerárquico, consulta Convierte un repositorio jerárquico en un repositorio no estructurado.
Repositorios de código y configuración separados
Cuando se amplía un monorepositorio, se requiere una compilación específica para cada carpeta. Por lo general, los permisos y las inquietudes de las personas que trabajan en el código y en la configuración del clúster son diferentes.
Separar los repositorios de código y configuración tiene los siguientes beneficios:
- Evita los "bucles" en las confirmaciones. Por ejemplo, confirmar un repositorio de código podría activar una solicitud de CI, que podría producir una imagen, que luego requiere una confirmación de código.
- La cantidad de confirmaciones requeridas puede convertirse en una carga para los miembros del equipo que realizan contribuciones.
- Puedes usar diferentes permisos para las personas que trabajan en el código de la aplicación y la configuración del clúster.
Separar los repositorios de código y configuración tiene las siguientes desventajas:
- Reduce el descubrimiento de la configuración de la aplicación, ya que no se encuentra en el mismo repositorio que el código de la aplicación.
- Administrar muchos repositorios puede llevar mucho tiempo.
Usa repositorios separados para aislar los cambios
Cuando se amplía un monorepositorio, se requieren diferentes permisos en diferentes carpetas. Por este motivo, la separación de los repositorios permite establecer límites de seguridad entre la configuración de seguridad, la plataforma y la aplicación. También es recomendable separar los repositorios de producción y los que no son de producción.
Si bien administrar muchos repositorios puede ser una tarea grande en sí misma, aislar diferentes tipos de configuración en diferentes repositorios tiene los siguientes beneficios:
- En una organización con equipos de plataforma, seguridad y aplicaciones, la cadencia de los cambios y los permisos son diferentes.
- Los permisos permanecen a nivel del repositorio. Los archivos
CODEOWNERSpermiten que las organizaciones limiten el permiso de escritura y, al mismo tiempo, permitan el permiso de lectura. - El Sincronizador de configuración admite varias sincronizaciones por espacio de nombres, lo que puede lograr un efecto similar al de obtener archivos de varios repositorios.
Cómo fijar versiones de paquetes
Ya sea que uses Helm o Git, debes fijar la versión del paquete de configuración en algo que no se avance accidentalmente sin una implementación explícita.
Si bien esto agrega verificaciones adicionales a tus lanzamientos cuando se actualiza una configuración compartida, reduce el riesgo de que las actualizaciones compartidas tengan un impacto mayor de lo previsto.
Usa la federación de identidades para cargas de trabajo para GKE
Puedes habilitar la federación de identidades para cargas de trabajo para GKE en los clústeres de GKE, lo que permite que las cargas de trabajo de Kubernetes accedan a los servicios de Google de manera segura y administrable.
Si bien algunos servicios que no son deGoogle Cloud , como GitHub y GitLab, no admiten la federación de identidades para cargas de trabajo de GKE, debes intentar usarla siempre que sea posible debido al aumento de la seguridad y la reducción de la complejidad de la administración de secretos y contraseñas.