技术简述

技术发展如此迅速，以至于几乎不可能跟上节奏。有时我们刚学会一项新技术，它就已经过时，被其他东西取代了。

以容器为例。Docker 几年前才出现，如今已广泛应用于各种场景。尽管它仍是一款相对较新的产品，但其形态已多次演变。就在开发者刚刚掌握 docker run 的用法时，却被告知它已过时，应改用 docker-compose up。于是大家开始将所有 docker run 命令转换为 Compose 的 YAML 格式。

而当他们刚完成转换，又得知容器不应直接运行，而应通过容器调度器来管理。更复杂的是，他们必须在 Mesos 和 Marathon、Docker Swarm 或 Kubernetes 之间做出选择。

我们可以选择无视这些趋势，但这意味着我们将落后于竞争对手。保持竞争力没有捷径，一旦放松警惕、停止学习和进步，竞争者就会抢占我们的市场。即使是在高度监管的行业，也无人能幸免于持续改进的压力。只有先跟上当前的技术步伐，创新才有可能实现。只有真正掌握了他人今日所做的一切，我们才能向前迈进，提出真正的新想法。

如今，容器调度器已成为常态。它们不再是未来的概念，而是当下的现实。它们将持续存在，尽管未来几个月甚至几年内可能会经历巨大变化。理解容器调度器至关重要。

Kubernetes 是目前使用最广泛的容器调度器，拥有庞大的社区支持。

在深入探讨 Kubernetes 之前，了解一些历史背景或许有助于我们理解开发者曾面临的问题，以及他们所经历的挑战。

过去的一瞥

想象一个年轻的男孩。他刚刚完成了数月的工作，对自己的成果感到自豪，却又不确定是否真的能正常运行。他尚未在真正的服务器上测试过这个程序，这将是第一次交付自己的劳动成果。

他从抽屉里取出一张软盘，插入电脑，复制之前编译好的文件。他庆幸自己不用再使用穿孔卡片——那已经是过去的事了。

他起身离开办公桌，走出办公室，走向自己的汽车。前往存放服务器的机房需要超过两个小时。他对这段漫长的车程并不满意，但别无选择。他本可以派信使送软盘，但这毫无意义，因为他必须亲自安装软件，远程操作不可行。他必须到场。

一段时间后，他进入服务器机房，插入软盘，复制并安装软件。十五分钟后，他的脸上显露出焦虑的神情。事情并未按预期运行，出现了意料之外的问题。他正在收集输出信息，记录笔记，尽力保持冷静，尽可能多地获取线索。他担心着漫长归程，以及可能持续数天甚至数周的排查时间。他必须返回，重新安装修复方案。也许第二次就能成功，但更大概率还是失败。

这就是过去的缩影。我们可以想象，完成一次简单的部署任务，曾经需要付出多么巨大的不确定性与努力。