Kubernetes requires third-party plugins to handle networking within and across pods and clusters. Organizations have historically taken a do-it-yourself approach to networking using open source tools. Networking challenges are magnified in complex environments such as multicloud/multicluster deployments, where workforces tend to lack the skills for it. Although building networking solutions using open-source container networking interfaces (CNIs), ingress controllers, and service meshes has worked well enough up to now, there is a growing advantage in leveraging enterprise-grade tools for managing container networks.

This situation mirrors the mid-2010s, when enterprises adopted a DIY approach to managing cloud networks. But as cloud service providers began offering native networking functions, organizations encountered significant challenges in managing networks across different cloud providers. The market quickly saw the need for cloud networking solutions that could enable connectivity across hybrid and multicloud environments.

Container networking is undergoing a similar transition—although managing cloud networking across different providers was difficult, orchestrating clusters of containers across various cloud environments proves significantly more challenging.

Unlike cloud providers, which natively offer virtual networking appliances that can be set up with GUIs and are documented by the cloud providers themselves, container networking has largely been driven by community efforts, with scant prescriptive guidance on how the network must behave.

A DIY approach to container networking is much more complex than cloud networking. Container networking necessitates knowledge of both container runtimes and orchestration platforms and requires multiple third-party plug-ins such as CNIs and ingress controllers. This is a completely different kettle of fish than what networking folks are used to dealing with, having followed a training path consisting of certifications such as CCNA/CCNP or Network+.

These certifications include very few details about real-world use cases of dealing with networking in Kubernetes or other container runtimes and orchestration systems. CNIs, ingress controllers, service meshes, and network models are generally foreign concepts to network administrators.

So the networking burden often falls on DevOps teams, which have not traditionally been (and should not be) responsible for network deployment and management. To manage effectively, they must acquire knowledge spanning Layers 3 to 7, border gateway protocol (BGP), subnetting, network address translation (NAT), and the like, but that’s a fairly long training path.

A container networking solution can help level the playing field in terms of the skills required and team responsibilities. Specifically, in exchange for a paid plan you get:

• Graphical user interfaces
• Extensive policy definition engines
• Security that goes beyond allow/block rules
• Analytics and observability
• Multicluster capabilities
• Advanced routing capabilities

The container networking space, primarily driven by open source projects, presents challenges in defining exactly which capabilities an enterprise-grade container networking solution should offer and identifying vendors capable of effectively delivering them.

Historically, organizations have looked at open source CNIs to make a start on Kubernetes networking. Cilium and Calico are some of the most widely deployed CNIs, and their enterprise-grade versions are an obvious choice for many organizations. This is especially true as several CNIs—such as Flannel, Canal, or kube-router—lack an enterprise-grade plan, and others—such as Tungsten Fabric and Weave Net—have been discontinued and are no longer supported.

Business Imperative
To address Kubernetes networking, observability and security requirements, users typically require numerous tools, including CNI, service mesh, observability platform, multicluster (such as Submariner or Skupper), ingress gateway (such as Nginx), bare-metal load-balancer (such as MetalLB), and multi-NIC meta plugin (such as Multus). Container networking solutions bring most, if not all, of these functionalities natively, simplifying cluster management.

Sector Adoption Score
To help executives and decision-makers assess the potential impact and value of deploying a container networking solution, this GigaOm Key Criteria report provides a structured assessment of the sector across five factors: benefit, maturity, urgency, impact, and effort. By scoring each factor based on how strongly it compels or deters adoption of a container networking solution, we provide an overall Sector Adoption Score (Figure 1) of 3.6 out of 5, with 5 indicating the strongest possible recommendation to adopt. This score positions a container networking solution as a credible candidate for deployment and worthy of thoughtful consideration.

The factors contributing to the Sector Adoption Score for container networking are explained in more detail in the Sector Brief section that follows.