Usa archivos de configuración en repositorios de Git

El Sincronizador de configuración está diseñado para operadores de clúster que administran muchos clústeres. Puedes asegurarte de que tus clústeres cumplan con los estándares empresariales y de cumplimiento si permites que el Sincronizador de configuración administre espacios de nombres, funciones, RoleBindings, ResourceQuotas y otros objetos importantes de Kubernetes en toda tu flota.

El Sincronizador de configuración mantiene los clústeres inscritos sincronizados mediante archivos de configuración. Un archivo de configuración es un archivo YAML o JSON que se almacena en tu repositorio de Git y contiene los mismos tipos de detalles de configuración que puedes aplicar de forma manual a un clúster mediante el comando kubectl apply. Puedes crear un archivo de configuración para cualquier objeto de Kubernetes que pueda existir en un clúster. Este tema abarca los siguientes puntos:

  • Cómo organizar los archivos de configuración en un directorio
  • Cómo inicializar un repositorio de Git para almacenar los archivos de configuración
  • Cómo configurar el Sincronizador de configuración para leer desde los archivos de configuración

Almacena archivos de configuración en repositorios

El Sincronizador de configuración usa un repositorio de Git para el almacenamiento de archivos de configuración y el control de versiones, y realiza acciones basadas en su contenido. En el Sincronizador de configuración, este repositorio se denomina repositorio. Hay dos formatos diferentes para un repositorio: no estructurado y jerárquico.

  • El formato fuente no estructurado te permite organizar la configuración de tu repositorio de la manera que sea más conveniente. Este formato puede ser muy útil si organizas o generas archivos de configuración con una herramienta como kustomize, kpt o helm.
  • El formato jerárquico o estructurado separa la configuración en distintas categorías para ayudarte a organizarlas. Las categorías son configuración del sistema, metadatos del clúster, configuración a nivel del clúster y configuración del espacio de nombres. Para obtener más información sobre la estructura de repositorio jerárquica, consulta Estructura del repositorio jerárquico.

En la siguiente tabla, se destacan las diferencias entre los formatos de repositorio jerárquico y no estructurado:

Funciones Formato del repositorio jerárquico Formato del repositorio no estructurado
Selectores de espacios de nombres Admitido Admitido
Selectores de clústeres Admitido Admitido
Espacios de nombres abstractos Admitido No compatible
Repo objetos Admitido No compatible
Objetos HierarchyConfig Admitido No compatible
Espacios de nombres jerárquicos en el controlador de jerarquía No compatible Admitido
Se usa como el formato de un repositorio de espacio de nombres No compatible Admitido
Se usa como el formato de un repositorio raíz Admitido Admitido
Se usa junto con el controlador de jerarquía No recomendado Admitido
El comando nomos init Admitido No compatible
El comando nomos hydrate Admitido No compatible
El comando nomos vet Admitido Compatible con la marca --source-format=unstructured
Todos los demás comandos nomos Admitido Admitido

Ejemplo de un diseño de archivo de configuración no estructurado

En el siguiente ejemplo, se muestra una manera de organizar los archivos de configuración, incluidos los recursos de Google Cloud.

Puedes colocar tus archivos de configuración sin procesar en un directorio raw-configs, usar una secuencia de comandos o una canalización automatizada para procesar los archivos de configuración sin procesar y almacenar el resultado en el directorio manifests. Al final, debes configurar el Sincronizador de configuración para que se sincronice desde tu directorio manifests.

├── manifests
│   ├── access-control
│   │   ├── ...
│   ├── change-control
│   │   ├── ...
│   ├── git-ops
│   │   └── ...
│   ├── logging-monitoring
│   │   └── ...
│   ├── networking
│   │   └── ...
│   ├── project-factory
│   │   └── ...
│   └── resource-hierarchy
│   │   └── ...
├── raw-configs
│   ├── access-control
│   │   └── ...
│   ├── change-control
│   │   └── ...
│   ├── git-ops
│   │   └── ...
│   ├── logging-monitoring
│   │   └── ...
│   ├── networking
│   │   └── ...
│   ├── project-factory
│   │   └── ...
│   └── resource-hierarchy
│   │   └── ...
└── scripts
    └── render.sh

Inicializa un repositorio de Git

La forma de iniciar un repositorio depende de su estructura.

  • Para el formato no estructurado, puedes inicializar un repositorio de Git vacío y comenzar a agregar archivos de configuración en el repositorio.
  • Para el formato jerárquico, puedes inicializar un repositorio mediante el comando nomos init o puedes crear la estructura del directorio de forma manual.

Configura el Sincronizador de configuración para que lea información desde el repositorio

Debes configurar la ubicación del repositorio cuando instalas el Sincronizador de configuración, y puedes editar su configuración más adelante en el archivo de configuración del operador. Además de la ubicación del repositorio, puedes especificar una rama de Git y un subdirectorio que deseas observar si el repositorio de Git tiene otro contenido aparte de archivos de configuración.

Después de actualizar el archivo de configuración, puedes aplicarlo al clúster mediante el comando kubectl apply. El Sincronizador de configuración no administra la configuración del operador.

Puedes otorgar a las personas acceso al repositorio de implementación de un equipo de productos determinado. Sin embargo, debes tener en cuenta que cuando otorgas a una persona acceso a un repositorio de implementaciones, esa persona también recibe el mismo RBAC que el conciliador que se ejecuta para ese repositorio.

Para configurar la autenticación y la autorización entre el Sincronizador de configuración y el repositorio, consulta el paso de instalación sobre la configuración del secreto git-creds.

Ignora las mutaciones de objetos

Si no deseas que el Sincronizador de configuración mantenga el estado del objeto que el clúster existe después de él, puedes agregar la anotación client.lifecycle.config.k8s.io/mutation: ignore al objeto que deseas que ignore las mutaciones en el Sincronizador de configuración. Para usar la anotación, debes habilitar el modo de varios repositorios y usar una versión de 1.7.0 o posterior.

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

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

No puedes modificar de forma manual esta anotación en los objetos administrados del clúster.

¿Qué sigue?