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

林冠宇（Rico Lin）， OpenStack Heat 元件 PTL（project team leader），開源雲中文社群特邀技術專家。6月28日受邀在北京開源雲端計算核心技術培訓專場做 “在 OpenStack 上建立你的應用程式架構”主題培訓。

如果你想使用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_config:

type: OS::Heat::StructuredConfig

properties:

group: kubelet

options:

images_timeout: 600

containers_timeout: 120

poll_period: 10

config:

version: v1beta2

containers:

...

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

調優5 :調優映象

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

優化方向有2：

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

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

(https://github.com/openstack/tripleo-common/blob/master/heat_docker_agent/Dockerfile)

總結

通過將上面5項調優（調優1:開啟convergence模式；調優2:調整`num_engine_workers`；調優3:開啟快取記憶體；調優4:允許OpenStack直接操作Kubernetes；調優5:調優映象）應用到你的K8S環境中，在執行佈署或擴充套件（或縮編）時，會產生明顯的效能改善。

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

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

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