A Comprehensive Technical Comparison of OpenShift and Kubernetes

Introduction

OpenShift and Kubernetes are two of the most popular container orchestration platforms used in the industry. Both platforms provide similar functionalities, but they have some fundamental differences in terms of architecture, tools, interfaces, and community support. I will show you a detailed technical comparison of OpenShift and Kubernetes, with a focus on highlighting the differences between Route and Ingress Controller. This article aims to provide a comprehensive analysis of the two platforms, their similarities, differences, and use cases, with examples of commands and console outputs.

Architecture

OpenShift is built on top of Kubernetes and adds additional components to provide a more complete platform. These components include the OpenShift Origin project, which provides tools for building and deploying applications, and the OpenShift router, which provides default networking and load-balancing capabilities. OpenShift also includes a registry for storing container images and provides a default Ingress Controller. Kubernetes, on the other hand, provides a more lightweight platform that focuses solely on container orchestration. It consists of a set of core components, including the Kubernetes API server, the etcd key-value store, and the kubelet agent, that work together to manage containerized applications.

Route vs Ingress Controller

One of the key differences between OpenShift and Kubernetes is the way they manage network traffic between containers. OpenShift provides a default router and a load balancer, while Kubernetes provides a Service object that provides load balancing and service discovery capabilities. Both platforms provide a network policy controller that allows administrators to define network policies for controlling traffic between pods.

OpenShift also provides a Route object, which is used to expose a service to the outside world. A Route object provides a more user-friendly and convenient interface for managing external access to services. It also provides features such as SSL termination, path-based routing, and service discovery.

On the other hand, Kubernetes provides an Ingress Controller, which is a plugin that manages external access to services. An Ingress Controller provides a flexible and extensible interface for managing external access to services. It also provides features such as SSL termination, path-based routing, and service discovery.

To illustrate the differences between Route and Ingress Controller, let’s consider an example of deploying an application with external access. In OpenShift, we can use the following command to create a new deployment with external access:

oc new-app --docker-image=myimage:latest --name=myapp
oc expose svc myapp --port=80 --hostname=myapp.example.com

This creates a new deployment object called “myapp” and exposes it using a Route object. The Route object provides external access to the “myapp” service on port 80 using the hostname “myapp.example.com”.

In Kubernetes, we can achieve the same result by creating a new deployment and an Ingress object using the following commands:

kubectl create deployment myapp --image=myimage:latest
kubectl expose deployment myapp --port=80
kubectl create ingress myapp-ingress --rule=myapp.example.com/path=myapp:80

This creates a new deployment object called “myapp” and exposes it using a Service object. We then create an Ingress object that maps the URL path “/path” to the Service object. The Ingress object provides external access to the “myapp” service on port 80 using the hostname “myapp.example.com”.

As we can see, both OpenShift and Kubernetes provide similar capabilities for managing external access to services, but with some differences in the objects used to manage the access. OpenShift provides a Route object, which provides a more user-friendly interface, while Kubernetes provides an Ingress Controller, which provides a more flexible and extible interface.

Security

OpenShift provides built-in security features, such as role-based access control (RBAC) and image scanning, that are not available in Kubernetes. RBAC allows administrators to define fine-grained access controls for users and groups, while image scanning ensures that container images are free from vulnerabilities and security threats.

To illustrate the differences in security features, let’s consider an example of deploying an application with restricted access. In OpenShift, we can use the following commands to create a new project and a new deployment with restricted access:

oc new-project myproject --display-name="My Project"
oc new-app --docker-image=myimage:latest --name=myapp
oc policy add-role-to-user view system:serviceaccount:myproject:default

This creates a new project called “myproject” and a new deployment called “myapp”. The last command grants the default service account in the “myproject” project with the “view” role, which allows it to view resources in the project.

In Kubernetes, we can achieve the same result by creating a new namespace and a new deployment with restricted access:

kubectl create namespace mynamespace
kubectl create deployment myapp --image=myimage:latest --namespace=mynamespace
kubectl create rolebinding myapp-view --namespace=mynamespace --role=view --serviceaccount=default:default

This creates a new namespace called “mynamespace” and a new deployment called “myapp”. The last command creates a role binding that grants the default service account in the “mynamespace” namespace with the “view” role, which allows it to view resources in the namespace.

As we can see, both OpenShift and Kubernetes provide similar security features, but with some differences in the objects used to manage access controls. OpenShift provides a default project and RBAC controls, while Kubernetes provides a default namespace and role bindings.

Community Support

OpenShift is backed by Red Hat, which provides commercial support and contributes to the development of the platform. This means that OpenShift users can benefit from dedicated support and assistance from Red Hat. Kubernetes, on the other hand, is a community-driven project that is supported by a large and active community of developers. While Kubernetes does not provide commercial support, there are many third-party companies that offer Kubernetes support and services.

Use Cases

OpenShift is best suited for large organizations that require a comprehensive platform with built-in tools for managing applications. It is also ideal for organizations that require strong security features, as OpenShift provides built-in support for RBAC and image scanning. Kubernetes, on the other hand, is best suited for smaller organizations or developers who require a more lightweight and flexible platform that can be customized to meet their specific needs.

Command Comparison

Let’s compare some of the commonly used commands in OpenShift and Kubernetes.

Create a new deployment: In OpenShift, we can create a new deployment using the following command:

oc new-app --docker-image=myimage:latest --name=myapp

This creates a new deployment object called “myapp” using the Docker image “myimage:latest”.

In Kubernetes, we can create a new deployment using the following command:

kubectl create deployment myapp --image=myimage:latest

This creates a new deployment object called “myapp” using the Docker image “myimage:latest”.

Expose a deployment: In OpenShift, we can expose a deployment using the following command:

oc expose deployment myapp --port=80

This creates a service object that exposes the “myapp” deployment on port 80.

In Kubernetes, we can expose a deployment using the following command:

kubectl expose deployment myapp --port=80

This creates a service object that exposes the “myapp” deployment on port 80.

Create a Route object

In OpenShift, we can create a Route object to expose a service to the outside world using the following command:

oc expose svc myapp --port=80 --hostname=myapp.example.com

This creates a Route object that provides external access to the “myapp” service on port 80 using the hostname “myapp.example.com”.

Create an Ingress object: In Kubernetes, we can create an Ingress object to expose a service to the outside world using the following command:

kubectl create ingress myapp-ingress --rule=myapp.example.com/path=myapp:80

This creates an Ingress object that maps the URL path “/path” to the “myapp” service on port 80 using the hostname “myapp.example.com”.

List objects

In OpenShift, we can list objects in a project using the following command:

oc get all -n myproject

This lists all objects in the project, including deployments, services, and routes.

In Kubernetes, we can list objects in a namespace using the following command:

kubectl get all -n mynamespace

This lists all objects in the “mynamespace” namespace, including deployments, services, and ingress objects.

Conclusion

In conclusion, OpenShift and Kubernetes are two powerful container orchestration platforms that offer similar functionalities but have some key differences in terms of architecture, tools, interfaces, and community support. OpenShift provides a more comprehensive platform with built-in tools and a more user-friendly interface, while Kubernetes provides a more lightweight and flexible platform with a more extensible interface. One of the main differences between the two platforms is the way they manage network traffic between containers, with OpenShift providing a default router and a Route object, while Kubernetes provides a Service object and an Ingress Controller. It is important to consider the specific needs of the organization when choosing between OpenShift and Kubernetes, as OpenShift is best suited for large organizations that require a comprehensive platform with built-in tools, while Kubernetes is best suited for smaller organizations or developers who require a more lightweight and flexible platform that can be customized to meet their specific needs.