Kubernetes Gateway API: The Intro You Need To Read
Welcome to my Kubernetes blogs. The blogs aim to provide you with effective Kubernetes knowledge and tools that increase efficiency while reducing stress and time to deliver high-quality solutions. Click the follow button to be notified when a new story is released.
Let’s get into it…
Have you heard about Kubernetes Gateway API by SIG-NETWORK before? Well, possibly most of you are encountering this topic for the first time. Still, regardless if this is your first time hearing about it or if you are already using it in some way, the purpose of this blog is to give you a baseline and high overview to understand this topic.
From understanding the need for Kubernetes Gateway API to exploring its use cases, this blog aims to provide you with a comprehensive guide on everything you need to know about this revolutionary tool for service networking in Kubernetes.
So in this blog, we are going to cover the following topics:
- Constraints and Limitations of Ingress Resource
- How Can Services be Exposed by Layer 4 Routing?
- Who is Kubernetes SIG-NETWORK, and What Drives Their Purpose?
- What is the reason for SIG-NETWORK to open the Kubernetes Gateway API project?
- A Comprehensive Look at the Kubernetes Gateway API [ PART TWO]
Constraints and Limitations of Ingress Resources
To understand the need for Kubernetes Gateway API, we will need to understand the ingress resource, which was introduced in 2015 and graduated as a stable API in Kubernetes 1.19. The ingress resource manages external traffic access to the appropriate Kubernetes service based on the requesting host, path, or combination of both. Ingress resource help to expose multiple services under the same load balancer, provide load balancing, SSL termination, and more.
While the ingress resource is a valid choice for layer 7 routing (HTTP, HTTPS), it comes short when it needs to serve layer 4 traffic (TCP, UDP) which is being used to expose services such as databases, message brokers, and more.
How Can Services be Exposed by Layer 4 Routing?
For serving layer 4 traffic for databases, message brokers, and more, you have several options.
One option is to use kubectl port-forward for internal access by developers to keep cloud costs low.
Another option is to use a LoadBalancer type service for external access to other services, developers or users, which is a simple solution for layer 4 routing.
Additionally, you can use service mesh providers like Kong or Istio, which offer the capability of routing both layer 4 and layer 7 traffic through a single load balancer IP address.
However, it is worth noting that service mesh providers such as Istio and Kong have their own proprietary APIs, leading to a lack of standardization in serving both layer 4 and layer 7 traffic.
Who is Kubernetes SIG-NETWORK, and What Drives Their Purpose?
SIG-NETWORK is a sub-community within the Kubernetes community focused on networking in Kubernetes. The SIG-NETWORK is responsible for developing, maintaining, and supporting the network-related components of the Kubernetes platform.
SIG-NETWORK aims to ensure the network functionality of Kubernetes is robust, scalable, and able to meet the needs of a wide variety of use cases.
What is the reason for SIG-NETWORK to open the Kubernetes Gateway API project?
Currently, there are solutions in the Kubernetes space which provide their own gateway solutions and their own API specific which allow them to route layer 4 and layer 7 traffic to Kubernetes services.
SIG-NETWORK community had started the Kubernetes Gateway API to create unified API resources and standards for route traffic of layer 4 and layer 7. The Kubernetes Gateway API provides a common interface for different third party solutions such as Kong and Istio.
While this project is currently in beta version, there is already adoption from major players in this field.
Youtube video by kong on API Gateway and demo with their controller
Blog from Istio regards API Gateway
Conclusion
In conclusion, the Kubernetes Gateway API is filling a gap in standardization left by the Kubernetes Ingress resource. Despite being in beta, it has already received support from prominent tools like Istio and Kong. This demonstrates the potential of the Kubernetes Gateway API to become a widely adopted solution for managing network traffic in Kubernetes environments.
Thank you, if you have any questions or need any help you can reach me over LinkedIn. Let me know if you want an in-depth review of Velero in the comments below or via direct message. Part two will be posted soon so feel free to hit the follow button and the notification so you will be notify when it come out.
***********************************************************************
Links:
www.kubegurus.com (Visit our company website)
https://www.linkedin.com/in/dekel-malul/ (Connect with me at Linkedin)
https://www.linkedin.com/company/kubegurus/ (Follow us in Linkedin for execlusive videos)
