摘要：本文回顾应用部署方式从物理机、虚拟机到容器的技术演进，分析大规模容器环境下编排系统的必要性，以及 Kubernetes 成为行业标准的技术原因。

一、应用部署方式的技术演进

应用部署方式经历了三个阶段，每一次演进都是为了解决前一阶段的资源利用率、隔离性和运维效率问题。

1.1 物理机直接部署

早期，应用程序直接部署在物理服务器的操作系统上，多个应用共享同一组硬件资源。

上图展示了物理机部署模型：所有应用共享同一个操作系统实例和底层硬件。这种架构存在以下问题：

• 无资源隔离：进程间共享 CPU 和内存，一个应用的资源占用可能导致其他应用性能劣化
• 故障传播：一个应用的异常（如内存泄漏、进程崩溃）可能影响同机的其他应用
• 扩展成本高：水平扩展需要采购物理硬件，交付周期通常以周为单位
• 资源利用率低：平均服务器利用率通常只有 10%~20%

1.2 虚拟化部署

虚拟化技术（VMware、KVM、Xen 等）在物理机之上引入 Hypervisor 层，将一台物理机划分为多个虚拟机（VM），每个 VM 拥有独立的 Guest OS。

上图展示了虚拟化部署模型：Hypervisor 在物理机上创建多个 VM，每个 VM 运行独立的 Guest OS 和应用。虚拟化解决了隔离性问题，但引入了新的开销：

改进	不足
应用之间通过 VM 实现强隔离	每个 VM 需要完整的 Guest OS（GB 级磁盘、百 MB 级内存开销）
资源按需分配给不同 VM	启动时间在分钟级（需要引导完整 OS）
物理机利用率显著提升	Hypervisor 自身有 CPU 和内存开销
可通过 API 自动创建和销毁 VM	每个 VM 的 OS 需要独立维护和补丁更新

1.3 容器化部署

容器技术（Docker、containerd）利用 Linux 内核的 Namespace（进程/网络/文件系统隔离）和 Cgroup（资源限制）机制，在同一个操作系统上实现进程级别的隔离。容器共享宿主机内核，不需要额外的 Guest OS。

上图展示了容器化部署模型：多个容器共享宿主机的 OS 内核，每个容器仅打包应用代码和依赖库。与虚拟机相比，容器的技术优势如下：

对比项	虚拟机	容器
隔离机制	硬件级（独立内核）	进程级（Namespace + Cgroup）
启动时间	分钟级	秒级至毫秒级
镜像体积	GB 级（含 Guest OS）	MB 级（仅应用 + 依赖）
性能开销	Hypervisor 虚拟化开销	接近原生性能
单机密度	数个到十几个 VM	数十到数百个容器
环境一致性	依赖 VM 镜像或配置管理工具	镜像不可变，构建即交付

容器镜像的不可变性（Immutability）是一个关键特性：同一个镜像在开发、测试、生产环境中行为一致，消除了"在我本地能跑"的问题。

上图说明了容器镜像的一致性：同一份镜像可以无差别地部署到不同环境，保证了运行时行为的可预测性。

二、为什么需要容器编排？

单机环境下，直接使用 docker run 即可管理少量容器。但在生产环境中，典型的微服务架构可能涉及数百个服务、数千个容器实例、分布在数十到数百台节点上。此时需要一个系统来自动化解决以下问题：

• 容器调度：将容器分配到合适的节点上运行（考虑 CPU、内存、磁盘等资源约束）
• 服务发现与负载均衡：容器 IP 动态变化，需要稳定的服务访问入口
• 自愈能力：容器崩溃后自动重启，节点故障后将容器迁移到健康节点
• 弹性伸缩：根据负载指标（CPU/内存/自定义指标）自动增减容器副本数
• 滚动更新与回滚：新版本逐步替换旧版本，出现问题时快速回退
• 配置与密钥管理：将配置从镜像中解耦，统一管理敏感数据

上图列出了容器编排系统需要解决的核心问题。这些问题在容器数量较少时可以手动处理，但在大规模场景下必须依赖自动化系统来管理。

三、容器编排方案的技术选型

2015-2017 年间，业界出现了三个主流的容器编排方案：

上图展示了三个编排方案的竞争格局。Docker Swarm 因功能有限逐步被边缘化；Mesos 主要服务于超大规模场景但社区采用率不高；Kubernetes 凭借以下技术优势最终成为行业标准：

因素	说明
架构来源	设计思想源自 Google 内部 Borg/Omega 系统 15+ 年的大规模生产实践
声明式 API	用户定义期望状态，系统通过控制循环自动收敛到目标状态
可扩展性	CRD（Custom Resource Definition）+ Operator 模式支持自定义资源和控制逻辑
开放标准	CNCF 托管，CRI/CNI/CSI 等接口标准化，不绑定特定实现
云厂商支持	AWS EKS、GCP GKE、Azure AKS 等托管服务降低了运维门槛

四、Kubernetes 的核心能力

Kubernetes 提供了一套完整的容器编排能力，覆盖应用生命周期的各个阶段：

以上思维导图展示了 Kubernetes 的六大核心能力域。每个能力域在后续文章中都有专门的章节深入讲解。

下表从运维视角说明 Kubernetes 解决的实际问题：

运维场景	手动运维	Kubernetes 自动化
服务进程崩溃	人工监测并手动重启	kubelet 通过 livenessProbe 检测并自动重启容器
流量峰值	提前评估并手动扩容节点和实例	HPA 根据 CPU/内存/自定义指标自动增加 Pod 副本
版本发布异常	手动停止新版本、恢复旧版本	kubectl rollout undo 一键回滚到上一版本
节点硬件故障	手动将应用迁移到其他节点	Controller 检测到节点不可用后自动在健康节点重建 Pod

五、Kubernetes 名称与简写

Kubernetes 源自希腊语 κυβερνήτης，意为"舵手"（helmsman）。项目 Logo 是一个七角舵轮。

简写 K8s 的由来：字母 K 与 s 之间有 8 个字母（u-b-e-r-n-e-t-e），采用 Numeronym 命名法缩写为 K8s，与 i18n（internationalization）、l10n（localization）同理。

六、声明式与命令式：K8s 的设计范式

Kubernetes 的核心设计理念是声明式（Declarative），这与传统的命令式（Imperative）运维方式有本质区别：

• 命令式：用户逐步发出操作指令——“创建容器、配置端口、启动服务、监控状态”，每一步都需要人工编排。
• 声明式：用户通过 YAML 文件描述期望状态（Desired State）——“我需要 3 个 nginx 副本，每个监听 80 端口”，Kubernetes 的控制循环（Control Loop）持续监测实际状态并自动向期望状态收敛。

上图对比了两种范式的工作流程。命令式需要人工编排每个步骤，声明式只需描述终态，由系统自动实现并持续维护。

声明式的技术优势：

• 幂等性：同一份 YAML 多次 kubectl apply，结果一致
• 自愈性：当实际状态偏离期望状态（如容器崩溃），控制循环自动修复
• 可审计：YAML 文件可纳入 Git 版本管理，所有变更可追溯
• 可预测：期望状态即文档，kubectl get 输出与 YAML 定义一致

七、搭建本地实验环境

以下是两种主流的本地 K8s 环境搭建方式：

# 方式一：Minikube（在虚拟机或容器中运行单节点集群）
# 安装参考：https://minikube.sigs.k8s.io/docs/start/
minikube start

# 方式二：Kind（Kubernetes in Docker，用 Docker 容器模拟 K8s 节点）
# 安装参考：https://kind.sigs.k8s.io/docs/user/quick-start/
kind create cluster

# 验证集群状态
kubectl cluster-info
kubectl get nodes

# 运行第一个 Pod
kubectl run nginx --image=nginx:1.24 --port=80
kubectl get pods

八、总结

上图概括了部署方式的技术演进路径，每一阶段的演进都由前一阶段的技术局限性驱动。

要点	说明
技术演进	物理机 → 虚拟机 → 容器 → 容器编排
K8s 定位	面向容器的自动化部署、扩缩和管理平台
核心能力	自动调度、自愈、弹性伸缩、服务发现、配置管理、存储编排
设计范式	声明式——用户描述期望状态，系统自动收敛