Kubernetes Ingress YAML Builder

Generate a K8s Ingress manifest with host rules and TLS configuration

Creates a Kubernetes Ingress YAML with host-based routing rules, path prefixes, backend service references, TLS secret configuration, and an ingress class name for routing external HTTP traffic. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is an Ingress in Kubernetes?

An Ingress is an API object that manages external HTTP and HTTPS access to Services in a cluster. It provides host and path based routing, TLS termination, and a single entry point for many services.

Kubernetes Ingress YAML Builder

An Ingress exposes HTTP and HTTPS routes from outside the cluster to Services inside it. Instead of provisioning one LoadBalancer per service (expensive and complex), an Ingress controller terminates traffic at a single entry point and routes by hostname and URL path. This builder generates a valid Ingress manifest including TLS configuration, so you can publish a service over HTTPS quickly.

How it works

The manifest uses apiVersion: networking.k8s.io/v1 and kind: Ingress. The spec.ingressClassName selects the controller. Each entry under spec.rules binds a host to one or more paths, where every path has a pathType (Prefix or Exact) and a backend.service reference giving the Service name and port.number.

For HTTPS, the spec.tls block lists the hosts covered and the secretName of a kubernetes.io/tls Secret containing the certificate and key. The controller terminates TLS for those hosts using that secret.

The ingress class: choosing a controller

The ingressClassName field tells Kubernetes which installed Ingress controller should handle this rule. Common values:

Class nameControllerNotes
nginxingress-nginxMost common open-source option
traefikTraefikPopular in k3s and Rancher environments
haproxyHAProxy IngressHigh-performance option
albAWS Load Balancer ControllerAWS-specific; provisions an ALB
gceGKE Ingress controllerGoogle Kubernetes Engine built-in

If no matching controller is installed, the Ingress object is created but has no effect — no address is assigned, and no traffic is routed.

Path types explained

pathType: Prefix matches the URL path and everything beneath it. /api matches requests to /api, /api/users, and /api/users/123. This is the right choice for most service routing.

pathType: Exact requires the URL path to match the rule exactly — /api matches only /api, not /api/users. Use this when you need to route a single specific endpoint to a different service.

pathType: ImplementationSpecific leaves matching semantics to the controller. Avoid it for portability.

Tips and complete workflow

Create the TLS secret first, before applying the Ingress, to avoid a race condition where the controller tries to load a certificate that does not yet exist:

kubectl create secret tls my-tls --cert=tls.crt --key=tls.key -n your-namespace

Then apply the Ingress and verify an external address is assigned:

kubectl apply -f ingress.yaml
kubectl get ingress -n your-namespace

The ADDRESS column in kubectl get ingress should fill in within a minute once the controller picks up the new rule. If it stays empty, check that the ingress class name matches an installed controller with kubectl get ingressclass.

Confirm the referenced backend Services already exist before applying, or traffic has nowhere to go even when routing is correctly configured.