Gérer les objets de cluster existants

Lorsque Config Sync gère un objet de cluster, il assure la surveillance de l'objet et de l'ensemble des configurations qui lui sont applicables dans le dépôt, ainsi que leur synchronisation. Cette rubrique explique comment commencer à gérer un objet existant et comment mettre fin à la gestion en cours d'un objet sans le supprimer.

Un objet dans un cluster est géré par Config Sync s'il possède l'annotation configmanagement.gke.io/managed: enabled et si son annotation configsync.gke.io/resource-id, qui assure le suivi des informations sur le groupe, le genre, l'espace de noms et le nom, est correcte.

Le format de l'annotation configsync.gke.io/resource-id est GROUP_KIND_NAMESPACE_NAME pour un objet à l'échelle d'un espace de noms et GROUP_KIND_NAME pour un objet à l'échelle d'un cluster.

L'organigramme ci-dessous décrit certaines situations dans lesquelles un objet est géré ou non géré :

Le graphique représente trois flux distincts : 1) Commencer à gérer un objet, 2) Arrêter de gérer un objet et 3) Supprimer un objet géré.

1. Je souhaite commencer à gérer un objet. L'objet dispose-t-il d'un fichier manifeste ? En d'autres termes, l'objet dispose-t-il d'une configuration dans le dépôt ?
   • Non : créez une configuration pour l'objet. Config Sync définit l'annotation configmanagement.gke.io/managed: enabled, définit l'annotation configsync.gke.io/resource-id pour qu'elle corresponde à l'objet, puis commence à gérer l'objet.
   • Oui : la configuration définit-elle l'annotation suivante ?configmanagement.gke.io/managed: disabled
     • Non : l'objet est géré par défaut.
     • Oui : modifiez la configuration pour supprimer l'annotation configmanagement.gke.io/managed: disabled. Lorsque la modification est transmise au dépôt source, Config Sync la détecte, applique l'annotation configmanagement.gke.io/managed: enabled et l'annotation configsync.gke.io/resource-id, puis applique la configuration.
2. Je souhaite arrêter de gérer un objet sans le supprimer.
   • Modifiez la configuration de l'objet dans le dépôt et définissez l'annotation configmanagement.gke.io/managed: disabled. Lorsque la modification de configuration est détectée, Config Sync cesse de gérer l'objet.
3. Je souhaite arrêter de gérer un objet et le supprimer.
   • Supprimez la configuration de l'objet du dépôt. Lorsque vous supprimez une configuration pour un objet précédemment géré, Config Sync supprime l'objet de tous les clusters ou espaces de noms auxquels la configuration s'applique.

En plus de l'annotation configmanagement.gke.io/managed: enabled et de l'annotation configsync.gke.io/resource-id, Config Sync applique le libellé app.kubernetes.io/managed-by: configmanagement.gke.io à tous les objets qu'il gère. Ce libellé vous permet de facilement répertorier tous les objets via Config Sync.

Pourquoi ne pas appliquer l'annotation manuellement ?

Config Sync utilise un modèle déclaratif pour appliquer les modifications de configuration à vos clusters en lisant la configuration souhaitée à partir de votre dépôt. Si vous tentez d'appliquer l'annotation manuellement (à l'aide de la commande kubectl ou de l'API Kubernetes), Config Sync la remplace automatiquement par le contenu de votre dépôt.

Avant de commencer

Les exemples suivants s'appuient sur la section Premiers pas avec Config Sync. Avant de commencer les étapes suivantes, suivez le guide de démarrage rapide et effectuez toutes les étapes avant de Explorer et tester l'installation de Config Sync.

Répertorier tous les objets gérés

Pour répertorier tous les objets gérés par Config Sync sur un cluster ou un espace de noms donné, utilisez un sélecteur de libellés comme celui-ci :

kubectl get object-type -n namespace -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

Pour répertorier tous les objets non gérés par Config Sync, utilisez un sélecteur de libellés comme celui-ci :

kubectl get object-type -n namespace -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

Par exemple, cette commande répertorie les objets RoleBinding faisant partie de l'espace de noms gamestore qui sont gérés par Config Sync :

kubectl get rolebindings -n gamestore \
    -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

Le résultat ressemble à ce qui suit :

NAME                              ROLE                                          AGE
configsync.gke.io:ns-reconciler   ClusterRole/configsync.gke.io:ns-reconciler   34h
gamestore-admin                   ClusterRole/admin                             34h
gamestore-webstore-admin          ClusterRole/webstore-admin                    34h

Cette commande répertorie les objets RoleBinding faisant partie de l'espace de noms kube-system qui ne sont pas gérés par Config Sync :

kubectl get rolebindings -n kube-system \
    -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

Le résultat ressemble à ce qui suit :

NAME                                             AGE
fluentd-gcp-scaler-binding                       2d21h
gce:cloud-provider                               2d21h
heapster-binding                                 2d21h
metrics-server-auth-reader                       2d21h
system::leader-locking-kube-controller-manager   2d21h
system::leader-locking-kube-scheduler            2d21h
system:controller:bootstrap-signer               2d21h
system:controller:cloud-provider                 2d21h
system:controller:token-cleaner                  2d21h

Commencer à gérer un objet existant

Vous pouvez créer une configuration pour un objet Kubernetes existant, tel qu'un espace de noms qui existe déjà dans votre cluster avant d'installer Config Sync. Cependant, cette configuration est ignorée à moins que l'objet ne possède l'annotation configmanagement.gke.io/managed: enabled ainsi que l'annotation configsync.gke.io/resource-id appropriée. Pour un objet existant, vous devez appliquer l'annotation manuellement.

Pour les espaces de noms, Config Sync applique les configurations qui créent des objets dans un espace de noms non annoté. Il applique ensuite les annotations configmanagement.gke.io/managed: enabled et configsync.gke.io/resource-id à ces objets. Toutefois, Config Sync refuse de modifier ou de supprimer tout objet à l'échelle d'un cluster non annoté. Ceci est illustré dans le schéma de la section Utiliser des configurations au fil du temps.

L'exemple suivant montre comment gérer un objet de rôle existant. Vous commencez par créer un objet de rôle manuellement avant de le gérer avec Config Sync.

1. Créez l'objet Role myrole dans l'espace de noms gamestore :

   kubectl create role -n gamestore myrole --verb=get --resource=pods

2. Affichez les autorisations accordées par l'objet Role myrole :

   kubectl describe role -n gamestore myrole

   Name:         myrole
   Labels:       <none>
   Annotations:  <none>
   PolicyRule:
     Resources  Non-Resource URLs  Resource Names  Verbs
     ---------  -----------------  --------------  -----
     pods       []                 []              [get]
   

   L'objet Role ne dispose que des autorisations pour obtenir (get) des pods.

3. À ce stade, l'objet Role existe dans le cluster, mais Config Sync ne le connaît pas.

   1. Dans un terminal, accédez au clone local de votre dépôt.

   2. Utilisez la commande suivante pour créer un fichier manifeste YAML pour myrole et enregistrez-le dans un nouveau fichier nommé gamestore-myrole.yaml.

      kubectl get role myrole -n gamestore -o yaml > gamestore-myrole.yaml
      

   3. Modifiez le fichier gamestore-myrole.yaml.

      1. Supprimez tous les champs situés sous la clé metadata, à l'exception de name et de namespace.
      2. Ajoutez le verbe list après get dans le champ de liste rules.verbs.

      Enregistrez les modifications. Le contenu du fichier obtenu est le suivant :

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: myrole
        namespace: gamestore
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        verbs:
        - get
        - list
      

   4. Validez et transférez la modification vers le dépôt.

   5. Attendez quelques instants que Config Management Operator détecte le commit. Pour vérifier que l'objet Role myrole est maintenant géré par Config Sync, exécutez à nouveau la commande kubectl describe.

      kubectl describe role myrole -n gamestore
      

Observez l'annotation configmanagement.gke.io/managed: enabled qui indique que l'objet est géré par Config Sync, puis l'annotation configsync.gke.io/resource-id qui assure le suivi des informations sur le groupe, le genre, l'espace de noms et le nom. Observez également les annotations qui indiquent le chemin d'accès dans le dépôt et le nom du fichier ayant entraîné la dernière modification de configuration de l'objet, ainsi que le hachage Git qui représente le commit.

Name:         myrole
Labels:       app.kubernetes.io/managed-by=configmanagement.gke.io
              configsync.gke.io/declared-version=v1
Annotations:  config.k8s.io/owning-inventory: config-management-system_root-sync
              configmanagement.gke.io/cluster-name: my-cluster
              configmanagement.gke.io/managed: enabled
              configmanagement.gke.io/source-path: config-sync-quickstart/multirepo/root/gamestore-myrole.yaml
              configmanagement.gke.io/token: 747b843a7ddbd945c0616034a935cf648b58e7b5
              configsync.gke.io/declared-fields: {"f:rules":{}}
              configsync.gke.io/git-context: {"repo":"https://github.com/GoogleCloudPlatform/anthos-config-management-samples","branch":"main","rev":"HEAD"}
              configsync.gke.io/manager: :root
              configsync.gke.io/resource-id: rbac.authorization.k8s.io_role_gamestore_myrole
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get list]

Arrêter de gérer un objet géré

Cet exemple montre comment arrêter de gérer un objet actuellement géré par Config Sync, tel que l'objet Role myrole de la section Commencer à gérer un objet existant.

Remarque : Avant de supprimer un espace de noms des objets gérés, veillez à bien comprendre ce qui se passe au niveau des objets présents dans cet espace de noms qui sont toujours gérés.

1. Modifiez le fichier config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml dans le clone local de votre dépôt, puis ajoutez une section annotations: correspondant au texte en gras ci-dessous :

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      annotations:
        configmanagement.gke.io/managed: disabled
      name: gamestore-webstore-admin
      namespace: gamestore
    subjects:
    - kind: ServiceAccount
      name: ns-reconciler-gamestore
      namespace: config-management-system
    roleRef:
      kind: ClusterRole
      name: webstore-admin
      apiGroup: rbac.authorization.k8s.io
   

   Enregistrez le fichier.

2. Créez un commit Git avec vos modifications, puis transférez le commit vers votre dépôt.

3. Patientez quelques instants pendant que Config Sync détecte et applique le nouveau commit.

4. Utilisez la commande suivante pour vérifier que les annotations et les libellés de l'objet RoleBinding gamestore-webstore-admin sont tous deux vides. Config Sync ne définit pas l'annotation configmanagement.gke.io/managed sur disabled de l'objet.

   kubectl get rolebinding gamestore-webstore-admin -n gamestore -o yaml
   

   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     annotations:
     name: gamestore-webstore-admin
     namespace: gamestore
   subjects:
   - kind: ServiceAccount
     name: ns-reconciler-gamestore
     namespace: config-management-system
   roleRef:
     kind: ClusterRole
     name: webstore-admin
     apiGroup: rbac.authorization.k8s.io
   

Après avoir vérifié que l'objet est maintenant désactivé, vous pouvez supprimer la configuration de votre dépôt et vérifier que l'objet non géré n'est pas supprimé de l'espace de noms. Si vous souhaitez gérer à nouveau l'objet, vous devez rajouter sa configuration dans votre dépôt. Pour cette raison, vous souhaiterez peut-être arrêter la gestion des objets et laisser leurs configurations dans le dépôt.

Maintenant que l'objet n'est plus géré, il n'est pas créé ni recréé sur des clusters nouveaux ou existants, et il n'est pas supprimé, même s'il existe. Pour reprendre la gestion d'un objet que vous avez précédemment cessé de gérer, consultez l'exemple suivant, Reprendre la gestion d'un objet précédemment non géré.

Reprendre la gestion d'un objet précédemment non géré

Cet exemple montre comment reprendre la gestion d'un objet que vous avez précédemment retiré de la gestion, comme décrit dans la section Arrêter de gérer un objet existant. L'exemple suppose que vous n'avez pas supprimé la configuration de l'objet RoleBinding gamestore-webstore-admin.

1. Si vous avez supprimé l'objet RoleBinding gamestore-webstore-admin de votre dépôt lors du dernier commit, procédez comme suit.

   1. Utilisez git revert pour restaurer le dernier commit :

      git revert HEAD~1
      

      Vous êtes invité à confirmer l'opération de restauration.

   2. Transférez le commit restauré vers votre dépôt.

      git push
      

2. Modifiez le fichier config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml dans le clone local de votre dépôt et supprimez l'annotation configmanagement.gke.io/managed: disabled. Enregistrez le fichier.

3. Validez et transférez le commit de votre modification. Config Sync effectue les opérations suivantes :

   • Signale la modification
   • Applique les annotations configmanagement.gke.io/managed: enabled et configsync.gke.io/resource-id, après quoi l'objet est géré.
   • Applique la configuration, comme pour n'importe quel objet géré

4. Pour vérifier que l'objet est maintenant géré, répertoriez ses annotations :

   kubectl get rolebinding gamestore-webstore-admin -n gamestore -o yaml

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     annotations:
       configmanagement.gke.io/cluster-name: my-cluster
       configmanagement.gke.io/managed: enabled
       configsync.gke.io/resource-id: rbac.authorization.k8s.io_rolebinding_gamestore_gamestore-webstore-admin
   ...
   

Arrêter de gérer un espace de noms

Vous pouvez arrêter de gérer un espace de noms de la même façon que vous arrêtez de gérer n'importe quel type d'objet. Si vous souhaitez arrêter de gérer d'autres ressources dans l'espace de noms, procédez comme suit :

1. Ajoutez l'annotation configmanagement.gke.io/managed:disabled à la configuration de l'espace de noms et à toutes les configurations faisant partie de ce même espace de noms. Tous les objets de l'espace de noms doivent comporter cette annotation.

   Attention : Dans une source de vérité hiérarchique, si l'espace de noms est hérité d'un espace de noms abstrait, il ne peut pas être non géré.

2. Procédez au commit et au transfert de vos modifications dans le dépôt. Attendez que Config Sync Operator se synchronise avec le dépôt.

3. Supprimez les ressources non gérées du dépôt.

   Avertissement : Si vous n'utilisez pas les API RootSync et RepoSync0, un problème connu entraîne la suppression de l'espace de noms du cluster actif lorsque vous supprimez un espace de noms non géré du dépôt. Pour les ressources non gérées qui sont accidentellement supprimées, vous devrez les ajouter à nouveau et manuellement dans le cluster, par exemple en utilisant kubectl apply. Pour utiliser les API RootSync et RepoSync, vous devez migrer votre objet ConfigManagement.

Si des configurations appliquées à des configurations gérées existent dans un répertoire d'espace de noms non géré, le processus de rapprochement enregistre les erreurs, mais les autres configurations continuent à se synchroniser normalement.

Supprimer des ressources gérées

Lorsque vous supprimez une ressource individuelle d'une source de vérité, cet objet est supprimé du cluster lors de la prochaine synchronisation de Config Sync à partir de la source de vérité. Vous pouvez également activer la propagation de la suppression, qui vous permet de supprimer des objets de manière groupée.

Supprimer des objets individuels

Avec le comportement par défaut de Config Sync, lorsque vous supprimez un objet d'une source de vérité, cet objet est supprimé du cluster lors de la synchronisation de Config Sync à partir de la source de vérité.

Il existe plusieurs façons de vérifier l'état de Config Sync ou l'état d'objets spécifiques :

• Utilisez nomos status.
• Utilisez kubectl pour examiner les ressources.
• Exécutez la commande gcloud alpha anthos config sync resources.
• Utiliser le tableau de bord Config Sync.

Supprimer des objets de manière groupée

Preview

Ce produit ou cette fonctionnalité est soumis aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent bénéficier d'une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Par défaut, la suppression d'un objet RootSync ou RepoSync oblige Config Sync à abandonner les objets précédemment appliqués à partir de la source de vérité. Vous pouvez également activer la propagation de la suppression pour supprimer tous les objets précédemment appliqués.

Lorsque vous activez la propagation de la suppression sur un objet RootSync ou RepoSync, puis que vous supprimez cet objet, Config Sync supprime automatiquement tous les objets gérés par ce RootSync ou RepoSync.

La propagation de la suppression peut faciliter le nettoyage des ressources, par exemple si vous migrez vers un nouvel espace de noms ou un nouveau cluster, si vous effectuez un nettoyage après une démonstration ou un test, ou si vous désinstallez une application.

Options de propagation des suppressions

La propagation des suppressions est désactivée par défaut. Pour activer la propagation de la suppression, ajoutez l'annotation configsync.gke.io/deletion-propagation-policy: Foreground à votre objet RootSync ou RepoSync, comme dans l'exemple suivant :

# example-rootsync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: example-rootsync
  namespace: config-management-system
  annotations:
    configsync.gke.io/deletion-propagation-policy: Foreground
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    branch: init
    dir: config-sync-quickstart/multirepo/root
    auth: none
    period: 30s

Vous pouvez également mettre à jour un objet RootSync ou RepoSync existant pour utiliser la propagation de la suppression en exécutant la commande suivante :

RootSync

kubectl patch RootSync ROOTSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'

Remplacez ROOTSYNC_NAME par le nom de l'objet RootSync que vous souhaitez mettre à jour.

RepoSync

kubectl patch RepoSync REPOSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'

Remplacez REPOSYNC_NAME par le nom de l'objet RepoSync que vous souhaitez mettre à jour.

Pour désactiver la propagation de la suppression, supprimez l'annotation ou remplacez la valeur par configsync.gke.io/deletion-propagation-policy: Orphan :

RootSync

kubectl patch RootSync ROOTSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Orphan"}}}'

Remplacez ROOTSYNC_NAME par le nom de l'objet RootSync que vous souhaitez mettre à jour.

RepoSync

kubectl patch RepoSync REPOSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Orphan"}}}'

Propager la suppression de l'objet

Cet exemple montre comment appliquer la propagation de la suppression à un objet RootSync ou RepoSync, puis supprimer l'objet RootSync ou RepoSync pour supprimer tous les objets gérés par l'objet RootSync ou RepoSync.

Attention : Pour les objets RepoSync, ne supprimez pas l'espace de noms dans lequel se trouve l'objet RepoSync avant la fin de la suppression de l'objet RepoSync. Cela peut entraîner la suppression de l'objet RoleBinding avant la fin de la propagation de la suppression, ce qui peut entraîner un blocage pouvant bloquer la suppression de l'objet RepoSync et de l'espace de noms.

RootSync

1. Appliquez l'annotation à un objet RootSync pour activer la propagation de la suppression :

   kubectl patch RootSync example-rootsync \
     --namespace config-management-system \
     --type merge \
     --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'
   

2. Supprimez l'objet RootSync et attendez que Config Sync le supprime :

   kubectl delete RootSync example-rootsync --namespace config-management-system --wait
   

   La suppression de RootSync peut prendre quelques minutes.

RepoSync

1. Appliquez l'annotation à un objet RepoSync pour activer la propagation de la suppression :

   kubectl patch RepoSync example-reposync \
     --namespace example-namespace \
     --type merge \
     --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'
   

2. Supprimez l'objet RepoSync et attendez que Config Sync le supprime :

   kubectl delete RepoSync example-reposync --namespace example-namespace --wait
   

   La suppression de l'objet RepoSync peut prendre quelques minutes.

Empêcher la suppression d'objets Kubernetes

Lorsque vous supprimez un objet Kubernetes d'un dépôt Git géré par Config Sync, cet objet est également supprimé du cluster lors de la synchronisation du nouveau commit avec le cluster.

Si vous souhaitez empêcher Config Sync de supprimer l'objet de cluster lorsque sa configuration est supprimée du dépôt Git, procédez comme suit :

1. Ajoutez l'annotation client.lifecycle.config.k8s.io/deletion: detach à la configuration de l'objet dans le dépôt Git.

2. Procédez au commit et déployez la modification dans le dépôt Git.

3. Attendez que la modification soit synchronisée avec le cluster.

Une fois ces étapes réalisées, Config Sync ne supprime pas cet objet du cluster lorsque sa configuration est supprimée du dépôt Git, mais il peut toujours être supprimé par d'autres clients.

Ignorer un objet dans la source de vérité

Vous souhaiterez peut-être que Config Sync ignore un objet de votre source dé vérité. Par exemple, une configuration de fonction kpt ne doit jamais être appliquée au cluster.

Pour les objets que Config Sync doit ignorer, ajoutez l'annotation config.kubernetes.io/local-config: "true" à l'objet. Après avoir ajouté cette annotation, Config Sync ignore cet objet comme s'il était supprimé de la source de vérité. Les ressources dont l'annotation local-config est définie sur une valeur autre que "false" sont traitées comme si elles étaient définies sur "true" et sont ignorées.