Decoupling Network Policies

Decoupling network policies means moving policy decisions out of individual services. An API gateway becomes the orchestration layer that forwards requests so that frontend code and backend API endpoints are not tightly coupled [1].

Simplifying Cluster Operations

The Gateway API is one expression of a decoupled policy layer. It is designed to provide a more flexible, extensible, and powerful way to manage traffic to your services [2]. It provides a standard Kubernetes API for ingress traffic control. It offers extended functionality, improved customization, and greater flexibility [2].

For operators who run clusters across multiple environments, portability reduces the cost of maintaining distinct ingress configurations per cluster. Gateway API is designed to be more portable across different implementations, clusters and environments [2]. That portability is tied to a clear support window: Gateway API commits to supporting the 5 latest Kubernetes minor versions. That means that Gateway API currently supports Kubernetes 1.24+ [2].

Kusk Gateway makes your OpenAPI definition the source-of-truth for both functional and operational aspects of your APIs [3].

openapi: 3.0.3
info:
  title: Payments API
  version: 1.0.0
paths:
  /payments:
  post:
  x-kusk:
  mock:
  enabled: true
  responses:
  '200':
  description: OK

API mocking can be enabled at the root, path, or operation level using a dedicated x-kusk extension in your OpenAPI definition [3]. With the OpenAPI contract driving the gateway, changes to request validation, mocking, and routing can be reviewed as API changes rather than as separate cluster manifests. The design shifts operational knowledge from per-service annotations to a single declarative API description.

The move from service-local policy to a central front door changes the operator workflow. Configuration is consolidated in Gateway API resources and in the API definition used by controllers like Kusk Gateway. The standard API surface means tooling, CI checks, and documentation can target one model instead of multiple implementation-specific CRDs. The constraint is that the gateway implementation must faithfully interpret the Gateway API and the OpenAPI extensions; operators need to validate feature parity between the chosen implementation and the Gateway API version they run.

Improving Performance

An API gateway handles load balancing, security, rate limiting, monitoring, and other cross-cutting concerns for API services [1]. Due to its speed, high availability and reliability, HAProxy can be used as a API gateway [1]. HAProxy can route based on any information found in the HTTP request, including portions of the URL path, query string, and HTTP headers [1].

Centralizing these concerns reduces duplication across services. Load balancing and health checking are performed once at the edge rather than reimplemented per backend. Rate limiting and header-based routing are applied in the gateway, which can inspect any information found in the HTTP request, including portions of the URL path, query string, and HTTP headers [1].

The API gateway becomes the orchestration layer that forwards requests so that frontend code and backend API endpoints are not tightly coupled [1]. That decoupling allows backend services to be changed, scaled, or moved without updating clients, as long as the gateway contract is maintained.

In practice, operators see a reduction in per-pod sidecar or daemon overhead for ingress logic, and a single place to observe traffic patterns. The trade-off is added latency at the front door and a new operational dependency. Capacity planning for the gateway tier becomes critical; the gateway must be sized and made highly available because it sits in the request path for all ingress traffic.

Networking and Security

Kusk Gateway now automatically reloads rotated certificates, easing the usage of SSL/HTTPS for API endpoints [3]. The Kusk Gateway manager automatically keeps track of all the TLS certificates stored in secrets used across all of your EnvoyFleets [3]. As of the beta release, we now generate our webhook certificates internally, removing the need to have CertManager installed and running [3].

Automatic certificate reload reduces manual intervention during rotation windows and limits the risk of expired certificates causing outages. Internal generation of webhook certificates removes an external dependency for the control plane of the gateway itself.

Gateway API provides standard, Kubernetes-backed support for a wide range of features, such as header-based matching, traffic splitting, weight-based routing, request mirroring and more [2]. Header-based matching and traffic splitting let operators enforce access patterns without modifying service code. Request mirroring enables safe testing of new backends against production traffic.

The request path through a decoupled front door can be visualized as:

Centralizing policy evaluation makes auditability more consistent. All ingress decisions are made at the gateway, which can log headers, certificates, and routing decisions in one place. The gateway also becomes the enforcement point for TLS termination, so operators must secure the gateway control plane and secret storage.

Scalability and Flexibility

Gateway API provides standard, Kubernetes-backed support for a wide range of features, such as header-based matching, traffic splitting, weight-based routing, request mirroring and more [2]. The design is intended to be more flexible, extensible, and powerful for traffic management [2].

With Kusk Gateway, the OpenAPI definition drives both functionality and operations [3]. That means API evolution can drive operational changes. Mocking can be enabled at either the root, path or operation level and will result in Kusk Gateway returning the first example response defined in your OpenAPI definition for each operation [3]. Mocking supports development and contract testing without requiring backend availability.

Traffic splitting and weight-based routing supported by Gateway API allow gradual rollouts and canary releases to be expressed declaratively. Operators can shift percentages of traffic between revisions without redeploying services. Request mirroring allows operators to duplicate production traffic to shadow services for validation.

Portability across implementations, clusters and environments [2] means the same Gateway API manifests can be applied in test, staging, and production with different backend implementations. The operational benefit is a consistent policy language across the fleet.

Real-World Examples

Gateway API is designed to provide a more flexible, extensible, and powerful way to manage traffic to your services [2].

For Banking, Education, HealthTech, FinTech and Tax Returns, the core mechanics of a kube-proxy-free, decoupled datapath apply in the same way: ingress policy is centralized, the API surface is standardized, and the gateway handles cross-cutting concerns. The subject means the same operationally across these sectors; the differences are in the constraints placed on the policy rather than in the architecture itself. Regulatory and audit requirements shape what policies are enforced at the gateway — authentication, header validation, rate limits, and TLS — but the pattern of decoupling network policy from individual services remains consistent.

An API gateway handles load balancing, security, rate limiting, monitoring, and other cross-cutting concerns for API services [1]. Due to its speed, high availability and reliability, HAProxy can be used as a API gateway [1]. The API gateway becomes the orchestration layer that forwards requests so that frontend code and backend API endpoints are not tightly coupled [1].

The decoupling reduces per-service networking complexity and centralizes observability, while requiring operators to maintain the gateway tier, its configuration, and the contract between the OpenAPI definition and the Gateway API resources that implement it.

References

1. Using HAProxy as an API gateway, part 1 [introduction] — haproxy.com (1 October 2018)
2. Introducing ingress2gateway; Simplifying Upgrades to Gateway API — kubernetes.io (29 October 2023)
3. Kusk-gateway  OpenAPI-driven Kubernetes Ingress Controller Beta — kubeshop.io (31 March 2022)