<p>I want to understand how the <code>/etc/resolve.conf</code> is configured for each pod of a replicaSet for DNS server info, because I upgraded the cluster from 1.13 to 1.14 and it somehow changed the IP of the kube DNS server , and the existing replicaSet is injecting the old IP/info into the <code>/etc/resolve.conf</code> of new pods of that replicaSet, breaking the service discovery for those particular pods.</p>

<p>Even if it is not a cluster upgrade and one just re-deploy kube-dns, and it changes its IP, then how existing replicaSet or statefulSets behave when they add/increase more pods. On my side, currently, it's injecting the old info.</p>

<p>New deployments work fine.</p>

Ijaz Ahmad
<p>The pods will always inherit the specification from the <a href="https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents" rel="nofollow noreferrer">owner object</a>, in this case, from the <code>ReplicaSet</code>.</p>

<p>Each <code>ReplicaSet</code> has a <strong>pod template</strong> that contains the <em>resolv.conf</em> registered configuration and won't change unless a new <code>Deployment</code> is rolled out (since RSs are dependents of the <code>Deployment</code> object):</p>

<p><code>kubectl get rs YOUR_REPLICASET -o yaml | grep pod-template-hash -m 1</code></p>

<p>In this case you can either rollout a new <code>Deployment</code> version or redeploy the <em>kube-dns/coreDNS</em>' YAML definition, keeping the original <code>clusterIP</code>:</p>

<pre><code>spec:
  clusterIP: 10.11.0.12 # Old service address
</code></pre>
