歡迎光臨
每天分享高質量文章

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

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

Spinnaker是Netflix的開源專案,是一個持續交付平臺,它定位於將產品快速且持續的部署到多種雲平臺上。Spinnaker有兩個核心的功能集群管理和部署管理。Spinnaker通過將發佈和各個雲平臺解耦,來將部署流程流水線化,從而降低平臺遷移或多雲平臺部署應用的複雜度,它本身內部支持Google、AWS EC2、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
  • 較強的Pipeline的能力:它的Pipeline可以複雜到無以復加,它還有很強的運算式功能(後續的操作中前面的引數均通過運算式獲取)。

  • 觸發的方式:定時任務、人工觸發、Jenkins job、Docker images,或者其他的Pipeline的步驟。

  • 通知方式:Email、SMS or HipChat。

  • 將所有的操作都融合到Pipeline中,比如回滾、金絲雀分析、關聯CI等等。


部署策略
由於我們用的是Kubernetes Provider V2(Manifest Based)方式:可修改yaml中:spec.strategy.type。
  • Recreate,先將所有舊的Pod停止,然後再啟動新的Pod對應其中的第一種方式。

  • RollingUpdate,即滾動升級,對應下圖中第二種方式。

  • Canary下麵會單獨的介紹其中的使用。

Spinnaker安裝踩過的坑

很多人都是感覺這個很難安裝,其實主要的原因還是牆的問題,只要把這個解決了就會方便很多,官方的文件寫的很詳細,而且Spinnaker的社區也非常的活躍,有問題均可以在上面進行提問。
安裝提供的方式
  • Halyard安裝方式(官方推薦安裝方式)

  • Helm搭建Spinnaker平臺

  • 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安裝步驟
  1. Halyard下載以及安裝。

  2. 選擇雲提供者:我選擇的是Kubernetes Provider V2(Manifest Based),需要在部署Spinnaker的機器上完成Kubernetes集群的認證,以及權限管理。

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

  4. 選擇儲存:官方推薦使用Minio,我選擇的是Minio的方式。

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

  6. 接下來進行部署工作,初次部署時間較長,會連接代理下載對應的包。

  7. 全部下載與完成後,查看對應的日誌,即可使用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 EC2、Microsoft Azure等。

  • Fiat:是鑒權的組件,配置權限管理,支持OAuth、SAML、LDAP、GitHub teams、Azure groups、 Google Groups等。

組件 端口 依賴組件 端口
Clouddriver 7002 Minio
Fiat 7003 Jenkins
Front50 8080 Ldap
Orca 8083 GitHub
Gate 8084
Rosco 8087
Igor 8088
Echo 8089
Deck 9000
Kayenta 8090

Spinnaker在Kubernetes的持續部署

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

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分析主要經過如下四個步驟:
  • 驗證資料

  • 清理資料

  • 比對指標

  • 分數計算

設計的模型如下:

運行結果的設計與展示:
  • 我們需要對應用開啟Canary的配置。

  • 創建出Baseline與Canary的deployment由同一個Service指向這兩個deployment。

  • 我們這裡採用讀取Prometheus的指標,需要在hal中增加Prometheus配置。Metric可以直接匹配Prometheus的指標。

    需要配置收集指標以及指標的權重:

  • 在Pipeline中指定收集分析的頻率以及需要指定的源,同時可以配置scoring從而改寫模板中的配置。

  • 每次分析的執行記錄:

  • 結果展示如下,由於我們設置的標的是75,所以pipeline的結果判定為失敗。


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

我們是騰訊雲的客戶,採用騰訊雲容器服務主要看重以下幾個方面:
  1. Kubernetes在自搭建的集群中,要實現Overlay網絡,在騰訊雲的環境里,它本身就是軟體定義網絡VPC,所以它在網絡上的實現可以做到在容器環境里和原生的VM網絡一樣的快,沒有任何的性能犧牲。

  2. 應用型負載均衡器和Kubernetes里的Ingress相關聯,對於需要外部訪問的服務能夠快速的創建。

  3. 騰訊雲的雲儲存可以被Kubernetes管理,便於持久化的操作。

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

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

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

為了容災我們使用了北京二區與北京三區兩個集群,若是需要灰度驗證時,則將線上北京三區的權重修改為0,這樣通過灰度負載均衡器即可到達新版本應用。日常使用中二區與三區均同時提供掛服務。


Q&A;

Q:為什麼沒有和CI結合在一起?使用這個比較重的Spannaker有什麼優勢?
A:可以和CI進行結合,比如Webhook的方式,或者採用Jenkins調度的方式。優勢在於可以和很多雲平臺進行結合,而且他的Pipeline比較的完美,引數化程度很高。
Q:目前IaaS只支持OpenStack和國外的公有雲廠商,國內的雲服務商如果要支持的話,底層需要怎麼做呢(管理雲主機而不是容器)?自己實現的話容易嗎?怎麼入手?
A:目前我們主要使用Spinnaker用來管理容器這部分的內容,對於國內的雲廠商Spinnaker支持都不是非常的好,像LB,安全策略這些都不可在Spinnaker上面控制。若是需要研究可以查看Cloud driver這個組件的功能。
Q:Spinnaker能不能在Pipeline里通過http API獲取一個deployment yaml進行deploy,這個yaml可能是動態生成的?
A:部署服務有兩種方式:1. 在Spinnaker的UI中直接填入Manifest Source,其實就是對應的deployment YAML,只不過這裡可以寫入Pipeline的引數;2. 可以從GitHub中拉取對應的檔案,來部署。
Q:Spannaker的安全性方面怎麼控制?
A:Spinnaker中Fiat是鑒權的組件,配置權限管理,Auth、SAML、LDAP、GitHub teams、Azure Groups、 Google Groups,我們就採用LDAP,登陸後會在上面顯示對應的登陸人員。
Q: deploy和test以及rollback可以跟helm chart集成嗎?
A:我覺得是可以,很笨的方法最終都是可以借助於Jenkins來實現,但是Spinnaker的回滾與部署技術很強大,在頁面上點擊就可以進行快速的版本回滾與部署。
Q: Spannaker之前的截圖看到也有對部分用戶開發的功能,用Spannaker之後還需要Istio嗎?
A:這兩個有不同的功能,【對部分用戶開發的功能】這個是依靠創建不同的service以及Ingress來實現的,他的路由能力肯定沒有Istio強悍,而且也不具備熔斷等等的技術,我們線下這麼創建主要為了方便開發人員進行快速的部署與除錯。

Kubernetes應用實戰培訓

Kubernetes應用實戰培訓將於2018年9月14日在上海開課,3天時間帶你系統掌握Kubernetes本次培訓包括:容器特性、鏡像、網絡;Docker特性、架構、組件、概念、Runtime;Docker安全;Docker實踐;Kubernetes架構、核心組件、基本功能;Kubernetes設計理念、架構設計、基本功能、常用物件、設計原則;Kubernetes的實踐、運行時、網絡、插件已經落地經驗;微服務架構、DevOps等,點擊下方圖片查看詳情。

赞(0)

分享創造快樂