Gérer les objets de cluster existants

Lorsqu'Anthos Config Management 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.

Aperçu

Un objet dans un cluster est géré par Anthos Config Management s'il possède l'annotation configmanagement.gke.io/managed: enabled.

Si un objet ne présente aucune étiquette configmanagement.gke.io/managed, ou s'il est défini sur une autre valeur que enabled, il n'est pas géré.

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 d'Anthos Config Management

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

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. Anthos Config Management définit l'annotation configmanagement.gke.io/managed: enabled et 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, Anthos Config Management la détecte, applique l'annotation configmanagement.gke.io/managed: enabled, puis applique la configuration.
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, Anthos Config Management cesse de gérer l'objet.
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 la configuration d'un objet précédemment géré, Anthos Config Management 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, Anthos Config Management applique l'étiquette app.kubernetes.io/managed-by: configmanagement.gke.io à tous les objets qu'il gère. Cette étiquette vous permet de facilement répertorier tous les objets via Anthos Config Management.

Pourquoi ne pas appliquer l'annotation manuellement ?

Anthos Config Management 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), Anthos Config Management 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 Anthos Config Management sur un cluster ou un objet Namespace donné, utilisez un sélecteur d'étiquettes comme celui-ci :

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

Pour répertorier tous les objets non gérés par Anthos Config Management, utilisez un sélecteur d'étiquettes comme celui-ci :

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

Par exemple, cette commande répertorie les objets RoleBindings dans l'objet Namespace shipping-dev, qui sont gérés par Anthos Config Management :

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

NAME           AGE
job-creators   12m
pod-creators   12m
sre-admin      12m
viewers        12m

Cette commande répertorie les objets RoleBindings dans l'objet Namespace kube-system, qui ne sont pas gérés par Anthos Config Management :

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

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

Dans cet exemple, vous créez un objet Role manuellement, puis commencez à le gérer avec Anthos Config Management.

Créez l'objet Rôle myrole dans l'objet Namespace audit :

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

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

kubectl describe role -n audit 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 les pods get.

À ce stade, l'objet Role existe dans le cluster, mais Anthos Config Management 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é namespaces/audit/myrole.yaml.
```
kubectl get role myrole -n audit -o yaml > namespaces/audit/myrole.yaml
```
3. Modifiez le fichier 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: audit
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 désormais géré par Anthos Config Management, exécutez à nouveau la commande kubectl describe.
```
kubectl describe role myrole -n audit
```

Observez l'annotation configmanagement.gke.io/managed: enabled, qui indique que l'objet est géré par Anthos Config Management. Observez également les annotations qui indiquent le chemin d'accès 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 la validation.

Name:         myrole
Labels:       app.kubernetes.io/managed-by=configmanagement.gke.io
Annotations:  configmanagement.gke.io/cluster-name: example-cluster-name
              configmanagement.gke.io/managed: enabled
              configmanagement.gke.io/source-path: namespaces/audit/myrole.yaml
              configmanagement.gke.io/token: 0836805a09f160f12aa934b9042527e7283c7030
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 Anthos Config Management, tel que l'objet Role myrole de la section Commencer à gérer un objet existant.

Modifiez le fichier namespaces/online/shipping-app-backend/shipping-dev/job-creator-rolebinding.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:
   name: job-creators
 subjects:
 - kind: User
   name: sam@foo-corp.com
   apiGroup: rbac.authorization.k8s.io
 roleRef:
   kind: Role
   name: job-creator
   apiGroup: rbac.authorization.k8s.io
 annotations:
   configmanagement.gke.io/managed: disabled

Enregistrez le fichier.

Créez un commit Git avec vos modifications, puis transférez le commit vers votre dépôt.
Patientez quelques instants pendant qu'Anthos Config Management détecte et applique le nouveau commit.

Utilisez la commande suivante pour répertorier toutes les annotations dans l'objet RoleBinding job-creators. La sortie est tronquée pour des raisons de lisibilité.

kubectl get rolebinding job-creators -n audit -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  annotations:
    configmanagement.gke.io/cluster-name: my-cluster
    configmanagement.gke.io/managed: disabled
    configmanagement.gke.io/source-path: namespaces/viewers-rolebinding.yaml
    configmanagement.gke.io/sync-token: fabdb51587d51a81c7e419eeb983aafcf293dc83
...

Après vous être assuré que l'objet est désactivé, vous pouvez éventuellement supprimer la configuration appliquée et vérifier que l'objet qui est désormais non géré n'a pas été supprimé de l'objet Namespace. Si vous souhaitez gérer à nouveau l'objet, vous devez recréer sa configuration. 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 job-creators.

Si vous avez supprimé l'objet RoleBinding job-creators 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
```
Modifiez le fichier namespaces/online/shipping-app-backend/shipping-dev/job-creator-rolebinding.yaml dans le clone local de votre dépôt et supprimez l'annotation configmanagement.gke.io/managed: disabled. Enregistrez le fichier.
Validez et transférez le commit de votre modification. Anthos Config Management effectue les opérations suivantes :
- Signale la modification
- Application de l'annotation configmanagement.gke.io/managed: enabled ; l'objet est maintenant géré.
- Application de la configuration, comme pour n'importe quel objet géré.

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

kubectl get rolebinding job-creators -n audit -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  annotations:
    configmanagement.gke.io/cluster-name: my-cluster
    configmanagement.gke.io/managed: enabled
...

Arrêter de gérer un objet Namespace

Vous pouvez arrêter de gérer un objet Namespace 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 :

Ajoutez l'annotation configmanagement.gke.io/managed:disabled à la configuration d'objet Namespace et à toutes les configurations dans le même objet Namespace.

Remarque : Tous les objets dans l'objet Namespace doivent avoir cette annotation.
De plus, un objet Namespace qui hérite d'un espace de noms abstrait ne peut pas être non géré.
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.
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 mécanisme de synchronisation enregistre les erreurs, mais les autres configurations continuent à se synchroniser normalement.

Et ensuite ?

Découvrez comment créer des configurations.