前言

上一篇我們用 kubeadm 把叢集建起來了，今天終於可以開始部署東西了！

在 Kubernetes 的世界裡，Pod 是最小的部署單位，而 Deployment 則是幫你管理 Pod 的大管家。這篇我們會從建立一個最簡單的 Pod 開始，親眼看看它的「脆弱」，再帶出 Deployment 為什麼不可或缺。

以下操作皆在 master 節點 執行。

一、先來跑一個 Pod

最快的方式，就是用 kubectl run 直接建一個 Pod：

kubectl run nginx-pod --image=nginx

確認一下有沒有跑起來：

kubectl get pods -o wide

輸出大概長這樣：

可以看到 Pod 被排程到 node1 上，拿到了一個 cluster 內部的 IP 192.168.166.130，狀態是 Running，一切正常。

到這裡，你可能覺得：「就這樣？也太簡單了吧。」

沒錯，建立 Pod 本身很簡單，但問題在後面。

二、Pod 的問題開始浮現

現在我們來做一件事 —— 把它刪掉。

kubectl delete pod nginx-pod

再看一次：

kubectl get pods

它消失了，而且 不會回來。

這就是 Pod 的本質特性：

• 👉 Pod 本身沒有自我修復能力 — 掛了就是掛了，不會自動重啟一個新的
• 👉 Pod 不負責維持副本數 — 你刪了一個，不會自動補回來
• 👉 Pod 不適合直接用在正式環境 — 沒有滾動更新、沒有版本管理

如果今天跑的是你們公司的服務，Pod 一掛，服務就斷了，這在 Production 是不能接受的。

💡 你可以把 Pod 想像成「一次性的工人」，幹完活就走了，沒人管它死活。

三、Deployment 登場

為了解決上面的問題，Kubernetes 提供了 Deployment 這個資源。

Deployment 做的事情很單純但很重要：

簡單來說，Deployment = Pod + 自動管理。

建立一個 Deployment

kubectl create deployment nginx-deploy --image=nginx --replicas=2

這行指令會建立一個名為 nginx-deploy 的 Deployment，跑 2 個 nginx Pod。

確認狀態：

kubectl get deployments
kubectl get pods

可以看到 Deployment 幫我們建了 2 個 Pod，名稱是 Deployment名稱 + ReplicaSet雜湊 + Pod雜湊。

四、來驗證「自我修復」

這是 Deployment 最讓人安心的能力。我們手動刪掉其中一個 Pod：

kubectl delete pod <你的pod name>

馬上再看：

kubectl get pods

你會發現 Pod 數量還是 2 個！Deployment 偵測到少了一個 Pod，立刻補了一個新的上來。

💡 這就是 Deployment 背後的 ReplicaSet 在運作 — 它會持續監控實際 Pod 數量，確保與你設定的 replicas 一致。

五、擴縮容（Scaling）

如需增加副本數，只需執行以下指令：

kubectl scale deployment nginx-deploy --replicas=5

kubectl get pods

瞬間就會看到 5 個 Pod 在跑。反過來縮減也一樣：

kubectl scale deployment nginx-deploy --replicas=1

多餘的 Pod 會被依序終止，只留下 1 個。

小結

今天我們學到了兩個核心概念：

總結：

在 Kubernetes 裡，你幾乎不會單獨建 Pod，而是透過 Deployment 來管理它。

今天我們用 kubectl scale 手動調整了副本數，但在真實環境中，流量是動態的，不可能隨時盯著手動調。明天我們會介紹 HPA（Horizontal Pod Autoscaler），讓 Kubernetes 根據 CPU、記憶體等指標自動幫你擴縮容。敬請期待！