Kubernetes vs OpenShift (service vs routes)

There are only minor differences in tools being used. OpenShift is a Kubernetes distribution, this means it is a collection of opinionated pre-selected components. So for Ingress, OpenShift uses HAProxy to get (HTTP) traffic into the cluster. Other hand Kubernetes distributions maybe uses the NGINX Ingress Controller or something similar.

So Services are used to loadbalance traffic inside the cluster. So when you create a ReplicaSet, you'll have multiple Pods running. To "talk" to these Pods, you typically create a Service. That Service will distribute the traffic evenly between your Pods.

So to get HTTP(S) traffic from the outside to your Service, OpenShift uses Routes (Ingress in other Kubernetes distributions):

So to expose your application to the outside world, you typically create an internal Service using oc create service and then create a Route using oc expose:

# Create a new ClusterIP service named myservice
$oc create service clusterip myservice --tcp=8080:8080
$oc expose service myservice

Actually creating an ingress object should not have any effects on its own and requires an ingress controller on the Kubernetes platform in order to fulfill the configurations defined by the ingress object.

Here at Red Hat, we saw the need for enabling external access to services before the introduction of ingress objects in Kubernetes, and created a concept called Route for the same purpose (with additional capabilities such as splitting traffic between multiple backends, sticky sessions, etc).

When a Route object is created on OpenShift, it gets picked up by the built-in HAProxy load balancer in order to expose the requested service and make it externally available with the given configuration. It’s worth mentioning that although OpenShift provides this HAProxy-based built-in load-balancer, it has a pluggable architecture that allows admins to replace it with NGINX (and NGINX Plus) or external load-balancers like F5 BIG-IP.

You might be thinking at this point that this is confusing! Should one use the standard Kubernetes ingress objects or rather the OpenShift routes? What if you already have applications that are using the route objects? What if you are deploying an application written with Kubernetes ingress in mind?

don’t worry at all ! Since the release of Red Hat OpenShift 3.10 and above, ingress objects are supported alongside route objects. The Red Hat OpenShift ingress controller implementation is designed to watch ingress objects and create one or more routes to fulfill the conditions specified. If you change the ingress object, the Red Hat OpenShift Ingress Controller syncs the changes and applies to the generated route objects. These are then picked up by the built-in HAProxy load balancer.

Conclusion

As a openshift user, when these capabilities are introduced in Kubernetes, you have the option to switch to the Kubernetes objects and continue using the OpenShift platform as you did before. Despite this, due to the feature-set differences between Ingress and Route, unless you need to deploy the same objects across multiple Kubernetes distributions, Route objects are my recommended approach on Red Hat OpenShift.

Thanks for reading…..