OpenShift (OCP) – Ingress

techhadoop , , , ,

In OpenShift (OCP), Ingress is the mechanism that allows external traffic (HTTP/HTTPS) to reach services inside your cluster. While Kubernetes has a standard “Ingress” resource, OpenShift has historically used its own evolved version called Routes.

As of 2026, the landscape has expanded to include the Gateway API, which is the modern successor to both.

1. The Three Ways to Expose Apps

FeatureRoute (Native OCP)Ingress (K8s Standard)Gateway API (The Future)
SimplicityHigh (Very easy to use)MediumMedium/High
FlexibilityGoodLimited (Needs annotations)Extreme (Fine-grained control)
StandardRed Hat ProprietaryKubernetes LegacyKubernetes Modern (GA 2026)
Best ForStandard OCP appsCross-platform migrationComplex routing/Canary/Blue-Green

2. How the “Router” Works

The Ingress Controller in OCP is an Operator-managed deployment of HAProxy (by default).

  • It sits at the edge of the cluster.
  • It watches for new Routes or Ingresses.
  • It automatically updates its configuration and starts proxying traffic to the correct Pods.

3. Key Concepts for Admins

Ingress Controller Sharding

In large clusters, a single router can become a bottleneck. You can “shard” your ingress traffic by creating multiple Ingress Controllers.

  • Example: Create one router for *.public.example.com and a separate, isolated router for *.internal.example.com.
  • Benefit: Performance isolation and security (e.g., PCI-compliant traffic on specific nodes).

TLS Termination Patterns

Routes support four types of security:

  1. Edge: SSL is decrypted at the Router. Traffic to the Pod is plain HTTP. (Most common).
  2. Passthrough: SSL is sent directly to the Pod. The Router doesn’t see the data.
  3. Re-encryption: SSL is decrypted at the Router, inspected, then re-encrypted before being sent to the Pod.
  4. None: Simple plain HTTP.

4. Interview “Pro” Tips

  • The “503 Service Unavailable” Error: If a developer sees this on their Route, it almost always means the Readiness Probe for the Pod is failing. The Router won’t send traffic to a Pod that isn’t “Ready.”
  • Host vs Path Routing: OCP Routes excel at host-based routing (app-a.com vs app-b.com). If you need complex path-based routing (e.g., app.com/v1/api going to one service and /v2/api to another), the Gateway API is now the recommended tool over standard Routes.
  • Wildcard DNS: OCP creates a default wildcard (e.g., *.apps.cluster.example.com). Every time you create a Route without a host, OCP generates one for you using this pattern.

5. Troubleshooting Command Cheat Sheet

# Check the status of the Ingress Operator
oc get ingresscontroller -n openshift-ingress-operator
# See the HAProxy pods actually doing the work
oc get pods -n openshift-ingress
# Check if a Route is "Admitted" (Successfully configured)
oc get route <route-name> -o yaml | grep -A 5 status
# Look at router logs to see traffic errors
oc logs -n openshift-ingress deployment/router-default
In a high-scale enterprise environment, you often want to isolate traffic. For example, your **Internal HR App** shouldn't share the same entry point (the router) as your **Public Marketing Site**. This is called **Ingress Sharding**.
In OpenShift, we achieve this by creating a second **Ingress Controller** and using **Namespace Selectors**.
---
### 1. The Strategy: Router Sharding
By default, OpenShift has a `default` Ingress Controller that handles everything. To split traffic, we will:
1.  Create a new Ingress Controller named `sharded-router`.
2.  Tell it to only watch namespaces with a specific label (e.g., `type: public`).
3.  Label our target namespace.
---
### 2. Implementation Steps
#### **Step A: Label the Namespace**
First, identify which projects should use the new, isolated router.
```bash
oc label namespace my-public-app type=public
```
#### **Step B: Create the New Ingress Controller**
This YAML creates a new set of HAProxy pods that only serve traffic for namespaces with the `type=public` label.
```yaml
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: sharded-public
  namespace: openshift-ingress-operator
spec:
  domain: public.apps.mycluster.com  # A dedicated subdomain
  endpointPublishingStrategy:
    type: LoadBalancerService       # Creates a new Cloud Load Balancer
  namespaceSelector:
    matchLabels:
      type: public                  # The magic filter
  nodePlacement:                    # Optional: Run on specific "DMZ" nodes
    nodeSelector:
      matchLabels:
        node-role.kubernetes.io/infra: ""
```
---
### 3. Verification
Once applied, OpenShift will spin up new pods in the `openshift-ingress` namespace.
* **Check Pods:** `oc get pods -n openshift-ingress` (You'll see `router-sharded-public-...`)
* **Check Load Balancer:** `oc get svc -n openshift-ingress` (You'll see a new service with a unique External IP).
Now, any Route created in the `my-public-app` namespace will be picked up by the **new** router and ignored by the **default** one.
---
### 💡 Interview Questions on Sharding
* **Q: Why would you shard an Ingress Controller?**
    * **A:** For **Security** (isolating internal vs. external traffic), **Performance** (preventing a noisy neighbor from hogging the CPU/bandwidth of the router), and **Compliance** (ensuring certain data only flows through nodes that meet specific regulatory standards).
* **Q: How does the Route know which router to use?**
    * **A:** The Route doesn't "choose." The **Ingress Controllers** choose the Routes based on the `namespaceSelector` or `routeSelector` defined in their configuration.
* **Q: Can a single Route be served by two different Routers?**
    * **A:** Yes, if both Ingress Controllers have selectors that match that Route's namespace or labels. This is sometimes used during migrations.
---

Leave a comment