Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Présentation de Config Sync

Config Sync est un outil Open Source qui permet aux opérateurs de cluster et aux administrateurs de plate-forme de déployer des configurations et des règles cohérentes. Vous pouvez déployer ces configurations et ces règles dans des clusters Kubernetes individuels, dans plusieurs clusters pouvant s'étendre sur des environnements hybrides et multicloud, ainsi que dans plusieurs espaces de noms au sein des clusters. Ce processus simplifie et automatise la gestion des configurations et des règles à grande échelle. Config Sync permet également aux équipes de développement de gérer indépendamment leurs espaces de noms dans des clusters, tout en respectant les garde-fous des règles définis par les administrateurs.

S'appuyant sur les mêmes principes que Kubernetes, Config Sync consolide continuellement l'état des clusters enregistrés avec un ensemble central de déclarations de configurations, appelées configurations. Vous pouvez stocker des configurations dans un ou plusieurs dépôts Git, des dépôts Helm (version bêta) ou des images OCI. Cette approche GitOps (parfois appelée configuration en tant que code) vous permet de gérer et de déployer des configurations courantes à l'aide d'un processus vérifiable, transactionnel, révisable et contrôlé par version.

Dans le schéma suivant, un administrateur de plate-forme crée des configurations cohérentes pour trois clusters différents en appliquant des configurations aux clusters et aux espaces de noms du cluster :

Administrateur de plate-forme déployant plusieurs configurations dans ses clusters

Avantages de Config Sync

Les exemples suivants présentent certains des avantages offerts par Config Sync :

  • Limiter le risque "d'opérations cachées" : si des modifications non validées sont envoyées aux clusters opérationnels, il peut être difficile d'identifier les différences entre la configuration documentée et votre environnement réel. Vous pouvez exiger que toutes les modifications de configuration des clusters soient appliquées à l'aide de Config Sync, de verrouiller l'accès direct à l'API Kubernetes et de suivre les modifications apportées aux sources de vérité dans Git.
  • Utilisez les bonnes pratiques GitOps : avant que les modifications ne soient appliquées à l'environnement réel, vous pouvez exiger des revues de code à l'aide des outils de gestion de dépôt de votre choix. Utilisez Config Sync pour vérifier exactement quel commit a provoqué une modification de configuration.
  • Réduire les temps d'arrêt engendrés par les défaillances liées aux configurations : Config Sync vous permet d'appliquer une stratégie d'investigation par retour arrière pour effectuer un rollback des modifications destructives et rétablir le bon fonctionnement des clusters opérationnels avant de corriger la modification problématique et de l'appliquer lors d'un nouveau commit.
  • Utiliser les pipelines d'intégration continue ou de déploiement continu (CI/CD) : vous pouvez utiliser un workflow CI/CD pour afficher la configuration à l'aide des outils et formats de votre choix, tester les modifications et les valider automatiquement lorsque les tests réussissent. Config Sync applique ensuite les modifications, puis surveille et corrige les dérives de configuration.

Comprendre Config Sync

Prerequisites

Config Sync utilise des espaces de noms, des libellés et des annotations qui constituent des éléments essentiels de son implémentation. Il est utile de bien comprendre ces concepts avant de commencer à utiliser le produit.

Configurer des clusters

Config Sync vous permet de créer un ensemble commun de configurations et de règles au niveau du cluster, telles que les contraintes de Policy Controller, et de les appliquer de manière cohérente sur les clusters enregistrés et connectés à partir d'une seule source de vérité dans Git. Pour pouvoir configurer un cluster, vous devez créer une configuration et un dépôt.

Configurations

Une configuration est une déclaration de configuration Kubernetes, écrite au format YAML ou JSON. Config Sync lit et applique la configuration à un ou plusieurs clusters pour créer ou configurer un objet ou une ressource Kubernetes dans ces clusters, ou pour fournir les informations dont Config Sync a besoin. Elles peuvent contenir toutes les informations de configuration que vous êtes susceptible d'appliquer à un cluster Kubernetes à l'aide de kubectl edit ou de kubectl apply. Vous pouvez également déclarer plusieurs configurations dans un seul fichier. Config Sync lit trois types de fichiers : .yaml, .yml et .json. Les fichiers ayant d'autres suffixes sont ignorés.

Avant d'écrire une configuration, vous devez comprendre l'objet Kubernetes pour lequel vous écrivez la configuration.

Pour en savoir plus, consultez les sections Ajouter des configurations à un dépôt Git et Créer des configurations.

Dépôts

Le dépôt correspond au dépôt Git où sont stockées les configurations, y compris la configuration de Config Sync. Lorsque vous configurez Config Sync, vous configurez le dépôt, la branche et le sous-répertoire que Config Sync surveille pour identifier les modifications apportées.

Config Sync vous permet de synchroniser les configurations de plusieurs dépôts avec le même ensemble de clusters. Dans Config Sync, vous pouvez référencer chaque dépôt à l'aide de sa référence Git (une URL Git, une branche de dépôt, un commit ou un tag et un répertoire). Cette configuration dissocie le cycle de vie du déploiement de configuration pour différentes équipes. Il vous permet également de choisir où vous souhaitez placer le dépôt et comment le structurer pour plus d'autonomie.

Vous pouvez créer deux types de dépôts - dépôts racine et dépôts d'espaces de noms :

  • Dépôts racine : les dépôts racines vous permettent de synchroniser les configurations à l'échelle d'un cluster et à l'échelle d'un espace de noms. Les dépôts racines utilisent des identifiants de niveau administrateur pour appliquer des règles sur les espaces de noms de l'application et remplacer les modifications locales qui dépassent l'état que vous avez déclaré dans vos configurations. Les dépôts racines sont généralement régis par un administrateur central.

    Vous pouvez structurer votre dépôt racine de deux manières différentes :

    • Format non structuré : le format source non structuré vous permet d'organiser les configurations de votre dépôt de la manière la plus pratique. Ce format peut être particulièrement utile si vous organisez et/ou générez des configurations à l'aide d'un outil tel que kustomize, kpt ou helm. Le format non structuré est recommandé pour la plupart des utilisateurs. Il est utilisé par défaut lors de la configuration de Config Sync via Google Cloud Console. Pour en savoir plus, consultez la page Utiliser un dépôt non structuré.
    • Format hiérarchique : le format source hiérarchique (ou structuré) répartit les configurations en différentes catégories pour la configuration système, les métadonnées du cluster, la configuration au niveau du cluster et la configuration d'un espace de noms pour vous aider à organiser les configurations. Il permet également l'héritage hiérarchique des configurations sur plusieurs espaces de noms en fonction de la structure de répertoire, qui est abordée plus en détail dans la section Configurer des espaces de noms. La hiérarchie est le format de dépôt par défaut pour Config Sync si vous ne spécifiez pas de sourceFormat dans votre fichier manifeste. Pour en savoir plus, consultez la page Présentation du dépôt hiérarchique.

    Pour savoir comment configurer votre dépôt racine, consultez la section Installer Config Sync.

  • Dépôts d'espaces de noms : les dépôts d'espaces de noms sont facultatifs et peuvent contenir des configurations à l'échelle d'un espace de noms synchronisées avec un espace de noms particulier sur les clusters. Vous pouvez déléguer la configuration et le contrôle d'un dépôt d'espaces de noms à des utilisateurs non administrateurs. Les dépôts d'espaces de noms doivent utiliser le format non structuré.

Le schéma suivant montre comment les équipes peuvent synchroniser leurs clusters avec un seul dépôt racine (géré par un administrateur) et plusieurs dépôts d'espaces de noms (gérés par les opérateurs d'application) :

Un administrateur central contrôlant plusieurs configurations et opérateurs d'application contrôlant leurs propres configurations d'espace de noms

Dans le schéma précédent, un administrateur central gère l'infrastructure centralisée de l'organisation et applique des règles sur le cluster et sur tous les espaces de noms de l'organisation. Les opérateurs d'application, qui sont responsables de la gestion des déploiements à chaud, appliquent des configurations aux applications dans les espaces de noms sur lesquels ils travaillent.

Images

À partir d'Anthos Config Management version 1.12.0, vous pouvez configurer Config Sync pour la synchronisation à partir d'images OCI. Vous pouvez stocker des images dans Artifact Registry ou Container Registry. Pour utiliser cette fonctionnalité, vous devez activer les API RootSync et RepoSync.

Charts Helm

À partir d'Anthos Config Management version 1.13.0, vous pouvez stocker vos configurations dans un dépôt Helm (version bêta). Pour utiliser cette fonctionnalité, vous devez activer les API RootSync et RepoSync. Vous pouvez également corriger des graphiques Helm avec Kustomize pour différents cas d'utilisation. Par exemple, vous pouvez combiner des charts Helm et Kustomize, ou afficher plusieurs graphiques Helm publics dans un seul rapprochement.

Configurer plusieurs clusters

Config Sync vous aide à déployer une configuration et des règles cohérentes dans plusieurs clusters pouvant s'étendre sur des environnements hybrides et multicloud.

Config Sync vous aide à configurer plusieurs clusters en vous offrant les options suivantes :

  • Au lieu d'exécuter de manière répétée la commande kubectl apply, vous pouvez orchestrer le déploiement des modifications de configuration sur les parcs de clusters via Git. Pour en savoir plus, consultez la page Déploiements sécurisés avec Anthos Config Management.
  • Vous pouvez vous assurer qu'une modification est envoyée à tous les clusters appropriés, et uniquement à ces derniers, en fonction des métadonnées appliquées à chaque cluster. Pour en savoir plus, consultez la page Configurer uniquement un sous-ensemble de clusters. Les métadonnées de cluster sont gérées de manière légèrement différente pour les formats de dépôts non structuré et hiérarchique.

Nous vous recommandons vivement d'enregistrer vos clusters. L'enregistrement de vos clusters facilite l'observation de l'état actuel de tous les clusters via Google Cloud Console, et permet de centraliser la configuration et la gestion de Config Sync sur les clusters enregistrés. Pour en savoir plus, consultez les pages Enregistrer un cluster, Configurer Config Sync et Mettre à jour les versions de Config Sync.

Configurer des espaces de noms

La configuration des espaces de noms avec Config Sync vous offre les fonctionnalités suivantes :

  • Vous pouvez provisionner de manière cohérente les espaces de noms Kubernetes en appliquant des règles aux espaces de noms, telles que des rôles RBAC, dans les clusters enregistrés et connectés. Les règles à l'échelle de l'espace de noms facilitent la mise en œuvre et la gestion de l'architecture mutualisée de vos clusters.
  • Appliquez des règles à plusieurs espaces de noms associés, sans dupliquer les configurations, et remplacez ou étendez une configuration pour un espace de noms ou un ensemble d'espaces de noms donné, afin de faciliter l'application de règles cohérentes entre les locataires.

Ces fonctionnalités fonctionnent différemment dans les formats de dépôts non structuré et hiérarchique.

Avec les dépôts non structurés, vous pouvez utiliser Hierarchy Controller pour propager des règles dans des hiérarchies d'espaces de noms que vous définissez pour vos clusters. Pour en savoir plus, consultez la page Présentation de Hierarchy Controller.

Avec les dépôts hiérarchiques, vous pouvez utiliser des groupes d'espaces de noms appelés espaces de noms abstraits pour contrôler les règles d'espaces de noms qui doivent être appliquées. Les espaces de noms abstraits nécessitent l'organisation hiérarchique des espaces de noms dans l'arborescence de répertoires de votre dépôt. Pour en savoir plus, consultez les pages Configurer des espaces de noms et des objets à l'échelle d'un espace de noms et Présentation de l'héritage des espaces de noms.

Les formats non structuré et hiérarchique acceptent également le ciblage des ensembles d'espaces de noms non hiérarchiques à l'aide de sélecteurs de libellés.

Commande nomos

Config Sync fournit une API. La commande nomos (nomos.exe sous Windows) utilise l'API, vérifie l'état de votre installation et valide les configurations.

Pour en savoir plus, consultez la section Utiliser l'outil de ligne de commande nomos.

Étapes suivantes