<p>I have pod A (it's actually the kube-scheduler pod) and pod B (a pod that has a REST API that will be invoked by pod A).</p>
<p>For this purpose, I created a ClusterIP service.</p>
<p>Now, when I exec into pod A to perform the API call to pod B, I get:
<code>curl: (6) Could not resolve host: my-svc.default.svc.cluster.local</code></p>
<p>I tried to follow the debug instructions mentioned <a href="https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/" rel="nofollow noreferrer">here</a>:</p>
<pre><code>kubectl exec -i -t dnsutils -- nslookup my-svc.default
Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   my-svc.default.svc.cluster.local
Address: 10.111.181.13
</code></pre>
<p>Also:</p>
<pre><code>kubectl exec -i -t dnsutils -- nslookup kubernetes.default
Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   kubernetes.default.svc.cluster.local
Address: 10.96.0.1
</code></pre>
<p>This seems to be working as expected. However, when I exec into pod A, I get:</p>
<pre><code>kubectl exec -it kube-scheduler -n kube-system -- sh
/bin # nslookup kubernetes.default
Server:         8.8.8.8
Address:        8.8.8.8:53

** server can't find kubernetes.default: NXDOMAIN

** server can't find kubernetes.default: NXDOMAIN
</code></pre>
<p>Other debugging steps (inside pod A) include:</p>
<pre><code>/bin # cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 172.30.0.1
</code></pre>
<p>And:</p>
<pre><code>/bin # cat /etc/*-release
3.12.8
NAME=&quot;Alpine Linux&quot;
ID=alpine
VERSION_ID=3.12.8
PRETTY_NAME=&quot;Alpine Linux v3.12&quot;
HOME_URL=&quot;https://alpinelinux.org/&quot;
BUG_REPORT_URL=&quot;https://bugs.alpinelinux.org/&quot;
</code></pre>
<p>There are no useful logs from the coredns pods, either.</p>
<pre><code>kubectl logs --namespace=kube-system -l k8s-app=kube-dns
.:53
[INFO] plugin/reload: Running configuration MD5 = db32ca3650231d74073ff4cf814959a7
CoreDNS-1.7.0
linux/amd64, go1.14.4, f59c03d
.:53
[INFO] plugin/reload: Running configuration MD5 = db32ca3650231d74073ff4cf814959a7
CoreDNS-1.7.0
linux/amd64, go1.14.4, f59c03d
</code></pre>
<p>From the <a href="https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/" rel="nofollow noreferrer">documentation</a>, it seems there is a known issue with Alpine and DNS resolution (even though the version I have is greater than the version they mentioned).</p>
<p>Is there a workaround this to enable accessing the service properly from the Alpine pod?</p>
<hr />
<p>Edit providing pod A manifest:</p>
<pre><code>apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    component: kube-scheduler
    tier: control-plane
  name: kube-scheduler
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-scheduler
    - --authentication-kubeconfig=/etc/kubernetes/scheduler.conf
    - --authorization-kubeconfig=/etc/kubernetes/scheduler.conf
    - --bind-address=127.0.0.1
    - --config=/etc/kubernetes/sched-cs.yaml
    - --port=0
    image: localhost:5000/scheduler-plugins/kube-scheduler:latest
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: 127.0.0.1
        path: /healthz
        port: 10259
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    name: kube-scheduler
    resources:
      requests:
        cpu: 100m
    startupProbe:
      failureThreshold: 24
      httpGet:
        host: 127.0.0.1
        path: /healthz
        port: 10259
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    volumeMounts:
    - mountPath: /etc/kubernetes/scheduler.conf
      name: kubeconfig
      readOnly: true
    - mountPath: /etc/kubernetes/sched-cs.yaml
      name: sched-cs
      readOnly: true
  hostNetwork: true
  priorityClassName: system-node-critical
  volumes:
  - hostPath:
      path: /etc/kubernetes/scheduler.conf
      type: FileOrCreate
    name: kubeconfig
  - hostPath:
      path: /etc/kubernetes/sched-cs.yaml
      type: FileOrCreate
    name: sched-cs
status: {}
</code></pre>
<hr />
<p>Edit 2:
Adding the following lines <strong>manually</strong> to <code>/etc/resolv.conf</code> of Pod A allows me to perform the curl request successfully.</p>
<pre><code>nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
</code></pre>
<p>Wouldn't there be a cleaner/less manual way to achieve the same result?</p>

<p>Try setting the <code>DNSPolicy</code> for pod A (or whatever deployment, statefulset, etc.) defines its template to <code>ClusterFirst</code> or <code>ClusterFirstWithHostNet</code>.</p>
<p>The behavior of this setting depends on how your cluster and kubelet are set up, but in most default configurations this will make the kubelet set resolv.conf inside the pod to use the kube-dns service that you manually set in your edit (10.96.0.10), which will forward lookups outside the cluster to the nameservers for the host.</p>
<p><a href="https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy" rel="nofollow noreferrer">K8s docs</a></p>
