Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "what is the garbage collection method in Kubernetes". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Consider a scenario; you create a deployment object in Kubernetes; therefore, it generates a replica set and pod based on the list provided. Later, you realized that you had missed the properties of a container, and to quickly fix it, you edited the deployment. Deployment of the version results in a new replica set object and an updated Pod. You know what happens to the old one? Similarly, what happens to the replica set or Pod if the deployment is deleted. The answer is obvious. Deleting the deployment will delete the replica set and Pod;, otherwise, it will become a mess.

The above statement raises a bigger question: how is cascading deletion implemented in Kubernetes, is there multiple cascading deletion strategies, and is it possible to have orphaned objects in K8? It seems that this is a typical garbage collection problem.

What is garbage collection (GC)?

In short, garbage collection is about removing unused objects from the system and releasing the computing resources allocated to them. GC appears in all high-level programming languages, while low-level programming languages have GC through system libraries.

One of the most common algorithms for GC is tag scanning. I didn't give the details of the algorithm, but we can explain it from the point of view that the title has two phases, marking the objects deleted during the cleanup phase in the first phase.

> From Wikipedia

This is a very short description of GC, and if necessary, follow the links posted in the reference section for detailed instructions. Now, we will explore how to implement GC in K8s.

Owner-owned; OwnerReference metadata

Like object-oriented languages, some objects refer to other objects / consist of other objects, and in Kubernetes, some objects own other objects in a similar manner. For example, the replica set is the owner of a set of Pod, while the deployment is the owner of the replica set.

Unlike object-oriented languages, we have never explicitly defined or written an owner-related relationship in the K8s object list definition, but how does the system determine that relationship? In K8s, each dependent object has a unique metadata field name metas.ownerReferences for relational representation.

Starting with Kubernetes 1.8, K8 sets the value of ownerReferences for objects created or adopted by specific controllers, such as ReplicaSet,StatefulSet,DaemonSet,Deployment,Job and CronJob.

You can also set the ownerReferences manually, if desired.

An object can have multiple ownerReferences, for example, in a namespace.

The metadata.ownerReferences values for core-dns deployment on the Kind K8s stand-alone cluster are shown below

If you take a closer look at the output of the above command, you will see a slight difference from other GC implementations. The object association reference pyramid is upside down, not the conventional one. The following figure will help you.

> Downside Up association of the objects in K8s

Garbage Collection Strategy in Kubernetes

As mentioned earlier, prior to Kubernetes 1.8, dependent object deletion logic was implemented on the client side and on the controller side for some resources. The client is not an atomic operation, and sometimes a midway failure can lead to a chaotic state of the cluster and need to be cleaned up manually. Later, to solve this problem, the K8s community introduced and implemented a garbage collector controller to handle GC in a better and simpler way.

In K8 for unused object GC, there are two main categories:

Cascading: in one of the cascades, the deletion of the owner causes dependent objects to be deleted from the cluster.

Orphans: as the name implies, deleting the owner object only removes it from the cluster and puts all dependent objects in an "orphan" state.

Let's take an in-depth look at the above strategy.

In the cascading delete policy, the dependent object is deleted along with the owner object. Within the cascade, there are two modes: foreground and background.

Foreground cascading deletion: in the foreground policy, owner object deletion waits until all dependent objects are deleted. The first change occurs when the foreground delete is the owner object state changed to the deletion in progress. The properties of objects in the deleting state are as follows:

With REST API, the object is still visible

The deleteTimestamp of the object is set

The metadata of the object. Finalizers contains the value "foregroundDeletion".

Once the state changes, the garbage collector deletes all "blocking" dependencies (the owner refers to the object of .blockOwnerDeletion = true), and finally deletes the owner object.

Background cascading deletion: this is much simpler, in which case it deletes the owner object directly. Later, GC determines the relevant objects and deletes them from the background. It is much faster than the foreground because there is no waiting time to delete the dependent object.

In the isolation policy, the owner object is deleted and the ownerReferences metadata in the dependent object is set to the default value. The GC controller then determines the orphaned object and deletes it.

How does the Kubernetes garbage collector controller work?

If there is no owner object in the object's OwnerReferences metadata, the GC controller is responsible for deleting the object. The GC controller consists of a scanner, a garbage processor and a communicator.

Scanner: use Discovery API, which detects all resources supported in the K8s cluster, periodically detects it through a control loop, scans all resources in the system, and adds each object to the "dirty queue".

Garbage disposal: made up of workers working on a "dirty queue". Each staff member takes an item from the "dirty queue" and checks to see if the project's OwnerReferences is empty. If empty, only the next entry is fetched from the Dirty queue for processing; otherwise, each entry in the OwnerReferences metadata is checked. If none of the owners listed in OwnerReferences exist, the worker asks the API server to delete the object.

Communicator: the communicator is used to optimize the GC controller and consists of three components. DAG for event queues, individual workers, and owner-related relationships. The following are the characteristics of the breeder

DAG stores only the name / uid / orphaned triples, not the entire body of each project.

Monitor the create / update / delete events of all resources and queue the events.

The worker removes the project from the event queue.

The creation or update of the K8s object updates the DAG accordingly. If the resource has an owner that does not already exist in the DAG, it queues objects to the "dirty queue" in addition to adding objects to the DAG.

Deleting the K8s object removes it from the DAG and queues all its dependents to the "dirty queue".

The propagator does not need to perform any RPC, so only one worker thread is sufficient, and it is easier to lock.

With the propagator, we just need to run the scanner when we start GC to populate the DAG and dirty queues.

This is the end of the content of "what are the garbage collection methods in Kubernetes"? thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.