Kubernetes

3 秒看懂

Kubernetes（K8s）是一個對容器化應用進行自動部署、彈性伸縮和全生命週期管理的開源平台。它將計算叢集抽象為統一的資源池，提供自愈、服務發現、滾動更新等能力，讓開發者像管理單臺機器一樣管理幾千臺伺服器上的工作負載，是雲端原生時代的事實標準“作業系統”。

3 分鐘產業解釋

如果把容器比作標準化的“集裝箱”，Kubernetes 就是精通港口排程的超級起重機 + 中央控制系統。它不直接搬運集裝箱，但通過對叢集中所有節點（物理機或虛擬機器）的統管，確保應用容器被放到最合適的位置，並持續維持使用者宣告的預期狀態。

誰在用：全球三大公有雲端（AWS、Azure、Google Cloud）均提供深度整合的託管 K8s 服務；大量企業的私有化、混合雲端和多雲端建設底層皆由 K8s 承載。
為什麼重要：它終結了“每個公司自己寫編排系統”的歷史，建置出統一的應用交付標準，讓產品團隊聚焦業務創新而非基礎設施拼接。
產業生態：Kubernetes 是雲端原生計算基金會（CNCF）的畢業專案，圍繞它的工具鏈（監控、服務網格、CI/CD、安全等）已形成千億美元級市場。

15 分鐘專家深入

Kubernetes 的設計哲學是宣告式 API + 控制迴圈，一切操作都通過向 API 伺服器提交期望狀態實現，系統內部控制器不斷將實際狀態調諧至期望狀態。

架構分層

控制平面（Master）：叢集大腦，通常自成一個高可用叢集。

kube-apiserver：唯一與 etcd 互動的元件，所有控制指令的入口，支援水平擴充套件。
etcd：強一致的分散式鍵值儲存，儲存叢集全部狀態。極度依賴低延遲磁碟 [未充分揭露] 。
kube-scheduler：監聽未繫結節點的 Pod，通過過濾（資源、親和性等）和打分（優選策略）決定其落腳節點。
kube-controller-manager：多個控制器（Deployment、ReplicaSet、節點生命週期等）的合體程序，驅動狀態收斂。
cloud-controller-manager：對接雲端廠商能力（負載均衡器、儲存卷、節點註冊）。

工作節點（Node）：真正執行應用的位置。

kubelet：負責 Pod 生命週期管理，呼叫容器執行時介面（CRI）建立/銷燬容器，向 API server 上報節點和 Pod 狀態。
容器執行時：通過 CRI 與 kubelet 互動，containerd 和 CRI-O 是兩大主流實現。
kube-proxy：在每個節點實現服務網路規則（iptables、IPVS 或通過 eBPF 替代方案如 Cilium），使 Service 的虛擬 IP 能被穩定路由到後端 Pod。

核心抽象

Pod：最小排程單元，內含 1 個或多個共享網路、IPC 的容器。
Service：為一組提供相同功能的 Pod 提供固定訪問入口（ClusterIP/NodePort/LoadBalancer）。
Deployment：宣告式管理無狀態應用的副本數、更新策略（滾動更新/回滾）。
StatefulSet：為有狀態應用提供穩定網路標識和持久儲存。
ConfigMap / Secret：將配置與敏感資訊從映象中解耦，以環境變數或卷方式注入。
PersistentVolume（PV） / PersistentVolumeClaim（PVC）：把儲存視為資源，實現儲存的抽象與動態供給。
Ingress：7 層流量規則入口，將外部 HTTP(S) 路徑對映到內部 Service。

網路與儲存模型

CNI（容器網路介面）：第三方網路外掛（Calico、Flannel、Cilium 等）實現 Pod 跨節點扁平化通訊，通常具備 Overlay 或 Underlay 模式。
CSI（容器儲存介面）：允許第三方儲存廠商提供符合標準的驅動，實現捲動態製備、掛載和快照等操作。
服務發現：CoreDNS 成為內建 DNS 伺服器，為 Service 和 Pod 提供名稱解析，kube-proxy 則負責將 Service IP 轉換為後端 Pod IP 的負載均衡規則。

排程與可擴充套件

排程是可插拔的；使用者可通過節點親和性、Pod 拓撲分佈約束、汙點與容忍等精細控制排布。設計大規模叢集時，常通過Pod 優先順序與搶佔、擴充套件排程器或自定義排程架構滿足效能與業務需求。

CRD（自定義資源）與 Operator 模式：將運維知識編碼為軟體，通過自定義資源擴充套件 Kubernetes 的能力，例如 Prometheus Operator 可自動管理監控元件。

技術原理（最深）

宣告式 API 與控制迴圈

使用者通過 kubectl apply -f deployment.yaml 提交期望狀態物件，kube-apiserver 將其落盤至 etcd。控制器監控資源變化，計算當前狀態與期望的差異（diff），並驅動執行子資源的建立或刪除。典型流程如下（以 Deployment 為例）：

使用者提交 Deployment 物件
        │
        ▼
┌─────────────────────────┐
│  kube-apiserver         │   → etcd 持久化
└─────────────────────────┘
        │
        ▼
┌──────────────────────────┐
│ deployment-controller    │  觀察 Deployment 與 ReplicaSet
│ (kube-controller-manager)│  建立符合預期的 ReplicaSet
└──────────────────────────┘
        │
        ▼
┌──────────────────────────┐
│ replicaset-controller    │  確保 Pod 數量正確
│ (kube-controller-manager)│  建立 Pod 物件（nodeName 為空）
└──────────────────────────┘
        │
        ▼
┌──────────────────────────┐
│ kube-scheduler           │  為未繫結節點的 Pod 選擇最優 Node
│                          │  更新 Pod 的 nodeName
└──────────────────────────┘
        │
        ▼
┌──────────────────────────┐
│ kubelet (所在節點)        │  監聽到分配至本節點的 Pod
│                          │  呼叫 CRI 建立容器
└──────────────────────────┘

Pod 網路實現機制

Pod 內所有容器共享一個網路名稱空間，通過一個 pause 容器 預先建立網路棧，其它業務容器通過 --net=container:pause 加入。跨節點通訊時，CNI 外掛負責：

為 Pod 分配 IP（通常每個節點擁有一個網段）。
配置路由或 Overlay 隧道（如 VXLAN），使不同節點 Pod 可直接通過 IP 互通。
以 Flannel VXLAN 為例：

Pod A (10.244.1.3) on Node1                Pod B (10.244.2.4) on Node2
       │                                              │
       ▼                                              ▼
    veth pair ──► cni0 bridge              veth pair ──► cni0 bridge
       │                                              │
       ▼                                              ▼
    flannel.1 (VTEP)  ── VXLAN tunnel ──▶  flannel.1 (VTEP)
       │                                              │
       ▼                                              ▼
   eth0 (192.168.1.10)   ──物理網路──▶   eth0 (192.168.1.11)

kube-proxy 實現 Service 負載均衡：早期用 iptables 生成隨機機率鏈，效能在大規模下退化，後轉向 IPVS（核心級 L4 負載均衡）。Cilium 等方案則通過 eBPF 完全替代 kube-proxy，在更細粒度且高效地處理資料包。

儲存供給流程

使用者建立 PVC（宣告需求），叢集內部執行 PersistentVolume Controller 根據 StorageClass 呼叫 CSI provisioner 向外部儲存系統動態建立卷，並繫結成 PV。排程器將 Pod 排程到相容節點後，kubelet 通過 CSI 驅動實現 attach 和 mount，最終容器內可見。對於一些本地卷 API（如 Local PV），排程器會感知卷的拓撲約束，避免 Pod 與卷錯位。

排程器工作原理

排程器從待排程 Pod 佇列中取出一個 Pod，分兩階段：

過濾（Predicates）：排除資源不足、汙點不匹配、卷拓撲衝突等節點。
打分（Priorities）：對剩餘節點按策略加權打分（如最少請求資源優先、節點親和性加分、映象本地性加分等），選出最高分節點。
可通過自定義排程架構（Scheduling Framework）註冊擴充套件點替代預設行為。

大規模叢集關鍵軟約束

etcd：Raft 共識演算法要求寫入延遲穩定，建議使用高 IOPS SSD，並維護 3 或 5 個奇數節點。大規模事件風暴時，API 伺服器 QPS 和高併發寫可能成為瓶頸，需通過審計策略和流控（APF）保護。
節點數：社群測試目標為 5000 節點 [社群公開資訊]，但實際運維中常通過多個控制平面租戶隔離（如虛擬叢集技術 vcluster，或 Cluster API 管理多叢集）橫向擴充套件。
控制器並行度：kubelet 彙報週期、node-status-update-frequency 等引數影響故障檢測速度 [未充分揭露]。

技術演進史

Kubernetes 源自 Google 內部 Borg 系統十餘年的經驗，2014 年開源。關鍵里程碑（定性）：

2015 年 v1.0：奠定 Pod、Service 基本抽象，釋出生產可用的首個正式版本。
2016 年 v1.2：Deployment 成為主流工作負載管理方式，簡化滾動更新。
2016~2017 年：StatefulSet（原 PetSet）和 DaemonSet 穩定，支撐資料庫等有狀態應用；RBAC 和 Pod 安全策略增強多租戶。
2018~2019 年：CSI 和 CRI 介面正式 GA，執行時和儲存徹底解耦；CRD（自定義資源定義）成熟，催生 Operator 生態。
2020~2022 年：宣佈移除內建 Docker 執行時（Dockershim），推動生態統一至 containerd / CRI-O；服務端應用（Server-side Apply）和不可變 Secret 等特性增強大型團隊協作。
2023~今：Sidecar 容器特性支援順序啟動，更適合服務網格；結構化鑑權配置、Pod 原地資源更換等大幅提升運維靈活性；生態持續向邊緣計算、AI 排程（如 GPU 共享、拓撲感知）演進。
社群遵循每 4 個月一個版本、每年三版，最新穩定版本追蹤依賴 [未通過檢索確認，建議查閱 kubernetes.io]。

技術路線對比（量化表）

以下對比基於行業認知定性，不含精確數值：

維度	Kubernetes	Docker Swarm	Apache Mesos + Marathon	Nomad (HashiCorp)
架構複雜性	高：控制平面元件多，學習曲線陡	低：單二進位制，與 Docker 深度繫結	中：依賴 ZooKeeper，雙級排程	低：單二進位制，架構精簡
生態豐富度	極高：CNCF 全景數千專案	低：社群萎縮	低：已商業失敗	中：與 Vault/Consul 整合好
自動伸縮能力	多維（HPA / VPA / CA）	基本	依賴第三方	支援任務級，無原生 VPA
批處理/大數據支援	較好：Job, CronJob, KubeFlow	弱	強：原生支援大數據架構	強：與 Hadoop 等良好整合
服務發現與負載均衡	內建 DNS + 多種 proxy 模式	內建 DNS	需藉助 Mesos-DNS	需第三方配合
社群活躍度	極高，貢獻者過萬 [據公開統計]	極低	已歸檔	穩定但小眾

國內主流容器雲端平台（如 Red Hat OpenShift、Rancher Prime、VMware Tanzu）皆為 K8s 發行版，增強了安全與運維能力。公有雲端託管服務（AKS, EKS, GKE）基本消除了自建控制平面的負擔。

上下游

上游（基礎設施與介面）

容器執行時：containerd, CRI-O, runc, gVisor, Kata Containers
Linux 核心原語：cgroups（v2 逐步成為標準）、namespaces、seccomp、eBPF
網路標準：CNI 規範，各第三方實現
儲存標準：CSI 規範，各廠商驅動
硬體/虛擬化：物理伺服器、虛擬化平台（vSphere, OpenStack）、裸金屬雲端

下游（平台與工具生態）

PaaS / 應用管理：OpenShift, Rancher Prime, KubeSphere, Google Cloud Run for Anthos
CI/CD：Tekton, Argo Workflows/CD, Jenkins X, Flux
服務網格：Istio, Linkerd, Consul Connect
可觀測性：Prometheus + Grafana, Thanos, Loki, Elastic ECK
安全：Falco, OPA/Gatekeeper, Kyverno, Trivy
開發者體驗：Helm, Kustomize, Tilt, Skaffold, DevSpace

關鍵指標

由於本次聯網檢索失敗，以下指標僅基於社群長期實踐經驗與定性描述，不可作為精確性能基準：

叢集規模：官方 SLO 針對 5000 節點 [社群文件]，單個控制面等實際根據 etcd 和 API Server 最佳化可進一步調優，但無公開硬上限。
Pod 密度：預設每節點 Pod 數約 110 個，可通過 kubelet --max-pods 調整，CNI 外掛決定實際可達數量。
API Server 吞吐：受認證欄位、WATCH 連線數、儲存（etcd）背壓影響。企業常常為不同請求等級配置優先順序與公平性（APF）。
etcd 效能：推薦磁碟順序寫延遲低於 10ms [社群建議]，否則控制面頻繁超時。
排程速率：預設排程器具備較高吞吐，可通過並行度和預選階段限制調節；生產環境常需啟用量目限制防止支配效應。
網路效能：Overlay 封裝帶來約 5%~15% 吞吐損耗 [非官方估計]，eBPF 直接路由可接近近線速，但具體數值極度依賴外掛及硬體。
可用性：控制平面採用多例項負載均衡，etcd 使用 Raft 仲裁，故障切換或領導者選舉一般可在秒級達成 [未充分揭露]。

供需與市場資料

（技術搜尋未返回精確數字，以下均為行業共識性趨勢描述，非定量引用）

據 CNCF 多次年度調查報告，容器在生產環境的使用率已超過 90%，其中 Kubernetes 佔據絕對主導地位 [行業普遍認知]。
全球託管 Kubernetes 服務市場由 AWS、Azure、GCP 三分天下，每家營收增長率持續高位 [未獲得最新財報資料]。
私有化部署的容器平台（如 OpenShift、Rancher）因資料主權和存量 IT 轉型需求，需求依然強勁，尤其在金融、政務行業。
人才缺口：Kubernetes 相關技能職位在 DevOps、平台工程等領域持續供不應求，CKA/CKAD 認證人數穩定增長 [教育機構估計]。

代表公司與資本對映

公有雲端託管服務商

Amazon EKS（及 EKS Distro、EKS Anywhere）
Google GKE（及 Anthos、Autopilot）
Azure AKS
阿里雲端 ACK、騰訊雲端 TKE、華為雲端 CCE

商業發行版 / 平台公司

Red Hat (IBM)：OpenShift，最成熟的企業 K8s 平台
VMware (Broadcom)：Tanzu，主打應用現代化
SUSE：Rancher Prime，多叢集管理領先
Mirantis：Docker Enterprise 轉型後聚焦容器雲端

核心元件與安全初創

Isovalent（Cilium 背後的公司，已被 Cisco 收購）
Tigera（Calico 商業公司）
Weaveworks（GitOps 先驅，2024 年已關閉但理念影響深遠）
Aqua Security、Sysdig、StackRox（容器安全賽道代表）

資本視角：託管 K8s 服務是雲端廠商的獲利驅動，而圍繞可觀測性、安全合規、混合/邊緣管理的上市公司和獨角獸構成了數百億美元市值叢集。這已成為雲端運算投資的“預設選項”。

投資邏輯

託管服務為雲端廠商創造黏性：客戶一旦將工作負載遷移到某家的託管 K8s，即可深度繫結其配套的資料庫、訊息佇列、監控等雲端服務，遷移成本高。
上層工具平台是價值爆發點：管理千個叢集的“多雲端控制平面”、服務網格、策略引擎、成本最佳化（FinOps）類產品是剛需。
邊緣 K8s（K3s, MicroK8s）與 5G、物聯網結合：輕量發行版在工業質檢、CDN 等場景釋放價值。
AI/ML 上的適配：Kubernetes 逐漸支援 GPU 拓撲感知、共享與 RDMA 排程，成為 AI 訓練平台事實底座（KubeFlow 等專案）。
風險：Kubernetes 自身迭代快、運維複雜度高，部分中小企業可能轉向 Serverless 容器服務（如 AWS Fargate）繞開底層管理，但這反而進一步推動託管 K8s 的滲透。

常見誤讀糾偏

誤讀 1：“Kubernetes 直接執行容器”
事實：Kubernetes 不建立也不管理容器本身，它通過 CRI 介面呼叫底層的容器執行時（如 containerd、CRI-O）來啟停容器。K8s 的角色是編排，而非容器引擎。
誤讀 2：“Kubernetes 替代了 Docker”
事實：Docker 是容器技術的一種實現，Kubernetes 早期用 Docker 作為預設執行時，後來為了統一介面而棄用內建的 Dockershim，直接對接 containerd（Docker 的底層元件）。Docker 映象格式仍然被廣泛使用。
誤讀 3：“用了 K8s 就自動實現高可用和彈性”
事實：Kubernetes 提供的是高可用和彈性伸縮的自動化機制，但必須由叢集管理員和應用開發者正確配置（健康檢查、副本數、資源請求、HPA 規則等），否則反而可能因驅逐策略導致服務不可用。
誤讀 4：“K8s 只能跑無狀態應用”
事實：通過 StatefulSet 和 PV/PVC 抽象，Kubernetes 已經成熟支援資料庫、訊息佇列、儲存系統等有狀態負載，生產環境使用 PostgreSQL、Kafka 等以 Operator 形式執行早已普遍。

學習路徑

基礎先修：Linux 命令列、容器與映象概念（Docker 入門）。
官方資料：Kubernetes 官方互動式教程 (https://kubernetes.io/docs/tutorials/) 及 “Play with Kubernetes” 環境。
認證導向：
- CKA（認證 Kubernetes 管理員）：覆蓋叢集運維、網路、儲存、故障排查。
- CKAD（認證應用開發者）：面向設計、建置、配置雲端原生應用。
- CKS（安全專家）：在 CKA 基礎上聚焦安全檢測與加固。
實戰工具：本地用 Minikube、kind 或 k3s 搭建開發環境；在公共雲端建立託管 K8s 小規模叢集實驗。
進階：閱讀《Kubernetes in Action》/ 《Programming Kubernetes》，分析核心元件原始碼，嘗試開發 Operator（使用 Kubebuilder 或 Operator Framework），理解 CNI/CSI 協議，參加 KubeCon 演講影片。

一句話總結

Kubernetes 是雲端原生的分散式應用作業系統，它將資料中心抽象為單一巨型資源池，讓應用獲取自愈、彈性與可移植性，成為現代基礎設施的預設介面。

延伸閱讀與來源

Kubernetes 官方文件：https://kubernetes.io/docs/ （最權威的架構與指南）
書籍：《Kubernetes in Action》 Marko Lukša，《Programming Kubernetes》 Michael Hausenblas 等
CNCF Cloud Native Landscape：https://landscape.cncf.io （全景生態圖）
社群實踐：Kubernetes Patterns (https://www.oreilly.com/library/view/kubernetes-patterns/9781492050285/)
大會演講：KubeCon + CloudNativeCon 歷年影片（YouTube）
注：本頁面編寫時聯網檢索遇阻，未盡精確資料/版本資訊皆以定性估算呈現，建議直接查閱上述來源獲取最新規範。

三步設好你的觀察臺

選 1-3 個想觀察的人或賽道

看一份樣張

設定一次異動告警

Kubernetes

Kubernetes

3 秒看懂

3 分鐘產業解釋

15 分鐘專家深入

架構分層

核心抽象

網路與儲存模型

排程與可擴充套件

技術原理（最深）

宣告式 API 與控制迴圈

Pod 網路實現機制

儲存供給流程

排程器工作原理

大規模叢集關鍵軟約束

技術演進史

技術路線對比（量化表）

上下游

關鍵指標

供需與市場資料

代表公司與資本對映

投資邏輯

常見誤讀糾偏

學習路徑

一句話總結

延伸閱讀與來源

Kubernetes

3 秒看懂

3 分鐘產業解釋

15 分鐘專家深入

架構分層

核心抽象

網路與儲存模型

排程與可擴充套件

技術原理（最深）

宣告式 API 與控制迴圈

Pod 網路實現機制

儲存供給流程

排程器工作原理

大規模叢集關鍵軟約束

技術演進史

技術路線對比（量化表）

上下游

關鍵指標

供需與市場資料

代表公司與資本對映

投資邏輯

常見誤讀糾偏

學習路徑

一句話總結

延伸閱讀與來源

相關推薦

同產業鏈 · 相關公司

相關概念