层次命名空间简介

作者:阿德里安·卢德温(Google)

在单个捕鱼大亨网络版集群上安全地托管大量用户一直以来 是一项麻烦的任务。主要原因之一是不同的组织 以不同的方式使用捕鱼大亨网络版,因此没有一种租户模式适合 大家。相反,捕鱼大亨网络版为您提供了构建自己的构建基块 租户解决方案,例如基于角色的访问控制(RBAC)和NetworkPolicies; 这些构件越好,安全地构建多租户就越容易 cluster.

租赁命名空间

到目前为止,这些构建块中最重要的是命名空间,它形成了 几乎所有捕鱼大亨网络版的骨干都控制平面安全性和共享 政策。例如,RBAC,NetworkPolicies和ResourceQuotas都尊重 默认情况下是名称空间,以及Secrets,ServiceAccounts和 入口可自由使用 任何一个名称空间,但完全隔离 from 其他 命名空间。

命名空间具有两个关键属性,这使其成为执行策略的理想选择。 首先,它们可以用来 代表所有权。大多数捕鱼大亨网络版对象 必须 位于名称空间中,因此,如果使用名称空间表示所有权,则表示 总是可以指望有一个所有者。

其次,名称空间具有 授权创建和使用。只要 特权较高的用户可以创建名称空间,而其他用户则需要显式 使用这些名称空间的权限-即在其中创建,查看或修改对象 这些名称空间。这样可以通过适当的方式精心创建它们 策略,然后无特权的用户可以创建“常规”对象,例如Pod和 services.

命名空间的限制

但是,实际上,名称空间不够灵活,无法满足某些常见用途 案件。例如,假设一个团队拥有多个微服务, 不同的秘密和配额。理想情况下,他们应该将这些服务放入 不同的名称空间以将它们彼此隔离,但这提出了 two problems.

首先,这些命名空间没有通用的所有权概念,即使 他们都属于同一支球队。这意味着如果团队控制 多个名称空间,不仅捕鱼大亨网络版没有任何记录 共同拥有者,但命名空间范围的策略不能在所有对象之间统一应用 them.

其次,如果团队能够自主运作,它们通常会表现最佳,但是由于 命名空间的创建具有很高的特权,因此, 开发团队可以创建名称空间。这意味着无论何时团队想要 一个新的名称空间,他们必须向集群管理员提出问题。而 这对于小型组织来说可能是可以接受的,它会产生不必要的 随着组织的发展而辛苦工作。

引入分层名称空间

分层的 namespaces 是由 捕鱼大亨网络版多租户工作组 (wg-multitenancy) 为了 解决这些问题。最简单的形式是,分层名称空间是 常规捕鱼大亨网络版命名空间,其中包含一个小的自定义资源 标识单个可选的父名称空间。这确立了 ownership 跨越 命名空间,而不仅仅是 他们。

这种所有权概念可带来另外两种类型的行为:

  • 策略继承: 如果一个名称空间是另一个名称空间的子代,则是策略对象 例如RBAC RoleBindings是 从父级复制到 child.
  • 委托创作: 您通常需要集群级特权才能创建 名称空间,但是分层名称空间增加了另一种选择: 子命名空间, 只能使用父级中的有限权限来操作 namespace.

这为我们的开发团队解决了两个问题。集群管理员可以 为团队创建一个单一的“根”命名空间,以及所有必要的东西 策略,然后将创建子命名空间的权限委派给以下成员 那支球队。然后,这些团队成员可以创建供自己使用的子命名空间, 而不违反群集管理员强加的策略。

动手使用分层名称空间

分层名称空间由捕鱼大亨网络版扩展提供,称为 分层命名空间 Controller, or HNC。 HNC包含两个组件:

  • 经理 在您的群集上运行,管理子命名空间,传播策略 对象,以确保您的层次结构合法并管理扩展点。
  • kubectl插件, called kubectl-hns, makes it easy for 用户s to 与经理互动。

两者都可以从 发布页面 repo.

让我们来看看HNC的作用。想象一下,我没有创建名称空间 privileges, but I can view the namespace team-a and create 子命名空间 within it1。使用插件,我现在可以说:

$ kubectl hns create svc1-team-a -n team-a

This creates a subnamespace called svc1-team-a. Note that since 子命名空间 只是常规的捕鱼大亨网络版命名空间,所有子命名空间名称仍必须为 unique.

我可以通过请求树视图来查看这些命名空间的结构:

$ kubectl hns tree team-a
# Output:
team-a
└── svc1-team-a

如果父名称空间中有任何策略,这些策略现在将显示在 child as well2. For example, let’s say that team-a had an RBAC RoleBinding called sres. This rolebinding will 也 be present in the subnamespace:

$ 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: ...

最后,HNC将标签添加到这些名称空间,其中包含有关以下内容的有用信息: 您可以用来应用其他策略的层次结构。例如,您可以创建 以下NetworkPolicy:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-team-a
  namespace: team-a
spec:
  ingress:
  - :
    - namespaceSelector:
        matchExpressions:
          - key: 'team-a.tree.hnc.x-k8s.io/depth' # Label created by HNC
            operator: Exists

This policy will both be propagated to all descendants of team-a, and will 允许所有这些名称空间之间的入口流量。 “树”标签 只能由HNC应用,并保证反映最新的层次结构。

您可以从以下网址了解有关HNC的所有功能: 用户 guide.

后续步骤和参与

如果您认为分层名称空间可用于您的组织, HNC v0.5.1可用于 GitHub. 我们很想知道您对此有何想法,您正在使用它来解决什么问题 以及您最想看到的功能。与所有早期软件一样, 在生产环境中使用HNC时应谨慎,但更多 得到的反馈,我们将越早能够使用HNC 1.0。

我们还向其他贡献者开放,无论是修复还是报告错误, 或帮助制作新功能的原型,例如异常,改进的监控, 分层资源配额或细粒度配置。

请通过我们与我们联系 回购, 邮寄 list 或上 松弛 - 我们期望 to hearing 从 you!


阿德里安·卢德温(Adrian Ludwin) 是一名软件工程师, 分层命名空间控制器的技术主管。

注意1:从技术上讲,您创建了一个称为“ subnamespace anchor”的小对象 在父命名空间中,然后HNC为您创建子命名空间。

注意2:默认情况下,仅传播RBAC角色和RoleBindings,但您 可以配置HNC传播任何命名空间的捕鱼大亨网络版对象。