Kubernetes：Service IP可正常Curl但Service名称无法访问求助

Hey there! Let's dig into why you're having trouble accessing your game-app-service using its name instead of the direct ClusterIP. That Verizon search page redirect is a key clue here—it tells us your Ambassador Pod isn't using Kubernetes' internal DNS (CoreDNS) to resolve the Service name, and instead is hitting an external DNS server that can't find the internal Service, so it redirects to a search page.

Key Observations #

• Using the Service's ClusterIP works fine, so your Service and Deployment are correctly wired.
• Resolving game-app-service or random points to 92.242.140.21 (Verizon's public search IP), which means DNS queries aren't going to CoreDNS.
• wget -O- game-service-app returns a 200 but with a redirect, confirming the external DNS lookup issue.

Step-by-Step Troubleshooting & Fixes #

1. Verify Ambassador Pod's DNS Configuration #

First, check how DNS is set up inside your Ambassador Pod:

kubectl exec -it <your-ambassador-pod-name> -- cat /etc/resolv.conf

A healthy Kubernetes Pod's resolv.conf should look something like this:

nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

• If you don't see the CoreDNS nameserver (usually 10.96.0.10 for default setups) or the cluster-specific search domains, that's the core problem.

2. Check Namespace Alignment #

Are your game-app-service and Ambassador running in the same Kubernetes namespace?

• If they're in different namespaces, you need to use the full qualified domain name (FQDN) of the Service instead of just the name. For example, if your Service is in the default namespace and Ambassador is in ambassador, use:

  curl -v -X POST game-app-service.default.svc.cluster.local:8084/api/test
  

3. Inspect Ambassador's DNS Policy #

Kubernetes uses the dnsPolicy setting to determine how a Pod resolves DNS. Check your Ambassador Deployment's configuration:

kubectl get deployment <ambassador-deployment-name> -o yaml | grep -A2 dnsPolicy

• The correct setting should be ClusterFirst—this tells the Pod to use CoreDNS for internal cluster names, and fall back to external DNS only for public domains.
• If it's set to Default, the Pod uses the node's DNS configuration (which points to external servers like Verizon's), causing internal Service names to resolve incorrectly. To fix this, update the Deployment:

  spec:
    template:
      spec:
        dnsPolicy: ClusterFirst
  

Then apply the change and restart the Ambassador Pods.

4. Validate CoreDNS Functionality #

Even if CoreDNS Pods are running, double-check they can resolve your Service:

kubectl exec -it <coredns-pod-name> -n kube-system -- nslookup game-app-service.default.svc.cluster.local

• This should return your Service's ClusterIP. If it doesn't, check CoreDNS logs for errors:

  kubectl logs -n kube-system <coredns-pod-name>
  

Common issues here include misconfigured Corefile rules or RBAC permissions preventing CoreDNS from accessing Service endpoints.

Summary #

The root cause is almost certainly that your Ambassador Pod isn't using Kubernetes' internal DNS to resolve Service names. Fixing the DNS policy or using the full FQDN (if namespaces differ) should get you back on track.

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