Kubernetes

背景 我负责一个核心查询服务：Spring Boot 3.2 + JDK 17.0.10（G1，"-Xmx4g -XX:MaxGCPauseMillis=50"）+ MySQL 8 + Redis 7，K8s 1.28.4 / contai

«结论先行：容器里 "pids.max" 撞墙，是一种没有「软阶段」、撞了直接拒绝 fork、且监控基本看不到的隐形杀手。CPU limit 会节流、memory limit 会 OOM，而 pids 撞墙时 CPU 和内存全绿、"dmes

背景 过去五年 K8s 从"容器编排方案之一"变成了"容器编排的默认解"。我见过不少团队的姿态是：只要跑容器，第一反应就是上 K8s——哪怕只有 5 个服务、3 台机器、没有跨集群诉求、没有复杂发布流程。 但热榜上「集群粒度」「要不要上 I

背景 我在给一套工业数据网关做容器化。网关里有个高吞吐转发进程（C++，自研 epoll 内核），我们想升级到 io_uring 走异步 IO，目标是单核从 ~24k QPS 提到 60k+。同一个二进制在裸机（节点内核 5.15.0-91

一、现象：RSS 没到 limit，P99 却从 40ms 涨到 220ms 上个月（10 月），线上一个 Java 17 服务（Spring Boot 3.2.5，K8s 1.28.9 + cgroup v2，单 Pod 4C/2Gi），

【背景】 我在给一套 K8s（1.28.9，containerd 1.7.x）做安全加固复盘，发现一个普遍隐患：大量 Pod 默认挂载了 ServiceAccount token（/var/run/secrets/kubernetes.io

背景 12 节点集群（16C64G，Kubernetes 1.28.9，containerd 1.7.13，内核 5.15），日志链路是：业务容器 stdout 走 containerd 的 json-file 驱动（"--log-opt

背景 我在一个 12 节点（16C64G，Kubernetes 1.28.4，containerd 1.7.13，cgroup v2，内核 5.15）的生产集群上跑一套 Java 17（OpenJDK 17.0.9）的无状态订单服务。每个

先讲结论：容器里的 "/dev/shm" 是一块默认 64MB、报错还会伪装成"磁盘满"的隐形共享内存。它既不属于磁盘问题，也不属于 memory limit 问题，是第三条独立的内存预算线。这篇文章复盘一次 Postgres 批量导入周期

«结论先行：一批「网络看起来很好、下游服务也没抖、但 P99 就是会周期性飙高」的故障，根因常常不在网络，而在应用每次新建连接都在同步等一个「电话簿」翻完。这篇文章复盘一次真实的 P99 长尾排查，从「以为是网络」一路挖到 "resolv.

背景 过去两年，几乎所有我接触的云原生团队都在评估 Karpenter，最常见的结论是：「比 CA 快、比 CA 灵活、直接换掉」。我自己在 3 个不同规模的集群（8 节点 / 40 节点 / 200+ 节点）里都做过 CA → Karpe

背景 我在一个 24 节点的 K8s 1.28 集群上跑一套 Go 1.21 的实时行情计算服务，节点规格是双路 32C（Intel 8358，2 个 NUMA node，每个 16C）/128G/512G NVMe，containerd

一、现象：凌晨 03:12，一台 32G 节点 40 秒内 evict 了 3 个 Pod，死的不是"最重"的那个 上个月凌晨 03:00，我们电商集群一台 8C32G 的 worker 节点（K8s 1.28.9，containerd 1

【背景】 我做了 5 年嵌入式，近两年主力在容器化和 K8s 运维。最近帮两个团队做镜像安全加固，被问得最多的一句话就是："线上出了 segfault / 内存越界，镜像里连 gdb 都没有，怎么查？" 热榜上有探针、OOM、资源声明的讨论

【背景】 我维护一个 8 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2，100GB 系统盘）的生产集群，CNI 是 Calico 路由模式。最近 2 个月节点磁盘压力明显上来

背景 我在一个 12 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v1）的生产集群上跑一套 Java 17 / Spring Boot 3 的无状态订单服务。每个 Pod 里有

«结论先行：K8s 上有一类故障长得很像「服务挂了」，其实服务、Pod、Service 全活，只是节点的内核连接跟踪表（conntrack）满了——新连接被内核直接丢弃，已建连的长连接还能跑。它的特点是按节点分布、只影响新建连接、"kube

«结论先行："terminationGracePeriodSeconds" 的计时器从 Kubelet 开始执行停机（含 preStop）那一刻就启动了，preStop sleep 不是"额外加"的缓冲，而是从总窗口里"扣"掉的。当你 pr

背景 最近给一个 200+ Pod 的 K8s 集群做容量审计，发现一个很有意思的现象：同一个团队的 Java 服务，A 团队 limit=requests，B 团队 limit=2×requests，C 团队干脆不写 limit 只写 r

«结论先行：「这个镜像在 arm 节点上跑得好好的，为什么到了 x86 节点就 "exec format error" / 冷启动慢 6 倍」——根因几乎都不是应用代码，而是 manifest list 的多架构子镜像被拉错了，或者 bin