三、Kubernetes API

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

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

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

四、Kubernetes對象

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

• 哪些容器化應用在運行（以及在哪些節(jié)點上）
• 可以被應用使用的資源
• 關于應用運行時表現的策略，比如重啟策略、升級策略，以及容錯策略

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

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

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

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

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

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

4.2 描述Kubernetes對象

創(chuàng)建 Kubernetes 對象時，必須提供對象的規(guī)約，用來描述該對象的期望狀態(tài)， 以及關于對象的一些基本信息（例如名稱）。 當使用 Kubernetes API 創(chuàng)建對象時（或者直接創(chuàng)建，或者基于kubectl）， API 請求必須在請求體中包含 JSON 格式的信息。 大多數情況下，需要在 .yaml 文件中為 kubectl 提供這些信息。 kubectl 在發(fā)起 API 請求時，將這些信息轉換成 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 文件作為參數。下面是一個示例：

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

4.3 必需字段

在想要創(chuàng)建的 Kubernetes 對象對應的 .yaml 文件中，需要配置如下的字段：

• apiVersion - 創(chuàng)建該對象所使用的 Kubernetes API 的版本
• kind - 想要創(chuàng)建的對象的類別
• metadata - 幫助唯一性標識對象的一些數據，包括一個 name 字符串、UID 和可選的 namespace

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

4.4 Kuberntes對象管理

命令式對象配置
聲明式對象配置

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

集群中的每一個對象都有一個名稱 來標識在同類資源中的唯一性。

每個 Kubernetes 對象也有一個UID 來標識在整個集群中的唯一性。

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

對于用戶提供的非唯一性的屬性，Kubernetes 提供了 標簽（Labels）和 注解（Annotation）機制。

4.5.1 名稱（）

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

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

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

• DNS 子域名
• DNS 標簽名
• 路徑分段名稱

4.5.2 UIDs

Kubernetes 系統生成的字符串，唯一標識對象。

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

Kubernetes UIDs 是全局唯一標識符（也叫 UUIDs）。 UUIDs 是標準化的，見 ISO/IEC 9834-8 和 ITU-T X.667.

4.6 名稱空間（namespace）

Kubernetes 支持多個虛擬集群，它們底層依賴于同一個物理集群。 這些虛擬集群被稱為名字空間。
名字空間適用于存在很多跨多個團隊或項目的用戶的場景。對于只有幾到幾十個用戶的集群，根本不需要創(chuàng)建或考慮名字空間。當需要名稱空間提供的功能時，請開始使用它們。

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

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

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

4.6.1 Kubernetes默認名稱空間

避免使用前綴 kube- 創(chuàng)建名字空間，因為它是為 Kubernetes 系統名字空間保留的。

kubectl get namespace

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

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

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

4.6.2 名字空間和 DNS

當你創(chuàng)建一個服務 時， Kubernetes 會創(chuàng)建一個相應的 DNS 條目。

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

4.6.3 并非所有對象都在名字空間中

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

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

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

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

4.7 標簽（label）

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

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

標簽能夠支持高效的查詢和監(jiān)聽操作，對于用戶界面和命令行是很理想的。 應使用注解 記錄非識別信息。

4.7.1 使用標簽目的

標簽使用戶能夠以松散耦合的方式將他們自己的組織結構映射到系統對象，而無需客戶端存儲這些映射。

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

"release" : "stable", "release" : "canary"
"environment" : "dev", "environment" : "qa", "environment" : "production"
"tier" : "frontend", "tier" : "backend", "tier" : "cache"
"partition" : "customerA", "partition" : "customerB"
"track" : "daily", "track" : "weekly"
請記住，對于給定對象標簽的鍵必須是唯一的。

4.7.2 標簽命名規(guī)則

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

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

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

有效標簽值必須為 63 個字符或更少，并且必須為空或以字母數字字符（[a-z0-9A-Z]）開頭和結尾， 中間可以包含破折號（-）、下劃線（_）、點（.）和字母或數字。

4.7.3 標簽選擇器

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

通過 標簽選擇算符，客戶端/用戶可以識別一組對象。標簽選擇算符是 Kubernetes 中的核心分組原語。

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

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

基于等值的

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

environment = production
tier != frontend

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

基于等值的標簽要求的一種使用場景是 Pod 要指定節(jié)點選擇標準。 例如，下面的示例 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

基于集合的

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

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
第一個示例選擇了所有鍵等于 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。

3.7.4 其他過濾方法

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

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

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

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

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

正如剛才提到的，基于集合 的需求更具有表達力。例如，它們可以實現值的 或 操作：

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

或者通過 exists 運算符限制不匹配：

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

3.7.5 在 API 對象中設置引用

Service 和 ReplicationController

一些 Kubernetes 對象，例如 services 和 replicationcontrollers ， 也使用了標簽選擇算符去指定了其他資源的集合，例如 pods。
一個 Service 指向的一組 Pods 是由標簽選擇算符定義的。同樣，一個 ReplicationController 應該管理的 pods 的數量也是由標簽選擇算符定義的。

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

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

或

selector:
    component: redis

這個選擇算符(分別在 json 或者 yaml 格式中) 等價于 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} 對組成的映射。 matchLabels 映射中的單個 {key,value } 等同于 matchExpressions 的元素， 其 key 字段為 "key"，operator 為 "In"，而 values 數組僅包含 "value"。 matchExpressions 是 Pod 選擇算符需求的列表。 有效的運算符包括 In、NotIn、Exists 和 DoesNotExist。 在 In 和 NotIn 的情況下，設置的值必須是非空的。 來自 matchLabels 和 matchExpressions 的所有要求都按邏輯與的關系組合到一起 -- 它們必須都滿足才能匹配。

選擇節(jié)點集(NodeSelector)

通過標簽進行選擇的一個用例是確定節(jié)點集，方便 Pod 調度。 有關更多信息，請參閱選擇節(jié)點文檔。

4.8 注解（annotation）

你可以使用 Kubernetes 注解為對象附加任意的非標識的元數據?？蛻舳顺绦颍ɡ绻ぞ吆蛶欤┠軌颢@取這些元數據信息。

4.8.1 為對象添加元數據

你可以使用標簽或注解將元數據附加到 Kubernetes 對象。 標簽可以用來選擇對象和查找滿足某些條件的對象集合。 相反，注解不用于標識和選擇對象。 注解中的元數據，可以很小，也可以很大，可以是結構化的，也可以是非結構化的，能夠包含標簽不允許的字符。

注解和標簽一樣，是鍵/值對:

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

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

由聲明性配置所管理的字段。 將這些字段附加為注解，能夠將它們與客戶端或服務端設置的默認值、 自動生成的字段以及通過自動調整大小或自動伸縮系統設置的字段區(qū)分開來。
構建、發(fā)布或鏡像信息（如時間戳、發(fā)布 ID、Git 分支、PR 數量、鏡像哈希、倉庫地址）。
指向日志記錄、監(jiān)控、分析或審計倉庫的指針。
可用于調試目的的客戶端庫或工具信息：例如，名稱、版本和構建信息。

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

輕量級上線工具的元數據信息：例如，配置或檢查點。

負責人員的電話或呼機號碼，或指定在何處可以找到該信息的目錄條目，如團隊網站。

從用戶到最終運行的指令，以修改行為或使用非標準功能。

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

4.8.2 語法與規(guī)則

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

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

例如，下面是一個 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）允許你根據一個或多個資源字段的值 篩選 Kubernetes 資源。 下面是一些使用字段選擇器查詢的例子：

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

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

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

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

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

• 支持的字段

不同的 Kubernetes 資源類型支持不同的字段選擇器。 所有資源類型都支持 metadata.name 和 metadata.namespace 字段。 使用不被支持的字段選擇器會產生錯誤。例如：

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"

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

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

• 鏈式選擇器
  同標簽和其他選擇器一樣， 字段選擇器可以通過使用逗號分隔的列表組成一個選擇鏈。 下面這個 kubectl 命令將篩選 status.phase 字段不等于 Running 同時 spec.restartPolicy 字段等于 Always 的所有 Pod：

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

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

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

4.10 推薦使用的標簽

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

除了支持工具外，推薦的標簽還以一種可以查詢的方式描述了應用程序。

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

4.10.1 標簽

為了充分利用這些標簽，應該在每個資源對象上都使用它們。

為說明這些標簽的實際使用情況，請看下面的 StatefulSet 對象：

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 應用和應用實例

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

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

4.10.3 示例

為了說明使用這些標簽的不同方式，以下示例具有不同的復雜性。

一個簡單的無狀態(tài)服務

考慮使用 Deployment 和 Service 對象部署的簡單無狀態(tài)服務的情況。以下兩個代碼段表示如何以最簡單的形式使用標簽。

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

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

下面的 Service 用于暴露應用。

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

帶有一個數據庫的 Web 應用程序

考慮一個稍微復雜的應用：一個使用 Helm 安裝的 Web 應用（WordPress），其中 使用了數據庫（MySQL）。以下代碼片段說明用于部署此應用程序的對象的開始。

以下 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
...

這個 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 作為一個 StatefulSet 暴露，包含它和它所屬的較大應用程序的元數據：

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，您會注意到有關 MySQL 和 Wordpress 的信息，包括更廣泛的應用程序。