标签和选择器

标签（Labels）是附加到如 Pod 等对象上的键值对。标签旨在用于指定对用户有意义且相关的对象标识属性，但不会直接对核心系统产生语义影响。标签可用于组织和选择对象子集。标签可以在创建对象时附加，也可以在随后随时添加和修改。每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的。

"metadata": {
  "labels": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

标签允许进行高效的查询和监听，非常适合在 UI 和 CLI 中使用。非标识性信息应使用注解（Annotations）记录。

动机

标签使用户能够以松散耦合的方式将其自身的组织结构映射到系统对象上，而无需客户端存储这些映射。

服务部署和批处理流水线通常是多维实体（例如，多个分区或部署、多个发布轨道、多个层级、每个层级有多个微服务）。管理通常需要交叉操作，这破坏了严格层次结构的封装，特别是那些由基础设施而非用户确定的刚性层次结构。

标签示例

• "release" : "stable", "release" : "canary"
• "environment" : "dev", "environment" : "qa", "environment" : "production"
• "tier" : "frontend", "tier" : "backend", "tier" : "cache"
• "partition" : "customerA", "partition" : "customerB"
• "track" : "daily", "track" : "weekly"

这些是常用标签的示例；您可以自由制定自己的规范。请记住，对于给定对象，标签键必须是唯一的。

语法和字符集

标签是键值对。有效的标签键包含两个部分：可选的前缀和名称，用斜杠（/）分隔。名称部分是必需的，长度不超过 63 个字符，必须以字母数字字符（[a-z0-9A-Z]）开头和结尾，中间可以包含连字符（-）、下划线（_）、点（.）和字母数字字符。前缀是可选的。如果指定了前缀，它必须是 DNS 子域名：一系列由点（.）分隔的 DNS 标签，总长度不超过 253 个字符，后跟一个斜杠（/）。

如果省略前缀，则标签键被假定为对用户私有。将标签添加到最终用户对象的自动系统组件（例如 kube-scheduler、kube-controller-manager、kube-apiserver、kubectl 或其他第三方自动化工具）必须指定一个前缀。

kubernetes.io/ 和 k8s.io/ 前缀为 Kubernetes 核心组件所保留。

有效的标签值

• 必须不超过 63 个字符（可以为空），
• 除非为空，否则必须以字母数字字符（[a-z0-9A-Z]）开头和结尾，
• 中间可以包含连字符（-）、下划线（_）、点（.）和字母数字字符。

例如，以下是一个具有两个标签 environment: production 和 app: nginx 的 Pod 清单：

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

标签选择算符

与名称和 UID 不同，标签不提供唯一性。通常，我们预计许多对象会携带相同的标签。

通过标签选择算符（Label Selector），客户端/用户可以识别一组对象。标签选择算符是 Kubernetes 中的核心分组原语。

API 目前支持两种类型的选择算符：基于等值和基于集合。标签选择算符可以由多个用逗号分隔的需求（requirements）组成。在有多个需求的情况下，必须全部满足，因此逗号分隔符充当逻辑与（AND，&&）运算符。

空选择算符或未指定选择算符的语义取决于上下文，使用选择算符的 API 类型应记录其有效性和含义。

基于等值的需求

基于等值或基于不等值的需求允许通过标签键和值进行过滤。匹配的对象必须满足所有指定的标签约束，不过它们也可能拥有额外的标签。支持三种运算符：=、==、!=。前两个表示相等（是同义词），后者表示不等。例如：

environment = production
tier != frontend

前者选择键等于 environment 且值等于 production 的所有资源。后者选择键等于 tier 且值不等于 frontend 的所有资源，以及所有不含 tier 键标签的资源。可以使用逗号运算符过滤生产环境（production）中排除前端（frontend）的资源：environment=production,tier!=frontend

基于等值的标签需求的一个使用场景是 Pod 指定节点选择标准。例如，下面的示例 Pod 选择存在 accelerator 标签且设置为 nvidia-tesla-p100 的节点。

apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "registry.k8s.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100

基于集合的需求

基于集合的标签需求允许根据一组值过滤键。支持三种运算符：in、notin 和 exists（仅键标识符）。例如：

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition

• 第一个示例选择键等于 environment 且值等于 production 或 qa 的所有资源。
• 第二个示例选择键等于 tier 且值不是 frontend 和 backend 的所有资源，以及所有不含 tier 键标签的资源。
• 第三个示例选择所有包含 partition 键标签的资源；不检查值。
• 第四个示例选择所有不含 partition 键标签的资源；不检查值。

类似地，逗号分隔符充当与（AND）运算符。因此，过滤具有 partition 键（无论值如何）且 environment 不为 qa 的资源，可以使用 partition,environment notin (qa)。基于集合的标签选择算符是等值形式的通用化，因为 environment=production 等同于 environment in (production)；!= 和 notin 同理。

基于集合的需求可以与基于等值的需求混合使用。例如：partition in (customerA, customerB),environment!=qa。

API

LIST 和 WATCH 过滤

对于 list 和 watch 操作，您可以指定标签选择算符来过滤返回的对象集；您可以使用查询参数指定过滤器。（要详细了解 Kubernetes 中的 watch，请阅读高效检测变更）。两种需求都允许使用（此处显示它们在 URL 查询字符串中出现的样子）：

• 基于等值的需求：?labelSelector=environment%3Dproduction,tier%3Dfrontend
• 基于集合的需求：?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29

这两种标签选择算符样式都可以通过 REST 客户端用于列出或监听资源。例如，在使用 kubectl 针对 apiserver 时，使用基于等值的语法：

kubectl get pods -l environment=production,tier=frontend

或使用基于集合的需求：

kubectl get pods -l 'environment in (production),tier in (frontend)'

如前所述，基于集合的需求更具表达力。例如，它们可以在值上实现或（OR）运算符：

kubectl get pods -l 'environment in (production, qa)'

或者通过 notin 运算符限制负向匹配：

kubectl get pods -l 'environment,environment notin (frontend)'

API 对象中的集合引用

某些 Kubernetes 对象，例如 services 和 replicationcontrollers，也使用标签选择算符来指定其他资源集合，例如 pods。

Service 和 ReplicationController

service 目标 Pod 的集合是通过标签选择算符定义的。同样，replicationcontroller 应管理的 Pod 集合也是通过标签选择算符定义的。

这两个对象的标签选择算符都在 json 或 yaml 文件中使用映射定义，并且仅支持基于等值的需求选择算符：

"selector": {
    "component" : "redis",
}

或者

selector:
  component: redis

此选择算符（分别以 json 或 yaml 格式）等同于 component=redis 或 component in (redis)。

支持基于集合需求的资源

较新的资源，例如 Job、Deployment、ReplicaSet 和 DaemonSet，也支持基于集合的需求。

selector:
  matchLabels:
    component: redis
  matchExpressions:
    - { key: tier, operator: In, values: [cache] }
    - { key: environment, operator: NotIn, values: [dev] }

matchLabels 是一个 {key,value} 对的映射。matchLabels 映射中的单个 {key,value} 等同于 matchExpressions 的一个元素，其 key 字段为 "key"，operator 为 "In"，values 数组仅包含 "value"。matchExpressions 是 Pod 选择算符需求列表。有效的运算符包括 In、NotIn、Exists 和 DoesNotExist。在 In 和 NotIn 的情况下，值集合必须是非空的。来自 matchLabels 和 matchExpressions 的所有需求都通过逻辑与（AND）连接在一起——必须全部满足才能匹配。

选择节点集合

标签选择的一个用例是限制 Pod 可以调度到的节点集合。有关更多信息，请参阅关于节点选择的文档。

有效使用标签

您可以对任何资源应用单个标签，但这并不总是最佳实践。在许多场景中，应使用多个标签来区分资源集。

例如，不同的应用程序会为 app 标签使用不同的值，但多层应用程序（例如留言板示例）还需要区分每一层。

在以下示例中，包含 app 标签是为了方便手动查询和简单的 CLI 使用。app.kubernetes.io/name 标签遵循推荐的 Kubernetes 标签规范，更适合工具和自动化。

前端可以携带以下标签：

labels:
  app: guestbook
  app.kubernetes.io/name: guestbook
  tier: frontend

而 Redis 主节点和副本节点将具有不同的 tier 标签，甚至可能还有额外的 role 标签：

labels:
  app: guestbook
  app.kubernetes.io/name: guestbook
  tier: backend
  role: master

和

labels:
  app: guestbook
  app.kubernetes.io/name: guestbook
  tier: backend
  role: replica

标签允许沿着标签指定的任何维度对资源进行切片和拆解。

kubectl apply -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml
kubectl get pods -Lapp -Ltier -Lrole

NAME                           READY  STATUS    RESTARTS   AGE   APP         TIER       ROLE
guestbook-fe-4nlpb             1/1    Running   0          1m    guestbook   frontend   <none>
guestbook-fe-ght6d             1/1    Running   0          1m    guestbook   frontend   <none>
guestbook-fe-jpy62             1/1    Running   0          1m    guestbook   frontend   <none>
guestbook-redis-master-5pg3b   1/1    Running   0          1m    guestbook   backend    master
guestbook-redis-replica-2q2yf  1/1    Running   0          1m    guestbook   backend    replica
guestbook-redis-replica-qgazl  1/1    Running   0          1m    guestbook   backend    replica
my-nginx-divi2                 1/1    Running   0          29m   nginx       <none>     <none>
my-nginx-o0ef1                 1/1    Running   0          29m   nginx       <none>     <none>

kubectl get pods -lapp=guestbook,role=replica

NAME                           READY  STATUS   RESTARTS  AGE
guestbook-redis-replica-2q2yf  1/1    Running  0         3m
guestbook-redis-replica-qgazl  1/1    Running  0         3m

更新标签

有时，您可能希望在创建新资源之前为现有的 Pod 和其他资源重新标记。这可以通过 kubectl label 完成。例如，如果您想将所有 NGINX Pod 标记为前端层（frontend tier），请运行：

kubectl label pods -l app=nginx tier=fe

pod/my-nginx-2035384211-j5fhi labeled
pod/my-nginx-2035384211-u2c7e labeled
pod/my-nginx-2035384211-u3t6x labeled

这首先会过滤所有标签为 "app=nginx" 的 Pod，然后用 "tier=fe" 标记它们。要查看您标记的 Pod，请运行：

kubectl get pods -l app=nginx -L tier

NAME                        READY     STATUS    RESTARTS   AGE       TIER
my-nginx-2035384211-j5fhi   1/1       Running   0          23m       fe
my-nginx-2035384211-u2c7e   1/1       Running   0          23m       fe
my-nginx-2035384211-u3t6x   1/1       Running   0          23m       fe

这将输出所有 "app=nginx" 的 Pod，并附带一个 Pod 层级（tier）的标签列（通过 -L 或 --label-columns 指定）。

欲了解更多信息，请参阅 kubectl label。

接下来

• 了解如何为节点添加标签
• 查找众所周知的标签、注解和污点
• 参阅推荐标签
• 使用命名空间标签强制执行 Pod 安全性标准
• 阅读关于编写 Pod 标签控制器的博客文章