Information in this document may be out of date

This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: Garbage Collection

Collecte des déchets

Le Garbage collection est un terme générique désignant les différents mécanismes utilisés par Kubernetes pour nettoyer les ressources du cluster. Cela permet le nettoyage des ressources suivantes :

Propriétaires et dépendants

De nombreux objets dans Kubernetes sont liés les uns aux autres par le biais de références de propriétaire. Les références de propriétaire indiquent au plan de contrôle quels objets dépendent des autres. Kubernetes utilise les références de propriétaire pour permettre au plan de contrôle et aux autres clients de l'API de nettoyer les ressources associées avant de supprimer un objet. Dans la plupart des cas, Kubernetes gère automatiquement les références de propriétaire.

La propriété est différente du mécanisme étiquettes et sélecteurs que certains ressources utilisent également. Par exemple, considérez un Service qui crée des objets EndpointSlice. Le Service utilise des étiquettes pour permettre au plan de contrôle de déterminer quels objets EndpointSlice sont utilisés pour ce Service. En plus des étiquettes, chaque EndpointSlice géré au nom d'un Service a une référence de propriétaire. Les références de propriétaire aident les différentes parties de Kubernetes à éviter d'interférer avec les objets qu'elles ne contrôlent pas.

Suppression en cascade

Kubernetes vérifie et supprime les objets qui n'ont plus de références de propriétaire, comme les pods laissés derrière lors de la suppression d'un ReplicaSet. Lorsque vous supprimez un objet, vous pouvez contrôler si Kubernetes supprime automatiquement les objets dépendants, dans un processus appelé suppression en cascade. Il existe deux types de suppression en cascade, comme suit :

  • Suppression en cascade en premier plan
  • Suppression en cascade en arrière-plan

Vous pouvez également contrôler comment et quand la collecte des déchets supprime les ressources qui ont des références de propriétaire en utilisant les finalizers Kubernetes.

Suppression en cascade en premier plan

Dans la suppression en cascade en premier plan, l'objet propriétaire que vous supprimez entre d'abord dans un état de suppression en cours. Dans cet état, les actions suivantes se produisent sur l'objet propriétaire :

  • Le serveur API Kubernetes définit le champ metadata.deletionTimestamp de l'objet sur l'heure à laquelle l'objet a été marqué pour suppression.
  • Le serveur API Kubernetes définit également le champ metadata.finalizers sur foregroundDeletion.
  • L'objet reste visible via l'API Kubernetes jusqu'à ce que le processus de suppression soit terminé.

Après que l'objet propriétaire entre dans l'état de suppression en cours, le contrôleur supprime les dépendants. Après avoir supprimé tous les objets dépendants, le contrôleur supprime l'objet propriétaire. À ce stade, l'objet n'est plus visible dans l'API Kubernetes.

Pendant la suppression en cascade en premier plan, seuls les dépendants qui bloquent la suppression du propriétaire sont ceux qui ont le champ ownerReference.blockOwnerDeletion=true. Consultez Utiliser la suppression en cascade en premier plan pour en savoir plus.

Suppression en cascade en arrière-plan

Dans la suppression en cascade en arrière-plan, le serveur API Kubernetes supprime immédiatement l'objet propriétaire et le contrôleur nettoie les objets dépendants en arrière-plan. Par défaut, Kubernetes utilise la suppression en cascade en arrière-plan, sauf si vous utilisez manuellement la suppression en premier plan ou choisissez d'abandonner les objets dépendants.

Consultez Utiliser la suppression en cascade en arrière-plan pour en savoir plus.

Dépendants orphelins

Lorsque Kubernetes supprime un objet propriétaire, les dépendants laissés derrière sont appelés objets orphelins. Par défaut, Kubernetes supprime les objets dépendants. Pour apprendre comment outrepasser ce comportement, consultez Supprimer les objets propriétaires et les dépendants orphelins.

Collecte des déchets des conteneurs et des images inutilisés

Le kubelet effectue la collecte des déchets sur les images inutilisées toutes les deux minutes et sur les conteneurs inutilisés toutes les minutes. Vous devez éviter d'utiliser des outils de collecte des déchets externes, car ils peuvent perturber le comportement du kubelet et supprimer des conteneurs qui devraient exister.

Pour configurer les options de collecte des déchets des conteneurs et des images inutilisés, ajustez le kubelet en utilisant un fichier de configuration et modifiez les paramètres liés à la collecte des déchets en utilisant le type de ressource KubeletConfiguration.

Cycle de vie des images de conteneur

Kubernetes gère le cycle de vie de toutes les images via son gestionnaire d'images, qui fait partie du kubelet, en collaboration avec cadvisor. Le kubelet prend en compte les limites d'utilisation du disque suivantes lors de la prise de décision de collecte des déchets :

  • HighThresholdPercent
  • LowThresholdPercent

Une utilisation du disque supérieure à la valeur configurée de HighThresholdPercent déclenche la collecte des déchets, qui supprime les images dans l'ordre en fonction de leur dernière utilisation, en commençant par les plus anciennes en premier. Le kubelet supprime les images jusqu'à ce que l'utilisation du disque atteigne la valeur LowThresholdPercent.

Collecte des déchets pour les images de conteneur inutilisées

FEATURE STATE: Kubernetes v1.30 [beta] (enabled by default: true)

En tant que fonctionnalité bêta, vous pouvez spécifier la durée maximale pendant laquelle une image locale peut rester inutilisée, indépendamment de l'utilisation du disque. Il s'agit d'un paramètre du kubelet que vous configurez pour chaque nœud.

Pour configurer le paramètre, activez la fonctionnalité ImageMaximumGCAge feature gate pour le kubelet, et définissez également une valeur pour le champ imageMaximumGCAge dans le fichier de configuration du kubelet.

La valeur est spécifiée en tant que durée Kubernetes ; Les unités de temps valides pour le champ imageMaximumGCAge dans le fichier de configuration du kubelet sont :

  • "ns" pour les nanosecondes
  • "us" ou "µs" pour les microsecondes
  • "ms" pour les millisecondes
  • "s" pour les secondes
  • "m" pour les minutes
  • "h" pour les heures

Par exemple, vous pouvez définir le champ de configuration sur 12h45m, ce qui signifie 12 heures et 45 minutes.

Collecte des déchets des conteneurs

Le kubelet collecte les conteneurs inutilisés en fonction des variables suivantes, que vous pouvez définir :

  • MinAge : l'âge minimum auquel le kubelet peut collecter les conteneurs. Désactivez en définissant sur 0.
  • MaxPerPodContainer : le nombre maximum de conteneurs inactifs que chaque Pod peut avoir. Désactivez en définissant sur une valeur inférieure à 0.
  • MaxContainers : le nombre maximum de conteneurs inactifs que le cluster peut avoir. Désactivez en définissant sur une valeur inférieure à 0.

En plus de ces variables, le kubelet collecte les conteneurs non identifiés et supprimés, généralement en commençant par les plus anciens.

MaxPerPodContainer et MaxContainers peuvent potentiellement entrer en conflit les uns avec les autres dans des situations où le maintien du nombre maximum de conteneurs par Pod (MaxPerPodContainer) dépasserait le total autorisé de conteneurs inactifs globaux (MaxContainers). Dans cette situation, le kubelet ajuste MaxPerPodContainer pour résoudre le conflit. Le pire des cas serait de réduire MaxPerPodContainer à 1 et d'évacuer les conteneurs les plus anciens. De plus, les conteneurs appartenant à des pods qui ont été supprimés sont supprimés une fois qu'ils sont plus anciens que MinAge.

Configuration de la collecte des déchets

Vous pouvez ajuster la collecte des déchets des ressources en configurant des options spécifiques aux contrôleurs qui gèrent ces ressources. Les pages suivantes vous montrent comment configurer la collecte des déchets :

A suivre

Dernière modification September 12, 2024 at 5:07 PM PST: Update French documentation for concept architecture (48766a92ac)