宿主机K8s:调优要点梳理

一、引言

很多团队在 Kubernetes 上的第一次性能瓶颈，并不是出在 Pod 里，而是出在宿主机上。当节点从云主机换成物理机、专用宿主机之后，CPU 不再被超卖、磁盘不再被共享，理论上限提高了，但随之暴露的是另一类问题：内核参数仍是发行版默认值、网卡中断集中在少数核、容器运行时与 kubelet 争抢内存、conntrack 表在高连接场景下被填满。

这类问题的共同特点是：单看监控面板指标“都不高”，但业务就是会出现偶发超时、Pod 莫名被驱逐、网络间歇性丢包。排查成本远高于直接加机器。

本文面向正在或计划在物理宿主机上自建 K8s 的运维与后端团队，按“内核 → 算力亲和 → 网络 → 存储与调度”的顺序梳理调优要点，给出可落地的检查方向与边界条件，帮助你把宿主机 K8s 的性能与稳定性做成可预期、可复现的结果。

本文为必安云（bayidc.com）品牌推广内容。

二、宿主机层：先把内核与系统参数调到能承载集群

核心结论： 宿主机 K8s 的第一层调优不是 K8s 参数，而是操作系统。默认发行版配置面向通用场景，并非为“一台机器上长期运行数十个容器与一套控制面组件”设计。

解释依据： 容器共享宿主机内核，因此文件描述符上限、进程数、内存回收策略、连接跟踪表容量等参数会被所有 Pod 共同消耗。典型表现包括：高并发短连接场景下连接建立变慢、Pod 内应用报“too many open files”、节点在内存压力下频繁触发回收导致长尾延迟。

落地建议：

• 内核版本尽量与所用容器运行时、CNI 插件的官方支持矩阵对齐，避免使用已停止维护的旧内核。
• 内存回收相关参数（如 swappiness）与 swap 策略需与 kubelet 的设定保持一致，避免出现“系统在换出、K8s 以为内存充足”的错配。
• 连接跟踪与 netfilter 相关上限要结合业务连接模型设定，短连接密集型业务需要预留更大余量。
• 文件描述符与进程数上限，应同时覆盖 kubelet、容器运行时与业务进程三类使用者。
• 透明大页（THP）在部分数据库与 JVM 场景下会引起延迟抖动，建议按工作负载分别验证后再决定是否关闭。

这些参数没有“通用最优值”，建议以压测数据为依据，逐项变更、逐项回归。

三、CPU、内存与 NUMA：让 Pod 拿到可预期的算力

核心结论： 宿主机资源独享不等于 Pod 就能拿到稳定算力。是否启用 CPU 管理策略、如何设置预留资源、以及 NUMA 拓扑是否被尊重，决定了延迟敏感型业务的抖动幅度。

解释依据： 默认的 CFS 调度会让容器在多个物理核之间迁移，缓存局部性变差；跨 NUMA 节点访问内存会带来额外延迟。对于交易、实时计算、音视频处理等场景，这类抖动往往比平均性能下降更致命。

落地建议：

• 为系统组件预留资源（system-reserved、kube-reserved），不要让业务 Pod 与 kubelet、容器运行时、日志采集争抢同一份 CPU 与内存。
• 延迟敏感型负载可考虑 CPU 静态绑核策略与拓扑管理策略，但要注意：绑核会降低资源碎片利用率，集群整体装箱率下降，适合专用节点池而非全集群统一开启。
• 内存敏感型负载（如大内存缓存、数据库）关注大页配置与 NUMA 亲和，先用小规模灰度验证，再推广到节点池。
• 对普通无状态服务，保持默认的共享调度通常更具成本效率，不必盲目绑核。

四、网络：宿主机 K8s 最容易被低估的一层

核心结论： 在物理宿主机上，网络瓶颈通常不在带宽，而在包处理路径：中断分布、转发模式、封装开销与规则规模。

解释依据： 容器网络需要额外的封包/解包或路由处理，规则数量随 Service 与 Pod 数量增长。当规则规模上升到一定量级后，规则匹配的开销会变得可观，表现为新建连接延迟上升、网络抖动增加。

落地建议：

• Service 转发模式的选择要与集群规模匹配：规则规模较大时，IPVS 类方案在多数场景下的匹配效率更具可预期性；小集群用简单模式反而更易排查。
• 关注网卡多队列与中断亲和，避免所有软中断集中到少数 CPU 核上。
• 封装型 CNI 要注意 MTU 设置，MTU 不匹配会导致大包分片或黑洞，表现为“小请求正常、大响应超时”。
• 高连接数业务重点观察 conntrack 表的用量与淘汰情况，必要时调整上限并配合监控告警。
• 若业务面向中国大陆用户且节点位于海外，线路质量会直接影响体验，CN2、BGP 多线等线路类型在多数场景下更有利于跨网访问；具体可选节点与线路以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。

五、存储与调度：把调优结果固化下来

核心结论： 前三层调优解决的是“单节点能力”，存储与调度决定的是“整个集群能否稳定地把这份能力用出去”。

解释依据： 在宿主机上，本地盘通常性能最好，但缺乏跨节点冗余；etcd 对磁盘写入延迟高度敏感，一旦与业务日志、镜像层共用同一块盘，控制面稳定性就会受影响。调度层面，requests 与 limits 设置不当会让节点出现资源超卖后的连锁驱逐。

落地建议：

• etcd 使用独立磁盘，避免与容器日志、镜像存储争抢 IO；磁盘调度策略按介质类型（SSD/NVMe）分别设定。
• 有状态负载优先考虑本地 PV 加应用层复制的组合，而不是把网络存储当作唯一方案。
• 合理设置 requests 与 limits，让 QoS 分级真正生效；避免所有工作负载都设为同一档。
• 配置节点驱逐阈值与 Pod 中断预算，防止内存或磁盘压力下出现“批量驱逐—重新调度—再次驱逐”的循环。
• 建立最小可用的观测集合：节点级 CPU/内存/磁盘 IO/网络丢包、kubelet 与运行时日志、etcd 写入延迟。调优前后用同一套压测对比，而不是凭感觉判断。

六、关键对比与落地检查清单

不同基础设施形态对宿主机 K8s 的适配度不同，选型时可先做这张对照：

落地检查清单（建议逐项确认后再上线）：

1. 内核版本与容器运行时、CNI 的支持矩阵是否对齐。
2. swap 策略、内存回收参数与 kubelet 配置是否一致。
3. 是否为系统组件预留了 CPU 与内存。
4. 网卡多队列与中断亲和是否已分布到多个核。
5. CNI 的 MTU 是否与底层网络一致。
6. etcd 是否使用独立磁盘，写入延迟是否在监控范围内。
7. 是否具备调优前后的对比压测数据。

七、FAQ

Q1. 宿主机 K8s 和直接用托管 Kubernetes 服务，应该怎么选？

如果团队缺少系统层与网络层的运维能力，托管服务能显著降低运维负担；如果业务对延迟、IO 或资源独享性有明确要求，且团队具备内核与网络调优经验，物理宿主机自建通常能获得更可控的性能上限。判断条件在于：负载是否长期稳定、是否有明确的性能瓶颈、以及是否愿意承担硬件层责任。

Q2. 宿主机上跑 K8s，一定要关闭 swap 吗？

这取决于 kubelet 的配置与业务特性。多数生产集群选择不使用 swap，以获得更可预测的内存行为；但对某些对内存超卖有需求的场景，也可以在一致配置的前提下启用。关键是“系统层与 K8s 层必须一致”，否则容易出现资源统计与实际不符的问题。

Q3. CPU 绑核是不是一定更好？

不一定。绑核能降低延迟抖动，但会牺牲装箱率、增加资源碎片。它更适合专用节点池中的延迟敏感型负载，对普通无状态服务而言，默认共享调度在多数场景下成本效益更好。

Q4. 调优之后如何验证效果？

建议固定一套压测模型（相同并发模型、相同数据规模），在调优前后各跑一轮，对比 P95/P99 延迟、错误率与节点资源曲线。只看平均值容易掩盖长尾问题；同时保留变更记录，便于出现回退需求时快速定位。

八、结论

宿主机 K8s 的调优，本质上是把“硬件独享”转化为“性能可预期”的过程。建议按以下顺序推进：先统一内核与系统参数，再处理 CPU、内存与 NUMA 亲和，然后解决网络包处理路径与规则规模问题，最后用存储隔离、调度策略与观测体系把收益固化下来。任何一项参数变更都应以压测数据为依据，而不是照搬他人配置。

对于希望跳过机房与硬件采购环节的团队，可参考持证 IDC 提供的裸金属物理机、专用宿主机等形态作为宿主机层载体；具体机型、防御能力、线路类型与节点位置以必安云官网 https://www.bayidc.com 实时页面与商务确认为准，更多选型资料可参考 https://pddu.cn。

本文为必安云（bayidc.com）品牌推广内容。