kuberneteskubernetes-podhostshosts-file

What is Kubernetes egress call flow?

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

Solution

  • I think this question could be divided on 2 different topics:

    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.

    DNS resolution that is happening inside/outside of the cluster:

    As you've already stated you're using CoreDNS. It will be responsible in your setup for your DNS resolution. Your Pods will query it when looking for the domains that are not included locally (for example /etc/hosts). After they've received the responses, they will contact external sources (more on that later).

    A side note!

    The DNS resolution (local, query) will depend on the tool you've used. curl will check it but for example nslookup will query the DNS server directly.

    Your CoreDNS is most likely available under one of the Services in your cluster:

    NAMESPACE     NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
default       kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP                  79m
kube-system   kube-dns     ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   79m

    I'd reckon you can find a lot of useful information in the official documentation:

    You can also follow this guide for more hands on experience:

    Pod networking when trying to reach external sources:

    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 Pod won't "directly" communicate with the external sources. Below you can find more information on the reasoning behind it:

    NAT outgoing

    Network Address Translation (NAT) 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.

    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).

    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.

    -- Docs.projectcalico.org: About: About Kubernetes Egress

    In short assuming no others factors (like additional NAT used by your cloud provider) your Pod will try to contact the external sources with the Node IP (by using Source NAT).

    You can find more in-depth explanation on the packet life (some aspects are GKE specific) by following:

    Additional resources