此文档中的信息可能已过时
此文档的更新日期比原文晚，因此其中的信息可能已过时。如果能阅读英文，请查看英文版本以获取最新信息： Object Names and IDs
对象名称和 ID
每个 Kubernetes 对象也有一个 UID 来标识在整个集群中的唯一性。
比如，在同一个名字空间
中只能有一个名为 myapp-1234 的 Pod，但是可以命名一个 Pod 和一个 Deployment 同为 myapp-1234。
对于用户提供的非唯一性的属性，Kubernetes 提供了标签（Label）和 注解（Annotation）机制。
名称
客户端提供的字符串，引用资源 URL 中的对象，如/api/v1/pods/some name。
某一时刻，只能有一个给定类型的对象具有给定的名称。但是，如果删除该对象，则可以创建同名的新对象。
名称在同一资源的所有 API 版本中必须是唯一的。 这些 API 资源通过各自的 API 组、资源类型、名字空间（对于划分名字空间的资源）和名称来区分。 换言之，API 版本在此上下文中是不相关的。
说明：
当对象所代表的是一个物理实体（例如代表一台物理主机的 Node）时， 如果在 Node 对象未被删除并重建的条件下，重新创建了同名的物理主机， 则 Kubernetes 会将新的主机看作是老的主机，这可能会带来某种不一致性。
当在资源创建请求中提供 generateName 而不是 name 时，服务器可能会生成一个名称。
使用 generateName 时，所提供的值将作为名称前缀，服务器会在其后附加一个生成的后缀。
即使名称是自动生成的，它仍可能与现有名称冲突，从而导致 HTTP 409 响应。
从 Kubernetes v1.31 及更高版本开始，这种情况发生的概率大大降低，
因为服务器会尝试最多 8 次生成唯一名称，然后才返回 HTTP 409 响应。
以下是比较常见的四种资源命名约束。
DNS 子域名
很多资源类型需要可以用作 DNS 子域名的名称。 DNS 子域名的定义可参见 RFC 1123。 这一要求意味着名称必须满足如下规则：
- 不能超过 253 个字符
- 只能包含小写字母、数字，以及 '-' 和 '.'
- 必须以字母数字开头
- 必须以字母数字结尾
RFC 1123 标签名
某些资源类型需要其名称遵循 RFC 1123 所定义的 DNS 标签标准。也就是命名必须满足如下规则：
- 最多 63 个字符
- 只能包含小写字母、数字，以及 '-'
- 必须以字母数字开头
- 必须以字母数字结尾
RFC 1035 标签名
某些资源类型需要其名称遵循 RFC 1035 所定义的 DNS 标签标准。也就是命名必须满足如下规则：
- 最多 63 个字符
- 只能包含小写字母、数字，以及 '-'
- 必须以字母开头
- 必须以字母数字结尾
说明：
RFC 1035 和 RFC 1123 标签标准之间的唯一区别是 RFC 1123 标签允许以数字开头，而 RFC 1035 标签只能以小写字母字符开头。
路径分段名称
某些资源类型要求名称能被安全地用作路径中的片段。
换句话说，其名称不能是 .、..，也不可以包含 / 或 % 这些字符。
下面是一个名为 nginx-demo 的 Pod 的配置清单：
apiVersion: v1
kind: Pod
metadata:
name: nginx-demo
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
说明：
某些资源类型可能具有额外的命名约束。
UID
Kubernetes 系统生成的字符串，唯一标识对象。
在 Kubernetes 集群的整个生命周期中创建的每个对象都有一个不同的 UID，它旨在区分类似实体的历史事件。
Kubernetes UID 是全局唯一标识符（也叫 UUID）。 UUID 是标准化的，见 ISO/IEC 9834-8 和 ITU-T X.667。
接下来
- 进一步了解 Kubernetes 标签和注解。
- 参阅 Kubernetes 标识符和名称的设计文档。