前言
最近在跟同事討論 Kubernetes 的時候，發現很多人雖然天天在用 K8s，但對一些底層細節其實沒那麼清楚。於是我整理了 10 個我覺得蠻有鑑別度的問題，涵蓋調度、網路、日誌、擴展等面向，可以拿來自我檢測一下。如果你每題都能快速回答並抓到關鍵點，那代表你對 K8s 的掌握程度已經相當不錯了。
十個問題，先想想再看答案
- 叢集有 2 個 Node，一個上面已經跑了 Pod，另一個是空的，新建的 Pod 會調度到哪個節點？
- 容器發生 OOM（記憶體不足），到底是容器重啟還是整個 Pod 被重建？
- 環境變數或
ConfigMap的設定可以不重建 Pod 就動態更新嗎？ - Pod 建立之後就穩定了嗎？使用者什麼都不做它會不會出事？
ClusterIP類型的Service能確保 TCP 流量均衡分配嗎？- 應用程式的日誌怎麼收集？有沒有可能漏掉？
- HTTP Server Pod 的
livenessProbe通過了，就代表一切正常嗎？ - 流量突然暴增，應用程式該怎麼擴展？
- 執行
kubectl exec -it <pod> -- bash之後，你其實「進入」了什麼？ - Pod 裡的容器不斷退出又重啟，該怎麼排查？
建議先自己想過一輪再往下看，效果會比較好。
逐題解析
1. 新的 Pod 會調度到哪個節點？
這題很多人直覺回答「空的那個」，但其實 不一定。
Kubernetes 的調度流程會經過多個階段：篩選（Filtering）→ 評分（Scoring）→ 選擇最高分節點。其中節點上的各種配置（節點親和性、污點容忍、強制調度等）都會影響最終結果。
假設我們排除特殊配置，單看預設的評分插件 NodeResourcesFit，它有三種策略：
| 策略名稱 | 行為 | 本題結果 |
|---|---|---|
LeastAllocated（預設） |
優先選資源使用率最低的節點 | 調度到空節點 |
MostAllocated |
優先選資源使用率較高的節點 | 調度到已有 Pod 的節點 |
RequestedToCapacityRatio |
追求節點間資源使用率平衡 | 調度到空節點 |
所以答案取決於叢集的調度策略設定，而非單純看哪個節點比較閒。
2. OOM 了是容器重啟還是 Pod 重建？
一般來說是 容器重啟，Pod 不會被重建。這裡的行為取決於 Pod 的 RestartPolicy（預設值為 Always），kubelet 會在原地重啟該容器。
但有個例外：如果節點本身記憶體壓力已經很大，kubelet 可能會觸發 Pod 驅逐（Eviction），這時候 Pod 就會被整個移除並在其他節點重建。
3. ConfigMap 可以動態更新嗎？
要分兩種情況：
- 環境變數：無法動態更新，改了之後必須重建 Pod 才會生效。
- ConfigMap 掛載為 Volume：可以動態更新，但有兩個前提條件——掛載時 不能使用
subPath，而且同步延遲受 kubelet 的syncFrequency（預設 1 分鐘）和configMapAndSecretChangeDetectionStrategy設定影響。
4. Pod 建立後就穩定了嗎？
不一定。即使使用者什麼都不做，以下情況都可能讓 Pod 被迫遷移：
- 節點資源不足觸發驅逐（Eviction）
- 節點網路異常導致 kubelet 無法回報心跳，Control Plane 判定節點不可用
- 節點維護或升級時被設定為不可調度（cordon/drain）
所以設計應用時，永遠要假設 Pod 是會隨時消失的。
5. ClusterIP Service 能保證 TCP 負載均衡嗎？
不能完全保證，特別是在長連接（Long-lived Connection）的場景下。
不管底層用的是 iptables 還是 ipvs，ClusterIP Service 都依賴 Linux 核心的 Netfilter 機制。而 Netfilter 內部的 Connection Tracking 會追蹤每個連線的狀態，確保已建立的 TCP 連線持續送往同一個後端 Pod。
這表示如果你的應用使用長連接（像是 gRPC、WebSocket），流量很可能集中在少數幾個 Pod 上，造成負載不均。
6. 應用日誌怎麼收集？會不會遺失？
常見的日誌輸出方式有兩種：
| 輸出方式 | 收集方法 | 是否可能遺失 |
|---|---|---|
stdout/stderr |
DaemonSet 部署日誌代理（如 Fluentd、Filebeat） | 可能。Pod 被刪除時容器日誌檔也會被清除，代理可能來不及採集完 |
| 寫入日誌檔案 + 持久化儲存 | 掛載 PV，日誌直接寫入持久化路徑 | 較不容易遺失 |
如果你的應用對日誌完整性有嚴格要求，建議採用持久化儲存的方式，而不是單純依賴 stdout。
7. livenessProbe 正常就沒問題嗎？
不一定。至少有兩個盲點：
- 應用層面：livenessProbe 只檢查應用是否「還活著」，不代表功能正常。應用可能已經進入異常狀態（例如連不上資料庫），但 health check endpoint 仍然回 200。
- 網路層面：livenessProbe（假設是 httpGet 型態）是由該節點的 kubelet 在本機發起的請求，只能驗證本機到容器的連通性，無法確認跨節點的網路是否正常。
所以除了 livenessProbe 之外，建議搭配 readinessProbe 做更完整的健康檢查。
8. 應用程式怎麼擴展來應對流量波動？
Kubernetes 提供兩種原生擴展機制：
| 機制 | 全名 | 說明 |
|---|---|---|
| HPA | Horizontal Pod Autoscaler | 根據 CPU、記憶體或自訂指標動態增減 Pod 數量，是最常用的方式 |
| VPA | Vertical Pod Autoscaler | 調整單一 Pod 的資源配額，但因為目前不支援原地調整，會先刪再建 Pod，實際使用較受限 |
實務上大多採用 HPA，搭配 Prometheus 等監控系統提供的自訂指標（如 RPS、佇列長度）來做更精確的擴縮。當然，你也可以透過外部系統監控指標後，直接呼叫 Kubernetes API 來手動或自動調整副本數。
9. kubectl exec 進去的到底是什麼？
這題是個經典的概念題。嚴格來說，你既不是「進入了 Pod」，也不是「進入了容器」。
首先，如果 Pod 裡有多個容器，你需要用 -c 指定要操作哪一個（只有一個容器時可省略）。
再來，Pod 本質上是一組共享的 Linux Namespace：
- 共享：Network、IPC、UTS namespace
- 獨立：每個容器有自己的 PID、Mount namespace
所以 kubectl exec -it <pod> -- bash 實際上是在目標容器的隔離環境中 建立一個新的 bash 程序，而不是什麼「登入」動作。
10. 容器反覆退出重啟怎麼排查？
當容器不斷 CrashLoopBackOff 時，kubectl exec 基本上用不了（容器一直在重啟）。這時候可以這樣排查：
kubectl describe pod <pod>查看事件和容器狀態kubectl logs <pod> --previous查看上一次退出前的日誌- 檢查節點狀態和資源使用情況
- 使用
kubectl debug在 Pod 上啟動一個 臨時除錯容器（Ephemeral Container），在同樣的環境下檢查檔案系統、環境變數和依賴服務
小結
這 10 個問題看似基礎，但每一題背後都牽涉到 Kubernetes 的核心機制。如果有幾題答不太上來也沒關係，重要的是理解背後的原理，而不是死記答案。希望這篇整理對你有幫助，有任何想法歡迎留言討論。
發佈留言