标签和选择算符

    标签能够支持高效的查询和监听操作，对于用户界面和命令行是很理想的。 应使用注解记录非识别信息。

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

    服务部署和批处理流水线通常是多维实体（例如，多个分区或部署、多个发行序列、多个层，每层多个微服务）。 管理通常需要交叉操作，这打破了严格的层次表示的封装，特别是由基础设施而不是用户确定的严格的层次结构。

    示例标签：

    • , "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]）开头和结尾
    • 包含破折号（-）、下划线（_）、点（.）和字母或数字

    例如，这是一个有 environment: production 和 app: nginx 标签的 Pod 配置文件：

    2. apiVersion: v1
    3. kind: Pod
    4.   name: label-demo
    5.   labels:
    6.     environment: production
    7.     app: nginx
    8. spec:
    9.   containers:
    10.   - name: nginx
    11.     image: nginx:1.14.2
    12.     ports:
    13.     - containerPort: 80

    与名称和 UID 不同， 标签不支持唯一性。通常，我们希望许多对象携带相同的标签。

    通过标签选择算符，客户端/用户可以识别一组对象。标签选择算符是 Kubernetes 中的核心分组原语。

    空标签选择算符或者未指定的选择算符的语义取决于上下文， 支持使用选择算符的 API 类别应该将算符的合法性和含义用文档记录下来。

    说明：

    对于某些 API 类别（例如 ReplicaSet）而言，两个实例的标签选择算符不得在命名空间内重叠， 否则它们的控制器将互相冲突，无法确定应该存在的副本个数。

    注意：

    对于基于等值的和基于集合的条件而言，不存在逻辑或（）操作符。 你要确保你的过滤语句按合适的方式组织。

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

    1. environment = production
    2. tier != frontend

    前者选择所有资源，其键名等于 environment，值等于 production。 后者选择所有资源，其键名等于 tier，值不同于 frontend，所有资源都没有带有 tier 键的标签。 可以使用逗号运算符来过滤 production 环境中的非 frontend 层资源：environment=production,tier!=frontend。

    基于等值的标签要求的一种使用场景是 Pod 要指定节点选择标准。 例如，下面的示例 Pod 选择带有标签 “accelerator=nvidia-tesla-p100“。

    1. apiVersion: v1
    2. kind: Pod
    3. metadata:
    4.   name: cuda-test
    5. spec:
    6.   containers:
    7.     - name: cuda-test
    8.       image: "registry.k8s.io/cuda-vector-add:v0.1"
    9.       resources:
    10.         limits:
    11.   nodeSelector:
    12.     accelerator: nvidia-tesla-p100

    基于集合的标签需求允许你通过一组值来过滤键。 支持三种操作符：in、notin 和 exists（只可以用在键标识符上）。例如：

    • 第一个示例选择了所有键等于 environment 并且值等于 production 或者 qa 的资源。
    • 第二个示例选择了所有键等于 tier 并且值不等于 frontend 或者 backend 的资源，以及所有没有 tier 键标签的资源。
    • 第三个示例选择了所有包含了有 partition 标签的资源；没有校验它的值。
    • 第四个示例选择了所有没有 partition 标签的资源；没有校验它的值。

    类似地，逗号分隔符充当与运算符。因此，使用 partition 键（无论为何值）和 environment 不同于 qa 来过滤资源可以使用 partition, environment notin (qa) 来实现。

    基于集合的标签选择算符是相等标签选择算符的一般形式，因为 environment=production 等同于 environment in (production)； 和 notin 也是类似的。

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

    • 基于等值的需求：?labelSelector=environment%3Dproduction,tier%3Dfrontend
    • 基于集合的需求：?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29

    两种标签选择算符都可以通过 REST 客户端用于 list 或者 watch 资源。 例如，使用 kubectl 定位 apiserver，可以使用基于等值的标签选择算符可以这么写：

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

    或者使用基于集合的需求：

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

    正如刚才提到的，基于集合的需求更具有表达力。例如，它们可以实现值的或操作：

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

    或者通过exists运算符限制不匹配：

    一些 Kubernetes 对象，例如 services 和 ， 也使用了标签选择算符去指定了其他资源的集合，例如 pods。

    Service 和 ReplicationController

    一个 Service 指向的一组 Pod 是由标签选择算符定义的。同样，一个 ReplicationController 应该管理的 Pod 的数量也是由标签选择算符定义的。

    两个对象的标签选择算符都是在 json 或者 yaml 文件中使用映射定义的，并且只支持 基于等值需求的选择算符：

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

    或者

    1. selector:
    2.     component: redis

    这个选择算符（分别在 json 或者 yaml 格式中）等价于 component=redis 或 component in (redis)。

    支持基于集合需求的资源

    比较新的资源，例如 、 Deployment、 和 DaemonSet， 也支持基于集合的需求。

    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 的情况下，设置的值必须是非空的。 来自 matchLabels 和 matchExpressions 的所有要求都按逻辑与的关系组合到一起 — 它们必须都满足才能匹配。

    选择节点集

    通过标签进行选择的一个用例是确定节点集，方便 Pod 调度。 有关更多信息，请参阅选择节点文档。