Ajouter des configurations aux 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.

Lorsque Config Sync gère ces ressources, il synchronise vos clusters enregistrés à l'aide de configurations. Une configuration correspond à un fichier YAML ou JSON stocké dans un dépôt Git. Elles contiennent le même type de détails de configuration que vous pouvez appliquer manuellement à un cluster à l'aide de la commande kubectl apply. Vous pouvez créer une configuration pour tout objet Kubernetes pouvant exister dans un cluster. Cependant, certains objets Kubernetes, tels que Secret, contiennent des informations sensibles qu'il n'est peut-être pas approprié de stocker dans un dépôt Git. Jugez vous-même s'il est pertinent de gérer ces types d'objets à l'aide de Config Sync.

Vous pouvez également utiliser Config Sync avec Config Connector pour synchroniser les configurations pour les ressources Google Cloud. Pour en savoir plus sur l'utilisation de Config Connector, consultez la page Gérer les ressources Google Cloud à l'aide de Config Connector. Vous pouvez également simplifier l'installation de Config Sync et de Config Connector en configurant Config Controller.

Cette page vous explique comment ajouter des configurations à vos dépôts. Pour savoir comment créer une configuration, consultez la section Créer des configurations.

Choisir comment organiser vos configurations

Config Sync utilise un dépôt Git pour le stockage des configurations et le contrôle des versions. Vous pouvez choisir deux formats pour votre 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 ou générez des configurations à l'aide d'un outil tel que kustomize, kpt ou Helm. Pour obtenir un exemple d'organisation de vos configurations, consultez la section Exemple de format pour un dépôt non structuré.

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 format non structuré est recommandé pour la plupart des utilisateurs. En outre, les dépôts d'espaces de noms doivent utiliser le format de dépôt non structuré.

Fonctionnalités compatibles pour les dépôts non structurés et hiérarchiques

Le tableau suivant met en évidence les différences entre les formats non structurés et hiérarchiques :

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

Ajouter des configurations au dépôt

Si vous créez un dépôt non structuré, vous pouvez commencer à y ajouter des configurations dès sa création. Si vous créez un dépôt hiérarchique, utilisez la commande nomos init pour initialiser le dépôt ou créez la structure du répertoire manuellement.

Vous ne pouvez pas procéder au commit de répertoires vides dans un dépôt Git. Par conséquent, avant de configurer Config Sync, créez des configurations et ajoutez-les à votre dépôt.

Après avoir créé le dépôt et y avoir ajouté les configurations, utilisez la commande nomos vet pour vérifier la structure du dépôt, et vérifier la syntaxe et la validité de vos configurations.

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

Après avoir créé un dépôt et y avoir placé vos configurations, vous pouvez configurer Config Sync pour lire les données du dépôt. Une fois cette étape terminée, Config Sync synchronise les configurations de votre dépôt avec vos clusters.

Vous pouvez configurer l'emplacement du dépôt lorsque vous installez Config Sync, puis modifier la configuration de Config Sync ultérieurement. 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.

Si vous utilisez un dépôt hiérarchique et que vous installez Config Sync manuellement avec kubectl, ne placez pas la configuration de l'opérateur dans le répertoire system/, ou tout autre répertoire réservé, tel que cluster/ ou namespaces/. Si vous placez la configuration dans l'un des répertoires réservés, nomos vet échoue et journalise une erreur telle que KNV1033 : IllegalSystemResourcePlacementError, KNV1038 : IllegalKindInNamespacesError ou KNV1039 : IllegalKindInClusterError.

Vous pouvez accorder aux utilisateurs l'accès au dépôt de déploiement d'une équipe produit donnée. Toutefois, lorsque vous accordez à une personne l'accès à un dépôt de déploiement, cette personne reçoit également le même rôle RBAC que le rapprochement exécuté 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 les mutations d'objets

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 la synchronisation à partir de plusieurs dépôts et utiliser la version 1.7.0 ou ultérieure. La synchronisation à partir de plusieurs dépôts est activée par défaut si vous utilisez Google Cloud Console ou Google Cloud CLI pour installer Config Sync avec la version 1.7.0 ou ultérieure. Si vous avez installé Config Sync à l'aide de kubectl, définissez spec.enableMultiRepo sur true dans votre objet ConfigManagement.

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