kubernetes 已經(jīng)成為容器時代的分布式操作系統(tǒng)內(nèi)核粉怕，目前也是所有公有云提供商的標(biāo)配，在國內(nèi)贫贝，阿里云、騰訊云崇堵、華為云這樣的公有云大廠商都支持一鍵部署 kubernetes 集群客燕，而 kubernetes 集群自動化管理則是迫切需要解決的問題。對于大部分不熟悉 kubernetes 而要上云的小白用戶就強烈需要一個被托管及能自動化運維的集群也搓，他們平時只是進行業(yè)務(wù)的部署與變更，只需要對 kubernetes 中部分概念了解即可幔摸。同樣在私有云場景下颤练，筆者所待過的幾個大小公司一般都會維護多套集群，集群的運維工作就是一個很大的挑戰(zhàn)昔案，反觀各大廠同樣要有效可靠的管理大規(guī)模集群，kube-on-kube-operator 是一個很好的解決方案庆亡。
所謂 kube-on-kube-operator捞稿，就是將 kubernetes 運行在 kubernetes 上，用 kubernetes 托管 kubernetes 方式來自動化管理集群娱局。和所有 operator 的功能類似，系統(tǒng)會定時檢測集群當(dāng)前狀態(tài)任斋，判斷是否與目標(biāo)狀態(tài)一致耻涛，出現(xiàn)不一致時瘟檩，operator 會發(fā)起一系列操作澈蟆，驅(qū)動集群達到目標(biāo)狀態(tài)。今年 kubeCon 上趴俘，雅虎日本也分享了其管理大規(guī)模 kubernetes 集群的方法，4000 節(jié)點構(gòu)建了 400 個 kubernetes 集群带膀，同樣采用的是 kube-on-kube-operator 架構(gòu)橙垢，以 kubernetes as a service 的形式使用。
kubernetes-operator 設(shè)計參考
記得 kube-on-kube-operator 的概念最初是在去年的 kubeCon China 上螞蟻金服提出來的柜某，先看看螞蟻金服以及騰訊云 kube-on-kube-operator 的設(shè)計思路喂击，其實騰訊云的架構(gòu)和螞蟻金服的是類似的。以下是螞蟻金服的架構(gòu)設(shè)計圖：
首先部署一套 kubernetes 元集群翰绊，通過元集群部署業(yè)務(wù)集群，業(yè)務(wù)集群的 master 組件都分布在一臺宿主上谐檀，該宿主以 node 節(jié)點的方式掛載在元集群中裁奇。在私有云場景下，這樣的部署方式有一個很明顯的問題就是元集群節(jié)點跨機房刽肠，雖然業(yè)務(wù)集群的 master 與 node 都是在同一個機房，但是元集群中的 node 節(jié)點大部分是分布在不同的機房惫撰，有些公司在不同機房之間會有網(wǎng)絡(luò)上的限制躺涝，有可能網(wǎng)絡(luò)不通或者只能使用專線連接。在公有云場景下莉撇，元集群自己有一套獨立的 vpc 網(wǎng)絡(luò)惶傻，它要怎么和用戶的 vpc 結(jié)點進行通信呢？騰訊云的做法是利用 vpc 提供的彈性網(wǎng)卡能力银室，將這個彈性網(wǎng)卡直接綁定到運行 apiserver 的 pod 中，運行 master 的這個pod 既加入了元集群的 vpc辜荠，又加入了用戶的 vpc抓狭，也就是一個 pod 同時在兩個網(wǎng)絡(luò)中，這樣就可以很好的去實現(xiàn)和用戶 node 相關(guān)的互通否过。這種方式都是通過 kubernetes API 去管理 master 組件的，master 組件的升級以及故障自愈都可以通過 kubernetes 提供的方式實現(xiàn)药磺。
kubernetes-operator 設(shè)計
kubernetes-operator 項目地址：https://github.com/gosoon/kubernetes-operator
目前該項目的主要目標(biāo)是實現(xiàn)以下三種場景中的集群管理：
- kube-on-kube
- kube-to-kube
- kube-to-cloud-kube
kubernetes-operator 不僅是要實現(xiàn) kube-on-kube 架構(gòu)煤伟，還有 kube-to-kube，kube-to-cloud-kube围辙，kube-to-kube 即 kubernetes 集群管理業(yè)務(wù)獨立的 kubernetes 集群放案，兩個集群相互獨立。kube-to-cloud-kube 即 kubernetes 集群管理多云環(huán)境上的 kubernetes 集群卿叽。
上面項目的架構(gòu)圖，紅色的線段表示對集群生命周期管理的一個操作贩虾，涉及集群的創(chuàng)建沥阱、刪除、擴縮容、升級等舰始，藍色線段是對集群應(yīng)用的操作咽袜，集群中應(yīng)用的創(chuàng)建、刪除谜嫉、發(fā)布更新等凹联，kubernetes-proxy 是一個 API 代理沐兰，所有涉及 API 的調(diào)用都要通過 kubernetes-proxy蔽挠。左邊部署有 kubernetes-operator 的是元集群澳淑，kubernetes-operator 使用 etcd 僅存儲部分配置信息，其管理業(yè)務(wù)集群的生命周期偶惠，支持三種集群的創(chuàng)建方式，第一種方式就是可以創(chuàng)建出類似螞蟻金服這種直接將業(yè)務(wù)集群 master 運行在元集群绑改，node 節(jié)點在業(yè)務(wù)集群兄一，第二種是以二進制方式創(chuàng)建業(yè)務(wù)集群，其中業(yè)務(wù)集群的 master 以及 node 都是在業(yè)務(wù)集群所在的機房出革，第三種方式就是在各種公有云廠商創(chuàng)建集群，以一種統(tǒng)一的方式管理公有云上的集群耳璧，也可以稱作融合云展箱。
項目結(jié)構(gòu)
總體來說，項目暫時分為三大塊：
- kubernetes proxy：支持 API 透傳混驰、訪問控制等功能皂贩；
- 控制器：也就是 kubernetes-operator昆汹，管理業(yè)務(wù)集群的生命周期；
- 集群部署模塊：用來部署業(yè)務(wù)集群辈末，目前主要在開發(fā)第二種方式使用二進制部署業(yè)務(wù)集群败潦；
- kubernetes 應(yīng)用安裝模塊：在新建完成的集群中部署監(jiān)控准脂、日志采集、鏡像倉庫狸膏、helm 等組件；
控制器
控制器也就是 Operator + CR贤旷，目前開發(fā) operator 的方式已知的有三種：
- 自定義 controller 的方式：kube-controller-manager 中所有的 controller 就是以自定義 controller 的方式砾脑，這種方式是最原生的方式，需要開發(fā)者了解 kubernetes 中的代碼生成盅藻，informer 的使用等畅铭。
- operator-sdk 的方式：一個開發(fā) Operator 的框架，對于一些不熟悉 kubernetes 的可以使用 operator-sdk 的方式硕噩，這種方式讓開發(fā)者更注重業(yè)務(wù)的實現(xiàn)，但是不夠靈活辉懒。
- kubebuilder 的方式：kubebuilder 是開發(fā) controller manager 的框架谍失，controller manager 會管理一個或者多個 operator。
kubebuilder, operator-sdk 都是對controller-runtime做了封裝, controller runtime又是對client-go shardInfromer 做的封裝仿便，本質(zhì)上其實都一樣的。kubernetes-operator 使用的是自定義 controller 的方式嗽仪，如果想要更深入的學(xué)習(xí) kubernetes，非自定義 controller 方式莫屬了沽翔，kube-controller-manager 組件中的各種 controller 都是使用這種方式開發(fā)的窿凤，完全可以按照官方這種套路來開發(fā)。在 kubernetes 中雳殊，目前有兩種方式可以定義一個新對象，一是 CustomResourceDefinition（CRD）座咆、二是 Aggregation ApiServer（AA）仓洼，其中 CRD 是相對簡單也是目前應(yīng)用比較廣的方法。kubernetes-operator 采用 CRD 的方式色建。
集群部署
其實項目中最難的是集群部署這一部分箕戳，部署集群目前有兩種方式，二進制部署和容器化部署漂羊，但是都有一些開源工具的支持。手動部署一個二進制集群需要熟悉 docker 的部署走越、etcd 的部署旨指、角色證書的創(chuàng)建、RBAC 授權(quán)谆构、網(wǎng)絡(luò)配置、yaml 文件編寫呵晨、kubernetes 集群運維等等，總之手動部署一個二進制集群是非常麻煩的摸屠，但是要真正會用 kubernetes 是逃不了部署這一步的。第二種方式就是以容器化的方式部署檩咱，這種部署方式相對來說比較簡單胯舷，有現(xiàn)成的工具直接傻瓜式操作就能部署成功。但是我目前選擇的是使用二進制的部署方式桑嘶，由于自己運維過二進制的 kubernetes 集群不翩，對于私有云場景一般都是直接將集群部署在物理機上兵扬，作為生產(chǎn)環(huán)境口蝠，自己認(rèn)為容器化的方式部署還不是非常成熟的妙蔗，目前工作過的大小公司中疆瑰，生產(chǎn)環(huán)境暫時沒有以容器化的方式運行集群搭伤。所以 kubernetes-operator 中目前主要支持的就是使用二進制部署集群锨苏。
目前比較成熟的用于生產(chǎn)環(huán)境的 kubernetes 集群部署工具有：kubeadm梳杏、kubespary淹接、kops、rancher塑悼、kubeasz 等。kubeadm霞势、kubespary、kops 都是官方開源的產(chǎn)品愕贡，kubeadm 使用容器化的方式部署颂鸿，需要手動執(zhí)行一些部署命令，暫時無法完全自動化部署嘴纺。kubespary 是對 kubeadm 的一層封裝，使用 ansible + kubeadm 的方式自動化進行部署尖坤，據(jù)說阿里云就是使用 kubespary 部署集群的闲擦。在公有云的環(huán)境(GCP、AWS)通常使用 kops 部署起來更方便些墅冷。kubeasz 是使用 ansible 自動化的方式部署二進制集群，目前也已經(jīng)比較成熟了驰唬。
應(yīng)用安裝
- 監(jiān)控：當(dāng)然是使用 promethus腔彰；
- 日志采集：使用 filebeat 或者基于 filebeat 封裝的一些組件如 logpilot，其他的還有 logkit 等都可以嘗試使用搓逾；
- 鏡像倉庫：當(dāng)然是使用 harbor杯拐；
- HPA：組件以及應(yīng)用的自動擴縮容；
應(yīng)用安裝使用 helm 的方式進行安裝寇损。
集群升級
若以二進制部署最好是替換二進制文件的方式進行升級裳食，若使用容器化部署，master 部署在元集群中可以使用 kubernetes 的滾動方式升級否則要以修改 manifest 文件的方式诲祸。
集群升級包括配置和版本的升級而昨，集群部署完成后找田，master 的配置改動不會很頻繁，由于要進行性能上的優(yōu)化以及業(yè)務(wù)的支持务嫡，對于 node 組件上的配置升級還是比較多的漆改。對于集群的版本升級，升級的難度系數(shù)隨著版本的跨度增大而增大挫剑，若按照官方的升級流程樊破，一般不會出現(xiàn)異常。升級操作一般都是先升 master 再升 node哲戚，在工作中經(jīng)歷的幾次版本升級中，每次升級完 master 后理論上不會再回退了档押，除非升級過程中有問題祈纯，否則升級完成后已經(jīng)很難回退了叼耙，master 升級完成后 APIServer 的一些 API 還有 pod 的字段都有可能改變，master 版本回退后一些已存在的應(yīng)用可能會異常筛婉，或者還可以參考 openshift 的藍綠升級方式簇爆。二進制部署的集群盡量以替換二進制文件的方式進行升級，對于容器化部署的集群爽撒，可以直接使用 kubernetes 的滾動方式升級或者是修改 manifest 文件的方式入蛆。
目前螞蟻金服 kube-on-kube-operator 架構(gòu)中在業(yè)務(wù)集群中會部署一個 node-operator，node-operator 會記錄 master 組件的鏡像硕勿、默認(rèn)啟動參數(shù)等信息哨毁，其作用就是節(jié)點配置管理、集群組件升級以及節(jié)點故障自愈源武，未來在項目中也會實現(xiàn)基于此的方式扼褪。
后期計劃
- 支持部署 k3s想幻、kubeedge：5G 時代，邊緣計算將是非郴敖剑火的，目前各大廠商也都在此布局幔崖，所以支持部署 k3s食店、kubeedge 這些專門支持邊緣計算的產(chǎn)品還是非常有必要的。
- 支持使用 kops 部署
- 支持部署多版本 k8s
- node-operator 開發(fā)赏寇，支持集群的配置管理叛买、自動化升級、故障自愈等功能
- 用戶及權(quán)限管理：操作集群用戶的權(quán)限和 kubernetes 中 RBAC 規(guī)則綁定
- Kubernetes-operator 一些功能的擴展和完善
參考：
