Kubernetes Gateway API

Dwara implements a Kubernetes Gateway API controller that reconciles Gateway API v1 resources (Gateway, HTTPRoute, GatewayClass) and standard Ingress resources into its config model. The controller watches the Kubernetes API server, translates the watched resources into a Dwara config YAML, and publishes it to a file the gateway hot-reloads.

When to use this

• Your workloads already declare routing with Gateway, HTTPRoute, or Ingress resources and you want Dwara to honor them instead of maintaining a parallel YAML.
• You want standard, portable ingress semantics in Kubernetes while keeping Dwara's policy features on top.

Enabling

The Kubernetes Gateway API controller is compiled into the OSS build (no k8s cargo feature needed)

cargo build

Deployment

Deploy the controller + gateway to a Kubernetes cluster. Three options are provided: raw manifests, Kustomize overlays, and a Helm chart.

Raw manifests

kubectl apply -f deploy/k8s/base/

Kustomize overlays

Environment overlays (dev, staging, prod) layer on the base, adding Service, HPA, PDB, NetworkPolicy, and ServiceMonitor objects as appropriate:

kubectl apply -k deploy/k8s/overlays/dev       # 1 replica, minimal
kubectl apply -k deploy/k8s/overlays/staging   # 2 replicas, HPA + PDB
kubectl apply -k deploy/k8s/overlays/prod      # 3 replicas, full set

Helm chart

helm install dwara deploy/helm/dwara --namespace dwara-system --create-namespace

The chart renders the complete object set (Deployment, Service, HPA, PDB, NetworkPolicy, ServiceMonitor, GatewayClass, RBAC). Toggle each via values; see deploy/helm/dwara/values.yaml.

The deployment runs two containers in a pod:

• controller: the dwara-k8s-controller binary that watches K8s resources and writes the generated config to a shared volume.
• gateway: the dwara gateway binary that hot-reloads the generated config via file-watch.

Configuration

The controller reads configuration from environment variables (set via the dwara-controller-config ConfigMap):

Variable	Default	Purpose
DWARA_K8S_CONTROLLER_NAME	shristilabs.com/dwara	GatewayClass controller name
DWARA_K8S_INGRESS_CLASS	dwara	Ingress class to watch
DWARA_K8S_OUTPUT_CONFIG	/etc/dwara/dwara.yaml	Output config YAML path
DWARA_K8S_NAMESPACE	(empty = all)	Namespace to watch

Supported features

Gateway API (standard channel v1.5)

• Protocols: HTTP, HTTPS, TLS
• TLS modes: Terminate, Passthrough, Reencrypt
• Path matches: Exact, PathPrefix, RegularExpression
• Header matches: Exact
• Query param matches: Exact
• Filters: RequestRedirect, RequestHeaderModifier, ResponseHeaderModifier, URLRewrite
• GatewayClass acceptance and status conditions
• Gateway status (Accepted, Programmed)
• HTTPRoute status (Accepted, ResolvedRefs)

Ingress

• Path types: Prefix, Exact, ImplementationSpecific
• Host-based routing
• TLS (Terminate mode)
• defaultBackend
• IngressClass filtering

Conformance

Self-test suite

The conformance self-test suite validates the translator against conformance-style test vectors. It is deterministic and requires no cluster:

cargo test -p dwara-core --test k8s_conformance
cargo test -p dwara-core --test k8s_controller

Conformance report

Generate the upstream Gateway API conformance report YAML:

dwara-cli k8s conformance-report

Running the upstream conformance suite

To earn the actual conformance badge, run the upstream Go conformance suite against the deployed controller:

git clone https://github.com/kubernetes-sigs/gateway-api.git
cd gateway-api
go test ./conformance -ginkgo.focus="Core" \
  -gateway-class=dwara \
  -controller-name=shristilabs.com/dwara

Submit the resulting report to the Gateway API implementations page to be listed on k8s.io.

Runnable demo

Run this feature against a live gateway: demos/09-operations/ (test script: test-12-kubernetes-gateway-api.sh) in the repository. The demo documents the current limitations alongside what runs today; see its README.