作者丨孫健波（天元） 阿里巴巴技術(shù)專家

**導(dǎo)讀：**DevOps 這個(gè)概念最早是在 2007 年提出的，那時(shí)云計(jì)算基礎(chǔ)設(shè)施的概念也才剛剛提出沒多久，而隨著互聯(lián)網(wǎng)的逐漸普及，應(yīng)用軟件的需求爆發(fā)式增長(zhǎng)，軟件開發(fā)的理念也逐漸從瀑布模型（waterfall）轉(zhuǎn)向敏捷開發(fā)（agile）。

傳統(tǒng)的軟件交付模式（應(yīng)用開發(fā)人員專注于軟件開發(fā)、IT 運(yùn)維人員負(fù)責(zé)將軟件部署到服務(wù)器運(yùn)行），再也無(wú)法滿足互聯(lián)網(wǎng)軟件快速迭代的需求。于是，DevOps 作為一種打破研發(fā)和運(yùn)維之間隔閡、加快軟件交付流程、提高軟件交付質(zhì)量的文化理念和最佳實(shí)踐逐漸普及至今。

DevOps 的現(xiàn)狀

DevOps 的流行得益于業(yè)界對(duì)于應(yīng)用軟件敏捷開發(fā)、高質(zhì)量交付的訴求，所以為開發(fā)和運(yùn)維開辟了一塊“公共的空間”，讓雙方可以在這里緊密合作。那時(shí)軟件研發(fā)依舊屬于一個(gè)新興行業(yè)，人們習(xí)慣于向成熟的制造業(yè)學(xué)習(xí)，制造業(yè)解決大規(guī)模生產(chǎn)的方式，就是構(gòu)建流水線，通過(guò)流水線規(guī)范化每個(gè)步驟對(duì)接的內(nèi)容，而流水線上的工人們則只需要各司其職，快速熟練的完成自己這部分生產(chǎn)內(nèi)容。

所以，DevOps 借鑒了制造業(yè)的經(jīng)驗(yàn)，開始構(gòu)建持續(xù)集成/持續(xù)交付（CI/CD）的流水線，催生出了一系列自動(dòng)化/半自動(dòng)化工具（如puppet、chef、ansible等），結(jié)合編寫腳本的可擴(kuò)展能力，將研發(fā)和運(yùn)維的大量操作規(guī)范化，從而達(dá)到彼此協(xié)作的目標(biāo)。但是最終還是要有人投入到這些工具的構(gòu)建中，于是就出現(xiàn)了 DevOps 團(tuán)隊(duì)。DevOps 團(tuán)隊(duì)構(gòu)建的工具和平臺(tái)，幫助研發(fā)更容易地接近生產(chǎn)環(huán)境，讓研發(fā)在持續(xù)集成、持續(xù)交付的過(guò)程中可以一鍵部署、快速試錯(cuò)，從而很大程度提前暴露和避免了軟件在實(shí)際運(yùn)行過(guò)程中的問(wèn)題。

從本質(zhì)上講，**DevOps是為運(yùn)維服務(wù)的。**它把生產(chǎn)環(huán)境的運(yùn)維流程通過(guò)自動(dòng)化的工具提供出來(lái)了，屏蔽了基礎(chǔ)設(shè)施細(xì)節(jié)，同時(shí)讓軟件本身的問(wèn)題更容易暴露，從而把這些問(wèn)題盡量提前交給研發(fā)去解決。這些，其實(shí)都是在幫助運(yùn)維減輕負(fù)擔(dān)。

這一套模式在一開始運(yùn)轉(zhuǎn)良好，但是問(wèn)題也隨著時(shí)間的推移慢慢暴露出來(lái)了。DevOps 本身不為企業(yè)帶來(lái)直接的利潤(rùn)，也不增加產(chǎn)品的功能，它們是企業(yè)的成本中心，所以許多企業(yè)不愿意為 DevOps 投入太多的成本。久而久之，DevOps 的能力便無(wú)法與研發(fā)人員增長(zhǎng)的需求所匹配，不愿意繼續(xù)伴隨著云和開源社區(qū)的發(fā)展向前演進(jìn)，反而成為軟件研發(fā)的瓶頸。試想一下，有多少大公司的技術(shù)人員，對(duì)自己公司里的“研發(fā)效能”工具表示滿意呢？

云計(jì)算的普及

聰明的企業(yè)總能從自己的需求中發(fā)現(xiàn)業(yè)界共有的需求，AWS 便是這么誕生的，他們?cè)缭?2006 年便首次把軟件部署需要的網(wǎng)絡(luò)、計(jì)算、存儲(chǔ)等基礎(chǔ)設(shè)施當(dāng)做服務(wù)提供給用戶，允許任何人在不購(gòu)買服務(wù)器等物理硬件的情況下構(gòu)建互聯(lián)網(wǎng)應(yīng)用程序，規(guī)模化使得整體的成本比用戶自建更低。而云計(jì)算IaaS、PaaS、SaaS的概念也正是在那一年開始逐漸清晰的。

云計(jì)算的初期，用戶主要使用的是IaaS服務(wù)，如虛擬機(jī)、存儲(chǔ)等，使用云計(jì)算服務(wù)的企業(yè)依舊需要運(yùn)維來(lái)管理這一類基礎(chǔ)設(shè)施，只是運(yùn)維管理的對(duì)象從物理機(jī)切換到虛擬機(jī)而已，并沒有太本質(zhì)的區(qū)別。

而隨著云計(jì)算的快速發(fā)展，云的能力不斷補(bǔ)充、增強(qiáng)，漸漸將原先由運(yùn)維提供的方方面面的能力都轉(zhuǎn)換成為了云上的服務(wù)，這其中自然包含了管理軟件完整生命周期的各類服務(wù)，從代碼托管、持續(xù)集成、持續(xù)交付，到監(jiān)控、報(bào)警、自動(dòng)擴(kuò)縮容等一系列的能力，均能在云上找到對(duì)應(yīng)的服務(wù)。品類之多、數(shù)量之巨，令人瞠目結(jié)舌。

但是 DevOps 依然有著用武之地。云的對(duì)接難度實(shí)在太大了，涉及到的云服務(wù)又多，不同云廠商提供的服務(wù)還不統(tǒng)一，為了使用云上的產(chǎn)品不得不投入大量的時(shí)間學(xué)習(xí)，而為了防止云廠商的綁定又不得不做多廠商的適配，DevOps 依舊需要像過(guò)去一樣為開發(fā)屏蔽實(shí)際環(huán)境的復(fù)雜性，只不過(guò)這次他們要負(fù)責(zé)管理的基礎(chǔ)設(shè)施變成了云資源。

改變一切的 Kubernetes

Kubernetes 的本質(zhì)是現(xiàn)代應(yīng)用基礎(chǔ)設(shè)施，它關(guān)注如何將應(yīng)用與“云”天然地集成在一起，將“云”的最大價(jià)值發(fā)揮出來(lái)。Kubernetes 強(qiáng)調(diào)讓基礎(chǔ)設(shè)施能更好的配合應(yīng)用、以更高效的方式為應(yīng)用“輸送”基礎(chǔ)設(shè)施能力，而不是反之。在這個(gè)過(guò)程中，Kubernetes 、Docker、Operator 等在云原生生態(tài)中起到了關(guān)鍵作用的開源項(xiàng)目，正在在把應(yīng)用管理與交付推上一個(gè)跟以前完全不一樣的境況：Kubernetes 的使用者只通過(guò)聲明式的方式描述自己應(yīng)用的終態(tài)是什么，然后一切就結(jié)束了。Kubernetes 會(huì)處理后面的所有事情。

這也是為什么Kubernetes 非常強(qiáng)調(diào)聲明式API。通過(guò)這種方式，Kubernetes 本身接入的基礎(chǔ)設(shè)施能力越強(qiáng)，Kubernetes 的使用者能夠聲明的終態(tài)就越豐富，他的職責(zé)也就約單純。現(xiàn)在，我們不僅能夠通過(guò) Kubernetes 聲明應(yīng)用的運(yùn)行終態(tài)，比如；“這個(gè)應(yīng)用需要 10 個(gè)實(shí)例”，我們還能夠聲明應(yīng)用的很多運(yùn)維終態(tài)，比如：“這個(gè)應(yīng)用使用金絲雀發(fā)布策略進(jìn)行升級(jí)”，以及 “當(dāng)它的 CPU 使用量大于 50%時(shí)，請(qǐng)自動(dòng)擴(kuò)展 2 個(gè)實(shí)例出來(lái)”。

這就讓傳統(tǒng)的 DevOps工具和團(tuán)隊(duì)受到了挑戰(zhàn)：如果一個(gè)業(yè)務(wù)研發(fā)自己只需要通過(guò)聲明式 API 聲明他的應(yīng)用的所有終態(tài)甚至包括完整的 SLA，后面的一切就都會(huì)有 Kubernetes 來(lái)自動(dòng)的搞定，那么他還有什么理由去對(duì)接和學(xué)習(xí)各式各樣的 DevOps 流水線呢？

換句話說(shuō)，長(zhǎng)久以來(lái)，DevOps 實(shí)際上是在充當(dāng)研發(fā)與基礎(chǔ)設(shè)施之間的那一層“膠水”。而現(xiàn)在，Kubernetes 通過(guò)它極具生命力的聲明式 API 和無(wú)限接入的應(yīng)用基礎(chǔ)設(shè)施能力，正在完美的扮演這個(gè)“膠水層”的作用。這也提醒了我們，上一個(gè)正在被 Kubernetes 體系強(qiáng)烈挑戰(zhàn)的“膠水層”，其實(shí)叫做“傳統(tǒng)中間件”：它正遭受到 Service Mesh 的巨大沖擊。

DevOps 會(huì)消失嗎？

近幾年，Kubernetes 項(xiàng)目經(jīng)常被描述成 DevOps 的“最佳拍檔”。類似的觀點(diǎn)認(rèn)為， Kubernetes 跟 Docker 一樣，解決的是軟件運(yùn)行時(shí)的問(wèn)題。這意味著 Kubernetes 更像一種“時(shí)髦”的 IaaS，只不過(guò)運(yùn)行時(shí)從虛擬機(jī)變成了容器。所以，只要能夠?qū)F(xiàn)有 DevOps 思想和流程對(duì)接到 Kubernetes 上來(lái)，就可以享受到容器技術(shù)帶來(lái)的輕量級(jí)與彈性。這對(duì)于提倡“敏捷”的 DevOps 來(lái)說(shuō)，顯然是最好的組合。

不過(guò)，至少目前看來(lái)，Kubernetes 的發(fā)展路徑并不是一個(gè)類 IaaS 的角色。它雖然關(guān)注接入底層的基礎(chǔ)設(shè)施能力，但它本身卻又不是基礎(chǔ)設(shè)施能力的提供方。而且，相比于軟件運(yùn)行時(shí)，Kubernetes 似乎更關(guān)心軟件的生命周期和狀態(tài)流轉(zhuǎn)。不僅如此，它還提供了一種叫做“控制器模型”的機(jī)制來(lái)將軟件的實(shí)際狀態(tài)與期望狀態(tài)不斷逼近，這顯然都已經(jīng)超出了一個(gè)“軟件運(yùn)行時(shí)”的范疇。

Kubernetes 項(xiàng)目對(duì)應(yīng)用本身的“額外關(guān)注”，讓它與一個(gè)類 IaaS 基礎(chǔ)設(shè)施有著明顯的區(qū)別，也讓它“膠水”的定位更加明顯。而如果 Kubernetes 的能力足夠強(qiáng)大，那么作為研發(fā)與基礎(chǔ)設(shè)施之間現(xiàn)有的“膠水層”， DevOps 是否還有必要存在？在所謂的云原生時(shí)代，應(yīng)用研發(fā)與交付是不是真的會(huì)走向“一次聲明”就可以“撒手不管”，從而讓 DevOps 徹底消失呢？

不過(guò)，至少目前看來(lái)，Kubernetes 項(xiàng)目距離這個(gè)愿景，還有不少困難需要克服。

“Platform for Platform” API 的局限性

Kubernetes 是一個(gè)典型的 “Platform for Platform”項(xiàng)目，所以它的 API，距離純研發(fā)視角還是非常遙遠(yuǎn)的。就比如一個(gè) Deployment 對(duì)象，就既包括了研發(fā)側(cè)關(guān)心的鏡像，也包括了基礎(chǔ)設(shè)施側(cè)的資源配置，甚至是容器安全配置。此外， Kubernetes API 并沒有提供出對(duì)“運(yùn)維能力”的描述與定義方式，這也使得聲明之后的“撒手不管”變得遙不可及。這也是為什么目前 DevOps 依然被需要的原因：Kubernetes 的大多數(shù)字段，還是必須經(jīng)過(guò)研發(fā)和運(yùn)維共同協(xié)作的流程來(lái)進(jìn)行填充。

無(wú)法對(duì)更多的云資源進(jìn)行描述

K8s的原生API只包含了云資源的很少一部分，比如用 PV/PVC 表達(dá)存儲(chǔ)，用 Ingress 表達(dá)負(fù)載均衡，但這對(duì)于一個(gè)完全聲明式的應(yīng)用描述來(lái)說(shuō)是完全不夠的。比如，研發(fā)希望在K8s上找到一個(gè)概念來(lái)表達(dá)數(shù)據(jù)庫(kù)、VPC、消息隊(duì)列等需求的時(shí)候，就會(huì)感到非常困惑。而現(xiàn)有的所有方案則完全依賴于云廠商的實(shí)現(xiàn)從而帶來(lái)了新的 vendor lock-in 困惑。

Operator 體系缺乏互操作性

Kubernetes 的 Operator 機(jī)制是這個(gè)項(xiàng)目的能力能夠無(wú)限增長(zhǎng)的公開秘密。但令人遺憾的是，目前所有 Operator 之間的關(guān)系，就像是一個(gè)又一個(gè)的煙囪，互相之間沒有任何交互與協(xié)作的可能。比如，我們把云上的 RDS 通過(guò) CRD 和 Operator 擴(kuò)展到了 K8s 聲明式API的體系中，但是當(dāng)?shù)谌较Ｍ麑懸粋€(gè)定時(shí)備份 RDS 持久化文件的 CRD Operator去配合的時(shí)候，卻往往無(wú)從下手。這就又需要 DevOps 的體系介入來(lái)解決問(wèn)題。

未來(lái)？

顯然，現(xiàn)在的 Kubernetes 項(xiàng)目，依然需要借助 DevOps 體系來(lái)真正完成軟件的高效迭代與交付工作。這是不可避免的：盡管 Kubernetes 聲稱自己是“以應(yīng)用為中心”的基礎(chǔ)設(shè)施，但它作為一個(gè)從 Google Borg 衍生出來(lái)的系統(tǒng)級(jí)項(xiàng)目，其本身的設(shè)計(jì)和工作層次還是更多的基礎(chǔ)設(shè)施領(lǐng)域徘徊。但另一方面，我們絕不可否認(rèn)的是，Kubernetes 在它的關(guān)鍵路徑上，始終保持著對(duì)研發(fā)側(cè) “NoOps” 的追求。這種渴望，從它第一天提出“聲明式應(yīng)用管理”理論的時(shí)候就已經(jīng)“昭然若揭”，而 CRD 和 Operator 體系的建立，更讓這種應(yīng)用級(jí)別的關(guān)心終于有了落地的機(jī)會(huì)。我們已經(jīng)看到很多 DevOps 流程正在“下沉”為 Kubernetes 里的聲明式對(duì)象與控制循環(huán)，比如 Tekton CD 項(xiàng)目。

如果 Kubernetes 的未來(lái)是 100% 的聲明式應(yīng)用管理，那么我們有理由相信 DevOps 最終會(huì)從技術(shù)領(lǐng)域消失然后徹底蛻變成一種文化。畢竟，那個(gè)時(shí)候的運(yùn)維工程師，可能都會(huì)成為 Kubernetes Controller/Operator 的編寫者或者設(shè)計(jì)者。而研發(fā)呢？他們可能根本不會(huì)知道原來(lái) Kubernetes 這個(gè)東西曾經(jīng)如此顯赫的存在過(guò)。

OAM

在 2019 年 10 月，阿里云聯(lián)合微軟一起發(fā)布了開放應(yīng)用模型 Open Application Model(OAM)，打破了傳統(tǒng)的軟件交付模式，OAM 是專注于描述應(yīng)用生命周期的標(biāo)準(zhǔn)規(guī)范，可以幫助應(yīng)用開發(fā)者、應(yīng)用運(yùn)維人員和基礎(chǔ)架構(gòu)運(yùn)維團(tuán)隊(duì)更好地進(jìn)行協(xié)同。


目前，OAM 還處于一個(gè)早期階段，阿里巴巴團(tuán)隊(duì)正在上游貢獻(xiàn)和維護(hù)這套技術(shù)，如果大家有什么問(wèn)題或者反饋，也非常歡迎與我們?cè)谏嫌位蛘哚斸斅?lián)系。


參與方式：

• 釘釘掃碼進(jìn)入 OAM 項(xiàng)目中文討論群
  

• 通過(guò) Gitter 直接參與討論
  
• OAM 開源實(shí)現(xiàn)地址（star 一下！）

期待大家的參與！

云原生技術(shù)公開課

本課程是由 CNCF 官方與阿里巴巴強(qiáng)強(qiáng)聯(lián)合，共同推出的以“云原生技術(shù)體系”為核心、以“技術(shù)解讀”和“實(shí)踐落地”并重的系列技術(shù)公開課。

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)圈。”

總結(jié)

以上是生活随笔為你收集整理的Kubernetes 会不会“杀死” DevOps？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。