Skip to content

Kubernetes Updated 2026-05-27

Kubernetes: creating ingresses

Expose a Kubernetes service through an Ingress on the Stack Harbor PaaS — how the bundled ingress controller (Traefik / NGINX / HAProxy) processes specs.

A Kubernetes Ingress is the load-balancer abstraction that sits in front of Service resources and routes external HTTP / HTTPS traffic into the cluster. On the Stack Harbor PaaS, the ingress controller is the one you picked at cluster install time — NGINX, Traefik, or HAProxy — and it watches Ingress resources, parses their specs and controller-specific annotations, and translates them into routing rules.

This page covers the shape of an Ingress spec, the recommended choice of controller, and one platform-specific behaviour: the controller selection sticks for the life of the cluster.

Ingress vs NodePort

Both expose a service to traffic outside the cluster. The trade-offs:

  • A NodePort binds the service to a port on every node and is the simplest path. One service, one port.
  • An Ingress sits behind a single IP and routes multiple services by hostname or path. The controller adds path rewriting, TLS termination, name-based virtual hosting, authentication, and rate-limiting out of the box.

For real workloads with multiple services or any need for TLS or hostname routing, Ingress is the right tool. NodePort is for ad-hoc exposure and quick tests.

An example Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp
  labels:
    app: myapp
  annotations:
    kubernetes.io/ingress.class: traefik
    traefik.ingress.kubernetes.io/router.middlewares: default-strip-prefix@kubernetescrd
spec:
  rules:
    - http:
        paths:
          - path: /myapp
            pathType: Prefix
            backend:
              service:
                name: myapp
                port:
                  number: 8080

This spec forwards requests under /myapp on the environment’s default domain (https://${envName}.${platformDomain}/myapp) to the myapp service on port 8080.

A few things to note:

  • The example uses the networking.k8s.io/v1 API group. The legacy extensions/v1beta1 group has been removed; new specs must use v1.
  • kubernetes.io/ingress.class selects the controller. With multiple controllers installed, this annotation is what routes the Ingress to the right one.
  • Path stripping (the equivalent of the legacy PathPrefixStrip) is now driven by middleware in Traefik and by nginx.ingress.kubernetes.io/rewrite-target in NGINX. The controller you picked dictates the annotation surface.

For host-based routing (multiple sites behind one cluster), add a host: field under each rule. For TLS, add a tls: section pointing at a Kubernetes Secret that holds the certificate.

Controller selection is sticky

The ingress controller you picked at install time can’t be swapped from the Kubernetes management add-on or any other automation surface after the cluster is up. The decision is sticky for the cluster’s lifetime.

A manual swap is possible — uninstall the current controller, install the replacement, update existing Ingress resources to point at the new class. It’s not a one-click operation. Contact Stack Harbor support if you need to do it; we can guide the migration.

This is a platform constraint, not a Kubernetes constraint. Plan the controller choice at install time.

Picking a controller

Three controllers ship with the platform package:

  • NGINX — recommended default. Largest annotation surface and the most documentation. Handles complex rewrites, auth, and rate-limiting cleanly.
  • Traefik — smaller footprint, declarative CRD-driven middleware. Good for teams that prefer Traefik’s configuration model.
  • HAProxy — high-performance and well-suited to workloads with very high request volumes where NGINX’s behaviour doesn’t match.

Pick NGINX unless you have a specific reason to prefer one of the others.

See also