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 name | Controller | Notes |
|---|---|---|
nginx | ingress-nginx | Most common open-source option |
traefik | Traefik | Popular in k3s and Rancher environments |
haproxy | HAProxy Ingress | High-performance option |
alb | AWS Load Balancer Controller | AWS-specific; provisions an ALB |
gce | GKE Ingress controller | Google 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.