Installer Config Sync

Avec Config Sync, vous pouvez gérer des ressources Kubernetes à l'aide de fichiers de configuration stockés dans une source d'informations. Config Sync est compatible avec les dépôts Git, les images OCI et les graphiques Helm comme source 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 avec l'édition Google Kubernetes Engine (GKE) Enterprise.

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 de référence ou assurez-vous d'y avoir accès. C'est ici que vous ajoutez les configurations que Config Sync synchronise. Pour en savoir plus sur la configuration de vos configurations et de votre source de référence, 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é la Google Cloud CLI, obtenez la dernière version en exécutant gcloud components update.

  3. Activez l'API GKE Enterprise

    Activez l'API GKE Enterprise

Configuration requise pour les clusters

Créez ou avez accès à un cluster répondant aux exigences suivantes:

  • Le cluster se trouve sur une plate-forme et une version compatibles de l'édition Google Kubernetes Engine (GKE) Enterprise.

  • Si vous utilisez des clusters Autopilot, Autopilot ajuste les besoins en ressources de conteneurs 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 d'écriture de métriques appropriées 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 les versions disponibles de GKE est traité comme un cluster utilisant la version disponible 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 de référence, vous devez inclure le niveau d'accès en lecture seule dans les 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 en matière de pare-feu VPC qui bloquent tout trafic inutile, vous devez créer des règles de pare-feu pour autoriser le trafic suivant sur les clusters GKE publics:

    • TCP: autoriser le trafic d'entrée et de sortie sur les ports 53 et 443

    • UDP: autoriser 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 de composants backend Config Sync ne sont créées, distribuées et testées que 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 votre cluster comporte des nœuds ARM, 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, afin d'éviter de programmer des pods sur vos nœuds arm64 sans tolérance spécifique. Les nœuds du groupe 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 utiliser des clusters en dehors de Google Cloud, assurez-vous que vos clusters GKE ou 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 de référence suivantes:

Une fois que vous avez accordé l'accès, 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 si vous pouvez utiliser git clone pour créer un clone du dépôt localement 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 (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 comme dépôt Config Sync, procédez comme suit afin de 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, vous devez ajouter 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é des 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 connus, 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 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 le parc Workload Identity, 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 encore d'un compte de service, créez-en un.

  2. Attribuez le rôle IAM de 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égie 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 Workload Identitypool. Conformément au concept d'uniformité des parcs, 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 du même parc obtient également 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 du projet de l'organisation.
  • FLEET_HOST_PROJECT_ID: si vous utilisez Workload Identity de GKE, c'est la même chose que 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. Le 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 de 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 nommé 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 sur Google Cloud 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 en tant que secretType.

Sélectionnez Google Cloud Repository ou gcenode pour 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 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.

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 du 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 à 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. 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 Charge Workload Identity du parc, vous pouvez utiliser k8sserviceaccount comme type d'authentification à partir de la version 1.17.2. Cette option est recommandée par rapport à 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 d'Workload Identity. Pour en savoir plus sur les rôles et les autorisations d'Artifact Registry, consultez la page 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: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 du projet de l'organisation.
    • FLEET_HOST_PROJECT_ID: si vous utilisez Workload Identity de GKE, c'est la même chose que 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 de 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 nommé 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 Workload Identity du parc, vous pouvez utiliser gcpserviceaccount comme type d'authentification. À partir de la version 1.17.2, il est recommandé d'utiliser plutôt k8sserviceaccount. Cette option élimine les étapes supplémentaires de création d'un compte de service Google et la liaison de stratégie IAM associée.

  1. Si vous ne disposez pas encore 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 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 du projet de l'organisation.
  • FLEET_HOST_PROJECT_ID: si vous utilisez Workload Identity de GKE, c'est la même chose que 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. Le 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 de 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 nommé 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 sur Google Cloud 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 accorder à votre compte de service Compute Engine par défaut un accès 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 l'accès en lecture seule à Config Sync à Helm

Config Sync a besoin d'un accès en lecture seule à votre dépôt Helm pour pouvoir lire les charts Helm dans 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.

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 pour le 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 donner au 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 Workload Identity du parc, vous pouvez utiliser k8sserviceaccount comme type d'authentification à partir de la version 1.17.2. Cette option est recommandée par rapport à 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 d'Workload Identity. Pour en savoir plus sur les rôles et les autorisations d'Artifact Registry, consultez la page 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: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 du projet de l'organisation.
    • FLEET_HOST_PROJECT_ID: si vous utilisez Workload Identity de GKE, c'est la même chose que 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 de 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 Workload Identity du parc, vous pouvez utiliser gcpserviceaccount comme type d'authentification. À partir de la version 1.17.2, il est recommandé d'utiliser plutôt k8sserviceaccount. Cette option élimine les étapes supplémentaires de création d'un compte de service Google et la liaison de stratégie IAM associée.

  1. Si vous ne disposez pas encore 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 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 du projet de l'organisation.
  • FLEET_HOST_PROJECT_ID: si vous utilisez Workload Identity de GKE, c'est la même chose que 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. Le 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 de 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 sur Google Cloud 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 accorder à votre compte de service Compute Engine par défaut un accès en lecture à Artifact Registry. Vous devrez peut-être accorder le niveau d'accès storage-ro pour accorder l'autorisation de lecture seule permettant d'extraire des images.

  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 nommé 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 section Configurer Config Sync à l'aide de 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 dans la section Fonctionnalités.

    Accéder à Config

  2. Cliquez sur Installer Config Sync.
  3. Sélectionnez Mises à niveau automatiques (Preview) pour permettre à Config Sync de mettre à niveau automatiquement les versions, 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 sont 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 la table Clusters disponibles.
  6. Cliquez sur Installer Config Sync. Dans l'onglet Paramètres, après quelques minutes, vous devriez voir la mention Activé s'afficher dans la colonne État des clusters de votre parc.

Déployer un package

Après avoir enregistré vos clusters, vous pouvez déployer un package depuis une source de référence vers votre cluster Config Sync. Vous pouvez déployer un package sur plusieurs clusters à la fois et ajouter plusieurs packages à un seul cluster.

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 le type de source Package hébergé sur Git ou Package hébergé sur OCI, puis cliquez sur Continuer.

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

  6. Dans la section Source, renseignez les champs suivants:

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

      1. Saisissez un Package name (Nom de package), qui identifie l'objet RootSync ou RepoSync.
      2. Dans le champ URL du dépôt, saisissez l'URL du dépôt Git que vous utilisez comme source de référence.
      3. Facultatif: mettez à jour le champ Révision pour vérifier si vous n'utilisez pas la valeur par défaut HEAD.
      4. (Facultatif) Mettez à jour le champ Chemin d'accès si vous ne souhaitez pas effectuer la synchronisation à partir du dépôt racine.
      5. 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, renseignez les champs suivants:

      1. Saisissez l'URL de l'image OCI que vous utilisez comme source de référence dans le champ Image.
      2. Dans le champ Directory (Répertoire), saisissez le chemin d'accès au répertoire à partir duquel la synchronisation doit être effectuée, par rapport au répertoire racine.

  7. Dans le champ Sync type (Type de synchronisation), sélectionnez RootSync ou RepoSync comme type de synchronisation.

    Les objets RootSync sont définis à l'échelle d'un cluster, tandis que les objets RepoSync sont définis à l'échelle d'un espace de noms. Pour en savoir plus sur ces objets, consultez la section Champs RootSync et RepoSync.

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

    1. Sélectionnez un type d'authentification:

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

    2. Saisissez un nombre en secondes pour définir le temps d'attente de synchronisation, qui détermine le délai d'attente de Config Sync entre la synchronisation à 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 Hierarchy (Hiérarchie) pour modifier le Source format (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 de référence 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, vous devriez voir la mention Synchronisé dans la colonne État de synchronisation du cluster que vous avez configuré.

  10. Pour mettre à jour un package, dans l'onglet Packages, développez le nom du package que vous souhaitez modifier, puis cliquez sur Edit (Modifier).

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 de 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, puis utiliser 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 d'autres objets RootSync ou RepoSync que vous pourrez gérer entièrement à l'aide des commandes kubectl.

    # 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 :

    • (Preview) UPGRADE_SETTING : défini sur auto pour configurer Config Sync afin qu'il soit mis à niveau automatiquement. 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 disponible que pour les clusters GKE sur Google Cloud.

    • SOURCE_TYPE: ajoutez git pour synchroniser à partir d'un dépôt Git, oci pour effectuer la synchronisation à partir d'une image OCI ou helm pour effectuer une 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 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 des images à l'aide de TAG ou DIGEST à la place. Spécifiez TAG ou DIGEST dans le 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 prévaut 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 par défaut de Compute Engine 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 par défaut de Compute Engine 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 système Google Search Appliance doit disposer du rôle IAM "Rédacteur de métriques de surveillance" (roles/monitoring.metricWriter). Le ServiceAccount Kubernetes default dans l'espace de noms config-management-monitoring doit être lié au système Google Search Appliance.

    • 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

  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 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 au parc que vous avez choisi lors de l'enregistrement de votre cluster. Vous pouvez trouver ce nom à l'aide de 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 pour 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'appartenance.
  • VERSION: (facultatif) numéro de version de Config Sync. Doit être défini sur la version 1.17.0 ou ultérieure. Si aucune valeur n'est spécifiée, 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'appartenance.
  • VERSION: (facultatif) numéro de version de Config Sync. Si aucune valeur n'est spécifiée, 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 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 le dépôt racine configuré, vous pouvez éventuellement choisir de configurer la synchronisation à partir de plusieurs dépôts, y compris d'autres dépôts racines 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 soit synchronisé avec un espace de noms particulier sur plusieurs clusters.

Configurer les valeurs par défaut au niveau du parc

Si vous avez activé Google Kubernetes Engine (GKE) Enterprise Edition, 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 chaque nouveau cluster GKE sur Google Cloud créé dans le parc avec les paramètres que vous spécifiez. 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 parc et configurer la connexion à votre dépôt Git ou 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 Configure (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 (Preview) pour disposer automatiquement des versions de mise à niveau de Config Sync, 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 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, le fait de cliquer sur Confirmer active également l'API anthosconfigmanagement.googleapis.com.

Terraform

  1. Créez un répertoire pour les fichiers Terraform de configuration par défaut du parc. Dans ce répertoire, ajoutez un fichier main.tf contenant 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 aucune valeur n'est spécifiée, 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 sur 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 aucune valeur n'est spécifiée, 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 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 sur 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 du parc par défaut:

    terraform apply

Si vous souhaitez mettre à jour des clusters existants pour utiliser vos paramètres Config Sync par défaut, utilisez la console Google Cloud pour synchroniser les clusters de votre parc sélectionnés avec les paramètres 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 paramètres 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 par défaut de Config Sync dans votre parc, procédez comme suit:

  1. Accédez au Gestionnaire de fonctionnalités:

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

  2. Dans la table des clusters, 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 seront appliqués à tous les clusters que vous sélectionnez. Bien que la console Google Cloud n'affiche qu'un sous-ensemble de paramètres, comme 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 dans la section Fonctionnalités.

    Accéder à Config

  2. Dans l'onglet Packages, consultez la colonne État de synchronisation dans la table des clusters. Une installation réussie de Config Sync indique l'état Installée. Une source de référence correctement configurée affiche l'état Synchronisé.

gcloud

Exécutez la commande ci-dessous.

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 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 des accès basés sur les rôles (RBAC) et autorisations

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

Composant Espace de noms Compte de service Autorisations Description
ConfigManagement Operator config-management-system config-management-operator cluster-admin ConfigManagement Operator installe les autres composants de cette table. Certains de ces composants nécessitent des autorisations d'administrateur de cluster. ConfigManagement Operator les requiert donc également.
Config Sync config-management-system Consultez Autorisations 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 prévention de la dérive est activée.
  • un reconciler est installé pour chaque RootSync et 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.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 100
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, lorsque vous calculez 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 100
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, lorsque vous calculez 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.15

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 100
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, lorsque vous calculez 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 afin de gérer la synchronisation. Le déploiement du rapprochement se compose de plusieurs conteneurs. Pour en savoir plus sur ces conteneurs, consultez la section Rapprocher des conteneurs.

Dans Config Sync version 1.17.0 et 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.

Clusters standards

1.17

Nom du conteneur Demande de processeur (m) Demande de mémoire (Mio)
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 (Mio)
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

1.15

Nom du conteneur Demande de processeur (m) Demande de mémoire (Mio)
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.17

Nom du conteneur Demande et limite de processeur (m) Demande et limite de mémoire (Mio)
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.

1.15

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.16.0 et versions ultérieures v3.11.3 v5.1.1
1.15.0 à 1.15.3 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