標籤

標籤其實就一對 key/value ，被關聯到物件上，比如Pod,標籤的使用我們傾向於能夠標示物件的特殊特點，並且對使用者而言是有意義的（就是一眼就看出了這個Pod是尼瑪資料庫），但是標籤對核心系統是沒有直接意義的。標籤可以用來劃分特定組的物件（比如，所有女的），標籤可以在建立一個物件的時候直接給與，也可以在後期隨時修改，每一個物件可以擁有多個標籤，但是，key值必須是唯一的

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

我們最終會索引並且反向索引（reverse-index）labels，以獲得更高效的查詢和監視，把他們用到UI或者CLI中用來排序或者分組等等。我們不想用那些不具有指認效果的label來汙染label，特別是那些體積較大和結構型的的資料。不具有指認效果的資訊應該使用annotation來記錄。

Motivation

Label可以讓使用者將他們自己的有組織目的的結構以一種鬆耦合的方式應用到系統的物件上，且不需要客戶端存放這些對應關係（mappings）。

服務部署和批處理管道通常是多維的實體（例如多個分割槽或者部署，多個釋出軌道，多層，每層多微服務）。管理通常需要跨越式的切割操作，這會打破有嚴格層級展示關係的封裝，特別對那些是由基礎設施而非使用者決定的很死板的層級關係。

Label例子

“release” : “stable”, “release” : “canary”, …
 “environment” : “dev”, “environment” : “qa”, “environment” : “production”
 “tier” : “frontend”, “tier” : “backend”, “tier” : “middleware”
 “partition” : “customerA”, “partition” : “customerB”, …
 “track” : “daily”, “track” : “weekly”

Label的語法和字符集

Label其實是一對 key/value，有效的Label keys必須是部分：一個可選字首+名稱，通過/來區分，名稱部分是必須的，並且最多63個字元，開始和結束的字元必須是字母或者數字，中間是字母數字和”_”，”-“，”.”，字首是刻有可無的，如果指定了，那麼字首必須是一個DNS子域，一系列的DNSlabel通過”.”來劃分，長度不超過253個字元，“/”來結尾。如果字首被省略了，這個Label的key被假定為對使用者私有的，自動系統組成部分（比如kube-scheduler, kube-controller-manager, kube-apiserver, kubectl）,這些為終端使用者新增標籤的必須要指定一個字首，Kuberentes.io 字首是為Kubernetes 核心部分保留的。

合法的label值必須是63個或者更短的字元。要麼是空，要麼首位字元必須為字母數字字元，中間必須是橫線，下劃線，點或者數字字母。

Label選擇器

與name和UID不同，label不提供唯一性。通常，我們會看到很多物件有著一樣的label。

通過label選擇器，客戶端/使用者能方便辨識出一組物件。label選擇器是kubernetes中核心的組織原語。

API目前支援兩種選擇器：基於相等的和基於集合的。一個label選擇器一可以由多個必須條件組成，由逗號分隔。在多個必須條件指定的情況下，所有的條件都必須滿足，因而逗號起著AND邏輯運算子的作用。

一個空的label選擇器（即有0個必須條件的選擇器）會選擇集合中的每一個物件。

一個null型label選擇器（僅對於可選的選擇器欄位才可能）不會返回任何物件。

Equality-based requirement

基於相等性或者不相等性的條件允許用label的鍵或者值進行過濾。匹配的物件必須滿足所有指定的label約束，儘管他們可能也有額外的label。有三種運算子是允許的，“=”，“==”和“!=”。前兩種代表相等性（他們是同義運算子），後一種代表非相等性。例如：

environment = production
 tier != frontend

第一個選擇所有鍵等於 environment 值為 production 的資源。後一種選擇所有鍵為 tier 值不等於 frontend 的資源，和那些沒有鍵為 tier 的label的資源。

要過濾所有處於 production 但不是 frontend 的資源，可以使用逗號操作符， environment=production,tier!=frontend 。

environment=production,tier!=frontend

基於set的條件

基於集合的label條件允許用一組值來過濾鍵。支援三種操作符: in ， notin ,和 exists(僅針對於key符號) 。例如：

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

第一個例子，選擇所有鍵等於 environment ，且value等於 production 或者 qa 的資源。 第二個例子，選擇所有鍵等於 tier 且值是除了 frontend 和 backend 之外的資源，和那些沒有label的鍵是 tier 的資源。 第三個例子，選擇所有所有有一個label的鍵為partition的資源；值是什麼不會被檢查。 第四個例子，選擇所有的沒有lable的鍵名為 partition 的資源；值是什麼不會被檢查。

類似的，逗號操作符相當於一個AND操作符。因而要使用一個 partition 鍵（不管值是什麼），並且 environment 不是 qa 過濾資源可以用 partition,environment notin (qa) 。

基於集合的選擇器是一個相等性的寬泛的形式，因為 environment=production 相當於environment in (production) ，與 != and notin 類似。

基於集合的條件可以與基於相等性 的條件混合。例如， partition in (customerA,customerB),environment!=qa 。

API

LIST 和WATCH過濾

LIST和WATCH操作，可以使用query引數來指定label選擇器來過濾返回物件的集合。兩種條件都可以使用： 基於相等性條件： ?labelSelector=environment%3Dproduction,tier%3Dfrontend基於集合條件的：

labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29

兩種label選擇器風格都可以用來通過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)'

如以上已經提到的，基於集合的條件表達性更強。例如，他們可以實現值上的OR操作：

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

或者通過exists操作符進行否定限制匹配：

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

Set references in API objects

一些Kubernetes物件，比如service和replication controlle的，也使用label選擇器來指定其他資源的集合，比如pods。

Service and ReplicationController

一個service針對的pods的集合是用label選擇器來定義的。類似的，一個replicationcontroller管理的pods的群體也是用label選擇器來定義的。

對於這兩種物件的Label選擇器是用map定義在json或者yaml檔案中的，並且只支援基於相等性的條件：

“selector”: {
“component” : “redis”,
}

或者

selector:
component: redis

這個選擇器（分別是位於json或者yaml格式的）相等於 component=redis 或者 component in(redis) 。

Job and other new resources

Job和其他新的資源

較新的資源，如job，也支援基於集合的條件。

selector:
matchLabels:相當於一個
component: redis
matchExpressions:
– {key: tier, operator: In, values: [cache]}
– {key: environment, operator: NotIn, values: [dev]}

matchLabels 是一個鍵值對的對映。一個單獨的 {key,value} 相當於 matchExpressions 的一個元素，它的鍵欄位是”key”,操作符是 In ，並且值陣列值包含”value”。 matchExpressions 是一個pod的選擇器條件的列表。合法的操作符包含In, NotIn, Exists, and DoesNotExist。在In和NotIn的情況下，值的組必須不能為空。所有的條件，包含 matchLabels andmatchExpressions 中的，會用AND符號連線，他們必須都被滿足以完成匹配。

更多討論：QQ交流群  513817976  入群暗號: kubernetes.org.cn

更多參考 kubernetes.io/docs/user-guide/labels/#set-based-requirement