Kubernetes Namespace 命名空间管理实战：资源隔离、默认命名空间与常用命令

Kubernetes Namespace 命名空间管理实战：资源隔离、默认命名空间与常用命令

摘要：多个团队共用一个 Kubernetes 集群，如何把彼此的资源隔离开？答案就是 Namespace（命名空间）。本文从"为什么需要 Namespace"讲起，梳理四个默认命名空间的用途，厘清"哪些资源属于 Namespace、哪些不属于"的经典问题，最后通过 kubectl 命令与 YAML 文件两种方式，完整演示命名空间的创建、查看、编辑、删除以及在指定命名空间中运行 Pod。

一、引言：多用户集群的隔离难题

在实际生产中，一个 Kubernetes 集群往往会被多个团队、多个项目共用。这时就出现一个问题：

多个用户使用同一个 Kubernetes Cluster，如何将他们创建的资源隔离开呢？

如果所有人都把 Pod、Service、PVC 丢在一个"大池子"里，很快就会面临：

• 团队 A 删掉了团队 B 的资源；
• 同名资源互相冲突；
• 谁也说不清某个 Pod 是哪个项目的；
• 无法按团队/项目做资源配额与权限控制。

Kubernetes 给出的答案就是 Namespace（命名空间）。

二、Namespace 介绍

2.1 什么是 Namespace？

Namespace ，简写为 ns ，也叫作 project（项目） ，代表资源的集合，用于分组集群资源。

它的核心思想是：Kubernetes 使用 Namespace 将一个物理的 Cluster 逻辑上划分成多个资源集合 ，每个集合就是一个 Namespace。不同 Namespace 里的资源是完全隔离的。

┌─────────────────────────── 一个物理 Kubernetes 集群 ───────────────────────────┐
│                                                                               │
│  ┌───────────────┐   ┌───────────────┐   ┌───────────────┐                    │
│  │  Namespace A  │   │  Namespace B  │   │  Namespace C  │   ...              │
│  │  (开发环境)    │   │  (测试环境)    │   │  (生产环境)    │                    │
│  │  Pod/Service/ │   │  Pod/Service/ │   │  Pod/Service/ │                    │
│  │  PVC/ConfigMap│   │  PVC/ConfigMap│   │  PVC/ConfigMap│                    │
│  └───────────────┘   └───────────────┘   └───────────────┘                    │
│                                                                               │
└───────────────────────────────────────────────────────────────────────────────┘

可以把它理解为 Kubernetes 集群内部的"虚拟子集群"：物理上共用同一批 Node 和网络，逻辑上每个命名空间独立管理自己的资源。

2.2 Kubernetes 默认创建的 4 个 Namespace

一个全新的集群默认包含以下命名空间：

Namespace	作用
default	创建资源时不指定 Namespace，就会被放到这个命名空间中
kube-system	Kubernetes 自己创建的系统资源都放在这里（如 kube-dns、calico、kube-proxy 等）
kube-public	该命名空间中的所有对象可以被所有用户读取（包括未验证身份的用户），适合存放公共信息
kube-node-lease	存放与每个节点关联的 Lease 对象；节点租约让 kubelet 发送心跳（heartbeat），以便控制平面能检测节点故障

实践提醒：除非确有特殊需求，业务资源不要放到 kube-system 中，也不要直接用 default 一把梭------给每个项目/环境建独立 Namespace 是集群治理的第一步。

2.3 经典思考：所有对象都属于 Namespace 吗？

答案：不是。

大多数 Kubernetes 资源（例如 Pod、Service、PVC、ConfigMap 等）都属于某个 Namespace；但有两类资源是**集群级别（Cluster-scoped）**的，不属于任何 Namespace：

• Namespace 资源本身不在 Namespace 中（不能"套娃"）；
• 更底层的资源也不在任何 Namespace 中，例如 Node（节点） 和 PersistentVolume（PV）。

常用资源归属对照表：

属于 Namespace（namespaced）	不属于 Namespace（cluster-scoped）
Pod、Service、Deployment	Node
PVC、ConfigMap、Secret	PersistentVolume（PV）
Ingress、NetworkPolicy	Namespace 本身
Role/RoleBinding（授权范围在 ns 内）	ClusterRole、StorageClass、PriorityClass
ServiceAccount	集群级别的 CustomResourceDefinition

判断一个资源是否属于命名空间，最可靠的方法是执行 kubectl api-resources 查看其 NAMESPACED 列：

root@master30:~# kubectl api-resources | head -20
NAME                              SHORTNAMES   APIVERSION                             NAMESPACED   KIND
pods                              po           v1                                     true         Pod
services                          svc          v1                                     true         Service
namespaces                        ns           v1                                     false        Namespace
nodes                             no           v1                                     false        Node
persistentvolumes                 pv           v1                                     false        PersistentVolume
persistentvolumeclaims            pvc          v1                                     true         PersistentVolumeClaim

NAMESPACED 为 true 表示属于命名空间，为 false 表示集群级别资源。

三、Namespace 管理实战

3.1 查看 Namespace 清单

root@master30:~# kubectl get ns
NAME              STATUS   AGE
default           Active   7d4h
kube-node-lease   Active   7d4h
kube-public       Active   7d4h
kube-system       Active   7d4h

STATUS 为 Active 表示命名空间处于正常可用状态。

3.2 获取 Namespace 的 YAML 定义

# 查看 default 命名空间完整的 yaml 格式定义
root@master30:~# kubectl get ns default -o yaml
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: "2026-08-23T02:10:11Z"
  name: default
  resourceVersion: "204"
  uid: ...
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

通过 -o yaml 可以清楚看到 Namespace 对象的完整结构，这也是"资源即 API 对象"的直观体现。

3.3 创建 Namespace

命令行创建：

root@master30:~# kubectl create ns shaka
namespace/shaka created

命名规则 ：命名空间名称必须满足正则表达式 [a-z0-9]([-a-z0-9]*[a-z0-9])?，最大长度为 63 位。简单理解：只能使用小写字母、数字和 -，且必须以字母或数字开头、结尾。

3.4 直接编辑 Namespace

root@master30:~# kubectl edit ns shaka

该命令会打开默认编辑器（通常是 vim），保存后实时生效。日常最常用的编辑场景是给 Namespace 添加标签（Labels），例如标记项目归属或环境类型：

metadata:
  labels:
    env: dev
    project: shaka

小知识：命名空间标签非常有用------NetworkPolicy 中的 namespaceSelector 就是靠它来选择"放行哪些命名空间"的流量。

3.5 查看 Namespace 详细信息

root@master30:~# kubectl describe ns shaka
Name:         shaka
Labels:       <none>
Annotations:  <none>
Status:       Active

No resource quota.

No LimitRange resource.

输出中的两行值得展开理解：

• No resource quota：表示该命名空间没有配置资源配额（ResourceQuota）。配额的作用是限制整个命名空间的 CPU、内存、PVC 数量等总用量，防止某个团队"吃光"集群资源；
• No LimitRange resource：表示没有配置 LimitRange（默认资源请求/限制），即命名空间内的 Pod 可以不声明资源 requests/limits 运行。

这两个资源都以 Namespace 为单位生效，是"多团队共享集群"场景下的重要治理工具。

3.6 删除 Namespace

root@master30:~# kubectl delete ns shaka
namespace "shaka" deleted

删除时务必牢记两点：

1. 删除一个 Namespace 会自动删除该 Namespace 中的所有资源（Pod、Service、PVC、ConfigMap 等全部级联删除，且不可恢复）；
2. default 和 kube-system 命名空间不可删除------它们由 Kubernetes 系统自身管理，删除会破坏集群。

实操建议：执行 kubectl delete ns 之前，先 kubectl get all -n <ns> 看看里面有哪些资源，确认是"真的不要了"再删。

3.7 通过 YAML 文件创建 Namespace

除了命令行，Namespace 也可以声明式创建，便于纳入 Git 版本管理（GitOps 的基础）：

# ns-shaka.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: shaka

root@master30:~# kubectl apply -f ns-shaka.yaml
namespace/shaka created

对比一下两种创建方式：

方式	命令	特点
命令式	kubectl create ns shaka	快捷，适合临时使用
声明式	kubectl apply -f ns-shaka.yaml	可重复执行、可版本化管理，适合生产

四、在指定 Namespace 中操作资源

创建好 Namespace 后，操作其中对象时需要使用 -n 选项指定 Namespace。

4.1 在指定 Namespace 中创建 Pod

root@master30:~# kubectl run web --image=nginx -n shaka
pod/web created

4.2 查看指定 Namespace 中的 Pod

root@master30:~# kubectl get pod -n shaka -o wide
NAME   READY   STATUS    RESTARTS   AGE     IP               NODE                   NOMINATED NODE   READINESS GATES
web    1/1     Running   0          39s   10.224.113.129   worker32.shaka.cn   <none>           <none>

Pod 运行在 shaka 命名空间中，获得独立的集群内 IP 10.224.113.129。

4.3 验证服务可访问

root@master30:~# curl -s 10.224.113.129 | grep nginx
<title>Welcome to nginx!</title>
<h1>Welcome to nginx!</h1>
<p>If you see this page, nginx is successfully installed and working.</p>

4.4 补充：不带 -n 时资源去哪了？

如果创建资源时不指定 -n ，资源会被放到当前上下文（Context）对应的命名空间中；如果上下文也没设置，就默认放入 default 命名空间。

两个实用命令：

# 查看所有命名空间中的 Pod（-A 是 --all-namespaces 的简写）
root@master30:~# kubectl get pods -A

# 切换当前上下文默认使用的命名空间（后续命令免去 -n）
root@master30:~# kubectl config set-context --current --namespace shaka

资源归属的优先级可以这样理解：

命令中的 -n / --namespace
        > 当前 Context 设置的命名空间
        > 默认命名空间 default

五、Namespace 使用中的常见问题与注意事项

5.1 删除后 Namespace 一直 Terminating？

kubectl delete ns 后，如果命名空间里有资源未完成清理，Namespace 会长时间停留在 Terminating 状态。常见原因：

• 命名空间内存在未被正确清理的资源（如卡住的 Finalizer）；
• 某些自定义资源（CRD 实例）有 Finalizer 等待外部控制器处理。

排查思路：

# 确认状态
root@master30:~# kubectl get ns
NAME        STATUS        AGE
shaka       Terminating   2m

# 查看命名空间内还残留什么资源
root@master30:~# kubectl get all -n shaka

5.2 不同 Namespace 之间的资源如何互通？

Namespace 提供的是管理/逻辑上的隔离，默认网络层面 Pod 之间是互通的（除非配置了 NetworkPolicy）。跨命名空间访问 Service 时，DNS 名称要带上命名空间：

服务名.命名空间名.svc.cluster.local

例如：kubectl exec -n shaka test -- curl -s web1.web 中的 web1.web，就是在访问 web 命名空间中的 web1 服务。

5.3 误删了 Namespace 怎么办？

Namespace 一旦删除，其中所有资源无法找回。因此：

• 重要环境建议定期备份（如用 etcd 快照或 kubectl get -o yaml 导出资源清单）；
• 生产集群应对删除操作做好权限管控（RBAC 中限制 delete 权限）。

六、总结

回到开头的问题------多用户共用集群如何隔离资源？Namespace 就是标准答案。本文核心要点：

1. Namespace 是资源集合 ：把一个物理集群逻辑划分成多个互相隔离的"虚拟集群"，简写 ns，也叫 project；
2. 四个默认命名空间各有分工 ：default 放默认资源、kube-system 放系统组件、kube-public 放公共可读信息、kube-node-lease 存节点心跳租约；
3. 并非所有资源都属于 Namespace：Pod、Service、PVC 等属于命名空间；Node、PV、Namespace 本身是集群级别资源；
4. 管理命令要熟练 ：get（查看）、create（创建）、edit（编辑）、describe（详情）、delete（删除）、apply -f（声明式创建）；
5. 操作对象记得带 -n ：不带则落到当前 Context 或 default；
6. 删除是"连锅端" ：删除 Namespace 会级联删除其中全部资源，default 与 kube-system 不可删除。

最后给出一份最佳实践清单：

• 按环境划分：dev / test / prod；
• 按团队或项目划分：team-a / team-b；
• 每个 Namespace 配置 ResourceQuota 与 LimitRange，避免资源被个别团队耗尽；
• 配合 RBAC 限制不同用户只能操作自己的 Namespace；
• 通过 NetworkPolicy 控制跨 Namespace 的访问；
• 用 YAML 声明式管理 Namespace，纳入版本控制。

Namespace 虽小，却是集群多租户治理的第一块基石。掌握了它，后面学习 RBAC、ResourceQuota、NetworkPolicy 都会事半功倍！