Istio IstioCon 2021, 10 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes Gateway APIs and the future of Istio networking APIs

Description

#IstioCon2021

Presented at IstioCon 2021 by John Howard.

This talk will describe the new Kubernetes Gateway API being developed by the Kubernetes SIG Network as “an evolution of the Ingress API”, and how this will impact Istio.

A

Hey everyone. Thank you for joining today, we're going to be discussing the new kubernetes gateway api, so quick overview of what we're going to be discussing um we're going to talk about this new api. That's been developed out of the kubernetes cig network and some of the motivations for this api and then we're going to discuss easter's plans for these apis in the future.

A

So before we dig into that, I think it's important to take a step back and look at where the apis are today.

A

So from the beginning of kubernetes, there was this ingress api, as you can see from this example here, it provides a pretty simple api to allow traffic to come into the cluster. So one of the great things about this api is that it provides this common denominator for all different implementations.

A

So, with a single object like this, we can have it backed by say, istio or maybe a cloud load, bouncer or something like nginx ingress and to change between those is trivial. You don't need to change all your ingress resources.

A

That's the idea! Anyhow, the problem is that the api is very simple. This is almost the entire api shown here, there's a few other tls rules, but nothing much, and so what ends up happening in practice is that it becomes the lowest common denominator api.

A

So because of that, all the implementations essentially add on their own extensions. So some of them had a bunch of annotations that configure behavior, while others add completely different api replacements. So in the easter case we add the gateway and virtual service apis to supplement the ingress one, so we can expose the rich estro functionality.

A

So the issue with this is now the ingress apis are more feature-rich, but we've lost that common denominator. So we don't have a single api. That's portable between different implementations,.

A

So the new kubernetes gateway apis are an attempt at kind of revisioning. The ingress apis they've often been called the ingress v2 apis and getting back that common api set, while not having the limitations of such a simple api.

A

So the idea is: there's a new collection of resources um which we'll get into later, but there's like gateway, http route, tcp route, back-end policy, a few more which provide kind of the core apis, but for more advanced cases, there's built-in extension points natively into the api, so that someone like estro, who has a lot of features that are maybe not present in the core api, can easily extend and support their full feature set.

A

So we'll give a quick overview of how the api is structured. um We only have 10 minutes, so we can't go too much into detail, but at a high level, there's this top-level resource called the gateway class and this kind of describes which implementations are available in the cluster and high level configuration settings for them. So, for example, we may have an eco gateway class and maybe a cloud load, bounce or gateway class.

A

Then a user would create a gateway referencing one of these classes, and that would be like an instantiation of that gateway. So, for example, we may say I want to open up a load balancer on port 80 and accept http traffic. This is very similar to like a easter gateway. In fact, it has the same name.

A

So from that point, application teams can add routes such as http route shown here, which can do things like on the fu.com domain. Send you know traffic to my food service and send 10 of that to the food canary service or do some sort of matching.

A

You know complex http, filter operations, adding or moving headers. That sort of thing um so part of the benefits of having this api be this kubernetes api, rather than using estros gateway and virtual service, is about the ecosystem.

A

So by using a common api between all these different implementations, we have this huge kubernetes ecosystem that we can tap into so there's already many projects that are istio aware, such as k native and external dns, but they have to do various things to actually integrate with estro. So, for example, k native is adding like this extra estro add-on.

A

um If we had a common api they this would not even be needed at all, because they could just create this common api and estro understands it. Natively now there's a whole other set of projects such as cert manager or a various off-the-shelf helm, charts that are just working with ingresses today and they don't have direct estio integrations so by using the kubernetes apis we'll be able to get. Basically all these integrations for free with estio, assuming that they adopt these new apis. Of course.

A

um The other great thing is, we have seamless migrations to, or or from east geo, so rather than having to migrate, all of your resources from one project special resource to another project special resource there's this common api, so moving between different implementations can be as simple as just changing the gateway class. That's referenced.

A

So I want to do a quick comparison of the two apis, um the estro and the gateway apis. So the first most obvious thing is that the gateway resource has the same name, and if we actually compare two example specs, um you can see they're quite similar, so we have a lot of the same concepts here. um Setting up a listener. We set up support. We declare the protocol the host names it uh hand handles.

A

um So we won't go too into detail on all the specs, but I just want to give a quick view that, like these are similar apis. So while the actual api is changing, the concepts of that estro gateway and virtual service have brought us are going to remain consistent even with these new apis.

A

um Similarly, similarly, we can compare the route with the easter virtual service. We get the same picture.

A

The exact field, names and structure of the api is slightly different, but we're still able to represent all the same things here.

A

So that that last point is is really important, so one of our goals with these new apis is to be able to represent all estrio configuration, that's possible today, with these two apis with the new kubernetes gateway apis, so the the gateway apis have this notion of api field level, which has core extended and custom, so not all of estro feature set is going to be in the core api, of course, because we have a lot of advanced features that won't be implemented by other implementations.

A

Instead, there'll be a small set of core apis. That's expected to be implemented by everyone, and the idea here is that this is a set of features that is most likely good enough for most users and then advanced users can use implementations that implement either extended or custom ones.

A

So these custom ones allow a bunch of extension points to have completely arbitrary configuration.

A

In addition, we'll have we'll go into this a bit more later, but we'll have the ability to infer operate with existing easter resources.

A

So the combination of these two will allow users of the kubernetes gateway apis to get the full feature set that eco offers today, and because this will also be able to uh offer tooling in order to help migrate users to the new apis.

A

So I want to give two examples of how this extensibility works, so one is with actually explicitly referencing easter resources. So, for example, if we want to add some authorization policy into a into a route, we can actually directly reference that from the resource. So this extension ref is a part of the core spec, and so we reference the eastern resource.

A

The other way is a more implicit composition, um so here we have two resources: one is the kubernetes gateway resource and one's in east geo destination. Rule there's nothing linking linking these two explicitly but they're, both modeling the same service, hello, world here and so istio is able to recognize that and layer these apis together.

A

This is a key point, because we know that users may have many many eastern resources, and we don't want to make migration painful and say that you have to go migrate. Your thousands and thousands of resources we want the process to be extremely incremental, and so you can slowly adopt the new apis.

A

You know maybe one service at a time after spinning up new services or, however, works for you um so because the apis are still new. All plans here are tentative and kind of optimistic, but we're hoping that eventually, the gateway apis will become the stable networking apis for estio, but we, like, I said we are not planning to remove the existing ones for quite a while.

A

um So our intent here is not really to replace the ego apis in the short term, but we do plan to have these be the more first class stable apis that we recommend. uh You know that's in our documentation on how to do things, but we totally understand that users have potentially long migration windows that we intend to support.

A

So with that, this is just a quick intro to the apis. If you want to learn more, the gateway api link here has a ton of info of the small specification and details on the api.

A

You can also try out our support for the gateways api in istio to actually try it in a real cluster, and we welcome any feedback both on the estio implementation and the apis themselves. Right now, it's the best time to give feedback, because they're still in alpha, so they're still kind of malleable to any feedback.

A

So I encourage you all to check it out and thank you for.

A