Kubernetes Network Model

Kubernetes networking refers to the system within Kubernetes that allows different components to communicate across a cluster of machines.

• Every pod gets its own IP address
• Containers within a pod share the pod IP address and can communicate freely with each other
• Pods can communicate with all other pods in the cluster using pod IP addresses (without NAT)
• Isolation (restricting what each pod can communicate with) is defined using network policies
• Plugin-based flexibility and customization.
• This style of the network is referred to as a “flat network.”
• From a pod's view, the cluster is a single network plane.

Node Networking Models

1. Overlay Network Model
2. Underlay Network Model

• Overlay Network Model: Each node has its own private network.
• Containers within a node communicate over this private network.
• To enable communication between containers across nodes, an overlay network is created.
• Overlay networks encapsulate packets and route them between nodes using an overlay network driver, such as VXLAN or Flannel.

An underlay network is the physical infrastructure of a network, while an overlay network is a virtual network built on top of it.

• Underlay network model, all nodes share a single flat network.
• Each node has a unique IP address within this network.
• Containers communicate with each other using the node’s IP address and port mapping.
• This model is simpler to set up and is commonly used in on-premises or single-cloud deployments.

The Container Network Interface (CNI) is a specification by the Cloud
Native Computing Foundation (CNCF) that standardizes the
configuration of network interfaces for Linux containers.

A CNI plugin is a software component based on the CNI specification.
• Configures network interfaces for Linux containers.
• Allocates networking resources like IPs.
• Implements routing and enforces network policies.

Taints and Tolerations are used to set restrictions on what pods can be shared on that node.

Taints are generally applied on nodes to prevent unwanted scheduling tolerations are applied on pods to allow them to be scheduled on nodes that have taints.

𝗡𝗼𝗱𝗲 𝗔𝗳𝗳𝗶𝗻𝗶𝘁𝘆 addresses these 𝗹𝗶𝗺𝗶𝘁𝗮𝘁𝗶𝗼𝗻𝘀 𝗯𝘆 𝗲𝗻𝗮𝗯𝗹𝗶𝗻𝗴 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 to schedule pods onto nodes that match specified labels.

𝗻𝗼𝗱𝗲𝗦𝗲𝗹𝗲𝗰𝘁𝗼𝗿 is the basic and recommended form of 𝗰𝗹𝘂𝘀𝘁𝗲𝗿 𝗻𝗼𝗱𝗲 𝘀𝗲𝗹𝗲𝗰𝘁𝗶𝗼𝗻 constraint.

Kubernetes offers a built-in service discovery mechanism that allows containers to locate other containers or services.

The Kubernetes DNS service automatically assigns a DNS name to each service, making it discoverable by other containers within the cluster.

More about DNS, Load Balancing, and Gateway API | Kubernetes