Installer Config Sync

Avec Config Sync, vous pouvez gérer les ressources Kubernetes à l'aide de fichiers, appelés configurations, stockés dans un ou plusieurs dépôts Git. Cette page vous explique comment activer et configurer Config Sync de sorte qu'il se synchronise à partir de votre dépôt racine. Config Sync est disponible si vous utilisez Anthos ou Google Kubernetes Engine (GKE).

Lorsque vous installez Config Sync à l'aide de Google Cloud Console ou de Google Cloud CLI, les API RootSync et RepoSync sont activées par défaut. Cela vous offre des fonctionnalités supplémentaires telles que la synchronisation à partir de plusieurs dépôts et la synchronisation des configurations Kustomize et Helm.

Avant de commencer

Avant d'installer Config Sync, préparez votre environnement, vos clusters et vos rôles, puis activez Anthos Config Management.

Préparer votre environnement local

Pour préparer votre environnement local, effectuez les tâches suivantes :

  1. Créez un dépôt Git ou assurez-vous d'y avoir accès. C'est ici que vous ajoutez les configurations que Config Sync synchronise. Pour en savoir plus sur la configuration de vos configurations et de votre dépôt, consultez la section Ajouter des configurations aux dépôts Git. Le dépôt que vous sélectionnez devient votre dépôt racine.
  2. Installez et initialisez Google Cloud CLI, qui fournit les commandes gcloud et nomos. Si vous utilisez Cloud Shell, Google Cloud CLI est préinstallé.

Configuration requise pour les clusters

Créez un cluster qui répond aux exigences suivantes ou assurez-vous d'y avoir accès :

Préparer votre cluster

Après avoir créé un cluster approprié, procédez comme suit :

  1. Si vous utilisez Anthos Config Management pour la première fois, activez Anthos Config Management.

  2. Accorder les rôles IAM requis à l'utilisateur qui enregistre le cluster

  3. Si vous prévoyez d'utiliser Google Cloud CLI pour configurer Config Sync, enregistrez votre cluster dans un fletet maintenant. Si vous prévoyez d'utiliser Google Cloud Console, enregistrez vos clusters lorsque vous configurez Config Sync.

Installer Config Sync

Dans les sections suivantes, vous allez autoriser Config Sync à accéder à votre dépôt. Une fois l'accès accordé, vous configurerez l'installation pour votre dépôt racine.

Accorder à Config Sync un accès en lecture seule à Git

Config Sync a besoin d'un accès en lecture seule à votre dépôt Git pour pouvoir lire les configurations validées dans le dépôt et les appliquer à vos clusters.

Si votre dépôt ne nécessite pas d'authentification pour un accès en lecture seule, vous pouvez continuer de configurer Config Sync et utiliser none comme type d'authentification. Par exemple, si vous pouvez parcourir le dépôt à l'aide d'une interface Web sans vous connecter ou que vous pouvez créer un clone du dépôt localement à l'aide de git clone sans fournir d'identifiants ni utiliser d'identifiants enregistrés, vous n'avez pas besoin de vous authentifier. Dans ce cas, vous n'avez pas besoin de créer un secret.

Cependant, la plupart des utilisateurs doivent créer des identifiants, car l'accès en lecture à leur dépôt est limité. Si des identifiants sont nécessaires, ils sont stockés dans le secret git-creds sur chaque cluster inscrit (sauf si vous utilisez un compte de service Google). Le secret doit être nommé git-creds, car il s'agit d'une valeur fixe.

Config Sync accepte les mécanismes d'authentification suivants :

  • Paire de clés SSH
  • cookiefile
  • Jeton
  • Compte de service Google (dépôts Cloud Source Repositories uniquement)

Le mécanisme choisi dépend des éléments compatibles avec votre dépôt. En règle générale, nous vous recommandons d'utiliser une paire de clés SSH. GitHub et Bitbucket permettent tous deux d'utiliser une paire de clés SSH. Toutefois, si vous utilisez un dépôt dans Cloud Source Repositories, nous vous recommandons d'utiliser plutôt un compte de service Google, car le processus est plus simple. Si votre organisation héberge votre dépôt et que vous ne savez pas quelles méthodes d'authentification sont compatibles, contactez votre administrateur.

Paire de clés SSH

Une paire de clés SSH se compose de deux fichiers : une clé publique et une clé privée. La clé publique possède généralement une extension .pub.

Pour utiliser une paire de clés SSH, procédez comme suit :

  1. Créez une paire de clés SSH pour permettre à Config Sync de s'authentifier auprès de votre dépôt Git. Cette étape est nécessaire si vous devez vous authentifier auprès du dépôt pour le cloner ou lire ses données. Ignorez cette étape si un administrateur de sécurité vous fournit une paire de clés. Vous pouvez utiliser une seule paire de clés pour tous les clusters ou une paire de clés par cluster, en fonction de vos exigences en matière de sécurité et de conformité.

    La commande suivante crée une clé RSA de 4 096 bits. Les valeurs inférieures ne sont pas recommandées :

    ssh-keygen -t rsa -b 4096 \
    -C "GIT_REPOSITORY_USERNAME" \
    -N '' \
    -f /path/to/KEYPAIR_FILENAME
    

    Remplacez les éléments suivants :

    • GIT_REPOSITORY_USERNAME : nom d'utilisateur avec lequel vous souhaitez que Config Sync s'authentifie auprès du dépôt
    • /path/to/KEYPAIR_FILENAME : chemin d'accès à la paire de clés

    Si vous utilisez un hôte de dépôt Git tiers tel que GitHub ou si vous souhaitez employer un compte de service avec Cloud Source Repositories, nous vous recommandons d'utiliser un compte distinct.

  2. Configurez votre dépôt pour qu'il reconnaisse la clé publique que vous venez de créer. Reportez-vous à la documentation de votre fournisseur d'hébergement Git. Pour plus de commodité, nous incluons les instructions suivantes qui sont propres à certains fournisseurs d'hébergement Git couramment utilisés :

  3. Ajoutez la clé privée à un nouveau secret dans le cluster :

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
    

    Remplacez /path/to/KEYPAIR_PRIVATE_KEY_FILENAME par le nom de la clé privée (celle qui ne comporte pas le suffixe .pub).

  4. Supprimez la clé privée du disque local ou protégez-la.

  5. Lorsque vous configurez Config Sync et ajoutez l'URL de votre dépôt Git, utilisez le protocole SSH. Si vous utilisez un dépôt dans Cloud Source Repositories, vous devez utiliser le format suivant pour saisir votre URL :

    ssh://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME
    

    Remplacez les éléments suivants :

    • EMAIL : votre nom d'utilisateur Google Cloud
    • PROJECT_ID : ID du projet Google Cloud dans lequel se trouve le dépôt
    • REPO_NAME : nom du dépôt

Fichier de cookie

Le processus d'acquisition d'un cookiefile dépend de la configuration de votre dépôt. Pour obtenir un exemple, consultez la section Générer des identifiants statiques dans la documentation de Cloud Source Repositories. Les identifiants sont généralement stockés dans le fichier .gitcookies de votre répertoire d'accueil ou peuvent vous être fournis par un administrateur de sécurité.

Pour utiliser un cookiefile, procédez comme suit :

  1. Après avoir créé et obtenu le cookiefile, ajoutez-le à un nouveau secret dans le cluster.

    Si vous n'utilisez pas de proxy HTTPS, créez le secret à l'aide de la commande suivante :

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-file=cookie_file=/path/to/COOKIEFILE
    

    Si vous devez utiliser un proxy HTTPS, ajoutez-le au secret avec cookiefile à l'aide de la commande suivante :

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-file=cookie_file=/path/to/COOKIEFILE \
     --from-literal=https_proxy=HTTPS_PROXY_URL
    

    Remplacez les éléments suivants :

    • /path/to/COOKIEFILE : chemin d'accès et nom de fichier appropriés
    • HTTPS_PROXY_URL : URL du proxy HTTPS à utiliser lors de la communication avec le dépôt Git
  2. Protégez le contenu du cookiefile si vous en avez toujours besoin localement. Dans le cas contraire, supprimez-le.

Jeton

Si votre organisation n'autorise pas l'utilisation de clés SSH, vous pouvez utiliser un jeton. Avec Config Sync, vous pouvez utiliser les jetons d'accès personnels (PAT) de GitHub, les PAT ou clés de déploiement de GitLab, ou encore le mot de passe d'application de Bitbucket comme jeton.

Pour créer un secret à l'aide de votre jeton, procédez comme suit :

  1. Créez un jeton à l'aide de GitHub, GitLab ou Bitbucket :

  2. Après avoir créé et obtenu le jeton, ajoutez-le à un nouveau secret dans le cluster.

    Si vous n'utilisez pas de proxy HTTPS, créez le secret à l'aide de la commande suivante :

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
      --namespace="config-management-system" \
      --from-literal=username=USERNAME \
      --from-literal=token=TOKEN
    

    Remplacez les éléments suivants :

    • USERNAME : nom d'utilisateur que vous souhaitez utiliser
    • TOKEN : jeton que vous avez créé à l'étape précédente

    Si vous devez utiliser un proxy HTTPS, ajoutez-le au secret avec username et token à l'aide de la commande suivante :

    kubectl create ns config-management-system && \
    kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=username=USERNAME \
      --from-literal=token=TOKEN \
     --from-literal=https_proxy=HTTPS_PROXY_URL
    

    Remplacez les éléments suivants :

    • USERNAME : nom d'utilisateur que vous souhaitez utiliser
    • TOKEN : jeton que vous avez créé à l'étape précédente
    • HTTPS_PROXY_URL : URL du proxy HTTPS à utiliser lors de la communication avec le dépôt Git
  3. Protégez le jeton si vous en avez toujours besoin en local. Dans le cas contraire, supprimez-le.

Compte de service Google

Si votre dépôt se trouve dans Cloud Source Repositories, vous pouvez autoriser Config Sync à y accéder dans le même projet que votre cluster géré à l'aide d'un compte de service Google.

Pour utiliser un dépôt dans Cloud Source Repositories en tant que dépôt Config Sync, procédez comme suit :

  1. Récupérez votre URL Cloud Source Repositories :

    1. Répertoriez tous les dépôts :

      gcloud source repos list
      
    2. À partir du résultat, copiez l'URL du dépôt que vous souhaitez utiliser : Exemple :

      REPO_NAME  PROJECT_ID  URL
      my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr
      

      Vous devez utiliser cette URL lorsque vous configurez Config Sync. Si vous configurez Config Sync à l'aide de Google Cloud Console, ajoutez l'URL dans le champ URL. Si vous configurez Config Sync à l'aide de Google Cloud CLI, vous ajoutez l'URL au champ syncRepo de votre fichier de configuration.

  2. Lorsque vous configurez Config Sync, sélectionnez le type d'authentification approprié. Le type d'authentification que vous devez choisir dépend du type de cluster dont vous disposez et de la manière dont vous avez activé Workload Identity.

    • Workload Identity activé : utilisez cette méthode si GKE Workload Identity est activé ou si vous utilisez Workload Identity. Si vous utilisez Workload Identity du parc, vous pouvez utiliser cette méthode d'authentification pour les clusters GKE et non-GKE.

    • Workload Identity non activé : vous ne pouvez utiliser la méthode que pour les clusters GKE.

    Workload Identity activé

    1. Si nécessaire, créez un compte de service. Assurez-vous que le compte de service dispose d'un accès en lecture à Cloud Source Repositories en lui attribuant le rôle source.reader.

    2. Si vous configurez Config Sync à l'aide de Google Cloud Console, sélectionnez Workload Identity comme type d'authentification, puis ajoutez l'adresse e-mail de votre compte de service.

      Si vous configurez Config Sync à l'aide de Google Cloud CLI, ajoutez gcpserviceaccount en tant que secretType, puis ajoutez l'adresse e-mail de votre compte de service à gcpServiceAccountEmail.

    3. Après avoir configuré Config Sync, créez uneliaison de stratégies IAM entre le compte de service Kubernetes et le compte de service Google. Le compte de service Kubernetes n'est créé que lorsque vous configurez Config Sync pour la première fois.

      Si vous utilisez des clusters enregistrés auprès d'un parc, vous ne devez créer la liaison de stratégie qu'une seule fois par parc. Tous les clusters enregistrés dans un parc partagent le même pool Workload Identity. Avec le concept d'uniformité du parc, si vous ajoutez la stratégie IAM à votre compte de service Kubernetes dans un cluster, le compte de service Kubernetes du même espace de noms sur les autres clusters d'un même parc bénéficient également de la même stratégie IAM.

      Cette liaison permet au compte de service Config Sync Kubernetes de fonctionner en tant que compte de service Google :

      gcloud iam service-accounts add-iam-policy-binding \
         --role roles/iam.workloadIdentityUser \
         --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
         GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
      

      Remplacez les éléments suivants :

      • PROJECT_ID : si vous utilisez Workload Identity de GKE, ajoutez l'ID de projet de votre organisation.

        Si vous utilisez Workload Identity de votre parc, vous pouvez utiliser deux ID de projet différents. Dans serviceAccount:PROJECT_ID, ajoutez l'ID de projet du parc dans lequel votre cluster est enregistré. Dans GSA_NAME@PROJECT_ID, ajoutez un ID de projet pour tout projet disposant d'un accès en lecture au dépôt dans Cloud Source Repositories.

      • KSA_NAME : compte de service Kubernetes pour le rapprochement. Pour les dépôts racines, si le nom de l'objet RootSync est root-sync, KSA_NAME est root-reconciler. Sinon, il est défini sur root-reconciler-ROOT_SYNC_NAME.

        Pour les dépôts d'espaces de noms, si le nom de l'objet RepoSync est repo-sync, KSA_NAME est ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME.

      • GSA_NAME : compte de service Google personnalisé que vous souhaitez utiliser pour vous connecter à Cloud Source Repositories. Assurez-vous que le compte de service Google que vous sélectionnez dispose du rôle source.reader.

    Workload Identity non activé

    Si vous configurez Config Sync à l'aide de Google Cloud Console, sélectionnez Google Cloud Repository comme type d'authentification.

    Si vous configurez Config Sync à l'aide de Google Cloud CLI, ajoutez gcenode comme secretType.

    La sélection de Google Cloud Repository ou de gcenode vous permet d'utiliser le compte de service Compute Engine par défaut. Par défaut, le compte de service Compute Engine par défaut PROJECT_ID-compute@developer.gserviceaccount.com dispose d'un accès source.reader au dépôt du même projet. Toutefois, si Cloud Source Repositories se trouve dans un projet différent de celui de votre cluster, vous devez accorder au compte de service Compute Engine par défaut du projet du cluster le rôle source.reader dans le projet de Cloud Source Repositories.

    Vous pouvez ajouter le rôle source.reader à l'aide de la commande suivante :

    gcloud projects add-iam-policy-binding PROJECT_ID \
      --member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
      --role roles/source.reader
    

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de projet de votre organisation
    • PROJECT_NUMBER : numéro de projet de votre organisation

    Vous ne pouvez pas modifier les niveaux d'accès après la création d'un pool de nœud. Toutefois, vous pouvez créer un autre pool de nœuds avec le niveau d'accès approprié tout en utilisant le même cluster. Le niveau d'accès par défaut gke-default n'inclut pas cloud-source-repos-ro.

Configurer Config Sync

Dans cette section, vous allez configurer les paramètres de votre dépôt racine. Google Cloud Console vous guide tout au long du processus d'installation et automatise un grand nombre de ces étapes. Vous pouvez également utiliser Google Cloud CLI pour terminer l'installation.

Lorsque vous installez Config Sync à l'aide de Google Cloud Console ou de Google Cloud CLI, vous ne pouvez pas utiliser ultérieurement les commandes kubectl pour modifier votre configuration.

Console

Enregistrer vos clusters

Pour utiliser Config Management, vous devez d'abord enregistrer vos clusters. L'enregistrement de vos clusters leur permet de partager un ensemble commun de configurations et de règles.

Pour enregistrer vos clusters, procédez comme suit :

  1. Dans Cloud Console :

    Cette page présente les clusters actuellement enregistrés et configurés, et vous permet de commencer à enregistrer de nouveaux clusters.

  2. Cliquez sur Nouvelle configuration.

  3. Sur la page Sélectionner des clusters enregistrés pour Config Management, localisez le tableau Clusters non enregistrés de ce projet, puis recherchez le cluster que vous souhaitez enregistrer.

  4. Cliquez sur Enregistrer en regard du cluster que vous souhaitez enregistrer.

    Une fois le cluster enregistré, il apparaît dans la table Sélectionner des clusters enregistrés pour Config Management.

Installer Config Sync

Une fois que vous avez enregistré vos clusters, vous pouvez continuer à installer et configurer Config Sync.

Pour installer Config Sync, procédez comme suit :

  1. Sur la page Sélectionner des clusters enregistrés pour Config Management, sélectionnez les clusters que vous souhaitez configurer, puis cliquez sur Suivant.

  2. Si vous souhaitez installer Policy Controller, laissez la case Activer Policy Controller cochée et cliquez sur Suivant.

  3. Dans la liste déroulante Dépôt, sélectionnez Utiliser l'exemple Google ou Personnalisé.

    Exemple Google

    Sélectionnez Utiliser l'exemple Google pour utiliser l'exemple de dépôt Google. Ce dépôt est prérempli avec des contraintes CIS. Config Sync synchronise ces contraintes avec votre cluster, et Policy Controller les applique.

    Pour sélectionner cette option, vous devez installer Policy Controller, installer la bibliothèque de modèles de contrainte Policy Controller et activer les contraintes référentielles. Ces options de Policy Controller sont activées par défaut.

    Personnalisé

    Sélectionnez Personnalisé pour utiliser votre propre dépôt Git, puis configurez les champs suivants :

    1. Dans le champ URL, saisissez l'URL du dépôt Git à utiliser comme source fiable. Saisissez les URL à l'aide du protocole HTTPS ou SSH. Exemple :https://github.com/GoogleCloudPlatform/anthos-config-management-samples Si vous prévoyez d'utiliser SSH en tant que type d'authentification, saisissez votre URL avec le protocole SSH. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS.

    2. Cliquez sur Afficher les options avancées.

    3. Dans la liste déroulante Type d'authentification, sélectionnez l'une des options suivantes :

      • Aucune : n'utilisez aucune authentification
      • SSH : utilisez une paire de clés SSH.
      • Cookiefile : utilisez un fichier cookiefile.
      • Jeton : utilisez un jeton.
      • Google Cloud Repository : 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.
      • Workload Identity : utilisez un compte de service Google pour accéder à un dépôt Cloud Source Repositories. Vous ne pouvez sélectionner Workload Identity que lorsque vous utilisez des clusters GKE avec Workload Identity activé. L'intégration à l'identité de charge de travail de parc pour les autres clusters Anthos n'est pas disponible. Lorsque vous sélectionnez Workload Identity, vous devez ajouter l'adresse e-mail de votre compte de service Google. Exemple : acm@PROJECT_ID.iam.gserviceaccount.com. Si vous sélectionnez ce type d'authentification, vous devez également créer une liaison de stratégie IAM une fois la configuration de Config Sync terminée. Pour en savoir plus, consultez l'onglet "Comptes de service Google" de la section Accorder à Config Sync un accès en lecture seule à Git.
    4. Suivez les instructions dans Google Cloud Console pour accorder à Config Sync un accès en lecture seule à Git, puis cliquez sur Continuer.

    5. Facultatif : dans le champ Branche, saisissez la branche du dépôt à partir de laquelle s'effectue la synchronisation. La branche par défaut est la branche principale.

    6. Facultatif : dans le champ Tag/Commit, saisissez la révision Git (tag ou valeur de hachage) à extraire. La valeur par défaut est HEAD.

    7. (Facultatif) Dans le champ Répertoire de configuration, ajoutez le chemin d'accès du répertoire à partir duquel effectuer la synchronisation, par rapport à la racine du dépôt Git. Tous les sous-répertoires du répertoire que vous spécifiez sont inclus et synchronisés avec le cluster. La valeur par défaut est le répertoire racine du dépôt.

    8. Facultatif : dans le champ Délai entre les synchronisations, saisissez le délai en secondes entre les synchronisations consécutives. La valeur par défaut est de 15 secondes.

    9. Facultatif : dans le champ Proxy Git, saisissez l'URL du proxy HTTPS à utiliser lors de la communication avec le dépôt Git. Ce champ est facultatif et, s'il est vide, aucun proxy n'est utilisé. Le proxy n'est compatible qu'avec les types d'autorisation cookiefile, none ou token.

      L'URL du proxy HTTPS est affichée en texte brut dans la ressource RootSync créée par Config Sync. Si l'URL contient des informations sensibles telles qu'un nom d'utilisateur ou un mot de passe, et que vous devez les masquer, vous pouvez laisser le proxy Git vide et ajouter l'URL du protocole HTTPS dans le même secret que celui utilisé pour l'identifiant Git. Le stockage du proxy dans le secret est possible lorsque le type d'autorisation est cookiefile ou token.

    10. Facultatif : dans la liste déroulante Format source, choisissez l'option non structuré ou hiérarchie. La valeur par défaut est non structuré. Nous vous recommandons de sélectionner non structuré, car ce format vous permet d'organiser vos configurations comme bon vous semble.

    11. Facultatif : dans la liste déroulante Version de Config Management, sélectionnez la version d'Anthos Config Management que vous souhaitez utiliser. La valeur par défaut est la version actuelle.

  4. Pour terminer l'installation, cliquez sur Terminer. Vous revenez alors à la page Config Management.

gcloud

Avant de continuer, assurez-vous d'avoir enregistré vos clusters dans un parc.

Si vous utilisez Anthos ou GKE, procédez comme suit pour configurer Config Sync avec Google Cloud CLI.

  1. Préparez la configuration en créant un nouveau fichier manifeste apply-spec.yaml ou en utilisant un fichier manifeste existant. L'utilisation d'un fichier manifeste existant vous permet de configurer votre cluster avec les mêmes paramètres que ceux utilisés par un autre cluster.

Créer un nouveau fichier manifeste

Pour configurer Config Sync avec des nouveaux paramètres pour votre cluster, créez un fichier nommé apply-spec.yaml et copiez-y le fichier YAML ci-dessous :

# apply-spec.yaml

applySpecVersion: 1
spec:
  configSync:
    # Set to true to install and enable Config Sync
    enabled: true
    # If you don't have a Git repository, omit the following fields. You
    # can configure them later.
    sourceFormat: FORMAT
    syncRepo: REPO
    syncBranch: BRANCH
    secretType: TYPE
    gcpServiceAccountEmail: EMAIL
    policyDir: DIRECTORY
    # the `preventDrift` field is supported in Anthos Config Management version 1.10.0 and later.
    preventDrift: PREVENT_DRIFT

Remplacez l'élément suivant :

  • 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.
  • REPO : ajoutez l'URL du dépôt Git à utiliser comme source fiable. Saisissez les URL à l'aide du protocole HTTPS ou SSH. Exemple :https://github.com/GoogleCloudPlatform/anthos-config-management-samples Si vous prévoyez d'utiliser SSH en tant que secretType, saisissez votre URL avec le protocole SSH. Ce champ est obligatoire. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS.
  • BRANCH : 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.
  • TYPE : l'une des options secretTypes suivantes :

    • none : n'utilisez aucune authentification
    • ssh : utilisez une paire de clés SSH.
    • cookiefile : utilisez un cookiefile
    • token : utilisez un jeton
    • gcpserviceaccount : utilisez un compte de service Google pour accéder à Cloud Source Repositories. Si vous sélectionnez ce type d'authentification, vous devez créer une liaison de stratégie IAM une fois la configuration de Config Sync terminée. Pour en savoir plus, consultez l'onglet "Comptes de service Google" de la section Accorder à Config Sync un accès en lecture seule à Git.
    • 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.

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

  • DIRECTORY : chemin d'accès du répertoire à synchroniser, associé à la racine du dépôt Git. Tous les sous-répertoires du répertoire que vous spécifiez sont inclus et synchronisés avec le cluster. La valeur par défaut est le répertoire racine du dépôt.

  • PREVENT_DRIFT : si la valeur est true, active le webhook d'admission Config Sync pour éviter les écarts en empêchant le transfert des modifications conflictuelles vers les clusters opérationnels. Le paramètre par défaut est false. Config Sync corrige toujours les dérives, quelle que soit la valeur de ce champ.

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

Utiliser un fichier manifeste existant

Pour configurer votre cluster avec les mêmes paramètres que ceux utilisés par un autre cluster, récupérez les paramètres d'un cluster enregistré :

 gcloud alpha container hub config-management fetch-for-apply \
     --membership=MEMBERSHIP_NAME \
     --project=PROJECT_ID \
     > CONFIG_YAML_PATH

Remplacez l'élément suivant :

  • MEMBERSHIP_NAME : nom de l'appartenance du cluster enregistré contenant les paramètres Config Sync que vous souhaitez utiliser.
  • PROJECT_ID : ID de votre projet.
  • CONFIG_YAML_PATH : chemin d'accès au fichier apply-spec.yaml contenant les paramètres récupérés du cluster

2. Appliquez le fichier apply-spec.yaml. Si vous utilisez un fichier manifeste existant, vous devez appliquer le fichier au cluster que vous souhaitez configurer avec les paramètres que vous avez récupérés dans la commande précédente :

  gcloud beta container hub config-management apply \
      --membership=MEMBERSHIP_NAME \
      --config=CONFIG_YAML_PATH \
      --project=PROJECT_ID

Remplacez les éléments suivants :

  • MEMBERSHIP_NAME : nom de l'appartenance que vous avez choisi lors de l'enregistrement de votre cluster. Vous pouvez trouver le nom avec gcloud container hub memberships list
  • CONFIG_YAML_PATH : chemin d'accès à votre fichier apply-spec.yaml
  • PROJECT_ID : ID de votre projet.

Une fois que vous avez configuré votre dépôt racine, vous pouvez éventuellement choisir de configurer la synchronisation à partir de plusieurs dépôts, y compris d'autres dépôts racines et d'autres dépôts d'espaces de noms. Ces dépôts d'espaces de noms sont utiles si vous souhaitez un dépôt contenant des configurations au niveau d'un espace de noms synchronisées avec un espace de noms particulier sur les clusters.

Vérifiez l'installation

Une fois que vous avez installé et configuré Config Sync, vous pouvez vérifier que l'installation s'est bien déroulée.

Console

Procédez comme suit :

  1. Dans Cloud Console :

  2. Dans le tableau du cluster, affichez la colonne État de Config sync. Une installation réussie présente l'état synchronisé.

gcloud

Exécutez la commande suivante :

gcloud beta container hub config-management status \
    --project=PROJECT_ID

Remplacez PROJECT_ID par l'ID de votre projet.

Une installation réussie présente l'état SYNCED. Si vous rencontrez une erreur après avoir exécuté la commande précédente, assurez-vous d'avoir bien créé le secret git-creds. Si c'est le cas, essayez d'exécuter à nouveau la commande suivante :

gcloud beta container hub config-management apply

Vous pouvez également utiliser la commande nomos status pour vérifier si Config Sync est correctement installé. Une installation valide ne présentant aucun problème affiche l'état PENDING ou SYNCED. Une installation non valide ou incomplète affiche l'état NOT INSTALLED ou NOT CONFIGURED. Le résultat comprend également les erreurs signalées.

Il est possible qu'une configuration non valide ne soit pas détectée immédiatement, par exemple un secret git-creds manquant ou incorrect. Pour connaître les étapes de dépannage, consultez l'article Objet ConfigManagement valide, mais incorrect sur la page de dépannage.

Mettre à jour Config Sync

Config Sync est mis à jour chaque fois que vous mettez à niveau Anthos Config Management. Pour en savoir plus, consultez la page Mettre à niveau Anthos Config Management.

Demandes de ressources

Récapitulatif du nombre total de demandes de ressources

Les tableaux suivants répertorient le nombre combiné de demandes de ressources pour chaque version compatible de Config Sync, en fonction des fonctionnalités que vous utilisez.

1.11

Feature CPU (m) Mémoire (Mio)
Config Sync 220 m + 80 m * (nombre d'objets RootSync et RepoSync) 600 Mi + 210 Mi * (nombre d'objets RootSync et RepoSync)
Config Sync avec le webhook d'admission activé 240 m + 80 m * (nombre d'objets RootSync et RepoSync) 700 Mi + 210 Mi * (nombre d'objets RootSync et RepoSync)
Hierarchy Controller 220 m 220 Mi

1.10

Feature CPU (m) Mémoire (Mio)
Config Sync 220 m + 80 m * (nombre d'objets RootSync et RepoSync) 600 Mi + 210 Mi * (nombre d'objets RootSync et RepoSync)
Config Sync avec le webhook d'admission activé 240 m + 80 m * (nombre d'objets RootSync et RepoSync) 620 Mi + 210 Mi * (nombre d'objets RootSync et RepoSync)
Hierarchy Controller 220 m 220 Mi

1.9

Feature CPU (m) Mémoire (Mio)
Mode par défaut (à l'aide des API RootSync et RepoSync) 240 m + 80 m * (nombre d'objets RootSync et RepoSync) 620 Mi + 210 Mi * (nombre d'objets RootSync et RepoSync)
Hierarchy Controller 220 m 220 Mi
Mode autre que celui par défaut 460 m 310 Mi

Requêtes de ressources détaillées

Le tableau suivant répertorie les exigences concernant les ressources Kubernetes pour les composants de Config Sync. Pour plus d'informations, consultez la section Gérer les ressources pour les conteneurs dans la documentation de Kubernetes.

1.11

Nom du déploiement Demande de processeur (m) par instance dupliquée Demande de mémoire (Mi) par instance dupliquée Dépôts uniques ou multiples
git-importer 450 300 Unique
monitor Par défaut1 Par défaut Unique
resource-group-controller-manager 100+par défaut 50+par défaut Multi
admission-webhook2 20 100 Multi
otel-collector 200 400 Multi
reconciler-manager 50 200 Multi
reconciler (un par RootSync et RepoSync) 80+par défaut 200+par défaut Multi
hnc-controller-manager 100+par défaut 150+par défaut Hierarchy Controller
gke-hc-controller-manager 100+par défaut 50+par défaut Hierarchy Controller

1 La requête par défaut des ressources utilise une requête de processeur de 10 milliCPU (mCPU) et une requête mémoire de 10 Mi.

2 Le webhook d'admission comporte deux instances dupliquées. Par conséquent, si vous souhaitez calculer le nombre total de requêtes de ressources, vous devez doubler la valeur. Avant la version 1.10.0 d'Anthos Config Management, le webhook d'admission est activé par défaut. À partir de la version 1.10.0 d'Anthos Config Management, le webhook d'admission est désactivé par défaut.

1.10

Nom du déploiement Demande de processeur (m) par instance dupliquée Demande de mémoire (Mi) par instance dupliquée Dépôts uniques ou multiples
git-importer 450 300 Unique
monitor Par défaut1 Par défaut Unique
resource-group-controller-manager 100+par défaut 50+par défaut Multi
admission-webhook2 20 20 Multi
otel-collector 200 400 Multi
reconciler-manager 20 120 Multi
reconciler (un par RootSync et RepoSync) 80+par défaut 200+par défaut Multi
hnc-controller-manager 100+par défaut 150+par défaut Hierarchy Controller
gke-hc-controller-manager 100+par défaut 50+par défaut Hierarchy Controller

1 La requête par défaut des ressources utilise une requête de processeur de 10 et une requête mémoire de 10 Mi.

2 Le webhook d'admission comporte deux instances dupliquées. Par conséquent, si vous souhaitez calculer le nombre total de requêtes de ressources, vous devez doubler la valeur. Avant la version 1.10.0 d'Anthos Config Management, le webhook d'admission est activé par défaut. À partir de la version 1.10.0 d'Anthos Config Management, le webhook d'admission est désactivé par défaut.

1.9

Nom du déploiement Demande de processeur (m) par instance dupliquée Demande de mémoire (Mi) par instance dupliquée Dépôts uniques ou multiples
git-importer 450 300 Unique
monitor Par défaut1 Par défaut Unique
resource-group-controller-manager 100+par défaut 50+par défaut Multi
admission-webhook2 20 20 Multi
otel-collector 200 400 Multi
reconciler-manager 20 120 Multi
reconciler (un par RootSync et RepoSync) 80+par défaut 200+par défaut Multi
hnc-controller-manager 100+par défaut 150+par défaut Hierarchy Controller
gke-hc-controller-manager 100+par défaut 50+par défaut Hierarchy Controller

1 La requête par défaut des ressources utilise une requête de processeur de 10 et une requête mémoire de 10 Mi.

2 Le webhook d'admission comporte deux instances dupliquées. Par conséquent, si vous souhaitez calculer le nombre total de requêtes de ressources, vous devez doubler la valeur.

Étape suivante