Si usas un repositorio sin estructurar, puedes organizar tu repositorio de la forma que más te convenga. Esta flexibilidad te permite sincronizar tu configuración de Kubernetes con tu repositorio de Config Sync. Por ejemplo, si quieres sincronizar un gráfico de Helm con tu clúster, puedes ejecutar el comando helm template
y confirmar el manifiesto renderizado en tu repositorio. Para obtener más información, consulta el tutorial Usar Config Sync con Helm.
Recomendamos los repositorios no estructurados para la mayoría de los casos prácticos. Sin embargo, también puedes crear un repositorio jerárquico para separar las configuraciones en categorías distintas.
Limitaciones
Los repositorios no estructurados tienen las siguientes limitaciones:
No puedes usar el objeto de Kubernetes
HierarchyConfig
en un repositorio sin estructurar.Los espacios de nombres abstractos no se admiten en los repositorios no estructurados.
Si usas el comando
nomos vet
, añade la marca--source-format=unstructured
. Por ejemplo:nomos vet --source-format=unstructured
Objetos centrados en espacios de nombres
Puedes declarar NamespaceSelectors en un repositorio no estructurado. Para declarar un NamespaceSelector, añade la anotación metadata.namespace
o NamespaceSelector
. Declarar ambas anotaciones no es válido. Si los recursos con ámbito de espacio de nombres no declaran metadata.namespace
o la anotación NamespaceSelector
, Config Sync usa el espacio de nombres "default" del clúster.
Para obtener más información, consulta Limitar los espacios de nombres a los que afecta una configuración.
Objetos centrados en clústeres
En un repositorio no estructurado, la función ClusterSelectors
funciona con normalidad.
Configurar un repositorio no estructurado
Para configurar un repositorio no estructurado, asigna el valor unstructured
a spec.sourceFormat
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
Haz los cambios siguientes:
ROOT_SYNC_NAME
: añade el nombre de tu objeto RootSync. El nombre debe ser único en el clúster y no tener más de 26 caracteres.SECRET_NAME
con el nombre del secreto.
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 lo siguiente en tu repositorio:
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, con las configuraciones totalmente resueltas. Cada subdirectorio se puede 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:
Elimina las configuraciones de
Repo
del directoriosystem/
de tu repositorio de Git. El recursoRepo
no es necesario para un repositorio no estructurado.El directorio de espacio de nombres abstracto no se admite en 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.La herencia de espacios de nombres no se admite en el repositorio no estructurado. Por lo tanto, debe declarar todos los recursos que se hereden originalmente en los espacios de nombres descendientes, es decir, los que se encuentren originalmente en el directorio
namespaces/
.
Formato de ejemplo de un repositorio no estructurado
En el siguiente ejemplo se muestra cómo puedes organizar tus configuraciones (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, las configuraciones sin procesar se encuentran en un directorio raw-configs
. Después, puedes usar una secuencia de comandos o una canalización automatizada para renderizar las configuraciones sin procesar y almacenar el resultado en el directorio manifests
. Cuando configures Config Sync, lo configuras para que se sincronice desde tu directorio manifests
.
Siguientes pasos
- Crear objetos centrados en el clúster
- Crear objetos centrados en espacios de nombres
- Instalar Config Sync
- Configurar la sincronización desde varios repositorios