首先得说，你看到的「单个Pod最多支持8个并发连接」这个数据太片面了，完全不能直接拿来作为计算依据——Pod的并发能力根本没有固定的硬限制，核心取决于你Pod里跑的应用本身：

• 如果是Nginx这类反向代理，单Pod轻松扛几千甚至上万并发都是常规操作；
• 如果是Java后端应用，并发能力由你的线程池配置、JVM参数、业务逻辑复杂度决定，可能从几十到几千不等；
• 就算是数据库Pod，比如MySQL，它的连接数也是可以通过max_connections参数调整的，默认一般是151，远不止8。

所以你直接按8算出来的1250个Pod，大概率是严重高估的，而且你的集群总Pod上限（12个Worker×100=1200）还装不下这么多，显然不合理。

那该怎么正确估算Deployment的副本数呢？给你几个关键步骤：

1. 先测出单Pod的真实并发能力 #

这是最核心的一步，没有之一。你需要对容器化后的单个应用Pod做性能压测：

• 用k6、JMeter这类工具，模拟和生产环境一致的请求类型、请求量；
• 同时监控Pod的CPU、内存使用率，确保压测时资源不超过你配置的resources.limits；
• 找到单Pod在资源饱和前能稳定承载的并发数（比如测出来单Pod能扛100并发，那10000并发只需要100个副本）。

2. 结合集群容量做校验 #

你的12个Worker节点，每个Pod上限约100，但要注意：每个节点上还会跑一些系统必备的Pod（比如kube-proxy、CNI插件Pod、监控Agent等），实际能分配给业务的Pod数大概是每个节点80-90个。所以集群总业务Pod上限大概在960-1080之间。如果你的计算结果超过这个数，要么需要扩容Worker节点，要么得优化单Pod的并发能力。

3. 用HPA实现动态扩缩容 #

别把副本数固定死，Kubernetes的Horizontal Pod Autoscaler（HPA） 能帮你自动调整副本数：

• 可以基于CPU、内存使用率触发扩缩，比如CPU使用率超过70%就加副本；
• 更精准的话，还可以接入自定义指标（比如QPS、并发连接数），让扩缩更贴合业务流量。
  这样既能应对突发的流量峰值，又能在流量低的时候减少副本节省资源。

补充：关于Kubernetes的硬限制 #

你提到的单节点Pod上限110是K8s的默认值，这个可以通过修改kubelet的--max-pods参数调整，但不建议随意调高——节点的CPU、内存、网络资源都是有限的，太多Pod会导致节点资源竞争，稳定性下降。而单Pod的连接限制，Kubernetes本身并没有做限制，完全由容器内的应用和宿主机的内核参数（比如文件句柄数）决定。

总结下来，别被那个8并发的资料误导，先测自己应用的真实性能，再结合集群容量和HPA来配置副本数才是靠谱的方案。

内容的提问来源于stack exchange，提问作者user1067171