Acerca de las fuentes de información veraz

En este documento se explican los distintos tipos de fuentes de referencia desde las que puede sincronizar Config Sync.

Un concepto clave de los flujos de trabajo de GitOps es la fuente de información veraz, un repositorio central donde se almacenan los archivos de configuración. Un archivo de configuración suele ser un archivo YAML o JSON que define recursos de Kubernetes. Normalmente, puedes aplicar objetos de Kubernetes manualmente con la herramienta de línea de comandos kubectl, pero Config Sync puede aplicar automáticamente esos recursos desde una única fuente de información principal, como un repositorio de Git. A continuación, Config Sync monitoriza la fuente de información veraz que hayas especificado y aplica automáticamente los cambios a tus clústeres.

Config Sync puede sincronizar archivos de configuración de tres tipos de fuentes: repositorios de Git, imágenes de Open Container Initiative (OCI) y gráficos de Helm. En este documento se explica cada uno de estos tipos de fuentes y cómo interactúa Config Sync con ellos. Leer este documento puede ayudarte a elegir la mejor opción de fuente para tu flujo de trabajo y tu entorno.

Repositorios de Git

Git es una tecnología ampliamente adoptada para el control de versiones y la colaboración. Con Git, puedes organizar tu repositorio de la forma que mejor se adapte a tus necesidades y disfrutar de las ventajas del control de versiones y la creación de ramas, si es necesario. Como Git es una tecnología consolidada y ampliamente adoptada, tienes varias opciones de proveedores y herramientas.

Cuando configuras Config Sync con un repositorio de Git como fuente de información principal, Config Sync usa un contenedor git-sync en el pod de reconciliación para extraer las configuraciones del repositorio de Git. Puedes configurar la URL, la rama y la revisión (confirmación o etiqueta) del repositorio para tener más control sobre dónde extraer las configuraciones de tu repositorio de Git.

Ejemplo de configuración de RootSync

En el siguiente ejemplo se muestra un manifiesto RootSync que se sincroniza desde un repositorio de Git:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/example/my-configs.git
    revision: main
    dir: cluster-configs
    auth: none # replace with your authentication method such as ssh or token
    period: 60s

Esta configuración define Config Sync para sincronizar manifiestos desde un repositorio de Git. Config Sync monitoriza el directorio cluster-configs de la rama main del repositorio https://github.com/example/my-configs.git y comprueba si hay actualizaciones cada 60 segundos sin usar autenticación.

Caso práctico: gestión centralizada

Supongamos que eres un administrador de plataforma que quiere usar un repositorio Git para aplicar políticas de referencia en todos los clústeres de una flota. En este caso, puedes almacenar los archivos estándar NetworkPolicies, RoleBindings y ResourceQuotas en un repositorio de Git central llamado standard-configs. Cuando se aprovisiona un nuevo clúster, Config Sync se configura para sincronizar datos desde el repositorio standard-configs, lo que ayuda a asegurar que todos los clústeres cumplan los estándares de la organización desde el principio.

Imágenes de OCI

Las imágenes de OCI son un formato estándar para empaquetar aplicaciones y sus dependencias. Con este enfoque, las configuraciones se tratan como artefactos, de forma similar a como se tratarían las imágenes de contenedor. Este enfoque ofrece ventajas como la inmutabilidad y un rendimiento más rápido a gran escala. Con OCI, puedes usar la infraestructura y las herramientas de imágenes de contenedor, como Artifact Registry, para gestionar tus imágenes, y Workload Identity Federation para GKE para simplificar la autenticación.

Para usar OCI como fuente de configuración, normalmente se necesita un proceso independiente para compilar los archivos de configuración en una imagen de OCI y, a continuación, subirla a una plataforma de registro como Artifact Registry. Este enfoque puede ser menos legible directamente por humanos que las configuraciones almacenadas como archivos en un repositorio de Git.

Cuando configuras Config Sync con una imagen OCI como fuente de información veraz, Config Sync usa un contenedor oci-sync dentro del pod de reconciliación para extraer la imagen OCI que contiene las configuraciones del registro.

Ejemplo de configuración de RootSync

En el siguiente ejemplo se muestra un manifiesto de RootSync que se sincroniza desde una imagen OCI almacenada en Artifact Registry:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0
    dir: .
    auth: k8sserviceaccount

Esta configuración permite que Config Sync se sincronice desde una imagen de OCI. Config Sync extrae la imagen de us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0 de Artifact Registry mediante una cuenta de servicio de Kubernetes para la autenticación.

Caso práctico: integración de un flujo de procesamiento de CI/CD

Supongamos que quieres integrar la creación de imágenes OCI en el flujo de procesamiento de CI/CD de tu organización. Cuando se combinen los cambios en los archivos de configuración, puedes configurar tu canalización para que ejecute pruebas de validación (como el comando nomos vet), compile los archivos YAML en una imagen OCI y envíe la imagen a Artifact Registry. Config Sync detectaría y aplicaría automáticamente la nueva versión de la imagen a tus clústeres, lo que aseguraría que todos los cambios de configuración se implementen de forma validada y versionada.

Gráficos de Helm

Helm es un gestor de paquetes popular para Kubernetes que usa un formato de empaquetado llamado gráficos. Config Sync puede obtener, renderizar y sincronizar recursos definidos en gráficos de Helm.

Helm ofrece una forma coherente de empaquetar y reutilizar aplicaciones de Kubernetes. Puedes usar plantillas o gráficos de Helm prediseñados para crear configuraciones coherentes y reutilizables.

Si no estás familiarizado con Helm, el proceso de creación de plantillas y lanzamiento puede añadir complejidad adicional a tu canalización de gestión de la configuración.

Cuando configuras Config Sync con un gráfico de Helm como fuente de información principal, Config Sync usa un contenedor helm-sync en el pod de reconciliación para extraer gráficos de un repositorio de Helm (como Artifact Registry) o de un repositorio de Git. Después, renderiza el gráfico para generar manifiestos de Kubernetes. También puedes usar Config Sync con Kustomize para renderizar charts de Helm. Para obtener más información sobre este enfoque, consulta Utilizar Config Sync con Kustomize y Helm.

Ejemplo de configuración de RootSync

En el siguiente ejemplo se muestra un manifiesto RootSync que se sincroniza desde un gráfico de Helm almacenado en Artifact Registry:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: helm
  helm:
    repo: oci://us-central1-docker.pkg.dev/my-project/my-helm-repo
    chart: my-chart
    version: 1.2.0
    auth: gcpserviceaccount
    gcpServiceAccountEmail: my-service-account@my-project.iam.gserviceaccount.com
    releaseName: my-chart-release
    namespace: my-app-namespace # Namespace where the chart resources will be deployed

Esta configuración define Config Sync para sincronizar un gráfico de Helm desde un repositorio de OCI. Config Sync obtiene la versión 1.2.0 del gráfico my-chart del repositorio oci://us-central1-docker.pkg.dev/my-project/my-helm-repo y se autentica con la cuenta de servicio my-service-account@my-project.iam.gserviceaccount.com. Despliega los recursos del gráfico en el espacio de nombres my-app-namespace con el nombre de lanzamiento my-chart-release.

Caso práctico: implementar una aplicación de terceros

Imagina que formas parte de un equipo de aplicaciones que quiere implementar Prometheus en un clúster. Puedes configurar Config Sync para que extraiga datos de un gráfico de Helm prediseñado que implemente Prometheus. En lugar de ejecutar manualmente comandos de Helm, puedes definir la fuente del gráfico, la versión y cualquier values personalizado en el objeto RootSync o RepoSync de Config Sync. Config Sync mantiene la implementación sincronizada con la versión del gráfico y las configuraciones especificadas.

Elegir un tipo de fuente

El mejor tipo de fuente depende de las herramientas, los flujos de trabajo y las preferencias de tu equipo. Puede usar esta tabla para conocer las características principales de cada tipo de fuente y tomar una decisión fundamentada:

Función Repositorio de Git Imagen OCI Gráfico de Helm
Usos recomendados Gestión de configuración de uso general, flexibilidad y legibilidad Configuraciones inmutables y versionadas que aprovechan la infraestructura de contenedores Empaquetar y distribuir aplicaciones complejas
Mutabilidad Modificable Inmutable Mutable (las versiones de los gráficos son inmutables, pero los valores pueden cambiar)
Restauraciones Deshacer confirmaciones o cambiar de rama Implementar la etiqueta de imagen anterior Restaurar una versión anterior de un gráfico
Herramientas Clientes de Git estándar y flujos de procesamiento de CI/CD Docker o Podman, registros de contenedores CLI de Helm y repositorios de Helm
Rendimiento Puede ser más lento en repositorios grandes Más rápido, sobre todo a gran escala Rápido al obtener datos de un repositorio de gráficos
Autenticación Flexible (SSH, token), puede ser más complejo de configurar Simplificado con Workload Identity Federation para GKE (por ejemplo, con Artifact Registry) Simplificado con Workload Identity Federation para GKE (por ejemplo, con Artifact Registry)

También es posible usar diferentes tipos de fuentes para distintos fines en el mismo clúster. Por ejemplo, un clúster podría tener lo siguiente:

  • Una RootSync sincronización desde un repositorio de Git que contiene recursos y políticas básicos de todo el clúster gestionados por el equipo de la plataforma.
  • Un RepoSync de un espacio de nombres específico que se sincroniza desde un gráfico de Helm para desplegar una instancia de Redis gestionada por un equipo de aplicaciones.
  • Otro RepoSync en un espacio de nombres diferente que se sincroniza desde una imagen OCI que contiene un conjunto de configuraciones específicas de la aplicación creadas por otro proceso de CI/CD.

Siguientes pasos