Creating Ingresses

Kubernetes Cluster: Creating Ingresses

Kubernetes Ingress manages external access to cluster Services. It can provide SSL termination, name-based virtual hosting, and rule-based routing so multiple applications can share the same external IP address.
External Routing Route incoming HTTP/HTTPS requests to the correct Kubernetes Service.
SSL Termination The ingress controller can handle HTTPS at the edge before forwarding traffic to backend Services.
Shared IP Expose several applications through one IP by routing requests according to hostnames or URL paths.
On this page

Ingress Overview

An Ingress works as a Kubernetes routing layer in front of Services. Incoming requests are compared with the rules defined in the Ingress specification and then forwarded to the appropriate backend Service and port.

Compared with exposing a Service through NodePort, Ingress is more powerful but also more complex. It becomes especially useful when several Services need to share one external IP address.
  • Route requests according to URL path.
  • Route requests according to hostname or subdomain.
  • Terminate SSL/TLS at the ingress-controller layer.
  • Apply controller-specific features such as authentication and advanced routing.

Ingress Controllers

Ingress resources require an ingress controller. The controller watches Kubernetes Ingress objects, reads their specifications and annotations, and translates them into active routing rules.

Traefik Used as the default ingress controller in the source documentation.
HAProxy Available as an alternative in supported Kubernetes package versions.
NGINX Available as another ingress-controller option in supported package versions.
Controller selection: The ingress controller selected during Kubernetes Cluster installation cannot be changed later through the standard Kubernetes management add-on or other automated platform tools. A manual change is still possible if required.

Ingress Specification

An Ingress rule combines three main elements:

Path or Host Rule Defines which incoming requests should match.
Backend Service Specifies which Kubernetes Service should receive the matching traffic.
Service Port Defines the port on the backend Service that receives the forwarded request.

Path-Based Routing Example

The following example exposes a Service named myapp through the /myapp path and forwards requests to Service port 8080.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  labels:
    app: myapp
  name: myapp
  annotations:
    kubernetes.io/ingress.class: traefik
    ingress.kubernetes.io/secure-backends: "true"
    traefik.frontend.rule.type: PathPrefixStrip
spec:
  rules:
    - http:
        paths:
          - path: /myapp
            backend:
              serviceName: myapp
              servicePort: 8080
This is a historical example from the source page and uses the older extensions/v1beta1 Ingress API. For newer Kubernetes versions, use the currently supported Ingress API syntax for your cluster.

The controller-specific annotations in this example instruct Traefik to manage the Ingress and use path-prefix stripping behavior for the configured route.

How the Example Is Accessed

With the example above, the myapp Service becomes available under the Kubernetes environment’s default domain with the /myapp path:

https://${envName}.${platformDomain.com}/myapp
  • The incoming request reaches the Kubernetes ingress controller.
  • The controller matches the /myapp path.
  • The request is routed to the myapp Service.
  • The Service forwards the request to its backend application on port 8080.
Ingress summary: Use Ingress when multiple HTTP/HTTPS Services need to share one external entry point or when you need path routing, hostname routing, SSL termination, authentication, or other controller-managed routing features.

What’s next?