如何实现Kubernetes集群内网关应用与其他应用的HTTP通信

Hey there, let's work through this connectivity issue between your Kubernetes gateway and the other app in your cluster. I’ve run into similar problems before, so here’s a step-by-step breakdown to diagnose and fix it:

First, a Critical Kubernetes 101 Note #

You shouldn’t directly call a Pod’s IP:port for inter-app communication in Kubernetes—Pod IPs are ephemeral (they change when Pods restart, scale, or get rescheduled). Instead, you need to use a ClusterIP Service to expose your target app internally. That’s the standard way apps talk to each other in a cluster.

1. Check if Your Target App Has a ClusterIP Service #

First, confirm your 9001-port app is exposed via a ClusterIP Service (the default for internal access):

• Run this command to list Services in your namespace (replace your-namespace with your actual namespace, or omit -n your-namespace to check all namespaces):

  kubectl get svc -n your-namespace
  

• Look for a Service linked to your target app. It should have a ClusterIP (not LoadBalancer unless you need external access too) and map to port 9001 of the Pods.

If No Service Exists: Create One #

Here’s an example YAML (target-app-svc.yaml) to create a ClusterIP Service for your app:

apiVersion: v1
kind: Service
metadata:
  name: target-app-service
  namespace: your-namespace
spec:
  selector:
    app: target-app  # Make sure this matches the labels on your target app's Pods
  ports:
    - protocol: TCP
      port: 80  # This is the internal port the Service exposes; can be any value (doesn't have to match 9001)
      targetPort: 9001  # This *must* match the port your app listens on inside its Pod
  type: ClusterIP

Apply it with:

kubectl apply -f target-app-svc.yaml

2. Test Connectivity Directly from the Gateway Pod #

Instead of running curl from outside the cluster (using my_cluster_ip:9001), test from the gateway Pod itself to rule out external network issues:

• Get your gateway Pod’s name:

  kubectl get pods -n your-namespace | grep gateway
  

• Exec into the gateway Pod:

  kubectl exec -it <gateway-pod-name> -n your-namespace -- /bin/bash
  

• Inside the Pod, use the Service’s DNS name to curl the target app (Kubernetes auto-creates DNS entries for Services):

  curl http://target-app-service.your-namespace.svc.cluster.local:80
  

  (Swap in your actual Service name, namespace, and Service port here.)

If this works, your internal connectivity is solid—your original curl my_cluster_ip:9001 was trying to hit a Pod directly, which isn’t reliable or intended.

3. Check for Blocking Network Policies #

If the curl from the gateway Pod fails, check if Network Policies are blocking traffic:

• List Network Policies in your namespace:

  kubectl get networkpolicies -n your-namespace
  

• Make sure no policy denies ingress to the target app from your gateway’s Pod labels, or egress from the gateway to the target app.

4. Verify the Target App is Listening Correctly #

Double-check that your target app is actually listening on port 9001 and bound to all interfaces (not just localhost):

• Exec into the target app’s Pod:

  kubectl exec -it <target-app-pod-name> -n your-namespace -- /bin/bash
  

• Run this to confirm the app is reachable:

  ss -tulpn | grep 9001
  

  You should see output showing the app is bound to 0.0.0.0:9001 (not 127.0.0.1:9001, which would make it unreachable from other Pods).

5. If You Must Access the Target App Externally (Not Recommended) #

If you really need to hit the target app via your cluster’s public IP (like your original curl attempt), you’d need to expose it via a LoadBalancer Service (similar to your gateway). But this is usually unnecessary—your gateway should handle external traffic and proxy it to the internal target app via the ClusterIP Service.

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