Kubernetes 全景导览：从部署演进到云原生底座

在云原生时代，Kubernetes 已经不仅仅是一个工具，它是分布式系统协作的通用语言，是应用交付的标准底座。要真正理解 K8s，必须先回到它诞生之前的世界------看看应用部署是如何一步步走到今天的。

文章目录

- 一、应用部署的三次范式跃迁
- - [1. 传统部署时代：一台物理机一个应用](#1. 传统部署时代：一台物理机一个应用)
  - [2. 虚拟化部署时代：把一台机器"劈"成多台](#2. 虚拟化部署时代：把一台机器"劈"成多台)
  - [3. 容器部署时代：轻量隔离，共享内核](#3. 容器部署时代：轻量隔离，共享内核)
- [二、Kubernetes 的前世今生](#二、Kubernetes 的前世今生)
- [三、Kubernetes 是什么](#三、Kubernetes 是什么)
- - 官方定义
  - 核心特性
- [四、Kubernetes 不是什么](#四、Kubernetes 不是什么)
- [五、Kubernetes 架构总览](#五、Kubernetes 架构总览)
- - [1. 控制平面组件（Control Plane）](#1. 控制平面组件（Control Plane）)
  - [2. Worker 组件（节点组件）](#2. Worker 组件（节点组件）)
  - [3. 插件（Addons）](#3. 插件（Addons）)
  - [4. 一个有意思的问题：为什么 master 节点上也有 kubelet 和 kube-proxy？](#4. 一个有意思的问题：为什么 master 节点上也有 kubelet 和 kube-proxy？)
- 六、总结

一、应用部署的三次范式跃迁

1. 传统部署时代：一台物理机一个应用

早期企业直接在物理服务器上运行应用程序。这种模式有一个根本缺陷：无法为应用定义清晰的资源边界。

一台物理机上混跑多个应用时，某个应用可能独占大部分 CPU 与内存，导致其他应用性能受损；
一个应用独占一台物理机虽然隔离性好，但资源利用率极低，且维护成本高昂，难以横向扩展。

资源分配与隔离的矛盾，成为那个时代最大的痛点。

2. 虚拟化部署时代：把一台机器"劈"成多台

虚拟化技术的出现给出了第一个像样的答案：它允许你在单个物理服务器的 CPU 上运行多个虚拟机（VM）。

每个 VM 是一台"完整的计算机"------在虚拟化硬件之上运行包括操作系统在内的全部组件；
应用被隔离在不同 VM 之间，一个应用无法自由访问另一个应用的信息，安全性显著提升；
添加或更新应用更加轻松，硬件成本下降，资源利用率与可伸缩性都得到改善。

3. 容器部署时代：轻量隔离，共享内核

容器与 VM 思路相似，但采用了轻量级的隔离机制 ：容器之间共享同一个操作系统内核，因此被称为"轻量级"。同时，容器依然拥有自己独立的文件系统、CPU、内存和进程空间。由于与底层基础设施解耦，容器可以跨云、跨操作系统发行版无缝移植。

容器之所以能迅速成为主流，源于以下核心优势：

优势	说明
敏捷的创建与部署	相比 VM 镜像，容器镜像的构建更简便、更高效
持续开发、集成与部署	镜像不可变性带来快速简单的回滚，支撑可靠而频繁的发布
开发与运维解耦	镜像在构建/发布阶段而非部署阶段创建，应用与基础设施分离
环境一致性	在笔记本上与在云中运行表现完全相同，消除"在我机器上能跑"
可移植性	可在 Ubuntu、RHEL、CoreOS、本地环境、Google Kubernetes Engine 等处运行
以应用为中心的管理	抽象层级从"虚拟硬件上跑 OS"上升为"逻辑资源上跑应用"
微服务友好	应用被拆分为松耦合、可动态部署管理的独立单元，而非单机整体运行
资源隔离	可预测的应用程序性能
资源利用	高效率、高密度

当容器成为交付单元，新的问题随之而来：成百上千个容器如何编排？ 这正是 Kubernetes 登场的舞台。

二、Kubernetes 的前世今生

Kubernetes 这个名字来自希腊语，意为**"舵手"或"领航员"**；而 K8s 则是将中间 8 个字母 "ubernete" 缩写为 "8" 的写法。

它的血统极为显赫。据说 Google 数据中心里运行着超过 20 亿个容器，而 Google 早在十年前就已大规模使用容器技术------最初开发了名为 Borg 的系统（后演进为 Omega ）来调度海量容器与工作负载。积累了多年经验之后，Google 决定重写这套容器管理系统并贡献给开源社区，让全世界受益。这个项目就是 Kubernetes。简单地说，Kubernetes 是 Google Omega 的开源版本。

几个关键的时间节点：

2014 年 6 月：谷歌云计算专家 Eric Brewer 在旧金山的发布会上为这款新的开源工具揭牌；
2015 年 5 月：Kubernetes 在 Google 上的搜索热度超越 Mesos 与 Docker Swarm，此后一路飙升，将对手远远甩开；
2015 年 7 月 22 日：K8s 迭代至 v1.0 并正式对外发布；
2017 年 9 月：Mesosphere 宣布支持 Kubernetes；同年 10 月，Docker 宣布在新版本中加入对 Kubernetes 的原生支持------容器编排"三足鼎立"的时代就此终结，Kubernetes 赢得全面胜利。

如今，AWS、Azure、Google、阿里云、腾讯云等主流公有云提供的容器服务均基于 Kubernetes；Rancher、CoreOS、IBM、Mirantis、Oracle、Red Hat、VMware 等厂商也在大力推广基于 Kubernetes 的 CaaS/PaaS 产品。Kubernetes 无疑是容器行业最炙手可热的明星。

三、Kubernetes 是什么

官方定义

Kubernetes（也称 K8s）是用于自动部署、扩缩和管理容器化应用程序的开源系统。它将组成应用程序的容器组合成逻辑单元，以便于管理和服务发现。

核心特性

自动化上线和回滚：Kubernetes 分步骤地将对应用或其配置的更改上线，同时监视应用运行状况，确保不会同时终止所有实例；一旦出现问题，会自动回滚你所做的更改。
服务发现与负载均衡：无需修改应用来适配陌生的服务发现机制。Kubernetes 为每个 Pod 分配独立的 IP 地址，并为一组 Pod 提供 DNS 名称，还可在它们之间实现负载均衡。
存储编排：自动挂载所选存储系统，包括本地存储、公有云提供商的存储，以及 iSCSI、NFS 等网络存储系统。
Secret 与配置管理：部署和更新 Secret 与应用配置时无需重新构建容器镜像，也不必把软件栈配置中的敏感信息暴露出来。
自动装箱：根据资源需求与其他限制自动放置容器，同时避免影响可用性；将关键型与尽力而为型工作负载混合放置，提高资源利用率、节省更多资源。
批量执行：除了在线服务，Kubernetes 还能管理批处理与 CI 工作负载，在期望时间替换失效的容器。
自我修复：自动重启崩溃的容器、必要时替换整个 Pod、在更大范围故障时重新挂载存储，并可与节点自动扩缩集成，实现节点级自我修复。
水平扩缩：用一个简单命令、一个 UI 或基于 CPU 使用率的策略，自动对应用程序进行扩缩。
IPv4/IPv6 双协议栈：为 Pod 和 Service 同时分配 IPv4 与 IPv6 地址。
为扩展性而设计：无需更改上游源码即可扩展 Kubernetes 集群的行为。

水平扩缩是日常最高频的操作之一，一行命令即可完成：

bash 复制代码

# 将名为 nginx 的 Deployment 副本数扩容到 4 个
kubectl scale deployment nginx --replicas=4

# 基于 CPU 使用率配置自动扩缩（最小 2 副本、最大 10 副本）
kubectl autoscale deployment nginx --cpu-percent=70 --min=2 --max=10

四、Kubernetes 不是什么

Kubernetes 并不是传统的 PaaS（平台即服务）系统，理解它的"边界"与理解它的能力同样重要：

不限制应用形态 ：不绑定应用框架，不限制语言运行时（Java、Python、Ruby 等皆可），只要满足 12-Factor 原则；不区分"app"与"service"，有状态、无状态、数据处理型负载统统支持。只要应用能跑在容器里，就能很好地跑在 Kubernetes 上。
不内置中间件与基础服务：不提供消息总线、Spark 等数据处理框架、MySQL 等数据库或 Ceph 等集群存储作为内置服务------但这些应用都可以运行在 Kubernetes 之上。
不负责源码与构建：不部署源码、不编译应用；针对 CI 工作流提供分层能力，但把"流水线如何组织"的选择权留给用户，因为不同用户的需求与偏好各不相同。
不绑定可观测性方案：允许用户自由选择日志、监控与告警系统。
不提供统一的配置语言：不强制某一种全面的应用配置语言/系统（例如 Jsonnet）。
不管机器本身：不提供机器配置、维护、管理或硬件层面的自修复系统。

💡 顺便厘清 PaaS 的概念：PaaS（Platform as a Service）即"平台即服务"，指云计算时代把服务器平台或开发环境作为服务提供。典型 PaaS 是一个开发平台框架，开发者基于内置软件组件构建或自定义云应用------就像 Microsoft Excel 的宏一样。其内置的可扩展性、高可用、多租户等云能力减少了开发者的代码工作量。Kubernetes 常被称为"PaaS 的构建材料"：它放弃了 PaaS 的一站式便利，换来了 PaaS 难以企及的灵活与通用。

五、Kubernetes 架构总览

一个 Kubernetes 集群由一组被称为 Node（节点） 的计算机组成，节点上运行着由 Kubernetes 管理的容器化应用。一个集群至少包含一个 master 节点和一个 worker 节点，整体架构分为三大块：控制平面（Control Plane）、节点组件（Worker 组件）、插件（Addons） 。

1. 控制平面组件（Control Plane）

控制平面负责对集群做出全局决策 （比如调度），以及检测和响应集群事件（例如当 Deployment 不满足 replicas 字段声明的副本数时，启动新的 Pod）。

控制平面组件可以运行在集群中的任意节点上。为了简化部署，初始化脚本通常在同一台机器上启动所有控制平面组件，并且不在该机器上运行用户容器。

kube-apiserver ：部署在 master 节点，提供 Kubernetes API 服务，是整个控制面的前端。各类客户端工具（CLI 或 UI）以及 Kubernetes 的其他组件都通过它来管理集群中的各种资源。
kube-scheduler：部署在 master 节点，按照预定的调度策略将 Pod 调度到相应的机器上。
kube-controller-manager：部署在 master 节点，负责维护集群状态，如故障检测、自动扩展、滚动更新等。
etcd ：兼具一致性与高可用性的键值数据库，是保存 Kubernetes 所有集群数据的后台数据库。

2. Worker 组件（节点组件）

Worker 组件在每个节点上运行（包括 master 节点），负责维护运行中的 Pod 并提供 Kubernetes 运行环境。

kubelet：集群中每个节点上都要运行的代理。它接收一组通过各类机制提供的 PodSpecs，确保其中描述的容器处于运行状态且健康；同时负责 Volume（CVI）与网络（CNI）的管理、维护容器的生命周期。
kube-proxy：在每个节点上运行的网络代理，负责为 Service 提供集群内部的服务发现与负载均衡。它维护节点上的网络规则，允许来自集群内部或外部的网络会话与 Pod 进行通信。
容器运行时（Container Runtime） ：负责镜像管理以及 Pod 和容器的真正运行（CRI）。Kubernetes 支持多种容器运行时：Docker、containerd、cri-o、rktlet，以及任何实现了 Kubernetes CRI（容器运行时接口）规范的运行时。

3. 插件（Addons）

插件使用 Kubernetes 资源（如 DaemonSet、Deployment）实现集群级功能，其资源归属于 kube-system 命名空间。常见插件包括：

KubeDNS：DNS 服务器，为 Kubernetes 服务提供 DNS 记录解析；
Dashboard：为集群提供 Web UI，便于管理集群中运行的应用、查看集群状态并进行故障排除；
容器资源监控：将容器的常见时间序列度量值存入集中式数据库，并提供浏览界面，例如 Heapster；
集群级日志：将容器日志汇聚到集中式日志存储，并提供搜索与浏览接口，例如 Fluentd-elasticsearch；
网络插件：实现 CNI（容器网络接口）规范的组件，负责为 Pod 分配 IP 地址，并让 Pod 在集群内部相互通信。

验证集群是否健康运转，最常用的就是下面几条命令：

bash 复制代码

# 查看集群所有节点状态
kubectl get nodes -o wide

# 查看 kube-system 命名空间下的组件 Pod
kubectl get pods -n kube-system

# 查看 API Server 与各组件的健康状况
kubectl get componentstatuses

4. 一个有意思的问题：为什么 master 节点上也有 kubelet 和 kube-proxy？

因为 Master 同时也是一个 worker。

Master 上也可以运行应用，事实上几乎所有的 Kubernetes 组件本身就运行在 Pod 里，例如 etcd、kube-apiserver、kube-controller-manager 等；
而 kubelet 是唯一没有以容器形式运行的 Kubernetes 组件------它必须直接常驻在节点操作系统上，才能去管理和拉起其他容器。

六、总结

从物理机到虚拟化，再到容器，应用部署的演进史本质上是一部对资源效率与交付速度不断加码的追求史。容器解决了轻量封装与环境一致性问题，Kubernetes 则解决了容器的规模化编排问题：服务发现与负载均衡、自动装箱、滚动发布与回滚、自我修复、水平扩缩，让它成为现代云原生基础设施的事实标准。同时也要清醒认识它的边界------Kubernetes 不是包办一切的 PaaS，不管中间件、不绑定语言与监控方案，它是数据中心级别的"容器操作系统"。理解其前世今生与"控制平面---节点组件---插件"的三层架构，正是从会用 K8s 迈向用好 K8s 的第一步。