容器化

背景 我做了 5 年嵌入式，早期写 MCU 固件时，"启动顺序"是一个必须严格保证的硬约束：时钟先起、外设再上、调度器最后跑，任何一步乱序都是硬故障。近两年主力转容器化和 K8s 运维，最近帮两个 IoT/边缘团队做服务容器化，被问得最多的

【背景】 我们团队管着 3 个 K8s 集群（阿里云 ACK、自建 3 节点、客户私有化），200+ 微服务。过去两年，「CPU limits 到底设不设」在三次架构评审里被反复吵，每次结论都不一样。今天想把它摊开，听听大家真实生产里的做法

«结论先行："docker run --memory" 限的是物理内存（RSS），而 "ulimit -v" / "RLIMIT_AS" 限的是虚拟地址空间（VA）——两者是两条完全独立的预算线。绝大多数「明明给了 8G 内存、进程却 "C

背景 我维护一个 8 节点（32C128G，K8s 1.28.9，containerd 1.7.13，cgroup v2）的生产集群，上面混跑 Java 微服务、Go 网关和一个 Flink 流计算作业。最近两次节点磁盘（/var/lib/

背景 10 年 SRE，最近接手一个 12 节点集群（Kubernetes 1.28.4，containerd 1.7，cgroup v2，内核 5.15，x86_64）。集群里有一个 C++ 写的二进制协议网关（非 Go/Java，gdb

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

背景 我在一个 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 批量导入周期

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

背景 我在一家做工业网关的厂里，核心是一个 1ms 控制周期的实时任务（运动控制 + 协议桥），原本裸机跑在 8C/16G 的工控机上，SCHED_FIFO 99，P99 抖动 <200us，跑了三年稳定。今年公司要求统一容器化、上 K8s

背景 我做了 15 年嵌入式，早期写 MCU 固件时，"崩溃"是一个必须严肃对待的事件：看门狗喂狗、状态机复位、外设寄存器回写、DMA 通道重初始化——"恢复"从来不等于"重新启动"，而是要回到一个可证明一致的状态。 后来转做容器化和 K8

【背景】 我做了 5 年嵌入式，近两年主要精力放在容器化和 K8s 运维上。最近带新人做集群扩容时，被问得最多的一句话就是："requests 和 limits 到底填什么？" 我发现社区里对这件事的分歧非常大，甚至同一家公司内不同团队的做

结论先行 探针不是「加上就对了」，而是「加错了就是故障放大器」。liveness 决定重启、readiness 决定流量、startup 决定冷启动窗口——三者职责完全不同，最常见的事故是把 startup 该干的事丢给 liveness，