三、Kubernetes API

Kubernetes 控制面 的核心是 API 服務(wù)器。 API 服務(wù)器負(fù)責(zé)提供 HTTP API，以供用戶、集群中的不同部分和集群外部組件相互通信。

Kubernetes API 使你可以查詢和操縱 Kubernetes API 中對(duì)象（例如：Pod、Namespace、ConfigMap 和 Event）的狀態(tài)。

大部分操作都可以通過 kubectl 命令行接口或 類似 kubeadm 這類命令行工具來執(zhí)行， 這些工具在背后也是調(diào)用 API。不過，你也可以使用 REST 調(diào)用來訪問這些 API。

四、Kubernetes對(duì)象

在 Kubernetes 系統(tǒng)中，Kubernetes 對(duì)象 是持久化的實(shí)體。 Kubernetes 使用這些實(shí)體去表示整個(gè)集群的狀態(tài)。特別地，它們描述了如下信息：

• 哪些容器化應(yīng)用在運(yùn)行（以及在哪些節(jié)點(diǎn)上）
• 可以被應(yīng)用使用的資源
• 關(guān)于應(yīng)用運(yùn)行時(shí)表現(xiàn)的策略，比如重啟策略、升級(jí)策略，以及容錯(cuò)策略

Kubernetes 對(duì)象是 “目標(biāo)性記錄” —— 一旦創(chuàng)建對(duì)象，Kubernetes 系統(tǒng)將持續(xù)工作以確保對(duì)象存在。 通過創(chuàng)建對(duì)象，本質(zhì)上是在告知 Kubernetes 系統(tǒng)，所需要的集群工作負(fù)載看起來是什么樣子的， 這就是 Kubernetes 集群的 期望狀態(tài)（Desired State）。

操作 Kubernetes 對(duì)象 —— 無論是創(chuàng)建、修改，或者刪除 —— 需要使用 Kubernetes API。

4.1 對(duì)象規(guī)約（Spec）和狀態(tài)（Status）

幾乎每個(gè) Kubernetes 對(duì)象包含兩個(gè)嵌套的對(duì)象字段，它們負(fù)責(zé)管理對(duì)象的配置： 對(duì)象 spec（規(guī)約） 和 對(duì)象 status（狀態(tài)） 。 對(duì)于具有 spec 的對(duì)象，你必須在創(chuàng)建對(duì)象時(shí)設(shè)置其內(nèi)容，描述你希望對(duì)象所具有的特征： 期望狀態(tài)（Desired State） 。

status 描述了對(duì)象的 當(dāng)前狀態(tài)（Current State），它是由 Kubernetes 系統(tǒng)和組件 設(shè)置并更新的。在任何時(shí)刻，Kubernetes 控制平面 都一直積極地管理著對(duì)象的實(shí)際狀態(tài)，以使之與期望狀態(tài)相匹配。

例如，Kubernetes 中的 Deployment 對(duì)象能夠表示運(yùn)行在集群中的應(yīng)用。 當(dāng)創(chuàng)建 Deployment 時(shí)，可能需要設(shè)置 Deployment 的 spec，以指定該應(yīng)用需要有 3 個(gè)副本運(yùn)行。 Kubernetes 系統(tǒng)讀取 Deployment 規(guī)約，并啟動(dòng)我們所期望的應(yīng)用的 3 個(gè)實(shí)例 —— 更新狀態(tài)以與規(guī)約相匹配。 如果這些實(shí)例中有的失敗了（一種狀態(tài)變更），Kubernetes 系統(tǒng)通過執(zhí)行修正操作 來響應(yīng)規(guī)約和狀態(tài)間的不一致 —— 在這里意味著它會(huì)啟動(dòng)一個(gè)新的實(shí)例來替換。

4.2 描述Kubernetes對(duì)象

創(chuàng)建 Kubernetes 對(duì)象時(shí)，必須提供對(duì)象的規(guī)約，用來描述該對(duì)象的期望狀態(tài)， 以及關(guān)于對(duì)象的一些基本信息（例如名稱）。 當(dāng)使用 Kubernetes API 創(chuàng)建對(duì)象時(shí)（或者直接創(chuàng)建，或者基于kubectl）， API 請(qǐng)求必須在請(qǐng)求體中包含 JSON 格式的信息。 大多數(shù)情況下，需要在 .yaml 文件中為 kubectl 提供這些信息。 kubectl 在發(fā)起 API 請(qǐng)求時(shí)，將這些信息轉(zhuǎn)換成 JSON 格式。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

使用類似于上面的 .yaml 文件來創(chuàng)建 Deployment的一種方式是使用 kubectl 命令行接口（CLI）中的 kubectl apply 命令， 將 .yaml 文件作為參數(shù)。下面是一個(gè)示例：

kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record

4.3 必需字段

在想要?jiǎng)?chuàng)建的 Kubernetes 對(duì)象對(duì)應(yīng)的 .yaml 文件中，需要配置如下的字段：

• apiVersion - 創(chuàng)建該對(duì)象所使用的 Kubernetes API 的版本
• kind - 想要?jiǎng)?chuàng)建的對(duì)象的類別
• metadata - 幫助唯一性標(biāo)識(shí)對(duì)象的一些數(shù)據(jù)，包括一個(gè) name 字符串、UID 和可選的 namespace

你也需要提供對(duì)象的 spec 字段。 對(duì)象 spec 的精確格式對(duì)每個(gè) Kubernetes 對(duì)象來說是不同的，包含了特定于該對(duì)象的嵌套字段。 Kubernetes API 參考 能夠幫助我們找到任何我們想創(chuàng)建的對(duì)象的 spec 格式。 例如，可以從 core/v1 PodSpec 查看 Pod 的 spec 格式， 并且可以從 apps/v1 DeploymentSpec 查看 Deployment 的 spec 格式。

4.4 Kuberntes對(duì)象管理

命令式對(duì)象配置
聲明式對(duì)象配置

4.5 對(duì)象名和IDs（即k8s對(duì)象命名規(guī)則）

集群中的每一個(gè)對(duì)象都有一個(gè)名稱 來標(biāo)識(shí)在同類資源中的唯一性。

每個(gè) Kubernetes 對(duì)象也有一個(gè)UID 來標(biāo)識(shí)在整個(gè)集群中的唯一性。

比如，在同一個(gè)名字空間 中有一個(gè)名為 myapp-1234 的 Pod, 但是可以命名一個(gè) Pod 和一個(gè) Deployment 同為 myapp-1234.

對(duì)于用戶提供的非唯一性的屬性，Kubernetes 提供了 標(biāo)簽（Labels）和 注解（Annotation）機(jī)制。

4.5.1 名稱（）

客戶端提供的字符串，引用資源 url 中的對(duì)象，如/api/v1/pods/some name。

某一時(shí)刻，只能有一個(gè)給定類型的對(duì)象具有給定的名稱。但是，如果刪除該對(duì)象，則可以創(chuàng)建同名的新對(duì)象。

以下是比較常見的三種資源命名約束

• DNS 子域名
• DNS 標(biāo)簽名
• 路徑分段名稱

4.5.2 UIDs

Kubernetes 系統(tǒng)生成的字符串，唯一標(biāo)識(shí)對(duì)象。

在 Kubernetes 集群的整個(gè)生命周期中創(chuàng)建的每個(gè)對(duì)象都有一個(gè)不同的 uid，它旨在區(qū)分類似實(shí)體的歷史事件。

Kubernetes UIDs 是全局唯一標(biāo)識(shí)符（也叫 UUIDs）。 UUIDs 是標(biāo)準(zhǔn)化的，見 ISO/IEC 9834-8 和 ITU-T X.667.

4.6 名稱空間（namespace）

Kubernetes 支持多個(gè)虛擬集群，它們底層依賴于同一個(gè)物理集群。 這些虛擬集群被稱為名字空間。
名字空間適用于存在很多跨多個(gè)團(tuán)隊(duì)或項(xiàng)目的用戶的場(chǎng)景。對(duì)于只有幾到幾十個(gè)用戶的集群，根本不需要?jiǎng)?chuàng)建或考慮名字空間。當(dāng)需要名稱空間提供的功能時(shí)，請(qǐng)開始使用它們。

名字空間為名稱提供了一個(gè)范圍。資源的名稱需要在名字空間內(nèi)是唯一的，但不能跨名字空間。 名字空間不能相互嵌套，每個(gè) Kubernetes 資源只能在一個(gè)名字空間中。

名字空間是在多個(gè)用戶之間劃分集群資源的一種方法（通過資源配額）。

不需要使用多個(gè)名字空間來分隔輕微不同的資源，例如同一軟件的不同版本： 使用標(biāo)簽來區(qū)分同一名字空間中的不同資源。

4.6.1 Kubernetes默認(rèn)名稱空間

避免使用前綴 kube- 創(chuàng)建名字空間，因?yàn)樗菫?Kubernetes 系統(tǒng)名字空間保留的。

kubectl get namespace

NAME          STATUS    AGE
default       Active    1d
kube-node-lease   Active   1d
kube-system   Active    1d
kube-public   Active    1d

Kubernetes 會(huì)創(chuàng)建四個(gè)初始名字空間：

default 沒有指明使用其它名字空間的對(duì)象所使用的默認(rèn)名字空間
kube-system Kubernetes 系統(tǒng)創(chuàng)建對(duì)象所使用的名字空間
kube-public 這個(gè)名字空間是自動(dòng)創(chuàng)建的，所有用戶（包括未經(jīng)過身份驗(yàn)證的用戶）都可以讀取它。 這個(gè)名字空間主要用于集群使用，以防某些資源在整個(gè)集群中應(yīng)該是可見和可讀的。 這個(gè)名字空間的公共方面只是一種約定，而不是要求。
kube-node-lease 此名字空間用于與各個(gè)節(jié)點(diǎn)相關(guān)的租期（Lease）對(duì)象； 此對(duì)象的設(shè)計(jì)使得集群規(guī)模很大時(shí)節(jié)點(diǎn)心跳檢測(cè)性能得到提升

4.6.2 名字空間和 DNS

當(dāng)你創(chuàng)建一個(gè)服務(wù) 時(shí)， Kubernetes 會(huì)創(chuàng)建一個(gè)相應(yīng)的 DNS 條目。

該條目的形式是 <服務(wù)名稱>.<名字空間名稱>.svc.cluster.local，這意味著如果容器只使用 <服務(wù)名稱>，它將被解析到本地名字空間的服務(wù)。這對(duì)于跨多個(gè)名字空間（如開發(fā)、分級(jí)和生產(chǎn)） 使用相同的配置非常有用。如果你希望跨名字空間訪問，則需要使用完全限定域名（FQDN）。

4.6.3 并非所有對(duì)象都在名字空間中

大多數(shù) kubernetes 資源（例如 Pod、Service、副本控制器等）都位于某些名字空間中。 但是名字空間資源本身并不在名字空間中。而且底層資源，例如 節(jié)點(diǎn) 和持久化卷不屬于任何名字空間。

查看哪些 Kubernetes 資源在名字空間中，哪些不在名字空間中：

# 位于名字空間中的資源
kubectl api-resources --namespaced=true

# 不在名字空間中的資源
kubectl api-resources --namespaced=false

4.7 標(biāo)簽（label）

標(biāo)簽（Labels） 是附加到 Kubernetes 對(duì)象（比如 Pods）上的鍵值對(duì)。 標(biāo)簽旨在用于指定對(duì)用戶有意義且相關(guān)的對(duì)象的標(biāo)識(shí)屬性，但不直接對(duì)核心系統(tǒng)有語義含義。 標(biāo)簽可以用于組織和選擇對(duì)象的子集。標(biāo)簽可以在創(chuàng)建時(shí)附加到對(duì)象，隨后可以隨時(shí)添加和修改。 每個(gè)對(duì)象都可以定義一組鍵/值標(biāo)簽。每個(gè)鍵對(duì)于給定對(duì)象必須是唯一的。

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

標(biāo)簽?zāi)軌蛑С指咝У牟樵兒捅O(jiān)聽操作，對(duì)于用戶界面和命令行是很理想的。 應(yīng)使用注解 記錄非識(shí)別信息。

4.7.1 使用標(biāo)簽?zāi)康?/h3>

標(biāo)簽使用戶能夠以松散耦合的方式將他們自己的組織結(jié)構(gòu)映射到系統(tǒng)對(duì)象，而無需客戶端存儲(chǔ)這些映射。

服務(wù)部署和批處理流水線通常是多維實(shí)體（例如，多個(gè)分區(qū)或部署、多個(gè)發(fā)行序列、多個(gè)層，每層多個(gè)微服務(wù)）。 管理通常需要交叉操作，這打破了嚴(yán)格的層次表示的封裝，特別是由基礎(chǔ)設(shè)施而不是用戶確定的嚴(yán)格的層次結(jié)構(gòu)。
示例標(biāo)簽：

"release" : "stable", "release" : "canary"
"environment" : "dev", "environment" : "qa", "environment" : "production"
"tier" : "frontend", "tier" : "backend", "tier" : "cache"
"partition" : "customerA", "partition" : "customerB"
"track" : "daily", "track" : "weekly"
請(qǐng)記住，對(duì)于給定對(duì)象標(biāo)簽的鍵必須是唯一的。

4.7.2 標(biāo)簽命名規(guī)則

標(biāo)簽 是鍵值對(duì)。有效的標(biāo)簽鍵有兩個(gè)段：可選的前綴和名稱，用斜杠（/）分隔。 名稱段是必需的，必須小于等于 63 個(gè)字符，以字母數(shù)字字符（[a-z0-9A-Z]）開頭和結(jié)尾， 帶有破折號(hào)（-），下劃線（_），點(diǎn)（ .）和之間的字母數(shù)字。 前綴是可選的。如果指定，前綴必須是 DNS 子域：由點(diǎn)（.）分隔的一系列 DNS 標(biāo)簽，總共不超過 253 個(gè)字符， 后跟斜杠（/）。

如果省略前綴，則假定標(biāo)簽鍵對(duì)用戶是私有的。 向最終用戶對(duì)象添加標(biāo)簽的自動(dòng)系統(tǒng)組件（例如 kube-scheduler、kube-controller-manager、 kube-apiserver、kubectl 或其他第三方自動(dòng)化工具）必須指定前綴。

kubernetes.io/ 前綴是為 Kubernetes 核心組件保留的。

有效標(biāo)簽值必須為 63 個(gè)字符或更少，并且必須為空或以字母數(shù)字字符（[a-z0-9A-Z]）開頭和結(jié)尾， 中間可以包含破折號(hào)（-）、下劃線（_）、點(diǎn)（.）和字母或數(shù)字。

4.7.3 標(biāo)簽選擇器

與名稱和 UID 不同， 標(biāo)簽不支持唯一性。通常，我們希望許多對(duì)象攜帶相同的標(biāo)簽。

通過 標(biāo)簽選擇算符，客戶端/用戶可以識(shí)別一組對(duì)象。標(biāo)簽選擇算符是 Kubernetes 中的核心分組原語。

API 目前支持兩種類型的選擇算符：基于等值的 和 基于集合的。 標(biāo)簽選擇算符可以由逗號(hào)分隔的多個(gè) 需求 組成。 在多個(gè)需求的情況下，必須滿足所有要求，因此逗號(hào)分隔符充當(dāng)邏輯 與（&&）運(yùn)算符。

空標(biāo)簽選擇算符或者未指定的選擇算符的語義取決于上下文， 支持使用選擇算符的 API 類別應(yīng)該將算符的合法性和含義用文檔記錄下來。

基于等值的

基于等值 或 基于不等值 的需求允許按標(biāo)簽鍵和值進(jìn)行過濾。 匹配對(duì)象必須滿足所有指定的標(biāo)簽約束，盡管它們也可能具有其他標(biāo)簽。 可接受的運(yùn)算符有=、== 和 != 三種。 前兩個(gè)表示 相等（并且只是同義詞），而后者表示 不相等。例如：

environment = production
tier != frontend

前者選擇所有資源，其鍵名等于 environment，值等于 production。 后者選擇所有資源，其鍵名等于 tier，值不同于 frontend，所有資源都沒有帶有 tier 鍵的標(biāo)簽。 可以使用逗號(hào)運(yùn)算符來過濾 production 環(huán)境中的非 frontend 層資源：environment=production,tier!=frontend。

基于等值的標(biāo)簽要求的一種使用場(chǎng)景是 Pod 要指定節(jié)點(diǎn)選擇標(biāo)準(zhǔn)。 例如，下面的示例 Pod 選擇帶有標(biāo)簽 "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

基于集合的

基于集合 的標(biāo)簽需求允許你通過一組值來過濾鍵。 支持三種操作符：in、notin 和 exists (只可以用在鍵標(biāo)識(shí)符上)。例如：

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
第一個(gè)示例選擇了所有鍵等于 environment 并且值等于 production 或者 qa 的資源。
第二個(gè)示例選擇了所有鍵等于 tier 并且值不等于 frontend 或者 backend 的資源，以及所有沒有 tier 鍵標(biāo)簽的資源。
第三個(gè)示例選擇了所有包含了有 partition 標(biāo)簽的資源；沒有校驗(yàn)它的值。
第四個(gè)示例選擇了所有沒有 partition 標(biāo)簽的資源；沒有校驗(yàn)它的值。 類似地，逗號(hào)分隔符充當(dāng) 與 運(yùn)算符。因此，使用 partition 鍵（無論為何值）和 environment 不同于 qa 來過濾資源可以使用 partition, environment notin（qa) 來實(shí)現(xiàn)。
基于集合 的標(biāo)簽選擇算符是相等標(biāo)簽選擇算符的一般形式，因?yàn)?environment=production 等同于 environment in（production）；!= 和 notin 也是類似的。

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

3.7.4 其他過濾方法

LIST 和 WATCH 過濾（由API提供）
LIST 和 WATCH 操作可以使用查詢參數(shù)指定標(biāo)簽選擇算符過濾一組對(duì)象。 兩種需求都是允許的。（這里顯示的是它們出現(xiàn)在 URL 查詢字符串中）

基于等值 的需求: ?labelSelector=environment%3Dproduction,tier%3Dfrontend
基于集合 的需求: ?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29
兩種標(biāo)簽選擇算符都可以通過 REST 客戶端用于 list 或者 watch 資源。 例如，使用 kubectl 定位 apiserver，可以使用 基于等值 的標(biāo)簽選擇算符可以這么寫：

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

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

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

正如剛才提到的，基于集合 的需求更具有表達(dá)力。例如，它們可以實(shí)現(xiàn)值的 或 操作：

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

或者通過 exists 運(yùn)算符限制不匹配：

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

3.7.5 在 API 對(duì)象中設(shè)置引用

Service 和 ReplicationController

一些 Kubernetes 對(duì)象，例如 services 和 replicationcontrollers ， 也使用了標(biāo)簽選擇算符去指定了其他資源的集合，例如 pods。
一個(gè) Service 指向的一組 Pods 是由標(biāo)簽選擇算符定義的。同樣，一個(gè) ReplicationController 應(yīng)該管理的 pods 的數(shù)量也是由標(biāo)簽選擇算符定義的。

兩個(gè)對(duì)象的標(biāo)簽選擇算符都是在 json 或者 yaml 文件中使用映射定義的，并且只支持 基于等值 需求的選擇算符：

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

或

selector:
    component: redis

這個(gè)選擇算符(分別在 json 或者 yaml 格式中) 等價(jià)于 component=redis 或 component in (redis) 。

支持基于集合需求的資源

比較新的資源，例如 Job、 Deployment、 Replica Set 和 DaemonSet ， 也支持 基于集合的 需求。

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

matchLabels 是由 {key,value} 對(duì)組成的映射。 matchLabels 映射中的單個(gè) {key,value } 等同于 matchExpressions 的元素， 其 key 字段為 "key"，operator 為 "In"，而 values 數(shù)組僅包含 "value"。 matchExpressions 是 Pod 選擇算符需求的列表。 有效的運(yùn)算符包括 In、NotIn、Exists 和 DoesNotExist。 在 In 和 NotIn 的情況下，設(shè)置的值必須是非空的。 來自 matchLabels 和 matchExpressions 的所有要求都按邏輯與的關(guān)系組合到一起 -- 它們必須都滿足才能匹配。

選擇節(jié)點(diǎn)集(NodeSelector)

通過標(biāo)簽進(jìn)行選擇的一個(gè)用例是確定節(jié)點(diǎn)集，方便 Pod 調(diào)度。 有關(guān)更多信息，請(qǐng)參閱選擇節(jié)點(diǎn)文檔。

4.8 注解（annotation）

你可以使用 Kubernetes 注解為對(duì)象附加任意的非標(biāo)識(shí)的元數(shù)據(jù)。客戶端程序（例如工具和庫(kù)）能夠獲取這些元數(shù)據(jù)信息。

4.8.1 為對(duì)象添加元數(shù)據(jù)

你可以使用標(biāo)簽或注解將元數(shù)據(jù)附加到 Kubernetes 對(duì)象。 標(biāo)簽可以用來選擇對(duì)象和查找滿足某些條件的對(duì)象集合。 相反，注解不用于標(biāo)識(shí)和選擇對(duì)象。 注解中的元數(shù)據(jù)，可以很小，也可以很大，可以是結(jié)構(gòu)化的，也可以是非結(jié)構(gòu)化的，能夠包含標(biāo)簽不允許的字符。

注解和標(biāo)簽一樣，是鍵/值對(duì):

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

以下是一些例子，用來說明哪些信息可以使用注解來記錄:

由聲明性配置所管理的字段。 將這些字段附加為注解，能夠?qū)⑺鼈兣c客戶端或服務(wù)端設(shè)置的默認(rèn)值、 自動(dòng)生成的字段以及通過自動(dòng)調(diào)整大小或自動(dòng)伸縮系統(tǒng)設(shè)置的字段區(qū)分開來。
構(gòu)建、發(fā)布或鏡像信息（如時(shí)間戳、發(fā)布 ID、Git 分支、PR 數(shù)量、鏡像哈希、倉(cāng)庫(kù)地址）。
指向日志記錄、監(jiān)控、分析或?qū)徲?jì)倉(cāng)庫(kù)的指針。
可用于調(diào)試目的的客戶端庫(kù)或工具信息：例如，名稱、版本和構(gòu)建信息。

用戶或者工具/系統(tǒng)的來源信息，例如來自其他生態(tài)系統(tǒng)組件的相關(guān)對(duì)象的 URL。

輕量級(jí)上線工具的元數(shù)據(jù)信息：例如，配置或檢查點(diǎn)。

負(fù)責(zé)人員的電話或呼機(jī)號(hào)碼，或指定在何處可以找到該信息的目錄條目，如團(tuán)隊(duì)網(wǎng)站。

從用戶到最終運(yùn)行的指令，以修改行為或使用非標(biāo)準(zhǔn)功能。

你可以將這類信息存儲(chǔ)在外部數(shù)據(jù)庫(kù)或目錄中而不使用注解， 但這樣做就使得開發(fā)人員很難生成用于部署、管理、自檢的客戶端共享庫(kù)和工具。

4.8.2 語法與規(guī)則

注解（Annotations） 存儲(chǔ)的形式是鍵/值對(duì)。有效的注解鍵分為兩部分： 可選的前綴和名稱，以斜杠（/）分隔。 名稱段是必需項(xiàng)，并且必須在63個(gè)字符以內(nèi)，以字母數(shù)字字符（[a-z0-9A-Z]）開頭和結(jié)尾， 并允許使用破折號(hào)（-），下劃線（_），點(diǎn)（.）和字母數(shù)字。 前綴是可選的。如果指定，則前綴必須是DNS子域：一系列由點(diǎn)（.）分隔的DNS標(biāo)簽， 總計(jì)不超過253個(gè)字符，后跟斜杠（/）。 如果省略前綴，則假定注解鍵對(duì)用戶是私有的。 由系統(tǒng)組件添加的注解 （例如，kube-scheduler，kube-controller-manager，kube-apiserver，kubectl 或其他第三方組件），必須為終端用戶添加注解前綴。

kubernetes.io/ 和 k8s.io/ 前綴是為Kubernetes核心組件保留的。

例如，下面是一個(gè) Pod 的配置文件，其注解中包含 imageregistry: https://hub.docker.com/：

apiVersion: v1
kind: Pod
metadata:
  name: annotations-demo
  annotations:
    imageregistry: "https://hub.docker.com/"
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80

4.9 字段選擇器（Field selectors）

字段選擇器（Field selectors）允許你根據(jù)一個(gè)或多個(gè)資源字段的值 篩選 Kubernetes 資源。 下面是一些使用字段選擇器查詢的例子：

• metadata.name=my-service
• metadata.namespace!=default
• status.phase=Pending

下面這個(gè) kubectl 命令將篩選出 status.phase 字段值為 Running 的所有 Pod：

kubectl get pods --field-selector status.phase=Running

說明：
字段選擇器本質(zhì)上是資源過濾器（Filters）。默認(rèn)情況下，字段選擇器/過濾器是未被應(yīng)用的， 這意味著指定類型的所有資源都會(huì)被篩選出來。 這使得以下的兩個(gè) kubectl 查詢是等價(jià)的：

kubectl get pods
kubectl get pods --field-selector ""

• 支持的字段

不同的 Kubernetes 資源類型支持不同的字段選擇器。 所有資源類型都支持 metadata.name 和 metadata.namespace 字段。 使用不被支持的字段選擇器會(huì)產(chǎn)生錯(cuò)誤。例如：

kubectl get ingress --field-selector foo.bar=baz
Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"

• 支持的操作符
  你可在字段選擇器中使用 =、==和 != （= 和 == 的意義是相同的）操作符。 例如，下面這個(gè) kubectl 命令將篩選所有不屬于 default 命名空間的 Kubernetes 服務(wù)：

kubectl get services  --all-namespaces --field-selector metadata.namespace!=default

• 鏈?zhǔn)竭x擇器
  同標(biāo)簽和其他選擇器一樣， 字段選擇器可以通過使用逗號(hào)分隔的列表組成一個(gè)選擇鏈。 下面這個(gè) kubectl 命令將篩選 status.phase 字段不等于 Running 同時(shí) spec.restartPolicy 字段等于 Always 的所有 Pod：

kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always

• 多種資源類型
  你能夠跨多種資源類型來使用字段選擇器。 下面這個(gè) kubectl 命令將篩選出所有不在 default 命名空間中的 StatefulSet 和 Service：

kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default

4.10 推薦使用的標(biāo)簽

除了 kubectl 和 dashboard 之外，您可以使用其他工具來可視化和管理 Kubernetes 對(duì)象。一組通用的標(biāo)簽可以讓多個(gè)工具之間相互操作，用所有工具都能理解的通用方式描述對(duì)象。

除了支持工具外，推薦的標(biāo)簽還以一種可以查詢的方式描述了應(yīng)用程序。

元數(shù)據(jù)圍繞 應(yīng)用（application） 的概念進(jìn)行組織。Kubernetes 不是 平臺(tái)即服務(wù)（PaaS），沒有或強(qiáng)制執(zhí)行正式的應(yīng)用程序概念。 相反，應(yīng)用程序是非正式的，并使用元數(shù)據(jù)進(jìn)行描述。應(yīng)用程序包含的定義是松散的。
共享標(biāo)簽和注解都使用同一個(gè)前綴：app.kubernetes.io。沒有前綴的標(biāo)簽是用戶私有的。共享前綴可以確保共享標(biāo)簽不會(huì)干擾用戶自定義的標(biāo)簽。

4.10.1 標(biāo)簽

為了充分利用這些標(biāo)簽，應(yīng)該在每個(gè)資源對(duì)象上都使用它們。

為說明這些標(biāo)簽的實(shí)際使用情況，請(qǐng)看下面的 StatefulSet 對(duì)象：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
    app.kubernetes.io/managed-by: helm

4.10.2 應(yīng)用和應(yīng)用實(shí)例

應(yīng)用可以在 Kubernetes 集群中安裝一次或多次。在某些情況下，可以安裝在同一命名空間中。例如，可以不止一次地為不同的站點(diǎn)安裝不同的 WordPress。

應(yīng)用的名稱和實(shí)例的名稱是分別記錄的。例如，某 WordPress 實(shí)例的 app.kubernetes.io/name 為 wordpress，而其實(shí)例名稱表現(xiàn)為 app.kubernetes.io/instance 的屬性值 wordpress-abcxzy。這使應(yīng)用程序和應(yīng)用程序的實(shí)例成為可能是可識(shí)別的。應(yīng)用程序的每個(gè)實(shí)例都必須具有唯一的名稱。

4.10.3 示例

為了說明使用這些標(biāo)簽的不同方式，以下示例具有不同的復(fù)雜性。

一個(gè)簡(jiǎn)單的無狀態(tài)服務(wù)

考慮使用 Deployment 和 Service 對(duì)象部署的簡(jiǎn)單無狀態(tài)服務(wù)的情況。以下兩個(gè)代碼段表示如何以最簡(jiǎn)單的形式使用標(biāo)簽。

下面的 Deployment 用于監(jiān)督運(yùn)行應(yīng)用本身的 pods。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: myservice
    app.kubernetes.io/instance: myservice-abcxzy
...

下面的 Service 用于暴露應(yīng)用。

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: myservice
    app.kubernetes.io/instance: myservice-abcxzy
...

帶有一個(gè)數(shù)據(jù)庫(kù)的 Web 應(yīng)用程序

考慮一個(gè)稍微復(fù)雜的應(yīng)用：一個(gè)使用 Helm 安裝的 Web 應(yīng)用（WordPress），其中 使用了數(shù)據(jù)庫(kù)（MySQL）。以下代碼片段說明用于部署此應(yīng)用程序的對(duì)象的開始。

以下 Deployment 的開頭用于 WordPress：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "4.9.4"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: wordpress
...

這個(gè) Service 用于暴露 WordPress：

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "4.9.4"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: wordpress
...

MySQL 作為一個(gè) StatefulSet 暴露，包含它和它所屬的較大應(yīng)用程序的元數(shù)據(jù)：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
...

Service 用于將 MySQL 作為 WordPress 的一部分暴露：

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
...

使用 MySQL StatefulSet 和 Service，您會(huì)注意到有關(guān) MySQL 和 Wordpress 的信息，包括更廣泛的應(yīng)用程序。