進入 21 世紀後，虛拟機技術進入相對成熟階段，由于虛拟機的“笨重”，開發者們開始追求一種更加輕便的虛拟化技術。2010 年，由 NASA 和 Rackspace 聯合開發的開源平台 OpenStack 誕生，幫助服務商和企業實作雲基礎架構服務。它将開源、開放的思想帶到了雲原生領域，并為雲原生發展掀開了新篇章。
2020 年，OpenStack 基金會更名為開放基礎設施基金會 OIF，OpenStack 從“雲”拓展到了“開放基礎設施”。
緊接着，OpenStack 從最初的虛拟化管理 Nova 和對象存儲 Swift ，逐漸發展到包含虛拟化管理、SDN、SDS 服務編排和容器管理等功能覆寫全面的開源項目集合。同時緊跟雲原生技術演進潮流，與容器、Kubernetes、AI 相關的更多開源技術緊密合作。2021 年 11 月，OIF 基金會宣布了開放基礎設施的新标準 LOKI —— Linux、OpenStack、Kubernetes 等組成的開放基礎設施管理軟體。
在今年 4 月，OIF 釋出了 OpenStack Yoga 版本，并宣布，待下一個被稱為終結者的 Zed 版本釋出之後，OpenStack 将以穩定的狀态成為企業IT的生産級工具。這意味着雲原生逐漸進入後OpenStack 時代，2017 年起，各大雲廠商都陸續開始包裝和提供容器的商業化服務，提供基于 Kubernetes 的商業服務産品，容器技術逐漸走向成熟和标準化、商業化，成為虛拟化的新代表産品，圍繞容器發展的雲原生逐漸走向普适的階段，已經應用容器的企業正在進行着雲原生的新一輪技術演進。
一、後 OpenStack 時代的 Kubernetes ：從“解決難用”到“用的好”
數字化轉型的加速增加了企業對于雲原生的需求，容器技術覆寫率提高，IDC預測，容器軟體市場在近幾年呈爆發式增長，并且未來五年仍然會保持超過 40% 的複合增長率。
進而，企業對容器管理的需求會直線提升，容器管理成為企業數字化轉型的主戰場。據 Gartner 預測，到 2025 年，成熟經濟體中 85% 的大型企業将更多地使用容器管理。
如今在大多企業的業務場景中，企業組織需要確定多個容器可同時協同工作，這方面的工作大部分都是又編排引擎完成。随着 Kubernetes 的興起與演進，目前已經克服了容器編排過程中許多技術挑戰。
或許因為 Kubernetes 想要解決的問題太多，是以導緻其複雜度很高，于是不少企業也在應用其他容器管了解決方案。然而市場資料證明，Kubernetes 依舊是大多企業的選擇。CNCF 最近的一份報告顯示，Kubernetes 在全球已擁有近 600 萬個企業使用者，成為雲上應用程式主要的部署模式。
盡管 Kubernetes 覆寫率高，但這也并不意味着已經在應用它的使用者滿意，常被吐槽“難用但還很需要”。在 Kubernetes 的實際使用過程中，經常會遇見一些“難用”問題，比如建立容器時間過長、低吞吐量/ RPS /突發并發、容器擴充速度慢、叢集擴充速度慢、Sidecar 資源開銷、資源使用率低等，為此，英特爾提出了創新的“SW+HW 功能解析”解決方案，開發工作主要集中在資源編排（Orchestration）和可觀測行（Observability）兩方面：
基于快照+熱代碼塊來建立容器；
- 分片式多排程器；
- 彈性 POD 的自動擴充；
- 基于遙測的快速預測，用于實時擴充的決策；
- 動态插入/删除 POD 中的 Sidecar 容器；
- 連結裝置的親和排程/配置設定(NUMA, GPU+Smart NIC 等)；
- 實時 “節點資源變化” 回報給 Kubernetes 排程器。
以上提到的這些技術都符合 Kubernetes 的 API 規範并可與現有的 API 相容，確定使用者在不修改已有 Kubernetes 代碼的情況下便能安裝使用。為了友善使用者測試、評估這些技術，英特爾還直接提供了容器鏡像的方式讓使用者可以通過Operator等标準的 Kubernetes 應用部署方法來安裝部署。
解決完容器“難用”問題，就要接着考慮如何“用得好”的問題。“用的好”的前提是選對架構。在後 OpenStack 時代，企業使用雲原生架構的目的是追求靈活、彈性、高性能和效率。要想達到這些目的，單純依靠軟體層面的優化是不夠的，以Serverless為例，很多部署中會出現的問題，比如函數冷啟動等，都需要通過硬體層面的優化來解決。
随着資料逐漸擴散至邊緣場景，越來越多的企業期望通過雲原生架構實作雲邊端一體化協同的基礎設施，英特爾一直在為此做出努力，聚焦企業發展不同階段的不同需求，針對性提出架構優化方案。
其次，企業部分廣泛存在的AI訴求也對“用得好”提出了挑戰。如今幾乎每個應用功能都離不開 AI，然而 AI 模型從開發進入到生産部署階段面臨着多重困難和挑戰。一般而言，AI 模型需要經過大量的調試和測試，通常需要 2-3 天才能部署上線；而且 AI 線上服務計算資源通常較固定，對于突發需求資源響應慢，又面臨着業務擴充難的問題。
作為雲原生的核心技術， Kubernetes 能夠管理雲平台中多個主機上的容器化應用，能夠完成 AI 資源的統一部署、規劃、更新、維護，有效提高 AI 資源管理率。此外，在基于 Kubernetes 的 AI 開發平台建設實踐中，使用 CPU 伺服器可有效利用空置資源、空閑時間，并通過 Kubernetes 的彈性資源排程配置設定給其它應用。而且 CPU 作為通用算力提供者，在采購成本、使用難度等方面有着重要優勢，不僅支援 AI 運算，還可用于其他應用負載。
在 Kubernetes 釋出初期，針對 CPU 和記憶體的管理與配置設定做的比較簡單，随着新版本的釋出，逐漸有一些新的功能加進來（如 CPU Manager、Topology Manager 等），但 Kubernetes 預設的 CPU Manager、Topology Manager 仍無法了解伺服器級硬體的複雜内部架構和 CPU 本身的能力，這就可能會導緻 CPU 的資源配置設定決策和計算性能無法達到最優。對于英特爾® 至強® 可擴充處理器來說，其架構複雜、功能強大，如果想要在上面部署 Kubernetes 叢集來高效支撐雲業務，就需要對其拓撲結構和 CPU 的強大功能暴露給 Kubernetes叢集，這時英特爾® CRI-RM 是以而生。
在英特爾研發團隊的不懈努力下，如今英特爾® CRI-RM 助力下的 CPU 在 AI 場景中能夠更顯威力。英特爾® CRI-RM 是英特爾初創的一個開源項目，其目的是通過在節點上的動态劃分系統資源，配合 Kubernetes 排程器，實作在節點層面上的最優任務編排，把英特爾平台的特性完美的适配到 Kubernetes 的叢集環境裡。
浪潮在 AIStation V3 中應用了英特爾® CRI-RM 元件，該元件可以插在 Kubelet 和 CR 之間，截取來自 Kubelet CRI 協定的請求， 扮演 CR 的非透明代理，跟蹤所有叢集節點容器狀态，能夠更好 地将處理器、記憶體、IO 外設、記憶體控制器等資源配置設定給應用負載。在 Tensorflow 等測試用例中，這一優化被證明能夠實作高達 57.76% 的性能提升。這意味着在未對硬體配置進行更新的前提下，CRI-RM 的應用會帶來大幅度的性能提升，使得使用者無需在進行硬體投入便能夠獲得可觀的 AI 訓練性能提升，進而提高基礎設施的利用效率，并節約了總體擁有成本。
通過浪潮的實踐，我們基本就能夠看出，英特爾的軟體開發和創新的起點就是充分利用硬體資源潛能來優化應用，加速應用負載使其在英特爾平台上以達到更好的開發和使用者體驗。又比如 QAT 加速卡，在雲原生領域的各種網絡傳輸子產品中，它便有效提速了安全加解密（TLS）和壓縮/解壓縮的處理性能，進而幫助軟體獲得更好的性能。
二、企業當下需要的是“一站式”容器解決方案
用過 OpenStack 的人都知道，版本更新是 OpenStack 商業化應用的最大痛點。每年兩次版本更新令企業真的有點吃不消，舊作業系統無法滿足新版本的更新需求，使用者輕易不敢進行更新。雖然說 OpenStack 将在 Zed 版本之後，從“A”開始重新命名，每年兩次大版本更新改為每年一次大版本更新，但這依舊滿足不了如今企業在數字化轉型過程中上雲的需求。
随着技術發生變革，使用者需要的是一套能從産品端到服務端的一站式解決方案來滿足需求。因為這些需求的存在，越來越多的團隊會基于 Kubernetes 建構上層抽象，增加更多的擴充能力，以“應用”為中心建構高可擴充的雲原生平台。
比如青雲科技開源的KubeSphere項目，在 Kubernetes 之上建構的面向雲原生應用的分布式作業系統，完全開源，支援多雲與多叢集管理，提供全棧的 IT 自動化運維能力，簡化企業的 DevOps 工作流。它的架構可以非常友善地使第三方應用與雲原生生态元件進行“即插即用”的內建。此外，KubeSphere 還開源了 KubeKey 幫助企業一鍵在公有雲或資料中心快速搭建 Kubernetes 叢集，提供單節點、多節點、叢集插件安裝，以及叢集更新與運維。
基于對企業使用者的需求洞察，青雲科技在發展 KubeSphere 的社群的同時，還圍繞 KubeSphere 這一核心産品開發了企業級容器平台—— KubeSphere 企業版。目前已經在金融、營運商、工業、教育、能源、交通物流、零售電商和政府等行業積累了大量成功經驗。像中金蒼穹容器平台、易方達基金 PaaS 平台、雲天化集團容器雲平台、中移金科容器雲平台都是 KubeSphere 企業版的優秀實踐。
為了真正幫助企業更好地落地雲原生應用場景，青雲科技廣泛聯合雲原生生态體系各層面合作夥伴，打造開放共生的雲原生生态圈。硬體層面的生态合作是其中重要的一部分，因為在目前的雲原生生态環境下，雲原生容器化平台上的軟體應用效率和硬體技術之前的關系更加緊密，其運作更需要調動硬體的加速能力。于是擁有獨特硬體黑科技優勢的英特爾成為了青雲科技的合作夥伴，為 KubeSphere 企業版提供了許多支援。
英特爾幫 KubeSphere 企業版實作了網絡功能增強，通過開發并開源 Multus 的 CNI 插件、提供“将多個接口添加到 Pod”的功能，成功解決了因 Kubernetes 缺乏支援多個網絡接口能力，而受制于單一網絡解決方案的企業使用者的需求。如今的 KubeSphere 企業版在優化後的 Intel Multus 解決方案的助力下，實作了更強大、更多元的網絡管理和擴充能力，支援使用者在建立應用負載時可以自定義選擇多塊網卡，同時支援網卡資源池管理。
圖：應用負載選擇多網卡
此外，為了檢測 Kubernetes Cluster 中每個 Node 的特性能力，英特爾還開發了 NFD（Node Feature Discovery），而 KubeSphere 企業版深度內建了 NFD，使其節點管理得到增強。KubeSphere 企業版通過把節點更詳細的 Label 發送到 KubeSphere 企業版 Master Scheduler 之上，應用負載獲得了更精準的排程，使其更充分地利用硬體資源。
圖：測試結果-Node Feature Discovery啟動成功
另外值得一提的是，CPU Manager 給 KubeSphere 企業版帶來的性能提升表現十分亮眼。當我們測試部署不同的 Redis pod 會發現，開啟 CPU Manager 後的 Redis 的讀寫性能與開啟前的讀寫性能相比，Redis 性能最高可以提升超過 9%。
圖：Redis 性能測試圖
三、容器好用，但也需要“注意安全”
虛拟化技術突破了作業系統與實體硬體的局限，在異構資源整合、集中管理、提高硬體使用率等方面具有很強的優勢，但這同時也增加了發生系統安全問題的機率，虛拟化的安全直接影響着雲原生架構的安全，間接影響着企業數字化轉型成果及業務發展。
作為雲原生虛拟化常用的技術，容器确實好用，但是容器安全問題也一直是行業内備受诟病的問題。傳統的容器基于 NameSpace 和 Cgroup 進行隔離，在帶來輕量簡潔的同時，也帶來了許多安全隐患。容器作為一種相對于虛拟機來說更加輕量的虛拟化技術，容器雖然能夠提供一個與系統中其他程序資源相隔離的執行環境，但還是與主控端系統共享核心的，很容易因為隔離性不足而産生安全隐患。尤其是在多租戶的場景下，一旦容器裡的應用逃逸到核心，後果将不堪設想。
據 Red Hat 公司調查資料顯示：有 94% 的受訪者在過去 12 個月内遭遇過 Kubernetes 安全事件。而 Akamai 日前也進行了一項實驗，将一個簡單的 Docker 容器蜜罐用于攻擊測試，結果顯示該容器在 24 小時内被攻擊者用于四起不同的犯罪活動。這些資料都在告訴我們，解決企業容器安全問題刻不容緩。
是以很多廠商在建構企業級容器管理平台時都會着重考慮容器安全問題，像我們剛剛提到的KubeSphere 企業版，它的一大亮點就是“安全加強”。在英特爾容器解決方案加持下的 KubeSphere 企業版，深度內建了 Kata Containers，使用者可以在建立符合自身業務需求的運作時，通過 KubeSphere 企業版的管理頁面進行統一管理。
圖：一鍵選擇Kata
Kata Containers 的核心亮點就是采用輕量級虛拟化作為容器的隔離，使得它兼具容器的速度和虛拟機的安全隔離，這一點解決了長期以來困擾容器發展的安全隔離性不足問題，大大促進了雲原生的發展。
作為符合 OCI 标準的輕量級 VM，可無縫地與 Docker 及 Kubernetes 對接。Kata Containers 運作的應用負載具備獨立核心，同時借助英特爾® VT 技術，具備其他輕量級 VM 所不具備的優異性能。它整合了英特爾的 Clear Containers 和 Hyper.sh 的 runV，在能夠充分利用英特爾® 架構平台性能優勢的同時，還支援其他架構的硬體。
Kata Containers 的隔離原理就是在請求建立容器執行個體時，首先啟動一個輕量化虛拟機，然後将容器鏡像挂載到虛拟機裡，進而在這個虛拟機裡啟動和運作這個容器應用程式。其本質是一個虛拟機執行個體，但拉起虛拟機的過程和運作在虛拟機裡這個事實對使用者是透明的，這種方式并不改變使用者使用容器的習慣。
Kata containers 可以被用在很多場景，目前雲服務提供商 CSP 們的使用場景主要包括安全容器執行個體服務、容器運作時的業務隔離等。感興趣的開發者可以參閱公開的應用案例集： 目前 Kata Containers 2.0 已經釋出，社群正在醞釀 Kata Containers 3.0 的規劃和開發，其主要開發方向将聚焦于優化性能、加強安全、提高可用性和穩定性方面。
另外，一個基于 Kata Containers 的典型用例也十分值得大家去了解——機密容器 （Confidential containers），它是一個基于硬體TEE的技術方案，目前是 CNCF 的沙箱項目。機密容器是機密計算（Confidential Computing）的一個具體實作，其主要目标是對資料在使用中的保護，随着雲計算的大規模部署，機密計算旨在允許将雲提供商從可信計算基礎（TCB）中移除，以便隻有硬體和受保護的應用程式本身在可信邊界内，這使租戶可以放心地、安全地把業務負載轉移到公有雲上去。
要知道，英特爾® SGX 一直是業内機密計算方案的主要推動者。英特爾® SGX 在記憶體空間中“開辟”出了一個可信的、受到嚴密保護的安全“飛地”，可通過嚴格的通路控制和加密操作去保障資料完整性、資料機密性和代碼完整性，確定主機作業系統、BIOS 等高等級應用和底層基礎系統都不能對其随意通路。即便應用、底層基礎系統在惡意攻擊中受損，“飛地”也可通過基于硬體的、增強型的安全防護來阻斷攻擊。
同時英特爾® SGX 的鑒權能力可在阻斷攻擊的同時證明自己的運作未被篡改。如果需要實作資料“可用不可見”，英特爾® SGX 也能以“飛地”機制為機密計算中的資料與代碼提供安全島。
“飛地”空間越大，其能承載和提供保護的應用程式和核心資料也就越多，于是英特爾對 SGX 技術進行了全面強化，在配置了面向單路和雙路的第三代英特爾® 至強® 可擴充處理器的系統中，目前雙路系統中最高可支援1TB容量的“飛地”空間，能夠讓使用者在雲上實作更大資料量的機密計算，輕松應對更多安全挑戰。
四、寫在最後
随着人工智能、大資料等創新技術席卷大多數行業和地域，疫情防護常态化暴露出來的企業“數字缺陷”加快了數字化轉型速度。企業想要成功實作數字化轉型，建構雲原生技術架構，就一定要利用好容器技術。
在後 OpenStack 時代，雲原生未來的發展趨勢就是将管理基礎設施（計算、網絡、存儲）的負擔解除安裝給雲服務提供商（公共雲/私有雲/邊緣雲），以便開發人員可以專注于應用程式的業務邏輯而不是基礎設施，進而以更低的資本性支出和管理支出、更快地使應用上市。如果更具象一點，則是将大型複雜的單體應用程式分解為小的子產品化執行單元，以便于修改程式或添加功能，更好地代碼重用，更少地維護開銷。
作為雲原生發展的基石，容器技術将再次順應雲原生發展潮流，解決上述的這些需求。随着技術的演進，企業勢必會越來越重視如何使容器技術更好地為業務帶來價值這件事。那在這個過程中，勢必會遇見各種各樣的挑戰，面對挑戰，我們需要的做的就是迎難而上。
對正處在數字化轉型關鍵期的企業來說，在降本增效的大目标下，應用英特爾等廠商提供的商用解決方案也是很不錯的選擇，不僅能夠幫助企業降低人力成本，還能夠大大地提高管理效率。