Kubernetes

背景 我在做边缘网关，核心是一个 C++ 控制/桥接服务，裸机跑 4C8G 工控机时 RSS 稳定在 120MB 左右，三年没崩过。今年统一容器化，落到一个 4C8G 的边缘 K8s 节点（1.28.9，containerd 1.7.13，

«结论先行：JDK 在容器里会「看见」宿主机的核数并据此派生 GC 并行线程数，但 Linux cgroup 只限制 CPU 用量、不限制 线程数——两者组合起来，会造出一个反直觉的故障模式：你给容器配的 CPU limit 越小，JDK

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

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

【背景】 我做了 5 年运维，目前维护一个 20 节点（32C128G，Kubernetes 1.27 + containerd 1.6）的集群，上面跑着约 200 个无状态微服务。日志链路是：容器 stdout → fluent-bit

一、现象：一次常规发布，2 个 Pod 卡 Terminating 90 秒，用户侧 3 个请求 502 上周三下午 15:40，我们给一个 Go 服务（Kubernetes 1.28.9，containerd 1.6.24，Deploym

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

背景 15 年嵌入式出身，现在带一个 Go 1.22 的数据清洗服务（K8s 1.28.6 / containerd 1.7.13 / cgroup v2 / 内核 5.15，节点 16C64G）。服务每天凌晨跑批，从 NFS 拉一份 1.

一、现象：批量下线 4 个命名空间，600 多个 PVC 集体僵死 先交代规模和现场。Kubernetes 1.28.9（containerd 1.7.4，120 台 worker，8C16G），业务侧用我们自研的存储 operator "

背景\n\n我们一个 Java 服务（JDK17，Spring Boot，启动要预热，正常冷启动大约 45–60s），跑在 K8s 1.28 上，4 副本，maxUnavailable=0、maxSurge=1，走滚动发布。发布走 CI 直

【背景】 我负责一个交易清算服务，K8s 1.28（containerd 1.7），gRPC 1.60（Netty 4.1.100），Java 17。上游 6 个微服务通过 gRPC 调用清算服务，服务 4 副本（Deployment，ma

【背景】 我们用 RocketMQ 4.9.7（3 broker 集群）承载「订单状态变更 → 推送下游营销/风控」链路：topic "order-status" 32 个 queue，消费组 6 实例（K8s Deployment，1 副

背景 做了 10 年嵌入式，早期写 MCU 固件时"健康"这件事是被看门狗强制定义的：主循环喂狗成功 = 活着，喂不上 = 复位。边界极其干净——只看"进程/主循环还在不在跑"，不替它检查外设寄存器、DMA、总线有没有挂。 搬到容器化之后，

【背景】 我负责一套 K8s 1.29（containerd 1.7）集群上约 40 个微服务的镜像安全加固。CI 流水线已接入 Trivy 扫描，策略是"无 CRITICAL 方可发布"。基础镜像统一用 eclipse-temurin:1

背景 我维护一个 14 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15，100GB 系统盘，Calico 路由模式）的生产集群，跑 Java 17 + Go 的

背景 我在一个 12 节点（16C64G，K8s 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15，Calico 路由模式）的生产集群里混跑 Java 17 微服务和一个 Flink 作业。节点上 kub

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

背景 我在一家中型公司带云原生平台组，集群规模从 30 节点长到 120 节点，业务方从 2 个团队长到 11 个。集群本身没出过大故障，但人和边界的问题越滚越大，最近三个月集中爆了三类矛盾，我越想越觉得这是个没有标准答案、但每个 K8s

背景 我在一个 12 节点（4C8G，cgroup v2，K8s 1.28.9，containerd 1.7）的集群上跑一套电机控制闭环，控制周期 5ms，硬实时要求 P99 ≤ 10ms。业务 Pod 用 cpuset 静态绑定 2 核，

结论先行 K8s 里有一类事故，"kubectl rollout status" 一路绿灯、"kubectl get pods" 全 "Running"、监控指标也正常，但同一份 Deployment 在不同节点上跑的根本不是同一个二进制。