Kubernetes – Networking

Kubernetes mangages many pods and containers. The management of networking in a cluster is not a simple matter. Kubernetes is doing the job using the CNI (Container Network Interface) plugins. There are many CNI providers, such as Flannel, Calico, Canal, and Weave Net.


Kubernetes Networking Requirements

The Kubernetes Network Model defines how pods should communicate each other regardless which node they are running on.

Kubernetes assume that each container (pod) has a unique and routable IP inside the cluster.

  • Each pod has its own unique IP address within the cluster (not just in a node).
  • Containers within a pod share the pod IP address, and they communicate freely with each other.
  • In this virtual network, a pod can communicate with any other pods in the cluster using pod IP addresses without NAT(Network Address Translation).
  • All nodes can communicate with all pods in the cluster without NAT.
  • The IP that a Pod sees itself as is the same IP that others see it as.

Network Plugins

A network plugin configures IPTables on each node to set up routing, which allows communication between all pods and all nodes in the cluster.


Flannel configures a layer 3 network fabric for Kubernetes.

Flannel runs a small, single binary agent called flanneld on each host and is responsible for allocating a subnet lease to each host out of a larger, preconfigured address space. Flannel uses either the Kubernetes API or etcd directly to store the network configuration, the allocated subnets, and any auxiliary data (such as the host’s public IP). Packets are forwarded using one of several backend mechanisms, including VXLAN and various cloud integrations.


kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml


While Flannel focuses on simplicity, Calico focuses on power and flexibility.

  • Calico provides more control over network administration and security.


Kubernetes DNS schedules a DNS Pod and Service on the cluster, and configures the kubelets to tell individual containers to use the DNS Service’s IP to resolve DNS names.

Every Service defined in the cluster (including the DNS server itself) is assigned a DNS name. By default, a client Pod’s DNS search list includes the Pod’s own namespace and the cluster’s default domain.


Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s