Kubernetes对象-标签和选择器

Kubernetes对象标签和选择器

标签是附加到 Pod 等对象上的多组键值对，旨在为对象指定对用户相关且有意义的标识属性，不直接包含对核心系统的语义含义，可用来组织和选择对象子集。可以在创建对象时附加标签，随后可以随时添加和修改。每个对象都可以定义一组键/值标签。对于同一个对象，每个 Key 必须是唯一的。

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

基于标签，可以快速对对象进行查询和监视，适合在 UI 和 CLI 中使用。非识别信息应使用注解来进行记录。

动机

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

服务部署和批处理管道通常是多维实体（例如，多个分区或部署、多个发布路线、多个层、每层多个微服务）。管理通常需要横切操作，这打破了按照严格分层表示的封装，尤其是由基础设施而不是用户确定的不可变层次结构。

示例标签：

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

以上演示的是常用的标签，可以自由制定标签约定，但是对与指定的对象，标签的 Key 必须是唯一的。

语法和字符集

标签是键值对。有效的标签键由两部分组成：一个可选的前缀和名称，由斜杠（/）分隔。名称部分是必需的，并且不得超过 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] 开头和结尾。
• 可以包含破折号 （-）、下划线 （_）、点 （.） 和字母数字。

例如，下面是一个 Pod 的 manifest，它有两个标签environment: 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），两个实例的标签选择器在命名空间内不得重叠，否则控制器会将其视为冲突指令，无法确定应该存在多少个副本。

对于基于等值和基于集合的条件，不存在逻辑“或”（OR (||)）运算符。

基于等值的需求

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

environment = production
tier != frontend

前者选择所有键 environment 值为 production 的资源。后者选择所有键 tier 值不为 frontend 的资源，以及所有没有 tier 键标签的资源。可以使用逗号运算符来合并这两个过滤条件：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 的 label，不检查任何值。
• 第四个示例选择所有没有标签为 partition 的资源，不检查任何值。

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

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

API

LIST 和 WATCH 过滤

对于 list 和 watch 操作，可以指定标签选择器来过滤返回的对象集；通过使用查询参数指定筛选条件。允许以下两种请求：

• 基于相等的需求：?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 and 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、Exist 和 DoesNotExist。在 In 和 NotIn 的情况下，设置的值必须为非空。来自 matchLabels 和 matchExpressions 的所有要求都被 ANDed 在一起——它们都必须得到满足才能匹配。

选择节点集

选择标签的一个用例是限制 pod 可以调度的节点集。

高效使用标签

可以将单个标签应用于任何资源，但这并不总是最佳实践。在许多情况下，应使用多个标签来区分资源集。

例如，不同的应用程序将对 app 标签使用不同的值，但多层应用程序（如留言簿示例）还需要区分每个层。前端可以带有以下标签：

labels:
  app: guestbook
  tier: frontend

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

labels:
  app: guestbook
  tier: backend
  role: master

和

labels:
  app: 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 标记为前端层，请运行：

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 层级的附加标签列（使用 -L 或 --label-columns指定）。

链接

• Kubernetes Object Labels and Selectors