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 : 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. Config Sync définit l'annotation
configmanagement.gke.io/managed: enabled, définit l'annotationconfigsync.gke.io/resource-idpour 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'annotationconfigmanagement.gke.io/managed: enabledet l'annotationconfigsync.gke.io/resource-id, puis applique la configuration.
- Non : créez une configuration pour l'objet. Config Sync définit l'annotation
- 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.
- Modifiez la configuration de l'objet dans le dépôt et définissez l'annotation
- 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.
Créez l'objet Role
myroledans l'espace de nomsgamestore:kubectl create role -n gamestore myrole --verb=get --resource=pods
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.À ce stade, l'objet Role existe dans le cluster, mais Config Sync ne le connaît pas.
- Dans un terminal, accédez au clone local de votre dépôt.
Utilisez la commande suivante pour créer un fichier manifeste YAML pour
myroleet enregistrez-le dans un nouveau fichier nommégamestore-myrole.yaml.kubectl get role myrole -n gamestore -o yaml > gamestore-myrole.yaml
Modifiez le fichier
gamestore-myrole.yaml.- Supprimez tous les champs situés sous la clé
metadata, à l'exception denameet denamespace. - Ajoutez le verbe
listaprèsgetdans le champ de listerules.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- Supprimez tous les champs situés sous la clé
Validez et transférez la modification vers le dépôt.
Attendez quelques instants que Config Management Operator détecte le commit. Pour vérifier que l'objet Role
myroleest maintenant géré par Config Sync, exécutez à nouveau la commandekubectl 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.
Modifiez le fichier
quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yamldans le clone local de votre dépôt, puis ajoutez une sectionannotations: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.ioEnregistrez le fichier.
Créez un commit Git avec vos modifications, puis transférez le commit vers votre dépôt.
Patientez quelques instants pendant que Config Sync détecte et applique le nouveau commit.
Utilisez la commande suivante pour vérifier que les annotations et les libellés de l'objet RoleBinding
gamestore-webstore-adminsont tous deux vides. Config Sync ne définit pas l'annotationconfigmanagement.gke.io/managedsurdisabledde 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.
Si vous avez supprimé l'objet RoleBinding
gamestore-webstore-adminde votre dépôt lors du dernier commit, procédez comme suit.Utilisez
git revertpour restaurer le dernier commit :git revert HEAD~1Vous êtes invité à confirmer l'opération de restauration.
Transférez le commit restauré vers votre dépôt.
git push
Modifiez le fichier
quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yamldans le clone local de votre dépôt et supprimez l'annotationconfigmanagement.gke.io/managed: disabled. Enregistrez le fichier.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: enabledetconfigsync.gke.io/resource-id, après quoi l'objet est géré. - Applique 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 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 :
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.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 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 :
Ajoutez l'annotation
client.lifecycle.config.k8s.io/deletion: detachà la configuration de l'objet dans le dépôt Git.Procédez au commit et déployez la modification dans le dépôt Git.
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
- Découvrez comment créer des configurations.