Installer Config Sync manuellement à l'aide de kubectl (non recommandé)

Cette page vous explique comment installer Config Sync à l'aide des commandes kubectl. Config Management Operator est un contrôleur qui gère Config Sync dans un cluster Kubernetes. Suivez cette procédure pour installer et configurer l'opérateur dans chaque cluster que vous souhaitez gérer à l'aide de Config Sync.

Attention : Les méthodes d'installation utilisées sur cette page ne sont pas recommandées, car elles ne sont pas compatibles avec la console Google Cloud ni avec Google Cloud CLI.

Avant de commencer

Cette section décrit les conditions préalables que vous devez remplir avant d'installer Config Sync à l'aide de kubectl.

Préparer votre environnement local

Avant d'installer l'opérateur, assurez-vous d'avoir préparé votre environnement local en effectuant les tâches suivantes :

• Accédez à une source de référence ou créez-en une.

• Installez et initialisez Google Cloud CLI, qui fournit les commandes gcloud, kubectl et nomos utilisées dans les présentes instructions. Si vous utilisez Cloud Shell, Google Cloud CLI est préinstallé.

• kubectl n'est pas installé par défaut par Google Cloud CLI. Pour installer kubectl, utilisez la commande suivante :

  gcloud components install kubectl
  

• Authentifiez-vous auprès de Google Cloud à l'aide de la commande gcloud auth login afin de pouvoir télécharger les composants de Config Sync.

Préparer vos clusters

Créez ou accédez à un cluster Google Kubernetes Engine (GKE) Enterprise Edition répondant aux exigences de Config Sync.

Préparer les autorisations

L'utilisateur Google Cloud qui installe Config Sync doit disposer d'autorisations IAM pour créer des rôles dans votre cluster. Si nécessaire, attribuez ces rôles avec les commandes suivantes :

gcloud container clusters get-credentials CLUSTER_NAME

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user USER_ACCOUNT

Remplacez l'élément suivant :

• CLUSTER_NAME : nom de votre cluster
• USER_ACCOUNT : adresse e-mail de votre compte Google Cloud

En fonction de la configuration de Google Cloud CLI sur votre système local, vous devrez peut-être ajouter les champs --project et --zone.

Si vous devez accorder à l'opérateur l'accès à OCI en utilisant gcpserviceaccount comme type d'authentification, pour créer une liaison de stratégie, vous devez également disposer de l'autorisation iam.serviceAccounts.setIamPolicy. Vous pouvez obtenir cette autorisation en attribuant le rôle IAM Administrateur de compte de service (roles/iam.serviceAccountAdmin). Vous pouvez également obtenir cette autorisation avec des rôles personnalisés ou d'autres rôles prédéfinis.

Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Enregistrer un cluster

Pour enregistrer un cluster dans Config Sync, procédez comme suit :

1. Déployez l'opérateur.
2. Accordez à l'opérateur un accès en lecture seule à l'un des éléments suivants :
   • Git
   • OCI
   • Helm
3. Configurez l'opérateur.

Déployer l'opérateur

Après avoir vérifié que vous remplissez toutes les conditions préalables, vous pouvez déployer l'opérateur en téléchargeant et en appliquant un fichier manifeste YAML.

1. Téléchargez la dernière version du fichier manifeste Operator à l'aide de la commande ci-dessous. Pour télécharger une version spécifique, consultez la section Téléchargements.

   gcloud storage cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml
   

2. Appliquez les fichiers manifestes :

   kubectl apply -f config-management-operator.yaml

Si cette opération échoue en raison d'un problème avec l'objet ConfigManagement qui n'est pas dû à une erreur de syntaxe YAML ou JSON, l'objet peut être instancié dans le cluster, mais peut ne pas fonctionner correctement. Dans ce cas, vous pouvez utiliser la commande nomos status pour rechercher les erreurs dans l'objet.

Une installation valide sans problème affiche l'état PENDING ou SYNCED.

Une installation non valide affiche l'état NOT CONFIGURED et répertorie l'une des erreurs suivantes :

• missing git-creds Secret
• missing required syncRepo field
• git-creds Secret is missing the key specified by secretType

Pour résoudre le problème, corrigez l'erreur de configuration. Selon le type d'erreur, vous devrez peut-être réappliquer le fichier manifeste ConfigManagement au cluster.

Si le problème concerne la création du secret git-creds, Config Sync détecte le secret dès sa création et vous n'avez pas besoin d'appliquer à nouveau la configuration.

Accorder à l'opérateur un accès en lecture seule

Si vous stockez vos configurations dans Git, vous devez accorder à l'opérateur un accès en lecture seule à Git. Si vous stockez vos configurations en tant qu'images OCI, vous devez accorder à l'opérateur un accès en lecture seule à OCI. Si vous stockez vos configurations dans Helm, vous devez accorder à l'opérateur un accès en lecture seule à Helm.

Accorder à l'opérateur un accès en lecture seule à Git

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

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

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

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

• Paire de clés SSH (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.

Avertissement : Protégez les fichiers créés par cette commande. Ils permettent de lire les données de votre dépôt.

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.

   Remarque : Vous devez créer la clé SSH sans phrase secrète. Config Sync n'est pas compatible avec les phrases secrètes SSH.

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 :

   • Cloud Source Repositories
   • Bitbucket
   • GitHub Nous vous recommandons de créer des clés de déploiement distinctes afin de fournir un accès en lecture seule à un seul dépôt GitHub.
   • GitLab

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://[e-mail]: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

Remarque : Les identifiants cookiefile ne peuvent être utilisés qu'avec Cloud Source Repositories. Si vous souhaitez utiliser GitHub avec l'authentification cookiefile, vous pouvez mettre en miroir votre dépôt GitHub à l'aide de Cloud Source Repositories.

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
   Remarque : Pour des raisons de sécurité, le proxy HTTP n'est pas accepté.

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 :

   • GitHub : créez un PAT. Attribuez-lui le champ d'application repo afin qu'il puisse lire les données des dépôts privés. Comme vous liez un jeton d'accès personnel à un compte GitHub, nous vous recommandons par la même occasion de créer un utilisateur machine et de lui associer votre PAT.
   • GitLab : créez un PAT ou créez un jeton de déploiement
   • Bitbucket : créez un mot de passe d'application.

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
   Remarque : Pour des raisons de sécurité, le proxy HTTP n'est pas accepté.

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 Workload Identity Federation for GKE ou Workload Identity Federation for GKE pour le 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 disposent de 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 la console Google Cloud, sélectionnez Workload Identity Federation for GKE 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 Federation for GKE. 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 la fédération d'identité de charge de travail GKE pour GKE, cette valeur est identique à PROJECT_ID. Si vous utilisez la Workload Identity Federation for GKE pour votre parc, il s'agit de l'ID du projet 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.

Remarque : La création de cette liaison de stratégie nécessite l'autorisation iam.serviceAccounts.setIamPolicy.

Compte de service Compute Engine par défaut

Si votre dépôt se trouve dans Cloud Source Repositories et que votre cluster est un cluster GKE avec la fonctionnalité Workload Identity Federation for GKE désactivée, 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:[e-mail]"

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'opérateur 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 qu'il puisse 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 Workload Identity Federation for GKE ou Workload Identity Federation for GKE pour le parc, vous pouvez utiliser k8sserviceaccount comme type d'authentification dans les versions 1.17.2 et ultérieures. Cette option est recommandée à la place de 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 Federation for GKE. 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: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 disposent de 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 la fédération d'identité de charge de travail GKE pour GKE, cette valeur est identique à PROJECT_ID. Si vous utilisez la Workload Identity Federation for GKE pour votre parc, il s'agit de l'ID du projet 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.
   Remarque : La création de cette liaison de stratégie nécessite l'autorisation iam.serviceAccounts.setIamPolicy.

Compte de service Google

Si vous stockez votre image OCI dans Artifact Registry et que votre cluster utilise Workload Identity Federation for GKE ou Workload Identity Federation for GKE pour le parc, vous pouvez utiliser gcpserviceaccount comme type d'authentification. À partir de la version 1.17.2, nous vous recommandons 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 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 disposent de 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 la fédération d'identité de charge de travail GKE pour GKE, cette valeur est identique à PROJECT_ID. Si vous utilisez la Workload Identity Federation for GKE pour votre parc, il s'agit de l'ID du projet 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.

Remarque : La création de cette liaison de stratégie nécessite l'autorisation iam.serviceAccounts.setIamPolicy.

Compte de service Compute Engine par défaut

Si vous stockez votre chart Helm dans Artifact Registry et que votre cluster est un cluster GKE avec la fonctionnalité Workload Identity Federation for GKE désactivée, 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:[e-mail] \
      --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 l'opérateur pour une autorité de certification

Pour les serveurs configurés avec des certificats provenant d'une autorité de certification (CA) qui n'est pas déjà approuvée, Config Sync peut être configuré pour utiliser un certificat CA afin de vérifier les connexions HTTPS au serveur. Cette fonctionnalité est compatible avec les serveurs Git, Helm ou OCI. Le certificat de l'autorité de certification doit inclure des certificats SSL complets (racine/intermédiaire/feuille). Si votre serveur utilise déjà une autorité de certification de confiance ou si vous ne vous connectez pas via HTTPS, vous pouvez ignorer cette étape et laisser caCertSecretRef non défini.

RootSync

1. Récupérer le certificat de l'autorité de certification qui a été utilisé pour émettre le certificat de votre serveur Git et l'enregistrer dans un fichier.

2. Pour les objets RootSync, le secret doit être créé dans l'espace de noms config-management-system. Exemple :

   kubectl create ns config-management-system && 
   
   kubectl create secret generic ROOT_CA_CERT_SECRET_NAME 
   
    --namespace=config-management-system 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. Lorsque vous configurez l'opérateur, définissez la valeur du champ caCertSecretRef.name dans l'objet RootSync sur ROOT_CA_CERT_SECRET_NAME.

RepoSync

1. Récupérez le certificat CA utilisé pour émettre le certificat de votre serveur Git et enregistrez-le dans un fichier.

2. Pour les objets RepoSync, le secret doit être créé dans le même espace de noms que RepoSync. Exemple :

   kubectl create ns REPO_SYNC_NAMESPACE && 
   
   kubectl create secret generic NAMESPACE_CA_CERT_SECRET_NAME 
   
    --namespace=REPO_SYNC_NAMESPACE 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. Lorsque vous configurez RepoSync, définissez la valeur du champ caCertSecretRef.name dans l'objet RepoSync sur NAMESPACE_CA_CERT_SECRET_NAME.

Accorder à l'opérateur 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)

Remarque : Config Sync ne permet pas de configurer helm en tant que type de source à l'aide de la console Google Cloud ou de Google Cloud CLI. Vous pouvez configurer la synchronisation de votre objet RootSync ou RepoSync à partir d'un dépôt Helm à l'aide de l'API Kubernetes, ou le déclarer dans une autre source fiable. Pour en savoir plus, consultez la section Configuration pour le dépôt Helm.

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 Workload Identity Federation for GKE ou Workload Identity Federation for GKE pour le parc, vous pouvez utiliser k8sserviceaccount comme type d'authentification dans les versions 1.17.2 et ultérieures. Cette option est recommandée à la place de 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 Federation for GKE. 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: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 disposent de 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 la fédération d'identité de charge de travail GKE pour GKE, cette valeur est identique à PROJECT_ID. Si vous utilisez la Workload Identity Federation for GKE pour votre parc, il s'agit de l'ID du projet 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.

Remarque : La création de cette liaison de stratégie nécessite l'autorisation iam.serviceAccounts.setIamPolicy.

Compte de service Google

Si vous stockez votre chart Helm dans Artifact Registry et que votre cluster utilise la Workload Identity Federation for GKE ou Workload Identity Federation for GKE pour le parc, vous pouvez utiliser gcpserviceaccount comme type d'authentification. À partir de la version 1.17.2, nous vous recommandons 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 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 disposent de 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 la fédération d'identité de charge de travail GKE pour GKE, cette valeur est identique à PROJECT_ID. Si vous utilisez la Workload Identity Federation for GKE pour votre parc, il s'agit de l'ID du projet 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.

Remarque : La création de cette liaison de stratégie nécessite l'autorisation iam.serviceAccounts.setIamPolicy.

Compte de service Compute Engine par défaut

Si vous stockez votre chart Helm dans Artifact Registry et que votre cluster est un cluster GKE avec la fonctionnalité Workload Identity Federation for GKE désactivée, 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:[e-mail] \
       --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 l'opérateur

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

1. Si vous utilisez le webhook d'admission Config Sync (le webhook d'admission est désactivé par défaut) et que vous installez Config Sync dans un cluster privé, ajoutez une règle de pare-feu pour autoriser le port 10250. Le webhook d'admission Config Sync utilise le port 10250 pour prévenir les dérives.

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

   # config-management.yaml
   apiVersion: configmanagement.gke.io/v1
   kind: ConfigManagement
   metadata:
     name: config-management
   spec:
     # The `enableMultiRepo` field is set to true to enable RootSync and RepoSync APIs.
     enableMultiRepo: true
     preventDrift: PREVENT_DRIFT
   

   Remplacez les éléments suivants :

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

3. Appliquez les modifications :

   kubectl apply -f config-management.yaml
   

4. Attendez que les CRD RootSync et RepoSync soient disponibles :

   until kubectl get customresourcedefinitions rootsyncs.configsync.gke.io reposyncs.configsync.gke.io; do date; sleep 1; echo ""; done
   

5. Enregistrez l'un des fichiers manifestes suivants sous le nom root-sync.yaml. Utilisez la version du fichier manifeste correspondant au type de source de vos configurations.

   Git

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: git
     sourceFormat: ROOT_FORMAT
     git:
       repo: ROOT_REPOSITORY
       revision: ROOT_REVISION
       branch: ROOT_BRANCH
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       secretRef:
         name: ROOT_SECRET_NAME
       noSSLVerify: ROOT_NO_SSL_VERIFY
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Remplacez les éléments suivants :

   • ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
   • ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
   • ROOT_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Ce champ est obligatoire.
   • ROOT_REVISION : ajoutez la révision Git (tag ou valeur de 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 revision. 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 forme abrégée.
   • ROOT_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master. À partir de la version 1.17.0 de Config Sync, il est recommandé d'utiliser le champ revision afin de spécifier un nom de branche pour plus de simplicité. Si les champs revision et branch sont spécifiés, revision est prioritaire sur branch.
   • ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.

   • ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

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

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

     Ce champ est obligatoire.

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

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

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

   • ROOT_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Git doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.

     Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.

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

   Ce fichier manifeste crée un objet RootSync qui utilise Git comme source.

   OCI

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: oci
     sourceFormat: ROOT_FORMAT
     oci:
       image: ROOT_IMAGE
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Remplacez les éléments suivants :

   • ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
   • ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
   • ROOT_IMAGE : URL de l'image OCI à utiliser comme dépôt racine, par exemple 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

   Attention : Config Sync nécessite que la couche OCI soit compressée dans le fichier tar ou tar+gzip. Les autres formats (par exemple, tar+bz2) ne seront pas reconnus par Config Sync. Le passage d'un dépôt valide à une image OCI avec un format non compatible entraînera l'élimination des ressources gérées sans erreur.

   • ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.

   • ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

     • none : n'utiliser aucune authentification
     • 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 Federation for GKE n'est pas activé dans votre cluster.
     • gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.

     Ce champ est obligatoire.

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

   • ROOT_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur OCI doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.

   Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.

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

   Ce fichier manifeste crée un objet RootSync qui utilise une image OCI comme source.

   Helm

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: helm
     sourceFormat: ROOT_FORMAT
     helm:
       repo: ROOT_HELM_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: ROOT_AUTH_TYPE
         gcpServiceAccountEmail: ROOT_EMAIL
         secretRef:
           name: ROOT_SECRET_NAME
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

   Remplacez les éléments suivants :

   • ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
   • ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
   • ROOT_HELM_REPOSITORY : URL du dépôt Helm à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Ce champ est obligatoire.
   • HELM_CHART_NAME : ajoutez le nom de votre chart Helm. Ce champ est obligatoire.
   • HELM_CHART_VERSION : version de votre chart. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la dernière version est utilisée.
   • HELM_RELEASE_NAME : nom de la version de Helm. Ce champ est facultatif.
   • HELM_RELEASE_NAMESPACE : espace de noms cible d'une version. Il ne définit un espace de noms que pour les ressources dont les modèles contiennent namespace: {{ .Release.Namespace }}. Ce champ est facultatif. Si aucune valeur n'est spécifiée, l'espace de noms par défaut config-management-system est utilisé.
   • HELM_INCLUDE_CRDS : définissez cette valeur sur true si vous souhaitez que le modèle Helm génère également un objet CustomResourceDefinition. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la valeur par défaut est false et aucun objet CRD n'est généré.
   • VALUE : valeurs à utiliser à la place des valeurs par défaut qui accompagnent le chart Helm. Mettez en forme ce champ de la même manière que le fichier values.yaml du chart Helm. Ce champ est facultatif.

   • ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

     • none : n'utiliser aucune authentification
     • token : utilisez un nom d'utilisateur et un mot de passe pour accéder à un dépôt Helm privé.
     • 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 Federation for GKE n'est pas activé dans votre cluster.
     • gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.

     Ce champ est obligatoire.

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

   • ROOT_SECRET_NAME : ajoutez le nom de votre secret si token est le ROOT_AUTH_TYPE. Ce champ est facultatif.

   • ROOT_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Helm doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.

   Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.

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

   Ce fichier manifeste crée un objet RootSync qui utilise Helm comme source.

6. Appliquez les modifications :

   kubectl apply -f root-sync.yaml
   

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

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

nomos status

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

my_managed_cluster-1
  --------------------
  <root>   [e-mail]:foo-corp/acme/admin@main
  SYNCED   f52a11e4

Vérifier l'installation de RootSync

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

Vous pouvez vérifier que l'objet RootSync fonctionne correctement en vérifiant l'état du déploiement du rapprochement racine :

kubectl get -n config-management-system deployment \
    -l configsync.gke.io/sync-name=ROOT_SYNC_NAME

Remplacez ROOT_SYNC_NAME par le nom de RootSync.

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

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

Pour découvrir d'autres moyens d'explorer l'état de votre objet RootSync, consultez la page Surveiller les objets RootSync et RepoSync.

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. Ces dépôts 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.

Mettre à jour Config Sync

Remarque : La mise à niveau à partir d'une version antérieure à la version 1.10.0 supprime toutes les ressources de webhook d'admission Config Sync.

Remarque : Si vous effectuez une mise à niveau à partir d'une version non compatible, vous devez effectuer une mise à niveau détaillée par incréments de trois versions mineures maximum à la fois. Par exemple, si la version actuelle de Config Sync est 1.11.0, passez d'abord à la version 1.14.0, puis à la version 1.17.0.

Pour mettre à jour Config Sync, exécutez les commandes suivantes pour chaque cluster enregistré :

1. Téléchargez le fichier manifeste et les commandes nomos de Config Sync pour la nouvelle version.

2. Appliquez le fichier manifeste de Config Sync :

   kubectl apply -f config-management-operator.yaml
   

   Cette commande met à jour l'image de l'opérateur ConfigManagement. Kubernetes récupère la nouvelle version et l'utilise pour redémarrer le pod Config Sync. Lorsque Config Sync démarre, il exécute une boucle de rapprochement qui applique l'ensemble des fichiers manifestes regroupés dans la nouvelle image. Cette opération met à jour et redémarre chaque pod de composant.

3. Remplacez la commande nomos par la nouvelle version sur tous les clients. Cette modification garantit que la commande nomos peut toujours obtenir l'état de tous les clusters enregistrés et valider les configurations correspondantes.

Désinstaller Config Sync

Attention : La suppression d'un objet RootSync ou RepoSync ne nettoie pas les annotations et les libellés Config Sync, et le webhook d'admission Config Sync refuse les requêtes essayant de supprimer ces ressources si Config Sync est toujours activé dans le cluster. La solution consiste à annuler la gestion ou la suppression de ces ressources gérées avant de supprimer l'objet RootSync ou RepoSync correspondant.

Pour désinstaller Config Sync, procédez comme suit :

1. Un administrateur central doit supprimer le dépôt racine :

   1. Si vous avez activé le webhook et que vous souhaitez conserver vos ressources, désactivez la protection contre les dérives pour les ressources abandonnées. Si vous n'avez pas activé le webhook, vous n'avez pas besoin d'effectuer des étapes supplémentaires pour conserver vos ressources.

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

      kubectl delete -f root-sync.yaml
      

2. Supprimez tous les dépôts.

3. Supprimez le champ spec.enableMultiRepo de votre fichier config-management.yaml.

4. Appliquez votre fichier config-management.yaml à votre cluster.

Remarque : La désactivation de cette fonctionnalité n'a pas d'incidence sur les configurations précédemment appliquées par Config Sync à vos clusters.

Si vous souhaitez désinstaller complètement Config Sync, consultez la section Supprimer ConfigManagement Operator.

Étapes suivantes

• Découvrez comment configurer la synchronisation à partir de plusieurs dépôts.