Bonnes pratiques GitOps pour Kubernetes avec Config Sync

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

GitOps en soi est une bonne pratique universelle pour les organisations qui gèrent la configuration Kubernetes à grande échelle. Mais lorsqu'il s'agit de concevoir l'architecture de cette solution, de nombreuses options s'offrent à vous. Comprendre vos options ainsi que les avantages et les inconvénients liés à ces décisions peut vous aider à éviter de réécrire votre architecture à l'avenir.

Vous n'avez pas besoin de suivre toutes les bonnes pratiques listées sur cette page. Les bonnes pratiques que vous choisissez d'adopter dépendent de votre situation unique. 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 à les trouver plus facilement. Vous pouvez utiliser des services tels qu'Artifact Registry ou des dépôts Git.

L'équipe chargée de la plate-forme peut mettre en œuvre des stratégies permettant aux équipes d'applications d'utiliser des packages uniquement à partir du dépôt central. Ils peuvent également utiliser le dépôt central comme 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 répertorie les avantages et les inconvénients liés à l'utilisation d'un dépôt de packages privé et centralisé:

Avantages

Inconvénients

Ingérez les packages publics à un rythme défini, pour éviter d'être interrompu par la connectivité ou la perte d'utilisateurs en amont. Examinez et analysez les packages partagés. Fournit un moyen facile de découvrir ce qui est utilisé et pris en charge. Par exemple, les équipes peuvent trouver plus facilement le déploiement Redis standard stocké dans le dépôt central. Modifiez les packages en amont pour vous assurer qu'ils respectent les normes internes, telles que les valeurs par défaut, l'ajout d'étiquettes et les dépôts d'images de conteneurs.

Quelqu’un doit gérer le référentiel central. Ajout de processus pour les équipes de candidature.

Créer des dépôts humides

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

Le tableau suivant présente les avantages et les inconvénients de la création de dépôts humides:

Avantages	Inconvénients
Les différences sont plus faciles à examiner. Aucun traitement n'est nécessaire pour connaître l'état souhaité de la configuration.	Une configuration entièrement hydratante peut entraîner la répétition du code YAML.

Décaler vers la gauche pour valider les configurations

Attendre le début de la synchronisation de Config Sync pour détecter d'éventuels 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 en utilisant les fonctions de validation kpt telles que kubeval.

Le tableau suivant présente les avantages et les inconvénients liés à la vérification des problèmes avant d'appliquer une configuration:

Avantages	Inconvénients
L'affichage des modifications de configuration dans une demande de modification permet d'éviter que les erreurs ne soient intégrées dans un dépôt. Réduit l'impact des problèmes liés aux 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 plutôt que des 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 un changement à 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 liés à l'utilisation de dossiers plutôt que de branches:

Avantages

Inconvénients

La découverte de dossiers est plus facile que les branches. Faire une différence au niveau des dossiers est possible avec de nombreux outils CLI et IUG, tandis que la différence de branche est moins courante en dehors des fournisseurs Git. Avec les dossiers, il est plus facile de différencier les différences permanentes des différences non promues. Vous pouvez déployer des 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 adressées à différentes branches.

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

Minimiser 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 à appliquer ou ajouter des libellés aux clusters. Toutefois, à mesure que le nombre de ClusterSelectors augmente, il peut devenir compliqué de comprendre l'état final du cluster.

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

Le tableau suivant présente les avantages et les inconvénients de ne pas utiliser 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 étiquettes sont un moyen léger d'ajouter une caractéristique à un cluster. Il est plus complexe de créer un "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 d'une offre d'emploi sont immuables. Pour modifier un champ immuable, vous devez supprimer l'objet, puis le recréer. 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 avec Config Sync et que cette tâche est ensuite supprimée du cluster, Config Sync considère que la tâche dérive de l'état choisi et recrée la tâche. Si vous spécifiez une valeur valeur TTL (Time To Live), la tâche est automatiquement supprimée et Config Sync la recrée automatiquement, en la redémarrant, jusqu'à ce que vous la supprimiez de la source fiable. Souvent, ce n'est pas ce qui était prévu, car Config Sync réexécute la tâche.

• Problèmes de rapprochement: Config Sync attend normalement que les objets soient rapprochés après leur application. Toutefois, les tâches sont considérées comme rapprochées lorsqu'elles commencent à s'exécuter. Cela signifie que Config Sync n'attend pas la fin de la tâche pour continuer à appliquer d'autres objets. Toutefois, si la tâche échoue ultérieurement, le rapprochement est considéré comme un échec. 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.

C'est pourquoi nous vous déconseillons de synchroniser les tâches avec Config Sync.

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

Le tableau suivant répertorie les avantages et les inconvénients de ne pas utiliser Config Sync pour gérer les tâches:

Avantages

Inconvénients

Augmente la compatibilité avec GitOps. Les jobs ne fonctionnent pas bien avec l'approche déclarative et avec contrôle des versions de GitOps en raison de leurs champs immuables. Réduit les conséquences imprévues. É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 les jobs ayant échoué sont évités.

Gestion manuelle des jobs Vous devez trouver un autre service pour gérer les jobs.

Utiliser des dépôts non structurés

Config Sync accepte deux structures pour l'organisation d'un dépôt : non structurée 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 qui vous convient le mieux. 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 entraîner des problèmes lorsque vous devez partager des configurations. Par exemple, si une équipe publie un package contenant un objet CRD, une autre équipe qui doit l'utiliser doit le déplacer dans un répertoire cluster, ce qui entraîne une surcharge du processus.

Le tableau suivant présente 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 CRD ou d'autres définitions à l'échelle du cluster.	Sans processus ni consignes, les structures de dépôt peuvent 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 page 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 est nécessaire de créer une compilation spécifique à chaque dossier. Les autorisations et les préoccupations pour les personnes travaillant sur le code et sur la configuration du cluster sont généralement différentes. En séparant les dépôts de code et de configuration, chaque dépôt peut disposer de ses propres autorisations et structure.

Le tableau suivant présente 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 "boucles". Par exemple, la validation dans un dépôt de code peut déclencher une requête CI, qui peut générer une image, qui nécessite ensuite un commit du code, et ainsi de suite. Vous pouvez utiliser des autorisations différentes pour les personnes qui travaillent sur le code d'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 d'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 pour différents dossiers. C'est pourquoi la séparation des dépôts permet de définir des limites de sécurité entre la configuration de la sécurité, de la plate-forme et des applications. Il est également judicieux de séparer les dépôts de production et hors production.

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

Avantages

Inconvénients

Dans une organisation avec des équipes dédiées à la plate-forme, à la sécurité et aux 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 d'écriture tout en autorisant l'autorisation de lecture. Config Sync accepte plusieurs synchronisations par espace de noms, ce qui permet d'obtenir un "effet mixte" à partir de plusieurs dépôts.

La gestion de nombreux dépôts est une tâche en soi. Ainsi, si 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 les versions du package

Que vous utilisiez Helm ou Git, vous devez épingler la version du package de configuration à un élément qui n'est pas accidentellement déployé sans déploiement explicite.

Le tableau suivant présente les avantages et les inconvénients liés au blocage des versions de package:

Avantages	Inconvénients
Une 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 lors de la mise à jour des packages partagés.

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 présente les avantages et les inconvénients d'utiliser 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 extérieurs à 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 avez probablement besoin d'au moins quatre types de dépôts:

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

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

Le schéma suivant illustre le flux de configuration depuis le code de l'application vers un dépôt de configuration d'application. Les équipes de développement transfèrent le code des applications et des configurations d'application dans un dépôt. Le code des applications et des configurations est stocké au même endroit, et les équipes en charge des applications contrôlent ces dépôts. Les équipes chargées des applications peuvent ensuite transférer du code dans un build.

Étapes suivantes

• Premiers pas avec Config Sync