At VSHN and APPUiO.ch we rely on OpenShift as Kubernetes distribution. What a Kubernetes distribution is, why we use it and where the differences to ‘plain’ Kubernetes will be explained in this blog post.
What is Kubernetes?
The official description of Kubernetes is:
Kubernetes is a portable, extensible open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation.
The most important part of this description is the fact that Kubernetes is a platform and not a ready off-the-shelf product. This is an important piece of information for understanding this article.
What is a Kubernetes distribution?
To understand the differences between Kubernetes and OpenShift, first of all we have to clarify the term ‘Kubernetes distribution’: if Kubernetes is installed directly from the open source Kubernetes project, you ‘only’ get the core components (API server, controller manager, scheduler, Kubelet, kube-proxy). In order for Kubernetes to be really usable, you need a lot of other components like etcd, ingress controller, logging server, metrics collector (for example Prometheus), software defined network (SDN) and many more. This is very similar to Linux: the Linux kernel alone does not help much, you need a whole Linux distribution which provides a shell, package management, boot process and much more.
OpenShift is a Kubernetes distribution and makes Kubernetes a product
A ‘minimum viable Kubernetes distribution’ requires the following additional components and tools for productive operation:
- Installation and upgrade mechanism: for an automated installation of all involved components.
- SDN (software defined network): pods must be able to communicate with each other no matter where they are running. The SDN ensures that.
- Ingress controller: to allow user access to applications running on the cluster.
- Authentication: a central user and group database provides the authenticated and authorized access.
- Security: Kubernetes executes containers via Docker or CRI-O. The security on the host system must be ensured accordingly.
- Persistent storage: stateful applications such as databases require persistent storage.
- Monitoring: constant monitoring of all cluster components and applications.
- Backup: backup of cluster components and persistent data.
Optionally, further components are recommended:
- Central logging with graphics and searchability
- Application and cluster metrics including alerting
OpenShift as Kubernetes distribution
Essentially, OpenShift relies 100% on Kubernetes, but as a Kubernetes distribution, it comes with everything needed for a Kubernetes cluster. To name just the most important functions:
- Operations tools: an official and supported way via Ansible allows the entire lifecycle of OpenShift to be executed. This includes the automated installation, as well as upgrades to newer versions of OpenShift.
- Router: the OpenShift router (ingress controller) – based on HAProxy – ensures that access to applications within the cluster is made possible via HTTP(S).
- Multi-tenancy: multi-tenancy is built-in the core on OpenShift projects, RBAC and other concepts to allow the use of the platform by various stakeholders.
- Authentication: the most different authentication backends are supported, above all LDAP, Active Directory (AD) and others.
- Metrics: the bundled metrics component collects all available data (RAM, CPU, network) of the applications running on the cluster and visualizes them in the web console.
- Central logging: all lines logged by the application on
stdoutare automatically collected by the central logging component and are made available to the user via the web console.
- Security: the platform is designed for maximum security. For example, security measures in the kernel of Red Hat Enterprise Linux like SELinux ensure that the security of the containers is guaranteed. Further measures such as ‘security context constraints’ (SCC) and the prevention of root containers ensure further security.
- Builds and pipelines: directly in the cluster integrated build and pipeline capabilities enable a fully integrated CI / CD workflow.
- Web console: all operations on the cluster are visually displayed to the user of the platform in a web console and allow an easy and quick access to the use of Kubernetes.
- SDN: the included software defined networking provides connectivity between the pods running on the platform and for an adequate network security with network policies.
- Container registry: Docker / container images are stored in the bundled registry and used for deployment onto the worker nodes.
All these built-in functionalities can be added to any Kubernetes cluster, but only with a lot of effort. Comparable to building your own Linux distribution, as for example Linux From Scratch demonstrates. Kubernetes has a similar guide called Kubernetes The Hard Way.
OpenShift as PaaS
The strength of Kubernetes lies in the container orchestration. In addition, OpenShift offers classic Platform-as-a-Service (PaaS) functionalities. One of these is the automatic building and deployment of application code directly from a Git repository. Nevertheless, as a user of the platform and thanks to its great flexibility, you always have the choice of whether you want to use the integrated build functions, or rather build outside the cluster. This can be chosen for each deployment, so both types can be used on one cluster.
OpenShift as upstream to Kubernetes
Many developments in Kubernetes originally came from OpenShift. The best example is RBAC (role based access control). This feature has been part of OpenShift since the first release and has been gradually integrated into Kubernetes. RBAC has been an integral part of Kubernetes since Kubernetes version 1.6. The OpenShift ‘Route’ or the ‘DeploymentConfiguration’ object also played a key role in the current objects ‘Ingress’ and ‘Deployment’ in Kubernetes.
Since OpenShift is 100% based on Kubernetes, all Kubernetes native workloads are also supported, such as the ‘Deployment’ or the ‘Ingress’ object.
If you look more closely at the contributor statistics, you’ll find that Red Hat is one of the top 3 contributor companies, so Red Hat is crucial in the development of Kubernetes. With the purchase of the company CoreOS, Red Hat has acquired formidable Kubernetes know-how. The merger of OpenShift and Tectonic will be the next milestone of the Kubernetes distribution OpenShift.
Alternatives to OpenShift
OpenShift is not the only Kubernetes distribution on the market. A quick comparison shows the differences:
- Cloud vendor Kubernetes: the big clouds offer their own Kubernetes distributions as a service. These are tailored to the respective cloud and are maintained by the providers. Installation on your own private cloud or on other public clouds is not possible.
- Rancher: since version 2.0, Rancher focuses 100% on Kubernetes and offers a multi-cluster management function as a major strength. With Rancher, Kubernetes clusters in the cloud (for example, on Amazon or Google) can be managed centrally, as well as Kubernetes clusters with the ‘Rancher Kubernetes Engine’ on your own VMs. With the web interface, setting up a new cluster is very easy and application deployments using Helm are also directly available.
- Tectonic: this distribution lies great importance on cloud-native automation. Through Red Hat’s acquisition of CoreOS, Tectonic will be merged with OpenShift and many of its features will inserted into OpenShift.
- Canonical / Ubuntu Kubernetes: platform based on Ubuntu, which uses Juju as installation tool. In partnership with Google and Rancher, a hybrid cloud solution will be offered in the future.
- SUSE CaaS platform: a very new platform based on SUSE MicroOS. Salt is used to ensure configuration management. Under the following link you can participate in the beta program: SUSE CaaS Platform Beta.
Further Kubernetes distributions include:
- Kontena Pharos
- Cisco Container Platform
- And even more from the Kubernetes documentation: Picking the Right Solution
One very important aspect to consider is the cloud and / or vendor lock-in. Many of the Kubernetes distributions have their own characteristics, which may not be compatible with each other. Using the example of ‘cloud vendor’ distributions: these can only be used in the corresponding cloud. However, if you want to pursue a hybrid cloud approach, this is not possible due to the lock-in. In contrary, a self-installable distribution like OpenShift makes this option possible.
Pure open source distributions without manufacturer support are not recommended for productive environments, as this is of great advantage for a complex platform like Kubernetes.
APPUiO – Swiss Container Platform
The attentive reader may have noticed that there are some discrepancies between the ‘minimum viable Kubernetes distribution’ and OpenShift. This is exactly where APPUiO comes in: we refine OpenShift into a comprehensive, production-ready Kubernetes distribution by offering managed services. We automatically monitor and secure the cluster status, take care of regular updates, fix bugs, provide persistent storage and help with our know-how to make the most out of the platform.
More information about Kubernetes and OpenShift
At the Cloud Native Meetup on August 28, 2018 in Zurich, we also talked about Kubernetes distributions: you can find the slides on Speaker Deck. You can also find more about OpenShift, Docker and Kubernetes here. Another recommendable blog post on this topic by Tomasz Cholewa: 10 most important differences between OpenShift and Kubernetes (English, technical).
How can we help?
Through our experience in operating OpenShift clusters around the world, we offer managed OpenShift clusters on almost any public, private or on-premise cloud. Or are you interested in another Kubernetes distribution than OpenShift? We gladly help you with the evaluation, integration and operation and support with our many years of Kubernetes experience.
We are looking forward to your feedback!