Enterprise networking has been remarkably stable since the Internet revolution. Even the massive shift to x86 virtual machines embraced existing tools and processes. Spin up a new application instance? Here’s your IP address. Looking for that new service? Resolve its name via DNS. Everyone knew the basic requirements to deploy applications.
Why are containers causing so much confusion for enterprise networking? Is every enterprise about to become the next Facebook, with all the network redesign that implies? Why can’t enterprise networks operate as before while developers deploy containerized applications?
Before I turn to these questions, it’s worth mentioning that Diamanti started with the proposition that your existing enterprise network (predominantly layer 2) and its associated operational processes should operate smoothly when you adopt containers. Diamanti preserves the well-understood VM networking model whereby each VM has its own virtualized network interface, MAC address, and IP address. Or multiple interfaces, if you’d like. Each container may use DHCP and DNS just like a VM. Existing services like load balancers and firewalls just work. So too your operational processes.
VM and container networking
Traditionally, each virtualized application has its own VM with a dedicated OS and network stack. Servers and VMs connect to enterprise networks using layer 2, which means each OS instance usually has a single primary IP address. Therefore, each virtualized application is associated with that unique IP.
In contrast, each container on a server shares a common OS instance with other containers on that server. While each container’s access to the OS is restricted by namespaces and cgroups, there’s a common network stack running in the OS. And a common IP address. Existing tools and processes (e.g., DHCP and DNS) that were built on the assumption of a unique IP per application won’t work.
While numerous approaches have been implemented to address this fundamental container networking issue, they often require substantial changes to your existing network tools and processes. There are excellent blogsand resources on this topic. This table summarizes some of the tradeoffs.
| Approach | Benefits | Compromises |
|---|---|---|
| Port mapping (NAT) |
|
|
| Subnet per node |
|
|
| Overlay network |
|
|
| L3 edge routing |
|
|
Simple container networking for the enterprise
Whether from large or small enterprises, users I speak with don’t need to redesign a network that already meets their needs. Here’s how Diamanti approaches container networking:
- Seamless enterprise network integration. Connect to existing L2 switches without redesigning the network. Containers appear like VMs on the network. Each has a MAC and IP address per interface.
- Use existing network services. Work with existing DHCP, IPAM, and DNS. Developers already understand service discovery. Keep using familiar load balancers and firewalls.
- Easy network segmentation. VLANs and firewalls are well-understood and meet the needs of most enterprise organizations today. Place containers on multiple networks by security domain or workload profile. Segment management and data networks to ensure access to each container for monitoring and logging. When scale eventually becomes an issue, upgrade to VXLAN without a performance penalty.
- Container-to-container quality-of-service. Increasing container densities expose the potential for network performance issues as many traffic flows fight for latency and throughput. Leverage standard 10-gig Ethernet with configurable, real-time traffic priorities per container.
We welcome you to get involved. Diamanti participates in the container open source community on projects like Kubernetes and Mesos. Contact us to learn more about deploying containers with your existing network tools and processes.
Mark
@markbalch
