Label和Selector(Label和选择器)

Label是附加到对象(如Pod)的键值对。Label旨在用于指定对用户有意义的对象的识别属性,但不直接表示核心系统的语义。Label可用于组织和选择对象的子集。Label可在创建时附加到对象,也可在创建后随时添加和修改。每个对象都可定义一组Label。 对于给定的对象,Key必须唯一。

  1. "labels" : {
  2. "key1" : "value1" ,
  3. "key2" : "value2"
  4. }

我们最终会对Label进行索引和反向索引,以便于高效的查询、watch、排序、分组等操作。不要使用非标识的、大型的结构化数据污染Label。对于非标识的信息应使用非标识,特别是大型和/或结构化数据来污染Label。 非识别信息应使用 annotation 记录。

动机

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

服务部署和批处理流水线通常是多维实体(例如:多个分区或部署、多个发布轨道、多个层、每层有多个微服务)。管理往往需要跨部门才能进行,这打破了严格层级表现的封装,特别是由基础设施而非用户确定的刚性层次结构。

示例Label:

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

以上只是常用Label示例。可自由定制。请记住,给定对象的Label的key必须唯一。

语法和字符集

Label是键值对的形式。

有效Label的key分为两段:

  • 名称段和前缀段,以 / 分隔。
  • 名称段是必需的,不超过63个字符,以字母或数字( [a-z0-9A-Z] )开头和结尾,中间可包含 -_. 、字母或数字等字符。
  • 前缀段是可选的。必须是DNS子域:一系列由 . 分隔的DNS Label,总共不超过253个字符,后跟 /
  • 如省略前缀,则假定Label的Key对用户是私有的。
  • 为最终用户对象添加Label的自动化系统组件(例如, kube-schedulerkube-controller-managerkube-apiserverkubectl 或其他第三方自动化组件)必须指定前缀。 kubernetes.io/ 前缀保留给Kubernetes核心组件。

有效的Label值必须:

  • 不超过63个字符
  • 为空,或者:以字母或数字( [a-z0-9A-Z] )开头和结尾,中间包含 -_. 、字母或数字等字符。

Label选择器

不同于 names and UIDs ,Label不提供唯一性。一般来说,多个可对象携带相同的Label。

通过Label选择器 ,客户端/用户可识别一组对象。Label选择器是Kubernetes中的核心分组API。

API目前支持两种类型的选择器:equality-basedset-based 。Label选择器可由逗号分隔的多个需求组成。在多重需求的情况下,必须满足所有需求,因此逗号作为AND逻辑运算符。

一个empty Label选择器(即一个零需求的选择器)选择集合中的每个对象。

null Label选择器(仅用于可选的选择器字段)不选择任何对象。

注意 :两个Controller的Label选择器不能在命名空间内重叠,否则它们将会产生冲突。

Equality-based requirement

Equality- or inequality-based requirement允许通过LabelKey和Value进行过滤。匹配对象必须满足所有的Label约束,尽管对象可能还有其他Label。允许使用三种运算符:===!= 。前两个表示相等 (只是同义),而后者则表示不相等 。 例如:

  1. environment = production
  2. tier != frontend

前者选择所有与key = environment 并且value = production 的资源。后者选择key = tier 并且value不等于frontend ,以及key不等于tier 的所有资源。可使用, 过滤是生产环境中(production )非前端(frontend )的资源:environment=production,tier!=frontend

Set-based requirement

Set-based label requirement允许根据一组Value过滤Key。支持三种运算符: innotinexists(只有Key标识符)。 例如:

  1. environment in (production, qa)
  2. tier notin (frontend, backend)
  3. partition
  4. !partition

第一个示例选择Key等于environment ,Value等于productionqa 的所有资源。

第二个示例选择Key等于tier ,Value不等于frontendbackend,以及所有Key不等于tier 的所有资源。

第三个示例选择Key包含partition 所有资源;不检查Value的值。

第四个示例选择Key不包含partition 的所有资源,不检查任何值。

类似地,逗号可用作AND运算符。 因此可用partition,environment notin (qa) 过滤 Key = partition(无论值)并且environment != qa 的资源。 基于集合的Label选择器,也可表示基于等式的Label选择。例如,environment=production等同于environment in (production) ; 同样,!= 等同于notin

Set-based requirement可以与equality-based requirement混合使用。例如: partition in (customerA, customerB),environment!=qa

API

LIST与WATCH过滤

LIST和WATCH操作可指定Label选择器,这样就可以使用查询参数过滤返回的对象集。两种requirement都是允许的(在这里表示,它们将显示在URL查询字符串中):

  • equality-based requirement: ?labelSelector=environment%3Dproduction,tier%3Dfrontend
  • set-based requirements: ?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29

两种Label选择器都可用于在REST客户端中LIST或WATCH资源。例如,使用kubectl 定位apiserver 并使用 equality-based 的方式可写为:

  1. $ kubectl get pods -l environment=production,tier=frontend

或使用set-based requirements:

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

如上所示,set-based requirement表达能力更强。例如,他们可以对Value执行OR运算符:

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

或通过exists操作符,实现restricting negative matching:

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

在API对象中设置引用

一些Kubernetes对象(如 servicesreplicationcontrollers )也可使用Label选择器来指定其他资源(例如 pods )。

Service 和 ReplicationController

使用Label选择器定义service 指向的一组Pod。类似地, replicationcontroller 所管理的Pod总数也可用Label选择器定义。

两个对象的Label选择器都使用map在jsonyaml 文件中定义,只支持equality-based requirement选择器:

  1. "selector": {
  2. "component" : "redis",
  3. }

或:

  1. selector:
  2. component: redis

此选择器(分别以jsonyaml 格式)等价于 component=rediscomponent in (redis)

支持set-based requirement的资源

较新的资源(例如 JobDeploymentReplica Set 以及 Daemon Set )也支持 set-based requirement。

  1. selector:
  2. matchLabels:
  3. component: redis
  4. matchExpressions:
  5. - {key: tier, operator: In, values: [cache]}
  6. - {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时,Value必须非空。所有来自matchLabelsmatchExpressions 的需求使用AND串联,所有需求都满足才能匹配。

选择Node列表

使用Label选择Node的一个用例是约束一个Pod能被调度到哪些Node上。有关详细信息,请参阅有关 node selection 的文档。