Containers have emerged over the past several years to provide an efficient method of storing and delivering applications reliably across different computing environments. By containerizing an application platform and its dependencies, differences in OS distributions and underlying infrastructures are abstracted away.
Networking has emerged as a critical element within the container ecosystem, providing connectivity between containers running on the same host as well as on different hosts, says Michael Letourneau, an IT architect atLiberty Mutual Insurance. “Putting an application into a container automatically drives the need for network connectivity for that container,” says Letourneau, whose primary focus is on building and operating Liberty Mutual’s container platform.
Virtualization evolution
Container networking is part of an evolution in thevirtualizationof storage, compute and networking technologies that began over a decade ago with PC/machine virtualization. “Early on, it was recognized that virtualization of the physical machine had all sorts of benefits around cost, speed and ease of development,” says Thomas Nadeau, technical director ofnetwork function virtualizationat open-source software provider and IBM subsidiary Red Hat.
With virtualization, hardware resources are shared by virtual machines, each of which include both an application and a complete operating system instance. A physical server running three VMs, would, for example, feature a hypervisor accompanied by three separate operating systems running on top. On the other hand, a server supporting three containerized applications requires just a single operating system, with each container sharing the operating system kernel with its companion containers.
While a VM with its own complete operating system may consume several gigabytes of storage space, a container might be only be tens of megabytes in size. Therefore, a single server can host many more containers than VMs, significantly boosting data-center efficiency while reducing equipment, maintenance, power and other costs.
Following the right container-networking approach is critical to long-term success.
Choosing the right approach to container networking depends largely on application needs, deployment type, use of orchestrators and underlying OS type. “Most popular container technology today is based on Docker and Kubernetes, which have pluggable networking subsystems using drivers,” explains John Morello, vice president of product management, container and serverless security at cybersecurity technology provider Palo Alto Networks. “Based on your networking and deployment type, you would choose the most applicable driver for your environment to handle container-to-container or container-to-host communications.”
“The network solution must be able to meet the needs of the enterprise, scaling to potentially large numbers of containers, as well as managingephemeral containers,” Letourneau explains.
The process of defining initial requirements, determining the options that meet those requirements, and then implementing the solution can be as important choosing the right orchestration agent to provision and load balance the containers. “In today’s world, going with aKubernetes-based orchestrator is a pretty safe decision,” Letourneau says. “The question of what to use as the networking layer is a more nuanced conversation, and is driven not only by scale, but by features required.”
When transitioning to containers, the main goal is to create a distributed architecture comprised of microservices, which are applications structured as collections of loosely coupled services, says Chris Meyer, a senior integration architect forBlueCat Networks, an IP address-management, DNS, and DHCP services provider. “By utilizing microservices, one can have a more fault-tolerant and easy-to-upgrade application that is broken down in core pieces,” he says.
This is where the networking plays an important role. “Traditionally, one would have to connect each container together as if it were a normal networking device, reaching out over the network and paying the expenses of needing to leave the interface and come back in,” Meyer says.
Such an approach introduces additional complexities, such as having to worry about issues created by firewalls. “By utilizing the latest in container networking tech, one can link containers together in such a way that it appears to be running on the same interface,” he says. “This is a huge benefit, because not only can all the pieces of your architecture talk to each other easily and quickly, they can be distributed across different machines in different data centers.”
Some common container-networking options to choose from are bridge, overlay, host and Macvlan, as described in an InfoWorld article by Serdar Yegulalp:
Bridge networks enable containers running on the same host to communicate with each other, but the IP addresses assigned to each container are not accessible from outside the host. A new instance of Docker comes with a default bridge network, and all newly started containers automatically connect to it. Out-of-the-box defaults will require fine-tuning in production. For example, custom bridges enable features that aren’t automatic in default mode, including DNS resolution; the ability to add and remove containers from a custom bridge while they’re running; and the ability to share environment variables between containers.
Overlay networks are for containers running on different hosts, such as those in a Docker swarm. In an overlay network, containers across hosts can automatically find each other and communicate by tunneling network subnets from one host to the next; an enterprise doesn’t have to set that up for each individual participating container. Production systems will typically require creating a custom overlay network.
In a host network, the host networking driver lets containers have their network stacks run side by side with the stack on the host. A web server on port 80 in a host-networked container is available from port 80 on the host itself. Speed is the biggest appeal of host networking, but it comes at the cost of flexibility: If you map port 80 to a container, no other container can use it on that host.
A Macvlan network is for applications that work directly with the underlying physical network, such as network-traffic monitoring applications. The macvlan driver doesn’t just assign an IP address to a container, but a physical MAC address as well. Macvlan is generally reserved for applications that don’t work unless they rely on a physical network address.
Connectivity isn’t the only consideration. Different modes of container networking support different networking capabilities. For example, a bridge network leverages network address translation (NAT), which comes with a performance cost. A host network eliminates the need for NAT but introduces potential port conflicts. Other features that vary among networking approaches include IP address management (IPAM), IPv6, load-balancing, and quality of service.
In addition, enterprises need to contend with differences in the ways that container runtimes, orchestrators and plugins handle networking. For example, Docker and Kubernetes have different models for how network resources are allocated and managed. Kubernetes-based Container Network Interface (CNI) plugins that work with Docker’s networking controls can help bridge the gap. CNI plugins are designed to link container runtimes to dozens of different container-network implementations.
