緯育 2026-0524

本講於2026-05-24聚焦Kubernetes（K8s）環境的自動化部署、叢集架構與基礎操作，系統性說明以 Expo 將 Lab 8 的地端/VM 版較完整叢集安裝流程自動化，並比較輕量環境（MiniKube、K3d）與雲端託管（EKS、GKE）開源與商業生態差異。課程主軸為 kubectl 指令與資源物件操作，刻意不教 Dashboard，改以命令列與 YAML/JSON 設定為核心，涵蓋節點與 Pod 寬欄位輸出判讀、控制平面元件對應、Container runtime 辨識、三節點與單點失敗風險、Help/completion 自動補全啟用與永久化、動詞-資源-物件名稱三段式操作、Namespace、Get All、Service/Endpoint 與網路連通性差異。深入講解 YAML 結構（apiVersion、kind、metadata、spec）、縮排規則與常見鍵（name、image、command、args、workingDir），並以探測與自我修復心智模型為重點：Running 不等於可用；需以 Liveness/Readiness 的 exec/TCP/HTTP 探測與合宜的 InitialDelay/Timeout 驅動控制器在失敗時依重啟策略介入。最後介紹 Labels 與 Selectors（Equality/Set-based）的管理與覆寫、移除操作，作為資源篩選與治理基礎。

部署選項、課程定位與工具觀點

• 以 Expo 將 Lab 8 的 K8s 安裝步驟自動化，降低人為成本與錯誤；對應用導向者不強迫從零安裝。
• 輕量體驗：MiniKube、K3d；較完整叢集：地端實體/VM。雲端託管：EKS、GKE需付費且行為細節可能與原生開源有差異。
• 工具取捨：偏好直接用 kubectl 指令以掌握細節；K9S 可視化但資訊可能不完全符合需求；不教 Dashboard。

叢集架構與節點角色

• 自建地端需自行維護控制面（API server、etcd、controller-manager、scheduler）；雲端由供應商代管。
• 常見三節點設計（至少一控制面＋兩運算節點）以達備援；單節點雖可運作但屬單點失敗風險。
• kubectl get nodes 的欄位判讀：Name、Status（Ready/NotReady）、Role/Label、Age、Version；版本自1.24起移除dockershim，常見runtime為containerd，近期版本約1.35/1.36。

kubectl 操作方法與輸出判讀

• 三段式操作：kubectl + 動詞 + 類型 + 名稱；常見動詞：get、describe、create、apply、edit、delete、logs。
• Help 與 completion：深入閱讀 kubectl help；啟用並永久化 Bash/Zsh/Fish 的自動補全，提升效率與正確性。
• 寬欄位輸出（-o wide）：查看 Internal/External IP、節點名稱、Pod IP、OS/Kernel 與 runtime。
• Namespace 與 Get All：-A 跨命名空間；-n 指定命名空間；get all 概覽多類型資源。

Pod、Container、控制器與網路

• Pod 是最小管理單位，一個 Pod 可含多個 Container，容器共享 Volume 與網路命名空間。
• 控制器（Deployment、ReplicaSet、DaemonSet、Job）以範本維持期望狀態與副本數；Pod 的自癒來自控制器介入而非 Pod 本身。
• Service 與 Endpoint：Endpoint由「Pod IP + Container Port」組成；Ping Pod IP通常可通，Ping Service IP不通屬常態（ICMP與虛擬IP行為差異）。

YAML/JSON 設定與語法嚴謹性

• K8s 設定支援 YAML 與 JSON；實務以 YAML 為主，多物件以“---”分隔，# 註解。
• 結構以 List/Map 混用；鍵值以“key: value”。嚴格一致縮排（常用2空白），格式錯誤將導致套用失敗。
• 必要區塊：apiVersion、kind、metadata、spec；常見鍵：name、image、command、args（List）、workingDir。

狀態、重啟與探測心智模型

• Pod 狀態：Pending（常因 image 拉取）、Running、Succeeded、Failed、Unknown；服務型應長期Running，任務型可能完成即Succeeded。
• Restart Policy：Always（服務型）、OnFailure 或 Never（批次/一次性）；依任務性質選擇。
• Running 不等於可用：需以多層探測驗證服務健康與可服務性。
  • 底層：TCP socket/埠監聽與遠端連線測試（ss/netstat、nc、telnet、curl）。
  • 應用層：HTTP GET 回應碼（200–399為成功範圍，404/5xx為異常）。
  • exec 探測：依命令退出碼（0成功，非0失敗）判斷。
• Liveness 與 Readiness：分別代表健康與就緒；合理設定 InitialDelaySeconds 與 TimeoutSeconds，避免初始化期間的誤判；Readiness通過後才導入流量。
• 優雅刪除：刪除 Pod 預設為graceful，運行中（如sleep）需等待；無上層控制器時刪除不會自動重建。

標籤（Labels）與選取器（Selectors）

• Labels：以Key-Value為物件賦予可識別屬性，便於治理與篩選；一個Key只能對應一個Value，需多值時以不同Key表達。
• 操作：kubectl label 設定；get --show-labels 檢視；以“key-”移除；--overwrite 覆寫既有Key的值。
• 選取器：
  • Equality-based：key=value 等值過濾。
  • Set-based：In/NotIn 等集合條件多值過濾。
• 探測與重啟架構：單一路徑心跳不足，建議多路徑與更深入服務行為探測以提升可靠度。

基本操作與環境提醒

• 啟動 VM、登入控制面（master）後，先以 kubectl get nodes/pods 檢查節點與系統 Pod 狀態。
• 以 -A 與 -o wide 檢視控制平面元件（etcd、apiserver、controller-manager、scheduler、CoreDNS、kube-proxy、Calico等）與節點/Pod IP。

Namespace 與資源總量管理

• ResourceQuota 與 LimitRange
  • 命名空間層級的資源總量控管：建立物件後請求/使用量累加，達上限即拒絕建立或更新。
  • 範例：配額最多允許 4 個 Pod，於建立第 5 個時觸發超出 quota 錯誤；亦可限制 CPU/記憶體等。
  • 若 YAML 宣告的資源超過命名空間 quota，K8s 會拒絕並回報超出 quota 的錯誤訊息。
• 命名空間操作與環境一致性
  • 先於 Development 命名空間練習後，需刪除先前的 ResourceQuota/LimitRange 與練習物件，再切換至 default 進入部署章節，避免殘留限制影響後續。
  • 不強制使用 default；選擇其他命名空間時，務必確認限制已清理或調整，確保部署與更新不受配額阻擋。

kubectl 指令與宣告式操作

• create 與 apply 的差異
  • create：僅建立，不存在則成功，已存在則報已存在錯誤，不進行更新。
  • apply：先判斷有無物件；無則建立，有則更新；輸出可能含警告，顯示 configured 代表已套用變更。適合迭代與宣告式管理。
  • 實務建議以 YAML 作為單一真實來源，透過 apply 管理生命週期，遇到配額/限制先調整宣告。
• 自動補全的優缺點與風險
  • 優點：操作便利、效率提升；缺點：版本轉換或 BUG 下可能失效，需保有替代流程。
  • 現場口誤「Google CTL」「Cooper CTL」實為 kubectl；指令示範包含 get、建立/刪除與上下鍵重用等。

部署應用程式的核心觀念

• 宣告式 YAML
  • YAML 作為 manifest，描述期望狀態；K8s 依宣告達成目標，不指示具體步驟。
  • Pod 可視為應用程式單元；示例：單一 Pod 跑一個 NGINX Web Server 即代表部署一個應用。
• Deployment、ReplicaSet 與自我修復
  • Deployment 負責版本管理、滾動更新與回滾；每次變更生成新的 ReplicaSet，再建立對應 Pod。
  • Controller Manager 持續監控副本數與 Pod 健康，刪除 Pod 時自動重建，維持 Desired/Ready 狀態。
  • 滾動更新原則：新 Pod Ready/Running 後才逐步替換舊 Pod；新版本不可用時，舊版本保留，服務不中斷。
• 物件相依與觀察
  • 建立 Deployment（如 nginx）會伴隨生成 ReplicaSet（含唯一字串後綴）與 Pod。
  • 透過 kubectl get/ watch -n 1 -d 觀察 Desired、Ready 等欄位與物件變化；刪除 Pod 立即出現新 Pod。

影像版本管理與操作

• set image 與 YAML 更新
  • 指令語意：kubectl set image deployment/nginx nginx=nginx:v2

 ** 第一個 nginx：Deployment 名稱
 ** 第二個 nginx：容器名稱
 ** 第三個 nginx：映像名稱與 tag

• • 建議使用明確 tag（v1、v2…），避免 latest，確保可追溯、可控的 Rolling Update/Rollback。
  • 也可透過修改 Deployment YAML 的 image 欄位進行版本切換，保持宣告式一致性。
• 版本失敗與回滾
  • 更新至錯誤或不存在的 tag 時，新 ReplicaSet/Pod 可能不可用；舊版本維持不中斷。
  • 可用 rollout undo 進行回滾，恢復服務至先前版本。
• 版本世代辨識
  • 新 ReplicaSet 具較小 age 與新標識；可由名稱後綴與 age 辨識新舊世代。

擴縮副本與彈性

• 手動擴縮
  • 使用 kubectl scale 快速擴縮副本數（如 1→3→12→5），數秒內完成，資源依負載調整。
• 業務場景
  • 節慶高峰（如母親節大量下單）可事前計劃擴容；進階以監控指標自動擴縮，峰值後自動縮減。
  • 相較 VM，容器擴縮輕量快速，符合宣告式資源管理。

GitOps 與 CICD 最佳實務

• 以 YAML 驅動交付
  • 以版本化 YAML 在 Git 中管理，透過 GitOps/CICD（如 Argo CD）自動部署，取代手動 set image。
• 分工
  • 開發者完成程式與 YAML 後提交至 Git，由自動化管線部署；流程可追溯、可回滾、可審計。
• 指令補充
  • rollout history 可查看變更歷史；在 Git 驅動流程下較少直接使用但需了解。

K8s 邏輯層、容器觀察與學習環境

• POD 為最小管理單位
  • K8s 以 POD 為調度與管理核心；一個 POD 內可含多容器，並含系統容器「PODS」。
  • 操作思維以 POD 為入口；進入容器以 exec 類指令指定 POD 與容器。
• containerd/nerdctl 與 Namespace
  • 相較 Docker，採用 containerd 搭配 nerdctl 更貼近 K8s；於 k8s.io Namespace 下以 nerdctl ps 觀察容器與 PODS 的存在。
• 學習環境與平台
  • 教學以三節點 VM 叢集示範；初學者可用 Minikube 或 KIND（含 WSL）輕量體驗。
• 課程節奏與學習建議
  • 四天課程資訊量大，建議延長至六天；鼓勵課後持續練習、主動提問，累積對映像與部署流程的熟悉度。
  • 強調建立正確心智模型（以邏輯層理解 POD/Namespace/資源關係）後，實作難度顯著下降。
• 章節銜接與時間標記
  • 於 Namespace 章節結束後切換至 default，預備進入部署（Deployment）章節；約 15:12 進入最後章節前的提問與確認。