cobra-尋找scheduler元件啟動函式
main函式在哪裡?
看到這個go檔案時大家是不是有一種找到入口的欣喜,同時有一種難以言表的鬱悶,為什麼那麼短?獲取一個command,然後執行一個Execute()就運行了?好像是這麼回事,然後點開了Execute()方法:
越往下看越鬱悶,咋那麼難。。。
這時候看一下我們在哪裡,可以發現當前路徑是:
D:/go/src/k8s.io/kubernetes/vendor/github.com/spf13/cobra/command.go:790
尷尬,一開始就陷入了3方庫。點開NewSchedulerCommand()函式看看呢:
到這裡好像我們發現了什麼,cobra是個什麼東西?似乎cobra影響了整個程式碼結構,獲取command是cobra的Command物件,最後的Execute()方法也是cobra提供的方法。於是不難發現,這是一個繞不過去的三方庫,我們得先花點力氣查查cobra是什麼!
cobra是什麼?
我們可以在github上看到這個專案
來自spf13,看來是精品!上圖的英文介紹裡可以看到一點訊息:A Commander for modern Go CLI interactions
然後瀏覽一下README.md(建議大家到github上認真看一下這個說明文件),我們大致可以看出來
天哪,那麼多知名開源go專案,k8s生態的etcd、docker、之上的openshift等等居然都用了cobra!明顯這些專案都用了cobra當做“腳手架”,也就是入口風格會很像!spf13寫的pflag等都是大名鼎鼎的輪子中的精品啊,看來cobra很值得稍微深入一下,如果自己開發命令列工具,需要用到子命令和flag的話,spf13的cobra和pflag是不二之選了。
一句話介紹cobra,然後我們簡單實踐一下:支援子命令列模式和複雜flag的時髦命令列程式腳手架!
cobra程式長什麼樣?
要寫個demo,當然得先install cobra. 作為一隻gopher,我相信大家install 一個github上的go專案是沒有壓力的,此中無非可能遇到網路問題,go get不行就git clone,缺啥找啥,最終下載完是這樣的:
下面我們試著寫一個小小的cobra程式:
如上命令,cobra告訴我們application is ready at xxx,所以我們看一下本地生成了些什麼:
本地自動建立好了一個專案,我們看一下main.go裡面是什麼:
是不是有點小激動?和kube-scheduler的入口一樣一樣的!我們執行如下命令來新增2個command:
我們開啟version.go稍微修改一下:
發現沒有,當我們執行一個命令時,對應的command中Run方法會被執行!我們最後看一個子命令的玩法:
怎麼樣,輕輕鬆鬆寫了一個支援多級命令的程式,後面一張圖可以看到上面我們輸入命令中serverCmd的含義:
下面看kube-scheduler中對應的Run在哪裡?
cmd/kube-scheduler/app/server.go:322 func NewSchedulerCommand() *cobra.Command
繼續看一下Run:後面是什麼:
這個Run()方法繼續跟一下:
是不是發現好像接近真相了?
這個server.Run()我們繼續看看:
太和諧了!這個註釋也可以直觀看到這就是執行SchedulerServer的入口,這個函式接收到stop資訊前會一直執行下去,也就是一直執行著的kube-scheduler!!!
我們最後回頭看一下main.go
是不是很好理解了?第一個紅框中設定Run()方法中需要做什麼,後面的Execute()方法其實就是運行了前面定義的Run()方法!
今天就講到這裡,我們下一講尋找排程演算法!