La récupération de place est le processus par lequel Kubernetes supprime les objets dépendants après la suppression d'une ressource. Il gère également le nettoyage automatique des éléments redondants dans votre cluster. Les conteneurs finis et les images désaffectées sont périodiquement supprimés pour éviter qu'un grand nombre de ressources inutiles ne s'accumulent au fil du temps.
Plusieurs stratégies de récupération de place peuvent être déployées en fonction du type d'objet à supprimer. La récupération de place des ressources inutilisées est configurable par les paramètres Kubelet sur les nœuds de travail de votre cluster. Dans cet article, nous expliquerons les différentes formes de récupération de place et comment vous pouvez personnaliser les paramètres de nettoyage.
Récupération de place de base
< p>La récupération de place de Kubernetes gère la suppression des objets dépendants, des anciens conteneurs et des images inutilisées. Kubelet exécute périodiquement des opérations de nettoyage pendant que son service est actif. Il supprimera les conteneurs arrêtés, tels que ceux des tâches terminées, et supprimera les images inutilisées une fois qu'un certain seuil d'utilisation du disque est atteint.
La récupération de place des ressources du cluster en réponse aux suppressions d'objets utilise un mécanisme en cascade. Cela garantit que les enfants d'un objet sont supprimés à côté de lui, empêchant les orphelins d'exister. Vous pouvez contrôler ce processus en demandant une commande en cascade spécifique lorsque vous lancez la suppression.
Références du propriétaire
Les relations parent-enfant sont exprimées par des références de propriétaire Kubernetes. Les propriétaires sont responsables des objets qui y sont imbriqués. Cela crée un graphique de dépendance qui informe le processus de récupération de place.
Kubernetes utilise les données de référence du propriétaire pour déterminer quelles ressources doivent être supprimées avant qu'une cible ne soit supprimée. Par exemple, les pods qui font partie d'un ReplicaSet auront une référence de propriétaire qui définit ce lien. La suppression du ReplicaSet supprimera également automatiquement les pods qu'il contient.
Les références propriétaires sont définies sur les objets dans leur champ manifeste metadata.ownerReference. Vous ne devriez normalement pas avoir besoin d'inspecter ou de modifier manuellement ce champ, car les références du propriétaire sont automatiquement gérées par les contrôleurs Kubernetes.
Les enfants peuvent bloquer la suppression de leurs parents en définissant le champ metadata.blockOwnerDeletion sur la valeur booléenne true. Cela empêchera les parents de la chaîne ownerReference de l'objet d'être supprimés jusqu'à ce que l'objet lui-même ait été supprimé.
Mécanismes de suppression en cascade
La chaîne de référence du propriétaire signifie qu'il existe deux manières de procéder aux suppressions d'objets :
- Suppression en arrière-plan : l'objet cible est supprimé en premier, puis ses objets dépendants.
- Suppression du premier plan : les objets dépendants sont supprimés en premier, puis l'objet cible.
Envisagez une commande de suppression telle que la suivante :
$ kubectl delete deployment/demo-app
La méthode de suppression en arrière-plan supprimera immédiatement l'objet de déploiement de l'application de démonstration. Cela laissera ses pods en cours d'exécution dans votre cluster. Ils seront automatiquement nettoyés en arrière-plan dans le cadre du processus de récupération de place.
La suppression du premier plan commence par marquer le déploiement de l'application de démonstration comme une “suppression en cours”. Il supprime ensuite tous les objets dépendants qui existent en son sein. Le déploiement de l'application de démonstration restera visible dans votre cluster jusqu'à ce que ses pods aient été supprimés. Le déploiement sera nettoyé une fois que les personnes à charge auront disparu.
La cascade d'arrière-plan est le mécanisme par défaut. Il offre un résultat immédiat qui supprime l'objet cible de votre cluster sans délai. La suppression du premier plan peut cependant être plus souhaitable dans certains scénarios, par exemple lorsque vous souhaitez qu'un déploiement ou un ReplicaSet soit supprimé uniquement après la destruction de ses pods. Cela évite la brève période où les pods sont effectivement orphelins, avec leur propriétaire ReplicaSet déjà parti.
Vous pouvez opter pour la suppression du premier plan en passant l'indicateur –cascade=foreground à la commande kubectl delete :< /p> $ kubectl delete deployment/demo-app –cascade=foreground
Les pods seront supprimés, puis le déploiement de l'application de démonstration.
Désactiver la récupération de place des personnes à charge
Il existe une troisième option en cascade : ignorer complètement la récupération de place dépendante. Cela rendra orphelins tous les dépendants de l'objet, les laissant dans votre cluster mais avec leur référence de propriétaire supprimée.
$ kubectl delete deployment/demo-app –cascade=orphan
Cette commande supprime immédiatement le déploiement de l'application de démonstration mais laisse ses gousses intactes. Ils continueront à s'exécuter dans votre cluster jusqu'à ce qu'ils soient supprimés séparément, dans le cadre d'une autre commande. Bien que ce comportement soit rarement souhaitable, il peut être utile si vous décidez que les pods n'ont plus besoin d'être dans un Deployment ou un ReplicaSet.
Collecte de mémoire et finaliseurs
Les finaliseurs affectent également le fonctionnement de la récupération de place. Ils empêchent les suppressions de se produire jusqu'à ce que certaines conditions soient remplies.
Beaucoup semblent “bloqués” les suppressions sont causées par des finaliseurs en attente. Un finaliseur qui n'est pas marqué comme terminé empêchera la suppression de l'objet de votre cluster. Une fois le finaliseur effacé, le plan de contrôle Kubernetes procédera à la suppression.
Certains finaliseurs sont inclus avec Kubernetes, comme la protection pv-protection contre la suppression des volumes activement utilisés. D'autres peuvent être ajoutés par des contrôleurs tiers que vous ajoutez à votre cluster. Remplacer un finaliseur n'est pas recommandé car cela pourrait créer un état incorrect qui entraînerait un comportement inattendu.
Personnalisation de la récupération de place des ressources inutilisées
La récupération de place des conteneurs et des images redondants se produit automatiquement sur vos noeuds worker. Cinq paramètres sont disponibles pour régler les seuils de suppression :
- maximum-dead-containers – Nombre maximal d'anciens conteneurs pouvant continuer à exister après l'exécution de la récupération de place. La valeur par défaut de -1 supprime la limite.
- maximum-dead-containers-per-container – Définissez le nombre maximal d'anciens conteneurs conservés par conteneur. Cela contrôle le nombre de versions précédentes d'un conteneur qui restent dans le cluster après le démarrage d'un nouveau remplacement.
- minimum-container-ttl-duration – Les conteneurs deviennent éligibles à la collecte des ordures ce nombre de minutes après leur arrêt. La valeur par défaut de 0 désactive le délai.
- image-gc-high-threshold – Lorsque l'utilisation du disque atteint ce pourcentage, Kubelet essaiera de supprimer les images inutilisées …
- image-gc-low-threshold – …pour ramener l'utilisation à ce niveau.
Ces paramètres sont définis comme des indicateurs de lancement Kubelet. Les drapeaux sont généralement placés dans /var/lib/kubelet/kubeadm-flags.env :
KUBELET_KUBEADM_ARGS=”–image-gc-high-threshold=60 –image-gc-low-threshold=50 –minimum -container-ttl-duration=5″
Cette configuration permettra la suppression automatique des conteneurs qui ont été redondants pendant au moins cinq minutes. Chaque passe de récupération de place tentera également d'élaguer les anciennes images une fois que 60 % d'utilisation du disque est atteint, dans le but de réduire la consommation à 50 %.
Vous devez redémarrer le processus Kubelet après avoir apporté ces modifications :
$ sudo systemctl daemon-reload $ sudo systemctl restart kubelet
Comme les paramètres font partie de Kubelet, vous devrez les appliquer à chacun de vos nœuds de travail dans votre cluster si vous souhaitez que la configuration soit cohérente pour tous.
Résumé
Comprendre les différentes formes de récupération de place Kubernetes vous aide à choisir la bonne stratégie lors de la suppression d'objets de votre cluster. Les cascades d'arrière-plan et d'avant-plan affectent l'ordre dans lequel les ressources dépendantes sont nettoyées. Les relations entre les objets sont identifiées par leurs chaînes de référence de propriétaire. Kubernetes nettoie également les conteneurs inutilisés et les images en arrière-plan. Les seuils de ce comportement peuvent être personnalisés à l'aide des paramètres de Kubelet.
Pour de meilleurs résultats, vous devez vous en tenir aux mécanismes fournis par Kubernetes. Le projet met en garde contre l'utilisation d'outils de récupération de place tiers, car ceux-ci peuvent créer des incohérences d'état qui causent des problèmes dans votre cluster.
LIRE LA SUITE
- › JBL Live Free 2 Review : excellente suppression du bruit, son correct
- › 6 choses qui ralentissent votre Wi-Fi (et que faire à leur sujet)
- &rsaquo ; 10 fonctionnalités cachées d'Android 13 que vous auriez pu manquer
- &rsaquo ; Android 13 est sorti : nouveautés et date de disponibilité
- &rsaquo ; Il est normal de lésiner sur ces 10 produits technologiques
- &rsaquo ; Comment ajouter des visualisations Winamp à Spotify, YouTube, etc.