Homework

Apply what you learned about Gateway API by building Helm templates for real-world routing scenarios.

Task 1

Helm-Templated Gateway and HTTPRoute

Create a Helm chart called gateway-app that templates a Gateway and an HTTPRoute as separate resources in the templates/ directory. The chart should support the following values.yaml structure:

gateway:
  enabled: true
  className: envoy
  listeners:
    - name: http
      port: 80
      protocol: HTTP
    - name: https
      port: 443
      protocol: HTTPS
      tls:
        mode: Terminate
        certificateRef: wildcard-cert

httproute:
  enabled: true
  hostnames:
    - "app.example.com"
  rules:
    - path: /api
      serviceName: api-svc
      servicePort: 8080
    - path: /
      serviceName: frontend-svc
      servicePort: 80

Requirements:

Both the Gateway and HTTPRoute templates must be gated by their respective .enabled flags.
The Gateway template must iterate over .Values.gateway.listeners and conditionally include a tls block only when the listener defines one.
The HTTPRoute template must iterate over .Values.httproute.rules to produce one rule per entry with a PathPrefix match.
Use standard Helm helpers (include "gateway-app.fullname", include "gateway-app.labels") for metadata.

Self-Check

helm template gateway-app ./gateway-app renders valid YAML with no errors.
Setting gateway.enabled=false suppresses the Gateway resource entirely.
The HTTPS listener includes a tls section; the HTTP listener does not.
Each rule in the HTTPRoute has type: PathPrefix and correct backendRefs.
helm template output passes kubectl apply --dry-run=server against a cluster with Gateway API CRDs installed.

Task 2

HTTPRoute with Filters

Extend the chart from Task 1 (or create a new one) to support HTTPRoute filters. Add the following capabilities to the values.yaml:

httproute:
  enabled: true
  hostnames:
    - "shop.example.com"
  rules:
    - path: /old-api
      filters:
        - type: RequestRedirect
          requestRedirect:
            scheme: https
            hostname: shop.example.com
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /api/v2
            statusCode: 301
    - path: /api
      filters:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            set:
              - name: x-request-id
                value: "{{ .Release.Name }}"
            add:
              - name: x-forwarded-prefix
                value: /api
      serviceName: api-svc
      servicePort: 8080

Requirements:

Rules that define filters must render a filters: section in the HTTPRoute YAML.
Rules without filters must omit the section entirely (no empty filters: []).
A redirect rule (no serviceName) must not render a backendRefs section.
The filter configuration must be passed through using toYaml so arbitrary filter types are supported without template changes.

Self-Check

The redirect rule renders RequestRedirect filter with no backendRefs.
The API rule renders both the RequestHeaderModifier filter and a backendRefs entry.
Adding a new filter type (e.g., URLRewrite) to values.yaml works without changing the template.
helm lint ./gateway-app passes with no errors or warnings.

Task 3

ReferenceGrant for Cross-Namespace Routing

Create a Helm template for a ReferenceGrant that allows HTTPRoutes in specified source namespaces to reference Services in the chart's release namespace. Support the following values:

referenceGrant:
  enabled: true
  grants:
    - name: allow-frontend
      fromNamespaces:
        - frontend
        - staging-frontend
      toKinds:
        - group: ""
          kind: Service
    - name: allow-monitoring
      fromNamespaces:
        - monitoring
      toKinds:
        - group: ""
          kind: Service
        - group: ""
          kind: Secret

Requirements:

Each entry in .Values.referenceGrant.grants produces a separate ReferenceGrant resource.
Use range to iterate over fromNamespaces and produce one from entry per namespace, each with group: gateway.networking.k8s.io and kind: HTTPRoute.
The to section must iterate over toKinds to support granting access to multiple resource kinds.
Each ReferenceGrant must be deployed in the release namespace (the target namespace for the references).

Self-Check

helm template produces two separate ReferenceGrant resources (one per grant).
The allow-frontend grant has two from entries (frontend and staging-frontend).
The allow-monitoring grant has two to entries (Service and Secret).
All ReferenceGrants use apiVersion: gateway.networking.k8s.io/v1beta1.
Disabling referenceGrant.enabled suppresses all ReferenceGrant resources.

Grading Rubric

Criterion	Points	Description
Task 1 — Gateway template	15	Conditional TLS block, listener iteration, proper gating
Task 1 — HTTPRoute template	15	Rule iteration, PathPrefix matches, correct backendRefs
Task 2 — Filter support	20	Conditional filters section, redirect without backendRefs, toYaml passthrough
Task 3 — ReferenceGrant	20	Multiple grants via range, from/to iteration, correct apiVersion
Helm best practices	15	Named templates for labels/fullname, consistent metadata, lint passes
Validation	15	All templates pass helm template and kubectl dry-run, toggle flags work

Bonus challenge: Add a dualStack toggle to your values that, when enabled, templates both an Ingress resource and a Gateway API HTTPRoute from the same values. This mirrors the real-world migration pattern where teams run both side by side during the transition from Ingress to Gateway API.