Try   HackMD

Kubernetes Networking

Networking is a crucial component in Kubernetes. Pod-to-Pod networking also known as cluster networking is central part of Kubernetes and is focus of this guide. Kubernetes dictates the following requirements on cluster networking.

  • Pods scheduled on the same node must be able to communicate with other Pods without using NAT (Network Address Translation).
  • All system daemons (background processes, for example, kubelet) running on a particular node can communicate with the Pods running on the same node.
  • Pods that use the host network must be able to contact all other Pods on all other nodes without using NAT.

The Kubernetes network model defines a “flat” network and uses an IP per Pod model to meet the above requirements. Every Pod gets its own IP address and communicates with other Pods using IP addresses, reducing the complexity of mapping container ports to host ports. A Pod is modeled as a group of containers that share a network namespace, including their IP address and MAC address. Containers within a Pod all have the same IP address and port space assigned through the network namespace assigned to the Pod, and can find each other via localhost since they reside in the same network namespace.

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

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, and configuration.

Kubernetes Network Model

There are many different ways to implement the Kubernetes networking model. One of the most common ways to implement the Kubernetes networking model is by using the CNI (Container Networking Interface) API. CNI (Container Network Interface) is a standard API which allows different network implementations to plug into Kubernetes. CNI consists of a CNI specification, a set of references, and sample plugins. There are many different kinds of CNI plugins, but the two main ones are:

  • Network plugins: responsible for adding or deleting pods to/from the Kubernetes pod network. This includes creating/deleting each pod’s network interface and connecting/disconnecting it to the rest of the network implementation.
  • IPAM (IP Address Management) plugins: which are responsible for allocating and releasing IP addresses for pods as they are created and deleted. Depending on the plugin, this may include one or more interfaces and ranges of IP addresses (CIDRs) to each node, allocate to pods.

The CNI plugin is selected by Kubelet when –network-plugin command-line option is set as CNI. Kubelet reads a file from –cni-conf-dir (default /etc/cni/net.d) and uses the CNI configuration from that file to set up each Pod's network. The CNI configuration file must match the CNI specification (v0.4.0) and any required CNI plugins referenced by the configuration must be present in –cni-bin-dir (default /opt/cni/bin). If there are multiple CNI configuration files in the directory, the kubelet uses the configuration file that comes first by name in lexicographic order.

Last changed by 
 
sheetjos
11
101

Read more

Prefix Mode (v2)

In the default mode of the VPC CNI, without prefix delegation, singular IP addresses are assigned to ENIs. With prefix delegation, a range of IP addresses is assigned to an ENI. Traffic to an address within the assigned range is directed to the ENI. This greatly increases the number of IP addresses, and thus pods, that may be on a single node. More specifically, you can assign a private CIDR range (network prefix) to your network interfaces (ENIs) on EC2 instances. IPv4 and IPv6 ranges may be assigned to an ENI. The prefix assignments may be manually or automatically managed. Amazon VPC CNI assigns network prefixes to Amazon EC2 network interfaces to increase the number of IP addresses available to nodes and increase pod density per node. You can configure version 1.9.0 or later of the Amazon VPC CNI add-on to assign IPv4 and IPv6 CIDR instead of assigning individual IP addresses to network interfaces. [[GDC: JC do you prefer "ENABLE_PREFIX_DELEGATION is set to true" as the first line (techincal accuracy) or "When prefix delgation is enabled" (more general, users should follow the link to learn how to enable)]]

Jul 5, 2022
VPC Considerations (v2)

Operating an EKS cluster requires knowledge of VPC networking, in addition to Kubernetes networking. We recommend you understand the EKS control plane communication mechanisms before you start to plan your VPC or use existing VPCs to create Kubernetes clusters. Refer to Cluster VPC considerations and Amazon EKS security group considerations when architecting a VPC and subnets to be used with EKS. [[GDC: SJ & JC - I'm skeptical that the below section is relevant to the BPG. It's more than a general introduction to the reccomendations. The customer and AWS VPCs are a key part of EKS.]] EKS Control Plane Communication An EKS cluster consists of two VPCs:

Jul 5, 2022
Amazon EKS Best Practices Guide for Networking (v2)

It is critical to understand Kubernetes networking to operate your applications efficiently. This section of the EKS Best Practices advises on different cluster networking modes. How to use this guide? This guide introduces the Amazon VPC Container Network Interface (CNI) in the context of Kubernetes networking. The VPC CNI is highly configuable to support different use cases. This guide further includes dedicated sections on different VPC CNI use cases, operating modes, and sub-components. Generally, the VPC CNI plugin coordinates VPC resources with a Kubernetes Cluster. THE VPC CNI implements Kubernetes networking concepts using native AWS resources. Kubernetes Networking

Jul 1, 2022
Configuring Multus on EKS

A CNI is the container network interface that provides an application programming interface to configure network interfaces in containers. Multus CNI is a container network interface plugin for Kubernetes that enables attaching multiple network interfaces to Pods. In Kubernetes, each Pods has only one network interface by default, other than local loopback. With Multus, you can create multi-homed Pods that have multiple interfaces. Multus acts as ‘meta’ plugin that can call other CNI plugins to configure additional interfaces. Multiple network interfaces for Pods are useful in various use cases; examples include: Traffic splitting: Running network functions (NF) that require separation of control/management, and data/user plane network traffic to meet low latency Quality of Service (QoS) requirements. Performance: Additional interfaces often leverage specialized hardware specifications such as Single Root I/O Virtualization (SR-IOV) and Data Plane Development Kit (DPDK), which bypass the operating system kernel for increased bandwidth and network performance. Security: Supporting multi-tenant networks with strict traffic isolation requirements. Connecting multiple subnets to Pods to meet compliance requirements. What is a Multi-Homed Pods? The Multus CNI plugin allows Pods to have multiple interfaces in Kubernetes. The current version of EKS support for Multus bundles Amazon VPC CNI as the default delegate plugin (which is the only supported and validated default delegate plugin). The default delegate plugin configures the primary network interface (eth0) for Pods to enable Kubernetes control plane traffic, including the IP Address Management (IPAM) for the primary network interface for the Pods.

Jun 29, 2022
Read more from sheetjos
Published on HackMD