華爲雲容器實例服務，它基於 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容器和多租隔離等場景的能力補齊和生態發展。