一、录制说明

正文中的【停顿】【加重】是给录制时的提示，不用念出来。

二、口播正文

0:00 — 0:35 开场：三秒钟里发生了什么

你有没有想过：你在终端敲下 kubectl apply，屏幕上只跳出三个字——created，然后过了几秒，一个 Pod 变成 Running。这三秒钟里，集群到底发生了什么？

大部分教程会告诉你「容器是轻量级虚拟化」，然后你就开始背名词。但真到了线上排障，Pod 卡在 Pending，你还是不知道该看哪。【停顿】

今天这条视频，我用九个生活里的比喻，把 Kubernetes 的底座讲一遍。不用记命令，先把画面建起来。

0:35 — 1:45 第一个比喻：容器不是小虚拟机，是一间合租房

先说最容易搞错的一件事：容器不是小虚拟机。

虚拟机像买了一套房。房子再小，水电燃气都得自己装一套，所以启动慢、占地方。容器像租一间房：水电是房东的，也就是宿主机的内核，所有容器共用。

但租来的房间有两样东西：一是门禁，二是额度。

门禁叫 Namespace，作用是让你看不见隔壁——看不见别人的进程、别人的网络、别人的文件。额度叫 cgroup，作用是让你用不了太多——CPU 用超了会被限流，变慢但不会死；内存用超了，配电箱直接跳闸，进程被内核杀掉。

所以看到容器的退出码是 137，别怀疑人生：137 就是 128 加 9，9 是 SIGKILL，翻译过来就是「被杀了」。【加重】

1:45 — 2:40 第二个比喻：镜像是一份分层便当

那容器里的程序，是怎么打包送过来的？靠镜像。

镜像像一份分层便当：最底下是米饭，也就是基础系统；中间是配菜，运行库；最上面是主菜，你的程序。一层一层叠起来，每一层单独封装。

分层的好处是复用：十种便当都用同一锅米饭，米饭只做一次；换的只是主菜，传输时也只传那一格。这就是为什么容器镜像常常只有几十兆，而不是几个 G。

还有个细节叫写时复制。你就理解成：便当盒全是封好的，容器启动时在上面盖一层保鲜膜，想改哪个文件，就复制到保鲜膜上改。所以容器里改的配置，重启就没了——它写在保鲜膜上。

2:40 — 3:50 第三个比喻：Pod 是一套合租房

问题来了：既然容器就是一间房，为什么 K8s 的最小单位不叫容器，叫 Pod？

因为现实里的应用不是一个人住。主程序、日志采集、本地代理，他们是一伙的，必须住在一起、共用一个门牌号、在客厅里说话——也就是用 localhost 通信。

所以 K8s 把「一套房」作为最小单位，这套房就是 Pod。调度按套房算，扩容按套房加，销毁时一整套一起退。

每套房里还住着一个奇怪的房客，叫 pause 容器。他不干活、不接客，只做一件事：拿着钥匙，保证这套房的门牌号不消失。技术上，他持有 Pod 级别的网络命名空间，业务容器都是「加入」他建好的网络。

所以你看到节点上一堆 pause 容器，千万别当垃圾删。【加重】删了，持有网络的进程没了，整个 Pod 的网络直接崩。

3:50 — 4:50 第四个比喻：apiserver 是公司唯一的前台

房子有了，接下来要有人管事。整栋楼只有一个前台，所有事都从他这儿办，没有后门。这就是 kube-apiserver。

它是三个唯一：所有用户请求的唯一入口，所有组件通信的唯一入口，也是唯一能进档案室、读写 etcd 的人。

每个请求进来，要过三道关。

第一关，认证：你是谁？证书过期、Token 不对，直接 401。

第二关，授权：这件事你能做吗？没给你创建 Pod 的权限，就是 403。

第三关，准入：这东西合不合规？配额够不够、镜像是不是来自内部仓库、允不允许特权容器。

三关都过，才会登记进档案室。注意：这个时候，容器一个都还没启动。【停顿】

4:50 — 5:50 第五个比喻：etcd 是三个人共记的一本总账

档案室里那本总账，就是 etcd。整个集群的全部状态，都记在这一本上。它丢了，集群就等于失忆——Pod 配置、Service、密码全没了，而且找不回来。

为了防止记丢，etcd 一般三个人一起记。选一个值班会计，所有新账先记他那儿；他要抄给多数人，过半签字才算数；会计病倒，剩下的人重新投票选一个。

这就是 Raft。为什么生产上只用 3 台或 5 台？因为决定权在过半：3 台能坏 1 台，5 台能坏 2 台，4 台也只能坏 1 台——多养一台，抗故障能力没变，不划算。

还有一条容易误解：过半的人不在，小组直接停止记账，不是少数服从多数继续写。3 台坏 2 台，集群就只能读、不能写。

5:50 — 6:50 第六个比喻：分诊台与巡场经理

总账记好了，谁来决定活派给谁？两个人：一个是分诊台的护士，一个是巡场的经理。

分诊台是 kube-scheduler。他的工作三步：先排除住不了的节点——满房、禁烟、没大床房；再给剩下的打分;最后发房卡，把结果写回 Pod。如果所有房间都被排除，客人只能站大堂等，这就是 Pod 一直 Pending。

巡场经理是 controller-manager。他的逻辑跟空调恒温器一模一样：读你设定的温度，读当前室温，比较，然后制冷或加热，过一会儿再看一次。【加重】永远在循环，永不停止。

所以 K8s 里没有「重启服务」这个动作。你删掉一个 Pod，经理发现人少了，立刻补一个；你把节点关机，他发现人不见了，重新安排到别处。

多副本时，同一时刻只有一个经理当班——靠一张会过期的房卡，谁抢到谁干，房卡到期就换人。

6:50 — 7:50 第七个比喻：宿管与总机

决定做完了，得有人在楼层里干活。每个节点上有两个岗位。

一个是宿管，kubelet。他手里有一份名单：分给我这层楼的 Pod。他安排入住，叫施工队来装修；每天查房，问三个问题——还活着吗、能接客吗、刚搬来适应了吗；然后定期向管理处汇报。

他汇报断了会怎样？这层楼就变成 NotReady，上面的 Pod 会被搬走。

另一个是总机接线员，kube-proxy。房间号会变，外面记不住，所以楼里设一个总机号码，也就是 Service。谁找业务就拨总机，接线员负责转到当前在岗的房间。

他有两种工作方式：贴一张写满规则的纸条，一条条查，这叫 iptables；或者换一台智能交换机，直接查表转发，这叫 IPVS。

记住一句：接线员只负责接线，不参与通话内容。所以访问不通，先看有没有人接——名单是不是空的，Pod 是不是 Ready，别一上来就翻规则。

7:50 — 8:40 最后一个比喻：一次 apply，就是从下单到送达

现在把这些角色串起来。你敲下 apply，就像点了一单外卖。

第一步，下单：kubectl 先问一句「这个对象存在吗」，不存在就创建，存在就算差异更新。

第二步，接单审核：前台过三关，把期望状态记进总账。

第三步，拆单：Deployment 把套餐拆成批次，批次再拆成一份份 Pod。

第四步，派单：分诊台选节点，写回房号。

第五步，制作送达：宿管叫施工队，起 pause 沙箱、拉镜像、起容器、跑探针。

第六步，开通服务：接线员写规则，别人终于能访问到。

8:40 — 9:10 收尾

所以下次 Pod 起不来，你不用猜。看它卡在哪个状态：Pending 是派单没派出去，ImagePullBackOff 是材料没拉到，CrashLoopBackOff 是一开工就崩。【加重】状态决定查哪一段，只看那一段的日志。

整套比喻我整理成了九份文档，从一间房、到一套房、到一座厂，再到一次下单的全流程。想看哪一段，评论区告诉我。

如果这条视频帮你把画面建起来了，点个收藏，下次排障前先回来对一眼。我们下期见。

三、分镜与时长对照