8月最新基於kubernetes的應用編排實踐

  

本文根據8月22日騰訊雲研發工程師顏衛在DockOne社群線上直播分享整理。顏衛來自騰訊雲容器服務團隊，現在主要從事騰訊雲容器服務應用編排和微服務相關開發工作。

 

 

1

 

今天交流的話題主要會分為三部分

1、為什麼需要應用編排

2、kubernetes社群應用編排發展現狀

3、騰訊雲容器服務應用編排的實踐這幾個方面做介紹。

 

在騰訊雲容器服務應用編排的實踐部分，主要會涉及1、配置管理，2、應用模板管理，3、基於應用的服務組管理等內容。

 

為什麼需要應用編排：

 

 

“微服務”架構大家都知道，他具有開發效率高，擴充套件性好，穩定性好，維護簡單等優點。越來越多的軟體，開始採用微服務的方式進行開發和部署。

 

2

 

但任何事情都是有利有弊的，微服務架構有諸多好處。但微服務軟體的部署和運維對傳統的自動化運維體系提出了新的挑戰。

 

3

 

 

微服務部署帶來的挑戰：

服務數量急劇增多。比較常見的情況是，一個系統可能會被拆分成多達數十個微服務。如何管理一個系統中這麼多的微服務，對於運維部署系統是一種挑戰。

 

服務自身的配置問題。配置問題一直是服務管理中的難點。隨著服務數量的增多，對服務配置的管理也提出了更高的要求。如何去管理諸多服務，不同環境中存在差異部分以及在系統運維階段需要靈活變更的部分，這些都是服務配置管理中需要解決的問題。

 

服務依賴關係的管理。隨著服務數量增加，服務依賴關係也變得更加複雜。

 

4、環境資訊的管理，如何在多個環境中快速複製，如何在新的環境快速的部署一個複雜的系統。

 

由於服務數量的增多，同時需要多環境部署。採用原有對單個的服務進行部署和管理的方式，會出現一定的部署運維上的瓶頸。

 

而應用編排，透過應用模板，配置管理和服務組管理的方式。能夠很好的簡化微服務部署管理的複雜度，實現複雜系統在多個環境中的快速部署和高效管理。

 

4

 

 

開發，測試，預釋出，正式環境多環境的管理，進一步加劇了微服務管理的複雜度。

但這些都可以透過應用編排得到簡化，實現對系統的高效管理和快速部署(複製)。

 

 

kubernetes社群應用編排發展現狀：

 

Kubernetes原生的方案中，基於服務粒度對系統元件進行管理，支援服務註冊發現和路由管理。對於一個服務提供多種不同的資源描述型別，比較常用的有Deployment，Job, CronJob, Stateful, Daemonset。

 

每種型別都表示一種特定的部署方式。Kubernetes支援透過Yaml對服務的資源進行描述，也支援透過Label(標籤)的方式對服務之間的關聯關係進行管理。

 

5

 

隨著服務數量的增多，描述一個系統需要組合使用大量的Kubernetes資源，這個過程會相當複雜。於是社群就可以引入可以在更高維度對資源進行描述的管理工具，將多個服務組合成應用進行描述和編排。

 

 

kubernetes社群編排方案中，Helm基於Charts包的實現方案占主導地位。目前Helm已經成為kubernetes下應用編排的唯一子專案。推出Helm專案的Deis公司已經被微軟收購。說明大家比較看好這個專案的未來。

 

6

 

上圖是一個Chart包的示例，主要包括templates資料夾，values.yaml檔案，Chart.yaml檔案等部分。

 

Templates夾裡面有含應用的多個服務資源描述的模版。資源描述的模板指的是在kubernetes原始YAML的基礎上，將gotemplate的語法進行嵌入產生的一種描述文字形式。

 

Values.yaml 用來儲存配置項，不同的環境可能會有不同的配置項。在Helm處理時候，會首先使用gotemplate對templates中的檔案進行渲染，生成對應kubernetes的資原始檔。檔案渲染的過程，本質上是一個變數替換的過程，使用values.yaml中變數的值替換掉templates中預留的變數。

 

Chart.yaml是一個說明檔案，描述chart包的一些基本資訊。在某些chart包中還會有requirements.yaml，requirements.yaml用於描述依賴的其他的.

 

7

上圖是一個Charts包的示例，Helm Template檔案支援的語法包括，基本語法:1、 {{.Value}}的方式來表示一個變數，支援基本的變數替換。2、支援{{.Release.Service}}等預設的內建變數。高階語法：1、支援分支語句2、支援管道和函式處理等

 

 

kubernetes社群應用編排發展現狀中存在的問題：原生kubernetes僅支援透過服務和label進行管理，在服務數量較多的對服務的管理會比較困難。

 

Helm編排，更加側重於包管理；語法複雜，學習成本高；不支援按照服務更新和管理；差異化比較功能弱。

 

9

 

考慮到社群方案中的一些問題，騰訊雲容器服務參考社群Helm的實現形式，在容器服務中實現了完整的應用編排管理功能。

 

騰訊雲容器服務編排服務主要分為配置管理，應用模板管理，基於應用的服務組管理幾個主要部分。

 

10

 

配置管理：將應用中常變的值以變數的形式替代，配置項支援多版本，方便使用者進行更新和回滾應用。

 

應用模板：包括多個服務的定義加一個預設配置，透過應用模板+配置項的組合，方便使用者部署相同應用的不同環境。

 

應用：包括描述多個服務以及這些服務間的相互呼叫依賴關係 ，方便使用者管理多個服務。

 

11

如上圖所示使用應用模板對複雜系統中各個服務進行描述，透過配置項區分不同環境中差異化資訊，從而實現在多環境中快速部署，快速回滾，環境快速複製。透過應用例項對服務進行分組，簡化服務的管理。

 

 

12 

配置管理的主要作用包括

1、透過提取出多個環境中不同的部分，支援同一套系統在多個環境中部署

2、提取出服務中經常變更的部分，實現服務的靈活變更。

 

例如一般會將服務例項數量，例項的映象tag提取成為一個配置項。修改這些引數時，修改對應的配置項就可以實現變更。並且透過配置檔案的版本管理，可以很好的對變更進行追溯和回滾。

 

透過配置項，可以隱含的實現多個服務直接依賴關係的管理。例如：服務A需要訪問服務B的，一般情況下依賴於服務B的名稱。

 

這種情況下，將服務B的名稱提取成為一個配置項，而將配置項傳遞給服務A。這樣在不同環境中，服務B名稱的改變，服務A能自動感知，不需要單獨修改服務A的引數。

 

13

 

配置管理的實現，我們支援三種：

1、Helm的模板檔案支援變數渲染

2、kubernetes的Configmap中環境變數方式

3   kubernetes的Configmap透過Volume方式進行資料填充

 

為了簡化配置管理本身的複雜度，我們將三種配置管理都統一成了“Key/Value”形式。

 

在使用者指定應用相對應的配置檔案後，使用同一份配置檔案，我們會先對應用的Template檔案進行渲染，然後會進行環境變數替換。

 

最後會在k8s中建立對應的configmap資源，支援使用者透過Volume的形式掛載configmap中的Key。

 

這樣做的好處是，沒有多種形式的配置項形式，應用也不需要指定多個配置檔案。應用在不同環境中的複製，只需關聯對應的配置檔案就可以了，不需要考慮配置檔案的組合。

 

 

14

 

上圖是騰訊雲容器服務中配置管理操作的UI介面。配置管理支援多版本。應用的變更先修改配置，然後再透過配置觸發對應的服務更新，這樣對服務的更新實現規範化和可追溯。

 

後面我們還將實現透過配置項更新，自動觸發服務的更新。可以結合CI/CD流程，透過CI編譯生成新的映象，修改配置項中映象tag的引數，自動觸發對應服務的更新。

 

 

15

 

 

應用模板用於描述一個或多個服務的定義，服務的定義支援原生的Yaml語法，但可以透過GoTemplate的方式定義對應的變數。

 

應用模板的主要作用包括：

實現應用的快速克隆。由於應用的相關資訊已經透過對應的template檔案進行了描述，複製應用的過程只需要針對性的修改應用的配置，其他結構資訊不需要進行改變。

 

應用的多環境部署。在多個環境中，實現應用的部署，也不需要關係每個服務具體的部署資訊，只需要在不同環境下修改環境對應的配置，即可以透過應用模板實現在新環境應用的快速部署。

3、更高階的功能，透過應用市場可以下載通用的模板，快速的部署應用。例如：在Helm(Charts)的應用市場，已經打包好了100+應用的模板檔案。直接下載對應的應用模板就可以實現應用的部署。

 

16

 

上圖是騰訊雲容器服務中應用模板操作的UI介面。在應用模板中包含一個或者多個服務，一個服務對應於一個或者多個k8s的資源。但建議將一個deployment，stateful，deamonset這樣的資源，單獨作為一個服務進行管理。

 

服務使用一個template檔案進行描述，服務的template中的變數，透過一個統一的配置檔案進行管理。

 

17

 

應用可以理解為多個服務的組合，多個服務會統一進行展示，服務支援按照應用進行搜尋。多個服務的配置項，統一的透過同一個配置進行管理。透過服務組的方式，管理多個服務。可以簡化多個服務管理的複雜度。

 

18

19

 

前面兩張圖是騰訊雲容器服務中應用操作的UI介面。

 

應用中的服務支援單獨編輯，部署和更新。同時服務支援差異化比較，方便使用者檢視兩次修訂之間的差異。

 

在服務編輯時，自動提取出對應的變數，簡化配置的過程。支援服務回滾功能，支援服務回滾到上一個版本。

 

 

20

 

 

 

 

後期展望包括下面幾個部分：

 

啟動項管理，這個對應在啟動上有先後順序依賴的應用來說，是一個強訴求。目前docker compose 支援透過depends_on標籤實現多個元件間啟動順序的管理。

 

k8s目前還不支援指定啟動順序的，只能透過init_container，在例項容器啟動前對依賴的服務進行檢測，檢測到依賴的服務啟動後再啟動相應的容器。

 

2、應用下的日誌聚合，其實這裡應該還包括監控資料聚合。這個需求應該是系統基於服務組管理後的一個延展訴求，可以進一步強化服務組管理的能力。

 

3、呼叫關係展示，這個需求進一步在應用中突出服務與服務之間的依賴關係。更進一步對於呼叫鏈的追蹤也是一個強訴求。

 

公共模板與應用市場，這個是應用編排更高階的一個形式。透過應用市場可以快速的實現通用軟體的容器化部署。

 

接下來是互動問答的內容：

 

Q: 應用下的服務展示（未部署），是yaml資源沒有建立，還是副本數為0？

W: 未部署狀態是yaml資源還沒有建立

 

Q: 騰訊雲能否將Kubernetes應用編排過程做成部落格或影片的形式具體分享一下？

W: 我們接下來會將Kubernetes應用編排過程做成部落格分享出來，後面也會做出影片分享給大家

 

Q: 騰訊雲k8s網路用的是哪個元件呢？

W: 我們用的是全域性路由的方式，直接和我們騰訊雲容器服務的VPC網路打通。

 

Q: 使用configmap的時候，在配置修改完，需要重啟服務。騰訊雲容器服務配置檔案的變更如何觸發服務的重新啟動？

W: 透過觸發器的模式，可以在修改配置時觸發服務的更新。

 

Q: 之前講到可以結合CI/CD流程，透過CI編譯生成新的映象，修改配置項中映象tag的引數，自動觸發對應服務的更新。 這部分有詳細例子嗎？

W: 我們會將詳細示例放到騰訊雲容器服務幫助文件，在騰訊雲分享論壇--騰雲閣後面也可以看到。

 

Q: 應用配置如何實現版本控制的？

W: 對於每一個配置檔案，我們支援每一次修改預設建立一個新的版本，具有唯一的版本號

 

Q：應用裡的服務具體要怎麼更新呢？

W: 一般建議的更新方法是，先修改配置，會生成配置的一個新的版本，這樣這次修改在配置中是可以記錄的。然後更新應用匯總配置檔案的版本。觸發或者手動更新對應的服務。

   在修改配置檔案的版本後，我們會比較出哪些服務有變化，需要更新。

 

Q：應用裡的服務具體要怎麼更新呢？

W: 一般建議的更新方法是，先修改配置，會生成配置的一個新的版本，這樣這次修改在配置中是可以記錄的。然後更新應用匯總配置檔案的版本。觸發或者手動更新對應的服務。

   在修改配置檔案的版本後，我們會比較出哪些服務有變化，需要更新。

 

Q: 外部訪問叢集是透過Nginx轉發到pod還是透過k8s本來都dns服務來轉發，兩者優缺點是什麼？

W: 外部訪問，支援兩種方式。

   一種是透過服務的LB直接轉發到對應的Pod，但需要在建立服務時指定訪問方式為外部訪問(對應於k8s中的LoadBanace方式)。

   另外一種是透過ingress的方式。這種方式會有一個統一的LB作為入口。然後配置對應的後端域名轉發規則。可以將外部的訪問按照配置的規則轉發後端的服務。

 

Q: 上面提到 應用模版+應用配置=應用例項，這樣一個應用模版可以對應多個應用配置並生成多份應用例項嗎？例如生成200個例項，如果可以如何寫ci比較合適？

W:  這個是可以的，並且我們提供叢集隔離和名稱空間隔離。方便多個應用例項的建立。

 

Q: 應用的擴容縮容透過什麼監控，有什麼指標可以參考？

W: 自動擴容和縮容我們參考的是社群HPA的方案。指標目前考慮的是CPU和記憶體。

 

Q: 狀態化的容器怎麼做的？

W: 目前看到的有三種方式：一種是社群推薦的Stateful資源+headles service另外一種是：將服務的每一個例項拆分成獨立的headless service

   第三種是： 採用CoreOS提出的operater方式。儲存部分一般推薦使用PVC的方式，但有其他的儲存方式也可以。