En esta página, se proporciona un punto de partida para ayudarte a planificar y diseñar canalizaciones de GitOps de CI/CD para Kubernetes. GitOps, junto con herramientas como el Sincronizador de configuración, ofrece beneficios como una mayor estabilidad del código, una 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 tus requisitos para la canalización de CI/CD, existen muchas opciones para diseñar y organizar tu aplicación y el código de configuració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 deseen 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 Google Cloud contenido de, consulta Roles y tareas comunes del usuario 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 repositorio. En un nivel alto, puedes considerar al menos cuatro tipos de repositorios:
- Un repositorio de paquetes para grupos de configuraciones relacionadas
- Un repositorio de plataforma para la configuración en toda la flota de clústeres y espacios de nombres
- 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, se muestra lo siguiente:
- Los equipos de desarrollo envían código para aplicaciones y configuraciones de 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 archivo readme, el uso de 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 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 al repositorio a solo 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 transmitir actualizaciones.
Aunque la administración de un repositorio central puede agregar una sobrecarga adicional, ya que alguien debe mantener el repositorio central y agrega un proceso adicional para los equipos de aplicaciones, este enfoque tiene muchos beneficios:
- Un equipo central puede optar por agregar paquetes públicos a una cadencia definida, lo que ayuda a evitar que se interrumpan por la conectividad o la rotación ascendente.
- Una combinación de revisores automatizados y humanos puede verificar los paquetes en busca de problemas antes de que estén disponibles para todos.
- El repositorio central proporciona una forma para que los equipos descubran qué se usa y qué es compatible. 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 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 contenedores.
Crea repositorios WET
WET significa "Write Everything Twice" (escribe todo dos veces). Contrasta con DRY, que significa "Don't Repeat Yourself" (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 propaga 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.
Aunque 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 procesamiento para ver el estado previsto de un archivo de configuración.
Realiza pruebas antes cuando valides las configuraciones
Esperar hasta que el Sincronizador de configuración comience a sincronizar 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 kpt.
Aunque 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 el delta entre una rama de producción y una de desarrollo es un cambio próximo en la configuración o una diferencia permanente entre el aspecto que deberían tener los entornos 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:
- El descubrimiento de carpetas es más fácil que el de las ramas.
- Es posible realizar 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.
- Es más fácil diferenciar entre las diferencias permanentes y las no promocionadas 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 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. Aunque 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.
Como 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 separado 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 el 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 trabajo 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 deseada 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 se desvía del estado elegido y vuelve a crear el trabajo. Si especificas un 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 conciliación: Por lo general, el Sincronizador de configuración espera a que los objetos se concilien 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 antes de 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 impedir que se sincronicen otros recursos y causar errores hasta que lo corrijas. En otros casos, la sincronización puede tener éxito y solo falla la conciliación.
Por estos motivos, no recomendamos sincronizar trabajos con el Sincronizador de configuración.
Usa repositorios no estructurados
El Sincronizador de configuración admite dos estructuras para organizar un repositorio: no estructurado y jerárquico.
El enfoque no estructurado es el recomendado porque te permite organizar un repositorio de la manera más conveniente para ti.
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 necesitas compartir configuraciones. 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 agregaría más sobrecarga al proceso.
Si usas un repositorio no estructurado, se vuelve mucho más fácil compartir y reutilizar paquetes de configuración. Sin embargo, sin un proceso o lineamientos definidos para organizar repositorios, las estructuras de 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 un repositorio no estructurado.
Separa los repositorios de código y configuración
Cuando se escala verticalmente un repositorio único, se requiere una compilación específica para cada carpeta. Los permisos y las inquietudes de las personas que trabajan en el código y en la configuración del clúster suelen ser diferentes.
Separar los repositorios de código y configuración tiene los siguientes beneficios:
- Evita las confirmaciones "en bucle". Por ejemplo, confirmar 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.
- La cantidad de confirmaciones requeridas puede convertirse en una carga para los miembros del equipo que contribuyen.
- 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 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 verticalmente un repositorio único, se requieren diferentes permisos en diferentes carpetas. Por este motivo, la separación de repositorios permite límites de seguridad entre la seguridad, la plataforma y la configuración de la aplicación. También es una buena idea separar los repositorios de producción y no producción.
Aunque la administración de muchos repositorios puede ser una tarea grande por sí sola, 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 cambios y permisos es diferente.
- Los permisos permanecen en el 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.
Fija las versiones del paquete
Ya sea que uses Helm o Git, debes fijar la versión del paquete de configuración a algo que no se mueva accidentalmente sin una implementación explícita.
Aunque esto agrega verificaciones adicionales a tus implementaciones cuando se actualiza una configuración compartida, reduce el riesgo de que las actualizaciones compartidas tengan un impacto mayor que el previsto.
Usa Workload Identity Federation for GKE
Puedes habilitar Workload Identity Federation for GKE en clústeres de GKE, lo que permite que las cargas de trabajo de Kubernetes accedan a los servicios de Google de una manera segura y administrable.
Aunque algunos servicios que no son de GoogleGoogle Cloud , como GitHub y GitLab, no admiten Workload Identity Federation for GKE, debes intentar usar Workload Identity Federation for GKE 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.