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、支持管道和函數處理等
8
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)的應用市場https://kubeapps.com/，已經打包好了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的方式，但有其他的存儲方式也可以。
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、支持管道和函數處理等
8
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)的應用市場https://kubeapps.com/，已經打包好了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的方式，但有其他的存儲方式也可以。
8月最新基於kubernetes的應用編排實踐