标签是附加到对象的键/值对，就像 pod。标签旨在用于指定对用户有意义且与用户相关的对象的标识属性，但并不直接暗示核心系统的语义。标签可用于阻止和选择对象的子集。标签可以在创建时附加到对象上，然后可以随时添加和修改。每个对象可以定义一组键/值对标签。每个键对于给定的对象必须是唯一的。
"metadata": {
"labels": {
"key1" : "value1",
"key2" : "value2"
}
}
标签允许进行有效的查询和监控，并且非常适合在用户界面和命令行中使用。非识别信息应使用注解来记录。
动机
标签使用户能够以松散耦合的方式将子集的组织结构映射到系统对象上，而无需客户端存储这些映射。
服务部署和比处理流水线通常是多为实体（例如，多个分区或部署，多个发布轨道、多层、每层多个微服务）。流水线通畅需要跨领域操作，这会破坏严格的层析结构形式的封装，尤其是由基础结构而非用户确定的硬性的层次结构。
标签示例：
"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 个字符，后跟斜杠（/）。
如果省略前缀，则假定标签 Key 对用户是私有的。向最终用户对象添加标签的自动化系统组件（例如 kube-scheduler、kube-controller-manager、kube-apiserver、kubectl 或其他第三方自动化）必须指定前缀。
kubernetes.io/ 及 k8s.io/ 前缀是为 Kubernetes 核心组件保留的。
有效标签值必须为 63 个字符或更少，并且必须为空，或者以带破折号（-）、下划线（_）、点（.）及字母数字的字母数字字符（[a-z0-9A-Z]）开头和结尾之间。
例如，这是具有两个标签环境的 Pod 的配置文件：production 及 app:nginx：
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 不同，标签不提供唯一性。通常，我们希望许多对象带有相同的标签。
通过标签选择器，客户端/用户可以识别一组对象。标签选择器是 Kubernetes 中的核心分组原语。
该 API 当前支持两种类型的选择器：基于相等性和基于集合。标签选择器可以由多个要求组成，这些要求以逗号分隔。在有多个要求的情况下，必须满足所有条件，以便逗号分隔符充当逻辑与（&&）运算符。
空的或为指定的选择器的语义取决于上下文，并且使用选择器的 API 类型应记录它们的有效性和含义。
注意：对于某些 API 类型（例如 ReplicaSets），两个实例的标签选择器不得在命名空间内重叠，否则控制器会将其视为冲突的指令，而无法确定应存在多少个副本。
警告：对于基于相等性的条件和基于集合的条件，都没有逻辑或（
||）运算符。确保我们的过滤器语句具有相应的结构。
基于相等性的需求
基于相等或不相等的要求允许按标签键和值进行过滤。匹配对象必须满足所有指定的标签约束，尽管他们也可能具有其他标签。允许使用三种运算符 =、==、!=。前两个代表相等（并且只是同义词），而最后一个代表不相等。例如：
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: "k8s.gcr.io/cuda-vector-add:v0.1"
resources:
limits:
nvidia.com/gpu: 1
nodeSelector:
accelerator: nvidia-tesla-p100
基于集合的需求
基于集合的标签要求允许根据一组值过滤关键字。支持三种运算符：in、notin 及 exists（仅键标识符）。例如：
environment in (product, qa)
tier notin (frontend, backend)
partition
!partition
第一个示例选择键等于 environment 且值等于 production 或 qa 的所有资源。第二个实例选择键等于 tier 的所有资源及 frontend 和 backend 意外的其他值，以及所有没有 tier 键的标签的资源。第三个示例选择所有带有 partition 键的标签的资源；不检查任何值。第四个示例选择不带 partition 键的标签的所有资源。不检查任何值。同样，逗号分隔充当与运算符。因此，可以使用 partition, environment notin (qa) 来实现使用 partition 键（无论其值是什么）和 environment 不是 qa 来过滤资源。基于集合的标签选择器是相等的一般形式，因为 environment=production 等同于 environment in (production)；!= 和 notin 的相似性。
基于集合的需求可以与基于相等性的需求混合。例如：partition in (customerA, customerB),environment!=qa。
API
LIST 和 WATCH 过滤
LIST 和 WATCH 操作可以指定标签选择器以过滤使用查询参数返回的对象集。这两个需求都是允许的（在该处现实，因为它们将出现在 URL 查询字符串中）：
- 基于相等性的要求：
?labelSelector=environment%3Dproduction,tier%3Dfrontend； - 基于集合的要求：
?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29。
两种标签选择器样式均可用于通过 REST 客户端列出或监控资源。例如，使用 kubectl 定位 apiserver 并使用基于相等性的 apiserver 可以这样写：
kubectl get pods -l environment=production,tier=frontend
或使用基于集合的要求：
kubectl get pods -l 'environment in (production),tier in (frontend)'
如前所述，基于集合的需求更具表现力。例如，他们可以在值上实现或运算符：
kubectl get pods -l 'environment in (production, qa)'
或通过存在运算符限制否定匹配：
kubectl get pods -l 'environment,environment notin (frontend)'
API 对象里的集合引用
一些 Kubernetes 对象，像是Service（敬请期待～～）及RelicationController（敬请期待～～），也适用标签选择器来指定其他资源集，像是 Pod（敬请期待～～）。
服务和副本复制控制器
服务目标的 pod 集合是使用标签选择器定义的。同样，还使用标签选择器定义了副本复制控制器应该管理的 pod 数量。
使用映射在 json 或 yaml 文件中定义了两个对象的标签选择器，并且仅支持基于相等性需求的选择器：
"selector": {
"component" : "redis",
}
或
selector:
component: redis
该选择器（分别为 json 或 yaml 格式）等价于 component=redis 或 redis or 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 和 DidNotExist。对于 In 和 NotIn，设置的值必须为非空。matchLabels 和 matchExpressions 的所有需求都进行 “与” 运算 - 必须全部满足才能匹配。
选择节点集合
用于选择标签的一个用例是约束 Pod 可以调度到的一组节点。有关更多信息，请参见有关节点选择（敬请期待～～）的文档。
