Choosing the Best Kubernetes API Gateway: comparing Kong, Envoy, and kgateway

API Gateways in Kubernetes: A Quick Glimpse

Think of your Kubernetes cluster as a busy city. Microservices are like the traffic moving through it. To avoid chaos and ensure everything runs smoothly, you need something to control and guide the flow. That's where an API Gateway comes in. It acts like the city's main traffic controller, managing where each request goes, ensuring security, balancing the load, and keeping the system organized.

So far, Kubernetes relied on the Ingress API for its API Gateway purposes. Ingress manages basic HTTP routing and TLS certificate management, but basic Ingress struggles with modern workloads which require WebSockets, gRPC, or the ability to run multi-tenant workloads. Here comes the Kubernetes Gateway API, the next generation traffic manager where you can use modular and role-oriented and multi-protocol ready records.

Why Gateway API Matters

Gateway API adds Custom resources like GatewayClass, Gateway, and HTTPRoute and addresses the topics of TCP, UDP, HTTP, traffic splitting, header rewrites as well as mTLS. This API also solved the problem of cluster operators who manage infrastructure while permitting developers to control routing, a touchy domain for both without inflicting any damage.

Envision a game platform. Everything seamlessly managed via Gateway API. UDP for multiplayer access, mTLS for service security, and others.

Ecosystem Buzz

From theory to reality since its v1.0 GA release in 2023, Gateway API has evolved a great deal. Developers on Twitter say it is "Kubernetes networking done right". Ingress is not dying, but the Gateway API is the future.

Kong Gateway Overview

Kong Gateway is an open-source API solution that is flexible, secure, and scalable which helps ease the development of APIs and microservices. In addition, it supports modern application architectures like microservices and Kubernetes environments since it provides a cloud-native reverse proxy that efficiently manages, configures, and routes API traffic.

Brief History and Adoption Reasons

Kong Gateway grew and gained popularity when it started as an open-source project as a result of its outstanding performance, extensibility, community support, and a rich ecosystem of over a thousand plugins. On top of that, Kong Gateway is built on reliable technologies such as NGINX, and supports declarative configuration.

Organizations adopted Kong because it offers:

• Higher reliability and scalability with the ability to handle traffic of twenty times that of Netflix worldwide.
• Strong security features including OAuth 2.0 and OpenID Connect support, mutual TLS, and integration with third-party secrets managers.
• Flexibility and extensibility through plugins and support for serverless code execution in a sandboxed Lua environment.
• Kubernetes-native operation with zero downtime updates and efficient resource use.

Why Organizations Are Moving Away from Kong Gateway

Despite its strengths, some organizations are reconsidering Kong Gateway due to several challenges:

Modern Open Source Alternatives to Kong Gateway

With the increasing adoption of cloud-native infrastructure, newer alternatives to Kong Gateway are emerging. These below listed options are the most prominent ones with the support of Open source.

Key Alternatives:

• Envoy Gateway
• kgateway
• Istio Gateway
• Traefik Gateway
• NGINX Gateway Fabric

Even though there are many options substituting Kong Gateway, in this overview we look at Envoy Gateway and Kubernetes Gateway (kgateway), since they are the most open source compliant and Kubernetes-native solutions.

Envoy Gateway

Serving as a modern ingress and API gateway for Kubernetes, Envoy Gateway is a CNCF project built on top of the Envoy Proxy. It uses Kubernetes Gateway API for sophisticated routing and aligns well with service mesh ecosystems.

Benefits

• It is basically designed to lower the barrier for adopting Envoy as an API gateway, with straightforward Kubernetes-native configuration
• Comprehensive built-in support for TLS, OAuth2, OIDC, detailed metrics, and tracing.
• I can be integrated seamlessly with service meshes like Istio, managing north-south traffic while collaborating with mesh for east-west
• It has fast-growing community, frequent releases, and strong CNCF backing

Limitations:

• It is developing rapidly, though it still doesn't have some of the sophisticated enterprise capabilities and integrations offered by older gateways like kgateway.
• Some advanced functionalities, such as traffic management for AI, will require additional tools or specialized development.
• The community remains comparatively younger and less established than more developed, long-standing gateway projects.

Envoy Gateway Installation

helm install eg oci://docker.io/envoyproxy/gateway-helm --version v1.4.2 -n envoy-gateway-system --create-namespace
kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/v1.4.2/quickstart.yaml -n default
bash

Get the name of the Envoy host:

export GATEWAY_HOST=$(kubectl get gateway/eg -o jsonpath='{.status.addresses[0].value}')
bash

Test routing through Envoy Gateway:

curl --verbose --header "Host: www.example.com" http://$GATEWAY_HOST/get
bash

Testing some features

Connection limit

cat <<EOF | kubectl apply -f -
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: ClientTrafficPolicy
metadata:
  name: connection-limit-ctp
  namespace: default
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: eg
  connection:
    connect
EOF
yaml

hey -c 10 -q 1 -z 10s  -host "www.example.com" http://${GATEWAY_HOST}/get
bash

IP Allowlist/Denylist

cat <<EOF | kubectl apply -f -
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: authorization-client-ip
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: backend
  authorization:
    defaultAction: Deny
    rules:
    - action: Allow
      principal:
        clientCIDRs:
        - 10.0.1.0/24
EOF
yaml

Verify

echo $GATEWAY_HOST
curl -v -H "Host: www.example.com" "http://${GATEWAY_HOST}/"
bash

Kubernetes Gateway (kgateway)

kgateway is a CNCF-hosted project implementing the Kubernetes Gateway API for managing Layer 4 and Layer 7 traffic in clusters. Built on Envoy and using a declarative API, it enables scalable, cloud-native traffic routing. By separating GatewayClass, Gateway, and Route resources, it supports role-based control for ingress, service mesh, and load balancing. It handles HTTP, TCP, gRPC, and WebSocket traffic, with features like authentication and rate limiting.

Benefits:

• It has long track record (as Gloo), robust support for advanced routing, security, and resiliency
• Specialized features for AI/LLM traffic management, including prompt safety, cost control, and multi-backend routing
• Extensibility: Custom CRDs and extensions for advanced policies, traffic simulation, and integration with external identity providers
• It has been proven at scale which handles billions of API requests for major enterprises

Limitations:

• Some features may be overkill for basic API gateway needs or small-scale deployment.
• As a newly donated CNCF project, some governance and roadmap aspects are still being stabilized.
• Some of the features in terms of security are still unavailable. There is a draft PR for that and which will be available in the future iteration.

kgateway Installation

Install the custom resources of the Kubernetes Gateway API:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.1/standard-install.yaml
bash

Deploy the gateway CRDs:

helm upgrade -i --create-namespace --namespace kgateway-system --version v2.0.3 kgateway-crds oci://cr.kgateway.dev/kgateway-dev/charts/kgateway-crds
bash

Install the gateway Helm chart:

helm upgrade -i -n kgateway-system kgateway oci://cr.kgateway.dev/kgateway-dev/charts/kgateway --version v2.0.3
bash

Once, the kgateway pod is up and running. Consider the following guide to deploy the sample application.

Testing some feature:

Traffic splitting

kubectl create namespace helloworld
kubectl -n helloworld apply -f https://raw.githubusercontent.com/solo-io/gloo-edge-use-cases/main/docs/sample-apps/helloworld.yaml
bash

Set up weighted routing:

kubectl apply -f- <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: traffic-split
  namespace: helloworld
spec:
  parentRefs:
  - name: http
    namespace: kgateway-system
  hostnames:
  - traffic.split.example
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: helloworld-v1
      port: 5000
      weight: 10
    - name: helloworld-v2
      port: 5000
      weight: 10
    - name: helloworld-v3
      port: 5000
      weight: 80
EOF
yaml

Verify

for i in {1..20}; do curl -i http://$INGRESS_GW_ADDRESS:8080/hello -H "host: traffic.split.example:8080"; done
bash

Comparative Analysis: Kong Gateway vs. Envoy Gateway vs. kgateway

Similarities Across Three Gateways

• All three serve as API gateways for managing and securing traffic in modern applications.
• They support L4/L7 routing, load balancing, authentication, authorization, and observability features.
• They provide extensibility through plugins or modules, enabling customization.
• They are open-source projects designed for high-performance traffic management.

Feature Comparison Table

Community Support & Maturity Level

Conclusion

If future-proofing, Kubernetes-native architecture, and leading-edge Envoy-based technology are your priorities, Envoy Gateway or kgateway are recommended. Both offer outstanding Kubernetes integration and state-of-the-art routing/security features. If high performance and low latency requirements are today's must-haves, with a mature plugin ecosystem, Kong Gateway is still an option but consider an eventual transition to Envoy-based platforms. kgateway is best suited for complex ingress and service mesh needs; Envoy Gateway is simpler to deploy and has good community support.

In summary:

• Utilize Kong Gateway if you need immediate high-load performance and established ecosystem with regard to possibly migrating to it in the future.
• Choose Envoy Gateway for widespread contemporary API gateway needs that are Kubernetes and cloud-native designs compatible.
• Apply kgateway when superior Kubernetes-native deep routing, AI, or multi-cluster cases and service mesh extension take precedence.

Confused? Don't worry, we've covered all the bases. If you're still unsure, feel free to reach out to our team for personalized guidance. Book a slot. Schedule a meeting.