Ajouter des configurations à une source de vérité

Cette page explique comment ajouter et organiser des configurations stockées dans une source de vérité.

À propos des configurations

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 une source de vérité. Config Sync est compatible avec les dépôts Git, les images OCI et les charts Helm en tant que source de vérité. Les configurations 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 une source de vérité. 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 ressourcesGoogle 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.

Limites

• Certaines ressources Kubernetes contiennent des champs immuables, comme les sélecteurs de pods dans un objet de déploiement. Vous ne pouvez pas modifier un champ immuable dans une configuration en modifiant la valeur de la source de vérité. Toute tentative de modification entraîne une erreur KNV2009. Si vous devez modifier un champ immuable, supprimez l'objet de votre source de vérité, attendez que Config Sync le supprime du cluster, puis recréez l'objet dans votre source de vérité avec vos modifications.

• Si vous utilisez des sous-modules Git, vous devez accorder à Config Sync l'accès à tous les dépôts, y compris les sous-modules.

• Vous ne pouvez pas utiliser Config Sync pour gérer directement les rôles Kubernetes intégrés. GKE est fourni avec des rôles destinés aux utilisateurs intégrés, tels que cluster-admin, admin, edit et view. Vous ne pouvez pas gérer directement ces ClusterRoles avec Config Sync, sinon Config Sync entre en conflit avec GKE. Pour ajouter des autorisations aux rôles de cluster intégrés, utilisez l'agrégation de rôles pour les modifier indirectement. Pour modifier les rôles, créez un ClusterRole au nom unique dans votre source de vérité avec les annotations appropriées.

Choisir comment organiser vos configurations

Config Sync utilise une source de vérité pour le stockage des configurations et le contrôle des versions. Vous pouvez choisir deux formats comme source de vérité : non structuré et hiérarchique.

Le format source non structuré vous permet d'organiser les configurations de la manière qui vous convient le mieux. 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 le format source 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, lorsque vous configurez des objets RepoSync, vous devez utiliser le format source non structuré.

Fonctionnalités compatibles pour les formats non structurés et hiérarchiques

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

Quand ajouter des configurations à la source ?

Si vous créez un format non structuré, vous pouvez commencer à y ajouter des configurations dès sa création. Si vous créez un format hiérarchique, utilisez la commande nomos init pour initialiser la source de vérité 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éé la source de vérité et y avoir ajouté des configurations, utilisez la commande nomos vet pour vérifier la structure de la source de vérité et vérifier la syntaxe et la validité de vos configurations.

Configurer Config Sync pour lire les données à partir de la source de vérité

Après avoir créé une source de vérité et y avoir placé vos configurations, vous pouvez configurer Config Sync pour lire les données de la source. Une fois cette étape terminée, Config Sync synchronise les configurations de votre source de vérité avec vos clusters.

Vous pouvez configurer l'emplacement de la source de vérité lorsque vous installez Config Sync, puis modifier la configuration de Config Sync ultérieurement. Outre l'emplacement de la source de vérité, vous pouvez spécifier une branche ou un sous-répertoire à surveiller, si la source contient des éléments autres que des configurations.

Si vous utilisez un format 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 à la source de vérité de déploiement d'une équipe produit donnée. Toutefois, lorsque vous accordez à une personne l'accès à une source de vérité de déploiement, cette personne reçoit également le même rôle RBAC que le rapprochement exécuté pour cette source de vérité.

Pour configurer l'authentification et l'autorisation entre Config Sync et la source de vérité, 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 les API RootSync et RepoSync.

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.

Étapes suivantes

• Découvrez comment gérer des espaces de noms et des objets à l'échelle d'un espace de noms.
• Pour savoir comment publier une image OCI, consultez la page Synchroniser les artefacts OCI à partir d'Artifact Registry.
• Pour savoir comment synchroniser à partir d'un graphique Helm, consultez la section Synchroniser des graphiques Helm à partir d'Artifact Registry.