Usa un repositorio no estructurado

Usar un repositorio no estructurado te permite organizar tu repositorio de la manera que te resulte más conveniente. Esta flexibilidad te permite sincronizar tu configuración existente de Kubernetes con el repositorio del Sincronizador de configuración. Por ejemplo, si deseas sincronizar un gráfico de Helm con tu clúster, puedes ejecutar el comando helm template y confirmar manifiesto procesado al repositorio. Para obtener más información, consulta el instructivo Usa el Sincronizador de configuración con Helm.

Recomendamos repositorios no estructurados para la mayoría de los casos de uso. Sin embargo, también puedes crear un repositorio jerárquico para separar archivos de configuración en categorías distintas.

Limitaciones

Los repositorios no estructurados tienen las siguientes limitaciones:

  • No puedes usar el objeto HierarchyConfig de Kubernetes en un repositorio no estructurado.

  • Los espacios de nombres abstractos no son compatibles con los repositorios no estructurados.

  • Si usas el comando nomos vet, agrega la marca --source-format=unstructured. Por ejemplo:

    nomos vet --source-format=unstructured

Objetos con alcance de espacio de nombres

Puedes declarar NamespaceSelectors en un repositorio no estructurado. Para declarar un NamespaceSelector, agrega la anotación metadata.namespace o NamespaceSelector. La declaración de ambas anotaciones no es válida. Si los recursos con alcance de espacio de nombres no declaran metadata.namespace o la anotación NamespaceSelector, el Sincronizador de configuración usa el espacio de nombres "predeterminado" del clúster. Para obtener más información, consulta Limita los espacios de nombres a los que afecta un archivo de configuración.

Objetos con permiso de clúster

En un repositorio no estructurado, ClusterSelectors funciona con normalidad.

Configura un repositorio no estructurado

Para configurar un repositorio no estructurado, establece el valor de spec.sourceFormat en unstructured en tu objeto RootSync:

  # root-sync.yaml
  apiVersion: configsync.gke.io/v1beta1
  kind: RootSync
  metadata:
    name: ROOT_SYNC_NAME
    namespace: config-management-system
  spec:
    sourceFormat: unstructured
    git:
      repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
      branch: main
      dir: config-sync-quickstart/multirepo/root
      auth: ssh
      secretRef:
        name: SECRET_NAME

Reemplaza lo siguiente:

  • ROOT_SYNC_NAME: Agrega el nombre de tu objeto RootSync. El nombre debe ser único en el clúster y no debe tener más de 26 caracteres.
  • SECRET_NAME por el nombre del Secret.

Convierte un repositorio jerárquico en un repositorio no estructurado

Si usas un repositorio jerárquico y deseas convertirlo en un repositorio no estructurado, ejecuta lo siguiente en tu repositorio:

nomos hydrate PATH

Reemplaza PATH por la ruta de acceso a tu directorio.

Esto crea un directorio compiled/ en el directorio de trabajo actual. Dentro de ese directorio, se crea un subdirectorio para cada clúster inscrito, con los archivos de configuración completamente resueltos, y cada subdirectorio se puede usar en un repositorio no estructurado.

Para obtener más detalles, consulta Comandos nomos.

Si prefieres convertir tu repositorio de forma manual, completa las siguientes instrucciones:

  1. Quita las configuraciones Repo en el 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 es compatible con un repositorio no estructurado. Por lo tanto, debes declarar el espacio de nombres de todos los recursos incluidos originalmente en el directorio namespaces/ y sus subdirectorios.

  3. No se admite la herencia de espacios de nombres en el repositorio no estructurado. Por lo tanto, debes declarar todos los recursos que se heredaron en los espacios de nombres subordinados, es decir, los que estaban originalmente en el directorio namespaces/.

Formato de ejemplo para un repositorio no estructurado

En el siguiente ejemplo, se muestra cómo puedes organizar tus archivos de configuración (incluidos los recursos de Google Cloud ) en un repositorio no estructurado:

├── 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

En este ejemplo, los archivos de configuración sin procesar se encuentran en un directorio raw-configs. Luego, puedes 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. Cuando configuras el Sincronizador de configuración, lo configuras para sincronizar desde el directorio manifests.

¿Qué sigue?