Installer Config Sync

Avec Config Sync, vous pouvez gérer les ressources Kubernetes avec des fichiers de configuration stockés dans une source fiable. Config Sync accepte les dépôts Git, les images OCI et les charts Helm en tant que source fiable. 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 avec Google Kubernetes Engine (GKE) Enterprise Edition.

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, assurez-vous de répondre aux exigences du cluster et attribuez les rôles utilisateur appropriés.

Préparer votre environnement local

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

  1. Créez une source fiable 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 définition de vos configurations et de votre 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é. Si vous avez déjà installé Google Cloud CLI, installez la dernière version en exécutant la commande gcloud components update.

  3. Activez l'API GKE Enterprise

    Activez l'API GKE Enterprise

Configuration requise pour les clusters

Utilisez un cluster qui répond aux exigences suivantes ou créez-en un :

  • Le cluster est sur une plate-forme et une version compatibles avec Google Kubernetes Engine (GKE) Enterprise Edition.

  • Si vous utilisez des clusters Autopilot, Autopilot ajuste les besoins en ressources du conteneur pour répondre aux règles suivantes :

    En raison de ces règles, pour les clusters Autopilot, Config Sync :

  • (Facultatif) Workload Identity est activé sur le cluster si vous utilisez des clusters GKE. Workload Identity est la solution recommandée pour accéder aux services Google Cloud à partir des applications s'exécutant dans GKE en raison de ses propriétés de sécurité renforcée et de sa facilité de gestion. Workload Identity est activé par défaut sur les clusters Autopilot.

  • Accordez les autorisations nécessaires pour écrire les métriques afin que Config Sync puisse envoyer des métriques à Cloud Monitoring. Cette étape est obligatoire si vous souhaitez utiliser les mises à niveau automatiques.

  • Si vous souhaitez mettre à niveau automatiquement la version de Config Sync, assurez-vous que votre cluster GKE est enregistré dans une version disponible. Un cluster qui n'utilise pas un canal de publication GKE est traité comme un cluster utilisant le canal de publication stable.

  • Si vous souhaitez utiliser un cluster GKE privé, configurez Cloud NAT pour autoriser la sortie des nœuds GKE privés. Pour en savoir plus, consultez la page Exemple de configuration GKE. Vous pouvez également activer l'accès privé à Google pour vous connecter à l'ensemble des adresses IP externes utilisées par les API et services Google.

  • Si vous souhaitez utiliser un compte de service Google lorsque vous accordez à Config Sync l'accès à votre source fiable, vous devez inclure le champ d'application de lecture seule dans la section niveaux d'accès pour les nœuds du cluster pour Cloud Source Repositories.

    Vous pouvez ajouter le niveau d'accès de lecture seule en incluant cloud-source-repos-ro dans la liste --scopes spécifiée lors la création du cluster ou en utilisant le champ d'application cloud-platform au moment de la création du cluster. Exemple :

    gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform

    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.

  • Si vous avez des exigences strictes concernant le pare-feu VPC afin qu'il bloque tout trafic inutile, vous devez créer des règles de pare-feu pour autoriser le trafic suivant sur les clusters GKE publics :

    • TCP : autorisez les entrées et les sorties sur les ports 53 et 443

    • UDP : autorisez la sortie sur le port 53

    Si vous n'incluez pas ces règles, Config Sync ne se synchronise pas correctement et nomos status signale l'erreur suivante :

    Error: KNV2004: unable to sync repo Error in the git-sync container

    Vous pouvez ignorer ces étapes si vous utilisez un cluster GKE privé.

  • Vous devez exécuter Config Sync sur un pool de nœuds amd64. Les images de conteneur des composants du backend de Config Sync sont uniquement créées, distribuées et testées pour l'architecture de machine amd64. Si un composant Config Sync est planifié sur un nœud Arm, il rencontre l'erreur exec format et plante.

    Si vous disposez de nœuds Arm dans votre cluster, ajoutez un ou plusieurs nœuds amd64 à votre cluster et, si vous n'utilisez pas de cluster GKE, ajoutez un rejet à vos nœuds arm64, pour éviter de programmer des pods sur vos nœuds arm64 sans tolérance spécifique. Les nœuds arm GKE disposent déjà d'un rejet par défaut. Vous n'avez donc pas besoin d'en ajouter un.

Préparer votre cluster

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

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

  2. 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 que vos clusters GKE ou vos clusters en dehors de Google Cloud sont maintenant 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 accordez à Config Sync l'accès à l'une des sources fiables 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 de 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 (ssh)
  • Fichier de cookie (cookiefile)
  • Jeton (token)
  • Compte de service Google (gcpserviceaccount)
  • Compte de service Compute Engine par défaut (gcenode)

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.

Pour utiliser un dépôt dans Cloud Source Repositories en tant que dépôt Config Sync, procédez comme suit pour récupérer 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 la console Google Cloud, 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.

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. (Recommandé) Pour configurer la vérification des hôtes connus à l'aide de l'authentification SSH, vous pouvez ajouter la clé d'hôtes connus au champ data.known_hosts du secret git_creds. Pour désactiver la vérification known_hosts, vous pouvez supprimer le champ known_hosts du secret. Pour ajouter la clé d'hôtes connue, exécutez la commande suivante :

    kubectl edit secret git-creds \
 --namespace=config-management-system

    Ensuite, sous data, ajoutez l'entrée d'hôtes connus :

    known_hosts: KNOWN_HOSTS_KEY

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

  6. 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 et que votre cluster utilise GKE Workload Identity ou la fonctionnalité Workload Identity du parc vous pouvez autoriser Config Sync à accéder à un dépôt du même projet que votre cluster géré à l'aide d'un compte de service Google.

  1. Si vous ne disposez pas d'un compte de service, créez-en un.

  2. Attribuez le rôle IAM Lecteur Cloud Source Repositories (roles/source.reader) au compte de service Google. Pour en savoir plus sur les rôles et les autorisations de Cloud Source Repositories, consultez la page Accorder des autorisations pour afficher les dépôts.

    • Accordez une autorisation à l'échelle du projet si les mêmes autorisations s'appliquent à tous les dépôts du projet.

      gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"

    • Accordez une autorisation spécifique au dépôt lorsque vous souhaitez que les comptes de service aient différents niveaux d'accès pour chaque dépôt de votre projet.

      gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID

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

  4. Après avoir configuré Config Sync, créez une liaison 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 \
    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
    --project=PROJECT_ID

Remplacez les éléments suivants :

  • PROJECT_ID : ID de projet de l'organisation.
  • FLEET_HOST_PROJECT_ID : si vous utilisez Workload Identity de GKE, ce champ d'application est identique à PROJECT_ID. Si vous utilisez la fonctionnalité Workload Identity du parc, il s'agit de l'ID de projet du parc dans lequel votre cluster est enregistré.
  • GSA_NAME : compte de service Google personnalisé que vous souhaitez utiliser pour vous connecter à Artifact Registry. Ce compte de service doit disposer du rôle IAM Lecteur Artifact Registry (roles/artifactregistry.reader).
  • KSA_NAME : compte de service Kubernetes pour le rapprochement.
    • Pour les dépôts racine, si le nom RootSync est root-sync, utilisez root-reconciler. Sinon, utilisez root-reconciler-ROOT_SYNC_NAME. Si vous installez Config Sync à l'aide de la console Google Cloud ou de Google Cloud CLI, Config Sync crée automatiquement un objet RootSync appelé root-sync.
  • REPOSITORY : nom du dépôt
  • POLICY_FILE : fichier JSON ou YAML avec la stratégie Identity and Access Management.

Compte de service Compute Engine par défaut

Si votre dépôt se trouve dans Cloud Source Repositories et que votre cluster est GKE avec Workload Identity désactivé, vous pouvez utiliser gcenode comme type d'authentification.

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. Vous devez attribuer le rôle IAM Lecteur Cloud Source Repositories (roles/source.reader) au compte de service Compute Engine par défaut. Pour plus d'informations sur les rôles et les autorisations de Cloud Source Repositories, consultez la section Accorder des autorisations pour afficher les dépôts.

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

Remplacez PROJECT_ID par l'ID de projet de votre organisation et PROJECT_NUMBER par le numéro de projet de votre organisation.

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

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. Config Sync accepte les mécanismes d'authentification suivants :

  • Compte de service Kubernetes (k8sserviceaccount)
  • Compte de service Google (gcpserviceaccount)

  • Compte de service Compute Engine par défaut (gcenode)

Compte de service Kubernetes

Si vous stockez votre image OCI dans Artifact Registry et que votre cluster utilise GKE Workload Identity ou la fonctionnalité Workload Identity du parc, vous pouvez utiliserk8sserviceaccount comme type d'authentification dans les versions 1.17.2 et ultérieures. Cette option est recommandée plutôt que gcpserviceaccount en raison de son processus de configuration simplifié.

  1. Attribuez le rôle IAM de lecteur Artifact Registry (roles/artifactregistry.reader) au compte de service Kubernetes avec le pool Workload Identity. Pour en savoir plus sur les rôles et les autorisations d'Artifact Registry, consultez la page Configurer les rôles et les autorisations pour Artifact Registry.

    • Accordez une autorisation à l'échelle du projet si les mêmes autorisations s'appliquent à tous les dépôts du projet.

      gcloud projects add-iam-policy-binding PROJECT_ID \
      --role=roles/artifactregistry.reader \
      --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"

    • Accordez une autorisation spécifique au dépôt lorsque vous souhaitez que les comptes de service aient différents niveaux d'accès pour chaque dépôt de votre projet.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
   --project=PROJECT_ID

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de projet de l'organisation.
    • FLEET_HOST_PROJECT_ID : si vous utilisez Workload Identity de GKE, ce champ d'application est identique à PROJECT_ID. Si vous utilisez la fonctionnalité Workload Identity du parc, il s'agit de l'ID de projet du parc dans lequel votre cluster est enregistré.
    • KSA_NAME : compte de service Kubernetes pour le rapprochement.
      • Pour les dépôts racine, si le nom RootSync est root-sync, utilisez root-reconciler. Sinon, utilisez root-reconciler-ROOT_SYNC_NAME. Si vous installez Config Sync à l'aide de la console Google Cloud ou de Google Cloud CLI, Config Sync crée automatiquement un objet RootSync appelé root-sync.
    • REPOSITORY : ID du dépôt.
    • LOCATION : emplacement régional ou multirégional du dépôt.

Compte de service Google

Si vous stockez votre image OCI dans Artifact Registry et que votre cluster utilise GKE Workload Identity ou la fonctionnalité Workload Identity du parc, vous pouvez utiliser gcpserviceaccount comme type d'authentification. À partir de la version 1.17.2, il est recommandé d'utiliser k8sserviceaccount à la place. Cette option élimine les étapes supplémentaires de la création d'un compte de service Google et la liaison de stratégie IAM associée.

  1. Si vous ne disposez pas d'un compte de service, créez-en un.

  2. Attribuez le rôle IAM de lecteur Artifact Registry (roles/artifactregistry.reader) au compte de service Google. Pour en savoir plus sur les rôles et les autorisations d'Artifact Registry, consultez la page Configurer les rôles et les autorisations pour Artifact Registry.

    • Accordez une autorisation à l'échelle du projet si les mêmes autorisations s'appliquent à tous les dépôts du projet.

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

    • Accordez une autorisation spécifique au dépôt lorsque vous souhaitez que les comptes de service aient différents niveaux d'accès pour chaque dépôt de votre projet.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
   --project=PROJECT_ID

  3. 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
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
    --project=PROJECT_ID

Remplacez les éléments suivants :

  • PROJECT_ID : ID de projet de l'organisation.
  • FLEET_HOST_PROJECT_ID : si vous utilisez Workload Identity de GKE, ce champ d'application est identique à PROJECT_ID. Si vous utilisez la fonctionnalité Workload Identity du parc, il s'agit de l'ID de projet du parc dans lequel votre cluster est enregistré.
  • GSA_NAME : compte de service Google personnalisé que vous souhaitez utiliser pour vous connecter à Artifact Registry. Ce compte de service doit disposer du rôle IAM Lecteur Artifact Registry (roles/artifactregistry.reader).
  • KSA_NAME : compte de service Kubernetes pour le rapprochement.
    • Pour les dépôts racine, si le nom RootSync est root-sync, utilisez root-reconciler. Sinon, utilisez root-reconciler-ROOT_SYNC_NAME. Si vous installez Config Sync à l'aide de la console Google Cloud ou de Google Cloud CLI, Config Sync crée automatiquement un objet RootSync appelé root-sync.
  • REPOSITORY : ID du dépôt.
  • LOCATION : emplacement régional ou multirégional du dépôt.

Compte de service Compute Engine par défaut

Si vous stockez votre chart Helm dans Artifact Registry et que votre cluster est GKE avec Workload Identity désactivé, vous pouvez utiliser gcenode comme type d'authentification. Config Sync utilise le compte de service Compute Engine par défaut. Vous devez autoriser votre compte de service Compute Engine par défaut à accéder en lecture à Artifact Registry.

  1. Accordez au compte de service Compute Engine l'autorisation de lecture sur 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

    Remplacez PROJECT_ID par l'ID de projet de votre organisation et PROJECT_NUMBER par le numéro de projet de votre organisation.

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

Config Sync a besoin d'un accès en lecture seule à votre dépôt Helm pour pouvoir lire les charts Helm de votre dépôt et les installer dans 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 votre dépôt Helm est public 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 dépôts Helm privés. Config Sync accepte les mécanismes d'authentification suivants :

  • Jeton (token)
  • Compte de service Kubernetes (k8sserviceaccount)
  • Compte de service Google (gcpserviceaccount)
  • Compte de service Compute Engine par défaut (gcenode)

Jeton

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 à votre secret.
  • USERNAME : nom d'utilisateur du dépôt Helm.
  • PASSWORD : mot de passe du dépôt Helm.

Lorsque vous configurez l'opérateur ConfigManagement, vous utilisez le nom du secret que vous avez choisi pour spec.helm.secretRef.name.

Compte de service Kubernetes

Si vous stockez votre chart Helm dans Artifact Registry et que votre cluster utilise GKE Workload Identity ou la fonctionnalité Workload Identity du parc, vous pouvez utiliser k8sserviceaccount comme type d'authentification dans les versions 1.17.2 et ultérieures. Cette option est recommandée plutôt que gcpserviceaccount en raison de son processus de configuration simplifié.

  1. Attribuez le rôle IAM de lecteur Artifact Registry (roles/artifactregistry.reader) au compte de service Kubernetes avec le pool Workload Identity. Pour en savoir plus sur les rôles et les autorisations d'Artifact Registry, consultez la page Configurer les rôles et les autorisations pour Artifact Registry.

    • Accordez une autorisation à l'échelle du projet si les mêmes autorisations s'appliquent à tous les dépôts du projet.

      gcloud projects add-iam-policy-binding PROJECT_ID \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"

    • Accordez une autorisation spécifique au dépôt lorsque vous souhaitez que les comptes de service aient différents niveaux d'accès pour chaque dépôt de votre projet.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
   --project=PROJECT_ID

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de projet de l'organisation.
    • FLEET_HOST_PROJECT_ID : si vous utilisez Workload Identity de GKE, ce champ d'application est identique à PROJECT_ID. Si vous utilisez la fonctionnalité Workload Identity du parc, il s'agit de l'ID de projet du parc dans lequel votre cluster est enregistré.
    • KSA_NAME : compte de service Kubernetes pour le rapprochement.
      • Pour les dépôts racine, si le nom RootSync est root-sync, utilisez root-reconciler. Sinon, utilisez root-reconciler-ROOT_SYNC_NAME.
    • REPOSITORY : ID du dépôt.
    • LOCATION : emplacement régional ou multirégional du dépôt.

Compte de service Google

Si vous stockez votre chart Helm dans Artifact Registry et que votre cluster utilise GKE Workload Identity ou la fonctionnalité Workload Identity du parc, vous pouvez utiliser gcpserviceaccount comme type d'authentification. À partir de la version 1.17.2, il est recommandé d'utiliser k8sserviceaccount à la place. Cette option élimine les étapes supplémentaires de création d'un compte de service Google et de la liaison de stratégie IAM associée.

  1. Si vous ne disposez pas d'un compte de service, créez-en un.

  2. Attribuez le rôle IAM de lecteur Artifact Registry (roles/artifactregistry.reader) au compte de service Google. Pour en savoir plus sur les rôles et les autorisations Artifact Registry, consultez la section Configurer des rôles et des autorisations pour Artifact Registry.

    • Accordez une autorisation à l'échelle du projet si les mêmes autorisations s'appliquent à tous les dépôts du projet.

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

    • Accordez une autorisation spécifique au dépôt lorsque vous souhaitez que les comptes de service aient différents niveaux d'accès pour chaque dépôt de votre projet.

      gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
   --location=LOCATION \
   --role=roles/artifactregistry.reader \
   --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
   --project=PROJECT_ID

  3. 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
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
    --project=PROJECT_ID

Remplacez les éléments suivants :

  • PROJECT_ID : ID de projet de l'organisation.
  • FLEET_HOST_PROJECT_ID : si vous utilisez Workload Identity de GKE, ce champ d'application est identique à PROJECT_ID. Si vous utilisez la fonctionnalité Workload Identity du parc, il s'agit de l'ID de projet du parc dans lequel votre cluster est enregistré.
  • GSA_NAME : compte de service Google personnalisé que vous souhaitez utiliser pour vous connecter à Artifact Registry. Ce compte de service doit disposer du rôle IAM Lecteur Artifact Registry (roles/artifactregistry.reader).
  • KSA_NAME : compte de service Kubernetes pour le rapprochement.
    • Pour les dépôts racine, si le nom RootSync est root-sync, utilisez root-reconciler. Sinon, utilisez root-reconciler-ROOT_SYNC_NAME.
  • REPOSITORY : ID du dépôt.
  • LOCATION : emplacement régional ou multirégional du dépôt.

Compte de service Compute Engine par défaut

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

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

    Remplacez PROJECT_ID par l'ID de projet de votre organisation et PROJECT_NUMBER par le numéro de projet de votre organisation.

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 appelé root-sync. Vous pouvez utiliser les commandes kubectl pour modifier root-sync et ajouter des configurations Config Sync supplémentaires. Pour en savoir plus, consultez la page Configurer Config Sync avec des commandes kubectl.

Console

Installer Config Sync

Pour installer Config Sync, tous les clusters doivent être enregistrés dans un parc. Lorsque vous installez Config Sync dans la console Google Cloud, la sélection de clusters individuels enregistre automatiquement ces clusters dans votre parc.

  1. Dans la console Google Cloud, accédez à la page Configuration sous la section Fonctionnalités.

    Accéder à la page "Configuration"

  2. Cliquez sur Installer Config Sync.
  3. Sélectionnez Mises à niveau automatiques (Aperçu) pour permettre à Config Sync de mettre à niveau les versions automatiquement ou sélectionnez Mises à niveau manuelles pour gérer vous-même la version de Config Sync. Pour en savoir plus sur le fonctionnement des mises à niveau automatiques, consultez la page Mettre à niveau Config Sync.
  4. Sous Options d'installation, sélectionnez l'une des options suivantes :
    • Installer Config Sync sur l'ensemble du parc (recommandé) : Config Sync sera installé sur tous les clusters du parc.
    • Installer Config Sync sur des clusters individuels : tous les clusters sélectionnés seront automatiquement enregistrés dans un parc. Config Sync sera installé sur tous les clusters du parc.
  5. Si vous installez Config Sync sur des clusters individuels, sélectionnez les clusters sur lesquels vous souhaitez installer Config Sync dans le tableau Clusters disponibles.
  6. Cliquez sur Installer Config Sync. Dans l'onglet Paramètres, après quelques minutes, Activé devrait s'afficher dans la colonne État pour les clusters de votre parc.

Déployer un package

Une fois que vous avez enregistré vos clusters dans un parc et installé Config Sync, vous pouvez configurer Config Sync pour déployer un package sur un cluster à partir d'une source fiable. Vous pouvez déployer le même package sur plusieurs clusters ou déployer différents packages sur différents clusters. Vous pouvez modifier un package après l'avoir déployé, à l'exception de certains paramètres tels que le nom du package et le type de synchronisation. Pour en savoir plus, consultez la section Gérer les packages.

Pour déployer un package, procédez comme suit :

  1. Dans la console Google Cloud, accédez au tableau de bord Config Sync.

    Accéder au tableau de bord Config Sync

  2. Cliquez sur Déployer le package.

  3. Dans la table Sélectionner des clusters pour le déploiement de packages, sélectionnez le cluster sur lequel vous souhaitez déployer un package, puis cliquez sur Continuer.

  4. Sélectionnez Package hébergé sur Git ou Package hébergé sur OCI comme type de source, puis cliquez sur Continuer.

  5. Dans la section Informations sur le package, saisissez un nom de package, qui identifie l'objet RootSync ou RepoSync.

  6. Dans le champ Type de synchronisation, sélectionnez le type de synchronisation Synchronisation à l'échelle du cluster ou Synchronisation à l'échelle de l'espace de noms.

    La synchronisation à l'échelle d'un cluster crée un objet RootSync, tandis que la synchronisation à l'échelle d'un espace de noms crée un objet RepoSync. Pour en savoir plus sur ces objets, consultez la page Architecture de Config Sync.

  7. Dans la section Source, configurez les éléments suivants :

    • Pour les sources hébergées dans un dépôt Git, renseignez les champs suivants :

      1. Dans le champ URL du dépôt, saisissez l'URL du dépôt Git que vous utilisez comme source fiable.
      2. Facultatif : Mettez à jour le champ Révision pour vérifier si vous n'utilisez pas la valeur par défaut HEAD.
      3. Facultatif : Mettez à jour le champ Chemin d'accès si vous ne souhaitez pas synchroniser à partir du dépôt racine.
      4. Facultatif : mettez à jour le champ Branche si vous n'utilisez pas la branche main par défaut.

    • Pour les sources hébergées dans une image OCI, saisissez les champs suivants :

      1. Saisissez l'URL de l'image OCI que vous utilisez comme source fiable en tant qu'image.
      2. Saisissez le chemin du répertoire à synchroniser, associé au répertoire racine, dans le champ Répertoire.

  8. Facultatif : Développez la section Paramètres avancés pour effectuer les opérations suivantes :

    1. Sélectionnez un type d'authentification. Config Sync a besoin d'un accès en lecture seule à votre source fiable pour lire les fichiers de configuration de la source et les appliquer à vos clusters. À moins que votre source ne nécessite aucune authentification, telle qu'un dépôt public, veillez à accorder à Config Sync un accès en lecture seule à votre dépôt Git, Image OCI ougraphique Helm (gcloud CLI uniquement). Choisissez le même type d'authentification que celui configuré lors de l'installation de Config Sync :

      • Aucune : n'utilisez aucune authentification
      • SSH : authentifiez-vous à l'aide d'une paire de clés SSH.
      • Cookiefile : authentifiez-vous à l'aide d'un fichier cookiefile.
      • Jeton : authentifiez-vous à l'aide d'un jeton d'accès ou d'un mot de passe.
      • 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.

    2. Saisissez un nombre en secondes pour définir le temps d'attente de la synchronisation, qui détermine la durée pendant laquelle Config Sync attend entre les tentatives d'extraction à partir de la source fiable.

    3. Saisissez une URL de proxy Git pour le proxy HTTPS à utiliser lors de la communication avec la source fiable.

    4. Sélectionnez Hiérarchie pour modifier le Format source.

      La valeur par défaut Non structuré est recommandée dans la plupart des cas, car elle vous permet d'organiser votre source fiable comme vous le souhaitez.

  9. Cliquez sur Déployer le package.

    Vous êtes redirigé vers la page Packages de Config Sync. Après quelques minutes, Synchronisé doit s'afficher dans la colonne État de synchronisation du cluster que vous avez configuré.

gcloud

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

  1. Activez la fonctionnalité de parc ConfigManagement :

    gcloud beta container fleet config-management enable

  2. 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 suivant.

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

    # apply-spec.yaml

applySpecVersion: 1
spec:
  # upgrades: UPGRADE_SETTING
  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
    syncRev: REVISION
    syncBranch: BRANCH
    secretType: SECRET_TYPE
    gcpServiceAccountEmail: EMAIL
    metricsGcpServiceAccountEmail: METRICS_EMAIL
    policyDir: DIRECTORY
    preventDrift: PREVENT_DRIFT

    Remplacez les éléments suivants :

    • (Bêta) UPGRADE_SETTING : annulez la mise en commentaire du champ et définissez-le sur auto pour configurer la mise à niveau automatique de Config Sync. Définissez la valeur sur manual pour mettre à niveau manuellement Config Sync vous-même. La valeur par défaut est manual. Cette option n'est compatible qu'avec les clusters GKE sur Google Cloud. Pour utiliser ce champ, vous devrez peut-être mettre à jour gcloud CLI en exécutant gcloud components update.

    • SOURCE_TYPE : ajoutez git pour synchroniser à partir d'un dépôt Git, oci pour synchroniser à partir d'une image OCI ou helm pour effectuer la synchronisation à partir d'un chart 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 fiable. Les URL de dépôt 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 récupérer les images par 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

    • REVISION : révision Git (tag ou hachage) à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est HEAD. À partir de la version 1.17.0 de Config Sync, vous pouvez également spécifier un nom de branche dans le champ syncRev. Lorsque vous utilisez un hachage dans la version 1.17.0 ou ultérieure, il doit s'agir d'un hachage complet et non d'une version abrégée.

    • 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. À partir de la version 1.17.0 de Config Sync, il est recommandé d'utiliser le champ syncRev pour spécifier un nom de branche par souci de simplicité. Si les champs syncRev et syncBranch sont tous les deux spécifiés, syncRev est prioritaire sur syncBranch.

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

    • METRICS_EMAIL : adresse e-mail du compte de service Google Cloud (GSA) utilisé pour exporter les métriques Config Sync vers Cloud Monitoring. Le GSA doit disposer du rôle IAM "Rédacteur de métriques Monitoring" (roles/monitoring.metricWriter). Le compte de service Kubernetes default dans l'espace de noms config-management-monitoring doit être lié au GSA.

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

  3. 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 de l'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.

Terraform

Pour chaque cluster sur lequel vous souhaitez configurer Config Sync, appliquez un bloc de ressources google_gkehub_feature_membership contenant un bloc configmanagement et config_sync :

git

resource "google_container_cluster" "cluster" {
 name = EXISTING_CLUSTER_NAME
 location = "EXISTING_CLUSTER_LOCATION"
}

resource "google_gke_hub_membership" "membership" {
 membership_id = "MEMBERSHIP_ID"
 endpoint {
   gke_cluster {
     resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
   }
 }

resource "google_gke_hub_feature" "feature" {
  name = "configmanagement"
  location = "global"
  }
}

resource "google_gke_hub_feature_membership" "feature_member" {
 location = "global"
 feature = google_gke_hub_feature.feature.name
 membership = google_gke_hub_membership.membership.membership_id
 configmanagement {
   version = "VERSION"
   config_sync {
     git {
       sync_repo = "REPO"
       sync_branch = "BRANCH"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

Remplacez les éléments suivants :

  • EXISTING_CLUSTER_NAME : nom de votre cluster existant.
  • EXISTING_CLUSTER_LOCATION : emplacement de votre cluster existant.
  • MEMBERSHIP_ID : ID de liaison d'abonnement.
  • VERSION : (facultatif) numéro de version de Config Sync. Doit être défini sur la version 1.17.0 ou ultérieure. Si vous ne renseignez pas ce champ, la valeur par défaut est la dernière version.
  • REPO : URL du dépôt contenant vos fichiers de configuration.
  • BRANCH : branche du dépôt, par exemple main.
  • DIRECTORY : chemin d'accès dans le dépôt Git qui représente le niveau supérieur du dépôt que vous souhaitez synchroniser.
  • SECRET : type d'authentification du secret.

OCI

resource "google_container_cluster" "cluster" {
 name = EXISTING_CLUSTER_NAME
 location = "EXISTING_CLUSTER_LOCATION"
}

resource "google_gke_hub_membership" "membership" {
 membership_id = "MEMBERSHIP_ID"
 endpoint {
   gke_cluster {
     resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
   }
 }

resource "google_gke_hub_feature" "feature" {
  name = "configmanagement"
  location = "global"
  }
}

resource "google_gke_hub_feature_membership" "feature_member" {
 location = "global"
 feature = google_gke_hub_feature.feature.name
 membership = google_gke_hub_membership.membership.membership_id
 configmanagement {
   version = "VERSION"
   config_sync {
     oci {
       sync_repo = "REPO"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

Remplacez les éléments suivants :

  • EXISTING_CLUSTER_NAME : nom de votre cluster existant.
  • EXISTING_CLUSTER_LOCATION : emplacement de votre cluster existant.
  • MEMBERSHIP_ID : ID de liaison d'abonnement.
  • VERSION : (facultatif) numéro de version de Config Sync. Si vous ne renseignez pas ce champ, la valeur par défaut est la dernière version.
  • REPO : URL du dépôt d'images OCI contenant vos fichiers de configuration.
  • DIRECTORY : chemin d'accès absolu du répertoire contenant les ressources que vous souhaitez synchroniser. Laissez le champ vide pour utiliser le répertoire racine.
  • SECRET : type d'authentification du secret.

Répétez cette procédure pour chaque cluster que vous souhaitez synchroniser.

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

Configurer les valeurs par défaut au niveau du parc

Si vous avez activé Google Kubernetes Engine (GKE) Enterprise, vous pouvez activer et configurer Config Sync comme valeur par défaut au niveau du parc pour vos clusters. Cela signifie que Config Sync est activé sur le cluster avec les paramètres que vous spécifiez pour chaque nouveau cluster GKE sur Google Cloud créé dans le parc. Pour en savoir plus sur la configuration par défaut du parc, consultez la page Gérer les fonctionnalités au niveau du parc.

Si vous n'utilisez que la console Google Cloud, vous pouvez activer Config Sync par défaut sur vos clusters et définir la version de Config Sync pour votre parc. Si vous utilisez Terraform, vous pouvez activer Config Sync par défaut sur vos clusters, définir la version de Config Sync pour votre flotte et configurer la connexion à votre dépôt Git ou à votre dépôt d'images OCI.

Pour configurer les valeurs par défaut au niveau du parc pour Config Sync, procédez comme suit :

Console

  1. Dans la console Google Cloud, accédez à la page Gestionnaire de fonctionnalités.

    Accéder au gestionnaire de fonctionnalités

  2. Dans le volet Config Sync, cliquez sur Configurer.

  3. Vérifiez vos paramètres au niveau du parc. Tous les clusters que vous créez dans le parc héritent de ces paramètres.

  4. Facultatif : Pour modifier les paramètres par défaut, cliquez sur Personnaliser les paramètres du parc. Dans la boîte de dialogue qui apparaît, procédez comme suit :

  5. Sélectionnez Mises à niveau automatiques (bêta) pour que les versions de Config Sync soient mises à niveau automatiquement, ou sélectionnez Mises à niveau manuelles pour gérer la version de Config Sync vous-même. Pour en savoir plus sur le fonctionnement des mises à niveau automatiques, consultez la page Mettre à niveau Config Sync.

  6. Si vous avez sélectionné Mises à niveau manuelles, dans la liste Version, sélectionnez la version de Config Sync que vous souhaitez utiliser.

  7. Cliquez sur Enregistrer les modifications.

  8. Cliquez sur Configurer.

  9. Dans la boîte de dialogue de confirmation Configurer les paramètres du parc, cliquez sur Confirmer. Si vous n'avez pas encore activé Config Sync, cliquez sur Confirmer pour activer également l'API anthosconfigmanagement.googleapis.com.

Terraform

  1. Créez un répertoire pour les fichiers Terraform de configuration par défaut du parc. À ce répertoire, ajoutez un fichier main.tf avec la ressource suivante qui configure les paramètres de Config Sync :

    git

    terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
      version = ">=5.16.0"
      }
    }
  }

provider "google" {
  project = "PROJECT_ID"
}

resource "google_gke_hub_feature" "feature" {
  name = "configmanagement"
  location = "global"
  provider = google
  fleet_default_member_config {
    configmanagement {
    version = "VERSION"
    config_sync {
    source_format = "unstructured"
      git {
        sync_repo = "REPO"
        sync_branch = "BRANCH"
        policy_dir = "DIRECTORY"
        secret_type = "SECRET"
      }
    }
    }
  }
}

    Remplacez les éléments suivants :

    • PROJECT_ID : ID du projet hôte du parc.
    • VERSION : (facultatif) numéro de version de Config Sync. Si vous ne renseignez pas ce champ, la valeur par défaut est la dernière version.
    • REPO : URL du dépôt contenant vos fichiers de configuration.
    • BRANCH : branche du dépôt, par exemple main.
    • DIRECTORY : chemin d'accès dans le dépôt Git qui représente le niveau supérieur du dépôt que vous souhaitez synchroniser.
    • SECRET : type d'authentification du secret.

    Pour obtenir la liste complète des paramètres compatibles avec le bloc Config Sync git, consultez la documentation de référence de Terraform pour les fonctionnalités de GKE Hub.

    OCI

    terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
      version = ">=5.16.0"
      }
    }
  }

provider "google" {
  project = "PROJECT_ID"
}

resource "google_gke_hub_feature" "feature" {
  name = "configmanagement"
  location = "global"
  provider = google
  fleet_default_member_config {
    configmanagement {
    version = "VERSION"
    config_sync {
    source_format = "unstructured"
      oci {
        sync_repo = "REPO"
        policy_dir = "DIRECTORY"
        secret_type = "SECRET"
      }
    }
    }
  }
}

    Remplacez les éléments suivants :

    • PROJECT_ID : ID du projet hôte du parc.
    • VERSION : numéro de version de Config Sync. Doit être défini sur la version 1.17.0 ou ultérieure. Si vous ne renseignez pas ce champ, la valeur par défaut est la dernière version.
    • REPO : URL du dépôt d'images OCI contenant les fichiers de configuration.
    • DIRECTORY : chemin d'accès absolu du répertoire contenant les ressources que vous souhaitez synchroniser. Laissez le champ vide pour utiliser le répertoire racine.
    • SECRET : type d'authentification du secret.

    Pour obtenir la liste complète des paramètres compatibles avec le bloc Config Sync oci, consultez la documentation de référence de Terraform pour les fonctionnalités de GKE Hub.

  2. Initialisez Terraform dans le répertoire que vous avez créé :

    terraform init

  3. Vérifiez que les modifications que vous proposez avec Terraform correspondent au plan attendu :

    terraform plan

  4. Créez les configurations de membres de parc par défaut :

    terraform apply

Si vous souhaitez mettre à jour des clusters existants pour qu'ils utilisent vos paramètres Config Sync par défaut, utilisez la console Google Cloud pour synchroniser les clusters de parc sélectionnés avec les valeurs par défaut de votre parc. Vous pouvez également configurer manuellement chaque cluster avec les mêmes paramètres à l'aide de Terraform ou de gcloud CLI en suivant les instructions de configuration de Config Sync. Si vous avez déjà utilisé Terraform pour spécifier les valeurs par défaut du parc, utilisez les mêmes blocs configmanagement et config_sync que ceux utilisés pour définir les valeurs par défaut afin de configurer les clusters choisis.

Pour synchroniser les paramètres Config Sync par défaut dans votre parc, procédez comme suit :

  1. Accéder au gestionnaire de fonctionnalités

    Accéder au gestionnaire de fonctionnalités : Config Sync

  2. Dans la table du cluster, sélectionnez les clusters que vous souhaitez synchroniser avec les paramètres du parc.

  3. Cliquez sur Synchroniser avec les paramètres du parc.

Les paramètres par défaut de Config Sync s'appliquent à tous les clusters que vous sélectionnez. Bien que la console Google Cloud n'affiche qu'un sous-ensemble de paramètres, tel que la version de Config Sync, tous les paramètres au niveau du parc sont synchronisés avec les clusters. Par exemple, si vous configurez Config Sync pour qu'il se synchronise avec un dépôt Git à l'aide de Terraform, ce paramètre est synchronisé avec vos clusters, mais ne s'affiche pas dans la console Google Cloud.

Vérifier 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, accédez à la page Configuration sous la section Fonctionnalités.

    Accéder à la page "Configuration"

  2. Dans l'onglet Packages, consultez la colonne État de synchronisation dans le tableau du cluster. Une installation réussie de Config Sync présente l'état Installé. Une source fiable configurée avec succès affiche 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. À partir de la version 1.18.0 de Config Sync, le résultat affiche également la version de Config Sync installée et le paramètre de mise à niveau de Config Sync.

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.

Contrôles d'accès et autorisations basés sur les rôles

Policy Controller, Config Sync et Config Controller incluent des charges de travail à privilèges élevés. Le tableau suivant liste les autorisations pour ces charges de travail :

Composant Namespace Compte de service Autorisations Description
Config Management Operator config-management-system config-management-operator cluster-admin Config Management Operator installe les autres composants de ce tableau. Certains de ces composants nécessitent des autorisations de type cluster-admin. Par conséquent, Config Management Operator les requiert également.
Config Sync config-management-system Consultez la section Autorisations de Config Sync pour connaître les autorisations requises.

Demandes de ressources

La section suivante répertorie les demandes de ressources pour Config Sync.

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.

Tous les composants répertoriés ne sont pas créés. Les conditions suivantes entraînent la planification de chaque composant :

  • config-management-operator est installé lorsque Config Sync est activé.
  • reconciler-manager est installé lorsque Config Sync est activé.
  • admission-webhook est installé lorsque la protection contre les dérives est activée.
  • un reconciler est installé pour chaque RootSync et chaque RepoSync.
  • otel-collector est installé lorsque Config Sync est activé.

Pour en savoir plus sur ces composants, consultez la section Architecture de Config Sync.

1.18

Nom du déploiement Demande de processeur (m) par instance dupliquée Demande de mémoire (Mi) par instance dupliquée
config-management-operator 100 200
resource-group-controller-manager 110 300
admission-webhook1 10 100
otel-collector 200 400
reconciler-manager 20 150
reconciler (un par RootSync et RepoSync) Pour en savoir plus, consultez la section Déploiement du rapprochement.

1 Le webhook d'admission comporte deux instances répliquées. Par conséquent, si vous souhaitez calculer le nombre total de requêtes de ressources, vous devez doubler la valeur si vous utilisez le webhook d'admission. Le webhook d'admission est désactivé par défaut.

1.17

Nom du déploiement Demande de processeur (m) par instance dupliquée Demande de mémoire (Mi) par instance dupliquée
config-management-operator 100 200
resource-group-controller-manager 110 300
admission-webhook1 10 100
otel-collector 200 400
reconciler-manager 20 150
reconciler (un par RootSync et RepoSync) Pour en savoir plus, consultez la section Déploiement du rapprochement.

1 Le webhook d'admission comporte deux instances répliquées. Par conséquent, si vous souhaitez calculer le nombre total de requêtes de ressources, vous devez doubler la valeur si vous utilisez le webhook d'admission. Le webhook d'admission est désactivé par défaut.

1.16

Nom du déploiement Demande de processeur (m) par instance dupliquée Demande de mémoire (Mi) par instance dupliquée
config-management-operator 100 200
resource-group-controller-manager 110 300
admission-webhook1 10 100
otel-collector 200 400
reconciler-manager 20 150
reconciler (un par RootSync et RepoSync) Pour en savoir plus, consultez la section Déploiement du rapprochement.

1 Le webhook d'admission comporte deux instances répliquées. Par conséquent, si vous souhaitez calculer le nombre total de requêtes de ressources, vous devez doubler la valeur si vous utilisez le webhook d'admission. Le webhook d'admission est désactivé par défaut.

Déploiement du rapprochement

Pour chaque objet RootSync et RepoSync, Config Sync crée un déploiement de rapprochement indépendant pour gérer la synchronisation. Le déploiement du rapprochement est constitué de plusieurs conteneurs. Pour en savoir plus sur ces conteneurs, consultez la section Conteneurs de rapprochement.

Dans Config Sync 1.17.0 et versions ultérieures, les demandes de ressources par défaut pour les rapprochements sont différentes pour les clusters Standard et Autopilot. Tous les autres types de clusters utilisent les valeurs par défaut standards.

Les clusters standards

1.18

Nom du conteneur Demande de processeur (m) Demande de mémoire (Mi)
reconciler 50 200
otel-agent 10 100
hydration-controller (Facultatif) 10 100
git-sync 10 16
gcenode-askpass-sidecar (Facultatif) 10 20
helm-sync 75 128
oci-sync 25 32

1.17

Nom du conteneur Demande de processeur (m) Demande de mémoire (Mi)
reconciler 50 200
otel-agent 10 100
hydration-controller (Facultatif) 10 100
git-sync 10 16
gcenode-askpass-sidecar (Facultatif) 10 20
helm-sync 75 128
oci-sync 25 32

1.16

Nom du conteneur Demande de processeur (m) Demande de mémoire (Mi)
reconciler 50 200
otel-agent 10 100
hydration-controller (Facultatif) 10 100
git-sync 10 200
gcenode-askpass-sidecar (Facultatif) 10 20
helm-sync 50 256
oci-sync 10 200

Clusters Autopilot

1.18

Nom du conteneur Demande et limite de ressources processeur (m) Demande et limite de mémoire (Mi)
reconciler 700 512
otel-agent 10 64
hydration-controller (Facultatif) 200 256
git-sync 20 32
gcenode-askpass-sidecar (Facultatif) 50 64
helm-sync 250 384
oci-sync 50 64

1.17

Nom du conteneur Demande et limite de ressources processeur (m) Demande et limite de mémoire (Mi)
reconciler 700 512
otel-agent 10 64
hydration-controller (Facultatif) 200 256
git-sync 20 32
gcenode-askpass-sidecar (Facultatif) 50 64
helm-sync 150 256
oci-sync 50 64

1.16

Dans les versions de Config Sync antérieures à la version 1.17.0, les demandes de ressources sont les mêmes pour les versions Standard et Autopilot.

Pour savoir comment remplacer les demandes et les limites de ressources par défaut, consultez la section Remplacements de ressources.

Versions groupées de Helm et Kustomize

Config Sync exploite les exécutables Helm et Kustomize pour effectuer le rendu des configurations en arrière-plan. Le tableau suivant fournit une liste des versions de Config Sync compatibles avec la fonctionnalité de rendu, ainsi que les versions groupées de Helm et Kustomize.

Versions de Config Sync Version de Helm Version de Kustomize
1.18.0 v3.14.3 v5.3.0
1.17.1 et 1.17.3 v3.13.3 v5.3.0
1.16.3 et 1.17.0 v3.13.1 v5.1.1
1.16.1 et 1.16.2 v3.12.3 v5.1.1
1.16.0 v3.12.2 v5.1.1
1.15.3 v3.12.2 v5.1.0
1.15.1 à 1.15.2 v3.11.3 v5.0.3
1.15.0 v3.11.3 v5.0.1
1.11.0 à 1.14.3 v3.6.3 v4.5.2

Pour en savoir plus sur le rendu de Helm via Kustomize, consultez la page Configurer Kubernetes avec Kustomize. Pour en savoir plus sur l'utilisation de l'API Helm, consultez la page Synchroniser des charts Helm à partir d'Artifact Registry.

Étapes suivantes