The ability to serve external traffic to Kubernetes is critical. Kubernetes provides two API objects to achieve this:

• Service: External network LoadBalancer or NodePort (L4)
• Ingress: HTTP(S) LoadBalancer (L7)

We'll learn more about ingress in the next section. For now, we'll focus on the L4 service. Based on what we've learned about pod-to-pod communication across nodes, the packet goes in and out between the service and pod. The following diagram is an illustration of this process. Let's say we have two services: service A has three pods (pod a, pod b, and pod c) and service B gets only one pod (pod d). When the traffic comes in from the LoadBalancer, the packet will be dispatched to one of the nodes. Most of the LoadBalancer cloud itself is not aware of pods or containers; it only knows about the node. If the node passes the health check, then it will be the candidate for the destination.

Let's assume that we want to access service B; this currently only has one pod running on one node. However, LoadBalancer sends the packet to another node that doesn't have any of our desired pods running. In this case, the traffic route will look like this:

The packet routing journey will be as follows:

1. LoadBalancer will choose one of the nodes to forward to the packet. In GCE, it selects the instance based on a hash of the source IP and port, destination IP and port, and protocol. In AWS, load balancing is based on a round-robin algorithm.
2. Here, the routing destination will be changed to pod d (DNAT) and will forward the packet to the other node, similar to pod-to-pod communication across nodes.
3. Then comes service-to-pod communication. The packet arrives at pod d and pod d returns the response.
4. Pod-to-service communication is manipulated by iptables as well.
5. The packet will be forwarded to the original node.
6. The source and destination will be un-DNAT to the LoadBalancer and client, and will be sent all the way back to the requester.