Kubernetes

Kubernetes Network Namespace

Kubernetes Network Namespace

Kubernetes has emerged as the de facto standard for containerization and orchestration for managing containerized applications. Among its many features, Kubernetes offers network namespace functionality, which is critical in isolating and securing network resources within a cluster. This blog post will delve deeper into Kubernetes Network Namespace, exploring its purpose, benefits, and how it enhances its overall network management capabilities.

Kubernetes networking operates on a different level compared to traditional networking models. We will explore the basic building blocks of Kubernetes networking, including Pods, Services, and the Container Network Interface (CNI). By grasping these fundamentals, you'll be better equipped to navigate the networking landscape within Kubernetes.

In simple terms, a network namespace is an isolated network stack that allows for the creation of separate network environments within a single Linux kernel. Kubernetes leverages network namespaces to provide logical network isolation between pods, ensuring each pod operates in its virtual network environment.

In the context of Kubernetes, each container runs in its own network namespace, providing a dedicated network stack that is separate from other containers and the host system.

Table of Contents

Highlights: Kubernetes Network Namespace

Container Network Interface (CNI)

The Container Network Interface (CNI) is a crucial component that enables different networking plugins to integrate with Kubernetes. We will delve into the inner workings of CNI and discover how it facilitates communication between Pods and the integration of external networks. Understanding CNI will empower you to choose the right networking solution for your Kubernetes cluster.

The Role of Docker

In addition to my theoretical post on container networking – Docker & Kubernetes, the following hands-on series examines Linux Namespaces and Docker Networking. The advent of Docker makes it easy to isolate the Linux processes so they don’t interfere with one another. As a result, users can run various applications and dependencies on a single Linux machine, all sharing the same Linux kernel. This abstraction is made possible using Linux Namespaces, which form the docker container security basis.

Related: Before you proceed, you may find the following helpful post for pre-information.

  1. Neutron Network
  2. OpenStack neutron security groups
  3. Kubernetes Networking 101



Kubernetes Network Namespace.

Key Kubernetes Network Namespace  Discussion points:


  • Introduction to both Docker networking and Linux.

  • Discussion on the namespace and virtual interface types.

  • Kubernetes network namespace and docker networking.

  • Security options with Linux firewall and Netfilter.

Back to Basics: Kubernetes Networking

Understanding Container Networking Models

There are various container networking models, each offering distinct advantages and use cases. Let’s explore two popular models:

1. Bridge Networking: The bridge networking model creates a virtual network bridge that connects containers running on the same host. Containers within the same bridge network can communicate directly with each other, whereas containers in different bridge networks require additional configuration for communication.

2. Overlay Networking: The overlay networking model allows containers running on different hosts to communicate seamlessly. It achieves this by encapsulating network packets within existing network protocols, effectively creating a virtual network overlay across multiple hosts.

Multicast VXLAN
Diagram: Multicast VXLAN

Kubernetes Networking

Kubernetes users generally do not create pods directly. Instead, they make a high-level workload, such as a deployment, which organizes pods according to some intended spec. In the case of deployment, users specify a template for pods and how many pods (often called replicas) they want to exist.

Several additional ways to manage workloads exist, such as ReplicaSets and StatefulSets. Remember that Pods are ephemeral, suggesting they are deleted and replaced with new versions.

Kubernetes Networking 101
Diagram: Kubernetes Networking 101

Benefits of Kubernetes Network Namespace:

1. Enhanced Network Isolation: Kubernetes Network Namespace provides a robust framework for isolating network resources, ensuring that pods do not interfere with each other’s network traffic. This isolation helps prevent unauthorized access, reduces the attack surface, and enhances overall security within a Kubernetes cluster.

2. Efficient Resource Utilization: Kubernetes optimizes network resource utilization by utilizing network namespaces. Pods within a namespace can share the same IP address range while maintaining complete isolation, resulting in more efficient use of IP addresses and reduced network overhead.

3. Simplified Networking Configuration: Kubernetes Network Namespace simplifies the configuration of network policies and routing rules. Administrators can define network policies at the namespace level, allowing for granular control over inbound and outbound traffic between pods and external resources.

4. Scalability and Flexibility: With Kubernetes Network Namespace, organizations can scale their applications without worrying about network conflicts. By encapsulating each pod within its network namespace, Kubernetes ensures that the network resources can scale seamlessly, enabling the deployment of complex microservices architectures.

How Kubernetes Network Namespace Works:

Kubernetes Network Namespace leverages the underlying Linux kernel’s network namespace feature to create separate network environments for each pod. When a pod is created, Kubernetes assigns a unique network namespace, isolating the pod’s network stack from other pods in the cluster.

Each pod has network interfaces, IP addresses, routing tables, and firewall rules within a network namespace. This isolation allows each pod to operate as if it were running on its virtual network, even though it shares the same underlying physical network infrastructure.

Administrators can define network policies at the namespace level, controlling traffic flow between pods within the same namespace and across different namespaces. These policies enable fine-grained control over network traffic, enhancing security and allowing for the implementation of complex networking scenarios.

Docker Default Networking 101 & Linux Namespaces

Six namespaces are implemented in the Linux kernel, enabling the core of container based virtualization. The following diagram displays per process isolation – IPC, MNT, NET, PID, USER, and UTS. The number on the right in the square brackets is each namespace’s unique proc inode number.

A structure called nsproxy was added to implement namespaces in the Linux kernel. As the name suggests, it’s a namespace proxy. We have several userspace packages to support namespaces: util-linux, iproute2, ethtool, and wireless iw. In this hands-on series, we will focus on the iproute2 userspace, which allows management of the network namespace (NET) with the IP NETNS and IP LINK commands.

Docker Networking

Docker networking, essentially a namespacing tool, can isolate processes into small containers. Containers differ from VMs that emulate a hardware layer on the operating system. Instead, they use operating system features like namespaces to provide similar isolation without emulating the hardware layer.

Docker networking

Each namespace has an individual and isolated view, allowing sharing of the same host but with individual routing tables and interfaces.

Users may create namespaces, assign ports, and connect for external connectivity. A virtual interface type known as virtual Ethernet (veth) interface is set to namespaces. They act as pairs and have a similar analogy of an isolated tube – what comes in one end must go back out the other.

The pairing enables namespace connectivity. Users may also connect namespaces using Open vSwitch. The following screenshot displays the creation of a namespace called NAMESPACE, a veth pair, and adding a veth interface to the newly created namespace. As discussed, the IP NET and IP LINK commands enable interaction with the network namespace. 

Docker Networking

The following screenshot displays IP-specific parameters for the previously created namespace. The routing table will only show specific namespace parameters, not information from other namespaces. For example, the following ip route list command does not display the 192.168.1.1/24 interface assigned to the NAMESPACE-A.

This is because the ip route list command looks into the global namespace, not the routing table assigned to the new namespace. Instead, the command will show different route table entries, including different default gateways for each namespace. 

Netnamespace

Kubernetes Network Namespace & Docker Networking

Installing Docker creates three networks that can be viewed by issuing the docker network ls command: bridge, host, and null. Running containers with a specific –net flag highlights the network in which you want to run the container. The “none” flag puts the container in no network, so it’s completely isolated. The “host” flag puts the container in the host’s network.

inspecting container networks
Diagram: Inspecting container networks

Leaving the defaults places the container into the bridge default network. The default docker bridge is what you will probably use most of the time. Any containers connected to the default bridge, like a flat VLAN, can communicate freely. The following displays the networks created and any containers attached. Currently, no containers are attached.

docker network

The image below displays the initiation of the default Ubuntu image pulled from the Docker public registry. There are plenty of images up there that are free to pull down. As you can see, Docker automatically creates a subnet and a gateway. The docker run command starts the container in the default network.

With this setup, it will stop running if you don’t use crtl+p + ctrl +q to exit the container. Running containers are viewed with the docker ps command, and users can connect to a container with the Docker attach command. \

docker network

IPTables

Communication between containers can be restricted with IPTables. The Linux kernel uses different IPtables according to the protocol in use:

  •  IPtables for IPv4 – net/ipv4/netfliter/ip_tables.c
  •  IP6table for IPv6 -net/ipv6/netfliter/ip6_tables.c
  •  arptables for ARP -net/ipv4/netfliter/arp_tables.c
  •  ebtables for Ethernet – net/bridge/netfilter/ebtables.c

Docker Security Options

They are essentially a Linux firewall before the Netfilter, providing a management layer for adding and deleting Netfilter rules and displaying statistics. The Netfilter performs various operations on packets traversing the network stack. Check the FORWARD chain; it has a default policy of ACCEPT or DROP.

All packets reach this hook point after a lookup in the routing system. The following screenshot shows the permit for all sources of the container. If you want to narrow this down, restrict only source IP 8.8.8.8 access to the containers with the following command – iptables -I DOCKER -i ext_if! -s 8.8.8.8 -j DROP

IPTABLES

In addition to the default networks created during Docker installation, users may create user-defined networks. User-defined networks come in two forms – Bridge and Overlay networks. Bridge networks support single-host connectivity, and containers connected to an overlay network may reside on multiple hosts.

The user-defined bridge network is similar to the docker0 bridge. An overlay network allows containers to span multiple hosts, enabling a multi-host connectivity model. However, it has some prerequisites, such as a valid data store. 

Summary: Kubernetes Network Namespace

Kubernetes, the powerful container orchestration platform, offers various features to manage and isolate workloads effectively. One such feature is Kubernetes Network Namespace. In this blog post, we deeply understood what Kubernetes Network Namespace is, how it works, and its significance in managing network communications within a Kubernetes cluster.

Section 1: Understanding Network Namespace

Kubernetes Network Namespace is a virtualized network stack that isolates network resources within a cluster. It acts as a logical boundary, allowing different pods and services to have their own network configuration and routing tables. Using Network Namespace, Kubernetes ensures that each workload operates within its defined network environment, preventing interference and maintaining security.

Section 2: Benefits of Kubernetes Network Namespace

One of the significant advantages of Kubernetes Network Namespace is enhanced network segmentation. By segregating network resources, Kubernetes enables better isolation, reducing the risk of network conflicts and potential security breaches. Additionally, Network Namespace facilitates improved resource utilization by efficiently allocating IP addresses and network policies specific to each workload.

Section 3: Working with Kubernetes Network Namespace

Administrators and developers can leverage various Kubernetes objects and configurations to utilize Kubernetes Network Namespace effectively. This includes creating and managing namespaces, deploying pods and services within specific namespaces, and configuring network policies to control traffic between namespaces. Understanding and implementing these concepts ensures a robust and well-organized network infrastructure.

Section 4: Best Practices for Kubernetes Network Namespace

While working with Kubernetes Network Namespace, following best practices is crucial for maintaining a stable and secure environment. Some recommendations include properly labeling pods and services with namespaces, implementing network policies to control traffic flow, regularly monitoring network performance, and considering network plugin compatibility when using third-party solutions.

Conclusion:

Kubernetes Network Namespace is vital in managing network communications within a Kubernetes cluster. By providing isolation and segmentation, it enhances security and resource utilization. Understanding the concept of Network Namespace and following best practices ensures a well-structured and efficient network infrastructure for your Kubernetes deployments.