這篇文章我想要介紹關於K8s主要的單元所負責的職責

核心概念：從基礎設施到對外服務

想像一下，你要開一家非常現代化、自動化管理的連鎖餐廳。

1. 基礎設施 (The Foundation)

• Cluster (叢集): 這是你的整個餐飲集團，包含了所有分店、中央廚房和管理辦公室。在 K8s 中，Cluster 是所有資源的集合，包含了所有機器、網路和儲存，是整個系統的邊界。

• Node (節點): 這是你的一家家分店。每家分店都有自己的廚房、員工和設備（CPU、記憶體、硬碟）。在 K8s 中，Node 是一台實體或虛擬機器，是實際執行應用程式的地方。一個 Cluster 由多個 Node 組成。

互動關係: Cluster 是由一群 Node 組成的。Kubernetes 的大腦（Control Plane）會管理所有 Node，決定要把工作分配到哪家分店（哪個 Node）去做最有效率。

2. 最小的執行單位 (The Smallest Unit)

• Pod: 這不是一個廚師，而是一個「料理站」。這個料理站可能只有一位廚師（一個 Container），負責做一道菜。也可能是一位主廚搭配一位助手（多個 Containers），他們需要共用同一個流理台、調味料和鍋具（共享網路和儲存空間），緊密合作才能完成一道複雜的料理。在 K8s 中，Pod 是最小的部署單位。它是一個或多個緊密關聯的容器（Container）的集合，它們共享網路和儲存資源。

互動關係: Pod 是應用程式的載體，它最終會被 Kubernetes 的調度器（Scheduler）分配到某個健康的 Node 上去執行。一個 Pod 永遠只會在一個 Node 上運行。

3. 自動化管理 (Workload Management)

單獨管理每個「料理站」（Pod）太累了。你需要更聰明的管理層來確保餐廳運作順暢。這就是 Workload Management 的角色。

• Workload (工作負載): 這是一個抽象概念，指的是你想在 K8s 上運行的「應用程式」，比如你的「披薩菜單」或「飲料吧台」服務。

• Deployment (部署): 這是你的「輪班經理」。他的任務是確保「披薩料理站」（Pod）永遠有指定的數量（例如 3 個）在正常運作。如果有一個料理站突然關閉了（Pod 故障），他會立刻找一個新的來替補。當你要更新披薩菜單時（更新應用程式版本），他會採用「滾動更新」，一個一個地替換舊的料理站，確保服務不中斷。Deployment 最適合無狀態（stateless）的應用，比如網站前端或 API 服務，因為每個 Pod 都是一模一樣的，可以隨意替換。

• StatefulSet: 這是你的「行政主廚」。他專門管理需要「記住身份」的料理站，例如你的「會員資料庫」。每個資料庫 Pod 都有一個固定的名字（db-0, db-1）和專屬的儲存空間（像是有自己專屬的保險箱）。當需要擴展或更新時，行政主廚會嚴格按照順序一個一個來，確保資料的一致性與安全。StatefulSet 專為有狀態（stateful）的應用設計，如資料庫、消息隊列。

• DaemonSet: 這是你的「食品安全稽查員」。他的任務是確保每一家分店 (每一個 Node) 都必須有一個「衛生監控站」（Pod）。當你開一家新分店（新增 Node）時，稽查員會自動在那裡也設置一個監控站。這通常用於日誌收集、監控或網路代理等需要在每個節點上運行的系統級服務。

互動關係: 你不會直接去創建 Pod。你會告訴 Deployment、StatefulSet 或 DaemonSet 你的需求（例如：「我需要 3 個 Web Server Pods」）。這些「管理器」（我們稱之為 Controller）會去創建、監控和維護你所需要的 Pod，確保系統狀態與你的期望一致。它們是 Pod 的管理者。

4. 對外服務與流量分配 (Service & Exposure)

你的料理站（Pod）都準備好了，但客人要如何點餐呢？客人不會直接走到料理站前面，他們會跟服務生點餐。

• Service (服務): 這就是你的「服務生團隊」或「內部點餐系統」。Pod 是會變動的，它們可能會故障重啟，IP 位址也會跟著改變。Service 提供了一個穩定不變的內部 IP 位址和 DNS 名稱。它會追蹤所有健康的、負責特定菜色（例如披薩）的料理站（Pods），並將訂單（網路流量）聰明地分配給其中一個。叢集內的其他應用程式可以透過這個穩定的 Service 位址來存取服務，而不用擔心後端的 Pod 如何變化。

• Load Balancer (負載均衡器): 你的餐廳非常成功，現在需要接受來自店外（網際網路）的訂單。Load Balancer 就是你的「外送平台入口」。當你將一個 Service 的類型設定為 LoadBalancer 時，Kubernetes 會請求雲端服務商（如 AWS, GCP）提供一個公開的、對外的 IP 位址。所有來自網際網路的流量會先到達這個外部的 Load Balancer，然後它再將流量轉發給你的 Service，最後由 Service 分配給某個 Pod。

互動關係: 流量的傳遞路徑通常是這樣的： 外部使用者 -> Load Balancer (對外 IP) -> Service (對內 IP) -> 其中一個健康的 Pod

Service 透過標籤（Labels）來識別它應該管理哪些 Pod。例如，所有由 "Web-API" Deployment 創建的 Pod 都會有 app: web-api 的標籤，而 "Web-API" Service 就會設定去尋找所有帶有這個標籤的 Pod。

總結與流程圖

讓我們把整個流程串起來：

1. 建立基礎 (Setup):

   • 你先建立一個 Cluster，這個叢集由數個 Node (機器) 組成。

2. 部署應用 (Deploy):

   • 你定義一個 Deployment，告訴它：「請幫我維持 3 個運行著 Nginx 映像檔的 Pod。」

   • Deployment 收到指令後，創建了 3 個 Pod，並將它們分散到不同的 Node 上運行。

3. 內部通訊 (Internal Access):

   • 你創建一個 Service，將它指向這 3 個 Nginx Pod。

   • 這個 Service 獲得了一個叢集內部的 IP 位址。叢集內的其他應用（例如一個後端 API）現在可以透過這個穩定的 Service IP 來存取 Nginx 服務。

4. 對外暴露 (External Access):

   • 你將 Service 的類型改為 LoadBalancer。

   • 雲端平台為你創建了一個外部的 Load Balancer，它有一個公開的 IP 位址。

5. 完整流程 (Full Flow):

   • 使用者在瀏覽器輸入你的網站網址。

   • DNS 將網址解析到 Load Balancer 的公開 IP。

   • 流量進入 Load Balancer，它將流量轉發到你叢集的某個 Node 上的特定埠口（NodePort）。

   • Service 接收到流量，並根據其負載均衡策略，將流量轉發到其中一個健康的 Nginx Pod 的私有 IP。

   • Pod 中的 Nginx 容器處理請求並回傳網頁內容。

這個互動模型是 Kubernetes 強大功能的核心，它將底層複雜的基礎設施抽象化，讓開發者可以專注於應用程式本身，而不用過度擔心伺服器的擴縮、故障轉移和網路配置。