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

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

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

1

今天交流的話題主要會分爲三部分
一、爲何須要應用編排
二、kubernetes社區應用編排發展示狀
三、騰訊雲容器服務應用編排的實踐這幾個方面作介紹。

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

爲何須要應用編排：

「微服務」架構你們都知道，他具備開發效率高，擴展性好，穩定性好，維護簡單等優勢。愈來愈多的軟件，開始採用微服務的方式進行開發和部署。

2

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

3

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

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

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

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

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

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

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文件支持的語法包括，基本語法:一、 {{.Value}}的方式來表示一個變量，支持基本的變量替換。二、支持{{.Release.Service}}等默認的內置變量。高級語法：一、支持分支語句二、支持管道和函數處理等

8

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

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

9

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

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

10

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

應用模板：包括多個服務的定義加一個默認配置，經過應用模板+配置項的組合，方便用戶部署相同應用的不一樣環境。

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

11
如上圖所示使用應用模板對複雜系統中各個服務進行描述，經過配置項區分不一樣環境中差別化信息，從而實如今多環境中快速部署，快速回滾，環境快速複製。經過應用實例對服務進行分組，簡化服務的管理。

12

配置管理的主要做用包括
一、經過提取出多個環境中不一樣的部分，支持同一套系統在多個環境中部署
二、提取出服務中常常變動的部分，實現服務的靈活變動。

例如通常會將服務實例數量，實例的鏡像tag提取成爲一個配置項。修改這些參數時，修改對應的配置項就能夠實現變動。而且經過配置文件的版本管理，能夠很好的對變動進行追溯和回滾。

經過配置項，能夠隱含的實現多個服務直接依賴關係的管理。例如：服務A須要訪問服務B的，通常狀況下依賴於服務B的名稱。

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

13

配置管理的實現，咱們支持三種：
一、Helm的模板文件支持變量渲染
二、kubernetes的Configmap中環境變量方式
3 kubernetes的Configmap經過Volume方式進行數據填充

爲了簡化配置管理自己的複雜度，咱們將三種配置管理都統一成了「Key/Value」形式。

在用戶指定應用相對應的配置文件後，使用同一份配置文件，咱們會先對應用的Template文件進行渲染，而後會進行環境變量替換。

最後會在k8s中建立對應的configmap資源，支持用戶經過Volume的形式掛載configmap中的Key。

這樣作的好處是，沒有多種形式的配置項形式，應用也不須要指定多個配置文件。應用在不一樣環境中的複製，只需關聯對應的配置文件就能夠了，不須要考慮配置文件的組合。

14

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

後面咱們還將實現經過配置項更新，自動觸發服務的更新。能夠結合CI/CD流程，經過CI編譯生成新的鏡像，修改配置項中鏡像tag的參數，自動觸發對應服務的更新。

15

應用模板用於描述一個或多個服務的定義，服務的定義支持原生的Yaml語法，但能夠經過GoTemplate的方式定義對應的變量。

應用模板的主要做用包括：
實現應用的快速克隆。因爲應用的相關信息已經經過對應的template文件進行了描述，複製應用的過程只須要針對性的修改應用的配置，其餘結構信息不須要進行改變。

應用的多環境部署。在多個環境中，實現應用的部署，也不須要關係每一個服務具體的部署信息，只須要在不一樣環境下修改環境對應的配置，便可以經過應用模板實如今新環境應用的快速部署。
三、更高階的功能，經過應用市場能夠下載通用的模板，快速的部署應用。例如：在Helm(Charts)的應用市場https://kubeapps.com/，已經打包好了100+應用的模板文件。直接下載對應的應用模板就能夠實現應用的部署。

16

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

服務使用一個template文件進行描述，服務的template中的變量，經過一個統一的配置文件進行管理。

17

應用能夠理解爲多個服務的組合，多個服務會統一進行展現，服務支持按照應用進行搜索。多個服務的配置項，統一的經過同一個配置進行管理。經過服務組的方式，管理多個服務。能夠簡化多個服務管理的複雜度。

18
19

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

應用中的服務支持單獨編輯，部署和更新。同時服務支持差別化比較，方便用戶查看兩次修訂之間的差別。

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

20

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

啓動項管理，這個對應在啓動上有前後順序依賴的應用來講，是一個強訴求。目前docker compose 支持經過depends_on標籤實現多個組件間啓動順序的管理。

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

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

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

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

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

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的方式，但有其餘的存儲方式也能夠。