基于云原生架構(gòu)下的DevOps實(shí)踐

基于云原生架構(gòu)下的DevOps實(shí)踐目錄CONTENTS一、“傳統(tǒng)”DevOps如何技術(shù)演進(jìn)為“云原生”DevOps二、云原生和DevOps的結(jié)合實(shí)踐三、金融生產(chǎn)級(jí)云原生容器云平臺(tái)的優(yōu)化四、基于云原生的DevOps技術(shù)趨勢(shì)“云化”DevOps“傳統(tǒng)”DevOps輕量級(jí)交付

快速?gòu)椥陨炜s

提高資源利用率

故障自動(dòng)遷移

.2 3全棧自動(dòng)化4

流水線自動(dòng)化

故障自愈

支持跨數(shù)據(jù)中心調(diào)度

以整套環(huán)境為單位交付云原生工具生態(tài)

K8S原生CI/CD系統(tǒng)

服務(wù)可視化編排

滾動(dòng)升級(jí)發(fā)布

流量接入/灰度發(fā)布

1基于物理機(jī)/獨(dú)立虛機(jī)技術(shù)的時(shí)代2 3應(yīng)用軟件交付

周期長(zhǎng)、迭代慢

手工配置、自動(dòng)化率低

不能可視化交付

不能以環(huán)境+系統(tǒng)為單位交付

1應(yīng)用跨云遷移性

.4集群感知(Cluster-Aware)

IaaS資源可編程接口實(shí)現(xiàn)集群感知

自動(dòng)協(xié)調(diào)控制，動(dòng)態(tài)配置

提高開發(fā)測(cè)試和交付的效率

資源環(huán)境的搭建與應(yīng)用部署過程割裂開來

創(chuàng)建系統(tǒng)資源環(huán)境效率低、耗時(shí)、風(fēng)險(xiǎn)高

系統(tǒng)變更需靜態(tài)配置+人工協(xié)調(diào)資源環(huán)境交付

基于IaaS技術(shù)的時(shí)代一鍵自動(dòng)化

創(chuàng)建環(huán)境到部署安裝應(yīng)用組件整個(gè)過程的一鍵創(chuàng)建和部署

資源和應(yīng)用同時(shí)交付

擴(kuò)縮容后服務(wù)自動(dòng)注冊(cè)

基于容器技術(shù)的時(shí)代

遷移后環(huán)境一致性

遷移部署速度快

一次打包，到處運(yùn)行

基于云原生技術(shù)的時(shí)代“傳統(tǒng)”DevOps如何技術(shù)演進(jìn)為“云原生”DevOps目錄CONTENTS一、“傳統(tǒng)”DevOps如何技術(shù)演進(jìn)為“云原生”DevOps二、云原生和DevOps的結(jié)合實(shí)踐

三、金融生產(chǎn)級(jí)云原生容器云平臺(tái)的優(yōu)化四、基于云原生的DevOps技術(shù)趨勢(shì)云平臺(tái)總體架構(gòu)云管平臺(tái)物理設(shè)備管理 虛擬機(jī)管理 虛擬卷管理 虛擬網(wǎng)絡(luò)管理資源池管理容器管理應(yīng)用管理 DevOps監(jiān)控運(yùn)維服務(wù)目錄 服務(wù)質(zhì)量（SLA）租戶體系Openstack云平臺(tái)容器平臺(tái)基礎(chǔ)設(shè)施平臺(tái)NovaCinderNeutron服務(wù)器存儲(chǔ) 網(wǎng)絡(luò) 安全鏡像倉(cāng)庫(kù)容器管理持續(xù)集成持續(xù)部署編排引擎配置管理Openstack云平臺(tái)容器平臺(tái)NovaCinder SwiftNeutronGlanceMonitoringMeteringBackup/Restore Image鏡像倉(cāng)庫(kù)容器管理持續(xù)集成持續(xù)部署編排引擎配置管理服務(wù)器存儲(chǔ) 網(wǎng)絡(luò) 安全A數(shù)據(jù)中心 B數(shù)據(jù)中心跨數(shù)據(jù)中心可編排調(diào)度容器網(wǎng)絡(luò)二層打通，跨數(shù)據(jù)中心可遷移云主機(jī)江北、雨花IDC基礎(chǔ)設(shè)施池化其他組件VMware云平臺(tái)vSpherevSANNSX其他組件Openstack云平臺(tái)NovaCinderNeutron其他組件VMware云平臺(tái)vSpherevSAN其他組件NSXDevOps總體架構(gòu)

可自定義流程：把DevOps流程抽象并具體化成一個(gè)個(gè)獨(dú)立的動(dòng)作，形成標(biāo)準(zhǔn)化DevOps流程自動(dòng)化流程引擎：面向可編排任務(wù)流程，提供任務(wù)的編排、配置、執(zhí)行等功能，通過該流程引擎支撐不同應(yīng)用的不同DevOps流程，實(shí)現(xiàn)DevOps的自定義特性。支撐平臺(tái)：管理DevOps流程中涉及的各類資源，包括代碼管理、持續(xù)集成、配置文件、應(yīng)用實(shí)例等，同時(shí)提供部署、配置等Ops服務(wù)?？勺远x流程GIT validate Pre-processcompile testingpackagingverify Pre-release install configdeployonline支撐平臺(tái)代碼倉(cāng)庫(kù)管理應(yīng)用版本庫(kù)持續(xù)集成管理構(gòu)建任務(wù)管理配置文件（模板）管理安裝腳本管理自動(dòng)部署服務(wù)自動(dòng)配置服務(wù)腳本運(yùn)行器任務(wù)管理環(huán)境管理應(yīng)用實(shí)例管理自動(dòng)化流程引擎任務(wù)1任務(wù)2.1任務(wù)2.2任務(wù)3數(shù)據(jù)調(diào)度器庫(kù)服務(wù)發(fā)現(xiàn)調(diào)度器接口任務(wù)隊(duì)列任務(wù)執(zhí)行任務(wù)調(diào)度引擎支撐平臺(tái)DevOps系統(tǒng)選型分析Jenkins

云化DevOps系統(tǒng)=？Spinnaker

GitlabTektonArgo持續(xù)交付平臺(tái)

專注于多云平臺(tái)的CD老牌CI/CD工具

感覺太重

Jenkins的Pipeline語(yǔ)法學(xué)習(xí)成本

非kubernetes原生

雖帶有CI/CD系統(tǒng)

非kubernetes原生

避免和Gitlab耦合，不想用gitlab-ci遵循聲明式GitOps理念的持續(xù)部署工具

應(yīng)用定義、配置和環(huán)境信息是聲明式的且可以進(jìn)行版本控制

應(yīng)用部署和生命周期管理是全自動(dòng)化的且可審計(jì)

支持對(duì)多環(huán)境、多Kubernetes集群上的應(yīng)用進(jìn)行統(tǒng)一部署和管理Google開源的kubernetes原生CI/CD系統(tǒng)

CDF四個(gè)初始項(xiàng)目之一

基于kubernetesCRD定義的pipeline流水線

在工作流控制上的支持較弱

Tekton+ArgoCD實(shí)踐-場(chǎng)景

應(yīng)用代碼放在CodeRepository中，代碼變化后會(huì)通過Webhook觸發(fā)Tekton的Pipeline運(yùn)行。

Tekton的Pipeline先從CodeRepository中獲得應(yīng)用代碼，然后Build成Image，隨后將應(yīng)用Image推送到容器云平臺(tái)內(nèi)部的ImageRegistry中。最后再更新InfraRepository中的部署配置。

ArgoCD發(fā)現(xiàn)InfraRepository中的部署配置發(fā)生變化后自動(dòng)同步到容器云平臺(tái)。

容器平臺(tái)根據(jù)新的部署配置從其內(nèi)部的ImageRegistry獲取最新的應(yīng)用Image，然后部署到容器云平臺(tái)。

ArgoCD+ArgoRollouts支持blue/green、canary多種部署方式，結(jié)合keptn做SLI/SLO及自動(dòng)化測(cè)試。場(chǎng)景描述：基于Argocd-Rollouts進(jìn)行blue/greencanary發(fā)布創(chuàng)建新版本觀察新版本運(yùn)行狀態(tài)配置發(fā)布策略觀測(cè)真實(shí)流量工作情況采納新版本新版本接收全部（部分）流量原版本全部（部分）下線繼續(xù)發(fā)布此版本下線 更新版本YNY NN Y發(fā)布流程：新舊灰度對(duì)比原灰度系統(tǒng) 新灰度發(fā)布版本發(fā)布新版本全發(fā)布在生產(chǎn)環(huán)境所有應(yīng)用節(jié)點(diǎn)滾動(dòng)發(fā)布，部分流量運(yùn)行新版本，部分流量運(yùn)行老版本系統(tǒng)中斷新版本發(fā)布過程中系統(tǒng)提供服務(wù)會(huì)有短暫中斷新老版本平滑過渡，系統(tǒng)服務(wù)能力不中斷用戶體驗(yàn)白名單用戶可訪問新版系統(tǒng)，非白名單用戶看不到新功能或新功能灰色不能使用，用戶體驗(yàn)效果不好灰度用戶與非灰度用戶分別看到新老版本，待灰度完成，非灰度用戶會(huì)平滑升級(jí)到新功能，系統(tǒng)使用體驗(yàn)較好版本回退現(xiàn)有灰度系統(tǒng)發(fā)布失敗后，需全量回退版本，回退過程系統(tǒng)會(huì)再次中斷服務(wù)灰度發(fā)布驗(yàn)證有問題，可滾動(dòng)回滾老版本，系統(tǒng)運(yùn)行不中斷流量控制通過白名單系統(tǒng)控制訪問賬戶，無法做精準(zhǔn)流控，對(duì)線上系統(tǒng)容量、性能指標(biāo)無法做到精準(zhǔn)測(cè)算通過云原生的技術(shù)平臺(tái)可以做灰度流量的控制調(diào)配，以掌控灰度功能發(fā)布成功率、精準(zhǔn)測(cè)算系統(tǒng)容量和性能瓶頸等目錄CONTENTS一、“傳統(tǒng)”DevOps如何技術(shù)演進(jìn)為“云原生”DevOps二、云原生和DevOps的結(jié)合實(shí)踐三、金融生產(chǎn)級(jí)云原生容器云平臺(tái)的優(yōu)化四、基于云原生的DevOps技術(shù)趨勢(shì)以上生產(chǎn)為目標(biāo)如我們是以上生產(chǎn)為目標(biāo)，列舉幾個(gè)原則：1、盡量不改變現(xiàn)有生產(chǎn)網(wǎng)絡(luò)架構(gòu)模式、不改變生產(chǎn)系統(tǒng)IP地址以及防火墻策略，使現(xiàn)有的防火墻規(guī)則對(duì)K8S集群中的POD也生效，那么可以使用macvlan這種網(wǎng)絡(luò)模型，這樣PODip和宿主機(jī)屬于同一網(wǎng)絡(luò)平面，既所有的網(wǎng)絡(luò)流量都會(huì)經(jīng)過現(xiàn)有交換機(jī)和防火墻（這種場(chǎng)景下可以簡(jiǎn)單的理解為POD就是虛擬機(jī)），需要提前規(guī)劃足夠多的IP地址資源池來給后面所有的POD使用。使用macvlan最大的問題：受技術(shù)原理限制（主要是underlay2層流量不經(jīng)過宿主機(jī)的3層及以上的協(xié)議棧，報(bào)文沒有用iptables，ipvs處理，所以K8s里的Service、QoS、networkpolicy沒法實(shí)現(xiàn)），二是需要開啟混雜模式，這種模式下會(huì)造成網(wǎng)卡過多的接受非自身處理的數(shù)據(jù)包。

2、還需要考慮集群內(nèi)部的網(wǎng)絡(luò)安全策略以及QoS，雖可通過Calico的networkpolicy來配置ipvs來實(shí)現(xiàn)，但原生Calico均是命令行，操作不方便和易出錯(cuò)。

3、需要考慮集群內(nèi)POD與第三方外圍系統(tǒng)（如虛機(jī)某端口）安全策略（如核心生產(chǎn)區(qū)到外聯(lián)DMZ區(qū)或者核心生產(chǎn)區(qū)到互聯(lián)網(wǎng)DMZ區(qū)，需要開點(diǎn)到點(diǎn)的防火墻策略，源和目的都是物理IP），用macvlan也可以解決此需求，但不支持Service

4、可使用linuxbrige-vlan模式需要考慮的底層技術(shù)1、K8S中CPUNUMA調(diào)度能力優(yōu)化2、K8S集群調(diào)度能力，如：宿主機(jī)宕機(jī)場(chǎng)景后，調(diào)度策略3、K8S管理Node的能力4、彈性伸縮CA、HPA、VPA能力優(yōu)化5、拉取鏡像規(guī)則：空負(fù)載服務(wù)器、有負(fù)載服務(wù)器，計(jì)數(shù)器規(guī)則、就“近”原則6、東西向QoS、networkpolicy7、IPAM能力網(wǎng)絡(luò)定制8、APIServer/ETCD性能優(yōu)化9、harbor需要做雙harbor進(jìn)行同步，保證鏡像倉(cāng)庫(kù)高可用10、etcd要用ssd做加速，做兩個(gè)etcd集群，把存儲(chǔ)的數(shù)據(jù)按事件類型不同分別讀寫不同的集群11、。。。。。。

DevOps基礎(chǔ)架構(gòu)監(jiān)控中心DevOps基礎(chǔ)架構(gòu)監(jiān)控-APIServer

DevOps基礎(chǔ)架構(gòu)監(jiān)控-ETCD

@KubeSphereandFriendsShanghaiDevOps基礎(chǔ)架構(gòu)監(jiān)控-調(diào)度器DevOps基礎(chǔ)架構(gòu)監(jiān)控-節(jié)點(diǎn)用量排行DevOps項(xiàng)目管理DevOps+容器云實(shí)踐效果系統(tǒng)建站資源提供過程管理代碼走查版本發(fā)布配置管理迭代周期虛機(jī)+原CI系統(tǒng)手工部署1-3天虛機(jī)鏡像方式0.5-1.5小時(shí)各項(xiàng)目分散多樣化管理人工走查0.5-1天人工/腳本方式1-2小時(shí)各項(xiàng)目分散多樣化管理1個(gè)月容器云+DevOps自動(dòng)化部署1小時(shí)容器鏡像方式2-5秒DevOps工具可視化管理自動(dòng)掃描5-10分鐘流水線發(fā)布2-10分鐘統(tǒng)一配置庫(kù)多角色協(xié)作14天

環(huán)境交付、版本發(fā)布周期提速2-3倍

提升投產(chǎn)質(zhì)量，提升用戶體驗(yàn)

投產(chǎn)時(shí)用戶體驗(yàn) 指定版本能力，保證系統(tǒng)穩(wěn)定 提升投產(chǎn)質(zhì)量虛機(jī)+原CI系統(tǒng)

發(fā)布版本時(shí)部分應(yīng)用實(shí)例強(qiáng)制關(guān)閉，發(fā)完版本再啟動(dòng)應(yīng)用，有可能會(huì)影響正在訪問系統(tǒng)的用戶體驗(yàn)發(fā)版結(jié)束但業(yè)務(wù)驗(yàn)證失敗，此時(shí)不具備版本回退能力，需要人工處理新投產(chǎn)系統(tǒng)，測(cè)試和生產(chǎn)環(huán)境配置不一致容器云+DevOps版本發(fā)布時(shí)，應(yīng)用實(shí)例滾動(dòng)升級(jí)、優(yōu)雅停機(jī)，即待用戶連接釋放后再停機(jī)發(fā)版，滾動(dòng)升級(jí)，保證用戶體驗(yàn)可指定任意歷史版本，一鍵回退版本，保證系統(tǒng)穩(wěn)定性集裝箱式上線發(fā)布服務(wù)，屏蔽環(huán)境差異，測(cè)試生產(chǎn)配置完全一致

容器云實(shí)踐效果

資源利用率提升60%，服務(wù)器/機(jī)柜成本下降60%

運(yùn)維效率/生產(chǎn)保障能力提升

投產(chǎn)服務(wù)實(shí)例數(shù) 需物理機(jī)數(shù)服務(wù)器成本機(jī)柜成本虛機(jī) Nginx+Jboss+Mysql+R+ZK+Kafka約3000+個(gè)60臺(tái) X萬 Y萬/年容器云Nginx+Jboss+Mysql+R+ZK+Kafka約3000+個(gè)24臺(tái) 0.4X萬 0.4Y萬/年場(chǎng)景生產(chǎn)計(jì)算資源不足（無狀態(tài)服務(wù)） 生產(chǎn)物理機(jī)宕機(jī)（無狀態(tài)服務(wù)）生產(chǎn)應(yīng)急需求虛機(jī) 1、運(yùn)維人員收到監(jiān)控告警2、撥入堡壘機(jī)，登錄vsphere3、人工擴(kuò)容，再修改JBOSS配置4、人工修改NGINX設(shè)置再reload5、總計(jì)耗時(shí)1小時(shí)+

1、生產(chǎn)環(huán)境無狀態(tài)服務(wù)的存儲(chǔ)使用本地盤2、計(jì)劃外物理機(jī)宕機(jī)3、無狀態(tài)服務(wù)無法遷移生產(chǎn)業(yè)務(wù)系統(tǒng)故障1、既需要重啟恢復(fù)業(yè)務(wù)2、也需要保留故障現(xiàn)場(chǎng)，做后續(xù)分析定位目前能做到第1點(diǎn)容器云提前設(shè)置彈性策略，根據(jù)負(fù)載自動(dòng)彈性，耗時(shí)秒級(jí)計(jì)劃外物理機(jī)宕機(jī)，無狀態(tài)服務(wù)可遷移可先快速拉起新容器對(duì)外提供服務(wù)能力，同時(shí)保留故障實(shí)例做后續(xù)分析目錄CONTENTS一、“傳