檢視緯育 2026-0531 的原始碼

本次講座串連 Kubernetes（K8s）中的 Pod 調度、節點汙點/容忍（Taint/Toleration）、Deployment 的滾動更新，以及 Service、ConfigMap、Secret 的實務操作與網路架構。內容依序說明：
* Pod 調度的三種方式（全自動、定向調度 NodeSelector、親和性 Affinity），著重於如何透過節點標籤與 nodeSelector 精準部署，並補充 Node/POD Affinity 與 Anti-Affinity 的彈性規則。
* Master（控制平面）節點預設帶有 Taint，避免一般工作負載調度至管理面；介紹 Taint Effect（三類：NoSchedule、PreferNoSchedule、NoExecute）與容忍（Toleration）匹配條件（key、operator、value、effect），示範移除/加回 taint 的影響與 Pending 排障。
* Deployment 的滾動更新機制：新版本未成功前舊版本保留，確保不中斷。
* Service 的核心概念（VIP、Endpoints、Label Selector）與型態（ClusterIP、NodePort、LoadBalancer）、FQDN 服務發現、端口定義（Port/TargetPort/NodePort），說明 ClusterIP 不可 ping 屬預期、NodePort 範圍 30000–32767 與外部存取路徑，並以負載平衡器/反向代理在正式環境提供標準入口與高可用。
* 設定管理：ConfigMap 與 Secret 的建立、以 env/envFrom 注入、以 Volume/volumeMounts 掛載、正確 items 語法整併多檔；Secret 的 Base64 僅為編碼非加密，與 ConfigMap 在型態與用途上的差異與彈性選擇。
* YAML 編輯重點：階層與縮排、containers 列表語義、kubectl edit 的行為與可能的「放棄儲存」，鼓勵實作與排錯。

=== Kubernetes 基礎與版本管理 ===
* 版本相容性風險：新舊版指令與功能可能不相容，需留意變更與公告。
* Deployment 滾動更新：變更即觸發 Rolling Update；新 Pod 成功前保留舊 Pod，維持服務穩定。
=== Pod 調度機制 ===
* 全自動調度：由控制面自動挑選節點，易用但不一定滿足特殊需求。
* 定向調度（NodeSelector）：
** 前置作業：對節點設定 label（kubectl label node [node] key=value）。
** 在 Pod 規格加入 nodeSelector 與節點標籤匹配；可動態編輯 Deployment YAML 使 Pod 重新調度。
* 親和性（Affinity）：
** Node Affinity：支援更複雜運算與權重。
** Pod Affinity/Anti-Affinity：在拓撲域內約束 Pod 之間的同/異節點部署，兼顧效能與可用性。
=== Master 節點與 Taint/Toleration ===
* 調度原則與 SPOF 風險：Master 不建議承載一般工作負載；測試環境可暫時移除 taint，生產環境應保留並增加 Worker 節點。
* Taint Effect：
** NoSchedule：新 Pod 不應調度入內。
** PreferNoSchedule：盡量避免，非強制。
** NoExecute：驅離既有與拒絕新 Pod，破壞性較高。
* Toleration 匹配：key、operator（Equal/Exists）、value、effect 必須對應；鍵名錯誤常致 Pending。
* 排障流程：kubectl describe pod/node 觀察 FailedScheduling 與節點 Taints；必要時以 kubectl taint node [node] [key]* 移除 taint。
=== 實務場景：GPU/AI 資源保護 ===
* 在具 GPU 的節點加 taint，僅允許具 toleration 的負載調度；可搭配 nodeSelector/affinity 精準分配，避免資源被混用。
=== Service 與網路存取 ===
* 為何需要 Service：提供穩定入口、服務發現與負載平衡；Deployment/Pod 本身不保證可存取。
* 核心機制：Service 建立 VIP，維護符合 selector 的 Endpoints；以 label 分群後端 Pod。
* 型態與存取：
** ClusterIP：叢集內存取，DNS 以「服務名稱.命名空間」解析；ClusterIP 不可 ping 屬正常。
** NodePort：對外存取，預設範圍 30000–32767；使用「任一節點 IP:NodePort」到達後端。
** LoadBalancer：雲端提供外部入口與健康檢查，高可用。
* 路徑等價理解：節點IP:NodePort ≈ Service ClusterIP:Port ≈ Endpoints（PodIP:ContainerPort）。
* 正式環境建議：以負載平衡器/反向代理在標準 80/443 導向至 NodePort，避免非標準埠帶來不專業印象。
=== YAML 編輯與指令實作 ===
* YAML 結構：正確階層與縮排、containers 列表語義，避免語法錯誤導致儲存失敗或變更被捨棄。
* 常用操作：
** kubectl edit/describe/get/exec 實務用法與 Tab 補全。
** 以 kubectl expose 快速建立 Service，設定 type/port/selector。
** 以 Pod IP（應可通）與服務名稱（FQDN）測試；勿以 ping ClusterIP 判斷可用性。
=== ConfigMap 與 Secret ===
* ConfigMap 用途：將設定與映像檔解耦，集中管理。建立方法：
** from-literal（key=value 直接宣告）
** from-env-file（讀取 .env，產出 key-value）
** from-file（整檔內容作為單一 key）
* 在 Pod 中使用：
** env/envFrom.configMapRef 將 key-value 注入環境變數。
** volume/volumeMounts 掛載為檔案；宣告 volumes 與對應的 volumeMounts 名稱一致，指定 mountPath。
* 多檔掛載正確語法：
** 以單一 Volume 的 configMap.items 指定多個 key 與 path，整併至同一目錄；避免用多個 volumeMounts 指向同一路徑（K8s 會靜默忽略重複）。
* Secret 比較與安全性：
** 與 ConfigMap 操作近似；generic 最常用。
** Base64 僅為編碼非加密，可輕易解碼；機敏資料建議搭配外部金鑰管理（如 AWS 相關服務）。
** K8s 不強制類型使用規則，視需求彈性選擇。
** 其他類型：docker-registry（憑證）、tls（憑證/私鑰）。
[[檔案:2026-0531-01.png|800px]]
=== kubectl 指令與操作習慣 ===
* 常用動詞：create、edit、delete、get、expose；多做上機練習熟悉。
* -o 為輸出格式（如 -o yaml），持續監看使用 -w。
* 事件與日誌：kubectl describe 與 logs/事件查詢掌握資源狀態變化。
* 以 -f 檔案方式管理多物件 YAML（--* 分隔）；create（新增、同名衝突）、apply（宣告式更新）、delete（依檔案或選擇器刪除）。
* 乾跑（dry-run）：先檢查不套用，降低錯誤風險。
=== 資源物件與標註機制 ===
* Label、Annotation、Taint 操作一致，describe 可檢視詳情。
* Taint 調度控制 Effect：
** NoExecute：阻止新調度並驅離既有不容忍 Pod。
** NoSchedule：阻止新 Pod 調度至該節點。
** PreferNoSchedule：盡量避免但非強制。
* 深入編輯 Deployment/Service YAML，強調正確縮排與從零撰寫。
=== ConfigMap 與 Secret ===
* 用途定位：ConfigMap（非機敏設定）、Secret（機敏資料）；Secret 並非絕對安全，需配合額外措施。
* 三種建立方式：--from-env-file、--from-file、--from-literal；需理解參數差異與適用場景。
* 以環境變數或檔案掛載載入至 Deployment。
=== K8s 架構與網路 ===
* Control Plane（API Server、Scheduler、Controller Manager、etcd）高可用建議至少 3 節點；Worker 執行 Pod。
* 容器執行時：1.24 以後多用 containerd 等非 Docker。
* CNI 外掛示例：Calico 等，初期不必深究細節。
* Service 類型：
** ClusterIP：叢集內通訊，效率高，適合同叢集服務（如 WordPress 連資料庫）。
** NodePort：對外暴露，示範用於理解機制，正式場景建議使用 Ingress/反向代理。
* 資安觀念：資料庫通常不對外暴露。
=== 測試環境中的 NFS 共享與掛載 ===
* Master 分享 Data 目錄至「任何來源」僅限測試用，正式需限制 IP/網段與權限。
* 啟用 NFS Server/RPC，設定 exports，exportfs -v 驗證分享。
* Node1、Node2 於 /etc/fstab 新增 NFS 掛載（defaults），完成後以 mount/df 確認三節點 Data 一致。
* 以正確格式在 Slack 用 code block 傳指令，避免貼上時空白/格式錯誤。
=== MariaDB（MyDB）部署與修正流程 ===
* 先建立/確認 ConfigMap 與 Secret，缺少密碼會導致 Pod 無法 Running。
* 建立 Deployment（名為 MyDB），以簡化字元集示範，不啟用 Unicode。
* kubectl edit 加入 env（引用 ConfigMap/Secret），儲存後觀察 ReplicaSet 與新 Pod 狀態至 Running。
* 使用 Tab 鍵指令補全，養成不依賴純貼上。
* 進入容器以 mysql -u root -p 建立資料庫（如 wp），並用 SHOW DATABASES; 驗證。
=== 資料持久化與 Volume 掛載 ===
* 將資料庫/應用資料寫入 Volume，Deployment YAML 內先宣告 volumes，再於 containers.volumeMounts 掛載。
* 編輯成功後 Pod 重新建立，至掛載路徑確認檔案已落地。
* 層級辨識：Volume 為 Pod 層級，VolumeMount 掛載在 Container 層級；縮排錯誤易致設定失敗。
=== WordPress（MyWeb）部署與配置 ===
* 建立 my-web 的 ConfigMap（可由 wordpress.yaml 建立），kubectl describe cm 檢視內容。
* 建立 MyWeb Deployment，初期狀態為 Pull Image，待 Running。
* kubectl edit deployment my-web，在 containers 區塊加入 env 引用 ConfigMap，讓 WordPress 透過環境變數連資料庫。
* 設定資料持久化：spec.volumes 指向共享目錄（如 /data/wordpress），containers.volumeMounts 掛載到 /var/www/html。
* 以 Service 對外檢視（示例埠 32089）；叢集內部服務連線建議用 ClusterIP。
=== 宣告式部署、備份/還原與 DevOps ===
* 教學從「分解動作」過渡到「一氣呵成」，以完整 YAML/JSON 定義 Deployment、Service、ENV、Volume，成為可重現配置。
* 匯出現有物件狀態作為備份，示範刪除 Deployment 後以設定檔 apply 一次性恢復。
* 版本管理多集中於 Image/Tag，更新主要修改設定檔中的 Image 欄位後套用。
* CI/CD 與 GitOps：Commit 觸發建置新 Image → 生成/更新 YAML → 交付至 K8s；工具如 Jenkins（Pipeline/Jenkinsfile）、Argo CD（宣告式部署），以 Git 作為單一真相源。
* IaC 與 Terraform：以程式化方式管理基礎架構與 K8s，多雲支援，體驗從建立到一鍵銷毀的流程；可結合 AI 協助撰寫，提高效率但需重視品質與驗證。
=== 學習路徑、實作建議與常見卡關 ===
* 多次練習 YAML 的編排、編輯、儲存與除錯，前期需時間累積。
* 從零開發小型應用（如 Flask API），打包 Image、部署至 K8s，理解 Image、YAML、ConfigMap、Secret 的關聯與必要性。
* 叢集與工具串接（如 Jenkins、Argo CD）需要較高時間成本與跨領域理解。
* 課堂節奏彈性，鼓勵即時提問；講師與助教提供協助但鼓勵學員自主操作與錯誤學習。
[[檔案:2026-0531-02.png|800px]]