Kubernetes 的命名空间（Namespace）提供一种将集群资源划分为多个逻辑分区的机制。用户可以按环境、团队或应用将对象放入不同命名空间，但这并不代表这些对象之间天然存在安全或性能上的硬隔离。如果不清楚命名空间级资源隔离的具体边界，就很容易在多租户场景下出现配置冲突、资源争抢甚至权限泄漏。因此，深入理解命名空间能隔离哪些资源、隔离不到哪些资源，是构建稳定集群的第一步。
命名空间能隔离哪些资源
命名空间是 Kubernetes 中用于组织 API 资源的核心单位。凡是属于命名空间作用域的对象，其名称在同一个命名空间内必须唯一，但不同命名空间中可以使用相同名称。常见的命名空间级资源包括 Pod、Service、Deployment、StatefulSet、ConfigMap、Secret、ServiceAccount、PersistentVolumeClaim、Ingress、NetworkPolicy、Role、RoleBinding 以及 ResourceQuota。当删除一个命名空间时，其中所有的命名空间级资源都会被级联删除，这为环境清理和权限回收提供了很大的便利。
不过，命名空间提供的隔离主要是逻辑层面的，而不是自动的网络或安全隔离。例如，两个不同命名空间中的 Pod 默认仍然可以互相访问，只要它们知道对方 Service 的 ClusterIP 或者直接使用 Pod IP，且集群中没有对应的 NetworkPolicy 限制。也就是说，命名空间解决了资源分组、名称冲突和权限作用域的问题，但并不会天然阻断流量，也不会阻止一个命名空间中的 Pod 去访问另一个命名空间中的 Service。
可以通过以下命令创建一个新的命名空间，并将资源声明放入该命名空间中。命名空间对象本身只需要名称即可定义：
apiVersion: v1 kind: Namespace metadata: name: team-a
创建完成后，后续的资源对象只要在 metadata 中指定 namespace: team-a，就会被归入该逻辑分区。如果同一个团队在多个环境中使用相同应用名称，那么不同命名空间可以让这些应用名称互不冲突。
命名空间隔离不到的资源与默认行为
Kubernetes 中还有一类资源是集群级作用域，它们不属于任何命名空间，例如 Node、PersistentVolume、StorageClass、ClusterRole、ClusterRoleBinding、CustomResourceDefinition 以及 Namespace 本身。这些对象在集群范围内唯一，任何命名空间中的主体都有可能看到或使用它们。例如，所有命名空间中的 Pod 都可以被调度到集群中的任意 Node 上，除非通过 nodeSelector、亲和性或者污点策略进行限制。这意味着 Node 的计算资源并不是被命名空间天然分割的。
默认情况下，一个命名空间中的 Pod 可以调度到同一个 Node，也可以分布在多个 Node 上。如果一个 Pod 没有设置 resources.requests 和 resources.limits，它可能与其它命名空间的 Pod 争抢同一个 Node 的 CPU 和内存。当节点压力增大时，kubelet 会根据 QoS 等级驱逐部分 Pod，但驱逐对象的选择是集群级别的，命名空间边界并不会保护某个团队的工作负载不受影响。因此，如果没有额外的配额和限制策略，命名空间无法隔离计算资源的实际使用。
网络方面同样如此。Kubernetes 使用扁平网络模型，所有 Pod 都位于一个可路由的网络空间中。不同命名空间的 Pod 默认可以直接通信，这与名称空间本身无关。Service 的 DNS 名称格式为 service-name.namespace.svc.cluster.local，虽然命名空间作为 DNS 的一部分承担了寻址作用，但它并不构成访问控制。任何 Pod 只要知道目标 Service 的完整名称，就可以发起连接，除非网络策略明确禁止。因此，命名空间隔离边界不能被误解为网络隔离边界。
用 ResourceQuota 和 LimitRange 建立资源边界
为了在命名空间级别约束资源消耗，Kubernetes 提供了 ResourceQuota 和 LimitRange 两个内置对象。ResourceQuota 可以限制某个命名空间中可创建的对象数量以及所有 Pod 的 CPU、内存请求和限制总量。它不预留资源，只是作为一个准入门槛，当命名空间内的资源使用总量超过硬性限制时，新的创建请求会被 API 服务器拒绝。这种方式可以防止单个团队无限制地创建 Pod 或申请大量存储卷。
下面是一个 ResourceQuota 的配置示例。它限制了 team-a 命名空间中所有 Pod 的 CPU 请求总量为 4 核，内存请求总量为 8Gi，并限制 Pod 数量为 20 个：
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-quota
namespace: team-a
spec:
hard:
requests.cpu: "4"
requests.memory: 8Gi
limits.cpu: "8"
limits.memory: 16Gi
persistentvolumeclaims: "5"
pods: "20"
LimitRange 则作用于命名空间中的单个 Pod 或容器，用来设置资源请求和限制的默认值、最大值和最小值。如果用户创建的 Pod 没有显式声明 requests 和 limits，LimitRange 会自动注入默认值，从而避免未声明资源的 Pod 被视为 BestEffort 类型而更容易被驱逐。以下示例为 team-a 命名空间中的容器设置了默认请求 200m CPU 和 256Mi 内存，默认上限 500m CPU 和 512Mi 内存，同时限制单个容器最大申请 2 核 CPU 和 2Gi 内存：
apiVersion: v1
kind: LimitRange
metadata:
name: default-limits
namespace: team-a
spec:
limits:
- default:
cpu: 500m
memory: 512Mi
defaultRequest:
cpu: 200m
memory: 256Mi
max:
cpu: 2
memory: 2Gi
min:
cpu: 100m
memory: 128Mi
type: Container
这两个对象共同构成了命名空间级别的资源治理框架。但需要明确的是，ResourceQuota 和 LimitRange 只能限制 API 层面的申请和创建，它们不能阻止正在运行的 Pod 消耗超过 limit 的 CPU，因为 CPU 是可压缩资源，超限时会被内核节流；而内存超限则会触发 OOM 杀死。因此，资源边界更多是管理上的约束，而不是物理上的硬隔离。
通过 RBAC 与 NetworkPolicy 强化命名空间边界
RBAC 是 Kubernetes 权限控制的核心机制。在命名空间内部，Role 和 RoleBinding 用于授予某个命名空间内的权限，而 ClusterRole 和 ClusterRoleBinding 则用于集群范围的权限。为了实现最小权限原则，建议为每个团队或服务创建独立的 ServiceAccount，并通过 Role 只授予它们访问自己命名空间中资源的权限。避免直接使用默认 ServiceAccount，或把集群管理员凭证分享给应用。
网络策略（NetworkPolicy）则用来声明 Pod 允许的入站和出站流量。它的作用对象是 Pod 而不是命名空间，但通常可以结合命名空间选择器来定义跨命名空间的访问规则。下面示例默认拒绝所有入站流量，然后只允许来自同一命名空间中带有 app: frontend 标签的 Pod 访问：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-same-namespace
namespace: team-a
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080
需要注意的是，NetworkPolicy 本身并不会创建隔离，它只是声明规则，是否生效取决于集群使用的 CNI 插件是否支持网络策略。如果 CNI 不支持 NetworkPolicy，那么这些 YAML 定义不会产生任何实际效果。因此，在评估命名空间隔离能力时，必须确认底层网络插件的成熟度和策略执行能力。
命名空间隔离的局限性与多租户方案选择
对于信任级别较高的场景，例如同一团队的不同环境、不同微服务之间，使用命名空间配合 ResourceQuota、LimitRange、RBAC 和 NetworkPolicy 通常足够。但如果多个租户互不信任，普通命名空间的边界就显得薄弱。首先，Node 仍然是共享的，租户可能通过侧面信道或资源耗尽影响其他租户；其次，API 服务器是共享的，一个恶意租户可能通过大量请求影响控制平面；第三，底层容器运行时和内核漏洞可能被利用进行容器逃逸。这些问题都超出了命名空间能够解决的范畴。
如果需要更强的隔离，可以采用虚拟集群方案，例如 vCluster。vCluster 在同一个宿主机集群中运行一个独立的 Kubernetes 控制平面，每个租户拥有自己的 API 服务器、调度器和控制器，但底层节点仍然共享。更进一步的选择是直接为每个租户创建独立集群，这样在控制平面和节点层面都实现了物理隔离，但成本也显著增加。OpenShift 的 Project 本质上也基于命名空间，配合 SCC 和更严格的默认策略来提供增强边界。
最终方案的选择取决于组织的安全需求、预算和运维复杂度。普通命名空间适合软多租户，vCluster 适合中等信任级别，独立集群适合强隔离场景。无论采用哪种方案，理解命名空间级资源隔离的真实边界，才能避免错误的安全假设，并在架构设计阶段做出合理决策。
Kubernetes命名空间资源隔离修改时间：2026-08-22 01:29:32