Shulou(Shulou.com)05/31 Report--

This article introduces Controller to achieve ReplicaSetController example analysis, the content is very detailed, interested friends can refer to, hope to be helpful to you.

Basically, the implementation of Controller is to listen for changes in certain resources on the etcd through the structure of SharedInformer, and then execute the corresponding business logic.

Take ReplicaSetController as an example to show how one controller can be combined with the whole manager.

Controller start

Controllers is introduced into manager in the NewControllerInitializers () method:

Func NewControllerInitializers () map [string] InitFunc {

Controllers: = map [string] InitFunc {}

....

Controllers ["replicaset"] = startReplicaSetController

....

Return controllers

}

StartReplicaSetController is the startup function, as follows:

Func startReplicaSetController (ctx ControllerContext) (bool, error) {

If! ctx.AvailableResources [schema.GroupVersionResource {Group: "extensions", Version: "v1beta1", Resource: "replicasets"}] {

Return false, nil

}

/ / get the Informer that listens to ReplicaSets/Pods

Go replicaset.NewReplicaSetController (

Ctx.InformerFactory.Extensions (). V1beta1 (). ReplicaSets ()

Ctx.InformerFactory.Core (). V1 (). Pods ()

Ctx.ClientBuilder.ClientOrDie ("replicaset-controller")

Replicaset.BurstReplicas

) .run (int (ctx.Options.ConcurrentRSSyncs), ctx.Stop)

Return true, nil

}

The creation process is as follows:

/ / NewReplicaSetController configures a replica set controller with the specified event recorder

Func NewReplicaSetController (rsInformer extensionsinformers.ReplicaSetInformer, podInformer coreinformers.PodInformer, kubeClient clientset.Interface, burstReplicas int) * ReplicaSetController {

....

/ / initialize controller

Rsc: = & ReplicaSetController {

KubeClient: kubeClient

PodControl: controller.RealPodControl {

KubeClient: kubeClient

Recorder: eventBroadcaster.NewRecorder (scheme.Scheme, v1.EventSource {Component: "replicaset-controller"})

}

BurstReplicas: burstReplicas

Expectations: controller.NewUIDTrackingControllerExpectations (controller.NewControllerExpectations ())

Queue: workqueue.NewNamedRateLimitingQueue (workqueue.DefaultControllerRateLimiter (), "replicaset")

}

/ / register callback handler on replica set informer

RsInformer.Informer () .AddEventHandler (cache.ResourceEventHandlerFuncs {

AddFunc: rsc.enqueueReplicaSet

UpdateFunc: rsc.updateRS

/ / This will enter the sync loop and no-op, because the replica set has been deleted from the store.

/ / Note that deleting a replica set immediately after scaling it to 0 will not work. The recommended

/ / way of achieving this is by performing a `stop` operation on the replica set.

DeleteFunc: rsc.enqueueReplicaSet

})

Rsc.rsLister = rsInformer.Lister ()

Rsc.rsListerSynced = rsInformer.Informer () .HasSynced

/ / register callback on pod informer

PodInformer.Informer () .AddEventHandler (cache.ResourceEventHandlerFuncs {

AddFunc: rsc.addPod

/ / This invokes the ReplicaSet for every pod change, eg: host assignment. Though this might seem like

/ / overkill the most frequent pod update is status, and the associated ReplicaSet will only list from

/ / local storage, so it should be ok.

UpdateFunc: rsc.updatePod

DeleteFunc: rsc.deletePod

})

Rsc.podLister = podInformer.Lister ()

Rsc.podListerSynced = podInformer.Informer () .HasSynced

/ / syncReplicaSet the entry of the entire controller actual business logic, which will be triggered by a callback

Rsc.syncHandler = rsc.syncReplicaSet

Return rsc

}

Replica Set resource change callback

The changes monitored by Informer will eventually be called back to the syncReplicaSet method, but it will traverse multiple cooperators and the logic is more complex. The approximate representation of a timing diagram is as follows:

1.Controller change Notification

The controller here is the structure of the Informer layer, and the HandleDeltas () method is triggered for resource changes. The HandleDeltas method calls the sharedProcessor.distribute method, passing the Delta to the channel of the processListener, waiting to be processed.

2.processorListener.run

The run method constantly pulls changes in listener's own local channel and distributes them to different methods on the registered handler according to the ActionType.

In the NewReplicaSetController () function introduced above, you can see that the callback function corresponding to AddFunc is enqueueReplicaSet. Eventually, the delta will be put into ReplicaSetController's own queue queue, waiting for controller to process.

3.ReplicaSetController.processNextItem

The processNextItem method handles the change information in the RepliaSetController.queue, and finally calls the syncReplicaSet method to handle the change, ensuring that the Pods and configuration are consistent.

The processing logic of each Controller is different, but it is roughly similar to the interaction of manager & informer.

In the analysis of ReplicaSetController, we can see once again that the calling order in go implementation is very different from that in traditional object-oriented languages.

This is the end of the sample analysis on the implementation of ReplicaSetController in Controller. I hope the above content can be of some help and learn more knowledge. If you think the article is good, you can share it for more people to see.

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.