Kubernetes对象之 Labels 和 Selectors

Kubernetes Labels 和 Selectors：
Labels其实就一对 key/value ，被关联到对象上，标签的使用我们倾向于能够标示对象的特殊特点
对用户而言是有意义的，但是标签对内核系统是没有直接意义的。
标签可以用来划分特定组的对象，标签可以在创建一个对象的时候直接给与，也可以在后期随时修改。
每一个对象可以拥有多个标签，但是，key值必须是唯一的。
我们最终会索引并且反向索引（reverse-index）labels，以获得更高效的查询和监视，把他们用到UI或者CLI中用来排序或者分组
不具有指认效果的信息应该使用annotation来记录。


Motivation：
Labels可以让用户将他们自己的有组织目的的结构以一种松耦合的方式应用到系统的对象上，且不需要客户端存放这些对应关系。
服务部署和批处理管道通常是多维的实体。


语法和字符集：
有效的标签键有两个段：
可选的前缀和名称，用斜杠（/）分隔，名称段是必需的，最多63个字符，以[a-z0-9A-Z]带有虚线（-）、下划线（_）、点（.）和开头和结尾必须是字母或数字（都是字符串形式）的形式组成。


Labels选择器（Labels Selectors）：
与Name和UID 不同，标签不需要有唯一性。一般来说，我们期望许多对象具有相同的标签。
通过标签选择器（Labels Selectors），客户端/用户 能方便辨识出一组对象。
标签选择器是kubernetes中核心的组成部分。
API目前支持两种选择器：equality-based（基于平等）和set-based（基于集合）
标签选择器可以由逗号分隔的多个requirements 组成。
一个为空的标签选择器（即有0个必须条件的选择器）会选择集合中的每一个对象。
一个null型标签选择器（仅对于可选的选择器字段才可能）不会返回任何对象。


Equality-based requirement 基于相等的要求：
基于相等的或者不相等的条件允许用标签的keys和values进行过滤。
匹配的对象必须满足所有指定的标签约束，尽管他们可能也有额外的标签。
有三种运算符是允许的，“=”，“==”和“!=”。


Set-based requirement：
Set-based 的标签条件允许用一组value来过滤key。
支持三种操作符: in ， notin 和 exists(仅针对于key符号) 。




API：
LIST和WATCH过滤：
LIST和WATCH操作可以指定标签选择器来过滤使用查询参数返回的对象集。
LIST和WATCH操作，可以使用query参数来指定label选择器来过滤返回对象的集合。
两个标签选择器样式都可用于通过REST客户端列出或观看资源。
两种标签选择器样式，都可以通过REST客户端来list或watch资源。


API对象中引用：
一些Kubernetes对象，也使用标签选择器来指定其他资源的集合。


Service和ReplicationController：
一个service针对的pods的集合是用标签选择器来定义的。
一个replicationcontroller管理的pods的群体也是用标签选择器来定义的。
这两种对象的Label选择器是用map定义在json或者yaml文件中的，并且只支持Equality-based的条件；
"selector": {
    "component" : "redis",
}
或
selector:
    component: redis




    支持set-based要求的资源：
    Job，Deployment，Replica Set，和Daemon Set，支持set-based要求。
    matchLabels 是一个{key,value}的映射。
    一个单独的 {key,value} 相当于 matchExpressions 的一个元素，它的key字段是”key”,操作符是 In ，并且value数组value包含”value”。 
    matchExpressions 是一个pod的选择器条件的list 。
selector:
  matchLabels:
    component: redis
  matchExpressions:
    - {key: tier, operator: In, values: [cache]}

    - {key: environment, operator: NotIn, values: [dev]}

内容整理自Kubernetes中文社区：https://www.kubernetes.org.cn/