OpenStack 與 Kubernetes 融合架構下的優(yōu)化實(shí)踐

　　如果你想使用Kubernetes來(lái)構建你的應用程序環(huán)境，通過(guò)OpenStack來(lái)部署Kubernetes其架構是一種推薦的方式，本文將與大家分享Kubernetes在OpenStack上的編排方式與其優(yōu)化方法。

　　以下介紹5種針對Kubernetes的調優(yōu)方式，希望對大家有所幫助。

　　接下來(lái)讓我們從架構分析開(kāi)始，了解為什么需要這樣的架構存在，解決什么樣的問(wèn)題。接著(zhù)了解優(yōu)化的目的，我們深入探討幾個(gè)優(yōu)化方式與選項。結合部分實(shí)際案例或測試來(lái)優(yōu)化后的改善。最后探討后續發(fā)展與計劃。

　　容器的存在是為了解決無(wú)狀態(tài)（stateless）的服務(wù)占用系統資源的問(wèn)題。針對網(wǎng)絡(luò )應用程序來(lái)說(shuō)，即能減少虛擬化所帶來(lái)的消耗，成為效能優(yōu)化的一大亮點(diǎn)。在容器之上應用程序仍需與多個(gè)容器共存，甚至互相通信。

　　因此Kubernetes、Mesos、Swarm等容器編排服務(wù)就成為新世代架構的寵兒。 Kubernetes概念架構如下圖所示：

　　在Kubernetes架構下，提供docker容器網(wǎng)絡(luò )與周期管理。通過(guò)COE（Container Orchestration Engine）管理的容器群，不但享受便利，也擁有快速編排應用程序架構的優(yōu)勢。

　　但通過(guò)下圖（Cloud Native Landscape by Cloud Native Computing Foundation）可以認識到：Kubernetes還需要建立在一個(gè)可以良好地承載如此多樣性服務(wù)的基處建設（即IaaS），而在圖中最底下的基礎架構（Infrastructure）你會(huì )選擇那個(gè)平臺？

　　以現今的云應用，相信多數私有云會(huì )選擇以OpenStack作為基礎框架，公有云也有不少案例使用OpenStack。而在選好的框架上承載相應的應用程序。

　　通過(guò)上面一起思考出的組合，若各位已經(jīng)熟悉Magnum開(kāi)源項目或是企業(yè)Kubernetes產(chǎn)品（例如 ESContainer），其提供你在OpenStack架構上想要的Kubernetes框架的方式。

　　另外此架構也還有幾個(gè)優(yōu)點(diǎn)供大家參考：通過(guò)此架構可以達成Kubernetes全自動(dòng)化管理，通過(guò)此架構可以提供完整多租戶(hù)框架。

　　在這樣的整體架構規劃下，可以深入討論以下幾大重點(diǎn)：網(wǎng)絡(luò )、運算、儲存與編排。想必大家通過(guò)之前網(wǎng)絡(luò )調優(yōu)的干貨（http://www.easystack.cn/en/technical_share/748/ ）與NUMA相關(guān)處理器技術(shù)干貨（http://www.easystack.cn/en/ technical_share/700/ ）已經(jīng)對自己的環(huán)境的基礎架構有相當的了解，甚至已經(jīng)著(zhù)手進(jìn)行優(yōu)化。

　　接下來(lái)正是文章想要突顯的重點(diǎn)，如何從編排下手讓OpenStack上的Kubernetes加速？如何調優(yōu)？當你已經(jīng)千方百計優(yōu)化了你的應用程序時(shí)，還有那些方式可以讓效能更上一層樓？

　　編排項目對于在OpenStack構建任何應用程序都具有重要角色，在下圖（Magnum的架構圖）中可以看見(jiàn)Heat （編排服務(wù)）對于整體流程的重要性。通過(guò)Heat腳本可以布署集群與安裝任何應用程序于集群上。因此選擇調優(yōu)Heat絕對是值得參考的選項。

　　若你的OpenStack環(huán)境已經(jīng)到了Mitaka或是以上版本。則建議你將convergence模式打開(kāi)（若版本為Newton以上版本，預設已經(jīng)是開(kāi)啟）。打開(kāi)方式為在`/etc/heat/heat.conf`檔案下加入`convergence_engine = True`的選項。

　　開(kāi)啟后對于操作不會(huì )有任何改變，使用者仍可以用原先的操作模式與腳本建立編排資源。原先已經(jīng)建立的編排資源則會(huì )維持在非Convergence模式下繼續運行。而新建立的編排資源則會(huì )以Convergence模式維運。

　　下圖為比較建立100個(gè)簡(jiǎn)單的資源，200個(gè)簡(jiǎn)單的資源，與100個(gè)復雜資源時(shí)在Convergence模式或是非Convergence模式下的效能。可以觀(guān)察到，越復雜的資源越需要更多的時(shí)間來(lái)完成，越容易在Convergence模式下獲得大幅的改善。

　　尤其是針對像是Kubernetes等需要建立多臺Nova Instance （虛擬機或裸機）的狀況下，通過(guò)模式轉換而獲得的效率改善理應更顯著(zhù)（Kubernetes一般架構屬于復雜度較高的資源，因此可以參考圖中復雜度高的狀況比較表）。

　　談到這里，應該有不少開(kāi)發(fā)者對Convergence相當陌生。 Convergence比起舊架構在服務(wù)之間的差異只有新增了一個(gè)worker服務(wù)。但是實(shí)際上程序流程完全不同。如果我們如下指令建立一個(gè)Kubernetes 群集。

　　如果是舊有的架構指令會(huì )被轉為API call,再通過(guò)RPC交由其中的一個(gè)后端Engine服務(wù)由頭到尾處理整個(gè)Kubernetes資源建構。

　　但如下圖在Convergence模式下，Kubernetes腳本抵達后端服務(wù)（Engine）時(shí)，會(huì )依照資源立刻被分成單一工作，交付給其他后端服務(wù)并行執行。

　　也就是說(shuō)，若后端服務(wù)數量允許，所有的Kubernetes master與minion都可以并行運行在獨立的后端服務(wù)，并且只需要你花費部署一臺節點(diǎn)的時(shí)間，就可以將整個(gè)集群都建置完畢。

　　過(guò)程中Heat服務(wù)會(huì )在數據庫中建立一張叫做Syncpoint的表，用來(lái)確認與取得操作的權限。并且存入資源相依性的連結數據以保證有資源創(chuàng )建流程（像是確保Cinder Volume掛載操作，必須在Nova將Kubernetes節點(diǎn)與Cinder Volume創(chuàng )建出來(lái)后才能執行）。

　　Engine worker數量調整，指的就是我們在調優(yōu)1時(shí)提及的后端服務(wù)數量。通過(guò)下圖架構可以看到，當API服務(wù)收到請求，并通過(guò)RPC往后方傳送時(shí)，是在多個(gè)Engine worker中，由搶先接收到者，作為處理該請求的后端。

　　而這個(gè)調優(yōu)設定可以用來(lái)決定每一個(gè)實(shí)體的Heat后端節點(diǎn)上要跑幾個(gè)后端服務(wù)程序。如若環(huán)境（在`/etc/heat/heat.conf`文件）尚未設定此參數，預設是按照CPU數量來(lái)調整單一節點(diǎn)上Heat的服務(wù)程序數量。

　　但是注意到，若你的電腦為HPC時(shí)建議將數量調高，因為你擁有較為強大的網(wǎng)絡(luò )、運算、與儲存資源，可以嘗試由1:1.5（cpu:num_engine_workers）開(kāi)始測試效能，在往上調整，直到你的Kubernetes集群的布署效能達到頂峰。

　　相對地，若你的CPU數量過(guò)多，其他部分的資源并未規劃為高效能狀況（可能發(fā)生在用來(lái)提供運算的節點(diǎn)上），建議嘗試1.25:1（cpu:num_engine_workers）開(kāi)始測試效能，并往下調整（num_engine_workers數量），直到你的環(huán)境取得更好的整體效能。

　　注意到單一節點(diǎn)上的編排服務(wù)程序數量，并不等于多節點(diǎn)上的整合。因此調整到適當的數量，也等同于提供其他程序（RPC、數據庫、其他服務(wù)程序）更多資源的使用空間。

　　尤其是像布署Kubernetes環(huán)境，將會(huì )同時(shí)調用Cinder管理儲存， Neutron管理網(wǎng)絡(luò )Nova管理虛機或裸機。因此資源分配更應該微調以獲取更好的整體效能。

　　多數的OpenStack服務(wù)都具有一定數量的緩存機制，若內存空間允許建議挑選部分服務(wù)（比如編排服務(wù)）開(kāi)啟緩存機制，開(kāi)啟方式為將緩存設定寫(xiě)入heat.conf內。

　　至于寫(xiě)入選項可參考網(wǎng)站：https://docs.openstack.org/developer/oslo.cache/opts.html 。若無(wú)特別想設定的參數，可以直接在[cache]下新增enabled=True即可。

　　至于為什么在此特別提及此設定，因為當你要布署或是擴展你的Kubernetes集群時(shí)，在資源編排上都會(huì )是以資源群組為單位，比如說(shuō)要再擴展出新的50臺Kubernetes minion節點(diǎn)。

　　在資源編排時(shí)，這50臺屬于同一Kubernetes叢集的minion節點(diǎn)將會(huì )被視為同一個(gè)資源群集，并在編排時(shí)一同處理。因此若能將高速緩存開(kāi)啟，在這案例上就可以直接節省49次等同于98%的部分操作。

　　目前在編排服務(wù)內，以下幾個(gè)主要環(huán)節已經(jīng)設有快取機制，包含Stack信息數據，Resource信息數據，Constraint數據（通過(guò)呼叫其他項目CLI以認證部分參數。例如當K8S master參數有Floating ip時(shí)，Constraint就會(huì )通過(guò)Neutron CLI找尋Floating ip數據作為參數認證依據）等。

　　在實(shí)際使用Kubernetes時(shí)，許多時(shí)候需要臨時(shí)或一次性變更多個(gè) Kubernetes集群，或是對單一個(gè)大型的Kubernetes集群進(jìn)行多次操作或復雜操作，其實(shí)也可以納入OpenStack管理范圍作一次性操作，進(jìn)而完成所有任務(wù)。

　　在編排服務(wù)中有能安裝與管理應用程序的能力，在提供鏡像時(shí)，只需要在里面多加入kubelet hook就可以了。后續只需通過(guò)更改編排腳本即可進(jìn)行操作。

　　對于不知道hook是什么的讀者，可以理解基本上它就是一個(gè)在os-collect-config協(xié)助將文件（例如yaml文件）轉入Kubernetes節點(diǎn)上之后，通過(guò)節點(diǎn)上kubelet指令執行操作。流程如下圖所示：

　　當你計劃開(kāi)發(fā)Kubernetes自動(dòng)化管理時(shí)，除了將kubelet hook加入鏡像內，也要注意到kubelet執行后，必須要能夠發(fā)送消息給Heat或Zaqar等等（看你在編排腳本撰寫(xiě)時(shí)的設定），因此請務(wù)必打開(kāi)部分防火墻設定（像是80或8080等等）允許消息發(fā)送。

　　Heat的自動(dòng)化軟件布署與設定，通過(guò)同一個(gè)用來(lái)設定K8S的腳本即可設定相關(guān)資源。如果你想要將軟件布署加入你的K8S腳本中，可以參考以下腳本片段。

　　當中`configure_master_deployment`就是可以將單一布署腳本應用于多個(gè)節點(diǎn)上的`OS::Heat::SoftwareDeploymentGroup`資源。

　　其工作會(huì )將`OS::Heat::SoftwareConfig`中設定的腳本與腳本形態(tài)（Ansible, script, Puppet, Kubelet, etc.）通過(guò)K8S節點(diǎn)（你的OS::Nova::Server資源）中的os -collect-config將腳本信息拉進(jìn)節點(diǎn)中（此為隨時(shí)監聽(tīng)動(dòng)作，可以調整監聽(tīng)區間，預設為30秒），再通過(guò)Kubelet hook呼叫Kubelet指令，執行腳本。

　　任何執行結果或是錯誤狀況。都會(huì )通過(guò)消息回傳給Heat服務(wù)。另外有關(guān)于詳細kubelet hook信息可以參考：https://github.com/openstack/heat-agents/tree/master/heat-config-kubelet 。

　　在編排腳本上加入：

　　即可以操作kubelet ，你也可以將cofig部分換成yaml文件輸入。至于在編排腳本上完整的使用方式，可以參考https://github.com/openstack/heat-templates/blob/master/hot/software-config/example-templates/example-kubelet-template.yaml

　　對于Kubernetes的優(yōu)勢之一即將服務(wù)都轉進(jìn)容器內執行，然而目前許多大型環(huán)境遺忘了應該建制Kubernetes的鏡像優(yōu)化。目前有幾家知名的歐洲大型研究機構，就在對他們OpenStack云上的Kubernetes，進(jìn)行這項優(yōu)化。

　　（https://github.com/openstack/tripleo-common/blob/master/heat_docker_agent/Dockerfile）

　　通過(guò)將上面5項調優(yōu)（調優(yōu)1:開(kāi)啟convergence模式；調優(yōu)2:調整`num_engine_workers`；調優(yōu)3:開(kāi)啟高速緩存；調優(yōu)4:允許OpenStack直接操作Kubernetes；調優(yōu)5:調優(yōu)鏡像）應用到你的K8S環(huán)境中，在執行布署或擴展（或縮編）時(shí)，會(huì )產(chǎn)生明顯的效能改善。

　　當K8S布署下去后，實(shí)體網(wǎng)絡(luò )調整變得非常困難。若你選擇運用OpenStack編排管理，在任何環(huán)境中改變節點(diǎn)信息，包含網(wǎng)絡(luò )，群集實(shí)體配置，儲存等等就會(huì )變成更為簡(jiǎn)單的操作。

　　你也可以通過(guò)專(zhuān)門(mén)負責資源管理的編排服務(wù)，強化資源布署效能。因為你絕對不可能將你的運營(yíng)中的容器化應用程序布署在只有一個(gè)單一節點(diǎn)的K8S，你更不希望因為任何人員操作時(shí)修改遺漏，導致整個(gè)群集停止服務(wù)。通過(guò)編排就變成是個(gè)較為符合自動(dòng)化目標的選項。

　　除了上面5項建議外，也鼓勵你將你的問(wèn)題、想法、解法、或是其他任何幫助發(fā)到社區上或是聯(lián)系我們，由社區作為源頭，我們有能力直接改變源頭以繼續強化Kubernetes與OpenStack的整合與優(yōu)化，我們努力將源頭技術(shù)優(yōu)化了，不久一定產(chǎn)生更多的優(yōu)化選項。最后受惠的，相信就是你正在運營(yíng)的環(huán)境。

　　林冠宇將受邀參加6月28日北京舉辦的2017中國開(kāi)源產(chǎn)業(yè)峰會(huì )，歡迎來(lái)到開(kāi)源云計算核心技術(shù)培訓專(zhuān)場(chǎng)與他親密互（mian）動(dòng)（ji）。

　　開(kāi)源云計算核心技術(shù)培訓專(zhuān)場(chǎng)由OpenStack基金會(huì )個(gè)人獨立董事、OpenStack Oslo 組件PTL郭長(cháng)波，OpenStack Heat 組件 PTL林冠宇，Ceph專(zhuān)家楊東升，EasyStack容器架構師王后明，GCC專(zhuān)家吳中如，OpenStack COA認證講師孫鉞6位全球技術(shù)專(zhuān)家團權威授課，培訓者還將獲得開(kāi)源云核心技術(shù)培訓結業(yè)證書(shū)。

　　作為培訓專(zhuān)場(chǎng)合作單位，開(kāi)源云中文社區再為粉絲發(fā)福利！報名頁(yè)面輸入優(yōu)惠碼“kyy628”即可獲得培訓專(zhuān)場(chǎng)優(yōu)惠報名，并贈送中國開(kāi)源產(chǎn)業(yè)峰會(huì )全天通票！

本文作者：林冠宇（Rico Lin）

　　林冠宇（Rico Lin）， OpenStack Heat 組件 PTL（project team leader），開(kāi)源云中文社區特邀技術(shù)專(zhuān)家。6月28日受邀在北京開(kāi)源云計算核心技術(shù)培訓專(zhuān)場(chǎng)做 “在 OpenStack 上建立你的應用程序架構”主題培訓。