Kubernetes跨集群HTTP请求超时问题排查与解决求助

问题背景 #

拥有两个Kubernetes集群A和B，当从集群A的Job向集群B通过公网HTTPS暴露的服务发起HTTP请求时，出现无响应（超时）问题。Kubernetes版本为v1.21。

Kube-proxy日志分析 #

提供的kube-proxy日志如下：

E0816 08:12:49.069369       1 utils.go:282] Skipping invalid IP: 
E0816 08:12:49.069388       1 utils.go:282] Skipping invalid IP: 
E0816 08:12:49.069394       1 utils.go:282] Skipping invalid IP: 
E0816 08:12:49.069402       1 utils.go:282] Skipping invalid IP: 
I0816 08:14:38.828143       1 proxier.go:854] "Syncing iptables rules"
I0816 08:14:38.849024       1 proxier.go:824] "syncProxyRules complete" elapsed="20.89552ms"
W0816 08:17:21.911048       1 warnings.go:70] discovery.k8s.io/v1beta1 EndpointSlice is deprecated in v1.21+, unavailable in v1.25+; use discovery.k8s.io/v1 EndpointSlice
I0816 08:18:06.618311       1 proxier.go:854] "Syncing iptables rules"
I0816 08:18:06.646124       1 proxier.go:824] "syncProxyRules complete" elapsed="27.861586ms"
W0816 08:23:46.915519       1 warnings.go:70] discovery.k8s.io/v1beta1 EndpointSlice is deprecated in v1.21+, unavailable in v1.25+; use discovery.k8s.io/v1 EndpointSlice
E0816 08:27:49.069409       1 utils.go:282] Skipping invalid IP: 
E0816 08:27:49.069429       1 utils.go:282] Skipping invalid IP: 
E0816 08:27:49.069436       1 utils.go:282] Skipping invalid IP: 
E0816 08:27:49.069443       1 utils.go:282] Skipping invalid IP: 
W0816 08:31:08.919514       1 warnings.go:70] discovery.k8s.io/v1beta1 EndpointSlice is deprecated in v1.21+, unavailable in v1.25+; use discovery.k8s.io/v1 EndpointSlice
W0816 08:36:43.923978       1 warnings.go:70] discovery.k8s.io/v1beta1 EndpointSlice is deprecated in v1.21+, unavailable in v1.25+; use discovery.k8s.io/v1 EndpointSlice

日志关键信息：

1. "Skipping invalid IP"错误：kube-proxy处理IP时遇到无效条目，大概率是集群内Service或Endpoint配置存在空IP/格式错误的IP，虽不直接导致跨集群公网请求超时，但会影响内部代理规则正确性，需优先修复。
2. EndpointSlice弃用警告：v1.21版本中discovery.k8s.io/v1beta1已被弃用，虽不影响当前运行，但建议后续升级到discovery.k8s.io/v1版本，避免未来版本兼容问题。

排查步骤（从易到难） #

1. 基础网络连通性验证 #

• 在集群A的Job Pod内，先Ping集群B服务的公网IP，确认网络可达：

  ping <集群B服务公网IP>
  

  • Ping不通：排查集群A节点出站防火墙/安全组是否允许访问目标端口（HTTPS默认443）；检查集群B公网负载均衡/防火墙是否放行集群A的IP段。
• Ping通但请求超时，用Telnet测试端口连通性：

  telnet <集群B服务公网IP> 443
  

  端口不通则重点排查双方防火墙规则。

2. 检查Job Pod的DNS解析 #

• 在Job Pod内执行nslookup <集群B服务域名>，确认域名能正确解析到公网IP。若解析失败，可给Job指定公共DNS服务器：

  apiVersion: batch/v1
  kind: Job
  metadata:
    name: test-job
  spec:
    template:
      spec:
        containers:
        - name: test
          image: busybox:1.35
          command: ["wget", "https://<集群B服务域名>"]
        dnsPolicy: "None"
        dnsConfig:
          nameservers:
            - 8.8.8.8
            - 1.1.1.1
        restartPolicy: Never
  

3. 修复kube-proxy无效IP问题 #

• 排查集群A内所有Service和Endpoint的IP配置，找出空IP或格式错误的条目：

  # 列出所有Service的IP信息
  kubectl get svc -A -o wide
  # 列出所有Endpoint的IP
  kubectl get endpoints -A -o yaml | grep -E "ip:"
  

• 删除错误配置后，重启kube-proxy：

  kubectl rollout restart daemonset kube-proxy -n kube-system
  

4. 验证集群B公网服务可用性 #

• 从集群外机器（如本地电脑）访问集群B的公网HTTPS服务，确认服务本身正常。若外部访问也超时，说明问题出在集群B的服务暴露配置（如Ingress/LoadBalancer配置错误、后端Pod未就绪）。

新手友好的快速修复方案 #

若基础连通性没问题，但Job请求仍超时，可尝试以下方法：

1. 启用hostNetwork绕过集群代理：让Pod直接使用节点网络栈，规避集群内部网络代理可能存在的问题：

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: test-job
   spec:
     template:
       spec:
         hostNetwork: true
         containers:
         - name: test
           image: curlimages/curl
           command: ["curl", "-v", "https://<集群B服务公网地址>"]
         restartPolicy: Never
   

2. 用curl verbose输出定位请求细节：在Job命令中加入-v参数，查看请求全流程（如TLS握手、证书问题）：

   curl -v https://<集群B服务公网地址>
   

   若为证书问题，可临时添加--insecure跳过验证（生产环境不建议）：

   curl -v --insecure https://<集群B服务公网地址>
   

总结 #

优先排查基础网络连通性（防火墙、安全组），再验证DNS解析，最后处理kube-proxy的无效IP错误。新手可先尝试hostNetwork: true和curl verbose输出快速定位问题。

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