如何在Kubernetes容器環(huán)境下部署Spinnaker ？

如果你關(guān)注Docker，想了解基于Kubernetes的CD實(shí)踐。那么，Spinnaker可能是多云平臺(tái)部署工具的最佳選擇。本文重點(diǎn)介紹spinnaker的概念、安裝與踩過的坑，spinnaker在kubernetes的持續(xù)部署，以及線上容器服務(wù)的選擇與多區(qū)容災(zāi)。
1、關(guān)于Spinnaker
Spinnaker 是什么？我們先來了解下它的概念。
Spinnaker 是 Netflix 的開源項(xiàng)目，是一個(gè)持續(xù)交付平臺(tái)，它定位于將產(chǎn)品快速且持續(xù)的部署到多種云平臺(tái)上。Spinnaker 有兩個(gè)核心的功能集群管理和部署管理。Spinnaker 通過將發(fā)布和各個(gè)云平臺(tái)解耦，來將部署流程流水線化，從而降低平臺(tái)遷移或多云品臺(tái)部署應(yīng)用的復(fù)雜度，它本身內(nèi)部支持 Google、AWS EC2、Microsoft Azure、Kubernetes和 OpenStack 等云平臺(tái)，并且它可以無縫集成其他持續(xù)集成（CI）流程，如 git、Jenkins、Travis CI、Docker registry、cron 調(diào)度器等。

spinnaker主要用于展示與管理你的云端資源。涉及Applications, clusters, and server groups等，并
通過Load balancers and firewalls 將服務(wù)展示給用戶。

官方結(jié)構(gòu)如下：

Application
定義了集群中一組的cluster的集合，也包括了firewalls 與 load balancers，存儲(chǔ)了服務(wù)所有的部署相關(guān)的的信息。

Server Group
定義了一些基礎(chǔ)的源比如(VM image, Docker image),以及一些基礎(chǔ)的配置信息，一旦部署后，在容器中對(duì)應(yīng)Kubernetes pods的集合。

Cluster

Server Groups的有關(guān)聯(lián)的集合。（Cluster中可以按照dev，prod的去創(chuàng)建不同的服務(wù)組），也可以理解為對(duì)于一個(gè)應(yīng)用存在多個(gè)分支的情況。

Load Balancer

他在實(shí)例之間做負(fù)載均衡流量。您還可以為負(fù)載均衡器啟用健康檢查，靈活地定義健康標(biāo)準(zhǔn)并指定健康檢查端點(diǎn)，有點(diǎn)類似于kubernetes中ingress。

Firewall

防火墻定義了網(wǎng)絡(luò)流量訪問，定義了一些訪問的規(guī)則，如安全組等等。

頁(yè)面展示如下，還是比較精簡(jiǎn)的，可以在它的操作頁(yè)面上看到項(xiàng)目以及應(yīng)用的詳細(xì)信息，還可以進(jìn)行集群的伸縮，回滾，修改以及刪除的操作。

2、spinnaker的部署管理功能

上圖中，infrastructure左側(cè)為PIPELINE的設(shè)計(jì)：主要講兩塊內(nèi)容：pipeline的創(chuàng)建，與部署的策略。

Pipeline

1）、較強(qiáng)的 Pipeline 的能力：它的 Pipeline 可以復(fù)雜到無以復(fù)加，它還有很強(qiáng)的表達(dá)式功能(后續(xù)的操作中前面的參數(shù)均通過表達(dá)式獲取)。

2）、觸發(fā)的方式：定時(shí)任務(wù)，人工觸發(fā)，jenkinsjob，docker images，或者其他的pipeline的步驟。

3）、通知方式：email, SMS or HipChat.

4）、將所有的操作都融合到pipeline中，比如回滾、金絲雀分析、關(guān)聯(lián)CI等等。

3、spinnaker安裝踩過的坑

很多人都是感覺這個(gè)很難安裝，其實(shí)主要的原因還是墻的問題，只要把這個(gè)解決了就會(huì)方便很多，官方的文檔寫的很詳細(xì)，而且spinnaker的社區(qū)也非常的活躍，有問題均可以在上面進(jìn)行提問。

安裝提供的方式：

1）、Halyard安裝方式(官方推薦安裝方式)
>>我采用Halyard安裝方式，因?yàn)楹笃谖覀儠?huì)集成很多其他的插件，類似于gitlab，ldap，kayenta，甚至多個(gè)jenkins，kubernetes服務(wù)等等，可配置性較強(qiáng)

2）、Helm搭建Spinnaker平臺(tái)

3）、Development版本安裝
>>helm方式若是需要自定義一些個(gè)性化的內(nèi)容會(huì)比較復(fù)雜，完全依賴于原始鏡像，而Development需要對(duì)spinnaker非常的熟悉，以及每個(gè)版本之間的對(duì)應(yīng)關(guān)系均要了解。
Halyard方式安裝注意點(diǎn)：

Halyard代理的配置

```
vim /opt/halyard/bin/halyard
DEFAULT_JVM_OPTS='S='-Dhttp.proxyHoxyHost=st=192.168.102.10 -Dh 10 -Dhttps.proxyPoxyPort=3128'
```
部署機(jī)器配置

由于spinnaker涉及的應(yīng)用較多，下面會(huì)單獨(dú)的介紹，需要消耗比較大的內(nèi)存，官方推薦的配置如下：
```
18 GB of RAM
A 4 core CPU
Ubuntu 14.04, 16.04 or 18.0
```

4、spinnaker安裝步驟

1）、Halyard下載以及安裝

2）、選擇云提供者：我選擇的是Kubernetes Provider V2 (Manifest Based)，需要在部署spinnaker的機(jī)器上完成K8S集群的認(rèn)證，以及權(quán)限管理。

3）、部署的時(shí)候選擇安裝環(huán)境：我選擇的是Debian包的方式。

4）、選擇存儲(chǔ)：官方推薦使用minio，我選擇的是minio的方式。

5)、選擇安裝的版本：我當(dāng)時(shí)最新的是V1.8.0

6)、接下來進(jìn)行部署工作，初次部署時(shí)間較長(zhǎng)，會(huì)連接代理下載對(duì)應(yīng)的包。

7)、全部下載與完成后，查看對(duì)應(yīng)的日志，即可使用localhost:9000訪問即可。
完成以上的步驟則可以在kubernetes上面部署對(duì)應(yīng)的應(yīng)用了。

下圖是spinnaker的各個(gè)組件之間的關(guān)系。

下面介紹一下每個(gè)組件在spinnaker中作用

Deck：面向用戶 UI 界面組件，提供直觀簡(jiǎn)介的操作界面，可視化操作發(fā)布部署流程。

API： 面向調(diào)用 API 組件，我們可以不使用提供的
UI，直接調(diào)用 API 操作，由它后臺(tái)幫我們執(zhí)行發(fā)布等任務(wù)。

Gate：是 API 的網(wǎng)關(guān)組件，可以理解為代理，所有請(qǐng)求由其代理轉(zhuǎn)發(fā)。

Rosco：是構(gòu)建 beta 鏡像的組件，需要配置 Packer 組件使用。

Orca：是核心流程引擎組件，用來管理流程。

Igor：是用來集成其他 CI 系統(tǒng)組件，如 Jenkins 等一個(gè)組件。
Echo：是通知系統(tǒng)組件，發(fā)送郵件等信息。

Front50：是存儲(chǔ)管理組件，需要配置 Redis、Cassandra 等組件使用。
Cloud driver 是它用來適配不同的云平臺(tái)的組件，比如 Kubernetes，Google、AWS EC2、Microsoft Azure 等。
Fiat 是鑒權(quán)的組件，配置權(quán)限管理，支持 OAuth、SAML、LDAP、GitHub teams、Azure groups、 Google Groups 等。

5、spinnaker在kubernetes的持續(xù)部署
一個(gè)優(yōu)美的PIPELINE，部署示例。
如下pipeline設(shè)計(jì)就是開發(fā)將版本合到某一個(gè)分支后，通過jenkins鏡像構(gòu)建，發(fā)布測(cè)試環(huán)境，進(jìn)而自動(dòng)化以及人工驗(yàn)證，在由人工判斷是否需要發(fā)布到線上以及回滾，若是選擇發(fā)布到線上則發(fā)布到prod環(huán)境，從而進(jìn)行prod自動(dòng)化的CI。若是選擇回滾則回滾到上個(gè)版本，從而進(jìn)行dev自動(dòng)化的CI。

我們針對(duì)如上的pipeline的每個(gè)stage進(jìn)行分析：

Stage-configuration具有如下的配置

Automated Triggers
設(shè)置觸發(fā)的方式，定義全局變量，執(zhí)行報(bào)告的通知方式，是pipeline的起點(diǎn)
這里我們可以指定多種觸發(fā)的方式：定時(shí)任務(wù)corn，git，jenkins，docker Registry，travis,pipeline,webhook等

Parameters
此處定義的全局變量會(huì)在整個(gè)PIPELINE中使用${ parameters[‘branch’]}得到,這樣大大的簡(jiǎn)化了我們?cè)O(shè)計(jì)pipeline的通用性

Notifications
這里通知支持：SMS，EMAIL，HIPCHAT等等的方式

運(yùn)行完成后展示如下，我們可以查看相關(guān)的build的信息，以及此stage執(zhí)行的相關(guān)信息，點(diǎn)擊build可以跳到對(duì)應(yīng)的jenkins的job查看相關(guān)的任務(wù)信息。

Stage-jenkins這個(gè)就很厲害了，完美的與jenkins結(jié)合，

調(diào)用jenkins來執(zhí)行相關(guān)的任務(wù)，其中jenkins的服務(wù)信息存在放hal的配置文件中（如下展示），spinnaker可自動(dòng)以同步j(luò)enkins的job以及參數(shù)等等的信息，運(yùn)行后能夠看到對(duì)應(yīng)的JOB ID以及狀態(tài)：

Stage-deploy

由于我們配置spinnaker的時(shí)候采用的是Kubernetes Provider V2方式，我們的發(fā)布均采用yaml的方式來實(shí)現(xiàn)，可以將文件存放在github中或者直接在頁(yè)面上進(jìn)行配置，同時(shí)yaml中文件支持了很多的參數(shù)化，這樣大大的方便了我們?nèi)粘５氖褂谩?

halyard關(guān)聯(lián)KUBERNETES的配置信息

由于我們采用的云服務(wù)是KUBERNETES，配置的時(shí)候需要將部署spinnaker的機(jī)器對(duì)KUBERNETES集群做認(rèn)證。

spinnaker發(fā)布信息展示：

此處Manifest Source支持參數(shù)化形式，類似于我們寫入的yaml部署文件，但是這里支持參數(shù)化的方式。

Stage-Webhook

webhook
我們可以做一些簡(jiǎn)單的環(huán)境驗(yàn)證以及去調(diào)用其他的服務(wù)的功能，它自身也提供了一些結(jié)果的驗(yàn)證功能，支持多種請(qǐng)求的方式。
Stage-Manual Judgment

用于人工的邏輯判斷，增加pipeline的控制性(比如發(fā)布到線上需要測(cè)試人員認(rèn)證以及領(lǐng)導(dǎo)審批)，內(nèi)容支持多種語法表達(dá)的方式。

Stage-Check Preconditions

上邊 Manual Judgment Stage 配置了兩個(gè) Judgment Inputs 判斷項(xiàng)，接下來我們建兩個(gè) Check Preconditions Stage 來分別對(duì)這兩種判斷項(xiàng)做條件檢測(cè)，條件檢測(cè)成功，則執(zhí)行對(duì)應(yīng)的后續(xù) Stage 流程。比如上面的操作，若是選擇發(fā)布到prod，則執(zhí)行發(fā)布到線上的分支，若是選擇執(zhí)行回滾的操作則進(jìn)行回滾相關(guān)的分支。

如上圖中我選擇了rollback，則prod分支判斷為失敗，會(huì)阻塞后面的stage運(yùn)行。

Stage-Undo Rollout (Manifest)

若是我們發(fā)布發(fā)現(xiàn)出現(xiàn)問題，也可以設(shè)計(jì)回滾的stage，spinnaker的回滾極其的方便，在我們的日常部署中，每個(gè)版本都會(huì)存在對(duì)應(yīng)的部署記錄。

回滾的pipeline描述中我們需要選擇對(duì)應(yīng)的deployment的回滾信息，以及回滾的版本數(shù)量。
運(yùn)行結(jié)果的示例

Stage-Canary Analysis

金絲雀部署方式：在我們發(fā)布新版本時(shí)引入部分流量到canary的服務(wù)中，kayenta會(huì)讀取spinnaker中配置的prometheus中收集的指標(biāo)，比如內(nèi)存，CPU，接口超時(shí)時(shí)間，失敗率等等通過kayenta中NetflixACAJudge來進(jìn)行分析與判斷，將分析的結(jié)果存于S3中，最終會(huì)給出這段時(shí)間的最終結(jié)果。

6、運(yùn)行結(jié)果的設(shè)計(jì)與展示

1）、我們需要對(duì)應(yīng)用開啟canary的配置。
2）、創(chuàng)建出baseline與canary的deployment由同一個(gè)service指向這兩個(gè)deployment。
3）、我們這里采用讀取prometheus的指標(biāo)，需要在hal中增加prometheus配置。Metric可以直接匹配prometheus的指標(biāo)。

每次分析的執(zhí)行記錄：

結(jié)果展示如下，由于我們?cè)O(shè)置的目標(biāo)是75，所以pipeline的結(jié)果判定為失敗。

7、線上容器服務(wù)的選擇與多區(qū)容災(zāi)

采用云容器服務(wù)主要看重以下幾個(gè)方面:
1、Kubernetes在自搭建的集群中，要實(shí)現(xiàn)Overlay網(wǎng)絡(luò)，在好的云平臺(tái)環(huán)境里，它本身就是軟件定義網(wǎng)絡(luò)VPC，所以它在網(wǎng)絡(luò)上的實(shí)現(xiàn)可以做到在容器環(huán)境里和原生的VM網(wǎng)絡(luò)一樣的快，沒有任何的性能犧牲。
2、應(yīng)用型負(fù)載均衡器和Kubernetes里的ingress相關(guān)聯(lián)，對(duì)于需要外部訪問的服務(wù)能夠快速的創(chuàng)建。
3、云儲(chǔ)存可以被Kubernetes管理，便于持久化的操作。
4、云部署以及告警也對(duì)外提供服務(wù)與接口，可以更好的查看與監(jiān)控相關(guān)的node與pod的情況。
5、云日志服務(wù)很好的與容器進(jìn)行融合，能夠方便的收集與檢索日志。

本文分享的案例中，為了容災(zāi)使用了北京二區(qū)與北京三區(qū)兩個(gè)集群，若是需要灰度驗(yàn)證時(shí)，則將線上北京三區(qū)的權(quán)重修改為0，這樣通過灰度負(fù)載均衡器即可到達(dá)新版本應(yīng)用。日常使用中二區(qū)與三區(qū)均同時(shí)提供掛服務(wù)。設(shè)計(jì)的思路以及模型如下：

pipeline執(zhí)行結(jié)果展示

具體某個(gè)應(yīng)用的展示：

具體某個(gè)應(yīng)用的展示：

8、相關(guān)問題

Q：為什么沒有和CI結(jié)合在一起？使用這個(gè)比較重的spannaker有什么優(yōu)勢(shì)？

A：可以和CI進(jìn)行結(jié)合，比如webhook的方式，或者采用jenkins調(diào)度的方式。
優(yōu)勢(shì)在于可以和很多云平臺(tái)進(jìn)行結(jié)合不僅僅支持容器，而且他的pipeline比較完美，參數(shù)化程度很高。

Q：spannaker的安全性方面怎么控制？

A：spinnaker中Fiat 是鑒權(quán)的組件，配置權(quán)限管理，Auth、SAML、LDAP、GitHub teams、Azure groups、 Google Groups，我們就采用ldap，登陸后會(huì)在上面顯示對(duì)應(yīng)的登陸人員。

Q：spinnaker能不能在pipeline里通過http api獲取一個(gè)deployment yaml進(jìn)行deploy，這個(gè)yaml可能是動(dòng)態(tài)生成的

A：部署服務(wù)有兩種方式：
1）、在spinnaker的UI中直接填入Manifest Source ，其實(shí)就是對(duì)應(yīng)的deployment YAML,只不過這里可以寫入pipeline的參數(shù)。
2）、可以從github中拉取對(duì)應(yīng)的文件，來部署，前提是要配置好對(duì)應(yīng)的git地址以及項(xiàng)目。

Q：目前IaaS只支持openstack和國(guó)外的公有云廠商，國(guó)內(nèi)的云服務(wù)商如果要支持的話，底層需要怎么做呢（管理云主機(jī)而不是容器）？自己實(shí)現(xiàn)的話容易嗎？怎么入手？

A：目前我們主要使用spinnaker用來管理容器這部分的內(nèi)容，對(duì)于國(guó)內(nèi)的云廠商spinnaker支持都不是非常的好，像lb，安全策略這些都不可在spinnaker上面控制。若是需要研究可以查看Cloud driver這個(gè)組件的功能。
Q：個(gè)人感覺還是需要結(jié)合Jenkins完成build，還有鏡像倉(cāng)庫(kù) etc。。。spinnaker只是完成了后面交付的部分，是這樣吧？

A：對(duì)的，spinnaker是一個(gè)持續(xù)交付的工具，我們?cè)谑褂弥幸彩峭ㄟ^jenkins來完成鏡像的制作以及推送到倉(cāng)庫(kù)。

Q： spannaker 之前的截圖看到也有對(duì)部分用戶開發(fā)的功能，用spannaker 之后 還需要Istio嗎？

A：這兩個(gè)有不同的功能，【對(duì)部分用戶開發(fā)的功能】這個(gè)是依靠創(chuàng)建不同的service以及ingress來實(shí)現(xiàn)的，他的路由能力肯定沒有istio強(qiáng)悍，而且也不具備熔斷等等的技術(shù)，我們線下這么創(chuàng)建主要為了方便開發(fā)人員進(jìn)行快速的部署與調(diào)試。
Q： deploy和test以及rollback可以跟helm chart集成嗎？

A:我覺得是可以，很笨的方法最終都是可以借助于jenkins來實(shí)現(xiàn)，但是spinnaker的回滾與部署技術(shù)很強(qiáng)大，在頁(yè)面上點(diǎn)擊就可以進(jìn)行快速的版本回滾與部署。
Q：最外層為何選擇nginx集群而不是某云的負(fù)載均衡器？

A：我們流量的入口是某云的負(fù)載均衡器，但是接下來我們有一些策略在NGINX中實(shí)現(xiàn)。

（本文根據(jù) 季邦華 社群分享整理）