還記得 Day 5 時,我們做了一件事:
kubectl delete pod nginx
一個 delete,就讓 Pod 就真的消失啦
但 Production 系統不能這樣搞啊。
如果凌晨三點 API Crash:
不可能等工程師醒來再手動執行 kubectl run。
所以我們需要 Controller (可以想成幫忙自動控制的)。
現在最常用的就是透過:
Deployment。

kubectl create deployment api \
--image=nginx:alpine \
--replicas=3 \
-n cka-lab
查看:
kubectl get deployments -n cka-lab
縮寫:
kubectl get deploy -n cka-lab
接著:
kubectl get pods -n cka-lab
你會看到三個:
這是非常重要的關係:
Deployment
│
▼
ReplicaSet
│
▼
Pod
看看:
kubectl get rs -n cka-lab

你會看到一個 ReplicaSet。
Deployment 管理 ReplicaSet。
ReplicaSet 再確保指定數量的 Pod 存在。
先:
kubectl get pods -n cka-lab
任選一個:
kubectl delete pod <API_POD_NAME> -n cka-lab

立刻:
kubectl get pods -n cka-lab
會發現:
舊 Pod Terminating
新 Pod Creating
這跟 Day 5 完全不一樣。
因為 ReplicaSet 發現:
Desired = 3
Actual = 2
於是:
補一個。
這就是:
Self-healing
最直觀的體驗。
現在:
kubectl scale deployment/api \
--replicas=5 \
-n cka-lab
看看:
kubectl get pods -n cka-lab

變五個。
再:
kubectl scale deployment/api \
--replicas=2 \
-n cka-lab
變兩個。

我們不是:
手動 create Pod
手動 delete Pod
而是在修改:
Desired State。
把它轉成宣告式:
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
namespace: cka-lab
spec:
replicas: 3
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
spec:
containers:
- name: nginx
image: nginx:alpine
這裡第一次看到:
selector:
matchLabels:
app: api
Deployment 在說:
哪些 Pod 是我的?
接著:
template:
metadata:
labels:
app: api
新建立的 Pod 都貼:
app=api 的標籤
兩邊吻合。
Deployment 不直接描述:
一個現有 Pod。
它描述的是:
Pod Template。
也就是:
未來你要建立 Pod 時,都照這個模板。
因此:
Deployment
↓
ReplicaSet
↓
從 Template 建 Pod
kubectl delete pod 為什麼不算真正修復?有時候大家遇到問題會:
kubectl delete pod
發現新的 Pod 正常,就說:
修好了。
其實不一定。
如果根本問題在:
Deployment Template
新 Pod 還是會使用相同設定。
因此真正排錯要區分:
這一個 Pod 偶發壞掉?
還是 Desired State 本身就錯?
這是 Debug 中很重要的思維。
今天第一次真正看到 Kubernetes 的核心能力:
Desired State
↓
Controller
↓
Self-Healing
也理解:
Deployment
↓
ReplicaSet
↓
Pod
明天我們要開始做真正 Deployment 最重要的事情:
更新 Application。
而且看看 Kubernetes 怎麼做到不一次把所有服務停掉。