您好,登錄后才能下訂單哦!
這篇文章主要介紹了kubernetes代碼閱讀apiserver的示例分析,具有一定借鑒價值,感興趣的朋友可以參考下,希望大家閱讀完這篇文章之后大有收獲,下面讓小編帶著大家一起了解一下。
apiserver是整個kubernetes的核心模塊,做的事情多,代碼量也較大。市面上已經有不少apiserver代碼解讀的文章了,但問題在于,由于k8s的代碼變化很快,想寫一篇長久能用的未必能做到。所以,我參照了《Kubernetes權威指南》和浙大SEL實驗室的一些文章,先把我看到的東西記下來,待后觀是否有用。
kubernetes源代碼版本1.2.0
先簡單講講整個代碼的目錄結構
目錄 | 說明 |
---|---|
api | 輸出接口文檔用 |
build | 構建腳本 |
cluster | 適配不同I層的云,例如亞馬遜AWS,微軟Azure,谷歌GCE的集群啟動腳本 |
cmd | 所有的二進制可執行文件入口代碼,例如apiserver/scheduler/kubelet |
contrib | 項目貢獻者 |
docs | 文檔,包括了用戶文檔、管理員文檔、設計、新功能提議 |
example | 使用案例 |
Godeps | 項目中依賴使用的Go第三方包,例如docker客戶端SDK,rest等 |
hack | 工具箱,各種編譯、構建、測試、校驗的腳本都在這里面 |
hooks | git提交前后觸發的腳本 |
pkg | 項目代碼主目錄,cmd的只是個入口,這里是所有的具體實現 |
plugin | 插件,k8s認為調度器是插件的一部分,所以調度器的代碼在這里 |
release | 應該是Google發版本用的? |
test | 測試相關的工具 |
third_party | 一些第三方工具,應該不是強依賴的? |
www | UI,不過已經被移動到新項目了 |
可以看到,關鍵實現代碼都放在pkg這個目錄下。對于apiserver這種跨度很廣的組件而言,唯一有效的閱讀方式估計就是
遍歷pkg下所有的目錄,概覽大概知道這個目錄是干啥的
從cmd這個入口來看apiserver的代碼,然后一點點由淺入深,看apiserver的大致實現
分特性,看具體某個大的特性是怎么實現的,例如安全,例如和etcd存儲對接
在上面這幾步的過程中可以看看別人的代碼閱讀文檔,能有效的節省時間
apiserver是k8s系統中所有對象的增刪查改盯的http/restful式服務端,其中盯是指watch操作。數據最終存儲在分布式一致的etcd存儲內,apiserver本身是無狀態的,提供了這些數據訪問的認證鑒權、緩存、api版本適配轉換等一系列的功能。
restful服務入門
對于http服務和使用go語言實現方式,可以看go-restful的文檔和例子,對這個有基本的了解,這個文檔對入門者和一知半解者極為有效!
古人有言,程序就是算法+數據結構,搞懂了數據結構,整個程序的處理過程就明白了一半。對于apiserver的任何一個api請求來說,上圖說明了所有的數據結構關系。
k8s放在etcd內的存儲對象是api.Pod對象(無版本),從不同版本的請求路徑標識來操作,例如api/v1
,最后獲取到的是不同版本,例如v1.Pod
的json文本。這里就經歷了幾個過程,包括
http client訪問/api/v1/pod/xyz,想要獲取這個Pod的數據
從etcd獲取到api.Pod對象
api.Pod對象轉換為v1.Pod對象
v1.Pod對象序列化為json或yaml文本
文本通過http的response體,返回給http client
其中用于處理業務數據的關鍵數據結構是APIGroupVersion,里面的幾個成員變量的作用是:
成員 | 作用 |
---|---|
GroupVersion | 包含 api/v1 這樣的string,用于標識這個實例 |
Serializer | 對象序列化和反序列化器 |
Converter | 這是一個強大的數據結構,這里放的是個接口,本體在/pkg/conversion/conversion.go ,幾乎可以轉換任意一種對象到另一種,只要你事先注入了相應的轉換函數 |
Storage | 這個map的key,用于對象的url,value是一個rest.Storage結構,用于對接etcd存儲,在初始化注冊時,會把這個map化開,化為真正的rest服務到存儲的一條龍服務 |
文件 | 主要數據結構/函數 | 用途 |
---|---|---|
kubernetes/cmd/kube-apiserver/apiserver.go | 入口 | |
kubernetes/cmd/kube-apiserver/app/options/options.go | struct APIServer | 啟動選項 |
kubernetes/cmd/kube-apiserver/apiserver.go | func Run | 初始化一些客戶端、啟動master對象 |
kubernetes/pkg/genericapiserver/genericapiserver.go | func Run | 啟動安全和非安全的http服務 |
k8s采用ApiGroup來管理所有的api分組和版本升級,目前有的API分組包括
核心組,REST路徑在 /api/v1
,但這個路徑不是固定的,v1是當前的版本。與之相對應的代碼里面的apiVersion
字段的值是 v1
。
擴展組,REST路徑在 /apis/extensions/$VERSION
,相對應的代碼里面的 apiVersion: extensions/$VERSION
(例如當前的apiVersion: extensions/v1beta1
)。這里提供的API對象今后有可能會被移動到別的組內。
"componentconfig"和 "metrics"這這些組。
在這個文檔里面講述了實現ApiGroup的幾個目標,包括api分組演化,對舊版API的向后兼容(Backwards compatibility),包括用戶可以自定義自己的api等。接下來我們看看他么是怎么初始化注冊的,這里都是縮減版代碼,去掉了其他部分。
kubernetes/pkg/master/master.go
api注冊入口
func New(c *Config) (*Master, error) { m.InstallAPIs(c) }
根據Config往APIGroupsInfo
內增加組信息,然后通過InstallAPIGroups
進行注冊
func (m *Master) InstallAPIs(c *Config) { if err := m.InstallAPIGroups(apiGroupsInfo); err != nil { glog.Fatalf("Error in registering group versions: %v", err) } }
轉換為APIGroupVersion
這個關鍵數據結構,然后進行注冊
func (s *GenericAPIServer) installAPIGroup(apiGroupInfo *APIGroupInfo) error { apiGroupVersion, err := s.getAPIGroupVersion(apiGroupInfo, groupVersion, apiPrefix) if err := apiGroupVersion.InstallREST(s.HandlerContainer); err != nil { return fmt.Errorf("Unable to setup API %v: %v", apiGroupInfo, err) } }
關鍵數據結構
kubernetes/pkg/apiserver/apiserver.go
type APIGroupVersion struct { Storage map[string]rest.Storage Root string // GroupVersion is the external group version GroupVersion unversioned.GroupVersion }
實際注冊的Storage的map如下:
kubernetes/pkg/master/master.go
m.v1ResourcesStorage = map[string]rest.Storage{ "pods": podStorage.Pod, "pods/attach": podStorage.Attach, "pods/status": podStorage.Status, "pods/log": podStorage.Log, "pods/exec": podStorage.Exec, "pods/portforward": podStorage.PortForward, "pods/proxy": podStorage.Proxy, "pods/binding": podStorage.Binding, "bindings": podStorage.Binding,
那么,這里的map[string]rest.Storage
最后是怎么變成一個具體的API來提供服務的呢?例如這么一個URL:
GET /api/v1/namespaces/{namespace}/pods/{name}
restful服務的實現
k8s使用的一個第三方庫github.com/emicklei/go-restful
,里面提供了一組核心的對象,看例子
數據結構 | 功能 | 在k8s內的位置 |
---|---|---|
restful.Container | 代表一個http rest服務對象,包括一組restful.WebService | genericapiserver.go - GenericAPIServer.HandlerContainer |
restful.WebService | 由多個restful.Route組成,處理這些路徑下所有的特殊的MIME類型等 | api_installer.go - NewWebService() |
restful.Route | 路徑——處理函數映射map | api_installer.go - registerResourceHandlers() |
實際注冊過程
kubernetes/pkg/apiserver/api_installer.go
func (a *APIInstaller) registerResourceHandlers(path string, storage rest.Storage, ws *restful.WebService, proxyHandler http.Handler) (*unversioned.APIResource, error) { }
最終的API注冊過程是在這個函數中完成的,把一個rest.Storage對象轉換為實際的getter, lister等處理函數,并和實際的url關聯起來。
上面已經基本厘清了從http請求 -> restful.Route -> rest.Storage這條線路,那rest.Storage僅僅是一個接口,有何德何能,可以真正的操作etcd呢?
這段也是牽涉到多個文件,但還比較清晰,首先,所有的對象都有增刪改查這些操作,如果為Pod單獨搞一套,Controller單獨搞一套,那代碼會非常重復,不可復用,所以存儲的關鍵目錄是在這里:
kubernetes/pkg/registry/generic/etcd/etcd.go
這個文件定義了所有的對etcd對象的操作,get,list,create等,但具體的對象是啥,這個文件不關心;etcd客戶端地址,這個文件也不關心。這些信息都是在具體的PodStorage對象創建的時候注入的。以Pod為例子,文件在:
kubernetes/pkg/registry/pod/etcd/etcd.go
這里的NewStorage
方法,把上述的信息注入了etcd里面去,生成了PodStorage這個對象。
// REST implements a RESTStorage for pods against etcd type REST struct { *etcdgeneric.Etcd proxyTransport http.RoundTripper }
由于PodStorage.Pod是一個REST類型,而REST類型采用了Go語言的struct匿名內部成員,天然就擁有Get, List等方法。
kubernetes/pkg/apiserver/api_installer.go
最后在這里把PodStorage轉換成了Getter對象,并最終注冊到ApiGroup
里面去。
感謝你能夠認真閱讀完這篇文章,希望小編分享的“kubernetes代碼閱讀apiserver的示例分析”這篇文章對大家有幫助,同時也希望大家多多支持億速云,關注億速云行業資訊頻道,更多相關知識等著你來學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。