K8s（Kubernetes，容器编排系统），说白了就是一套“自动管理成千上万个软件集装箱”的总调度系统——如果容器是一个个标准化的集装箱，那 K8s 就是整个超级港口的智能调度中心：哪个集装箱放哪条船、哪个坏了自动换新、旺季加开班次、淡季缩减运力，全都不用人工操心。
最近你只要关心 AI、云计算或者通信行业的新闻，就几乎躲不开这个词：大厂训练大模型的上万块 GPU、运营商的电信云、你每天刷的视频和下的外卖 App 后台，底层多半都跑在 K8s 上。它已经悄悄成为数字世界的“隐形地基”。
目录
以前的文章讲过“容器”（Container）：把一个软件和它需要的所有依赖打包成一个标准化“箱子”，搬到任何服务器上都能直接运行，就像海运集装箱不管装的是香蕉还是手机，到了任何港口都能用同一台吊机装卸。
这个比喻来自行业惯例——最流行的容器工具 Docker，图标就是一只驮着集装箱的小鲸鱼。
一个集装箱，你自己就能搬。可现实是：
如果靠运维工程师手动一个个启动、监控、修复、扩容——哪怕一个团队三班倒也会崩溃，而且人一定会出错。
于是需要一个“总调度”，这就是 K8s。
K8s 是 Kubernetes 的缩写：首字母 K 和尾字母 s 中间隔着 8 个字母，程序员嫌长，就简写成 K8s（类似的还有 i18n、l10n）。Kubernetes 一词源自希腊语，意思是“舵手、领航员”——掌控整艘船航向的人。它 2014 年由 Google 开源，脱胎于 Google 内部跑了十几年的集群管理系统 Borg，2015 年捐给了中立的开源基金会 CNCF（云原生计算基金会），如今是云计算领域事实上的“世界语”。
用一个生活类比：K8s 就像一个超级餐厅的智能后厨总管。
| K8s 的能力 | 后厨总管做的事 | 白话解释 |
|---|---|---|
| 自动调度（Scheduling） | 哪道菜让哪个灶台的厨师炒 | 有几百台服务器，新来的容器放哪台最合适（CPU 够不够、内存够不够），K8s 自动算 |
| 自愈（Self-healing） | 厨师晕倒了？立刻叫替补顶上 | 某个容器崩了，K8s 秒级发现并自动重启一个新容器，用户完全无感 |
| 弹性伸缩（Scaling） | 饭点加开 10 个窗口，凌晨只留 1 个 | 流量高峰自动多开容器，低谷自动关闭，按需花算力钱 |
| 滚动升级（Rolling update） | 边营业边悄悄换菜谱 | 升级软件时先换一小批，没问题再全量换，出问题立刻回退，服务不中断 |
| 声明式管理（Declarative） | 你只管下菜单，不用教怎么炒 | 这是最精髓的一点，下一节单独讲 |
K8s 的用法叫声明式（Declarative），翻译成人话就是：
你写一张“期望清单”：“我要 10 个网页服务容器，永远保持 10 个在线。” 然后就没了。至于怎么启动、放哪台机器、挂了怎么补——K8s 全自动搞定。
就像点外卖：“我要一份宫保鸡丁”——你不需要告诉厨师先切鸡丁再炸花生米。只要实际数量和清单不符（比如挂了 1 个只剩 9 个），K8s 会不知疲倦地把现实“掰”回你声明的样子。这也是它和传统运维工具最大的区别：从“人指挥每一步”变成“人定目标，系统自己找路”。
和我们栏目最相关的一点：如今的 5G 核心网早已不是一堆专用黑盒子设备，而是拆成几十个软件化网元（还记得之前讲过的 SBA 服务化架构吗？核心网变成了一堆微服务），全部以容器方式跑在运营商的电信云上——而管着这些容器的，就是 K8s。可以说，你打的每一通 5G 电话（VoNR），背后都有 K8s 在值夜班。
K8s 其实 2014 年就诞生了，为什么这两年新闻里出现频率反而更高？三个原因：
训练和运行大模型需要海量 GPU，而 GPU 昂贵（一块高端加速卡数万元）、任务调度极复杂：几百个训练任务抢几千块卡，谁先用、谁让位、空闲了怎么回收——这本质就是一个超大规模的“资源调度”问题。全球主流 AI 公司的训练集群，底层调度平台几乎清一色是 K8s 或它的衍生版本。AI 越火，K8s 越忙。近两年 K8s 社区的重点发展方向也正是“更好地调度 GPU/AI 任务”（比如动态资源分配 DRA、AI 任务排队等特性在持续增强），开源社区里 AI 相关的容器项目增长最快。
云计算历史上出现过好几个同类竞品（Docker 自家的 Swarm、Apache 的 Mesos），但十年竞争下来 K8s 全面胜出——今天所有主流公有云（AWS、Azure、谷歌云、阿里云、华为云等）都提供 K8s 服务。对企业和求职者来说，学它不会白学；对设备商和运营商来说，电信云、边缘节点基于 K8s 建设没有“押错宝”的风险。
K8s 保持每年三个版本（约 4 月、8 月、12 月各一个）的稳定节奏迭代，是 GitHub 上最活跃的开源项目之一。围绕它还长出了一整个生态：装软件的 Helm、管流量的服务网格、跑在边缘小盒子上的轻量版 K3s……（延伸阅读里会提到。）它甚至不再只管容器——通过扩展，还能管理虚拟机、GPU、AI 任务，从“容器编排”进化成了“一切资源的总调度”。
⚠️ 一点诚实的说明：本文关于 AI 集群基于 K8s、CNCF 生态等表述基于行业公开共识；至于你看到这篇文章时的最新版本号，请以 Kubernetes 官网（kubernetes.io）为准——因为它每年发三个版本，任何具体数字都会很快过时。
看懂这张图只需要抓住一句话：“大脑”发号施令，“工人”埋头干活，“监工”永不下班。
flowchart TB
subgraph CP["🧠 控制平面（指挥部）"]
API["API Server<br/>前台接待：只收'期望清单'"]
SCH["Scheduler 调度器<br/>排班员：决定容器放哪台机器"]
CTL["Controller 控制器<br/>监工：盯着实际状态，偏了就掰回来"]
ETCD["etcd 数据库<br/>档案室：记录全港口的账本"]
end
subgraph N1["🖥️ 节点A（干活的服务器）"]
K1["kubelet 工头"] --- P1["容器📦"]
K2["kube-proxy 交通岗"] -.- P1
end
subgraph N2["🖥️ 节点B（干活的服务器）"]
K3["kubelet 工头"] --- P2["容器📦📦"]
end
U["👤 运维/开发人员<br/>声明：我要10个容器在线"] --> API
API --> SCH
SCH -->|"把容器安排到最合适的节点"| N1
SCH --> N2
CTL <-->|"实际只有9个？补1个！"| API
CTL -.->|"发现节点A宕机"| RES["🔄 在节点B重新拉起容器"]
API --> ETCD
三个关键角色，用人话再过一遍：
你每天都在“用” K8s，只是不知道：刷的短视频、下的外卖、打的网车、查的健康码式政务 App，背后高概率跑在 K8s 上。它的“自愈 + 弹性伸缩”能力， translates 成你的体验就是——半夜 App 也很少崩，双十一卡一下就恢复。它不直接改变你的生活，但它决定了你数字生活的“下限不会太低”。
下一期可以继续了解这三个“亲戚”：
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。