多租户管理的核心思想和架构设计

Posted 2021-05-18 twt企业IT社区

【导读】随着互联网技术的兴起，云计算平台不断的发展，云原生的理念已深入互联网技术浪潮。容器云作为云原生的基础服务平台，其技术成熟度已达到商业水平。多租户管理是容器云平台提供的基础核心功能之一，通过多租户管理，云平台可有效地控制故障范围，隔离多租户间的数据，提高数据安全性。本文系统介绍容器云多租户管理的核心思想和架构设计，帮助读者掌握不同场景下多租户的重要关注点，制定出相应的整体设计方案。

【作者】尹琛，阳光保险集团股份有限公司，科技中心技术管理部架构管理室处长。中央财经MBA。12年保险行业IT从业经历，精通企业级IT项目的开发和交付，熟悉保险公司IT运营流程，有丰富的容器云和大数据落地实施和平台运营经验。致力于打造有创新意识的团队，引导公司进行数字化、智能化变革与转型。

1 多租户需求

在金融业，无论是银行、证券还是保险，每个行业都有大中小规模的金融公司，往往规模大的公司以集团的形式出现，中小公司则是单一主体，企业的形态不同，对科技的要求也不同。

1.1 单一主体用户

对于单一主体，每个业务条线或部门均有各自的业务场景和业务系统，传统物理机和虚拟机在资源利用率和资源供给效率，以及资源动态扩缩方面存在一定的问题。

容器云需提高资源利用率。由于各业务条线或部门作业的周期不同，导致对系统资源的需求呈现一定的周期性和不确定性，如财务部门和监控报送部门的周期性工作，渠道和营销条线的临时性促销活动。容器云在物理资源准备方面，根据公司自身的情况，合理规划云平台的规模，整体层面可采用年度或半年规划，按需建设的方式，保障资源充足，留有一定的临时资源空间，保持机动性。

容器云需加快资源供给效率。金融公司在使用系统资源时，往往需求业务部门提交正式的资源申请流程，各相关部门进行审批，最后IT基础资源部门给予开通，这期间流程长，节点多，资源供给效率慢，经常出现活动结束了，资源还没申请下来的情况。从管理方面，可通过线上化、自动化、自助化等方式，减少审批节点，优化流程，自动化资源供给，按需及时分配，从而提高资源供给效率的问题。

容器云需提供完备的动态扩缩能力。无论是公有云还是私有云，在资源扩缩方面几乎毫无建树，均需求人工操作处理，这不符合现代系统的自动化要求，再加上资源给供效率低，常见的作法提前1-3个月准备资源，而且资源使用后仍不下架。借鉴业务系统开发框架的微服务理念，容器云应有整套的动态扩缩策略，保障业务系统的可用性。

另外，在资源的隔离方面，IT系统应有相应的规划，可以从业务条线和系统重要程度等维度考虑资源隔离策略。

容器云需提供按业务条线划分的隔离机制。根据架构原则，应按业务条线或类型规划泳道，除非异步通知外，各泳道间不能通信，保持良好的故障隔离和影响范围。容器云需有强大的网络防护策略，根据公司的实际情况，采用2层或3层网络，实现网络隔离。

容器云需提供按系统重要程度划分的隔离机制。重点系统和非重点系统的资源使用策略和故障影响范围不同，因此，应根据系统重要性，划分网络区域和工作区域，优先保障重点系统的资源使用。

1.2 集团公司用户

对于集团化公司，由于监管要求不同行业的公司数据避免交叉，集团化公司比单一主体的公司有着更多的需求和考虑。集团化公司至少要从以下两个方面规划建设容器云：

1.2.1 多数据中心

集团化公司常有多个数据中心，虽然各数据中心承担的职责不同，但基本都是两地三中心或异地多中心的模式，至少有两个以上的数据中心负责生产系统运营。因此，在集团化公司部署容器云时，应考虑在生产的数据中心中部署容器云，以满足数据中心的资源需求。

1.2.2 物理集群隔离

对于集团下属的子公司，可根据规模和重要性，规划建设容器云，合理搭配控股子公司和参股子公司，从集团层面制定相应的管理办法，在保持各子公司的独立性同时，又能起到集团资源共享的作用。

2 多租户设计

大规模的容器集群设计，需要考虑资源池管理、网络通信方案、存储方案、容器编排、日志收集、监控告警等诸多事项。为了满足企业用户的使用需求，需要引入容器的多租户（Multi-Tenancy）概念。

多租户技术既可以实现多个租户之间共享底层系统资源和管理资源，同时又可以实现各租户系统实例配置和资源配额的个性化定制。针对企业容器云平台多租户的使用场景，需要配合合理的隔离与管理机制，才能保证整个容器云平台的稳定性和可扩展性。

企业级容器云平台的资源隔离主要需要考虑以下几个方面。

2.1 物理部署隔离

多容器集群部署是最常见的资源物理隔离方式，为了保证租户间计算资源的隔离和分区合理性，容器云平台在搭建之初就需要考虑进行多集群部署，而企业多集群部署按照优先级顺序可基于网络隔离、基础设施隔离和经营主体隔离，下面分别进行介绍。

2.1.1 根据网络分区划分

一般大型企业，尤其是金融保险企业，出于安全和监管要求，会规划若干网络分区，各网络分区间使用防火墙控制交互权限。为了满足安全和管理要求，建议容器集群的搭建不要存在计算节点跨网络分区部署的情况，以免网络权限复杂混乱。

此外，根据对容器平台的定位和管理策略，容器平台可能需要在传统的网络拓扑上做相应的扩充，例如：

① 如果容器平台是金融云的一部分，则出于安全要求，容器网络拓扑必须支持租户间的隔离。

② 容器平台中的容器和宿主机都运行在网络中，容器运行应用属于业务计算资源，而宿主机运行容器属于底层资源，建议把容器所在的业务域和宿主机所在的资源域划分到不同的网络区，分别使用不同的管理和访问策略，以保留足够的灵活性满足不同的用户需求。

2.1.2 根据基础设施划分

企业为了满足高可用和容灾要求，自建服务器机房往往会选择进行多机房部署，机房之间在网络层面进行统一规划，然而即使使用高速网络连通，仍然无法避免各机房间存在因网络抖动等原因造成的无法预期的不一致故障，故原则上容器集群部署应避免跨机房部署，各机房分别搭建容器集群，对于高可用需求可考虑在上层服务层面进行多副本部署统一负载，而非增加底层容器计算资源的部署复杂度。

2.1.3 根据经营主体划分

如果容器化部署的系统涉及企业的多个独立经营主体，且各经营主体之间无高耦合的系统交互，则可分别搭建容器集群，以便保证各主体间资源的隔离和个性化运营管理要求。

2.1.4 物理部署隔离原则

总结下来，企业级容器集群的物理部署隔离应遵循以下原则：

① 如果企业内部规划了若干网络分区，且各网络分区间使用防火墙隔离，则各网络分区原则上必须分别搭建容器集群。

② 如果同一网络分区有基础设施隔离（多机房），则建议各基础设施分区分别搭建容器集群，以避免网络干扰。

③ 如果多主体共用同机房的基础设施，则只有各主体间存在较多个性化运营管理要求的情况下才建议分别搭建容器集群。

④ 多集群应尽量实现统一纳管。如通过搭建多套集群的方式实现了容器计算资源的物理隔离，出于管理角度还需要考虑多集群的统一纳管，使用自研或商业版平台工具实现各集群底层资源的统一管理，诸如集群的版本升级、资源扩缩、权限管控、监控告警等操作，通过管理平台的统一处理，以求降低管理成本。

2.2 逻辑隔离

除了通过集群独立部署进行物理隔离，容器集群内还可实现基于资源的逻辑隔离，这也是最常使用的隔离模式。

在多租户场景下，当多个用户或团队共享具有固定数目节点的集群时，自然而然需要考虑部分用户使用资源超出应有份额的情况，因此需要借助资源配额（ResourceQuota）定义资源，按类型限制命名空间下可以创建的对象的数量，同时限制可被该项目以资源形式消耗的计算资源的总量。

为了方便实施容器资源的逻辑隔离，需要首先明确可逻辑隔离的资源类型和容器部署的逻辑层级。

2.2.1 逻辑隔离资源

资源配额包括计算资源配额、存储资源配额、对象数量配额、网络资源配额、镜像仓库等，下面分别进行说明。

Kubernetes自带的资源配额的作用域是命名空间（Namespace）层级，一个命名空间中最多只应存在一个资源配额对象，对象作用于对应命名空间下的Pods，在多租户使用场景中，可根据各用户需求为用户的命名空间分配容器资源。

① 计算资源配额

计算资源是最主要的资源配额，也是多租户资源逻辑隔离的基础，计算资源配额主要包括CPU和物理内存两部分。

CPU资源在Kubernetes中以m作为单位分配，1000m代表1CPU线程计算资源，作用域为命名空间。可以限制对应命名空间下所有非终止状态的Pod中，其CPU需求总量不能超过配额。

物理内存在Kubernetes中以Mi作为单位分配，1024Mi代表1G物理内存，作用域为命名空间。可以限制对应命名空间下所有非终止状态的Pod中，其内存需求总量不能超过配额值。

Quotas-用来在项目级（租户级别）限制可使用多少资源

• 分为限制单个项目的quota和多个项目的clusterquota

• Quotas可以限制的资源类型包括计算资源、存储资源和对象数量

如下图举例：

Limit ranges用来在项目级（租户级别）对pod、container、image、image stream、pv级设置缺省资 源，如下图举例：

POD（应用级别）创建容器时的资源需求可以通过request和limit来设置：

• request-CPU和内存可以保证分配的最小资源量。当一个节点可以满足一个pod中所有容器的request，则这个节点可以作为一个可用节点。

• limit-CPU和内存可以使用的最大资源量。

② 存储资源配额

存储资源在Kubernetes以持久卷（Persistent  Volumes）的形式分配。一般可通过存储类（Storage Class）来限制存储资源的消耗，基于存储类来创建持久卷申请（Persistent Volume Claim，简称PVC），然后PVC会根据Pod的要求去自动绑定合适的PV给Pod使用。

管理员可以对给定工作负载下的存储资源总量进行限制。

存储访问模式：

存储配额申明举例：

③ 对象数量配额

Kubernetes中可以对给定类型的对象数量进行限制，主要支持以下类型：

表2-1 容器对象数量控制

④ 网络资源配额

在资源管理中，网络的管理是比较复杂的。容器应用中的网络资源广义上包括IP资源、端口资源、负载资源等。

对于企业级的容器集群，常用的网络协议包括以下几种：

• 隧道协议（Overlay，代表性的方案有OVS、Flannel等）

• 底层路由协议（Underlay，代表性的方案有MacVlan、Calico等）

同一集群可以只应用一种网络协议，也有可以采用网络多平面技术。

对于IP资源的分配可通过建立若干子网，限制Pod的IP自子网分配。

端口资源主要指计算节点（Worker）的端口占用，原则上要尽量避免租户使用NodePort方式暴露服务，而改用Ingress（例如HAProxy）等负载方式，避免主机端口资源耗尽风险。

⑤ 镜像仓库

镜像仓库负责存储和发布应用的镜像部署版本，在功能上并不复杂，但由于用于生产发布的镜像版本必须通过严格的测试阶段，因此建议在生产环境搭建专用的生产镜像仓库；同时，为了保证开发和测试的方便，在测试区搭建测试镜像仓库。

各镜像仓库的镜像管理也应遵循最小权限原则，各租户使用的用户应仅有对私有目录的读写权限，公有目录只提供只读权限，保证上线镜像的安全和稳定性。

除上述资源之外还包括GPU资源，监控告警资源等，各类资源都应遵循租户间隔离，租户内部自行分配的原则。

2.2.2 逻辑隔离层级

Kubernetes管理下的集群可以划分为以下部署层级：

• Pod

• 工作负载（Workload）

• 命名空间（Namespace）

• 项目（Project）

下面分别进行说明。

Pod

Pod是Kubernetes中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，也是在Kubernetes上运行容器化应用的资源对象，其他的资源对象都是用来支撑或者扩展Pod对象功能的，比如控制器对象是用来管控Pod对象的，Service或者Ingress资源对象是用来暴露Pod引用对象的，Persistent Volume资源对象是用来为Pod提供存储等等。

工作负载（Workload）

工作负载是一些由label-selecteor相关联的Pod组合，Pod通过工作负载实现应用的伸缩和升级等操作，而资源的“消费”策略，也一般在工作负载层定义。

关键工作负载包括ReplicaSet、Deployment、DaemonSet等，而Service也是在工作负载层定义。

ReplicaSet用于解决pod的扩容和缩容问题。

Deployment提供了官方的用于更新Pod和ReplicaSet（下一代的Replication Controller）的方法，用户可以在Deployment对象中只描述期望的理想状态（预期的运行状态），Deployment控制器则负责将现在的实际状态转换为期望的状态。

Deployment集成了上线部署、滚动升级、创建副本、暂停上线任务、恢复上线任务、回滚到以前某一版本（成功/稳定）Deployment等功能。

Service定义了Pods的逻辑集合和访问这个集合的策略，Pods集合是通过定义Service时提供的Label选择器完成的。

Service包括ClusterIP、NodePort、LoadBalancer三种模式，而Ingress基于Service实现7层路由转发能力，是更为常用的负载模式。

命名空间（Namespace）

Kubernetes集群可以同时管理大量独立的工作负载，而单一经营主体通常会选择将不同团队创建的项目部署到单一集群上。随着工作负载数量的增加，部署和资源分配管理的复杂度直线上升，这会降低容器管理效率和运行稳定性。

Kubernetes使用命名空间的概念帮助降低集群管理工作负载的复杂度。命名空间允许将工作负载分组到一起，便于将它们作为一个单元进行统一管理和控制，所以多租户资源配额分配的作用域一般是在命名空间级别。

命名空间还能够利用Kubernetes基于角色的访问控制（RBAC），支持将权限或功能列表分组，将角色对象类型（Role Object Type）应用于具体租户的命名空间，从而提供更好的控制和粒度。在角色创建后，角色绑定（Role Binding）可以将定义的权限功能授予单个命名空间上下文中的具体具体用户或用户组。通过这种方式，可以方便租户将相同的策略映射到组织好的资源集合上。

项目（Project）

如果单一命名空间无法满足租户的复杂度要求，那么往往需要为单个租户分配多个命名空间，这时可以引入项目（Project）的概念，项目是一组命名空间的抽象集合，各命名空间相互独立又具备一定管理上的共性，这时可以借助平台工具或者组织规范，将租户隔离的级别提升至项目，由租户自行负责项目下命名空间的资源分配，以达到降低管理复杂度的目的。

2.3 群资源管理

容器集群在使用过程中，难免会遇到集群资源扩缩、租户资源申请、租户资源回收等场景，对于集群资源的管理，原则上应在操作过程中尽量降低对当前运行实例的影响，并且任何资源变更都应有审计和记录。

对于多租户容器资源的申请、分配、管理，常见的两种做法是：

① 按照容量预估，预先为租户分配预测的计算和存储等资源，在容器平台中将这些资源分配到项目中使用，当需要扩容或删除某些资源时，重复相应的操作。

② 对接外部的资源管理和供给系统，通过调用外部系统的流水线接口，容器平台按需获取租户所需的计算和存储资源。

第一种做法的优势在于系统简单，不需要对接外部资源管理系统，适合技术验证平台，或容器资源不需要频繁变化的情况，而对于多租户的生产系统，基本上都应该考虑第二种做法，虽然带来了系统集成的复杂性，但容器平台可以借助外部的IaaS等系统，确保所申请的资源的高可用性，同时，线上流程化让资源申请和变更无需人工介入，因此能做到容器平台资源的按需自动申请和快速扩容。

本文是容器云大赛架构师岗课程之《多租户管理需求和设计》中的内容，如希望系统学习容器网络基础知识，可点击阅读原文到社区免费下载完整课程。学课程，拿认证，详情可点击>>>

觉得本文有用，请 转发、点赞 或点击 “在看” ，让更多同行看到

 资料/文章推荐：

• 
  

https://www.talkwithtrend.com/Topic/98447

下载 twt 社区客户端 APP

或到应用商店搜索“twt”