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 les configurations dans un ou plusieurs dépôts Git ou, si vous ne souhaitez pas utiliser de dépôt Git, créez des images OCI (aperçu). 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 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.

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.

Autorisations / RBAC Config Sync

Les sections suivantes répertorient les autorisations pour Config Sync et ses composants afin d'obtenir un accès correct au niveau du cluster. Les autorisations répertoriées sont activées par défaut et ne doivent pas être désactivées lorsque Config Sync est en cours d'exécution.

.
Composants Namespace Compte de service Autorisations Description
reconciler-manager config-management-system reconciler-manager cluster-admin Le gestionnaire de rapprochement doit être cluster-admin afin de provisionner les rapprochements racines et de créer l'objet ClusterRoleBinding pour les rapprochements racines
root reconcilers config-management-system nom du rapprochement racine cluster-admin Les rapprochements racines doivent être cluster-admin pour appliquer des ressources à l'échelle d'un cluster et personnalisées
namespace reconcilers config-management-system nom du rapprochement de l'espace de noms configsync.gke.io:ns-reconciler Les rapprochements d'espace de noms doivent être autorisés à obtenir ou à mettre à jour les objets RepoSync et ResourceGroup, ainsi que leur état.
resource-group-controller-manager config-management-system resource-group-sa resource-group-manager-role resource-group-leader-election-role Le rôle resource-group-controller-manager doit disposer des rôles nécessaires pour vérifier l'état de l'objet et activer l'élection du responsable.
admission-webhook config-management-system admission-webhook cluster-admin Le webhook d'admission doit être cluster-admin afin de refuser les requêtes vers un objet du cluster.
importer config-management-system importer cluster-admin L'importateur doit être cluster-admin pour définir les autorisations RBAC en raison de la restriction selon laquelle l'utilisateur doit être autorisé à le définir.

RBAC pour les rapprochements d'espaces de noms

Les définitions d'API suivantes montrent les autorisations de contrôle d'accès pour les rapprochements d'espaces de noms.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: configsync.gke.io:ns-reconciler
  labels:
    configmanagement.gke.io/system: "true"
    configmanagement.gke.io/arch: "csmr"
rules:
- apiGroups: ["configsync.gke.io"]
  resources: ["reposyncs"]
  verbs: ["get"]
- apiGroups: ["configsync.gke.io"]
  resources: ["reposyncs/status"]
  verbs: ["get","list","update"]
- apiGroups: ["kpt.dev"]
  resources: ["resourcegroups"]
  verbs: ["*"]
- apiGroups: ["kpt.dev"]
  resources: ["resourcegroups/status"]
  verbs: ["*"]
- apiGroups:
  - policy
  resources:
  - podsecuritypolicies
  resourceNames:
  - acm-psp
  verbs:
  - use

RBAC pour le contrôleur de groupe de ressources

Les définitions d'API suivantes montrent les autorisations de contrôle d'accès pour le contrôleur de groupe de ressources.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  labels:
    configmanagement.gke.io/arch: "csmr"
    configmanagement.gke.io/system: "true"
  name: resource-group-manager-role
rules:
# This permission is needed to get the status for managed resources
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch
# This permission is needed to watch/unwatch types as they are registered or removed.
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
  - list
  - watch
# This permission is needed so that the ResourceGroup controller can reconcile a ResourceGroup CR
- apiGroups:
  - kpt.dev
  resources:
  - resourcegroups
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
# This permission is needed so that the ResourceGroup controller can update the status of a ResourceGroup CR
- apiGroups:
  - kpt.dev
  resources:
  - resourcegroups/status
  verbs:
  - get
  - patch
  - update
# This permission is needed so that the ResourceGroup controller can work on a cluster with PSP enabled
- apiGroups:
  - policy
  resourceNames:
  - acm-psp
  resources:
  - podsecuritypolicies
  verbs:
  - use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    configmanagement.gke.io/arch: "csmr"
    configmanagement.gke.io/system: "true"
  name: resource-group-leader-election-role
  namespace: resource-group-system
rules:  // The following permissions are needed so that the leader election can work
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete
- apiGroups:
  - ""
  resources:
  - configmaps/status
  verbs:
  - get
  - update
  - patch
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  verbs:
  - '*'

Étape suivante