KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

05 · 什么时候别用它 — keel 龙骨

前三章你已经会"交上去、它维持、给它一个入口"了。这一章不教新命令，只回答一个问题—— 这套东西，你该不该用。 它放在最后，因为一个技术用得对不对，往往不取决于你多会用它， 而取决于你知不知道它的边界。

前三章你已经会"交上去、它维持、给它一个入口"了。这一章不教新命令，只回答一个问题——
这套东西，你该不该用。 它放在最后，因为一个技术用得对不对，往往不取决于你多会用它，
而取决于你知不知道它的边界。

一、回到你刚体验过的那三件事

判断的材料就是你前三章亲手做过的事——挨个问一遍：

① 你交了一份文件，它自己去达成。
前提是这份"想要什么"需要被别人、被另一台机器、或者在很久以后重新读一遍。只跑在你自己
那台机器上、只有你动它的话，"期望状态"就是你脑子里的念头，敲一条 docker run 就表达了。

② 你删掉一个，它自己补回来。
前提是它在你不在场的时候也得活着。只要"进程挂了能自己起来"的话，上一门课那层就有
更省事的做法：docker run 加一个重启策略，或者交给 systemd 写开机自启 + 挂了重拉。

③ 一个地址不变，成员会换。
前提是成员真的会有多个、真的会换。只跑一个容器的话，-p 8080:80 已经是稳定的入口。

三条问下来是同一个形状：每件让你眼前一亮的事，都有一个"它值这个复杂度"的前提。

二、另外两条边界，代价不在技术上

上面三条是"用不上"，这两条是"用得起但代价不对等"：

你在改这个服务的时候。 写一行代码要看到结果，走的是"构建镜像 → 推上去 → 交文件 →
等它收敛"——每一步都比"改完直接跑"慢。不是它慢，是它在替你做别的事（维持份数、
滚动替换）；做开发时不需要那些。

没有人在真的维护它。 这是最容易被忽略、代价最大的一条。真出事时你会看到 Pending、
CrashLoopBackOff、ImagePullBackOff——每一个对应不同的原因和处置方向，看不懂只能搜。
再加上集群自己的软件也会过期、要升级，而升级有窗口。没人真的管这些，这东西就会从
"基础设施"变成"没人敢动的一坨"。

三、一条共同的判断线索

前面五条是同一句话的不同侧面：

它的价值来自"不止一台机器"和"不止一个人（或不止一段时间）需要维持它"这两件事同时成立。
缺一件，它就在替一个不存在的问题花力气。

拿到一个需求时，先问的不是"怎么用 Kubernetes 做"，而是这三个：

它要跑的地方不止一台机器吗？
它要在我不在场的时候、很久以后还保持那个样子吗？
除了我，还有别的人（或别的系统）需要读这份"想要什么"吗？

三个都是"是"，它值得；有一个是"不是"，先去考虑更小的东西。更细的选型替换（托管集群 /
函数计算 / 对象存储）在《Kubernetes 应用课》
的"什么时候不该上 K8s"一节。

四、一张速查表（用的时候回来查）

命令 做什么
kubectl get pods / get pods -o wide 副本现在怎么样（1/1 Running 才是好的）/ 哪台机器、地址多少
kubectl get deploy / get svc / get endpoints <名字> 份数 / 入口地址 / 成员名单
kubectl apply -f 文件.yaml 交期望状态。同一个文件交多少次都行
kubectl delete -f 文件.yaml / delete pod <名字> 撤掉这份文件管的东西 / 删一个（会再长一个出来）
kubectl describe pod <名字> / logs <名字> 细节与事件（排查第一件工具）/ 程序说了什么

不要背这张表。记住三件事就够了：get pods 看现在怎么样、describe 看为什么、
logs 看它说了什么。

五、读完你能做什么

下一步去哪

这门课到这里就结束了——你已经知道它是什么、边界在哪。

进入 keel 阅读