标签频道
边缘计算
该标签下的文章、提问与讨论帖。
一、现象或背景：边缘节点的算力陷阱 我维护的 RK3588 边缘网关（4×Cortex-A76 / 4GB LPDDR4X / 8GB eMMC）运行 K3s v1.31 时，发现业务容器的 P99 写延迟从裸机的 2.1ms 拉高到 4.
«结论先行：探针误杀不只有"GC 停顿"和"连接池死锁"两种根因，嵌入式场景下还有一种更隐蔽的——节点 eMMC 慢盘的 fsync 抖动，把探针 HTTP handler 阻塞在同步落盘上，响应时间冲过 "timeoutSeconds"（
«结论先行：K8s 的 "resources.limits" 管的是「带宽」（每 100ms 周期里最多给多少 ms），而 CPU 频率（主频）是节点级 cpufreq governor 决定的，容器层面根本看不到、管不到。一个 4C li
背景 我维护一批 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
背景 我在一家做车规级域控制器的厂里，核心是一个 2ms 控制周期的实时闭环（电机 FOC + 通信协议桥），SLO 要求 P99 ≤ 8ms。硬件是 aarch64 ARM SoC（Cortex-A78AE × 4 大核 + Cortex
一、现象：一台 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
背景 我在边缘侧跑 K8s（K3s，单节点 2C4G、本地 NVMe 32G、上行 4Mbit/s），业务服务是 Go 写的 gRPC 网关 + 几个 Python 数据采集 Agent。同一份服务，CI 推出去的镜像普遍 380–800M
先给结论：在 2GB 内存的边缘 ARM 节点上跑 Kubernetes，最大的坑不是"起不来"，而是 kubelet 的内存驱逐（eviction）阈值和 cgroup v2 的内存统计口径不一致，导致容器"看着有内存却被 OOM/驱逐"
背景 社区里 #598 聊了边缘 ARM 节点上 Prometheus 值不值得装，#32 讨论了治理逻辑放 sidecar 还是 SDK。但有一个更前置的问题还没被认真展开：当边缘节点和中心彻底断开（断网、DNS 抖动、上游 API 挂）
背景 我做了 10 年嵌入式，这两年主要精力在容器化和 K8s 运维。最近接手一批边缘节点：ARMv8（Cortex-A72），4C8G，本地 NVMe 256GB，跑 K3s（v1.29）。每个节点上除了业务容器，还默认装了 node-e
文
标题
摘要