Kubernetes（簡稱 K8s）是一款開源的容器編排平臺，核心目標是實現容器化應用的自動化部署、擴展、故障恢復和運維管理。其設計遵循 “主從架構”（Control Plane + Node），組件分工明確，通過 “聲明式 API” 和 “控制器模式” 實現集群狀態的自動調諧。
一、Kubernetes 整體架構
? ? K8s 集群由兩部分組成：控制平面（Control Plane）?和工作節點（Node）。控制平面是集群的 “大腦”，負責決策；工作節點是 “手腳”，負責運行容器化應用。
| 角色 | 核心作用 | 部署建議 |
|---|---|---|
| 控制平面（CP） | 管理集群狀態（如 Pod 調度、副本數量、故障恢復） | 生產環境需多節點高可用部署 |
| 工作節點（Node） | 運行容器化應用，執行控制平面下發的任務 | 數量根據業務負載擴展 |
二、核心組件
? ? K8s 的功能依賴于多個組件的協同工作，組件分為 “控制平面組件” 和 “工作節點組件” 兩類，部分組件還需依賴外部插件（如容器運行時、網絡插件）。
1. 控制平面組件（Control Plane Components）
? ? 控制平面組件通常部署在專用的控制節點上，負責集群的 “決策與管理”。
| 組件名稱 | 核心功能 | 關鍵特性 |
|---|---|---|
| kube-apiserver | 集群的 “統一入口”，所有操作（如創建 Pod、查詢狀態）都通過它執行 | - 唯一與 etcd 交互的組件（讀寫集群狀態） - 提供 RESTful API，支持認證 / 授權 - 是組件間通信的 “中樞”（其他組件不直接交互，均通過 apiserver） |
| etcd | 分布式鍵值（Key-Value）數據庫，存儲集群的所有狀態信息（如 Pod 配置、Service 規則） | - 強一致性（基于 Raft 協議），確保集群狀態可靠 - 生產環境需 3/5 節點集群部署（高可用） - 僅 kube-apiserver 可直接讀寫 etcd |
| kube-scheduler | 負責將 “未調度的 Pod” 分配到合適的工作節點（Node） | - 調度依據：資源需求（CPU / 內存）、親和性 / 反親和性、污點 / 容忍、節點負載等 - 僅負責 “調度決策”，不執行 Pod 啟動（由 kubelet 執行） |
| kube-controller-manager | 運行各類 “控制器”，監控集群狀態，確保 “實際狀態” 向 “期望狀態” 對齊（調諧） | 內置核心控制器： - 副本控制器（ReplicaSet）：維持 Pod 副本數 - 節點控制器（NodeController）：監控節點健康 - 部署控制器（Deployment）：管理 Pod 升級 - 服務控制器（ServiceController）：關聯 Pod 與 Service |
| cloud-controller-manager | （可選）對接云服務商 API（如 AWS、阿里云），實現云資源聯動（如負載均衡、存儲） | 僅在 “云環境” 中部署，物理機 / 私有集群無需此組件 |
2. 工作節點組件（Node Components）
每個工作節點（Node）都必須部署以下組件，負責 “執行控制平面的任務” 和 “管理本地容器”。
| 組件名稱 | 核心功能 | 依賴關系 |
|---|---|---|
| kubelet | 監控本節點的 Pod，確保 Pod 內的容器正常運行（啟動、重啟、停止） | - 從 apiserver 獲取 Pod 的 “期望狀態”（如容器鏡像、資源限制） - 調用 “容器運行時”（如 containerd）執行容器操作 - 定期向 apiserver 上報本節點和 Pod 的狀態 |
| kube-proxy | 實現 K8s 的 “服務（Service）” 網絡功能，維護節點的網絡規則 | - 為 Service 分配 “虛擬 IP（ClusterIP）”，并將流量轉發到后端 Pod - 支持兩種模式： 1. iptables 模式（默認，輕量）：通過 iptables 規則實現轉發 2. ipvs 模式（高性能）：適合大規模集群 - 確保 Pod 間、Pod 與外部的網絡連通性 |
| 容器運行時（CRI） | 實際運行容器的軟件，需符合 K8s 的 “容器運行時接口（CRI）” | 常用選項： - containerd（目前主流，Docker 已棄用直接支持，需通過 containerd） - CRI-O（專為 K8s 設計，輕量） - Docker（需額外安裝 cri-dockerd 適配器，逐步淘汰） |
3. 必備插件（Add-ons）
部分核心功能需通過插件實現，控制平面和節點均需依賴：
網絡插件（CNI）：實現 Pod 間跨節點通信（K8s 本身不提供網絡功能），常用插件如 Calico、Flannel、Weave Net。
DNS 插件（CoreDNS）：為集群內的 Pod 和 Service 提供 DNS 解析（如通過 Service 名稱訪問 Pod），是集群默認組件。
存儲插件（CSI）：對接持久化存儲（如云硬盤、NAS），實現 Pod 存儲持久化（容器存儲默認臨時，刪除 Pod 后數據丟失），常用插件如 AWS EBS CSI、阿里云 CSI。
三、Kubernetes 核心工作原理
K8s 的核心邏輯是 “聲明式調諧”：用戶通過 API 聲明 “期望的集群狀態”（如 “部署 3 個 Nginx 副本”），K8s 自動將 “實際狀態” 調整為 “期望狀態”，無需用戶手動操作。
1. 核心模式：聲明式 API + 控制器模式
這是 K8s 與傳統 “命令式工具”（如 Docker Compose）的本質區別：
聲明式 API：用戶只需定義 “最終要什么”（如
kubectl apply -f nginx-deploy.yaml），無需關心 “如何實現”；K8s 會記錄這個 “期望狀態” 到 etcd。控制器模式：每個控制器（如 Deployment 控制器）通過 apiserver “監聽” 集群狀態，對比 “期望狀態” 和 “實際狀態”：
若實際狀態 ≠ 期望狀態（如 Pod 副本數不足 3 個），控制器會觸發 “調諧操作”（如創建新 Pod）；
若實際狀態 = 期望狀態，控制器則 “靜默監控”，不做操作。
2. 典型工作流程：部署一個 Nginx 應用
以 “通過 Deployment 部署 3 個 Nginx 副本” 為例，理解 K8s 組件的協同邏輯：
用戶提交請求：通過
kubectl apply -f nginx-deploy.yaml向 apiserver 發送 “創建 Deployment” 的請求，指定 “3 個副本”。apiserver 處理：驗證請求合法性后，將 Deployment 的 “期望狀態”（3 副本）存入 etcd，并返回 “創建成功” 給用戶。
控制器調諧：Deployment 控制器通過 apiserver 監聽 Deployment 資源，發現 “期望 3 副本” 但 “實際 0 副本”，于是自動創建一個 ReplicaSet（負責維護副本數），并將 ReplicaSet 的狀態存入 etcd。
調度 Pod：ReplicaSet 控制器監聽 ReplicaSet 資源，發現 “期望 3 副本”，向 apiserver 請求創建 3 個 Pod。kube-scheduler 監聽 “未調度的 Pod”，根據節點資源、親和性等規則，將 3 個 Pod 分別調度到 3 個不同的 Node 上，并將 Pod 的 “調度結果”（綁定到某個 Node）存入 etcd。
啟動容器：每個 Node 上的 kubelet 通過 apiserver 監聽 “分配給本節點的 Pod”，調用 containerd 拉取 Nginx 鏡像，啟動容器，并定期向 apiserver 上報 Pod 狀態（如 “Running”）。
網絡訪問：用戶創建 Service（
kubectl expose deployment nginx-deploy --port=80），kube-proxy 在每個 Node 上維護 iptables 規則，為 Service 分配 ClusterIP（如 10.96.0.10），并將訪問 ClusterIP 的流量轉發到 3 個 Nginx Pod，實現負載均衡。故障自愈：若其中一個 Nginx Pod 意外崩潰（狀態變為 “CrashLoopBackOff”），ReplicaSet 控制器通過 apiserver 發現 “實際 2 副本 < 期望 3 副本”，立即請求創建 1 個新 Pod，kube-scheduler 重新調度，kubelet 啟動新容器，最終恢復 3 副本狀態。
3. 核心概念：Pod 與 Service 的關系
- Pod：K8s 的最小部署單元，一個 Pod 可包含 1 個或多個容器（如 “應用容器 + 日志收集容器”），容器間共享網絡和存儲。
? 注意：Pod 是 “臨時的”，會因節點故障、調度更新等原因銷毀重建，IP 地址會變化，無法直接作為固定訪問入口。 - Service：為 “一組相同功能的 Pod” 提供固定訪問入口（如 ClusterIP、NodePort），通過 “標簽選擇器”（Label Selector）關聯 Pod。即使 Pod 銷毀重建，Service 的 IP 和端口不變，確保外部訪問不中斷。
四、關鍵輔助概念
理解以下概念能更好地掌握 K8s 的使用場景：
Namespace：實現 “資源隔離”，將集群劃分為多個虛擬子集群（如 “開發環境”“測試環境”“生產環境”），避免不同環境的資源沖突。
ConfigMap/Secret：管理應用配置：
ConfigMap：存儲明文配置（如數據庫地址、端口）；
Secret：存儲敏感信息（如密碼、Token），會進行 Base64 編碼（非加密，需配合外部加密工具如 Vault 實現安全存儲）。
Volume：解決 “容器存儲臨時化” 問題，將外部存儲（如本地磁盤、云硬盤、NAS）掛載到 Pod 內，實現數據持久化（Pod 刪除后數據不丟失）。
五、總結
K8s 的架構和原理圍繞 “自動化、高可用、可擴展” 設計：
架構層面：控制平面決策，工作節點執行，組件間通過 apiserver 通信，etcd 保障狀態可靠；
原理層面：通過 “聲明式 API + 控制器模式” 實現自愈，無需人工干預；
核心價值：屏蔽容器底層的復雜性，讓用戶專注于應用本身，而非基礎設施運維，支撐大規模容器集群的穩定運行。
