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

 

導讀：隨着雲計算邊界不斷向邊緣側延展，傳統 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，這個版本雖然比較老，但穩定性非常好，經過大量的生產驗證。
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 有 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_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進行公測。

 

本文作者：stormx

原文鏈接

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