 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
The Gateway API, formerly known as the Services API and before that Ingress V2, was first discussed in detail — and in-person — at Kubecon 2019 in San Diego. There were already many well-known and well-documented limitations of Ingress and Kubernetes networking APIs. The Gateway API was intended as a redo of these APIs, built on the lessons from Services, Ingress and the service mesh community.
With a group of Ingress and Service controller implementors assembled, we came up with the properties that we wanted to have in our version 2 of the Kubernetes networking APIs:
Over a year later, there are several Gateway controller implementations in progress that users can use. This overwhelming conformity between implementations demonstrated the demand by vendors and users for a service networking refresh.
To understand how the Gateway API achieves these goals, let’s introduce two of its resources:
A gateway+route is somewhat equivalent to a single Ingress resource. Because they are two resources, it gives the ability for the infrastructure team to own the gateway (and attach policy and configuration to it) and for the app owners to own their routes. This allows less direct coordination between these groups and more developer autonomy.
If this concept is taken further, it also allows many teams to share the same gateway. Gateways provide built-in controls for the way they bind with routes, even across namespace boundaries. This gives admins control of the way apps are exposed to clients. The following diagram shows two different teams in their own respective namespaces using the same load balancer (modeled by a gateway resource).
This arrangement allows app owners to define traffic routing, traffic weighting, redirects or health checks, because these are attributes tied closely to their app. The infrastructure owners may want to define which load balancers the apps can use, which TLS certificates are used or which source IPs are allowed to connect, as these are platform-level attributes independent of the application. The separation of concerns may be different across organizations, and the API model also provides flexibility to match different models of ownership.
The extensibility of the Gateway API also enables new use cases that were not possible before. Released last week, the GKE Gateway controller from Google Cloud allows HTTPRoutes to reference services across different clusters. This opens up the world of multicluster networking for things like multicluster high availability or blue-green/multicluster traffic splitting. Google’s Gateway controller is able to do this multicluster load balancing using its global network, making routing decisions before traffic even gets into the cluster.
While the Gateway API has already shown promise to unify cluster ingress, there already are proposals for modeling sidecar-based service mesh and TCP/UDP load balancing using gateway and route resources. This would bring a unification of routing APIs, which might lower the barrier to entry for new service mesh users and provide some convergence between L4 and L7 as well.
It is early in the journey for the Gateway API, and there is still plenty of work to do. Thanks to well-defined conformance and a layered API model, the Gateway API already shows a lot of promise and a long road ahead.
There are many resources to check out to learn more:
