Linux Kubernetes节点性能调优核心是合理约束、精准隔离、减少干扰：配置kubelet资源预留与驱逐阈值，优化内核参数（禁用THP、调低swappiness、启用cgroup v2），强制Pod资源限制，精简节点组件并禁用swap。
Linux Kubernetes 节点的性能调优，核心在于让节点更稳定、更高效地承载 Pod，同时避免因资源争抢导致调度失败、OOM Kill 或延迟飙升。重点不是盲目压榨硬件，而是合理约束、精准隔离、减少干扰。
合理配置 kubelet 资源预留
kubelet 需要为系统守护进程（如 sshd、udev、容器运行时）和 Kubernetes 自身组件（如 kubelet、kube-proxy、容器引擎）预留资源，否则 Pod 可能挤占关键服务内存或 CPU，引发节点失联或崩溃。
- 通过 --system-reserved 和 --kube-reserved 参数明确划分：例如
--system-reserved=memory=512Mi,cpu=500m，--kube-reserved=memory=1Gi,cpu=1 - 务必配合 --eviction-hard 设置硬驱逐阈值（如
memory.available），防止节点因内存耗尽直接触发 OOM Killer 杀掉随机进程 - 预留值需基于实际节点规格调整——4C8G 节点和 32C128G 节点的预留量差异很大，建议用
kubectl describe node观察 Allocatable 与 Capacity 的差值是否合理
启用内核级资源隔离与优化
默认 Linux 内核参数未针对容器密集场景优化，需主动调整以降低调度开销、提升内存回收效率。
- 关闭透明大页（THP）：
echo never > /sys/kernel/mm/transparent_hugepage/enabled，避免容器频繁内存分配触发 THP 折叠/分裂，加剧延迟 - 调高 vm.swappiness（如设为 1）：抑制内核将匿名页交换到磁盘，优先回收 page cache，更适合内存紧张但又需保留缓存的容器环境
- 启用 cgroup v2 并配置 systemd：确保 kubelet 启动时使用
--cgroup-driver=systemd，利用 unified hierarchy 实现更精确的 CPU、IO、内存控制
限制单 Pod/容器资源滥用
不设限的容器可能吃光节点资源，影响其他 Pod。必须通过 LimitRange + ResourceQuota + Pod spec 三级约束。
- 在命名空间中部署 LimitRange，为未声明 requests/limits 的 Pod 设置默认值（如默认 memory request=128Mi，limit=512Mi）
- 对关键业务命名空间配置 ResourceQuota，限制总 CPU/Memory 消耗上限，防止单个团队占用过多节点资源
- Pod 中显式声明 requests（决定调度）和 limits（决定 cgroup 约束），避免 limit 过高导致 CPU 被 throttled 却无感知，或 memory limit 过低频繁被 OOM Kill
精简节点组件与减少干扰
K8s 节点不是通用服务器，应尽可能卸载非必要服务，降低中断、IO、内存碎片等隐性开销。
- 停用并屏蔽非必需服务：如
firewalld（K8s 使用 CNI 插件管理网络策略）、NetworkManager（改用静态网络配置）、auditd（若无需合规审计） - 禁用 swap 分区（
swapoff -a并注释/etc/fstab中 swap 行）：K8s 不支持 swap，且启用后会导致 eviction 机制失效 - 使用轻量级容器运行时（如 containerd 替代 dockerd），减少守护进程层级与资源占用；定期清理已退出容器、 dangling 镜像和未使用卷
节点资源优化不是一劳永逸的事，需结合监控（如 node_exporter + Prometheus 查看 CPU steal、pgpgin/pgpgout、nr_throttled）持续验证效果。调优的关键是“可知、可控、可退”，每次变更都应有基线对比和回滚预案。
