如果你想使用Kubernetes來構建你的應用程序環境，通過OpenStack來部署Kubernetes其架構是一種推薦的方式，本文將與大家分享Kubernetes在OpenStack上的編排方式與其優化方法。

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

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

架構分析

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

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

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

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

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

通過上面一起思考出的組合，若各位已經熟悉Magnum開源項目或是企業Kubernetes產品(例如ESContainer)，其提供你在OpenStack架構上想要的Kubernetes框架的方式。

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

在這樣的整體架構規劃下，可以深入討論以下幾大重點：網絡、運算、儲存與編排。想必大家通過之前網絡調優的干貨(http://www.easystack.cn/en/technical_share/748/ )與NUMA相關處理器技術干貨(http://www.easystack.cn/en/ technical_share/700/ )已經對自己的環境的基礎架構有相當的了解，甚至已經著手進行優化。

接下來正是文章想要突顯的重點，如何從編排下手讓OpenStack上的Kubernetes加速?如何調優?當你已經千方百計優化了你的應用程序時，還有那些方式可以讓效能更上一層樓?

優化項目-調優編排

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

調優1:開啟convergence模式

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

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

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

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

什么是Convergence模式?

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

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

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

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

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

調優2:調整`num_engine_workers`

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

而這個調優設定可以用來決定每一個實體的Heat后端節點上要跑幾個后端服務程序。如若環境(在`/etc/heat/heat.conf`文件)尚未設定此參數，預設是按照CPU數量來調整單一節點上Heat的服務程序數量。

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

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

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

尤其是像布署Kubernetes環境，將會同時調用Cinder管理儲存， Neutron管理網絡Nova管理虛機或裸機。因此資源分配更應該微調以獲取更好的整體效能。

調優3:開啟高速緩存

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

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

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

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

目前在編排服務內，以下幾個主要環節已經設有快取機制，包含Stack信息數據，Resource信息數據，Constraint數據(通過呼叫其他項目CLI以認證部分參數。例如當K8S master參數有Floating ip時，Constraint就會通過Neutron CLI找尋Floating ip數據作為參數認證依據)等。

調優4:允許OpenStack直接操作Kubernetes

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

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

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

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

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

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

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

任何執行結果或是錯誤狀況。都會通過消息回傳給Heat服務。另外有關于詳細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 - kubele - template . yaml

調優5 :調優鏡像

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

優化方向有2：

1. 替代原先使用的鏡像，將更適合容器的小型鏡像作為整體建置選擇。

2.將上面提及編排時所需要的hooks加入映像檔。在此提供相關的 Dockerfile 作為參考。

總結

通過將上面5項調優(調優1:開啟convergence模式;調優2:調整`num_engine_workers`;調優3:開啟高速緩存;調優4:允許OpenStack直接操作Kubernetes;調優5:調優鏡像)應用到你的K8S環境中，在執行布署或擴展(或縮編)時，會產生明顯的效能改善。

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

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

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