Service Mesh 101: an introduction with Linkerd

this is service mesh 101 with linker e my name is alex leung i'm a software engineer at buoyant i'm one of the maintainers of the linkerdy project and i'm here to tell you a little bit about service mesh and lingardy so linkerity is an open source service mesh and it's a member of the cncf i'm going to talk a little bit more about what a service mesh is in a moment but just in a nutshell linkerity is really committed to open governance it's built to be incredibly lightweight security first and it's written in go and rust so today i'm going to give a little bit of an overview about what a service mesh is and then we're going to dive right into how to install linker d and to get some value from it using the dashboard and the cli now in kubernetes you'll typically have a number of different pods which are all communicating with each other to accomplish some purpose and they may be communicating over http or some other protocol so you can see in this example we've got three pods a b and c and they're all talking to each other now when you install service mesh what you're doing is you're adding a proxy container to each one of those pods so a here gets a proxy b gets a proxy and c gets a proxy and those are called side cars and what those do is they'll intercept all of the traffic going in and out of those pods and manage it so now instead of a and b talking to each other directly they now talk through their sidecar proxy containers and all these proxies taken together make up what we call the data plane now different service meshes have different proxy implementations that they use for this for example istio and kuma use envoy as their proxy linkery on the other hand has a purpose-built proxy just that's just called the linkery proxy and that's what makes linker d so fast and so lightweight compared to the alternatives now in addition to having this set of proxies that manages all the traffic going in and out of these pods there's another component called the control plane and the control plane sits outside of all of that and manages those proxies it manages their configuration it manages their cryptographic identity so it pushes down certs to them and it also collects telemetry data from them things like metrics and traces and these two parts taken together make up the service mesh the data plane which is made up of these proxies and the control plane which manages those proxies so hopefully that gives you a pretty good idea at a high level of what the service mesh is but it doesn't really tell you why you would want that or what value that it gives and so having these proxies everywhere gives a lot of benefits that mostly fall into three distinct categories observability security and reliability on the observability side since you have these proxies which are uh intercepting all of the traffic going in and out of your pods they can collect a lot of really interesting traffic metrics about uh those requests so you can calculate things like request rate success rate and latency and you can aggregate this data across many different dimensions so you can look at you know what is the success rate for traffic from pod a to pod b or what is the latency for 503s sent to podc and you can ask a lot of really interesting questions of this data and this is all sent to prometheus so it's collected in a time series way so you can see these trends over time because these proxies are also seeing all the traffic that's flowing through them you can do request inspection as well which means you can ask a proxy to tell you about the request it's seeing which is a really useful debugging tool on the security side the control plane gives a cryptographic identity to each one of the proxies which means that you get mutual tls between all of your pods on by default and totally transparent to the application so the application doesn't need to opt into it doesn't need to manage certificates it's all handled by the proxies and finally there's a whole bunch of reliability features you get by having these proxies there because these proxies are aware of request latency they can do latency aware load balancing they can notice that certain replicas may be faster or slower than others and they can shift traffic so that more of the traffic is going to the faster replicas and back away from the slower ones link rd can also be configured to retry if it notices that requests have failed or to add timeouts if requests are taking too long okay so let's see it in action if you'd like to follow along all the instructions for everything i'm about to do are at linker dot io slash getting started [Music] so the first thing we need to do is install the linkerity cli and we can do that by curling an install script run dot linker d dot io install i'm piping that to sh if you don't want to do that you can also download the binary from the releases page uh so we can see that lingerie 2.9 was just installed there's some instructions here for adding it to your path but i've already done that and if we run linkedin version we can see that we have a client version of 2.9 that's the cli we just installed but there's no server version because we haven't installed this on our cluster yet now before we install this on our cluster we want to make sure that there's not going to be any problems down the road so what we can do is we can run check dash dash pre and this will do a pre-flight check and make sure that our cluster has everything that it needs in order to install linker d on it so it'll check for example the minimum kubernetes version and that we have all of the applicable permissions that we need in order to install so this looks good we're ready to go we can run linker to install and what this command does i'll just run it now you'll see that it spits out a whole bunch of yaml manifests for the linkedin control plane and so in order to install link rd all we have to do is pipe those manifests into coop control apply and so you can see now all of those resources being created in our cluster and right away even while those resources are being created and and coming up we can immediately run linkery check and this time we're not using the dash preflag we're just doing a regular check which is going to go through a checklist and make sure that linkerity is installed correctly that all of its components are up and healthy and that there's no problems with the installation and so you can see here that this one container is not ready yet it's still being created and it's going to wait here for that container to be created and to become ready and it'll let us know once the installation is complete great so we see that everything's been installed correctly and there's no problems so liquidity is now installed and we're ready to go so the first thing i want to do is run the linker dashboard command and what this will do is it will open up the linkedin dashboard in the local browser window and you can see already there's a whole bunch of really interesting data here this is a list of all the namespaces in our cluster and you can see the linkerity namespace here which is where the control plane is running and you can see already we've got some interesting metrics here we've got success rate we've got requests per second and we've got some latency data about the linkedin control plane itself and we're going to explore this dashboard a lot more in a moment but i just wanted to take a quick look at it so next we're going to install a demo app to uh to see how this works uh so we have one called emojivoto you can download it from run.linkerd.io emoji photo.yaml and so we're just going to curl that and pipe it to control apply [Music] uh so we've created this new demo app it's in the emojivoto namespace and we can see what that demo app looks like by port forwarding so we can do coop control port dash n emoji photo port forward service web service and we can port forward port 80 to port 8080. and then we can look at that in our browser so this is a simple emoji voting application we can click on different emoji to vote on them and then we can you know pick another one and we can take a look at the leaderboard where we can see what all the different votes have been it comes with a bot that votes randomly so you can see there's a lot of votes that have already accumulated here from that bot it's just a very simple demo application if we go back over to the linkerity dashboard we can see that there's the emojivoda namespace here now in the dashboard but you'll notice that there's zero of four meshed pods here and what that means is that the emoji photo namespace has four pods but none of them have sidecar proxies which means we're not able to collect any metrics for those pods we're not able to do mtls or do any of the any interesting things that the service mesh lets you do so the next step is going to be to add those proxies to those pods so in order to add sidecar proxies to each of those emoji photo pods all we have to do is get those manifest again so d dot io slash emoji photo and we're going to pipe that through a linkery command called linker d inject and the linkery inject command just does exactly what we want it's going to add those sidecar proxy containers to all of the pods in the emoji photo manifest and then we can take the results of that and put it right back into coop control so we can see here that it's told us that these four deployments have been injected if we look back at the dashboard now we can see that there are four or four mesh pods now and so we should see metrics come in and there they are we see success rate we see requests per second latent and latency data for the emoji emoji photo name space and we can even drill in further here and we get a little map showing which deployments are calling which other deployments here we have vote the vote bot calling web and web calls these two others and we can see stats broken down per deployment so request rate success rate and latency we can see individual pods and so on and so forth and if we even drill further down and look at an individual deployment like web we can see exactly which other deployments it talks to and the success rate on each of those edges so we see that you know when web sends requests to emoji the success rate is 100 but on the other hand when web talks to voting uh the success rate is quite a bit lower so that indicates that there's some problem there so this is a great debugging tool for understanding where your traffic's going where it's successful where it's not and where latency happens we also have a table of live requests so we can see exactly which requests the web deployment is getting and sending as well as you know whether those requests are successful and and how long they take so we can see right away that there's a zero percent success rate on this one path here vote donut as that immediately lets us kind of zero in on where the problems in the application might be all this data from the dashboard is also available on the cli for example you can write in the command linker d n emoji photo stat deploy and this will give you stats for all the deployments in the emoji photo name space so here we see that same information we saw from the dashboard in the cli so i hope that was helpful i highly encourage you to give it a try yourself as you just saw it's very easy to to try and get started with if you have any questions please head on over to our slack channel slack.linkerd.io or find us on github or twitter we'd love to have you participate in the project thank you very much

Channel: Buoyant

Views: 1,504

Rating: 5 out of 5

Keywords:

Id: xo9Tq2UNKfM

Length: 13min 18sec (798 seconds)

Published: Mon Feb 08 2021