What follows here is a short write-up of our experiences from running OpenShift on OpenStack. Inspiration for writing this blog and highlighting the need for it is credited to Alberto Garcia Moyano.
Why would I run OpenShift on OpenStack?
The first question to ask is, what is the your cloud vision? Are you happy with _just_ running containers or do you have a broader vision for your future IT environment of which OpenShift should be a part of?
A thing to keep in mind here is that although it’s a great technology, containers are not the answer to every problem an IT organization might have. Some workloads are just not very suitable for running in a container, and forcing them into one will result in a sub-optimal solution. And even when just considering container workloads, they most often don’t run in isolation, they need to interact with other components of an IT infrastructure such as networking, storage and what-not. And that’s where an Infrastructure-as-a-Service solution such as OpenStack comes in. And in such a vision, OpenShift should be part of it and not just a component on the side, running on traditional, legacy infrastructure.
Another aspect is that OpenShift can and should consume Infrastructure as a Service for improved scalability and efficient management.
With the recent integration of OpenStack Cinder in OpenShift, whenever there is a need for a persistent volume in an OpenShift Pod, OpenShift can access OpenStack Cinder to dynamically create one. Also scalability of the OpenShift environment itself can be greatly simplified if additional OpenShift nodes easily can be spun up on an OpenStack cloud without manual intervention from a hardware team, storage administrators or operators of a traditional virtualization solution.
How do I run OpenShift on OpenStack?
So what does OpenShift require from an underlying OpenStack cloud? As it turns out, not a whole lot, a default, out of the box OpenStack deployment (whatever that might be…) is very much a suitable platform for running OpenShift. Below are some items which however are worth considering.
OpenShift has it’s own SDN layer, encapsulating network traffic in a VXLAN tunnel. And so does OpenStack, by default tenant networks are also made up of VXLAN tunnels. And while it’s not pretty having a VXLAN tunnel encapsulated inside another VXLAN tunnel, apart from the overhead of an additional VXLAN header and the decreased MTU it implies, we’ve found that it works perfectly fine.
As an alternative, OpenStack can also be configured to use e.g. VLAN:s instead of VXLAN for network segmentation, this way avoiding double-VXLAN-tunnels.
OpenShift can make use of the OpenStack Cinder service for dynamically creating persistent volumes when requested by an application running in OpenShift. This way, storage provisioning can be automated and dependency on storage administrators reduced.
Container Registry backed by OpenStack Swift object storage
The OpenStack Swift object storage service can with recent versions of OpenShift be used as a storage backend for the container registry which is part of OpenShift, providing a highly efficient and scalable storage solution.
When deploying OpenShift on OpenStack, the OpenStack Heat Orchestration engine can be utilized to automate the deployment and also to automatically scale the OpenShift infrastructure up and down based on the current load of the system. This deployment method is described in detail in chapter 6 of the Deploying Red Hat OpenShift Container Platform 3 on Red Hat OpenStack Platform reference architecture.
What is missing?
So is the integration between OpenShift and OpenStack seamless, can they be seen as a fully-integrated solution? Well, maybe not quite yet, my main wish-list item is regarding network integration between OpenShift and OpenStack, something which currently is being worked on.
As mentioned above, both OpenStack and OpenShift manage an SDN, resulting in an extra encapsulation layer and unneeded complexity. If those SDNs could be merged, i.e. if OpenShift could consume an OpenStack Neutron network instead of setting up its own SDN, it would allow containers and OpenStack instances (and also Red Hat Virtualization VM:s) to run on the same tenant networks. This would enable some truly hybrid-application use-cases where part of an application is containerized while another part could still run on OpenStack instances or traditional VM:s.
Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn