Ingress and Gateway API Route Prompt Template

This prompt is for platform engineers, DevOps teams, and internal developer platform builders who need to translate natural language routing requirements into valid, deployable Kubernetes Ingress or Gateway API HTTPRoute YAML. The job-to-be-done is reducing the cognitive load and syntax errors that come from hand-writing routing manifests—correct path matching, backend service references, TLS configuration, and rewrite rules. The ideal user already understands their cluster's networking model and needs a reliable scaffold that survives kubectl apply --dry-run=server or a Gateway API controller's validation webhook on the first pass, not a tutorial on how Ingress works.

Use this prompt when you are working inside a GitOps pipeline, an internal developer platform, or an infrastructure automation workflow where YAML correctness is a hard gate. It is appropriate when you can provide concrete inputs: a list of backend services with their names and ports, the desired hostnames, TLS secret names if you are terminating TLS, and any path rewriting or header modification rules. The prompt template is designed to be wired into a larger system that can supply these variables programmatically, such as a service catalog or a deployment orchestrator. It is not a replacement for understanding your specific Gateway API controller's implementation—some controllers support a subset of filters or have specific TLS passthrough behaviors that the prompt cannot know unless you include those constraints explicitly.

Do not use this prompt as a substitute for a security review of your routing policies. It will generate technically valid YAML, but it cannot reason about whether exposing a particular backend via a specific path creates an unintended authorization bypass or violates your network segmentation policy. Similarly, do not use it to generate routes for controllers you have not validated against—if your cluster runs an older version of a Gateway API controller that does not support HTTPRouteMatch with regular expressions, the generated YAML will fail at runtime even if it passes schema validation. The next step after reading this section is to review the prompt template, identify which variables your system must supply, and build the validation harness described in the implementation section before putting this into production.

This prompt template is designed for platform engineers who need to generate Kubernetes Gateway API HTTPRoute manifests from routing specifications. It accepts structured inputs for hostnames, path rules, backend services, TLS configuration, and rewrite rules, then produces parseable YAML that conforms to the Gateway API schema. The template enforces strict output formatting—only valid YAML inside a fenced code block with no commentary—making it safe to pipe directly into kubectl apply or GitOps pipelines without manual cleanup.

textCopy
Generate a Kubernetes Gateway API HTTPRoute YAML manifest from the following routing specification. Output only valid YAML inside a yaml fenced code block. Do not include commentary, explanations, or markdown outside the code block. The YAML must parse without errors against the Gateway API [API_VERSION] schema. Use correct indentation with 2-space increments. Include all required fields: apiVersion, kind, metadata, spec. Follow these constraints: [CONSTRAINTS]. Hostnames: [HOSTNAMES]. Path rules: [PATH_RULES]. Backend services: [BACKEND_SERVICES]. TLS configuration: [TLS_CONFIG]. Rewrite and filter rules: [REWRITE_RULES]. Namespace: [NAMESPACE]. Route name prefix: [ROUTE_NAME_PREFIX]. Additional labels: [LABELS].

Adapt this template by replacing each square-bracket placeholder with concrete values from your routing specification. For [API_VERSION], use the exact Gateway API version your cluster supports (e.g., gateway.networking.k8s.io/v1). The [CONSTRAINTS] field should include explicit rules like 'do not use regular expression path matching' or 'all backends must reference Services in the same namespace.' For [PATH_RULES], provide structured path definitions with match types (Prefix, Exact, PathPrefix) and corresponding backend references. The [BACKEND_SERVICES] placeholder expects service names, ports, and optional weight values for traffic splitting. [TLS_CONFIG] should specify certificate references, hostname verification mode, or passthrough settings. [REWRITE_RULES] covers URL rewrites, header modifications, and request/response filtering. Always validate the generated YAML with kubectl apply --dry-run=server or a schema validation tool like kubeconform before deploying. For production use, add a post-generation validation step that checks for hostname collisions with existing routes, verifies backend service existence, and confirms TLS certificate availability in the target namespace.

The prompt template produces a fenced YAML code block inside a model response. Your application must extract that block reliably before the YAML ever touches a Kubernetes API. Build an extraction function that locates the first ```yaml fenced block in the model output, strips the fences, and passes the raw string to a strict YAML parser such as PyYAML (Python) or js-yaml (Node.js). Do not attempt to parse the YAML with regex or manual string splitting—strict parsers catch indentation errors, duplicate keys, and invalid type coercions that regex-based approaches miss. If the model response contains no fenced YAML block, treat it as a generation failure and do not proceed to validation.

After parsing succeeds, run the resulting manifest through a dry-run validator before any apply operation. Use kubectl apply --dry-run=server against the target cluster or a schema validator like kubeconform with the appropriate Gateway API CRD schemas. For Gateway API HTTPRoute resources, validate against the installed CRD version in your cluster (v1, v1beta1, or v1alpha2) to catch field name changes and removed API versions. If validation fails, capture the full error message and feed it back into a retry prompt that includes the original specification, the previously generated YAML, and the specific validation error. Structure the retry prompt to instruct the model to fix only the reported error while preserving the rest of the manifest. Set a maximum of 3 retry attempts. After the third failure, escalate to a platform engineer with the full generation history, all validation errors, and the original specification for manual review.

Log every generation attempt with structured metadata: the input variables passed to the prompt template, the raw model output, the extracted YAML, the validation result (pass/fail), any error messages, and the retry count. Store these logs in your observability platform with a correlation ID that ties together all attempts for a single generation request. For production systems, require human approval on any generated route that exposes a new backend service or modifies TLS configuration. Implement this as a review queue where generated manifests are held in a pending state until a platform engineer approves them. Store approved manifests in version control with the prompt variables and approval metadata as commit metadata, creating an audit trail that links every deployed route back to its generation request.

Implement host collision detection before applying generated HTTPRoute resources. Query the target namespace for existing HTTPRoute objects and extract their hostnames from the spec.hostnames field. Compare the proposed hostnames against the existing set. If a collision is detected, either reject the generation and notify the requester, or route to a human approval step that explicitly acknowledges the shared hostname configuration. This prevents accidental route conflicts where a newly generated manifest would silently override or conflict with existing traffic routing. For Gateway API resources that reference TLS certificates via spec.tls.certificateRefs, verify that the referenced Secret exists in the target namespace before applying the route, and flag missing Secrets as a pre-validation failure that does not count against the retry budget.