Kubernetes 内部域名间歇解析超时:CoreDNS 缓存与上游 DNS 的排查实践
适用场景 集群中的应用偶发报出 lookup xxx on 10.96.0.10:53: i/o timeout、SERVFAIL 或连接外部服务失败;重试后又恢复。故障通常集中在业务高峰,Pod 重建、扩容或切换节点后更明显。本文适用于使用 CoreDNS 作为集群 DNS,且 CoreDNS 需要转发外部域名查询的
Tag
包含这个标签的文章。
适用场景 集群中的应用偶发报出 lookup xxx on 10.96.0.10:53: i/o timeout、SERVFAIL 或连接外部服务失败;重试后又恢复。故障通常集中在业务高峰,Pod 重建、扩容或切换节点后更明显。本文适用于使用 CoreDNS 作为集群 DNS,且 CoreDNS 需要转发外部域名查询的
Nginx 偶发 502 且上游日志正常:upstream keepalive 陈旧连接的排查与治理 适用场景 服务部署在 Nginx 反向代理之后,流量高峰或发布后偶发 502 Bad Gateway。Nginx 错误日志出现 upstream prematurely closed connection、recv()
适用场景 服务容器偶发或持续重启,docker ps -a 显示退出码为 137,应用日志末尾没有 Java、Python 或 Go 自己抛出的异常。宿主机看起来还有可用内存,但容器仍被杀掉;或者一次流量高峰后多个容器同时不可用。 本文以 Docker / Docker Compose 部署的 API 服务为例,说明如
适用场景 业务接口偶发返回 Deadlock found when trying to get lock(错误码 1213),订单、库存、账户余额或状态流转等事务写入失败;重试后通常成功,但高峰期错误数明显上升。本文以 InnoDB 为例,给出一套可在生产环境执行的取证、定位和治理流程。 死锁不是数据库“故障”:两个或
适用场景 应用报出 No space left on device,但 df -h 显示磁盘使用率不高;Nginx 无法写入访问日志、容器无法创建临时文件、CI 构建失败,甚至 touch 一个空文件也失败。这通常不是字节空间耗尽,而是文件系统可分配的 inode 已经用完。 本文以 ext4/XFS 主机为例,给出从
适用场景 服务运行正常,但在故障窗口里 journalctl 中恰好缺少应用最关键的一段日志;常见于 Java、Python、Nginx/OpenResty、容器运行时或短时间大量报错的 systemd 服务。运维人员往往把它误判为程序没有输出,实际日志可能已经被 systemd-journald 的限流机制主动丢弃。
适用场景 Linux 宿主机的根分区或 Docker 数据盘持续告警,/var/lib/docker/overlay2 占用不断增加;但镜像和容器数量并不多,普通镜像清理也没有效果。本文给出 overlay2 的归属定位、止血和治理流程。 以下路径以 /var/lib/docker 为例。先用 docker info
适用场景 使用 Celery + Redis/RabbitMQ 承担异步任务。队列中仍有大量待执行任务,但监控显示少数 Worker 忙碌、其余 Worker 空闲;或者短任务被长任务“压住”,整体延迟持续升高。本文以默认的 prefork 并发池和 RabbitMQ 为例,Redis broker 的排查思路相同。
适用场景 部署在 Kubernetes 中的 Web、API 或消费服务在高峰期 CPU 已长期接近上限,但 HorizontalPodAutoscaler(HPA)始终保持原副本数;也可能在 kubectl get hpa 中看到 CPU 显示为 <unknown>。本文以基于 CPU 利用率的 HPA 为例,给出一
适用场景 Linux 服务器上的 Java、Python、Go 或 Node.js 服务由 systemd 托管。发布后或依赖异常时,进程在几秒内连续退出;即使问题随后已修复,执行 systemctl restart 仍失败,状态显示为 failed,日志里出现 Start request repeated too q