← 返回概念辨析

Concept Contrast Fable

Kubernetes 和容器:一个管货物怎么摆,一个管货物怎么装

容器和 Kubernetes 经常在同一份架构图里出现,时间久了大家开口就说“上 K8s 跑容器”,好像它们是一体两面。但容器解决的是程序怎么打包和隔离运行,Kubernetes 解决的是几百个容器怎么调度、怎么恢复、怎么联网。打包方案和调度方案是两层架构,混在一起选型会同时绑死两层的自由度。

寓言

码头调度中心里的集装箱和吊车

大港来了许多标准货箱,也来了调度全港泊位的总旗房。港务长管着两摊看似相近的事:一摊是一只只封好的货箱,另一摊是安排货箱上哪条船、坏船时挪到哪里、缺人时怎样补位。新伙计嫌麻烦,把两本册子合成一本,觉得反正都和成败有关。

最初没人反对。新商人以为有了货箱就等于有了好港口,掌柜看见页数少了,还夸他们省事。可旺季一到,旧账忽然说不清:到底是前一摊没做完,还是后一摊没守住,谁也答不上来。

他们先补了更多章印和口号,要求每个人写得详细些。结果册子更厚,争执更多。出事时,每个人都能找到一句为自己开脱的话,却没人知道该先救哪一头。

老管事把众人叫到院里,让他们按真实经过重走一遍。凡是关心眼前动作的,放在第一本;凡是关心后续承担的,放在第二本。两本册子互相引用,却不再混成同一页。

风暴一来,货箱都好好的,船位却乱了,冷货没人接电,急货被压在最底层。分开之后,很多旧结论改了:有些活看着热闹,其实没有挡住麻烦;有些安排平时不起眼,灾时却保住了全局。

为了防止新人再混,老管事让他们各办一件小案。只有当两本册子分别能回答自己的问题,又能在交界处互相接上,这件小案才算过关。若有人仍把两摊事写成一页,就必须回到现场重新看一遍谁先动手、谁最后担责;看不清时,宁可多问一次,也不让糊涂账过夜;因为真正出事那天,少一行分辨就会多一队人白忙。

港务长让货箱继续标准化,又让总旗房管泊位、班次、替换和健康巡查。后来新人入行,老管事只让他们记一句:装东西的箱子解决携带,调度箱子的港口解决成规模运行。

Kubernetes

容器编排平台,负责容器的调度、扩缩容、服务发现、负载均衡和故障恢复。管的是“一组容器怎么协同运行”。

容器

应用打包和运行时隔离技术,将程序及其依赖封装成标准化单元,可以在不同环境中一致运行。管的是“单个程序怎么打包和启动”。

故事对应

  • 集装箱统一包装货物:容器,把程序和环境打包成标准单元
  • 调度系统安排堆位和取货顺序:Kubernetes,编排容器的运行位置和生命周期
  • 打包合同把装箱和调度绑死:整体采购方案阻止了某一层的独立升级
  • 标准标签协议解耦两层:容器运行时的标准接口让编排层可以自由替换

落到基础设施选型里

架构评审时把容器运行时和编排平台分成两份独立决策。容器运行时回答“用什么打包、用什么隔离”,候选包括 Docker、containerd 等;编排平台回答“用什么调度、用什么做服务发现”,候选包括 K8s、Nomad 等。预算审批单上两行分开,给未来任何一层的独立替换留出合法通道。