The Kubernetes network model:

1. Every Pod in a cluster gets its own unique cluster-wide IP address.

This means you do not need to explicitly create links between Pods and you almost never need to deal with

mapping container ports to host ports.

2.

This creates a clean, backwards-compatible model where Pods can be treated much like VMs or physical

hosts from the perspectives of port allocation, naming, service discovery, load balancing, application

configuration, and migration.

3.

Kubernetes imposes the following fundamental requirements on any networking implementation

○ pods can communicate with all other pods on any other node without NAT

○ agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that nod 

In containers, the network configurations are temporary.

The container configuration and the data present in the containers are not persistent between executions.

Unless and until we attach some volume to our container, the data within the containers gets lost.

This doesn’t happen to only the data; the network configuration and the IP address assigned to the container also get deleted.

A deployment is a grouping of Pods. Similar to the containers, once a Pod gets deleted, all its network configurations and IP assigned get deleted. So, the manual network configuration process becomes cumbersome.

Kubernetes provides two network availability abstractions, which makes this process easier.

The two abstractions are services and ingresses. Using this, we don’t need to worry about the underlying infrastructure or managing the IP address assignment process.