有貨基於Kubernetes容器環境的持續交付實踐

業內各大雲服務商以及公司逐漸選擇Kubernetes與Docker做爲微服務支撐的首選平臺。爲了更好知足DevOps，咱們採用了開源框架Spinnaker做爲持續交付平臺，完成服務的快速部署，回滾，A/B測試，以及金絲雀等等的部署方式，同時咱們在生產作了多區的容災，更好的保障線上服務。

Spinnaker介紹

Spinnaker是Netflix的開源項目，是一個持續交付平臺，它定位於將產品快速且持續的部署到多種雲平臺上。Spinnaker有兩個核心的功能集羣管理和部署管理。Spinnaker經過將發佈和各個雲平臺解耦，來將部署流程流水線化，從而下降平臺遷移或多雲平臺部署應用的複雜度，它自己內部支持Google、AWS EC二、Microsoft Azure、Kubernetes和OpenStack等雲平臺，而且它能夠無縫集成其餘持續集成（CI）流程，如Git、Jenkins、Travis CI、Docker registry、cron調度器等。

應用管理

Spinnaker主要用於展現與管理你的雲端資源。

先要了解一些關鍵的概念：Applications，Cluster，and Server Groups，經過Load balancers and firewalls將服務展現給用戶。官方給的結構以下：

Application

定義了集羣中一組的Cluster的集合，也包括了Firewalls與Load Balancers，存儲了服務全部的部署相關的的信息。

Server Group

定義了一些基礎的源好比（VM image、Docker image），以及一些基礎的配置信息，一旦部署後，在容器中對應Kubernetes Pod的集合。

Cluster

Server Groups的有關聯的集合。（Cluster中能夠按照dev，prod的去建立不一樣的服務組），也能夠理解爲對於一個應用存在多個分支的狀況。

Load Balancer

它在實例之間作負載均衡流量。您還能夠爲負載均衡器啓用健康檢查，靈活地定義健康標準並指定健康檢查端點，有點相似於Kubernetes中Ingress。

Firewall

防火牆定義了網絡流量訪問，定義了一些訪問的規則，如安全組等等。

頁面預覽

頁面展現以下，仍是比較精簡的，能夠在它的操做頁面上看到項目以及應用的詳細信息，還能夠進行集羣的伸縮、回滾、修改以及刪除的操做。

部署管理

上圖中，Infrastructure左側爲Pipeline的設計：主要講兩塊內容：Pipeline的建立以及基礎功能，與部署的策略。

Pipeline

1.較強的Pipeline的能力：它的Pipeline能夠複雜到無以復加，它還有很強的表達式功能（後續的操做中前面的參數均經過表達式獲取）。

2.觸發的方式：定時任務、人工觸發、Jenkins job、Docker images，或者其餘的Pipeline的步驟。

3.通知方式：Email、SMS or HipChat。

4.將全部的操做都融合到Pipeline中，好比回滾、金絲雀分析、關聯CI等等。

部署策略

因爲咱們用的是Kubernetes Provider V2（Manifest Based）方式：可修改yaml中：spec.strategy.type。

1.Recreate，先將全部舊的Pod中止，而後再啓動新的Pod對應其中的第一種方式。

2.RollingUpdate，即滾動升級，對應下圖中第二種方式。

3.Canary下面會單獨的介紹其中的使用。

Spinnaker安裝踩過的坑

不少人都是感受這個很難安裝，其實主要的緣由仍是牆的問題，只要把這個解決了就會方便不少，官方的文檔寫的很詳細，並且Spinnaker的社區也很是的活躍，有問題都可以在上面進行提問。

安裝提供的方式

1.Halyard安裝方式（官方推薦安裝方式）

2.Helm搭建Spinnaker平臺

3.Development版本安裝

我採用Halyard安裝方式，由於後期咱們會集成不少其餘的插件，相似於GitLab、LDAP、Kayenta，甚至多個Jenkins，Kubernetes服務等等，可配置性較強。Helm方式如果須要自定義一些個性化的內容會比較複雜，徹底依賴於原始鏡像，而Development須要對Spinnaker很是的熟悉，以及每一個版本之間的對應關係均要了解。

Halyard方式安裝注意點

Halyard代理的配置

vim /opt/halyard/bin/halyard
DEFAULT_JVM_OPTS='-Dhttp.proxyHost=192.168.102.10 -Dhttps.proxyPort=3128'

部署機器選擇

因爲Spinnaker涉及的應用較多，下面會單獨的介紹，須要消耗比較大的內存，官方推薦的配置以下：

18 GB of RAM
 A 4 core CPU
 Ubuntu 14.04, 16.04 or 18.04

Spinnaker安裝步驟

Halyard下載以及安裝。

1.選擇雲提供者：我選擇的是Kubernetes Provider V2（Manifest Based），須要在部署Spinnaker的機器上完成Kubernetes集羣的認證，以及權限管理。

2.部署的時候選擇安裝環境：我選擇的是Debian包的方式。

3.選擇存儲：官方推薦使用Minio，我選擇的是Minio的方式。

4.選擇安裝的版本：我當時最新的是V1.8.0。

5.接下來進行部署工做，初次部署時間較長，會鏈接代理下載對應的包。

6.所有下載與完成後，查看對應的日誌，便可使用localhost:9000訪問便可。

完成以上的步驟則能夠在Kubernetes上面部署對應的應用了。

涉及的組件

下圖是Spinnaker的各個組件之間的關係。

Deck：面向用戶UI界面組件，提供直觀簡介的操做界面，可視化操做發佈部署流程。

API：面向調用API組件，咱們能夠不使用提供的UI，直接調用API操做，由它後臺幫咱們執行發佈等任務。

Gate：是API的網關組件，能夠理解爲代理，全部請求由其代理轉發。

Rosco：是構建beta鏡像的組件，須要配置Packer組件使用。

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

Igor：是用來集成其餘CI系統組件，如Jenkins等一個組件。

Echo：是通知系統組件，發送郵件等信息。

Front50：是存儲管理組件，須要配置Redis、Cassandra等組件使用。

Cloud driver：是用來適配不一樣的雲平臺的組件，好比Kubernetes、Google、AWS EC二、Microsoft Azure等。

Fiat：是鑑權的組件，配置權限管理，支持OAuth、SAML、LDAP、GitHub teams、Azure groups、 Google Groups等。

Pipeline部署示例

以下Pipeline設計就是開發將版本合到某一個分支後，經過Jenkins鏡像構建，發佈測試環境，進而自動化以及人工驗證，在由人工判斷是否須要發佈到線上以及回滾，如果選擇發佈到線上則發佈到prod環境，從而進行prod自動化的CI。如果選擇回滾則回滾到上個版本，從而進行dev自動化的CI。

Stage-configuration

設置觸發的方式，定義全局變量，執行報告的通知方式，是Pipeline的起點。

Automated Triggers，其中支持多種觸發的方式：定時任務Corn，Git，Jenkins，Docker Registry，Travis，Pipeline，Webhook等觸發方式，從而可以知足咱們自動回調的功能。

Stage-configuration

設置觸發的方式，定義全局變量，執行報告的通知方式，是Pipeline的起點。

Automated Triggers，其中支持多種觸發的方式：定時任務Corn，Git，Jenkins，Docker Registry，Travis，Pipeline，Webhook等觸發方式，從而可以知足咱們自動回調的功能。

Parameters，此處定義的全局變量會在整個Pipeline中使用${ parameters['branch']}獲得，這樣大大的簡化了咱們設計Pipeline的通用性。

Notifications，這裏通知支持：SMS，Email，HipChat等等的方式。

咱們使用了郵件通知的功能：須要在echo的配置文件中加入發件郵箱的基本信息。

Stage-jenkins

調用Jenkins來執行相關的任務，其中Jenkins的服務信息存在放hal的配置文件中（以下展現），Spinnaker可自動以同步Jenkins的Job以及參數等等的信息，運行後可以看到對應的Job ID以及狀態：

運行完成後展現以下，咱們能夠查看相關的build的信息，以及此stage執行的相關信息，點擊build能夠跳到對應的Jenkins的Job查看相關的任務信息。

Stage-deploy

因爲咱們配置Spinnaker的時候採用的是Kubernetes Provider V2方式，咱們的發佈均採用yaml的方式來實現，能夠將文件存放在GitHub中或者直接在頁面上進行配置，同時yaml中文件支持了不少的參數化，這樣大大的方便了咱們平常的使用。

Halyard關聯Kubernetes的配置信息：因爲咱們採用的雲服務是Kubernetes，配置的時候須要將部署Spinnaker的機器對Kubernetes集羣作認證。

Spinnaker發佈信息展現：此處Manifest Source支持參數化形式，相似於咱們寫入的yaml部署文件，可是這裏支持參數化的方式。

具體的配置項以下：

- apiVersion: extensions/v1beta1
 kind: Deployment
 metadata:
name: '${ parameters.deployName }-deployment'
namespace: dev
spec:
replicas: 2
template:
metadata:
labels:
name: '${ parameters.deployName }-deployment'
spec:
containers:
- image: >-
192.168.105.2:5000/${ parameters.imageSource }/${
parameters.deployName }:${ parameters.imageversion }
name: '${ parameters.deployName }-deployment'
ports:
- containerPort: 8080
imagePullSecrets:
- name: registrypullsecret
- apiVersion: v1
kind: Service
metadata:
name: '${ parameters.deployName }-service'
namespace: dev
spec:
ports:
- port: 8080
targetPort: 8080
selector:
name: '${ parameters.deployName }-deployment'
- apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: '${ parameters.deployName }-ingress'
namespace: dev
spec:
rules:
- host: '${ parameters.deployName }-dev.ingress.dev.yohocorp.com'
http:
paths:
- backend:
serviceName: '${ parameters.deployName }-service'
servicePort: 8080
path: /

運行結果的示例：

Stage-Webhook

Webhook咱們能夠作一些簡單的環境驗證以及去調用其餘的服務的功能，它自身也提供了一些結果的驗證功能，支持多種請求的方式。

運行結果的示例：

Stage-Manual Judgment

Spinnaker配置信息，用於人工的邏輯判斷，增長Pipeline的控制性（好比發佈到線上須要測試人員認證以及領導審批），內容支持多種語法表達的方式。

運行結果的示例：

Stage-Check Preconditions

上邊Manual Judgment Stage配置了兩個Judgment Inputs判斷項，接下來咱們建兩個Check Preconditions Stage來分別對這兩種判斷項作條件檢測，條件檢測成功，則執行對應的後續Stage流程。好比上面的操做，如果選擇發佈到prod，則執行發佈到線上的分支，如果選擇執行回滾的操做則進行回滾相關的分支。

Spinnaker配置信息：

運行結果的示例：如上圖中我選擇了rollback。

則prod分支判斷爲失敗，會阻塞後面的stage運行。

Stage-Undo Rollout（Manifest）

如果咱們發佈發現出現問題，也能夠設計回滾的stage，Spinnaker的回滾極其的方便，在咱們的平常部署中，每一個版本都會存在對應的部署記錄，以下所示：

Spinnaker Pipeline配置信息：回滾的Pipeline描述中咱們須要選擇對應的deployment的回滾信息，以及回滾的版本數量。

運行結果的示例：

Stage-Canary Analysis

金絲雀部署方式：在咱們發佈新版本時引入部分流量到Canary的服務中，Kayenta會讀取Spinnaker中配置的Prometheus中收集的指標，好比內存，CPU，接口超時時間，失敗率等等經過Kayenta中Netflix ACA Judge來進行分析與判斷，將分析的結果存於S3中，最終會給出這段時間的最終結果。

Canary分析主要通過以下四個步驟：

1.驗證數據

2.清理數據

3.比對指標

4.分數計算

設計的模型以下：

運行結果的設計與展現：

1.咱們須要對應用開啓Canary的配置。

2.建立出Baseline與Canary的deployment由同一個Service指向這兩個deployment。

3.咱們這裏採用讀取Prometheus的指標，須要在hal中增長Prometheus配置。Metric能夠直接匹配Prometheus的指標。

須要配置收集指標以及指標的權重：

在Pipeline中指定收集分析的頻率以及須要指定的源，同時能夠配置scoring從而覆蓋模板中的配置。

每次分析的執行記錄：

結果展現以下，因爲咱們設置的目標是75，因此pipeline的結果斷定爲失敗。

線上容器服務的選擇與多區容災

咱們是騰訊雲的客戶，採用騰訊雲容器服務主要看重如下幾個方面：

1.Kubernetes在自搭建的集羣中，要實現Overlay網絡，在騰訊雲的環境裏，它自己就是軟件定義網絡VPC，因此它在網絡上的實現能夠作到在容器環境裏和原生的VM網絡同樣的快，沒有任何的性能犧牲。

2.應用型負載均衡器和Kubernetes裏的Ingress相關聯，對於須要外部訪問的服務可以快速的建立。

3.騰訊雲的雲儲存能夠被Kubernetes管理，便於持久化的操做。

4.騰訊雲的部署以及告警也對外提供了服務與接口，能夠更好的查看與監控相關的Node與Pod的狀況。

5.騰訊雲日誌服務很好的與容器進行融合，可以方便的收集與檢索日誌。

下圖是咱們在線上以及灰度環境的發佈示意圖。

爲了容災咱們使用了北京二區與北京三區兩個集羣，如果須要灰度驗證時，則將線上北京三區的權重修改成0，這樣經過灰度負載均衡器便可到達新版本應用。平常使用中二區與三區均同時提供掛服務。