命名空间是 Kubernetes 中的基本资源之一。
但它们不提供网络隔离，会被调度程序忽略，并且无法限制资源使用。
它们实际上是如何工作的，有什么用处？
命名空间不是真实的，也不存在于基础设施中。
您可以将命名空间视为标签，在列出资源时可以使用它们对资源进行分组。
示例：显示默认（标签）命名空间中的所有 Pod。
我们经常将它们想象为对象周围的灵活边界，但节点中没有真正的资源分组。
Kubernetes 网络应始终满足两个要求：
1. 任何 pod 都可以与任何 pod 通信。
2. Pod 具有“稳定”的 IP 地址。
请注意，第一个要求已经使命名空间作为安全边界的想法变得无效。
但事情并没有就此结束。
命名空间只是标签，并不定义可以创建或分配多少资源。
您可以根据需要拥有任意数量（和大小）的工作负载。
最重要的是，Kubernetes 调度程序不支持命名空间。
当它决定 pod 应放置在基础设施中的位置时，它不会考虑命名空间。
为什么要这样设计呢？
当我们查看权限和 RBAC 时，我们看到事情发生了变化。
您拥有的 ClusterRoles 可以授予您对资源的访问权限，而不管命名空间如何。
但您也有受其限制的角色。
这是关于命名空间如何工作的第一个线索：Kubernetes API。
如果您熟悉 Kubernetes API，您可能知道有验证和变更控制器，旨在在资源到达 etcd 之前检查和变更资源。
每个控制器都有多项检查或变更操作，旨在修改 Pod、命名空间、入口、存储类等。
那么，当您想要限制命名空间中的资源时会发生什么？
您不将该策略附加到调度程序；相反，您创建一个 ResourceQuota 对象。
验证准入控制器中的 API 服务器将在资源存储到数据库之前强制执行它。
您还可以使用 LimitRange 资源定义命名空间中工作负载的默认请求和限制。
至于 ResourceQuota，这些值不是由调度程序强制执行的，但验证和更改准入控制器仍然会检查和更改这些值。
那么网络呢？如果任何 Pod 确实可以与任何 Pod 通信，那么命名空间网络策略如何工作？
在这种情况下，网络策略是由 DaemonSet 在节点上设置的规则（iptables、eBPF）。
DaemonSet 具有命名空间感知能力，可以制定正确的防火墙规则——网络仍然不知道命名空间。
命名空间不是为多租户设计的，当您专注于共享 Kubernetes 组件（例如 CoreDNS）时，它会显示出来。
没有什么可以阻止一个租户使 DNS 过载并影响所有其他租户。
DNS 不支持命名空间，您无法根据命名空间使用设置策略（除非您安装额外的插件）。
您可能会在使用 Kubernetes API 时遇到相同的场景：租户用请求淹没 API。
Kubernetes 1.29 中有一个名为 API 优先级和公平性的新功能，旨在缓解这种情况。
命名空间是在 Kubernetes 中构建更高抽象的重要构建块。
但是，它们本身并不意味着用作多租户解决方案。
社区开发了多种工具来构建更强大的抽象来管理租户，以填补这一空白。
了解更多如果您对我的分享感兴趣可以点击关注，或者查看我的技术专栏了解更多一线大厂互联网最新架构技术细节！
