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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
É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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
É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 |
|
|
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 |
|
|
Architecture de haut niveau
De manière générale, vous avez probablement besoin d'au moins quatre types de dépôts:
- 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.
- 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.
- Dépôt de configuration d'application.
- 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.