Installer Anthos Config Management

Config Management Operator est un contrôleur qui gère Anthos Config Management dans un cluster Kubernetes. Procédez comme suit pour installer et configurer l'opérateur dans chaque cluster que vous souhaitez gérer à l'aide d'Anthos Config Management.

Avant de commencer

Cette section décrit les conditions préalables que vous devez remplir avant d'enregistrer des clusters compatibles dans Anthos Config Management.

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 :

  • Anthos Config Management requiert des droits d'accès actifs pour Anthos. Pour en savoir plus, consultez la page Tarifs d'Anthos.

  • Installez le SDK Cloud afin de pouvoir exécuter les commandes gcloud, gsutil et kubectl utilisées dans ces instructions.

  • Le composant kubectl n'est pas installé par défaut par le SDK Cloud. Pour installer kubectl, utilisez la commande suivante :

    gcloud components install kubectl
    
  • Installez la commande nomos afin de pouvoir utiliser la sous-commande nomos status pour détecter tout problème lors de l'installation et de la configuration.

  • Pour télécharger des composants d'Anthos Config Management, vous devez vous authentifier auprès de Google Cloud à l'aide de la commande gcloud auth login.

  • Vous devez configurer la commande kubectl pour vous connecter à vos clusters. Pour ce faire, les étapes à suivre ne sont pas les mêmes pour les clusters GKE et GKE On-Prem :

  • L'API Anthos doit être activée pour votre projet :

gcloud

Pour activer l'API Anthos, exécutez la commande suivante :

gcloud services enable anthos.googleapis.com

Console

Activer l'API Anthos

Clusters

  • Vos clusters doivent se trouver sur une plate-forme et une version compatibles d'Anthos.

  • Vos clusters doivent être enregistrés dans un Environ Anthos à l'aide de Connect. L'Environ 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 en dehors de Google Cloud. Les frais d'Anthos s'appliquent uniquement à vos clusters enregistrés. Pour découvrir comment enregistrer un cluster, consultez la page Enregistrer un cluster.

Autorisations

L'utilisateur Google Cloud qui installe Anthos Config Management a besoin d'autorisations IAM (Identity and Access Management) pour créer de nouveaux rôles dans votre cluster.

Enregistrer un cluster

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

  1. Déployez l'opérateur.
  2. Accordez à l'opérateur un accès en lecture seule à Git.
  3. Configurez l'opérateur.

Déployer l'opérateur

Si vous installez Config Management Operator à l'aide de Google Cloud Console, l'opérateur est automatiquement déployé. Passez à la section suivante pour créer le secret git-creds.

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 l'objet CRD Operator à l'aide de la commande ci-dessous. 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 opération échoue, consultez la section Dépannage.

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

L'opérateur a besoin d'un accès en lecture seule à votre dépôt Git pour pouvoir lire les configurations associées au 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 le dépôt ne nécessite aucune authentification ni autorisation pour un accès en lecture seule, vous n'avez pas besoin de créer un secret git-creds. Vous pouvez ignorer l'étape Configurer Anthos Config Management et définir la valeur de SecretType sur none.

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

La solution que vous choisissez dépend du mécanisme compatible avec votre dépôt. Si tous les mécanismes sont disponibles, il est recommandé d'utiliser une paire de clés SSH. Au moment de la rédaction de cet article, GitHub, Cloud Source Repositories et Bitbucket permettent tous trois d'utiliser une paire de clés SSH. Si votre dépôt est hébergé par votre organisation et que vous ne connaissez pas les méthodes d'authentification acceptées, contactez votre administrateur.

Après avoir créé les identifiants, vous devez les ajouter au cluster en tant qu'objet Secret. La façon dont vous créez le secret dépend de la méthode d'authentification. Pour en savoir plus, consultez la section sur les méthodes d'authentification présentée ci-dessous.

Choisissez la meilleure méthode parmi les options ci-dessous pour autoriser l'accès à votre dépôt. La méthode que vous choisissez détermine également le secretType que vous utilisez lors de la configuration de l'opérateur.

Utiliser une paire de clés SSH

Si votre dépôt permet d'utiliser une paire de clés SSH pour le processus d'autorisation, suivez la procédure décrite dans cette section pour créer les éléments du secret. Dans le cas contraire, suivez les instructions relatives à l'utilisation d'un fichier de cookie.

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.

  1. Créez une paire de clés SSH pour permettre à l'opérateur de s'authentifier auprès de votre dépôt Git. Cette opération 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 la 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 ci-dessous permet de créer une clé RSA de 4 096 bits. Les valeurs inférieures ne sont pas recommandées. Remplacez [GIT REPOSITORY USERNAME] et /path/to/[KEYPAIR-FILENAME] par les valeurs que l'opérateur doit utiliser pour s'authentifier auprès du dépôt. Il est recommandé d'employer un compte distinct si vous vous servez d'un hôte de dépôt Git tiers (tel que GitHub) ou un compte de service si vous faites appel à Cloud Source Repositories.

    ssh-keygen -t rsa -b 4096 \
     -C "[GIT REPOSITORY USERNAME]" \
     -N '' \
     -f [/path/to/KEYPAIR-FILENAME]
    
  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. Spécifiez le nom de la clé privée (qui ne comporte pas le suffixe .pub) dans /path/to/[KEYPAIR-PRIVATE-KEY-FILENAME].

    kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=ssh=/path/to/[KEYPAIR-PRIVATE-KEY-FILENAME]
    
  4. Supprimez la clé privée du disque local ou protégez-la.

Utiliser un fichier de cookie

Si votre dépôt ne permet pas d'utiliser une paire de clés SSH pour le processus d'autorisation, vous pouvez utiliser un fichier de cookie ou un jeton d'accès personnel.

Suivez la procédure décrite dans cette section pour créer les éléments du secret du fichier de cookie.

Le processus d'acquisition d'un fichier de cookie dépend de la configuration de votre dépôt. Pour en savoir plus, vous pouvez par exemple consulter les instructions expliquant comment générer des identifiants statiques dans Cloud Source Repositories. Les identifiants sont généralement stockés dans le fichier .gitcookies du répertoire de base de l'utilisateur ou peuvent vous être fournis par un administrateur de la sécurité.

  1. Après avoir créé et obtenu le fichier de cookie, ajoutez-le à un nouveau secret dans le cluster. Remplacez /path/to/[COOKIEFILE] par le chemin d'accès et le nom de fichier appropriés.

    kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/[COOKIEFILE]
    
  2. Veillez à protéger le contenu du fichier de cookie si vous en avez toujours besoin en local. Dans le cas contraire, supprimez-le.

Utiliser un jeton

Si votre organisation n'autorise pas l'utilisation de clés SSH, vous pouvez utiliser un jeton. Avec Anthos Config Management, vous pouvez utiliser comme jeton un jeton d'accès personnel (Personal Access Token ou PAT) de GitHub ou un mot de passe d'application Bitbucket.

Pour créer un secret à l'aide de votre jeton, procédez comme suit :

  1. Créez un jeton à l'aide de GitHub ou Bitbucket.

    GitHub

    Créez un jeton d'accès personnel (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 (PAT) à un compte GitHub, nous vous recommandons par la même occasion de créer un utilisateur machine et de lui associer votre jeton 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. Remplacez [USERNAME] par le nom d'utilisateur souhaité et [TOKEN] par le jeton que vous avez créé à l'étape précédente.

    kubectl create secret generic git-creds \
        --namespace="config-management-system" \
        --from-literal=username=[USERNAME] \
        --from-literal=token=[TOKEN]
    
  3. Protégez le jeton si vous en avez toujours besoin en local. Dans le cas contraire, supprimez-le.

Utiliser un compte de service Google avec un dépôt source Google

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

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

  • Le compte de service Compute Engine par défaut PROJECT_NUMBER-compute@developer.gserviceaccount.com pour le cluster doit disposer d'un accès source.reader au dépôt.

    gcloud projects add-iam-policy-binding [PROJECT_ID] \
    --member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
    --role roles/source.reader
    
  • Les niveaux d'accès pour les nœuds du cluster doivent inclure cloud-source-repos-ro. Pour remplir cette condition, vous pouvez inclure cloud-source-repos-ro dans la liste --scopes spécifiée lors de la création du cluster ou utiliser le niveau d'accès cloud-platform lors de la création du cluster :

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

Une fois ces conditions préalables remplies, définissez spec.git.syncRepo sur l'URL du dépôt source Google souhaité lors de la configuration de l'opérateur. Exemple :

gcloud source repos list
REPO_NAME  PROJECT_ID  URL
my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr

Cela nécessiterait les éléments suivants :

spec.git.syncRepo: https://source.developers.google.com/p/my-project/r/my-repo-csr
Utiliser un dépôt source Google 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 effectué les étapes ci-dessus et configuré l'opérateur comme décrit dans la section ci-dessous, 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 l'opérateur afin d'activer Anthos Config Management pour la première fois.

Cette liaison permet au compte de service Kubernetes d'Anthos Config Management 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

Enfin, ajoutez une annotation au compte de service Kubernetes d'Anthos Config Management en utilisant l'adresse e-mail associée au 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

Accéder au dépôt sans authentification

Si votre dépôt ne nécessite pas d'authentification pour un accès en lecture seule, vous pouvez continuer à configurer l'opérateur et définir spec.git.secretType sur none.

Configurer l'opérateur

Vous pouvez configurer l'opérateur pour votre cluster à l'aide de la commande kubectl ou de Google Cloud Console.

kubectl

Pour configurer le comportement de l'opérateur, créez un fichier de configuration pour la CustomResource de ConfigManagement, puis appliquez-le à l'aide de la commande kubectl apply.

Par exemple, créez un fichier config-management.yaml et copiez-y le fichier YAML suivant.

# 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: my-cluster
  git:
    syncRepo: git@github.com:my-github-username/csp-config-management.git
    syncBranch: 1.0.0
    secretType: ssh
    policyDir: "foo-corp"

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

Pour appliquer la configuration, utilisez 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-1
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 configurer Anthos Config Management pour communiquer avec votre hôte Git à l'aide de l'URI du proxy.

Clé Description
spec.git.proxy.httpProxy httpProxy définit une variable d'environnement HTTP_PROXY utilisée pour accéder au dépôt Git.
spec.git.proxy.httpsProxy 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 tous les deux spécifiés, httpProxy sera 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. Ce nom est unique dans une installation Anthos Config Management.
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.

Console

Limites

La configuration d'Anthos Config Management sur Google Cloud Console présente les limitations suivantes :

  • Vous ne pouvez pas installer ni configurer les composants suivants :
    • Policy Controller
    • Config Connector
    • Hierarchy Controller
  • Seul un sous-ensemble des options de configuration de Config Sync est accepté. Les configurations de Config Sync suivantes ne sont pas compatibles :
    • spec.git.proxy
    • spec.git.secretType: gcenode
    • spec.git.secretType: token
    • spec.sourceFormat

Si vous souhaitez faire usage de l'une de ces options, n'utilisez pas Cloud Console.

Configurer l'opérateur

Pour configurer l'opérateur sur Cloud Console, procédez comme suit :

  1. Accédez au menu Anthos Config Management dans Google Cloud Console.

    Accéder au menu 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, procédez comme suit :

    1. Pour le champ Type de secret, sélectionnez l'une des valeurs suivantes :

      • Aucun. Sélectionnez cette valeur si votre dépôt ne nécessite pas d'authentification pour un accès en lecture seule.
      • SSH
      • Fichier de cookie

      Si vous souhaitez sélectionner token ou gcenode, configurez l'opérateur à l'aide de kubectl.

    2. Cliquez sur Continuer.

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

    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 valeur par défaut est la branche master. Ce champ est obligatoire.
    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. Cliquez sur Afficher les options avancées.
    5. 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.
    6. 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.
  5. Cliquez sur OK. Vous êtes redirigé vers le menu Anthos Config Management. Après quelques minutes, actualisez la page. Vous devriez voir apparaître la valeur Synced (Synchronisé) dans la colonne d'état à côté des clusters que vous avez configurés.

Vérifier l'installation

Vous pouvez utiliser la commande nomos status pour vérifier si l'opérateur 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.

Une fois l'opérateur 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 (mais pas identique) à la suivante :

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 à ce qui suit :

config-management-system Active 1m

Si les commandes ne renvoient pas de résultats semblables à ceux présentés ici, consultez les journaux afin d'identifier le problème rencontré :

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

Vous pouvez également utiliser kubectl get events pour vérifier si Anthos Config Management a créé 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 l'article Objet ConfigManagement valide mais incorrect dans la section "Dépannage" de cet article.

Dépannage

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

Processeur insuffisant

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

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, vous devez :

  • 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

kubectl apply -f config-management-operator.yaml
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=[]

Cette erreur indique que l'utilisateur actuel ne dispose pas de toutes les autorisations nécessaires pour l'installation. Pour en savoir plus, consultez la section Conditions préalables au contrôle des accès basé sur les rôles dans GKE.

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

D'autres erreurs peuvent être ajoutées ultérieurement.

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 résulte du fait que vous avez oublié de créer le secret git-creds, l'opérateur le détecte dès que vous le créez et vous n'avez pas besoin de réappliquer la configuration.

Effectuer la mise à niveau

Cette section fournit des instructions générales de mise à niveau vers la version actuelle. Avant de procéder à la mise à niveau, consultez les notes de version pour obtenir des instructions spécifiques.

Exécutez ces commandes pour chaque cluster enregistré.

  1. Téléchargez le fichier manifeste de l'opérateur et les commandes nomos pour la nouvelle version.

  2. Appliquez le fichier manifeste de l'opérateur :

    kubectl apply -f config-management-operator.yaml
    

    Cette commande met à jour l'image de l'opérateur. Kubernetes récupère la nouvelle version et l'utilise pour redémarrer le pod de l'opérateur. Lorsque l'opérateur démarre, il exécute une boucle de rapprochement qui applique l'ensemble des 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. Cela garantit que la commande nomos peut toujours obtenir l'état de tous les clusters enregistrés et valider les configurations correspondantes.

Désinstaller l'opérateur d'un cluster

Suivez ces instructions pour désinstaller l'opérateur d'un cluster. Vous devez suivre ces étapes pour chaque cluster que vous ne souhaitez plus gérer à l'aide d'Anthos Config Management.

  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 Anthos Config Management sont supprimés du cluster.
    • Toutes les configurations de contrôleurs d'admission installées par Anthos Config Management sont supprimées.
    • Le contenu de l'espace de noms config-management-system est supprimé, à l'exception du secret git-creds. Anthos Config Management ne peut pas fonctionner sans l'espace de noms config-management-system. Tous les objets CustomResourceDefinition créés ou modifiés dans des clusters par Anthos Config Management sont supprimés de ceux-ci. Les objets CustomResourceDefinition (CRD) requis pour exécuter l'opérateur existent toujours, car du point de vue de Kubernetes, ils ont été ajoutés par l'utilisateur qui a installé l'opérateur. La procédure de suppression de ces objets 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 GKE On-Prem, vous ne pouvez pas supprimer l'opérateur manuellement.

    Si vous utilisez GKE et décidez de ne plus utiliser Anthos Config Management, vous pouvez désinstaller l'opérateur 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 Anthos Config Management de l'espace de noms kube-system :

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

Étapes suivantes