Utiliser des configurations dans les dépôts Git

Config Sync est conçu pour les opérateurs qui gèrent de nombreux clusters. Vous pouvez vous assurer que vos clusters respectent les normes métier et de conformité en laissant Config Sync gérer des objets Kubernetes importants, tels que Namespace, Role, RoleBinding ou ResourceQuota, pour l'ensemble de votre parc.

Config Sync synchronise vos clusters enregistrés à l'aide de configurations. Une configuration correspond à un fichier YAML ou JSON stocké dans votre dépôt Git et contenant des types d'informations de configuration semblables à ceux que vous pouvez appliquer manuellement à un cluster au moyen de la commande kubectl apply. Vous pouvez créer une configuration pour tout objet Kubernetes pouvant exister dans un cluster. Cet article aborde les points suivants :

  • Comment organiser les configurations dans un répertoire.
  • Comment initialiser un dépôt Git pour stocker les configurations.
  • Découvrez comment configurer Config Sync pour lire les configurations.

Stocker des configurations dans les dépôts

Config Sync utilise un dépôt Git pour le stockage des configurations et le contrôle des versions, et effectue des actions en fonction de son contenu. Dans Config Sync, ce dépôt est appelé le dépôt. Il existe deux formats différents pour un dépôt : non structuré et hiérarchique.

  • Le format source non structuré vous permet d'organiser les configurations de votre dépôt de la manière la plus pratique pour vous. Ce format peut être particulièrement utile si vous organisez et/ou générez des configurations à l'aide d'un outil tel que kustomize, kpt ou helm.
  • Le format source hiérarchique (ou structuré) répartit les configurations en catégories distinctes pour vous aider à les organiser. Les différentes catégories sont les suivantes : la configuration système, les métadonnées du cluster, la configuration au niveau du cluster et la configuration de l'espace de noms. Pour en savoir plus sur la structure du dépôt hiérarchique, consultez la section Structure du dépôt hiérarchique.

Le tableau suivant met en évidence les différences entre les formats de dépôts hiérarchiques et non structurés :

Fonctionnalités Format de dépôt hiérarchique Format de dépôt non structuré
Sélecteurs d'espace de noms Compatible Compatible
Sélecteurs de clusters Compatible Compatible
Espaces de noms abstraits Compatible Non disponible
Repo objet Compatible Non disponible
Objets HierarchyConfig Compatible Non disponible
Espaces de noms hiérarchiques dans Hierarchy Controller Non disponible Compatible
Format utilisé pour un dépôt d'espaces de noms Non disponible Compatible
Format utilisé pour un dépôt racine Compatible Compatible
Utilisé conjointement avec Hierarchy Controller Option déconseillée Compatible
La commande nomos init Compatible Non disponible
La commande nomos hydrate Compatible Non disponible
La commande nomos vet Compatible Compatible avec l'option --source-format=unstructured
Toutes les autres commandes nomos Compatible Compatible

Exemple de mise en page de configuration non structurée

L'exemple suivant vous montre un moyen d'organiser vos configurations, y compris les ressources Google Cloud.

Vous pouvez placer vos configurations brutes dans un répertoire raw-configs, utiliser un script ou un pipeline automatisé pour afficher les configurations brutes, et stocker le résultat dans le répertoire manifests. En fin de compte, vous configurez Config Sync pour qu'il se synchronise à partir de votre répertoire manifests.

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

Initialiser un dépôt Git

La manière dont vous souhaitez initialiser un dépôt dépend de sa structure.

  • Pour le format non structuré, vous pouvez initialiser un dépôt Git vide et commencer à ajouter des configurations dans le dépôt.
  • Pour le format hiérarchique, vous pouvez initialiser un dépôt à l'aide de la commande nomos init ou créer la structure de répertoires manuellement.

Configurer Config Sync pour lire les données du dépôt

Vous pouvez configurer l'emplacement du dépôt lorsque vous installez Config Sync, puis modifier sa configuration ultérieurement dans le fichier de configuration de Config Sync Operator. Outre l'emplacement du dépôt, vous pouvez spécifier une branche Git et un sous-répertoire à surveiller, si le dépôt Git contient des éléments autres que des configurations.

Après avoir mis à jour le fichier de configuration, vous l'appliquez au cluster à l'aide de la commande kubectl apply. Config Sync ne gère pas la configuration de l'opérateur lui-même.

Vous pouvez accorder aux utilisateurs l'accès au dépôt de déploiement d'une équipe produit donnée. Toutefois, vous devez savoir que lorsque vous accordez à une personne l'accès à un dépôt de déploiement, cette personne se voit également attribuer le même RBAC que le processus de rapprochement en cours d'exécution pour ce dépôt.

Pour configurer l'authentification et l'autorisation entre Config Sync et le dépôt, reportez-vous à l'étape d'installation décrite dans la section Configurer le secret git-creds.

Ignorer des mutations d'objet

Si vous ne souhaitez pas que Config Sync conserve l'état de l'objet dans un cluster après son existence, vous pouvez ajouter l'annotation client.lifecycle.config.k8s.io/mutation: ignore à l'objet dans lequel vous souhaitez que Config Sync ignore les mutations. Pour utiliser l'annotation, vous devez activer le mode multidépôt et utiliser une version 1.7.0 ou ultérieure.

L'exemple suivant montre comment ajouter l'annotation à un objet :

metadata:
  annotations:
    client.lifecycle.config.k8s.io/mutation: ignore

Vous ne pouvez pas modifier manuellement cette annotation sur les objets gérés du cluster.

Étape suivante