À propos des sources de référence

Ce document explique les différents types de sources de vérité à partir desquelles Config Sync peut se synchroniser.

Un concept clé des workflows GitOps est la source de vérité, un dépôt central où sont stockés vos fichiers de configuration. Un fichier de configuration est généralement un fichier YAML ou JSON qui définit les ressources Kubernetes. Normalement, vous pouvez appliquer manuellement des objets Kubernetes avec l'outil de ligne de commande kubectl, mais Config Sync peut appliquer automatiquement ces ressources à partir d'une source unique de vérité, comme un dépôt Git. Config Sync surveille ensuite la source de vérité que vous avez spécifiée et applique automatiquement les modifications à vos clusters.

Config Sync peut synchroniser des fichiers de configuration à partir de trois types de sources : les dépôts Git, les images Open Container Initiative (OCI) et les charts Helm. Ce document explique chacun de ces types de sources et comment Config Sync interagit avec eux. La lecture de ce document peut vous aider à choisir la meilleure option de source pour votre workflow et votre environnement.

Dépôts Git

Git est une technologie largement adoptée pour le contrôle des versions et la collaboration. Avec Git, vous pouvez organiser votre dépôt de la manière qui vous convient et bénéficier du contrôle des versions et de la création de branches, si nécessaire. Git est une technologie mature et largement adoptée. Vous disposez donc d'un large éventail d'options pour les fournisseurs et les outils.

Lorsque vous configurez Config Sync avec un dépôt Git comme source de référence, Config Sync utilise un conteneur git-sync dans le pod du réconciliateur pour extraire les configurations du dépôt Git. Vous pouvez configurer l'URL, la branche et la révision (commit ou tag) du dépôt pour mieux contrôler l'emplacement à partir duquel extraire les configurations dans votre dépôt Git.

Exemple de configuration RootSync

L'exemple suivant montre un fichier manifeste RootSync qui se synchronise à partir d'un dépôt Git :

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/example/my-configs.git
    revision: main
    dir: cluster-configs
    auth: none # replace with your authentication method such as ssh or token
    period: 60s

Cette configuration permet à Config Sync de synchroniser les fichiers manifestes à partir d'un dépôt Git. Config Sync surveille le répertoire cluster-configs dans la branche main du dépôt https://github.com/example/my-configs.git et recherche les mises à jour toutes les 60 secondes sans authentification.

Exemple de cas d'utilisation : gestion centralisée

Imaginez que vous êtes un administrateur de plate-forme et que vous souhaitez utiliser un dépôt Git pour appliquer des règles de base à tous les clusters d'un parc. Dans ce scénario, vous pouvez stocker les NetworkPolicies, RoleBindings et ResourceQuotas standards dans un dépôt Git central nommé standard-configs. Lorsqu'un nouveau cluster est provisionné, Config Sync est configuré pour se synchroniser à partir du dépôt standard-configs, ce qui permet de s'assurer que tous les clusters respectent les normes de l'organisation dès le départ.

Images OCI

Les images OCI sont un format standard pour l'empaquetage des applications et de leurs dépendances. Cette approche traite vos configurations comme des artefacts, de la même manière que vous traiteriez des images de conteneur. Cette approche offre des avantages tels que l'immuabilité et des performances plus rapides à grande échelle. Avec OCI, vous pouvez utiliser l'infrastructure et les outils d'images de conteneurs, comme Artifact Registry, pour gérer vos images, et la fédération d'identité de charge de travail pour GKE pour simplifier l'authentification.

L'utilisation d'OCI comme source de configuration nécessite généralement un processus distinct pour compiler vos fichiers de configuration dans une image OCI, puis l'importer dans une plate-forme de registre telle qu'Artifact Registry. Cette approche peut être moins directement lisible par l'homme que les configurations stockées sous forme de fichiers dans un dépôt Git.

Lorsque vous configurez Config Sync avec une image OCI comme source de vérité, Config Sync utilise un conteneur oci-sync dans le pod de rapprochement pour extraire l'image OCI contenant les configurations du registre.

Exemple de configuration RootSync

L'exemple suivant montre un fichier manifeste RootSync qui se synchronise à partir d'une image OCI stockée dans Artifact Registry :

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0
    dir: .
    auth: k8sserviceaccount

Cette configuration permet à Config Sync de se synchroniser à partir d'une image OCI. Config Sync extrait l'image us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0 d'Artifact Registry à l'aide d'un compte de service Kubernetes pour l'authentification.

Exemple de cas d'utilisation : intégration de pipeline CI/CD

Imaginons que vous souhaitiez intégrer la création d'images OCI dans le pipeline CI/CD de votre organisation. Lorsque des modifications apportées aux fichiers de configuration sont fusionnées, vous pouvez configurer votre pipeline pour qu'il exécute des tests de validation (comme la commande nomos vet), compile les fichiers YAML en image OCI et envoie l'image à Artifact Registry. Config Sync détecte et applique ensuite automatiquement la nouvelle version de l'image sur vos clusters, ce qui garantit un déploiement validé et versionné de toutes les modifications de configuration.

Charts Helm

Helm est un gestionnaire de packages populaire pour Kubernetes, qui utilise un format de package appelé "charts". Config Sync peut extraire, afficher et synchroniser les ressources définies dans les charts Helm.

Helm offre un moyen cohérent d'empaqueter et de réutiliser les applications Kubernetes. Vous pouvez utiliser des modèles ou des charts Helm prédéfinis pour obtenir des configurations cohérentes et réutilisables.

Si vous n'êtes pas encore familiarisé avec Helm, le processus de création de modèles et de déploiement peut ajouter de la complexité à votre pipeline de gestion de la configuration.

Lorsque vous configurez Config Sync avec un chart Helm comme source de vérité, Config Sync utilise un conteneur helm-sync dans le pod de réconciliateur pour extraire les charts d'un dépôt Helm (comme Artifact Registry) ou d'un dépôt Git, puis affiche le chart pour produire des fichiers manifestes Kubernetes. Vous pouvez également utiliser Config Sync avec Kustomize pour afficher les charts Helm. Pour en savoir plus sur cette approche, consultez Utiliser Config Sync avec Kustomize et Helm.

Exemple de configuration RootSync

L'exemple suivant montre un fichier manifeste RootSync qui se synchronise à partir d'un graphique Helm stocké dans Artifact Registry :

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: helm
  helm:
    repo: oci://us-central1-docker.pkg.dev/my-project/my-helm-repo
    chart: my-chart
    version: 1.2.0
    auth: gcpserviceaccount
    gcpServiceAccountEmail: my-service-account@my-project.iam.gserviceaccount.com
    releaseName: my-chart-release
    namespace: my-app-namespace # Namespace where the chart resources will be deployed

Cette configuration permet à Config Sync de synchroniser un chart Helm à partir d'un dépôt OCI. Config Sync récupère la version 1.2.0 du graphique my-chart à partir du dépôt oci://us-central1-docker.pkg.dev/my-project/my-helm-repo et s'authentifie avec le compte de service my-service-account@my-project.iam.gserviceaccount.com. Il déploie les ressources du graphique dans l'espace de noms my-app-namespace sous le nom de version my-chart-release.

Exemple de cas d'utilisation : Déployer une application tierce

Imaginez que vous fassiez partie d'une équipe d'application qui souhaite déployer Prometheus dans un cluster. Vous pouvez configurer Config Sync pour qu'il extrait les données d'un chart Helm prédéfini qui déploie Prometheus. Au lieu d'exécuter manuellement des commandes Helm, vous définissez la source du chart, la version et tout values personnalisé dans l'objet RootSync ou RepoSync de Config Sync. Config Sync maintient ensuite le déploiement synchronisé avec la version et les configurations du graphique spécifiées.

Choisir un type de source

Le type de source le plus adapté dépend des outils, des workflows et des préférences existants de votre équipe. Vous pouvez utiliser ce tableau pour comprendre les principales caractéristiques de chaque type de source et prendre une décision éclairée :

Fonctionnalité Dépôt Git Image OCI Chart Helm
Application idéale Gestion de la configuration à usage général ; flexibilité ; lisibilité par les humains Configurations immuables et versionnées, utilisant l'infrastructure de conteneurs Mettre en package et distribuer des applications complexes
Mutabilité Non immuable Immuable Modifiable (les versions des graphiques sont immuables, mais les valeurs peuvent changer)
Rollbacks Annuler des commits ou changer de branche Déployer le tag d'image précédent Revenir à une version précédente du graphique
Outils Clients Git standards, pipelines CI/CD Docker ou Podman, registres de conteneurs CLI Helm, dépôts Helm
Performances Peut être plus lent pour les grands dépôts Plus rapide, surtout à grande échelle Rapide lors de la récupération à partir d'un dépôt de graphiques
Authentification Flexible (SSH, jeton), mais peut être plus complexe à configurer Simplifié avec la fédération d'identité de charge de travail pour GKE (par exemple, avec Artifact Registry) Simplifié avec la fédération d'identité de charge de travail pour GKE (par exemple, avec Artifact Registry)

Il est également possible d'utiliser différents types de sources à des fins différentes sur le même cluster. Par exemple, un cluster peut comporter les éléments suivants :

  • Un RootSync synchronisé à partir d'un dépôt Git contenant des ressources et des règles de base à l'échelle du cluster gérées par l'équipe de plate-forme.
  • Un RepoSync dans un espace de noms spécifique se synchronise à partir d'un chart Helm pour déployer une instance Redis gérée par une équipe d'application.
  • Un autre RepoSync dans un espace de noms différent se synchronise à partir d'une image OCI contenant un ensemble de configurations spécifiques à l'application, créées par un processus CI/CD distinct.

Étapes suivantes