一、一个容器好办，一百个容器是另一回事

单台机器上跑一个容器，手敲一条命令就行。 一百个容器散在十台机器上，就完全不是一回事了—— 因为每台机器都可能挂，每个容器都可能退。

编排要解决的，其实就是这五个问题：

• 这个容器放哪台机器？ —— 调度器按资源余量挑。
• 容器挂了呢？ —— 自动重启；机器挂了，就换一台重来。
• 容器之间怎么找到对方？ —— 给每个服务一个固定名字，不写 IP。
• 怎么升级才不停机？ —— 一个一个换，好了再换下一个。
• 半夜流量涨了怎么办？ —— 照你定的规则自动加副本。

五个问题里，只有第一个是【挑地方】，剩下四个都是【出事后怎么办】。 这就说明编排真正处理的是意外，不是常态。

二、它和传统部署最大的差别是思路

传统部署的做法是下命令： 去启动三个容器、去把这台机器上的进程杀掉。

编排的做法是声明：我要三个一直在跑的副本。 然后它不停地对照【现状】和【你要的样子】，不一样就调回来。 你描述目标，它负责维持。

这个转变带来一个容易被忽略的代价： 你得先把【你要的样子】写清楚。 要几个副本、什么情况下算健康、资源给多少、更新时允许掉几个—— 这些在过去是运维脑子里的经验，现在必须写成文件。

换句话说：编排把人的经验变成了必须显式写出的规格。 这就是它上手慢的真正原因——不是工具难，是它逼你把原本模糊的东西说清楚。

三、Kubernetes 是赢家，赢到什么程度

在这一波里，Kubernetes（简称 K8s）是毫无争议的赢家：

• 容器编排市场里，K8s 占 92%——其余所有工具加起来只占 8%。
• 93% 的组织已经在用、试点或评估它。
• 容器用户中 82% 在生产环境跑 K8s（2023 年是 66%）。
• 79% 用的是托管服务，而不是自己搭集群。
• 采用者中 91% 是千人以上的企业。

CNCF 2026 年的年度调查还有几组数字，能看出它的位置变了：

• 98% 的组织已经采用云原生技术。
• 59% 的开发部署【大部分或几乎全部】是云原生。
• 66% 已经在托管生成式 AI 模型、用 K8s 跑推理。
• 47% 把【团队文化】列为头号障碍。

倒数第二行说明它已经不只是部署工具了，而是 AI 推理的承载层。 市场规模的增速也能对上：25.7 亿美元 → 31.3 亿美元，一年涨 21.8%。

四、卡住的是组织，不是技术

前面那组数字里，最值得琢磨的是这一条： 47% 把团队文化列为头号障碍。

基础设施已经就绪了，卡住的是组织本身。 因为声明的写法要求各团队对【健康】、【资源】、【更新节奏】有统一的说法—— 而这件事是协商出来的，不是配出来的。

同一份调查里还有一组冷静的数字： 只有 7% 的组织每天部署模型，超过一半的组织根本不训练模型， 只是把现成的模型跑稳、跑便宜。

门槛也摆在这儿：团队从零开始到能在生产环境稳定运行， 通常要 2~4 个月。所以它不是一个【装上就完了】的东西。

用一句话记住它的价值：K8s 把你从【盯着服务器】换成了【描述你要的状态】。 重活它干，但描述得你自己写清楚。

五、动手 Demo：容器多了以后，谁来决定放哪儿

三个数字可以直接算出来：生产采用的涨幅、非 K8s 的份额、市场增速：

print("  生产跑 K8s 的容器用户：66%% -> 82%%，涨 %d 个百分点" % (82 - 66))
print("  K8s 占编排市场 92%%，其余所有工具共占 %d%%" % (100 - 92))
print("  市场 25.7 亿 -> 31.3 亿美元，一年涨 %.1f%%" % ((31.3 / 25.7 - 1) * 100))

实跑输出：

--------------------------------------------------------------------
容器多了以后，谁来决定放哪儿
--------------------------------------------------------------------
  一个容器好办，一百个容器就是另一回事了。编排要解决的就是这五个问题：

  问题                       编排给出的答案
  ------------------------------------------------------
  这个容器放哪台机器？       调度器按资源余量挑
  容器挂了呢？               自动重启，机器挂了就换一台
  容器之间怎么找到对方？     给每个服务一个固定名字
  怎么升级才不停机？         一个一个换，好了再换下一个
  半夜流量涨了怎么办？       照你定的规则自动加副本
  ------------------------------------------------------
  它和传统部署最大的差别在思路上：
  你不再下命令【去启动三个容器】，而是声明【我要三个一直在跑的副本】，
  然后它不停地对照现状和你要的样子，不一样就调回来。

  Kubernetes 是这件事上的赢家，优势有多大看份额：

  指标                            数字
  -----------------------------------------------------
  容器编排市场里 K8s 的份额       92%
  在用／试点／评估 K8s 的组织     93%
  容器用户在生产环境跑 K8s        82%（2023 年是 66%）
  用托管服务而非自建集群          79%
  采用者中千人以上企业            91%
  -----------------------------------------------------
  CNCF 2026 年的年度调查还有几组数字，能看出它的位置变了：

  说法                                   比例
  --------------------------------------------
  已采用云原生技术的组织                 98%
  开发部署【大部分或几乎全部】云原生     59%
  托管生成式 AI 模型、用 K8s 跑推理      66%
  把团队文化列为头号障碍                 47%
  --------------------------------------------
  倒数第一行最值得琢磨：基础设施已经就绪了，卡住的是组织本身。
  同一份调查里还有一组冷静的数字——只有 7% 的组织每天部署模型，
  超过一半的组织根本不训练模型，只是把现成的模型跑稳、跑便宜。

  门槛也摆在这儿：团队从零开始到能在生产环境稳定运行，通常要 2~4 个月。
  所以它不是一个【装上就完了】的东西。
  用一句话记住它的价值：K8s 把你从【盯着服务器】
  换成了【描述你要的状态】——重活它干，但描述得你自己写清楚。

那 8% 是最能说明问题的数字。 一个市场里第一名占九成，剩下的所有竞争者分一成—— 这时候再去比较各家工具的优劣，意义已经不大了。 有意思的是，它和上一节【虚拟化市场被拆散】正好相反： 底层在分散，上层在集中。

30 秒实验

1. 在搜索引擎里找一份公开项目的 deployment.yaml，看它写的是【要几个副本】还是【怎么启动】。
2. 想一下你手上有没有【半夜流量涨了要手动做什么】的场景——那就是该编排的地方。
3. 查一下你用的云平台的托管 K8s 服务叫什么名字，看它是不是已经开着。

常见误区

1. 错误：K8s 就是自动重启容器。——纠正：自动重启只是它最基础的一件事；它的核心是声明式——你写清楚要的样子，它负责不停地把现状对回来。
2. 错误：用了 K8s 就等于云原生。——纠正：云原生是一种做法（容器、声明式、可观测、持续交付），K8s 只是其中的调度层；98% 采用云原生，但只有 59% 的部署是大部分或几乎全部云原生。
3. 错误：上了 K8s 就能提高部署频率。——纠正：卡住的大多是组织和流程；47% 把团队文化列为头号障碍，而每天部署模型的组织只有 7%。

• ☐ 下一节（8-12 实测Web服务器的负载：负载测试工具、监控CPU与内存的使用情况）

相关笔记

• 服务器的虚拟化技术 —— 上一节把机器切成容器，这一节给容器找地方
• 管理大量IT资源的机制 —— 大量资源怎么被统一管起来
• 不能停止运行的系统1 —— 不停机这件事本来是另一门手艺
• 实现多云计算的容器 —— 容器怎么跨云跑
• 负载的分散 —— 加副本这件事的上位讲法
• 🕸️ Web技术原理 · 索引