緯育 2026-0531

出自頂極製作所
於 2026年6月3日 (三) 10:34 由 Kuyohong留言 | 貢獻 所做的修訂 (建立內容為「本次講座串連 Kubernetes(K8s)中的 Pod 調度、節點汙點/容忍(Taint/Toleration)、Deployment 的滾動更新,以及 Service、ConfigMap、Se…」的新頁面)
(差異) ←上個修訂 | 最新修訂 (差異) | 下個修訂→ (差異)

本次講座串連 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