大家好,很高兴能在线上和大家做一些分享。感谢QoopCon给我们提供的平台。我今天分享的主题是借助RBAC与QoopFeed实现KBS的多级群与多组户管理。在开始分享之前,先做一个简单的自我介绍。我叫望鸿铭,目前就职于青云。我是QuizFail社区的核心贡献者,主导QuizFail多组户安全相关的SIG。热衷于开源与云原生安全领域,希望能和大家有更多的交流。我今天分享主要包含下面四个部分内容。首先,我会向大家分享一下QuizFail的多组户模型与架构。紧接着,我会讲一讲在多级群环境下,QuizFail是如何实现资源的软隔离。说到多级群,我会再展开讲一讲QuizFail是如何利用QuizFail实现跨级群的资源同步。在使用QuizFail的过程中,我们还采用了代理连接的模式来解决集群之间网络联通的问题。多组户是一种软件架构,指的是多个多组用户共用一个基础资源池实现软硬件资源的贡想。对于企业来说,多组户的意义在于大家可以共用一套系统,而不是拆分成多个独立的子系统进行管理,造成人力和计算资源的浪费。我们可以这样理解多组户,从服务提供者的角度来看,我们开发的一个服务运行时可以同时提供给多个客户使用,并且客户之间的数据是保持隔离的。从服务的使用者的角度来看,你我作为不同的客户同时使用一个公共的服务时,我们的业务是互相不受影响的,就好像在使用独享的服务一样。基于KBS的多组户方案,可以提高继续的资源利用率,实现统一管理与资源调度,降低开发运萎的成本。目前,KBS社区多组户主要有两个解决方案,虚拟集群和HNC也就是分层秘密空间,但是社区的活跃度和成熟度并不算太高。在我看来,主要的原因是因为多组户的形态多种多样,一个解决方案很难覆盖到全部的使用场景,很难抽象一个通用的组户模型。基于KBS的多组户根据使用者的规模不同,有非常多的形态。我简单的举几个例子。第一类是PASS化的容器平台。对类类似公有营的容器平台,因为组户之间是互相不信任的。对数据隔离、网络隔离、节点安全、容器运营时的安全都有较高的要求。第二类是大企业内部的容器平台。相对于PASS化的这类公有平台,企业内部组户之间的信任程度更高,但是需要适应更为复杂的组织架构,更注重逻辑层面的自愿隔离。第三类是小企业内部的容器管理平台。组织架构相对简单,组户之间的信任程度更高,只需要提供基本的逻辑隔离能力就可以满足使用。组织架构的定位是企业级的容器管理平台,所以需要以逻辑隔离能力为基础,尽可能多的提供网络、物理、隔离能力。KBS中并没有租户这样的概念,但是它提供的Name Space作为基础的自愿隔离单位。如图所示,RBEC访问权限控制,就是KBS的访问控制的核心功能。在真实的企业环境中,组织架构往往错综复杂。如果将Name Space作为最小的租户单元,我们在很难抽象出一个更小的授权单位。和HNC的做法类似,Gridfield选择了增加自愿层级这条路。在Name Space之上,拓展了一种叫做Workspace的自愿层级,作为最小的租户单元。在KBSFair的租户单元下,支持成员管理和自愿管理。租户下的成员之间,可以通过互相邀请的方式,邀请对方参与项目的协同。如图所示,一个Workspace可以纳管多个集群。一个集群也可以被多个Workspace所使用。Workspace在往下的自愿隔离层级就是KBS中的Name Space。一个Name Space只会属于一个Workspace。这里的Workspace并不表示一个特定的实体,更多的是一种层级的属性。我们学习了KBS的模式,将自愿进行了分层。除了KBS中ClusterName Space这两个层级,我们在KBSFair中还额外的增加了Global和Workspace这两个层级。不同层级需要负责管理集群中不同类型的自愿。比如Global这个层级需要管理的是平台用户,成员集群这一类高层级的自愿。第二级是集群层级。集群层级主要是针对单个集群下的自愿建议授权,可以允许平台中的用户去管理指定的集群。第三级是KBSFair中的租户层级Workspace。Workspace可以获得集群的使用权限。在Workspace这个层级下,主要关注的是Name Space,Workspace Member,这类直接归属Workspace管理的自愿。再往下就是大家熟知的Name Space这个层级。Name Space可以属于某一个Workspace。在Name Space下,我们更加测重的是对WorkloadSecretConfigMap这类KBS原生自愿的管理权限,为了能够实现Workspace层级的自愿隔离逻辑。KBSFair对KBS的API进行了拓展。在使用KBS的API Solver的时候,支持使用Workspace层级的访问权限控制。比如图中KBS下的Workspace路径,就表示访问的是Workspace层级的自愿。KBS的API Solver会根据Workspace下的角色去对用户进行建权。为了支持多集群环境,KBSFair还借助KBSFair将Workspace路与Workspace路搬领写入到所有的成员集群中。KBSFair控制屏面中最核心的部分就是借助KBSFair去分发数据。除了基于RBAC的逻辑隔离之外,KBSFair还支持了Workspace这个层级的自愿配额的管理。这里接建了OpenShift Resource Quota的做法。通过Validating Admission Webhook在Port创建的时候,对租户自愿配额进行检查。同一个Workspace下的Namespace,共享这个Workspace的配额设置。还可以和Namespace下的自愿配额同时作用于这个自愿的创建过程,不论是Namespace下的自愿配额超出限制,还是Workspace下的自愿配额超出了限制。自愿的创建都会被直接拒绝,以此来实现Namespace之间的配额共享。在多集群环境下,Coopersfield控制平面也可以借助Coopersfield去同步这些配额数据。我们再来讲一讲Coopersfield的多集群方案。在Coopersfield中,我们选择了Coopersfield VR作为多集群管理的核心。集群分为host,与member两种角色。通过Coopersfield,我们可以分发Coopersfield控制平面的核心数据,比如User,Workspace,Workspace row,Workspace row bounding等等。借助Coopersfield便捷的自愿调度,跨集群的编排能力,我们实现了多集群的管理功能。对着KBS集群的规模日益增大,多集群的管理诉求,也会变得越来越多。Coopersfield在去年发布的3.0的版本中,就支持了多集群的管理能力。在项目开始支出,我们并没有太多的选择,要么跟着Coopersfield走,要么选择自愿多集群方案。但是Coopersfield唯一的版本,却是达不到使用的要求,我们当时也犹豫了很久,但是随着Coopersfield VR版本发布,我们发现Coopersfield已经可以基本的满足我们的使用需求,比如提供基础的跨集群的调度能力,支持自愿的差异化配置,支持简单的集群调度策略等等。所以最终我们选择了Coopersfield VR,经过了两年的发展,像Kmada,OCM等诸多的多集群管理方案,也在逐渐的展露头角。这一位我们的多集群管理,提供了更多的选择。可以看到图中,Coopersfield最为核心的,两个就是Cluster Configuration和Type Configuration,我们需要将现有的CRD资源进行联邦化,可以通过Template去定义我们需要分发的联邦资源,通过Placement去指定我们需要将这个资源同步到哪些集群上去。通过Override的字段,我们可以去针对不同的集群进行差异化的配置。同时,Coopersfield VR,在设计之初,就考虑到了跨集群的DNS和调度的问题。Coopersfield 多集群管理,有两种形态,一种是传统的集群多管的方式。这种时候,使用者需要进入到单个集群中,去逐一的创建资源。这在我们需要将一个工作负载部署到多个集群中,就变得非常的复杂。这个时候,我们就支持了Coopersfield 提供的联邦项目与联邦的资源管理。我们可以利用Coopersfield 提供的跨集群的资源变派能力去实现我们刚刚。遇到的这个问题,我们可以去创建一个联邦的工作负载,跨集群的去对这个工作负载进行调度。同时,我们可以针对不同的集群进行差异化的配置,如图中所示,我们可以去指定我们需要调度的集群。我们需要调度的哪几个集群上面去,我们就进行勾选。为不同的集群进行差异化的配置,我们可以去配置环境面量,配置不同的启动命令等等。既然Coopersfield 这么好,那么我们为什么还总是电击着Kamada OCM?因为在实际的使用过程中,我们也遇到了非常多的问题。比如说,Coopersfield 提供的Coopersfield CTL 使用起来的非常的烦躁。创建联邦资源的时候,需要复杂的配置。将CRD 资源联邦化的过程中,会产生大量的中间对象。这些中间对象,如果需要通过命令行进行管理,会成为非常大的负担。除此之外,社区的火越度也一直不温不火。所以我们并没有将联邦项目作为多继群管理的唯一选项。我们尽可能的屏蔽Coopersfield 的底层实现,为多继群方案提供了更多的可能。其中一个比较典型的例子,就是集群的连接方式。在Coopersfield 集群联邦模式下,要求 Host 集群到 Member 集群的网络可达。传统的隧道代理方案,实施起来相对的比较复杂。我们提供了更为简单的代理连接的模式,通过 Member 集群运行的 Agent连接到公开的 Host 的集群,创建一个正常的代理隧道。基于这种方案,我们可以快速地进行集群纳管。上面两张图,较为详细的展示了这个代理连接的过程。受起手的启发,通过 Agent 与 Tower 组建,创建连接,建立一个加密的代理隧道。相较于直接连接 Member 集群,去控制 Member 集群的控制平面,这种方式。代理的方式,更加的安全。多集群环境下,Cosfair 对资源的访问权限控制,教验实际上是在 Member 集群中进行处理的。通过 Host 的集群中,对请求进行代理转发,这么做可以减小集群之间的数据同步的压力,不必再将集群之间的权限数据进行权量的同步,也保证了每个集群都可以进行独立的健全,不同的成员集群之间是对等的。即使 Host 的集群发生异常,对 Member 集群中的访问权限依旧受到预设角色的影响。同一个用户的资源请求,不论是直接发往 Member 集群,或者是通过 Host 转发到 Member 集群,最终的结果都会是一致的。通过 API Proxy,可以支持最简单的多集群纳管模式。我今天的分享就到这里,可能我描述不够仔细,但是你可以到CoopedFail 社区中和我们进行互动,再Select 与我们直接的交流。欢迎大家关注CoopedFail,关注CoopedFail 社区。谢谢大家。