Que sont les finaliseurs dans Kubernetes ? Comment gérer les suppressions d’objets – CloudSavvy IT

Les suppressions d’objets Kubernetes ne sont pas aussi simples qu’il n’y paraît à première vue. La suppression d’un objet est un processus complexe qui inclut des vérifications conditionnelles pour déterminer si une suppression sûre est possible. Ceci est réalisé par des objets API appelés Finalizers.

Dans cet article, nous verrons ce que sont les finaliseurs, comment ils sont gérés et les défis qu’ils peuvent poser lorsque vous souhaitez supprimer un objet. Une meilleure compréhension du processus de suppression peut vous aider à déboguer les problèmes où les ressources ne semblent pas se terminer en temps opportun.

Que sont les finaliseurs ?

Les finaliseurs sont un mécanisme permettant de faire respecter certaines conditions avant qu’un objet puisse être supprimé. Lorsque vous exécutez une commande comme kubectl delete namespace/example, Kubernetes vérifie les finaliseurs définis sur l’objet référencé. Ceux-ci sont répertoriés dans son metadata.finalizers domaine. Chaque finaliseur a la possibilité de reporter la suppression jusqu’à ce qu’il ait terminé ses actions.

Le processus de suppression réel finit par ressembler à ceci :

1. Émettez une commande de suppression. – Kubernetes marque l’objet comme étant en attente de suppression. Cela laisse la ressource dans l’état « Terminer » en lecture seule.
2. Exécutez chacune des actions associées aux finaliseurs de l’objet. – Chaque fois qu’une action Finalizer se termine, ce Finalizer est détaché de l’objet, il n’apparaîtra donc plus dans le metadata.finalizers domaine.
3. Kubernetes continue de surveiller les finaliseurs attachés à l’objet. – L’objet sera supprimé une fois le metadata.finalizers champ est vide, car tous les finaliseurs ont été supprimés à la fin de leurs actions.

Les finaliseurs sont couramment utilisés pour exécuter des procédures de nettoyage et de récupération de place avant qu’un objet ne soit supprimé du cluster. Vous pouvez ajouter vos propres finaliseurs à l’aide de l’API Kubernetes ; Les finaliseurs intégrés sont également appliqués automatiquement à certains types d’objets.

Par exemple, les ressources PersistentVolume sont livrées avec un kubernetes.io/pv-protection Finaliseur qui empêche la suppression accidentelle des volumes en cours d’utilisation par les Pods. Le finaliseur s’assure que le PersistentVolume ne peut pas être supprimé du cluster tant qu’aucun pod ne l’utilise. L’émission d’une commande de suppression alors qu’il y a encore un pod actif entraînera le marquage du volume comme Terminating; il restera dans cet état aussi longtemps que le Pod aura besoin du volume, puis sera supprimé automatiquement dès que possible par la suite.

Défis du finaliseur

Les finaliseurs de longue durée qui attendent une condition impliquant d’autres ressources peuvent provoquer l’apparition de suppressions bloquées dans le Terminating Etat. Vous pouvez également rencontrer des problèmes où un finaliseur bloque la suppression d’objets dépendants, ce qui empêche le parent de se terminer avec succès.

Ces problèmes sont régulièrement source de confusion – les développeurs et les opérateurs ont tendance à considérer les suppressions comme de simples procédures alors que le processus est en fait nuancé et variable. Les conditions préalables à une suppression réussie dépendent des relations de la ressource et de leurs finaliseurs, ainsi que de l’objet cible lui-même.

Lorsqu’un objet a été Terminating trop longtemps, vérifiez ses Finaliseurs en inspectant les metadata.finalizers champ dans son YAML :

kubectl get pod example-pod --namespace example -o json | jq

Une fois que vous savez quels finaliseurs sont définis, vous pouvez commencer à identifier ceux susceptibles de bloquer une suppression. L’affichage des événements et des changements de condition de l’objet peut faciliter le débogage en affichant les actions qui se sont produites depuis l’émission de la commande de suppression. Les conditions sont indiquées dans les YAML spec.status.conditions domaine; les événements sont visibles lors de l’exécution kubectl describe pod example-pod.

Vous pouvez supprimer manuellement les finaliseurs d’un objet en corrigeant le spec.finalizers champ à null. Cette technique ne doit être utilisée qu’en cas d’absolue nécessité. Les finaliseurs sont des sauvegardes destinées à protéger votre cluster ; les remplacer pourrait conduire à des objets orphelins et à des chaînes de dépendance brisées.

kubectl patch pod example-pod -p '{"metadata: {"finalizers": null}}'

Propriétaires et politiques de propagation

Un sujet connexe est les propriétaires d’objets et les stratégies de propagation de suppression. Les références de propriétaire définissent les relations entre les objets. Ils sont utilisés pour supprimer des arborescences d’objets entières lorsqu’un parent est supprimé. Par exemple, si vous supprimez un déploiement, Kubernetes doit également détruire les pods de ce déploiement.

Les références du propriétaire sont définies via le metadata.ownerReferences champ sur les objets. Chaque référence comprend le kind et name de l’objet auquel est parent la ressource actuelle.

Lorsque des références de propriétaire sont utilisées, la suppression d’un parent supprime automatiquement tous ses enfants. C’est ce qu’on appelle la suppression en cascade. Il est possible de désactiver la cascade en ajoutant le --cascade=orphan drapeau à kubectl delete. Kubernetes permettra aux enfants de l’objet de rester dans le cluster, les laissant disponibles mais orphelins.

Kubernetes prend également en charge différentes « politiques de propagation » de suppression. Ceux-ci définissent si le parent ou ses enfants sont supprimés en premier. Le défaut Foreground La stratégie supprime les enfants, puis le parent, garantissant qu’aucun orphelin ne se produise. Background inverse l’ordre de sorte que le parent est supprimé en premier. La troisième politique, Orphan, indique à Kubernetes d’ignorer complètement les références de propriétaire.

le kubectl delete La commande ne prend pas en charge les stratégies de propagation. Vous devez effectuer une requête API directe si vous souhaitez modifier la politique d’une opération de suppression :

curl -X DELETE 
    localhost/api/v1/namespaces/default/deployments/example 
    -d '{"apiVersion": "v1", "kind": "DeleteOptions", "propagationPolicy": "Background"}'
    -H "Content-Type: application/json"

Les finaliseurs sont respectés lorsqu’une suppression est propagée ou mise en cascade vers des objets associés. Dans le cas de la Foreground politique, cela signifie que tous les finaliseurs de tous les enfants devront être terminés avant que le parent puisse résilier. Pour le Background politique, les enfants resteront en vie jusqu’à ce que les finaliseurs de leurs parents aient terminé.

Implémentation des finaliseurs

Vous pouvez implémenter vos propres finaliseurs à l’aide de l’API Kubernetes et du SDK Go. Les finaliseurs sont créés en enregistrant des crochets dans le Reconcile méthode d’un contrôleur.

La méthode doit vérifier si l’objet à réconcilier a une valeur dans son DeletionTimestamp domaine. Cela signifie qu’il est en attente de suppression et qu’il est dans le Terminating Etat. Choisissez un identifiant pour votre finaliseur et vérifiez si l’objet inclut la valeur dans son metadata.finalizers domaine. Si c’est le cas, vous devez exécuter toutes les actions nécessaires, puis détacher le Finalizer de l’objet. Un exemple d’implémentation est inclus dans le guide Kubebuilder pour écrire vos propres types d’objets Kubernetes à l’aide de CRD (définitions de ressources personnalisées).

Les finaliseurs sont toujours implémentés sous forme de code dans une méthode de contrôleur. le metadata.finalizers field agit de la même manière que les annotations et les étiquettes, répertoriant les finaliseurs à appliquer à cet objet sans définir directement le code à exécuter.

Conclusion

Les finaliseurs contrôlent le cycle de vie d’un objet Kubernetes après le lancement de la suppression. Ils sont utilisés pour implémenter le garbage collection, notifier les contrôleurs des suppressions imminentes et empêcher la suppression accidentelle d’objets qui sont toujours référencés par d’autres ressources.

Étant donné que les finaliseurs peuvent bloquer les suppressions d’objets pendant des périodes arbitrairement longues, ils sont une source courante de frustration lorsque les équipes opérationnelles ne comprennent pas pourquoi un objet « bloqué » se termine. Dans cette situation, il est préférable d’inspecter les ressources affectées, de voir quels finaliseurs sont actifs et d’enquêter sur les relations inter-objets qui pourraient agir comme des dépendances bloquantes. Forcer la suppression d’un finaliseur devrait être votre dernier recours si vous devez immédiatement supprimer un objet de terminaison ou si vous avez épuisé toutes vos autres options.