线上 Pod 明明 Running,流量打进去却报 502;或者应用启动慢,还没起来就被 K8s 反复杀掉重启,陷入 CrashLoopBackOff。这两类问题十有八九是探针没配对。Kubernetes 有三种探针:liveness、readiness、startup,名字相近但职责完全不同,配错了比不配还糟。这篇讲清楚每种探针管什么、什么时候用、怎么配。

你有没有遇到过这种情况:一个 Go 或 Node 服务,代码没多少,打出来的镜像却一两个 G,推到镜像仓库慢、拉到生产环境也慢。问题几乎都出在——。这篇用一个 Go 服务和一个前端项目为例,讲清楚多阶段构建(multi-stage build)怎么把镜像体积砍掉 95% 以上,以及几个能进一步压榨体积、还能加速构建的实战技巧。

流量高峰手动加 Pod、低谷手动减,是很多团队的日常。HPA(HorizontalPodAutoscaler)本该把这事自动化,但真配上去往往遇到两个尴尬:要么 HPA 一直显示<unknown>根本不扩容,要么扩缩容像抽风一样反复横跳(flapping)。这篇从能跑起来到调稳,一步步来。

上线时一把梭,结果看到 Pod 卡在Pending十分钟不动。Pending 意味着调度器(scheduler)还没给这个 Pod 找到能落脚的节点,或者找到了节点但容器还没起来。它和(起来了又崩)是两码事——Pending 是。这篇按「怎么定位 → 五类常见原因 → 每类怎么修」的顺序,给一套能照着敲的排查流程。

你部署了一个服务,显示全是Running,可另一个 Pod 里就是超时或 connection refused。日志没报错、探针也过了,偏偏请求进不去。这类问题最耗人,因为「Pod 是好的」这个假象会把你引向错误方向。这篇按数据流的顺序,一层一层把断点找出来。

你的 Go 服务在物理机上跑得好好的,一上 Kubernetes,同样的负载 CPU 却莫名被限流(throttling),P99 延迟飙高,GC 也变频繁。GOMAXPROCS。这篇讲清楚它为什么在容器里会算错,以及怎么一行修复。

定时任务谁都写过——数据库备份、清理过期文件、每小时同步一次报表。搬到 K8s 上,很多人直接照着文档抄一个 CronJob YAML,跑起来看着挺好,直到有一天出事:上一次备份还没跑完,下一次又启动了,两个进程同时写同一个文件把数据搞坏了;或者任务失败后疯狂重启,一晚上拉起几百个 Pod。这些坑都不是 K8s 的 bug,而是几个关键字段没配对。这篇把 CronJob 最容易踩的三块——并发策略

在 K8s 上部署过几个服务后,你大概率遇到过这个场景:测试环境和生产环境的 Deployment 几乎一模一样,只有镜像 tag、副本数、域名不同。于是你复制了一份 YAML,改几个字段,结果两份文件慢慢就漂移了——生产上加了个环境变量忘了同步到测试,某次故障排查半天才发现两边配置根本对不上。Helm 就是来治这个病的:把 K8s manifest 变成带变量的模板,不同环境只维护一份「差异值」

你有没有遇到过这种线上事故:运维半夜给节点打补丁,一执行,某个服务的三个副本恰好都在这台节点上,瞬间全被驱逐,服务直接 502 了几十秒。或者集群自动缩容,一次性下线两个节点,把一个只有两副本的服务同时干掉。这类问题的共同点是:Pod 数量在你眼里「够用」,但在「自愿中断」发生时缺乏保护。Kubernetes 的 PodDisruptionBudget(PDB,Pod 中断预算)就是给这类场景兜底

改一行代码,却把整个重新跑一遍,等上几分钟才出镜像——这是几乎每个团队都遇到过的痛。问题不在网速,而在 Dockerfile 没写对,把缓存全废了。这篇从缓存原理讲起,把三个立竿见影的提速手段——层缓存顺序、BuildKit 缓存挂载、——一次讲清,配可直接抄的 Dockerfile。