Prácticas recomendadas de GitOps en Kubernetes con el Sincronizador de configuración

En esta página, se proporciona un punto de partida para ayudarte a planificar y diseñar las canalizaciones de GitOps de CI/CD para Kubernetes, que pueden ayudarte a aprovechar al máximo el Sincronizador de configuración.

GitOps en sí es una práctica recomendada universal para las organizaciones que administran la configuración de Kubernetes Pero cuando se trata de diseñar esa solución, tienes muchas opciones. Comprender las opciones y los beneficios y desventajas de esas decisiones puede ayudarte a evitar volver a escribir tu arquitectura en el futuro.

No es necesario que sigas todas las prácticas recomendadas que se mencionan en esta página. Las prácticas recomendadas que elijas adoptar dependerán de tu situación particular. El objetivo de esta página es ayudarte a tomar decisiones fundamentadas cuando configures la arquitectura de GitOps.

Usa un repositorio de paquetes privado y centralizado

El uso de un repositorio central para paquetes públicos o internos (como Helm o kpt) puede ayudar a los equipos a encontrar paquetes con mayor facilidad. Puedes usar servicios como Artifact Registry o repositorios de Git.

El equipo de la plataforma puede implementar políticas en las que los equipos de aplicaciones puedan usar paquetes solo del repositorio central. De forma alternativa, podrían usar el repositorio central como un conjunto de paquetes verificados.

Puedes limitar los permisos de escritura del repositorio a solo una pequeña cantidad de ingenieros. El resto de la organización puede tener acceso de lectura. Recomendamos implementar un proceso para promover paquetes en el repositorio central y transmitir actualizaciones.

En la siguiente tabla, se enumeran las ventajas y las desventajas de usar un repositorio de paquetes privado y centralizado:

Ventajas

Desventajas

Transfiere paquetes públicos a una cadencia definida para evitar que sufra interrupciones por conectividad o deserción ascendente. Revisa y analiza paquetes compartidos. Proporciona una manera fácil de descubrir lo que se usa y es compatible. Por ejemplo, los equipos pueden encontrar más fácilmente la implementación estándar de Redis almacenada en el repositorio central. Realiza cambios en los paquetes ascendentes para asegurarte de que cumplan con los estándares internos, como los valores predeterminados, la adición de etiquetas y los repositorios de imágenes de contenedor.

Alguien debe mantener el repositorio central. Agrega más procesos para los equipos de aplicaciones.

Crea repositorios húmedos

Crea repositorios con el resultado YAML que coincida con el estado deseado de tu clúster o espacio de nombres. Los cambios en el repositorio húmedo o completamente hidratado deben ser fáciles de revisar con una diferencia. Se recomienda realizar cambios solo en el repositorio húmedo a través de un proceso de revisión (por ejemplo, en GitHub, esto sería una solicitud de extracción).

En la siguiente tabla, se enumeran las ventajas y las desventajas de crear repositorios húmedos:

Ventajas	Desventajas
Es más fácil examinar la diferencia. No se necesita procesamiento para ver cuál es el estado deseado de la configuración.	La configuración completa de hidratación puede causar una repetición de YAML.

Mayúsculas hacia la izquierda para validar los parámetros de configuración

Esperar hasta que el Sincronizador de configuración comience a sincronizarse para verificar si hay problemas puede crear confirmaciones de Git innecesarias y un ciclo de retroalimentación largo. Se pueden encontrar muchos problemas antes de que se aplique una configuración a un clúster mediante las funciones de validador de kpt, como kubeval.

En la siguiente tabla, se enumeran los beneficios y las desventajas de verificar si hay problemas antes de aplicar una configuración:

Ventajas	Desventajas
Mostrar cambios de configuración en una solicitud de cambio puede ayudar a evitar que se produzcan errores en un repositorio. Reduce el impacto de los problemas en los parámetros de configuración compartidos.	Debes agregar herramientas y lógica a tu proceso de confirmación para ayudar a detectar problemas.

Usa carpetas en lugar de ramas

Usa carpetas para las variantes de la configuración en lugar de ramas. Con las carpetas, puedes usar el comando tree para ver las variantes. Por ejemplo, con las ramas, no puedes saber si el delta entre una rama de producción y una de etapa es un cambio próximo en la configuración o una diferencia permanente entre la etapa y la producción.

En la siguiente tabla, se enumeran las ventajas y desventajas de usar carpetas en lugar de ramas:

Ventajas

Desventajas

Descubrir carpetas es más fácil que ramas. Es posible hacer una diferencia en las carpetas con muchas herramientas de la CLI y la GUI, mientras que la diferencia de ramas es menos común fuera de los proveedores de Git. La diferenciación entre diferencias permanentes y diferencias no promocionadas es más fácil con las carpetas. Puedes implementar cambios en varios clústeres y espacios de nombres en una solicitud de cambio, mientras que las ramas requieren varias solicitudes de cambio para diferentes ramas.

No se pueden ascender cambios de configuración mediante una solicitud de cambio en los mismos archivos.

Minimizar el uso de ClusterSelectors

ClusterSelectors te permite aplicar ciertas partes de una configuración a un subconjunto de clústeres. En lugar de configurar RootSync o RepoSync, puedes modificar el recurso que se está aplicando o agregar etiquetas a los clústeres. Sin embargo, con el tiempo, a medida que aumenta la cantidad de ClusterSelectors, puede resultar complicado comprender el estado final del clúster.

El Sincronizador de configuración te permite sincronizar varios RootSyncs y RepoSyncs a la vez, lo que significa que puedes agregar la configuración relevante a un repositorio separado y, luego, sincronizarla con los clústeres que desees.

En la siguiente tabla, se enumeran las ventajas y desventajas de no usar ClusterSelectors:

Ventajas	Desventajas
Es más fácil ensamblar la configuración que estará en el clúster en una carpeta en lugar de tomar esa decisión en el clúster. Reduce la carga mental de comprender lo que realmente se aplicará al clúster.	Las etiquetas son una forma rápida de agregar un trait a un clúster, y es más complejo crear un nuevo `RepoSync`.

Evita administrar trabajos con el Sincronizador de configuración

Si bien el Sincronizador de configuración puede aplicar trabajos por ti, estos no son adecuados para la implementación de GitOps por los siguientes motivos:

• Campos inmutables: Muchos campos del objeto Job son inmutables. Para cambiar un campo inmutable, se debe borrar y volver a crear el objeto. Sin embargo, el Sincronizador de configuración no borra tu 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, ese trabajo se borra del clúster, el Sincronizador de configuración considera que se desvía del estado elegido y vuelve a crear el trabajo. Si especificas un Tiempo de tiempo de actividad (TTL), el trabajo se borra de forma automática y el Sincronizador de configuración vuelve a crearlo de forma automática, lo que reinicia el trabajo hasta que lo borres de la fuente de información. A menudo, esto no es lo que se pretendía, porque el Sincronizador de configuración vuelve a ejecutar el trabajo.

• Problemas de conciliación: El Sincronizador de configuración normalmente espera a que se concilien los objetos después de aplicarse. Sin embargo, los trabajos se consideran conciliados cuando comienzan a ejecutarse. Esto significa que el Sincronizador de configuración no espera a que se complete el trabajo para continuar aplicando otros objetos. Sin embargo, si el trabajo falla más tarde, se considera un error de conciliación. En algunos casos, esto puede bloquear la sincronización de otros recursos y causar errores hasta que lo soluciones. En otros casos, la sincronización puede tener éxito y solo la conciliación falla.

Por estos motivos, no recomendamos sincronizar los 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 la administración de su ciclo de vida. Luego, puedes administrar ese servicio con el Sincronizador de configuración, en lugar de los trabajos.

En la siguiente tabla, se enumeran las ventajas y desventajas de no usar el Sincronizador de configuración para administrar trabajos:

Ventajas

Desventajas

Aumenta la compatibilidad con GitOps. Los objetos Job no funcionan bien con el enfoque declarativo y controlado por versiones de GitOps debido a sus campos inmutables. Reduce las consecuencias no deseadas. Se elimina el riesgo de que el Sincronizador de configuración vuelva a crear automáticamente los objetos Job borrados, lo que podría causar que se ejecuten de forma inesperada. Menos errores de sincronización. Se evitan los conflictos de sincronización y los errores potenciales activados por los objetos Job con errores.

Administración de trabajos manual. Debes buscar otro servicio para administrar trabajos.

Usa repositorios no estructurados

El Sincronizador de configuración admite dos estructuras para organizar un repositorio: no estructurado y jerárquico. El no estructurado es el método recomendado porque te permite organizar un repositorio de la manera que te resulta más conveniente. En comparación, los repositorios jerárquicos aplican una estructura específica. Por ejemplo, las CRD deben estar en un directorio específico. Esto puede causar problemas cuando necesitas compartir archivos de configuración. Por ejemplo, si un equipo publica un paquete que contiene una CRD, otro equipo que necesite usar ese paquete tendría que mover la CRD a un directorio cluster, lo que agrega más sobrecarga al proceso.

En la siguiente tabla, se enumeran las ventajas y las desventajas de usar repositorios no estructurados:

Ventajas	Desventajas
Puedes reutilizar paquetes de configuración compartidos incluso si contienen CRD o cualquier otra definición de todo el clúster.	Sin un proceso o lineamientos, las estructuras de los repositorios pueden variar entre los equipos, lo que puede dificultar la implementación de herramientas en toda la flota.

Para obtener información sobre cómo convertir un repositorio jerárquico, consulta Convierte un repositorio jerárquico en uno no estructurado.

Separa los repositorios de código y configuración

Cuando se escala verticalmente un repositorio mono, se requiere una compilación específica para cada carpeta. Los permisos y las preocupaciones para las personas que trabajan en el código y en la configuración del clúster suelen ser diferentes. Si se mantienen separados los repositorios de código y configuración, cada repositorio puede tener sus propios permisos y estructura.

En la siguiente tabla, se enumeran los beneficios y las desventajas de separar los repositorios de código y configuración:

Ventajas	Desventajas
Evita las confirmaciones "en bucle". Por ejemplo, la confirmación en un repositorio de código puede activar una solicitud de CI, que puede producir una imagen, que luego requiere una confirmación de código, etcétera. Puedes usar permisos diferentes para las personas que trabajan en el código de la aplicación y la configuración del clúster.	Reduce la detección de la configuración de la app, ya que no está 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 escala un repositorio mono, se requieren permisos diferentes en distintas carpetas. Debido a esto, separar repositorios permite límites de seguridad entre la seguridad, la plataforma y la configuración de las aplicaciones. También se recomienda separar los repositorios de producción y los que no son de producción.

En la siguiente tabla, se enumeran las ventajas y desventajas de los cambios de aislamiento en repositorios separados:

Ventajas

Desventajas

En una organización con equipos de plataforma, seguridad y aplicaciones, la cadencia de los cambios y los permisos es diferente. Los permisos permanecen en el nivel del repositorio. Los archivos CODEOWNERS permiten que las organizaciones limiten el permiso de escritura sin dejar de permitir el permiso de lectura. El Sincronizador de configuración admite varias sincronizaciones por espacio de nombres, que pueden lograr un "efecto de combinación" en varios repositorios.

Administrar muchos repositorios es una tarea propia. Por lo tanto, en el caso de que crees un repositorio nuevo por clúster, el problema de configuración o desmontaje del clúster ahora debe incluir la administración de repositorios.

Cómo fijar versiones de paquetes

Ya sea que uses Helm o Git, debes fijar la versión del paquete de configuración a algo que no se avance accidentalmente sin un lanzamiento explícito.

En la siguiente tabla, se enumeran las ventajas y las desventajas de fijar versiones de paquetes:

Ventajas	Desventajas
La actualización de la configuración compartida puede tener un impacto superior al previsto si la versión del paquete no está fijada.	Los lanzamientos requieren verificaciones cuando se actualizan los paquetes compartidos.

Usa Workload Identity

Puedes habilitar Workload Identity en los clústeres de GKE, lo que permite que las cargas de trabajo de Kubernetes accedan a los servicios de Google de forma segura y administrable.

En la siguiente tabla, se enumeran las ventajas y las desventajas de usar Workload Identity:

Ventajas	Desventajas
Reduce la complejidad y los posibles problemas con los secretos y las contraseñas.	Los servicios fuera de Google Cloud (como GitHub y GitLab) no son compatibles con Workload Identity.

Arquitectura de alto nivel

En un nivel alto, es probable que desees al menos cuatro tipos de repositorios:

1. Un repositorio de paquetes en el que se almacena la configuración compartida. También podría ser un gráfico de Helm almacenado en Artifact Registry.
2. Un repositorio de plataforma en el que el equipo de plataforma almacena la configuración de toda la flota para clústeres y espacios de nombres.
3. Un repositorio de configuración de aplicaciones.
4. Un repositorio de código de la aplicación.

En el siguiente diagrama, se muestra el diseño de estos repositorios:

En el siguiente diagrama, se muestra el flujo de configuración desde el código de la aplicación hasta un repositorio de configuración de la aplicación. Los equipos de desarrollo envían código para aplicaciones y configuraciones de aplicaciones a un repositorio. El código de las apps y los archivos de configuración se almacena en el mismo lugar, y los equipos de aplicaciones tienen control sobre estos repositorios. Luego, los equipos de apps pueden enviar código a una compilación.

¿Qué sigue?

• Comienza a usar el Sincronizador de configuración.