 Hi everyone, welcome to the Contour Ingress Controller Session. So let's do a round of intros first. We're trying to get pretty much all the maintainers for the project here. So I'm Alex Xu. I'm a product manager at VMware in the Modern Applications Business Unit. I'm the product manager for Contour. Over you, Nick. Hi everyone. My name is Nick Young. I'm the tech lead on Contour. I'm a staff engineer at VMware. Over to you, Steve Sloka. Thanks, Nick. Yeah, hey, I'm Steve. I work for VMware. I've been working on Contour since almost this inception. So let's see y'all. Pass it off to Daniel. Hi, Daniel Hansen, principal software engineer with Red Hat. And I'm excited to talk more about what we're doing with Contour. Steve Christ. Hey everyone, I'm Steve Christ. I'm an engineer at VMware and I'm a maintainer on Project Contour. I'll hand it over to Sanjay. Hi everyone, I'm Sanjay Bhatia, engineer at VMware as well and working on the Contour team. Thanks, everyone. Yeah, so let me just kick it off here with what is Contour and what we're all about. So Contour is the ingress controller for your Kubernetes cluster, which means it's a piece of software that you have to install into your Kubernetes environment in order to leverage Ingress. Ingress is a Kubernetes concept. It's one of the preferred ways to bring external traffic into your Kubernetes environment. You might have heard of service type node port or load balancer in Ingress. It's just one of the options. So we are built around another really popular open source project called Envoy. So Contour is the control plane for Envoy, which is acting as a data plane and the Envoy instance, which is deployed by and configured and managed by Contour is essentially functioning as a reverse proxy and a layer seven load balancer. And the communication back and forth between Contour and Envoy are all protected by mutual TLS. So there are a lot of Ingress controllers on the market today. And the purpose of this session is to just highlight why you might want to use Contour, given some of the things that we're working on, given our roadmap or extremely prolific roadmap and some of the fall leadership around Ingress that we are involved in. So there's something here that you don't quite understand or you have needs around Ingress. If you're not being captured in Contour today, please reach out to us in GitHub and Slack through email. We're always wanting to hear more. So if I may, I just want to highlight some of the most compelling features in Contour today. So we support dynamic configuration updates. This is driven largely by how Contour functions as a control plane for Envoy. We have very strong focus on multi-team Ingress delegation or multi-tenant Ingress. And what this means is that basically the behavior of how traffic lands into different applications in your cluster or different sub-domains, all of the domain can all be customized by different personas. So your Kubernetes cluster admin can set some basic rules on how traffic arrives at your cluster. And then each team can further customize the behavior of that request once it lands in your part of the application. Contour is very lightweight. We leverage pretty much just pure Kubernetes objects. So we create a bunch of cluster rules and spin a bunch of CRDs. There's no additional software or licensing here. There's no proprietary or paid version of Contour with more functionalities. Of course, we can do TLS termination and pass through. There's HTTP to HTTPS redirection. There's also session affinity. There's all kinds of low balancing options available to you. And you can also modify request headers as well. Next slide, please. So you've probably seen the slide before in previous Kubicons, but we are already on version 1.14. We release monthly. So you can always expect a pretty stable build, very fluid release management and lots of contributors. And in the last couple of releases, we've really been focusing on a couple of things. External auth. So your incoming requests can be secured against an auth server. We've added local as well as global rate limiting. We've also added support for ingress class resource, which was released as part of the Kubernetes 1.18. And we are adding support for gateway API, which is a new Kubernetes networking sake project that is attempting to rearchitect not just ingress, but a very large broad set of requirements around dynamically sourcing networking infrastructure. So you can think of ingress classes, ingress v1 and ingress and gateway APIs, ingress v2 and Contour has coverage for both. So to stick around to learn about how we're actually supporting gateway API. And with that, I'll hand it off to Steve Stoker now. Thanks, Alex. Alex touched on a little bit beginning some architecture overview components of how contours put together. This slide here will help you dig in a little further into what that looks like with some congrats. So again, Contour is typically deployed as an edge proxy. So the goal is to route traffic from outside of your cluster into your cluster. Here you can see we have traffic from the internet hitting some sort of load balancer. Net load balancer then targets a set of envoys. So depending on your environment, you can deploy one or more envoys in your fleet, again, to route traffic. So Envoy is our data path component. Its job is to actually route traffic from point A to point B within your cluster. Contour's job is to be the control plane server. So Contour implements an XDS server. An XDS is an Envoy type protocol. What lets us configure Envoy dynamically. And Contour and Envoy talk over a GRPC connection. That's a rich data connection. So we can pass updates quickly and easily. So Contour's job is to watch the cluster for resources. So to look for things like services for endpoints, secrets, ingress objects, all kinds of different things within your cluster. When any of those things change, Contour will rebuild a configuration. It will pass those changes down to Envoy. When the next request comes in, Envoy will be able to process that request and route traffic into your cluster however you see fit. Again, so typically this is an edge proxy. This can also be done for internal routing as well. So here you wouldn't have this external traffic. You would just have internal traffic routing as well. But again, the generic example is how this works with Envoy and Contour working together to help route your traffic. So I'll pass it off to Sanjay next to talk about the next thing. So as Alex mentioned, I alluded to a little while ago, we've got some new features that we've been working on in Contour. Those include rate limiting support, so ability to set per Envoy request rate limit as well as a version of a rate limit service for you to be able to more granularly control your rate limiting requests to your applications across a full deployment. We're starting work on getting initial alpha support on Gateway APIs, a new API that the SIG network group is working on in Kubernetes. We're trying to round out the Ingress V1 support, so supporting all of the various features in terms of filtering ingresses using ingress classes, various types of path matching, and other features of Ingress V1. And also we're working on a project that we have called a Contour operator, which is an operator for Contour that is currently in the alpha state. Yeah, so let's talk more about Gateway API. So Gateway API is an open source project that was established around 2019, actually from KubeCon San Diego 2019, and is managed by SIG network. It defines a collection of resources to model service networking in Kubernetes. So what are some of those resources to cover them real quickly? You've got a Gateway class, which is a cluster-scoped resource that defines infrastructure. There's a Gateway resource that defines an instance of the infrastructure. The infrastructure being a load balancer or a proxy in the case of Contour, and of course that proxy being convoy proxy. And going back very quickly with the Gateway class really represents an abstraction of the details of the infrastructure. And so as you see here in this diagram, the different resources map to different roles. And the role orientation of Gateway API is one of the benefits of the API. If we look at existing resources prior to Gateway API, like the Ingress resource, there is no concept of having different roles to express how an application and the infrastructure is modeled for service networking. And so one of the last pieces of the resources represented by Gateway API are routes. The most common is the HTTP route, as you see in this diagram. And the HTTP route represents how an application developer would model advanced routing. For example, sending a certain percentage of traffic to one service over the other. And that's just a quick summary of the different resources that make up Gateway API. We first introduced Gateway API support in 113. It was introduced as Alpha. It's still an Alpha, so still very new. Still have a long road ahead to go with this, but this at least gives users an opportunity to kind of keep the tires with Gateway API, provide feedback not only to us, but also the Gateway API community. And we're looking forward to get that feedback and excited to have Gateway API as part of Contour. All right, thanks, Daniel. And now I'm gonna talk a little bit about Contour support for Rate Limiting, which is a series of features really that we've added progressively over the last few Contour releases. And so Rate Limiting fundamentally is about defining policies for how much traffic is allowed to reach your back-end services in a given period of time. And there are a number of different reasons why you might want to have control over this and have enforcement of this. So a few examples are for protection against denial of service attacks from malicious actors where other folks are trying to overwhelm your back-end services with extraneous requests. It might be useful for enforcing usage quotas for different categories of users for your services. It can also be useful for protecting against bugs in client applications that create unintended traffic. So lots of different reasons why it's useful, and it's definitely a really valuable tool to have in your toolbox. And so we're happy to have support for it in Contour now. And so Envoy and by extension, Contour support kind of two main modes of Rate Limiting. So they're called Global and Local Rate Limiting. And the terminology really comes from the fact that, you know, usually when you deploy Envoy, you're not just going to have a single instance of Envoy. You typically are going to have a kind of a fleet of Envoys, multiple instances that are running. And so if you're running a service mesh, you might have an Envoy sidecar per workload. Or if you're in an Ingress scenario, like you are with Contour, you're probably going to have a daemon set or a deployment that has multiple instances of Envoy. And so then the question with Rate Limiting is really, when you're making a Rate Limiting decision, is it taking into account all of the traffic that's coming into all of those Envoy instances, which would be kind of a global Rate Limiting decision, or is the decision made locally by an individual Envoy, just based on the traffic that that Envoy has seen coming in without any coordination with other Envoys. So that in a nutshell is kind of the difference between the two approaches. Like I said, Envoy supports both and Contour supports both. The key operational difference is that with global Rate Limiting, you, the user are required to deploy a separate external Rate Limit service that's responsible for making those Rate Limit decisions. And then each Envoy within your Envoy fleet is going to be communicating with that external service, providing some information about requests coming in and getting Rate Limit decisions back. And then global also provides you some additional flexibility in terms of how you Rate Limit. So you're able to Rate Limit by things like the client IP and header values on requests and various other things, whereas local Rate Limiting is pretty simple and basically just allows you to limit the total number of requests that hit a backend service through any particular Envoy instance. And so just to dig into the global Rate Limiting architecture a little bit more since there are some more moving pieces there. What you see here, first of all in the center in the purple box is Envoy. And then on the bottom we have the Rate Limit service. So as I mentioned on the previous slide, this is something that you as a user would have to deploy yourself. Envoy publishes a GRPC interface that the Rate Limit service is required to adhere to. But as long as your implementation meets that interface, you can use whatever implementation you want. There is an open source Rate Limit implementation that's published as part of the Envoy GitHub organization. So that's definitely an option for you, but you're not tied into it by any means. And so then on the top in blue we have Contour. And Contour is kind of made aware of the existence of the Rate Limit service through an extension service, custom resource. And this is a part of the Contour API that we introduced as part of the external auth work last year. And so this tells Contour that the Rate Limit service exists and should be configured with Envoy. And then each of your HTTP proxies within Contour can optionally define a global Rate Limit policy, which essentially says that information about requests for that proxy should be sent to the Rate Limit service and the Rate Limit service should then return a Rate Limiting decision back to the user. And so Envoy then, as it's processing requests coming in, will reach out to that Rate Limit service, provide the information about the request, and then based on the decision that the Rate Limit service makes, either allow the request to proceed to the backend service or return an error code to the user. So with that I'd like to jump into a quick demo of global Rate Limiting. So let me switch over to my terminal here. So first of all, I have a cluster here that's running a three-node cluster. Give it a second. So I have a three-node cluster here and let's take a quick look at what's in the project contour namespace. I get pods. And so you'll see I have my two contour pods as part of my replica set. And then I have an Envoy daemon set, so one Envoy per node. And then additionally I have this Rate Limit pod here and this is part of the Rate Limit service that I have deployed into my cluster. And then let's just take a look at the contour config map. And this is where you as a contour user would tell contour about the existence of the Rate Limit service and so you can see I just have a simple YAML block here that defines the Rate Limit service. It identifies the extension service that kind of maps to that Rate Limit service and provides some additional parameters for that Rate Limit service. And then the next thing I want to take a look at is the config file for the Rate Limit service itself. And this is where the actual Rate Limits are defined. And so I'm not going to get into the details of the exact configuration format here. This is specific to the Envoy Rate Limit service, but if you have a different implementation, your config format would look a little bit different. But the important thing I want to point out here is that we have two different Rate Limits defined. So the first one here, you can see that there's a five request per hour Rate Limit and that's defined for each remote address, which is effectively the client IP. So this is saying that each client IP can have five requests per hour. And then the second one is similar, so it's a two request per hour limit. But it's saying that if this, essentially if this header value here is present, so if X Contour Rate Limit is defined on the request with the value of true, then only two requests per hour should be allowed. So basically if the header is present, you should get two requests per hour. And then in total, each client should get five requests per hour. And so the last thing I want to show just before I start issuing some requests really quickly here is the actual HTTP proxy I have defined. And I just want to focus kind of on the Rate Limit policy. So this is a new part of the HTTP proxy API. And so you can see here that I have a global Rate Limit policy defined. And again, I'm not going to walk through this in excruciating detail, but this is basically telling Contour and Envoy that for any requests coming into this particular virtual host, we should send the client IP to the Rate Limit service and then if this header exists on the incoming request, we should send that to the Rate Limit service as well. So what I'll do now is demonstrate those Rate Limits being enforced. So the first thing I want to do is use that two requests per hour Rate Limit. And so if you'll remember, basically if this header is present on the request, we should only be allowed two requests per hour. So I'm going to issue my first request here and we can see we got a 200 response. Everything worked okay. We got a response from my Echo server. And so I'll do one more request and we see we get another 200. And so now I've issued my two requests. So this next one should be Rate Limited. And so we get a 429, which is a too many requests response. And you can see a number of headers here that describe some information about the Rate Limiting that's taking place and tells you that it's been Rate Limited. But we know that if we don't have the header, we should be allowed five total requests per hour. Now, I've already issued three requests and those have counted against this additional five requests per hour quota. So I should be able to issue a couple more requests here where I get a 200. There's another 200. And now I believe on this one, I should get Rate Limited because I've now issued a total of six requests from this client IP. So hopefully that gives you a feel for what Global Rate Limiting looks like in Contour and Envoy. There are many more knobs and many more ways to configure this that I don't have time to get into, but definitely check out the docs and play around some more if you're interested. And with that, I'll flip back to the slides and hand it off to Nick. Hi, everyone. So I'm talking about the roadmap today. So we've got, you can see here that there's a few, this is the bigger items on our roadmap. Our whole roadmap is public and it's published in our Community repo. There's a link in the slides if you can see it. But if not, it's github.com slash projectcontour slash community. And then there's a roadmap.md file. So the first thing we've got here is we want to bring, we want to get our operator up to scratch. We want to get it all the way to GA, obviously. We make it beta first. It's currently alpha. In my mind, you know, I think we've talked a little bit about this, a large part of the things that we need to graduate to GA, the biggest feature that we need to do that is support for upgrades. The operator is intended to help you operate Contour. That means it helps you install Contour. It helps you make sure that it's, that it upgrades to the latest version and it should do that upgrade in a safe way for you so that you don't have to encode the knowledge of how to do a safe Contour upgrade into your deployment tooling. The operator can do it for you. As part of that, we also want to, and a little bit associated with that, we want to expand the Gateway API support. We want to make sure that we bring that to as production ready as we can make it. Obviously, with the Gateway API still being an alpha API, there's a limit to how far we can take that until it moves up. It's the production readiness chain itself. But I think that we should be able to get good support for the basic workflow and the two route types that we support, being a HTTP route and TLS route. We should be able to get those in a reasonably timely way, in a few months, hopefully. That's what I'm hoping for, anyway. The next one I wanted to mention here is, we've definitely had some issues with this in the past. Contour currently has two options for the code that actually handles XDS. XDS is the control plane protocol that Envoy uses to talk to its control plane. If you are deploying an Envoy in your cluster, you are running a control plane. It may be a static control plane from a file, but if you're running any of the other products that use Envoy, they provide an Envoy control plane. Currently, Envoy Contour supplies two options for that. There's our own organically homegrown, slightly elderly implementation, and there is one based on the upstream go control plane implementation. The homegrown one, it is aging, as I said. There's been a few advances in the XDS code that we haven't had a chance to build out yet, supporting things like incremental XDS and the ADS Anything Discovery Service, basically, and a few other things there. The reason to do those is that it should help when you're running a large contour installation. We have heard from people who are running thousands of HTTP proxies that Envoy can use an awful lot of memory in that case. We're hoping that by modernizing the XDS code, we should be able to help a lot with that. The last thing that's on the roadmap that we always intend to keep pushing along with is the further feature work. Some of the ones that we've got in-train, we've got some work for ALS, which is Envoy's automatic logging service. You can configure a remote logging service to have Envoy send all of its logs to. There's a few things like tracing and other stuff that's well-requested features that have been around for a while. The requests have been around for a while, and we are now working our way down to getting to them. With that, I think I've hit as much as I can in the time that I have. I'd love to take more questions about this at some other time. Over to you, Alex, for to sum up. Yeah, okay. I just wanted to also add that we're also working on Windows support in our roadmap, as well as making sure that Contra can deploy onto IPv6 clusters. These are the two big ones. Thank you, Alex, for doing your PM job and making sure that I get those things. It also fits compliance, which is a lot of customers have requirements. Open source users, community members as well as customers have requirements around delivering FIPS 140-2 compliance images. They can show that Contra works using a specific set of TLSI for suites. So all of these are coming. Yeah, the last thing is the community. The community is doing really well, as everyone can see. So we're at 2.7k GitHub stars. We have really lots of contributors, 450 forks. We have maintainers from VMware, from Red Hat. We're taking a very active position in driving the design for the Gateway API project upstream. So a few ways to reach out to us. You can reach out to us on Slack in the Kubernetes channel. You can also follow our Twitter account. Find us on GitHub at Project Contra and watch some of our community meetings as well as office hours on YouTube. So yeah, if you guys have any questions about Contra or the project, if you're, like I said earlier, if there are needs around Ingress that are not being met today in Contra, definitely reach out to us so we can discuss them. Anything else from anyone else? I guess I'd just like to say thanks to everybody who's contributed in the last few months since we last gave an update. It's been amazing to see such great contributions from the community. It's been really great to bring Daniel on board as a maintainer that's not from VMware and to just start getting a lot more external contributions. So as a take later Contra, I tip my hat to the community. Not actually wearing one, but you know what I mean. And yeah, just thanks to the community for everything we're doing, and we're really excited to see where we go from here. So I think we're going to move to some questions and hopefully we'll talk to you soon. Thanks for attending, everyone.