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

導讀：隨着雲計算邊界不斷向邊緣側延展，傳統 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 等虛擬框架，擴展性較差，不支持設備熱插拔。

• LibraryOS

基於 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，這個版本雖然比較老，但穩定性很是好，通過大量的生產驗證。
4. 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。

2. default 類，較老的接口，無Pod語義，社區會逐漸廢棄此類接口。

   1. /stats
   2. /stats/container
   3. /stats/{podName}/{containerName}
   4. /stats/{namespace}/{podName}/{uid}/{containerName}

3. 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 路徑，可在宿主機上直採容器內日誌文件。

2. 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 有 Overlay二、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_RR

UDP_RR

Host

100%

100%

100%

100%

100%

網卡直通

100%

100%

100%

98%

92%

Bridge

140%

82%

80%

77%

75%

IPVlan

121%

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 計算。

參考：
• runtimeclass issue：https://github.com/kubernetes/enhancements/pull/909
• runtimeclass kep：https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md （已加入1.16.0）
• pod-overhead: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md

新探索-可信/機密計算

不少用戶考慮到成本、運維、穩定性等因素去上雲，但每每由於對公有云平臺安全技術擔心以及信任，不少隱私數據、敏感數據對雲「望而卻步」；每每現有的安全技術能夠幫咱們解決存儲加密、傳輸過程當中的加密，但沒法作到應用運行過程的加密，這些數據在內存中是明文的，入侵者或者雲廠商有能力從內存窺探數據。就是在這種背景下，可信/機密計算應運而生，它是基於軟硬件技術，爲敏感應用/數據在內存中建立一塊 Encalve（飛地），它是一塊硬件加密的內存，任何其餘的應用程序、OS、BIOS、其餘硬件甚至雲廠商均沒法解密這部份內存數據。

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

原文連接

本文爲阿里雲內容，未經容許不得轉載。