-
我的服务镜像一路膨胀到三四个 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
-
我的分布式服务时不时冒出莫名其妙的错——JWT 明明没过期却被判过期、跨节点的日志时间对不上、限流和缓存过期也乱套,排查半天才发现是集群里几台机器的时钟悄悄漂移了、各自的现在几点根本不一样的深度复盘
我有套分布式服务跑在好几台机器上,某段时间开始系统时不时冒出毫无规律又对不上号的错:有的用户带着明明没过期的 JWT 却被判令牌已过期、有的又用着本该过期的令牌畅通无阻;把几台机器日志按时间拼一起时间戳乱七八糟因果颠倒;基于时间的限流忽松忽紧、缓存有的提前过期有的迟迟不过期。这些错散落各处看着不相关,我查认证查缓存都没毛病。直到同时登上几台机器敲 date 才倒吸凉气:这几台机器系统时间各不相同,…- 0
- 0
-
我只改了一行业务代码,重新构建 Docker 镜像却要把几百个依赖从头到尾重装一遍、每次都等好几分钟,排查半天才发现是我 Dockerfile 里几行命令的先后顺序,把构建缓存几乎全废掉了的深度复盘
我有个服务用 Docker 打包,Dockerfile 写得朴实:先把整个项目代码 COPY 进镜像,再 RUN 安装依赖。日常开发越来越折磨:我哪怕只改一行业务代码,重新 docker build 都要把几百个依赖从头重装一遍、每次等好几分钟。依赖一个都没动凭什么每次重装?我以为是 Docker 慢、网络慢,直到研究 Docker 缓存机制才恍然:Docker 构建是分层的且带缓存,只要某层及其…- 2
- 0
-
我的服务器突然报磁盘空间不足、写不了任何文件,可我 df 一看磁盘明明还有一大半空闲,百思不得其解,排查半天才发现真正被耗尽的不是磁盘空间、而是一个我从来没关注过的东西——inode 的深度复盘
我有台服务器某天服务集体报错 No space left on device——写日志失败、创建临时文件失败、连 touch 一个新文件都失败,字面意思再清楚不过:磁盘满了。我赶紧 df -h 想清理,却懵了:磁盘空间明明还剩一大半、使用率才 40% 多,哪里满了?可系统就铁了心说没有剩余空间,任何创建新文件都失败。我一度怀疑磁盘坏了、文件系统损坏、权限问题,折腾好久没头绪。直到老同事提醒我 df…- 0
- 0
-
我的代码在测试环境跑得好好的,一上生产就行为不对、还报了测试环境从没出过的错,折腾半天发现是两个环境的某个配置和依赖版本不一致,而这种差异散落在一堆没人管的地方的深度复盘
我有个功能在本地和测试环境反复验证都正常,信心满满上了生产,结果生产上行为不对、还报了测试从没出现过的错。我对着完全一样的代码百思不得其解,折腾大半天才一个个揪出真凶:生产某个环境变量值不一样、某个依赖库版本和测试差了一个小版本、还有个配置项是某次有人 SSH 上生产手动改的没记录在任何地方。复盘才看清:一个程序的实际行为不只由代码决定,还由它运行的整个环境(环境变量、配置文件、依赖版本、运行时版…- 0
- 0
-
我的 Pod 部署上去就一直 CrashLoopBackOff 反复重启,我盯着它在不停重启这个现象查了半天毫无头绪,后来才知道要去看它崩溃那一刻的日志而不是它正在重启时的状态的深度复盘
我把新服务部署到 K8s,Pod 一直 CrashLoopBackOff:容器启动几秒就退出、被重启、又退出,反复循环,退避间隔越拉越长,服务始终起不来。我一开始盯着它在不停重启这个现象查:看事件、调重启策略、加资源、改健康检查,折腾半天毫无头绪。直到同事提醒:别盯着它正在重启看,要看它崩溃那一刻报了什么——用 kubectl logs --previous 看上一个已崩掉容器的日志。一看真相立刻…- 3
- 0
-
我的服务跑了几个月一直好好的,某天突然各种 No space left on device,数据写不进、健康检查失败,连同节点上别的服务一起遭殃,排查发现是日志文件没配轮转涨到了几十 G 把磁盘撑满了的深度复盘
我的服务一直把日志写到一个文件 app.log,平稳跑了好几个月。某天毫无征兆地一堆故障同时爆发:报 No space left on device、数据写不进、健康检查失败被重启,连同节点上别的服务也跟着遭殃。登机器 df -h 一看磁盘 100% 满了,du 一查祸首是 app.log——它悄悄涨到了几十 GB。复盘才意识到:我只关心了把日志记下来,却从没考虑日志写到哪、会涨多大、怎么清理;一…- 0
- 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
-
一个没有配置日志轮转的服务,把一个几十 GB 的日志文件一路写到磁盘爆满,然后整台机器上的服务集体瘫痪:一次磁盘写满的深度复盘
半夜告警:一台机器上彼此不相关的几个服务同时报错崩溃,有的报无法写文件、数据库报无法写入。df -h 一看磁盘 100%、No space left on device,du 顺藤摸瓜揪出一个几十 GB 的日志文件。根因是这个服务的日志从上线起就一直往同一个文件追加、从没配过轮转,跑大半年把磁盘写满;而磁盘是整机共享资源,一旦写满,同机器所有要写盘的服务、数据库、系统全遭殃。本文讲透日志轮转与磁盘…- 0
- 0
-
一个没有处理 SIGTERM 的服务,每次滚动发布都会硬生生掐断一批正在处理的请求,丢单又报错:一次优雅停机缺失的深度复盘
每次上线滚动重启,监控都准时出现一小撮 5xx 和超时,客服收到零星下单失败投诉,赶上高峰就放大成一大批丢单。根因是服务完全没做优雅停机:部署滚动更新时给老进程发 SIGTERM,而进程没捕获它,被立即终止或宽限期后 SIGKILL 强杀,正在处理的请求被硬生生掐断、连接没关、事务可能没提交。本文讲透优雅停机要解决什么和信号机制,给出捕获 SIGTERM、srv.Shutdown 停接新请求等存量…- 0
- 0
-
一个把 COPY . . 写在 npm install 前面的 Dockerfile,让我每改一行代码都要重装全部依赖、构建十几分钟:一次 Docker 层缓存与镜像瘦身的深度复盘
CI 构建每次十几分钟、镜像 2.3GB,折腾网络和机器都没用。逐行读那个用了快一年的 Dockerfile 才发现:它把 COPY . . 写在了 npm install 前面——源码一改,Docker 层缓存全失效,每次都重装几百个依赖;又没有 .dockerignore,把 node_modules/.git/日志全打进了镜像。本文讲透 Docker 层缓存机制与指令顺序的关系,给出先装依赖…- 0
- 0
-
我给容器设了 2G 内存上限,Java 服务却反复被 OOMKilled 重启,JVM 日志里还说自己堆远没满,我对着容器里的 JVM 不感知 cgroup 内存限制按宿主机内存设堆这个坑排查了大半天的复盘
一个让我对容器里的程序到底看到多少内存彻底搞明白的 DevOps 坑,抓狂在一个矛盾现象:容器被系统以内存超限 OOMKilled 杀掉,可 JVM 自己的监控却一脸无辜说堆还远没满,一边喊内存爆了一边说还多着呢。Java 服务部署 K8s 容器设内存上限 2Gi,Pod 反复重启 Reason=OOMKilled、Exit137、Restart Count 飙升;进容器看 JVM 说堆用得好好的…- 0
- 0
-
每次发版滚动更新都会冒出一波请求失败,我以为做了优雅停机,排查才发现应用根本没收到关闭信号,我对着 Dockerfile 用 shell 形式启动让 PID 1 吞掉 SIGTERM 这个坑排查大半天的复盘
一个让我对容器里进程怎么活怎么死彻底搞明白的 DevOps 坑,隐蔽在我明明以为做了优雅停机(应用里写了关闭钩子),发版时却总有一小波请求失败,而那个优雅停机逻辑像从没被触发过——收到的关闭信号在到达它之前就被吞掉了。每次滚动更新监控就冒出一小波 5xx,用户偶尔反馈操作失败。Dockerfile 用了 CMD java -jar app.jar(shell form)。深究才明白:容器里 PID…- 0
- 0
-
我只改了一行业务代码,Docker 构建却又把几百个依赖从头到尾重新下载安装了一遍,等了十几分钟,我对着 Dockerfile 里 COPY 顺序写错导致层缓存全部失效这个坑排查大半天的复盘
一个让我对 Docker 分层缓存机制彻底开窍的 DevOps 坑,它不报错不崩服务,却以温水煮青蛙的方式一点点偷走团队时间。服务用 Docker 打包,我写了个看起来再正常不过的 Dockerfile:FROM node:18、WORKDIR /app、COPY . .、RUN npm install、RUN npm run build。某天只改了一行业务逻辑,本以为重建很快,结果 docker…- 0
- 0
-
我本地跑得好好的代码一上生产就报错、复现不出来,排查发现是本地和生产环境差了好几处,我对着"在我机器上是好的"这个魔咒排查了大半天的复盘
每个程序员都说过也都被坑过的话:在我机器上是好的啊!我写的功能本地开发测试跑得稳稳当当,一发生产就各种诡异报错(功能挂/结果不对/偶发崩溃),最气人的是本地怎么都复现不出来。对着代码反复看逻辑没毛病,一度怀疑生产有鬼。排查大半天才发现问题不在代码,而在本地和生产环境差了好几处:依赖/库版本不同(本地2.5生产2.8 API变了)、环境变量配置不同、操作系统不同(本地Win/Mac生产Linux,路…- 0
- 0
-
我的服务一上容器,日志时间和入库时间全慢了 8 小时,定时任务也在半夜诡异触发,我对着这个差了 8 小时的时区问题排查了大半天的复盘
我的服务本地一切正常,一打包成容器上线,所有时间就比北京时间慢了整整 8 小时:日志下午3点的事记成上午7点、入库 created_at 全差8小时、本该凌晨2点的定时任务在上午10点诡异触发。深挖才懂:容器基础镜像默认是 UTC 时区,我没配时区,而本地开发机是东八区,所以本地碰巧对、一上默认 UTC 的容器就差8小时——程序取系统当前时间得到的是 UTC、比北京少8小时,所有依赖系统当前时间的…- 0
- 0
-
我的服务某天凌晨突然全线崩溃、各种写入都报错,登上去一看磁盘被日志撑到了 100%,我对着这个被日志活活塞满的硬盘排查了大半天的复盘
我的服务跑了大半年稳如泰山,某天凌晨突然全线崩溃:写文件、写数据库全失败,SSH 登录都卡。登上去 df -h 一看磁盘 100%、一字节不剩。du 一路找下去发现是日志目录占了 45G、单个 app.log 就 43G——我的服务一直往同一个日志文件追加、从没配过日志轮转和清理,一个文件写了大半年只增不减,终于撑爆磁盘;而磁盘一满,应用写日志、数据库写 redo/binlog、系统写临时文件、S…- 0
- 0
DevOps
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×