Gateway API Application Stack on Kubernetes

The Kubernetes Ingress API handles basic HTTP routing but requires vendor-specific annotations for advanced features and mixes infrastructure and routing concerns into a single object. This template deploys a full application stack using the Kubernetes Gateway API, including a GatewayClass, a Gateway for HTTPS traffic, an HTTPRoute for L7 routing, automated TLS via cert-manager, and a ConfigMap-backed application service.

What's Included

Component	Type	Port	Role
GatewayClass	GatewayClass	-	Defines the infrastructure provider and gateway configuration standards
Gateway (prod-gateway)	Gateway	443	External HTTPS traffic entry point
HTTPRoute (main-app-route)	HTTPRoute	-	L7 routing rules directing traffic to backend services
ClusterIssuer	ClusterIssuer	-	Automated Let's Encrypt TLS certificate provisioning
TLS Secret	Secret	-	SSL/TLS certificate storage
App Secrets	Secret	-	Sensitive application configuration
ConfigMap (app-config)	ConfigMap	-	Non-sensitive environment variables
Service	Service	-	Stable DNS routing to application pods

Architecture Overview

The GatewayClass defines the infrastructure provider and is cluster-scoped. The prod-gateway Gateway listens on port 443 and terminates TLS using a certificate provisioned by cert-manager via Let's Encrypt. HTTPRoutes attach to the Gateway and define L7 routing rules that direct traffic to the backend Service. Application configuration is split between a ConfigMap for non-sensitive values and a Kubernetes Secret for credentials.

Why Gateway API

Kubernetes Ingress was designed for simple HTTP routing and depends on vendor-specific annotations for anything beyond basic path and host matching. Over time, annotation sprawl makes Ingress configurations fragile and tightly coupled to a specific controller. Gateway API solves this by replacing annotations with structured Kubernetes objects and separating responsibilities across three layers: the GatewayClass is owned by the infrastructure provider or cluster admin, the Gateway is managed by the platform team, and HTTPRoutes are configured by application developers. This means each team manages only the objects within their scope, without touching shared infrastructure.

Prerequisites

A Kubernetes cluster with a Gateway API compatible controller installed (e.g. Envoy Gateway, Istio, or NGINX Gateway Fabric)
cert-manager installed and configured for Let's Encrypt
A domain name pointed at your cluster's Gateway IP
KubeKanvas CLI installed and running on your computer (Optional, if you want to use one-click deployment)

How to Deploy

Click on the button at the top right corner of this page to load the manifest into the editor.
Update the GatewayClass name to match the controller installed on your cluster.
Set your domain name in the Gateway and HTTPRoute configuration.
Update the ClusterIssuer with your email address for Let's Encrypt certificate registration.
Add your application credentials to the App Secrets component.
Deploy the template to your cluster via the Play button in the top right bar. If you prefer to deploy manually, download the YAML and apply it with kubectl.
Wait for all pods to reach Running status. You can monitor progress in the Release Monitor screen.

How to Test

Verify the Gateway has been assigned an external IP: kubectl get gateway -n <namespace>.
Confirm the TLS certificate has been issued: kubectl describe certificate -n <namespace>.
Send an HTTPS request to your domain and verify the application responds: curl -I https://<your-domain>.
Check the HTTPRoute status shows Accepted: kubectl describe httproute -n <namespace>.

Use Cases

Multi-team routing management: Allowing application developers to manage their own HTTPRoutes without requiring access to the shared Gateway or GatewayClass objects.
Advanced L7 routing: Implementing traffic splitting, header-based routing, or weighted backends that Ingress cannot express without annotations.
Ingress migration: Replacing annotation-heavy Ingress configurations with structured Gateway API objects that have explicit role separation.
Controller-agnostic routing: Using a routing model that works consistently across different Gateway implementations (Envoy, Istio, NGINX) without changing the HTTPRoute definitions.

Summary

This template configures a Kubernetes Gateway API application stack with HTTPS termination, automated TLS, and L7 routing separated across GatewayClass, Gateway, and HTTPRoute objects. For a full walkthrough, read Migrating from Ingress to Gateway API: The Modern Way to Expose Kubernetes Services

Tags:

#Kubernetes#GatewayAPI#CloudNative#ProductionReady#ScalableArchitecture#K8sSecurity

Created by:

Mahmood

Gateway API Application Stack on Kubernetes template preview

4 uses

What's Included

Component	Type	Port	Role
GatewayClass	GatewayClass	-	Defines the infrastructure provider and gateway configuration standards
Gateway (prod-gateway)	Gateway	443	External HTTPS traffic entry point
HTTPRoute (main-app-route)	HTTPRoute	-	L7 routing rules directing traffic to backend services
ClusterIssuer	ClusterIssuer	-	Automated Let's Encrypt TLS certificate provisioning
TLS Secret	Secret	-	SSL/TLS certificate storage
App Secrets	Secret	-	Sensitive application configuration
ConfigMap (app-config)	ConfigMap	-	Non-sensitive environment variables
Service	Service	-	Stable DNS routing to application pods

Architecture Overview

Why Gateway API

Prerequisites

A Kubernetes cluster with a Gateway API compatible controller installed (e.g. Envoy Gateway, Istio, or NGINX Gateway Fabric)

cert-manager installed and configured for Let's Encrypt

A domain name pointed at your cluster's Gateway IP

KubeKanvas CLI installed and running on your computer (Optional, if you want to use one-click deployment)

How to Deploy

Click on the button at the top right corner of this page to load the manifest into the editor.

Update the GatewayClass name to match the controller installed on your cluster.

Set your domain name in the Gateway and HTTPRoute configuration.

Update the ClusterIssuer with your email address for Let's Encrypt certificate registration.

Add your application credentials to the App Secrets component.

Deploy the template to your cluster via the Play button in the top right bar. If you prefer to deploy manually, download the YAML and apply it with kubectl.

Wait for all pods to reach Running status. You can monitor progress in the Release Monitor screen.

How to Test

Verify the Gateway has been assigned an external IP: kubectl get gateway -n <namespace>.

Confirm the TLS certificate has been issued: kubectl describe certificate -n <namespace>.

Send an HTTPS request to your domain and verify the application responds: curl -I https://<your-domain>.

Check the HTTPRoute status shows Accepted: kubectl describe httproute -n <namespace>.

Use Cases

Multi-team routing management: Allowing application developers to manage their own HTTPRoutes without requiring access to the shared Gateway or GatewayClass objects.

Advanced L7 routing: Implementing traffic splitting, header-based routing, or weighted backends that Ingress cannot express without annotations.

Ingress migration: Replacing annotation-heavy Ingress configurations with structured Gateway API objects that have explicit role separation.

Controller-agnostic routing: Using a routing model that works consistently across different Gateway implementations (Envoy, Istio, NGINX) without changing the HTTPRoute definitions.