檢視緯育 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。
[[檔案:2026-0524-01.png|800px]]
=== 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 進入最後章節前的提問與確認。
[[檔案:2026-0524-02.png|800px]]