-
我的服务镜像一路膨胀到三四个 GB 平时不觉得、直到一次大促要紧急扩容,新 Pod 卡在拉镜像上好几分钟才起得来扩容根本来不及救火,还把节点磁盘塞得告警,排查很久才搞懂我把一堆编译工具构建缓存整套基础系统全打进了最终镜像、交付物的体积本身就是一笔我一直没正眼看的成本的深度复盘
我的服务镜像不知不觉长到了三四个 GB,平时滚动更新慢点没在意,可一次大促流量暴涨需要紧急扩容时问题集中爆发:新调度到节点的 Pod 卡在 ContainerCreating/Pulling 状态好几分钟镜像没拉完容器起不来、等它就绪高峰都快过去了扩容根本来不及救火;调度到本地没这镜像的新节点要从仓库完整拉取三四个 GB 网络一波动更慢甚至超时;几个大镜像加各版本把节点磁盘吃告急触发磁盘压力驱逐;…- 6
- 0
-
我为了把节点塞得更满提高部署密度、把 K8s 里 Pod 的内存 requests 按平时用得很少往低了配想着一个节点能多跑好几个 Pod 省机器,结果平时风平浪静一到业务高峰几个 Pod 同时上量节点内存被打爆、我的服务 Pod 莫名其妙被打上 Evicted 状态杀掉重新调度,排查很久才明白 requests 是调度器分配资源的唯一依据我把它谎报低了等于骗调度器把节点超卖了的深度复盘
我们的服务跑在 Kubernetes 上,为了让集群利用率高一点少买几台机器,我配 Pod 资源时动了个聪明念头:看监控发现这些服务平时内存占用都不高,就把 resources.requests.memory 按平时低水位往小了写,想着 requests 写小了调度器就能在一个节点上多塞几个 Pod 省机器。上线后一段时间风平浪静,可一到每天业务高峰就出事:我的服务 Pod 时不时被打上 Evic…- 0
- 0
-
我给容器里的 Java 应用明明设了 2GB 的内存上限、也没配多大的堆,可它一加压就被 OOMKilled 反复重启,我对着监控看 JVM 堆用量百思不得其解,最后才搞懂这个老版本 JVM 根本不知道自己被关在了 2GB 的容器里它按宿主机那 64GB 内存算了个十几 GB 的最大堆的深度复盘
我把 Java 服务部署到 K8s、给容器设了 limits.memory: 2Gi,想着 2GB 够它跑、启动 JVM 也没特意配 -Xmx。低负载正常,可流量一上来负载一加压 Pod 就被 OOMKilled、重启、再被杀陷入 CrashLoop。我以为是堆不够或内存泄漏,可监控里 JVM 堆使用量还没涨多高就被杀;又怀疑 limit 设小了,可这服务物理机上撑死用一两 GB。直到进容器执行 …- 4
- 0
-
我给容器化的服务做了优雅停机、代码里明明监听了 SIGTERM 信号,可每次 kubectl 删 Pod 它都不优雅退出、非要硬等三十秒被强杀,我对着代码反复确认信号处理逻辑没问题,最后才发现根子在 Dockerfile 那行用 shell 形式写的 CMD、我的应用压根不是容器里的 1 号进程的深度复盘
我给容器化的服务做了优雅停机:收到停止信号时先停接新请求、把手头请求处理完、关好连接再退出,代码里老老实实注册了 SIGTERM 处理函数,本地手动 kill 进程完美触发。可部署上 K8s 后,每次滚动更新或 kubectl delete pod、Pod 都要卡足整整 30 秒才消失——正是 terminationGracePeriodSeconds 默认值,也就是 K8s 发了 SIGTERM…- 0
- 0
-
我的 Pod 部署上去就一直 CrashLoopBackOff 反复重启,我盯着它在不停重启这个现象查了半天毫无头绪,后来才知道要去看它崩溃那一刻的日志而不是它正在重启时的状态的深度复盘
我把新服务部署到 K8s,Pod 一直 CrashLoopBackOff:容器启动几秒就退出、被重启、又退出,反复循环,退避间隔越拉越长,服务始终起不来。我一开始盯着它在不停重启这个现象查:看事件、调重启策略、加资源、改健康检查,折腾半天毫无头绪。直到同事提醒:别盯着它正在重启看,要看它崩溃那一刻报了什么——用 kubectl logs --previous 看上一个已崩掉容器的日志。一看真相立刻…- 3
- 0
-
我给容器设了 CPU limit,监控上 CPU 用量明明远没到上限,服务却偶发严重的延迟尖刺和卡顿,查了半天才发现它一直在被悄悄节流:一次容器 CPU limit 与 CFS 配额节流的深度复盘
我的服务跑在 K8s 上,设了 limits.cpu: "1"。线上偶发严重延迟尖刺(P99 从 50ms 飙到几百毫秒甚至超时),可 CPU 监控显示用量只有 50%~60%、远没到上限,内存正常、GC 也不频繁,往网络/下游/GC 查了好几天都没结果。直到看了平时从不关注的 container_cpu_cfs_throttled 指标才恍然大悟:CPU limit 不是稳定…- 0
- 0
-
我那个每天凌晨两点的定时任务,上了容器后变成了上午十点跑,日志时间也全差了八小时,只因容器里的时区是 UTC:一次容器时区不一致的深度复盘
我有个定时任务配的是每天凌晨 2 点执行(挑业务低谷),本地和物理机一直好好的。上了容器(K8s)后运维发现它居然在上午 10 点左右跑(正好业务高峰),而且容器日志时间戳全比实际慢了 8 小时。进容器 date 一看才明白:多数基础镜像默认时区是 UTC,不是东八区——我配的凌晨 2 点被容器当成了 UTC 02:00 也就是北京时间上午 10 点,now()/日志取的也是 UTC 时间慢 8 …- 0
- 0
-
我的 Java 服务在容器里跑着跑着就被干掉重启,kubectl 显示 OOMKilled,可服务器明明有几十 G 内存,排查发现是 JVM 根本不知道自己被关在了一个小盒子里的深度复盘
我的 Java 服务跑在 K8s 里、给容器设了 memory limit 512Mi,可它跑着跑着就被杀掉重启,kubectl describe pod 写着 OOMKilled,而宿主机明明有几十 G 内存,JVM 自己也没抛 OutOfMemoryError。查到底才明白:JVM 没感知到容器的内存限制——它启动时按看到的机器总内存(宿主机几十 G,不是容器 cgroup 限制的 512Mi…- 0
- 0
-
每次滚动发布都有几分钟大量 502、半夜还莫名其妙被重启,我查到底才发现是 K8s 的就绪探针没配、存活探针又配得太敏感:一次健康检查探针配置失当、把自愈机制配成故障源的深度复盘
我们的服务跑在 K8s 上,出了两个看似不相关的问题:每次滚动发布都有几分钟接口大量报 502/连接被拒,以及有些 Pod 半夜莫名被 Killed 重启(没崩溃没 OOM)。查到底发现根因都在健康检查探针,且是两个相反方向的错:一是没配 readiness 探针,K8s 不知道 Pod 何时就绪、容器一启动就把流量打进来而应用还没就绪所以 502;二是 liveness 探针配得太敏感(time…- 0
- 0
-
一个 liveness 探针配置得又急又严、还去查下游的服务,在启动慢或下游抖动时被 Kubernetes 反复 kill 重启,陷入 CrashLoopBackOff:一次健康检查配置不当的深度复盘
服务部署后反复重启、状态 CrashLoopBackOff,可进到容器里看进程其实是活的、并没崩。根因是 liveness 探针配错:一是 initialDelaySeconds 太短,服务启动慢、还没就绪就被探测失败、被反复 kill;二是 liveness 端点去查了数据库/下游,下游一抖动健康检查就失败、把本来好好的服务也 kill 了。本文讲透 liveness(要不要重启,轻量只看进程自…- 3
- 0
-
一个没有处理 SIGTERM 的服务,每次滚动发布都会硬生生掐断一批正在处理的请求,丢单又报错:一次优雅停机缺失的深度复盘
每次上线滚动重启,监控都准时出现一小撮 5xx 和超时,客服收到零星下单失败投诉,赶上高峰就放大成一大批丢单。根因是服务完全没做优雅停机:部署滚动更新时给老进程发 SIGTERM,而进程没捕获它,被立即终止或宽限期后 SIGKILL 强杀,正在处理的请求被硬生生掐断、连接没关、事务可能没提交。本文讲透优雅停机要解决什么和信号机制,给出捕获 SIGTERM、srv.Shutdown 停接新请求等存量…- 0
- 0
-
我每次发布服务都有一两分钟大量 502、用户骂声一片,可实例明明都起来了,我对着 K8s 健康检查探针的配置排查了大半天的复盘
负责的一个跑在 K8s 上的服务,功能没问题,可每次滚动发布都有一两分钟大量 502/503,用户骂声一片,过一两分钟又恢复。一开始以为是发布的必然抖动,越想越不对:滚动发布不就是为了不中断吗?新实例起来才切流量啊怎么还502?排查大半天才理解 K8s 健康检查探针的门道和我没配 readiness 探针的致命疏忽:没配 readiness 时,K8s 只看进程起没起来判断就绪,进程一启动就切流量…- 0
- 0
-
我的 Java 容器上线后总是莫名其妙被杀、日志没有任何异常就直接退出 137,我对着 OOMKilled 和容器内存限制排查了大半天的复盘
把一个跑得好好的 Java 服务容器化扔上 K8s 后,它时不时无声无息地重启:应用日志干干净净、没有任何异常堆栈,进程就直接没了。直到 kubectl describe pod 看到 Last State: OOMKilled, Exit Code: 137,我才意识到不是程序崩了,是它被外面强杀了。排查大半天才搞懂根因:容器用 cgroup 把内存限制在 1G,但老版本 JVM 不感知容器、通…- 2
- 0
-
我的 Java 服务一上 K8s 就莫名其妙地被反复重启、退出码永远是 137,我对着 OOMKilled 这个状态和容器内存限制排查了大半天才搞懂的惨痛经历
我的 Java 服务在虚拟机上稳如老狗,一上 K8s 就反复重启,kubectl describe 显示 Reason: OOMKilled、Exit Code: 137。我给容器配了 4G limit、虚拟机上 4G 也够用,怎么会内存不足?深挖才懂:JVM 在容器里"看不见"cgroup 的内存 limit——容器 limit 是 4G 但节点宿主机有 64G,我没设 -X…- 0
- 0
-
我的容器三天两头被悄无声息地重启,exit code 137,应用日志里却啥错误都没留下,我查了好几天才发现是被内存限制 OOMKilled 的深度复盘
我的服务跑在 K8s 容器里,三天两头被悄无声息地重启,可应用日志里啥错误都没有——像跑得好好的突然被一闷棍打死。看容器状态才发现线索:exit code 137、Reason: OOMKilled。深究才懂:容器内存超过了我设的 memory limit,被 Linux 内核 OOM Killer 用 SIGKILL 强杀;SIGKILL 无法捕获、无法清理,所以应用没机会留下任何日志;137 …- 0
- 0
-
我每次发布服务监控就报一批 5xx,我一直以为是发布时正常的网络抖动,最后发现是 Pod 被杀时根本没做优雅停机、正在处理的请求被硬生生掐断的深度复盘
我的服务跑在 K8s 上滚动发布,每次发布监控都冒一批 5xx,我一直当成"发布时正常的网络抖动"没在意。可它每次必现、投诉变多,深究才知根本不是抖动:K8s 下线旧 Pod 时发 SIGTERM,而我的程序压根没处理这个信号——要么立刻退出、把正在处理的请求直接丢弃,要么被 SIGKILL 强杀;再加上 endpoints 摘除有延迟,Pod 关闭后还有新请求被误路由过来。我…- 0
- 0
-
服务一直在 CrashLoopBackOff,可它根本没崩——是 k8s 的存活探针,在它启动还没完成时就把它"杀"了的复盘
服务部署到 k8s 上一直 CrashLoopBackOff,起一下就被杀、重启,永远起不来。可查应用日志根本没有崩溃报错——它只是在正常但缓慢地启动(要 40 多秒)。describe pod 才揪出真凶:是存活探针把它"杀"了。我把 initialDelaySeconds 设成了 10 秒,服务才启动 10 秒、端点还不通,探针就来探测、连续失败、判定"死亡&qu…- 4
- 0
-
容器明明限制了 1G 内存,Java 服务却一上线就被 OOMKilled 反复重启:我在 Docker 里栽进 JVM 看不见容器内存限制的那次排查复盘
一个平时只用几百兆的 Java 服务,部署到限制 1Gi 内存的容器里,却一启动就 OOMKilled、陷入 CrashLoopBackOff。钻进容器一看,JVM 认为自己的最大堆是 8G——它读到的是宿主机 32G 物理内存、按 1/4 算出 8G,完全看不见 cgroup 给的 1G 限制。这篇从容器=隔离+限制的本质讲到 UseContainerSupport/MaxRAMPercenta…- 0
- 0
-
宿主机内存够却被 OOMKilled:容器 JVM 内存避坑
我们把一个 Java 服务容器化上了 K8s,给 Pod 配了 2GB 内存上限,本以为足够宽裕。可上线后容器三天两头重启,Pod 状态写得明明白白:OOMKilled、退出码 137。最费解的是这台宿主机有 64GB 内存空闲得很,进容器用 top、free 看显示的全是宿主机那 64GB 富得流油,可容器就是一次次以内存超限为由被处决。排查好一阵真相才浮出水面、经典得让人哭笑不得:我那个版本的…- 0
- 0
-
一次发布把服务全杀了:K8s 健康检查与滚动更新的坑
一次寻常的版本上线,滚动更新刚启动,Pod 就一个接一个跳进 CrashLoopBackOff,可用副本像退潮一样往下掉。可 exec 进容器手动 curl 健康接口明明是 200——没有一行业务代码出错,凶手是一段从别处抄来、从没认真理解的健康检查 YAML。从这次"配置杀人"事故出发,这篇文章把 liveness/readiness/startup 三种探针的区别、探针阈值…- 3
- 0
-
从粗放发布一个看似无害的小改动全量上线后因一个只在生产才触发的配置差异瞬间让所有用户白屏既无版本化旧制品又无一键回滚只能手忙脚乱翻找旧包 scp 覆盖全站不可用三十多分钟 + 本地手工 build 环境不一致包不可复现出了线上问题对不上是哪次构建产物根本无从查起 + scp 覆盖式部署新包直接盖掉旧包旧版本被销毁得无影无踪想回退连个可用旧制品都找不到 + 人肉点测全凭测试同学手点漏点了边缘功能带 bug 代码因无强制门禁就被合并上线 + SSH 登录到一台台机器凭记忆手工敲停服务传包覆盖改配置起服务的命令漏一步敲错一字多机不一致就酿故障还不可重复不可审计 + 一次性全量上线把新包往所有机器一覆盖所有用户同一瞬间切到新版本一有潜藏 bug 就同时对 100% 用户全面爆发无缓冲无试错损失即全员损失 + 出事才手忙脚乱满世界翻找旧包还可能已被覆盖没了再在火急火燎手抖中重做整套手工部署几十分钟全站瘫痪 + 配置散落各服务器各角落全凭 SSH 上去 vim 手工改改错没人拦改了没记录多机改得不一致诡异故障频发 + 开发测试生产环境各自手工搭野蛮生长成孤岛运行时依赖系统库版本处处不同在我机器上是好的一上生产就诡异崩溃 + 发布完看进程起来日志没刷红就以为成功转身忙别的错误率延迟悄悄劣化全然不知靠用户投诉报障才知翻车 → 2026 现代 CI/CD 流水线与发布工程 CI 统一环境自动构建 + 制品仓库版本化归档关联 commit 可追溯 + 自动化质量门禁编译测试覆盖率安全扫描全绿才许合 + 声明式部署描述期望状态工具自动收敛可重复可审计多机绝对一致 + 金丝雀渐进放量先 1% 验证再逐级加码蓝绿瞬时切换 + 历史制品归档加声明式部署让回滚一键确定性秒级退回稳定版本 + 配置即代码集中加版本化加评审加自动下发 + 容器化加 IaC 让开发测试生产环境处处一致铲除环境幽灵 + 发布与监控联动对比基线指标劣化即时告警自动回滚 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
8 人的平台工程团队 87 天把一套支撑几十个服务构建测试发布、五年里规模翻了几番、却一直停留在本地手工打包 scp 覆盖人肉点测 SSH 手敲部署全量上线靠用户报障原始阶段的发布体系——绝大多数构建还在开发各自机器上手工 mvn package 出包环境五花八门产物不可复现出了线上问题对不上是哪一次构建的哪个产物、部署还是把新包 scp 上去直接覆盖旧包旧版本被销毁得无影无踪想回退连个可用的旧制…- 0
- 0
-
从古老交付运维体系 手动 SSH 上服务器跑命令部署 + 在我机器上能跑物理机手装环境 + 手动管理进程没有编排 + 手点云控制台开机器无基础设施代码化 + 手改配置文件到处漂移 + 没有 CI 靠人肉构建测试 + 停机部署中断用户 + 出事手动翻日志手动回滚 + 没有监控告警靠用户打电话才知道挂了 + 密钥明文写在配置里 → 2026 现代云原生交付运维体系 容器化 Docker 统一环境 + Kubernetes 编排调度自愈 + Terraform/Ansible 基础设施即代码 + GitHub Actions CI/CD 流水线全自动 + 不可变基础设施 + 蓝绿与金丝雀零停机发布 + ArgoCD GitOps 声明式交付 + Prometheus/Grafana/Loki/Jaeger 可观测三件套 + Vault 密钥集中管理 + 自动回滚 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
14 位平台工程与 SRE 工程师 87 天把一套跑了七年的粗放交付运维体系——上线要手动 SSH 登服务器一条条敲命令、scp 传包改配置启动几十步全靠人记忆一步手抖就是事故、应用裸跑在机器上环境靠手装这台 JDK8 那台 JDK11"在我机器上能跑"一上线就挂、几十个进程靠人肉盯着挂了手动重启、服务器网络全在云控制台手点出来没人说得清线上有啥、配置手改到处漂移、没有 CI …- 0
- 0
-
从 物理机/裸 VM + 手工 SSH 部署 + Jenkins 自由风格脚本 + 无 IaC + 配置漂移 + 停机发布 + 回滚靠记忆 远古交付体系 → 2026 Kubernetes + 容器化 + Terraform IaC + GitHub Actions + ArgoCD GitOps + Argo Rollouts 金丝雀 + Prometheus/OpenTelemetry 全栈可观测 现代 DevOps 体系 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
15 位平台工程与运维工程师 87 天把一套跑了八年的物理机 + 手工 SSH 部署 + Jenkins 脚本堆砌远古交付体系,用绞杀者模式零中断重构到 2026 年现代 DevOps 体系:容器化消除环境差异 + Terraform 基础设施即代码 + GitHub Actions 声明式 CI + ArgoCD GitOps 让 Git 成唯一事实源 + Argo Rollouts 金丝雀指标…- 0
- 0
-
Kubernetes ArgoCD GitOps 一次 .gitignore 漂移导致误删 412 个生产 Deployment + 业务 5xx 飙到 73% 的 5 天复盘:SyncPolicy 保护 + Kyverno 拦截 + 全环境 diff + Argo Rollouts 灰度 6 套修法 + 12 条 GitOps 工程纪律
2026年2月,我们一组Kubernetes多集群平台(8个生产集群、64个namespace、3200个workload、ArgoCD2.10+Helm3.14+Kustomize5.4GitOps全栈)在一次"清理冗余资源"的合并PR后遭遇了灾难性的GitOpsdrift雪崩:ArgoCD自动sync删除了412个生产Deployment+1140个Service+86个P…- 2
- 0
Kubernetes
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×