K8s 的 Namespace 用于实际承接业务应用的部署

K8s 的 Namespace ，用于实际承接业务应用的部署，是管理的最小单元。

租户和项目在实现上是一个 CRD ，用户只需要在管控 K8s 集群上创建租户和项目的 CR，KubeCube会将租户和项目的 CR 实时同步到所有的计算 K8s 集群。运维人员可以集中式的管理所有的计算 K8s 集群，新增集群时会自动同步租户项目等基础信息，项目管理员只需要在任一 K8s 集群（包括管控和计算集群）创建命名空间即可。

租户、项目和命名空间三者之间的关联关系是通过层级命名空间实现的 ，每一个租户都关联一个 Namespace ，每一个项目也都关联一个 Namespace ，通过租户和项目的Manifest里 .spec.namespace 字段指定关联的 Namespace 名称。租户和项目关联的命名空间与实际承载应用的命名空间不同，它是为了解决管理员仅可以在拥有权限的租户和项目下面创建命名空间而引入的一个特殊命名空间。

为了避免供应商锁定和更好的兼容原生 K8s 能力，KubeCube 的权限模型是基于 K8s 原生的 RBAC 能力实现的，我们期望项目管理员仅可以在他拥有权限的项目下面创建命名空间。假设授权给一个项目管理员 ClusterRole 定义赋予创建 Namespace 的权限，由于 Namespace 是集群级别资源，那么他将拥有超出项目范围任意创建命名空间的权限，这与我们的期望不符合。

这里我们引入 HNC （The Hierarchical Namespace Controller）的 SubNamespace 的概念，它是命名空间级别的资源，负责自动生成和控制 Namespace 的生命周期。在 KubeCube 的设计中，租户和项目管理员都没有直接创建命名空间的权限，他们通过拥有创建 SubNamespace 的权限来间接获得创建命名空间权利。 SubNamespace 是命名空间级别的资源，通过 RBAC 限制 SubNamespace 操作权限，租户管理员只能在自己租户关联的 Namespace 下创建 SubNamespace ，项目管理员只能在自己项目关联的 Namespace 下创建 SubNamespace ，再由 HNC 控制器组件根据 SubNamespace 自动创建 Namespace ，最终实现管理员仅可以在拥有权限的租户和项目下面创建命名空间的权限。

实际使用中，用户创建租户和项目的 CR 时，KubeCube 程序会自动监听并创建相应的 SubeNamespace ，再由 HNC 控制器监听并创建 Namespace ，继而将租户和项目与命名空间关联起来。

KubeCube 租户模型采用多层级命名空间的设计除了考虑权限限定能够兼容原生 K8s 的 RBAC 外，还额外考虑到一个因素是可以放置租户级的公共配置和项目级的公共配置，如针对整个项目的统一监控配置。在必要的时候，还可以指定 HNC 控制器将父级命名空间的资源复制传递到子命名空间，如用户权限绑定 RoleBinding 配置。