前言
上文
【從入門到放棄-Kubernetes】Kubernetes入門-應用部署中，我們學習了如何通過指令行部署應用，本文我們學習如果通過yaml配置檔案進行應用部署，并進行應用的擴縮容。
Kubernetes 對象
本段是參考
kubernetes官方手冊的學習筆記，建議初步了解下，如已了解相關概念，可跳過本段，直接看下面的操作。
Kubernetes 對象 是持久化的實體。Kubernetes 使用這些實體去表示整個叢集的狀态。
描述了如下資訊：
- 哪些容器化應用在運作（以及在哪個 Node 上）
- 可以被應用使用的資源
- 關于應用運作時表現的政策，比如重新開機政策、更新政策，以及容錯政策
一但對象被建立，k8s叢集就會開始持續工作以保證對象符合期望狀态。
對象規約（Spec）與狀态（Status）
每個 Kubernetes 對象包含兩個嵌套的對象字段，它們負責管理對象的配置：對象 spec 和 對象 status 。 spec 是必需的，它描述了對象的 期望狀态（Desired State） —— 希望對象所具有的特征。 status 描述了對象的 實際狀态（Actual State） ，它是由 Kubernetes 系統提供和更新的。在任何時刻，Kubernetes 控制面一直努力地管理着對象的實際狀态以與期望狀态相比對。
描述 Kubernetes 對象
一般使用yaml來描述一個k8s對象，yaml是專門用來寫配置的語言。
基本文法規則如下：
- 大小寫敏感
- 使用縮進表示層級關系
- 縮進不允許使用tab，隻允許空格
- 縮進的空格數不重要，隻要相同層級的元素左對齊即可
- '#'表示注釋
使用yaml描述k8s對象，需要以下必需字段：
- apiVersion - 建立該對象所使用的 Kubernetes API 的版本
- kind - 想要建立的對象的類型
- metadata - 幫助識别對象唯一性的資料，包括一個 name 字元串、UID 和可選的 namespace
- spec - 描述了對象的 期望狀态（Desired State），k8s叢集會持續保證對象符合描述的狀态。
管理 Kubernetes 對象
管理k8s對象有三種方式
指令式指令（Imperative commands）
就是我們上文中使用的方式，在指令行直接操作。
如：
kubectl create deployment nginx --image nginx 與對象配置相比的優點：
- 指令簡單，易學且易于記憶。
- 指令僅需一步即可對叢集進行更改。
與對象配置相比的缺點：
- 指令不與變更審查流程內建。
- 指令不提供與更改關聯的稽核跟蹤。
- 除了實時内容外，指令不提供記錄源。
- 指令不提供用于建立新對象的模闆。
指令式對象配置（Imperative object configuration）
需要操作指令和配置檔案配合使用。
kubectl create -f nginx.yaml 與指令式指令相比的優點：
- 對象配置可以存儲在源控制系統中，比如 Git。
- 對象配置可以與流程內建，例如在推送和審計之前檢查更新。
- 對象配置提供了用于建立新對象的模闆。
與指令式指令相比的缺點：
- 對象配置需要對對象架構有基本的了解。
- 對象配置需要額外的步驟來編寫 YAML 檔案。
與聲明式對象配置相比的優點：
- 指令式對象配置行為更加簡單易懂。
- 從 Kubernetes 1.5 版本開始，指令式對象配置更加成熟。
與聲明式對象配置相比的缺點：
- 指令式對象配置更适合檔案，而非目錄。
- 對活動對象的更新必須反映在配置檔案中，否則會在下一次替換時丢失。
聲明式對象配置（Declarative object configuration）
使用聲明式對象配置，不需要在指令中顯示的指定操作，這樣可以将配置檔案放在目錄中，對目錄中的檔案進行不同的操作。
比如：
kubectl apply -f configs/ 與指令式對象配置相比的優點：
- 對活動對象所做的更改即使未合并到配置檔案中，也會被保留下來。
- 聲明性對象配置更好地支援對目錄進行操作并自動檢測每個檔案的操作類型（建立，修補，删除）。
與指令式對象配置相比的缺點：
- 聲明式對象配置難于調試并且出現異常時結果難以了解。
- 使用 diff 産生的部分更新會建立複雜的合并和更新檔操作。
實踐操作
建立Deployment
建立node-deployment.yaml檔案
apiVersion: apps/v1
kind: Deployment
metadata:
name: node-deployment
labels:
app: node
spec:
replicas: 3
selector:
matchLabels:
app: node
template:
metadata:
labels:
app: node
spec:
containers:
- name: node
image: registry.cn-hangzhou.aliyuncs.com/larswang/hello-node:1.0
ports:
- containerPort: 80 建立
kubectl apply -f node-deployment.yaml 檢視deployments
kubectl get deployments 
檢視pods
kubectl get pods --show-labels 縮放Deployment
擴容到十個副本
kubectl scale deployment.v1.apps/node-deployment --replicas=10 擴充完成檢視deployments和pods情況
kubectl get deployments
kubectl get pods --show-labels 縮容到三個副本
kubectl scale deployment.v1.apps/node-deployment --replicas=3 此時可以看到 其中7個pod處于Terminating狀态。一段時間後，再次檢視，隻剩下了3個正在running的pod。
自動恢複
先檢視pods清單
kubectl get pods --show-labels 選中其中一個pod并删除
kubectl delete pod node-deployment-57df45c5bf-d8xst 等删除成功後，再次檢視pods清單
kubectl get pods --show-labels 會發現被删除的pod已經不存在了，但是Deployment又建立了一個新的pod。
這就是k8s會始終盡量保證叢集的運作狀态和配置描述的狀态保持一緻的特性。
擷取Deployment描述資訊
kubectl describe deployment node-deployment 可以看到Deployment的目前描述，及pod曆史變化情況。
NewReplicaSet：
- 當第一次建立 Deployment 時，它建立了一個 ReplicaSet （node-deployment-57df45c5bf） 并建立了3個副本。
Events：
- 先擴容到了10個pods
- 縮容到了3個pods
- 縮容到了1個pods
- 擴容到了3個pods
檢視Deployment狀态
kubectl get deployment node-deployment -o yaml 以yaml格式展示Deployment的配置情況及目前狀态
總結
本文我們介紹了什麼是k8s對象，以及使用yaml配置，建立了一個Deployment。
通過scale對Deployment進行縮放，并示範了手動删除一個pod後，k8s根據描述保持運作态與描述一緻的特性。
在操作完一遍之後，回過頭再看概念，會有種茅塞頓開的感覺。
文中的配置檔案可以在
AloofJr中找到。
更多文章
見我的部落格：
https://nc2era.comwritten by
，轉載請注明出處