Bonnes pratiques GitOps Kubernetes avec Config Sync

Cette page constitue un point de départ pour vous aider à planifier et à concevoir des pipelines GitOps CI/CD pour Kubernetes, ce qui peut vous aider à tirer le meilleur parti de Config Sync.

GitOps lui-même est une bonne pratique universelle pour les organisations qui gèrent la configuration Kubernetes à grande échelle. Cependant, de nombreux choix s'offrent à vous pour concevoir l'architecture de cette solution. Comprendre vos options, ainsi que les avantages et les inconvénients de ces décisions, peut vous aider à éviter de réécrire votre architecture à l'avenir.

Vous n'avez pas besoin d'appliquer toutes les bonnes pratiques répertoriées sur cette page. Les bonnes pratiques à adopter dépendent de votre situation particulière. L'objectif de cette page est de vous aider à prendre des décisions éclairées lors de la configuration de votre architecture GitOps.

Utiliser un dépôt de packages privé et centralisé

L'utilisation d'un dépôt central pour les packages publics ou internes (tels que Helm ou kpt) peut aider les équipes à trouver plus facilement les packages. Vous pouvez utiliser des services tels qu'Artifact Registry ou les dépôts Git.

L'équipe chargée de la plate-forme peut mettre en œuvre des stratégies grâce auxquelles les équipes applications ne peuvent utiliser des packages qu'à partir du dépôt central. L'entreprise peut également utiliser le dépôt central sous la forme d'un ensemble de packages approuvés.

Vous pouvez limiter les autorisations d'écriture sur le dépôt à un petit nombre d'ingénieurs. Le reste de l'organisation peut disposer d'un accès en lecture. Nous vous recommandons de mettre en œuvre un processus de promotion des packages dans le dépôt central et de diffusion des mises à jour.

Le tableau suivant présente les avantages et les inconvénients de l'utilisation d'un dépôt de packages privé et centralisé :

Avantages

Inconvénients

Ingérez des packages publics à un rythme défini, afin d'éviter toute rupture par la connectivité ou la perte d'utilisateurs en amont. Examinez et analysez les packages partagés. Fournit un moyen simple de savoir ce qui est utilisé et pris en charge. Par exemple, les équipes peuvent plus facilement trouver le déploiement Redis standard stocké dans le dépôt central. Modifiez les packages en amont afin de vous assurer qu'ils répondent aux normes internes, telles que les valeurs par défaut, l'ajout de libellés et les dépôts d'images de conteneurs.

Quelqu'un doit gérer le dépôt central. Ajout de processus pour les équipes de développement.

Créer des dépôts "wet"

Créez des dépôts avec la sortie YAML correspondant à l'état souhaité de votre cluster ou de votre espace de noms. Les modifications apportées au dépôt "wet" ou entièrement hydraté doivent être faciles à examiner à l'aide d'une différence. Une bonne pratique consiste à n'apporter des modifications qu'au dépôt "wet" via un processus de révision (par exemple, dans GitHub, il s'agit d'une demande d'extraction).

Le tableau suivant répertorie les avantages et les inconvénients de la création de dépôts "wet" :

Avantages	Inconvénients
Il est plus facile d'examiner la différence. Aucun traitement n'est nécessaire pour connaître l'état souhaité de la configuration.	Une configuration entièrement hydratée peut entraîner la répétition du code YAML.

Décalez vers la gauche pour valider les configurations

Attendre que Config Sync commence à se synchroniser pour vérifier les problèmes peut créer des commits Git inutiles et une longue boucle de rétroaction. De nombreux problèmes peuvent être détectés avant qu'une configuration ne soit appliquée à un cluster à l'aide des fonctions du programme de validation kpt telles que kubeval.

Le tableau suivant répertorie les avantages et les inconvénients de la vérification des problèmes avant d'appliquer une configuration :

Avantages	Inconvénients
L'affichage des modifications de configuration dans une requête de modification permet d'éviter que les erreurs ne parviennent à un dépôt. Réduit l'impact des problèmes dans les configurations partagées.	Vous devez ajouter des outils et une logique à votre processus de commit pour vous aider à détecter les problèmes.

Utiliser des dossiers au lieu de branches

Utilisez des dossiers pour les variantes de la configuration plutôt que des branches. Avec les dossiers, vous pouvez utiliser la commande tree pour afficher les variantes. Par exemple, avec les branches, vous ne pouvez pas savoir si le delta entre une branche de production et une branche de préproduction est une modification à venir de la configuration ou une différence permanente entre la phase et la production.

Le tableau suivant répertorie les avantages et les inconvénients de l'utilisation de dossiers plutôt que de branches :

Avantages

Inconvénients

Il est plus facile de détecter les dossiers que les branches. Il est possible d'effectuer une comparaison de dossiers avec de nombreux outils de ligne de commande et d'interface graphique, tandis que la comparaison de branches est moins courante en dehors des fournisseurs Git. Il est plus facile d'effectuer une comparaison des différences permanentes et des différences non promues avec les dossiers. Vous pouvez déployer les modifications sur plusieurs clusters et espaces de noms en une seule requête de modification, tandis que les branches nécessitent plusieurs demandes de modification dans différentes branches.

Il n'est pas possible de promouvoir des modifications de configuration à l'aide d'une demande de modification sur les mêmes fichiers.

Réduisez l'utilisation de ClusterSelectors.

ClusterSelectors vous permet d'appliquer certaines parties d'une configuration à un sous-ensemble de clusters. Au lieu de configurer RootSync ou RepoSync, vous pouvez modifier la ressource en cours d'application ou ajouter des libellés aux clusters. Toutefois, au fil du temps, à mesure que le nombre de ClusterSelectors augmente, il peut devenir difficile de comprendre l'état final du cluster.

Config Sync vous permet de synchroniser plusieurs RootSyncs et RepoSyncs à la fois. Vous pouvez ainsi ajouter la configuration appropriée à un dépôt distinct, puis la synchroniser avec les clusters de votre choix.

Le tableau suivant répertorie les avantages et les inconvénients de la non-utilisation de ClusterSelectors :

Avantages	Inconvénients
Il est plus facile d'assembler dans un dossier la configuration qui se trouvera sur le cluster, plutôt que de prendre cette décision au niveau du cluster. Réduit la charge mentale liée à la compréhension de ce qui sera réellement appliqué au cluster.	Les libellés sont un moyen simple d'ajouter une caractéristique à un cluster. Il est plus complexe de créer un objet "RepoSync".

Éviter de gérer des tâches avec Config Sync

Bien que Config Sync puisse appliquer des tâches à votre place, celles-ci ne sont pas adaptées au déploiement GitOps pour les raisons suivantes :

• Champs immuables : de nombreux champs de type "Job" sont immuables. Pour modifier un champ immuable, l'objet doit être supprimé et recréé. Toutefois, Config Sync ne supprime pas votre objet, sauf si vous le supprimez de la source.

• Exécution involontaire de tâches : si vous synchronisez une tâche à l'aide de Config Sync et que cette tâche est ensuite supprimée du cluster, Config Sync prend en compte cette dérive par rapport à l'état choisi et recrée le Job. Si vous spécifiez une valeur TTL (Time To Live), la tâche est automatiquement supprimée et Config Sync la recrée automatiquement, en redémarrant la tâche, jusqu'à ce que vous supprimiez son Job provenant de la source fiable. Ce n'est souvent pas ce qui était prévu, car Config Sync exécute à nouveau la tâche.

• Problèmes de rapprochement : Config Sync attend normalement que les objets soient rapprochés après avoir été appliqués. Toutefois, les tâches sont considérées comme rapprochées lorsqu'elles ont commencé à s'exécuter. Cela signifie que Config Sync n'attend pas que la tâche soit terminée avant de continuer à appliquer d'autres objets. Toutefois, si la tâche échoue ultérieurement, cela est considéré comme un échec du rapprochement. Dans certains cas, cela peut empêcher la synchronisation d'autres ressources et provoquer des erreurs jusqu'à ce que vous les corrigiez. Dans d'autres cas, la synchronisation peut réussir et seul le rapprochement échoue.

Pour ces raisons, nous vous déconseillons de synchroniser les tâches avec Config Sync.

Dans la plupart des cas, les jobs et autres tâches liées à la situation doivent être gérés par un service qui gère leur cycle de vie. Vous pouvez ensuite gérer ce service avec Config Sync au lieu des tâches elles-mêmes.

Le tableau suivant présente les avantages et les inconvénients de l'utilisation de Config Sync pour gérer les tâches :

Avantages

Inconvénients

Accroît la compatibilité avec GitOps. Les tâches ne fonctionnent pas bien avec l'approche déclarative de GitOps avec contrôle des versions en raison de leurs champs immuables. Réduit les conséquences inattendues. Élimine le risque que Config Sync recrée automatiquement des tâches supprimées, ce qui peut entraîner leur exécution inattendue. Moins d'erreurs de synchronisation Les éventuels conflits de synchronisation et les erreurs déclenchées par des tâches ayant échoué sont évités.

Gestion manuelle des tâches. Vous devez rechercher un autre service pour gérer les tâches.

Utiliser des dépôts non structurés

Config Sync accepte deux structures pour l'organisation d'un dépôt : non structuré et hiérarchique. L'approche non structurée est recommandée, car elle vous permet d'organiser un dépôt de la manière la plus adaptée à vos besoins. En comparaison, les dépôts hiérarchiques appliquent une structure spécifique. Par exemple, les objets CRD doivent se trouver dans un répertoire spécifique. Cela peut poser des problèmes lorsque vous devez partager des configurations. Par exemple, si une équipe publie un package contenant un objet CRD, une autre équipe devant utiliser ce package devra déplacer l'objet CRD dans un répertoire cluster, ce qui ajoutera davantage de surcharge au processus.

Le tableau suivant répertorie les avantages et les inconvénients liés à l'utilisation de dépôts non structurés :

Avantages	Inconvénients
Vous pouvez réutiliser des packages de configuration partagés même s'ils contiennent des objets CRD ou d'autres définitions à l'échelle du cluster.	Sans processus ni consignes, la structure du dépôt peut varier selon les équipes, ce qui peut compliquer la mise en œuvre d'outils à l'échelle du parc.

Pour savoir comment convertir un dépôt hiérarchique, consultez la section Convertir un dépôt hiérarchique en dépôt non structuré.

Séparer les dépôts de code et de configuration

Lors du scaling à la hausse d'un dépôt "mono", il nécessite une compilation spécifique à chaque dossier. Les autorisations et les préoccupations des personnes qui travaillent sur le code et sur la configuration du cluster sont généralement différentes. En séparant le code et les dépôts de configuration, chaque dépôt peut disposer de ses propres autorisations et de sa propre structure.

Le tableau suivant répertorie les avantages et les inconvénients de la séparation des dépôts de code et de configuration :

Avantages	Inconvénients
Évite les commits "en boucle". Par exemple, un commit dans un dépôt de code peut déclencher une requête CI, qui peut produire une image, qui nécessite ensuite un commit de code, etc. Vous pouvez utiliser différentes autorisations pour les personnes travaillant sur le code de l'application et la configuration du cluster.	Réduit la découverte de la configuration de l'application, car elle ne se trouve pas dans le même dépôt que le code de l'application. La gestion de nombreux dépôts peut prendre beaucoup de temps.

Utiliser des dépôts distincts pour isoler les modifications

Lors du scaling à la hausse d'un dépôt "mono", différentes autorisations sont requises sur différents dossiers. Par conséquent, la séparation des dépôts permet de définir des limites de sécurité entre la sécurité, la plate-forme et la configuration des applications. Il est également recommandé de séparer les dépôts de production et hors production.

Le tableau suivant répertorie les avantages et les inconvénients de l'isolation des modifications dans des dépôts distincts :

Avantages

Inconvénients

Dans une organisation avec des équipes chargées de la plate-forme, de la sécurité et des applications, la fréquence des modifications et des autorisations est différente. Les autorisations restent au niveau du dépôt. Les fichiers CODEOWNERS permettent aux organisations de limiter l'autorisation en écriture tout en autorisant la lecture. Config Sync accepte plusieurs synchronisations par espace de noms, ce qui permet d'obtenir une "combinaison" à partir de plusieurs dépôts.

Gérer de nombreux dépôts est une tâche en soi. Ainsi, dans le cas où vous créez un dépôt par cluster, le problème de configuration/suppression du cluster doit désormais inclure la gestion des dépôts.

Épingler des versions de package

Que vous utilisiez Helm ou Git, vous devez épingler la version du package de configuration sur une version qui n'a pas été accidentellement déplacée sans déploiement explicite.

Le tableau suivant répertorie les avantages et les inconvénients de l'épinglage des versions de package :

Avantages	Inconvénients
La mise à jour de la configuration partagée peut avoir un impact plus important que prévu si la version du package n'est pas épinglée.	Les déploiements nécessitent des vérifications lorsque les packages partagés sont mis à jour.

Utiliser Workload Identity

Vous pouvez activer Workload Identity sur les clusters GKE, ce qui permet aux charges de travail Kubernetes d'accéder aux services Google de manière sécurisée et gérable.

Le tableau suivant répertorie les avantages et les inconvénients de l'utilisation de Workload Identity :

Avantages	Inconvénients
Réduction de la complexité et des problèmes potentiels liés aux secrets et aux mots de passe.	Les services en dehors de Google Cloud (tels que GitHub et GitLab) ne sont pas compatibles avec Workload Identity.

Architecture de haut niveau

De manière générale, vous aurez probablement besoin d'au moins quatre types de dépôts :

1. Un dépôt de packages où la configuration partagée est stockée. Il peut également s'agir d'un chart Helm stocké dans Artifact Registry.
2. Un dépôt de plate-forme dans lequel l'équipe de gestion de la plate-forme stocke la configuration à l'échelle du parc pour les clusters et les espaces de noms.
3. Un dépôt de configuration d'application.
4. Un dépôt de code de l'application.

Le schéma suivant illustre la disposition de ces dépôts :

Le schéma suivant illustre le flux de configuration entre le code de l'application et le dépôt de configuration de l'application. Les équipes de développement transfèrent le code destiné aux applications et à leurs configurations dans un dépôt. Le code des applications et des configurations est stocké au même endroit, et les équipes dédiées aux applications ont le contrôle sur ces dépôts. Les équipes chargées des applications peuvent ensuite transférer du code dans une compilation.

Étapes suivantes

• Premiers pas avec Config Sync