Synchroniser à partir de plusieurs dépôts

L'activation du mode multidépôt dans Config Sync vous permet de synchroniser les configurations de plusieurs dépôts avec le même ensemble de clusters. Pour utiliser le mode multidépôt, vous devez créer un dépôt racine unique et éventuellement créer des dépôts d'espaces de noms. Un dépôt racine peut synchroniser les configurations à l'échelle d'un cluster et à l'échelle d'un espace de noms. Il est généralement géré par un administrateur. Les dépôts d'espaces de noms contiennent des configurations à l'échelle d'un espace de noms qui sont synchronisées avec un espace de noms particulier couvrant plusieurs clusters. Pour en savoir plus sur ces types de dépôts, consultez la section Dépôts dans la présentation de Config Sync.

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. Il vous permet également de choisir où vous souhaitez placer le dépôt et comment le structurer pour plus d'autonomie.

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.

Avant de commencer

Effectuez les tâches suivantes avant d'activer le mode multidépôt :

  • Créez ou accédez à des dépôts Git.
  • Créez ou accédez à un projet Google Cloud.
  • Créez ou accédez à un cluster Google Kubernetes Engine (GKE) répondant aux exigences suivantes :
    • Il s'agit d'un cluster standard. Remarque : Config Sync n'est pas compatible avec les clusters Autopilot.
    • Il utilise une version de GKE comprise entre les versions 1.18 et 1.21.
  • Utilisez Config Sync 1.5.3 ou une version ultérieure.
  • Si vous utilisez la version 1.7 et que vous installez Config Sync dans un cluster privé, ajoutez une règle de pare-feu pour autoriser le port 8676. Le webhook d'admission Config Sync utilise le port 8676 pour prévenir les dérives. À partir de la version 1.8.0, le port est remplacé par 10250 et est ouvert par défaut dans les clusters privés.

Limites

Tenez compte des limitations suivantes lorsque vous utilisez le mode multidépôt :

Configurer la synchronisation à partir du dépôt racine

Pour configurer la synchronisation à partir du dépôt racine, vous devez activer le mode multi-dépôt dans votre objet ConfigManagement et créer un objet RootSync qui synchronise votre dépôt racine avec le cluster. Vous ne pouvez créer qu'un seul dépôt racine par cluster et le dépôt racine peut être un dépôt non structuré ou un dépôt hiérarchique.

Les sections suivantes décrivent trois méthodes différentes pour activer le mode multidépôt :

  1. Si vous n'avez pas déjà installé Config Sync, créez une configuration de dépôt Git racine.
  2. Si vous avez déjà installé Config Sync, déplacez la configuration du dépôt Git racine vers RootSync.
  3. Si vous avez déjà installé Config Sync et que vous devez utiliser les champs spec.git, conservez la configuration du dépôt Git racine dans le fichier YAML ConfigManagement.

1. Nouvelle configuration

Si vous n'avez pas encore installé Config Sync, effectuez les tâches suivantes pour activer le mode multidépôt :

  1. Effectuez les sections suivantes dans la section Installer Config Sync manuellement :

    1. Avant de commencer
    2. Déployer l'opérateur
    3. Accorder à l'opérateur un accès en lecture seule à Git
  2. Si vous utilisez la version 1.7 et que vous installez Config Sync dans un cluster privé, ajoutez une règle de pare-feu pour autoriser le port 8676. Le webhook d'admission Config Sync utilise le port 8676 pour prévenir les dérives. À partir de la version 1.8.0, le port est remplacé par 10250 et est ouvert par défaut dans les clusters privés.

  3. Créez un fichier nommé config-management.yaml et copiez le fichier YAML ci-dessous dans ce fichier :

    # config-management.yaml
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      enableMultiRepo: true
    
  4. Appliquez les modifications :

    kubectl apply -f config-management.yaml
    
  5. Créez un objet RootSync :

    # root-sync.yaml
    # If you are using a Config Sync version earlier than 1.7.0,
    # use: apiVersion: configsync.gke.io/v1alpha1
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: root-sync
      namespace: config-management-system
    spec:
      sourceFormat: ROOT_FORMAT
      git:
        repo: ROOT_REPOSITORY
        revision: ROOT_REVISION
        branch: ROOT_BRANCH
        dir: "ROOT_DIRECTORY"
        auth: ROOT_AUTH_TYPE
        gcpServiceAccountEmail: ROOT_EMAIL
        secretRef:
          name: ROOT_SECRET_NAME
        # the `noSSLVerify` field is supported in Anthos Config Management version 1.8.2 and later.
        noSSLVerify: ROOT_NO_SSL_VERIFY
    

    Remplacez l'élément suivant :

    • ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
    • ROOT_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.
    • ROOT_REVISION : ajoutez la révision Git (tag ou hachage) à récupérer. Ce champ est facultatif et la valeur par défaut est HEAD.
    • ROOT_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master.
    • ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
    • ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

      • none : n'utiliser aucune authentification
      • ssh : utilise une paire de clés SSH.
      • cookiefile : utiliser un cookiefile
      • token : utiliser un jeton
      • gcpserviceaccount : utilisez un compte de service Google pour accéder à Cloud Source Repositories.
      • gcenode : utilisez un compte de service Google pour accéder à Cloud Source Repositories. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.

      Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.

      Ce champ est obligatoire.

    • ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.

    • ROOT_SECRET_NAME : ajoutez le nom de votre secret. Si vous utilisez un secret, vous devez ajouter la clé publique du secret au fournisseur Git. Ce champ est facultatif.

    • ROOT_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.

Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

  1. Appliquez les modifications :

    kubectl apply -f root-sync.yaml
    

2. Déplacer la configuration

Si vous avez déjà installé Config Sync, vous pouvez déplacer les configurations de dépôt Git de votre objet ConfigManagement existant vers un objet RootSync.

Si vous configurez le dépôt racine en déplaçant la configuration, procédez comme suit :

  1. Si vous utilisez la version 1.7 et que vous installez Config Sync dans un cluster privé, ajoutez une règle de pare-feu pour autoriser le port 8676. Le webhook d'admission Config Sync utilise le port 8676 pour prévenir les dérives. À partir de la version 1.8.0, le port est remplacé par 10250 et est ouvert par défaut dans les clusters privés.
  2. Ouvrez l'objet ConfigManagement.
  3. Faites une copie des valeurs dans les champs spec.git. Ces valeurs s'utilisent pour créer l'objet RootSync.
  4. Supprimez tous les champs spec.git (y compris git:) de l'objet ConfigManagement.
  5. Dans l'objet ConfigManagement, définissez le champ spec.enableMultiRepo sur true :

    # config-management.yaml
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      enableMultiRepo: true
    
  6. Appliquez les modifications :

    kubectl apply -f config-management.yaml
    
  7. En utilisant les valeurs que vous avez copiées à partir de l'objet ConfigManagement, créez l'objet RootSync. Exemple :

    # root-sync.yaml
    # If you are using a Config Sync version earlier than 1.7.0,
    # use: apiVersion: configsync.gke.io/v1alpha1
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: root-sync
      namespace: config-management-system
    spec:
      sourceFormat: ROOT_FORMAT
      git:
        repo: ROOT_REPOSITORY
        revision: ROOT_REVISION
        branch: ROOT_BRANCH
        dir: "ROOT_DIRECTORY"
        auth: ROOT_AUTH_TYPE
        gcpServiceAccountEmail: ROOT_EMAIL
        secretRef:
          name: ROOT_SECRET_NAME
    

    Remplacez l'élément suivant :

    • ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
    • ROOT_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.
    • ROOT_REVISION : ajoutez la révision Git (tag ou hachage) à récupérer. Ce champ est facultatif et la valeur par défaut est HEAD.
    • ROOT_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master.
    • ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
    • ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

      • none : n'utiliser aucune authentification
      • ssh : utilise une paire de clés SSH.
      • cookiefile : utiliser un cookiefile
      • token : utiliser un jeton
      • gcpserviceaccount : utilisez un compte de service Google pour accéder à Cloud Source Repositories.
      • gcenode : utilisez un compte de service Google pour accéder à Cloud Source Repositories. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.

      Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.

      Ce champ est obligatoire.

    • ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.

    • ROOT_SECRET_NAME : ajoutez le nom de votre secret. Si vous utilisez un secret, vous devez ajouter la clé publique du secret au fournisseur Git. Ce champ est facultatif.

  8. Appliquez les modifications :

    kubectl apply -f root-sync.yaml
    

3. Conserver la configuration

Si vous avez déjà installé Config Sync, vous pouvez conserver un dépôt Git racine existant dans votre objet ConfigManagement. Cependant, cette méthode n'est pas recommandée, car elle va devenir obsolète.

Pour configurer le dépôt racine en conservant le dépôt racine dans l'objet ConfigManagement, procédez comme suit :

  1. Si vous utilisez la version 1.7 et que vous installez Config Sync dans un cluster privé, ajoutez une règle de pare-feu pour autoriser le port 8676. Le webhook d'admission Config Sync utilise le port 8676 pour prévenir les dérives. À partir de la version 1.8.0, le port est remplacé par 10250 et est ouvert par défaut dans les clusters privés.

  2. Dans l'objet ConfigManagement, définissez les champs spec.enableMultiRepo et spec.enableLegacyFields sur true, définissez le paramètre spec.sourceFormat sur unstructured afin d'utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations comme bon vous semble.

    # config-management.yaml
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      enableMultiRepo: true
      enableLegacyFields: true
      sourceFormat: FORMAT
      git:
        syncRepo: REPO
        syncBranch: BRANCH
        secretType: TYPE
        policyDir: "DIRECTORY"
    # ...other fields...
    
  3. Appliquez les modifications :

    kubectl apply -f config-management.yaml
    

L'application de config-management.yaml avec les paramètres enableMultiRepo: true et enableLegacyFields: true génère automatiquement l'objet RootSync sur le cluster. Ne modifiez pas la configuration RootSync générée.

Pour ajouter des dépôts d'espaces de noms facultatifs, consultez la section Configurer la synchronisation à partir de dépôts d'espaces de noms. Si vous souhaitez ne synchroniser qu'un seul dépôt et continuer à utiliser votre workflow actuel, vous pouvez ignorer cette section.

Vérifier l'état de synchronisation du dépôt racine

Vous pouvez utiliser la commande nomos status pour inspecter l'état de synchronisation du dépôt racine :

nomos status

Un résultat semblable aux lignes suivantes doit s'afficher :

my_managed_cluster-1
  --------------------
  <root>   git@github.com:foo-corp/acme/admin@main
  SYNCED   f52a11e4

Vérifier l'installation de RootSync

Lorsque vous créez un objet RootSync, Config Sync crée un rapprochement nommé root-reconciler. Un rapprochement est un pod qui est déployé en tant que déploiement. Il synchronise les fichiers manifestes d'un dépôt Git avec un cluster.

Vous pouvez vérifier que l'objet RootSync fonctionne correctement en vérifiant l'état du déploiement root-reconciler :

kubectl get -n config-management-system deployment/root-reconciler

Un résultat semblable aux lignes suivantes doit s'afficher :

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
root-reconciler   1/1     1            1           3h42m

Pour analyser plus en détail l'état de votre objet RootSync, consultez la section Explorer les objets RootSync et RepoSync.

Configurer la synchronisation à partir des dépôts d'espaces de noms

Une fois que vous avez configuré votre dépôt racine, vous pouvez configurer des dépôts d'espaces de noms que les utilisateurs non administrateurs peuvent contrôler. Les dépôts d'espaces de noms doivent être non structurés.

Pour configurer des dépôts d'espaces de noms, vous devez attribuer des autorisations et créer un objet RepoSync qui synchronise votre dépôt d'espaces de noms avec le cluster. Vous avez le choix entre deux méthodes 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 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.

  • Facultatif : activez le webhook d'admission dans le dépôt d'espaces de noms. Si vous souhaitez activer le webhook d'admission Config Sync en tant qu'étape supplémentaire pour prévenir la dérive, suivez les étapes décrites dans la section Activer le webhook d'admission dans les dépôts 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 objets du dépôt d'espace 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 :

  1. 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.

  2. Dans le dépôt racine, créez un objet RepoSync dans le même espace de noms :

    # ROOT_REPO/namespaces/NAMESPACE/repo-sync.yaml
     # If you are using a Config Sync version earlier than 1.8.0,
     # use: apiVersion: configsync.gke.io/v1alpha1
    apiVersion: configsync.gke.io/v1beta1
    kind: RepoSync
    metadata:
      name: repo-sync
      namespace: NAMESPACE
    spec:
      # Since this is for a namespace repository, the format should be unstructured
      sourceFormat: unstructured
      git:
       repo: NAMESPACE_REPOSITORY
       revision: NAMESPACE_REVISION
       branch: NAMESPACE_BRANCH
       dir: "NAMESPACE_DIRECTORY"
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       secretRef:
         name: NAMESPACE_SECRET_NAME
       # the `noSSLVerify` field is supported in Anthos Config Management version 1.8.2 and later.
       noSSLVerify: NAMESPACE_NO_SSL_VERIFY
    

    Remplacez l'élément suivant :

    • NAMESPACE : ajoutez le nom de votre espace de noms.
    • NAMESPACE_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt de l'espace de noms. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.
    • NAMESPACE_REVISION : ajoutez la révision Git (tag ou hachage) à récupérer. Ce champ est facultatif et la valeur par défaut est HEAD.
    • NAMESPACE_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master.
    • NAMESPACE_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
    • NAMESPACE_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

      • none : n'utiliser aucune authentification
      • ssh : utilise une paire de clés SSH.
      • cookiefile : utiliser un cookiefile
      • token : utiliser un jeton
      • gcpserviceaccount : utilisez un compte de service Google pour accéder à Cloud Source Repositories.
      • gcenode : utilisez un compte de service Google pour accéder à Cloud Source Repositories. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.

        Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.

      Ce champ est obligatoire.

    • NAMESPACE_EMAIL : si vous avez ajouté gcpserviceaccount comme AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.

    • NAMESPACE_SECRET_NAME : ajoutez le nom que vous souhaitez donner à votre Secret. Ce champ est facultatif.

    • NAMESPACE_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.

    Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RepoSync.

    Il peut y avoir au maximum un objet RepoSync par espace de noms. Pour appliquer cette restriction, l'objet name doit être repo-sync. Toutes les configurations contenues dans le répertoire référencé par RepoSync doivent également se trouver dans le même espace de noms que l'objet RepoSync.

  3. Dans le dépôt racine, déclarez une configuration RoleBinding qui accorde au compte de service ns-reconciler-NAMESPACE l'autorisation de gérer des objets dans l'espace de noms. Config Sync crée automatiquement le compte de service ns-reconciler-NAMESPACE lorsque la configuration RepoSync est synchronisée avec le cluster.

    Pour déclarer RoleBinding, créez l'objet 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 rôle ClusterRole ou Role défini par l'utilisateur et déclaré dans le dépôt racine. Ce rôle permet des autorisations précises.

  4. Effectuez un commit des modifications dans le dépôt racine :

     git add .
     git commit -m 'Setting up new namespace repository.'
     git push
    
  5. Si nécessaire, créez un secret basé sur la méthode d'authentification de votre choix. Si vous avez utilisé none comme type d'authentification, vous pouvez ignorer cette étape.

    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 dans repo-sync.yaml.
    • Vous devez ajouter la clé publique du Secret au fournisseur Git.
  6. 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 des 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 de l'objet RepoSync à l'opérateur d'application.

Tâches administratives centrales

L'administrateur central effectue les tâches suivantes :

  1. 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.

  2. Dans le dépôt racine, déclarez un 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: USERNAME
       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.
    • USERNAME : 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. Ce rôle permet des autorisations précises.

  3. Effectuez un commit des modifications 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 :

  1. Déclarez une configuration RoleBinding qui accorde au compte de service ns-reconciler-NAMESPACE provisionné automatiquement l'autorisation de gérer les objets de l'espace de noms. Config Sync crée automatiquement le compte de service ns-reconciler-NAMESPACE lorsque la configuration RepoSync 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.
  2. Appliquez la configuration RoleBinding :

    kubectl apply -f sync-rolebinding.yaml
    
  3. Si nécessaire, créez un secret basé sur la méthode d'authentification de votre choix. Si vous avez utilisé none comme type d'authentification, vous pouvez ignorer cette étape.

    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 dans root-sync.yaml.
    • Vous devez ajouter la clé publique du Secret au fournisseur Git.
  4. Déclarez une configuration RepoSync :

    # repo-sync.yaml
    # If you are using a Config Sync version earlier than 1.8.0,
    # use: apiVersion: configsync.gke.io/v1alpha1
    apiVersion: configsync.gke.io/v1beta1
    kind: RepoSync
    metadata:
      name: repo-sync
      namespace: NAMESPACE
    spec:
      # Since this is for a namespace repository, the format should be unstructured
      sourceFormat: unstructured
      git:
       repo: NAMESPACE_REPOSITORY
       revision: NAMESPACE_REVISION
       branch: NAMESPACE_BRANCH
       dir: "NAMESPACE_DIRECTORY"
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       secretRef:
         name: NAMESPACE_SECRET_NAME
       # the `noSSLVerify` field is supported in Anthos Config Management version 1.8.2 and later.
       noSSLVerify: REPO_SSL_VERIFY
    

    Remplacez l'élément suivant :

    • NAMESPACE_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt de l'espace de noms. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.
    • NAMESPACE_REVISION : ajoutez la révision Git (tag ou hachage) à récupérer. Ce champ est facultatif et la valeur par défaut est HEAD.
    • NAMESPACE_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master.
    • NAMESPACE_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
    • NAMESPACE_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

      • none : n'utiliser aucune authentification
      • ssh : utilise une paire de clés SSH.
      • cookiefile : utiliser un cookiefile
      • token : utiliser un jeton
      • gcpserviceaccount : utilisez un compte de service Google pour accéder à Cloud Source Repositories.
      • gcenode : utilisez un compte de service Google pour accéder à Cloud Source Repositories. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.

        Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.

      Ce champ est obligatoire.

    • NAMESPACE_EMAIL : si vous avez ajouté gcpserviceaccount comme AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.

    • NAMESPACE_SECRET_NAME : ajoutez le nom que vous souhaitez donner à votre Secret. Ce champ est facultatif.

    • NAMESPACE_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.

    Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RepoSync.

    Il peut y avoir au maximum un objet RepoSync par espace de noms. Pour appliquer cette règle, le nom de l'objet name doit être repo-sync. Toutes les configurations contenues dans le répertoire référencé par RepoSync doivent également se trouver dans le même espace de noms que l'objet RepoSync.

  5. Appliquez la configuration RepoSync :

    kubectl apply -f repo-sync.yaml
    
  6. 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
    

Vérifier l'état de synchronisation du dépôt d'espaces de noms

Vous pouvez utiliser la commande nomos status pour inspecter l'état de synchronisation du dépôt d'espaces de noms :

nomos status

Un résultat semblable aux lignes suivantes doit s'afficher :

my_managed_cluster-1
  --------------------
  <root>   git@github.com:foo-corp/acme/admin@main
  SYNCED   f52a11e4
  --------------------
  bookstore  git@github.com:foo-corp/acme/bookstore@v1
  SYNCED     34d1a8c8

Dans cet exemple de résultat, le dépôt d'espaces de noms est configuré pour l'espace de noms nommé bookstore.

Vérifier l'installation de RepoSync

Lorsque vous créez un objet RepoSync, Config Sync crée un rapprochement appelé ns-reconciler-NAMESPACE, où NAMESPACE est l'espace de noms dans lequel vous avez créé votre objet RepoSync.

Vous pouvez vérifier que l'objet RepoSync fonctionne correctement en vérifiant l'état du déploiement ns-reconciler-NAMESPACE :

kubectl get -n config-management-system deployment/ns-reconciler-NAMESPACE

Remplacez NAMESPACE par l'espace de noms dans lequel vous avez créé votre dépôt d'espaces de noms.

Pour analyser plus en détail l'état de votre objet RepoSync, consultez la section Explorer les objets RootSync et RepoSync.

Prévenir les écarts de configuration

Config Sync réduit le risque d'"opérations cachées" via la détection de dérive. Lorsque des modifications non validées sont envoyées à des clusters opérationnels, Config Sync détecte et corrige les écarts de la source fiable dans Git. De plus, à partir de la version 1.7.0, le mode multidépôt de Config Sync fournit un webhook d'admission qui refuse le transfert des modifications en conflit vers les clusters opérationnels. Cela permet une meilleure rétroaction de la part des utilisateurs lors de tentatives de modifications manuelles, plutôt que de les autoriser et de corriger les modifications en mode silencieux.

De plus, ce webhook d'admission empêche la modification manuelle des métadonnées et des annotations Config Sync, ce qui entraînerait des erreurs dans la configuration du webhook d'admission ou des rapprochements.

Activer le webhook d'admission dans les dépôts d'espaces de noms

Le webhook d'admission qui refuse le transfert de modifications incompatibles vers les clusters actifs est installé uniquement lorsque Config Sync est configuré en mode multidépôt. Par défaut, le webhook ne protège que le dépôt racine. Les dépôts d'espaces de noms ne sont pas protégés par le webhook, car le rapprochement Config Sync pour chaque dépôt d'espaces de noms ne dispose pas des autorisations nécessaires pour lire ou mettre à jour les objets ValidatingWebhookConfiguration au niveau du cluster.

Cette absence d'autorisation génère une erreur dans les journaux des rapprochements d'espaces de noms qui ressemble à ceci :

  Failed to update admission webhook: KNV2013: applying changes to admission webhook: Insufficient permission. To fix, make sure the reconciler has sufficient permissions.: validatingwebhookconfigurations.admissionregistration.k8s.io "admission-webhook.configsync.gke.io" is forbidden: User "system:serviceaccount:config-management-system:ns-reconciler-NAMESPACE" cannot update resource "validatingwebhookconfigurations" in API group "admissionregistration.k8s.io" at the cluster scope

Cette erreur peut être ignorée si la protection webhook n'est pas nécessaire pour le dépôt d'espaces de noms. Toutefois, si vous souhaitez ajouter cette protection, procédez comme suit pour accorder cette autorisation au rapprochement pour chaque dépôt d'espaces de noms :

Pour utiliser cette méthode, effectuez les tâches suivantes :

  1. Dans le dépôt racine, déclarez une nouvelle configuration d'objet ClusterRole utilisée pour accorder une autorisation au webhook d'admission Config Sync. Cet objet ClusterRole n'a besoin d'être défini qu'une seule fois par cluster :

    # ROOT_REPO/cluster-roles/webhook-role.yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: admission-webhook-role
    rules:
    - apiGroups: ["admissionregistration.k8s.io"]
      resources: ["validatingwebhookconfigurations"]
      resourceNames: ["admission-webhook.configsync.gke.io"]
      verbs: ["get", "update"]
    
  2. Pour chaque dépôt d'espaces de noms pour lequel l'autorisation de webhook d'admission doit être accordée, déclarez une configuration ClusterRoleBinding pour accorder l'accès au webhook d'admission :

    # ROOT_REPO/NAMESPACE/sync-webhook-rolebinding.yaml
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: syncs-webhook
    subjects:
    - kind: ServiceAccount
      name: ns-reconciler-NAMESPACE
      namespace: config-management-system
    roleRef:
      kind: ClusterRole
      name: admission-webhook-role
      apiGroup: rbac.authorization.k8s.io
    

    Remplacez NAMESPACE par le nom de votre espace de noms.

  3. Effectuez un commit des modifications dans le dépôt racine :

    git add .
    git commit -m 'Providing namespace repository the permission to update the admission webhook.'
    git push
    
    
  4. Pour vérifier, utilisez kubectl pour vous assurer que les objets ClusterRole et ClusterRoleBinding ont été créés :

    kubectl get clusterrole admission-webhook-role
    kubectl get clusterrolebindings syncs-webhook
    

Arrêter et reprendre la synchronisation

Pour savoir comment arrêter la synchronisation à partir de plusieurs dépôts, consultez la section Arrêter et reprendre la synchronisation à partir de plusieurs dépôts.

Supprimer les dépôts racine et d'espace de noms

Supprimer un dépôt d'espace 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 effectuer les deux étapes suivantes pour supprimer un dépôt d'espaces de noms :

  1. Annulez la gestion ou supprimez les ressources gérées par l'objet RepoSync en suivant les instructions de dépannage.

  2. Supprimez l'objet RepoSync du dépôt Git.

Méthode de l'API Kubernetes

Si vous avez utilisé la méthode Contrôler les dépôts d'espace de noms avec l'API Kubernetes, les opérateurs d'application peuvent suivre les deux étapes suivantes pour supprimer un dépôt d'espaces de noms :

  1. Annulez la gestion ou supprimez les ressources gérées par l'objet RepoSync en suivant les instructions de dépannage.

  2. Supprimez l'objet RepoSync en exécutant la commande suivante :

    kubectl delete -f repo-sync.yaml
    

Supprimer le dépôt racine

Un administrateur central peut supprimer le dépôt racine en procédant comme suit :

  1. Annulez la gestion ou supprimez les ressources gérées par l'objet RootSync en suivant les instructions de dépannage.

  2. Supprimez l'objet RootSync en exécutant la commande suivante :

     kubectl delete -f root-sync.yaml
    

Explorer les objets RootSync et RepoSync

Les sections suivantes vous présentent différentes manières d'explorer vos objets RootSync et RepoSync.

Afficher les journaux

Pour plus d'informations sur les erreurs potentielles, vous pouvez afficher les journaux des objets RootSync et RepoSync.

Pour afficher les journaux de rapprochement RootSync, exécutez la commande suivante :

kubectl logs -n config-management-system deployment/root-reconciler CONTAINER_NAME

Remplacez CONTAINER_NAME par git-sync, reconciler ou otel-agent. Le conteneur git-sync extrait les configurations d'un dépôt Git vers un répertoire local que le conteneur de rapprochement peut lire. Le conteneur reconciler applique ces configurations au cluster. Le conteneur otel-agent est un agent OpenTelemetry qui permet de récupérer et d'exporter des métriques Config Sync.

Pour afficher les journaux du rapprochement RepoSync, exécutez la commande suivante :

kubectl logs -n config-management-system deployment/ns-reconciler-NAMESPACE CONTAINER_NAME

Remplacez l'élément suivant :

  • NAMESPACE : espace de noms dans lequel vous avez créé votre dépôt d'espaces de noms.
  • CONTAINER_NAME : git-sync, reconciler ou otel-agent.

Afficher les commits synchronisés

Vous pouvez vérifier quel commit est synchronisé avec le cluster.

Pour afficher les détails de RootSync, exécutez la commande suivante :

kubectl get rootsync root-sync -n config-management-system

Pour afficher les détails de RepoSync, exécutez la commande suivante :

kubectl get reposync repo-sync -n config-management-system

Un résultat semblable aux lignes suivantes doit s'afficher :

NAME        SOURCECOMMIT                               SYNCCOMMIT
root-sync   66882815f0ef5517df27e864fb1315e97756ab72   66882815f0ef5517df27e864fb1315e97756ab72

La valeur de la colonne SOURCECOMMIT correspond au commit provenant du dépôt Git à synchroniser avec le cluster. La valeur de la colonne SYNCCOMMIT correspond au commit actuellement déployé sur le cluster. Si les valeurs des colonnes SOURCECOMMIT et SYNCCOMMIT sont identiques, le commit attendu a bien été déployé sur le cluster.

Afficher les détails d'un objet

Pour afficher les détails des objets RootSync et RepoSync, utilisez la commande kubectl describe. Cette commande peut vous fournir des informations supplémentaires sur les erreurs potentielles.

Pour afficher les détails de l'objet RootSync, exécutez la commande suivante :

kubectl describe rootsync root-sync -n config-management-system

Pour afficher les détails de l'objet RepoSync, exécutez la commande suivante :

kubectl describe reposync repo-sync -n config-management-system

Voir si une ressource est prête

Pour savoir si les ressources synchronisées avec le cluster sont prêtes, affichez l'état de rapprochement. Par exemple, cette commande peut vous indiquer si un déploiement synchronisé est prêt à diffuser le trafic.

Pour un dépôt Git synchronisé avec le cluster, l'état de rapprochement de toutes les ressources est agrégé dans une ressource appelée ResourceGroup. Pour chaque objet RootSync ou RepoSync, un objet ResourceGroup est généré pour capturer l'ensemble de ressources appliquées au cluster et agréger leurs états.

Pour afficher l'état de rapprochement de l'objet RootSync, exécutez la commande suivante :

kubectl get resourcegroup.kpt.dev root-sync -n config-management-system -o yaml

Pour afficher l'état de rapprochement de l'objet RepoSync, exécutez la commande suivante :

kubectl get resourcegroup.kpt.dev repo-sync -n NAMESPACE -o yaml

Dans le résultat, vous pouvez voir tous les états de la ressource ResourceGroup. Par exemple, le résultat suivant indique qu'un déploiement nommé nginx-deployment est prêt :

resourceStatuses:
- group: apps
  kind: Deployment
  name: nginx-deployment
  namespace: default
  status: Current

Étape suivante