Do the ssl-redirect and rewrite-target annotations work with any ingress class?

No. Both are controller-specific annotations under the nginx.ingress.kubernetes.io/ prefix, so this tool only emits them when you select the nginx ingress class. Traefik and AWS ALB use entirely different annotation keys (or CRDs, in Traefik's case) for equivalent behavior, which this generator doesn't attempt to guess.

What pathType does the generator use?

It always uses Prefix, the most common choice, matching any request path that starts with the rule's path. If you need Exact or ImplementationSpecific matching, change the pathType value in the generated YAML manually.

How does the TLS section relate to the host field?

When you supply a TLS secret name, the generated tls block lists the same host you entered under spec.tls[].hosts, since a TLS certificate is only valid for the host(s) it's issued for; the Secret itself (containing the certificate and key) must already exist in the same namespace.

Can I route different paths to different backend Services?

Yes, add one rule per path/service/port combination; each becomes its own entry under spec.rules[0].http.paths.

Kubernetes Ingress Generator - Build Ingress YAML

Overview

Introduction

Ingress manifests nest deeply (rules, then http, then paths, then backend, then service, then port) and it's easy to lose track of a bracket while hand-writing one, especially with multiple path rules.

This tool generates a complete Ingress manifest from a form: ingress class, host, one or more path rules, optional TLS, and common controller annotations, entirely client-side.

What Is Kubernetes Ingress YAML Generator?

A Kubernetes Ingress YAML generator targeting the stable networking.k8s.io/v1 API, supporting the nginx, traefik, and alb ingress classes.

It covers a single host with any number of path-to-backend-service routing rules, an optional TLS secret reference, and the two most common nginx-ingress-controller annotations (SSL redirect and rewrite-target).

How Kubernetes Ingress YAML Generator Works

The ingress class you pick sets spec.ingressClassName directly, which tells whichever ingress controller watches that class name to pick up this Ingress object.

Each path rule you add becomes one entry in spec.rules[0].http.paths, referencing a backend Service by name and port number with pathType: Prefix.

If you supply a TLS secret name, a spec.tls entry is added referencing your host and that Secret; nginx-specific annotations are only added when the ingress class is nginx, since they're meaningless (and potentially misleading) under other controllers.

When To Use Kubernetes Ingress YAML Generator

Use it once you have a Service in place (see the Service Generator) and need to route external HTTP(S) traffic to it by hostname and path.

Use it to quickly assemble a multi-path Ingress, for example routing /api to one Service and / to another, without hand-tracking indentation across nested rules.

Often used alongside Kubernetes Service YAML Generator, Kubernetes Secret YAML Generator and Kubernetes Deployment YAML Generator.

Features

Advantages

Handles the deeply nested rules/http/paths/backend structure for you, eliminating the most common source of Ingress YAML indentation bugs.
Scopes controller-specific annotations to the ingress class that actually understands them, instead of blindly adding nginx annotations to every Ingress.
Supports multiple path rules under a single host in one generated manifest.

Limitations

Supports a single host per manifest; multi-host Ingress objects need a second spec.rules entry added manually.
Traefik and ALB ingress classes get the ingressClassName set correctly but none of their controller-specific annotations or IngressClassParams, since those vary widely by setup.
Doesn't verify that the referenced backend Services or TLS Secret actually exist in your cluster.

Examples

Routing a single host's /api path to a backend Service

Input

ingressClassName: nginx, host: app.example.com, rule: path=/api service=api-service port=8080, sslRedirect: true

Output

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080

The ssl-redirect annotation is only emitted because nginx was selected as the ingress class.

Best Practices & Notes

Best Practices

Always set a TLS secret name for anything reachable over the public internet; unencrypted Ingress traffic should be the exception, not the default.
Order more specific paths (like /api/v2) before more general ones (like /api) if your controller matches rules in list order, to avoid the general rule swallowing the specific one.
Double-check that the ingress class you selected actually has a controller installed and watching it in your cluster; an Ingress with no matching controller simply does nothing.

Developer Notes

The generator hand-assembles the YAML string directly, branching on ingress class only to decide which vendor-specific annotations to emit, since nginx.ingress.kubernetes.io/* annotations are inert (and arguably misleading) outside an nginx-ingress-controller-managed cluster. pathType is hardcoded to Prefix since it's the overwhelmingly common choice and the safest default for path-based routing under networking.k8s.io/v1.

Kubernetes Ingress YAML Generator Use Cases

Exposing an HTTP API behind a single hostname with path-based routing to multiple backend Services
Setting up TLS termination at the ingress layer for a service that previously had no Ingress
Adding SSL-redirect and rewrite-target behavior to an nginx-ingress-controller-fronted Service

Common Mistakes

Setting an nginx-specific annotation and expecting it to work under a Traefik or ALB ingress controller.
Forgetting that the TLS Secret referenced by secretName must already exist in the same namespace as the Ingress; this manifest only references it, it doesn't create it.
Listing a broad path rule before a more specific one under a controller that matches in order, causing the specific rule to never be reached.

Tips

Generate the referenced TLS Secret with the Kubernetes Secret Generator (type kubernetes.io/tls) if it doesn't already exist in your cluster.

Kubernetes Ingress YAML Generator