名字空间
名字空间（Namespace） 提供一种机制，将同一集群中的资源划分为相互隔离的组。同一名字空间内的资源名称必须唯一，但跨名字空间时没有这个要求。名字空间作用域仅针对带有名字空间的对象（例如 Deployment、Service 等），对集群范围的对象（例如 StorageClass、Node、PersistentVolume 等）不适用。
官方文档参考
| 文档 | 语言 | 链接 |
|---|---|---|
| 名字空间（Namespace）概念页 | 中文 | https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/namespaces/ |
| Namespaces 概念页（英文，用于对照补全 DNS 告警等细节） | 英文 | https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/ |
中文站名字空间页的实际路径为 /zh-cn/docs/concepts/overview/working-with-objects/namespaces/（位于 working-with-objects 层级下），两者均为本次抓取验证可用的官方链接。
何时使用多个名字空间
- 名字空间适用于很多用户、跨多个团队或项目的场景。对于只有几到几十个用户的集群，根本不需要创建或考虑名字空间；当需要名字空间提供的功能时再使用。
- 名字空间为名称提供作用范围：资源名称需在名字空间内唯一，但可以跨名字空间重复。
- 名字空间不能相互嵌套，每个 Kubernetes 资源只能位于一个名字空间中。
- 名字空间是在多个用户之间划分集群资源的一种方法（通过资源配额 ResourceQuota 实现）。
- 不必用多个名字空间来分隔仅仅轻微不同的资源（例如同一软件的不同版本）：应该用标签区分同一名字空间中的不同资源。
对于生产集群，请考虑不要使用 default 名字空间，而是创建其他名字空间来使用，避免业务资源与临时测试资源混杂。
初始名字空间
Kubernetes 启动时会创建四个初始名字空间：
| 名字空间 | 用途 |
|---|---|
default | 预设的兜底名字空间，便于你在不创建新名字空间的情况下直接开始使用新集群 |
kube-node-lease | 保存与各个节点关联的 Lease（租约）对象；节点租约允许 kubelet 发送心跳，控制面据此检测节点故障 |
kube-public | 所有客户端（包括未经身份验证的客户端）都可读取；主要预留为集群使用，以便某些资源需要在整个集群中可见可读。其公共属性只是一种约定而非要求 |
kube-system | 存放 Kubernetes 系统自身创建的对象 |
避免创建以 kube- 为前缀的名字空间，该前缀是为 Kubernetes 系统名字空间保留的。
使用名字空间
查看名字空间
kubectl get namespace
# NAME STATUS AGE
# default Active 1d
# kube-node-lease Active 1d
# kube-public Active 1d
# kube-system Active 1d
为当前请求设置名字空间
使用 --namespace 参数：
kubectl run nginx --image=nginx --namespace=<名字空间名称>
kubectl get pods --namespace=<名字空间名称>
设置名字空间偏好（永久生效）
可以把名字空间保存到当前上下文，后续所有 kubectl 命令都默认使用它：
kubectl config set-context --current --namespace=<名字空间名称>
# 验证设置是否生效
kubectl config view --minify | grep namespace:
创建与删除名字空间
# 创建一个名字空间
kubectl create namespace my-namespace
# 删除一个名字空间（其下所有资源会被一并删除）
kubectl delete namespace my-namespace
也可以用 YAML 创建：
apiVersion: v1
kind: Namespace
metadata:
name: my-namespace # 名字空间名称，必须符合 RFC 1123 DNS 标签规范
名字空间和 DNS
创建一个 Service 时，Kubernetes 会创建一个相应的 DNS 条目，形式为：
<Service 名称>.<名字空间名称>.svc.cluster.local
- 如果容器只使用
<Service 名称>，它会被解析到本地名字空间中的服务。这对于跨多个名字空间（如开发、测试、生产）使用相同的配置非常有用。 - 如果要跨名字空间访问，必须使用完全限定域名（FQDN）。
- 因此所有名字空间名称都必须是合法的 RFC 1123 DNS 标签。
如果创建与公共顶级域名（如 com、io 等）同名的名字空间，这些名字空间中的 Service 可以拥有与公共 DNS 记录重叠的短 DNS 名称。所有名字空间中的负载在执行 DNS 查找时，如果查找的名称没有尾部句点，就会被重定向到这些 Service 上，优先级高于公共 DNS，形成 DNS 劫持风险。
缓解措施：将创建名字空间的权限仅授予可信用户；必要时可部署准入 Webhook（admission webhook）等安全控制机制，阻止创建与公共 TLD 同名的名字空间。
并非所有对象都在名字空间中
- 大多数 Kubernetes 资源（例如 Pod、Service、Deployment 等）都位于某个名字空间中。
- 名字空间资源本身并不在名字空间中。
- 底层资源（例如 Node、PersistentVolume）不属于任何名字空间。
查看哪些资源在/不在名字空间中：
# 位于名字空间中的资源
kubectl api-resources --namespaced=true
# 不在名字空间中的资源
kubectl api-resources --namespaced=false
自动打标签
特性状态：Kubernetes v1.22 起 GA。
Kubernetes 控制面会为所有名字空间设置一个不可变更的标签 kubernetes.io/metadata.name，标签的值就是名字空间的名称。可以据此对名字空间做统一筛选：
# 用标签筛选名字空间
kubectl get namespaces -l kubernetes.io/metadata.name=default
我的总结与避坑清单
- 生产集群不要把业务资源放进
default名字空间，按团队/项目/环境划分专属名字空间，并配合 ResourceQuota 和 LimitRange 限制资源用量。 - 永远不要创建
kube-前缀的名字空间，也不要在kube-system里部署业务负载，避免与系统组件冲突。 - 同名 Service 在不同名字空间互不冲突，容器内短名（
<service-name>）只解析到本名字空间；跨名字空间调用要写全xxx.<namespace>.svc.cluster.local，排查连通性问题时先确认是否用了短名。 kubectl delete namespace会级联删除其下所有资源，属于高危操作，删除前先用kubectl get all -n <ns>确认资源清单。- 执行 kubectl 命令时养成确认当前命名上下文的习惯：用
kubectl config view --minify | grep namespace:检查默认名字空间，避免在错误的名字空间里创建或删除资源。 - 名字空间名称要符合 RFC 1123 DNS 标签（小写字母、数字、连字符），且绝不能与公共顶级域名同名，否则会引发内部 DNS 抢答问题。
