作者 | 張磊  阿里雲高階技術專家、CNCF 官方大使，Kubernetes 專案資深成員和聯合維護者

在下一個十年交替之際，你是否知道，這個看似波瀾不驚的雲原生技術生態，又在孕育和經歷著哪些全新的變革呢？

前言

• 在這一年，這個生態具有標誌性意義的 KubeCon，史無前例的吸引到了一萬兩千人湧入聖地亞哥，整個會議的贊助商列表，多到一張十餘米長的巨幅海報才堪堪放下。

• 在這一年，Kubernetes 終於成為了廣受認可的基礎設施領域工業標準，而這個標準的確立，則以 AWS 的重量級投入畫上了圓滿的句號。

• 在這一年，在社群頭部參與者的持續推進下，“規模”與“效能”終於成為了 Kubernetes 專案的重要關鍵詞，這不僅真正意義上打通了 Kubernetes 在企業生產環境中大規模落地的最後一公里，也讓 Kubernetes 第一次成為了 “雙11” 等頂級網際網路規模化場景中實實在在的技術主角。

在下一個十年交替之際，你是否知道，這個看似波瀾不驚的雲原生技術生態，又在孕育和經歷著哪些全新的變革呢？

規模：Kubernetes 專案的新名片

如果要提名 2019 年的雲原生技術演進的重要節點，那麼“規模”一定是其中最當仁不讓的關鍵詞。

出於設計理念上的側重點考慮，Kubernetes 專案在過去乃至到 2019 年之前的很長一段時間內，也並不把“規模”作為整個專案演進的核心優先順序來對待。這裡的主要原因在於 Kubernetes 的設計思想是“以應用為中心”的基礎設施，所以相比於傳統作業編排排程管理專案（比如 Mesos 和 Yarn 等）關注的資源效能問題，Kubernetes 的核心競爭力則一直放在工作負載描述、服務發現、容器設計模式等更高緯度的應用基礎設施構建上。當然，另一方面的原因在於，對於 Kubernetes 服務提供商，比如 GKE 來說，他們對於規模與效能訴求也是比較有限的。

這個狀態，隨著 2019 年初頂級網際網路公司對 Kubernetes 社群的重量級投入而被打破。事實上，Kubernetes 本身的規模與效能優化並不是一個“不可解”的問題，但是整個社群長期以來欠缺大規模場景和專門的工程力量投入，最終使得發現、診斷和修復整個容器編排與管理鏈路中各個效能障礙成了一個遙不可及的事情。

在這條關鍵鏈路當中， Kubernetes 的規模性問題又可以細分為：以 etcd 為代表的“資料面”、以 kube-apiserver 為代表“管控面”和以 kubelet 及各種 Controller 組成的“生產 / 消費面”三個問題域。在場景的推動下，Kubernetes 以及 etcd 社群在過去的一年裡，正是圍繞這三個問題域進行了大量的優化，例如：

• 資料面

通過優化 etcd 底層資料庫的資料結構和演算法，將 etcd 百萬鍵值對隨機寫效能提升 24 倍。

• 管控面

為 kube-apiserver 新增 Bookmark 機制，將 APIServer 重啟時需要重新同步的事件降低為原來的 3%，效能提高了數十倍。

• 生產 / 消費面

將 Kubernetes 節點向 APIServer 的心跳機制從“定時傳送”修改為“按需傳送”，從而大大減少了規模化場景下 kubelet 對 APIServer 帶來的巨大壓力，大幅提高了 Kubernetes 所能支援的節點數目上限。

除此之外，在規模化 Kubernetes 落地的具體場景中，圍繞著上述三個問題域、在生產環境中經歷了充分驗證的規模與效能優化實踐也在 KubeCon 等技術演講中浮出水面。比如：如何讓多個 kube-apiserver 更均衡的處理生產 / 消費請求、避免效能熱點；如何通過合理的設定主備 Controller，讓升級 Controller 時無需大量重新同步資料，從而降低 controller 恢復時對 API Server 的效能衝擊等等。

這些 Kubernetes 規模與效能領域的“全鏈路優化”工作，幾乎全部源自於真實的網際網路級規模化場景，而它們最終完成的得益於頂級開源社群的協同與所有參與者的共同努力。而規模化與效能問題的逐步解決不僅僅帶來了為 Kubernetes 專案帶來了充足的底氣，也正在迅速改變著整個基礎設施領域的基本格局。

2019 年 5 月，Twitter 公司在舊金山總部正式宣佈 Twitter 的基礎設施將從 Mesos 全面轉向 Kubernetes。 這個新聞彷彿給當時略顯沉悶的技術社群裡扔進了一顆重磅炸彈一般，一時間傳言四起。

事實上，早在一年前，Twitter 公司的工程師就已經成為了灣區“大規模叢集管理小組（ CMWS， Cluster Mgmt at Web Scale）”裡的重要成員和分享常客。 CMWS 是一個專門針對大規模場景下的叢集管理問題而成立的閉門組織，其創始成員包括了阿里巴巴、Pinterest、Linkedin、Netflix、Google、Uber、Facebook、Apple 等一大批全球頂級技術公司。該小組成員會在每個月舉行閉門 Meetup，圍繞具體的議題進行深度技術分享和交流，推動小組成員更快更好的在網際網路場景中落地 Kubernetes 技術體系。眾所周知，出於規模和效能的考慮，灣區的網際網路公司一直以來都是 Mesos 專案的重度使用者，而此次 Twitter 的轉變，實際上只是 CMWS 小組成員中的一位而已。

雲原生的本質與誤區

儘管一路高歌猛進，但其實哪怕在 2019 年，還是有很多人對“雲原生”充滿了疑惑甚至誤解。這想必也是為何，我們一直能夠在不同的場合聽到關於雲原生的各種不同的定義。有人說，雲原生就是 Kubernetes 和容器；也有人說，雲原生就是“彈性可擴充套件”；還有人說，雲原生就是 Serverless；而後來，有人乾脆做出判斷：雲原生本身就是“哈姆雷特”，每個人的理解都是不一樣的。

實際上，自從這個關鍵詞被 CNCF 和 Kubernetes 技術生態“借用”之初，雲原生的意義和內涵，就是非常確定的。在這個生態當中，雲原生的本質是一系列最佳實踐的結合；更詳細的說，雲原生為實踐者指定了一條低心智負擔的、能夠以可擴充套件、可複製的方式最大化地利用雲的能力、發揮雲的價值的最佳路徑。

所以說，雲原生並不指代某個開源專案或者某種技術，它是一套指導軟體與基礎設施架構設計的思想。這裡關鍵之處在於，基於這套思想構建出來的應用和應用基礎設施，將天然能夠與“雲”天然地整合在一起，將“雲”的最大能力和價值發揮出來。

這種思想，以一言以蔽之，就是“以應用為中心”。

正是因為以應用為中心，雲原生技術體系才會無限強調讓基礎設施能更好的配合應用、以更高效方式為應用“輸送”基礎設施能力，而不是反其道而行之。而相應的， Kubernetes 、Docker、Operator 等在雲原生生態中起到了關鍵作用的開源專案，就是讓這種思想落地的技術手段。

以應用為中心，是指導整個雲原生生態和 Kubernetes 專案蓬勃發展至今的重要主線。

“下沉”的應用基礎設施能力與 Service Mesh

帶著這樣一條主線，我們回過頭來重新審視 2019 年雲原生生態的技術演進，會稍微清晰一些。

大家可能聽說過，在這次以 Kubernetes 為代表的基礎設施領域的演進過程中，總是伴隨著一個重要的關鍵詞，那就是應用基礎設施能力的“下沉”。

在過去，我們編寫一個應用所需要的基礎設施能力，比如，資料庫、分散式鎖、服務註冊 / 發現、訊息服務等等，往往是通過引入一箇中間件庫來解決的。這個庫，其實就是專門的中介軟體團隊為你編寫的服務接入程式碼，使得你可以在不需要深入瞭解具體基礎設施能力細節的前提下，以最小的代價學習和使用這些基礎設施能力。這其實是一種樸素的“關注點分離”的思想。不過更確切的說，中介軟體體系的出現，並不單單是要讓“專業的人做專業的事”，而更多是因為在過去，基礎設施的能力既不強大、也不標準。這就意味著，假如沒有中介軟體來把這些的基礎設施細節給遮蔽掉、把接入方式統一掉，業務研發就必須“被迫營業”，去學習無數晦澀的基礎設施 API 和呼叫方法，對於“生產力就是一切”的研發同學來說，這顯然是不可接受的。

不過，基礎設施本身的演進過程，實際上也伴隨著雲端計算和開源社群的迅速崛起。時至今日，以云為中心、以開源社群為依託的現代基礎設施體系，已經徹底的打破了原先企業級基礎設施能力良莠不齊、或者只能由全世界幾家巨頭提供的情況。

這個變化，正是雲原生技術改變傳統應用中介軟體格局的開始。更確切的說，原先通過應用中介軟體提供和封裝的各種基礎設施能力，現在全都被 Kubernetes 專案從應用層“拽”到了基礎設施層也就是 Kubernetes 本身當中。而值得注意的是，Kubernetes 本身其實也不是這些能力的直接提供者， Kubernetes 專案扮演的角色，是通過宣告式 API 和控制器模式把更底層的基礎設施能力對使用者“暴露”出去。這些能力，或者來自於“雲”（比如 PolarDB 資料庫服務）；或者來自於生態開源專案（比如 Prometheus 和 CoreDNS）。

這也是為什麼 CNCF 能夠基於 Kubernetes 這樣一個種子迅速構建起來一個數百個開源專案組成的龐大生態的根本原因：Kubernetes 從來就不是一個簡單的平臺或者資源管理專案，它是一個分量十足的“接入層”，是雲原生時代真正意義上的“作業系統”。

可是，為什麼只有 Kubernetes 能做到這一點呢？

這是因為， Kubernetes 是第一個真正嘗試以“應用為中心“的基礎設施開源專案。

以應用為中心，使得 Kubernetes 從第一天開始，就把宣告式 API 、而不是排程和資源管理作為自己的立身之本。宣告式 API 最大的價值在於“把簡單留給使用者，把複雜留給自己”。通過宣告式 API，Kubernetes 的使用者永遠都只需要關心和宣告應用的終態，而不是底層基礎設施比如雲盤或者 Nginx 的配置方法和實現細節。注意，這裡應用的“終態”，不僅僅包括應用本身的執行終態，還包括了應用所需要的所有底層基礎設施能力比如路由策略、訪問策略、儲存需求等所有應用依賴的終態。

這，正是以“應用為中心”的切實體現。

所以說，Kubernetes 並沒有讓中介軟體消失，而是把自己變成了一種“宣告式的”、“語言無關的”中介軟體，這正是應用基礎設施能力“下沉”的真實含義。

應用基礎設施能力“下沉”，實際上伴隨著整個雲原生技術體系和 Kubernetes 專案的發展始終。比如， Kubernetes 最早提供的應用副本管理、服務發現和分散式協同能力，其實就是把構建分散式應用最迫切的幾個需求，通過 Replication Controller，kube-proxy 體系和 etcd “下沉”到了基礎設施當中。而 Service Mesh ，其實就更進一步，把傳統中介軟體裡至關重要的“服務與服務間流量治理”部分也“下沉”了下來。當然，這也就意味著 Service Mesh 實際上並不一定依賴於 Sidecar ：只要能無感知的攔截下來服務與服務之間的流量即可（比如 API Gateway 和 lookaside 模式）。

隨著底層基礎設施能力的日趨完善和強大，越來越多的能力都會被以各種各樣的方式“下沉”下來。而在這個過程中，CRD + Operator 的出現，更是起到了關鍵的推進作用。 CRD + Operator，實際上把 Kubernetes 宣告式 API 驅動對外暴露了出來，從而使得任何一個基礎設施“能力”的開發者，都可以輕鬆的把這個“能力”植入到 Kubernetes 當中。當然，這也就體現了 Operator 和自定義 Controller 的本質區別：Operator 是一種特殊的自定義 Controller，它的編寫者，一定是某個“能力”對應的領域專家比如 TiDB 的開發人員，而不是 K8s 專家。遺憾的是當前的 Operator Framework 的發展並沒有體現出這個深層含義：太多的 K8s Controller 細節被暴露給了 Operator 的開發者，這是不對的。

在 2019 年，Service Mesh 生態取得了長足的進步，並且從原本 Istio 的絕對統治地位，來到了更接近於“諸侯爭鳴”的局面。畢竟，“中介軟體”這個生態，在過去也很難出現完全一家獨大的狀態，而 Google “一如既往”的宣佈 Istio 專案暫時不捐贈給任何一個開源社群，其實也只是給這個趨勢增加一個推波助瀾的作用而已。其實，作為這波 Service Mesh 浪潮中應用基礎設施能力“下沉”的集大成者，Istio 專案已經在跟 Kubernetes 專案本身產生越來越多的“區域性衝突”（比如跟 kube-proxy 體系的關係）。在未來，具體某種“宣告式中介軟體”的能力是 Kubernetes Core 還是 Mesh 外掛來提供，可能會有更多的爭論出現，而在這個過程中，我們也會看到 Istio 更多的“侵入”到 Kubernetes 的網路甚至容器執行時層面當中，這將使得基礎設施變得越來越複雜、越來越“黑科技”化。

宣告式應用基礎設施的主旋律

所以一個不爭的事實是，Kubernetes 專案的其實會越來越複雜、而不是越來越簡單。

更確切地說，“宣告式基礎設施”的基礎，就是讓越來越多的“複雜”下沉到基礎設施裡，無論是外掛化、介面化的 Kubernetes “民主化”的努力，還是容器設計模式，或者 Mesh 體系，這些所有讓人興奮的技術演進，最終的結果都是讓 Kubernetes 本身變得越來越複雜。而宣告式 API 的好處就在於，它能夠在基礎設施本身的複雜度以指數級攀升的同時，至少保證使用者的互動介面複雜度仍然以線性程度上升。否則的話，如今的 Kubernetes 恐怕早就已經重蹈了 OpenStack 的災難而被人拋棄。

“複雜”，是任何一個基礎設施專案天生的特質而不是缺點。今天的 Linux Kernel 一定比 1991 年的第一版複雜不止幾個數量級；今天的 Linux Kernel 開發人員也一定沒辦法像十年前那樣對每一個 Module 都瞭如指掌。這是基礎設施專案演進的必然結果。

但是，基礎設施本身的複雜度，並不意味著基礎設施的所有使用者都應該承擔所有這些複雜度本身。這就好比我們每一個人其實都在“使用” Linux Kernel，但我們並不會抱怨“Linux Kernel 實在是太複雜了”：很多時候，我們甚至並不知道 Linux Kernel 的存在。

為了更好的說明 Kubernetes 的“複雜性”問題，我們需要先闡述一下當前的 Kubernetes 體系覆蓋的三類技術群體：

• 基礎設施工程師

在公司裡，他們往往稱作“Kubernetes 團隊”或者“容器團隊”。他們負責部署、維護 Kubernetes 及容器專案、進行二次開發、研發新的功能和外掛以暴露更多的基礎設施能力。他們是 Kubernetes 與容器領域裡的專家，也是這個生態裡的中堅力量。

• 運維工程師（含運維研發和 SRE）

他們以及他們開發的工具和流水線（Pipeline），是保障關鍵業務穩定和正確執行的基石，而 Kubernetes 專案對他們來說，則是供給和研發運維能力的核心基礎依賴。理想情況下，運維工程師是 Kubernetes 專案的最重要使用者。

• 業務研發工程師

當前的 Kubernetes 專案使用者中，業務研發的比重很小。他們本身對基礎設施並不感冒，但是也有可能被 Kubernetes 的“宣告式中介軟體”的能力被吸引，逐步接受了依賴 Kubernetes 提供的基礎設施原語來編寫和部署應用。

上述三種使用群體在不同的公司內可能會有重合，而 Kubernetes 與生俱來的“複雜”，卻對上述三種使用者都有著深遠的影響。在 2019 年，雲原生生態也正在從上述三個角度出發，試圖解決 Kubernetes 複雜度對不同使用者帶來的問題。

Serverless Infrastructure 方興未艾

自然的，Kubernetes 生態首先希望解決的是基礎設施工程師面對的複雜度。在這裡宣告式 API 其實已經幫了很大的忙，但是部署和運維 Kubernetes 本身還是一個挑戰。這正是類似 kubeadm 、kops 專案，以及 Kubernetes 託管專案和服務（比如 GKE，ACK，EKS 等）的重要價值點。

另一方面，在幫助基礎設施工程師緩解複雜度問題的過程中，有一部分公有云提供商逐步發現了這樣一個事實：Kubernetes 工程師實際上也不希望關心更底層基礎設施比如網路、儲存、宿主機的細節和特性。這就好比一個電器工程師，怎麼會去關心發電廠裡的事情呢？

所以很多公有云提供商先後推出了 Serverless Kubernetes 的服務。這種服務保留了 Kubernetes 的 Control Plane，但是把 Kubernetes 中的 kubelet 元件、以及相應的網路、儲存等諸多 IaaS 相關概念去掉，然後用 Virtual Kubelet 專案把 Kubernetes Control Plane 直接對接到一個叫做 Serverless Container 的服務上來直接接入 IaaS 的能力。所謂 Serverless Container，實際上就是把虛擬機器以及相應的網路儲存等依賴，通過一個容器 API 暴露出來，比如 Microsoft 的 ACI，AWS 的 Fargate 以及阿里雲的 ECI。由於從使用者視角來看，他看到的效果是 Kubernetes 裡面的 Node 被去掉了，所以這種服務方式又被稱作“Nodeless”。

Nodeless 從 Kubernetes 中移除最讓人頭疼的節點和資源管理部分，所以它在使用上非常簡單，底層資源的問題也完全不必使用者操心，可謂省心省力無限彈性；而相應的折衷是 kubelet 的缺失會為 Kubernetes 的功能完整性打上折扣。

在 2019 年底，AWS 在 Re:Intent 大會上宣佈的 EKS on Fargate 服務之後，迅速在業界引起了巨大的反響。EKS on Fargate 的設計跟 Serverless Kubernetes 是類似的，主要差異點在於它並沒有使用 Virtual Kubelet 來直接去掉 Node 的概念，而是依然使用 kubelet 向 Fargate 服務申請 EC2 虛擬機器當 Pod 用，從而更好的保留了 Kubernetes 功能完整度。這種方式，我們可以稱作 Serverless Infrastructure，即：一個不需要關心底層基礎設施細節的 Kubernetes。

實際上，在 2019 年中旬，阿里就已經在 Kubernetes 社群提出了 Virtual Cluster 架構。它的核心思想是，在一個“基礎 Kubernetes 叢集（元叢集）”上，可以“虛擬出”無數個完整的 Kubernetes 叢集來給不同的租戶使用。可以看到，這個思路跟 EKS on Fargate 的設計不謀而合但走的更遠：Fargate 目前需要通過 EC2 虛擬機器和對應的虛擬機器管控系統來實現容器執行時的隔離，而 Virtual Cluster 則直接通過 KataContainers 使得所有租戶可以安全的共享同一個宿主機，從而大大提高了資源利用率（這也正是 KataContainers 最大的魅力所在）。不過，相信很快 EKS on Fargate 也會通過 Firecracker 逐步走向 Virtual Cluster 架構。與 Virtual Cluster 類似的另一個商業產品，就是 VMware 的 Project Pacific：它通過“魔改” kubelet，在 vSphere 之上實現了“虛擬出” 租戶 Kubernetes 叢集的目的。

作為開源界的 EKS on Farge 和 Project Pacific，Virtual Cluster 目前是 Kubernetes 上游多租工作組的核心孵化專案並且已經進行過多次 PoC，非常值得關注。

構建 “以應用為中心”的運維體系

從 Nodeless 到 Virtual Cluster，2019 年的雲原生生態正在全力以赴的解決基礎設施工程師的煩惱。不過，更加重要的運維工程師和業務研發所面臨的問題，卻似乎一直被忽視至今。要知道，他們其實才是抱怨“Kubernetes 複雜”的主要群體。

這裡的本質問題在於，Kubernetes 專案的定位是“The Platform for Platform”，所以它的核心功能原語服務的物件是基礎設施工程師，而不是運維和研發；它的宣告式 API 設計、CRD Operator 體系，也是為了方便基礎設施工程師接入和構建新基礎設施能力而設計的。這就導致作為這些能力的使用者和終端受益者，運維工程師和業務研發實際上跟 Kubernetes 核心定位之間存在著明顯的錯位；而現有的運維體系和系統，跟 Kubernetes 體系之間也存在著巨大的鴻溝。

為了解決這個問題，很多公司和組織落地 Kubernetes 的時候實際上採用了“ PaaS 化”的思路，即：在 Kubernetes 之上再構建一個 PaaS 系統，通過 PaaS API（或者 UI）把 Kubernetes 跟業務運維和業務研發隔離開來。這樣做的好處在於，Kubernetes 的基礎設施能力真的就變成了“基礎設施”：業務運維和研發真正學習和使用的是這個 PaaS，Kubernetes 的“複雜性”問題也迎刃而解了。

但這種做法從本質上來說，其實跟 Kubernetes “以應用為中心”的設計是不一致的。Kubernetes 一旦退化成了“類 IaaS 基礎設施”，它的宣告式 API、容器設計模式、控制器模型就根本無法發揮出原本的實力，也很難接入到更廣泛的生態。在 Kubernetes 的世界裡，傳統 PaaS 提供的各項能力比如 CI/CD、應用打包託管、釋出擴容，現在都可以通過一個個的 CRD Controller 的方式作為外掛部署在 Kubernetes 當中，這跟應用基礎設施“下沉”的過程其實是類似的。

當然，在這個過程中，這些外掛就成了如何將 Kubernetes 與現有的運維體系進行對接和融合的關鍵所在。比如：如何做應用原地升級、固定 IP，如何避免 Pod 被隨意驅逐，如何按照公司運維規範統一管理和釋出 Sidecar 容器等等。在 2019 年 KubeCon 上海，自定義工作負載開源專案 OpenKruise 的釋出，其實正是 Kubernetes 與現有運維體系成功對接的典型案例。一句話：在現代雲原生技術體系當中，“運維能力”可以直接通過宣告式 API 和控制器模型成為 Kubernetes 基礎設施的一部分。所以在大多數情況下，其實並不需要一個運維 PaaS 的存在。

但是，即使做到了“運維能力”雲原生化這一點，“以應用為中心”的基礎設施其實也才剛剛起步。

把“以應用為中心”進行到底

跟傳統中介軟體從業務研發視角出發不同，雲原生乃至整個應用基礎設施“下沉”的革命，是從底向上開始的。它起始於 Google Borg/Omega 這樣比“雲端計算”還要底層的容器基礎設施構建理念，然後逐層向上透出“以應用為中心”的設計思想。出於基礎設施本身與生俱來的高門檻和宣告式應用管理理論被接納的速度，直到 2019 年，社群對 Kubernetes 體系的認識其實才剛剛從“類 IaaS 基礎設施”、“資源管理與排程”，堪堪上升到“以應用為中心的運維能力”的維度上來。

當然，這次“以應用為中心”的技術革命，一定不會在“運維”這個節點就戛然而止。那麼接下來呢？

實際上，宣告式 API 和控制器化，是將底層基礎設施能力和運維能力接入 Kubernetes 的手段但並非目的。Kubernetes 打造“以應用為中心”的基礎設施真正希望達成的目標，是讓”應用“變成基礎設施中的絕對主角，讓基礎設施圍繞“應用”構建和發揮作用，而不是反之。

具體來說，在下一代“以應用為中心”的基礎設施當中，業務研發通過宣告式 API 定義的不再是具體的運維配置（比如：副本數是 10 個），而是“我的應用期望的最大延時是 X ms”。接下來的事情，就全部會交給 Kubernetes 這樣的應用基礎設施來保證實際狀態與期望狀態的一致，這其中，副本數的設定只是後續所有自動化操作中的一個環節。只有讓 Kubernetes 允許研發通過他自己的視角來定義應用，而不是定義 Kubernetes API 物件，才能從根本上的解決 Kubernetes 的使用者“錯位”帶來的各種問題。

而對於業務運維來說，下一代“以應用為中心”的基礎設施，必須能夠從應用的視角對運維能力進行封裝和再發現，而不是直接讓運維人員去學習和操作各種底層基礎設施外掛。**舉個例子，對於 kube-ovn 這樣一個 Kubernetes 網路外掛來說，運維人員拿到的不再是 kube-ovn 本身的使用文件或者 CRD，而是這個外掛能夠提供的一系列運維能力的宣告式描述，比如：“動態 QoS 配置 CRD”、“子網隔離配置 CRD”。然後，運維人員只需要通過這些宣告式 API ，為某個應用繫結它所需要的動態 QoS 和子網隔離的具體策略值即可。剩下的所有事情就全交給 Kubernetes 了。

這樣，在底層基礎設施層逐漸 Serverless 化、運維能力也越來越多的接入到 Kubernetes 體系當中之後，雲原生的下一站將會繼續朝著“把以應用為中心進行到底”的方向不斷邁進。

在 2019 年 4 月，Google Cloud 釋出了 Cloud Run 服務，第一次把 Serverless Application 的概念呈現給大眾。2019 年 9 月，CNCF 宣佈成立應用交付領域小組，宣佈將“應用交付”作為雲原生生態的第一等公民。 2019 年 10 月，Microsoft 釋出了基於 Sidecar 的應用中介軟體專案 Dapr ，把“面向 localhost 程式設計”變成了現實。

而在 2019 年 10 月，阿里巴巴則聯合 Microsoft 共同釋出了 Open Application Mode（OAM）專案，第一次對“以應用為中心”的基礎設施和構建規範進行了完整的闡述。在 2019 年，我們已經能夠切實感受到一場新的雲端計算革命正在興起。在這場革命的終態，任何一個符合“以應用為中心“規範的軟體，將能夠從研發而不是基礎設施的視角自描述出自己的所有屬性，以及自己執行所需要所有的運維能力和外部依賴。

這樣的應用才能做到天生就是 Serverless Application：它可以被“自動匹配”到任何一個滿足需求的“以應用為中心”的執行平臺上去執行，我們不再需要關心任何基礎設施層面的細節和差異性。

總結

2019 年，在 Kubernetes 技術體系的規模性問題逐漸解決之後，整個雲原生生態正在積極的思考和探索如何達成雲原生技術理念“以應用為中心”的最終願景。而從 Serverless Infrastructure 到 Serverless Application，我們已經看到雲原生技術棧正在迅速朝“應用”為中心聚攏和收斂。我們相信在不久的未來，一個應用要在世界上任何一個地方執行起來，唯一要做的，就是宣告“我是什麼”，“我要什麼”。在這個時候，所有的基礎設施概念包括 Kubernetes、Istio、Knative 都會“消失不見”：就跟 Linux Kernel 一樣。

我們拭目以待。

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