Acerca de las fuentes de información

El Sincronizador de configuración te permite automatizar las implementaciones de recursos de Kubernetes en tus clústeres desde una fuente de información central, lo que reemplaza los comandos manuales de kubectl. En los flujos de trabajo de GitOps, una fuente de información es el repositorio central en el que almacenas los archivos de configuración YAML o JSON que definen los recursos de tu clúster. El Sincronizador de configuración supervisa continuamente este repositorio y aplica de forma automática los cambios en tus clústeres.

Puedes sincronizar archivos de configuración desde tres tipos de fuentes: repositorios de Git, imágenes de Open Container Initiative (OCI) y gráficos de Helm. Comprender cómo interactúa el Sincronizador de configuración con cada tipo de fuente te ayuda a elegir la mejor opción para tu flujo de trabajo y entorno.

Repositorios de Git

Git es una tecnología muy adoptada para el control de versión y la colaboración. Con Git, puedes organizar tu repositorio de la manera que se adapte a tus necesidades y obtener los beneficios del control de versión y la ramificación, si es necesario. Como Git es maduro y tiene una amplia compatibilidad, obtienes una variedad de opciones para proveedores y herramientas.

Cuando configuras el Sincronizador de configuración con un repositorio de Git como fuente de información, el Sincronizador de configuración usa un contenedor git-sync dentro del Pod de conciliador para extraer los parámetros de configuración 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 los parámetros de configuración dentro de tu repositorio de Git.

Configuración de RootSync de ejemplo

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 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 autenticación.

Ejemplo de caso de uso: Administración centralizada

Imagina que eres un administrador de plataforma que quiere usar un repositorio de Git para aplicar políticas de referencia en todos los clústeres de una flota. En esta situación, puedes almacenar NetworkPolicies, RoleBindings y ResourceQuotas estándar en un repositorio de Git central llamado standard-configs. Cuando se aprovisiona un clúster nuevo, el Sincronizador de configuración se configura para sincronizarse 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 de OCI

Las imágenes de OCI son un formato estándar para empaquetar aplicaciones y sus dependencias. Este enfoque trata tus parámetros de configuración como artefactos, de manera similar a como tratarías 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 administrar tus imágenes, y Workload Identity Federation for GKE para simplificar la autenticación.

Por lo general, usar OCI como fuente de configuración requiere 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 por 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 de oci-sync dentro del Pod conciliador para extraer la imagen de OCI que contiene los parámetros de configuración del registro.

Configuración de RootSync de ejemplo

En el siguiente ejemplo, se muestra un manifiesto 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 de 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 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, el 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 un lanzamiento validado y con control de versiones 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 parámetros de configuración coherentes y reutilizables.

Si aún no conoces Helm, el proceso de creación de plantillas y lanzamiento puede agregar complejidad adicional a tu canalización de administración de configuraciones.

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.

Configuración de RootSync de ejemplo

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.s3ns.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. El 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.s3ns.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: Implementa una aplicación de terceros

Imagina que eres parte de un equipo de aplicaciones que quiere implementar Prometheus en un clúster. Puedes configurar el Sincronizador de configuración para que extraiga datos de un gráfico de Helm precompilado que implemente Prometheus. En lugar de ejecutar comandos de Helm de forma manual, defines la fuente del gráfico, la versión y cualquier values personalizado 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 del gráfico especificadas.

Elige 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 de OCI Gráfico de Helm
Ideal para Administración de configuraciones de uso general, flexibilidad y legibilidad por humanos Configuraciones inmutables y con control de versiones que aprovechan la infraestructura de contenedores Empaquetado y distribución de aplicaciones complejas
Mutabilidad Mutable Inmutable Mutable (las versiones de los gráficos son inmutables, pero los valores pueden cambiar)
Reversiones Cómo revertir confirmaciones o cambiar de rama Implementa la etiqueta de imagen anterior Revierte a una versión anterior del gráfico
Herramientas Clientes de Git estándar, canalizaciones de CI/CD Docker o Podman, Container Registry CLI de Helm, repositorios de Helm
Rendimiento Puede ser más lento para repositorios grandes Más rápido, en especial a gran escala Rápido cuando se recupera de un repositorio de gráficos
Autenticación Flexible (SSH, token), puede ser más compleja de configurar Simplificado con la federación de identidades para cargas de trabajo para GKE (por ejemplo, con Artifact Registry) Simplificado con la federación de identidades para cargas de trabajo para 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:

  • Un 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?