Kubernetes的下一站是什么？

Matt Asay

“乏味”（boring）是對基礎架構技術所能給予的最高贊譽之一。沒有人想要在“火辣時髦”的技術上運行關鍵任務應用程序。但如果是乏味的技術呢？那很好。

乏味表明一項技術的普遍性和可信度已到了某種程度，它廣為人知且易于管理。Kubernetes已部署在78%的企業的生產環境中，可以說已到了這個程度，已被廣泛認為是“切實可行”的支持云的標準底層技術。

或者換句話說，Kubernetes已變得“乏味”。

就在云原生計算基金會（CNCF）幫助協調其他一系列項目的開發，以填補Kubernetes在基礎架構層留下的任何空白之際，Kubernetes方面的對話已開始轉移到堆棧上層。今年4月，知名的開發者倡導者Kelsey Hightower表示，Kubernetes只解決了更新改造應用程序的一半問題：

“在基礎架構層‘更新改造應用程序方面投入了大量的努力，但是在應用程序層（想想框架和應用程序服務器）方面沒有同等的投入，我們只解決了一半問題。”

對此我們該怎么辦？

填補應用程序和基礎架構之間的空白

Lightbend的首席技術官兼聯合創始人Jonas Bonér在接受采訪時說：“基礎架構與構建完整應用程序之間存在巨大空白?！盉onér幫助啟動了開源項目Akka，該項目位于堆棧中的Kubernetes之上，旨在解決基礎架構和應用程序之間的一個復雜問題。正如Bonér所說：“程序員要做的實際工作就是填補這個巨大的空白，這就意味著為業務部門提供服務等級協議（SLA），這在分布式系統中很難實現，但應用程序層要充分利用Kubernetes及其生態系統，就需要這么做?！?/p>

Bonér繼續說，企業組織需要讓介于應用程序和基礎架構之間的系統完全切實可行。不是說關鍵在于替換任何系統，而是往工具箱添加更多工具，并將基礎架構隔離模型以及網絡施加的約束擴展到應用程序本身中——并以一種直觀、靈活、強大但又簡單的編程模型來提供。

正如特斯拉的兩名工程師在去年一次會議上所討論的，特斯拉依賴“數字孿生”功能支持其電網，這一切得益于Akka和Kubernetes的結合。特斯拉工程師Colin Breck說：“我們的大多數微服務在Kubernetes中運行，而Akka和Kubernetes可謂天作之合?！?/p>

他解釋道：“Kubernetes可以處理擴展方面的粗粒度故障，因此可以進行諸如增加或減少Pod、運行存活監測或以指數退避機制重啟失效Pod之類的操作。然后，我們使用Akka處理細粒度故障，比如斷路或重試單個請求，以及為單個實體的狀態（比如電池在充電或放電）建模。”

據Bonér聲稱，云原生堆棧上的Kubernetes方面仍存在3個尚未解決的領域，帶來了Akka等技術提供的新抽象：應用程序層組合、狀態性用例和傳輸中數據用例。

支持聲明式應用程序層組合

Bonér特別指出：“人們常常使用一套舊的工具、習慣和模式，它們通常源自傳統的（整體式三層）設計，這種設計抑制和約束了Kubernetes提供的云模型?！彼硎荆覀冃枰獙⑷萜?、服務網格和編排“非常好”的模型一直擴展到應用程序/業務邏輯，那樣我們可以在充分利用它的同時代表應用程序維護端到端保證。

無服務器技術指明了道路：它提高了抽象級別，并提供一種聲明式模型：平臺消除和管理盡可能多的樣板代碼、基礎架構和操作，從而使開發人員專心于核心方面：業務邏輯及工作流程。

改進對狀態性用例的支持

云生態系統的大部分主要處理所謂的類似12因素應用程序（12-factor）的應用程序，即無狀態應用程序。有時這可能正是你需要的。但重要的應用程序通常結合無狀態用例和狀態性用例。

Bonér說：“我們需要更多更好的工具來處理好狀態。如今，價值通常在于數據，通常在于蘊含大多數業務價值的狀態性用例——確保你可以快速訪問這些數據，同時確保正確性、一致性和可用性?！?/p>

在云中，除非有非常好的模型以及支持它的工具，否則會被迫回到三層架構：每次將所有內容推送到數據庫中，無論它用于狀態的通信、協調還是長期運行。

重要的是，你還需要良好的狀態模型來補充無狀態方法，從而為工具箱增添更多的選擇。Bonér特別指出，如今，Kubernetes處理狀態性用例的程度實際上僅在其StatefulSets功能中得到支持，但StatefulSets是為實施數據庫等基礎架構的人員設計的，而不是為應用程序開發人員設計的。

Bonér說：“因此，這里仍存在巨大空白。這是Akka真正發揮用場的地方?！?h3>處理快速數據或傳輸中數據用例

可以說，Kubernetes生態系統尚未為基于流和基于事件的用例提供強大支持。Bonér表示，像Istio這樣的服務網格是圍繞請求-響應模型設計的，“可能會擋路”。流也常常是狀態性的，各階段在內存中聚合數據，同時需要確?？捎眯?。Bonér表示，Knative社區正在竭力解決該問題，但我們剛邁出了一步。

推動業界邁向這些新方向的主力軍似乎是低代碼/無代碼/“前后端脫鉤”概念，這些概念為無服務器運動起到了推波助瀾的作用。

Bonér說：“無服務器使我們更有望解決將Kubernetes模型擴展到應用程序本身這個問題。這就是關鍵。盡可能地進行抽象，轉而使用一種聲明式配置模型，而不是編程模型，在該模型中你定義應該執行的操作，而不是定義如何執行。”

“切實可行”的應用程序基礎架構

隨著云原生堆棧繼續在Kubernetes基礎架構層上發展，應用程序層的這些概念如何實際服務于特定的語言開發人員還需拭目以待。雖然應用程序架構許多最棘手的挑戰長期以來一直是服務器端Java開發關注的點，但我們似乎正朝著Jamstack架構邁進：JavaScript開發人員日益要求訪問切實可行的應用程序基礎架構，尤其是當端點設備數量急劇增加時。

這倒不是說后端基礎架構不重要。正如Ian Massingham所言，這是承認前端開發人員的數量遠超過后端開發人員，這有其充分理由：需要構建的應用程序比需要為托管它們而創建的基礎架構多得多。通過Akka之類的開源項目在兩者之間架起橋梁變得越來越重要。

本文作者Matt Asay是亞馬遜網絡服務（AWS）的負責人。Asay以前是Adobe的開發者生態系統負責人。加盟Adobe之前，Asay在多家開源公司擔任過一系列職務。他是開源組織（OSI）的名譽董事會成員，擁有斯坦福大學法學博士學位，主要研究開源及其他知識產權（IP）許可問題。

原文網址

https：//www.infoworld.com/article/3567648/what-comes-after-kubernetes.html