Descripción general de los repositorios jerárquicos

En esta página, se describe cómo el Sincronizador de configuración lee la configuración de un repositorio jerárquico y aplica automáticamente la configuración resultante a tus clústeres.

Si deseas obtener más flexibilidad estructural (por ejemplo, deseas crear subcarpetas de recursos), puedes crear un repositorio no estructurado. Los repositorios no estructurados se recomiendan para la mayoría de los usuarios y se pueden combinar con el Controlador de jerarquía a fin de proporcionar herencia de espacios de nombres similar a la que ofrecen los repositorios jerárquicos.

Para comprender cómo el Sincronizador de configuración usa un repositorio jerárquico, es útil si estás familiarizado con los repositorios de Git y la interfaz de línea de comandos git.

Estructura del repositorio jerárquico

En los repositorios jerárquicos, el Sincronizador de configuración aprovecha la estructura similar a un sistema de archivos que tiene Git y la usa para determinar a qué clústeres o espacios de nombres pertenece una configuración.

namespaces/

El directorio namespaces/ contiene opciones de configuración para espacios de nombres y objetos con alcance de espacio de nombres. La estructura dentro de namespaces/ es el mecanismo que dirige la herencia del espacio de nombres. Puedes limitar los espacios de nombres que pueden heredar un archivo de configuración mediante un NamespaceSelector.

cluster/

El directorio cluster/ contiene opciones de configuración que se aplican a clústeres enteros, en lugar de a espacios de nombres. De forma predeterminada, cualquier configuración del directorio cluster/ se aplica a todos los clústeres inscritos en el Sincronizador de configuración. Puedes limitar los clústeres a los que una configuración puede afectar mediante un ClusterSelector.

clusterregistry/

El directorio clusterregistry/ es opcional y contiene opciones de configuración para ClusterSelectors. Los ClusterSelectors limitan los clústeres a los que se aplica una configuración y se mencionan en las opciones de configuración que se encuentran en los directorios cluster/ y namespaces/.

system/

El directorio system/ contiene opciones de configuración para el operador. Consulta la página sobre cómo instalar el Sincronizador de configuración para obtener más información sobre cómo configurarlo.

Ejemplo de repositorio jerárquico

En la siguiente estructura de directorios, se muestra cómo usar un repositorio jerárquico del Sincronizador de configuración para configurar un clúster de Kubernetes que comparten dos equipos diferentes, team-1 y team-2.

  • Cada equipo tiene su propio espacio de nombres y cuenta de servicio de Kubernetes, así como cuotas de recursos, políticas de red y vinculaciones de funciones.
  • El administrador del clúster configura una política en namespaces/limit-range.yaml para restringir las asignaciones de recursos (a Pods o contenedores) en ambos espacios de nombres.
  • El administrador del clúster también configura ClusterRoles y ClusterRoleBinidngs.

Un repositorio jerárquico del Sincronizador de configuración válido debe incluir tres subdirectorios: cluster/, namespaces/ y system/.

El directorio cluster/ contiene opciones de configuración que se aplican a clústeres enteros (como ClusterRole, ClusterRoleBinding), en lugar de a espacios de nombres.

El directorio namespaces/ contiene opciones de configuración para los objetos de espacio de nombres y los objetos con alcance de espacio de nombres. Cada subdirectorio de namespaces/ incluye la configuración para un objeto de espacio de nombres y todos los objetos con permisos de espacio de nombres del espacio de nombres. El nombre de un subdirectorio debe ser el mismo que el nombre del objeto del espacio de nombres. Los objetos con permisos de espacios de nombres que se deben crear en cada espacio de nombres se pueden colocar directamente en namespaces/ (por ejemplo, namespaces/limit-range.yaml).

El directorio system/ contiene opciones de configuración para el operador de Config Management.

├── cluster
│   ├── clusterrolebinding-namespace-reader.yaml
│   ├── clusterrole-namespace-reader.yaml
│   ├── clusterrole-secret-admin.yaml
│   └── clusterrole-secret-reader.yaml
├── namespaces
│   ├── limit-range.yaml
│   ├── team-1
│   │   ├── namespace.yaml
│   │   ├── network-policy-default-deny-egress.yaml
│   │   ├── resource-quota-pvc.yaml
│   │   ├── rolebinding-secret-reader.yaml
│   │   └── sa.yaml
│   └── team-2
│       ├── namespace.yaml
│       ├── network-policy-default-deny-all.yaml
│       ├── resource-quota-pvc.yaml
│       ├── rolebinding-secret-admin.yaml
│       └── sa.yaml
├── README.md
└── system
    └── repo.yaml

¿Qué sigue?