大规模容器化部署的资源隔离依赖内核级机制而非kubernetes配置，核心是cgroups+namespaces+调度器协同；cpu需调优cfs参数与实时调度，内存须用cgroup v2分层控制，网络要结合tc/ebpf深度介入，io应规避inode与page cache争抢。
大规模容器化部署的底层资源隔离，核心不在上层配置，而在 Linux 内核如何把 CPU、内存、网络、文件系统这些资源真正“切开”并稳住。Kubernetes 的 limits 和 requests 只是声明，真正执行的是内核——靠的是 cgroups + namespaces + 调度器协同工作。优化的关键，是让这三者在高密度、多租户场景下不打架、不抖动、不误杀。
CPU 隔离：别只设 limit，得调 CFS 组调度参数
单纯设置 cpu.limits 容易导致节流抖动，尤其在突发负载下。根本原因是 CFS 默认时间片（sched_latency_ns）和最小粒度（sched_min_granularity_ns）不适合容器密度高的环境。
- 降低
sched_min_granularity_ns到 2ms（默认 4ms），提升小容器调度响应性：echo 2000000 > /proc/sys/kernel/sched_min_granularity_ns - 关闭自动迁移（
sched_migration_cost_ns设为较高值），减少跨核切换开销：echo 5000000 > /proc/sys/kernel/sched_migration_cost_ns - 对关键服务容器启用
cpu.rt_runtime_us配合实时调度类（需CONFIG_RT_GROUP_SCHED=y），保障硬实时任务不被 CFS 抢占
内存隔离：防 OOM 不靠运气，靠分层控制
容器被 OOM Killer 杀掉，往往不是内存真不够，而是内核没看清“谁该让”——cgroup v2 的 memory controller 比 v1 更精准，必须用。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 启用 cgroup v2（挂载点
/sys/fs/cgroup），关闭 v1 兼容模式，避免双控制器冲突 - 设置
memory.high（软限）而非仅memory.max（硬限），让内核提前回收 page cache，避免突刺触发 OOM - 调低
vm.swappiness=1（非 0），保留 swap 作为最后缓冲，防止因 page cache 回收过激引发 I/O 飙升 - 监控
memory.events中的low和high事件，比看usage更早发现压力苗头
网络隔离：命名空间要配 tc + eBPF，不能只靠 iptables
纯 namespace 提供逻辑隔离，但带宽、连接数、延迟控制还得靠内核网络栈深度介入。
- 每个 Pod 网络命名空间内，用
tc cbs或tc fq_codel做出口整形，防单个容器打满网卡 - 用 Cilium 或 eBPF program 替代 iptables，实现连接跟踪、限速、策略校验全在内核态完成，避免上下文切换损耗
- 调大
net.core.somaxconn和net.ipv4.tcp_max_syn_backlog，配合应用层连接池，撑住瞬时建连高峰 - 对高优先级服务，绑定到独立 netns + 单独网卡队列（RSS），绕过共享 softirq 处理瓶颈
IO 与文件系统：避开 inode 和 page cache 争抢
容器密集写日志或临时文件时，常卡在 inode 分配或 dirty page 回写，这不是磁盘慢，是内核锁竞争。
- 用
df -i监控 inode 使用率，overlay2 在大量小文件场景下易耗尽，可改用zfs或btrfs存储驱动 - 限制容器 writeback 行为：
echo 5 > /sys/fs/cgroup/<path>/io.max</path>（cgroup v2），防脏页堆积拖垮整机 - 对只读镜像层启用
overlay2.override_xattr=1，减少 xattr 操作锁开销 - 关键服务挂载 tmpfs 作日志目录，避开 ext4 journal 锁竞争
