 All right, this is emissary ingress self-service api's and the kubernetes gateway api. I'm lance austin a principal engineer at ambassador labs I'm flan. I'm a technical evangelist at buoyant. I used to be at ambassador labs, but not anymore All right So we're gonna go over a little bit of an intro a little recap on what's happened since kube con Detroit in the fall and then talk a little bit of self-service configuration and then jump into some stuff about gateway api So quick quick show of hands who here is completely new to emissary ingress All right, I guess we're doing the full intro so If you have not run across emissary ingress before it's an api gateway That means you've got your kubernetes cluster. You have users out somewhere in the internet emissary's function is to sit between those two and Provide access for the people out in the world to interact with services in your cluster It is an open-source cloud native developer centric opinionated self-service api gateway There will be a quiz, but we'll come back to that later. Don't worry It's a CNCF incubating project. We donated it in 2021 2020 something like that. It's been with CNCF for a little while. It's powered by envoy What this basically boils down to is that we use envoy to wrangle all of your data and then we use emissary to wrangle the envoy Since it is an api gateway one of its core functions is traffic management So if you've got Jane out in the cloud and she wants to request a quote from the quote of the moment service Then emissary will go through and accept that request and route it three to one of the workloads If mark asked for the quote of the moment mark may end up talking to a different instance of that workload But yeah, this is all okay API gateways are not just proxies though. They get to do a bunch of other things. So in particular App security is a big one where maybe Jane is allowed to update a quote but mark is not allowed to update a quote and Emissary gives you a place where you can put that functionality in one place Manager for everybody in one place and not have to worry about all of your application developers getting it right every time in the applications themselves There are a bunch of other things that can happen here There's stuff that emissary does about observability it can do rate limiting it gives you a bunch of resilience features It can do things that make it easier to develop your apps entirely We're not going to go over this whole slide, but yeah, there's a bunch of stuff baked into this overall It is a API gateway But more importantly it is a self-service opinionated developer centric API gateway We'll be coming back to that in a little bit But first I'm going to hand it over and let Lance talk about what has changed since Detroit in this project Thanks, Lynn All right, so recap since cube count Detroit So first we've had quite a few new releases in our three series So 3.4 3.5 and 3.6 we shipped to quite a few new features Better security easier migrations and we'll talk about those in a little bit here In our two five in our two series we ship just critical fixes making sure that we keep up to date on those And we're also doing some we're Kind of a lesson learned from our one series is really making sure we stay up from our our our major dependencies So we're gonna, you know, you know, I'm boy moves quickly So we want to make sure we keep with that cadence So you'll see us continuing to stay up to today with on boy underneath the hood Thank you for not emphasizing how painful that lesson was Yes Same with go laying and other other critical dependencies for the project So key new features that we've shipped just recently so open telemetry tracing That was a great partnership between one of our maintainers Alice and Paul they work together to get that shipped and We're really happy to have that Resolved name ports and ingress if so if you are still using ingress and we'll talk about our our our language here in a little bit So you'll see that but if you are using the ingress resources We got help from Anton. He was a first-time contributor. So that was really great Direct TLS support for ingress fatted that non-blocking ready. Listener again. Thanks for Fabrizio and Tomas That was a good really helped and they were really patient with us. So we were we were happy on that one and so active upstream health checks and we also added support for get ambassador Vs V1 This is to help reduce some of the migration So folks that were coming from older clusters and from the ambassador one This would make sense for for folks that are just starting out and you're you've already adopting V3 we recommend you need to V3 alpha the latest that you see in our docs So again, thanks for our community so since cubecon we had 175 commits 10 first-time contributors We have 9,000 members in our slack channel and 4k hub stars and again just another shout-out to our community and some some some of the folks that have recently submitted Pull requests and commits Pierre Paul and on Dmitri Tomas Favruti. We really appreciate that Yeah And I'll hand it over to Flynn So I said we'd come back to the whole self-service thing and I'm gonna emphasize again This is self-service developer centric and opinionated configuration stuff We talk about this every time we're doing this and the reason is fairly simple. It's important one of the things that gets glossed over a lot at cubecon in particular is That kubernetes is a means it is not an end There is nobody out there who runs kubernetes solely so they can say that they're running kubernetes Everybody runs it because they are trying to get some other application to accomplish certain goals and this is important The self-service part of the self-service developers in your Developer centric opinionated part the self-service part is about allowing your developers to achieve the goals more quickly By arranging it so that they don't have to be constantly waiting for other people to be able to get things done The developer centric part is about allowing the developers to achieve their goals more easily By providing them with configuration tools that are using a set of semantics that makes sense to an application developer The opinionated part is about trying to provide straightforward mechanisms that make a lot of sense as opposed to mechanisms that can accomplish absolutely everything but are ridiculously complex in our world This shows up by the set of CRDs that we did originally We've got listeners that talk about what ports and protocols you're listening on We've got hosts which talk about host names TLS certificates things like that We have mappings which talk about taking chunks of the URL space and routing them through to specific services All of these things could be expressed in a single resource like the Ingress resource If you do it that way, then you tend to have multiple people getting stuck editing the same resource all the time Which is painful so we didn't do it that way Another thing going on here is it is absolutely possible to have a single person going through and Working with all of these resources and managing the whole configuration start to finish But it is also possible to have say your developer crew worrying about request mapping While trusting the operation side of the world to worry about listeners and hosts and certificates and rate limits and auth services and There's a bunch of stuff down there this separation of roles this separation of concerns turns out to be a thing that Really helps Allowing people to get stuff done We're going to be coming back to this when Lance is talking about the Gateway API because this is also a big deal there Overall This is one of those things where the self-service, you know microservices 101 Separating things this way and arranging it so that everybody can work independently in parallel all the time lets you get things done More quickly it does require a lot of trust The developer side of the world has to trust that the ops side of the world is maintaining the infrastructure correctly Likewise the ops side of the world has to trust that the developer side of the world can get their stuff done without destroying the cluster It requires going both ways it can be very uncomfortable for people who are just coming into this world, but it really is worth it It's a good thing It's also worth pointing out It requires trust, but it doesn't require a blind trust There are a bunch of tools available in Kubernetes that permit you to do this more safely our back gives you guardrails We're kind of fond of the coop control sudo sang which lets you Mostly interact with a cluster in a way that's safe and then when you need to do stuff that's dangerous in an audited controlled fashion You know the declarative thing lets you fairly easily audit the world It's fairly easy also to build layers on top of this with you know get ops infrastructure as a service CICD all of those things Give you ways that you can let people go forward quickly in parallel and still have some confidence that the world is not going to come to an end tomorrow and All of this actually ends up tying back into some of the gateway API stuff, which I will let Lance talk about I'm giving him the hard part Yeah, so who here has heard of the gateway API? Who here has worked with it? Okay, a lot of fewer hands. Okay, so we're gonna we're gonna talk about it. We're gonna go quickly over it And that there's tons of talks here at there So hopefully you're already catching them and that'll go really in depth in it But we wanted to touch on it and kind of talk about how it compares to MS area You just saw the MS area language and then kind of talk about where it's cut where we're going with it So so the gateway API is a standard set of resources for service network networking You can think of it as the successor to ingress resource And it's community-driven. I think that's really important. It's being community-driven It's coming from a lot of experience from other projects and trying to take all the lessons learned Similar to emissary where we talked about self-service developer centric developer oriented This is role oriented So it really looks at that what we talked about that developer and that trust between them and the platform operators as well and in general like I said it takes it's been taking learnings from projects like ours contour And then the wider ecosystem of Kubernetes. Oh Before I go back and check it out. There's a lot more content obviously on the the website So go ahead and when you get here download the slides click on there and read about it and tons more So earlier we showed you how ingress compared to the MS area language And you can see we have our listener host and mapping and you can see a similar Thing in the gateway is where it's broken up all the resources are broken up broken up into individual resources compared to the ingress, which was one large one large resource If we dive into them individually You start with a gateway class So the gateway class is similar to ingress controller class if you've worked with that before and so it's saying what? controller wants to listen to these resources and can handle them then We say what is the gateway there's a gateway and so this is similar to what you just saw the host and listener But they're kind of consolidated into a single resource here So this is where you'll actually say what gateway class that you want to talk to you'll say what protocol? Port number if you want to have DNS resolution here This is a wildcard example.com and if you want to terminate TLS certificate Found in a secret and then finally similar to a mapping We have an HTTP route and so the HTTP route is going to give you that ability to shape that traffic so traffic comes into your cluster and it hits a Emissary and it says okay, where do we want to go we want to go to When we see foo example.com we want to go to this back-end ref quote quote 80 If we put them side by side or sorry if we look at it like we did earlier We said there's Jane this developer and she's really focused on her application And so she can go ahead and focus on HTTP routes similar to emissary where you'd focused on Mappings and then there's the platform administrator that can focus on those those cluster-wide things and they'll focus on Gateway class and gateway so very similar in that separation of concerns So now you're probably asking the fun question does emissary ingress support the gateway API and The answer is yes, but not really so if you go out to our docs today, you will see You can search and you'll find the gateway API on there, but it's a much much older version of that and so That's why we've been spending time getting familiar. We've been working with the gateway API team we've been working with on boy gateway to understand it better and And we want to see where it wants to go And so the other question you might be asking is what about the v3 CRDs that we have and what we just showed Well, are those going away is the gateway API going to replace them? Well, that's where we kind of actually we want to hear from you guys So what does that look like? And you know, we've we've for people that have been familiar with emissary ingress and you've been using it for a long time You're very familiar with our language for folks that are new you want to see the gateway API So do you see a hybrid of the two? Do you see it being? Being a backwards translation. Do you see it more of a get ops thing? These are things that we want to talk to the community about see what you're interested in and and actually put that into the product and We do have a contrib fast later So we'd love to have you guys stop by or the OSS pavilion and chat with us about that and we'd love to hear more So just out of summary here Emissary ingresses focuses on self-service ingress because it's a great way to let everyone get things done faster So if you're new to the kubernetes world and to emissary it's definitely something to look at if it when you're setting up your teams and how you want to operate being able to focus on platform and then developers being able to focus on on their piece as well and it takes trust, but it works really well once you get it right We think it's definitely starts to make sense to look at the gateway API and like I said There's a ton of talks here. They're going really far in depth in it But we want to know what it's gonna look like or what you guys would like to see it look like in emissary We emissary input language that we just went over the host listeners all those things They're here to stay there for the foreseeable future but we want to know how would it look with a gateway API and that and So we need your feedback and we would like to really work with you on that in the community So again, we just want to also say thanks to the community as you saw earlier in our slides We had lots of contributors lots of new contributors here And they've been really really pivotal on some key features and so we'd love for folks here that I want to get involved Like I said, we have a contrib fest later today at 430 So definitely stop on by or you can always catch us on slack. I lost one of our Other contributors that's here at the conference Flynn mayors. Sorry. Yes, maintainers and Flynn and myself You can catch us on slack or again at the OSS pavilion Um For any contributors here, I see a few so we just wanted to give a shout out for the tag contributors strategy if You're you know, you're a maintainer and you're looking to Getting more involved in the Kubernetes CNCF world Go ahead and check this out. There's a link here And it has a lot of guides on how to contribute and and whatnot All right Thanks, and then questions questions Is it work, okay My name is Andre. I'm from London. I've been an active user of ambassador stack for years and I was always confused between Ambassador at stack and emissary ingress. Can you? Elaborate on these a little bit because latest changes Venues the the beats the buzzer between them Can you speak up on this a little bit? Thank you? So emissary ingress is the CNCF Project that we're here talking about today and that was like when said 2001 Or sorry, it's my life. Yeah around that time. Yeah age of myself. It was donated around 2021 I think the project started in 2017. So it's been around for a while and so That is the open-source project and then edge stack what you're talking about is is built on top of that So it's added features like authentication provides authentication service rate limiting and those types of things. So You want to add anything on it? Emissary also has authentication to rate limit and all that stuff The big difference there is that edge stack provides you an implementation of the external services that are used For those so emissary has hooks to call out to an auth service And edge stack bundles an implementation of the auth service that does a lot That separation where you've got emissary as the open core of a larger commercial project is very very likely to stick around I It's always fun for me to deal with stuff because I don't work at ambassador labs anymore But I'm fairly confident that edge stack isn't going away. It would it would surprise me a lot if that were to happen Going forward we do expect that where emissary is currently built directly on top of Envoy Emissary is probably going to shift to being built on top of Envoy Gateway. That makes a lot of sense and Then edge stack will continue to be built on top of emissary which is built on top of Envoy Gateway and it's turtles all the way down Thank you Anything else? Hello. Yeah, go ahead and then there's one over here The edge speaking from France, so thank you for the presentation. Absolutely. Thank you for being here a quick question is about Envoy plugins implementation in emersy especially when we look at two is the Jrpc to Http rest to us Jrpc transcoding Because you know the most of public API the arrest API and the developers we speak about the developers experience Enjoy doing a Jrpc microservices so we really need the Envoy that already implemented The Jrpc transcoding to Http. So what you're inside about this. Thank you So the the flip answer is hey PR is welcome Obviously, I'm being a little bit facetious about that one, but do you remember? wasn't there I Feel like there was work that was done to start enabling that one do you remember? Yeah, yes When you look to the cultures there is something but nothing raised Okay, so in that case Why don't I would like to talk to you a little bit more about that one because I thought that there was stuff already in There that could do this If it is not what you're talking about I want to understand that Thank you Hello, hi there. Thanks. So the the scenario that I had was let's say the Product that we have is distributing emissary gateway, but the customer's environment also has let's say Emissary gateway installed but different versions of CRDs Different version of the product or project. Let's say in that case obviously we have a conflict because we want to install Different versions of CRDs. So do you have any? Suggestions on how do we handle these scenarios? Thank you You want that one? I guess not Recent emissaries have a component called a bi x that is supposed to handle the translation for you between CRD versions, so I would encourage you to install the newer It's a little tricky in installing the newer version of emissary should allow Translation for all of the older versions of the CRD that are already in the cluster and that should do what you need If I understand you correctly, you're talking about Different versions of emissary running so there's different versions of the actual CRD itself not Not this not our CRD version. So is that what you're referring to? Okay, so you are referring to that. I wasn't sure if you were talking about just the different versions So Kubernetes itself doesn't allow you to version in the sense of How do I word that things get really tricky if you're using a version of Kubernetes that uses the old Like v1 beta 1 custom resource definition resource I know it trust me. I know Kubernetes itself do you remember what version this changed in anybody Shane? I'm looking at Shane because 1.22. Yeah so in Kubernetes 1.22 support for the custom resource definition beta version went away and You had to use v1 proper and a lot of the rules changed And if you're trying to deal with older versions of Kubernetes and multiple versions of project CRDs Your life is going to be miserable Don't do that upgrade your version of kube If you're using a newer version of kubernetes, so you're using the v1 custom resource definition Then the newer versions of emissary like emissary 3 and higher Should be able to deal with the problem that you're talking about where you need to deal with multiple versions of the emissary CRDs Did that I hope that answered the question instead of making it less clear Thank you Hey for service mesh integrations with console connect and Istio How do you use linker D? Yeah, okay? Well with them starting to support The gateway API as well, how do you guys see emissary ingress fitting into that picture Do we have emissary routing only to non service mesh services or you know? What type of architecture would you guys see that's evolving into? The actual answer to that question is go and hang out with the gamma group, which is worrying about gateway API and service mesh and In the bright shiny future that we all look forward to then we will have ingress controllers and service meshes That are living in perfect harmony configured with the gateway API and everything will be wonderful and we'll all sing kumbaya And the Middle East will be peaceful and yeah I don't actually know how long it'll take to get there, but It's a thing that's yeah It's definitely a thing that we're paying attention to because it doesn't actually make a lot of sense to do gateway API and not Think about how to play nicely with service meshes as well There's there is in all seriousness a lot of a lot of work and a lot of thought going into that in the gamma group some of the Some of the concerns you run into there are deeply deeply fascinating That's that's a good word right Any other questions Okay, thank you. Thank you