L'activation du mode multidépôt dans Config Sync vous permet de synchroniser la configuration de plusieurs dépôts avec le même ensemble de clusters. Vous pouvez utiliser les types de dépôts suivants :
Dépôt racine : ce dépôt vous permet de synchroniser les configurations appliquées à l'échelle du cluster et à 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 souhaité. Un administrateur central régit le dépôt racine. Un seul dépôt racine peut exister pour chaque cluster.
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.
Chaque dépôt dispose d'une référence Git unique (branche de dépôt, commit ou tag, et tuple de répertoire) que vous pouvez gérer séparément. Cette configuration dissocie le cycle de vie du déploiement de configuration pour différentes équipes. Elle vous permet également de choisir avec plus d'autonomie où vous souhaitez héberger le dépôt et comment le structurer.
Le schéma suivant montre comment les équipes peuvent utiliser un dépôt racine et des dépôts d'espaces de noms :
Dans ce schéma, 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.
Avant de commencer
Effectuez les tâches suivantes avant d'activer le mode multidépôt :
- Utilisez Config Sync version 1.5.1 ou ultérieure.
Limites
Tenez compte des limitations suivantes lorsque vous utilisez le mode multidépôt :
- Le champ
spec.enableMultiRepo
n'est pas compatible avec le champspec.git
. Si vous devez toujours utiliser le champspec.git
, consultez la section Utiliser les anciens champs spec.git. ClusterSelectors
etnamespaceSelectors
(y compris les annotations pointant vers des sélecteurs) ne fonctionnent que dans le dépôt racine.
Configurer la synchronisation à partir du dépôt racine
Pour configurer le dépôt racine, effectuez les tâches suivantes :
- Ouvrez votre fichier
config-management.yaml
. Définissez le champ
spec.enableMultiRepo
surtrue
:# config-management.yaml apiVersion: configmanagement.gke.io/v1 kind: ConfigManagement metadata: name: config-management spec: enableMultiRepo: true # ...other fields...
Appliquer les modifications :
kubectl apply -f config-management.yaml
Pour définir des fonctionnalités spécifiques pour le dépôt racine, créez le champ
root-sync.yaml file
. Exemple :# root-sync.yaml apiVersion: configsync.gke.io/v1alpha1 kind: RootSync metadata: name: root-sync namespace: config-management-system spec: git: repo: REPOSITORY revision: REVISION branch: BRANCH dir: "DIRECTORY" auth: AUTH_TYPE secretRef: name: SECRET_NAME
Remplacez l'élément suivant :
- REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt racine. Ce champ est obligatoire.
- REVISION : ajoutez la révision Git (tag ou hachage) à récupérer. Ce champ est facultatif et la valeur par défaut est
HEAD
. - BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est obligatoire.
- DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git qui représente le niveau supérieur du dépôt à synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine du dépôt.
- AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
none
ssh
cookiefile
token
gcenode
Ce champ est obligatoire.
- SECRET_NAME : ajoutez le nom que vous souhaitez donner à votre secret. Ce champ est obligatoire.
Créez un secret basé sur la méthode d'authentification de votre choix.
Le secret doit répondre aux exigences suivantes :
- Le nom du secret doit correspondre au nom
spec.git.secretRef
que vous avez défini dansrepo-sync.yaml
. - Vous devez ajouter la clé publique du secret au fournisseur Git.
- Le nom du secret doit correspondre au nom
Appliquez la configuration :
kubectl apply -f root-sync.yaml
Vérifiez l'installation :
kubectl -n config-management-system get pods | grep reconciler-manager
Un résultat semblable aux lignes suivantes doit s'afficher :
reconciler-manager-6f988f5fdd-4r7tr 1/1 Running 0 26s
Configurer la synchronisation à partir des dépôts d'espaces de noms
Deux options s'offrent à vous pour configurer les dépôts d'espaces de noms :
Contrôlez les dépôts d'espaces de noms dans le dépôt racine. Cette méthode centralise toute la configuration des dépôts d'espaces de noms dans le dépôt racine, permettant ainsi à un administrateur central de contrôler entièrement la configuration.
Contrôlez les dépôts d'espaces de noms avec l'API Kubernetes. Cette méthode délègue le contrôle du dépôt d'espaces de noms aux propriétaires d'espaces de noms.
Contrôler les dépôts d'espaces de noms dans le dépôt racine
Dans cette méthode, l'administrateur central gère la configuration des dépôts d'espaces de noms directement à partir du dépôt racine. Étant donné que Config Sync gère les ressources du dépôt d'espaces de noms, cette méthode empêche toute modification locale des définitions de ce dépôt.
Pour utiliser cette méthode, effectuez les tâches suivantes :
Dans le dépôt racine, déclarez une configuration
namespace
:# ROOT_REPO/namespaces/NAMESPACE/namespace.yaml apiVersion: v1 kind: Namespace metadata: name: NAMESPACE
Remplacez NAMESPACE par le nom de votre espace de noms.
Dans le dépôt racine, déclarez une configuration
RepoSync
dans le même espace de noms :# ROOT_REPO/namespaces/NAMESPACE/repo-sync.yaml apiVersion: configsync.gke.io/v1alpha1 kind: RepoSync metadata: name: repo-sync namespace: NAMESPACE spec: git: repo: REPOSITORY revision: REVISION branch: BRANCH dir: "DIRECTORY" auth: AUTH_TYPE secretRef: name: SECRET_NAME
Remplacez l'élément suivant :
- NAMESPACE : ajoutez le nom de votre espace de noms.
- REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt racine. Ce champ est obligatoire.
- REVISION : ajoutez la révision Git (tag ou hachage) à récupérer. Ce champ est facultatif et la valeur par défaut est
HEAD
. - BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est obligatoire.
- DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git qui représente le niveau supérieur du dépôt à synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine du dépôt.
- AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
none
ssh
cookiefile
token
gcenode
Ce champ est obligatoire.
- SECRET_NAME : ajoutez le nom que vous souhaitez donner à votre secret. Ce champ est obligatoire.
Il peut y avoir au plus une ressource RepoSync par espace de noms. Pour appliquer cette règle, le nom de l'objet doit être
repo-sync
. Toutes les configurations contenues dans le répertoire référencé parRepoSync
doivent également se trouver dans le même espace de noms que la ressourceRepoSync
.Dans le dépôt racine, déclarez une configuration
RoleBinding
qui accorde au compte de servicens-reconciler-NAMESPACE
l'autorisation de gérer les ressources dans l'espace de noms. Config Sync crée automatiquement le compte de servicens-reconciler-NAMESPACE
lorsque la configurationRepoSync
est synchronisée avec le cluster.Pour déclarer
RoleBinding
, créez le fichier manifeste suivant :# ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: syncs-repo namespace: NAMESPACE subjects: - kind: ServiceAccount name: ns-reconciler-NAMESPACE namespace: config-management-system roleRef: kind: ClusterRole name: RECONCILER_ROLE apiGroup: rbac.authorization.k8s.io
Remplacez l'élément suivant :
- NAMESPACE : ajoutez le nom de votre espace de noms.
RECONCILER_ROLE : en tant qu'administrateur central, vous pouvez définir RECONCILER_ROLE pour appliquer les types de configuration pouvant être synchronisés à partir du dépôt d'espaces de noms. Vous pouvez choisir l'un des rôles suivants :
Un ClusterRole par défaut :
admin
edit
Pour en savoir plus, consultez la section Rôles pour les utilisateurs.
Un ClusterRole ou Role défini par l'utilisateur déclaré dans le dépôt racine. Ce rôle permet des autorisations précises.
Validez les modifications précédentes dans le dépôt racine :
git add . git commit -m 'Setting up new namespace repository.' git push
Créez un secret basé sur la méthode d'authentification de votre choix.
Le secret doit répondre aux exigences suivantes :
- Créez le secret dans le même espace de noms que l'objet RepoSync.
- Le nom du secret doit correspondre au nom
spec.git.secretRef
que vous avez défini dansrepo-sync.yaml
. - Vous devez ajouter la clé publique du secret au fournisseur Git.
Pour vérifier la configuration, utilisez
kubectl get
sur l'un des objets du dépôt d'espaces de noms. Exemple :kubectl get rolebindings -n NAMESPACE
Contrôler les dépôts d'espaces de noms avec l'API Kubernetes
Dans cette méthode, l'administrateur central ne déclare que l'espace de noms dans le dépôt racine et délègue la déclaration du fichier RepoSync
à l'opérateur d'application.
Tâches administratives centrales
L'administrateur central effectue les tâches suivantes :
Dans le dépôt racine, déclarez une configuration
namespace
:# ROOT_REPO/namespaces/NAMESPACE/namespace.yaml apiVersion: v1 kind: Namespace metadata: name: NAMESPACE
Remplacez NAMESPACE par le nom de votre espace de noms.
Dans le dépôt racine, déclarez une configuration
RoleBinding
pour accorder les autorisations aux opérateurs d'application. Utilisez la prévention de l'élévation RBAC pour vous assurer que l'opérateur d'application ne pourra pas appliquer ultérieurement une liaison de rôle avec des autorisations non accordées par cette liaison de rôle.Pour déclarer l'objet RoleBinding, créez le fichier manifeste suivant :
# ROOT_REPO/namespaces/NAMESPACE/operator-rolebinding.yaml kind: RoleBinding # Add RBAC escalation prevention apiVersion: rbac.authorization.k8s.io/v1 metadata: name: operator namespace: NAMESPACE subjects: - kind: User name: USER_NAME apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: OPERATOR_ROLE apiGroup: rbac.authorization.k8s.io
Remplacez l'élément suivant :
- NAMESPACE : ajoutez l'espace de noms que vous avez créé dans le dépôt racine.
- USER_NAME : ajoutez le nom d'utilisateur de l'opérateur d'application.
OPERATOR_ROLE : en tant qu'administrateur central, vous pouvez définir OPERATOR_ROLE pour appliquer les types de configuration pouvant être synchronisés à partir du dépôt d'espaces de noms. Vous pouvez choisir l'un des rôles suivants :
Un ClusterRole par défaut :
admin
edit
Pour en savoir plus, consultez la section Rôles pour les utilisateurs.
Un ClusterRole ou Role défini par l'utilisateur déclaré dans le dépôt racine. Cela permet des autorisations précises.
Validez les modifications précédentes dans le dépôt racine :
git add . git commit -m 'Setting up new namespace repository.' git push
Tâches de l'opérateur d'application
L'opérateur d'application effectue les tâches suivantes :
Déclarez une configuration
RoleBinding
qui accorde au compte de servicens-reconciler-NAMESPACE
provisionné automatiquement l'autorisation de gérer les ressources de l'espace de noms. Config Sync crée automatiquement le compte de servicens-reconciler-NAMESPACE
lorsque la configurationRepoSync
est synchronisée avec le cluster.Pour déclarer l'objet RoleBinding, créez le fichier manifeste suivant :
# sync-rolebinding.yaml kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: syncs-repo namespace: NAMESPACE subjects: - kind: ServiceAccount name: ns-reconciler-NAMESPACE namespace: config-management-system roleRef: kind: ClusterRole name: RECONCILER_ROLE apiGroup: rbac.authorization.k8s.io
Remplacez l'élément suivant :
- NAMESPACE : ajoutez l'espace de noms que vous avez créé dans le dépôt racine.
- RECONCILER_ROLE : en tant qu'opérateur d'application, vous pouvez définir RECONCILER_ROLE pour appliquer les types de configuration pouvant être synchronisés à partir du dépôt d'espaces de noms. Vous ne pouvez restreindre davantage l'ensemble d'autorisations que l'administrateur central vous a accordées. Par conséquent, ce rôle ne peut pas être plus permissif que OPERATOR_ROLE que l'administrateur central a déclaré dans la section précédente.
Appliquez la configuration RoleBinding :
kubectl apply -f sync-rolebinding.yaml
Créez un secret basé sur la méthode d'authentification de votre choix.
Le secret doit répondre aux exigences suivantes :
- Créez le secret dans le même espace de noms que l'objet RepoSync.
- Le nom du secret doit correspondre au nom
spec.git.secretRef
que vous avez défini dansrepo-sync.yaml
. - Vous devez ajouter la clé publique du secret au fournisseur Git.
Déclarez une configuration
RepoSync
:# repo-sync.yaml apiVersion: configsync.gke.io/v1alpha1 kind: RepoSync metadata: name: repo-sync namespace: NAMESPACE spec: git: repo: REPOSITORY revision: REVISION branch: BRANCH dir: "DIRECTORY" auth: AUTH_TYPE secretRef: name: SECRET_NAME
Remplacez l'élément suivant :
- REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt racine. Ce champ est obligatoire.
- REVISION : ajoutez la révision Git (tag ou hachage) à récupérer. Ce champ est facultatif et la valeur par défaut est
HEAD
. - BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est obligatoire.
- DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git qui représente le niveau supérieur du dépôt à synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine du dépôt.
- AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
none
ssh
cookiefile
token
gcenode
Ce champ est obligatoire.
- SECRET_NAME : ajoutez le nom que vous souhaitez donner à votre secret. Ce champ est obligatoire.
Il peut y avoir au plus une ressource RepoSync par espace de noms. Pour appliquer cette règle, le nom de l'objet doit être
repo-sync
. Toutes les configurations contenues dans le répertoire référencé parRepoSync
doivent également se trouver dans le même espace de noms que la ressourceRepoSync
.Appliquez la configuration
RepoSync
:kubectl apply -f repo-sync.yaml
Pour vérifier la configuration, utilisez
kubectl get
sur l'un des objets du dépôt d'espaces de noms. Exemple :kubectl get rolebindings -n NAMESPACE
Utiliser les anciens champs spec.git
Pour faciliter la migration vers les ressources de RootSync
, définissez spec.enableLegacyFields
sur true
dans votre fichier config-management.yaml
. L'ajout de ce champ vous permet d'utiliser les champs obsolètes spec.git
dans la ressource ConfigManagement
. La définition de ce champ génère automatiquement la ressource RootSync
sur le cluster. Ne modifiez pas la configuration RootSync
.
L'exemple suivant montre comment utiliser le champ spec.git
:
# config-management.yaml
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
name: config-management
spec:
enableMultiRepo: true
enableLegacyFields: true
git:
syncRepo: REPO
syncBranch: BRANCH
secretType: TYPE
policyDir: "DIRECTORY"
# ...other fields...
Pour en savoir plus sur ces champs, consultez la section Champs config-management.yaml.
Arrêter et reprendre la synchronisation
Cette section vous explique comment arrêter temporairement la synchronisation et la reprendre. Vous devrez peut-être effectuer cette opération si une configuration incorrecte est validée par erreur dans votre dépôt.
Seul un administrateur central peut arrêter la synchronisation dans le dépôt racine.
La possibilité d'arrêter la synchronisation dans les dépôts d'espaces de noms dépend de la méthode de configuration utilisée pour ceux-ci.
Si la méthode Contrôler les dépôts d'espaces de noms dans le dépôt racine a été utilisée, un administrateur central est le seul à pouvoir arrêter et reprendre la synchronisation.
Si la méthode Contrôler les dépôts d'espaces de noms avec l'API Kubernetes a été utilisée, les opérateurs d'application peuvent arrêter et reprendre la synchronisation à partir des dépôts d'espaces de noms sur lesquels ils travaillent.
Arrêter la synchronisation
Cette section explique comment arrêter la synchronisation du dépôt racine et des dépôts d'espaces de noms.
Arrêter la synchronisation à partir du dépôt racine
Pour arrêter la synchronisation à partir du dépôt racine, un administrateur central peut exécuter la commande suivante :
kubectl -n config-management-system scale deployment root-reconciler --replicas=0
Cette commande réduit à 0 le nombre de replicas
dans le déploiement de root-reconciler
.
Arrêter la synchronisation à partir des dépôts d'espaces de noms
Sélectionnez l'onglet Méthode du dépôt racine ou Méthode de l'API Kubernetes pour afficher les instructions correspondantes.
Méthode du dépôt racine
Si la méthode Contrôler les dépôts d'espaces de noms dans le dépôt racine a été utilisée, les administrateurs centraux peuvent effectuer les commandes suivantes pour arrêter la synchronisation à partir du dépôt d'un espace de noms :
kubectl -n config-management-system scale deployment ns-reconciler-NAMESPACE --replicas=0
Cette commande réduit à 0 le nombre d'instances dupliquées du déploiement ns-reconciler-NAMESPACE
.
Méthode de l'API Kubernetes
Si la méthode Contrôler les dépôts d'espaces de noms avec l'API Kubernetes a été utilisée, les opérateurs d'application peuvent arrêter la synchronisation en exécutant les commandes suivantes :
Récupérez la configuration
RepoSync
et enregistrez-la pour l'utiliser plus tard lorsque vous souhaiterez reprendre la synchronisation :kubectl -n NAMESPACE get reposyncs repo-sync -oyaml > repo-sync.yaml
Remplacez NAMESPACE par l'espace de noms de votre objet RepoSync.
Supprimez la configuration
RepoSync
:kubectl -n NAMESPACE delete reposyncs repo-sync
Cette commande déclenche le gestionnaire de rapprochement pour supprimer le rapprochement de l'espace de noms (
ns-reconciler-NAMESPACE
) de NAMESPACE et arrête la synchronisation.
Reprendre la synchronisation
Cette section explique comment reprendre la synchronisation du dépôt racine et des dépôts d'espaces de noms.
Reprendre la synchronisation à partir du dépôt racine
Pour reprendre la synchronisation à partir d'un dépôt racine, un administrateur central peut exécuter la commande suivante :
kubectl -n config-management-system scale deployment root-reconciler --replicas=1
Cette commande effectue le scaling du déploiement root-reconciler
pour qu'il dispose d'une instance dupliquée.
Reprendre la synchronisation à partir d'un dépôt d'espaces de noms
Sélectionnez l'onglet Méthode du dépôt racine ou Méthode de l'API Kubernetes pour afficher les instructions correspondantes.
Méthode du dépôt racine
Si vous avez utilisé la méthode Contrôler les dépôts d'espaces de noms dans le dépôt racine, un administrateur central peut exécuter la commande suivante :
kubectl -n config-management-system scale deployment ns-reconciler-NAMESPACE --replicas=1
Cette commande effectue le scaling du déploiement "ns-reconciler-NAMESPACE" pour qu'il dispose d'une instance dupliquée.
Méthode de l'API Kubernetes
Si vous avez utilisé la méthode Contrôler les dépôts d'espaces de noms avec l'API Kubernetes, les opérateurs d'application peuvent reprendre la synchronisation en appliquant à nouveau repo-sync.yaml
, qui contient la configuration RepoSync
:
kubectl apply -f repo-sync.yaml
Cette commande déclenche le gestionnaire de rapprochement pour créer un processus de rapprochement des espaces de noms et un déploiement ns-reconciler-NAMESPACE
.
Supprimer les dépôts racine et d'espace de noms
Pour supprimer le dépôt racine, supprimez le fichier RootSync
. Exemple :
kubectl delete -f root-sync.yaml
Pour désinstaller un dépôt d'espaces de noms, supprimez un fichier RepoSync
. Cette action désinstalle le dépôt d'espaces de noms correspondant.
Résolution de conflits
Lorsque vous travaillez avec deux dépôts, des conflits peuvent survenir lorsque la même ressource (groupes correspondants, genres, noms et espaces de noms) est déclarée à la fois dans la racine et dans le dépôt d'espaces de noms. Dans ce cas, seule la déclaration dans le dépôt racine est appliquée au cluster.
Comme le dépôt racine est toujours prioritaire, vous pouvez résoudre le conflit en mettant à jour le dépôt racine afin qu'il corresponde au dépôt d'espaces de noms ou en supprimant l'objet conflictuel dans le dépôt d'espaces de noms.