单个Service能否承载70个StatefulSet/Deployment Pod及百万级请求？

1. 单个Service支撑70个Pod的可行性 #

• 完全可以，该场景属于K8s的常规使用范围。
• Service仅通过标签选择器匹配关联的Pod生成Endpoint列表，和Pod归属的 workload 类型（StatefulSet/Deployment）无关，即便是默认iptables模式的kube-proxy，支撑数百个后端Pod也不会有性能瓶颈，70个后端的负载均衡规则生成、转发完全无压力。

2. 百万级请求的承载能力说明 #

• Service本身是负载均衡规则的抽象，不直接处理流量，实际转发由kube-proxy生成的内核态规则完成，转发损耗几乎可以忽略，本身不存在性能瓶颈。
• 能否支撑百万级请求核心取决于以下几个条件：
  • 后端70个Pod的业务处理能力：只要单Pod的QPS承载能力达标，比如单Pod可承载2万QPS，70个Pod即可支撑140万总请求，完全满足要求
  • kube-proxy的运行模式：高并发场景建议切换为ipvs模式，相比iptables模式的规则匹配效率高很多，可轻松支撑百万级四层流量转发
  • 集群节点的网络带宽：需要确保集群节点的出入口带宽可以匹配百万级请求对应的流量大小
  • 若使用公有云LoadBalancer类型的Service，需要确认对应云厂商负载均衡实例的性能规格，选择符合百万级QPS要求的规格即可
• 如果是七层请求场景，需要在Service前搭配Ingress控制器或独立网关组件做七层处理，这部分性能需要单独评估，和Service本身无关。

3. service-per-pod方案的适用场景 #

• 常规的流量负载均衡场景完全不需要采用service-per-pod方案，该方案会生成大量冗余的Service、Endpoint资源，额外增加kube-apiserver和kube-proxy的调度负担，属于不必要的资源浪费。
• 只有存在以下特殊需求时才需要考虑该方案：
  • StatefulSet的每个Pod需要独立的内部服务发现入口，比如分布式数据库、消息队列的每个数据节点需要单独被访问
  • 每个Pod需要单独做流量管控、灰度发布、权限控制
  • 业务逻辑要求每个实例拥有独立的对外访问地址

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