Digital Garage supports the Kubernetes Container Network Interface (CNI) as the interface between the Digital Garage and Kubernetes. Software defined network (SDN) plug-ins are a powerful and flexible way to match network capabilities to your networking needs. Additional plug-ins that support the CNI interface can be added as needed.
The following network plug-ins are currently supported by Digital Garage:
Digital Garage deploys a software-defined networking (SDN) approach for connecting pods in an Digital Garage cluster. The OpenShift SDN connects all pods across all node hosts, providing a unified cluster network.
OpenShift SDN is installed and configured by default as part of the Ansible-based installation procedure. See the OpenShift SDN section for more information.
flannel is a virtual networking layer designed specifically for containers. Digital Garage can use it for networking containers instead of the default software-defined networking (SDN) components. This is useful if running Digital Garage within a cloud provider platform that also relies on SDN, such as OpenStack, and you want to avoid encapsulating packets twice through both platforms.
Digital Garage runs flannel in host-gw mode, which maps routes from container to container. Each host within the network runs an agent called flanneld, which is responsible for:
Managing a unique subnet on each host
Distributing IP addresses to each container on its host
Mapping routes from one container to another, even if on different hosts
Each flanneld agent provides this information to a centralized etcd store so other agents on hosts can route packets to other containers within the flannel network.
The following diagram illustrates the architecture and data flow from one container to another using a flannel network:
Node 1 would contain the following routes:
default via 192.168.0.100 dev eth0 proto static metric 100 10.1.15.0/24 dev docker0 proto kernel scope link src 10.1.15.1 10.1.20.0/24 via 192.168.0.200 dev eth0
Node 2 would contain the following routes:
default via 192.168.0.200 dev eth0 proto static metric 100 10.1.20.0/24 dev docker0 proto kernel scope link src 10.1.20.1 10.1.15.0/24 via 192.168.0.100 dev eth0
A router is one way to get traffic into the cluster. The F5 BIG-IP® Router plug-in is one of the available router plugins.
The F5 router plug-in integrates with an existing F5 BIG-IP® system in your environment. F5 BIG-IP® version 11.4 or newer is required in order to have the F5 iControl REST API. The F5 router supports unsecured, edge terminated, re-encryption terminated, and passthrough terminated routes matching on HTTP vhost and request path.
The F5 router has feature parity with the HAProxy template router, and has additional features over the F5 BIG-IP® support in Compared with the routing-daemon used in earlier versions, the F5 router additionally supports:
path-based routing (using policy rules),
re-encryption (implemented using client and server SSL profiles)
passthrough of encrypted connections (implemented using an iRule that parses the SNI protocol and uses a data group that is maintained by the F5 router for the servername lookup).
Passthrough routes are a special case: path-based routing is technically impossible with passthrough routes because F5 BIG-IP® itself does not see the HTTP request, so it cannot examine the path. The same restriction applies to the template router; it is a technical limitation of passthrough encryption, not a technical limitation of Digital Garage.
Because F5 BIG-IP® is external to the OpenShift SDN, a cluster administrator must create a peer-to-peer tunnel between F5 BIG-IP® and a host that is on the SDN, typically an Digital Garage node host. It is also possible to configure multiple such hosts and use the Digital Garage ipfailover feature for redundancy; the F5 BIG-IP® host would then need to be configured to use the ipfailover VIP for its tunnel’s remote endpoint.
The operation of the F5 router is similar to that of the Digital Garage routing-daemon used in earlier versions. Both use REST API calls to:
create and delete pools,
add endpoints to and delete them from those pools, and
configure policy rules to route to pools based on vhost.
Both also use
ssh commands to upload custom TLS/SSL certificates to
The F5 router configures pools and policy rules on virtual servers as follows:
When a user creates or deletes a route on Digital Garage, the router creates a pool to F5 BIG-IP® for the route (if no pool already exists) and adds a rule to, or deletes a rule from, the policy of the appropriate vserver: the HTTP vserver for non-TLS routes, or the HTTPS vserver for edge or re-encrypt routes. In the case of edge and re-encrypt routes, the router also uploads and configures the TLS certificate and key. The router supports host- and path-based routes.
Passthrough routes are a special case: to support those, it is necessary to write an iRule that parses the SNI ClientHello handshake record and looks up the servername in an F5 data-group. The router creates this iRule, associates the iRule with the vserver, and updates the F5 data-group as passthrough routes are created and deleted. Other than this implementation detail, passthrough routes work the same way as other routes.
When a user creates a service on Digital Garage, the router adds a pool to F5 BIG-IP® (if no pool already exists). As endpoints on that service are created and deleted, the router adds and removes corresponding pool members.
When a user deletes the route and all endpoints associated with a particular pool, the router deletes that pool.
The F5 appliance can connect to the Digital Garage cluster via an L3 connection. An L2 switch connectivity is not required between Digital Garage nodes. On the appliance, you can use multiple interfaces to manage the integration:
Management interface - Reaches the web console of the F5 appliance.
External interface - Configures the virtual servers for inbound web traffic.
Internal interface - Programs the appliance and reaches out to the pods.
An F5 controller pod has
admin access to the appliance. The F5 image is
launched within the Digital Garage cluster (scheduled on any node) that uses
iControl REST APIs to program the virtual servers with policies, and configure
the VxLAN device.
This section explains how the packets reach the pods, and vice versa. These actions are performed by the F5 controller pod and the F5 appliance, not the user.
When natively integrated, The F5 appliance reaches out to the pods directly using VxLAN encapsulation. This integration works only when Digital Garage is using openshift-sdn as the network plug-in. The openshift-sdn plug-in employs VxLAN encapsulation for the overlay network that it creates.
To make a successful data path between a pod and the F5 appliance:
F5 needs to encapsulate the VxLAN packet meant for the pods. This requires the sdn-services license add-on. A VxLAN device needs to be created and the pod overlay network needs to be routed through this device.
F5 needs to know the VTEP IP address of the pod, which is the IP address of the node where the pod is located.
F5 needs to know which
source-ip to use for the overlay network when
encapsulating the packets meant for the pods. This is known as the gateway address.
Digital Garage nodes need to know where the F5 gateway address is (the VTEP address for the return traffic). This needs to be the internal interface’s address. All nodes of the cluster must learn this automatically.
Since the overlay network is multi-tenant aware, F5 must use a VxLAN ID that is
representative of an
admin domain, ensuring that all tenants are reachable by
the F5. Ensure that F5 encapsulates all packets with a
vnid for the
admin namespace in Digital Garage) by putting an
annotation on the manually created
hostsubnet is manually created as part of the setup, which fulfills
the third and forth listed requirements. When the F5 controller pod is launched,
this new ghost
hostsubnet is provided so that the F5 appliance can be
The term ghost
The first requirement is fulfilled by the F5 controller pod once it is launched.
The second requirement is also fulfilled by the F5 controller pod, but it is an
ongoing process. For each new node that is added to the cluster, the controller
pod creates an entry in the VxLAN device’s VTEP FDB. The controller pod needs
access to the
nodes resource in the cluster, which you can accomplish by
giving the service account appropriate privileges. Use the following command:
$ oadm policy add-cluster-role-to-user system:sdn-reader system:serviceaccount:default:router
These actions are performed by the F5 controller pod and the F5 appliance, not the user.
The destination pod is identified by the F5 virtual server for a packet.
VxLAN dynamic FDB is looked up with pod’s IP address. If a MAC address is found, go to step 5.
Flood all entries in the VTEP FDB with ARP requests seeking the pod’s MAC address. ocated. An entry is made into the VxLAN dynamic FDB with the pod’s MAC address and the VTEP to be used as the value.
Encap an IP packet with VxLAN headers, where the MAC of the pod and the VTEP of the node is given as values from the VxLAN dynamic FDB.
Calculate the VTEP’s MAC address by sending out an ARP or checking the host’s neighbor cache.
Deliver the packet through the F5 host’s internal address.
These actions are performed by the F5 controller pod and the F5 appliance, not the user.
The pod sends back a packet with the destination as the F5 host’s VxLAN gateway address.
openvswitch at the node determines that the VTEP for this packet is the
F5 host’s internal interface address. This is learned from the ghost
A VxLAN packet is sent out to the internal interface of the F5 host.
During the entire data flow, the VNID is pre-fixed to be