 My name is Mitch Connors. I am a principal software engineer and product manager for Aviatrix. I also work on Istio for the last five and a half years. I've been a member of the project where I now serve on the technical oversight committee, as well as the steering committee. I'm also a CNCF ambassador. So if you'd like to talk about how to get involved in CNCF projects, how to understand the landscape, well, maybe nobody can do that part. We'll stick with how to get involved in CNCF projects. Come talk to me after I'd be happy to help you out and help orient you. And I'm happy to share the stage with my colleague. Hello, good afternoon, everyone. My name is Zhou Huxu. I'm from Huawei Cloud. And I'm very happy to be here on behalf of Istio community. And I'm currently an Istio steering committee member. And I have been working in Istio for the last six years. And I'm also an Istio maintainer and previously also a community member. And thank you. Whoops, there we go. Well, so Tsongu and I have been coworkers now for six years. And we just met on Tuesday. So it's really cool to be a part of this community that spans the globe, that brings people together from different companies, different walks of life and literally different continents. So very cool to be able to meet you this week. Tsongu is one of my favorite maintainers of the project. I can always count on high quality PRs from him and issues to be resolved quickly. So super happy to share the stage with him today. This is our agenda today. It's pretty simple. We're going to be talking first about a look back at where we've come from over the last 12 months, thankfully, we're not going to go back 12 years. And in that, particularly, we're going to look at these four topics. We're going to be talking about the health of the Istio project. How are we doing? There's a lot of projects that are struggling these days. The economy is very difficult. Getting contributions is hard. So we're going to check in and make sure things are going well with the Istio project. We're going to look at what's been released over the last year and the significance of those releases, why you should care, particularly with regard to security vulnerabilities. And then we're going to have a tiny like 30 second celebration as Istio graduated or was moved to graduated status by the CNCF. So let's not steal the thunder there. Looking at our project health, this graph, by the way, everyone can find these charts themselves. This is not a privileged graph. This is at Istio.devstats.cncf.io, I think. You might want to just Google it instead of typing it in because I might have gotten some of those out of order. But the bottom line is CNCF gives these dashboards for all of their projects so that you can keep tabs on health. This particular graph shows over the last two years the different companies that have been contributing to Istio. Every contributor, even though it's open source, can mark their company affiliation. And as you can see, I want to point out two things. One, there's healthy contribution. Overall, we've got about as much contribution as we were seeing two years ago, not seeing any big decline due to the economic downturn. Two, I'd like to point out just the sheer number of companies involved in contributing to Istio. I went through and counted them. There's actually 58 of them. And that does not include those who have contributed but have not marked what their affiliation is with the CNCF. So Istio has supported or contributed to by all of these companies. I want to thank these companies for their contribution. By the way, these are pull request contributions. So these companies are not just telling us about issues, though that's very important and valuable to Istio. They're actually contributing code to fix those issues, helping to move the project forward. And I'm really thrilled to have so many different companies involved in supporting that and so many different colleagues across all of these companies that I get to meet at events like KubeCon. So big thanks to all of those companies. Now let's look at the project from a slightly different perspective. These are the net new contributors, as well as what do we call them? Periodic contributors. A periodic contributor is one who has contributed in the past but maybe not in the last 90 days. Overall, we do see a slight downtick in the periodic contributors. Those are the, I think, the blue and orange lines. We see a little bit of a downtick. That could be one of two things. That could be that we're seeing a little bit of reduced involvement from some of the contributors who were once or twice a year. Sort of makes sense if you're trying to prioritize things, make sure you're proving your value and you only had a few contributions a year. Maybe those aren't as high of a priority this year as in others. The other possibility, though, is that we have more contributors simply consistently contributing. They're not taking those 90-day breaks in between their pull requests. This chart really doesn't show the difference between those two. But the thing that I'm more impressed by is that our overall new contributors are pretty much on par for where we've been. 2022 was a record year for new contributors, so quite high. We're not really meeting those levels but the green and yellow lines show that where we're at with new contributors this year is about where we were at two years ago. So shows that the project is still moving healthily. By the way, if you're not an Istio contributor, I would love to see you help us move those yellow and green lines upward. Join us at github.com slash Istio slash Istio. Last dimension we wanna look at in terms of project health is how long does it take to get a pull request merged? Each of these lines shows a different percentile. I don't recall which line corresponds to which percentile, but you can see that the green line has less noise, the yellow line a bit more and the blue line a bit more than that. So that gives you some idea of where we're headed but overall the story here is again, consistency. The time to take a PR to merge is approximately the same as it has been for the last two years. It's a noisy chart but it shows consistency. Istio is a project that you can rely on to have consistent new contributors, consistent releases and a consistent time to resolution of the issues that are raised. So really proud of these statistics and the track record that we've set as a project. I'll also note that at the beginning of each of these charts we were not a part of the CNCF. So the move to the CNCF while it's been wonderful for the project I'm very thankful to be able to be here and representing the project on behalf of the CNCF. I also will say that it didn't fundamentally change what was happening in the project. It's been consistent across the donation. All right, let's look at the releases we've had over the last year. Our releases go like clockwork every three months for the most part. We did have a four month release cycle for this most recent release due to some security concerns. But by and large we've had good progress. Ambient went to Alpha a year ago. That's getting a little bit long in the tooth and we'll talk about that. We need to move that forward to beta in the coming year. And the Gateway API support moved on to V1 beta one which is the most mature version of the Gateway API at the time, I think it might still be. Gamma support, the Gateway API if you haven't heard of it by the way is a Kubernetes API standard for arbitrary proxies. So rather than learning the Istio API in particular and then if you wanted to switch to a different provider you'd have to learn their APIs. You have one API that should work for all compliant providers. We also think that it's a preferable API. So if you're a new user to Istio probably start with Gateway API for Istio rather than virtual services and destination rules. If you've already invested, don't worry. We're gonna get to that, you're safe. Just a little bit of a better experience for our users we think. We've improved our DNS experience for users a little bit more consistent with what Kubernetes was doing in the past. And we've introduced something very exciting just this last week, compatibility mode. Within the project we're often having to balance a decision between consistency and innovation. We got the default wrong in one release. The next release, do we change the default to be the right thing? Or do we leave it so that it's consistent for those users who onboarded with the wrong default? We've found a way around this choice with compatibility mode. When you first onboard to Istio you should lock in your compatibility mode to whatever version you've onboarded at. And your defaults will then stay consistent until you choose to change your compatibility mode. So you can upgrade safely. We can be modifying the defaults for new users so that we're fixing problems but we're not breaking you as you upgrade. So really happy about that work. And then we've improved a little bit on our CNI support for Ambient which we're gonna get to a lot of Ambient information later so I'm not gonna spend much time there. Our patch releases are mostly about 50% of our patch releases in the last year have been about CVE fixes. At any given time we have two or three minor versions of Istio that are being supported at the moment. There are three. We've just shipped 121, we're also supporting 120 and we're supporting 119. So tomorrow if a new critical vulnerability usually an envoy were to be released or to be made known to the project we would ship fixes and patches back ported for all three of those releases that then you can pick up in open source and make use of. By the way, we've got some research showing that those aren't well picked up. So if you're an Istio user today and you are not running one of the latest versions of 121, 120 or 119 would encourage you to consider your upgrade posture. Envoy CVEs are serious business and the things that you secure with your Istio service mesh are very important. So have a look at those, make sure that you're not impacted and if you are impacted please keep your service mesh up to date, very proud of the fact that over the course of the last year there were zero, zero day exploits. Not that there are no CVEs, there are plenty of vulnerabilities being reported and patched at all times but none of them were publicly disclosed so far as we're aware and made use of in the wild before we were able to publish patches for them. So very proud of that record and looking forward to another very safe year with our product security working group. And of course, we have to talk about this at KubeCon. In August it was announced that Istio had been moved to graduated status. Istio joined the CNCF as an incubating project in the summer of 2022. So it was great to see the maturity and the broad user base recognized graduated status by the way really just means that Istio is ready for production adoption across the industry and we're ready for prime time. We think that's probably been true of us for several years but it's great to have that recognition from the CNCF as well. All right, and now I'm gonna pass it to Tsengu for the next section. Yeah, next section I will talk about what we did in the recent releases and what we'll do in the next release or the future releases. And then at last we will talk about the culture action. Okay, first let's look at what is unbent. Unbent is the most features that Istio have been working in the, I think last year or more. Yeah, now let's take a look at the unbent architecture. On the left side, the architecture is focused on the L4 traffic management. And for L4 we can see that there is a Zeternal reside in the node. It is deployed per node, sorry. And then the Zeternal will intercept the traffic sent out from the application. And then it will redirect it to the remote nodes. So the proxy they use is based on the H-Bone. H-Bone is a new protocol that is designed based on the HTTPS and it is actually a tunnel protocol. And then on the server side, the Zeternal will do some authorization and then before send it to the server. So compared to the Sidecar mode, it is completely Sidecar-less and the Zeternal is very light-weight. And we have to separate the L4 and L7 traffic management because we want to improve the security and to make it either later with each service account. So look at the right side. It is the L7 traffic management architecture. And compared with the left, we have a waypoint deployed. The waypoint is actually envoy based. So the traffic first will be redirected to the waypoint before it is sent to the server. What does waypoint actually do? If we know Sidecar for the L7 traffic management, it is down in the Sidecar. Now the waypoint actually is the same. So the next left look forward what is still we are doing next release? Yeah, actually we have done import redirection in this release. So why do we introduce a new import redirection in this release? Because in previous release, the traffic interception is based on the node network. And it may conflict with the third party container network working CNI like CDM and CaliCore. And also conflict with OpenShift or Azure CNI. So what is import redirection? Actually it is innovative solution. First we can take a look at the right side. First it will enter POS network name space and then set up IPTBOS capturing and redirection rules in the port. And then at last it doesn't interfere with host level rules. So have no influence on the host CNI implementations. It is very like the side car mode now. I mean the traffic redirection and capture. Next we can, I'm sure that in the next release 1.22 we will announce ambient F4 beta. And I encourage everyone to take a try. And in next release it will be completely compatible with any third party CNI and any Kubernetes platform. And also it can achieve side car mode compatibility. And the compatibility we provide includes L4 traffic load balancing and it is as secure as side car. And we also provide the authorization policy and metrics functions. So what's the status of ambient L7? Yeah, actually ambient L7 is still alpha. We want to make it beta in the maybe 1.3 26 or sorry, 1.24, yeah. Before that 1.7, L7, I mean, okay. You know, L4 is going to beta in 1.22, L7 is not. Yeah, yeah, I mean L7 is not. Yeah, so before we get to that stage, I think in for ambient L7 we need to plan a new feature this is currently being discussed and working. It is L7, we point capture. What is we point capture? We point capture is to capture the traffic to services and workloads and to simplify we point implement. Now we point customization for users and vendors. How we do the redirection? Actually, if we want to capture, we need to apply an annotation on the service or port. You can see it is this annotation. And then with this, we will do the capture automatically. And then how we can deploy the viewpoint. Actually, we have a viewpoint deployment controller in EC2D, so it is the duty of it to deploy it. The requirement is that user should have to create a gateway API object. Okay, then how to use that? You should create a route or policy configuration with gateway APIs. So we totally support gateway API. Okay, on the right side, I want to show you what is the sandwich we point. So we should point it is actually to terminate the H-bone as the terminal and then propagate the desktop address and social address and peer identity to the we point. So it can simplify we point configuration. And then we point, sorry, and then we will encode the identity and such the important information into the TLV. And then we point, need to terminate that and communicate with the collocated Zetano via UDS. And then Zetano should also be able to encamp its bone on the outside and send to the server side. Okay, sorry. The next one is we will maybe promote ambient LS7 in 1.24 or later. So what are missing for L7 beta? I think there are several points here. It is lack of telemetry capabilities compared with Zetka and we point implementation is complex. And the API support is missing some security and part of the networking capabilities. Okay, so next turn to Mish. So ambient's very exciting. I think it's going to be a very compelling product and I hope to hear feedback from you all on it very soon as we march L4 to beta. But it's not all that we've been working on and we've got some other exciting news coming up this year. Any of you, were you users of Istio back in 2019? Anyone back in the day? Okay, so we've got a few, that's great. At the time we used Helm v2 for our install and upgrade process. And Helm v2 had this very interesting characteristic when it came to custom resources. I don't know if any of you have the misfortune of encountering this. But rather than applying updates to the custom resource definitions, that's like your database schema of Kubernetes effectively, it would delete the schema and then recreate it. So if you had configured your service mesh with virtual services, destination rule, auth policies, et cetera, when you upgraded Istio you would have this really fun effect where everything you did was deleted. But your Istio upgraded, so it's all good. I was working at Google at the time and we have a habit of looking at problems and thinking, you know what, we can do better. So we began to build the Istio operator to replace Helm. It would bypass this problem with the CRD delete and handle everything in a nice item potent manner that doesn't cause so many conflicts. Well, it turns out that was a lot harder than we expected it to be. And Helm 3 was published before we were able to publish the Istio operator and solved all these problems within Helm. We went ahead and published the operator and overall the feedback that we've had is that it's really not the right tool for the job. Our Helm support has been much improved since that time to the point where we're actually, we've not been recommending that new users adopt the Istio operator for some time. And we are announcing here that we will be deprecating the Istio operator this year. We originally planned on doing that in 122. I think my slide is gonna say 122. Been having some dialogue online about a possible delay in that deprecation schedule. But keep in mind that deprecation does not mean removed. It means we will be formally announcing that it will be removed. We're going to begin warning users. We're gonna give everyone an off ramp and we'll talk about that on this slide here. So Istio operator has been a beta supported solution in Istio for quite some time. And ordinarily our beta support policy is that you have three months to move off. We'll announce it three months later, we'll remove it. But we recognize that that is probably not sufficient time for the amount of adoption that Istio operator has seen. So we're going to go ahead and use our GA support policy even though this was never a GA feature and give all of our users 12 months from the time that we formally announced Istio operator's deprecation before it is removed from the project. The other major initiative that we have here is we are going to ensure that if you have invested in the operator, if your operator.yaml file is what defines your current Istio installation, we are going to provide a migration tool. It's not available at the moment because I got busy doing KubeCon stuff instead of finishing my pull request. So my apologies there. It'll be available very soon. What this is going to do is it'll take an operator.yaml file as input. It will produce a helm values.yaml file as output and then you can use that file to install Istio with helm. So the automation that you've built around the operator will probably need some degree of update but we hope that that will be a very smooth process for you. If you have concerns about that, please reach out to us either on GitHub or on the Istio Slack. We recognize that this is a big operation. We want to do it with minimal pain to users but we do think the best thing for the community moving forward is if the operator were no longer a part of the project. It's caused quite a bit of friction for some people and we want to make sure to prevent that moving forward. And that 12 month removal policy will mean May of 2025 is the earliest point in time where we could ship an Istio release that does not include the operator. All right. The other thing that we've been working on getting back to what Chengu was mentioning about ambient is we've been reimagining ambient as something that's bigger than Istio. If you had a bunch of network utilities prior to using Istio and you onboarded Istio, what you needed to do with those network utilities was likely figure out how to do the same thing with Istio. Translate Apache config into Istio config or Nginx config into Istio config. And there's no guides to do that. There's no Istio cuddle translate your Nginx config command and there's not going to be one. It's an incredibly complex thing to do. Or you could try to continue running those network utilities with a sidecar. So then you have the sidecar proxying traffic to the proxy which then sends the traffic forward back to the sidecar proxy. And then to your application, hopefully you can see why that may not have been the best choice for many of our users. What we're doing with ambient is imagining since we have this sandwich model where the Z-tunnel handles all of the complicated H-bone operations and the waypoint is not required to understand them. The waypoint only does HTTP. There's no real reason that that waypoint needs to be envoy. It could be Nginx or it could be HA proxy. With ambient and L7 starting in release 122, any Gateway API compliant proxy can be run as a part of your ambient service mesh. In particular, a lot of you may have some old configs that a developer wrote 10 years ago and then left the company. No one has touched them since then because no one knows quite what they do and you're a little bit intimidated to do that. That should not be a blocker for adopting Istio ambient mesh. We want you to be able to bring that proxy with you, know that it gets all of the security guarantees that you're used to having with Istio ambient mesh and yet you don't have to figure out how to translate your crufty old configs. I know I'm looking forward to not having to do that any longer. I will say that there are two caveats here. One is we will not program your arbitrary proxy for you. So ordinarily, you set up a waypoint gateway, you can program it with HTTP root, TCP root, and we'll support it and explain how to do that. If it's an Nginx gateway, you need to talk to the Nginx team about how to get config onto that particular proxy. The other caveat is that while we can do MTLS at layer four and tell you that it's encrypted, oftentimes you wanna apply authorization and authentication policies at layer seven. And for that, your proxy will need to have some degree of understanding of the contract between the waypoint and the Z-tunnel. There's no real easy way around that limitation. I think in most proxies, you're gonna be able to do that via config rather than waiting for the proxy to add it in code, but that is a limitation that you should be aware of before adopting this pattern. And this will be available for you to kick the tires in May looking forward to your feedback on that. All right, looking forward in the next year as well, we're gonna start talking again about API graduations. If you were an Istio user back in, what do I have listed here? 2020, we moved a whole bunch of our APIs to beta, indicating that they were ready for production adoption, but that we might have a few tweaks to them moving forward. Well, we've not really done those few tweaks because they got adopted so quickly in production that it was immediately clear that breaking these APIs would break an implicit promise we've made to our users that their service mesh will continue to work. We've struggled for a number of years with what to do with these APIs because there are some things that we think are not ideal. I've already mentioned that if you're making a choice between APIs, choose the Kubernetes Gateway API over the Istio native APIs. However, the nature of the APIs being beta has been caused for consternation. Some of our users have been concerned that we're going to yank the rug out from under them and suddenly within three months deprecate all the APIs they built their service mesh on top of. So we are gonna be promoting the networking APIs as well as almost all of the security APIs to GA in this upcoming release in May. Again, this is not a real change to the API per se and this is not a vote of confidence that this is the best possible API. What this is is a commitment to consistency for users who have adopted these APIs that they're not going to be changed out from under them that they can depend on them for many releases to come. While we do think that the Gateway API in many cases is a better option, we're not gonna remove these APIs from the project until we have a clear signal from our users that they are no longer necessary. So if you're a user of the API and you're worried about it being deprecated, just make sure we know that you're a user of the API and we'll be supporting it for many years to come. All right, and with that, I'm going to hand it back to Shungu for our next section. Yeah, it still is excellent and amazing. Here, I want to call you everyone to join us to build an excellent and amazing technology to change the world. And how you can get involved in e-stool community? First, we have some steps. First, you can ask us questions in the following ways. You can ask us via Slack, via GitHub discussion. I have a note here that the discuss.e-stool.io is deprecated by the GitHub discuss. So the next step, you can join the community via participate our community meeting and follow us on the Twitter. And then if for the more you want to be a contributor, you can join us. We are very welcome. Sorry. So the next part, you can visit our booth at the second floor. I think it is very easy to find. There is TLC member and the student community member and the maintainer there. You can ask them any question. So it is a good chance. Don't miss that. Thank you. Thanks everyone. I want to mention that of course you can always reach the Istio project at Istio.io. You can reach Shungu and myself at the contact information there. And I wanted to point out that my colleague here has joined us to present in English for the first time in his career. So big hand to Shungu for having the bravery to do that. If I were to try to do this in French, I could get about three words in before I would be lost and so would everyone else. All right. Do we have any questions? I don't know if we have a floating mic for questions. Yes, I see one moving your way. For the next version of Istio, 122, and Ambien L4, it was mentioned authorization policies. So would that be based on current Istio authorization policy resource? And what kind of authorization we're talking about at L7? Are those like SAIN or common name or any certificate based authorization? So authorization policies have been retooled slightly for Ambien, particularly with regard to how they target workloads and how they apply to workloads, but overall most of the fields are going to stay the same. I think we had to change one field for that particular thing. And the things that are going to be available to you as beta in 122 are going to be your layer four based authorization. So if you have advanced authorizations such as HTTP semantics or things like that, that will still be a part of alpha. And I mean alpha can still be run with layer four. So you can spin up a waypoint by using the Gateway API and attach a layer seven authorization policy to that and it will work fine. The other thing we're going to do that we haven't done as much of in the past is if you create a layer seven policy and you do not have a corresponding layer seven proxy so that that policy is effectively not working, we're going to make sure to write to the status field to inform you of that so that you're not making your security decisions based on APIs that aren't working. Okay, thank you. Yes, yeah. Right here. We started using the Istio several years ago and we have a very good experience with that. I have one question. Kubernetes updates itself three times per year and you update yourself four times per year. So it is possible to update this three times per year because we have one spare update in which we need to update all the sidecar of all the Kubernetes nodes but we don't need to update the Kubernetes. You've got two maintainers sitting right behind you who are both nodding their heads like this with your question. So we do support skipping minor versions or yeah, minor versions during upgrade. So you can upgrade directly from 120 to 122 and have a biannual cadence of upgrades that's completely supported and we support each release long enough that you should be able to still get security patches while you're doing the upgrade, et cetera. So if you want a three release upgrade cadence what you might do is do one skip release say 120 to 122, then you do 123, 124 before skipping again. That'll get you to three times per year. It won't perfectly line up with the Kubernetes schedule but the difficulty with aligning, we talked actually as a project for a while about aligning with the Kubernetes schedule. Envoy is very important to the Istio project and if we were to align with the Kubernetes schedule we would misalign with the Envoy schedule in such a way that you would be running an unsupported version of Envoy proxy in production and that did not feel like an unacceptable amount of risk. Any other questions? They're gonna keep you running back and forth. Okay, hi, so Michiel from IT Geeks. So big news for me, operator is getting deprecated. Will we at least be able to use it also in 122 and with that nice tool that you have. By the way, I'm a big fan of Helm and really didn't like the previous so yeah, now the part looks better but with that handle everything that the current CR does like Ingress gateways, Ingress gateways, everything. Yes, the long and short of it is that under the hood for quite some time now, the operator has used Helm. So it takes the operator and translates it into a Helm command. We're just gonna go forward and reverse the flow. I do wanna stress though, 122 is when we're hoping to announce formally that the operator is deprecated. You will have another year of releases. So at a minimum, the earliest possible timeframe for removing the operator so that you cannot use it anymore will be 126, which would launch approximately May of 2025. So we're gonna give you a very long time to migrate. We recognize what an investment it is to change your CICD tooling and your platform engineering to reflect this change. By the way, with most of our installations at the moment, the operator YAML is actually generated with Helm, so. Oh, so you're going Helm to operator to Helm to Kubernetes. All right, well, let's clean that up together. Last question. No, I think we're out of time. I'm really sorry. All right, well, thank you everyone. I'll be down here or actually, I think I'll be in the back of the room there and I see a couple of other Istio maintainers in the room. So feel free to come up and ask us some questions. Thank you all for joining.