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

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

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

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

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

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

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

　　以現(xiàn)今的云應(yīng)用，相信多數(shù)私有云會選擇以O(shè)penStack作為基礎(chǔ)框架，公有云也有不少案例使用OpenStack。而在選好的框架上承載相應(yīng)的應(yīng)用程序。

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

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

　　在這樣的整體架構(gòu)規(guī)劃下，可以深入討論以下幾大重點：網(wǎng)絡(luò)、運算、儲存與編排。想必大家通過之前網(wǎng)絡(luò)調(diào)優(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)境的基礎(chǔ)架構(gòu)有相當(dāng)?shù)牧私�，甚至已�?jīng)著手進行優(yōu)化。

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

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

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

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

　　下圖為比較建立100個簡單的資源，200個簡單的資源，與100個復(fù)雜資源時在Convergence模式或是非Convergence模式下的效能。可以觀察到，越復(fù)雜的資源越需要更多的時間來完成，越容易在Convergence模式下獲得大幅的改善。

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

　　談到這里，應(yīng)該有不少開發(fā)者對Convergence相當(dāng)陌生。 Convergence比起舊架構(gòu)在服務(wù)之間的差異只有新增了一個worker服務(wù)。但是實際上程序流程完全不同。如果我們?nèi)缦轮噶罱�立一個Kubernetes 群集。

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

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

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

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

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

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

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

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

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

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

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

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

　　至于為什么在此特別提及此設(shè)定，因為當(dāng)你要布署或是擴展你的Kubernetes集群時，在資源編排上都會是以資源群組為單位，比如說要再擴展出新的50臺Kubernetes minion節(jié)點。

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

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

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

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

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

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

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

　　當(dāng)中`configure_master_deployment`就是可以將單一布署腳本應(yīng)用于多個節(jié)點上的`OS::Heat::SoftwareDeploymentGroup`資源。

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

　　任何執(zhí)行結(jié)果或是錯誤狀況。都會通過消息回傳給Heat服務(wù)。另外有關(guān)于詳細(xì)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ù)都轉(zhuǎn)進容器內(nèi)執(zhí)行，然而目前許多大型環(huán)境遺忘了應(yīng)該建制Kubernetes的鏡像優(yōu)化。目前有幾家知名的歐洲大型研究機構(gòu)，就在對他們OpenStack云上的Kubernetes，進行這項優(yōu)化。

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

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

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

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

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

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

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

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

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

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