来自AI中国网 https://www.cnaiplus.com
知行学院是青云QingCloud 为广大 CIO、架构师、开发者、运维工程师、技术爱好者提供的一个云计算、大数据、容器等技术的最佳分享与实践平台。其中包括线上技术公开课、云产品解析、线下实践课堂、行业沙龙等众多知识分享形式。
本次我们邀请了青云QingCloud 容器平台研发工程师万宏明，带来《如何打造一个企业级 Kubernetes 发行版》。
正文：
本期分享主要有三部分内容，首先带大家了解什么是多租户，以及 K8S 下的多租户面临着哪些难题，接下来向大家介绍 KubeSphere 的多租户设计，最后给大家简短的展示一下 KubeSphere 的角色管理功能。
第一部分: Kubernetes 下的多租户难题
首先我们来了解一下什么是多租户及为什么需要多租户架构。
多租户是一种软件架构，指的是多个、多组不同用户共用一个基础资源池，实现软、硬件资源的共享。
对于一个企业来说，多租户系统的意义在于，大家可以共用一套系统，而不是拆分成多个子系统独立管理，造成人力和计算资源的浪费。
我们可以这样理解多租户：
从服务提供者的角度看，我们开发的一个服务运行时可以同时提供给多个客户使用，并且客户之间的数据是保持隔离的。
从服务使用者的角度看，你我可以作为不同的客户同时使用同一个公共服务，此时我们的业务是相互不影响的，就好像在使用独享的服务一样。
基于 Kubernetes 的多租户方案可以提高集群的资源利用率，实现统一管理，统一调度，统一运维，降低开发运维成本。
熟悉 Kubernetes 的同学可能知道，开源社区很早就有相关的讨论组，但是实质进展非常的慢，主要原因在于多租户的形态多种多样，很难覆盖全部使用场景。
要想真正将 Kubernetes 落实到企业的生产环境中，多租户就是一个不可逾越的难题。
基于 Kubernetes 的多租户根据使用者的规模不同，有非常多的形态，这里列举几个典型的例子：
PaaS/SaaS 化的容器平台
这种类似公有云的容器平台，因为租户间是互不信任的，对数据隔离、网络隔离、节点安全，容器安全的要求非常高。
大企业内部的容器管理平台
相对于 PaaS/SaaS 这类公有平台，企业内部租户之间信任程度更高，但也面临着更加复杂的组织架构，更深更细的权限划分，更注重的是逻辑层面的数据隔离。
小企业内部的容器管理平台，
租户之间的信任程度更高，只需要基本的数据隔离能力，提供基础的网络隔离就能满足他们的使用。kubctl + k8s dashboard 已经可以满足正常使用了。
KubeSphere 定位为企业级容器管理平台，我们的目标和方向自然是第二类大企业客户，助力容器技术在传统企业中落地。
我们遇到了下面这些问题：
一是租户之间的数据隔离，包括逻辑上的隔离和物理上的隔离。
K8S 中并没有租户这样的概念，但是提供了 namespace 作为基础的资源隔离单位，还提供了基于 RBAC 的权限管理方式，可以说只要是基于 K8S 的多租，都离不开 namespace，和 RBAC 这两个核心内容。
二是租户之间的网络隔离，虽然 K8S 提供了 NetworkPolicy 来限制不同 namespace 之间的网络通讯，但往往无法满足企业的使用需求，比如说带宽控制和流量监控。
三是权限控制，K8S 提供的 RBAC 只实现了 cluster、namespace 两个层级的权限管理。比如说 OpenShift，他们是这么做的，每个用户都在不同的 project 下，这个 project 实际上映射到 K8S 中就是一个 namespace，把 namespace 作为一个租户的边界，借助 K8S 的 RBAC 就可以实现租户的权限管理，我们在 KubeSphere 的社区版中也是这么做的，但是在一些客户的实际使用中我们发现，一个租户一个 namespace 往往不能满足他们的使用需求，我们需要面对非常复杂的人员组织架构。
四是多租户环境中的安全问题，网络隔离已经能在一定程度上保证集群的安全了，但在容器安全和节点安全上 K8S 做的还不够。
第五点，作为一个容器管理平台，面向多租户的日志、审计和监控也是非常重要的，虽有 prometheus、EFK、open-tracing 这么多优秀的产品助力，但他们在多租户的支持上非常弱。
面对诸多阻碍，我们需要寻求一个低成本的解决方案，直接 hack K8S 肯定是不行的，下面给大家带来 KubeSphere 的多租户设计方案。
第二部分 KubeSphere 的多租户设计
这是 K8S 开源的 dashboard，可以说是非常的简洁，基本上已经可以满足一个小企业的使用需求，通过这个项目可以很直观的对 K8S 集群进行可视化的操作。
但真实的客户使用场景往往是这样的：
复杂的用户层级、资源层级，细致的权限划分。
namespace 作为权限管理的最小单位，如果我们继续沿用之前的方案，就是一个租户一个 namespace， 租户下再很难划分出组织机构、部门等权限管理层级，但在大企业多租环境下往往一个部门、一个小组会被分配到一个 namespace 中，那么一个租户则需要跨好几个 namespace 进行协同。
为此我们在高级版中重新对租户进行了抽象，在 K8S 原有的 RBAC 基础之上，新增了一层企业空间（workspace）作为租户的权限边界，租户下可以有多个 namespace，namespace 下再设管理员，这就意味着每个租户都可以拥有多个层级的资源。
我们重新定义了租户，还需要考虑如何对租户的权限进行控制。
KubeSphere 多租户权限控制
这张图是 KubeSphere 中多租户管理的一个概览，可以看到对整个集群的管理分为了三级。
这里是集群层面的资源，包括用户、企业空间也就是租户、还有平台的管理，所有集群中的资源访问都需要相应的授权。
这里是租户层面的权限管理，包括成员管理、组织机构管理、项目管理、devops 工程管理，以及针对租户的配额设置
再到第三层就是项目和工程的权限管理，包括各类应用负载、网络、存储、configmap、secrets 的权限等等，可以非常灵活的进行控制。
对应到真实的企业环境中，集群对应一个集团，企业空间可以是分公司，企业空间下创建不同的项目(namespace)再分配给企业空间下不同的成员或组织机构，企业空间下成员之间的项目还可以相互共享，不同成员创建的项目也是相对独立的。
这样能满足一个企业用户的基本使用场景。
这是一张角色概览图，从集群到租户、再到项目，每个层级都有一些预置的角色可以直接使用。
比方说集群下有集群管理员、企业空间的管理员、普通用户，还可以创建用户管理员这样的角色。
企业空间中的角色会在企业空间创建之后自动生成，暂时不支持自定义角色。
企业空间下的普通用户可以创建项目，但每个用户创建的项目是互相看不到的，企业空间的管理员则可以看到企业空间下所有的项目。。
项目内的权限管理就非常灵活了，作为一个项目的管理员，可以灵活的定制项目角色，将你的项目共享给其他同事。
有了一个清晰的租户模型，还需要考虑的 API 的权限校验。
因为存在大量封装的租户 API、第三方服务（日志、监控等），我们很多的服务并不适合直接聚合到 kube-apiserver 中。
我们做了如下的架构：
最上层是我们的 API Gateway，他是我们 Kubesphere 的流量入口，主要实现用户的认证、鉴权和代理请求。
再到内部就是我们的 Tenant API， 包括 iam api、resources API，监控和日志的 API，我们都针对多租户场景进行了封装，而不是直接 hack 基础服务。
所有的租户 API 都构建再这些基础服务至上，包括 普罗米修斯、jenkins、K8S 等等。
有了这样一个统一的入口，我们的 API 可以很方便的开放给企业用户，与他们的账户系统、监控告警系统、日志系统进行集成。
KubeSphere 多租户数据隔离
刚刚说到的的权限控制已经做到了第一点，K8S 中 namespace + RBAC + workspace，已经可以做到不同租户之间逻辑层面的数据隔离。
针对要求更高的用户我们还需要实现运行环境的物理隔离，实现节点独享，或者是特定的节点调度，我们会在高级版中通过 nodeSelector，节点亲和性，再或是 Taints、tolerations 实现，我们要做的就是保证 Tenant API 不被 hack， 在部署应用的时候将非法数据过滤掉。
docker runtime 基于 cgroup 已经提供了基础的运行时隔离环境， 每个应用都运行在自己独立的环境中，配合 PodSecurityPolicy 已经可以满足大部分场景，特殊情况下以可以使用 kata 替换掉 runC，但这里有一个显著的问题就是 kata。
除了数据隔离，网络隔离也是重中之重。
常见的方式是使用 NetworkPolicy , Calico 已经提供了支持。
NetworkPolicy 这个概念可以类比虚机里的安全组，因为我们知道 K8S 只有一张网络，所以每个租户配的 NetworkPolicy 规则也都是作用在一张网上，它的隔离性其实比较弱，因为在一张网上，只解决了通和断的问题，像带宽控制、流量监控这些都很难实现。
这里不得不说我们青云自研的 QingCloud SDN 3.0 方案，可以完美衔接 K8S，为多租户环境提供强大的网络定义，分割能力，它实际上适用的场景非常多。
在 KubeSphere 场景中，每个企业空间（租户）的创建都会同时出实话一个 VPC 网络，不同的项目(namespace)会分配一个独立子网，通过 SDN 直接映射到 IaaS 底层的真实网络，这种方案的易用性相比 NetworkPloicy 来说就要好很多，不同的租户之间网络天然的强隔离，不需要每次都创建 NetworkPloicy，还可以灵活的控制租户下项目之间的网络通断，虽然方案更重了，为容器平台在企业生产环境中的落地打下坚实的基础。
KubeSphere 多租户集群安全
启用网络隔离，可以极大的保护租户的安全。在此基础之上还可以尝试kata提供的更安全的运行时环境。使用 PodSecurityPolicy 限制不可信容器的行为，保护系统和其他容器不受其影响，除了租户权限。容器中如果有用到的 ServiceAccount 也要合理的限制权限。
安全问题不容忽视，社区在飞速发展需要关注最新的动态，更新运行环境，减少漏洞的影响。
视频最后是一段简短的 Demo，期待更多的同学关注到我们的产品。
参考资料:
来自AI中国网 https://www.cnaiplus.com
本文网址：
