🐳 Docker：理想中的“集装箱”

Docker 的承诺很美好：我把环境打包成一个盒子（镜像），你不用管服务器是 Linux 还是 Windows，直接跑盒子就行。

动作	代码行数 (理想状态)	描述
打包	1 行	docker build -t my-app .
运行	1 行	docker run -d my-app
结果	-	一次构建，到处运行 (Build Once, Run Anywhere)。

现实是： 你不仅要学 Linux 内核知识，还要学网络桥接，最后发现你打包的一个“Hello World”镜像竟然有 2GB 大。

---

🧅 第一关：洋葱的诅咒 (Image Layers)

Docker 镜像是分层的，像洋葱一样。这是新手最容易忽视的物理特性。

场景：
你写了一个 Python 脚本，只有 1KB。
你写了 Dockerfile：

1. FROM ubuntu:latest (基础层)
2. RUN apt-get update && apt-get install python3 (安装层)
3. COPY my_script.py . (代码层)
4. RUN rm my_script.py (你突发奇想删了它)

恐怖故事：
你以为第四步删了文件，镜像就变小了？
错！
Docker 的每一行 RUN 命令都会生成一个新的只读层。

• 第 3 层：文件还在，占空间。
• 第 4 层：标记该文件为“已删除”。
  结果： 镜像体积一点没变小，反而因为多了一层元数据变得更大了。这就像你在书上写了字，又用修正液涂掉——书变厚了，字还在底下。

后果：
运维咆哮：“大哥，你传个 1KB 的补丁，为什么要我拉取 800MB 的镜像？硬盘满了！”

---

🧟‍♂️ 第二关：PID 1 的僵尸 (Zombie Processes)

这是 Docker 独有的“生化危机”。

场景：
你在容器启动命令里写了：CMD ["/bin/sh", "-c", "python app.py"]。
你的应用跑起来了。

恐怖故事：
你的应用在处理并发请求时，生成了一些子进程。子进程干完活退出了。
过了一周，容器挂了，或者宿主机内存爆了。
你进容器一看：ps aux。
几千个 <defunct> (僵尸进程)！

原因：
在 Linux 系统里，只有 PID 1 进程（init 进程，如 systemd）有资格回收“孤儿僵尸进程”。
在容器里，你的启动脚本（或 Python）变成了 PID 1。
但是，普通的应用程序不具备回收僵尸进程的能力（它没有处理 SIGCHLD 信号）。
于是，死掉的子进程就像孤魂野鬼一样，永远占着系统资源，直到把容器撑爆。

防御手段：
必须使用 tini 或 dumb-init 这种专业的“保姆进程”作为容器的入口。

---

☸️ 第三关：Kubernetes (K8s) 的 YAML 地狱

如果说 Docker 是集装箱，K8s 就是那个全自动化、无人值守的超级码头。
理想： 它是谷歌级的基础设施，自动化扩容，自动化修复，永不宕机。
现实： 你变成了一个 YAML 工程师，每天在跟缩进和空格较劲。

场景：
你想部署一个简单的 Web 服务。
你需要写：

1. Deployment.yaml（定义怎么跑，跑几个）
2. Service.yaml（定义怎么在集群内访问）
3. Ingress.yaml（定义外网域名怎么转进来）
4. ConfigMap.yaml（定义配置文件）
5. Secret.yaml（定义密码）

恐怖故事：
你写错了一个空格（缩进）。
K8s 报错：error: error parsing deployment.yaml: error converting YAML to JSON。
它绝对不会告诉你是第几行错的。
你只能肉眼一行行数空格，或者把几百行的配置删得只剩一行来排查。

后果：
以前部署代码是写 Shell 脚本，现在部署代码是“绣花”（对齐缩进）。
一个简单的博客系统，配置文件的行数比源代码还多。

---

🔄 第四关：CrashLoopBackOff 的死亡螺旋

这是 K8s 运维最常见的噩梦状态。

场景：
你更新了代码，推送到 K8s。
Pod 状态显示：Running -> Error -> CrashLoopBackOff -> Running …

恐怖故事：

1. 容器启动了。
2. 容器里的代码报错了（比如连不上数据库，或者缺个环境变量）。
3. 容器退出了。
4. K8s 的逻辑： “哎呀，它死掉了？根据用户定义的 replicas=3，我必须把它救活！”
5. K8s 立刻重启容器。
6. 容器又报错退出了。
7. K8s 又重启……

后果：
如果你的应用报错原因是“数据库连接超时”。
K8s 的无限重启机制，会让你的应用瞬间变成一个 DDoS 攻击机。
每秒几十次重启，几百次尝试连接数据库。
结果： 应用没起得来，先把数据库彻底打死了，导致其他正常的服务也跟着挂了。

---

🔪 第五关：OOMKilled (隐形杀手)

场景：
你的 Java 应用在物理机上跑得好好的，内存 8G。
你把它搬到 K8s 上，限制了 Pod 内存 limit: 2G。

恐怖故事：
Java (JVM) 默认会根据宿主机的总内存来分配堆大小。
虽然你限制了 Pod 只能用 2G，但 Java 看到宿主机（Node）有 64G 内存，于是它豪爽地申请了 16G 堆内存。
K8s 监工（OOM Killer）： “小子，你越界了（超过 2G）。”
咔嚓！ 直接杀掉进程。

现象：
你的 Pod 总是莫名其妙重启。
没有报错日志！ 因为 JVM 还没来得及打印 OutOfMemoryError 就已经被系统层面的 kill -9 杀掉了。
你查了一周代码，都找不到内存泄漏点。

防御手段：
必须让 JVM 感知容器限制 (-XX:+UseContainerSupport)，或者手动设置堆大小 (-Xmx)。

---

💡 结论：复杂度的守恒定律

Docker 和 K8s 并没有消灭复杂度，它们只是转移了复杂度。

• 以前，你跟依赖做斗争（DLL Hell）。
• 现在，你跟镜像分层做斗争。
• 以前，你跟服务器配置做斗争。
• 现在，你跟 YAML 缩进做斗争。

为什么还要用它们？
因为当你的服务器从 1 台变成 1000 台时，你宁愿去写 YAML，也不愿去手动登录 1000 台服务器敲命令。
这是规模化的代价。