Redis基准测试时Kubernetes端口转发进程崩溃问题咨询

首先明确：kubectl port-forward 本身存在并发处理上限，这并非Redis容器的问题，而是端口转发进程及K8s中转链路的限制导致的。

核心原因 #

• kubectl port-forward是单进程模型，所有转发连接都由单个进程处理，高并发场景下会快速耗尽进程自身的文件描述符（FD）——即便你调高了宿主机系统级的FD限制，kubectl进程自身的FD配额可能未同步提升。
• K8s端口转发依赖apiserver中转流量，而非直接的容器端口映射，高并发下apiserver的转发链路会成为瓶颈，同时kubectl进程的CPU、内存资源也不足以支撑大量并发连接的维护。

验证方法 #

1. 检查kubectl port-forward进程的FD限制：

   # 查找kubectl port-forward的进程ID
   ps aux | grep kubectl
   # 查看该进程的文件描述符限制
   cat /proc/<进程ID>/limits | grep "Max open files"
   

   若该值远低于你设置的65000，即可确认是进程级FD限制不足。

2. 查看kubectl进程崩溃前的详细日志：

   kubectl port-forward <你的Redis Pod名称> 6379:6379 -v=6
   

   高日志级别下会输出连接处理失败的具体原因，例如too many open files。

解决方案 #

• 临时提升kubectl进程的FD限制：启动端口转发前，先在当前shell中临时调高进程FD配额，再启动kubectl：

  ulimit -n 65000
  kubectl port-forward <你的Redis Pod名称> 6379:6379
  

  注：该设置仅对当前shell会话有效，重启后会恢复默认值。

• 绕过kubectl port-forward做高并发测试：

  • 给Redis Service配置NodePort或LoadBalancer类型，直接通过节点IP+端口访问，跳过apiserver中转，并发能力会大幅提升。
  • 测试环境中，也可直接登录宿主机，通过docker inspect查看容器的主机端口映射，直接访问该端口，完全绕开K8s转发链路。

• 集群级优化（需集群管理员权限）：
  调整K8s apiserver的--max-requests-inflight和--max-mutating-requests-inflight参数，提升其并发请求处理能力，但该操作会影响整个集群，需谨慎评估资源负载后再调整。

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