K8s环境下Nginx代理无法访问WordPress Pod问题求助

Hey there, let’s work through this connection refused error you’re hitting between your Nginx proxy pod and WordPress pod. I’ve debugged this exact scenario a handful of times, so here’s a step-by-step breakdown of the most likely culprits and how to check them:

1. Verify the WordPress Pod itself is reachable #

First, rule out issues with the WordPress pod before blaming the proxy or service:

• Test direct pod access: Exec into your Nginx proxy pod and run a curl against the WordPress pod’s internal IP on port 80:

  kubectl exec -it <nginx-proxy-pod-name> -- curl <wordpress-pod-ip>:80
  

  If this fails, the problem is with the WordPress pod, not the proxy.
• Check Apache’s listening address: Exec into the WordPress pod and confirm Apache is listening on all interfaces (not just localhost):

  kubectl exec -it <wordpress-pod-name> -- netstat -tulpn | grep :80
  

  You should see output like 0.0.0.0:80 (not 127.0.0.1:80). If it’s only bound to localhost, your Apache config is restricting access—update your Listen directive or VirtualHost to bind to 0.0.0.0:80.
• Confirm the container is healthy: Check the WordPress pod’s status with kubectl describe pod <wordpress-pod-name> to make sure it’s in Running state, no crash loops, and the container port 80 is correctly exposed.

2. Validate the WordPress Service configuration #

Since you mentioned the Service config isn’t complete, here are the critical bits to check:

• Selector-label matching: Ensure the Service’s selector exactly matches the labels on your WordPress pod. For example, if your Service has:

  selector:
    app: wordpress
  

  Your WordPress pod must have the label app: wordpress (check with kubectl get pods --show-labels). Mismatched selectors mean the Service can’t find backend pods.
• Port mapping: Double-check that the Service’s targetPort matches the port your WordPress container exposes (80). The port field is the cluster-internal port the Service uses, but targetPort must point to the container’s actual port. Example:

  ports:
    - name: http
      port: 8080  # Cluster-internal port, can be any value
      targetPort: 80  # Must match container's exposed port
  

• Test Service access: From the Nginx proxy pod, curl the Service’s name (and port) to confirm it routes to the WordPress pod:

  kubectl exec -it <nginx-proxy-pod-name> -- curl <wordpress-service-name>:<service-port>
  

  If this fails, the Service is misconfigured.

3. Check Nginx Proxy Configuration #

Make sure your Nginx config is pointing to the right upstream target:

• Upstream address: Your Nginx upstream block should reference the WordPress Service name (or fully qualified domain name if cross-namespace) instead of a hardcoded IP. For example:

  upstream wordpress_upstream {
      server wordpress-service:8080;  # Use Service name + its port
      # If cross-namespace: server wordpress-service.wordpress-namespace.svc.cluster.local:8080;
  }
  

  Avoid using localhost or pod IPs (pods can restart and change IPs).
• Error log details: Check your Nginx error logs to confirm which upstream address it’s trying to connect to. The log line will show something like connect() failed (111: Connection refused) while connecting to upstream, client: ..., server: ..., upstream: "<ip>:<port>"—verify that IP/port matches your WordPress pod or Service.

4. Rule Out Network Policies & Firewalls #

• Cluster Network Policies: If your cluster uses NetworkPolicies, ensure there’s a policy allowing traffic from the Nginx proxy pod/namespace to the WordPress pod on port 80. A missing policy will block connections even if everything else is correct.
• Node-Level Firewalls: Check if any iptables rules or security groups on your Kubernetes nodes are blocking pod-to-pod traffic on port 80. Most managed clusters handle this automatically, but it’s worth verifying if you’re running a self-hosted cluster.

Start with the simplest checks first (pod health and direct access) and work your way up—this should help you pinpoint exactly where the connection is breaking.

内容的提问来源于stack exchange，提问作者Pablo Marti Cordero