始终很难在单个Kubernetes集群上安全地托管大量用户。主要原因是所有组织使用Kubernetes的方式不同，因此单个多用户模型不太可能对每个人都有效。相反，Kubernetes提供了用于构建自己的解决方案的组件，例如基于角色的访问控制（RBAC）和NetworkPolicies。这些组件越好，构建安全的多用户群集就越容易。
命名空间急救
到目前为止，这些组件中最重要的是名称空间。它们是Kubernetes中几乎所有安全和控制平面共享策略的基础。例如，RBAC，NetworkPolicies和ResourceQuotas默认情况下支持名称空间，而诸如Secret，ServiceAccount和Ingress之类的对象可在一个空间内自由使用，但与其他空间完全隔离。
命名空间具有几个关键功能，使其成为执行策略的理想选择。首先，它们可以用来表示property。大多数Kubernetes对象应该在任何名称空间中。通过使用命名空间表示所有权，您始终可以依靠那些对象来拥有所有者。
其次，只有具有适当权限的用户才能创建和使用命名空间。您需要提升的特权才能创建名称空间，而其他用户需要明确的权限才能使用它们-即在这些名称空间中创建，查看或修改对象。因此，首先创建具有精心设计的策略集的名称空间，只有在此之后，非特权用户才能创建“常规”对象，如Pod和服务。
命名空间限制
不幸的是，在实践中，名称空间不够灵活，并且在某些常见的用例中不太适合。例如，某个团队拥有多个具有不同机密和配额的微服务。理想情况下，他们应该将这些服务拆分为单独的名称空间，以将它们彼此隔离，但这带来了两个问题。
首先，这些名称空间缺乏一个所有权概念，即使它们都属于同一团队。这意味着不仅Kubernetes对这些名称空间只有一个所有者一无所知，而且还缺乏一次将全局策略应用于所有受控名称空间的能力。
其次，众所周知，自主性是有效团队合作的关键。由于创建名称空间需要提升的特权，因此开发团队中的任何人都不太可能拥有这些特权。换句话说，每当团队决定创建一个新的名称空间时，他们都必须联系集群管理员。对于一家小公司来说，这可能是完全可以接受的，但是随着它的成长，这种组织的负面影响变得更加明显。
层次命名空间简介
分层名称空间是Kubernetes多租户工作组（wg-multitenancy）为解决这些问题而开发的新概念。简化形式下，分层名称空间是一个常规的Kubernetes名称空间，其中包括一个指向一个（可选）父名称空间的小型自定义资源。这扩展所有权的概念的命名空间本身，而不仅仅是对象之内他们。
所有权的概念还实现了两种其他类型的关系：
- : namespace' . : subnamespaces, .
这解决了典型开发团队的两个问题。集群管理员可以为其创建一个“根”空间以及必要的策略，并将创建子空间的权限委派给团队成员。这样，开发人员可以创建供自己使用的子命名空间，而不会违反集群管理员设置的策略。
一点练习
分层名称空间是使用称为Hierarchical Namespace Controller或HNC的Kubernetes扩展实现的。HNC包含两个组件：
- Manager在群集中运行，管理子命名空间，分发策略对象，确保层次结构有效，并管理扩展点。
- 一个名为
kubectl-hns它的kubectl插件允许用户与管理器进行交互。
组件安装指南可在项目存储库的发行页面上找到。
让我们看一下HNC的工作原理。假设我没有创建名称空间的权限，但是可以浏览该名称空间
team-a并在其中创建子名称空间*。该插件允许我输入以下命令：
$ kubectl hns create svc1-team-a -n team-a
*从技术上讲，您在父空间中创建了一个称为“子名称空间锚”的小对象，然后HNC创建了一个子名称空间。
这将创建一个名称空间
svc1-team-a。请注意，子命名空间与常规Kubernetes命名空间没有什么不同，因此其名称必须唯一。
您可以使用以下命令查看结果结构
tree：
$ kubectl hns tree team-a
# Output:
team-a
└── svc1-team-a
如果父空间中有任何策略，它们将被复制到子*。例如，假设您
team-a有一个名为的RBAC RoleBinding sres。此RoleBinding也将出现在相应的名称空间中：
$ kubectl describe rolebinding sres -n svc1-team-a
# Output:
Name: sres
Labels: hnc.x-k8s.io/inheritedFrom=team-a # inserted by HNC
Annotations: <none>
Role:
Kind: ClusterRole
Name: admin
Subjects: …
*默认情况下，仅重新分配RBAC中的Roles和RoleBindings，但是您可以配置HNC传播任何Kubernetes对象。
最后，HNC将带有有关层次结构的有用信息的标签添加到这些命名空间。它们可用于应用其他策略。例如，您可以创建以下NetworkPolicy：
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-team-a
namespace: team-a
spec:
ingress:
- from:
- namespaceSelector:
matchExpressions:
- key: 'team-a.tree.hnc.x-k8s.io/depth' # Label created by HNC
operator: Exists
这一政策将传递到后代
team-a，并还允许所有这些命名空间之间的入口流量。只有HNC可以分配标签“树”。保证可以反映当前的层次结构。
HNC功能的详细信息可以在用户手册中找到。
后续步骤和参与过程
如果您认为分层名称空间在您的组织中有用，则可以在GitHub上 使用HNC v0.5.1版本（从8月28日开始发行v0.5.2 -ca. Perevi ..）。我们想知道您对此有何想法，您解决了哪些问题以及想要为其添加哪些功能。与开发初期的任何软件一样，在生产中使用HNC时必须小心。而且，获得的反馈越多，我们就能更快地达到HNC 1.0。
我们也欢迎第三方贡献者的贡献，无论是错误修复/有关他们的信息，还是帮助原型设计新功能，例如异常，改进的监控，分层资源引用或配置优化。
您可以通过存储库，新闻通讯或Slack与我们联系。我们期待您的评论！
最初的公告是由分层命名空间控制器的软件工程师兼技术主管Adrian Ludwin宣布的。
奖金！路线图和问题
请发布问题-越多，越有趣！将首先分析错误，并对功能请求进行优先级排序，然后将其包含在工作计划或积压中。
HNC尚未达到GA状态，因此在具有无法丢失的配置对象（例如，未存储在Git存储库中的配置对象）的群集上使用HNC时要小心。
所有HNC问题均包含在相应的工作计划中。目前，该计划的以下主要阶段已经实施或计划：
- v1.0：I结束-2021年第二季度开始；建议将HNC用于生产。
- v0.8：2021年初；新的关键功能可能会出现。
- v0.7：2020年底；最有可能出现v1beta1 API。
- v0.6: 2020-; v1alpha2 API .
- v0.5: 2020-; , .
- v0.4: 2020-; API production-.
- v0.3: 2020-; UX subnamespace'.
- v0.2: 2019-; non-production.
- v0.1: 2019-; . , - .
- : .
译者的PS
另请参阅我们的博客：