对象名称和 ID

集群中的每个对象都有一个在该资源类型中唯一的名称。每个 Kubernetes 对象也有一个在整个集群中唯一的UID。

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

对于非唯一的用户提供的属性，Kubernetes 提供了标签和注解。

名称

客户端提供的字符串，用于引用 资源 URL 中的对象，例如 `/api/v1/pods/some-name`。

给定类型的对象在同一时间只能有一个给定名称。但是，如果你删除该对象，你可以用相同的名称创建一个新对象。

名称在同一资源的所有API 版本中必须是唯一的。API 资源通过其 API 组、资源类型、命名空间（对于命名空间资源）和名称进行区分。换句话说，API 版本在此上下文中无关紧要。

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

以下是四种常用的资源名称约束类型。

DNS 子域名

大多数资源类型要求其名称可用作 RFC 1123 中定义的 DNS 子域名。这意味着名称必须

• 包含不超过 253 个字符
• 只包含小写字母数字字符、'-' 或 '.'
• 以字母数字字符开头
• 以字母数字字符结尾

RFC 1123 标签名称

某些资源类型要求其名称遵循 RFC 1123 中定义的 DNS 标签标准。这意味着名称必须

• 最多包含 63 个字符
• 只包含小写字母数字字符或 '-'
• 以字母数字字符开头
• 以字母数字字符结尾

RFC 1035 标签名称

某些资源类型要求其名称遵循 RFC 1035 中定义的 DNS 标签标准。这意味着名称必须

• 最多包含 63 个字符
• 只包含小写字母数字字符或 '-'
• 以字母字符开头
• 以字母数字字符结尾

路径段名称

有些资源类型要求它们的名称可以安全地编码为路径段。换句话说，名称不能是“.”或“..”，并且名称不能包含“/”或“%”。

以下是名为 `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 中的标识符和名称设计文档。