 Hi there, my name is William Morgan, and I'm one of the creators of LinkerD. This is the introduction to LinkerD and state of the project talk at KubeCon NA 2020 Virtual. I'm going to be joined by my fellow LinkerD person, Tarun Pusulapati. He's going to tell you about the LinkerD 2.8 release, the very fresh LinkerD 2.9 release, and our plans for 2.10 and beyond. By the way, Tarun started his LinkerD journey as a Google Summer of Code student, and now he holds the illustrious title of LinkerD Maintainer. So hopefully he'll tell you a little bit about that. But before that, I'm going to give you an introduction to LinkerD, what it is, what it isn't, and then I'll hand it over to Tarun. So, here we are. What is LinkerD? LinkerD is a service mesh. Hopefully that's a term that you have heard before, but it's okay if you haven't, because I'm going to tell you what that means. LinkerD is known as an ultra-light and ultra-fast and security-first service mesh, and I'll go into details for each of those aspects of LinkerD. A very healthy community of adopters and contributors, of which you are now officially members. By watching this talk, you are now part of the LinkerD community. So welcome. It's very nice to have you here. Over four years in production, Slack channel with 5,000 members in it, very helpful and friendly members, all sorts of GitHub stars and contributors, and of course we're hosted by the CNCF. All sorts of fancy logos up here, two logos up here that are not up here that probably should be because we have two very exciting end-user talks at this very conference. One is a keynote by Dave Sudia of GoSpotCheck, where he talks about how he uses LinkerD and other CNCF projects to build a developer platform at GoSpotCheck. So definitely go watch that talk. And then another exciting talk from Justin Turner and Garrett Griffin at HEB, talking about how they rolled LinkerD out to production in order to accelerate the delivery of their curbside checkout. HEB is a grocery store in response to the COVID-19 pandemic. So LinkerD is not just a cool project. It can actually help people get their groceries as part of the pandemic. So that is really exciting for us. Be sure to check out those two talks. So let's get back to LinkerD. What does LinkerD do? So as a service mesh, we bucket these features into kind of three categories. LinkerD gives you a bunch of observability features, a bunch of reliability features, and a bunch of security features. And there are some nice screenshots here of the cool dashboards that we have as well. And what's interesting about the service mesh, in my mind, is that it's thought that these are new features that we've never had before. It's that what the service mesh does, what LinkerD does, is it gives you these features at the platform level. So rather than having the developers have to implement things like TLS, or retries, or timeouts, or metrics, of course they still have to do some of that. There's still a component to reliability and security and observability that cannot be done by the service mesh. But rather than the developers having to own all of that, they can now get those features at the platform level. So that's what LinkerD provides. It moves those features out of the hands of the developers, and down to the platform where they belong. And LinkerD, of course, focuses on being very light and being very simple. So why should you care? Well, in my mind, you should care because what LinkerD does is it gives you, the platform owners, the Kubernetes adopters, the SREs, gives you some primitives around observability and security and reliability that you need. You need these things if you're building a cloud-native application. And it does it in a way, like I said, that gives you no developer involvement. So it's not really about solving technical problems so much as solving socio-technical problems. It's going to give you the control and ownership over your own destiny. Sounds great. Okay, let's talk a little bit about LinkerD's design philosophy. In short, I would say this is do as little as possible. So LinkerD should just work out of the box. You should be able to add LinkerD to a functioning Kubernetes application. And the application should continue functioning. Sounds great. Actually pretty hard to do. It should consume as a minimum of resource costs. So memory, CPU consumption should be as small as possible. The latency that it adds to your application, of course, should be as small as possible too. And there's all sorts of cool engineering that we do in order to accomplish that. It should be simple. So you as the operator of LinkerD should not have to wrestle with a thousand configuration options and a whole bunch of new YAML and so on. You've just adopted Kubernetes. It's already very complicated. You shouldn't have to adopt a whole new level of complication. And LinkerD should have security enabled out of the box on by default. And that's the big headline feature of 2.9 around mutual TLS. But I'll leave that for Turin. So if a control plane that's written in Go sits in a Kubernetes namespace, we have a very cool data plane written in Rust, which I'm going to talk a little bit about called LinkerD2-proxy. And I have, you know, some background reading here if you feel like hearing about some of the history in the big kind of rewrite from LinkerD V1 to V2. All right. So just briefly, LinkerD architecture, like most service meshes, there is a control plane and there's a data plane. The control plane is a bunch of components that sit off to the side and give you control and visibility into the data plane. And the data plane is a set of proxies. Those proxies are deployed as sidecar containers, which means they sit in the same pod as your application containers. And LinkerD does all the magic to make the TCP connections to and from your application components go through those proxies so that the proxy can handle all the fancy stuff that needs to handle and can initiate and terminate TLS and change HTTP1 to HTTP2 and so on. And ideally, that happens under the scenes without your developers being aware of it without them even having to know that LinkerD is there. Now, you might have noticed in that diagram that there are two proxies that we've added in between every single hop. So that means those proxies have got to be really, really fast and really, really lightweight because you might have a whole lot of them. So we have invested a whole lot of time and energy into what we call our micro proxy, which is a LinkerD data plane called LinkerD 2 Proxy. It's a critical part of the system. Many service meshes are built on Envoy. We're built on this very dedicated service mesh proxy which allows us to be extremely fast, extremely low memory, and extremely secure. So by writing this in Rust, we avoid a whole class of memory vulnerabilities that are endemic to C and C++. We can be just as fast as the machine will let us be. Of course, we're audited thanks to CNCF. We have regular third-party security audits, which we pass. And LinkerD 2 Proxy is built on this ultra-modern asynchronous network stack. So all of the really interesting asynchronous network programming kind of development is all happening in the Rust world today. So if that kind of thing is exciting to you, then please check out the repo. Everything is open source. Of course, the patch EV2, 100% audited, 100% awesome. So that's LinkerD 2-proxy. Here's a little snippet from the security audit. Of course, the full audit is in the repo itself. Atypically excellent code readability. Careful choice of implementation languages. Yeah, it was a good report. Okay, we actually have a newer version of these numbers. Unfortunately, that newer version was not available in time for me to record this. But if you search for Kinvoke LinkerD benchmarks, you should find a whole bunch of open source benchmark frameworks and results talking about how expensive it is to run LinkerD. And the answer is, well, it's more expensive than not having a service mesh, but it is a lot faster and a lot smaller than other service mesh alternatives. Istio is the one we like to pick on, because that's the one that everyone knows about. LinkerD is much, much faster and much, much smaller. But do your own research, check out those results. And then finally, I said we were going to pick on Istio a little bit, and I'm happy to take questions. I'll be around during the Q&A period for this. In my mind, because this is such a common one, I want to address it up front, I think it comes down to what do you need in a service mesh. Both Istio and LinkerD provide very, very similar value props. They both provide these security and observability and reliability features. But there's a very different focus between the two projects. Istio is extremely feature rich and works in many, many different environments under many, many different situations. LinkerD is very focused on doing the bare minimum. So we are very focused on the Kubernetes use case and we're very focused on making it so that if you want the power of the service mesh, you actually don't have to do any configuration at all, at least certainly not to get started. And we'll do as much out of the box for you by default. Of course, that doesn't mean we're hiding things away from you. We're also very focused on visibility and introspection. So at every point, you know exactly what LinkerD is doing. And you can understand the state of the mesh as well as how it's helping your applications. Okay, so lots more to be said on this obviously. But at this point, I am going to turn it over to my fellow LinkerD person, Tarun Pothalapati, who's going to tell you a little bit about what has been cooking in the LinkerD kitchen and what is coming soon. So take it away, Tarun. Thank you, William. Hello, everyone. My name is Tarun and I'm one of the maintenance of the LinkerD project. In today's my part of the session, I'll try to cover the current roadmap of the project and also the current state of the LinkerD project and also the future roadmap. So first, we'll start with the 2.8 release, which added support for multi-cluster. This means that you can have applications across clusters talking to each other in a secure manner. This is possible by adding a new component called the multi-cluster gateway that acts like an entry point into your cluster. And all the communication from other clusters will flow through. That's the following goals. So it expects a unified trust domain that is validated across all clusters, across clusters during communication. There is no single point of failure, which means that even if a cluster goes down, it does not affect the service, the multi-cluster functionality. But for your application, you can use things like traffic split, et cetera, to fail over onto other clusters, et cetera. Applications on other clusters. It also does not have a requirement on the networking primitive that the cluster uses. So you can have this feature in environments like private environments, VPCs, or on the open internet. It also builds on the same unified in-cluster communication model, which means that all your metrics, traffic splits, primitives like traffic splits, et cetera, service profiles will work out of the box. Next, 2.8 release also has a ton of other improvements around Helm, the installation way, et cetera. Next, we'll talk about the current latest release, the 2.9. 2.9. By the time you're watching this talk, the release would have already gone out. So feel free to try that out and give us feedback. So the flagship feature is TCP, MTLS, and load balancing, which means that not only your HTTP request, all your TCP connections will be MTLS and load balanced out of the box without any extra configuration. This has been one of the requested features. So we also added support for ARM64, which means that you can run the CLI, the control bin, and the process on ARM64 devices like the Raspberry Pi, et cetera now. We also added support for bring your own Prometheus, which means that previously whenever you install even now, whenever you install Linker, you have Linker to get its own Prometheus, which is used to power the dashboards, the CLI, et cetera. We are trying to make it easy to use your own Prometheus that you already have in your environment so that the control bin, et cetera, can talk to your Prometheus to power the dashboards, et cetera. We also made it made the existing Linker to Prometheus more configurable so that you can have things like remote right, et cetera configurations on the Linker to Prometheus. We also added support for service topologies. Service topologies is a relatively new feature in Kubernetes that allows you to have node topology aware load balancing. So for example, if a client is connecting to a service, it should probably talk to the part on the same node or at least on the same availability zone so that the latencies are lower rather than some other one. So if you have service topologies configured with that information, Linker will take that information into account whenever it's taking a load balancing decision so as to have a latency so that to have less latency. We also did a foundational change on how we store state and retrieve it during upgrade. So essentially previously as Linker is being adopted more widely, it has been a problem to add more configurations, et cetera, specific to environments, et cetera. We made it easy to add more configuration options without having to change things at multiple places so that you can have more configurations on Linker. 2.9 release also has a ton of other improvements around multi-cluster, multi-threading in the proxy and support for endpoint slices. The 2.9 release is a very tightly packed release and I'll highly recommend you to check out the release nodes to understand the scale of this release. Next we'll talk about the 2.9 and beyond. So first obviously we will work on the server speaks first protocol which means that for applications like MySQL, et cetera, where the server speaks first rather than the client, it's hard for the proxy to do protocol detection and to do MTLS on top. So what we are planning to do is to have a way for the user to configure things so that the proxy can configure that it's a server speaks first protocol and so that the proxy can act accordingly. We'll also be adding support for multi-cluster TCP which means that not only HTTP connections can flow through the multi-cluster ghetto but also all kinds of TCP connections and it is and they are MTLS obviously. With both of the above changes done what we can do is to we can mandate TLS by default in your cluster. So what it means that Linker expects you to have some configuration to tell you that to tell Linker to that there is some communication that you don't want MTLS so it means that by default all your meshed applications all the if all the applications in your cluster are meshed it essentially means that you have TLS by default everywhere which is awesome for security and ordering purposes obviously we'll also be having a minimal control plan installed. So what you're trying to do is that even though the Linker to components right now can work independently the installation package is a bit tightly packed to allow you to do that so what we're trying to do is that to break up these components into modules that you can independently install and incrementally install. So for example first you would start with the core control plan that consists of the proxy injector the destination service the identity service and then you can incrementally install things like the dashboard on top so this makes the installation approach more simpler and also more flexible based on your environment etc we'll also be doing authorization obviously so which means that you want to have a way to configure policies on which service can access which other service and which service should not access which other services essentially we'll be adding a new new primitive around those lines to make it possible to configure allow and deny rules based on that we are also planning to have standardized APIs and add on framework so it is as so what a service mesh allows to be built on top using its APIs is very important so things like flagger which does canada deployments or the service mesh interface etc are built using the APIs that a service mesh provides so to add additional functionality like an agent that reacts to golden metrics and emits events and things like that you want to have a standardized API on the service mesh so we are trying to make the API more standardized so that it is easier for more developers to add to build agents and other things on top and we are also planning to have an add on framework that makes it easy to use that makes it easy to have additional components installed together along with the lilinkard installed like agar etc one of the we'll obviously have a lot of other plans around WebAssembly plugins etc as more and more of these use cases and feature request pop up we'll try to prioritize based on that and have all these road maps are available as issues in the project and if you are interested on any of them you should definitely check them out or raise an issue if you are interested in a specific use case and we can figure it out as it's a planned roadmap keep in mind that it can change so next we'll talk about the getting involved side of things so I'll tell my story first so like an year ago I was a cnc of intern working on linker day on various bug fixes on the SMI project etc and then I've been kept contributing on it now I'm one of the maintenance of the project which is awesome I guess so if you are interested in contributing to the project we are more than help help having you and help you get started contributing to a project not just implies that you have to write code there are like 100 different things that you could do a project for example you could write blog post on a specific problem that you face during the install and blog about it so that other users can can take note I'm sure a lot of users would fall into the same problem we have a very active slack community where not just the maintenance but also the users ask questions and also answers and also answers between themselves all our development activity happens on GitHub using issues and using issues and discussions feature we also send mail English etc about the project updates etc we also have monthly community calls where where we provide an update on what's been cooking in the project and also take user feedback questions if you are interested we are more than happy to help you get started thank you