Cloud Native 6 min read

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.

System Architect Go
System Architect Go
System Architect Go
An Introduction to Kubernetes Gateway API: Concepts, Use Cases, and Limitations

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.

cloud-nativekubernetesservice meshNetworkingingressGateway API
System Architect Go
Written by

System Architect Go

Programming, architecture, application development, message queues, middleware, databases, containerization, big data, image processing, machine learning, AI, personal growth.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.