If Kubernetes is the hottest thing in IT hosting, then, by association, it is also the hottest thing in networking.

But Kubernetes networking is complicated, and many believe the Kubernetes ecosystem overall gets more complex every year. To simplify, we'll divide Kubernetes networking into three elements -- networking within pods, networking between pods and networking that unites users and containerized resources -- and see how a unified approach can support all three.

Kubernetes networking within pods Everything in Kubernetes starts with a pod. The containers or application components inside a Kubernetes pod are inside a local host, which means they're on the same system and thus reachable by the localhost mechanism. Kubernetes implements this connection as a virtual bridge, which means the containers or components within a pod are on a virtual ethernet network, akin to an office or home network. Communication is direct, with no need for routing. One designated "bridge" container within each Kubernetes pod provides the pod networking, so most questions about Kubernetes networking are about how to connect pods and users -- the second and third of the three Kubernetes networking elements discussed here.

Networking between pods The pods in a Kubernetes node, or host, are externally accessible through the aforementioned bridge container. Pod addresses are assigned as applications deploy, which means that if the pods redeploy or scale, their addresses change. That leads to the next level of Kubernetes networking, which is services. Each Kubernetes service has a persistent address, which is mapped to the current pod addresses that make up the service. The Kubernetes service is essentially the boundary between the virtual network and dynamic IP addresses from cloud and container hosting, and the company's internet or VPN, where addresses must be consistent for each resource and user.