You are viewing documentation for Kubernetes version: v1.31
Kubernetes v1.31 documentation non maintenue. Vous consultez une version statique. Pour une documentation à jour, veuillez consulter: dernière version.
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 :
- Pods terminés
- Jobs terminés
- Objets sans références de propriétaire
- Conteneurs et images inutilisés
- PersistentVolumes provisionnés dynamiquement avec une politique de récupération de classe de stockage Delete
- CertificateSigningRequests (CSRs) obsolètes ou expirés
- Nodes supprimés dans les scénarios suivants :
- Sur un cloud lorsque le cluster utilise un gestionnaire de contrôleur cloud
- Sur site lorsque le cluster utilise un addon similaire à un gestionnaire de cloud
- Objets de bail de nœud
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.
Note:
Les références de propriétaire entre namespaces sont interdites par conception. Les dépendants dans un namespace peuvent spécifier des propriétaires à portée de cluster ou à portée de namespace. Un propriétaire à portée de namespace doit exister dans le même namespace que le dépendant. S'il n'existe pas, la référence de propriétaire est considérée comme absente et le dépendant est susceptible d'être supprimé une fois que tous les propriétaires sont vérifiés comme absents.
Les dépendants à portée de cluster ne peuvent spécifier que des propriétaires à portée de cluster. À partir de la version 1.20, si un dépendant à portée de cluster spécifie un type à portée de namespace en tant que propriétaire, il est considéré comme ayant une référence de propriétaire non résoluble et ne peut pas être collecté par le garbage collector.
À partir de la version 1.20, si le garbage collector détecte une référence de propriétaire non valide entre namespaces,
ou un dépendant à portée de cluster avec une référence de propriétaire faisant référence à un type à portée de namespace, un événement d'avertissement
avec une raison de OwnerRefInvalidNamespace et un involvedObject du dépendant non valide est signalé.
Vous pouvez vérifier ce type d'événement en exécutant
kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace.
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.deletionTimestampde l'objet sur l'heure à laquelle l'objet a été marqué pour suppression. - Le serveur API Kubernetes définit également le champ
metadata.finalizerssurforegroundDeletion. - 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 :
HighThresholdPercentLowThresholdPercent
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
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.
Note:
Cette fonctionnalité ne suit pas l'utilisation des images entre les redémarrages du kubelet. Si le kubelet est redémarré, l'âge de l'image suivi est réinitialisé, ce qui fait que le kubelet attend la durée complèteimageMaximumGCAge avant de qualifier les images pour la collecte des déchets
en fonction de l'âge de l'image.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 sur0.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.
Note:
Le kubelet ne collecte que les conteneurs qu'il gère.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 :
- Configuration de la suppression en cascade des objets Kubernetes
- Configuration du nettoyage des Jobs terminés
A suivre
- En savoir plus sur la propriété des objets Kubernetes.
- En savoir plus sur les finalizers Kubernetes.
- Découvrez le contrôleur TTL qui nettoie les Jobs terminés.