網路，通常有下列問題需要回答，如圖 2.17 所示。 有哪些開源的元件支援 Kubernetes 的網路模型？ 外部如何存取 Kubernetes 的叢集？ Kubernetes 的網路元件之間是如何通訊的？ Docker 自身的網路模型和限制？ Docker 背後的網路基礎是什麼？ Kubernetes 的網路模型是什麼？ 圖 2.17 Kubernetes 常見問題 在本節將分別 在本節將分別回答這些問題，然後透過一個具體的試驗，將這些相關的知識串聯在 一起。 2.5.1 Kubernetes 網路模型 Kubernetes 網路模型設計的一個基礎原則是：每個 Pod 都擁有一個獨立的 IP 位址， 而且假設所有 Pod 都在一個可以直接連線的、扁平的網路空間中。所以不管它們是 否運行在同一個 Node（Host 主機）中，都要求它們可以直接透過對方的 IP 進行存 取。 取。設計這個原則的主要原因是，使用者不需要額外考慮如何建立 Pod 之間的連 線，也不需要考慮將容器連接埠對應到主機連接埠等問題。 實際上在 Kubernetes 的世界裡，IP 是以 Pod 為單位來進行分配的。一個 Pod 內部 的所有容器共用一個網路底層堆疊（實際上就是一個網路命名空間，包括它們的 IP 2-70 Kubernetes 核心原理 2 PREROUTING 鏈 PREROUTING

Kubernetes支援最新的5個Kubernetes版本。其中最新的3個版本可獲 得完整功能、產品更新及安全性修補程式，比較舊的2個版本則僅獲得安全性更新。 這種更為廣泛的支援方式，可消除混合雲之中的問題，因為雲端供應商採用現行 Kubernetes修訂版的步調緩慢，並持續支援舊版本。 6. 邊緣支援 在邊緣運作對Kubernetes產生全新挑戰：資源的規模、大小及可存取性很快 將成為限制因素。C Single-node edition單節點版本 使用者如果想在單一裝置執行Kubernetes，目前有輕量級的發行版本專門用於提 供單節點叢集，並可透過抽象化技術，排除Kubernetes固有的部分複雜度問題。 Canonical Kubernetes及Rancher可分別透過MicroK8及K3支援單節點叢集。撰 寫本文時，Red Hat並未正式支援任何單節點OpenShift解決方案。 MicroK 為企業工作負載提供無可比擬的自動化程度及通用平台。不過Kubernetes本身是一 項高度複雜的技術，並不是所有企業都具有專業知識及時間在內部維護。完全託管的 Kubernetes叢集可消除此項問題，讓使用者將Kubernetes當成服務使用。廠商負責 運作叢集，使用者則將重心放在提供核心業務價值。 Canonical Kubernetes可讓企業選擇在裸機、OpenStack或任何公有雲使用完

程序的開源系統 ○ 根據資源需求和其他約束自動放置容器 ○ 自我修復，重新啟動失敗的容器 ○ 橫向縮放，自動調整應用程序副本數 ○ 自動部署和回滾，逐漸部署對應用程序或其配置的更改， 在出現 問題時恢復更改 Google Kubernetes Engine ● Google Kubernetes Engine GKE ○ 在 Google Cloud 提供技術的 Kubernetes

Runbook 是詳細的“how-to”指 南，用於完成運營流程中經常 重複的任務或程序。 • 創建 Runbook 的目的是為團 隊中的每個人（無論是新人還 是經驗豐富的人）提供快速準 確地解決特定問題的知識和步 驟。 21 每一個 alert 都應該要有 一個 runbook！ Ref. https://runbooks.prometheus-operator.dev/ Click to edit