華為雲容器例項服務，它基於 Kubernetes 打造，對終端使用者直接提供 K8S 的 API。正如前面所說，它最大的優點是使用者可以圍繞 K8S 直接定義執行應用。
這裡值得一提是，我們採用了全物理機的方案，對於端到端資源利用率有一個很大的提升。而在 K8S 之上我們通過一層封裝實現了超規模資源池。大家知道 K8S 現開源的版本最大隻能支援到5000節點，並且這是在 Google 雲上的驗證結果，而在很多其他的雲平臺往往達不到。主要是受限於底層網路和儲存系統。
所以在華為雲，我們的做法是通過一層封裝和引入Federation來獲得整體服務的超大規模。同時因為 K8S 原生多租能力非常有限，所以我們選擇將額外基於租戶的驗證、多租限流等工作放在這一層封裝中實現。但對於應用定義等介面，則是直接透傳 K8S原生的API資料，只是在呼叫過程中增加如請求合法性等的校驗。圖中右側的容器網路、容器儲存，現有的開源方案是無法滿足的，所以華為雲採用自研的策略。
租戶概念和網路隔離
前面已經講過，K8S 原生並沒有租戶概念，只有一層以 Namespace 為邊界的隔離。在 Namespace 這一層，除了API物件的可見性隔離，K8S 還提供了 Resource Quota（資源總和限制）以及 Limit Range（定義每個Pod、Container能使用的資源範圍）等精細的配額管理能力。而在華為雲上，我們設計的租戶模型是：租戶（使用者）、專案、Namespace 三層模型，方便使用者管理多個專案的開發、測試、生產等不同階段。
網路隔離方面，採用多網路模型，一個專案中可以定義多個VPC，VPC 和 Namespace 是一對多的關係。使用者可以結合實際需要將開發、測試階段的應用部署在同個 VPC 的不同 Namespace 中便於除錯和問題定位，生產環境部署在擁有單獨 VPC 的 Namespace 保證不受其他活動干擾。
Runtime安全與隔離
再看 Runtime，由於是全物理機的模式，節點被不同的租戶共享，普通docker容器無法滿足Pod間的隔離性要求，Runtime採用的是安全容器（即早期的runV，現在的Kata Container）。使用安全容器的主要思路，就是在Pod外圍包一層輕量級虛擬機器，這樣既保證了Pod間的隔離性，又相容了K8S原生Pod內容器共享網路和儲存的設計。而包裝這層輕量級的虛機，因為裡面只需要執行容器，可以通過裁剪等手段優化到與普通容器相同數量級的啟動時間。
介面層面，按照社群現在的進展，推薦的做法是使用 CRI (container runtime interface) 直接對接安全容器的CRI-shim實現。不過因為專案啟動很早，CRI尚未成熟，我們採用的是在 Docker 內部分支處理的方案：在容器引擎服務中，仍然是原來的邏輯，直接建立普通容器；而在我們的容器例項服務裡，通過 Docker API 呼叫建立出來的則是安全容器。使用者原本使用 Docker 容器的習慣幾乎沒有改變，在指定容器映象時也是需要指定所需執行的 Docker 映象，外層輕量級虛機的映象直接由宿主機提供。這樣既解決了安全隔離的問題，又不會給使用者帶來額外的切換成本。
最後，讓我們來回顧一下本次分享的關鍵內容。
首先，我們基於 Kubernetes 構建了華為雲容器例項服務的核心部分，在其上封裝實現了多租戶的定義和訪問隔離。對使用者來說，最大的好處是可以使用原生 K8S 的 API 和命令列，不需要感知 K8S 叢集和底層資源，不需要在使用前建立叢集，使用過程中也不用擔心叢集出現任何問題，完全由平臺自身來保證服務的可用性。
其次，在計算資源隔離方面，我們採用是Docker原生API後端對接 kata container，可以最大限度相容兩個專案的生態。而對於終端使用者來說，使用者只需要知道安全隔離足夠可靠。而在網路隔離方面，採用多網路的模型，使用者可以定義多個 VPC，將 Namespace 和應用建立到不同的 VPC 中，以此實現彼此之間的隔離。
此外，針對高效能運算場景，我們還完成了GPU、FPGA加速晶片的分配排程優化，配合高效能網路與本地儲存加速，進一步提升了端到端計算效能。
結語
以上是華為雲對Kubernetes在Serverless Container產品落地中的實踐經驗。隨著產品的成熟，我們也計劃將一些共性的增強點回饋社群，推動Kubernetes在面向Serverless容器和多租隔離等場景的能力補齊和生態發展。