Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2021, 15 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Sponsored Session: Google Cloud - Multi-cluster, Blue-green Traffic Splitting with the Gateway API

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Sponsored Session: Google Cloud - Multi-cluster, Blue-green Traffic Splitting with the Gateway API

Speakers: Mark Church

The Gateway API is an open source SIG-Network project that is evolving the Kubernetes Ingress specification, making it a much more capable and role-oriented API. This demo will show how to use the Gateway API and its support for weights and HTTP header matching to shift multi-cluster ingress traffic across different Kubernetes clusters. This kind of traffic management enables much safer blue-green, multi-cluster deployments for less risk and more stability in multi-cluster environments.

A

Hi, I'm mark church, product manager from google cloud and I'm here to talk to you about the kubernetes gateway api. The koreans gateway api is a open source specification uh created in the sig network group for modeling service networking in kubernetes, so very much like ingress or service resources.

A

It's intended to up level and be an evolution for service networking kubernetes. That is still a generic standard, supported by a variety of different companies, projects and implementations.

A

There have been a variety of different contributors that have been um contributing to and and helping design the gateway api over the last year, since it was first proposed kubecon san, diego and they're already beginning starting to begin a couple.

A

Different implementations of this gateway of the gateway api that already exist, including ones that model cloud load, balancing cluster, hosted proxies and more don't forget to check out the gateway api sig's website, where you can see more information about the gateway api, including how to get involved with the community attending one of the meetings joining the slack, um seeing how to use the gateway api in one of the available guides that we have or just checking out the implementations that currently exist, that's growing every day, so you might be asking what's wrong with ingress.

A

What what does it not do for us, and why do we need another new api resource? It's a very valid question. Ingress had a lot has a lot of good things going for it. Well, it's very widely adopted. There's many implementations that ingress controllers that exist out there. It's easy to use and understand it, does basic host and path routing, along with tls and the ability to reference services, but it's very basic and so ultimately ingress became a lowest common, honor and denominator api. It was not very expressive.

A

It was not extensible other than in through annotations and as a result, it's become not very portable, and partly this is because it's it's a it's. A tough challenge. There's diverse implementations between hardware load, balancers cloud load, balancers and in-cluster proxies that all have different capabilities constraints and ways that they operate and there's also diverse models in which load balancing really occurs.

A

For instance, there are middle proxy service mesh grpc.

A

All that can do what one might call load balancing in slightly different models, but they have a lot of similarities and overlap between them, and so this is really the challenge of modeling service networking in a generic way, and so that's where gateway really came about.

A

It improves upon ingress in four major ways, and the first is that it's role oriented and what this means is that different personas or roles that use load balancing within a kubernetes cluster can have resources that align to the roles and responsibilities that that role needs that persona needs. It's also expressive in that it provides more features and capabilities than ingress.

A

Does things like header based matching or weight based, load, balancing, there's simply more things within the core api to do what modern load balancers are expected to do it's also much more extensible extensible in that it it has more extension points within the api for projects and vendors and implementations to put their their proprietary or custom capabilities to layer it on the api which allows them to use it without without having to fork or rely on their own custom resources to get this done so that that allows load, balancing and service networking to continue using a core api while having some of the implementation.

A

Specific capabilities lie within the extensions. So let's take a look at the resources that the gateway api has so there's a couple new ones that you might see gateway, class gateway and http route, and so these are all different resources that make up pieces of what used to be ingress where gateway models, the actual underlying data plane or load, balancing, that's performing the routing the http route models, the actual configuration of the routes and the gateway class is a template kind of like a storage class.

A

For defining what kind of gateways can be instantiated, so let's take a look at these, so in my cluster here I have uh a fuvi one and a fuvi ii uh deployment running. What I'm going to do is I'm going to show you some of the resources that I've deployed in my cluster so one. Let's take a look at the http routes. I have and it looks like I have one foo route that matches for food.com.

A

So let me just show you what I've deployed earlier and it looks like this and so uh at first blush. This might look a lot like ingress right, so it matches for the hostname food.com and it looks like it's forwarding it to actually two services here: fuvi one fuvi two and it's using a weight of 50.. So this is one of the aspects where it's more expressive. It has more capabilities built into the core. Api weights is one example, that's something that wasn't possible in ingress and there's some other things here.

A

One thing that we will notice. So let's go ahead and just describe this hp route and we'll realize that well, there's no vip anywhere and that might be kind of interesting, because an ingress has a vip and a port, that's actually exposing traffic on. So where might that bit be? Well, I'm going to go ahead and let's look at the infra name, space that I have and let's look at our gateway resource.

A

So we have one gateway here: describe gateway internal hp, and so this gateway resource is what actually represents the load balancer and it references a gateway class. It has listeners that describe exactly what port protocol are being listened to, and it also has an address field with a value. So this is actually the ip address of of our of our load balancer and where the traffic uh will go to to get into the load balancer, and so we have split up ingress into a couple different resources, and this actually has a lot of power.

A

So let me go back to here, so if we can see here because we're allowing a load balancer to be split up or at least to be shared by different teams through configuration, it allows teams to share underlying infrastructure more easily and also allows platform administrators to apply policy and centralize certain aspects of the operations of that load balancer in a way that suits their role more better uh better. So this is really the role oriented aspect of the api is that some of these separation responsibilities can be done because the api resources are separated.

A

So if we go go back to our cluster and I'm going to go into the bar namespace- and I could see that here is my bar route with a match for bar.com- that's probably sending it to the bar service. So let's just look really quick bar out. Yes, so it's it's doing so these routes are getting aggregated and then applied to the same, underlying load, balancer using standardized, merging and conflict logic between the routes, and so this allows the sharing of infrastructure to be much more easily done in a multi-tenant and shared cluster.

A

So now I'll show you how the gateway api can also be used for multi-cluster load, balancing. So in gke's implementation of the gateway api, we have been working on a multi-cluster controller that allows multi-cluster gateways to exist effectively. What this does is it programs, the google, the google cloud global load balancer to be able to load balance at multiple gke clusters around the globe that live across different regions and different data centers.

A

But this is all done through a centralized configuration model using gateway resources.

A

So this this supports both multi-cluster load, balancing for internal load, balancing external load, balancing and also all the features that come along with gateway such as traffic, splitting traffic capacity, traffic, mirroring and advanced routing between clusters, which enables a lot of very powerful use cases, and so in this example that I'm about to show you, I'm going to show three different common use cases. That might be very useful when you are onboarding a new cluster.

A

So let's say you have a gke2 cluster that is already serving production traffic and you want to onboard a new gke cluster. Maybe because you want to scale more or you just want to have disaster recovery.

A

In any case, you need to onboard this new cluster so at first to de-risk, the migration or you might want to send some synthetic traffic to gk3, and so for that you might just want to use some header-based matching to send some specific requests that are targeted to gke3, and then you would want to maybe mirror production traffic from the production cluster or from the gk2 cluster to the gk3 cluster.

A

So this would allow you to do capacity testing because you're mirroring real traffic to the gk3 cluster without actually responding to the clients with that traffic and then lastly, you're going to want to do blue-green traffic splitting. So you can canary a percentage of the actual production traffic to the new cluster until you've, validated that everything works fine and then you can put them both at full capacity.

A

So this looks a little complicated but I'll explain it we're using the service export api and if you remember the service export api, both aggregates and exports endpoints outside of the cluster, and it makes those available as service imports and all the other clusters.

A

So we have a service export foo that represents all four pots, and then we have a service export food gke2. That represents just the pods on the gk2 cluster and then we have a service export food gk3. That represents just the pods on that cluster. And so let's go ahead to cli and show you how this works.

A

We're now sitting on my kubernetes cluster, we can see on the right hand, side. I've got kubernetes cluster. I've got three running, um I'm gonna look across all of them and see all the pods. I've got fuvi one pods running on clusters, gke2 and gk3, I'm currently on gk1, where I have my gateway resource. So it's a multi-cluster gateway of the class gk layer, 7 rilb. So this is a layer, 7 load, balancer running in gcp.

A

I'm going to look at my service exports, which again is the resource. That's used to export services across all the clusters, so I could see that foo exists on both and so it's being aggregated while gk3 and gk2 are just specific to those clusters.

A

We can see the service imports exist everywhere, which means that the exports were successful. They've successfully exported those pods across all of the clusters. So let's look at the first route that I have deployed, it's simply matching on hostnamefu.com and sending it to the service import foo dash gke2.

A

So what this means is we're going to send traffic just to the fuji k2, which represents the pods just on that cluster. As expected, traffic is only being received from gk2, which proves that the routing rule does work. So let's go ahead and apply a second routing rule now, so that's configured and I'll show you what this looks like.

A

Okay, so here we have again matching of food.com, except we're using this, this header m canary and sending that traffic to just food gk3, while the remainder of the traffic goes to food. Gk2.

A

Note that we're referencing the service import resources here, we're not actually addressing this to services, we're using the service imports as those represent multi-cluster services that we can point to across cluster boundaries. So we add the canary header here and the m header, and it does look like we're getting routed only to cluster gk3.

A

So that proves that the header-based routing across clusters does in fact work. Let's go ahead and apply our final route here, which is going to do the weight-based traffic splitting between clusters. So that's deployed now I'll show you what it looks like.

A

And I'm referencing three service imports. Here too, I've got a weight of 70 percent against cluster gk2 and a weight of 30 against cluster gke3.

A

Let's see if it works and we're going to send traffic to food.com again and it does look like we're hitting gk3 and gk2 looks like a little bit more gk2 than gk3, which is expected so great success. It does look like multi-cluster load. Balancing using cloud load balancers is possible through a kubernetes native way. Thank you for watching, and I hope you learned something.