Skip to main content
Version: v0.25.0 (Latest)

Cloud Load Balancers

The gateway contract is provider-neutral. AWS, Google Cloud, and Azure each have a managed load balancer that can front the EDK enterprise stack on a single port, terminate wildcard TLS, and route by host and path. This page covers how each one conforms and the single gotcha to watch for on each platform. The edk-enterprise chart ships an example values file per platform under helm/edk-enterprise/examples/.

Two general shapes appear across the three platforms:

  • Gateway API path: set gateway.enabled: true with the platform's GatewayClass, and ingress.legacy.enabled: false. The Gateway and HTTPRoutes fan out by host and path exactly as the Cilium install does.
  • Classic Ingress path: set gateway.enabled: false and ingress.legacy.enabled: true, then configure per-service public ingress hosts and the platform's load balancer annotations.

AWS Application Load Balancer​

Example values: helm/edk-enterprise/examples/gateway-aws-alb-values.yaml.

On AWS you can either use the AWS Gateway API controller (set gateway.enabled: true with the ALB Gateway class) or the classic Ingress path with the AWS Load Balancer Controller. The example file uses the classic path, which is the common choice: one internet-facing ALB terminates TLS on 443 and routes by host and path. The ALB controller groups Ingress objects that share a group.name annotation into a single load balancer, so all public hosts land on one ALB and one port.

ALB preserves the inbound Host header and sets X-Forwarded-Proto by default, so it satisfies the contract without extra tuning.

The gotcha is the certificate. Use one ACM wildcard certificate for *.example.com, which covers the operator host platform.example.com and every tenant host such as acme.example.com, and reference it by ARN:

ingress:
  legacy:
    enabled: true
  public:
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
      alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-east-1:123456789012:certificate/REPLACE-WITH-WILDCARD-CERT
      alb.ingress.kubernetes.io/ssl-redirect: "443"
      alb.ingress.kubernetes.io/group.name: edk-enterprise

GKE Gateway​

Example values: helm/edk-enterprise/examples/gateway-gke-values.yaml.

On GKE, use the Gateway API. One wildcard HTTPS listener terminates TLS for the operator host and all tenant hosts, and HTTPRoutes fan out by host and path. The classic per-service Ingress objects are disabled so the Gateway is the only public entry point.

GKE Gateway preserves the inbound Host header and sets X-Forwarded-Proto by default, so it satisfies the contract without extra tuning.

The gotcha is the managed certificate and DNS. Wildcard TLS for *.example.com has two options. The simple one is tls.mode: secret, which references a pre-created Kubernetes TLS secret. The Google-managed option provisions a Certificate Manager managed certificate for *.example.com, and a wildcard SAN requires DNS authorization rather than load-balancer authorization. Bind the managed certificate to the Gateway with a networking.gke.io/certmap annotation instead of a secret reference.

gateway:
  enabled: true
  className: gke-l7-global-external-managed
  operatorHost: platform
  baseDomain: example.com
  tls:
    mode: secret
    secretName: edk-wildcard-tls
  httpRedirect: true

ingress:
  legacy:
    enabled: false

Azure Application Gateway (AGIC)​

Example values: helm/edk-enterprise/examples/gateway-azure-agic-values.yaml.

On Azure, the example uses the Application Gateway Ingress Controller (AGIC) classic Ingress path. One Application Gateway terminates TLS on 443 and routes by host and path.

The gotcha on Azure is host preservation, and it is the one that breaks tenant routing if missed. AGIC by default rewrites the Host header to the backend pool address before forwarding upstream. Tenant resolution reads the raw inbound Host header, so a rewritten Host makes every request resolve to the wrong tenant or to none. You must keep the original public Host on the way to the backend. Do one of the following:

  • Set appgw.ingress.kubernetes.io/backend-hostname to the public host per service so the forwarded Host matches the inbound host. For tenant hosts this is the wildcard tenant host.
  • Or disable host override on the Application Gateway HTTP setting or backend pool so the inbound Host passes through unchanged.

Verify with a request to a tenant host that the backend sees the original Host and not the pod or service name.

ingress:
  legacy:
    enabled: true
  public:
    annotations:
      kubernetes.io/ingress.class: azure/application-gateway
      appgw.ingress.kubernetes.io/ssl-redirect: "true"
      appgw.ingress.kubernetes.io/appgw-ssl-certificate: edk-wildcard
services:
  platform:
    publicIngress:
      className: azure-application-gateway
      host: platform.example.com
      annotations:
        appgw.ingress.kubernetes.io/backend-hostname: platform.example.com

Wildcard TLS for *.example.com is supplied either from Azure Key Vault, with appgw-ssl-certificate referencing a pre-uploaded certificate as shown, or from a Kubernetes TLS secret referenced in the Ingress tls block.

Next Steps​