KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

课程导读 · Kubernetes 应用课 — keel 龙骨

Kubernetes 应用课：把编排用对的参考信息：课程导读 · Kubernetes 应用课

从「YAML 能提交」到「知道它会在集群里怎么卡住」

你现在的起点

先对一下。下面四条里只要有一条不确定，对应章节就是为你写的：

你能说清 kubectl apply 返回成功之后，还有哪些事没发生；
你的 Deployment 清单里同时有 requests 与 limits，并且你能说出两者分别被谁使用；
你的 Pod 有三个探针（startupProbe / readinessProbe / livenessProbe），并且知道少任何一个会出什么问题；
你改过 ConfigMap 之后，知道哪些 Pod 会看到新值、哪些不会。

第 4 条是最容易答错的一条。多数人的直觉是"改了配置，重启一下就好了"——方向对，但**"重启"发生在什么时候、由谁触发**这件事，K8s 故意没有替你做。

一条能走通的学习路径

它怎么运转              01 声明式与调谐：apply 之后发生了什么
  ↓
对象怎么分工            02 清单解剖：谁管什么，标签怎么连接它们
  ↓
怎么判定"活着"          03 探针三件套：三个判定，三种后果
  ↓
怎么判定"装得下"        04 资源预算：requests 与 limits 是两件事
  ↓
怎么安全地换版本        05 滚动更新：算术、回滚与 revision
  ↓
外部的东西怎么进去      06 配置与密钥：两种传播语义
  ↓
坏了怎么查              07 异常状态分流与选型边界

01–02 是地形（它怎么运转、对象怎么分工），03–06 是四个具体判断点（活着、装得下、换版本、喂配置），07 收口到排障。

03 与 05 之间有依赖：没有 readinessProbe，滚动更新的"就绪"判定就无从谈起。建议连着读。

章节地图

章	关键问题	你会亲手验证什么
01 声明式与调谐	`apply` 成功意味着什么？控制器在做什么？	用 `kubectl kustomize` 离线构建出 base/两套 overlay，并看到 `apply --dry-run=client` 在无集群时照样失败
02 清单解剖	每个对象的职责边界在哪？标签为什么是"连接组织"？	实测 `namePrefix` 改写了资源名与引用，却没有改 selector
03 探针三件套	三种探针分别判定什么、判错的后果是什么？	从构建产物算出 `startupProbe` 的启动容忍预算（实测 60 秒）
04 资源预算	`requests` 与 `limits` 分别被谁使用？超卖怎么算？	算出全清单的 requests/limits 合计与超卖比（实测 CPU 4.17 倍）
05 滚动更新与回滚	滚动更新在滚什么？`maxUnavailable: 0` 保证什么？	用静态检查抓出 `maxSurge=0 + maxUnavailable=0` 的死锁组合
06 配置与密钥	为什么改了 ConfigMap 而 Pod 里没变？	用引用解析检查抓出"引用了不在清单里的对象"这一类问题
07 异常状态与边界	五种常见异常状态分别从哪查起？什么时候不该上 K8s？	用两套检查各自跑一遍，看它们分别漏掉什么

每章统一以 现场 → 机制推演 → 实测输出 → 生产边界 → 动手 → 故障注入 → 自测 收束。

与相邻课程的分工

《Docker 应用课》：它的 03 与 06 章是本课的前置。那边的 --start-period 与本课的 startupProbe、那边的 stop_grace_period 与本课的 terminationGracePeriodSeconds 是同一件事的两种表达。本课不重讲信号与 PID 1，只在需要处指过去。
《构建打包与部署上线》：五种部署策略的横向取舍在那边；本课只把"滚动更新"这一种深入下去。
《CI 流水线与质量门禁》：本课 01 章的离线校验管道，是那边流水线里 apply 之前应有的一步。

前置要求

读过《Docker 应用课》，尤其是 03（多阶段与健康检查）与 06（信号与优雅停机）；
知道容器的镜像、端口、环境变量是怎么回事；
不需要有任何 K8s 集群，也不需要会写 YAML——本课的实验全部在离线构建与静态检查上完成，这也恰好是它最容易被跳过的部分。

实验环境说明

实测输出来自一台 Windows + kubectl v1.34.1（Kustomize v5.7.1）+ kubeconform v0.8.0 的机器，没有集群。

kubectl kustomize 是纯离线的：它把 base 与 overlay 合成最终清单，全程不连集群。本课所有"构建产物"都出自它；
kubeconform 用官方 JSON Schema 做单对象字段级校验（需要联网取 schema）；
配套的静态不变量脚本做跨对象检查（selector 能否选到 Pod、引用能否解析、预算是否自洽）——它不是官方工具，正文会说明它检查什么、以及它为什么也会误报；
集群内的实际行为（调度、探针判定、滚动过程、事件）没有实测，正文按官方文档写，并逐处标注。

Linux 集群上的绝对数值与你这里的会不同。请读输出里"哪个字段被改写、哪个判定被触发"，不要抄任何具体数字当阈值。

进入 keel 阅读