concepts/overview/working-with-objects/labels/

Labels and Selectors 便签和选择器

Labels are key/value pairs that are attached to objects, such as pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. Labels can be used to organize and to select subsets of objects. Labels can be attached to objects at creation time and subsequently added and modified at any time. Each object can have a set of key/value labels defined. Each Key must be unique for a given object.
labels是附加到对象（如pod）的键/值对。标签用于指定对象的标识属性，这些属性对用户有意义且相关，但不直接向核心系统暗示语义。标签可用于组织和选择对象的子集。标签可以在创建时附加到对象，然后可以随时添加和修改。每个对象都可以定义一组键/值标签。对于给定的对象，每个键必须是唯一的。

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

Labels allow for efficient queries and watches and are ideal for use in UIs and CLIs. Non-identifying information should be recorded using annotations标签允许高效的查询和监视，非常适合在ui和clis中使用。应使用注释记录非识别信息。

• Motivation
• Syntax and character set
• Label selectors
• API

Motivation 动机

标签使用户能够以松散耦合的方式将自己的组织结构映射到系统对象上，而不需要客户机存储这些映射。
服务部署和批处理管道通常是多维实体（例如，多个分区或部署、多个发布跟踪、多个层、每层多个微服务）。管理通常需要横切操作，这打破了严格层次表示的封装，特别是由基础结构而不是用户决定的严格层次。(简而言之见名知意)

Example labels:

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

这些只是常用标签的示例；您可以自由开发自己的约定。请记住，对于给定的对象，标签键必须是唯一的。

Syntax and character set 语法和字符集

Labels are key/value pairs. Valid label keys have two segments: an optional prefix and name, separated by a slash (/). The name segment is required and must be 63 characters or less, beginning and ending with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), underscores (_), dots (.), and alphanumerics between. The prefix is optional. If specified, the prefix must be a DNS subdomain: a series of DNS labels separated by dots (.), not longer than 253 characters in total, followed by a slash (/).标签是键/值对。有效的标签键有两个段：可选的前缀和名称，用斜线（/）分隔。名称段是必需的，必须不超过63个字符，以字母数字字符（[A-Z0-9A-Z]）开头和结尾，中间有破折号（-）、下划线（_）、点（.）和字母数字。前缀是可选的。如果指定，前缀必须是DNS子域：由点（.）分隔的一系列DNS标签，总共不超过253个字符，后跟斜杠（/）。

If the prefix is omitted, the label Key is presumed to be private to the user. Automated system components (e.g. kube-scheduler, kube-controller-manager, kube-apiserver, kubectl, or other third-party automation) which add labels to end-user objects must specify a prefix.

如果省略前缀，则标签密钥被假定为用户专用。向最终用户对象添加标签的自动化系统组件（例如kube调度器、kube控制器管理器、kube apiserver、kubectl或其他第三方自动化）必须指定前缀。

The kubernetes.io/ and k8s.io/前缀是为kubernetes核心组件保留的。

Valid label values must be 63 characters or less and must be empty or begin and end with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), underscores (_), dots (.), and alphanumerics between.有效的标签值必须不超过63个字符，并且必须为空，或者以字母数字字符（[A-Z0-9A-Z]）开头和结尾，中间带有破折号（-）、下划线（_）、点（.）和字母数字。

For example, here’s the configuration file for a Pod that has two labels environment: production and app: nginx 例如，下面是一个pod的配置文件，它有两个标签环境：production和app:nginx：

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80

Label selectors 标签选择器

Unlike names and UIDs, labels do not provide uniqueness. In general, we expect many objects to carry the same label(s).与名称和uid不同，标签不提供唯一性。一般来说，我们希望许多对象都带有相同的标签。

Via a label selector, the client/user can identify a set of objects. The label selector is the core grouping primitive in Kubernetes.通过标签选择器，客户机/用户可以标识一组对象。标签选择器是kubernetes中的核心分组原语。

The API currently supports two types of selectors: equality-based and set-based. A label selector can be made of multiple requirements which are comma-separated. In the case of multiple requirements, all must be satisfied so the comma separator acts as a logical AND (&&) operator.api目前支持两种类型的选择器：基于等式的选择器和基于集合的选择器。标签选择器可以由逗号分隔的多个需求组成。在多个要求的情况下，必须满足所有要求，以便逗号分隔符充当逻辑和（&&）运算符。

The semantics of empty or non-specified selectors are dependent on the context, and API types that use selectors should document the validity and meaning of them.空选择器或非指定选择器的语义取决于上下文，使用选择器的api类型应记录它们的有效性和含义。

Note: For some API types, such as ReplicaSets, the label selectors of two instances must not overlap within a namespace, or the controller can see that as conflicting instructions and fail to determine how many replicas should be present.注意：对于某些api类型，例如replicasets，两个实例的标签选择器不能在命名空间中重叠，否则控制器会将其视为冲突的指令，并且无法确定应该存在多少个副本。

Equality-based requirement

基于等式或不等式的要求允许通过标签键和值进行过滤。匹配对象必须满足所有指定的标签约束，尽管它们也可能有其他标签。允许三种运算符=，=，！=前两个代表平等（只是同义词），后一个代表不平等。例如：

environment = production
tier != frontend

The former selects all resources with key equal to environment and value equal to production. The latter selects all resources with key equal to tier and value distinct from frontend, and all resources with no labels with the tier key. One could filter for resources in production excluding frontend using the comma operator: environment=production,tier!=frontend前者选择的是关键等于环境、值为production。后者选择键等于层且值不同于前端的所有资源，以及没有带层键标签的所有资源。可以使用逗号运算符筛选生产中的资源（不包括前端）：environment=production，tier！=前端

One usage scenario for equality-based label requirement is for Pods to specify node selection criteria. For example, the sample Pod below selects nodes with the label “accelerator=nvidia-tesla-p100”.基于等式的标签需求的一个使用场景是pods指定节点选择标准。例如，下面的示例pod选择标签为“accelerator=nvidia-tesla-p100”的节点。

apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "k8s.gcr.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100

Set-based requirement基于集合的需求

Set-based label requirements allow filtering keys according to a set of values. Three kinds of operators are supported: in,notin and exists (only the key identifier). For example:基于集合的标签要求允许根据一组值筛选键。支持三种运算符：in、notin和exists（仅密钥标识符）。例如：

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition

The first example selects all resources with key equal to environment and value equal to production or qa. The second example selects all resources with key equal to tier and values other than frontend and backend, and all resources with no labels with the tier key. The third example selects all resources including a label with key partition; no values are checked. The fourth example selects all resources without a label with key partition; no values are checked. Similarly the comma separator acts as an AND operator. So filtering resources with a partition key (no matter the value) and with environment different than qa can be achieved using partition,environment notin (qa). The set-based label selector is a general form of equality since environment=production is equivalent to environment in (production); similarly for != and notin.第一个例子选择的所有资源的key等于environment，value等于production或qa。第二个示例选择键等于层和值的所有资源（前端和后端除外），以及没有带层键标签的所有资源。第三个示例选择所有资源，包括带有键分区的标签；不选中任何值。第四个示例选择所有没有带键分区标签的资源；不检查任何值。类似地，逗号分隔符充当and运算符。因此，使用分区键（无论值如何）和与qa不同的环境过滤资源可以使用分区environment notin（qa）来实现。由于environment=production与environment in（production）等价，因此基于集合的标签选择器是一种通用的相等形式；与此类似！=和诺丁

Set-based requirements can be mixed with equality-based requirements. For example: partition in (customerA, customerB),environment!=qa.基于集合的需求可以与基于等式的需求混合。例如：环境中的分区（customera，customerb）！= QA。

API

LIST and WATCH filtering

LIST and WATCH operations may specify label selectors to filter the sets of objects returned using a query parameter. Both requirements are permitted (presented here as they would appear in a URL query string):列表和监视操作可以指定标签选择器来筛选使用查询参数返回的对象集。这两个要求都是允许的（此处的显示方式与url查询字符串中的显示方式相同）：

• equality-based requirements(等值筛选): ?labelSelector=environment%3Dproduction,tier%3Dfrontend
• set-based requirements(集合筛选): ?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29

Both label selector styles can be used to list or watch resources via a REST client. For example, targeting apiserver with kubectl and using equality-based one may write:两种标签选择器样式都可用于通过rest客户端列出或监视资源。例如，以kubectl为目标并使用基于等式的apiserver可以写入：

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

or using set-based requirements:

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

As already mentioned set-based requirements are more expressive. For instance, they can implement the OR operator on values:如前所述，基于集合的需求更具表现力。例如，它们可以在值上实现或运算符

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

or restricting negative matching via exists operator: 或通过exists运算符限制负匹配：

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

Set references in API objects在API对象中设置引用

Some Kubernetes objects, such as services and replicationcontrollers, also use label selectors to specify sets of other resources, such as pods.一些kubernetes对象，比如服务和复制控制器，也使用标签选择器来指定其他资源集，比如pods。

Service and ReplicationController

The set of pods that a service targets is defined with a label selector. Similarly, the population of pods that a replicationcontroller should manage is also defined with a label selector.用标签选择器定义服务目标的pod集。类似地，复制控制器应该管理的pod的数量也由标签选择器定义。

Labels selectors for both objects are defined in json or yaml files using maps, and only equality-based requirement selectors are supported:两个对象的标签选择器使用映射在json或yaml文件中定义，并且只支持基于等式的需求选择器：

"selector": {
    "component" : "redis",
}

or

selector:
    component: redis

this selector (respectively in json or yaml format) is equivalent to component=redis or component in (redis).这个选择器（分别采用json或yaml格式）相当于component=redis或component-in（redis）。

Resources that support set-based requirements支持基于集合的需求的资源

Newer resources, such as Job, Deployment, Replica Set, and Daemon Set, support set-based requirements as well.较新的资源，如作业、部署、副本集和守护程序集，也支持基于集的需求。

selector:
  matchLabels:
    component: redis
  matchExpressions:
    - {key: tier, operator: In, values: [cache]}
    - {key: environment, operator: NotIn, values: [dev]}

matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is “key”, the operator is “In”, and the values array contains only “value”. matchExpressions is a list of pod selector requirements. Valid operators include In, NotIn, Exists, and DoesNotExist. The values set must be non-empty in the case of In and NotIn. All of the requirements, from both matchLabels and matchExpressions are ANDed together – they must all be satisfied in order to match.matchlabels是{key，value}对的映射。matchlabels映射中的单个{key，value}等价于matchexpressions的元素，其键字段为“key”，运算符为“in”，值数组仅包含“value”。matchexpressions是pod选择器需求的列表。有效的运算符包括in、notin、exists和doesnotexist。对于in和notin，设置的值必须为非空。matchlabels和matchexpressions中的所有要求都被放在一起，必须满足所有这些要求才能匹配。

Selecting sets of nodes

One use case for selecting over labels is to constrain the set of nodes onto which a pod can schedule. See the documentation on node selection for more information.

选择标签的一个用例是约束pod可以调度的节点集。有关详细信息，请参阅有关节点选择的文档。

Feedback

Was this page helpful?

本作品采用《CC 协议》，转载必须注明作者和本文链接