当前 Kubernetes 已经成为名副其实的企业级容器编排规范，很多云平台都开始提供兼容 Kubernetes 接口的容器服务。而在多用户支持方面，多数平台选择直接提供专属虚机集群，用户需要花费大量精力处理集群规模、资源利用率、费用等问题。

本次分享带来的是华为云在基于 K8S 构建企业级 Serverless Container 平台过程中的探索与实践，涉及容器安全隔离、多租管理、Serverless 理念在 Kubernetes 平台的落地等相关内容。

Kubernetes 在华为云的历程

首先来了解一下华为云在 Kubernetes 的发展历程。2014 年，华为云就开始研究并使用 Kubernetes，早期的重点是将 Kubernetes 应用在私有云环境中。2016 年，华为公有云上发布了容器引擎平台 ( CCE），它的形式与市面上多数的公有云Kubernetes服务（如 GKE、AKS） 类似，是给用户提供完整一套托管的K8S集群。而在今年年初，华为云发布了 Kubernetes 容器实例服务（Serverless Container），不过它与业界一些传统的容器实例服务不太一样。

容器的三大好处，为应用而生
众所周知，容器技术有三大好处。一是它提供资源隔离，用户很容易通过应用合设来提升资源利用率；二是，它具备秒级弹性的能力。因为容器本身技术特点，不用加载重型虚拟化，所以它可以做到非常快速的弹性扩缩容；三是，容器镜像技术，解决了包括应用及其依赖环境的一致性问题，简化业务交付流程。

但在实际环境中，容器技术带来的终端便利有多少呢？这还得从Kubernetes的使用形态谈起。

Kubernetes 的常见使用形态

私有云部署Kubernetes
人们使用Kubernetes的一种常见形式就是在自己的数据中心搭建集群。

这种做法的优点在于：第一，可以享受DIY过程带来的乐趣和成就感（当然也可能随使用时间的增长，问题越来越多而变成苦难）。第二，在全套私有化的模式下，数据请求都在本地处理，不会存在隐私顾虑。第三，资源规划、集群安装部署升级，都是用户自己端到端控制。

但是缺点也很明显：首先，很多人在自建时只看中了 Kubernetes，对周边配套并没做过很深度的研究，在实施过程中就会面临网络、存储等配套系统的选型问题。其次，用户需要负担 100% 的运维成本，而且资源的投入往往是一次性（或阶段性的），投入成本门槛非常高。此外，在自建的环境中 Kubernetes 的集群数量、中的单个集群规模往往不会很大，所以业务部署规模比较大时，弹性伸缩还会受限于底层资源规模，偏偏硬件资源的扩容速度往往慢得不可想象。最后，开发者习惯于做比较多的资源预留，因此资源利用率也非常有限。也就是说，自建者还要为全套资源利用率买单。

公有云半托管Kubernetes专属集群

第二种 Kubernetes 的常见形态是公有云的（半）托管集群。可以这样理解，用户购买一组虚机，云平台则自动在这些机器上部署一套 Kubernetes，而半托管含义在于有些平台，它的控制面可能是附送的。

这种形态的优点是：

（1）用户自己拥有集群，不用担心与其他用户共用一套 Kubernetes 可能引起一系列干扰问题。

（2）云平台在提供 Kubernetes 服务时，往往经过大量的测试和调优，所以给出集群的配置是在自家平台上的最佳实践。用户通过这种模式在云上运行 Kubernetes，可以获得比自己部署运维好很多的体验。

（3） Kubernetes 社区发布新版本后，云平台会至少做一轮额外的测试、问题修复，再上线并推荐用户升级。这用就节省了用户对升级时机评估的工作量。而直接使用开源版本的用户，如果对新版本跟进太快，自己要踩很多坑，但要延后到哪个版本再升，则要持续跟进社区bug和fix的进度，费时费力。

（4）当用户的 Kubernetes 出现问题时，可以从云平台获得专业的技术支持。所以在公有云上使用（半）托管的 Kubernetes 服务，是一种很好的成本转嫁方式，运维成本与云平台共同分担。

当然仍有一些明显的缺点，首先还是价格，当用户购买一组虚机，需要付出的价格是 虚机 Flavor 单价 乘以 节点数量 N。其次，因为用户独占一套 Kubernetes 集群，规格不会太大，整体资源利用率仍然比较低。即使尝试调优也效果不大，况且多数情况下用户名不能完全自定义控制面组件的配置。另外，当集群空闲资源不多而业务需要扩容时，还必须先扩集群，端到端的扩容会受限于虚机的创建时间。

容器实例服务

第三种，严格说是用户使用容器的形态，使用公有云的容器实例服务。

它的优点显而易见：用户不感知底层集群，也无需运维；资源定价颗粒度足够细，用多少买多少；真正的秒级扩缩容，并且是秒级计费。

其缺点在于：很多平台的容器实例服务主要提供私有API，并不能很好兼容kubernetes的API，而且容易被厂商绑定。
迫于满足用户使用K8S API的需求，这些容器实例服务也推出了基于virtual-kubelet项目的兼容方案。通过把整个容器实例服务虚拟成 Kubernetes 集群中的节点，对接 kubernetes master 来处理 Pod 的运行。

然而，由于整个容器实例服务被虚拟成了一个超级节点。Kubernetes 中原本针对多节点精心设计的一系列应用高可用相关特性都无法生效。另一个问题是这个基于virtual-kubelet项目的兼容方案在数据面并不完整，这里包括项目成员在Kube-proxy部署层级位置上的摇摆，以及仍无音讯的容器存储如何兼容。
如何基于 K8S 多租能力构建 Serverless Container

看了前面这么多的背景，你可能不禁要问：为什么不尝试使用 Kubernetes 的多租方案来构建 Serverless Container 服务？实际上基于 Kubernetes 多租来构建容器实例服务，优点有很多，最大的在于是支持 K8S 原生 API 和命令行。用户围绕 Kubernetes 开发的应用都以直接在基于 K8S 的 Serverless Container 上部署和运行。因为容器可以做到秒级计费，用户可以享受容器实例服务价格门槛较低的特点。另外，这种形态下通常是云平台来运维一个大资源池，用户只需为业务容器的资源付费，不需要关心底层集群的资源利用率，也没有集群运维的开销。

这种形体现存的主要挑战是 K8S 原生只支持软多租，隔离性等方面还有有欠缺。

接下来我们回顾一下 K8S 中典型的多租场景。

第一是 SaaS 平台，或其他基于 K8S 封装提供的服务，它不直接暴露 K8S 的 API。因为有一层自己的 API 封装，平台可以做很多额外工作，比如自己实现租户定义，所以对于 k8s 控制面的租户隔离要求较低。而应用来自最终用户，并不可信，所以实际上在容器运行时，需要较强的数据面资源隔离和访问控制。

第二小公司的内部平台。用户和应用都来自于公司内部，互信程度比较高，控制面和数据面都不需要做过多额外的隔离增强。原生的 K8S 就能满足需要。

第三是大型企业的平台，这种场景下 K8S 的用户，基本来自于企业内部的各个部门，开发部署的应用也是经过内部的验证之后才可以上线。所以应用的行为是可信的，数据面不需要做太多的隔离。更多的是要在控制面做一些防护控制，来避免不同部门、业务之间的管理干扰，如API调用时，需要实现针对租户的限流。

第四种场景，在公有云上对外提供一个多租的 K8S 平台，它对控制面和数据面的要求都是最高的。因为应用的来源不可控，很可能包含一些恶意代码。而 K8S 的 API 直接暴露给最终用户，控制面的隔离能力，如区分租户的API限流、访问控制等都是不可或缺的。

总结一下，对于 K8S 来说，如果要在公有云场景下提供 Serverless Container 服务，需要解决三大类挑战。一是租户概念的引入、访问控制实现。目前 K8S 仍然没有原生的租户概念，以 Namespace 为边界的并不能很多好适配多租场景。二是节点 (计算资源) 的隔离还有 Runtime 的安全。三是网络隔离，K8S 默认网络全通的模式在这种景下会有很多问题。