An Introduction to Kubernetes Gateway API: Concepts, Use Cases, and Limitations
This article provides a comprehensive overview of the Kubernetes Gateway API, covering the constraints of Ingress resources, L4 routing methods, the role of SIG-NETWORK, reasons behind the API's development, and a preview of deeper technical details.
You may have heard of SIG-NETWORK's Kubernetes Gateway API, or this might be your first encounter; either way, this blog aims to give you a basic yet thorough overview of the topic.
From understanding the need for the Kubernetes Gateway API to exploring its use cases, this blog serves as a complete guide to the revolutionary networking tool in Kubernetes.
Thus, this article covers the following topics:
Constraints and limitations of Ingress resources
How L4 routing exposes services
What SIG-NETWORK is and what drives its goals
Why SIG-NETWORK started the Kubernetes Gateway API project
A comprehensive understanding of the Kubernetes Gateway API (part two will follow)
Ingress Resources Constraints and Limitations
To grasp the demand for the Kubernetes Gateway API, we need to understand the Ingress resource, introduced in 2015 and promoted to stable in Kubernetes 1.19. Ingress manages external traffic to services based on host, path, or both, enabling multiple services behind a single load balancer with features like SSL termination.
While Ingress is suitable for L7 (HTTP/HTTPS) routing, it falls short for L4 traffic (TCP/UDP) often needed for databases, message brokers, and similar services.
How L4 Routing Exposes Services
To expose L4 traffic for databases, message brokers, etc., you have several options.
One option is using kubectl port-forward for internal access, keeping cloud costs low.
Another is creating a Service of type LoadBalancer to provide external access, a simple L4 routing solution.
You can also employ service‑mesh providers such as Kong or Istio, which allow routing both L4 and L7 traffic through a single load‑balancer IP.
However, note that these service‑mesh solutions have proprietary APIs, leading to a lack of standardization for L4/L7 traffic handling.
What is SIG-NETWORK?
SIG-NETWORK is a sub‑community within the Kubernetes community focused on networking. It develops, maintains, and supports network‑related components of the Kubernetes platform.
The SIG aims to ensure Kubernetes networking is robust, scalable, and meets diverse use‑case requirements.
Why SIG-NETWORK Started the Kubernetes Gateway API Project?
Currently, various solutions in the Kubernetes ecosystem provide their own gateway implementations and specific APIs for routing L4 and L7 traffic to services.
The SIG-NETWORK community launched the Kubernetes Gateway API to create a unified API and standard for both L4 and L7 routing, offering a common interface for third‑party solutions like Kong and Istio.
Although the project is still in beta, major players have already adopted it.
Youtube video by Kong on API Gateway and demo with their controller
Blog from Istio regarding API Gateway
Conclusion
In summary, the Kubernetes Gateway API is filling the standardization gap left by Ingress resources. While still in a testing phase, it has gained support from well‑known tools such as Istio and Kong, demonstrating its potential to become a widely adopted solution for managing network traffic in Kubernetes environments.
System Architect Go
Programming, architecture, application development, message queues, middleware, databases, containerization, big data, image processing, machine learning, AI, personal growth.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.