K8s多租户方案指南--图文篇
本篇文章是"啃"官方文档的第14篇,属于安全篇,关于多租户方案的总结。
一、两种“租户”场景
k8s官方文档里,对租户的概念进行了两种情况说明。
一种是多团队场景,即同一企业内多个团队共享一个k8s集群,每个团队可以操作一个或多个工作负载。 这些工作负载与位于相同或不同集群上的其他负载进行通信。
在这一场景中,团队成员通常可以通过类似kubectl 等工具直接访问 Kubernetes 资源。 不同团队的成员依赖一定程度的信任而共享集群资源, RBAC、配额和网络策略等 K8s 策略对于安全、公平地共享集群是重中之重。
这应该是“集约化”企业偏好的一种方案。
还有一种就是多客户场景,主要形式通常涉及为客户运行多个工作负载实例的软件即服务 (SaaS) 供应商。
在这种情况下,客户无权访问集群; 从他们的角度来看,K8s 是不可见的,仅由供应商用于管理工作负载。 除成本优化首要问题外,K8s 策略如何确保工作负载彼此高度隔离亟需解决。
1.1 到底是multi-team-tenancy,还是multi-customer-tenancy?
K8s 官方文档中,对“租户”没有单一的定义。 相反,租户的定义将根据讨论的是多团队还是多客户租户而有所不同。
在多团队使用中,租户通常是一个团队, 每个团队部署少量工作负载,这些工作负载会随着用量而发生伸缩。 然而,“团队”的定义本身可能是模糊的, 因为团队可能被组织成更高级别的部门或细分为更小的团队。