Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2021, 29 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Envoy Maintainer Q&A - Lizan Zhou, Tetrate

Description

Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Envoy Maintainer Q&A - Lizan Zhou, Tetrate

Q&A with Envoy maintainers. Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions! Come ask questions!

A

Can you tell us a little bit about the road map for envoy um in the months ahead.

B

Okay, so um so employee is really a community driven project, so we don't have any like specific feature. Roadmap saying like this will be landed in like 1.21 1.22, or anything like that. um Anyone are welcome to contribute to the project and uh to drive each features by their own. So we do have some roadmap for specific features like the two big area. Right now happening is the http 3 support. Google is heavily invested again invested in that, um and another area is the web assembly.

B

Extensions that was like invested from a couple years ago now is in still in the alpha stage. It's because of the post. The extension mechanism is in the in its early day and web assembly ecosystem is also in its early day.

B

We're trying to stabilize this make it more usable for our users, um that's also driven by um astro community as well, so we are at statute. We have invested in that as well. Thank you.

C

You guys done any like uh performance testing for the the wasm environment versus like a native c plus filter.

B

um So the um that's a good good question, so the web assembly performance is like a very well asked. um It really depends on the situation. I'd say um I do see if you have like very simple um filter. That might be, um I think it's a half performance performance of the zip express stuff.

B

um It's really depends on how you do that like. If you have more like small string copies, it really degrades the performance um if you're just like doing some stats around the the traffic with several. Basically, it's not that bad and the glue code between web assembly and envoy is not really well tuned. Like there's a lot of copy, we just want to make it work so yeah. Those are things that could be improved in the future, so it really depends on the on the use case.

C

I guess I have a follow-up question then, um for the the low-level abi for envoy. Are you guys? Are you guys going to use the wasm api as you're considered stable um internal api? Are you are you going to uh like finalize an internal design and then stick with that.

B

um So the there was an api that uh envoy interacts with web assembly modules called proxy wasm. That's in uh like separate github project, uh we're trying to stabilize that, but I think the version right now is 0.1 or 0.2. I think so. um It will be stabilized over the time. At this moment we don't uh it's not really stable right now, because there's more use case, we might change that to adopt a real use case. We don't. We don't want to lock ourselves to some specific api which is not used anywhere else.

B

So um that's the current state, but we're trying to make that as stable as possible um in the future.

C

Okay cool because I just asked because uh I I asked a question in the envoy slack yesterday about using like the c plus dll kind of system for uh the dynamic like, for example, loading a filter. Instead of using wasm. um We could point to an external sequel plug-in and then we might not have the negative performance effects. But uh I believe I think matt mentioned something about finalizing the stable abi inside of envoy. Before we ever get to that.

B

Yeah, so um I would say the current was on my api is still like um should be stable, more stable than the what the invoicing is filter api, because we don't burden that we don't do any, uh have any back backward compatibility assurance on that. That can be changed anytime and the filters in the envoy mainstream report. If you use any api, we do tests on all of them, so we do update how they use those like filter api extension api.

B

um But if you have your own in-house ones, then when you upgrade envoy, you might need to change your code to adapt to like new version like um when we have the filter api changes. um That should be like less likely. If you use the web web.

A

Assembly, api to.

B

To do the interaction with envoy.

C

Okay cool. Thank you very much.

D

So questions from more of a user perspective envoy has a very fast release pipeline where the versions are released every quarter and after a year, they're usually deprecated for most companies, when the main competitor njx is barely releasing anything. There is a high toll here on maintenance and upgrading versions. Is there any thoughts done around this? This issue.

B

So your so the question is about the unvoice cycle is very fast and it's hard to maintain over the time right. um So I think we we increase. It increase the supports cycle to one year right now. Every stable version have one uh one year supported for security fixed stuff.

B

So um I think that's that's what that wasn't the case in like a couple years ago, we only support like latest release and only master um so yeah there, and we try to make the we have the compatibility policy about the duplicated like we only remove duplicated field in um in two radius. We can. We do have some sort of that. Are you saying that is still very high.

D

Yes, uh so um I come from niantic, you might know us, as the company behind company pokemon go. Our clusters are there for over four years. It's really hard for us to now go and deploy a new version with all the testing and everything and the guarantee that nothing will break when you are deploying a new version versus the engines that we were using before that. To be honest, we haven't changed the version through all the life.

B

So the the well, the answer to that will be as a project. We are also short of the resources to maintain older versions um like over a year. If um so, if there's a, if you have resources or anyone else, other country have resource can like contribute and make the commitment to the project so you're welcome to do so.

B

Like maintain older version more longer supported, um you can contact me or contact in the voicelab to make that proposal and have the enough resources funded there. We can make it happen, but the reality is, we don't have unlimited resource, so uh there's from project maintenance perspective. We don't have um enough maintainers to keep the that supports for like two years or like supports more versions so yeah. That's.

D

Well, something to think about even one stable version that can once per year is good enough. Can I ask another question.

B

uh Sure so, if you're asking for um the so there's, there's like different like there's, people asking for like people want a new feature to land it in the stable version faster. So they they want. They only one to uh deploy stable versions. So it's I think it you don't have to really like upgrade to the latest stable version every quarter, because the support cycle is um it's one year right, you can upgrade like every two versions and you still have some sort of compatibility, um because we we remove difficulty stuff. We remove the api.

B

Stability is more longer than one release. So it's you can build your own strategy on that.

D

Yeah- and I totally get it it's uh at least for a year back- it's very important to have all the new updates of the new features, all the great work that everybody is doing. Another question is more around the go control plane, so we do have a problem with go control, planes, release cycles, not aligned with invoice release cycles. For example. Currently the last version from go control plane produces a deprecated error because it wasn't updated with the latest. Is there any thinking on aligning them?

D

So it's kind of more a wish list than a question. I must say.

B

C

So uh previously the the data plane and the actual server code in the control plane were all versioned together um in the current months, we're actually working on a release plan where the data plane and the code will be versioned separately, and we will we are targeting a 1.0 shortly. um So hopefully those problems will no longer be an issue for people. uh We've had a lot of requests to get. That said, we.

B

Just haven't had.

C

The bandwidth to manage uh release cycles like that, since it's such a small skill project.

C

Yeah, no definitely yeah. We are. We are working to fix that.

A

B

Okay, um anyone else, let me check if I have any online questions.

A

B

If you have no more questions, so I can wrap up quickly all.

A

Right thanks everybody for attending and yeah. Please uh drop a review on the sketch app and uh enjoy the conference.

B

Thank you, everyone yeah, I'm still around. If you want to ask me a question privately welcome to do so.

B

Thank you. Thank you.