Choosing a Container-Native Network for Kubernetes

26 Oct 2020 1:26pm, by

Similar to container-native storage, the container-native network abstracts the physical network infrastructure to expose a flat network to containers. It is tightly integrated with Kubernetes to tackle the challenges involved in pod-to-pod, node-to-node, pod-to-service and external communication.

Kubernetes can support a host of plugins based on the Container Network Interface (CNI) specification, which defines the network connectivity of containers and deals with the network resources when the container is deleted. The CNI project is one of the incubating projects of the Cloud Native Computing Foundation.

Container-native networks go beyond basic connectivity. They provide dynamic enforcement of network security rules. Through a predefined policy, it is possible to configure fine-grained control over communications between containers, pods and nodes.

Choosing the right networking stack is critical to maintain and secure the CaaS platform. Customers can select the stack from open source projects including Cilium, Contiv, Flannel, Project Calico, Tungsten Fabric and Weave Net. On the commercial side, Tigera offers Calico Enterprise and an enterprise subscription of Weave Net can be purchased by contacting Weaveworks.

Managed CaaS offerings from public cloud vendors come with tight integration of the existing virtual networking stack. For example, Amazon Web Services has a CNI plugin for Amazon Elastic Kubernetes Service (EKS) based on Amazon Virtual Private Cloud (VPC), while Microsoft has built Azure Virtual Network Container Networking Interface (CNI) for Azure Kubernetes Service (AKS).

Table: Container-Native Networks
Container-Native Networks
Commercial Offerings Product Vendor
Calico Enterprise Tigera
Weave Net (contact Weaveworks for Enterprise subscription) Weaveworks
Open Source Projects Project CNCF Status
Cilium Not Submitted
Contiv Not Submitted
Flannel Not Submitted
Project Calico Not Submitted
Tungsten Fabric Not Submitted
Weave Net Not Submitted

Data from the 2019 CNCF survey provides further insight into cloud native networking.

Networking is a challenge that has declined over the years, although Kubernetes users continued to assess ingress providers. In fact, while a Kubernetes user had an average of 1.5 ingress providers, the 28% of respondents who cited networking as a challenge had on average 3 ingress providers. NGNIX was in 66% of Kubernetes stacks — but by itself, it wasn’t able to address the needs of all users. Adoption of HAProxy and Envoy was lower, but rose among those with networking challenges. This suggests that newer market entrants were adopted to address problems. Looking forward, expect offering to differentiate themselves based on the protocols they support and whether or not they include an API gateway.

Caption: Although involved with ingress, using NGINX with Kubernetes has little impact on networking challenges. Source: Survey question: What Kubernetes ingress provider(s) (i.e., service proxy) are you using? Please select all that apply.What are your challenges in using / deploying containers? Please select all that apply. The chart only shows data for offerings used by at least 1% of respondents with at least one Kubernetes cluster. n=1197.

Amazon Web Services and the Cloud Native Computing Foundation are sponsors of The New Stack.

This post is part of a larger story we're telling about Kubernetes.

Get the full story in the ebook

Get the full story in the ebook