Utiliser un dépôt non structuré

L'utilisation d'un dépôt non structuré vous permet d'organiser votre dépôt arbitrairement. Cette flexibilité vous permet de synchroniser votre configuration Kubernetes existante avec votre dépôt Config Sync. Par exemple, si vous souhaitez synchroniser un chart Helm avec votre cluster, vous pouvez exécuter helm template et effectuer un commit sur le manifeste affiché dans votre dépôt. Un dépôt non structuré vous permet également de créer des sous-dossiers de ressources.

Les dépôts non structurés sont recommandés pour la plupart des utilisateurs. Toutefois, vous pouvez également créer un dépôt hiérarchique pour séparer les configurations en catégories distinctes. Si vous souhaitez créer des stratégies hiérarchiques sans respecter les règles du dépôt hiérarchique, envisagez d'utiliser Hierarchy Controller.

Limites

Les dépôts non structurés présentent les limites suivantes :

  • Vous ne pouvez pas utiliser les objets Kubernetes Repo et HierarchyConfig dans un dépôt non structuré.

  • Les espaces de noms abstraits ne sont pas compatibles avec les dépôts non structurés.

  • Si vous utilisez la commande nomos vet, ajoutez l'option --source-format=unstructured. Exemple :

    nomos vet --source-format=unstructured
    

Objets à l'échelle d'un espace de noms

Vous pouvez déclarer des objets NamespaceSelector dans un dépôt non structuré. Pour déclarer un objet NamespaceSelector, ajoutez l'annotation metadata.namespace ou NamespaceSelector. Le fait de déclarer les deux annotations n'est pas valide. Si les ressources à l'échelle de l'espace de noms ne déclarent pas metadata.namespace ou l'annotation NamespaceSelector, Config Sync utilise l'espace de noms "par défaut" du cluster.

Contrairement à un dépôt hiérarchique, un dépôt non structuré ne doit pas déclarer tous les espaces de noms pour les objets à l'échelle d'un espace de noms dans le dépôt. Un objet peut définir un metadata.namespace sans posséder d'objet d'espace de noms correspondant dans un dépôt non structuré. Si l'espace de noms existe déjà sur le cluster, Config Sync crée l'objet dans cet espace de noms. Si l'espace de noms n'existe pas encore sur le cluster, Config Sync le crée implicitement.

Dans un dépôt non structuré, les objets qui déclarent l'annotation NamespaceSelector sont appliqués à tous les espaces de noms qui satisfont aux conditions de l'objet NamespaceSelector's. Avant de créer un dépôt non structuré avec des objets précédemment utilisés dans un dépôt hiérarchique, vérifiez que vos objets NamespaceSelectors ne s'appliquent pas aux autres ressources.

Lorsque vous supprimez des objets à l'échelle d'un espace de noms d'un dépôt non structuré, Config Sync supprime ces objets, mais ne supprime aucun espace de noms qui aurait pu être créé implicitement pour ces objets. Cela est dû au fait que Config Sync ne peut pas déterminer à quel moment il peut supprimer sans risques un espace de noms créé implicitement, et donc laisse toujours cet espace de noms dans le cluster.

Objets à l'échelle d'un cluster

Dans un dépôt non structuré, les objets ClusterSelectors fonctionnent normalement.

Configurer un dépôt non structuré

Pour configurer un dépôt non structuré, définissez la valeur de spec.sourceFormat sur unstructured dans votre objet RootSync ou votre objet ConfigManagement.

RootSync

L'objet RootSync suivant configure Config Sync pour qu'il se synchronise à partir d'un dépôt non structuré :

# 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

Remplacez SECRET_NAME par le nom su secret.

ConfigManagement

L'objet ConfigManagement suivant configure un pipeline d'intégration continue et spécifie que le dépôt avec lequel il se synchronise est non structuré :

# 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

Pour obtenir la liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs ConfigManagement.

Convertir un dépôt hiérarchique en dépôt non structuré

Si vous utilisez un dépôt hiérarchique et que vous souhaitez le convertir en dépôt non structuré, procédez comme suit pour le convertir :

  1. Supprimez les configurations Repo du répertoire system/ de votre dépôt Git. La ressource Repo n'est pas nécessaire pour le dépôt non structuré.

  2. L'espace de noms abstrait n'est pas compatible avec le dépôt non structuré. Par conséquent, vérifiez les ressources dans le répertoire namespaces/ et assurez-vous que chaque ressource dispose d'un espace de noms déclaré.

  3. L'héritage des espaces de noms n'est pas disponible dans un dépôt non structuré. Par conséquent, vérifiez les ressources qui se trouvent dans le répertoire namespaces/, mais pas dans un sous-répertoire namespaces/NAMESPACE/. Dans un dépôt non structuré, ces ressources ne sont plus héritées par chaque espace de noms dans namespaces/. Vous devez les déclarer dans chaque répertoire /namespaces/NAMESPACE.

Étape suivante