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

Comment gérer ou arrêter la gestion d'un objet Kubernetes à l'aide de Config Sync

Le graphique représente trois flux distincts : le début de la gestion d'un objet, l'arrêt de la gestion d'un objet et la suppression d'un objet géré.

  1. Je souhaite gérer un objet. 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 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 le guide de démarrage rapide. Avant de commencer les étapes suivantes, suivez le guide de démarrage rapide et effectuez toutes les étapes avant d'examiner le cluster et le dépôt.

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"

Example de résultat : ```none 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


This command lists RoleBindings in the `kube-system` namespace that are **not**
managed by Config Sync:

<pre class="devsite-click-to-copy">
kubectl get rolebindings -n kube-system \
    -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"
</pre>

Example output:
```none
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: 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.

  1. Modifiez le fichier 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 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.

  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.

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.

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 le dépôt Git

Il peut arriver que vous souhaitiez que Config Sync ignore un objet du dépôt Git. Par exemple, une configuration de fonction kpt ne doit jamais être appliquée au cluster. Pour ce type d'objet, vous pouvez ajouter 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é du dépôt Git.

Étape suivante