Organizar los archivos de configuración en una fuente de información veraz

En esta página se explica cómo organizar las configuraciones en una fuente de información veraz.

A medida que tu organización crece, es probable que tengas que gestionar configuraciones en una flota de clústeres y admitir varios equipos que trabajen en los mismos repositorios. Una parte fundamental de una estrategia de GitOps eficaz es asegurarse de que las configuraciones se apliquen a los clústeres correctos y de que los equipos puedan trabajar sin interferir entre sí.

Acerca de los archivos de configuración

Config Sync está diseñado para operadores de clústeres que gestionan muchos clústeres. Puedes asegurarte de que tus clústeres cumplan los estándares empresariales y de cumplimiento dejando que Config Sync gestione los espacios de nombres, los roles, los enlaces de roles, los ResourceQuotas y otros objetos importantes de Kubernetes en toda tu flota.

Cuando Config Sync gestiona estos recursos, mantiene sincronizados los clústeres registrados mediante configuraciones. Una configuración es un archivo YAML o JSON en una fuente de información veraz. Config Sync admite repositorios de Git, imágenes OCI y gráficos de Helm como fuente de información principal. Las configuraciones contienen el mismo tipo de detalles de configuración que puedes aplicar manualmente a un clúster mediante el comando kubectl apply. Puedes crear una configuración para cualquier objeto de Kubernetes que pueda existir en un clúster. Sin embargo, algunos objetos de Kubernetes, como los secretos, contienen información sensible que puede no ser adecuada para almacenar en una fuente de información veraz. Piensa detenidamente si quieres gestionar estos tipos de objetos con Config Sync.

Requisitos y limitaciones

  • Algunos recursos de Kubernetes contienen campos inmutables, como los selectores de pods en un objeto Deployment. No puedes cambiar ningún campo inmutable de una configuración cambiando el valor de la fuente de información veraz. Si intenta hacer este cambio, se producirá un error KNV2009. Si necesitas cambiar un campo inmutable, elimina el objeto de tu fuente de información veraz, espera a que Config Sync elimine el objeto del clúster y, a continuación, vuelve a crear el objeto en tu fuente de información veraz con los cambios.

  • Si usas submódulos de Git, debes conceder acceso a Config Sync a todos los repositorios, incluidos los submódulos.

  • No puedes usar Config Sync para gestionar directamente los ClusterRoles de Kubernetes integrados. GKE incluye algunos roles orientados al usuario, como cluster-admin, admin, edit y view. No puedes gestionar directamente estos ClusterRoles con Config Sync, ya que Config Sync entraría en conflicto con GKE. Para añadir permisos a los ClusterRoles integrados, usa la agregación de roles para modificarlos indirectamente. Para modificar los roles, crea un ClusterRole con un nombre único en tu fuente de información veraz con las anotaciones adecuadas.

Organizar la fuente de información veraz

Puedes configurar Config Sync para que se sincronice desde un repositorio completo o desde carpetas o ramas específicas. Gracias a esta flexibilidad, puedes organizar los archivos de configuración según las necesidades de tu equipo u organización.

Te recomendamos que, al configurar Config Sync, definas sourceFormat como unstructured. El tipo de origen estructurado (jerárquico) requiere una estructura de carpetas muy específica para sincronizar correctamente las configuraciones y añade una complejidad innecesaria en la mayoría de los casos.

La mayor parte de la documentación de Config Sync, incluida esta página, usa el formato no estructurado de forma predeterminada, pero puedes consultar información sobre el formato jerárquico en Usar un repositorio jerárquico.

Cuando se usa una fuente no estructurada, se pueden organizar las configuraciones de forma flexible para adaptarlas al flujo de trabajo del equipo. En esta sección se muestran algunos patrones habituales para estructurar tu repositorio.

Diseño basado en el entorno

Una práctica habitual es organizar el repositorio por entorno.

├── cluster-essentials/
│   ├── crds/
│   └── namespace.yaml
├── environments/
│   ├── dev/
│   │   ├── backend/
│   │   └── frontend/
│   ├── staging/
│   │   ├── backend/
│   │   └── frontend/
│   └── prod/
│       ├── backend/
│       └── frontend/
└── system/
    └── monitoring/

En este ejemplo, la fuente de información se organiza de la siguiente manera:

  • cluster-essentials/: contiene la configuración que se aplica a todos los clústeres, independientemente del entorno. Esto puede incluir recursos como definiciones de recursos personalizadas (CRDs) y espacios de nombres esenciales.
  • environments/: el directorio principal de todas las configuraciones específicas del entorno.
  • system/: contiene configuraciones de servicios a nivel de sistema, como la monitorización.

Este enfoque es fácil de entender y de usar, y proporciona una ruta de promoción clara para los cambios de un entorno a otro.

Cuando configuras Config Sync en este caso, creas varios objetos RootSync en cada clúster. Por ejemplo, un clúster de desarrollo tiene RootSync objetos sincronizados de cluster-essentials/, system/ y environments/dev/.

Diseño basado en clústeres

Si te centras en gestionar una flota de clústeres individuales con configuraciones distintas, un diseño basado en clústeres puede ser más adecuado.

├── clusters/
│   ├── cluster-a/
│   │   ├── apps/
│   │   └── networking/
│   ├── cluster-b/
│   │   ├── apps/
│   │   └── networking/
│   └── cluster-c/
│       ├── apps/
│       └── networking/
└── shared/
    ├── roles/
    └── policies/

En este ejemplo, la fuente de información se organiza de la siguiente manera:

  • clusters/: contiene un directorio para cada clúster que gestionas.
  • shared/: contiene configuraciones comunes a todos los clústeres, como roles de RBAC y políticas de seguridad.

Este enfoque es eficaz para gestionar muchos clústeres si todos ellos tienen configuraciones únicas, ya que proporciona una propiedad clara y un aislamiento de las configuraciones. Este enfoque puede ser más complejo de gestionar si tienes muchas configuraciones de clúster compartidas.

Cuando configuras Config Sync en este caso, puedes usar un RepoSync para configurar cada clúster de forma que se sincronice tanto desde shared como desde el directorio específico del clúster.

Diseño basado en equipos

En las organizaciones en las que diferentes equipos gestionan diferentes aplicaciones o servicios, un diseño basado en equipos puede ser eficaz. De esta forma, la estructura de la fuente de información veraz se adapta a la estructura de tu organización.

├── teams/
│   ├── team-alpha/
│   │   ├── app-one/
│   │   └── app-two/
│   ├── team-beta/
│   │   ├── service-a/
│   │   └── service-b/
│   └── team-gamma/
│       ├── data-pipeline/
│       └── dashboard/
└── platform/
    ├── cluster-roles/
    └── storage-classes/

En este ejemplo, la fuente de información se organiza de la siguiente manera:

  • teams/: organiza la configuración por equipos, de forma que cada equipo gestiona sus propias configuraciones de aplicaciones y servicios.
  • platform/: contiene configuraciones de todo el clúster que gestiona un equipo de plataforma central y que usan todos los equipos.

Este enfoque permite a los equipos gestionar sus propios ciclos de configuración y lanzamiento, y reduce la probabilidad de que los cambios de un equipo afecten accidentalmente a otro. Sin embargo, este enfoque requiere una gestión cuidadosa de las dependencias entre los equipos de aplicaciones y los equipos de plataformas.

Cuando configuras Config Sync, en este caso, cada equipo usa un objeto RootSync para sincronizar las configuraciones. Por ejemplo, team-alpha se sincroniza desde teams/team-alpha/.

Validar archivos de configuración

Después de crear, organizar y añadir archivos de configuración a una fuente de información veraz, usa el comando nomos vet --source-format=unstructured para comprobar la sintaxis y la validez de tus configuraciones. De esta forma, evitarás errores durante o después de una sincronización.

Ignorar mutaciones de objetos

Si no quieres que Config Sync mantenga el estado del objeto en el clúster después de que exista, añade la anotación client.lifecycle.config.k8s.io/mutation: ignore al objeto en el que quieras que Config Sync ignore las mutaciones.

En el siguiente ejemplo se muestra cómo añadir la anotación a un objeto:

metadata:
  annotations:
    client.lifecycle.config.k8s.io/mutation: ignore

No puedes modificar manualmente esta anotación en objetos gestionados del clúster.

Convertir un repositorio jerárquico en un repositorio no estructurado

Si usas un repositorio jerárquico y quieres convertirlo en un repositorio sin estructurar, ejecuta el siguiente comando:

nomos hydrate PATH

Sustituye PATH por la ruta a tu directorio.

Este comando crea un directorio compiled/ en el directorio de trabajo actual. En ese directorio, se crea un subdirectorio para cada clúster registrado. Estos subdirectorios contienen las configuraciones totalmente resueltas y se pueden usar en un repositorio no estructurado.

Para obtener más información, consulta los comandos de nomos.

Si prefieres convertir tu repositorio manualmente, sigue estas instrucciones:

  1. Elimina las configuraciones de Repo del directorio system/ de tu repositorio de Git. El recurso Repo no es necesario para un repositorio no estructurado.

  2. El directorio de espacio de nombres abstracto no se admite en un repositorio no estructurado. Por lo tanto, declara el espacio de nombres de todos los recursos incluidos originalmente en el directorio namespaces/ y sus subdirectorios.

  3. La herencia de espacios de nombres no se admite en el repositorio no estructurado. Por lo tanto, declara todos los recursos que se hereden originalmente en los espacios de nombres descendientes (los que estén originalmente en el directorio namespaces/).

Siguientes pasos