Acerca de las fuentes de información

En este documento, se explican los diferentes tipos de fuentes de información desde las que se puede sincronizar el Sincronizador de configuración.

Un concepto clave en los flujos de trabajo de GitOps es la fuente de información, un repositorio central en el que se almacenan tus archivos de configuración. Por lo general, un archivo de configuración es un archivo YAML o JSON que define recursos de Kubernetes. Normalmente, puedes aplicar objetos de Kubernetes de forma manual con la herramienta de línea de comandos kubectl, pero el Sincronizador de configuración puede aplicar automáticamente esos recursos desde una sola fuente de información, como un repositorio de Git. Luego, el Sincronizador de configuración supervisa la fuente de información especificada y aplica automáticamente cualquier cambio a tus clústeres.

El Sincronizador de configuración puede sincronizar archivos de configuración desde tres tipos diferentes 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 con ellos el Sincronizador de configuración. Leer este documento puede ayudarte a elegir la mejor opción de fuente para tu flujo de trabajo y entorno.

Repositorios de Git

Git es una tecnología ampliamente adoptada para el control de versión y la colaboración. Con Git, puedes organizar tu repositorio de la manera que mejor se adapte a tus necesidades y obtener los beneficios del control de versión y la creación de ramas, si es necesario. Dado que Git es una tecnología consolidada y ampliamente adoptada, tienes una variedad de opciones de proveedores y herramientas.

Cuando configuras Sincronizador de configuración con un repositorio de Git como fuente de información, Sincronizador de configuración usa un contenedor git-sync dentro del Pod del reconciliador 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 un mayor control sobre dónde extraer las configuraciones dentro de tu repositorio de Git.

Ejemplo de configuración de RootSync

En el siguiente ejemplo, se muestra un manifiesto de 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 establece el Sincronizador de configuración para sincronizar manifiestos desde un repositorio de Git. El Sincronizador de configuración supervisa el directorio cluster-configs en la rama main del repositorio https://github.com/example/my-configs.git y verifica si hay actualizaciones cada 60 segundos sin usar autenticación.

Ejemplo de caso de uso: Administración centralizada

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

Imágenes OCI

Las imágenes de OCI son un formato estándar para empaquetar aplicaciones y sus dependencias. Con este enfoque, tus configuraciones se tratan como artefactos, de manera similar a como tratarías las imágenes de contenedores. 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 contenedores, como Artifact Registry, para administrar tus imágenes, y Workload Identity Federation for GKE para simplificar la autenticación.

Usar OCI como fuente de configuración suele requerir un proceso independiente para compilar tus archivos de configuración en una imagen de OCI y, luego, enviarla a una plataforma de registro como Artifact Registry. Este enfoque puede ser menos legible para los humanos que las configuraciones almacenadas como archivos en un repositorio de Git.

Cuando configuras el Sincronizador de configuración con una imagen de OCI como fuente de información, el Sincronizador de configuración usa un contenedor oci-sync dentro del Pod del conciliador para extraer del registro la imagen de OCI que contiene los parámetros de configuración.

Ejemplo de configuración de RootSync

En el siguiente ejemplo, se muestra un manifiesto de RootSync que se sincroniza desde una imagen de 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 establece el Sincronizador de configuración para que se sincronice desde una imagen de OCI. El Sincronizador de configuración extrae la imagen us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0 de Artifact Registry con una cuenta de servicio de Kubernetes para la autenticación.

Ejemplo de caso de uso: Integración de la canalización de CI/CD

Imagina que deseas integrar la creación de imágenes de OCI en la canalización de CI/CD de tu organización. Cuando se combinan 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 de OCI y envíe la imagen a Artifact Registry. Luego, Sincronizador de configuración detectaría y aplicaría automáticamente la nueva versión de la imagen en tus clústeres, lo que garantizaría una implementación validada y versionada de todos los cambios de configuración.

Charts de Helm

Helm es un administrador de paquetes popular para Kubernetes que usa un formato de empaquetado llamado charts. El Sincronizador de configuración puede recuperar, 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 obtener configuraciones coherentes y reutilizables.

Si aún no conoces Helm, el proceso de plantillas y versiones puede agregar complejidad adicional a tu canalización de administración de la configuración.

Cuando configuras el Sincronizador de configuración con un gráfico de Helm como fuente de información, el Sincronizador de configuración usa un contenedor helm-sync dentro del Pod del conciliador para extraer gráficos de un repositorio de Helm (como Artifact Registry) o un repositorio de Git y, luego, renderiza el gráfico para producir manifiestos de Kubernetes. Como alternativa, puedes usar el Sincronizador de configuración con Kustomize para renderizar gráficos de Helm. Para obtener más información sobre este enfoque, consulta Usa el Sincronizador de configuración 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 establece el Sincronizador de configuración para sincronizar un gráfico de Helm desde un repositorio de OCI. Sincronizador de configuración recupera 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. Implementa los recursos del gráfico en el espacio de nombres my-app-namespace con el nombre de versión my-chart-release.

Ejemplo de caso de uso: Implementación de una aplicación de terceros

Imagina que formas parte de un equipo de aplicaciones que desea implementar Prometheus en un clúster. Puedes configurar el Sincronizador de configuración para extraer datos de un gráfico de Helm compilado previamente que implementa Prometheus. En lugar de ejecutar manualmente los comandos de Helm, defines la fuente, la versión y cualquier values personalizado del gráfico dentro del objeto RootSync o RepoSync del Sincronizador de configuración. Luego, el Sincronizador de configuración mantiene la implementación sincronizada con la versión y las configuraciones especificadas del gráfico.

Cómo elegir un tipo de fuente

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

Función Repositorio de Git Imagen OCI Gráfico de Helm
Ideal para Administración de configuración de uso general, flexibilidad y legibilidad Configuraciones inmutables y con versiones que aprovechan la infraestructura de contenedores Cómo empaquetar y distribuir aplicaciones complejas
Mutabilidad Mutable Inmutable Mutable (las versiones del gráfico son inmutables, pero los valores pueden cambiar)
Reversiones Cómo revertir confirmaciones o cambiar de rama Implementa la etiqueta de imagen anterior Cómo revertir a una versión anterior del gráfico
Herramientas Clientes de Git estándar, canalizaciones de CI/CD Docker o Podman, registros de contenedores CLI de Helm y repositorios de Helm
Rendimiento Puede ser más lento para repositorios grandes Más rápido, en especial a gran escala Es rápido cuando se recupera información de un repositorio de gráficos.
Autenticación Flexible (SSH, token), puede ser más complejo de configurar Simplificada con Workload Identity Federation for GKE (por ejemplo, con Artifact Registry) Simplificada con Workload Identity Federation for GKE (por ejemplo, con Artifact Registry)

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

  • Una RootSync que se sincroniza desde un repositorio de Git que contiene recursos y políticas básicos para todo el clúster administrados por el equipo de la plataforma.
  • Un RepoSync en un espacio de nombres específico que se sincroniza desde un gráfico de Helm para implementar una instancia de Redis administrada por un equipo de aplicaciones.
  • Otro RepoSync en un espacio de nombres diferente que se sincroniza desde una imagen de OCI que contiene un conjunto de parámetros de configuración específicos de la aplicación compilados por un proceso de CI/CD independiente.

¿Qué sigue?