Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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 : 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, mais pas 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 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.

  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.

  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.

Étapes suivantes