AI時代，K8s還是企業敏捷開發的最好選擇么？答案是肯定。以生成式AI“鼻祖”OpenAI為例，其底層使用的調度平臺、計算平臺就是K8s（Kubernetes）。

Kubernetes業內簡稱K8s，是Google開源的一個容器編排引擎，它支持自動化部署、大規模可伸縮、應用容器化管理。在生產環境中部署一個應用程序時，通常要部署該應用的多個實例以便對應用請求進行負載均衡。

在Kubernetes中，企業可以創建多個容器，每個容器里面運行一個應用實例，然后通過內置的負載均衡策略，實現對這一組應用實例的管理、發現、訪問，而這些細節都不需要運維人員去進行復雜的手工配置和處理。

從“1”到“N”

回看K8s的發展史，它源自谷歌一個內部服務和應用——Borg，彼時，谷歌正在面臨著不斷增長的應用程序和愈發復雜的服務管理的痛點，于是創建了Borg系統，用于管理和運行谷歌的內部服務和應用。Borg采用了容器化的思想，將應用程序打包成容器并在集群中運行。

直到2014前后，Google將Borg的一部分經驗開源，推出了Kubernetes項目。Kubernetes最初是由Google、Red Hat、Microsoft等公司共同推動的，旨在為云原生應用提供一個開源的容器編排和管理平臺。

同時期，云原生概念問世，隨后，在2015年Google聯合Linux基金會成立了CNCF（云原生計算基金會），Kubernetes成為CNCF管理的首個開源項目。CNCF組織開始推廣云原生，并定義了云原生的三大支柱——容器化、微服務、DevOps。

而金融行業作為數字化轉型較早的行業之一，其數字化轉型初期的一大需求就是—滿足業務快速多變的需求，在此背景下，云原生技術因其快速、彈性的特點，開始引起金融機構的重視，并與原先金融機構的大集中架構融合，共同形成目前銀行IT系統的主流架構。

而這個過程中，K8s作為云原生容器化過程中的不二之選，受到了金融行業數字化轉型的青睞，而容器化也成為了金融行業數字化轉型最優先的“訴求”。對此，青云科技云原生產品負責人于爽表示，在2020年甚至更早以前，用戶的訴求很簡單——你幫我把容器用起來就行，“彼時，用戶對于微服務、敏捷等服務的訴求不大。”于爽指出。

時至今日，再看金融機構對于K8s的使用，以銀行為例，目前絕大多數銀行的內部結算系統都放在了K8s平臺上，“當下銀行對于容器化平臺的要求更高了，不僅要用起來，還要用得更好，”于爽進一步指出，“這也對云服務商提出了更高的要求，不止要容器化，還需要‘穩敏兼得’。”

這也意味著，K8s要實現用戶從只需要容器化到的“1”，到需要穩敏兼得、微服務.....“N”的轉變。

除此之外，用戶對于K8s平臺的差異化、定制化能力的要求也伴隨著其數字化程度逐漸顯現出來。于爽表示，以前用戶的需求更多的停留在“表面”上，平臺能有一個界面，能讓用戶使用K8s某個功能就足夠了，但現在不是這樣了，“現在用戶的需求逐漸變多，需要進行容器化改造，而這些深度的需求也呈現出兩極化發展。”于爽如是說。

一方面，用戶對于底層的基礎設施的大規模運維管理的穩定性提出了更高的要求，“無論是操作系統層面，還是異構硬件設備管理層面，用戶都希望能通過K8s實現統一納管，從而降低運維成本。”于爽指出。

另一方面，在上層，用戶圍繞數據庫的容器化、操作系統內核優化、災備和容災，以及穩定性等更深層的云原生需求。

以中國建設銀行為例，據了解，目前建行的數據庫資產已經全面K8s化了，這里面還包括了建行的核心數據庫資產。

AI時代，K8s也要“緊跟潮流”

如果把K8s比作一個人，那么它才剛剛步入成人的階段，一方面，已經K8s已經具備了足夠的技術成熟度，以及成熟的開源社區生態，并在很多行業、很多場景中得以應用；另一方面，K8s還有很多需要“學習”，進步的地方，比如在AI時代，企業AI應用落地的過程中，也對K8s平臺提出了新的需求。

在AI大模型問世以前，標準的K8s加上一些上層的管理能力，以及諸如微服務、敏捷的一些業務場景能力，就基本能滿足60%以上的云原生用戶的需求，但在AI時代，很多用戶涌現出了對于復雜工作負載管理的需求。于爽表示，“因為AI時代的工作負載，遠比原先基于K8s運行一個Web應用，或者一個后臺應用要復雜。尤其是在用戶如何通過可觀測的工具、調度工具，有效的解決他們的遇見的問題，滿足需求，這就對K8s的后臺管理能力和產品的復雜度提出了更高的要求。”

以可觀測方面為例，隨著AI應用開發的逐漸變多，對于K8s平臺的可觀測的規模也有了更大的要求，有些問題會隨著規模的上升而顯現出來，“目前來看500個節點、1000個節點已經算很大的了，但可能明年規模會翻一倍，到時候500節點、1000節點能解決的問題，在更大的規模下就無法解決了。”于爽強調。

另一方面，“觀測”行為對于IT環境的區別性和異構性也在AI時代與原先有了很大的差異。原先環境下，異構計算的占比相對而言比較少，而如今異構計算幾乎已經成為必需的存在，除此之外，企業為了不被同一廠商綁定，會在搭建IT環境時選擇不同廠商的產品和解決方案，每個硬件廠商自身的監控指標、驅動不盡相同，這對于可觀測來說是一個難題。

以青云科技為例，其解題思路是選擇當下比較主流的內核技術—eBFF框架，eBPF 技術的興起使得無侵入地對基礎設施和應用進行可觀測變得可行。這套框架可以以插件化的方式，可以無需侵入用戶應用，從內核感知不同的可觀測的數據，簡化用戶的配置和使用，”于爽進一步指出，“也能加強對AI 基礎設施 和 AI 應用的可觀測。”

可觀測也成為了AI時代，K8s平臺“跑”的更穩定、更安全的重要保障，“2025年，可觀測一定是K8s平臺主要優化的方向之一。”

除此之外，因為AI大模型訓練的負載通常是階段性的，因此對K8s平臺也提出了更高的彈性伸縮的能力要求，需要根據負載情況自動調整資源分配，確保AI應用的穩定性和可用性。企業也需要再開發的過程中，不斷優化資源調度算法，從而確保AI應用能夠優先獲得所需的計算資源，同時不影響其他應用的正常運行。

向更多應用場景延伸

顯然，AI時代，企業在開發的過程中，對于K8s的使用程度會越來越深，而K8s平臺也不再僅局限在金融行業可以“大展身手”。

從行業應用上看，目前除了金融行業以外，傳統制造業在建設數字工廠的過程中，也大多會采用K8s平臺作為底座，以此來快速提升工廠、底層運維等方面的標準化水平。

以某電池制造業龍頭企業為例，在使用K8s平臺之前，該企業有五個廠區采用物理機環境運行業務系統，各廠區之間缺乏統一管理，導致應用迭代只能依賴人工手動方式進行，無法實現自動化持續交付。此外，由于第三方供應商眾多且開發語言不統一，造成管理和集成困難。內部應用未配備高可用機制，而工廠生產線必須保持 24 小時不間斷運行，數據庫管理人員的缺失導致數據庫高可用性和維護性不足。

基于上述痛點，該企業采用了青云科技的 KubeSphere 容器平臺進行了升級，實現了應用系統全面容器化部署，提升應用系統的交付效率和彈性擴展能力，提供靈活、開放、敏捷的基礎設施服務。

并且，該企業基于KubeSphere平臺構建了企業級容器云平臺，在整合存量應用分布式微服務的同時，增量應用直接接入容器化平臺，打通各個廠區間的系統流通性，對各大廠區進行統一管理，顯著提升了廠區間協同效率與應用建設管理水平的同時，大幅提高業務定制化程度。

同時，通過數據庫的容器化，降低了運維壓力。使用RadonDB 數據庫產品提供了從創建、運維、監控、告警到備份的全生命周期數據庫管理方案，極大減輕了運維人員的工作負擔。

而制造業的案例僅僅是K8s平臺應用的“冰山一角”，政企、高校用戶也在逐漸增多。

在AI的浪潮下，越來越多的學校科研項目中開始應用AI大模型的能力輔助科研，高校師生對于開發平臺的各方面要求逐漸提升，“原先，高校可能應用虛擬化平臺就足夠支撐師生的科研項目，但隨著AI大模型的問世，今年以來，高校對于云原生的建設需求也在不斷涌現，”于爽指出，“而K8s也自然就成為了高校的重要IT 基礎設施。”

隨著用戶群體的不斷增加與變化，K8s平臺也需要具備更廣發的應用性，展望K8s在2025年的發展趨勢時，于爽表示，2025年，K8s平臺會向著三個方向演進，一是要提升可觀測性，讓K8s更穩定、更安全；二是要不斷優化跨基礎設施的集群管理，優化跨硬件、軟件、混合云等場景下的使用便捷度；三是，隨著邊緣AI的發展，在邊緣側的平臺部署和應用場景的發掘。（本文首發于鈦媒體APP，作者｜張申宇，編輯丨蓋虹達）

海量資訊、精準解讀，盡在新浪財經APP