对象名称和 ID

集群中的每一个对象都有一个名称来标识其在同类资源中的唯一性；同时每个 Kubernetes 对象还有一个 UID 来标识其在整个集群中的唯一性。

比如，在同一个名字空间中只能有一个名为 myapp-1234 的 Pod，但是可以命名一个 Pod 和一个 Deployment 同为 myapp-1234。

对于用户提供的非唯一性的属性，Kubernetes 提供了标签（Label）和注解（Annotation）机制。

官方文档参考

页面	链接
对象名称和 ID（本篇主参考）	https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names/

名称（Name）

名称是客户端提供的字符串，用于引用资源 URL 中的对象，例如 /api/v1/pods/some-name。关键规则：

某一时刻，只能有一个给定类型的对象具有给定的名称；但对象删除后，可以创建同名的新对象。
名称在同一资源的所有 API 版本中必须是唯一的。

Kubernetes 使用以下四个属性的组合来唯一标识一个对象：

组成部分	说明	示例
API 组	对象所属的 API 组	`apps`
资源类型	对象的资源类型	`deployments`
命名空间	针对命名空间范围的资源	`default`
名称	对象名称	`myapp-1234`

虽然你可以通过不同的 API 版本（如 v1 或 v1beta1）访问资源，但版本只是同一底层对象的不同表示。因为版本不是唯一标识的一部分，所以不能通过使用不同的 API 版本，在同一个命名空间中创建名称和资源类型相同的两个对象。

generateName 自动命名

当在资源创建请求中提供 generateName 而不是 name 时，服务器可能生成一个名称：所提供的值作为名称前缀，服务器在其后附加一个生成的后缀。即使名称是自动生成的，它仍可能与现有名称冲突，从而导致 HTTP 409 响应。从 Kubernetes v1.31 及更高版本开始，这种情况发生的概率大大降低，因为服务器会尝试最多 8 次生成唯一名称，然后才返回 HTTP 409 响应。

四种常见命名约束

Kubernetes 中比较常见的四种资源命名约束如下：

名称类型	最大长度	允许字符	开头要求	结尾要求
DNS 子域名	253 字符	小写字母、数字、`-`、`.`	字母数字	字母数字
RFC 1123 标签名	63 字符	小写字母、数字、`-`	字母	字母数字
RFC 1035 标签名	63 字符	小写字母、数字、`-`	字母	字母数字
路径分段名称	无长度限制	不能是 `.`、`..`，不能包含 `/` 或 `%`	——	——

DNS 子域名

很多资源类型需要可以用作 DNS 子域名的名称（定义参见 RFC 1123）。名称必须满足如下规则：

不能超过 253 个字符
只能包含小写字母、数字，以及 - 和 .
必须以字母数字开头
必须以字母数字结尾

RFC 1123 标签名

某些资源类型需要其名称遵循 RFC 1123 所定义的 DNS 标签标准。命名必须满足如下规则：

最多 63 个字符
只能包含小写字母、数字，以及 -
必须以字母开头
必须以字母数字结尾

例外：Service 名称可以以数字开头

当启用 RelaxedServiceNameValidation 特性门控时，Service 对象名称可以以数字开头。

RFC 1035 标签名

某些资源类型需要其名称遵循 RFC 1035 所定义的 DNS 标签标准。命名必须满足如下规则：

最多 63 个字符
只能包含小写字母、数字，以及 -
必须以字母开头
必须以字母数字结尾

RFC 1123 与 RFC 1035 的实现差异

尽管 RFC 1123 在技术上允许标签以数字开头，但当前的 Kubernetes 实现要求 RFC 1035 和 RFC 1123 标签都以字母字符开头。唯一例外是当为 Service 对象启用了 RelaxedServiceNameValidation 特性门控时，才允许 Service 名称以数字开头。

路径分段名称

某些资源类型要求名称能被安全地用作路径中的片段。换句话说，其名称不能是 .、..，也不可以包含 / 或 % 这些字符。

清单示例

下面是一个名为 nginx-demo 的 Pod 的配置清单：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo            # 名称符合 RFC 1123 标签名约束：小写字母开头、可含 '-'
spec:
  containers:
  - name: nginx               # 容器名称同样受标签名约束
    image: nginx:1.14.2
    ports:
    - containerPort: 80

某些资源可能有额外命名约束

某些资源类型除了上述通用规则外，可能具有额外的命名约束，使用前请查阅对应 API 的参考文档。

UID

UID 是由 Kubernetes 系统生成、用来唯一标识对象的字符串：

在 Kubernetes 集群的整个生命周期中创建的每个对象都有一个不同的 UID，它旨在区分类似实体的历史事件。
Kubernetes UID 是全局唯一标识符（也叫 UUID）。UUID 是标准化的，见 ISO/IEC 9834-8 和 ITU-T X.667。

名称可复用，UID 永不重复

删除 Pod myapp-1234 再重建一个同名 Pod，名称相同但 UID 必然不同。日志系统、事件追踪中应该用 UID 区分"两个曾经同名的对象"，这在排查"旧实例残留行为"时非常关键。

我的总结与避坑清单

命名统一用小写字母 + 中划线（如 nginx-demo），兼容 RFC 1123/RFC 1035 两种标签名约束；不要用大写、下划线或以数字开头，避免在严格校验的资源上翻车。
注意长度上限的差别：单个标签名最多 63 字符，而 DNS 子域名（如 StatefulSet 生成的 Pod 名 pod-name.svc-name.ns.svc.cluster.local 类结构）最多 253 字符，给前缀和后缀留余量。
同类型同名可以"复活"：删除再创建同名对象是允许的，不要用名称当作对象的永久身份；审计和监控去重逻辑要用 UID。
同名 Node 重建有风险：当对象代表物理实体（如 Node）时，如果 Node 对象未被删除并重建，而同名物理主机被重新创建，Kubernetes 会把新主机看作老主机，可能带来不一致性——替换物理机时记得先删除旧 Node 对象。
Service 命名以数字开头的写法依赖特性门控（RelaxedServiceNameValidation），跨版本/跨集群迁移时不要依赖该行为，除非确认目标集群已开启。
generateName 生成的名称仍可能冲突返回 HTTP 409，客户端要有重试逻辑；v1.31 起服务器会自动尝试最多 8 次，但并没有完全消除冲突。

官方文档参考​

名称（Name）​

四种常见命名约束​

DNS 子域名​

RFC 1123 标签名​

RFC 1035 标签名​

路径分段名称​

清单示例​

UID​

我的总结与避坑清单​