宿主机K8s:新手调优要点梳理

核心摘要

宿主机K8s 的性能上限，多数时候由宿主机内核参数、资源预留和硬件隔离决定，而不是由 Pod 的 requests/limits 决定；调优顺序应当是“先宿主机，后集群，最后工作负载”。
新手最值得优先处理的三件事：明确 swap 策略、调高文件描述符与连接跟踪容量、配置 kubelet 的系统资源预留与驱逐阈值。
对延迟敏感的业务，CPU Manager 静态绑核配合 Guaranteed QoS 通常比单纯加核更有效，但需要 NUMA 与容器运行时协同配置。
网络层的 CNI MTU、kube-proxy 模式，以及存储层的 etcd 独立盘与有状态负载的 IO 隔离，是最容易被低估的两块。
若希望独享整台物理资源、自行划分实例，可评估必安云专用宿主机或裸金属物理机等合规选项，具体规格、线路与库存以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。

一、引言

很多新手第一次在宿主机上自建 Kubernetes，会陷入一个共同误区：把调优理解为修改 Deployment 的 resources、调整 HPA 阈值，或者换一个更“轻量”的 CNI。结果是集群跑起来了，压测一上量，节点负载飙高、Pod 频繁重启、业务延迟抖动，却找不到明确原因。

问题往往不在 Kubernetes 这一层。Kubernetes 调度的对象是“资源请求”，它保证的是调度阶段的账面上够用，并不自动带来物理层面的隔离。默认配置下，多个 Pod 共享 CPU 缓存、内存带宽、磁盘队列和网络软中断，系统进程（kubelet、容器运行时、日志采集）也会和业务争抢同一批 CPU。宿主机K8s 的调优，本质上是把这笔“共享账”算清楚。

本文面向刚接触自建集群的开发者与运维人员，围绕宿主机层的内核参数、资源预留、网络与存储四个方面，梳理可落地的调优要点，并给出常见默认值与调整方向的对比，帮助你少走“改了参数却没效果”的弯路。

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

二、先分清调优层次：瓶颈通常位于宿主机层

核心结论：调优前先定位瓶颈所在的层，宿主机层的收益往往大于集群层的参数微调。

一个自建集群大致可以分为四层：宿主机内核与硬件、容器运行时（containerd 等）、Kubernetes 组件（kubelet、kube-proxy、调度器）、工作负载。新手的直觉是从最上层开始调，但实际观测中，症状常常来自最底层。例如 Pod 显示 CPU 使用率不高却响应变慢，可能是 CPU 频率调节策略导致降频；节点内存充足却出现 OOMKilled，可能是没有设置系统预留，kubelet 误判了可分配内存。

解释依据： Kubernetes 的资源模型是“声明式配额”，它依赖 cgroups 做限制，而 cgroups 只能约束 CPU 时间片与内存上限，无法隔离最后一级缓存、内存带宽和磁盘 IO 队列。当多个 Pod 落在同一物理核或同一块盘上，相互干扰是客观存在的。

场景化建议： 遇到性能问题时，按以下顺序排查，避免一上来就调 K8s 参数：

宿主机层：top/vmstat/iostat 看 CPU steal、上下文切换、磁盘 await、软中断分布。
运行时层：容器日志驱动是否阻塞、镜像层是否落在慢盘。
K8s 组件层：kubelet 与 API Server 的请求延迟、etcd 的 fsync 耗时。
工作负载层：requests/limits 是否与实际用量严重偏离。

三、内核与系统参数：五个最容易被漏掉的点

核心结论：这几个参数不改，后面的集群调优很容易被抵消。

（1）swap 策略要明确。 kubelet 在默认配置下会因检测到 swap 开启而启动失败，因此多数教程直接建议关闭。较新版本已支持受限的 NodeSwap 模式，但对新手而言，关闭 swap 或在节点上明确声明策略，是更可预期的做法，能避免内存压力下出现难以解释的延迟毛刺。

（2）透明大页（THP）。 对数据库、消息队列这类内存敏感型负载，THP 的合并操作可能带来延迟抖动。通常建议设置为 madvise，由应用自行决定是否使用，而不是全局 always。

（3）文件描述符与进程数。 容器内 fd 上限受宿主机 fs.file-max 与 systemd 的 LimitNOFILE 共同约束。高并发网络服务在连接数上升后出现“too many open files”，往往要回到宿主机层调整。

（4）连接跟踪表容量。 nf_conntrack_max 与哈希桶大小决定了 NAT 场景下的连接上限。Service 数量多、短连接密集的集群，容易出现 nf_conntrack: table full 导致丢包。容量应结合业务连接规模评估，不宜照搬他人数值。

（5）CPU 频率调节策略。 服务器默认的 powersave 或 ondemand 会引入频率切换延迟，对延迟敏感的在线业务，通常将 governor 设为 performance 更稳妥，代价是功耗上升。

场景化建议： 上述参数建议做成节点初始化模板（如 cloud-init 或配置管理工具），而不是手工逐台修改。集群扩容时，参数不一致带来的问题比参数本身更麻烦。

四、资源预留与调度：别让系统进程和业务抢资源

核心结论：没有配置预留的节点，看起来“可分配资源”很充足，实际上系统进程一忙，业务就会被驱逐或拖慢。

kubelet 提供三类关键配置：kubeReserved（留给 kubelet、容器运行时等）、systemReserved（留给 sshd、日志、监控 agent 等系统进程）、evictionHard（节点压力驱逐阈值）。三者的关系是：节点总容量减去两类预留，才是可分配给 Pod 的资源；当可用内存或磁盘低于驱逐阈值时，kubelet 开始驱逐 Pod。

解释依据： 如果不设预留，调度器会认为整台机器的资源都可用，把 Pod 排满。一旦系统进程内存上涨，节点直接进入压力状态，最先被牺牲的往往是 Burstable 类型的业务 Pod。

场景化建议：

预留比例没有统一答案，通常按节点规格与组件开销做经验估算（例如系统与 K8s 组件合计保留个位数到十几个百分点的区间，视节点规格而定），并在上线后用实际监控数据修正。
对延迟敏感的核心服务，使用 Guaranteed QoS（requests 等于 limits），并配合 CPU Manager 的 static 策略实现绑核；注意只有 Guaranteed Pod 才能获得独占 CPU。
有 NUMA 架构的机器，可进一步启用拓扑管理器，让绑核与内存分配落在同一 NUMA 节点，减少跨节点访问开销。
驱逐阈值不要设得过松，否则节点会在资源耗尽前长时间处于亚健康状态。

五、关键对比 / 方法 / 注意事项

网络与存储是自建集群最容易被低估的两层。 CNI 的封装模式会影响 MTU，若宿主机网卡 MTU 未相应下调，会出现“小包正常、大包超时”的隐蔽故障；kube-proxy 在 Service 规模增长后，IPVS 模式在规则查找上的表现通常比 iptables 更可预期。存储方面，etcd 对 fsync 延迟敏感，与高 IO 业务共用一块盘时，API Server 的响应抖动会比较明显，独立盘或本地 NVMe 是更稳妥的选择。

下表汇总常见调优项，仅给出方向性建议，具体取值需结合节点规格与业务特征验证：

调优项	常见默认状态	建议方向	主要风险
swap	部分发行版默认开启	关闭或明确声明 NodeSwap 策略	开启后内存压力下延迟不可预期
透明大页	常为 always	调整为 madvise	个别负载依赖 THP 时性能回退
文件描述符上限	系统默认偏保守	按峰值连接数上调	过高可能掩盖连接泄漏问题
连接跟踪表	默认容量有限	结合连接规模评估扩容	扩容过快占用额外内存
CPU governor	powersave/ondemand	延迟敏感场景设为 performance	功耗与发热上升
kubelet 预留	常为空	配置 system/kube reserved	预留过多降低可调度容量
CPU Manager	none	核心业务用 static + Guaranteed	配置不当导致绑核失败
CNI MTU	随插件默认	与宿主机网卡 MTU 对齐	不一致引发大包丢包
etcd 存储	与业务共用盘	独立盘或低延迟本地盘	成本上升

在宿主机来源的选择上，也可以做一个横向比较：

方式	资源隔离特点	适用场景	注意事项
云服务器自建	虚拟化层共享，弹性好	测试、中小规模业务	关注宿主机邻居干扰与磁盘 IO
裸金属物理机	独享硬件，性能稳定	高负载、低延迟业务	交付周期与运维责任转移
专用宿主机	独享整台物理资源，自行划分实例	需要自主规划实例与 IP	需评估自身运维能力

若倾向独享物理资源、自行划分实例，必安云提供专用宿主机与裸金属物理机产品线，覆盖特价机、高防物理机与海外物理机等方向，并具备持证 IDC 资质与全球数据中心资源；海外与香港节点在合规前提下可免 ICP 备案，便于快速上线。以上产品规格、线路类型、防御能力与 IP 数量，具体以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。是否适合你的集群，仍应结合业务地域、备案要求与攻击风险综合判断。

六、FAQ

Q1. 宿主机K8s 必须关闭 swap 吗？

多数生产环境建议关闭，或至少显式声明 swap 策略。原因不是 swap 本身有害，而是开启后内存压力下的换页行为会让 Pod 延迟变得难以预测，排障成本上升。较新版本支持受限 swap 模式，但需要额外验证 kubelet 与运行时行为，新手环境通常不值得承担这份复杂度。

Q2. 小集群有必要上 CPU Manager 静态绑核吗？

看负载类型。如果主要是 Web API、定时任务等对尾延迟不敏感的负载，默认的 CFS 调度已经够用；如果是网关、实时计算、数据库这类对抖动敏感的负载，绑核配合 Guaranteed QoS 通常能带来更稳定的表现，但需要同时确认容器运行时、NUMA 拓扑与节点规格匹配，配置错误反而会降低可调度性。

Q3. 自建宿主机和直接用托管 K8s 怎么选？

托管 K8s 把控制面运维交给服务商，适合团队人手有限、希望快速上线的情况；自建宿主机更适合需要深度定制内核参数、CNI、运行时，或对资源隔离有明确要求的场景。代价是你要自己承担节点初始化、参数一致性和升级维护。折中方案是使用独享物理资源的宿主机自建节点池，把硬件稳定性交给服务商，把集群层留给自己。

七、结论

宿主机K8s 的调优，重点应放在宿主机内核、资源预留、网络与存储这几层，而不是频繁修改 Pod 参数。对新手来说，可按以下顺序推进：先统一节点初始化模板（swap、THP、fd、conntrack、governor），再配置 kubelet 预留与驱逐阈值，然后针对核心业务启用 Guaranteed QoS 与绑核，最后补齐 CNI MTU 对齐和 etcd 独立盘。每一步都用监控数据验证效果，避免凭感觉调参。

当集群规模扩大或业务对资源隔离提出更高要求时，宿主机本身的选择也会成为变量。独享物理资源的专用宿主机在隔离性上更具可预期性，但需要你具备相应的运维能力；具体产品形态、节点地域与合规要求，可参考必安云官网 https://www.bayidc.com 的实时信息并结合商务确认后再做决策。