Though most of the enterprise is still just dipping its toes in the container water, cautiously venturing into...
Docker or Rocket in their development efforts, the software container technology space continues to evolve quickly. Consequently, the frontiers expand even more quickly than the baseline technology spreads.
Early adopters quickly realized a need to manage "pods" of service-providing software containers across clusters of host servers (virtual or physical) to deliver a given application. This led to the development of higher-level container management tools such as Kubernetes, Google's pod-and-cluster manager. (Other container managers include fleet and Docker Swarm.)
Now, the early adopters of Kubernetes (which just recently achieved its version 1 release status) have developed use cases around issues such as fault-tolerance, geospecificity and cloud bursting for software containers. These use cases make it clear that containers need to have pod/cluster management that is even more flexible with respect to how and where clusters are provisioned and how container pods utilize them. This has given rise to "Ubernetes," a (still mostly theoretical) manager of Kubernetes instances. The main goal of Ubernetes is to provide federation of Kubernetes clusters independent of their locations, and policy-driven deployment of software containers among and across them.
Where does software-defined networking (SDN) come in? Everywhere! Consider how containers make use of network virtualization -- one type of SDN -- to deliver communications among containers on a single host or within a cluster of hosts. So, too, will cluster federation need to use virtualization to provide transparent communications among clusters hosted in different resource pools. That is, in order for services within one pod to talk to each other as though local to the same host, even when software containers are not all running in the same infrastructure (and so share no physical network at all), Ubernetes will need to manage virtual networks spanning the clusters.
So, for example, consider an application that manages medical records. When asked to provide services to a person in a location such as Germany, which has strict limits on where such data can reside, the response to that request may trigger the cluster manager to spin up a cluster in a German data center or in a German availability zone from a cloud infrastructure as a service provider. All data associated with the German user's session and all handling of that data can then take place within that area, from the user perspective. All subsequent service requests for Germany can be routed to that set of containers, as well. Because the cross-cluster orchestration layer can provision a virtualized network that can tunnel across the Internet to connect pods wherever they are running, the application can continue to run as a cohesive whole. From the perspective of any software containers in the service pod, all services appear to be within the same network.
Ubernetes is still in its early evolution, and much about it will change, but SDN principles and techniques will continue to be at its core.
Containers can create network challenges at scale
What does containerization mean for SDN?
Dealing with container networking hurdles