Kubernetes and OpenShift- do they share more common attributes or are they far apart? What do you think? Hold your thoughts, we will come back to this question! This post is targeted for people who are in the world of DevOps and for people already familiar/working with Kubernetes.
It would be unfair to everyone else if I did not relay what Kubernetes is from Wikipedia- “Kubernetes is an open-source container orchestration system for automating application deployment, scaling, and management“. Then, what is OpenShift? In short, it is Kubernetes for Enterprise. Nice way to describe OpenShift, isn’t it? Feel free to read the complete definition of OpenShift at your spare time! So, what do you think? Are they similar or different? Hold your thoughts, let’s not conclude yet!
Figure 1: Kubernetes Service vs OpenShift Service
Both Kubernetes and OpenShift are made of many components but here are the most important components. Let me borrow nice graphical presentation by James Buckett, DevOps and Cloud Practice Lead, Asia-Pacific at Levvel.
Figure 2: Kubernetes components in purple and OpenShift components in orange
PODs are the basic building block of Kubernetes and OpenShift. You can deploy multiple containers in a POD but, for best practice, we deploy one container per POD. PODs are distributed on to many nodes but they are logically grouped (by Label Selector or Selector) to expose as a Service. As you can see in figure 1, Kubernetes service (on the left) is exposed as internal endpoint (aks-apidemo-front-internal) and OpenShift service (on the right) is exposed by a Route at a hostname(osa-api-demo.api-demo.svc). Both cases services are accessible internally within the cluster by their internal endpoint or hostname. Alternatively, services can be accessed internally by the ClusterIP (10.240.22.241 or 172.30.252.100) but IP can change anytime. So, in terms of PODs and Services Kubernetes and OpenShift look very similar.
As mentioned, service can be accessed via internal endpoint or hostname only within the cluster (i.e. from a POD). Let’s verify this claim!
Figure 3: Successful API call from inside Kubernetes (left) POD and OpenShift (right) POD
Services exposed with Internal endpoint or hostname are not accessible by external clients. So, how do we make our micro-services available to external clients? As you may noticed, in Kubernetes you can expose the service with External Endpoint (10.240.0.67). External endpoint is a Load Balancer and Kubernetes support both internal load balancer and external load balancer (public ip). To make our service secure, we will not expose service with external load balancer. We can use Application Gateway or ELB to expose the external endpoint to external client. Same concept applies to OpenShift. An OpenShift Container Platform administrator can deploy Routers to nodes in an OpenShift Container Platform cluster, which enable Routes created by developers to be used by external clients. Figure 1 (R) is showing a router that is exposed with public ip but, for best practice, we would expose router with internal ip.
Now, let’s verify that services can be accessed via external endpoint or router. OpenShift provides private dns for router. You will have to use Private DNS Zone in Azure Kubernetes and create A record with external endpoint.
Figure 4: API call from inside Kubernetes (left) POD via external endpoint and from OpenShift (right) POD via router
What’s external endpoint in Kubernetes? External endpoint is a load balancer, it can be internal (private ip) or external (public ip) load balancer. Router in OpenShift is HAProxy which is a load balancer. I see similarity between external endpoint and router but officially router (in OpenShift) is compared with NGINX (pronounced as engine-x in Kubernetes)! I don’t see any difference between external endpoint and router except router comes with more capabilities.
Kubernetes Ingress & NGINX vs OpenShift Route & Router
Route in OpenShift is a construct (configuration) that defines how connections or paths are mapped to service(s). Similarly, Ingress in Kubernetes defines how connections or paths are mapped to service(s). Route or Ingress definition alone can’t execute an action. Route needs it’s companion Router which is a HAProxy Container. Similarly, Ingress needs it’s companion Ingress Controller (NGINX Container). Figure 5 below shows Ingress (left) and Route (right).
Figure 5: Sample Ingress (left) and Route (right) Definition
Do you really need Ingress and Ingress Controller (NGINX) in Kubernetes? Not really, you can expose an Application Gateway to external clients and configure it’s backend pool to external endpoint of a service. Ingress Controller definitely provides the flexibility of path based routing and other capabilities like that of Router (HAProxy) in OpenShift.
Figure 6: Sample NGINX Controller (left) and Route/Router (right)
RBAC in Kubernetes and OpenShift
RBAC stands for Role Based Access Control. RBAC controls who gets to do what in Kubernetes or OpenShift. RBAC is made of Role and RoleBinding. Think of Role as group of entitlements or permissions. RoleBinding, as the name says, binds user(s) to role(s).
Figure 7: Roles in Kubernetes (left) and Roles in OpenShift (right)
OpenShift provides nice web interface to manage roles and bindings. Kubernetes lacks user interface to manage RBAC but you can do all using kubectl (cli).
Figure 8: Bindings in Kubernetes (left) and Bindings in OpenShift (right)
Okay, we have covered the most important components and compared them side-by-side! What do you think now? Is OpenShift similar to Kubernetes? The loud answer is- Yes! OpenShift is built on top of Kubernetes but OpenShift comes with some of the features (authentication, authorization, SDN, Network Policies, etc.) required by enterprise. You may read this very informative post if you want to know which platform is better- 10 most important differences between OpenShift and Kubernetes.