Back to home

Differences between OpenShift and Kubernetes from a developer's perspective

The goal of this article is to walk you through the resources that are available in OpenShift, that would not be on a Kubernetes installation.

Differences inside of your application

Project and Namespace

OpenShift talks about Projects, where Kubernetes talks about namespaces. As far as an application goes, they are identical.

Migration to Kubernetes

Apart from a naming change, nothing to do here!

Route and Ingress

In OpenShift, you use routes to expose your services to external traffic. Since we are taking care of the DNS magic and the OpenShift routing for you, you typically just need add a route resource to your project, and you’re good to go!

In Kubernetes, routes do not exist. Instead, the ingress resource is what you would need to use.

Migration to Kubernetes

You would need to convert your routes resources to ingress resources.

Route example
kind: Route
  annotations: "true"
  name: my-route
    insecureEdgeTerminationPolicy: Redirect
    termination: edge
    kind: Service
    name: my-service
    weight: 100
  wildcardPolicy: None
Ingress example
apiVersion: extensions/v1beta1
kind: Ingress
  annotations: letsencrypt-prod
  name: my-ingress
  - host:
      - backend:
          serviceName: my-service
          servicePort: 80
  - hosts:

All in all, they are fairly similar. It is worth noting that OpenShift at nine uses openshift-acme to manage TLS certificates, and on Kubernetes, you would typically rely on other projects, cert-manager being the current standard.

DeploymentConfig and Deployment

A bit of Trivia: OpenShift had DeploymentConfig before Kubernetes had Deployments!

There are both ways to create ReplicaSets and Pods that would contain your applications and restart it in case of failures, scale it in case you set the replica number to a different number, …

Migration to Kubernetes

Since both are supported by OpenShift, the simplest would be to start off with only using Deployments. This is what you will use if you have used Helm charts to deploy your applications, as most of them use a Deployment resource.

If you already have some DeploymentConfig, you will have to transform them to Deployment resources.


OpenShift comes with a BuildConfig resource, which is here to typically help you build Docker images from your source code.

This is a pattern that is not present in Kubernetes.

Migration to Kubernetes

Do not use BuildConfig. Instead, build your Docker images outside of your cluster (e.g. via a CI/CD pipeline).

Differences outside of your application

These will not directly impact your applications, but they will impact your current workflow.

oc and kubectl

oc and kubectl are both tools that allow you to interact with your cluster via the command line.

They are very similar in practice, and it should be seamless to switch from one to the other (provided you don’t use one of the resources mentioned previously in this article).

OpenShift UI and Kubernetes UI

Since OpenShift and Kubernetes are two different products, they also come with two different UIs.

OpenShift UI is a big part of the whole product. Kubernetes itself does not have a UI by default, and the main way of controlling a k8s cluster is via kubectl on the CLI.

We do install a dashboard in your cluster, but in general, Kubernetes Dashboard should be used more for checking rather than controlling your cluster.


OpenShift and Kubernetes are very similar beasts when it comes to deploying containerized applications, with some exceptions that were mentioned in this article.

Should you need any assistance in making the switch to Kubernetes, don’t hesitate to contact us:

Didn't find what you were looking for?

Contact our support:

+41 44 637 40 40