Controller實(shí)現(xiàn)ReplicaSetController的示例分析

這篇文章給大家介紹Controller實(shí)現(xiàn)ReplicaSetController的示例分析，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

目前累計(jì)服務(wù)客戶上1000+，積累了豐富的產(chǎn)品開發(fā)及服務(wù)經(jīng)驗(yàn)。以網(wǎng)站設(shè)計(jì)水平和技術(shù)實(shí)力，樹立企業(yè)形象，為客戶提供成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站策劃、網(wǎng)頁設(shè)計(jì)、網(wǎng)絡(luò)營銷、VI設(shè)計(jì)、網(wǎng)站改版、漏洞修補(bǔ)等服務(wù)。成都創(chuàng)新互聯(lián)始終以務(wù)實(shí)、誠信為根本，不斷創(chuàng)新和提高建站品質(zhì)，通過對(duì)領(lǐng)先技術(shù)的掌握、對(duì)創(chuàng)意設(shè)計(jì)的研究、對(duì)客戶形象的視覺傳遞、對(duì)應(yīng)用系統(tǒng)的結(jié)合，為客戶提供更好的一站式互聯(lián)網(wǎng)解決方案，攜手廣大客戶，共同發(fā)展進(jìn)步。

Controller的實(shí)現(xiàn)基本上都是通過SharedInformer的結(jié)構(gòu)去監(jiān)聽etcd上某種資源的變更，然后再執(zhí)行對(duì)應(yīng)的業(yè)務(wù)邏輯。

以ReplicaSetController為例，介紹一個(gè)controller如何與整個(gè)manager組合在一起。

controller啟動(dòng)

controllers都是在NewControllerInitializers()方法中引入到manager里的：

func NewControllerInitializers() map[string]InitFunc {

controllers := map[string]InitFunc{}

....

controllers["replicaset"] = startReplicaSetController

....

return controllers

}

startReplicaSetController是啟動(dòng)函數(shù)，如下：

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

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

return false, nil

}

// 獲取監(jiān)聽ReplicaSets/Pods的Informer

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

}

創(chuàng)建過程如下：

// 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 {

....

// 初始化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"),

}

// 在replica set informer上注冊(cè)回調(diào)handler

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

// 在pod informer上注冊(cè)回調(diào)

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整個(gè)controller實(shí)際業(yè)務(wù)邏輯的入口，會(huì)被回調(diào)觸發(fā)

rsc.syncHandler = rsc.syncReplicaSet

return rsc

}

Replica Set資源變更回調(diào)

Informer監(jiān)聽到的變更最終會(huì)回調(diào)到syncReplicaSet方法上，但當(dāng)中會(huì)穿越多個(gè)協(xié)程，邏輯比較復(fù)雜。用一個(gè)時(shí)序圖近似表示如下：

1.Controller變更通知

這里的controller是Informer層的結(jié)構(gòu)，對(duì)于資源變更會(huì)觸發(fā)HandleDeltas()方法。HandleDeltas方法會(huì)調(diào)用sharedProcessor.distribute方法，將Delta傳入到processListener的channel上，等待被處理。

2.processorListener.run

run方法會(huì)不斷拉取listener自己本地channel中的變更，并根據(jù)ActionType分發(fā)到注冊(cè)的handler上的不同方法里。

在上文介紹的NewReplicaSetController()函數(shù)里，可以看到AddFunc對(duì)應(yīng)的回調(diào)函數(shù)是enqueueReplicaSet。最終會(huì)把delta放入ReplicaSetController自己的queue隊(duì)列中，等待controller處理。

3.ReplicaSetController.processNextItem

processNextItem方法會(huì)處理RepliaSetController.queue當(dāng)中的變更信息，最終調(diào)用syncReplicaSet方法來處理變更，確保Pods和配置一致。

Controller實(shí)現(xiàn)ReplicaSetController的示例分析

每個(gè)Controller的處理邏輯都不相同，但與manager & informer的交互大體類似。

ReplicaSetController的分析中可以再次看出go實(shí)現(xiàn)中，調(diào)用順序和傳統(tǒng)面向?qū)ο笳Z言有很大差異。

關(guān)于Controller實(shí)現(xiàn)ReplicaSetController的示例分析就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

文章標(biāo)題：Controller實(shí)現(xiàn)ReplicaSetController的示例分析
分享URL：http://weahome.cn/article/pcgihh.html

真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

Controller實(shí)現(xiàn)ReplicaSetController的示例分析

controller啟動(dòng)

Replica Set資源變更回調(diào)

1.Controller變更通知

2.processorListener.run

3.ReplicaSetController.processNextItem

其他資訊

網(wǎng)站制作

企業(yè)服務(wù)

網(wǎng)站建設(shè)

服務(wù)器托管