After completing this section, you should be able to see the differences between several Kubernetes implementations, and how to prepare different Kubernetes flavours for this course.
Kubernetes has historically been targeted to be a general solution for container management and orchestration. With this versatility, Kubernetes can solve the same problems in different ways depending on needs and opinions. Because of this Kubernetes has evolved into different opinionated distributions. Different distributions can be categorized by many dimensions, including:
The target size of the cluster: From small single-node clusters to large-scale clusters of hundreds of thousands of nodes.
The location of the nodes: Either locally on the developer workstation, on premises (such as a private data center), on the cloud, or a hybrid solution of those two.
The ownership of the management: Self-managed clusters versus Kubernetes-as-a-Service.
The following table shows a classification for some of the most popular Kubernetes distributions:
|Big Scale||Small Scale|
Self-Managed - Local
minikube, CodeReady Containers, Microk8s, Docker Kubernetes
Self-Managed - On Premises / Hybrid
Red Hat OpenShift, VMWare Tanzu, Rancher
Kubernetes-as-a-Service - On Cloud
OpenShift Dedicated, Google Container Engine, Amazon EKS
This course supports
Visit the links in the references section below for a comprehensive list of Kubernetes certified distributions.
Kubernetes is highly extendable for adding more services to the platform. Each distribution provides different approaches (or none) for adding capabilities to Kubernetes:
DNS allows internal name resolution inside the cluster, so pods and services can refer to others by using a fixed name.
minikube and OpenShift include a
CoreDNS controller that provides this feature.
The dashboard provides a graphical user interface to Kubernetes.
minikube provides an add-on and utility commands for using the general-purpose
Dashboard open source application. OpenShift includes the
Console, a dedicated application that integrates most of the Kubernetes extensions provided by OpenShift.
The ingress extension allows traffic to get into the cluster network, redirecting requests from managed domains to services and pods. Ingress enables services and applications inside the cluster to expose ports and features to the public.
minikube uses an ingress add-on based on the
ingress ngix controller.
You must to install the ingress add-on for
OpenShift deploys an ingress controller based on
HAProxy and controlled by a
Ingress Operator. OpenShift also introduces the
route resource. A
route extends the
ingress manifest to ease controlling ingress traffic.
The storage extension allows pods to use persistent storage and nodes to distribute and share the storage contents.
OpenShift bases its storage strategy on
Red Hat OpenShift Data Foundation, a storage provider supporting multiple storage strategies across nodes and hybrid clouds.
minikube provides out-of-the-box storage by using the underlying storage infrastructure (either local the file system or the virtual machine’s file-system). This feature is provided by the
minikube also provides a
storage-provisioner-gluster add-on that allows Kubernetes to use
Gluster as shared persistent storage.
Authentication and authorization.
Kubernetes embeds a certificate authority (CA) and considers anyone that presents a certificate issued by that CA as a valid user.
minikube provides the user with an administrator
minikube account, so users have total control over the cluster.
Different OpenShift implementations differ on authentication features, but all of them agree on avoiding the use of administration accounts. Developer Sandbox provides limited access to the user, restricting them to the
Authorization in Kubernetes is role based. Authorized users or administrators can assign predefined roles to users on each resource. For example, administrators can grant read-only access to auditor users to application namespaces.
Operators are a core feature of most Kubernetes flavors. Operators allow automated management of applications and Kubernetes services, by using a declarative approach.
minikube requires the
olm add-on to be installed to enable operators in the cluster.
OpenShift distributions enable operators by default, despite the fact that Kubernetes-as-a-Service platforms usually restrict user-deployed operators. Developer Sandbox does not allow users to install operators, but comes with the
RHOAS-Operator and the
Service Binding Operator by default.
Table 1. Comparison summary of Kubernetes features
NGINX Ingress add-on
Local or Gluster add-ons
Red Hat OpenShift Data Foundation,
Developer used restricted to 2 namespaces
OLM add-on. No restrictions
Limited to RHOAS and Service Binding