Installer Config Sync

Avec Config Sync, vous pouvez gérer les ressources Kubernetes à l'aide de fichiers, appelés configurations, qui sont stockés dans une source fiable. Config Sync est compatible avec les dépôts Git, les images OCI et les charts Helm comme sources de référence. 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éer une source fiable ou 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 la source fiable, consultez l'un des guides suivants :
  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 ou d'utiliser des clusters en dehors de Google Cloud, assurez-vous maintenant que vos clusters GKE ou vos clusters en dehors de Google Cloud sont enregistrés dans un parc. Si vous prévoyez d'utiliser la console Google Cloud, vous pouvez enregistrer des clusters GKE lorsque vous configurez Config Sync.

Installer Config Sync

Dans les sections suivantes, vous allez autoriser Config Sync à accéder à l'une des sources suivantes:

Une fois l'accès accordé, vous pouvez configurer Config Sync.

Accorder l'accès à 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.

      Config Sync utilise Workload Identity par défaut si le cluster est enregistré dans un parc. Assurez-vous que Workload Identity de votre parc est activé sur vos clusters enregistrés. Pour en savoir plus, consultez Enregistrer un cluster. Si votre cluster se trouve dans un projet différent du projet hôte du parc, vous devez lier le compte de service Google au compte de service Kubernetes du projet hôte du parc.

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

Accorder à Config Sync un accès en lecture seule à l'importation des conversions hors connexion

Config Sync a besoin d'un accès en lecture seule à votre image OCI stockée dans Artifact Registry pour pouvoir lire les configurations incluses dans l'image et les appliquer à vos clusters.

Si votre image 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 votre image est publique et accessible par tous les internautes, vous n'avez pas besoin de vous authentifier.

Cependant, la plupart des utilisateurs doivent créer des identifiants pour accéder aux images restreintes. Pour les images avec accès en lecture restreint, vous pouvez utiliser un compte de service Google pour l'authentification avec gcenode ou gcpserviceaccount comme type d'authentification.

gcenode

Si votre cluster est un cluster GKE et que Workload Identity n'est pas activé, vous pouvez utiliser gcenode comme type d'authentification. Config Sync utilise le compte de service Compute Engine par défaut. Vous devez accorder à votre compte de service Compute Engine l'accès à Artifact Registry.

  1. Enregistrez le numéro de projet dans une variable d'environnement en exécutant la commande suivante :

    export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID \
    --format=json | jq -r .projectNumber)

    Remplacez PROJECT_ID par votre ID de projet.

  2. Accordez au compte de service Compute Engine l'autorisation d'accès en lecture à Artifact Registry en exécutant la commande suivante:

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

gcpserviceaccount

Si votre cluster utilise GKE Workload Identity ou un parc Workload Identity, vous pouvez utiliser gcpserviceaccount comme type d'authentification.

  1. Si vous ne disposez pas encore d'un compte de service, créez-en un et accordez-lui le rôle IAM Artifact Registry (roles/artifactregistry.reader).

  2. Créez une liaison de stratégie IAM entre le compte de service Kubernetes et le compte de service Google en exécutant la commande suivante :

    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 GKE Workload Identity, il s'agit de l'ID de projet de votre organisation. Si vous utilisez Workload Identity de votre parc, vous pouvez utiliser deux ID de projet différents. Pour serviceAccount:PROJECT_ID, ajoutez l'ID de projet du parc dans lequel votre cluster est enregistré. Pour 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 racine, si le nom RootSync est root-sync, ajoutez root-reconciler. Sinon, ajoutez root-reconciler-ROOT_SYNC_NAME.
      • Pour les dépôts d'espaces de noms, si le nom RepoSync est repo-sync, ajoutez ns-reconciler-NAMESPACE. Sinon, ajoutez ns-reconciler-NAMESPACE-REPO_SYNC_NAME.
    • GSA_NAME: compte de service Google personnalisé que vous souhaitez utiliser pour vous connecter à Artifact Registry. Le compte de service doit disposer du rôle IAM "Lecteur Artifact Registry" (roles/artifactregistry.reader).

Accorder l'accès à Config Sync en lecture seule à Helm

Config Sync a besoin d'un accès en lecture seule à votre dépôt Helm pour pouvoir lire les graphiques Helm de votre dépôt et les installer dans vos clusters.

Si votre dépôt ne nécessite pas d'authentification pour l'accès en lecture seule, vous pouvez continuer à configurer Config Sync et utiliser none comme type d'authentification. Par exemple, si votre dépôt Helm est public et accessible par tous les internautes, vous n'avez pas besoin de vous authentifier.

Toutefois, la plupart des utilisateurs doivent créer des identifiants pour accéder aux dépôts Helm privés. Config Sync accepte les mécanismes d'authentification suivants :

  • token
  • gcenode

  • gcpserviceaccount

token

Créez un secret avec un nom d'utilisateur et un mot de passe de dépôt Helm:

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

Remplacez les éléments suivants :

  • SECRET_NAME: nom que vous souhaitez attribuer au secret.
  • USERNAME: nom d'utilisateur du dépôt Helm.
  • PASSWORD: mot de passe du dépôt Helm

Lorsque vous configurez Config Management Operator, vous utiliserez le nom du secret que vous avez choisi pour spec.helm.secretRef.name.

gcenode

Si votre cluster est un cluster GKE et que Workload Identity n'est pas activé, vous pouvez utiliser gcenode comme type d'authentification. Config Sync utilise le compte de service Compute Engine par défaut. Vous devez accorder à votre compte de service Compute Engine l'accès à Artifact Registry. Vous devrez peut-être accorder le niveau d'accès storage-ro pour accorder l'autorisation en lecture seule pour extraire des images.

  1. Enregistrez le numéro du projet dans une variable d'environnement:

    export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format='value(projectNumber)')

    Remplacez PROJECT_ID par votre ID de projet.

  2. Accordez au compte de service Compute Engine l'autorisation de lecture sur Artifact Registry:

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

gcpserviceaccount

Si vous stockez votre graphique Helm dans Artifact Registry et que votre cluster utilise GKE Workload Identity ou Workload Identity de Cloud Identity, vous pouvez utiliser gcpserviceaccount comme type d'authentification.

  1. Si vous ne disposez pas encore d'un compte de service, créez-en un et accordez-lui le rôle IAM Artifact Registry (roles/artifactregistry.reader). Pour en savoir plus sur les rôles et les autorisations Artifact Registry, consultez la page Configurer les rôles et les autorisations pour Artifact Registry.

  2. Créez une liaison de stratégie IAM entre le compte de service Kubernetes et le compte de service Google en exécutant la commande suivante :

    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 GKE Workload Identity, il s'agit de l'ID de projet de votre organisation. Si vous utilisez Workload Identity de votre parc, vous pouvez utiliser deux ID de projet différents. Pour serviceAccount:PROJECT_ID, ajoutez l'ID de projet du parc dans lequel votre cluster est enregistré. Pour 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 racine, si le nom RootSync est root-sync, ajoutez root-reconciler. Sinon, ajoutez root-reconciler-ROOT_SYNC_NAME.
      • Pour les dépôts d'espaces de noms, si le nom RepoSync est repo-sync, ajoutez ns-reconciler-NAMESPACE. Sinon, ajoutez ns-reconciler-NAMESPACE-REPO_SYNC_NAME.
    • GSA_NAME: compte de service Google personnalisé que vous souhaitez utiliser pour vous connecter à Artifact Registry. Le compte de service doit disposer du rôle IAM "Lecteur Artifact Registry" (roles/artifactregistry.reader).

Configurer Config Sync

Dans cette section, vous allez configurer les paramètres de votre dépôt racine. Si vous effectuez une synchronisation avec un dépôt Git, vous pouvez utiliser la console Google Cloud pour vous guider tout au long du processus d'installation et automatiser certaines étapes.

Lorsque vous installez Config Sync à l'aide de la console Google Cloud ou de Google Cloud CLI, Config Sync crée automatiquement un objet RootSync nommé root-sync. Vous pouvez utiliser les commandes kubectl pour modifier root-sync et ajouter des configurations Config Sync. Pour en savoir plus, consultez Configurer Config Sync avec des commandes kubectl.

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 la console Google Cloud :

    • Si vous utilisez Google Kubernetes Engine, accédez à la page Configuration de GKE dans la section Configuration et règles.

      Accéder à Config Management

    • Si vous utilisez Anthos, accédez à la page Configuration d'Anthos dans la section Configuration et règles.

      Accéder à Config Management

  2. Cliquez sur Installer Config Sync.
  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 contient des bundles Policy Controller.

    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.

    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.

  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 les nouveaux paramètres de votre cluster, créez un fichier nommé apply-spec.yaml et copiez-y le fichier YAML suivant.

Vous pouvez définir tous les champs spec.configSync facultatifs dont vous avez besoin lorsque vous créez votre fichier manifeste, puis utiliser les commandes kubectl pour la configuration. Vous ne pouvez également définir le champ spec.configSync.enabled que sur true et omettre les champs facultatifs. Vous pourrez ensuite utiliser des commandes kubectl pour créer des objets RootSync ou RepoSyncs supplémentaires que vous pourrez gérer entièrement à l'aide des commandes kubectl.

# apply-spec.yaml

applySpecVersion: 1
spec:
  configSync:
    # Set to true to install and enable Config Sync
    enabled: true
    # If you don't have a source of truth yet, omit the
    # following fields. You can configure them later.
    sourceType: SOURCE_TYPE
    sourceFormat: FORMAT
    syncRepo: REPO
    syncBranch: BRANCH
    secretType: SECRET_TYPE
    gcpServiceAccountEmail: EMAIL
    policyDir: DIRECTORY
    preventDrift: PREVENT_DRIFT

Remplacez les éléments suivants :

  • SOURCE_TYPE: ajoutez git pour effectuer la synchronisation à partir d'un dépôt Git, oci pour effectuer la synchronisation à partir d'une image OCI ou helm pour la synchronisation à partir d'un graphique Helm. Si aucune valeur n'est spécifiée, la valeur par défaut est git.
  • 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 de la source de référence. Les URL des dépôts Git et Helm utilisent le 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.

    Les URL OCI utilisent le format suivant : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Par défaut, l'image est extraite du tag latest, mais vous pouvez extraire les images via TAG ou DIGEST à la place. Spécifiez TAG ou DIGEST dans PACKAGE_NAME:

    • Pour extraire par TAG : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
    • Pour extraire par DIGEST : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

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

  • SECRET_TYPE : l'une des options secretTypes suivantes :

    git

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

    OCI

    • none : n'utiliser aucune authentification
    • gcenode: utilisez le compte de service Compute Engine par défaut pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.
    • gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.

    helm

    • token : utilisez un jeton
    • gcenode: utilisez le compte de service Compute Engine par défaut pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.
    • gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.

  • 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 fleet config-management fetch-for-apply \
    --membership=MEMBERSHIP_NAME \
    --project=PROJECT_ID \
    > CONFIG_YAML_PATH

Remplacez les éléments suivants :

  • 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 fleet config-management apply \
      --membership=MEMBERSHIP_NAME \
      --config=CONFIG_YAML_PATH \
      --project=PROJECT_ID

Remplacez les éléments suivants :

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

Après avoir terminé la configuration de votre dépôt racine, vous pouvez choisir de configurer la synchronisation depuis plusieurs dépôts, y compris d'autres dépôts racine et d'espaces de noms. Les dépôts d'espaces de noms sont utiles si vous souhaitez qu'un dépôt contenant des configurations à l'échelle d'un espace de noms se synchronise avec un espace de noms particulier sur plusieurs 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 la console Google Cloud :

    • Si vous utilisez Google Kubernetes Engine, accédez à la page Configuration de GKE dans la section Configuration et règles.

      Accéder à Config Management

    • Si vous utilisez Anthos, accédez à la page Configuration d'Anthos dans la section Configuration et règles.

      Accéder à Config Management

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

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

Caractéristique CPU (m) Mémoire (Mi)
Config Sync 330 m + 80 m * (nombre d'objets RootSync et RepoSync)1 850 Mi + 600 Mi * (nombre d'objets RootSync et RepoSync)
Config Sync avec le webhook d'admission activé 350 m + 80 m * (nombre d'objets RootSync et RepoSync)1 1050 Mi + 600 Mi * (nombre d'objets RootSync et RepoSync)
Hierarchy Controller 200 m 200 Mi

1 Si le type de source RootSync et RepoSync est défini sur helm, la requête de processeur est de 120 m * (nombre d'objets RootSync et RepoSync).

1.14

Caractéristique CPU (m) Mémoire (Mi)
Config Sync 330 m + 80 m * (nombre d'objets RootSync et RepoSync)1 850 Mi + 600 Mi * (nombre d'objets RootSync et RepoSync)
Config Sync avec le webhook d'admission activé 350 m + 80 m * (nombre d'objets RootSync et RepoSync)1 1050 Mi + 600 Mi * (nombre d'objets RootSync et RepoSync)
Hierarchy Controller 200 m 200 Mi

1 Si le type de source RootSync et RepoSync est défini sur helm, la requête de processeur est de 120 m * (nombre d'objets RootSync et RepoSync).

1.13

Caractéristique CPU (m) Mémoire (Mi)
Config Sync 330 m + 80 m * (nombre d'objets RootSync et RepoSync) 850 Mi + 600 Mi * (nombre d'objets RootSync et RepoSync)
Config Sync avec le webhook d'admission activé 350 m + 80 m * (nombre d'objets RootSync et RepoSync) 1050 Mi + 600 Mi * (nombre d'objets RootSync et RepoSync)
Hierarchy Controller 200 m 200 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.15

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 400 Single
monitor Par défaut1 Par défaut Single
resource-group-controller-manager 110 300 Multi
admission-webhook2 10 100 Multi
otel-collector 200 400 Multi
reconciler-manager 20 150 Multi
reconciler (un par RootSync et RepoSync) 80 + valeur par défaut3 600 + par défaut Multi
hnc-controller-manager 100 150 Hierarchy Controller
gke-hc-controller-manager 100 50 Hierarchy Controller

1 La requête de ressources par défaut utilise une requête de 10 milliprocesseurs (mCPU) et une demande de mémoire de 10 Mio.

2 Le webhook d'admission comporte deux instances dupliquées. Par conséquent, lorsque vous calculez le nombre total de demandes de ressources, vous devez doubler la valeur si vous utilisez le webhook d'admission. Le webhook d'admission est désactivé par défaut.

3 Si le type de source RootSync et RepoSync est défini sur helm, la requête de processeur correspond à 120 m x (nombre d'objets RootSync et RepoSync).

1.14

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 400 Single
monitor Par défaut1 Par défaut Single
resource-group-controller-manager 110 300 Multi
admission-webhook2 10 100 Multi
otel-collector 200 400 Multi
reconciler-manager 20 150 Multi
reconciler (un par RootSync et RepoSync) 80 + valeur par défaut3 600 + par défaut Multi
hnc-controller-manager 100 150 Hierarchy Controller
gke-hc-controller-manager 100 50 Hierarchy Controller

1 La requête de ressources par défaut utilise une requête de 10 milliprocesseurs (mCPU) et une demande de mémoire de 10 Mio.

2 Le webhook d'admission comporte deux instances dupliquées. Par conséquent, lorsque vous calculez le nombre total de demandes de ressources, vous devez doubler la valeur si vous utilisez le webhook d'admission. Le webhook d'admission est désactivé par défaut.

3 Si le type de source RootSync et RepoSync est défini sur helm, la requête de processeur correspond à 120 m x (nombre d'objets RootSync et RepoSync).

1.13

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 400 Single
monitor Par défaut1 Par défaut Single
resource-group-controller-manager 110 300 Multi
admission-webhook2 10 100 Multi
otel-collector 200 400 Multi
reconciler-manager 20 150 Multi
reconciler (un par RootSync et RepoSync) 80 + par défaut 600 + par défaut Multi
hnc-controller-manager 100 150 Hierarchy Controller
gke-hc-controller-manager 100 50 Hierarchy Controller

1 La requête de ressources par défaut utilise une requête de 10 milliprocesseurs (mCPU) et une demande de mémoire de 10 Mio.

2 Le webhook d'admission comporte deux instances dupliquées. Par conséquent, lorsque vous calculez le nombre total de demandes de ressources, vous devez doubler la valeur si vous utilisez le webhook d'admission. Le webhook d'admission est désactivé par défaut.

Étapes suivantes