安全容器在邊緣計算場景下的實踐

導讀：隨著雲端計算邊界不斷向邊緣側延展，傳統 RunC 容器已無法滿足使用者對不可信、異構工作負載的執行安全訴求，邊緣 Serverless、邊緣服務網格等更是對容器安全隔離提出了嚴苛的要求。本文將介紹邊緣計算場景如何構建安全執行時技術基座，以及安全容器在架構、網路、監控、日誌、儲存、以及 K8s API 相容等方面的遇到的困難挑戰和最佳實踐。

正文：

本文主要分為四個部分，首先前兩個部分會分別介紹一下ACK安全沙箱容器和邊緣容器（Edge Kubernetes），這兩個方向內容目前大部分人接觸並不是很多。第三部著重分享安全沙箱容器在邊緣這邊的解決方案與實踐經驗，最後會介紹一下我們在安全容器方向新的探索和實踐-可信/機密計算。

安全容器執行時

據 Gartner 預測，2019 年一半以上的企業會在其開發和生產環境中使用容器部署應用，容器技術日趨成熟穩定，然而在未容器化的企業或使用者中，42% 以上的受訪者表示容器安全成為其容器化的最大障礙之一，主要包括容器執行時安全、映象安全和資料安全加密等。

端到端的雲原生安全架構

在講安全沙箱容器之前簡單介紹下端到端雲原生安全架構，主要分為三部分：

1.基礎架構安全

基礎架構安全依賴於雲廠商或者是專有云一些基礎設施安全能力，也包括 RAM認證，細粒度RAM授權，支援審計能力等等。

2.安全軟體供應鏈

這部分包括映象簽名，映象掃描，安全合規等等，甚至包括有一些靜態加密BYOK，DevSecOps，安全分發等。

3.容器執行時的安全

這部分包括安全沙箱隔離，還包括了容器執行時其它方面一些安全機制，如KMS（秘鑰管理服務）整合、多租戶的管理和隔離等等。

安全容器執行時對比

接下來分享下業界在安全容器執行時的一些方案對比，業界安全容器執行時分為四大類：

• OS容器+安全機制

主要原理是在傳統 OS 容器之上增加一些輔助安全輔助手段來增加安全性，如SELinux、AppArmor、Seccomp等，還有docker 19.03+可以讓Docker執行在 Rootless 的模式之下，其實這些都是透過輔助的工具手段來增強OS容器的安全性，但依然沒有解決容器與Host共享核心利用核心漏洞逃逸帶來的安全隱患問題；而且這些安全訪問控制工具對管理員認知和技能要求比較高，安全性也相對最差。

• 使用者態核心

此類典型代表是 Google 的 gVisor，透過實現獨立的使用者態核心去補獲和代理應用的所有系統呼叫，隔離非安全的系統呼叫，間接性達到安全目的，它是一種程式虛擬化增強。但系統呼叫的代理和過濾的這種機制，導致它的應用相容性以及系統呼叫方面效能相對傳統OS容器較差。由於並不支援 virt-io 等虛擬框架，擴充套件性較差，不支援裝置熱插拔。

• Library OS

基於 LibOS 技術的這種安全容器執行時，比較有代表 UniKernel、Nabla-Containers，LibOS技術本質是針對應用對核心的一個深度裁剪和定製，需要把 LibOS 與應用編譯打包在一起。因為需要打包拼在一起，本身相容性比較差，應用和 LibOS 的捆綁編譯和部署為傳統的 DevOPS 帶來挑戰。

• MicroVM

我們知道業界虛擬化(機)本身已經非常的成熟，MicroVM輕量虛擬化技術是對傳統虛擬化的裁剪和，比較有代表性的就是 Kata-Containers、Firecracker，擴充套件能力非常優秀。VM GuestOS 包括核心均可自由定製，由於具備完整的OS和核心它的應用相容性及其優秀；獨立核心的好處是即便出現安全漏洞問題也會把安全影響範圍限制到一個 VM 裡面，當然它也有自己的缺點，Overhead 可能會略大一點，啟動速度相對較慢一點。

完全杜絕安全問題的發生-不可能！

Linus Torvalds 曾在 2015年的 LinuxCon 上說過 "The only real solution to security is to admit that bugs happen, and then mitigate them by having multiple layers.” ，我們無法杜絕安全問題，軟體總會有 Bug、Kernel 總會有漏洞，我們需要去面對這些現實問題，既然無法杜絕那我們需要就給它（應用）加上隔離層（沙箱）。

安全容器執行時選擇

使用者選擇安全容器執行時需要考慮三方面：安全隔離、通用性以及資源效率。

• 安全隔離

主要包括安全隔離和效能隔離。安全隔離主要是安全問題影響的範圍，效能隔離主要是降低容器間的相互干擾和影響。

• 通用性

通用性，首先是應用相容性，應用是否可以在不修改或者小量修改的前提下執行在上面；其次是標準性相容，包括 OCI 相容、K8sAPI 相容等；最後“生態”保證它可持續性和健壯性。

• 資源效率

資源效率講究更低 Overhead，更快的啟動速度，更好的應用效能。

總結

其實 目前沒有任何一種容器執行時技術可以同時滿足以上三點，而我們需要做的就是根據具體的場景和業務需求合理選擇適合自己的容器執行時。

在「資源效率」和「通用性」做的比較好的是傳統的OS容器、runC等，但安全性最差；在「資源效率」和「安全隔離」做的比較好的是 UniKernel、gVisor 等，但應用相容和通用性較差；在「安全隔離」和「通用性」方面做的比較的是 Kata-containers、Firecracker等，但 overhead 開銷稍大啟動速度稍慢，應用效能也相對傳統OS容器較差。

ACK安全沙箱容器

我們阿里雲容器服務 ACK 產品基於 Alibaba Cloud Sandbox 技術在 2019 年 09 月份推出了安全沙箱容器執行時的支援，它是在原有Docker容器之外提供的一種全新的容器執行時選項，它可以讓應用執行在一個輕量虛擬機器沙箱環境中，擁有獨立的核心，具備更好的安全隔離能力，特別適合於多租戶間負載隔離、對不可信應用隔離等場景。它在提升安全性的同時，對效能影響非常小，並且具備與Docker容器一樣的使用者體驗，如日誌、監控、彈性等。

對於我們場景來說，「安全性」和「通用性」是無疑最重要的，當然效能和效率我們也做了大量的最佳化：

• 輕量虛擬機器沙箱；
• 獨立 kernel，強隔離，安全故障域影響最小；
• 相容 OCI 標準，幾乎相容所有 K8s API；
• 約 25 MB 的極低 Overhead 開銷；
• 500ms 極速啟動，擁有原生傳統OS容器約 90% 的優秀效能；
• 適合多租負載隔離、不可信三方應用隔離、多方計算、Serverless 等場景。

ACK邊緣容器（ACK@Edge）

隨著萬物互聯時代的到來，智慧城市、智慧製造、智慧交通、智慧家居，5G時代、寬頻提速、IPv6的不斷普及，導致數百億的裝置接入網路，在網路邊緣產生ZB級資料，傳統雲端計算難以滿足物聯網時代大頻寬、低時延、大連線的訴求，邊緣雲端計算便應運而生。

邊緣計算設施服務越來越難以滿足邊端日益膨脹的訴求，因而云上服務下沉，邊緣 Serverless、邊緣側隔離不可信負載等日趨強烈...

所以，為了滿足我們邊緣雲端計算場景需求，我們 ACK 推出了 Kubernetes 邊緣版。

先來看下典型的邊緣雲模型，它由雲（側）、邊（側）、端（側）三部分共同組成，三者相互協同，並提供統一的交付、運維和管控標準。雲側統一管控，是整個模型的中樞大腦；邊側由一定計算/儲存能力的節點組成，是距離裝置和使用者最近的計算/儲存資源；億萬端側裝置就近計入“邊緣節點”。

“邊”又分為兩大類；一個是工業級的邊，這類比較典型代表是雲廠商提供的 CDN 節點計算資源、服務或者 Serverless 等，工業級的邊也可提供 AI 預測、實時計算、轉碼等服務能力，把雲上的服務下沉到邊側。第二類是使用者或者工廠、園區、樓宇、機場等自己提供計算資源伺服器或者閘道器伺服器，如一個家庭閘道器可以作為邊緣節點接入到叢集中從而可以納管控制家庭中的智慧電器裝置。
那邊緣 Serverless 如何解決多租戶負載隔離？工程如何在自己的內網環境安全執行三方提供的應用服務和負載？這也就是我們在邊緣側引入安全沙箱容器的根本原因。

解決方案

整體方案

先看下整體解決方案，上面架構完全契合了“雲-邊-端”模型，我們整個架構是基於 Kubernetes 來開發的。

“雲側”，既“管控端”，提供了整個 K8s 叢集的統一管控，託管了 K8s 叢集“四(master元件)”：kube-apiserver、kube-controller-manager、kube-scheduler以及 cloud-controller-manager，同時我們在“雲側為”增加了 AdminNode 節點使用者部署 Addons 元件，如 metrics-server、log-controller 等非核心功能元件；當然，“雲側”也會適配雲上的各類服務為自己附能，如監控服務、日誌服務、儲存服務等等。

“邊側”，既邊緣Node節點，我們知道“雲側”到“邊側”的弱網會導致邊緣Node失聯，失聯時間過長會導致 Master 對節點上的 Pod 發出驅逐指令，還有斷網期間“邊緣節點”主機重啟後應用如何恢復和自治，這些都是 Edge Kubernetes 面臨的最大挑戰之一；當在 K8s 引入安全沙箱容器執行時，會發現 K8s Api 不相容、部分監控異常、日誌無法正常採集、儲存效能極差等諸多問題，都給我們帶來了極大的挑戰。

在分享解決以上問題前，我們先看下雲側安全沙箱容器方案。

上圖橙色虛框內是節點執行時的元件分層結構，上面是 kubelet，CRI-Runtime 有 Docker 和 Containerd 兩類，其中安全沙箱容器執行時方案（深藍色背景部分）中我們選擇了 Containerd 作為 CRI-Runtime，主要考慮到 Containerd 的結構簡潔，呼叫鏈更短，資源開銷更小，而且它具有及其靈活的多 Runtimes 支援，擴充套件能力也更優。

我們在一個“安全沙箱節點”上同時提供了 RunC 和 RunV 兩種執行時的支援，同時在 K8s 叢集中對應的注入了兩個 RuntimeClass（ runc 和 runv ）以便輕鬆輕易按需排程和選擇，“同時提供 RunC 支援” 也是考慮到諸如 kube-proxy 等 Addon 元件沒必要執行在安全沙箱中。

OS 我們選擇了阿里雲的發行版 OS：Aliyun Linux，4.19+ 的 Kernel 對容器的相容性更優、穩定性更好，同時我們對其進行了極少的定製，以便支援硬體虛擬化。

最下面執行就是我們的裸金屬伺服器，在雲上我們提供了神龍，在邊緣側任何支援硬體虛擬化的裸金屬伺服器均可。

邊緣接節點治理

問題

1. K8s 管控端與邊緣節點斷網維護，如工廠封網內部裝置維護等，超過 Pod 容忍時間（預設300s）後會導致管控端發出“驅逐失聯節點上所有 Pods”指令，在維護結束網路恢復後，邊緣節點收到驅逐指令刪除所有應用 Pod，這對於一個工廠來說是災難性的。
2. 在封（斷）網期間邊緣節點硬體重啟，就會導致節點上依賴管控端（如 kube-apiserver）的部分元件或資料無法正常啟動或載入。

常見社群方案

社群方案一：

主要原理是基於 kubelet checkpoint 機制把一些資源物件緩衝到本地檔案，但 kubelet checkpoint 能力較弱，僅可以魂村 pod 等個別型別物件到本地檔案，像常用的 ConfigMap/Secret/PV/PVC 等暫不支援。當然也可以定製修改 kubelet，但後期會帶來的大量的升級和維護成本。

社群方案二：

利用叢集聯邦，把整個 K8s 叢集下沉到邊緣側，如每個 EdgeUnit 存在一個或多個 K8s 叢集，透過雲側的 K8s Federation 進行多叢集/負載管理。但因為 EdgeUnit 分散性且規模較大龐大，會導致叢集規模數倍增加，產生大量的 Overhead 成本，很多 EdgeUnit 內通常僅有幾臺機器。而且這種架構也比較複雜，難以運維，同時，邊緣K8s叢集也很難複用雲上成熟服務，如監控、日誌等。

我們的方案

如上圖，在我們的邊緣治理方案中，我們增加了兩個非常重要的元件：

• ECM(edge-controller-manager)：節點自治管理，忽略自治模式節點上的 Pod 驅逐等。
  
• 基於 node-lifecycle-controller；
• 透過 Annotation 配置開關，表示節點是否開啟自治模式；
• 對於自治模式的節點，當節點失聯（NotReady等）時忽略對節點上容忍超時的 Pod 驅逐。

• EdgeHub：邊緣節點代理
  
• 作為 kubelet 和 apiserver 之間的快取和代理;
• 在網路正常情況下，EdgeHub直接代理轉發 Kubelet 請求到 apiserver，並快取結果到本地;
• 在節點斷網的情況下，EdgeHub 利用本地快取充當 apiserver，但 EdgeHub並未真正的 apiserver，所以須忽略所有過來的寫操作請求。

監控方案

上圖為整個監控的原理圖，流程是：

1. metrics-server 定期主動向所有節點 kubelet 請求監控資料；
2. kubelet 透過 CRI 介面向 containerd 請求監控資料；
3. containerd 透過 Shim API 向所有容器 shim 請求容器的監控資料；
   
1. Shim API 目前有兩個版本 v1 和 v2。
2. containerd-shim-kata-v2 透過虛擬串列埠向 VM GuestOS（POD） 內的 kata-agent 請求監控資料，kata-agent 採集 GuestOS 內的容器監控資料並響應。
3. 我們 runC shim 用的是 containerd-shim，這個版本雖然比較老，但穩定性非常好，經過大量的生產驗證。

1. metrics-server 把監控資料除了 Sink 到雲監控上外，自己記憶體中還存放了最近一段時間的監控資料，用於提供給 K8s Metrics API，這些資料可用於 HPA 等。

我們遇到的問題是 CRI ContainerStats 介面提供的監控指標非常少，缺失了 Network、Block IO等非常重要的API，並且已有的 CPU 和 Memory 的資料項也及其少。

// ContainerStats provides the resource usage statistics for a container.
message ContainerStats {
    // Information of the container.
    ContainerAttributes attributes = 1;
    // CPU usage gathered from the container.
    CpuUsage cpu = 2;
    // Memory usage gathered from the container.
    MemoryUsage memory = 3;
    // Usage of the writeable layer.
    FilesystemUsage writable_layer = 4;
}
// CpuUsage provides the CPU usage information.
message CpuUsage {
    // Timestamp in nanoseconds at which the information were collected. Must be > 0.
    int64 timestamp = 1;
    // Cumulative CPU usage (sum across all cores) since object creation.
    UInt64Value usage_core_nano_seconds = 2;
}
// MemoryUsage provides the memory usage information.
message MemoryUsage {
    // Timestamp in nanoseconds at which the information were collected. Must be > 0.
    int64 timestamp = 1;
    // The amount of working set memory in bytes.
    UInt64Value working_set_bytes = 2;
}

那如何補齊監控API？由於我們有著龐大的存量叢集，我們的改動既不能影響已有的使用者監控，也不能對整個監控設施方案做大的改動，所以改動儘量在靠近底層的地方做適配和修改，我們最終決定定製 kubelet，這樣整個監控基礎設施不需要做任何變更。

下面是 kubelet 具體修改的原理圖：

kubelet 的監控介面分為三大類：

1. summary 類，社群後面主推介面，有Pod語義，既可以適配 CRI Runtime 也可以相容 Docker。
   
1. /stats/summary。

1. default 類，較老的介面，無Pod語義，社群會逐漸廢棄此類介面。
   
1. /stats
2. /stats/container
3. /stats/{podName}/{containerName}
4. /stats/{namespace}/{podName}/{uid}/{containerName}

1. prometheus類，prometheus格式的介面，實際上後端實現複用了 default 類的方法。
   
1. /metrics
2. /metrics/cadvisor

為了更好的相容，我們對三類介面均進行了適配。上圖紅色部分為新增，黃色虛框部分為修改。

1. summary 類

新增為 containerd 專門實現了介面 containerStatsProvider ：containerdStatsProvider，因 kubelet 透過 CRI 連線 containerd，故 containerdStatsProvider 在實現上覆用了 criStatsProvider， 同時增加了 Network、Block IO 等。

1. default 類和 prometheus 類

在入口處增加判斷分支，若為 containerd 則直接透過 contaienrdStatsProvider 拿資料。

實際上，只修改 kubelet 還不夠，我們發現 containerd 後端返回的監控資料也沒有 Network、Block IO等，所以我們推動了社群在 containerd/cgroups 擴充套件補齊了API。

日誌方案

上圖是我們的日誌方案，我們需要透過阿里雲日誌採集 Agent Logtail 採集容器日誌，主要有三種使用方式：

1. DaemonSet 部署的 Logtail
   
1. 採集節點上所有容器的標準輸出。
2. 透過容器環境變數配置的容器內的採集日誌路徑，在宿主機上拼接容器的 rootfs 路徑，可在宿主機上直採容器內日誌檔案。

1. Sidecar 部署的 Logtail
   
1. 只採集同 Pod 內的其他應用容器日誌檔案。

我們在containerd/安全沙箱容器遇到的問題：

1. Logtail 需要連線容器引擎獲取主機上的所有容器資訊，但只支援docker，不支援 containerd。
2. 所有 runC 和 runV 容器標準輸出無法採集。
3. Logtail DaemonSet 模式無法直採 runC 和 runV 內。

解法：

1. 支援 containerd，同時考慮到通用性，我們在實現上透過 CRI 介面而非 containerd SDK 直接連線 containerd，這樣即便以後換了其他 CRI-Runtime，我們 Logtail 可以輕易直接支援。
2. 透過 Container Spec 獲取容器標準輸出日誌路徑，由於如論 runC 還是 runV 容器的標準輸出檔案均在 Host 上，所以只要找到這個路徑可以直接採集。
3. 在 runC 的日誌檔案路徑查詢上，我們做了個最佳化：優先嚐試查詢 Upper Dir，否則查詢 devicemapper 最佳匹配路徑，由於 runV 有獨立 kernel 無法在 Host 側直採容器內日誌檔案。由於 runV 容器和 Host 核心不再共享，導致無法在 Host 上直接採集 runV 容器內的日誌檔案。

儲存方案

安全沙箱容器儲存方案涉及到兩方面，分別是 RootFS 和 Volume。

• RootFS 可以簡單的理解為容器的“系統盤”，每一個容器均有有一個 RootFS，目前主流的 RootFS 有 Overlay2、Devicemapper 等；
• Volume 可以簡單的理解為容器的“資料盤”，可以為容器用來作為資料儲存擴充套件。

RootFS

對於安全沙箱容器場景中容器 RootFS 我們並沒有採用預設的 overlayfs，主要是因為 overlayfs 屬於檔案目錄類，在 runC 把 rootfs 目錄 mount bind 到容器內沒有任何問題，但在 安全沙箱容器 kata 上直接 mount bind 到容器內會經過 kata 的 9pfs，會導致 block io 效能下降數十倍，所以 我們採⽤ devicemapper 構建了⾼速、穩定的容器 Graph Driver，由於 devicemapper 的底層基於 LVM，為每個容器分配的 dm 均為一個 block device，把這個裝置放入容器內就可以避免了 kata 9pfs 的效能影響，這樣就可以實現一個功能、效能指標全⾯對⻬ runC 場景的 RootFS。

優點/特點：

1. 採用 devicemapper snapshot 機制，實現映象分層儲存；
2. IOPS、Bandwidth 與 RunC overlayfs + ext4 基本持平；
3. 基於 snapshot 增強開發，實現容器映象計算和儲存的分離。

Volume

在容器的儲存上，我們採用了標準的社群儲存外掛 FlexVolume 和 CSI Plugin，在雲上支援雲盤、NAS 以及 OSS，在邊緣我們支援了 LocalStorage。

FlexVolume 和 CSI Plugin 在實現上，預設均會將雲盤、NAS 等先掛載到本地目錄，然後 mount bind 到容器內，這在 runC 容器上並沒有任何問題，但在安全沙箱容器中，由於過 9PFS 所以依然嚴重影響效能。

針對上面的效能問題，我們做了幾方面的最佳化：

• 雲上
  
• NAS
  
• 最佳化 FlexVolume 和 CSI Plugin，針對沙箱(runV) Pod，把 mount bind 的動作下沉到沙箱 GuestOS 內，從而避開了 9PFS；而對 runC Pod 保持原有預設的行為。

• 雲盤或本地盤
  
• 雲盤或本地盤會在本地依然格式化，但不會 mount 到本地目錄，而是直接把 block device 直通到沙箱中，由沙箱中的 agent 執行掛載動作。

• 邊緣
  
• 在邊緣側，我們採用了 Virtio-fs 避開 9PFS 的問題，這種方式更通用，維護起來也更輕便，在效能上基本可以滿足邊緣側的需求，當然無法和“雲上直通”最佳化的效能好。

網路方案

在網路方案中，我們同樣既需要考慮“雲上”和“邊緣”，也需要考慮到“通用性”和“效能”，在 K8s 中還需要考慮到網路方案對 “容器網路” 和 “Service 網路” 的相容性。

如上圖，我們的網路方案中雖然有三種方案。

1. Bridge 橋接模式
2. 網路卡直通模式
3. IPVlan 模式

Birdge橋接模式

橋接模式屬於比較老的也比較成熟的一種網路方案，它的優點就是通用性比較好，架構非常穩定和成熟，缺點是效能較差，特點是每個 Pod 都需要分配 Veth Pair，其中一端在 Host 測，一端在容器內，這樣所有容器內的進出流量都會透過 Veth Pair 回到 Host，無需修改即可同時完美相容 K8s 的容器網路和 Service 網路。目前這種方案主要應用於雲上的節點。

網路卡直通模式

顧名思義，就是直接把網路卡裝置直通到容器內。在雲上和邊緣由於基礎網路設施方案不通，在直通方面略有不同，但原理是相同的。

• 雲上，主要用來直通 ENI 彈性網路卡到每個 Pod 內。
• 邊緣，邊緣網路方案基於 SR-IOV，所以主要用來直通 VF 裝置。

直通方案的優點是，最優的網路效能，但受限於節點 ENI 網路卡 或 VF 裝置數量的限制，一般一臺裸金屬服務商只能直通 二三十個 Pod，Pod密度較低導致節點資源浪費。

IPVlan模式

IPVlan 是我們下一代網路方案，整體效能高於 Bridge 橋接模式，建議核心版本 4.9+，缺點是對 K8s Service 網路支援較差，所以我們在核心、runtime 以及網路外掛上做了大量的最佳化和修復。目前 IPVlan 網路模式已在灰度中，即將全域開放公測。

網路效能對比

下圖是各個方案網路效能對比：

Ping 時延頻寬(128B)頻寬(1024B)TCP_RRUDP_RRHost100%100%100%100%100% 網路卡直通100%100%100%98%92% Bridge140%82%80%77%75% IPVlan121%81%85%80%78%

總結

從 Ping 時延、不同頻寬、TCP_RR 和 UDP_RR 多個方面同時對比了這幾種網路方案，Host作為基準。可以看出，直通網路卡的效能可以做到接近host的效能，ipvlan和bridge與直通網路卡方式有一定差距，但前兩者通用性更好；總體來說 ipvlan 比 bridge 效能普遍更好。

另外，表中 Ping 時延的相對百分比較大，但實際上從數值差距來說只有零點零幾毫秒差距。

注：以上為內部資料測試結果，僅供參考。

多執行時(RuntimeClass)排程

Kubernetes 從 1.14.0 版本開始引入了 RuntimeClass API，透過定義 RuntimeClass 物件，可以很方便的透過 pod.Spec.runtimeClassName 把 pod 執行在指定的 runtime 之上，如 runc、runv、runhcs等，但是針對後續不同的 K8s 版本，對 RuntimeClass 排程支援不同，主要分為兩大階段。

1.14.0 <= Kubernetes Version < 1.16.0

apiVersion: node.k8s.io/v1beta1
handler: runv
kind: RuntimeClass
metadata:
name: runv
---
apiVersion: v1
kind: Pod
metadata:
    name: my-runv-pod
spec:
    runtimeClassName: runv
    nodeSelector:
        runtime:  runv
    # ...

低於 1.16.0 版本的 K8s 排程器不支援 RuntimeClass，需要先給節點打上執行時相關的 Label，然後再透過 runtimeClassName 配合 NodeSelector 或 Affinity 完成。

Kubernetes Version >= 1.16.0

從 K8s 1.16.0 版本開始，對 RuntimeClass 排程的支援得以改善，但從實現上，並不是在 kube-scheduler 的新增對 RuntimeClass 支援的演算法，而是在 RuntimeClass API 上新增了 nodeSlector 和 tolerations，此時使用者的 pod 上只需要指定 runtimeClassName 而無需指定 nodeSelector 或 affinity， kube-apiserver 的 Admission WebHook 新增了 RuntimeClass 的 Mutating，可以自動為 pod 注入 pod.spec.runtimeClassName 所關聯的 RuntimeClass 物件裡配置的 nodeSelector 和 tolerations ，從而間接地支援排程。

同時，由於很多新的執行時（如 安全沙箱）自身有 overhead，會佔用一定的記憶體和CPU，所以 RuntimeClass API 上新增了 overhead 用於支援此類場景，這部分資源在 Pod 的排程上也會被 kube-scheduler 計算。

新探索-可信/機密計算

很多使用者考慮到成本、運維、穩定性等因素去上雲，但往往因為對公有云平臺安全技術擔憂以及信任，很多隱私資料、敏感資料對雲“望而卻步”；往往現有的安全技術可以幫我們解決儲存加密、傳輸過程中的加密，但無法做到應用執行過程的加密，這些資料在記憶體中是明文的，入侵者或者雲廠商有能力從記憶體窺探資料。就是在這種背景下，可信/機密計算應運而生，它是基於軟硬體技術，為敏感應用/資料在記憶體中建立一塊 Encalve（飛地），它是一塊硬體加密的記憶體，任何其他的應用程式、OS、BIOS、其他硬體甚至雲廠商均無法解密這部分記憶體資料。

在此背景下，我們聯合了多個團隊，在 ACK 上研發了基於 Intel SGX 硬體加密的 TEE 執行時，可讓使用者的應用的跑在一個更加安全、可信的執行時環境中，幫助更多的使用者破除上雲的安全障礙，我們也將在 2020年Q1進行公測。

原文連結

本文為阿里雲原創內容，未經允許不得轉載。