<p>I am newbie to kubernetes. Trying to understand that what happens when I try to access <code>google.com</code> from inside the kubernetes pod. <br/> Will the request directly reaches the google.com (offcourse not) or some dns lookup happens in <code>/etc/hosts.allow</code> file first before the call goes outside the pod ? What is the flow or journey of the egress call? <br/>
<strong>PS:</strong> I already have default coredns pod running.</p>

gaurav sinha
<p>I think this question could be divided on 2 different topics:</p>
<ul>
<li><code>DNS</code> resolution.</li>
<li><code>Pod</code> networking when trying to reach external sources.</li>
</ul>
<p>Answering both of this question could be quite lengthy but I will try to give you a baseline to it and add additional documentation that would be more in-depth.</p>
<hr />
<h3><code>DNS</code> resolution that is happening inside/outside of the cluster:</h3>
<p>As you've already stated you're using <code>CoreDNS</code>. It will be responsible in your setup for your <code>DNS</code> resolution. Your <code>Pods</code> will query it when looking for the domains that are not included locally (for example <code>/etc/hosts</code>). After they've received the responses, they will contact external sources (more on that later).</p>
<blockquote>
<p>A side note!</p>
<p>The <code>DNS</code> resolution (local, query) will depend on the tool you've used. <code>curl</code> will check it but for example <code>nslookup</code> will query the DNS server directly.</p>
</blockquote>
<p>Your <code>CoreDNS</code> is most likely available under one of the <code>Services</code> in your cluster:</p>
<ul>
<li><code>$ kubectl get service --all-namespaces</code></li>
</ul>
<pre class="lang-sh prettyprint-override"><code>NAMESPACE     NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
default       kubernetes   ClusterIP   10.96.0.1    &lt;none&gt;        443/TCP                  79m
kube-system   kube-dns     ClusterIP   10.96.0.10   &lt;none&gt;        53/UDP,53/TCP,9153/TCP   79m
</code></pre>
<p>I'd reckon you can find a lot of useful information in the official documentation:</p>
<ul>
<li><em><a href="https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/" rel="nofollow noreferrer">Kubernetes.io: Docs: Concepts: Services networking: Dns pod service</a></em></li>
</ul>
<p>You can also follow this guide for more hands on experience:</p>
<ul>
<li><em><a href="https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/" rel="nofollow noreferrer">Kubernetes.io: Docs: Tasks: Administer cluster: DNS debugging resolution</a></em></li>
</ul>
<hr />
<h3>Pod networking when trying to reach external sources:</h3>
<p>Each Kubernetes solution could differ on how exactly is handling networking. Please reach to the documentation of your solution for more details. The main premise of it is that the <code>Pod</code> won't &quot;directly&quot; communicate with the external sources. Below you can find more information on the reasoning behind it:</p>
<blockquote>
<h3>NAT outgoing</h3>
<p>Network Address Translation (<a href="https://en.wikipedia.org/wiki/Network_address_translation" rel="nofollow noreferrer">NAT</a>) is the process of mapping an IP address in a packet to a different IP address as the packet passes through the device performing the NAT. Depending on the use case, NAT can apply to the source or destination IP address, or to both addresses.</p>
<p>In the context of Kubernetes egress, NAT is used to allow pods to connect to services outside of the cluster if the pods have IP addresses that are not routable outside of the cluster (for example, if the pod network is an overlay).</p>
<p>For example, if a pod in an overlay network attempts to connect to an IP address outside of the cluster, then the node hosting the pod uses SNAT (Source Network Address Translation) to map the non-routable source IP address of the packet to the node’s IP address before forwarding on the packet. The node then maps response packets coming in the opposite direction back to the original pod IP address, so packets flow end-to-end in both directions, with neither pod or external service being aware the mapping is happening.</p>
<p>-- <em><a href="https://docs.projectcalico.org/about/about-kubernetes-egress" rel="nofollow noreferrer">Docs.projectcalico.org: About: About Kubernetes Egress</a></em></p>
</blockquote>
<p>In short assuming no others factors (like additional <code>NAT</code> used by your cloud provider) your <code>Pod</code> will try to contact the external sources with the <code>Node IP</code> (by using <code>Source NAT</code>).</p>
<p>You can find more in-depth explanation on the packet life (some aspects are <code>GKE</code> specific) by following:</p>
<ul>
<li><em><a href="https://www.youtube.com/watch?v=0Omvgd7Hg1I" rel="nofollow noreferrer">Youtube.com: Life of a Packet [I] - Michael Rubin, Google
</a></em> - around the <code>17:55</code> minute mark.</li>
</ul>
<hr />
<h3>Additional resources</h3>
<ul>
<li><p><em><a href="https://coredns.io/plugins/log/" rel="nofollow noreferrer">Coredns.io: Plugins: Log</a></em> - you can modify the <code>CoreDNS</code> <code>ConfigMap</code> (<code>$ kubectl edit configmap -n kube-system coredns</code> to enable logging to stdout (<code>$ kubectl logs ...</code>) to see more in-depth query resolution.</p>
</li>
<li><p><em><a href="https://speakerdeck.com/thockin/kubernetes-and-networks-why-is-this-so-dang-hard?slide=57" rel="nofollow noreferrer">Speakerdeck.com: Thockin: Kubernetes and networks why is this so damn hard: Slide 57</a></em> - more on the Kubernetes networking.</p>
</li>
</ul>
