很多人把云计算理解成“把服务器放到别人的机房”，把容器理解成“更轻量的虚拟机”。这两个说法都抓住了一点表象，却没有解释它们为什么改变了软件交付方式。

这组文章先从资源管理的演进开始，再讨论容器的隔离机制、Docker 的工程实践和 Kubernetes 的调度模型。重点不是记住一堆产品名，而是理解每一层解决了什么问题。

一、计算资源为什么需要抽象

一台物理服务器提供 CPU、内存、磁盘和网络。早期应用直接部署在服务器上，优点是路径短，缺点是资源利用率和交付效率都很差：一台机器上的应用会互相争抢资源，扩容需要采购和安装，迁移还要重新配置环境。

因此基础设施逐步出现了三层抽象：

  • 虚拟机：把一台物理机切分成多个相互隔离的完整计算机，每台虚拟机拥有自己的内核和用户空间。
  • 容器：隔离进程、网络、文件系统和资源配额，但共享宿主机内核。
  • 云服务：把计算、存储、网络和应用能力封装成可按需申请的服务，并用 API 自动化管理。

抽象层越高，使用者越少关心底层设备；同时也越需要接受服务边界、故障模型和计费方式的约束。

二、云计算解决的核心问题

云计算的价值可以拆成四件事：

  1. 资源池化：把多个数据中心或集群的资源统一管理，按需分配。
  2. 弹性：业务高峰时增加实例，低峰时释放实例。
  3. 自动化：通过 API、声明式配置和控制器完成创建、升级、扩缩容和回收。
  4. 服务化：把基础设施能力包装成标准服务，使用者按使用量或订阅付费。

常见的服务模型是：IaaS 提供虚拟机、网络和磁盘；PaaS 提供运行应用所需的平台；SaaS 直接提供可使用的软件。它们不是互斥的产品分类，而是责任边界：服务商负责的范围越大，用户管理的底层细节越少。

三、虚拟机和容器怎么选择

虚拟机的隔离边界更完整，适合运行不同操作系统、需要强隔离的租户环境，以及对内核有特殊要求的工作负载。容器启动更快、镜像更容易分发，适合微服务、批处理和持续交付。

容器并没有消除虚拟机。公有云中常见的架构是“虚拟机承载容器”：虚拟机提供租户隔离，容器负责应用交付。选择时应该先看隔离、兼容性和运维责任，再比较启动速度和资源开销。

四、云原生不是某个产品

云原生更像一组工程习惯：应用可重复构建、配置与代码分离、实例尽量无状态、通过 API 管理、能够水平扩展，并且具备日志、指标和追踪能力。容器和 Kubernetes 是常见实现方式，但不是云原生的全部。

例如，一个只把应用打进镜像、仍然依赖人工登录服务器修改配置的系统，仍然没有获得云原生的主要收益。真正的改进来自可重复交付、自动恢复和可观测性。

五、接下来怎样学习

建议按这条路径建立概念：先理解虚拟机与容器的边界，再学习 Docker 镜像、网络和存储，最后学习 Kubernetes 的 Pod、Deployment、Service 和控制器。每学习一个概念，都用“它管理什么状态、谁负责恢复、故障会如何传播”三个问题检验理解。

下一篇会从 Linux 的 Namespace、cgroup 和 UnionFS 解释容器为什么能够工作。

参考资料：