Red Hat’s OpenShift vs FreeBSD Jails

FreeBSD jails can be considered the start of modern containerization and process separation, but it can be hard to understand how FreeBSD jail technologies such as VNET relate to modern container products.  

Container terminology is a bit of a mess 

Container terminology is an unfortunate soup of names, products and company names mixed together with actual technologies—sometimes the same term can be all of these three things, and sometimes it can be a rebranding for a modification to one component. 

When looking at modern micoservice platforms from the top it is very easy to get lost in the details of the distributed architecture and become confused about which of the core pieces make up the code that is run. 

What is OpenShift? 

Red Hat’s OpenShift is an Enterprise Kubernetes Platform designed to work in Open Hybrid Cloud environments.  OpenShift offers a flexible environment for Day 1 (installation and set up) and Day 2 (ongoing maintenance and updates) operations tasks, and is flexible over a range of hosting environments. More specifically, OpenShift is a high level tool for managing an entire fleet of microservices—but it’s only one building block in a tower of technologies that allow operators to have control of clusters of resources. 

OpenShift is deployed by all of the Fortune Global 500, which stands as a testament to the penetration its technology stack has managed to achieve. If you are tasked to understand how OpenShift relates to other technologies like FreeBSD jails, it can be difficult to figure out where the product names end and where the actual tech starts. 

This article aims to demystify OpenShift a little and relate the technical components of a typical stack back to the FreeBSD core technologies and tools which serve as equivalents to those in the OpenShift technology stack. 

Building Block: Containers 

The power in a modern microservice platform comes from both its lowest building blocks and from the tooling that enables automated deployment and management of resources across a cluster of compute resources. 

The low level components of the microservice platform are tied to the Operating System’s implementation of them—but as we move up to the management layers, these can be decoupled from the lower level technologies and applied across a larger range of lower level primitives. 

The lowest layer in this stack is the containerization technology, something that is also called Operating System Level Virtualization. This is the technology that allows a single running instance of an operating system kernel—like the FreeBSD Kernel or the Linux Kernel—to host multiple distinct and separated instances of child host systems. 

FreeBSD Jails implement Operating System Level Virtualization, in the form of a separate environment that can be created as a process on a host system. Coupled with VNET, jails can be given an entirely isolated network stack.  Jails with VNETs can be created as very minimal environments, or they can be given access to more of the host’s information—a powerful range of configuration styles which can be managed by their sysadmins and architects.  

FreeBSD jails can and do implement separated build environments, are powerful hosting environments for network services, and can leverage the power of ZFS to be integrated into highly reliable systems. FreeBSD jails act as a security mechanism and offer a high level of protection for different services being run on the same host. 

Operating System Level Virtualization is implemented on Linux using a few technologies, particularly cgroups and Linux Namespaces. These technologies also allow the creation of separate process environments, inside which a host operation system can be run. In Linux environments, it is typical to run a very stripped down system; specialized Linux operating system distributions target this containerized environment by offering minimal installations which come with only the required packages installed. 

Because of the installation size difference between host platforms and the child containers they run, specific services are commonly packaged up as single images. These containerized images may then be deployed as is, or customized to increase functionality. One example of such a package might be a webserver such as nginx, packaged and installed in an Alpine Linux image, which is then launched in its entirety as a minimal service. 

Building Block: Cluster Management 

Treating containers as discrete components allow an explosion in the number of services that can be provided by a single host, whether that host is running on bare metal, or is a virtual machine itself. With a geometric increase in the number of tasks a host can be put to, it becomes a challenge to deploy and run services, and to manage the hosts that the services run on effectively. 

The power of microservice environments comes from their simple deployment, and the ability to scale up and down dynamically—individual service instances can be created and destroyed as needed without the platform as a whole suffering. 

Kubernetes itself is a cloud scheduler, designed to manage container based microservices and their dependencies on a cluster of hosts. It manages the entire lifecycle of containers on the cluster. Kubernetes allows the operator to make the best use of the available compute, network and storage resources at their disposal. 

Previously, Kubernetes containers were created by the docker tooling, but as of version 1.20 the container format has moved to Container Runtime Interface (CRI) based images. Containers are effectively a filesystem image containing a snapshot of an OS installation and metadata required to deploy and manage them. 

Building Block: Enterprise Kubernetes Platform 

The final building block to get us to OpenShift is the Kubernetes Enterprise Platform. Kubernetes has the ability to connect and control containers running on a variety of different backends, but managing the backend cluster’s hosts themselves can be a lot of work.  

Rather than all users of kubernetes having to run these hosts directly, cloud providers offer many products that integrate kubernetes with the provider’s virtual machine and bare metal instance management code. These tools hide the management of the cluster, making it easy to deploy apps and services on kubernetes without worrying about the layers beneath it. 

However, cloud provider tools come with significant vendor lock in. If you build your infrastructure with Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), IBM Cloud Kubernetes Service (IKS) or any of the other host of provider-specific platforms, you are tied to using the cloud backend those services support. 

Red Hat’s OpenShift offers the features of an enterprise Kubernetes platform, but doesn’t lock you into using their cloud offering (Red Hat OpenShift Container Platform). OpenShift extends beyond services like Amazon Elastic Kubernetes Service (which can allow on-premises operation), and allows both hybrid cloud (running both in the cloud and on your own hardware) and  multicloud (running on multiple providers’ clouds) deployment. 

Jails vs OpenShift 

OpenShift is a high level interface for managing a large number of container instances,offering the ability to create and manage all of the microservices for a large organization.  

FreeBSD Jails are a core technology, similar to the lower layers operating beneath OpenShift. It is entirely possible for someone to replace the lower layers of a Kubernetes platform—the containers—with FreeBSD technologies. There are in fact several projects that do this already, such as POT—a FreeBSD cluster manager that we have discussed before. 

At the time of writing, FreeBSD is getting much closer to being able work in Linux container environments;  support for an OCI-compatible runtime for FreeBSD jails is improving rapidly. This work will enable development and operations workflows using FreeBSD’s jails as a component in the same way that Linux containers are.  

Once this is possible it becomes easier and easier to add the ability to run native FreeBSD containers—and the infrastructure is almost ready. 

OpenShift and FreeBSD jails are technologies that work at very different layers—jails serve the same purpose as containers, not much higher level management systems like OpenShift itself. But there is a possible and exciting future where OpenShift is able to drive FreeBSD jails, and the necessary infrastructure is getting close to working.  

Once that infrastructure is complete, it will be possible to extend OpenShift with more platforms—improving diversity and making high quality FreeBSD tools available in microservice architectures.