Installer Config Sync

Config Sync permet aux opérateurs de cluster de gérer des ressources Kubernetes à l'aide de fichiers, appelés configurations, stockés dans des dépôts Git.

Cette page vous explique comment activer et configurer Config Sync au sein d'Anthos Config Management. Procédez comme suit pour installer et configurer Anthos Config Management dans chaque cluster que vous souhaitez gérer.

Avant de commencer

Avant d'installer Config Sync, assurez-vous d'avoir préparé votre environnement, vos clusters et vos rôles, et d'avoir activé Anthos Config Management.

Préparer votre environnement local

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

  1. Activez l'API Anthos pour votre projet :

    Console

    Dans Google Cloud Console, accédez à la page de l'API Anthos.

    Accéder à la page de l'API Anthos

    • Cliquez sur Activer.

    gcloud

    Exécutez la commande suivante :

    gcloud services enable anthos.googleapis.com
    
  2. Installez et initialisez le SDK Cloud, qui fournit les commandes gcloud, gsutil, kubectl et nomos utilisées dans les présentes instructions. Si vous utilisez Cloud Shell, le SDK Cloud est pré-installé.

  3. kubectl n'est pas installé par défaut par le SDK Cloud. Pour installer kubectl, exécutez la commande suivante :

    gcloud components install kubectl
    
  4. Exécutez la commande gcloud auth login pour vous authentifier auprès de Google Cloud et télécharger les composants d'Anthos Config Management.

Préparer le cluster

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

  1. Vérifiez que votre cluster utilise une plate-forme et une version compatibles d'Anthos.

  2. Enregistrez votre cluster dans un environ Anthos à l'aide de Connect. L'environnement de votre projet fournit un moyen unifié de visualiser et de gérer vos clusters et leurs charges de travail au sein d'Anthos, y compris les clusters situés en dehors de Google Cloud. Les frais d'Anthos s'appliquent uniquement à vos clusters enregistrés.

Préparer les autorisations

Selon la méthode d'installation employée, vous devez accorder différentes autorisations à l'utilisateur qui installe Config Sync. Pour savoir comment accorder des rôles Identity and Access Management (IAM), consultez la page Accorder, modifier et révoquer les accès à des ressources.

Console

L'utilisateur Google Cloud qui installe Config Sync doit disposer du rôle Administrateur GKE Hub (roles/gkehub.admin) pour administrer votre cluster via l'API Hub.

gcloud

L'utilisateur Google Cloud qui installe Config Sync doit disposer du rôle Administrateur GKE Hub (roles/gkehub.admin) pour administrer votre cluster via l'API Hub.

kubectl

Si vous utilisez GKE, l'utilisateur Google Cloud qui installe Config Sync doit disposer d'autorisations IAM pour créer des rôles dans votre cluster.

Exemple :

gcloud container clusters get-credentials CLUSTER_NAME

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

Remplacez les éléments suivants :

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

Selon la façon dont vous avez configuré l'outil de ligne de commande gcloud sur votre système local, vous devrez peut-être ajouter les champs --project et --zone.

Activer Anthos Config Management

Si vous utilisez Anthos Config Management pour la première fois, activez la fonctionnalité en procédant comme suit :

Console

  1. Dans Google Cloud Console, accédez à la page Fonctionnalités d'Anthos.

    Accéder à la page "Fonctionnalités" d'Anthos

  2. Sur la ligne Config Management, cliquez sur Activer.

  3. Dans la fenêtre de confirmation, cliquez sur Activer Config Management.

gcloud

Exécutez la commande suivante :

 gcloud alpha container hub config-management enable

Installer Config Sync

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

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

Config Sync a besoin d'un accès en lecture seule à votre dépôt Git pour pouvoir lire les configurations validées dans le dépôt et les appliquer à vos clusters. Si des identifiants sont nécessaires, ils sont stockés dans le secret git-creds sur chaque cluster inscrit.

Si votre dépôt ne nécessite pas d'authentification pour un accès en lecture seule, vous pouvez continuer à configurer Config Sync et définir secretType sur none. 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 git-creds.

Cependant, la plupart des utilisateurs doivent créer des identifiants, car l'accès en lecture à leur dépôt est limité. Config Sync accepte les mécanismes d'authentification suivants :

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

Le mécanisme choisi dépend des éléments compatibles avec votre dépôt. Si tous les mécanismes sont disponibles, nous vous recommandons d'utiliser une paire de clés SSH. GitHub, Cloud Source Repositories et Bitbucket permettent tous d'utiliser une paire de clés SSH. Si votre organisation héberge votre dépôt et que vous ne savez pas quelles méthodes d'authentification sont compatibles, contactez votre administrateur.

Paire de clés SSH

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

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

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

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

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

    Remplacez les éléments suivants :

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

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

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

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

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

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

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

Fichier de cookie

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

Pour utiliser un cookiefile, procédez comme suit :

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

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

    Remplacez /path/to/COOKIEFILE par le chemin d'accès et le nom de fichier appropriés.

  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 ou 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 ou de 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.

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

    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
  3. Protégez le jeton si vous en avez toujours besoin en local. Dans le cas contraire, supprimez-le.

Compte de service Google

Si votre dépôt se trouve dans Cloud Source Repositories, vous pouvez utiliser secretType: gcenode pour autoriser Config Sync à accéder à un dépôt du même projet que votre cluster géré.

Prérequis

Avant de commencer, vérifiez que les conditions préalables suivantes sont remplies :

  • Les niveaux d'accès pour les nœuds du cluster doivent inclure cloud-source-repos-ro. De base, le compte de service Compute Engine par défaut PROJECT_ID-compute@developer.gserviceaccount.com dispose d'un accès source.reader au dépôt du même projet. Si nécessaire, vous pouvez toutefois ajouter le rôle à l'aide de la commande suivante :

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

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de projet de votre organisation
    • PROJECT_NUMBER : numéro de projet de votre organisation
  • Les niveaux d'accès pour les nœuds du cluster doivent inclure cloud-source-repos-ro. Vous pouvez ajouter ce champ d'application 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 :

    gcloud container clusters create example-cluster --scopes=cloud-platform
    

Utiliser Cloud Source Repositories en tant qu'objet SyncRepo

Une fois ces conditions préalables remplies, définissez spec.git.syncRepo pour l'URL du dépôt souhaité dans Cloud Source Repositories lorsque vous configurez Config Sync.

Pour utiliser un dépôt dans Cloud Source Repositories en tant qu'objet SyncRepo, procédez comme suit :

  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 :

    REPO_NAME  PROJECT_ID  URL
    my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr
    
  3. Ajoutez l'URL en tant que syncRepo. Exemple :

    spec.git.syncRepo: https://source.developers.google.com/p/my-project/r/my-repo-csr
    

Utiliser Cloud Source Repositories avec Workload Identity

Si Workload Identity est activé sur votre cluster, des étapes supplémentaires sont nécessaires pour utiliser secretType: gcenode. Après avoir suivi les étapes précédentes et configuré Config Sync (voir la section suivante), 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.

Cette liaison permet au compte de service Config Sync Kubernetes de fonctionner en tant que compte de service Compute Engine par défaut :

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

Remplacez les valeurs suivantes : * PROJECT_ID : ID de projet de votre organisation * PROJECT_NUMBER : numéro de projet de votre organisation

Après avoir créé la liaison, ajoutez une annotation au compte de service Config Sync Kubernetes en utilisant l'adresse e-mail du compte de service Compute Engine par défaut :

kubectl annotate serviceaccount -n config-management-system importer \
  iam.gke.io/gcp-service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com

Remplacez PROJECT_NUMBER par le numéro de projet de votre organisation.

Configurer Config Sync

Google Cloud Console vous guide tout au long du processus d'installation et automatise un grand nombre de ces étapes. Vous pouvez également exploiter l'outil de ligne de commande gcloud ou les commandes kubectl pour terminer l'installation.

Si vous utilisez un cluster GKE, nous vous recommandons de configurer Config Sync à l'aide de Cloud Console. Si vous utilisez un cluster Anthos clusters on VMware, vous devez exécuter des commandes kubectl pour installer Config Sync, car les registres privés ne sont pas compatibles avec Cloud Console ou l'outil gcloud.

Pour configurer Config Sync, procédez comme suit :

Console

  1. Dans Cloud Console, accédez à la page Anthos Config Management.

    Accéder à la page "Anthos Config Management"

  2. Sélectionnez les clusters enregistrés, puis cliquez sur Configurer.

  3. Dans la section Authentification auprès du dépôt Git pour ACM, sélectionnez l'une des options suivantes :

    • Néant
    • SSH
    • Fichier de cookie
    • Jeton
    • Google Cloud Repository

    Si ce n'est pas déjà fait, accordez à Config Sync un accès en lecture seule à Git.

  4. Cliquez sur Continuer.

  5. Dans la section Paramètres ACM pour vos clusters, procédez comme suit :

    1. Dans le champ Version, sélectionnez la version d'Anthos Config Management.
    2. Cochez la case Activer Config Sync.
      1. Dans le champ URL, saisissez l'URL du dépôt Git à utiliser comme source fiable. Ce champ est obligatoire.
      2. Dans le champ Branche, saisissez la branche du dépôt à partir de laquelle s'effectue la synchronisation. La branche par défaut est la branche principale (maître).
      3. Dans le champ Tag/Commit, saisissez la révision Git (tag ou valeur de hachage) à extraire. La valeur par défaut est HEAD.
      4. Dans le champ Répertoire des règles, ajoutez le chemin d'accès au sein du dépôt en haut de la hiérarchie des règles à synchroniser. La valeur par défaut est le répertoire racine du dépôt.
      5. Dans le champ Délai entre les synchronisations, saisissez le délai en secondes entre les synchronisations consécutives. La valeur par défaut est de 15 secondes.
      6. Dans le champ Proxy Git, saisissez l'URL du proxy HTTPS à utiliser lors de la communication avec le dépôt Git. Ce champ est facultatif et, s'il est vide, aucun proxy n'est utilisé.
      7. Dans le champ Format source, indiquez si le dépôt est une hiérarchie ou est non structuré.
  6. Cliquez sur OK. Vous êtes redirigé vers la page Anthos Config Management. Après quelques minutes, Synced devrait s'afficher dans la colonne d'état à côté des clusters que vous avez configurés. Si vous voyez Error, cliquez sur le mot Error pour plus d'informations.

gcloud

  1. 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:
      git:
        syncRepo: REPO
        syncBranch: BRANCH
        secretType: TYPE
        policyDir: "DIRECTORY"
    

    Remplacez les éléments suivants :

    • REPO : URL du dépôt Git à utiliser comme source fiable. Ce champ est obligatoire.
    • BRANCH : branche du dépôt à partir de laquelle la synchronisation doit être effectuée. La branche par défaut est la branche principale (maître).
    • TYPE : l'une des options SecretTypes suivantes :

      • none
      • ssh
      • cookiefile
      • token
      • gcenode
    • DIRECTORY : chemin d'accès au sommet de la hiérarchie des stratégies à synchroniser dans le dépôt. La valeur par défaut est le répertoire racine du dépôt.

      Pour obtenir la liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Configuration pour le dépôt Git. Ne modifiez pas les valeurs de configuration en dehors du champ "spec".

  2. Appliquez le fichier config-management.yaml :

     gcloud alpha container hub config-management apply \
         --membership=CLUSTER_NAME \
         --config=CONFIG_YAML_PATH \
         --project=PROJECT_ID
    

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster enregistré auquel vous souhaitez appliquer cette configuration
    • CONFIG_YAML_PATH : chemin d'accès à votre fichier config-management.yaml
    • PROJECT_ID : ID de votre projet.

kubectl

Lorsque vous installez Config Sync avec kubectl, vous devez déployer l'opérateur avant de pouvoir le configurer. L'opérateur est un contrôleur qui gère Config Sync dans un cluster Kubernetes.

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 de la définition de ressource personnalisée (CRD) de l'opérateur à l'aide de la commande suivante. Pour télécharger une version spécifique, consultez la section Téléchargements.

    gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml
    
  2. Appliquez l'objet CRD :

    kubectl apply -f config-management-operator.yaml

Si cette commande échoue, consultez la section Dépannage.

Configurer Anthos Config Management

Pour configurer le comportement d'Anthos Config Management, créez un fichier de configuration pour la ressource personnalisée ConfigManagement, puis appliquez-le à l'aide de la commande kubectl apply :

  1. Créez un fichier nommé config-management.yaml et copiez-y le fichier YAML ci-dessous :

    # config-management.yaml
    
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      # clusterName is required and must be unique among all managed clusters
      clusterName: CLUSTER_NAME
      git:
        syncRepo: REPO
        syncBranch: BRANCH
        secretType: TYPE
        policyDir: "DIRECTORY"
    

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster enregistré auquel vous souhaitez appliquer cette configuration.
    • REPO : URL du dépôt Git à utiliser comme source fiable. Ce champ est obligatoire.
    • BRANCH : branche du dépôt à partir de laquelle la synchronisation doit être effectuée. La branche par défaut est la branche principale (maître).
    • TYPE : l'une des options SecretTypes suivantes :

      • none
      • ssh
      • cookiefile
      • token
      • gcenode
    • DIRECTORY : chemin d'accès au sommet de la hiérarchie des stratégies à synchroniser dans le dépôt. La valeur par défaut est le répertoire racine du dépôt.

    Pour obtenir la liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Configuration pour le dépôt Git. Ne modifiez pas les valeurs de configuration en dehors du champ "spec".

  2. Appliquez la configuration à l'aide de la commande kubectl apply :

    kubectl apply -f config-management.yaml
    

    Vous devrez peut-être créer des fichiers de configuration distincts pour chaque cluster ou chaque type de cluster. Vous pouvez spécifier le cluster à l'aide de l'option --context :

    kubectl apply -f config-management1.yaml --context=CLUSTER_NAME
    

    Remplacez CLUSTER_NAME par le nom du cluster que vous souhaitez utiliser.

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

  1. Dans Cloud Console, accédez à la page Anthos Config Management.

    Accéder à la page "Anthos Config Management"

  2. Affichez la colonne État. Une installation réussie passe à l'état Synced.

Pour obtenir une vue détaillée de l'état d'un cluster, procédez comme suit :

  • Sélectionnez le cluster que vous souhaitez explorer. La page Détails du cluster s'affiche. Sur cette page, vous pouvez afficher les détails de votre cluster ainsi que les détails de votre installation Config Sync.

gcloud

Exécutez la commande suivante :

gcloud alpha container hub config-management status
    --project=PROJECT_ID

Remplacez PROJECT_ID par l'ID de votre projet.

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

gcloud alpha container hub config-management apply

kubectl

Pour vérifier si Config Sync est correctement installé, vous pouvez utiliser la commande nomos status. 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.

Lorsque Config Sync a bien été déployé, il s'exécute dans un pod dont le nom commence par config-management-operator, dans l'espace de noms kube-system. L'initialisation du pod peut prendre quelques instants.

Vérifiez qu'il est en cours d'exécution :

kubectl -n kube-system get pods | grep config-management

Si le pod est en cours d'exécution, la réponse de la commande est semblable à l'exemple suivant :

config-management-operator-6f988f5fdd-4r7tr 1/1 Running 0 26s

Vous pouvez également vérifier que l'espace de noms config-management-system existe :

kubectl get ns | grep 'config-management-system'

Le résultat de la commande ressemble à l'exemple suivant :

config-management-system Active 1m

Si les commandes ne renvoient pas de résultats semblables à l'exemple précédent, consultez les journaux pour identifier le problème :

kubectl -n kube-system logs -l k8s-app=config-management-operator

Vous pouvez également utiliser kubectl get events pour vérifier si Config Sync a généré des événements.

kubectl get events -n kube-system

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

Mettre à jour les versions de Config Sync

Config Sync est mis à niveau chaque fois que vous mettez à niveau une configuration d'Anthos Config Management.

Pour mettre à niveau Anthos Config Management, vous pouvez utiliser Google Cloud Console ou kubectl. Avant de procéder à la mise à niveau, consultez les notes de version pour obtenir des instructions spécifiques.

Console

  1. Dans Cloud Console, accédez à la page Anthos Config Management.

    Accéder à la page "Anthos Config Management"

  2. Sélectionnez les clusters que vous souhaitez mettre à niveau.

  3. Configurer

  4. Cliquez sur Paramètres ACM pour vos clusters.

  5. Dans le menu déroulant Version, sélectionnez la version vers laquelle vous souhaitez effectuer la mise à niveau.

  6. Cliquez sur OK.

kubectl

Exécutez ces commandes pour chaque cluster enregistré :

  1. Téléchargez le fichier manifeste et les commandes nomos d'Anthos Config Management pour la nouvelle version.

  2. Appliquez le fichier manifeste d'Anthos Config Management :

    kubectl apply -f config-management-operator.yaml
    

    Cette commande met à jour l'image Anthos Config Management. Kubernetes récupère la nouvelle version et redémarre le pod Anthos Config Management à l'aide de cette nouvelle version. Lorsque Anthos Config Management 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 ou nomos.exe 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 d'un cluster

Suivez les instructions suivantes pour désinstaller Config Sync d'un cluster. Vous devez suivre ces étapes pour chaque cluster que vous ne souhaitez plus gérer à l'aide de Config Sync.

Console

Pour désactiver Anthos Config Management, procédez comme suit :

  1. Dans Google Cloud Console, accédez à la page Fonctionnalités d'Anthos.

    Accéder à la page "Fonctionnalités" d'Anthos

  2. Dans la ligne Config Management de la table Fonctionnalités, cliquez sur Détails. La page Résumé de l'état s'affiche.

  3. Cliquez sur Désactiver Config Management. Une page de confirmation s'affiche.

  4. Sur la page de confirmation, cliquez sur Désactiver Config Management.

gcloud

Exécutez la commande suivante :

gcloud alpha container hub config-management delete \
    --project=PROJECT_ID \
    --membership=CLUSTER_NAME

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster enregistré duquel vous souhaitez supprimer cette configuration
  • PROJECT_ID : ID de votre projet.

Pour supprimer l'ensemble des configurations et des états Config Sync, exécutez la commande suivante :

gcloud alpha container hub config-management disable \
    --project=PROJECT_ID

Remplacez PROJECT_ID par l'ID du projet.

kubectl

  1. Supprimez l'objet ConfigManagement du cluster :

    kubectl delete configmanagement --all
    

    Cette opération a les conséquences suivantes :

    • Tous les objets ClusterRole et ClusterRoleBinding créés dans le cluster par Config Sync sont supprimés du cluster.
    • Toutes les configurations de contrôleurs d'admission installées par Config Sync sont supprimées.
    • Le contenu de l'espace de noms config-management-system est supprimé, à l'exception du secret git-creds. Config Sync ne peut pas fonctionner sans l'espace de noms config-management-system. Toutes les définitions de ressources personnalisées (CRD) créées ou modifiées par Config Sync sont supprimées des clusters où elles ont été créées ou modifiées. Les CRD requises pour exécuter Config Sync existent toujours car, du point de vue de Kubernetes, elles ont été ajoutées par l'utilisateur qui a installé Config Sync. La procédure de suppression de ces composants est présentée à l'étape suivante.
  2. À ce stade, l'opérateur existe toujours dans votre cluster, mais n'intervient pas. Si vous utilisez Anthos clusters on VMware, vous ne pouvez pas supprimer l'opérateur manuellement.

    Si vous utilisez GKE et que vous décidez de ne plus utiliser Config Sync, vous pouvez désinstaller Config Sync en procédant comme suit :

    1. Vérifiez que l'espace de noms config-management-system est vide après la suppression de l'objet ConfigManagement à l'étape précédente. Attendez que la commande kubectl -n config-management-system get all renvoie le résultat No resources found.

    2. Supprimez l'espace de noms config-management-system :

      kubectl delete ns config-management-system
      
    3. Supprimez l'objet CustomResourceDefinition ConfigManagement :

      kubectl delete crd configmanagements.configmanagement.gke.io
      
    4. Supprimez tous les objets Config Sync de l'espace de noms kube-system :

      kubectl -n kube-system delete all -l k8s-app=config-management-operator
      

Dépannage

Les sections suivantes vous aident à résoudre les problèmes d'installation de Config Sync.

Utiliser les journaux d'audit

Les journaux d'audit peuvent être des outils de débogage utiles.

Si vous avez installé Config Sync à l'aide de Cloud Console ou de l'outil de ligne de commande gcloud, procédez comme suit pour utiliser les journaux d'audit afin d'examiner Config Sync.

Console

  1. Activez les journaux d'audit des API GKE Connect/Hub.

    1. Dans Cloud Console, accédez à la page Journaux d'audit d'IAM.

      Accéder à la page "Journaux d'audit"

    2. Dans le tableau, cochez la case API GKE Connect/Hub.

    3. Cochez les cases suivantes :

      • Lecture administrateur
      • Lecture de données
      • Écriture de données
    4. Cliquez sur Enregistrer.

  2. Accédez à la page Explorateur de journaux.

    Accéder à la page "Explorateur de journaux"

  3. Dans la zone de texte Générateur de requêtes, ajoutez les filtres suivants :

    resource.type="audited_resource" resource.labels.service="gkehub.googleapis.com"
    
  4. Cliquez sur Exécuter la requête.

  5. Dans la section Résultats de la requête, sélectionnez des entrées pour en savoir plus sur les événements.

Processeur insuffisant

La sortie de kubectl get events peut inclure un événement de type FailedScheduling. L'événement ressemble à l'exemple suivant :

LAST SEEN   TYPE      REASON              OBJECT                                       MESSAGE
9s          Warning   FailedScheduling    pod/config-management-operator-74594dc8f6    0/1 nodes are available: 1 Insufficient cpu.

Pour corriger cette erreur, choisissez l'une des options suivantes :

  • ajouter un nœud à un pool de nœuds GKE existant ;
  • créer un pool de nœuds avec des nœuds de plus grande capacité.

Erreur : tentative d'attribution de droits supplémentaires

Si vous rencontrez l'erreur suivante lorsque vous essayez d'appliquer le fichier config-management-operator.yaml, vous disposez peut-être d'une autorisation inférieure à celle requise pour l'installation :

Error from server (Forbidden): error when creating "config-management-operator.yaml": clusterroles.rbac.authorization.k8s.io "config-management-operator" is forbidden: attempt to grant extra privileges: [...] ruleResolutionErrors=[]

Pour vous assurer que vous disposez des autorisations nécessaires, consultez la section Préparer les autorisations.

Objet ConfigManagement valide, mais incorrect

Si l'installation é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 ConfigManagement peut être instancié dans le cluster mais ne pas fonctionner correctement. Dans ce cas, vous pouvez utiliser la commande nomos status pour rechercher les erreurs dans l'objet ConfigManagement.

Une installation valide ne présentant aucun 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.

Champs de config-management.yaml

Les sections suivantes décrivent les différents champs que vous pouvez définir dans votre fichier config-management.yaml.

Configuration pour le dépôt Git

Clé Description
spec.git.syncRepo URL du dépôt Git à utiliser comme source fiable. Obligatoire.
spec.git.syncBranch Branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Valeur par défaut : master
spec.git.policyDir Chemin d'accès dans le dépôt Git qui représente le niveau supérieur du dépôt à synchroniser. La valeur par défaut correspond au répertoire racine du dépôt.
spec.git.syncWait Période en secondes entre des synchronisations consécutives. La valeur par défaut est 15.
spec.git.syncRev Révision Git (tag ou hachage) à récupérer. La valeur par défaut est HEAD.
spec.git.secretType Type de secret configuré pour l'accès au dépôt Git. Spécifiez l'un des types suivants : ssh, cookiefile, token, gcenode ou none. Obligatoire.
spec.sourceFormat Si vous définissez ce paramètre sur unstructured, vous configurez un dépôt non hiérarchique. Valeur par défaut : hierarchy

Configuration du proxy pour le dépôt Git

Si les règles de sécurité de votre organisation vous obligent à acheminer le trafic via un proxy HTTP(S), vous pouvez utiliser l'URI du proxy pour configurer Config Sync de manière à communiquer avec votre hôte Git.

Clé Description
spec.git.proxy.httpProxy Définit une variable d'environnement HTTP_PROXY utilisée pour accéder au dépôt Git.
spec.git.proxy.httpsProxy Définit une variable d'environnement HTTPS_PROXY utilisée pour accéder au dépôt Git.

Si les champs httpProxy et httpsProxy sont spécifiés, httpProxy est ignoré.

Configuration pour le comportement de l'objet ConfigManagement

Clé Description
spec.clusterName Nom défini par l'utilisateur pour le cluster, utilisé par l'objet ClusterSelectors pour regrouper les clusters. Unique dans une installation Config Sync. Vous ne pouvez pas configurer ce champ dans Cloud Console.

Configuration pour les intégrations

Ces champs permettent l'intégration avec Config Connector et Policy Controller.

Clé Description
spec.configConnector.enabled Si elle est définie sur true, Config Connector est installé. La valeur par défaut est false.
spec.policyController.enabled Si elle est définie sur true, Policy Controller est activé. La valeur par défaut est false.
spec.policyController.templateLibraryInstalled Si elle est définie sur true, la bibliothèque de modèles de contraintes est installée. La valeur par défaut est true.

Étapes suivantes