Load Balancers and Routers

One challenge that OpenStack has had to deal with on a regular basis as a virtualization solution and as cloud software is the integration of external appliances into the cloud, such as firewalls or classic load balancers from Palo Alto Networks or F5 Networks [8]. Because OpenShift builds a cloud and uses software-defined networking (SDN), at least to some extent, it faces a real problem: The physical appliance somehow has to be integrated into the customer's virtual network, although it is not visible in the underlay.

Using F5 as an example, Red Hat has now demonstrated in OpenShift that external appliances can be integrated into SDN. If you have an F5 with BIG-IP DNS version 11.6 or higher, you can use it not only as an external firewall in OpenShift, but also directly on your container network as a router.

However, first and foremost, it is of interest for companies that operate their own OpenShift installations or create such setups for customers. Red Hat doubtfully will be able to fulfill such special requests in the public OpenShift cloud, for example. However, if you are upgrading a private OpenShift installation and are already using F5, the combination of the two technologies provides a more elegant solution for routing and load balancing than is possible with the available OpenShift tools.

Of course, it is also aimed at those companies that have to use external routers or load balancers for compliance reasons and are committed to F5 in this respect. Thanks to the new functions, which became fully available for the first time in OpenShift 3.1, the chance to use OpenShift has now been opened up for those with compliance commitments.

Multicast for Pods

Another groundbreaking innovation, at least for many applications, is that Kubernetes can now handle multicasts between many pods. Until now, multicast traffic could be sent from the source, but everything stopped at the pod border, meaning that multicast traffic could never reach its destination.

Multicast traffic isn't very popular with network administrators anyway – in fact, many people get annoyed when they hear the word – but this does not change the fact that some software relies on multicast for operations (e.g., when it comes to service discovery or exchanging large amounts of data between many clients).

Current versions of OpenShift offer such applications a home for the first time. In the 3.6 version, the feature is no longer a technology preview; it can be used officially in production setups. Multicast can now be enabled individually for a project.

Network Policies for More Security

The security groups available in OpenStack are very popular with the OpenStack user community. Simply put, they provide an iptables-based approach to restricting access to individual VMs. For example, the default security group allows traffic to the outside world but does not allow incoming traffic. OpenShift did not have a feature comparable to security groups in its program. Kubernetes itself provides a network policy flag as a possible object for pod definitions, but OpenShift ignored it and didn't use it until recently.

In OpenShift 3.5, the developers deliver at least part of the feature. Although it is still marked as a Technology Preview and only works in setups based on Open vSwitch, the range of functions on offer is considerable. In fact, network policy in Kubernetes replicates what security groups in OpenStack have been able to do for years. If you enable the flag for a pod, it automatically blocks all incoming traffic except for the exceptions you define explicitly.

It will probably take some time before OpenShift fully supports network policy and officially releases it for production. However, a start has been made, and those of us who need appropriate packet filters, for compliance reasons in particular, will be happy about the new possibilities.