Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2020 - Virtual, 4 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Contour, A High Performance Multitenant Ingress Controller for Kubernetes - Michael Michael

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.

Contour, A High Performance Multitenant Ingress Controller for Kubernetes - MICHAEL MICHAEL, Steve Sloka, Nick Young, & James Peach, VMware

Contour, a CNCF incubating project, is a high performance ingress and load balancer solution for Kubernetes. Contour offers a richer feature set than some common alternatives while maintaining a lightweight profile. At its core, Contour is providing a control plane for the Envoy edge and service proxy. This session will show you how to leverage Contour and Envoy for Kubernetes workloads in a multi-tenant environment, demonstrate recent Contour features like authentication and preview our near term roadmap.

https://sched.co/ekGX

A

Hello, everybody and welcome to our presentation. Today we will be talking about contour, a high performance, multi-tenant ingress controller for kubernetes. uh First, let's go ahead and introduce the team that's working on contour. My name is michael michael. I'm, the product lead and a director of product management at vmware uh as part of our team, but not present. Here is steve. Chris, a staff engineer at vmware tong liu, the engineering manager also at vmware, and I'm going to pass the baton to nick.

A

Go ahead and I'm unique.

B

Hi everyone, I'm nick young, I'm a teddy, I'm the technical lead for contour, I'm a staff man engineer at vmware and I am in charge of the overall direction and architecture of.

C

Hey everyone, I'm steve sloca, I'm a senior member of technical staff here at vmware. uh I work a lot on the envoy integrations to contour.

D

Hi everyone I'm james peach, I'm a staff engineer at vmware. I've been working on contour for about a year and I contribute in most of the different areas.

A

Cool, thank you all and we have our slack channels ids on the bottom. So if you need to reach us we're all available on the kubernetes slack channel as well, so let's take a look at what contour is today. So contour is an open source, kubernetes ingress controller and it's providing a control plane for the envoy edge and service proxy. We really aimed with a mission to be the best ingress controller for kubernetes, and lately we've been accepted into the cmcf back last summer as an incubating project.

A

So we plan to kind of bring together a lot of the cloud native community within the cncf landscape and deliver an amazing english controller that meets your needs. We support dynamic configuration updates and multi-team ingress delegation out of the box, while maintaining a lightweight profile and I'm going to switch over to me young. Our technical lead to go through some of the highlights of contour yeah.

B

Hi everyone um so yeah contour was started in september 2017 uh at heptio. uh It was started by uh dave, cheney and steve sokol. The original members of the team um and at the time contour was aiming to be a high performance.

B

As uh michael said, contours are aiming to be a high performance and gross controller, with a focus on multi-tenancy simplicity and being able to source your ingress config from whatever objects you need, whether that's ingress um our http proxy crd or the new service apis. um A really key part of contour's philosophy and goals. All along have been to really keep the unix philosophy in mind to be a tool.

B

That does one thing well, uh and that thing is ingress kubernetes, and so uh we've worked really hard on contour I've been on on here since uh for about just over a year and a half. Now I think, and um the uh we released version 1.0 last year in november, 2019 uh and yeah.

C

B

We've uh kept going, we've yeah. As michael said, we've been donated to the cncf incubation level in july, which was amazing, um really great, uh really glad to have been a part of that uh and we've. Our we've recently released uh version 110, uh which uh has a bunch of new awesome features uh which we'll go into later, um but yeah we're. I'm really excited to be a part of this project.

B

um It's been a great journey for me uh being able to work on and then lead a open source project like this, and I'm really looking forward to where we go.

B

C

All right, so I'm going to walk through a quick architecture, overgram or overview of how contour is, is implemented and deployed. uh So you'll see here, we've got traffic from the internet which comes in from outside your cluster. It targets typically a load balancer. This little balancer's job is to send traffic to a fleet of envoys running in your cluster, so contour uses envoy as its data path component. So all traffic routes through envoy envoy's another cncf project and again it's the it's, the reverse proxy that contour implements so contour.

C

Actually in this architecture, is the configuration server for envoy, so it implements envoy's xds server, so contour's job is to watch the cluster for things like services, endpoints, ingress objects and secrets. When it sees any of those things. Change contour then builds a new configuration in memory and streams. Those changes down to envoy envoy then can take those changes without reloading and then serve traffic properly within your cluster. So again, the traffic comes in from the internet, hits load, bouncer routes through envoy and then to your backend applications.

A

Thank you steve, and we're going to see a demo later on of some of the next generation work on on contour here. So let's switch over and talk about some of the latest developments in contour. So james you got the baton.

D

Thanks, michael so, as nick pointed out, we've done maybe 10 releases in in the last year, so we're actually adding features quite frequently. um Some of the things we're working on recently, the big one is external authorization support which we'll talk about in more detail soon, we've also added cause support which is really useful for anyone doing web applications or single page apps in javascript.

D

um We're working on envoy, xds, v3 support, so envoy has done a major uh new version of its api and we're taking full advantage of that.

D

Also one of the things we've been doing you know, as the over number of releases, is kind of improve the integration of contour with other projects in the ecosystem, so load balancer ip status is one of the features in that area.

D

We now support a client certificate, client, tls certificates for the envoy proxy and we're working on arm support. So you can deploy contour in your arm images in on your arm, platforms in the cloud and tls client certificate, validation, there's another there's a project in the contour ecosystem called net contour, which allows uh k native serving to use contour for its ingress support and, finally, we're working on a contour operator which will make it easy to to deploy contour and envoy and also to have multiple contour deployments.

D

Can you go to the next slide, michael.

D

So external authorization is one of the earliest user requested features for contour and what people want here is a way for the platform and the contour deployment to provide a single authorization mechanism that authorizes you and authenticates users and means that individual applications don't have to worry about implementing it. So you can get a consistent authorization experience across all your applications in the cluster.

D

So you can you can a lot of cloud log. Excuse me, so some people will use oidc. Some people will use ldap, but basically, as far as contour is concerned, it doesn't matter what you do where you can build your own server and do your own custom authorization mechanism or you can pull one from the broader onboard ecosystem. For example, istio's auth service can be used with contour and everything will work.

D

D

The general architecture for authentication is shown here in this diagram, so a client will do a get request to envoy and there's a extension service crd, which the operator has already deployed the extension service crd represents a binding between envoy and a external authorization service.

D

Contour will configure envoy to send requests to the external authorization service on every request that comes from the client. The external authorization service will um either accept or reject the request, and if it rejects the request, it can redirect the client in order so that the client can obtain any kind of authorization information that it needs. Then, when the client returns, the extension will authorize that request and will forward it to the upstream service.

A

Thank you james. So, let's take a look at all of this in action and a lot of exciting work has gone into enabling external authorization into contour and it's actually one of the highest requested features uh for contours. So uh next I'm gonna stop. My sharing here and uh steve slogan is gonna, share his screen and walk you through what it looks like in real life, steve.

C

Cool: hey thanks, michael thanks james for that intro, uh so here we're going to walk through actually implementing what james just described there on the screen. So what I have here is I've got a cluster running and I have contour deployed to it.

C

So what I can do is I can go ahead and get um I can show you all the other http proxies I have in my cluster, so here I've got three of them right, and this is a typical site that you might see you know in your cluster, so my domain name here is stevesloca.dev and I've got a tls secret on here and that comes from let's encrypt via cert manager.

C

So these are all um you know: let's encrypt certificates that were dynamically configured, so there's a couple other proxies here for the marketing team and the blog sites. But we won't worry about that for this demo, at least so just to prove that this works we can come into here and let's go ahead and check out the site and what you'll see here is it's got a simple echo server here. So this tells you that hey! This is the default site.

C

Here's the request and here's the headers so we'll use this site here, just to kind of validate how this author authorization stuff is going to get implemented. So the first bit we're going to do again. This is the the same diagram that james just talked about. Is we're going to go ahead and deploy some prerequisite, prerequisite bits to deploy this external auth service again, it's something that we deploy in the cluster.

C

So first, what we're going to do is we're going to go ahead and deploy a name space for all of these. We're going to put all this stuff into this namespace called project contour auth in the namespace we're going to create a service account, and this is going to be used for our authorization server to be able to look for secrets in the cluster.

C

It's going to use these secrets to be able to pull out passwords in this demo, we're going to use basic passwords or basic password auth, which is very simple, but again we can extend it to other types as james mentioned. So once we have this cluster role, we'll create a binding and then we'll also create a quick little cluster issuer here. This is going to. Let us create some self-signed certificates for the auth service inside the cluster, so that communication between envoy and the service is all secured cool.

C

Let's go ahead and apply this first bit so we'll send this one over all right, so we haven't created all those. So now we should have a namespace called project, contour auth down here you can see it's seven seconds old, all right, so next we're gonna go ahead and deploy our actual auth server. And that's again, that's this external os service a bit right here.

C

So this this is here: here's our service, we're going to use for it. It's called ht password and then here's the deployment so down here a little further you'll see this is the image this is. um This is a actually project that the contour team has out in its contour repo. uh So there's a couple different auth servers that we provide for you there's a simple one: that's used for unit testing and then this one's used for basic auth. uh So this is again this we're going to demo today with hd password.

C

So the image here this is v2 uh we're going to run the ht password auth server over port 9443 and we'll reference some secrets or certificates that come from secrets and you'll see. Those secrets are volumed in here through the passwords.

C

The the source of the secret here is going to come from the certificate. So in the previous step we created that self-signed cluster issuer for sort manager. Here we're actually going to request the password from start manager or request a certificate. Sorry, so we can secure that communication. So let's go ahead and deploy this bit.

C

Okay, so created the service, the deployment and the certificate. So if we go ahead and get pods in the namespace project, contour off what you'll see here is I have this auth server now running.

C

uh Similarly, I should have a secret in there and it's called hd password again that matches the certificate that we requested and you can see that one's 14 seconds old, okay, so back to our diagram here, we've got this auth server bit deployed uh next, we're gonna go ahead and deploy um some secrets for this. So what we need is some sort of user database.

C

um So in here uh this secret has uh it's and it's kind of it's basically for encoded, but with hd password we actually created a user called user, one with password called password one and we created user two and user three- and that's all done up front here in this secret. So whenever the auth server spins up, it's gonna look for the secret and then use it to become the source source user base for our users to log. In so we'll go ahead and apply this one.

C

Okay, so now we have that next we're going to create this extension service and again back to our diagram. Here we have this bit all deployed now, so now we're going to create this extension service again, as james mentioned, the goal of this is to help integrate this auth service into our contour infrastructure. So now we can reference this auth service from our http proxy.

C

So if you look at this again, this is called extension service and we're going to reference the service we created in step two here, this deployment so hd password, is the service of our auth server, again deployed here in this orange box. Let's go ahead and create this.

C

Okay, so now we have our extension servers created. Finally, that's all the bits. Now we just have to tell our http proxy that we want to turn off on right and we'll do that here. So this is that root um proxy that we saw originally and we're going to do. Is we're going to add these little bits here, so this authorization bit now within the virtual host lets us reference an extension service.

C

So here you can see referencing this ht password again, that was created in the step four here and it's in the namespace project, contour auth. So now, once we apply, this contour will then tell envoy that on new requests coming in, we want to have this authorized so envoy. Will then forward this request out to our auth server. The officer will basically do a thumbs up or thumbs down depending on what it receives, and then the request will either be denied or it'll be allowed through into your into your application.

C

Let's go ahead and apply this one.

C

Okay, so we configured our route, real, quick. We can check for errors, so we'll get our proxies again. You can see. We have no errors here based on the status information. So what we can do now is we'll go ahead and curl for this. So we'll do a quick curl for um secure and you'll, see that I get a 401 redirect here.

C

So this 401 response tells me that I'm not authenticated because I haven't passed any users in so again based on our authorization flow, I'm not allowed to come in, but if we grab the second one here and we actually pass a user so user1 with password one now they see the request comes through right. The only downside to what we've done here is that the secure path uh has security, which is what we want, but um the other one doesn't either.

C

So it looks like I already stepped ahead of myself and uh configured that for us. So what we've done is um in your routes. You can apply um some auth conditions and from here you can say I can disable my auth policy. So what you'll see is on the um on the slash secure. We have off, but if I hit slash, dev or slash, I still get the 401.

C

so we'll do is we'll go ahead and apply this auth policy to our our route, which basically will allow our our root path, which is slash to not require authorization. So we'll save that.

C

And we'll apply the root again cool. So now, when I curl for um the root, I don't have, I'm not required to have authorization, but if I add secure you can see now that is secured, so I'm required to log in before. I do anything there so hopefully that's a good, a good, quick overview of um authorization and contour.

C

um There is a nice guide out here on the contour website, if you're looking for more information which walks you through what we just talked about, also with some some flow diagrams and everything to help explain this a little better.

C

That's all I have back to you, michael.

A

Absolutely thank you steve and thank you team for for working on this and obviously, as you are users, you want to implement your own authorization providers and extensions into contour come into the contour channel. Talk show up in our community meetings and office hours and tell us what it is that you're building might be able to redirect you to an existing solution or or help you out so we're here to make sure that you're successful with your english needs.

A

Next, I'm going to switch to to nick young who's, going to talk to you about the road map and where we're going.

B

Everyone again um so yeah we're obviously as a public open source project. We have a public road map, first starters with our public roadmap. I probably should say um this is a this. Is our current directions based on our current priorities? This is an open roadmap, so it's really open for you to come and say hey. I really need this thing straight away and I want to build it or I really need this thing very urgently, and I need you to build it.

B

You know if you need either of those things please come and talk to us. You know this roadmap is not set in stone, it's a living document and we're con and we're and we're up to change it if, uh with with a reason, however, that said um this, the current things that are on this slide uh are some of the things that we're scheduled to do by the end of this, hopefully by the end of this calendar year.

B

um So the first one is rendering um that's being able to plug an external service for rate, limiting in a similar way to what we did with the external auth, um so that you can rate limit uh rate limit particular routes or services.

B

um So yeah this one in the past we've it's been very difficult to figure out a design for how we were going to do this. But luckily, in order to do external off, we needed to build the same functional. The same features that we needed, which was that extension service cid.

B

um Also um we're looking for some we're hoping to get some more deployment support um done by the end of the year. So right now, we've got projects working running to create an operator and to have an official uh helm chart for comfort. There is a currently an artificial one and we're working to build, bring that one uh and make it official um and the purposes of both of those are to just make it easier to get contour installed, but also to make it easier to install contour in a variety of scenarios.

B

Currently, our install method is that we provide you with an example deployment that will get you up and running, um but you then we can't do it, because it's supplied as a series of the animals there's no way for us to give you options, and so both of those things are a way for us to give you options um the.

A

Third, the third one here.

B

Is to be more uh complicated to explain um we've historically, when the project started, we were a very small team, um knew two. Then three people when I joined uh and we had a lot of features that we needed to build, uh and so we needed to stay focused on the ones that were the most important and one of the things that you we didn't put much focus on at the time was configurability.

B

um I think we all missed uh to begin with the um the real importance of for a centralized proxy team of being able to.

B

You know, tweak a whole bunch of options about your requests, timeouts and a bunch of other details, and so uh since, since I've become the tech lead, one of the focuses for me has been really opening up uh that and finding sustainable ways to to allow people to configure all those things about android that you need to configure in a centralized property that we haven't allowed you to in the past, um and so we're really hoping to close out this and to put to sort of make adding new envoy config with just vau and something that we do do all the time.

B

And it's done in a relatively so that's what sort of that this roadmap item needs um the last one, and probably one of the most exciting ones for the future of contour is um service. Api support, so service. The service.

C

B

Are a project of kubernetes sig network that uh is about building a new set of apis to describe services inside the cluster and how they get traffic? How you get traffic to them from outside the cluster?

B

That is, uh it's a it's kind of a replacement plus more for both ingress and the service of type load, balancer that you have in kubernetes right now, um it's a huge project with huge uh scope that we need to cover, uh and so you, if you're more interested in this I'd, certainly encourage you to get involved in that project. um There's you there's a lot of work to do, um but yeah one full contour. The thing that we want to look at doing is making sure that we, once the service apis are actually released.

B

We are able to take those objects for as a source for config, in the same way that we can currently take ingress objects or our own http, proxy crv and the the exciting part there is that this is. This is going to be eventually the new way that that we configured this.

A

B

It's going to stay around for the foreseeable future, but this is going to be the the way that you'll get all the nifty bells and whistles. That is very hard to do in ingress v1. So.

D

Yeah, that's that's most.

B

Of the our roadmap for the end of the year, um we've got a few um there's, a few other sort of maintenance, things that are on there by the end of the year. The big one is, as michael said earlier, the xds v3 change um that xdsv2 full support by from envoy at the end of the year. So that's really important.

B

Can we finish that one um yeah, those are probably the biggest things for until the end of this calendar year um further out than that um that we do have a few things on the list, but yeah the roadmap is pretty open. uh Please come and uh talk to us about other features that you want and then I'll uh hand back to michael right now.

A

Thank you. Thank you nick. So uh we've taken a lot of time so far talking about what's going on in contour and from a technical standpoint and some of our features, but you know we want you to come and help us shape. What contour looks like tomorrow, we're a vibrant community. uh We have multiple ways that you can engage with us. uh You know I'm gonna go through some of them right now, so we're on the kubernetes slack under the hashtag contour channel.

A

We have a mailing list where you can get updates about the project new releases um and also ask questions. You can interact with us on twitter under project contour. We have our github repos, where you can come and see all the work that's happening in real time in contour, and we also have a playlist on youtube of all the community meetings that you have.

A

So if you want to know about something that happened in the past or missed a meeting, go ahead and view that overall, the contour community is super vibrant, our ecosystem is, is super, engaging we're welcoming to new users. But let's go through some of the project statistics. We have two and a half thousand github stars and that number is growing: 430 contributors, 400 forks, five maintainers 55 releases. Since we started 130 contributing companies, 731 slack members and more blogs. Cubicon talks, twitter followers.

A

We want you to be part of this community come and help us deliver contour. We have about 10 minutes left for q, a so feel free to ask anything. That's near and dear to your heart. Thank you all from the country community.

A

Thanks everybody.