标签频道
cgroup-v2
该标签下的文章、提问与讨论帖。
结论先行 "GOMEMLIMIT" 是 Go runtime 的软性内存上限：它只是告诉 GC「尽量别超过这个水位」，而 cgroup 的 "memory.max" 是硬性物理页上限——两者之间隔着 goroutine 栈、cgo 分配、m
问
cgroup v2 memory.high 给存量 Java Pod 上「软限」怎么安全灰度：开启瞬间 reclaim 风暴 + JVM 堆已按 limit 定死，操作顺序、阈值与观测口径怎么定？
【背景】 K8s 1.28.9 + containerd 1.7.13 + 内核 5.15.0-91（cgroup v2），10 节点（16C64G）在线集群，主力负载是 Java 17 / Spring Boot 3.2 无状态订单服务，
背景 K8s 1.28.9 / containerd 1.7 / cgroup v2 / 内核 5.15，10 节点（16C64G）在线集群。一个 Java 17（Temurin 17.0.12）/ Spring Boot 3 无状态网关，
【背景】 做了 10 年嵌入式，后 5 年主力在容器化与 K8s 运维。资源调度这块我见过三个阵营，每次新人入职都要重新吵一遍，但每次吵完没有定论——因为答案取决于负载类型，而"取决于负载类型"这句话本身不够用。 我维护的集群：K8s 1.
【背景】 做了 5 年运维。社区里"OOMKill 事前预警盯哪个信号"已经聊透了：#1905 把 working_set/request、working_set/limit 的比值和 page cache 误报讲清楚了，#1777 进一步
背景 我维护一批 RK3588 边缘网关（4×Cortex-A76 / 4GB LPDDR4X / 8GB eMMC，标称 50k P/E），跑 K3s v1.31 + containerd 1.7.x，内核 5.10（cgroup v2）
背景 - K8s 1.28.9 / containerd 1.7.13 / 内核 5.15.0-91 / cgroup v2，10 节点（16C64G）在线集群。 - Java 17 / Spring Boot 3.2.5 无状态订单服务，
背景 我维护一批 RK3588（4C A76 / 4GB）的边缘网关节点，跑 K3s v1.31 + containerd 1.7.x，内核是 5.10（cgroup v2）。业务侧是一个 Java 17 网关代理容器（request=li
«结论先行：Go 服务在 K8s 里「limit 设了 4Gi 却被 OOMKilled」，根因几乎都是三层预算没对齐——① Go GC 的触发条件是 heap size（"runtime.MemStats.HeapAlloc" + spa
背景 K8s 1.28.4 / cgroup v2 / containerd 1.7.13 / 内核 5.15，跑 Netty 4.1.100.Final 的 Java 17 网关服务，Pod limit=4Gi，JVM 侧 "-Xmx2.
【背景】 - K8s 1.28.9 集群，cgroup v2，节点规格 32C256G - 核心 Java 17 服务（Spring Boot 3.2），12 个 Pod，每个 Pod memory request=4Gi / limit=
背景 我在一个 3 节点自建 K8s（1.28.9 + containerd 1.6.24，节点 16C64G，内核 5.15.0-91，cgroup v2）里把 etcd 拆到独立节点单独管，数据目录在本地 NVMe。业务侧 revisi
背景 我在一家做车规级域控制器的厂里，核心是一个 2ms 控制周期的实时闭环（电机 FOC + 通信协议桥），SLO 要求 P99 ≤ 8ms。硬件是 aarch64 ARM SoC（Cortex-A78AE × 4 大核 + Cortex
一、现象：同一个 1.2GB 文件，读一次 30ms，再读一次 2.5s，且反复横跳 先交代环境：K8s 1.28.9（cgroup v2，Ubuntu 22.04.4 内核 6.5），一个报表导出服务 Pod，规格 2C/2Gi，JVM
«结论先行：cgroup v2 的 "memory.high" 是一个「软限」（soft limit），它不杀进程，而是通过让内核在该水位下主动回收（reclaim）并施加「背压」（back-pressure，让进程在内存分配时主动 sle
【背景】 我在 K8s 上跑过 40+ 业务服务，踩过的最典型的坑有两个，恰好互相打架： - 一个没设 limits 的批处理服务，一次内存泄漏把整个节点 64G 吃光，node 上 7 个在线服务跟着被 OOMKill，告警一片红，根因却
结论先行 K8s 的 "resources.limits" 只覆盖 CPU 和内存，磁盘 I/O 是容器世界里最后一条「无人限流」的公共资源。两个容器共享同一块云盘时，批处理服务可以把 IOPS 吃光，在线服务被「饿」到写延迟翻 15 倍，
背景 我做了 5 年运维，最近半年在 K8s 1.29 + cgroup v2 + 内核 6.1 的集群上，被 CFS throttling 坑了不止一次。最典型的一次：一个 Go 报表导出服务（systemd 拉起，非 K8s），被批量「
文
标题
摘要