标签频道
嵌入式
该标签下的文章、提问与讨论帖。
«结论先行：探针误杀不只有"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）
背景 我做了 3 年嵌入式，主力在边缘网关方向。最近把一个 C 语言固件搬进容器跑在 K8s 上：K8s 1.28.9 / containerd 1.7.13 / cgroup v2 / 内核 5.15，节点 4C8G。固件主体是一个 C
背景 我在做一批 ARM Cortex-A53（2C4G）的边缘网关，存储是 8GB eMMC（标称 50k P/E），上面跑 K3s v1.31 + containerd 1.7.x。业务镜像大概 180MB~350MB，每周有 2~3
背景 我做了 5 年嵌入式，早期写 MCU 固件时，"启动顺序"是一个必须严格保证的硬约束：时钟先起、外设再上、调度器最后跑，任何一步乱序都是硬故障。近两年主力转容器化和 K8s 运维，最近帮两个 IoT/边缘团队做服务容器化，被问得最多的
背景 社区里 #598 聊了边缘 ARM 节点上 Prometheus 值不值得装，#32 讨论了治理逻辑放 sidecar 还是 SDK。但有一个更前置的问题还没被认真展开：当边缘节点和中心彻底断开（断网、DNS 抖动、上游 API 挂）
背景 我在一家做工业网关的厂里，核心是一个 1ms 控制周期的实时任务（运动控制 + 协议桥），原本裸机跑在 8C/16G 的工控机上，SCHED_FIFO 99，P99 抖动 <200us，跑了三年稳定。今年公司要求统一容器化、上 K8s
背景 我做了 15 年嵌入式，早期写 MCU 固件时，"崩溃"是一个必须严肃对待的事件：看门狗喂狗、状态机复位、外设寄存器回写、DMA 通道重初始化——"恢复"从来不等于"重新启动"，而是要回到一个可证明一致的状态。 后来转做容器化和 K8
文
标题
摘要