Deployment patterns

Learn how you can deploy kgateway proxies to ensure proper traffic routing, security, and isolation for your apps.

The flexibility of kgateway allows you to deploy it in a way that best serves your environment. Review the following recommended deployment patterns to choose how to set up kgateway proxies.

Simple ingress

The following image shows a kgateway proxy that serves as a single ingress API gateway to the workloads in a Kubernetes cluster. The gateway is centrally managed by the kgateway control plane and configured to match and forward traffic based on the traffic management, resiliency, and security rules that you define.

This setup is a great way to get started with kgateway, and is suitable for smaller environments where all workloads run in a single cluster and traffic is balanced between services. However, in larger environments or environments where you have both high traffic and low traffic services, consider adding multiple gateway proxies to distribute traffic load more evenly.

Sharded gateway

In larger environments or environments where you have both high traffic and low traffic services, you can isolate services from each other and protect against noisy neighbors by using a sharded gateway. With a sharded gateway architecture, you typically have multiple gateway proxies that split up the traffic for different services in the cluster as depicted in the following image.

All gateway proxies are managed by the kgateway control plane. However, one gateway proxy manages traffic for the workloads in the foo and bar namespaces. The second gateway proxy is a dedicated API gateway for the workloads in the extra namespace. Both gateway proxies are exposed directly on the edge.

While this setup is great to split up and load balance traffic across apps, you might not want the gateway proxies to be exposed directly on the edge. Instead, you might want a central ingress gateway proxy that applies common traffic management, resiliency, and security rules, and that forwards traffic to other gateway proxies that are dedicated to certain apps, teams, or namespaces. To learn more about this deployment pattern, see Sharded gateway with central ingress.

Sharded gateway with central ingress

The following image shows a kgateway proxy that serves as the main ingress endpoint for all traffic. The gateway proxy can be configured to apply common traffic management, resiliency, and security rules to all traffic that enters the cluster. For example, you can set header manipulation policies on that gateway before you forward traffic to a second layer of gateway proxies. This is useful if you need a central IP address and DNS name for the gateway that serves all your traffic.

The second layer of gateway proxies can apply additional traffic management, resiliency, and security policies to incoming traffic for specific apps. You also shard the second layer of proxies to better account for high and low traffic services to avoid noisy neighbor problems. All gateway proxies are managed by the same kgateway control plane.

Depending on your existing setup, you might want to use a different type of proxy as your central ingress endpoint. For example, you might have an HAProxy or AWS NLB/ALB instance that all traffic must go through. Kgateway can be paired with these types of proxies as depicted in the following image.

API gateway for a service mesh

Ambient mesh

You can deploy kgateway as an ingress, egress, or waypoint proxy gateway for the workloads in an Istio ambient mesh. An ambient mesh uses node-level ztunnels to route and secure Layer 4 traffic between pods with mutual TLS (mTLS). Waypoint proxies enforce Layer 7 traffic policies whenever needed.

The following image shows a kgateway proxy that is exposed on the edge and serves traffic for the ambient mesh. Services in the mesh communicate with each other via mutual TLS (mTLS).

For more information, see the guides for using kgateway as an ingress gateway or waypoint proxy for your ambient mesh.

Sidecar mesh

You can deploy kgateway with an Istio sidecar to route traffic to services in an Istio sidecar mesh. The following image shows a kgateway proxy that is exposed on the edge and serves traffic for the sidecar mesh. Services in the mesh communicate with each other via mutual TLS (mTLS) by using the istio-proxy sidecar that is injected into the app. The sidecar is represented with the Envoy logo in the image.

For more information, see the guide for using kgateway as an ingress gateway to your sidecar mesh.