<p>&#22823;&#23478;&#22909;&#65281;&#20170;&#22825;&#35201;&#26469;&#20171;&#32461;&#24182;&#20146;&#33258;&#31034;&#33539;&#19968;&#19979;&#65281;</p> 

讯享网

在 Kubernetes 中， 是最基本的单元。它通过创建逻辑分区来组织和隔离资源。通过将资源划分到不同的命名空间中，管理员可以实施安全策略、限制资源的使用，并保持一个干净、有序的环境。

为了在 Kubernetes 中创建一个命名空间，可以按照以下步骤创建命名空间 -

• 声明式的表达，

也就是说 -

或者用命令句式

Kubernetes命名空间的限制了解一下

命名空间确实非常有用——你可能会发现为每个集群创建很多命名空间。然而，在大规模部署时，众多命名空间可能会带来管理上的麻烦。

考虑以下场景，例如——

场景#1 — 你可能希望多个命名空间应用类似的策略，例如允许同团队成员访问。然而，由于角色绑定在每个命名空间的级别上运行，你将被迫在每个命名空间中单独创建这些角色绑定，这可能会很麻烦并且容易出错。同样的情况也适用于其他策略，例如网络策略和资源限制范围。

场景#2 — 你可能希望某些团队可以自行创建命名空间作为服务的隔离单元。然而，创建命名空间是一项需要集群级别特权的操作，你通常希望严格控制这一特权。

层次命名空间

这些是对 Kubernetes 命名空间的简单扩展，从而解决我们上面讨论的一些不足之处。它通过让用户能够将命名空间组织成树形结构、在这些树中创建新的命名空间以及将策略应用到这些树（或它们的子树）上来解决这些问题。

如下所示，每个都是命名空间

这样做可以让管理具有相同所有权概念的命名空间的集合变得容易。这在多个团队共用但所有者不一定是人的集群中尤其有用。例如，你可能想让一个操作员担当一组命名空间的所有者。

通过HNC（层次命名空间控制）可以实现的一些关键功能包括以下几点：

• 命名空间层级关系 — HNC 允许在命名空间间创建父子层级关系，使资源管理更加有序和结构化。
• 配置传播 — 使用 HNC，父命名空间中的配置和策略会自动传播到其子命名空间，无需手动干预。
• 访问控制 — HNC 简化了层级命名空间设置中基于角色的访问控制（RBAC）的管理，使得在整个层级中执行安全策略更加简单直接。

要使用HNC，你首先需要在你的Kubernetes集群中安装HNC扩展插件。

如果没有安装 krew，请先安装它，接着安装 hns 的 kubectl 插件。

假设你有一个叫“ _acme-org”的组织。我们会为它创建一个根命名空间。

接下来，我们将为该组织中的一个团队创建一个命名空间，并将其命名为“team-a”。

还有另一个命名空间用于该团队拥有的服务。默认情况下，它们之间没有任何关系。

假设我们要让某人成为团队a的SRE（即站点可靠性工程师），因此我们需要创建一个RBAC角色。

以及绑定到该角色的RoleBinding。

类似地，比如说，我们可能希望在整个组织中建立一个超级SRE小组，因此需要为相同的设置角色和相应角色绑定。

显然，这都不会对“service-1”产生影响，因为它是一个完全独立的命名空间，并且RBAC仅在命名空间级别起作用。

这样 HNC 就派上用场了。我们把 “acme-org” 设置成 “team-a” 的上级。

其中“team-a”是“service-1”的父节点

现在让我们展示确保一切都如我们所愿的层级。

现在再检查一下“service-1”，我们会看到角色及其绑定已经从祖先命名空间传递到了子命名空间中。

层级修改，及子命名空间的创建

让我们在“acme-org”内创建一个新空间，名字叫“team-b”吧。

这次我们不自己创建命名空间，而是让HNC（Hierarchical Namespace Controller）来创建。如果你在管理一个子树，但没有在整个集群中创建命名空间的权限，这会非常有用。

以下是所需设置确认。我们期望的设置确认 -

(Note: Given the expert's suggestion to remove the hyphen and use a period, and also to avoid repetition, the final translation would ideally be: "以下是所需设置的确认。")

比如说，“_team-b”有点奇怪，他们把他们的SRE称为“法师”，所以我们也将为他们的角色安排好。

现在，如果我们把这个服务（service-1）分配给新的团队（team-b）的话——

而且可以验证角色及其角色绑定也已经更新了。

分享各类资源

HNC不仅限于RBAC。任何Kubernetes资源都可以配置为在层级中传播，默认情况下，只有RBAC对象会被传播。

比如说，“ service-1 ”中的工作负载需要一个名为my-creds的秘密凭证，每个团队的my-creds都不一样。

让我们在“团队-b”里创建那些凭据——

如果你使用这个命令检查“_service-1_”中存在的 secrets，你会发现 secret 并没有在 service-1 中显示出来，这个是因为我们还没有在 HNCConfiguration 中配置 HNC 来传播 secrets。

为了让这个功能正常工作，你需要更新HNC的配置对象，这是HNC整体的一个集群范围内的配置。要做到这一点，只需使用config子命令即可。

现在，我们应该能够验证我的凭证是否已传递到服务-1。

异常（比如在编程中遇到的问题）

（注：此处“异常”指技术或编程中的“异常”（cháoyí），而非更口语化的“异常”（yíchánɡ））

现在假设你的acme-org有一个秘密，你想和所有团队分享。我们创建这个秘密如下:

你会发现“_my-secret_”会传递到“_team-a_”和“_team-b_”——

但现在我们在“_team-b”开始运行一个不可信的服务，因此我们不再与它分享那个秘密了。这样一来，我们可以通过设置秘密的传播选择器来实现。

现在你看不到秘密可以从“ _team-b _”访问了。如果我们再在“ _team-b _”下添加任何孩子节点，秘密也不会传递给这些新添加的节点。

最后的思绪

在这篇博客中，我们探讨了 Kubernetes 中层级命名空间的强大功能，它简化了命名空间管理，并提供了一种更结构化的组织集群资源的方式。通过实施层级命名空间控制器 (HNC)，管理员可以轻松管理命名空间的父子关系，传播配置和资源设置，并在整个层次结构中实施访问控制策略。

随着容器化应用程序复杂度的增加，采用层次化命名空间的理念可以有助于简化管理并增强您 Kubernetes 环境中的安全性。通过将 HNC（层次化命名空间控制器）集成到您的工作流程中，这将帮助您更好地管理大规模命名空间，从而实现更高效、更可扩展的部署。

一如既往地，紧跟 Kubernetes 及其生态系统最新进展对于保持 Kubernetes 和其生态系统的稳健和高效至关重要。继续探索、学习和实验，来充分发掘 Kubernetes 基础设施的潜力。祝您玩转容器化！