Managing Ingress Traffic and Service Mesh with the Gateway API
Background
In Kubernetes’ original design, Ingress and Service resources were created with the assumption that developers building services would also control how those services are exposed to end users. However, in shared infrastructure environments, this model posed challenges because it didn’t adequately support the needs of developers, cluster operators, and infrastructure administrators.
To address these challenges, the Gateway API introduces a flexible model where different personas, such as platform providers, cluster operators, and application developers, have distinct roles. This allows each group to manage the aspects of traffic routing that concern them, balancing usability and control within shared infrastructures.
As illustrated by its logo, the Gateway API serves a dual purpose: it not only handles North-South (ingress) traffic but also manages East-West (service-to-service or mesh) traffic using the same configuration model.
By enabling both types of traffic routing under a unified API, the Gateway API provides a more streamlined and consistent configuration model, allowing platform providers and cluster operators to manage edge traffic and internal service mesh routing using the same resource definitions.
What is the Gateway API?
The Gateway API represents the next evolution in managing ingress traffic and service-to-service communication within Kubernetes. Unlike the original Ingress model, which assumed that developers would control the exposure of their applications, the Gateway API introduces a more flexible and robust approach tailored for shared infrastructure environments.
The Gateway API defines three key resources:
One of the primary advantages of the Gateway API is its ability to handle both North-South (ingress) and East-West (service-to-service) traffic under a unified configuration model. This capability streamlines the management of traffic flows, allowing platform operators to configure edge traffic and internal routing using the same resource definitions.
The API introduces distinct roles to address the varying needs of users in shared environments:
By separating these roles, the Gateway API strikes a balance between usability and control, enabling more efficient traffic management across shared environments.
Key Benefits
Example: Configuring North-South and East-West Traffic
Here’s a sample configuration using the Gateway API for both ingress traffic and mesh traffic:
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: GatewayClass
metadata:
name: my-gateway-class
spec:
controllerName: example.com/gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
name: my-gateway
spec:
gatewayClassName: my-gateway-class
listeners:
- name: http
protocol: HTTP
port: 80
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
name: my-http-route
spec:
parentRefs:
- name: my-gateway
rules:
- matches:
- path:
type: Prefix
value: "/"
backendRefs:
- name: my-service
port: 80
This configuration manages ingress traffic via the Gateway resource and routes it to the my-service service. It can also be extended to manage East-West traffic by introducing service mesh routes that define internal service-to-service communication.
Security Model - Role-Based Access Control (RBAC)
The Gateway API introduces three roles and personas: Infrastructure Providers, Cluster Operators, and Application Developers. In a small startup, one user might embody all these roles, while in a larger enterprise, distinct individuals or teams would typically take on each role.
To enable this multi-role functionality, RBAC (Role-Based Access Control) is used to define permissions for each persona within the Gateway API's framework. RBAC allows Kubernetes administrators to specify who can perform certain actions on specific objects within the cluster.
领英推荐
Route Binding
Routes can be connected to Gateways in different namespaces. To accomplish this, the Gateway owner must explicitly allow Routes to bind from additional namespaces. This is configured by setting allowedRoutes within a Gateway listener as follows:
namespaces:
from: Selector
selector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: In
values:
- foo
- bar
This configuration allows routes from the "foo" and "bar" namespaces to attach to this Gateway listener.
Advanced Concept: Limiting Namespaces Where a GatewayClass Can Be Used
Some infrastructure providers or cluster operators may wish to limit the namespaces where a GatewayClass can be used. Currently, there is no built-in solution for this within the Gateway API. Instead, we recommend using a policy agent such as Open Policy Agent and Gatekeeper to enforce these policies.
Using OPA and Gatekeeper to Enforce Namespace Restrictions
Open Policy Agent (OPA), along with Gatekeeper, allows for defining and enforcing policies within your Kubernetes cluster. These tools enable infrastructure providers to set rules on where certain resources can be created and managed.
Example Configuration
Here’s an example configuration that demonstrates how to limit the namespaces where a GatewayClass can be utilized:
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: gatewayclass-namespaces
spec:
crd:
spec:
names:
kind: GatewayClassNamespace
validation:
openAPIV3Schema:
type: object
properties:
namespaces:
type: array
items:
type: string
validation:
message: "GatewayClass can only be created in specified namespaces."
rego: |
package gatewayclassnamespaces
violation[{"msg": msg}] {
input.review.object.kind == "GatewayClass"
not input.review.object.metadata.namespace in data.allowed_namespaces
msg = sprintf("GatewayClass can only be created in one of the allowed namespaces: %v", [data.allowed_namespaces])
}
In this configuration:
For more details, refer to the example of configuration
The Use Cases
The Gateway API covers a broad range of use cases, presenting both strengths and challenges. Here’s a summary of its key applications:
Implementations of the Gateway API
The Gateway API has gained traction in various environments, leading to several popular implementations that enhance its functionality. Here are a few notable ones:
For a complete list of implementations and additional details, please refer to the official Gateway API Implementations page.
Conclusion
The Gateway API is a robust and flexible tool for managing ingress and service traffic in Kubernetes. Its ability to handle both North-South and East-West traffic in a unified configuration model makes it a significant step forward in Kubernetes traffic management. Whether you are managing basic HTTP ingress or advanced mesh traffic, the Gateway API provides a modern, vendor-neutral approach that works across implementations and simplifies operations.
References: