Kubernetes 命名空间（Namespace）是集群内部一种逻辑隔离机制，它把一组资源打包进独立的“虚拟集群”中，主要隔离的是资源对象的可见范围、访问权限和配额上限，不隔离网络与底层计算能力。你可以把它理解成同一台物理服务器上划出的多个“隔间”，不同团队各占一间，互相看不到对方的东西,也动不了对方的配置。
Kubernetes命名空间到底隔离了什么
命名空间从三个维度帮你把集群“切”成了若干块，这也是它与 Docker 容器隔离在本质上的不同。
隔离资源对象的可见性
默认情况下，Kubernetes 集群自带了几个命名空间：default、kube-system、kube-public，你在执行 kubectl get pods 时看到的资源,其实都属于当前上下文中指定的命名空间。
假设你创建两个名叫 web 的 Deployment，一个放在 dev 命名空间，一个放在 prod 命名空间，它们可以共存，互不干扰，这里的“互不干扰”指的是资源名称的冲突被消解了，不同命名空间里的同名 Service、ConfigMap、Secret 都是独立副本，改一个不会影响另一个，对于运维人员来说，这意味着你可以在同一套集群里跑多套业务,而不必为每个环境单独买机器。
隔离访问权限
RBAC（基于角色的访问控制）在 Kubernetes 中与命名空间紧密相关，你可以把“创建 Pod 的权限”绑定到某个用户或服务账号上，但限制它只对 dev 命名空间生效，换句话说，张三可以在开发环境里随意重建 Pod，但他对 prod 命名空间连查看的权限都没有。
实际项目中这种隔离非常实用，新来的实习生拿到的是 dev 命名空间的写权限，误操作影响的也只是一个测试环境，而不是整个生产集群，业内专家指出，很多企业生产事故的根因不是操作复杂，而是权限边界太宽,命名空间就是这条边界最基础的实现方式。
隔离资源配额
ResourceQuota 是命名空间内置的“预算表”，你可以给某个命名空间设置 Pod 数量上限、CPU 请求上限、内存上限等，一旦这个命名空间里的资源消耗达到阈值，再创建新 Pod 会被 API Server 直接拒绝。
用列表说明更直观：
requests.cpu控制所有 Pod 的 CPU 请求总和limits.memory控制所有容器的内存上限总和count/pods控制 Pod 总数上限persistentvolumeclaims
控制 PVC 数量
对于多团队共用集群的场景，这是防止“一个团队吃光所有资源”的关键手段，没有配额约束的命名空间，等于你把一栋楼的钥匙分给了所有人,却没有任何人管水电表。
kubernetes命名空间是什么先理解它的“虚拟隔间”属性
搞清楚了它隔离什么,我们再回头看看它本身是什么。
一个逻辑隔间，对外表现为一组资源的集合，Kubernetes API Server 在处理请求时，会根据请求中携带的 namespace 字段，决定把资源放进哪个隔间，你执行 kubectl get pods -n dev，本质上是请求 API Server 返回 dev 这个隔间里的所有 Pod。
命名空间只提供命名和管理的隔离，它不是一台独立的虚拟机，两个不同命名空间里的 Pod，很可能运行在同一台物理节点上，共享同一个内核、同一块磁盘，从这个角度看，它很像 Linux 的 cgroups 与命名空间体系：本身不提供绝对安全边界,但提供了很好的组织边界。
对比一下各类隔离手段的强弱,有助于加深理解：
| 隔离方式 | 资源粒度 | 安全强度 | 适用场景 | 成本 |
|---|---|---|---|---|
| Kubernetes 命名空间 | 逻辑对象 | 弱（不隔离网络与内核） | 多团队/多环境管理 | 极低 |
| 节点隔离 | 物理机器 | 强 | 高合规要求的生产环境 | 高 |
| 容器运行时隔离 | 进程级 | 中 | 多租户 SaaS | 中 |
命名空间解决的是“组织混乱”的问题，不是“安全攻击”的问题，如果两个应用之间有严格的数据隔离要求，光靠命名空间是不够的，还需要配合 NetworkPolicy 或直接拆集群。
命名空间在Kubernetes里不隔离什么
有经验的工程师常用一句话概括命名空间的边界：“它管得住资源，管不住流量。”
网络互通不受限
默认情况下，dev 命名空间里的 Pod 完全可以访问 prod 命名空间里 Pod 的 IP 地址，Service 的跨命名空间访问也很常见，使用全限定域名即可，格式是 服务名.命名空间.svc.cluster.local,这意味着命名空间不提供任何网络安全屏障。
要实现网络隔离，必须额外部署网络策略组件，如 Calico 或 Cilium，再用 NetworkPolicy 定义“谁可以访问谁”，这是很多初学者容易踩的坑：以为把资源放进不同命名空间就安全了,事实并非如此。
计算资源不隔离
命名空间里的资源配额只是一个数字上限，它不会把 CPU 核心数或内存大小物理切分，两个命名空间里的 Pod 共享同一批物理资源，某个命名空间出现 CPU 飙高，另一个命名空间同样会感受到性能抖动，要获得更确定的性能隔离，需要为关键工作负载设置 Guaranteed QoS 等级,或使用节点亲和性把工作负载绑定到专属节点上。
行业共识认为：命名空间适合作为管理单元，不适合作为性能保障单元，追求极致隔离的场景，必须把“使用命名空间隔离”和“使用节点隔离”结合起来。
实战：kubernetes多环境隔离方案怎么落地
最常见的命名空间用法，是搭建开发、测试、生产三套逻辑环境。
第一步,创建命名空间：
kubectl create namespace dev kubectl create namespace test kubectl create namespace prod
第二步，为每个命名空间设置资源配额,防止开发环境把测试环境的资源抢占：
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-quota
namespace: dev
spec:
hard:
requests.cpu: "4"
requests.memory: 8Gi
limits.cpu: "8"
limits.memory: 16Gi
第三步，把当前 kubectl 的默认上下文切到某个命名空间：
kubectl config set-context --current --namespace=dev
完成这一步之后，后续所有 kubectl 命令都不需要再加 -n 参数了，这一步对于日常操作的效率提升非常明显,也让误操作生产环境的概率大幅降低。
这里有一个坑需要提醒：删除命名空间是一个危险操作。kubectl delete namespace dev 会把这个命名空间里的所有资源一次性清空，包括 Deployment、Service、ConfigMap、Secret 甚至 PVC，这个操作是不可逆的，执行前务必确认里面的资源已经备份或不再需要，实际操作中，经常能看到命名空间卡在 Terminating 状态，原因通常是里面有资源未能完成清理，比如存在 Finalizer 的 Pod 或 PVC。
多环境隔离组合策略
大型项目通常不止用命名空间这一招,以下是实际项目里常见的组合方案：
- 命名空间隔离环境，
dev、test、prod各占一个命名空间 - 用 RBAC 限制团队成员只能操作指定命名空间
- 用 ResourceQuota 限制每个环境的资源消耗上限
- 用 NetworkPolicy 限制跨环境流量，如禁止
dev
prod - 用 Helm 模板中的
.Release.Namespace变量，实现一套代码多环境部署
这套组合策略可以解决90%以上的日常管理需求，而且不引入额外的复杂组件，如果你的团队规模只有几十人，这套方案完全够用，如果规模更大，或者有独立的合规审计要求,那就需要引入多集群方案了。
Kubernetes命名空间常见问题解答
命名空间和标签（Label）有什么区别
命名空间是资源对象在 API Server 中的归属位置，决定资源属于哪个分区；标签是资源对象的元数据属性，用于选择和分组，命名空间在创建资源时由请求路径决定，标签则随时可以修改，通俗地说，命名空间决定资源“住在哪栋楼”，标签决定资源“能被谁选中”，一个 Pod 只能属于一个命名空间，但可以拥有多个标签，并且这两个概念的用途不冲突,跨命名空间的资源选择仍然需要靠标签。
删除命名空间时卡在 Terminating 怎么办
先执行 kubectl get namespace <名称> -o json 查看 spec.finalizers 字段，如果里面有 kubernetes 字样，说明该命名空间正在等待其中的资源完成清理，检查该命名空间下是否还有遗留的 Pod、PVC 或自定义资源，逐个删除后命名空间会自动消失，如果确认资源已经全部清理但命名空间仍然存在，可能是某个 CRD 资源的 Finalizer 没有正常执行，需要手动编辑命名空间的 finalizers 字段来强制完成清理。
跨命名空间访问 Service 应该怎么写地址
把请求目标写在 Service 名称后面，加上命名空间和集群域名后缀即可。dev 命名空间里的 api-gateway 服务要访问 prod 命名空间里的 user-service，地址写作 http://user-service.prod.svc.cluster.local:8080，这种方式要求两个服务在同一集群内，且目标命名空间存在对应的 Service，需要提醒的是，跨命名空间访问虽然方便，但会在服务间产生隐式耦合，在需要严格控制访问关系的场景下，应优先使用 NetworkPolicy 对这类流量做显式限制。
命名空间的本质是管理工具，不是安全边界，合理使用它，可以让你的集群在多团队、多环境下保持条理清晰，无论你管理的是十台节点的测试集群，还是上百台节点的大规模生产环境，先把命名空间的隔离边界摸透，再谈其他高级特性,这条路一定不会走偏。