- Label和Selector(Label和选择器)
- 动机
- 语法和字符集
- Label选择器
- Equality-based requirement
- Set-based requirement
- API
- LIST与WATCH过滤
- 在API对象中设置引用
- Service 和 ReplicationController
- 支持set-based requirement的资源
- 选择Node列表
Label和Selector(Label和选择器)
Label是附加到对象(如Pod)的键值对。Label旨在用于指定对用户有意义的对象的识别属性,但不直接表示核心系统的语义。Label可用于组织和选择对象的子集。Label可在创建时附加到对象,也可在创建后随时添加和修改。每个对象都可定义一组Label。 对于给定的对象,Key必须唯一。
"labels" : {
"key1" : "value1" ,
"key2" : "value2"
}
我们最终会对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-scheduler
、kube-controller-manager
、kube-apiserver
、kubectl
或其他第三方自动化组件)必须指定前缀。kubernetes.io/
前缀保留给Kubernetes核心组件。
有效的Label值必须:
- 不超过63个字符
- 为空,或者:以字母或数字(
[a-z0-9A-Z]
)开头和结尾,中间包含-
、_
、.
、字母或数字等字符。
Label选择器
不同于 names and UIDs ,Label不提供唯一性。一般来说,多个可对象携带相同的Label。
通过Label选择器 ,客户端/用户可识别一组对象。Label选择器是Kubernetes中的核心分组API。
API目前支持两种类型的选择器:equality-based 和 set-based 。Label选择器可由逗号分隔的多个需求组成。在多重需求的情况下,必须满足所有需求,因此逗号作为AND逻辑运算符。
一个empty Label选择器(即一个零需求的选择器)选择集合中的每个对象。
null Label选择器(仅用于可选的选择器字段)不选择任何对象。
注意 :两个Controller的Label选择器不能在命名空间内重叠,否则它们将会产生冲突。
Equality-based requirement
Equality- or inequality-based requirement允许通过LabelKey和Value进行过滤。匹配对象必须满足所有的Label约束,尽管对象可能还有其他Label。允许使用三种运算符:=
、 ==
、 !=
。前两个表示相等 (只是同义),而后者则表示不相等 。 例如:
environment = production
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。支持三种运算符: in
、notin
和exists
(只有Key标识符)。 例如:
environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
第一个示例选择Key等于environment
,Value等于production
或qa
的所有资源。
第二个示例选择Key等于tier
,Value不等于frontend
或backend
,以及所有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 的方式可写为:
$ kubectl get pods -l environment=production,tier=frontend
或使用set-based requirements:
$ kubectl get pods -l 'environment in (production),tier in (frontend)'
如上所示,set-based requirement表达能力更强。例如,他们可以对Value执行OR运算符:
$ kubectl get pods -l 'environment in (production, qa)'
或通过exists操作符,实现restricting negative matching:
$ kubectl get pods -l 'environment,environment notin (frontend)'
在API对象中设置引用
一些Kubernetes对象(如 services
和 replicationcontrollers
)也可使用Label选择器来指定其他资源(例如 pods )。
Service 和 ReplicationController
使用Label选择器定义service
指向的一组Pod。类似地, replicationcontroller
所管理的Pod总数也可用Label选择器定义。
两个对象的Label选择器都使用map在json
或yaml
文件中定义,只支持equality-based requirement选择器:
"selector": {
"component" : "redis",
}
或:
selector:
component: redis
此选择器(分别以json
或yaml
格式)等价于 component=redis
或component in (redis)
。
支持set-based requirement的资源
较新的资源(例如 Job
、 Deployment
、 Replica Set
以及 Daemon Set
)也支持 set-based requirement。
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时,Value必须非空。所有来自matchLabels
和matchExpressions
的需求使用AND串联,所有需求都满足才能匹配。
选择Node列表
使用Label选择Node的一个用例是约束一个Pod能被调度到哪些Node上。有关详细信息,请参阅有关 node selection 的文档。