At first, you must understand the differences between Route and Ingress Objects. They are intended to achieve the same aim ultimately. Originally, Kubernetes had no such concept and so OpenShift developed the concept of a Route, along with the bits for providing a load-balancing proxy, etc. In the time it was seen as being useful to have something like this in Kubernetes, so using Route from OpenShift as a starting point for what could be done, Ingress was developed for Kubernetes. In the Ingress version, they went for a more generic rules-based system so how you specify them looks different, but the intent is to effectively be able to do the same thing.

If you are using Openshift templates with “oc” command, you can add a Route object directly. You can create a route with a YAML file or even without using any YAML file and do not need any ingress object in Openshift.

For example, we have the service named “ test-service” and want to expose it.

Creating by YAML file:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    app: test
  name: test
spec:
  host: test.apps.ocp.domain.com
  port:
    targetPort: http
  tls:
    termination: edge
  to:
    kind: Service
    name: test-service
    weight: 100
  wildcardPolicy: None

‍

If you don’t need HTTPS end, delete “TLS” items.

Creating by “oc” command:

Expose with HTTP

oc expose svc/test-service — hostname=test.apps.ocp.domain.com

Expose with HTTPS

oc create route edge — service=test-service hostname=test.apps.ocp.domain.com

If you need IaC codes for Openshift only, everything is nice and clear. But If you need to use HELM package manager, you have to use Ingress object. Well! Why do we need to use HELM? For example, I had to use it because my project required the multi-platform installation of IaC codes. One code, one command, and one installation on different Kubernetes platforms like Openhift, RKE, Microk8S, K3S, EKS, etc…

Ingress objects are like the upstream equivalent of Routes. They aren’t tied to OpenShift. They behave differently in different Kubernetes clusters, depending on which ingress controller you’re using, and where the Kubernetes cluster is located.

For example, if you create an Ingress on an Amazon EKS cluster, Amazon will configure an Application Load Balancer (ALB) for you, behind the scenes. But if you create an Ingress object on a Google Kubernetes Engine (GKE) cluster, Google will configure a Google Cloud Load Balancer. if you create an Ingress object on Openshift, Openshift will create a Route object to expose.

Without TLS:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  labels:
    app: test
  name: test
spec:
  rules:
    - host: test.apps.ocp.domain.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: test-service
                port:
                  number: 80

With TLS:
‍
‍

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  labels:
    app: test
  name: test
  annotations:
    route.openshift.io/termination: edge
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  tls:
    - secretName: tls-ingress
  rules:
    - host: test.apps.ocp.domain.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: test-service
                port:
                  number: 80

You can use these similar Ingress YAML examples above in HELM codes. These manifests can run on Openshift and other Kubernetes in the same way. This manifest is an Ingress object, so it must obey the Ingress rules. But we need Openshift Route object descriptions.
The solution is using Annotations.

route.openshift.io/termination: edge

Openshift read these Annotations and applies them to the route objects.

‍

‍