Organiser les fichiers de configuration dans une source de vérité

Cette page explique comment organiser les configurations dans une source de vérité.

À mesure que votre organisation se développe, vous devez probablement gérer les configurations d'une flotte de clusters et prendre en charge plusieurs équipes travaillant dans les mêmes dépôts. Pour qu'une stratégie GitOps soit efficace, il est essentiel de s'assurer que les configurations sont appliquées aux bons clusters et que les équipes peuvent travailler sans se gêner mutuellement.

À propos des fichiers de configuration

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 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é. Réfléchissez bien avant de gérer ces types d'objets à l'aide de Config Sync.

Conditions requises et limites

  • Certaines ressources Kubernetes contiennent des champs immuables, comme les sélecteurs de pods dans un objet Deployment. 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 ClusterRoles Kubernetes intégrés. GKE est fourni avec des rôles visibles par l'utilisateur intégrés, tels que cluster-admin, admin, edit et view. Vous ne pouvez pas gérer directement ces ClusterRoles avec Config Sync, car cela entraînerait un conflit entre Config Sync et GKE. Pour ajouter des autorisations aux ClusterRoles intégrés, utilisez l'agrégation de rôles pour les modifier indirectement. Pour modifier les rôles, créez un ClusterRole portant un nom unique dans votre source de vérité avec les annotations appropriées.

Organiser votre source de référence

Vous pouvez configurer Config Sync pour qu'il se synchronise à partir d'un dépôt entier, ou à partir de dossiers ou de branches spécifiques. Grâce à cette flexibilité, organisez vos fichiers de configuration en fonction des besoins de votre équipe ou de votre organisation.

Nous vous recommandons de définir sourceFormat sur unstructured lorsque vous configurez Config Sync. Le type de source structurée (hiérarchique) nécessite une structure de dossiers très spécifique pour synchroniser correctement vos configurations et ajoute une complexité inutile dans la plupart des cas.

La plupart de la documentation de Config Sync, y compris cette page, utilise le format non structuré par défaut. Toutefois, si nécessaire, vous trouverez des informations sur le format hiérarchique sur la page Utiliser un dépôt hiérarchique.

Lorsque vous utilisez une source non structurée, vous pouvez organiser vos configurations en fonction du workflow de votre équipe. Cette section présente quelques modèles courants pour structurer votre dépôt.

Mise en page basée sur l'environnement

Une approche courante consiste à organiser votre dépôt par environnement.

├── cluster-essentials/
│   ├── crds/
│   └── namespace.yaml
├── environments/
│   ├── dev/
│   │   ├── backend/
│   │   └── frontend/
│   ├── staging/
│   │   ├── backend/
│   │   └── frontend/
│   └── prod/
│       ├── backend/
│       └── frontend/
└── system/
    └── monitoring/

Dans cet exemple, la source de vérité est organisée comme suit :

  • cluster-essentials/ : contient la configuration qui s'applique à tous les clusters, quel que soit l'environnement. Cela peut inclure des ressources telles que les définitions de ressources personnalisées (CRD) et les espaces de noms essentiels.
  • environments/ : répertoire parent pour toutes les configurations spécifiques à l'environnement.
  • system/ : contient les configurations des services au niveau du système, comme la surveillance.

Cette approche est facile à comprendre et à parcourir, et fournit un chemin de promotion clair pour les modifications d'un environnement à un autre.

Lorsque vous configurez Config Sync dans ce scénario, vous créez plusieurs objets RootSync sur chaque cluster. Par exemple, un cluster de développement comporte des objets RootSync synchronisés à partir de cluster-essentials/, system/ et environments/dev/.

Mise en page basée sur les clusters

Si vous souhaitez gérer un parc de clusters individuels avec des configurations distinctes, une mise en page basée sur les clusters peut être plus appropriée.

├── clusters/
│   ├── cluster-a/
│   │   ├── apps/
│   │   └── networking/
│   ├── cluster-b/
│   │   ├── apps/
│   │   └── networking/
│   └── cluster-c/
│       ├── apps/
│       └── networking/
└── shared/
    ├── roles/
    └── policies/

Dans cet exemple, la source de vérité est organisée comme suit :

  • clusters/ : contient un répertoire pour chaque cluster que vous gérez.
  • shared/ : contient les configurations communes à tous les clusters, comme les rôles RBAC et les stratégies de sécurité.

Cette approche est efficace pour gérer de nombreux clusters si ceux-ci ont tous des configurations uniques, car elle permet de définir clairement la propriété et l'isolement des configurations. Cette approche peut être plus complexe à gérer si vous avez de nombreuses configurations de cluster partagées.

Lorsque vous configurez Config Sync dans ce scénario, vous pouvez utiliser un RepoSync pour configurer chaque cluster afin qu'il se synchronise à la fois à partir de shared et du répertoire spécifique au cluster.

Mise en page basée sur l'équipe

Pour les organisations dans lesquelles différentes équipes gèrent différentes applications ou différents services, une mise en page basée sur les équipes peut être efficace. Cette approche permet d'aligner la structure de la source de vérité sur celle de votre organisation.

├── teams/
│   ├── team-alpha/
│   │   ├── app-one/
│   │   └── app-two/
│   ├── team-beta/
│   │   ├── service-a/
│   │   └── service-b/
│   └── team-gamma/
│       ├── data-pipeline/
│       └── dashboard/
└── platform/
    ├── cluster-roles/
    └── storage-classes/

Dans cet exemple, la source de référence est organisée comme suit :

  • teams/ : organise la configuration par équipe, chaque équipe gérant ses propres configurations d'applications et de services.
  • platform/ : contient les configurations à l'échelle du cluster qu'une équipe de plate-forme centrale gère et que toutes les équipes utilisent.

Cette approche permet aux équipes de gérer leurs propres cycles de configuration et de publication, et réduit le risque que les modifications apportées par une équipe aient un impact accidentel sur une autre équipe. Toutefois, cette approche nécessite une gestion minutieuse des dépendances entre les équipes chargées des applications et celles chargées de la plate-forme.

Lorsque vous configurez Config Sync pour ce scénario, chaque équipe utilise un objet RootSync pour synchroniser les configurations. Par exemple, team-alpha se synchronise à partir de teams/team-alpha/.

Valider les fichiers de configuration

Après avoir créé une source de vérité, organisé vos fichiers de configuration et les y avoir ajoutés, utilisez la commande nomos vet --source-format=unstructured pour vérifier la syntaxe et la validité de vos configurations. Cela vous permet d'éviter les erreurs pendant ou après une synchronisation.

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, ajoutez l'annotation client.lifecycle.config.k8s.io/mutation: ignore à l'objet dans lequel vous souhaitez que Config Sync ignore les mutations.

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.

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é, exécutez la commande suivante :

nomos hydrate PATH

Remplacez PATH par le chemin d'accès au répertoire.

Cela crée un répertoire compiled/ dans le répertoire de travail actuel. Dans ce répertoire, un sous-répertoire est créé pour chaque cluster enregistré. Ces sous-répertoires contiennent les configurations entièrement résolues et peuvent être utilisés dans un dépôt non structuré.

Pour en savoir plus, consultez la section Commandes nomos.

Si vous préférez convertir manuellement le dépôt, procédez comme suit :

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

  2. Le répertoire d'espace de noms abstrait n'est pas disponible dans un dépôt non structuré. Par conséquent, déclarez l'espace de noms de toutes les ressources initialement incluses dans le répertoire namespaces/ et ses sous-répertoires.

  3. L'héritage des espaces de noms n'est pas disponible dans un dépôt non structuré. Par conséquent, déclarez toutes les ressources qui sont à l'origine héritées dans les espaces de noms descendants (celles qui se trouvent initialement dans le répertoire namespaces/).

Étapes suivantes