对象名称和 ID

集群中的每个对象都有一个名称，该名称对于该类型的资源而言是唯一的。每个 Kubernetes 对象还都有一个 UID，该 UID 在整个集群中是唯一的。

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

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

名称

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

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

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

说明

在对象代表物理实体的情况下，例如表示物理主机的节点，如果主机在不删除和重新创建节点的情况下使用相同的名称重新创建，Kubernetes 会将新主机视为旧主机，这可能导致不一致。

当在资源创建请求中提供 generateName 而不是 name 时，服务器可能会生成名称。当使用 generateName 时，提供的值将用作名称前缀，服务器会将生成的后缀附加到该名称前缀。即使名称是生成的，也可能与现有名称冲突，从而导致 HTTP 409 响应。这在 Kubernetes v1.31 及更高版本中不太可能发生，因为服务器将尝试最多 8 次生成唯一名称，然后再返回 HTTP 409 响应。

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

DNS 子域名名称

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

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

RFC 1123 标签名称

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

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

说明

当启用 RelaxedServiceNameValidation 功能门时，允许 Service 对象名称以数字开头。

RFC 1035 标签名称

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

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

说明

虽然 RFC 1123 在技术上允许标签以数字开头，但当前的 Kubernetes 实现要求 RFC 1035 和 RFC 1123 标签都以字母字符开头。例外情况是，当 Service 对象的 RelaxedServiceNameValidation 功能门启用时，允许 Service 名称以数字开头。

路径段名称

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

这是一个名为 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 中的标识符和名称设计文档。

上次修改时间：2025 年 10 月 02 日下午 6:19 PST：docs: 修复 RFC 1123 标签名称文档 (0a5bab0183)