Webinar: Contour - High Performance Ingress Controller for Kubernetes

they're due I'd like to get started thank you for joining us today welcome to today's CN CF webinar contour high performance ingress controller for kubernetes I'm Chris short a principal technical marketing manager at Red Hat and a cloud native ambassador I'll be moderating today's webinar few hi you housekeeping items before you get started during the webinar you're not able to talk as an attendee I'm sorry however there is a Q&A box available to you that you can ask questions of Steve or myself and if you have you know other questions that you feel like the chat might be able to help with feel free to drop you know comments in the chat also this is an official CN CF webinar and it's subject to the CN CF code of conduct please do not add anything to the chat or questions that would be in violation of that code of conduct basically be respectful of all your fellow participants and presenters so with that we would like to welcome our presenter today Steve sloka senior member of technical staff at VMware take it away Steve okay hey thanks Chris so good morning good evening good afternoon everyone yeah again I'm Steve sloka and today we're going to talk about contour and contour is an ingress controller for kubernetes so quick look at the agenda for today we're gonna review kind of what ingress is so we can help level set your background just to be on the same playing field we're gonna go and look at contour you know what is it how does it work what are the components that make it up then we'll dig into this CRD that we wrote called HTTP proxy and we'll look at why we built that and some of the reasons around you might want to use that versus you looking at using ingress today and then we'll do a bunch of demos so I've got a whole whole slew of demos we can dig into and I think majority of today's talk will be live coding on a server so it should be fun so let's dig into and figure out what ingress is right so ingress itself when you think of that generically it means incoming right so I can talk about ingress traffic you know coming into my network and this is the same for kubernetes so ingress and kubernetes LAN is the ability to route traffic from outside the cluster or from the inner it into your cluster and route that to a service an ingress uses this l7 protocol of the application stack so it's able to route requests based on the host header in the path combination so I like to look at ingress and then think about will why hide it why would I use something else right so let's look at alternatives real quick and then we'll see why ingress may be a good fit for what we're trying to do so I could use the thing called node ports and I put node points and load balancers together because they kind of fit hand-in-hand but a node port type service and kubernetes will expose a random port on your cluster and that 30,000 range by default whenever I expose that service on that port if I hit any node in the cluster then traffic will route to my application so this works the problem here is that I've got a whole bunch of random ports now depending on how many applications I have and I've got to manage the life cycle of all those nodes right so if I know goes unhealthy and my cluster I've got a connected out of service load balancer kind of works hand in hand if you're an environment that has a you know a cloud provider or something like that you can create a service type of load balancer and essentially behind the scenes you creates you a node port service but it also provisions a load balancer outside of the cluster and this load balancer will then send traffic to your cluster and this will solve the problem easily the problem is is that how many applications are going to live in your cluster right there's a quantity of those applications there's also a cost whether you're you know an on-premise environment or the cloud environment some sort of cost associated with this as well as complexity so let alone having all of these ports open up in your cluster so your security team may not be happy with all these different entry points nothing you could use our thing called host ports so host ports basically map a pod in your cluster to a host port on the node and this again would be another solution to the problem is you can only have one per cluster right only one port can map port 80 or one can map port 80 so basically unless you're gonna deploy one application per cluster there's a lot of overhead in that so ingress gets around all of this by only having a single entry point but being able to handle multiple application and multiple paths into your cluster so this diagram here is an overview of how contour looks and you can also apply this to basically any ingress control or instance so again we have our traffic coming in from outside the cluster and we're gonna hit some sort of load balancer and that load balancers job is to send traffic out across the cluster and again I'll need one of these for our ingress once the traffic gets to in our case envoy for contour envoy is going to take that request inspect it and then route it to the right place within the cluster and you noticed here that envoy is the data path component in contour so it's the one handling all of the traffic all of the the network routing for us contour in this scenario is just the configuration server for envoy so contours job is to watch the cluster it's gonna look for services endpoints ingress objects these HTTP proxy objects as well as secrets and when any of those things might change in the cluster contour will rebuild this configuration and stream that change down to envoy and again envoy is gonna handle all of the traffic and again they said this is an l7 proxy at layer seven so that means that in this example XYZ comm is my host and slash blog is my path so I'm always able to inspect the fat that layer of the stack and be able to make decisions on routing oh and I meant for this could work for any ingress controller if you replace this box here you can probably swap out any kind of different ingress controller for for contour and it should work in this similar vein depending on you know the different components but again the concept is the same in terms of how ingress controllers are implemented there's another look at the components of contour again we said that contour is the configuration server and it uses envoy as the data plane again we're deploying this to kubernetes so kubernetes is our our underlying infrastructure we're gonna deploy this too and we also expose Prometheus metrics an envoy as well as contour and you can use Gravano or any other tool that can consume Prometheus depending on your environment so feel free to do that but again this is just giving you the overview again of all the components that make up contour let's dig into some more highlights of contour again contour is an ingress Controller we're using envoy as the data plane component contour it has can dynamically update its configurations without dropping connections so whenever those services or endpoints change or your users are pushing configuration changes all that happens in real-time or near real-time and those changes are pushed down to envoy and connections aren't dropped right there's no reload there's no issue of receiving that update contour can safely support ingress in multi teen clusters we do this through our CRT called HTTP proxy and we'll dig into what that looks like and feels like here in a little bit that multi-team pattern is enabled through this thing called delegation so we can delegate a path and a header combination down to namespaces and by carving off these different pieces of the path we're able to implement this this multi team or multi-user cluster in a safe way in addition to having a 30 we can now place things that are typically annotations in ingress today things like service weights load balancing strategies you know prefix rewrite rules all those things that you've got to deal with today that maybe don't aren't described in the ingress spec we can describe them in a place within our C or D again so you can do that without having annotations all over your objects we're able to support in multiple up streams right so if you ever want to go out with traffic to multiple services within your cluster this is helpful to do things like Bluegreen deployments or maybe a canary deployment you can implement this maybe in a simpler pattern by allowing you have to have multiple services to route traffic to another cool thing is we can do is things this thing called TLS or certificate delegation so again an ingress today you've got to have your your secret live in the same namespace where your ingress object is right and if you have a secret copied across multiple namespaces one that can be a pain to manage and deal with getting that deployed out so you've got to rotate that you've got updated multiple places and and three your users have access to those private keys which may not be the be what you want so with contour we can tuck our secrets away in an admin namespace and then use delegation or to pass that the permissions off to other teams right so basically they can still use the certificates as if they were in their namespace but they don't have to have access to them so it's a good separation of concerns so why envoy why do we choose envoy when we started bloating contour well its dynamic configuration to be an API so I mentioned this is one of the first wins of contour so envoy expose is a GRDC endpoint and it's it's their XDS protocol so we can basically contour is the XDS server for envoy and we're going to stream this changes again down through that gr QC connection we've got this rich connection that we can push configuration changes down to and again not have to reload on void for that for it to accept them on void provides first-class support for HTTP 2 as well as G RPC so I'm looking for the future and what our users are looking to consume these two protocols are first-class citizens an envelope and it's battle-tested in production on what came out of that the engineers that lift and I use this all over the place and this has become a well-known component in lots of architectures today I'm gonna kind of walk through a situation and we're gonna look at basically what ingress looks like today so if I have two ingress documents right here I've got one on the left one on the right and you'll see here I have it one is for Team a so I've got one team here and one is for Team B so I'm splitting across you know two different namespaces here each team has created their own object and they're both have defined the hosts of project contoured at i/o and I both to define the same path slash blog but because there are different namespaces they're able to set different services throughout traffic to so in this case team a is writing to a wordpress blog and Team B is routing to service new well the question comes is when we go to process these documents together what happens right what is the result of this merge because we basically have conflicting descriptions of what this should look like really it's undefined right and this could be dangerous depending on how your controller processes these it could be the last one in wins the first one in wins maybe none of them win and your users just get you know four or four air so this is one of the things we look to solve with contour we wanted to come up with the way that we could allow users to still self-manage their an ingress objects their name space but not have to deal with these sort of issues that can come up and this is a common scenario where maybe you have this is your production application here and then you go and deploy a new application the new version of it and someone just you know accidentally deploys the same ingress object and we've taken down your production so we'll look here how to how we can solve that here with contour so contour can do that with this thing called HTTP proxy and if you're familiar with contour in the past we used to have a series called ingress route ingress route supported a path prefix and now our new proxy city supports path prefixes as well as headers and additional information so our users over over the last year gave us a lot of feedback as to what we wanted to do with that and we can do a lot more now which is why we have the new the new proxy see already it's again the same rules are still are still there that are the same goals being able to support multi team users and finding good homes for all these parameters so let's look at how this delegation can work so generically from a high-level this this works is that at the end owns a domain name right in my case there's project contours at i/o and this is defined and what we sometimes call a route proxy right or there's this top-level route item so it has ownership over this domain another team comes along and says hey I want to deploy my blog site so this is slash blog and we want to give them authority to do that so they'll create an ingress or a proxy and they'll define it to be slash blog and we'll implement this by and include and we'll show you how this works with real code here in a second but this route can then say hey this child object has authority to manage the slash blog so in the case that someone else comes along and they say you know what I'm the dev site I'm gonna go in or create a path of slash blog what happens is this contourable throw this out right because this proxy here does not have authority to manage that that path slash blog because this one already has it so you can see we can apply this to paths as well as headers and other things so if you just deploy this out over a large cluster you're able to safely let users again self manage themselves without having to deal with this overhead of the fear of breaking breaking your routes so we take a quick pause here if I mean has any questions that was all the slides that I had so next I like just dick do a bunch of code and actually deploy some of this and look at if that works no questions you have Steve but I suspect as we dive in they might be more okay sounds good so what I'm gonna start with is just a simple hello world right everyone starts with a hello world app so this is no different so we're gonna deploy a simple proxy here that basically just says anything on slash is going to route to an application so what I have here is I have some default apps that I wrote so what I built is this little simple echo server and what the server does is it spits out some text that I've defined and this is just to help us understand which application is getting the traffic and then and it spits out some information about the headers as well as the path right again just to help us to go ahead and kind of see what's going on so let's go ahead and deploy that so we'll apply this one app that'll create us some services and some deployments and then we'll also deploy the proxy great let's dig in at this proxy real quick and see what it looks like so you see here is I have my version and this is our CRT so this is project contour that io / v1 and the kind is HTTP proxy we've got to name a namespace but here's where that the fun stuff happens so here we define this fully qualified domain name this is the incoming host that convoys gonna look for in my case it's demo dot project contort at i/o and then I'm defining this TLS struct and here I'm saying I want to terminate TLS I'm gonna use this certificate right so if I go and look at I get my secrets you'll see I have a corresponding secret that's called TLS wild and this is using let's encrypt through the cert manager from the jet stack folks so this went out and got me a wild card certificate and I'm gonna just attach that and use it now that we're going to terminate TLS we'll look at the routes on here so here we have a set of conditions and conditions in proxy tell you what conditions need to be met for this route to match in this case I have one is just slash right so this is again the generic default route so slash is going to route to this route app application so we can verify that we have our proxy in here and we do I got all my proxies and it's it's healthy and it's valid so let's go ahead and curl that and we'll just see how this looks a little smaller here so if I do a curl on demo dot project contour dot IO you'll see this application returns and this is our default app site here and it's slash here you can see the headers and we'll look at that here in a second now one of the cool things that that you might have noticed I might not have noticed is here I inherently said HTTPS because we defined this TLS secret here in contour contour is going to be secure by default so other times you might have might have had to annotate your object to say hey do a 301 redirect from an insecure port to the secure port but contour will do that for you automatically because we've seen we have T last year so here if I do a curl on the insecure port what you'll see is contour will reply with or unavoidable return a 301 redirect and this is hey make sure you go to the to the TLS version there are ways around this if you're if you're interested in using the insecure port you can say permit and secure true and if I go ahead and apply this one now when I curl for the insecure port it'll work right because we're overriding that default a secure secure behavior so what kind of take that off and then we'll check along with some more things that cool alright so let's go ahead and add in a second route here so right now we have this route one I have another service in here in my space and it's called secure app right so let's do a little demo with that so if I go ahead and add a prefix of secure what's gonna happen now is I have two different routes I have a route for slash which is going to send traffic to route app and I have a route for slash secure which is going to the secure app so if we go ahead and apply that and if we do a curl again on the routes you'll see do the TLS version we get the default app which is what we wanted I do it on slash secure you'll see now I get the secure site right so that's that's cool let's make this a little more interesting right I mentioned before that conditions are all the requirements to make this this route match but I can do more now with with contour than just prefix and previously so what I can do is I can add a header to this and I can say the header has a name of X header and we'll say it contains the value ABC right so now we're going to route on the existence of slash secure in the peep and the path as well as this header on the request so if I go ahead and apply write and I do the same curl that I just did a minute ago if we curl for slash secure what happens is I get the default site right and this this is true because we we've required that the slash secure route have the header existing on the request and it's not there so this other route is matching that condition right because it's matching slash which is which is true but if I do the same request and I add a header X header of ABC what you'll see is I get the request to the secure app which so we've defined here and down here in the and the request if you see here the bottom we can have the X header of ABC all right so again these all get appended together and those all have to match for the proper request to work something else we can do is again we can add it be a more realistic thing would be like a user agent so maybe I want to say user agent is Chrome right let's take this one off baby so if I go ahead and apply this one again and I come over to Chrome what I could see is if I go to demo just I get the default site and if I hit slash secure I get the app right because I'm actually in Chrome but if we switch browsers and went to Firefox you see where I'm going I get the default site right I got the default one here because I'm asking for only having Chrome and in the user-agent headers are neat I can also do the reverse so I can say not contains so I could say hey I don't want Chrome and I don't want Firefox right so if I apply that one now let me hop back to Firefox you'll see I get the default site because we don't want Firefox if I switch to Chrome you'll see that in the default one but if we come over here to Safari you'll see that it works right because they can work this is not matching Chrome or Firefox it's matching Safari so there's how conditions can work and function in your app so looks like this is one step further and let's look at delegation so I'm just going to take these off for now and we'll have just the path now so what I do is I want to go deploy it another app right so I have a marketing team and again the sooner have you talked about in the slides or we wanted to have the marketing team have slash blog so what I can do is go ahead and deploy a marketing app if I do a good control I will do marketing or one so we'll create a name space for our team and then what apply some apps they're gonna have a couple sample apps that are gonna help us deploy this thing all right cool so now if I get my pods in the name space marketing you see I've got an application there and I also should have proxy or two proxies right so I still have the route 1 which we deployed just a second ago and now I have this new one in the marketing namespace and it's called blog site and the status right now is orphaned right because we haven't defined a linkage between the route 1 and this other proxy we haven't you know linked them together let's go ahead and do that so well do I'll go ahead and bring up my my route proxy which is here and then this one is my child 1 let's let's put together so maybe this will help to see them again this is my route one here on the left and this is the child one here living in the marketing namespace so what I want to do is I'm gonna go ahead and add this thing called include and includes in contour work just like they would in a programming language so if I have a programming language and I say hey I want to include a header file what happens is when that's before it's compiled that header file gets dumped in the top of the of the code and then the whole the whole headers is processed or compiled the same thing happens here right so if I have an include on an HTTP proxy you'll see that I can tell I can add conditions on to this one before it's processed let's explain this so from the root one I'm gonna define I have a proxy called blog site which matches blog site and it's in the namespace marketing and then I'm gonna give it some conditions so by doing this I'm gonna link these two together and I'm gonna add these conditions to here so let's go ahead and apply our route proxy right and then if we go ahead and get our proxies again you'll see that now they should both be valid and they're valid because now we have a proper linkage or a proper delegation from this route one over here to my child which is in the marketing namespace and the result of what's gonna happen here is as if on this one we define a set of conditions like this right this is what we contour goes to process these these conditions will exist here automatically but we won't have to define them there right because we're passing down these permissions automatically let's go ahead and test this out let's go back to here and we'll check out our route route still works now if I hit slash blog what I'm expecting to see is the blog site here we go I've got that but the cool part is is that for one this child proxy doesn't have to deal with TLS they've done that off in the route site in a different namespace and right now they don't have to deal with even the prefix because that's been passed off to them they have authority to manage slash blog again if someone else made another path prefix of slash blog contour and throw that out because it doesn't have permissions cool so now we can dig deeper right so we added a header to before so the same thing happens here with conditions on includes the sum of all those conditions get passed off to your child so if I add a header condition here and I call it name is the user-agent and we say it contains Chrome do Chrome again again the result here is that I have a slash blog as the prefix and now the condition is I have to have a user agent of Chrome right because all of the conditions as a sum are passed off to this other proxy so we'll go ahead and apply this route 1 again good so now in kernel this should still work and it does she get the blog site here but if we hopped over to Firefox and hit this path you'll see now I get the default site again because our child slash blog requires that we have both the path slash blog as well as the huge agent user agent chrome and that doesn't match so that's why it's not working so you can see where this is kind of powerful if you had to have a bunch of things exist on a request you can define them up here and again the sum of that rolls down I go so another demo we can do real quick is the marketing team wants to deploy an info site right so within their own namespace let's do a self delegation let's have it them delegate to themselves and see how this functions so what I have here is I've got two more apps I've got these info sites so if we go ahead and apply marketing and we'll do three give the info deployment as well as the info proxy so now again if you look at our proxy it should have three of them on the blog sites valid the routes valid but this new one here this info one is orphaned because we haven't done any delegations to it let's go wire that one up and see how this looks so let's get an include and now we're going to add it include to our child right so now on this include Here I am alright if we add this include here this acts as adding additional conditions to any of its children right so the root owns project contour da do and it passes off /blog to this proxy here now this proxy is gonna add additional conditions and pass it off to another child right so it has another child of its own and that's the slash info and this should all wire up so let's go ahead and save this child one here in marketing so we'll apply marketing o to proxy great now if we go and get our proxies here we'll see they're all valid because we've tied them all together but what happens now is the result of this child 3 of slash info gets everything appended together so the result should be slash blog slash info as well as the user agent of Chrome right because these all these conditions are getting applied down the chain because of the includes let's go validate that this works so I'll think it over to Chrome so slash blog should still do the blog site if I hit slash blog / info what you'll see here now is I get the info site which is what we wanted right but if I tackle this into Chrome or I'm sorry Firefox this should be the default site right and it is because again of our conditions but you can see here how this is kind of powerful right I can carve off pieces of my path pieces of headers whatever it whatever I'd like whatever I need to do and you just don't have to deal with all of that that logic but just they can just focus on on managing their own infrastructure within their own namespace cool so that is deployments let's go ahead and do a quick blue green and querida planet and and we'll poke through that real quick so what I'll do is I'll go deploy two more things so here I've got a blue deployment and the green deployment and they basically just spit out this is the green site or this is the blue site that's again just to help us to visualize this a little easier so let's go ahead and apply our marketing then we'll do for green as well as before blue all right cool so now if I get my services we'll see in marketing we'll see I've got four but now I've got blue and green all right so let's go ahead and update the slash blog here and we'll change this one to blue right so now when we hit slash blog I'd expect to see the blue deployment respond so we'll go ahead and apply our proxy too right so we deployed that child there and just to verify this we'll go ahead and refresh slash blog you see we get the blue site let's go ahead and look at doing a canary deployment so canary deployment works where you have two services you've got your current version and your new version and what you want to do is slowly move traffic over to the new version or the green version so your production is blue and your new version is green and we're gonna slowly turn the knobs and and send traffic from one version to the next but do it in a paste environment this can be done easily with contour now because we can do multiple up streams so what I can do is copy this and I can make this screen right mmm so I can have multiple services on an ingress resource so now what I can do is also add a weight so I could say hey Luke it's a hundred percent over a hundred points and the green one gets zero so if we go ahead and apply this let's do this real quick I have this let's do it I steal a while loop on this here we go so for every half a second we'll curl for that site right this will help us see it so you can see here well so here's the thing so I'm getting a default site because my route is requiring the user agent of chrome now I'll have that because I'm using curl let's go ahead and change that real quick and take that requirement out actually just do it here and just take a curl now we should get blue there we go okay so what I want to see now is that it's using I have again two up streams I have one blue service than one green service right now I have a hundred percent of the traffic going to blue and you can see I'm getting the blue site over and over if I want I can switch this around I could say let's send eighty here and ten here all right so now if we apply this one what I should get is mostly the blue but I'll get some green every now and again there it is I saw cream in there cool so as we can what we can do now is watch our metrics watch our performance see how this is performing if well we can go 50-50 split the traffic mostly I mean you can do this as fast or slow as you'd like now we're getting a blue and green pretty much 50/50 once we're happy with that will switch to 1090 apply that one we should get most mostly the green site now cool mostly the green site every day not again we should get a blue there we go and once we're happy we can ship it all so let me this is zero and make just one hundred I will apply that and now we've done a successful blue canary deployment from blue to green right so that's canary a Bluegreen deployment works in the same vein but instead of shifting traffic slowly we're gonna shift traffic all at once right this may be because you have a maybe requirement on a database that can't handle both versions or maybe your application just can't live with having two versions at the same time was just a totally reasonable thing we can do it a couple ways we can solve with weights right so just like this right now I could switch back to blue by making this one 100 making this in zero now I've given blue one hundred percent giving green zero so if I apply this we'll see an instance switch to blue one way to do it I know we could do it here so we could just obviously switch the service right now we're at blue I could just make this screen right and if I apply this one will do it instant switch from blue to green and the last thing we could do it would be to use use delegation right so I right now I have include sending traffic here I can create a whole new set of proxies and then swap those delegation chains and that would be an easy way to do as well the nice thing about that one is that you're not gonna be breaking any existing infrastructure right you leave everything kind of sitting as is you swap the proxies if you see an issue you can roll back seamlessly cool so I think that is all all the demo that I had which is a lot so thanks very much sticking around so here's just gonna give you a click after all that a quick overview of the roadmap of contour so contour is gonna hit 1.0 here in early November so tomorrow we're gonna ship an RC one and two weeks will ship at RC two and then come hang out with us the coop con much of the team will be there I have it I was speaking at on VidCon about some of these things and will be all over the place so come come here with us and chat very interested to see I mean they'll meet all of you and see you see your use cases and then here's how if you want to help get started in contour you can check us out at project contoured on Io we have a slot channel and kubernetes that's hashtag contour you can follow us on Twitter we have community meetings every third Tuesday so if you want to hop on a call and chat about anything that's going on or anything that we're doing and we also have a bunch of issues labeled with good first issue and Help Wanted so if you want to help contribute happy to help you jump in and help out that's all I have so many questions we can go run this Wow great presentation Steve thank you so much so we do have questions quite a bit let's see so servers questions in chat and I tried to answer it but basically contour can work across multi sown clusters multi-region cluster it could work across federated clusters I'm assuming - yeah so contour is meant to work within a single cluster so contour itself is just an ingress controller for one cluster so it's its boundary I think it's going to be that one cluster if you had to do a multi cluster type thing there's something that we have called gimble which aims to solve that so the idea there is you can have multiple clusters that miss could be kubernetes or OpenStack or anything else its goal is to go scrape those clusters and then basically turn a cluster into a routing cluster and use the power of contour here with delegation everything to then send traffic to multiple clusters but nice any of those multi cloud multi cluster things always needs a conversation I think to chat about how you're gonna implement that and have it look and work yes but inherently contour itself out of the box is only a single cluster solution cool all right thank you does contour support TCP traffic it does yes so you can expose in L 4 we do that over S&I so you still have to have it being a TLS endpoint but we can route TCP in there through S&I yes cool see just contour address the use case of developers controlling defining the fqdn effectively managing dns or it only works downstream so contour doesn't reach backwards so right now it's assuming like you know I had my example I was using project contour at i/o I had done DNS and set up a load balancer and done all that work behind the scenes so contour doesn't go out and you know and programmatically set up gns for you that's something that's that's on you to get set up today right got it cool ok talk about the secret management with regards to contour how are they managed differently than like normal kubernetes secrets what's the process there sure so I'm so secrets so you notice I had that route proxies namespace and I just mention this but what you can do is you can for one thing you can do is you can put all your secrets in a set of namespaces and then I can tell contour that this these root namespaces are only where root proxies can live and that key will basically if someone else creates a root proxy outside of one of those contour will throw it out right so limits the surface area of where those can live within there's route proxy namespaces that's where you can store all of your certificates so based on that contour if you delegate off paths or headers to other namespaces now all the secrets live in one namespace but your users can consume them from other namespaces that's the one generic scenario the other way you can do it is through a thing called TLS certificate delegation so what I can do is I can we have another serie called a GLS certificate delegation and what it does is you can say I have a certificate here in this namespace I'm gonna go delegate permission to another namespace so contour so it's just a it's a software based delegation and from that other namespace the team namespace you're able to say hey I'm gonna reference a secret which doesn't physically exist in that namespace but you can still use it because of the linkage you set up with that delegation chain so contrib will make it all happen behind the scenes for you so basically now your users can still reference secrets where they want to but the actual secret will live in a different namespace from the user yeah I mean it makes sense to me there might be follow-up questions are coming in after that explanation but we'll try to get to them what authentication schemes does contour support basic digest so off I'm assuming that's kind of not inside contours purview or maybe it is so there's an open issue to talk about I'm off so it's come up a lot where folks want it you know have it have contour help out with that I'm today there isn't there isn't a story around having off where contour is going to manage that for you but there is an open issue which I think join us get up let's maybe look at or fine to go comment on so again we're very feature driven and feedback driven so whatever users are wanting let us know open issues that's the best way to get good feedback to us but today yeah there isn't any off and the off story in contour cool good to know regarding weight distribution in Canary what happens if the total sum of weights is not 100 yeah so I always use 100 because these are for me to to grok in a demo but those weights are all arbitrary you could have it be you know one one one or three three three all so we'll just basically take the sum of all the make that two total so you can use whatever numbers you'd like you could use ten thousand and ten thousand and that'll work as well they're all just arbitrary however you want to manage those those percentages or those those values okay okay here we go all right you'll love this one if only one classic ingress controller is deployed in the cluster we usually get performance hit if some team is deploying a lot of changes breaking traffic from our other teams during reconfiguring for example does contour address this issue and I think the answer is yes but please explain how sure yeah so contrast shouldn't you shouldn't see an issue with busy clusters because because of how envoy we talked to envoy so envoy doesn't have to restart or do any kind of reboot logic Ollie will take those changes as fast as we can push them down that JIRA PC connection so there's there's no issue there there is a usually there's a there's an initial startup time so as when you first turn on contour it's got to go and scrape the entire cluster and get all of the services and endpoints and all those things depending on the size of that there could be a small hit but it's never really noticeable so yeah you shouldn't Alesi an issue of lag in terms of configuration changes and seeing it happen in real time okay cool so there's oh how can I change the admin port number for envoy with contour so you can't do it contour right now we don't expose that that ports it publicly so it's it's it's hidden behind it's only on localhost from the pod so I know we can get to unless you can you know port forward to that pod those contour support web application firewalls it does not today that requires the custom build of Envoy so you'd have to have a custom build of that so no we don't support that today all right so the next series of questions and I will leave this to you is comparison how does contour compared to engine X which Rafiq or you know how do you look at contour and the scope of its tio I can you can handle those how you see fit sure so in terms of SEO so contour is not a service mesh right so you can do some service mesh type things but I think depending on what your needs are sometimes you don't need to deploy a full mesh but that's a different conversation in terms of how contour compares to the nginx and traffic in those folks you know and your necks has been around like forever and eight traffic's been around a lot longer as well so I think there's more knobs under the hood and because that's contour apart is is this this proxy CRT right I think you're you just will be happy you'll be happy you'll gain a lot of a lot of gains from having that that C or D not dealing with with ingress today that said you know contour still supports ingress as is you know the upstream Kerberos ingress so you can still use that I know it's all I demoed today was our C or D but we still support normal ingress objects as well so release whatever whatever you feel like using I feel like having ongoing the backend is a big wing again with those dynamic updates on what self is a big community so you know it's growing and it has lots of patches and security winces which is good I'm sorry whatever it fits you I think is the best but yeah cool this is a contour support h2 or HTTP 2g RPC traffic and a load balancer across all the pods of a service yes so you can if you annotate the service with those those parameters we can do that HTTP to G right PC connection then you can also have multiple up streams in your in your redefinition so it'll it'll send them traffic across all of them what was the last part to all pods and a service you did you come oh yeah yeah yeah so all pods yeah so envoy so contour will use his envoy will route to endpoints right so we use the service in cure bays just to go discover the end points but contours like envoy itself is doing the routing so we can actually we didn't demo it but you can change the routing algorithm if you like so right now it's lead waist or its round robin you can do it lead device lead it least weighted request in different types like that yeah so it it is got a ten points awesome so have you seen many people migrate from engine X to Commodore and what kind of problems have they had yeah I mean we have users you know all the time coming in and saying hey I'm using this this is cool problems come up I'm trying to think we have a few bugs recently just cause we have this the you know the road to one dodo we switched to a whole new series so we've got a couple of things there but oh no I think those are getting ironed out you know we have some users that have different scaling issues that you know some people have again it's always the unique environments that you don't plan the 4020 role right yeah yeah so those things come up you know or you should just want like new features like hey it'd be cool if I could do this thing or I could have this feature and then let's chat about that and see see how we can best implement that so yeah so I think it's it's it's been going it's a growing community and it's it's on it's been exciting to see you users you know using it more and more that's awesome ah see Oh someone just came in with a question sorry let me answer long time okay let me preface this with the end of this question a long time a contour user from pre 0.9 days why the rename of ingress routes erd to HTTP proxy sure so if you so generous if you coming out with this one just to UM Dave Cheney he's our tech lead here on contour he wrote a blog post on this which should help explain it but the short answer is one ingress route is confusing because there's the kubernetes ingress object there's a generic term ingress and then there's this thing called ingress route that we created so it's when you say ingress it's like what's what version you talking about the object our object the generic turn and then it aligns more proxy aligns more with what we're doing you know we're in HTTP l7 proxy it is confusing with the l4 component of that but at its heart and soul I think on contours this you know as an ingress controller so reach out to that and and to that blog post and that should help hopefully answer some questions if not come find us and I'm just lack and we can we can chat about it some more nice a last question about Yaeger Tracey enabled Viacom tour I would think you can answer that but I think those are two separate issues yeah I'm not sure if you've ever set up tracing with anything we have to dig into that I do good issue I'm gonna open that up we can investigate that yeah definitely the Nash right like definitely post that issue asking that question I get help page or in the Select channel potentially you could spark a discussion for sure absolutely so you're gonna be a cube comm right VMware got a big boost big presents Steve you're gonna be there Jonas is also I'm assuming gonna be there or maybe I think he's in the other will awesome thank you he's in the chat dropping answers for everybody so thank you so much Jonas so we look forward to seeing everybody there at Keuka I'll be there as well stop by the slack channel for sure and github page is get up comm slash pressure contour right yes okay cool and yes do you've anything else before we go no I think that's it thank so much your time and again I reach out and open issues and chat with us happy to chat about anything so thanks for your time yeah thank you everyone for joining us today we look forward to seeing you at a future CN CF webinar have a good one

Channel: CNCF [Cloud Native Computing Foundation]

Views: 4,745

Keywords: Kubernetes, containers, containerization, web development, app development, microservices, vmware, contour, ingress controller

Id: 764YUk-wSa0

Length: 47min 11sec (2831 seconds)

Published: Thu Oct 10 2019