Cloud Native Computing Foundation EnvoyCon 2019 (San Diego), 21 Nov 2019

Previous Meeting

⏯

youtube image

►

From YouTube: The Universal Dataplane API (UDPA): Envoy's Next Generation APIs - Harvey Tuch, Google

Description

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects

The Universal Dataplane API (UDPA): Envoy's Next Generation APIs - Harvey Tuch, Google

The vision of the Universal Dataplane API (UDPA) is to evolve Envoy's v2 xDS APIs to become an open standard for the configuration and control plane of L4/L7 dataplane load balancers. We envision an industry standard for L4/L7 data plane configuration, similar to the role played by OpenFlow at L2/L3/L4 in SDN. The CNCF has formed the industry spanning UDPA Working Group (UDPA-WG) and in this talk, we will discuss the vision and goals of UDPA, progress towards a UDPA standard, upcoming Envoy xDS and implementation changes and the roadmap ahead.

A

Good afternoon, on my god, yeah yeah, sorry about that reminded a bit of technical difficulties: okay, I'm Harvey, Talk, I'm, a senior envoy, maintainer and I also work for Google, where I'm I lead the efforts around envoy platform, specifically api's in security, and today, I want to take you on a journey through the future of the Envoy XDS api's. So, let's start with this slide, which depicts what I think is one of the key points that has been that we largely attribute towards the success of envoy- and that is envoy- is a platform.

A

It's an open platform. It's highly extensible, it's not just the proxy or a load balancer, it's something that you can customize towards your needs, and this includes the data plane. Where you, you know, we have our filters and our various extension points and also the control plane, which is what I'm going to focus on today and the control plane is largely about having Envoy configured at runtime via the XDS api's.

A

What is XDS I assume most folks are familiar with xes, but just a quick recap. So XDS is a set of G RPC api's, which we use to configure Envoy I can pretty much deliver everything you need to give to envoy at runtime to change its behavior, and this varies from very bad table stakes like listeners. You know what port is Envoy. Listening on to service discovery, to delegate her health checking to things like even reconfiguring the runtime system, cryptograph, the delivery of crypto certs and so on.

A

Now, when are we first open sourced at the end of 2016? We had like one discovery service now was this called service discovery service? It's now called EDS, and this was a simple polling rest JSON API, and over the course of 2017, the api's began to evolve pretty dramatically. We got api's for things like cost, the discovery, routing table discovery and so on.

A

We had integrations with sto, where I personally got involved with envoy was in the latter half of 2017 when we started to he introduced the vitu XDS api's, and these were a pretty huge change paradigm shift. If you will- and we went towards types protobufs is our canonical definition, which allows us to scale up the api's and and make them accommodate all the growing use cases that envoy was taking on, and we also introduced gr pc streaming as a basis which allows us to I get high speed updates.

A

Now, over the last two years, the v2 XDS api's have grown significantly. Okay, there now are like 15,000 lines of coded proto. It's like unbelievable.

A

They also have things like HTS, which I mentioned before we've added in all these features to address scalability concerns, which we've heard quite a bit about today, including things like incremental XDS and a VHDs, and the talk.

A

The rest of this talk is gonna, be about two things: okay, the v3 XDS api is and what v4 v father going to look like and what our new versioning scheme is, and the universal data plane api, which is really exciting, a project that we have going on in the community so to understand why we even need a v3 API, it's good to look at like where we are today and what our sort of pain points are now the ecosystem around envoy, API is has grown really significantly over the last few years and we now probably have at our best guess order a hundred management servers out there.

A

We don't have any exact numbers on this, but it's definitely more than ten and definitely probably less than a thousands.

A

We really need to get better at ensuring we have stricter adherence to put above Y compatibility rules that includes things like never removing fields don't break any existing users of the API and then that's sync and so does management service. It's also new clients who are interested in adopting on voice debug tools, config pipelines and so on. So what we need to do is ensure that the api's can follow best practices here and the best practices are just don't remove anything, never modify anything once it's in the API.

A

You can only add okay, now, that's kind of at odds with where we really want to go with the api's, which is essentially to rake in prove them right. We are these api's. We don't want to be used like this growing sort of tangled ball of string, which gets like you more and more tangled over time. We wanted them to actually start to become cleaner and simpler over time as well. So we want to remove technical debt and involve envoys API. So how do we do this without violating one?

A

Well, the only real way to do this is to have actually a new API when you want to start to simplify things, and we actually essentially have a complete copy and paste of the v2 API since the v3 API is, and then we remove the things that we don't actually really want from, and we you know we move fields around and we rename things and so on. So we essentially no longer have this a single version of the API. We have a sequence of these API versions going forward now.

A

Another big challenge is like: how do you do this at scale? I, don't know we really are talking about doing it at scale. Here we have a huge API surface.

A

We have just within the Envoy kind itself, thousands of references to the proto's in the field and the types in this API and when you have to go from v2 to v3 and rename everything it's a pretty big said job, so you've, probably something a little smarter than that, and so we're turning towards things like put above plugins, clang, tooling and automation to at scale mechanically move on voice implementation ahead, and this is actually we establishing went to design patterns here which we're putting together as we do.

A

The v3 API is which hopefully, management, servers and others will be able to benefit from okay, so where it's v2 major version today. This is where we are and v3 alpha is in development.

A

Now, at the end of this year, we're hoping to release the v3 major version, and this is going to start off what we call the API clock and it's going to have a tick which occurs once every year at the end of the year, in conjunction with the Envoy release, and at that point we'll introduce a new major version, so v3 is released. Then v2 is deprecated but still supported by envoy, and we begin on v4 alpha.

A

That's the end of 2020 we're going to release v4. The 3 is deprecated now, what's really interesting here is v2 is removed if you're relying on this in your management, server that you can use existing feature.

A

Api is at that point think again you are going to have to move towards v3 and with that in mind- and this is like a really important thing to keep in mind and as we go forward each year will release a new API at the end of the year, and the pattern for this is gonna, be we're really going to have three versions supported by envoy at any point in time, they'll be like VN plus 1.

A

Alpha, which is one we will use internally and or more developers, will write we'll have the N and the N minus 1 major version supported and we'll have translate direct translation code from these api's to the current alpha version and the previous versions will support will be removed from the client completely, and this pretty much takes us to the API versioning story.

A

Now, there's a lot more detail around this and we have a markdown file on github, so I recommend you check that out and there's the API versioning doc, so the v3 API is aren't going to do anything. Super exciting, they're, really just going to be mechanical changes, we're going to be introducing process and tooling. There's like a ton of work around that. So don't expend anything specifically. We added in v3 on day one but we'll be adding in things as we go, because that will now be the next actor version.

A

So UDP a is the kind of exciting thing which leads us into the v4 api's and what is UDP a ok. So this follows from a think piece that matt wrote a medium a while back and it sort of explore this idea that you know there's only so many probably ways you want to configure things, and you know all envoy, all data plane proxies have to listen on a pause and eat a router table need to do service.

A

Discovery and envoy has like a really great set of open api's, which have a bunch of integrations and whole ecosystem around that. Why don't we just adopt this as like a standard for all l7 data, plane proxies and load balancers, and so we forms a working group under the CNC F, there's UDP a working group UDP, a WG for short, that's rig snappy, and we have mailing lists we can sign up to. We have a Charter. We have a bunch of design Doc's exploring what we want.

A

The next generation of api's envoys api's and the generic ones to look like, and we expect most of this work to take place early next year, we're pretty busy at the right now with v3 API. So, to give you a flavor of what UDP a is going to address, it's going to be things like evolving xes as a generic resource transport protocol, which can be used beyond just envoy for any kind of like resource or configuration distribution. It sort of builds on this insight that really won't XTS is a pub/sub protocol for proto objects.

A

We want to think about things like Federation. We want to do couple from envoy specifics and we get rid of sort of you know very specific technical debt that we built up in the v2 XDS api's, we're all just also interested in building our things like compliance tests and the reference implementation that that's independent from on, but which is really important. If you want to treat this as a true standard versus just like oh yeah envoy, does it so everyone else should, which is not the most enticing thing for the rest of the industry.

A

So we have a working group proactively, look reviewing our design Docs, and we hope that that will also provide a sort of initial sanity check there. So that's all this has been a lightning tour. Please I'm! Happy to take questions, I think I'm out of time now, but any time that's appropriate man. What kind of coop come. Please come speak to me having a chat api's. Thank you.