Kubernetes 架構與核心概念

而在開始學習指令與操作之前，理解 Kubernetes (K8s) 的設計哲學與架構是非常重要的。這篇文章將帶你認識 K8s 究竟解決了什麼問題，以及它的核心運作原理。

為什麼需要 Kubernetes？

在 虛擬機 (Virtual Machine, VM) 時代，我們在每台實體伺服器上執行多個 VM，每個 VM 都有完整的作業系統。雖然隔離性好，但資源利用率低且啟動慢。

進入 容器 (Container) 時代（如 Docker），我們共享從作業系統核心 (OS Kernel)，容器更加輕量、啟動快。但當你的應用程式擴展到成百上千個容器，分佈在多台伺服器時，問題就來了：

這這正是 Kubernetes (容器調度工具) 要解決的問題。它像是一個指揮家，指揮整個基礎設施樂團協同運作。

Kubernetes 叢集 (Cluster) 主要由兩大類型的節點組成：Control Plane (控制平面) 與 Node (工作節點)。

Kubernetes Architecture Diagram (圖片來源: Kubernetes.io)

Control Plane 是叢集的大腦，負責決策（例如調度 Pod）、偵測與回應叢集事件。

kube-apiserver: 這是 K8s 的大門。所有的操作指令（如 kubectl）或內部組件通訊，都必須經過 API Server。它是唯一直接與 etcd 溝通的元件。
etcd: 一個高可用的 Key-Value 資料庫，用來儲存整個叢集的狀態資料（Configuration data）。這是 K8s 的「記憶」。
kube-scheduler: 負責「排程」。當你建立一個新的 Pod，Scheduler 會根據資源需求（CPU/RAM）與限制，決定要將這個 Pod 放到哪個 Node 上執行。
kube-controller-manager: 負責執行各種控制器 (Controller)。例如，當 Node 掛掉時，Node Controller 會負責通知；當 Deployment 設定要有 3 個副本時，Replication Controller 會確保隨時都有 3 個副本在跑。

Node 是實際運行應用程式容器的地方。

kubelet: 每個 Node 上都會跑的 Agent。它會接收 Control Plane 的指令，確保容器在 Pod 中正常運行，並回報 Node 的狀態給 Master。
kube-proxy: 負責維護 Node 上的網路規則，實現 Service 的概念，讓流量能正確導發到後端的 Pod。
Container Runtime: 負責執行容器的軟體，最常見的是 containerd 或 CRI-O (早期是 Docker Shim)。

Kubernetes 最重要的設計哲學之一是 宣告式配置 (Declarative Configuration)。

指令式 (Imperative): 告訴電腦「做什麼動作」。例如：「啟動 3 個伺服器」、「安裝 Nginx」。
宣告式 (Declarative): 告訴電腦「我想要什麼結果 (Desired State)」。例如：「我想要隨時都有 3 個 Nginx 伺服器在執行」。

在 K8s 中，我們通常透過 YAML 檔案定義 Desired State，提交給 API Server。K8s 的 Controller 會不斷地監控 Current State (目前狀態)，並嘗試將其調整為 Desired State。

例如，如果你宣告要有 3 個 Pod，如果不小心刪掉了一個，K8s 會發現 Current State (2個) 與 Desired State (3個) 不符，於是自動再建立一個新的，這就是 自我修復 (Self-healing) 能力。

Kubernetes 是一個龐大且功能強大的系統。