kubernetes中apiserver的設計無疑是複雜的,其自身內部就包含了三種角色的api服務,今天咱們一塊兒來臆測下其內部的設計,搞明白aggregator、apiserver、apiExtensionsServer(crd server)的設計精要web
apiserver仍是蠻複雜的,今天咱們只討論其kube-aggregator/apiserver/apiextensions三者架構上的設計,而不關注諸如請求認證、准入控制、權限等等後端
一個最基礎的Rest服務一般會包括一個resource資源和一組HTTP請求的方法, 在kubernetes中被稱爲一個REST,其內部還內嵌了一個Store(能夠理解爲繼承),其提供了針對某個具體資源的全部操做的集合,也就是咱們常說的最終執行CRUD的具體操做的實現api
咱們有了Rest就能夠提供各類k8s中資源的管理,可是若是我要進行擴展呢,若是要支持一些外部的資源k8s中不存在, 最簡單的方式確定就是在外部獨立一個服務了,由這個服務本身管理數據存儲、變動、控制等等邏輯微信
當經過外部服務來進行集羣資源擴展的時候,針對這類資源咱們如何集成到當前的apiserver中呢?爲此k8s中設計了APIAggregator組件(其實APIAggreator組件還包括代理後端服務等功能),來實現外部服務的集成,這樣開發人員不用修改k8s代碼,也能夠來自定義服務信息架構
一個基礎的業務服務一般包含數據模型、控制邏輯、持久化存儲、基礎功能(認證、監控、日誌等等)等等,爲了要建立一個服務,咱們一般須要以下操做(不包含設計階段):1)選擇合適的框架(完成基礎功能) 2)定義數據模型 3)選擇數據存儲 4)編寫業務控制邏輯, 這裏面除了業務控制邏輯,其他部分在大多數狀況下可能都是通用,好比框架、數據存儲這些,那能不能簡化下?來看大招CRD框架
CRD中文被稱爲自定義資源類型,其核心在k8s中提供數據模型定義、數據存儲、基礎功能,這樣若是咱們要擴展服務就只須要編寫一個業務邏輯控制器便可, 咱們思考下其場景ide
一般web請求的處理流程都是反序列化、驗證字段、業務邏輯處理、數據存儲,而在k8s中業務控制邏輯大多數由controller來進行,那爲了支持CRD剩餘工做確定也是在k8s中完成的源碼分析
在咱們完成定義模型以後,k8s的crd模塊須要進行對應資源REST的構建、驗證、轉換、存儲等操做這些無疑都是耗費資源的,並且在apiserver這種數據總線上,由此能夠發行CRD並不支持大規模的數據存儲 學習
CRDServer主要就是負責CRD資源的管理,其會監聽CRD資源的變動,而且爲其建立對應的REST接口,完成對應的認證、轉換、驗證、存儲等機制ui
ServerChan從設計上更相似一種責任鏈的模式,簡單來講若是我處理不了該請求,我就交給下我的處理,這種操做在k8s中被稱爲delegate(委託),接下來咱們開始瞭解其關鍵實現
到目前咱們已經有了三個server, 其中APIAggregator負責外部服務的集成和內部請求的轉發,apiserver服務k8s彙總內部資源的控制,CRDServer則負責用戶自定義資源的處理,而後咱們就只須要將三者串聯起來,就是咱們最終的apiserver
當APIAggregator接收到請求以後,若是發現對應的是一個service的請求,則會直接轉發到對應的服務上不然則委託給apiserver進行處理,apiserver中根據當前URL來選擇對應的REST接口處理,若是未能找到對應的處理,則會交由CRD server處理, CRD server檢測是否已經註冊對應的CRD資源,若是註冊就處理
APIAggreagtor中會經過informer 監聽後端Service的變化,若是發現有新的服務,就會建立對應的代理轉發,從而實現對應的服務註冊
當在集羣中建立了對應的CRD資源的時候,會經過內部的controller來感知對應的CRD資源信息,而後爲其建立對應的REST處理接口,這樣後續接收到對應的資源就能夠進行處理了
讀k8s代碼老是這樣迷迷糊糊中又能靈光一現直接柳暗花明,流程真的重要嘛,貌似也不是很重要,瞭解其上層設計,而後直接關注感興趣點便可,除非和我同樣就是感興趣,那就只能死磕了,我該去吃飯了,祝你好運
kubernetes學習筆記地址: https://www.yuque.com/baxiaoshi/tyado3 > 微信號:baxiaoshi2020 > 關注公告號閱讀更多源碼分析文章 > 更多文章關注 www.sreguide.com > 本文由博客一文多發平臺 OpenWrite 發佈