K8s 是什麼？基本元件、核心功能、4 大優點一次看！
內容目錄
本文為 Kubernetes（下方簡稱 K8s） 的入門介紹，將以容器化技術的角度切入，因此需要讀者對 Docker 和容器化技術有基本認識，如果對相關概念還不太熟悉，請參考 Docker 是什麼？Docker 基本觀念介紹
K8s 解決了什麼問題？
介紹 K8s 前，我們應先了解它被用來解決什麼問題。
K8s 旨在幫助開發者建構大型服務時，有效管理成百上千台主機上容器間的通訊。
在 K8s 尚未問世前，想透過 Docker 快速啟動由容器組成的微服務，可以在單一伺服器上使用 Docker Compose 。開發者只需寫出一份 yaml 文件，將參數設置好後直接執行設置檔，就能啟動或終止一組相依的服務。
這雖然有效降低了測試和部署的難度，但 Docker Compose 的運行範圍受限於單一主機。在面對需要跨越多台主機協同工作的大規模服務時，就顯得力不從心。K8s 的容器自動化部署、擴展功能也就此展露頭角，成為大規模管理容器通訊的最佳解決方案。
K8s 是什麼？
K8s 是一種容器資源調度平台，能夠將部署流程自動化、擴展並管理不同容器間的工作負載。它的構想理念是「Automated container deployment, scaling, and management」，意即透過自動化功能提升應用程式的可靠性和減輕維運負擔，讓開發人員專注於軟體開發任務。
K8s 的微服務管理叢集，能夠達成 Docker Compose 的所有功能，例如：啟動容器，管理網路以及容器間的通訊。除此之外，它還能將多個 Container 分派到多台主機上，並監控每個 Container 的運行狀態。
如果 K8s 偵測到某個 Container 或 Pod 故障，它會啟動 Replica Set 來確保服務持續運行。除了能夠監控節點狀態，K8s 的自動擴展功能（Auto Scaling）可以幫助開發團隊自動調整 K8s 的節點數量來配合開發和營運時所需的資源用量。
在部署方面，K8s 的容器自動部署 (Automated deployment) 功能讓使用者能透過一個描述狀態的文件（通常是 yaml 格式）指定服務所需的容器和設定，讓 K8s 根據這份文件建立所需的資源或配置。
K8s 的架構和工作流程
下圖為一個 K8s 平台的 Cluster（集群），K8s Cluster [1] 中的成員統稱為 Node，這些 Node 會依照其工作角色，被區分成 Worker 或 Master。
我們能將 Worker Node 想像成人體的軀幹，並將 Master Node 想像成人體的大腦，負責發號命令。
-
- 圖中右邊為 Worker Node，通常會被配置較多的運算資源，因為它們要負責成百上千的應用程式。
- 圖中左邊的為 Master Node。 Master 上面執行的管理程式叫做 Control Plane，它們負責整個 Cluster 的排程和狀態維護。
- Worker Node 裡運行著數個 Pod[2]，Pod 是 K8s 裡運行和部署的基本單位，而一個 Pod 內允許多個 Container 並存。Kubernetes 透過 Pod 來包裝管理 Container，增加調度部署的彈性。
K8s 兩大基本元件
元件一、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 的組件。
元件二、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 容器化的本質讓封裝在內的應用程式與其相依的資源能夠緊密結合，從而解決不同平台的兼容問題，並降低在不同基礎架構上部署的難度。
二、宣告式組態
K8s 讓使用者透過宣告式組態文件（Kubernetes Manifest）來宣告期望的系統狀態，管理應用程序和資源。由於宣告式組態直接描述期望的服務狀態（declarative），不需要透過逐項命令式宣告（imperative）來堆疊，因此不易出錯。
K8s 宣告式組態以 YAML 或 JSON 檔格式撰寫，描述要執行運作的資源組態，再發送到 K8s API Server。API Server 會確保目標的運行狀態與使用者的期望相符。
K8s 宣告式組態支援版本控制、自動部署、回滾、擴展和自我修復，可以提高使用者管理大規模分佈式系統的能力。同時，它提供了高層次的抽象化，使開發人員和運營人員能夠專注於應用程序的行為和需求。
三、促進開發團隊和維運團隊的協作
K8s 透過提供統一的應用程式部署和管理平台，促進開發和維運團隊間的協作。開發人員能透過 Kubernetes Manifests File 將應用程式的配置定義為代碼，從而實現版本控管和持續部署。維運人員則能透過 K8s 自動化部屬流程，監控應用程式運行狀況並導入 CI/CD 工作流程。
四、儲存調度
K8s 的儲存調度（Storage Orchestration）功能對運行 Stateful 應用程式至關重要，因為它能將需要儲存資源的容器連接到能夠提供資源的基礎設施。
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 將更合適。
