Présentation de Config Sync

Config Sync 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. Les configurations sont stockées dans un ou plusieurs dépôts Git, et Config Sync les conserve de manière à ce qu'elles demeurent cohérentes avec les objets Kubernetes configurés. Cette approche GitOps (parfois appelée configuration en tant que code) vous permet de gérer et de déployer les configurations courantes à l'aide d'un processus vérifiable, transactionnel, révisable et dont les versions sont contrôlées.

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

Prérequis

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 pages Présentation des configurations et Configurer des objets Kubernetes qui expliquent comment créer une configuration.

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, un dépôt racine et à des dépôts d'espaces de noms :

  • Dépôt racine : ce dépôt vous permet de synchroniser les configurations appliquées au niveau du cluster et au niveau de l'espace de noms. Le dépôt racine utilise 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. Chaque cluster ne peut avoir qu'un seul dépôt racine qui est généralement géré 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. 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. Config Sync utilise le format de dépôt hiérarchique par défaut. 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é. Pour en savoir plus, consultez la section Configurer la synchronisation à partir des dépôts d'espaces de noms.

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.

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 la commande nomos.

Étape suivante