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

成都創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),巴彥淖爾企業(yè)網(wǎng)站建設(shè),巴彥淖爾品牌網(wǎng)站建設(shè),網(wǎng)站定制,巴彥淖爾網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,巴彥淖爾網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

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

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

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

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

Cluster

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

Load Balancer

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

Firewall

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

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

2、spinnaker的部署管理功能

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

Pipeline

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

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

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

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

3、spinnaker安裝踩過的坑

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

安裝提供的方式：

1）、Halyard安裝方式(官方推薦安裝方式)
>>我采用Halyard安裝方式，因為后期我們會集成很多其他的插件，類似于gitlab，ldap，kayenta，甚至多個jenkins，kubernetes服務(wù)等等，可配置性較強

2）、Helm搭建Spinnaker平臺

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

Halyard代理的配置

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

由于spinnaker涉及的應(yīng)用較多，下面會單獨的介紹，需要消耗比較大的內(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的機器上完成K8S集群的認(rèn)證，以及權(quán)限管理。

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

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

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

6)、接下來進行部署工作，初次部署時間較長，會連接代理下載對應(yīng)的包。

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

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

下面介紹一下每個組件在spinnaker中作用

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

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

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

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

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

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

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

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

我們針對如上的pipeline的每個stage進行分析：

Stage-configuration具有如下的配置

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

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

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

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

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

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

Stage-deploy

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

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

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

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

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

Stage-Webhook

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

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

Stage-Check Preconditions

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

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

Stage-Undo Rollout (Manifest)

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

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

Stage-Canary Analysis

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

6、運行結(jié)果的設(shè)計與展示

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

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

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

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

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

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

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

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

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

8、相關(guān)問題

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

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

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

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

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

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

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

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

A：對的，spinnaker是一個持續(xù)交付的工具，我們在使用中也是通過jenkins來完成鏡像的制作以及推送到倉庫。

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

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

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

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

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

網(wǎng)站標(biāo)題：如何在Kubernetes容器環(huán)境下部署Spinnaker？-創(chuàng)新互聯(lián)
路徑分享：http://chinadenli.net/article20/cepejo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站制作、云服務(wù)器、響應(yīng)式網(wǎng)站、域名注冊、外貿(mào)網(wǎng)站建設(shè)、App設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)