Kubernetes1.3 new feature: New Resource Recovery controller

(i) Core concepts

In kubernetes1.3, a new resource recovery controller Garbasecollector is used to replace the resource Recovery controller GC in kubernetes1.3.

The following is the resource recovery controller structure in kubernetes1.2:

The following is the resource recovery controller structure in kubernetes1.3:

In kubernetes1.2, if you want to implement a resource-cascading reclamation, you need to implement the resource Cascade recycle call through the client, such as there is a replica set type of resource, there are multiple pod resources under this resource, If we use the command line to cascade Delete, we need to use the Kubect command to remove all the pod resources below the replica set, and then delete this replica set resource, the logical processing of the resource cascade deletion is done through the client.

In kubernetes1.3, the logical processing of the resource Cascade Recycle function can be put on the service side, which reduces the workload of the Client maintenance logic processing, facilitates the user's use, and further perfects the kubernetes as a platform resource recovery function. In order to realize the above idea, the resource recovery controller structure was redesigned in kubernetes1.3, and the finalizer mechanism, such as the "orphan" finalizer mechanism in 1.3, was introduced to allow the user to make flexible choices.

(ii) Use of the introduction

This new recovery controller is an alpha version, which means it is not recommended to be used in the production process.

In kubernetes1.3, a new startup parameter Enable-garbage-collector is added, the type of this parameter is Boolean, if this parameter is set to True, then the Recycle controller garbasecollector is enabled. It is important to note that this startup parameter enable-garbage-collector is present in both the Kube-apiserver and Kube-controller-manager two modules, and if you want to make this function effective, It needs to be set up in both Kube-apiserver and Kube-controller-manager two modules.

The struct Objectmeta represents the metadata for each object in the Kubernetes, In kubernetes1.3, two new variables are added, ownerreferences and Finalizers, where the first variable ownerreferences is a struct array, the corresponding struct is ownerreference, which represents the list of other objects on which this object depends; The second variable, finalizers, is an array of strings that represents all the finalizers that need to be run before the object is deleted.

There is a Boolean variable controller in the struct ownerreference, if the value of this variable is true, then the associated object is the management controller. Because all Ownerreference objects associated with this object by the Objectmeta object must be in the same namespace, there is no namespace variable in ownerreference.

Through the association between the Objectmeta and the ownerreference two structures, it is possible to remove all other objects that are dependent on the object first, and finally delete the object to achieve the purpose of cascade recycling the resources.

The Recycle controller Garbagecollector provides a management queue Dirtyqueue:

The recycle controller puts all the objects in the Kubernetes system into this management queue, then the recycle controller takes the objects from the Dirtyqueue queue and then recycles the resources, and the process of recycling is running concurrently. 5 workers are started by default in Kube-controller-manager for processing.

The process for each worker is as follows:

The Recycle controller Garbagecollector also provides a variable propagator:

The corresponding structure of this variable propagator is as follows:

The function of this struct is to monitor various events of all resources in the kubernetes, including creating, updating, deleting, and then putting these events into the event queue EventQueue, and then initiating a worker that takes an event from the event queue EventQueue. The process is then processed to maintain the correct object dependencies.

For example, when an object exists to create or update an event, Propagator will determine whether the object exists owner, that is to say whether the object exists owners, if there is owner, and the owner does not exist, Then put this object in the Dirtyqueue queue for processing.

For example, when an object has a delete event, Propagator removes the object from the object dependency and places all objects that the object relies on into the dirtyqueue queue for processing.

Propagator Maintenance object dependencies need to be used to struct node, as shown in:

From the owner's point of view, all dependent objects can be queried, as shown in this structure:

From the whole, each node exists owner, and there are dependent, as shown in:

The kubernetes1.3 Recovery controller Garbagecollector provides the finalizer mechanism, which means that the contents of the object before being deleted must be processed, finalizers is an array of strings, each string table Shows a finalizer processing logic. Under this mechanism, the recovery controller Garbagecollector provides a "orphan" finalizer logic that takes advantage of the Orphanqueue queue variables in the recovery controller structure:

The orphandependents variables in the structure deleteoptions are also used:

The variable orphandependents is a Boolean variable. When the value is true, if Apiserver receives a delete request at this time, then API server updates the finalizers variable in the OBJECTMETA structure where the object is deleted, adding the string "orphan" to indicate that the object needs to be executed The finalizer processing logic of "orphan"; when the value is False, if the API server receives a delete request at this time, then API server updates the finalizers variable in the OBJECTMETA structure where the object is deleted. Delete the string "orphan", which means that the object does not need to perform "orphan" finalizer processing logic.

The finalizer processing logic of this "orphan" is kubernetes1.3 the newly added function of resource cascade deletion on the server. The recycle controller takes the object from the Orphanqueue queue and then "orphan" processing, and the "orphan" process runs concurrently, starting with 5 workers by default in Kube-controller-manager, The process is to query the dependent object in the node structure of the object and send a "PATCH" instruction to the API server for deletion. The finalizer processing of "orphan" finally removes the "orphan" string from the finalizers variable in the Objectmeta struct, thus completing the entire "orphan" process.

Kubernetes1.3 new feature: New Resource Recovery controller