作者?| 張磊??阿里云高級技術專家、CNCF?官方大使，Kubernetes?項目資深成員和聯(lián)合維護者

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

前言

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

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

• 在這一年，在社區(qū)頭部參與者的持續(xù)推進下，“規(guī)模”與“性能”終于成為了 Kubernetes 項目的重要關鍵詞，這不僅真正意義上打通了 Kubernetes 在企業(yè)生產環(huán)境中大規(guī)模落地的最后一公里，也讓 Kubernetes 第一次成為了 “雙11” 等頂級互聯(lián)網(wǎng)規(guī)模化場景中實實在在的技術主角。

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

規(guī)模：Kubernetes 項目的新名片

如果要提名 2019 年的云原生技術演進的重要節(jié)點，那么“規(guī)模”一定是其中最當仁不讓的關鍵詞。

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

這個狀態(tài)，隨著 2019 年初頂級互聯(lián)網(wǎng)公司對 Kubernetes 社區(qū)的重量級投入而被打破。事實上，Kubernetes 本身的規(guī)模與性能優(yōu)化并不是一個“不可解”的問題，但是整個社區(qū)長期以來欠缺大規(guī)模場景和專門的工程力量投入，最終使得發(fā)現(xiàn)、診斷和修復整個容器編排與管理鏈路中各個性能障礙成了一個遙不可及的事情。

在這條關鍵鏈路當中， Kubernetes 的規(guī)模性問題又可以細分為：以 etcd 為代表的“數(shù)據(jù)面”、以 kube-apiserver 為代表“管控面”和以 kubelet 及各種 Controller 組成的“生產 / 消費面”三個問題域。在場景的推動下，Kubernetes 以及 etcd 社區(qū)在過去的一年里，正是圍繞這三個問題域進行了大量的優(yōu)化，例如：

• 數(shù)據(jù)面

通過優(yōu)化 etcd 底層數(shù)據(jù)庫的數(shù)據(jù)結構和算法，將 etcd 百萬鍵值對隨機寫性能提升 24 倍。

• 管控面

為 kube-apiserver 添加 Bookmark 機制，將 APIServer 重啟時需要重新同步的事件降低為原來的 3%，性能提高了數(shù)十倍。

• 生產 / 消費面

將 Kubernetes 節(jié)點向 APIServer 的心跳機制從“定時發(fā)送”修改為“按需發(fā)送”，從而大大減少了規(guī)模化場景下 kubelet 對 APIServer 帶來的巨大壓力，大幅提高了 Kubernetes 所能支持的節(jié)點數(shù)目上限。

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

這些 Kubernetes 規(guī)模與性能領域的“全鏈路優(yōu)化”工作，幾乎全部源自于真實的互聯(lián)網(wǎng)級規(guī)模化場景，而它們最終完成的得益于頂級開源社區(qū)的協(xié)同與所有參與者的共同努力。而規(guī)模化與性能問題的逐步解決不僅僅帶來了為 Kubernetes 項目帶來了充足的底氣，也正在迅速改變著整個基礎設施領域的基本格局。

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

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

云原生的本質與誤區(qū)

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

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

所以說，云原生并不指代某個開源項目或者某種技術，它是一套指導軟件與基礎設施架構設計的思想。這里關鍵之處在于，基于這套思想構建出來的應用和應用基礎設施，將天然能夠與“云”天然地集成在一起，將“云”的最大能力和價值發(fā)揮出來。

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

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

以應用為中心，是指導整個云原生生態(tài)和 Kubernetes 項目蓬勃發(fā)展至今的重要主線。

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

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

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

在過去，我們編寫一個應用所需要的基礎設施能力，比如，數(shù)據(jù)庫、分布式鎖、服務注冊 / 發(fā)現(xiàn)、消息服務等等，往往是通過引入一個中間件庫來解決的。這個庫，其實就是專門的中間件團隊為你編寫的服務接入代碼，使得你可以在不需要深入了解具體基礎設施能力細節(jié)的前提下，以最小的代價學習和使用這些基礎設施能力。這其實是一種樸素的“關注點分離”的思想。不過更確切的說，中間件體系的出現(xiàn)，并不單單是要讓“專業(yè)的人做專業(yè)的事”，而更多是因為在過去，基礎設施的能力既不強大、也不標準。這就意味著，假如沒有中間件來把這些的基礎設施細節(jié)給屏蔽掉、把接入方式統(tǒng)一掉，業(yè)務研發(fā)就必須“被迫營業(yè)”，去學習無數(shù)晦澀的基礎設施 API 和調用方法，對于“生產力就是一切”的研發(fā)同學來說，這顯然是不可接受的。

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

這個變化，正是云原生技術改變傳統(tǒng)應用中間件格局的開始。更確切的說，原先通過應用中間件提供和封裝的各種基礎設施能力，現(xiàn)在全都被 Kubernetes 項目從應用層“拽”到了基礎設施層也就是 Kubernetes 本身當中。而值得注意的是，Kubernetes 本身其實也不是這些能力的直接提供者， Kubernetes 項目扮演的角色，是通過聲明式 API 和控制器模式把更底層的基礎設施能力對用戶“暴露”出去。這些能力，或者來自于“云”（比如 PolarDB 數(shù)據(jù)庫服務）；或者來自于生態(tài)開源項目（比如 Prometheus 和 CoreDNS）。

這也是為什么 CNCF 能夠基于 Kubernetes 這樣一個種子迅速構建起來一個數(shù)百個開源項目組成的龐大生態(tài)的根本原因：Kubernetes 從來就不是一個簡單的平臺或者資源管理項目，它是一個分量十足的“接入層”，是云原生時代真正意義上的“操作系統(tǒng)”。

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

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

以應用為中心，使得 Kubernetes 從第一天開始，就把聲明式 API 、而不是調度和資源管理作為自己的立身之本。聲明式 API 最大的價值在于“把簡單留給用戶，把復雜留給自己”。通過聲明式 API，Kubernetes 的使用者永遠都只需要關心和聲明應用的終態(tài)，而不是底層基礎設施比如云盤或者 Nginx 的配置方法和實現(xiàn)細節(jié)。注意，這里應用的“終態(tài)”，不僅僅包括應用本身的運行終態(tài)，還包括了應用所需要的所有底層基礎設施能力比如路由策略、訪問策略、存儲需求等所有應用依賴的終態(tài)。

這，正是以“應用為中心”的切實體現(xiàn)。

**所以說，Kubernetes 并沒有讓中間件消失，而是把自己變成了一種“聲明式的”、“語言無關的”中間件，**這正是應用基礎設施能力“下沉”的真實含義。

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

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

在 2019 年，Service Mesh 生態(tài)取得了長足的進步，并且從原本 Istio 的絕對統(tǒng)治地位，來到了更接近于“諸侯爭鳴”的局面。畢竟，“中間件”這個生態(tài)，在過去也很難出現(xiàn)完全一家獨大的狀態(tài)，而 Google “一如既往”的宣布 Istio 項目暫時不捐贈給任何一個開源社區(qū)，其實也只是給這個趨勢增加一個推波助瀾的作用而已。其實，作為這波 Service Mesh 浪潮中應用基礎設施能力“下沉”的集大成者，Istio 項目已經(jīng)在跟 Kubernetes 項目本身產生越來越多的“局部沖突”（比如跟 kube-proxy 體系的關系）。在未來，具體某種“聲明式中間件”的能力是 Kubernetes Core 還是 Mesh 插件來提供，可能會有更多的爭論出現(xiàn)，而在這個過程中，我們也會看到 Istio 更多的“侵入”到 Kubernetes 的網(wǎng)絡甚至容器運行時層面當中，這將使得基礎設施變得越來越復雜、越來越“黑科技”化。

聲明式應用基礎設施的主旋律

所以一個不爭的事實是，Kubernetes 項目的其實會越來越復雜、而不是越來越簡單。

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

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

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

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

• 基礎設施工程師

在公司里，他們往往稱作“Kubernetes 團隊”或者“容器團隊”。他們負責部署、維護 Kubernetes 及容器項目、進行二次開發(fā)、研發(fā)新的功能和插件以暴露更多的基礎設施能力。他們是 Kubernetes 與容器領域里的專家，也是這個生態(tài)里的中堅力量。

• 運維工程師（含運維研發(fā)和 SRE）

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

• 業(yè)務研發(fā)工程師

當前的 Kubernetes 項目用戶中，業(yè)務研發(fā)的比重很小。他們本身對基礎設施并不感冒，但是也有可能被 Kubernetes 的“聲明式中間件”的能力被吸引，逐步接受了依賴 Kubernetes 提供的基礎設施原語來編寫和部署應用。

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

Serverless Infrastructure 方興未艾

自然的，Kubernetes 生態(tài)首先希望解決的是基礎設施工程師面對的復雜度。在這里聲明式 API 其實已經(jīng)幫了很大的忙，但是部署和運維 Kubernetes 本身還是一個挑戰(zhàn)。這正是類似 kubeadm 、kops 項目，以及 Kubernetes 托管項目和服務（比如 GKE，ACK，EKS 等）的重要價值點。

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

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

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

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

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

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

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

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

這里的本質問題在于，Kubernetes 項目的定位是“The Platform for Platform”，所以它的核心功能原語服務的對象是基礎設施工程師，而不是運維和研發(fā)；它的聲明式 API 設計、CRD Operator 體系，也是為了方便基礎設施工程師接入和構建新基礎設施能力而設計的。這就導致作為這些能力的使用者和終端受益者，運維工程師和業(yè)務研發(fā)實際上跟 Kubernetes 核心定位之間存在著明顯的錯位；而現(xiàn)有的運維體系和系統(tǒng)，跟 Kubernetes 體系之間也存在著巨大的鴻溝。

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

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

**當然，在這個過程中，這些插件就成了如何將 Kubernetes 與現(xiàn)有的運維體系進行對接和融合的關鍵所在。**比如：如何做應用原地升級、固定 IP，如何避免 Pod 被隨意驅逐，如何按照公司運維規(guī)范統(tǒng)一管理和發(fā)布 Sidecar 容器等等。在 2019 年 KubeCon 上海，自定義工作負載開源項目 OpenKruise 的發(fā)布，其實正是 Kubernetes 與現(xiàn)有運維體系成功對接的典型案例。一句話：在現(xiàn)代云原生技術體系當中，“運維能力”可以直接通過聲明式 API 和控制器模型成為 Kubernetes 基礎設施的一部分。所以在大多數(shù)情況下，其實并不需要一個運維 PaaS 的存在。

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

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

跟傳統(tǒng)中間件從業(yè)務研發(fā)視角出發(fā)不同，云原生乃至整個應用基礎設施“下沉”的革命，是從底向上開始的。它起始于 Google Borg/Omega 這樣比“云計算”還要底層的容器基礎設施構建理念，然后逐層向上透出“以應用為中心”的設計思想。出于基礎設施本身與生俱來的高門檻和聲明式應用管理理論被接納的速度，直到 2019 年，社區(qū)對 Kubernetes 體系的認識其實才剛剛從“類 IaaS 基礎設施”、“資源管理與調度”，堪堪上升到“以應用為中心的運維能力”的維度上來。

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

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

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

而對于業(yè)務運維來說，下一代“以應用為中心”的基礎設施，必須能夠從應用的視角對運維能力進行封裝和再發(fā)現(xiàn)，而不是直接讓運維人員去學習和操作各種底層基礎設施插件。**舉個例子，對于?kube-ovn?這樣一個 Kubernetes 網(wǎng)絡插件來說，運維人員拿到的不再是 kube-ovn 本身的使用文檔或者 CRD，而是這個插件能夠提供的一系列運維能力的聲明式描述，比如：“動態(tài) QoS 配置 CRD”、“子網(wǎng)隔離配置 CRD”。然后，運維人員只需要通過這些聲明式 API ，為某個應用綁定它所需要的動態(tài) QoS 和子網(wǎng)隔離的具體策略值即可。剩下的所有事情就全交給 Kubernetes 了。

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

在 2019 年 4 月，Google Cloud 發(fā)布了 Cloud Run 服務，第一次把 Serverless Application 的概念呈現(xiàn)給大眾。2019 年 9 月，CNCF 宣布成立應用交付領域小組，宣布將“應用交付”作為云原生生態(tài)的第一等公民。 2019 年 10 月，Microsoft 發(fā)布了基于 Sidecar 的應用中間件項目 Dapr ，把“面向 localhost 編程”變成了現(xiàn)實。

而在 2019 年 10 月，阿里巴巴則聯(lián)合 Microsoft 共同發(fā)布了?Open Application Mode（OAM）項目，第一次對“以應用為中心”的基礎設施和構建規(guī)范進行了完整的闡述。在 2019 年，我們已經(jīng)能夠切實感受到一場新的云計算革命正在興起。在這場革命的終態(tài)，任何一個符合“以應用為中心“規(guī)范的軟件，將能夠從研發(fā)而不是基礎設施的視角自描述出自己的所有屬性，以及自己運行所需要所有的運維能力和外部依賴。

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

總結

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

我們拭目以待。

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

總結

以上是生活随笔為你收集整理的解读容器 2019：把“以应用为中心”进行到底的全部內容，希望文章能夠幫你解決所遇到的問題。

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