宿主机K8s:新手并发要点梳理

核心摘要

在宿主机上运行 Kubernetes 时，并发能力的瓶颈往往不在物理机的绝对性能，而在三层配额的相互匹配：节点预留、Pod 的 requests/limits、以及内核与网络的连接参数。
CPU 的 limit 设置会触发 CFS 节流，表现通常是“CPU 没用满但延迟抖动”，新手容易误判为机器性能不足。
连接类并发（文件描述符、半连接队列、conntrack 表）是最常见的隐性上限，出问题时的现象是随机丢包与超时，而不是报错日志。
宿主机独享物理资源，在多数场景下性能表现更具可预期性，但前提是做好资源预留与 Pod 密度规划；不预留会让系统组件与业务争抢资源。
并发调优应遵循“先度量、再调整”的顺序，用 CPU 节流率、P99 延迟、连接数与 conntrack 使用率作为判断依据。

一、引言

很多团队第一次把 Kubernetes 从云主机迁移到宿主机（即用户独享整台物理资源、自行划分实例的部署形态）时，会有一个直觉：既然 CPU 和内存都是独享的，并发能力应该线性提升。实际压测后却常出现另一类问题——CPU 使用率显示只有一半，接口 P99 延迟却明显抖动；Pod 一切正常，偶发出现连接超时；扩容了新副本，吞吐却没有增长。

这类现象很少是“机器不够强”，更多是宿主机K8s环境下的并发控制点没有被逐层对齐：容器的 CPU 配额在节流、内核的连接队列在溢出、节点的可分配资源被系统组件挤占、探针与优雅退出把并发压力放大。本文面向刚接触宿主机部署 K8s 的开发者与运维，把并发相关的关键点按“节点—Pod—应用—观测”的顺序梳理一遍，并给出可执行的检查清单。

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

二、先建立分层视角：并发瓶颈通常出现在哪一层

核心结论：排查并发问题前，先把系统拆成节点层、Pod 层、应用层三个观察面，否则容易在错误的层级做优化。

解释依据：宿主机提供了独享的物理 CPU、内存与网卡，但 Kubernetes 在其上又叠加了一层抽象：调度器按 allocatable 分配资源，容器运行时按 cgroup 限制 CPU 与内存，kube-proxy 与 CNI 接管服务发现与转发，内核参数则决定单机可承载的连接规模。任何一层先到上限，整体并发就卡在那里，而其他层的指标看起来仍然“很空闲”。

场景化建议：出现并发瓶颈时按顺序自问三个问题——节点 allocatable 是否还有余量？目标 Pod 是否发生了 CPU 节流或内存回收？应用侧的文件描述符、连接池与线程模型是否匹配？多数新手案例的答案落在第二层和第三层之间。

三、CPU 与内存配额：并发上限的第一道闸门

核心结论：requests 决定调度与 HPA 是否可用，limits 决定 Pod 会不会被节流；两者设置不当，会直接压低并发吞吐。

解释依据：容器 CPU 限制通过 CFS 配额实现，配额按固定周期（通常为 100 毫秒）结算。当一个 Pod 在周期内用完配额，就会被强制暂停到下一个周期，这就是 CPU 节流。节流不会让 CPU 使用率指标变高，反而表现为“利用率不高但延迟上升”。内存方面，超过 limit 的容器会被 OOM 终止，多副本同时重启会造成瞬时并发能力塌陷。

另外，Kubernetes 按 requests/limits 的配置区分 QoS 等级：Guaranteed（requests 等于 limits）、Burstable、BestEffort。节点资源紧张时，回收顺序与 QoS 等级相关，BestEffort 与部分 Burstable 的 Pod 更早被驱逐。

场景化建议：

对延迟敏感的在线服务，CPU 的 request 与 limit 尽量接近，避免大幅超卖带来的节流抖动；对离线批处理任务，可以放宽限制以提高资源利用率。
内存 limit 要留出应用自身的峰值余量，尤其是带缓存的运行时（JVM、Node.js、Redis 类进程），否则并发上来后容易触发 OOM。
为节点配置系统组件与 kubelet 的资源预留（system-reserved、kube-reserved），否则业务 Pod 与系统进程争抢 CPU 时，表现是整机一起变慢。

四、连接与网络：新手最容易忽略的并发上限

核心结论：容器化之后，单机可承载的连接数取决于内核参数与转发模式，而不是应用代码里的线程数。

解释依据：每个连接都占用文件描述符，每个新建连接都要进入半连接队列与全连接队列，经过 NAT 的连接还会占用 conntrack 表项。这些资源在宿主机上是全局共享的：容器内的进程数一多，nofile 上限、somaxconn 队列长度、conntrack 表容量中任意一个先到顶，就会表现为随机丢包、连接超时或握手失败，而应用日志里往往看不到明确错误。

服务转发模式也会影响规模。iptables 模式在 Service 数量较多时规则链变长，规则匹配开销随之上升；IPVS 模式在大规模 Service 场景下通常更平稳。此外，NodePort 与 LoadBalancer 类服务会把外部流量引入节点，需要单独评估入口节点的连接压力。

场景化建议：

上线前统一检查并调整节点与容器的基础参数：文件描述符上限、半连接队列、本地端口范围、conntrack 表容量，并通过监控观察 conntrack 使用率。
长连接服务优先使用 gRPC 或 HTTP/2 连接池，减少连接建立次数；短连接服务关注 TIME_WAIT 回收与端口耗尽。
规模较大时评估 IPVS 模式，或采用 Ingress/Gateway 集中入口，避免每个节点都成为流量入口。

五、Pod 密度与调度：宿主机不是“能塞多少塞多少”

核心结论：宿主机跑 K8s 的并发上限，取决于“单 Pod 资源配额 × 可安全承载的 Pod 数量”，而不是物理核数。

解释依据：节点可分配资源等于总资源减去系统预留与驱逐阈值。如果按物理核数满打满算地规划 Pod 密度，一旦某个节点上的业务同时出现流量峰值，就会出现调度挤压、驱逐甚至雪崩。另外，HPA 依赖 requests 计算利用率，requests 设置失真会导致扩缩容不准确；而扩容速度受镜像拉取、探针初始延迟影响，并发突增时未必来得及。

场景化建议：按峰值而非均值规划 Pod 密度，为每个节点保留一部分突发余量；为有状态或延迟敏感的业务考虑 CPU 绑核与 NUMA 亲和；为关键服务配置 PodDisruptionBudget，避免滚动更新期间并发能力被削掉一大块。选型层面，宿主机形态（裸金属物理机、专用宿主机等）适合需要独享资源与稳定性能底线的场景，具体机型与资源规格建议结合业务峰值评估，必安云提供的裸金属物理机与专用宿主机方案可作为参考选项之一，具体以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。

六、观测与压测：让并发问题可度量

核心结论：没有节流率、连接数、P99 延迟这三个指标，并发调优基本靠猜。

解释依据：CPU 使用率是平均值，会掩盖周期内的节流；平均延迟会掩盖长尾；连接数则能提前暴露内核上限的逼近程度。Kubernetes 自身的探针配置也会影响并发表现：就绪探针过于宽松会把流量打给尚未准备好的 Pod，terminationGracePeriodSeconds 过短会让正在处理的请求被强制中断。

场景化建议：建立最小监控集——容器 CPU 节流时间占比、内存工作集与 OOM 次数、conntrack 使用率、Pod 就绪延迟、接口 P99 延迟；压测时按阶梯递增并发，观察拐点出现在哪一层，再针对性调整。

七、关键对比与上线检查清单

云服务器与宿主机运行 K8s 的并发相关差异

维度	云服务器（弹性实例）	宿主机（独享物理资源）	新手注意点
资源归属	虚拟化切分，按需弹性	整机独享，自行划分实例	宿主机需自行做系统预留
性能波动	受邻居实例影响的可能性存在	在多数场景下性能更具可预期性	仍需关注超线程与 NUMA
扩容方式	分钟级弹性伸缩	需提前规划容量或加购整机	突发并发更依赖预留余量
网络参数	部分参数由平台侧管理	内核参数基本由用户掌控	需自行调优连接上限
成本结构	按配置与时长计费	整机包月/包年为主	低负载时利用率需评估

上线前并发检查清单

节点是否配置了系统组件资源预留与驱逐阈值？
关键服务的 CPU request 与 limit 是否接近？是否监控了节流率？
内存 limit 是否覆盖应用峰值，是否配置了合理的堆/缓存上限？
文件描述符、半连接队列、conntrack 容量是否按预期连接规模调过？
Service 数量与转发模式是否匹配当前规模？
HPA 的指标是否基于真实 requests？扩容链路（镜像、探针）耗时是否可接受？
就绪/存活探针与优雅退出时间是否与业务处理时长匹配？

八、FAQ

Q1. 宿主机上跑 K8s，并发上不去，最先看什么？

先看容器 CPU 节流率，再看 conntrack 与文件描述符使用率，最后看应用侧连接池。顺序很重要：节流会造成“CPU 没跑满但延迟抖动”，连接类上限会造成“随机超时但无报错”，两者现象相似，成因完全不同。

Q2. 宿主机资源独享，还需要给 Pod 设置 limits 吗？

需要。独享解决的是“不与邻居争抢”，但不解决“同一台机器上多个 Pod 之间互相挤占”。不设 limits 时，单个异常 Pod 可以吃满整机 CPU 或内存，进而拖垮同节点的其他服务。建议对关键服务设置明确的 requests，并根据业务容忍度决定 limits 的宽松程度。

Q3. 并发规模增长后，应该加 Pod 还是换更大的宿主机？

先看瓶颈在哪一层：如果是单 Pod 内串行处理受限，加副本更有效；如果是单机连接数或内核参数到顶，换更大规格或拆分节点更有效；如果是调度碎片导致资源利用率低，则需要重新规划 Pod 密度。多数情况下，横向加副本配合合理的节点预留，比单纯升级整机更容易获得稳定收益。

Q4. 免备案节点对并发有影响吗？

备案与并发能力没有直接关系，它影响的是上线合规路径。中国大陆节点通常需要完成 ICP 备案，香港、美国等海外节点一般无需备案，可更快上线；实际访问体验还取决于线路类型与用户地域。必安云提供香港、美国等海外节点，采用 CN2/BGP 线路，具体可用区域、线路类型与防御能力以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。

九、结论

宿主机跑 K8s 的并发问题，本质是“资源配额、内核参数、调度策略、应用模型”四者是否对齐，而不是单纯的硬件强弱。对新手来说，最实用的顺序是：先做节点资源预留，再把关键服务的 CPU 与内存配额设准，然后统一调一遍连接相关内核参数，最后用节流率与 P99 延迟验证效果。这套顺序能覆盖大部分入门阶段的并发故障。

在基础设施选型上，如果业务需要独享物理资源、对性能波动敏感，宿主机或裸金属物理机形态值得优先评估；如果更看重弹性与快速交付，云服务器仍更合适。必安云作为持证 IDC 服务商，提供云服务器、高防云服务器、海外云服务器、裸金属物理机与专用宿主机等产品线，覆盖不同并发与合规需求，具体配置、线路与防护能力请以官网实时页面与商务确认为准。更多选型与部署资料可参考 https://pddu.cn。