K8s API 可接受JSON和YAML格式的數據, 但API Server需要事先將其轉換為JSON格式才能提交。API Server經手的JSON對象都具備同樣的模式, 都有 kind 和 apiVersion, 用來標示object的類型、API群組及相關版本。此外, 多數的object都需要再具備三個字段: metadata, spec, status。metadata為資源提供元數據類型, ex: name, namespace, tag; spec 用來定義用戶期望的狀態, 不同object定義的方式也不同; status 紀錄object當前狀態訊息, 它由K8s自行維護, 用戶只能讀取。

資源配置清單

想獲取K8s上任一object的配置清單可以直接使用 kubectl get TYPE/NAME -o yaml 獲得YAML格式的配置內容或者使用 kubectl get TYPE/NAME -o json 獲得JSON格式的配置內容

• 獲得YAML範例:
  

• 獲得JSON格式:
  

K8s 大多數的資源都是由使用者透過上面的YAML或JSON定義出符合用戶期望狀態的配置數據所創建的, 然後再由K8s底層的組件去確保object的運行狀態與用戶提供的配置定義相近。
在部署後K8s會補齊用戶端未定義完全的非必填資源內容, 以day4 部署的deployment為例

• 用戶端描述的部署檔 nginx-deployment.yaml

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: nginx-deployment
  spec:
    replicas: 2
    selector:
      matchLabels:
        app: nginx
    template:
      metadata:
        name: nginx-deploy
        namespace: default
        labels:
          app: nginx
      spec:
        containers:
        - image: nginx:latest
          imagePullPolicy: Always
          name: nginx
  

• 完成部署後執行

  kubectl get deployment nginx-deployment -o yaml
  

  取得回應內容
  

從上面的回應可以看到K8s補齊了大部分的配置內容並提供對應的數據, 其遵循K8s API的資源組織格式的定義, 具備了五個必要的核心字段: apiVersion, kind, metadata, spec和status。

Metadata

Metadata 用來描述object的屬性, 裡面有許多用來定義資源元數據的字段, ex: name, labels。
把這些字段整理一下:

• 必填字段:
  • namespace: 默認default, 用來指定object隸屬的命名空間。
  • name: object名稱, 同一命名空間內不可重複。
  • uid: 唯一識別符, 主要用來區別同樣名稱但是不同狀態的object, ex: 已刪除跟重新創建中的object
• 選填字段(存在default或是允許空值的字段):
  • labels: 用來識別object, 常被用來當作挑選條件
  • annotations: labels的補充, 也是一種挑選條件
  • resourceVersion: 內部版本識別符, 用來確認版本是否有異動
  • generation: 用來識別object狀態
  • creationTimestamp: object創建日期時間戳
  • deletionTimestamp: object 刪除日期時間戳

創建object時通常只需要填寫必填字段就可以創建, 另外某些object會具備專用的字段, 例如: ConfigMap 可以填寫 clusterName。

spec 和 status

兩個都屬於嵌套類型的字段, 以下分別說明:

• spec
  用來描述object 應該具備的狀態, 定義object配置內容時為必填項目, 在每一個object的部屬檔中字段大多不同, 部署時需要為每一個object都定義spec。

• status
  用來記錄object在系統上的當前狀態, K8s Master 會透過controller動態管理object的運行狀態, 讓他可以與用戶配置的spec一致。

在K8s運作時, 只要有任一個實體發生錯誤, status狀態就會被修改, 此時controller會即時比對status跟spec之後響應差異去補足實體，讓他可以趨近於spec的配置。

配置清單格式檢視

• 每一個object spec各自不同, 可以透過 kubectl explain <object>.spec 查看詳細說明

  kubectl explain deployment.spec
  

  執行結果
  

  也可以看spec底下其中一個項目

  kubectl explain deployment.spec.paused
  

  kubectl explain deployment.spec.selector
  

  執行結果
  

  不特別指定spec項目的話可以觀察到kubectl explain <object>回應的格式都是一樣的

  

  透過 kubectl explain 瀏覽object的spec詳細說明可以加速上手編寫object 配置格式, 除了檢視清單格式之外, k8s 也提供了輸出配置格式的功能。

• 輸出配置格式到YAML kubectl get <object> <object name> -o yaml > <export filename>

  以day4 部署的deployment

  kubectl get deployment nginx-deployment -o yaml > export_demo.yaml 
  

  執行結果
  

資源對象管理方法

K8s API Server 是根據 Declarative programming 模式設計的,它著重在建構目標的流程而不是實現的流程, 用戶只要設定期望狀態系統就會主動去檢查並讓系統狀況趨近於用戶設定的狀態。例如設定Deployment底下應該有3個pod, 系統只偵測到兩個pod時, 系統會自動建立一個新的Pod來滿足被期望的狀態, 這都是依靠Declarative programming的機制完成的。K8s同時也支援Imperative programming模式, 可以直接透過對object操作命令完成動作, 像是 run,get, delete, 操作時必須下明確的指令, 這些功能的使用都要依賴資源配置清單。

圖片參考書:【Kubernetes 進階實踐】

一開始可以先使用kubectl (Imperative programming方式) 來操作object, Imperative programming 一次只能操作一種object, 等到熟悉操作行為之後建議採用編寫YAML(Declarative programming方式), 用戶只要提供資源配置內容讓K8s主動完成配置結果, 編寫YAML檔的方式也較為適合大型專案管理使用。

今日小結

在我們專案上有統一集中管理各服務的部署YAML, 大家可以在上面互相確認內容, 通用的設定需要修改時也只要修改共用參數的部分, 用編寫YAML的方式進行控管可以掌握每個專案的狀況, 對於多人協同開發的專案來說很方便。