云計(jì)算大躍進(jìn)，看芯片廠商如何推動(dòng)虛擬化技術(shù)發(fā)展

原標(biāo)題：云計(jì)算大躍進(jìn)，看芯片廠商如何推動(dòng)虛擬化技術(shù)發(fā)展

進(jìn)入 21 世紀(jì)后，虛擬機(jī)技術(shù)進(jìn)入相對(duì)成熟階段，由于虛擬機(jī)的“笨重”，開(kāi)發(fā)者們開(kāi)始追求一種更加輕便的虛擬化技術(shù)。2010 年，由 NASA 和 Rackspace 聯(lián)合開(kāi)發(fā)的開(kāi)源平臺(tái) OpenStack 誕生，幫助服務(wù)商和企業(yè)實(shí)現(xiàn)云基礎(chǔ)架構(gòu)服務(wù)。它將開(kāi)源、開(kāi)放的思想帶到了云原生領(lǐng)域，并為云原生發(fā)展掀開(kāi)了新篇章。

2020 年，OpenStack 基金會(huì)更名為開(kāi)放基礎(chǔ)設(shè)施基金會(huì) OIF，OpenStack 從“云”拓展到了“開(kāi)放基礎(chǔ)設(shè)施”。

緊接著，OpenStack 從最初的虛擬化管理 Nova 和對(duì)象存儲(chǔ) Swift ，逐漸發(fā)展到包含虛擬化管理、SDN、SDS 服務(wù)編排和容器管理等功能覆蓋全面的開(kāi)源項(xiàng)目集合。同時(shí)緊跟云原生技術(shù)演進(jìn)潮流，與容器、Kubernetes、AI 相關(guān)的更多開(kāi)源技術(shù)緊密合作。2021 年 11 月，OIF 基金會(huì)宣布了開(kāi)放基礎(chǔ)設(shè)施的新標(biāo)準(zhǔn) LOKI —— Linux、OpenStack、Kubernetes 等組成的開(kāi)放基礎(chǔ)設(shè)施管理軟件。

在今年 4 月，OIF 發(fā)布了 OpenStack Yoga 版本，并宣布，待下一個(gè)被稱為終結(jié)者的 Zed 版本發(fā)布之后，OpenStack 將以穩(wěn)定的狀態(tài)成為企業(yè)IT的生產(chǎn)級(jí)工具。這意味著云原生逐漸進(jìn)入后OpenStack 時(shí)代，2017 年起，各大云廠商都陸續(xù)開(kāi)始包裝和提供容器的商業(yè)化服務(wù)，提供基于 Kubernetes 的商業(yè)服務(wù)產(chǎn)品，容器技術(shù)逐漸走向成熟和標(biāo)準(zhǔn)化、商業(yè)化，成為虛擬化的新代表產(chǎn)品，圍繞容器發(fā)展的云原生逐漸走向普適的階段，已經(jīng)應(yīng)用容器的企業(yè)正在進(jìn)行著云原生的新一輪技術(shù)演進(jìn)。

一、后 OpenStack 時(shí)代的 Kubernetes ：從“解決難用”到“用的好”

數(shù)字化轉(zhuǎn)型的加速增加了企業(yè)對(duì)于云原生的需求，容器技術(shù)覆蓋率提高，IDC預(yù)測(cè)，容器軟件市場(chǎng)在近幾年呈爆發(fā)式增長(zhǎng)，并且未來(lái)五年仍然會(huì)保持超過(guò) 40% 的復(fù)合增長(zhǎng)率。

進(jìn)而，企業(yè)對(duì)容器管理的需求會(huì)直線提升，容器管理成為企業(yè)數(shù)字化轉(zhuǎn)型的主戰(zhàn)場(chǎng)。據(jù) Gartner 預(yù)測(cè)，到 2025 年，成熟經(jīng)濟(jì)體中 85% 的大型企業(yè)將更多地使用容器管理。

如今在大多企業(yè)的業(yè)務(wù)場(chǎng)景中，企業(yè)組織需要確保多個(gè)容器可同時(shí)協(xié)同工作，這方面的工作大部分都是又編排引擎完成。隨著 Kubernetes 的興起與演進(jìn)，目前已經(jīng)克服了容器編排過(guò)程中許多技術(shù)挑戰(zhàn)。

或許因?yàn)?Kubernetes 想要解決的問(wèn)題太多，所以導(dǎo)致其復(fù)雜度很高，于是不少企業(yè)也在應(yīng)用其他容器管理解決方案。然而市場(chǎng)數(shù)據(jù)證明，Kubernetes 依舊是大多企業(yè)的選擇。CNCF 最近的一份報(bào)告顯示，Kubernetes 在全球已擁有近 600 萬(wàn)個(gè)企業(yè)用戶，成為云上應(yīng)用程序主要的部署模式。

盡管 Kubernetes 覆蓋率高，但這也并不意味著已經(jīng)在應(yīng)用它的用戶滿意，常被吐槽“難用但還很需要”。在 Kubernetes 的實(shí)際使用過(guò)程中，經(jīng)常會(huì)遇見(jiàn)一些“難用”問(wèn)題，比如創(chuàng)建容器時(shí)間過(guò)長(zhǎng)、低吞吐量/ RPS /突發(fā)并發(fā)、容器擴(kuò)展速度慢、集群擴(kuò)展速度慢、Sidecar 資源開(kāi)銷、資源利用率低等，為此，英特爾提出了創(chuàng)新的“SW+HW 功能解析”解決方案，開(kāi)發(fā)工作主要集中在資源編排（Orchestration）和可觀測(cè)行（Observability）兩方面：

基于快照+熱代碼塊來(lái)創(chuàng)建容器；

• 分片式多調(diào)度器；
• 彈性 POD 的自動(dòng)擴(kuò)展；
• 基于遙測(cè)的快速預(yù)測(cè)，用于實(shí)時(shí)擴(kuò)展的決策；
• 動(dòng)態(tài)插入/刪除 POD 中的 Sidecar 容器；
• 鏈接設(shè)備的親和調(diào)度/分配(NUMA, GPU+Smart NIC 等)；
• 實(shí)時(shí) “節(jié)點(diǎn)資源變化” 反饋給 Kubernetes 調(diào)度器。

以上提到的這些技術(shù)都符合 Kubernetes 的 API 規(guī)范并可與現(xiàn)有的 API 兼容，確保用戶在不修改已有 Kubernetes 代碼的情況下便能安裝使用。為了方便用戶測(cè)試、評(píng)估這些技術(shù)，英特爾還直接提供了容器鏡像的方式讓用戶可以通過(guò)Operator等標(biāo)準(zhǔn)的 Kubernetes 應(yīng)用部署方法來(lái)安裝部署。

解決完容器“難用”問(wèn)題，就要接著考慮如何“用得好”的問(wèn)題?！坝玫暮谩钡那疤崾沁x對(duì)架構(gòu)。在后 OpenStack 時(shí)代，企業(yè)使用云原生架構(gòu)的目的是追求敏捷、彈性、高性能和效率。要想達(dá)到這些目的，單純依靠軟件層面的優(yōu)化是不夠的，以Serverless為例，很多部署中會(huì)出現(xiàn)的問(wèn)題，比如函數(shù)冷啟動(dòng)等，都需要通過(guò)硬件層面的優(yōu)化來(lái)解決。

隨著數(shù)據(jù)逐漸擴(kuò)散至邊緣場(chǎng)景，越來(lái)越多的企業(yè)期望通過(guò)云原生架構(gòu)實(shí)現(xiàn)云邊端一體化協(xié)同的基礎(chǔ)設(shè)施，英特爾一直在為此做出努力，聚焦企業(yè)發(fā)展不同階段的不同需求，針對(duì)性提出架構(gòu)優(yōu)化方案。

其次，企業(yè)部分廣泛存在的AI訴求也對(duì)“用得好”提出了挑戰(zhàn)。如今幾乎每個(gè)應(yīng)用功能都離不開(kāi) AI，然而 AI 模型從開(kāi)發(fā)進(jìn)入到生產(chǎn)部署階段面臨著多重困難和挑戰(zhàn)。一般而言，AI 模型需要經(jīng)過(guò)大量的調(diào)試和測(cè)試，通常需要 2-3 天才能部署上線；而且 AI 線上服務(wù)計(jì)算資源通常較固定，對(duì)于突發(fā)需求資源響應(yīng)慢，又面臨著業(yè)務(wù)擴(kuò)展難的問(wèn)題。

作為云原生的核心技術(shù)， Kubernetes 能夠管理云平臺(tái)中多個(gè)主機(jī)上的容器化應(yīng)用，能夠完成 AI 資源的統(tǒng)一部署、規(guī)劃、更新、維護(hù)，有效提高 AI 資源管理率。此外，在基于 Kubernetes 的 AI 開(kāi)發(fā)平臺(tái)建設(shè)實(shí)踐中，使用 CPU 服務(wù)器可有效利用空置資源、空閑時(shí)間，并通過(guò) Kubernetes 的彈性資源調(diào)度分配給其它應(yīng)用。而且 CPU 作為通用算力提供者，在采購(gòu)成本、使用難度等方面有著重要優(yōu)勢(shì)，不僅支持 AI 運(yùn)算，還可用于其他應(yīng)用負(fù)載。

在 Kubernetes 發(fā)布初期，針對(duì) CPU 和內(nèi)存的管理與分配做的比較簡(jiǎn)單，隨著新版本的發(fā)布，逐步有一些新的功能加進(jìn)來(lái)（如 CPU Manager、Topology Manager 等），但 Kubernetes 缺省的 CPU Manager、Topology Manager 仍無(wú)法了解服務(wù)器級(jí)硬件的復(fù)雜內(nèi)部架構(gòu)和 CPU 本身的能力，這就可能會(huì)導(dǎo)致 CPU 的資源分配決策和計(jì)算性能無(wú)法達(dá)到最優(yōu)。對(duì)于英特爾? 至強(qiáng)? 可擴(kuò)展處理器來(lái)說(shuō)，其架構(gòu)復(fù)雜、功能強(qiáng)大，如果想要在上面部署 Kubernetes 集群來(lái)高效支撐云業(yè)務(wù)，就需要對(duì)其拓?fù)浣Y(jié)構(gòu)和 CPU 的強(qiáng)大功能暴露給 Kubernetes集群，這時(shí)英特爾? CRI-RM 因此而生。

在英特爾研發(fā)團(tuán)隊(duì)的不懈努力下，如今英特爾? CRI-RM 助力下的 CPU 在 AI 場(chǎng)景中能夠更顯威力。英特爾? CRI-RM 是英特爾初創(chuàng)的一個(gè)開(kāi)源項(xiàng)目，其目的是通過(guò)在節(jié)點(diǎn)上的動(dòng)態(tài)劃分系統(tǒng)資源，配合 Kubernetes 調(diào)度器，實(shí)現(xiàn)在節(jié)點(diǎn)層面上的最優(yōu)任務(wù)編排，把英特爾平臺(tái)的特性完美的適配到 Kubernetes 的集群環(huán)境里。

浪潮在 AIStation V3 中應(yīng)用了英特爾? CRI-RM 組件，該組件可以插在 Kubelet 和 CR 之間，截取來(lái)自 Kubelet CRI 協(xié)議的請(qǐng)求， 扮演 CR 的非透明代理，跟蹤所有集群節(jié)點(diǎn)容器狀態(tài)，能夠更好 地將處理器、內(nèi)存、IO 外設(shè)、內(nèi)存控制器等資源分配給應(yīng)用負(fù)載。在 Tensorflow 等測(cè)試用例中，這一優(yōu)化被證明能夠?qū)崿F(xiàn)高達(dá) 57.76% 的性能提升。這意味著在未對(duì)硬件配置進(jìn)行更新的前提下，CRI-RM 的應(yīng)用會(huì)帶來(lái)大幅度的性能提升，使得用戶無(wú)需在進(jìn)行硬件投入便能夠獲得可觀的 AI 訓(xùn)練性能提升，從而提高基礎(chǔ)設(shè)施的利用效率，并節(jié)約了總體擁有成本。

通過(guò)浪潮的實(shí)踐，我們基本就能夠看出，英特爾的軟件開(kāi)發(fā)和創(chuàng)新的起點(diǎn)就是充分利用硬件資源潛能來(lái)優(yōu)化應(yīng)用，加速應(yīng)用負(fù)載使其在英特爾平臺(tái)上以達(dá)到更好的開(kāi)發(fā)和用戶體驗(yàn)。又比如 QAT 加速卡，在云原生領(lǐng)域的各種網(wǎng)絡(luò)傳輸模塊中，它便有效提速了安全加解密（TLS）和壓縮/解壓縮的處理性能，從而幫助軟件獲得更好的性能。

二、企業(yè)當(dāng)下需要的是“一站式”容器解決方案

用過(guò) OpenStack 的人都知道，版本升級(jí)是 OpenStack 商業(yè)化應(yīng)用的最大痛點(diǎn)。每年兩次版本升級(jí)令企業(yè)真的有點(diǎn)吃不消，舊操作系統(tǒng)無(wú)法滿足新版本的升級(jí)需求，用戶輕易不敢進(jìn)行升級(jí)。雖然說(shuō) OpenStack 將在 Zed 版本之后，從“A”開(kāi)始重新命名，每年兩次大版本升級(jí)改為每年一次大版本升級(jí)，但這依舊滿足不了如今企業(yè)在數(shù)字化轉(zhuǎn)型過(guò)程中上云的需求。

隨著技術(shù)發(fā)生變革，用戶需要的是一套能從產(chǎn)品端到服務(wù)端的一站式解決方案來(lái)滿足需求。因?yàn)檫@些需求的存在，越來(lái)越多的團(tuán)隊(duì)會(huì)基于 Kubernetes 構(gòu)建上層抽象，增加更多的擴(kuò)展能力，以“應(yīng)用”為中心構(gòu)建高可擴(kuò)展的云原生平臺(tái)。

比如青云科技開(kāi)源的KubeSphere項(xiàng)目，在 Kubernetes 之上構(gòu)建的面向云原生應(yīng)用的分布式操作系統(tǒng)，完全開(kāi)源，支持多云與多集群管理，提供全棧的 IT 自動(dòng)化運(yùn)維能力，簡(jiǎn)化企業(yè)的 DevOps 工作流。它的架構(gòu)可以非常方便地使第三方應(yīng)用與云原生生態(tài)組件進(jìn)行“即插即用”的集成。此外，KubeSphere 還開(kāi)源了 KubeKey 幫助企業(yè)一鍵在公有云或數(shù)據(jù)中心快速搭建 Kubernetes 集群，提供單節(jié)點(diǎn)、多節(jié)點(diǎn)、集群插件安裝，以及集群升級(jí)與運(yùn)維。

基于對(duì)企業(yè)用戶的需求洞察，青云科技在發(fā)展 KubeSphere 的社區(qū)的同時(shí)，還圍繞 KubeSphere 這一核心產(chǎn)品開(kāi)發(fā)了企業(yè)級(jí)容器平臺(tái)—— KubeSphere 企業(yè)版。目前已經(jīng)在金融、運(yùn)營(yíng)商、工業(yè)、教育、能源、交通物流、零售電商和政府等行業(yè)積累了大量成功經(jīng)驗(yàn)。像中金蒼穹容器平臺(tái)、易方達(dá)基金 PaaS 平臺(tái)、云天化集團(tuán)容器云平臺(tái)、中移金科容器云平臺(tái)都是 KubeSphere 企業(yè)版的優(yōu)秀實(shí)踐。

為了真正幫助企業(yè)更好地落地云原生應(yīng)用場(chǎng)景，青云科技廣泛聯(lián)合云原生生態(tài)體系各層面合作伙伴，打造開(kāi)放共生的云原生生態(tài)圈。硬件層面的生態(tài)合作是其中重要的一部分，因?yàn)樵诋?dāng)前的云原生生態(tài)環(huán)境下，云原生容器化平臺(tái)上的軟件應(yīng)用效率和硬件技術(shù)之前的關(guān)系更加緊密，其運(yùn)行更需要調(diào)動(dòng)硬件的加速能力。于是擁有獨(dú)特硬件黑科技優(yōu)勢(shì)的英特爾成為了青云科技的合作伙伴，為 KubeSphere 企業(yè)版提供了許多支持。

英特爾幫 KubeSphere 企業(yè)版實(shí)現(xiàn)了網(wǎng)絡(luò)功能增強(qiáng)，通過(guò)開(kāi)發(fā)并開(kāi)源 Multus 的 CNI 插件、提供“將多個(gè)接口添加到 Pod”的功能，成功解決了因 Kubernetes 缺乏支持多個(gè)網(wǎng)絡(luò)接口能力，而受制于單一網(wǎng)絡(luò)解決方案的企業(yè)用戶的需求。如今的 KubeSphere 企業(yè)版在優(yōu)化后的 Intel Multus 解決方案的助力下，實(shí)現(xiàn)了更強(qiáng)大、更多元的網(wǎng)絡(luò)管理和擴(kuò)展能力，支持用戶在創(chuàng)建應(yīng)用負(fù)載時(shí)可以自定義選擇多塊網(wǎng)卡，同時(shí)支持網(wǎng)卡資源池管理。

圖：應(yīng)用負(fù)載選擇多網(wǎng)卡

此外，為了檢測(cè) Kubernetes Cluster 中每個(gè) Node 的特性能力，英特爾還開(kāi)發(fā)了 NFD（Node Feature Discovery），而 KubeSphere 企業(yè)版深度集成了 NFD，使其節(jié)點(diǎn)管理得到增強(qiáng)。KubeSphere 企業(yè)版通過(guò)把節(jié)點(diǎn)更詳細(xì)的 Label 發(fā)送到 KubeSphere 企業(yè)版 Master Scheduler 之上，應(yīng)用負(fù)載獲得了更精準(zhǔn)的調(diào)度，使其更充分地利用硬件資源。

圖：測(cè)試結(jié)果-Node Feature Discovery啟動(dòng)成功

另外值得一提的是，CPU Manager 給 KubeSphere 企業(yè)版帶來(lái)的性能提升表現(xiàn)十分亮眼。當(dāng)我們測(cè)試部署不同的 Redis pod 會(huì)發(fā)現(xiàn)，開(kāi)啟 CPU Manager 后的 Redis 的讀寫性能與開(kāi)啟前的讀寫性能相比，Redis 性能最高可以提升超過(guò) 9%。

圖：Redis 性能測(cè)試圖

三、容器好用，但也需要“注意安全”

虛擬化技術(shù)突破了操作系統(tǒng)與物理硬件的局限，在異構(gòu)資源整合、集中管理、提高硬件利用率等方面具有很強(qiáng)的優(yōu)勢(shì)，但這同時(shí)也增加了發(fā)生系統(tǒng)安全問(wèn)題的概率，虛擬化的安全直接影響著云原生架構(gòu)的安全，間接影響著企業(yè)數(shù)字化轉(zhuǎn)型成果及業(yè)務(wù)發(fā)展。

作為云原生虛擬化常用的技術(shù)，容器確實(shí)好用，但是容器安全問(wèn)題也一直是行業(yè)內(nèi)備受詬病的問(wèn)題。傳統(tǒng)的容器基于 NameSpace 和 Cgroup 進(jìn)行隔離，在帶來(lái)輕量簡(jiǎn)潔的同時(shí)，也帶來(lái)了許多安全隱患。容器作為一種相對(duì)于虛擬機(jī)來(lái)說(shuō)更加輕量的虛擬化技術(shù)，容器雖然能夠提供一個(gè)與系統(tǒng)中其他進(jìn)程資源相隔離的執(zhí)行環(huán)境，但還是與宿主機(jī)系統(tǒng)共享內(nèi)核的，很容易因?yàn)楦綦x性不足而產(chǎn)生安全隱患。尤其是在多租戶的場(chǎng)景下，一旦容器里的應(yīng)用逃逸到內(nèi)核，后果將不堪設(shè)想。

據(jù) Red Hat 公司調(diào)查數(shù)據(jù)顯示：有 94% 的受訪者在過(guò)去 12 個(gè)月內(nèi)遭遇過(guò) Kubernetes 安全事件。而 Akamai 日前也進(jìn)行了一項(xiàng)實(shí)驗(yàn)，將一個(gè)簡(jiǎn)單的 Docker 容器蜜罐用于攻擊測(cè)試，結(jié)果顯示該容器在 24 小時(shí)內(nèi)被攻擊者用于四起不同的犯罪活動(dòng)。這些數(shù)據(jù)都在告訴我們，解決企業(yè)容器安全問(wèn)題刻不容緩。

所以很多廠商在構(gòu)建企業(yè)級(jí)容器管理平臺(tái)時(shí)都會(huì)著重考慮容器安全問(wèn)題，像我們剛剛提到的KubeSphere 企業(yè)版，它的一大亮點(diǎn)就是“安全加固”。在英特爾容器解決方案加持下的 KubeSphere 企業(yè)版，深度集成了 Kata Containers，用戶可以在創(chuàng)建符合自身業(yè)務(wù)需求的運(yùn)行時(shí)，通過(guò) KubeSphere 企業(yè)版的管理頁(yè)面進(jìn)行統(tǒng)一管理。

圖：一鍵選擇Kata

Kata Containers 的核心亮點(diǎn)就是采用輕量級(jí)虛擬化作為容器的隔離，使得它兼具容器的速度和虛擬機(jī)的安全隔離，這一點(diǎn)解決了長(zhǎng)期以來(lái)困擾容器發(fā)展的安全隔離性不足問(wèn)題，大大促進(jìn)了云原生的發(fā)展。

作為符合 OCI 標(biāo)準(zhǔn)的輕量級(jí) VM，可無(wú)縫地與 Docker 及 Kubernetes 對(duì)接。Kata Containers 運(yùn)行的應(yīng)用負(fù)載具備獨(dú)立內(nèi)核，同時(shí)借助英特爾? VT 技術(shù)，具備其他輕量級(jí) VM 所不具備的優(yōu)異性能。它整合了英特爾的 Clear Containers 和 Hyper.sh 的 runV，在能夠充分利用英特爾? 架構(gòu)平臺(tái)性能優(yōu)勢(shì)的同時(shí)，還支持其他架構(gòu)的硬件。

Kata Containers 的隔離原理就是在請(qǐng)求創(chuàng)建容器實(shí)例時(shí)，首先啟動(dòng)一個(gè)輕量化虛擬機(jī)，然后將容器鏡像掛載到虛擬機(jī)里，從而在這個(gè)虛擬機(jī)里啟動(dòng)和運(yùn)行這個(gè)容器應(yīng)用程序。其本質(zhì)是一個(gè)虛擬機(jī)實(shí)例，但拉起虛擬機(jī)的過(guò)程和運(yùn)行在虛擬機(jī)里這個(gè)事實(shí)對(duì)用戶是透明的，這種方式并不改變用戶使用容器的習(xí)慣。

Kata containers 可以被用在很多場(chǎng)景，目前云服務(wù)提供商 CSP 們的使用場(chǎng)景主要包括安全容器實(shí)例服務(wù)、容器運(yùn)行時(shí)的業(yè)務(wù)隔離等。感興趣的開(kāi)發(fā)者可以參閱公開(kāi)的應(yīng)用案例集： 目前 Kata Containers 2.0 已經(jīng)發(fā)布，社區(qū)正在醞釀 Kata Containers 3.0 的規(guī)劃和開(kāi)發(fā)，其主要開(kāi)發(fā)方向?qū)⒕劢褂趦?yōu)化性能、加強(qiáng)安全、提高可用性和穩(wěn)定性方面。

另外，一個(gè)基于 Kata Containers 的典型用例也十分值得大家去了解——機(jī)密容器 （Confidential containers），它是一個(gè)基于硬件TEE的技術(shù)方案，目前是 CNCF 的沙箱項(xiàng)目。機(jī)密容器是機(jī)密計(jì)算（Confidential Computing）的一個(gè)具體實(shí)現(xiàn)，其主要目標(biāo)是對(duì)數(shù)據(jù)在使用中的保護(hù)，隨著云計(jì)算的大規(guī)模部署，機(jī)密計(jì)算旨在允許將云提供商從可信計(jì)算基礎(chǔ)（TCB）中移除，以便只有硬件和受保護(hù)的應(yīng)用程序本身在可信邊界內(nèi)，這使租戶可以放心地、安全地把業(yè)務(wù)負(fù)載轉(zhuǎn)移到公有云上去。

要知道，英特爾? SGX 一直是業(yè)內(nèi)機(jī)密計(jì)算方案的主要推動(dòng)者。英特爾? SGX 在內(nèi)存空間中“開(kāi)辟”出了一個(gè)可信的、受到嚴(yán)密保護(hù)的安全“飛地”，可通過(guò)嚴(yán)格的訪問(wèn)控制和加密操作去保障數(shù)據(jù)完整性、數(shù)據(jù)機(jī)密性和代碼完整性，確保主機(jī)操作系統(tǒng)、BIOS 等高等級(jí)應(yīng)用和底層基礎(chǔ)系統(tǒng)都不能對(duì)其隨意訪問(wèn)。即便應(yīng)用、底層基礎(chǔ)系統(tǒng)在惡意攻擊中受損，“飛地”也可通過(guò)基于硬件的、增強(qiáng)型的安全防護(hù)來(lái)阻斷攻擊。

同時(shí)英特爾? SGX 的鑒權(quán)能力可在阻斷攻擊的同時(shí)證明自己的運(yùn)行未被篡改。如果需要實(shí)現(xiàn)數(shù)據(jù)“可用不可見(jiàn)”，英特爾? SGX 也能以“飛地”機(jī)制為機(jī)密計(jì)算中的數(shù)據(jù)與代碼提供安全島。

“飛地”空間越大，其能承載和提供保護(hù)的應(yīng)用程序和核心數(shù)據(jù)也就越多，于是英特爾對(duì) SGX 技術(shù)進(jìn)行了全面強(qiáng)化，在配置了面向單路和雙路的第三代英特爾? 至強(qiáng)? 可擴(kuò)展處理器的系統(tǒng)中，目前雙路系統(tǒng)中最高可支持1TB容量的“飛地”空間，能夠讓用戶在云上實(shí)現(xiàn)更大數(shù)據(jù)量的機(jī)密計(jì)算，輕松應(yīng)對(duì)更多安全挑戰(zhàn)。

四、寫在最后

隨著人工智能、大數(shù)據(jù)等創(chuàng)新技術(shù)席卷大多數(shù)行業(yè)和地域，疫情防護(hù)常態(tài)化暴露出來(lái)的企業(yè)“數(shù)字缺陷”加快了數(shù)字化轉(zhuǎn)型速度。企業(yè)想要成功實(shí)現(xiàn)數(shù)字化轉(zhuǎn)型，構(gòu)建云原生技術(shù)架構(gòu)，就一定要利用好容器技術(shù)。

在后 OpenStack 時(shí)代，云原生未來(lái)的發(fā)展趨勢(shì)就是將管理基礎(chǔ)設(shè)施（計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)）的負(fù)擔(dān)卸載給云服務(wù)提供商（公共云/私有云/邊緣云），以便開(kāi)發(fā)人員可以專注于應(yīng)用程序的業(yè)務(wù)邏輯而不是基礎(chǔ)設(shè)施，從而以更低的資本性支出和管理支出、更快地使應(yīng)用上市。如果更具象一點(diǎn)，則是將大型復(fù)雜的單體應(yīng)用程序分解為小的模塊化執(zhí)行單元，以便于修改程序或添加功能，更好地代碼重用，更少地維護(hù)開(kāi)銷。

作為云原生發(fā)展的基石，容器技術(shù)將再次順應(yīng)云原生發(fā)展潮流，解決上述的這些需求。隨著技術(shù)的演進(jìn)，企業(yè)勢(shì)必會(huì)越來(lái)越重視如何使容器技術(shù)更好地為業(yè)務(wù)帶來(lái)價(jià)值這件事。那在這個(gè)過(guò)程中，勢(shì)必會(huì)遇見(jiàn)各種各樣的挑戰(zhàn)，面對(duì)挑戰(zhàn)，我們需要的做的就是迎難而上。

對(duì)正處在數(shù)字化轉(zhuǎn)型關(guān)鍵期的企業(yè)來(lái)說(shuō)，在降本增效的大目標(biāo)下，應(yīng)用英特爾等廠商提供的商用解決方案也是很不錯(cuò)的選擇，不僅能夠幫助企業(yè)降低人力成本，還能夠大大地提高管理效率。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。