As described in this blog post, we have recently launched a preview of our integration with the RedHat OpenShift platform, bringing the power of policy-driven networking to container-based application and microservices.
One of the important aspects of the Kubernetes-based platforms – like e.g. RedHat OpenShift — is the flexibility of using labels to describe application-level metadata. When used in conjunction with Nuage Networks Virtualized Services Platform, labels can be used to express, in an abstract way, very powerful network policies: Connectivity, QoS, traffic policies, RBAC (role-based access control) – these are just a few of the properties that can be expressed in an abstract form using labels.
Previewing this technology at DockerCon Europe 2015 in Barcelona, we introduced this technology in conjunction with low-level Docker containers. Together with our colleagues from Bell Labs EMEA, we presented how policy-driven SDN for Docker containers can be used for meeting the stringent requirements of telco applications.
In this post we describe the use of that technology using a new, experimental Docker SDN driver for Nuage Networks VSP. This plug-in is open-source, and offered “as-is” via GitHub.
Once the software repository is downloaded on a Docker host that also runs Nuage Networks VSP (in particular, a Nuage VRS – Virtual Routing and Switching), build the software as such:
go build
Once the plugin binary is built, run it in standalone, in “monitor” mode:
docker-vsp-plugin –d
This will allow the plugin to monitor Docker daemon operations, and connect containers to according to the specified network policy.
As an example, consider the following traditional “three-tier application – called 3-tier-app-v1” in the picture below — consisting of a “Backend”, “Frontend” and “Management” zones, each one consisting of a single IPv4 subnet:
In this environment, creating a single Docker container with multiple interfaces, each with network policies fully inherited from the application template is as simple as:
docker run -it –net=none –label=Nuage –label=Org=ORG1 –label=User=admin –label=eth0=3-tier-app-v1.Backend.BackendSubnetORG1 –label=eth1=3-tier-app-v1.Frontend.FrontendSubnetORG1 ubuntu
As a result, the Nuage Networks VSP instantiates this container and attaches those network interfaces to the application template, all in accordance to the interface metadata specified via the labels:
One thing to note here is that each interface has its own metadata information, independent on all other interfaces. In particular, the metadata hierarchy is expressed as: “<interface-name>=Nuage Domain-Name>.<Nuage Zone-Name>.<Nuage Subnet-Name>” hierarchy. Once that authorized to be created in the application template, full network policy are automatically applied to all interface, in accordance to the ingress and egress traffic rules pre-defined for the application (i.e. “network policies”)
While the plugin allows any number of interfaces for a given Docker container – and the above examples uses two interface — in accordance to the established practices of micro-segmentation we would recommend to keep that at a bare minimum (ideally, only one interface per Docker container)
To summarize, using run-time application metadata using labels (key-value pairs) allows very rich expressions of network policies. With its powerful policy engine and rich platform integration capabilities, Nuage Networks Virtualized Services Platform provides the full power of SDN and platform federation, be that bare-metal servers, virtual machines, Kubernetes / OpenShift pods or Docker containers.