Kubernetes同容器React前端调用Node.js后端API超时问题咨询

你的判断完全正确：React打包后运行在终端用户的本地浏览器中，所有API请求从用户本地网络发起，既无法解析K8s集群内部的Pod域名、Service ClusterIP对应的内网地址，也没有访问集群内网网段的路由权限，这就是请求超时的核心原因。

• 你在Pod内用curl访问Pod名+端口能通，是因为curl运行在集群内网的Pod环境里，具备内网解析和访问权限
• 硬编码LoadBalancer外部IP能通，是因为这个IP是公网/用户可达的，但Pod重建漂移后直连Pod的地址会失效，本身也不符合K8s服务暴露的最佳实践

你不需要强制部署Nginx Ingress控制器，针对你当前前后端同容器部署的架构，有更轻量的零额外组件方案，也可以后续根据架构演进选择更通用的生产方案。

方案1：静态服务代理（最简，适配当前同容器架构，无需额外组件） #

这个方案完全利用你已经在容器内安装的serve静态服务做反向代理，不需要新增任何中间件，改造成本最低：

• 第一步：修改前端代码中的API请求路径，把所有写死的绝对地址（比如http://podname:3001/api/xxx）全部替换为相对路径/api/xxx，这样请求默认会发往前页页面所在的同域名、同端口。

  注意：React开发阶段在setupProxy.js里配置的代理仅对npm start启动的开发服务器生效，执行npm run build打出来的静态包不包含这个代理逻辑，不要指望开发代理在生产环境生效。

• 第二步：给serve添加反向代理配置，在前端项目根目录新建serve.json文件，写入如下规则，将所有/api开头的请求转发到同容器内监听3001端口的Node后端：

{
  "rewrites": [
    {
      "source": "/api/:path*",
      "destination": "http://localhost:3001/api/:path*"
    }
  ]
}

• 第三步：调整前端启动命令，启动serve时加载上述配置，比如原来的启动命令是serve -s build -l 3000，修改为serve -c serve.json -s build -l 3000，把这个命令更新到你的startup.sh脚本里，注意启动顺序：先启动3001端口的Node后端，再启动3000端口的serve服务。
• 第四步：调整K8s Service配置，只需要创建一个对外暴露的Service（LoadBalancer/NodePort/Ingress都可以），仅暴露前端的3000端口即可，不需要单独暴露后端的3001端口。

这个方案下，所有请求的流转逻辑是：用户浏览器 -> 对外暴露的Service -> 容器内serve服务 -> 静态资源直接返回给用户，/api开头的请求由serve直接通过容器内localhost转发给同容器的Node后端，全程不依赖集群内网DNS、不需要跨节点网络转发，Pod重启漂移完全不影响逻辑，也不会有跨域问题。

方案2：Nginx Ingress统一路由（适合后续前后端拆分部署的生产场景） #

如果你后续计划把前后端拆成独立的Deployment、Pod部署，再考虑部署Nginx Ingress控制器即可，当前同容器场景下没必要上：

• 把前后端分别打包成独立镜像，部署成独立的Deployment，对应创建两个ClusterIP类型的Service，分别指向前端、后端
• 配置Ingress路由规则：/路径的请求转发到前端Service，/api路径的请求转发到后端Service
• 对外只暴露Ingress的统一访问入口，所有流量由Ingress控制器在集群内网完成转发，用户侧不需要感知集群内部拓扑。

• 不要在前端代码中硬编码任何K8s集群内部地址（Pod名、ClusterIP、内部域名），这些地址对用户浏览器不可达
• 不建议单独给后端Service配置LoadBalancer对外暴露，会额外消耗负载均衡资源，还会引入跨域问题，同域代理方案可以完全规避跨域
• 同容器部署的场景下，容器内多进程通过localhost通信是性能最高、可靠性最好的方式，比走集群网络转发延迟更低、也不依赖集群DNS组件可用性

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