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 helm template y confirmar el manifiesto renderizado en el repositorio. Para obtener más información sobre cómo puedes hacerlo, consulta el instructivo Usa el Sincronizador de configuración con Helm.

Los repositorios no estructurados se recomiendan para la mayoría de los usuarios. Sin embargo, también puedes crear un repositorio jerárquico para separar archivos de configuración en categorías distintas. Si deseas crear políticas jerárquicas sin cumplir con las reglas del repositorio jerárquico, considera usar el controlador de jerarquía.

Limitaciones

Los repositorios no estructurados tienen las siguientes limitaciones:

  • No puedes usar los objetos de Kubernetes Repo y HierarchyConfig 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.

A diferencia de un repositorio jerárquico, un repositorio no estructurado no tiene que declarar todos los espacios de nombres de los objetos con alcance de espacio de nombres del repositorio. Un objeto puede definir un metadata.namespace sin tener un objeto de espacio de nombres coincidente en un repositorio no estructurado. Si el espacio de nombres ya existe en el clúster, el Sincronizador de configuración crea el objeto dentro de ese espacio de nombres. Si el espacio de nombres aún no existe en el clúster, el Sincronizador de configuración crea el espacio de nombres de manera implícita.

En un repositorio no estructurado, los objetos que declaran la anotación NamespaceSelector se aplican a todos los espacios de nombres que cumplan con las condiciones de NamespaceSelector's. Antes de crear un repositorio no estructurado con objetos que se usaron con anterioridad en un repositorio jerárquico, verifica que tus NamespaceSelectors no se apliquen a recursos adicionales.

Cuando quitas objetos con alcance de espacio de nombres de un repositorio no estructurado, el Sincronizador de configuración borra esos objetos, pero no quita los espacios de nombres que se hayan creado de manera implícita para ellos. Este comportamiento se produce porque el Sincronizador de configuración no puede inferir cuándo es seguro borrar un espacio de nombres que se creó de forma implícita, así que siempre se deja en el clúster.

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 o en el objeto ConfigManagement.

RootSync

El siguiente objeto RootSync configura Anthos Config Management para sincronizarse desde un repositorio no estructurado:

# root-sync.yaml
# If you are using a Config Sync version earlier than 1.7,
# use: apiVersion: configsync.gke.io/v1alpha1
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    branch: init
    dir: quickstart/multirepo/root
    auth: ssh
    secretRef:
      name: SECRET_NAME

Reemplaza SECRET_NAME por el nombre del Secret.

ConfigManagement

El siguiente objeto ConfigManagement configura una canalización de integración continua y especifica que el repositorio con el que se sincroniza no está estructurado:

# config-management.yaml

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  # clusterName is required and must be unique among all managed clusters
  clusterName: CLUSTER_NAME
  sourceFormat: unstructured
  git:
    syncRepo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    syncBranch: init
    secretType: ssh
    policyDir: ci-pipeline-unstructured

Para obtener una lista completa de los campos que puedes agregar al campo spec, consulta Campos de ConfigManagement.

Convierte un repositorio jerárquico en un repositorio no estructurado

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

nomos hydrate [/path/to/directory]

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 hacerlo de forma manual, sigue estas instrucciones para convertirlo:

  1. Quita las opciones de configuración Repo del directorio system/ de tu repositorio de Git. El recurso Repo no es necesario para el repositorio no estructurado.

  2. El directorio de espacio de nombres abstracto no es compatible con el repositorio no estructurado. Por lo tanto, debes declarar el espacio de nombres de todos los recursos que originalmente se encontraban en el directorio namespaces/ y en 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/.

¿Qué sigue?