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

有貨基於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)

分享創造快樂