本文為 Kubernetes（下方簡稱 K8s） 的入門介紹，將以容器化技術的角度切入，因此需要讀者對 Docker 和容器化技術有基本認識。如果對相關概念還不太熟悉，請參考 Docker 是什麼？Docker 基本觀念介紹

K8s 解決了什麼問題？ 

K8s 旨在幫助開發者建構大型服務時，有效管理成百上千台主機上容器間的通訊。

在 K8s 出現之前，想用 Docker 快速啟動多個微服務，可以在單台伺服器上使用 Docker Compose。開發者只需撰寫一份 YAML 文件，設定好參數後即可一鍵啟動或停止整組服務。

雖然降低了測試和部署的難度，但 Compose 僅限於單機運行，無法應對跨多台主機的大規模服務。K8s 的自動部署與擴展功能因此脫穎而出，成為管理大規模容器服務的最佳方案。

K8s 是什麼？

K8s 是一種容器資源調度平台，可以自動化部署、擴展並管理容器工作負載。

它的核心理念是「Automated container deployment, scaling, and management」，透過自動化提升應用可靠性，減輕維運負擔，讓開發人員專注於軟體開發。

K8s 的微服務管理叢集涵蓋 Docker Compose 所有功能，包括：啟動容器、管理網路與容器間通訊。更重要的是，它能將容器分派到多台主機，並監控每個容器的運行狀態。

當容器或 Pod 發生故障時，K8s 會啟動 Replica Set 確保服務持續運行；自動擴展功能（Auto Scaling）則可依需求自動調整節點數量，滿足開發與營運資源需求。

在部署方面，K8s 支援自動化部署。使用者只需提供描述服務所需狀態的 YAML 文件，K8s 就會根據設定自動建立容器和資源，簡化部署流程。

K8s 的架構和工作流程

下圖為一個 K8s 平台的 Cluster（集群），K8s Cluster [1] 中的成員統稱為 Node，這些 Node 會依照其工作角色，被區分成 Worker 或 Master。

我們能將 Worker Node 想像成人體的軀幹，並將 Master Node 想像成人體的大腦，負責發號命令。

1. 1. 圖中右邊為 Worker Node，通常會被配置較多的運算資源，因為它們要負責成百上千的應用程式。
   2. 圖中左邊的為 Master Node。 Master 上面執行的管理程式叫做 Control Plane，它們負責整個 Cluster 的排程和狀態維護。
   3. Worker Node 裡運行著數個 Pod[2]，Pod 是 K8s 裡運行和部署的基本單位，而一個 Pod 內允許多個 Container 並存。Kubernetes 透過 Pod 來包裝管理 Container，增加調度部署的彈性。

K8s 兩大基本元件

元件 1：Master Node（Control Plane）

Control plane 又叫控制平台，是 K8s 運作的指揮中心，負責下達指揮命令。

例如：容器排程（Scheduling Containers）、服務管理（Managing Services）和回應 API 請求（Serving API Requests）。

Control Plane 會透過專用 API 與各個 Node 進行通訊，也會監控所有 Node 的工作負載，並下發指令來應對突發狀況。舉例來説，如果 Control Plane 偵測到應用程式的使用量暴增，它會調度相應的運算資源來應對，並在使用量下降時，自動縮減運算資源。

Control plane 由 4 個元件組成：

• Kube-API Server： 所有請求的唯一入口，也是 Cluster 中各個 Node 的溝通橋樑，負責身份驗證（Authentication）、授權（Authorization）、存取控制（Access Control）和 API 註冊（Registration）。

• etcd： 存放 K8s Cluster 備份資訊的資料庫，紀錄整個 K8s 的狀態。 當 Controller Plane 發生故障， etcd 可以幫我們還原 K8s 的狀態。

• Kube-scheduler： K8s 的工作調度器，負責監控所有使用者開啓 Pod 的指令，並根據 Worker Node 的資源規定和硬體限制找出最合適的 Worker Node。

• Kube-controller-manager：K8s Cluster 的自動化控制中心，負責管理並運行 K8s Controller 的組件。

元件 2：Worker Node

Worker Node 是 K8s 中的工作主機，負責管理和運行 Pod。它可以是實體機，也可以是虛擬機（例如：AWS 上的 EC2）。每個 Node 都包含運行 Pod 所需的服務，並由 Master Node 管理。

Worker Node 上的服務包括：

• Pod

Pod 是 K8s 中最小的資源部署單位，設計目的是爲了簡化容器化應用程式的部署和管理。

一個 Pod 封裝了一個或多個 Container，這些容器共同執行相同的工作任務，也共享相同的網路資源（例如：IP 地址、記憶體和主機名）。這種架構允許容器間能高效地共享和交換資料，同時也保證了容器間通信的簡便性和安全性。

雖然使用者能將應用程式上的所有容器封裝至同一個 Pod，但最佳做法是讓每個 Pod 對應一個 Container，接著再把這些 Pod 裝入 Namespace，這樣就能組成一個完整的應用程式。

• Kubelet

Kubelet 是 Worker Node 與 Kube-API Server 進行溝通的元件，主要負責接收 API server 發送的新或修改後的 Pod 規格，確保 Pod 及 Pod 內的容器在 API Server 的期望下運行。

Kubelet 也會定時從 Worker Node 上收集 Pod/Container 上的狀態（例如：運行什麼 Container、副本運行數量、資源配置），並將這些資訊匯報給 Control Plane。如果 Controller 沒有收到節點的運行資訊，該 Node 就會被斷定為 Unhealthy。

• Kube-proxy

Kube-Proxy 是每個 Node 上運行的網路代理服務，負責管理 Pod 間的網路通信規則、 Cluster 內部的通訊與回應 Cluster 外部的 request 。如果作業系統中存在封包過濾器（packet filtering layer），Kube-proxy 會將處理 request 的請求轉由 Worker Node 的作業系統處理。 

• Container Runtime

Container Runtime 屬於較為底層的元件，負責實際運行容器，並聽從 Kubelet 的命令管理容器。

K8s 支援多種不同的 Container Runtime，例如：containerd 、 runC 、 CRI-O 等。

K8s 四大核心功能

一、動態擴展（Dynamic Scaling）

實務上，DevOps 常碰到資源不夠用的情況，原因是應用流量會隨時間變化，但分配的資源始終固定。

K8s 透過 Dynamic Scaling 可動態增減運算資源，常見方式包括：水平擴展（Horizontal Scaling）、垂直擴展（Vertical Scaling）。

水平擴展（Horizontal Scaling）

水平擴展（Horizontal Scaling）[3] 的核心概念是根據「工作負載的變化來更新 Pod 的數量」。

這意味著當負載增加時，我們可以自動部署更多的 Pod，以確保服務的性能。而負載減少時，也能減少 Pod 的數量，以確保資源不被浪費。

具體來說， K8s 會透過 Horizontal Pod Autoscaler（HPA，一種用於自動調整應用程式中 Pod 副本數的控制器） 自動更新工作負載資源（例如：Deployment 或 StatefulSet），並由這兩種資源負責更新 Pod 數量，使 Pod 在資源節約和服務性能之間達到平衡。

水平擴展運作流程

如上圖所示，使用 HPA 架構的 K8s 首先會透過 Metric Server 檢測各項指標，如果監測到 CPU/Mermory 的利用率高於目標，HPA 會增加 Pod 的數量，直到平均使用率降低到目標範圍內。

垂直擴展（Vertical Scaling） 

與水平擴展不同，垂直擴展（Vertical Scaling）的核心概念是根據工作負載的變化來「更新 Pod 的資源請求而非 Pod 數量」。

換句話説，當負載增加時，我們可以給 Pod 更多資源，以確保服務不會因為超出資源限制而降低性能。負載減少時，也能減少 Pod 的資源請求，以確保資源不被浪費。

Vertical Pod Autoscaler（ VPA ，垂直 Pod 資源擴縮器）會根據容器的資源使用率自動縮放 Pod 能存取的 CPU 和 Memory 資源，讓 Pod 中的應用程式能夠取得足夠的運算資源，維持應用程式的服務品質。

垂直擴展運作流程

如上圖所示，首先使用 VPA 架構的 K8s 每隔 10 秒檢查各資源的使用指標，當請求資源增加，VPA Operator 會根據資源使用量更動 Pod 的資源配置，並將 Pod 重啟，重啟後的 Pod 就是新的資源配置。

簡而言之，水平擴展是關於「增減 Pod 的數量」，而垂直擴展則是關於「調整單個 Pod 的資源」。這兩種機制讓我們能夠在 K8s 中實現有效的負載管理，確保應用程式在不同工作負載下都能保持高性能。

二、自我修復（Self Healing）

K8s 能夠即時地修復 Cluster 中有問題的 Pod。

當一個節點或 Pod 出現故障時， K8s 會自動將它們從 Cluster 中刪除並重新創建，以確保應用程式的可用性。

除此之外，K8s 還會確認系統狀態是否與開發者的需求配置相符。舉例來說，如果開發者向 K8s 提出建立 3 個副本的需求，K8s 除了建立副本之外，也會持續確認這 3 個副本的運行狀態，如果發現有第 4 個副本被建立了，K8s 會將第 4 個副本刪除，以維持３個副本的設定。另外，如果其中一個副本停止運行，為了維持運行３個副本，K8s 就會重新建立一個副本。

三、滾動更新（Rolling Updates）

開發團隊能透過 K8s Cluster 中的 ReplicaSet 執行 Rolling Update[4] ，從而避免應用程式更新時造成停機。ReplicaSet 主要負責管理 Pod 的數量，確保某個 Pod 在停止運行時，能將其快速重建以確保服務的可用性。

Rolling Update 會透過同時建立新版 Pod 的 ReplicaSet 以及逐步關閉舊版 Pod 來進行更新。這意味著開發者無須擔心在更新過程中將所有 Pod 同時關閉，進而導致服務中斷。

四、回復舊版（Rolling Back）

如果版本更新後發現服務有問題怎麼辦？Rolling Back 可以解決這個問題！

前段提到的 Rolling Update 會透過建立新版 Pod 的 ReplicaSet 來更新，而 Rolling Back 則是透過舊版的 ReplicaSet 來恢復舊版 Pod。

通常如果沒有設定參數，一個 Deployment 中會保留最多十版的 ReplicaSet 。開發者如果在服務運行時發現錯誤，就可透過 Rolling Back 功能找到想要恢復的舊版本 ReplicaSet 進行無痛 Rollback。

K8s 的四個優勢

輕量級

K8s 的輕量化特性讓應用程式能被輕易地部署至不同環境，例如：地端資料中心、公有雲或其他雲端混合環境。K8s 容器化的本質讓封裝在內的應用程式與其相依的資源能夠緊密結合，從而解決不同平台的兼容問題，並降低在不同基礎架構上部署的難度。

同時，借助 HashiCorp Vault，您可以輕鬆地在這些環境中安全地管理應用程式的 secrets 和憑證，無需擔心安全風險。Vault 可以與 K8s 無縫整合，提供集中式的 secrets 管理，簡化 secrets 的存取控制，並確保應用程式在不同環境中的安全性。

宣告式組態

K8s 讓使用者透過宣告式組態文件（Kubernetes Manifest）來宣告期望的系統狀態，管理應用程序和資源。由於宣告式組態直接描述期望的服務狀態（declarative），不需要透過逐項命令式宣告（imperative）來堆疊，因此不易出錯。

K8s 宣告式組態以 YAML 或 JSON 檔格式撰寫，描述要執行運作的資源組態，再發送到 K8s API Server。API Server 會確保目標的運行狀態與使用者的期望相符。

例如：在部署 EDB PostgreSQL 資料庫時，您可以使用 K8s 宣告式組態來定義 PostgreSQL 叢集的期望狀態，包括副本數量、儲存配置、資源限制等。K8s 會自動確保 PostgreSQL 叢集按照您的配置運行，並在發生故障時自動進行修復，確保資料庫的高可用性和穩定性。

K8s 宣告式組態支援版本控制、自動部署、回滾、擴展和自我修復，可以提高使用者管理大規模分佈式系統的能力。同時，它提供了高層次的抽象化，使開發人員和運營人員能夠專注於應用程序的行為和需求。

促進開發和維運團隊的協作

K8s 透過提供統一的應用程式部署和管理平台，促進開發和維運團隊間的協作。開發人員能透過 Kubernetes Manifests File 將應用程式的配置定義為代碼，從而實現版本控管和持續部署。維運人員則能透過 K8s 自動化部屬流程，監控應用程式運行狀況並導入 CI/CD 工作流程。

此外，開發和維運團隊可以共同使用 ELK Stack 來監控應用程式的效能和健康狀況。ELK Stack 可以收集和分析 K8s 叢集中的各種日誌和指標數據，例如：應用程式日誌、系統日誌、Pod 事件等，並提供實時的視覺化 dashboards 和報警功能。

開發人員可以透過 Kibana 的視覺化介面，快速識別和診斷應用程式問題；維運人員可以利用 Elasticsearch 的強大搜尋和分析功能，深入分析日誌數據，並主動地解決潛在問題，進一步提升團隊協作效率。

儲存調度

K8s 的儲存調度（Storage Orchestration）功能對運行 Stateful 應用程式至關重要，因為它能將需要儲存資源的容器連接到能夠提供資源的基礎設施。

例如：EDB PostgreSQL 資料庫等 Stateful 應用程式需要持久化的儲存來保存資料。K8s 的儲存調度功能可以將 PostgreSQL 容器連接到合適的儲存卷，並確保資料的持久性和一致性，即使 Pod 重新啟動或遷移到不同的節點，資料也不會丟失。

K8s 執行儲存協調的方式會因多種因素而異，例如儲存基礎架構（Storage Infrastructure）種類以及容器使用 Storage 的方式。

以下圖為例，需要將日誌文件寫入本機 Volume 時可以使用 Local 儲存方式，使用 Azure 時可以使用 AzureFile 儲存方式等。K8s 的儲存協調功能讓使用者能按照不同需求進行儲存。

開源容器編排工具的對比：K8s v.s Docker Swarm 

K8s 和 Docker Swarm 是市面上兩種主流容器編排工具，這段我們將比較這兩種工具的功能、優勢與適用場景。

高可用性（High availability）

兩種工具都具備高可用性

• K8s：自動檢測不健康的 Pod，並將工作負載調度到健康的 Pod 上，從而確保服務的可用性。
• Docker Swarm：Swarm Managers 的高可用性控制機制（Availability Control）能確保節點出現故障時，叢集仍能夠運行。此外，Swarm Manager 會自動在叢集中的節點上分配和調度服務實例，從而達到負載平衡和高可用的目的。

負載平衡（Load balancing）

Docker Swarm 相較 K8s 具備自動化負載平衡功能。然而，使用者可以透過第三方工具將負載平衡功能整合至 K8s Cluster 上。

• Kubernetes：透過單一的 DNS 名稱啟用服務的 Discovery。K8s 能透過 IP 或 HTTP Route 存取容器應用程式。
• Docker Swarm：具備內建的負載平衡器

擴展性（Scalability）

K8s 以 Pod 為單位擴展，適合規模較大的擴展。與之相比， Docker Swarm 以容器為單位擴展，擴展速度較快。

• K8s：內建 HPA 水平擴展
• Docker Swarm：需要額外安裝水平擴展

所以，該選擇 K8s 還是 Docker Swarm ?

K8s 作為熱門的容器調度平台，擁有龐大的社群資源。

除此之外，各大雲端供應商和 Docker EE 也都支援 K8s 。雖然 K8s 的功能相較 Docker EE 更強大、更靈活且更客製化，但學習曲線也更陡峭。因此 K8s 需要由一支經驗豐富的團隊維運；為了節省成本，一些公司也會選擇將 K8s 交由託管商維運。

而 Docker Swarm 擁有 Docker 原生與組態設定較為簡單的優勢，能夠無縫與 Docker 引擎整合，並且在環境中快速啟動和部署。相較於 K8s ，Docker Swarm 提供使用者更直觀的入門選擇，並適合處理較小的工作負載。

選擇 Docker Swarm 還是 K8s 這個問題取決於自身的需求、團隊的技術能力以及想要實現的目標。如果你的應用規模較小，並且正在尋找一個部署步驟簡單、容易上手的解決方案，Docker Swarm 會是不錯的選擇。反之，如果你有足夠的預算並且需要一個功能豐富、能大規模擴展並且有龐大社群和雲端供應商支持的解決方案，K8s 將更合適。

---

參考網址

1. Kubernetes Components
2. Pods
3. Horizontal Pod Autoscaling
4. Performing a Rolling Update

---