Robert Rojek

Scope and Flexibility

In OpenShift, Ingress and Routes both expose services running within the cluster to the outside world, but they differ in implementation and management.

An important distinction is that using an Ingress resource in OpenShift does not necessarily mean deploying a separate ingress solution. It works the same way as in a native K8S installation. Instead, OpenShift’s built-in ingress infrastructure can process standard Kubernetes Ingress resources and OpenShift Routes.

• Ingress:
  • Scope: Ingress is a standard Kubernetes API resource (networking.k8s.io/v1) and provides a standardized way to manage external HTTP/HTTPS traffic. It works across different Kubernetes distributions, making it a more flexible option for hybrid or multi-cloud environments.
  • Flexibility: Ingress supports various ingress controllers (such as NGINX, HAProxy, Traefik), each offering different features and capabilities. This allows for more customization and adaptability to specific requirements.
• Routes:
  • Scope: Routes are specific to OpenShift and are tailored to integrate seamlessly with OpenShift’s native router. They are not part of the Kubernetes core API and are unique to OpenShift environments.
  • Flexibility: Routes are simpler and more straightforward, with built-in support from OpenShift’s router. Routes provide a rich set of OpenShift-integrated routing features, particularly around TLS termination and HAProxy-based routing. Ingress may offer greater portability and can expose additional capabilities when combined with specialized third-party ingress controllers.

Implementation

• Ingress:
  • Ingress: Requires an Ingress Controller to process the Ingress resource. OpenShift provides a default Ingress Controller out of the box, so you typically don’t need an additional third-party controller. You can deploy other controllers, such as NGINX or Traefik, when you need their specific capabilities.
  • Example: If using an NGINX ingress controller, you can leverage features like advanced load balancing, URL rewrites, and custom headers.
• Routes:
  • Routes don’t require a separate controller because the OpenShift router handles them directly.
  • Example: Defining a route in OpenShift is straightforward, with simple configurations for basic HTTP/HTTPS traffic routing.

Code Example

Ingress YAML example

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example
            port:
              number: 8080

Routes YAML example

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: example
spec:
  host: app.example.com
  to:
    kind: Service
    name: example
  port:
    targetPort: 8080
  tls:
    termination: edge

Advanced Features

• Ingress:
  • Supports more advanced routing features, depending on the ingress controller used. This can include URL path-based routing, URL rewrites, external authentication, rate limiting, and more.
  • Suitable for complex deployment scenarios where specific and advanced traffic management rules are required.
• Routes:
  • Provide essential routing capabilities such as path-based routing and SSL/TLS termination but may lack the extensive feature set of some ingress controllers.
  • Ideal for simpler scenarios where ease of use and quick setup are more important than advanced customization.

Ease of Use

• Ingress:
  • May have a steeper learning curve because you need to understand and configure the ingress controller alongside Ingress resources.
  • Requires more configuration, especially for advanced features or when integrating with external systems.
• Routes:
  • Generally easier to set up and use within OpenShift. The configuration is straightforward, and the OpenShift router handles most of the complexity.
  • Designed to be user-friendly, making it quick to expose services to external traffic with minimal setup.

SSL/TLS Termination

Feature	Kubernetes Ingress	OpenShift Route
Standard Kubernetes API	✅	❌
Portable across Kubernetes	✅	❌
Built into OpenShift ecosystem	✅	✅
Edge TLS	Controller dependent	✅
Re-encrypt TLS	Controller dependent	✅
TLS passthrough	Controller dependent	✅
Path routing	✅	✅
Controller-specific extensions	✅	HAProxy/OpenShift-specific
OpenShift-native configuration	Limited	✅

• Ingress:
  • Supports multiple methods for SSL/TLS termination, either at the ingress controller level or at the service level, providing more flexibility depending on the ingress controller’s capabilities.
  • Example: Using an NGINX ingress controller, you can configure SSL termination with Let’s Encrypt for automated certificate management.
• Routes:
  • Simplifies SSL/TLS termination by integrating it directly into the route definitions. This makes it easier to manage certificates and encryption for basic use cases.
  • Example: You can define a route with a TLS configuration in OpenShift, and the OpenShift router handles SSL termination.

Impact on Managing External Traffic

1. Complexity and Customization:
   • Ingress allows more complex, customized traffic management, suitable for environments that require detailed, specific routing rules.
   • Routes provide a simpler, more integrated approach, making them easier to manage but potentially less flexible for advanced scenarios.
2. Standardization vs. Simplicity:
   • Ingress offers a standardized way to manage external traffic across different Kubernetes platforms, making it a better choice for hybrid or multi-cloud deployments.
   • Routes offer a simpler, OpenShift-specific solution that integrates tightly with the OpenShift ecosystem, ideal for users who prefer ease of use over flexibility.
3. Controller Dependency:
   • Ingress requires an ingress controller, which adds an extra layer of configuration and management.
   • Routes use the built-in OpenShift router, reducing the need for additional components and simplifying setup.

In summary, while both Ingress and Routes expose services to external traffic, they differ in key ways. Use Ingress when Kubernetes portability and standard APIs are important. Use Routes when you are working specifically with OpenShift and want to take advantage of OpenShift-native routing and TLS capabilities.

In many OpenShift environments, Routes are the natural choice because they integrate directly with the platform. However, standard Kubernetes Ingress resources remain valuable when applications need to remain portable across Kubernetes distributions.