K3s

«结论先行：探针误杀不只有"GC 停顿"和"连接池死锁"两种根因，嵌入式场景下还有一种更隐蔽的——节点 eMMC 慢盘的 fsync 抖动，把探针 HTTP handler 阻塞在同步落盘上，响应时间冲过 "timeoutSeconds"（

背景 我维护一批 RK3588 边缘网关（4×Cortex-A76 / 4GB LPDDR4X / 8GB eMMC，标称 50k P/E），跑 K3s v1.31 + containerd 1.7.x，内核 5.10（cgroup v2）

背景 我维护一批 RK3588（4C A76 / 4GB）的边缘网关节点，跑 K3s v1.31 + containerd 1.7.x，内核是 5.10（cgroup v2）。业务侧是一个 Java 17 网关代理容器（request=li

背景 在 ARM Cortex-A53（2C4G，8GB eMMC）的边缘网关上跑 K3s v1.31 + containerd 1.7.x，业务是一个 Java 17（Temurin）网关代理容器：request=limit=2500Mi

一、现象：一台 4GB 节点，容器 limit 总和只有 2.8Gi，却一天被驱逐 6 次 先交代环境和数字。我们一批边缘网关节点：RK3588，4 核 Cortex-A76，4GB LPDDR4X，内核 5.10（cgroup v2），K

«结论先行：K8s 给容器设了「上限」（"memory.max"），但没给它设「下限」（"memory.min"）。cgroup v2 的 "memory.min" 是内核层面唯一能阻止全局内存压力回收某个 cgroup file cach

背景 我在做一批 ARM Cortex-A53（2C4G）的边缘网关，存储是 8GB eMMC（标称 50k P/E），上面跑 K3s v1.31 + containerd 1.7.x。业务镜像大概 180MB~350MB，每周有 2~3

先给结论：在 2GB 内存的边缘 ARM 节点上跑 Kubernetes，最大的坑不是"起不来"，而是 kubelet 的内存驱逐（eviction）阈值和 cgroup v2 的内存统计口径不一致，导致容器"看着有内存却被 OOM/驱逐"