9-Overview-Labels and Selectors

cucytoman發表於2019-09-24
View

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

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 動機

標籤使使用者能夠以鬆散耦合的方式將自己的組織結構對映到系統物件上，而不需要客戶機儲存這些對映。
服務部署和批處理管道通常是多維實體（例如，多個分割槽或部署、多個釋出跟蹤、多個層、每層多個微服務）。管理通常需要橫切操作，這打破了嚴格層次表示的封裝，特別是由基礎結構而不是使用者決定的嚴格層次。(簡而言之見名知意)

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 協議》，轉載必須註明作者和本文連結

相關文章