À propos des sources de référence

Config Sync vous permet d'automatiser les déploiements de ressources Kubernetes sur vos clusters à partir d'une source de vérité centrale, en remplaçant les commandes kubectl manuelles. Dans les workflows GitOps, une source de vérité est le dépôt central dans lequel vous stockez les fichiers de configuration YAML ou JSON qui définissent les ressources de votre cluster. Config Sync surveille en permanence ce dépôt et applique automatiquement les modifications à vos clusters.

Vous pouvez synchroniser des fichiers de configuration à partir de trois types de sources : des dépôts Git, des images OCI (Open Container Initiative) et des charts Helm. Comprendre comment Config Sync interagit avec chaque type de source vous aide à choisir la meilleure option 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 des avantages du contrôle des versions et de la création de branches, si nécessaire. Comme Git est un outil mature et largement pris en charge, vous disposez d'un large choix de fournisseurs et d'outils.

Lorsque vous configurez Config Sync avec un dépôt Git comme source de vérité, Config Sync utilise un conteneur git-sync dans le pod de rapprochement 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 d'extraction des 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 configure Config Sync pour 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, en vérifiant les mises à jour toutes les 60 secondes sans authentification.

Exemple de cas d'utilisation : gestion centralisée

Imaginons que vous êtes un administrateur de plate-forme et que vous souhaitez utiliser un dépôt Git pour appliquer des règles de référence à tous les clusters d'un parc. Dans ce scénario, vous pouvez stocker les éléments NetworkPolicies, RoleBindings et ResourceQuotas standards dans un dépôt Git central nommé standard-configs. Lorsqu'un 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 empaqueter des applications et leurs dépendances. Cette approche traite vos configurations comme des artefacts, de la même manière que vous traiteriez des images de conteneurs. 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'image de conteneur comme Artifact Registry pour gérer vos images, et Workload Identity Federation for 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 la transférer vers une plate-forme de registre telle qu'Artifact Registry. Cette approche peut être moins lisible par l'humain 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 configure Config Sync pour la synchronisation à 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 au pipeline CI/CD de votre organisation. Lorsque les 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 dans une image OCI et transfère l'image vers Artifact Registry. Config Sync détecte et applique 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 paquets populaire pour Kubernetes, qui utilise un format d'empaquetage appelé "charts". Config Sync peut récupérer, afficher et synchroniser les ressources définies dans les charts Helm.

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

Si vous ne connaissez pas encore Helm, le processus de création de modèles et de publication peut ajouter une complexité supplémentaire à votre pipeline de gestion de 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 rapprochement 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 chart 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 configure Config Sync pour synchroniser un chart Helm à partir d'un dépôt OCI. Config Sync récupère la version 1.2.0 du chart 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 chart 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 faites partie d'une équipe d'application qui souhaite déployer Prometheus sur un cluster. Vous pouvez configurer Config Sync pour extraire des 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, la version et les values personnalisées du chart dans l'objet RootSync ou RepoSync de Config Sync. Config Sync maintient ensuite le déploiement synchronisé avec la version et les configurations de chart spécifiées.

Choisir un type de source

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

Fonctionnalité Dépôt Git Image OCI Chart Helm
Application idéale Gestion de configuration à usage général, flexibilité, lisibilité par l'humain Configurations immuables et avec gestion des versions ; exploitation de l'infrastructure de conteneurs Empaqueter et distribuer des applications complexes
Mutabilité Non immuable Immuable Modifiable (les versions de graphique sont immuables, mais les valeurs peuvent changer)
Rollbacks Annuler des commits ou changer de branche Déployer le tag d'image précédent Effectuer un rollback vers une version de chart précédente
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, en particulier à grande échelle Rapide lors de la récupération à partir d'un dépôt de chart
Authentification Flexible (SSH, jeton), peut être plus complexe à configurer Simplifiée avec Workload Identity Federation for GKE (par exemple, avec Artifact Registry) Simplifiée avec Workload Identity Federation for 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 avoir les éléments suivants :

  • Un RootSync qui se synchronise à 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 la plate-forme.
  • Un RepoSync dans un espace de noms spécifique se synchronisant à 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, qui 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