Kubernetes 會不會「殺死」 DevOps？

做者丨孫健波（天元）  阿里巴巴技術專家

導讀：DevOps 這個概念最先是在 2007 年提出的，那時雲計算基礎設施的概念也纔剛剛提出沒多久，而隨着互聯網的逐漸普及，應用軟件的需求爆發式增加，軟件開發的理念也逐漸從瀑布模型（waterfall）轉向敏捷開發（agile）。

傳統的軟件交付模式（應用開發人員專一於軟件開發、IT 運維人員負責將軟件部署到服務器運行），再也沒法知足互聯網軟件快速迭代的需求。因而，DevOps 做爲一種打破研發和運維之間隔閡、加快軟件交付流程、提升軟件交付質量的文化理念和最佳實踐逐漸普及至今。

DevOps 的現狀

DevOps 的流行得益於業界對於應用軟件敏捷開發、高質量交付的訴求，因此爲開發和運維開闢了一塊「公共的空間」，讓雙方能夠在這裏緊密合做。那時軟件研發依舊屬於一個新興行業，人們習慣於向成熟的製造業學習，製造業解決大規模生產的方式，就是構建流水線，經過流水線規範化每一個步驟對接的內容，而流水線上的工人們則只須要各司其職，快速熟練的完成本身這部分生產內容。

因此，DevOps 借鑑了製造業的經驗，開始構建持續集成/持續交付（CI/CD）的流水線，催生出了一系列自動化/半自動化工具（如puppet、chef、ansible等），結合編寫腳本的可擴展能力，將研發和運維的大量操做規範化，從而達到彼此協做的目標。可是最終仍是要有人投入到這些工具的構建中，因而就出現了 DevOps 團隊。DevOps 團隊構建的工具和平臺，幫助研發更容易地接近生產環境，讓研發在持續集成、持續交付的過程當中能夠一鍵部署、快速試錯，從而很大程度提早暴露和避免了軟件在實際運行過程當中的問題。

從本質上講，DevOps是爲運維服務的。它把生產環境的運維流程經過自動化的工具提供出來了，屏蔽了基礎設施細節，同時讓軟件自己的問題更容易暴露，從而把這些問題儘可能提早交給研發去解決。這些，其實都是在幫助運維減輕負擔。

這一套模式在一開始運轉良好，可是問題也隨着時間的推移慢慢暴露出來了。DevOps 自己不爲企業帶來直接的利潤，也不增長產品的功能，它們是企業的成本中心，因此許多企業不肯意爲 DevOps 投入太多的成本。長此以往，DevOps 的能力便沒法與研發人員增加的需求所匹配，不肯意繼續伴隨着雲和開源社區的發展向前演進，反而成爲軟件研發的瓶頸。試想一下，有多少大公司的技術人員，對本身公司裏的「研發效能」工具表示滿意呢？

雲計算的普及

聰明的企業總能從本身的需求中發現業界共有的需求，AWS 即是這麼誕生的，他們早在 2006 年便首次把軟件部署須要的網絡、計算、存儲等基礎設施當作服務提供給用戶，容許任何人在不購買服務器等物理硬件的狀況下構建互聯網應用程序，規模化使得總體的成本比用戶自建更低。而云計算IaaS、PaaS、SaaS的概念也正是在那一年開始逐漸清晰的。

雲計算的初期，用戶主要使用的是IaaS服務，如虛擬機、存儲等，使用雲計算服務的企業依舊須要運維來管理這一類基礎設施，只是運維管理的對象從物理機切換到虛擬機而已，並無太本質的區別。

而隨着雲計算的快速發展，雲的能力不斷補充、加強，漸漸將原先由運維提供的方方面面的能力都轉換成爲了雲上的服務，這其中天然包含了管理軟件完整生命週期的各種服務，從代碼管理、持續集成、持續交付，到監控、報警、自動擴縮容等一系列的能力，均能在雲上找到對應的服務。品類之多、數量之巨，使人瞠目結舌。

可是 DevOps 依然有着用武之地。雲的對接難度實在太大了，涉及到的雲服務又多，不一樣雲廠商提供的服務還不統一，爲了使用雲上的產品不得不投入大量的時間學習，而爲了防止雲廠商的綁定又不得不作多廠商的適配，DevOps 依舊須要像過去同樣爲開發屏蔽實際環境的複雜性，只不過此次他們要負責管理的基礎設施變成了雲資源。

<a name="9f1631b1"></a>

改變一切的 Kubernetes

Kubernetes 的本質是現代應用基礎設施，它關注如何將應用與「雲」自然地集成在一塊兒，將「雲」的最大價值發揮出來。Kubernetes 強調讓基礎設施能更好的配合應用、以更高效的方式爲應用「輸送」基礎設施能力，而不是反之。在這個過程當中，Kubernetes 、Docker、Operator 等在雲原生生態中起到了關鍵做用的開源項目，正在在把應用管理與交付推上一個跟之前徹底不同的境況：Kubernetes 的使用者只經過聲明式的方式描述本身應用的終態是什麼，而後一切就結束了。Kubernetes 會處理後面的全部事情。

這也是爲何Kubernetes 很是強調聲明式API。經過這種方式，Kubernetes 自己接入的基礎設施能力越強，Kubernetes 的使用者可以聲明的終態就越豐富，他的職責也就約單純。如今，咱們不只可以經過 Kubernetes 聲明應用的運行終態，好比；「這個應用須要 10 個實例」，咱們還可以聲明應用的不少運維終態，好比：「這個應用使用金絲雀發佈策略進行升級」，以及 「當它的 CPU 使用量大於 50%時，請自動擴展 2 個實例出來」。

這就讓傳統的 DevOps工具和團隊受到了挑戰：若是一個業務研發本身只須要經過聲明式 API 聲明他的應用的全部終態甚至包括完整的 SLA，後面的一切就都會有 Kubernetes 來自動的搞定，那麼他還有什麼理由去對接和學習各式各樣的 DevOps 流水線呢？

換句話說，長久以來，DevOps 其實是在充當研發與基礎設施之間的那一層「膠水」。而如今，Kubernetes 經過它極具生命力的聲明式 API 和無限接入的應用基礎設施能力，正在完美的扮演這個「膠水層」的做用。這也提醒了咱們，上一個正在被 Kubernetes 體系強烈挑戰的「膠水層」，其實叫作「傳統中間件」：它正遭受到 Service Mesh 的巨大沖擊。

DevOps 會消失嗎？

近幾年，Kubernetes 項目常常被描述成 DevOps 的「最佳拍檔」。相似的觀點認爲， Kubernetes 跟 Docker 同樣，解決的是軟件運行時的問題。這意味着 Kubernetes 更像一種「時髦」的 IaaS，只不過運行時從虛擬機變成了容器。因此，只要可以將現有 DevOps 思想和流程對接到 Kubernetes 上來，就能夠享受到容器技術帶來的輕量級與彈性。這對於提倡「敏捷」的 DevOps 來講，顯然是最好的組合。

不過，至少目前看來，Kubernetes 的發展路徑並非一個類 IaaS 的角色。它雖然關注接入底層的基礎設施能力，但它自己卻又不是基礎設施能力的提供方。並且，相比於軟件運行時，Kubernetes 彷佛更關心軟件的生命週期和狀態流轉。不只如此，它還提供了一種叫作「控制器模型」的機制來將軟件的實際狀態與指望狀態不斷逼近，這顯然都已經超出了一個「軟件運行時」的範疇。

Kubernetes 項目對應用自己的「額外關注」，讓它與一個類 IaaS 基礎設施有着明顯的區別，也讓它「膠水」的定位更加明顯。而若是 Kubernetes 的能力足夠強大，那麼做爲研發與基礎設施之間現有的「膠水層」， DevOps 是否還有必要存在？在所謂的雲原生時代，應用研發與交付是否是真的會走向「一次聲明」就能夠「撒手無論」，從而讓 DevOps 完全消失呢？

不過，至少目前看來，Kubernetes 項目距離這個願景，還有很多困難須要克服。

「Platform for Platform」 API 的侷限性

Kubernetes 是一個典型的 「Platform for Platform」項目，因此它的 API，距離純研發視角仍是很是遙遠的。就好比一個 Deployment 對象，就既包括了研發側關心的鏡像，也包括了基礎設施側的資源配置，甚至是容器安全配置。此外， Kubernetes API 並無提供出對「運維能力」的描述與定義方式，這也使得聲明以後的「撒手無論」變得高不可攀。這也是爲何目前 DevOps 依然被須要的緣由：Kubernetes 的大多數字段，仍是必須通過研發和運維共同協做的流程來進行填充。

沒法對更多的雲資源進行描述

K8s的原生API只包含了雲資源的不多一部分，好比用 PV/PVC 表達存儲，用 Ingress 表達負載均衡，但這對於一個徹底聲明式的應用描述來講是徹底不夠的。好比，研發但願在K8s上找到一個概念來表達數據庫、VPC、消息隊列等需求的時候，就會感到很是困惑。而現有的全部方案則徹底依賴於雲廠商的實現從而帶來了新的 vendor lock-in 困惑。

Operator 體系缺少互操做性

Kubernetes 的 Operator 機制是這個項目的能力可以無限增加的公開祕密。但使人遺憾的是，目前全部 Operator 之間的關係，就像是一個又一個的煙囪，互相之間沒有任何交互與協做的可能。好比，咱們把雲上的 RDS 經過 CRD 和 Operator 擴展到了 K8s 聲明式API的體系中，可是當第三方但願寫一個定時備份 RDS 持久化文件的 CRD Operator去配合的時候，卻每每無從下手。這就又須要 DevOps 的體系介入來解決問題。

將來？

顯然，如今的 Kubernetes 項目，依然須要藉助 DevOps 體系來真正完成軟件的高效迭代與交付工做。這是不可避免的：儘管 Kubernetes 聲稱本身是「以應用爲中心」的基礎設施，但它做爲一個從 Google Borg 衍生出來的系統級項目，其自己的設計和工做層次仍是更多的基礎設施領域徘徊。但另外一方面，咱們毫不能否認的是，Kubernetes 在它的關鍵路徑上，始終保持着對研發側 「NoOps」 的追求。這種渴望，從它第一天提出「聲明式應用管理」理論的時候就已經「昭然若揭」，而 CRD 和 Operator 體系的創建，更讓這種應用級別的關心終於有了落地的機會。咱們已經看到不少 DevOps 流程正在「下沉」爲 Kubernetes 裏的聲明式對象與控制循環，好比 Tekton CD 項目。

若是 Kubernetes 的將來是 100% 的聲明式應用管理，那麼咱們有理由相信 DevOps 最終會從技術領域消失而後完全蛻變成一種文化。畢竟，那個時候的運維工程師，可能都會成爲 Kubernetes Controller/Operator 的編寫者或者設計者。而研發呢？他們可能根本不會知道原來 Kubernetes 這個東西曾經如此顯赫的存在過。

OAM

<br />在 2019 年 10 月，阿里雲聯合微軟一塊兒發佈了開放應用模型 Open Application Model(OAM)，打破了傳統的軟件交付模式，OAM 是專一於描述應用生命週期的標準規範，能夠幫助應用開發者、應用運維人員和基礎架構運維團隊更好地進行協同。

目前，OAM 還處於一個早期階段，阿里巴巴團隊正在上游貢獻和維護這套技術，若是你們有什麼問題或者反饋，也很是歡迎與咱們在上游或者釘釘聯繫。

參與方式：

• 釘釘掃碼進入 OAM 項目中文討論羣
  

• 經過 Gitter 直接參與討論
• OAM 開源實現地址（star 一下！）

期待你們的參與！

雲原生技術公開課

本課程是由 CNCF 官方與阿里巴巴強強聯合，共同推出的以「雲原生技術體系」爲核心、以「技術解讀」和「實踐落地」並重的系列技術公開課。

「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術圈。」