Hoot [Episode 1]: Istio

March 2, 2020

Hoot is a live video series hosted roughly every two weeks where engineers unbox various cloud-native technologies, dig into features of new releases and answer your questions live. To kick off the launch of Hoot, we start with a series on Get to Know Service Mesh as service mesh is the latest buzzword in our ecosystem. The questions come up often include: What is it? Why do I need it? and Which one should I choose?

Get to Know Service Mesh

To help explain service mesh, this series will explore the different service meshes, explain the architectural approach, unique capabilities, contrast them and provide guidance on how to navigate the landscape in choosing a mesh(es) for your applications.

Covered in this series:

Episode 1: Get to Know Istio (emphasis on v1.5)

Speaker: Christian Posta, Global Field CTO


All right.  Good morning, good evening – wherever you might be joining us. My name is Christian Posta and we’re going to kick off a series of various episodes where we dive into different cloud native technologies. I’m calling it Hoot.  ‘Hoot’ is the sound that an owl makes. The owl is the mascot of the company that I work for. I don’t think it has an acronym yet, but, tweet us and maybe suggest some acronyms. Maybe something like “Hacking on Open Technologies” or something. I don’t know. We don’t have an acronym for it, it’s just the name.  We’re going to try to do this every week or so to the extent that we can. We’re going to start off with a series within a series. So, we’re going to start off with looking at different service mesh technologies.


Today I’ll cover Istio and some of the usability – the improved usability and much welcomed usability improvements for Istio – and then in the next week or so cover Linkerd and will cover Consul, and from there we’re open to suggestions from the community. So, if you reach out, mention it in the chat or tweet us,  then we’ll try to get that on the list to look at a handful of different service mesh technologies and then we’ll also look at them, and then we’ll do an episode on comparing them. I know a lot of folks that we talked to in the enterprises are looking at different service mesh technologies and trying to decide what parameters to evaluate with, and which service mesh might be best for their situation. So, in one of the episodes, we’ll take a look at comparing and contrasting, and maybe coming up with a criteria for determining which service mesh is best for you.  So, again, my name is Christian. I’m going to kick off the first episode here. The subsequent episodes will be hosted by other folks on our team, so you’ll get the chance to meet them. And if there’s any interest in guest hosting or coming on and showing us some of the technology that you found to be interesting in this cloud native ecosystem then definitely reach out and let us know. We’re very open to that. So, let’s kick this off. 



We’re going to be looking at Istio. The latest release of Istio is 1.4, which came out, I believe, in about November.  Istio has been around now for a couple years and it is a service mesh. So, if you’re unfamiliar with service mesh, that’s one term that you should probably go do a little research on.  I’m not saying you’re going to find crystal clear definitions and meaning behind it. But the service mesh is that ecosystem, those bits of technology, that are intended to help solve some of the difficult challenges of securing and observing and controlling ultimately) the communication between services in a cloud environment deployed the cloud infrastructure; things like Kubernetes.  You can think of Kubernetes as a great deployment target for containerized applications. And those applications might interact with services running on a potentially serverless environment or in VMs or ephemeral. You might find that your existing either off-the-shelf applications or existing investments in applications – all of these services need to interact, talk with and communicate with any of the new microservice style applications you might be writing.  And with that comes the challenges of networking security. When you have more of these different services talking to each other and they’re ephemeral, they are coming and going, you have the challenges of identifying those services, securing them, and writing policy about which services are allowed to talk with which.  


Istio is an open source project that is aiming to solve the problem of that connectivity and then controlling it. If we come over here and look at the istio.io website, we see that those are some of the main features that it has.   One thing I do want to say is that Istio, although released back in July 2018, was not production ready by any means when released. The 1.0 label, I think, was a way to get people to come look at it and kick the tires on it. The idea is sound. How its implemented, I think, is just as sound. But, of course it was a .0 technology and it’s continuing to improve.  Once we get to see 1.3, 1.4, we see a lot of improvements around the stability and usability of the technology. 


So now Istio (just a little bit of a battle a background) is a control plane that drives the Envoy proxies that are deployed with your application. So the general architecture of the service mesh is some kind of agent or proxy that gets deployed along with your application and runs outside of the application. And then some piece of configuration is used to drive the control plane. So, you define what policies you want to see, what security you want to see, and then you send that to the control plane and then the control plane will disseminate those configurations to the data plane, which Envoy is running  So Istio is the control plane with an API for people to define those policies. In my opinion, one of the big hurdles was (in some of the earlier versions of Istio) was getting Istio stood up or even just to kick the tires, getting it installed. Some of the early versions of Istio had a lot of different moving components and pieces that interacted with each other in a not very obvious way, and gave the impression (and rightfully so) that it’s a complex piece of technology. 


So, in 1.4 what I want to do is take a look at a potential flow for installing Istio and exploring the various ways that it can be installed, and moving on to some of the things that are happening in the Istio 1.5 release.  So, just again, this year 1.4 was released in November, so this is out right now. The things that I’m going to show you are available. And then toward the end I’ll show you some of the things that are happening in the in the community.  Still, 1.5 is targeted to be released in the middle of February so these are things that I’ll show you. They’re not available yet but they will be coming and something to keep in the back of your mind.  


The first thing that we’re going to do is take a look at the Istio docs for getting started, because I’ve been involved with the Istio community since 2017 and I’ve seen big changes and improvements in the Getting-Started experience and the usability of it. So, first thing I’m going to do is click on Setup and click on Getting Started. That’s where most new users to Istio would navigate. The beginning start experience depends on Kubernetes, so  you’ll need a Kubernetes cluster. You’ll want to download the release from GitHub. You can follow any of these links to do that. But the interesting part that I’ve seen is the new manifest commands. So, when you download Istio, it comes with the istioctl binary, which in the past that was fairly simplistic.  In the past you could use that to inject the sidecar next to your Kubernetes  deployment. But now the istioctl command has become more of an entry way to the Istio user experience. We’re going to take a look at the istioctl , CLI and then some of the commands that have been added to simplify the experience of installing and using Istio. 


So first thing we’ll look at is istioctl .  We see there are more commands than just Kubernetes.  We see a few things for doing debugging, for verifying installations and, of course, the manifest command that we’re going to take a look at and deal with right now. Actually, I just want to make sure real quick – all right.  I have a version of Istio running already. I should have cleaned this up. One second. So the manifest command, what that does is allow us to deploy Istio without messing around with pre-populated resource files or messing around with Helm.  We can get full control over customizing our installation just by using this command. And you’ll notice that there are other helpful commands here to verify install, which will allow us to determine whether our cluster and the environment that we’re targeting has the minimum requirements, prerequisites, to be able to install Istio. And then once we install it, we can go back and verify that, yes, actually this was installed correctly or, no, right?  That’s more important when things are not installed correctly, you want to know at the end instead of just going ahead and finding out later. So, we deleted our existing installation. 



The first thing we’re going to do is – let’s look at that command.  We have istioctl manifest apply. So, there’s a second command here and we’re going to set a parameter: set profile equals demo.  So, this implies that there’s some kind of profile mechanism or some way of targeting or picking specific pre-curated Istio packaging.  If we don’t apply that, then we would see the default deployment here. Let’s just take a look at istioctl manifest. We can see the apply command that we saw on the top. We also see a couple of other ones: generate, migrate, versions, and diff, of course.  With the generate command what we would expect is that if we picked a profile, we customize it the way we want – and I’ll show you some of the detail in a second – and then we can just generate the Kubernetes resources directly and kube-apply that. So again, we don’t have to mess around with Helm.  If you’re using the older Helm, you know, Tiller and all that other stuff. We can, by just using the command line that comes out of the box, generate the kube resources that we would need to install Istio. Now, because the docs in the parameters show that we can pass in a profile, let’s take a look at what that’s all about.  If we come back here to the istioctl comand, we see that there is a profile command. Let’s take a look at that. And if we look at the profile command, we can see that we can either list down or diff the various profiles that are available to us that come out of the box.  


Let’s list the profiles. Demo is the one that we saw in the documentation. But we see that we have a couple of other ones: we have a default xDS for using the xDS capabilities for distributed secrets; minimal, for setting up a remote installation.  I’m a little bit curious about what is in the minimal profile. Before we do any installation, though, we do want to take a look at some of the helper commands for validating and sanity checking our environment before we get going. So, what we do is to ctl verify install.  This will go through and take a look at our key cluster and make sure minimum Kubernetes requirements that’s not already set up. And it can take sidecar injecting, webhooks, and so forth.  


So, everything looks good on that.  Now if we wanted to manifest apply set profile minimal, we want to take a look at what this minimal profile looks like.  Let’s just deploy Istio like that. And we can see that under the covers, it’s using a few different mechanisms to shrink down the deployment of Istio. That is one of the things that initially, when people get started, they see the deploy and find – that it had 10 different components. 


Let’s take a look at what it deployed and keep a watch on that and make sure it’s ready. It should be running soon, hopefully.  But the first thing we noticed is that there aren’t 10 different components. This is the most minimal deployment of Istio that you can get and all that is Istio Pilot.  And if you’re not familiar with Pilot, it is the component that serves Envoy’s configuration so it can grab the API documents that you create to drive the mesh. Things like virtual services and destination move, and so on. Take those documents and basically just translate them into Envoy configurations that the data plane can then understand. So, what this means is that it’s a fairly simple – super simple – system.  Simple capabilities. All it is, is an Envoy xDS server. And we can do quite a bit of the Istio functionality using just this deployment.


Now, it doesn’t have any of the security functionality. It doesn’t do automatic sidecar injection, telemetry and other components are not deployed here.  But you can see that if you’re just going to get started, if you just want to try out traffic shifting and some of the capabilities that Istio has for doing things like circuit breaking and retries and so on, you don’t really need much. You just need this minimal profile.  So let’s go ahead and delete that. We’re going to come back and deploy the full demo because I want to show a couple of other pieces here. Give that a second to delete. The next thing that we’re going to do is we’re actually going to run this command with profile equals demo.


One thing that might pop into your head is, “what are the various values that we can configure here?” Right?  So, we can see dash dash set and we’re specifying profile equal demo, which will run. But what other values can we use here and where can we find that?  If you click on Reference and click on Configuration, we get a lot more detail about how the istioctl command is deriving the configuration and what configuration we have to customize.  I’ll let you read through those but the important CRD that we’re interested in here is still control plane spec. This is the CRD that gets created when it is used to drive the installation of Istio when we’re using the command line. When we come down here, we should see the profile parameter.  We also have a few different sections of the CRD where we can configure various parts of the control plane. And then lastly, if we want very fine-grained control over those values, we can override and set the values that we would find in the Helm templates using the values parameter here. So, you know, that’s an offline exercise for you all.


But we can see that the istioctl manifest command is very customizable and you can tailor the installation of Istio very fine grain. But right now, we’re just going to stick with some of the out of the box profiles.  Copy that command exactly and we’ll give that a second to install. Now, the demo profile is going to install more than what we just saw a second ago with the minimal install, so it will install the rest of the control plane. It will install some of the supporting components like Grafana or telemetry, like Prometheus for capturing the telemetry and so forth.


So, if we do this…we can see as things start to stabilize and that we have the ingress gateway deploy. We have an egress. We have a handful of other parts of the control plane here.  And that would then allow us to demo the book info app which I’ll show in a little bit. We won’t go into that right now. But what I do want to show is that in the past it’s been a little bit more cumbersome than necessary to try to find all the right UI’s and dashboards that Istio has.  The Istio command has a dashboard subcommand that we can use to simplify that. 


Click on that.  We can pop up an Envoy, a web UI quickly.  We can get to Grafana, Kiali and some of these other UI’s. With just a simple command sort of trying to figure out exactly what ports they are listing on from version to version. Maybe the ports changed and then started a port forwarding session, and so on. So, if we just forget and want to take a look at Grafana, we can just do this and what we should see is Grafana load up here. A little bit better formatting here.  We don’t have any apps to play right now, but you can see that this way of being able to get to the dashboard is a lot… let me take a look here…. We can see the Kiali dashboard here which is more of an overview of the various services that are running in the data plane and the various control plane components. The dashboard subcommand is a very welcomed addition to the user experience, especially when you’re starting to just kick the tires. Now, that’s all good but I encourage you to go through and take a closer look at some of these new commands.


But what I want to show next is, if we go here and take a look at the various components that make up the controller. We have the Pilot, which we discussed was deployed in the minimal installation. Then we have a few other things like galley and citadel, and the sidecar injector and telemetry.  So, these various control plane components kind of work together to do things like serve the config to ongoing, to discover other sources of configuration – so, maybe things like console or maybe a different environment – to maybe automatically inject sidecars and bootstrap Envoy when the data plane starts to come up. Things like handling requests for certificate signing, like serving certificates, mounting them, rotating them. So these are various functions of the control plane that in Istio have historically been built as individual services so they can be deployed independently, scaled independently and developed independently.


What I’m going to show next is using the plane deployment model that’s coming in Istio 1.5. Now, I don’t want to spook anyone.  This change is intended as instruments benefits and intended to help, but it’s not something that’s going to be Kind of switched on and often, and just magically there, right? So there’s going to be an upgrade path to get to it and it will gradually be phased in.  So, it will be available in 1.5 and you can take a look at it. I’ll show you exactly what I’m talking about in a second. But don’t be worried that, oh my goodness, everything you learned about Istio will now be obsolete because that won’t be the case, especially for me since I’m writing a book on Istio.  I am going have to revise some of these chapters to accommodate these changes, but these changes are good.


The first thing that we want to do is to use a Snapshot of Istio 1.5. This is really a very alpha snapshot of Istio 1.5.  So some of the polish will be on the end product, but it will be in the middle of February when it’s shift is not there. But that’s okay. The point is that what I’m going to show here is still valid. We saw in Istio 1.4 and all the previous versions that the Istio control plane is made up of a lot of component -a lot of components that work together and coordinate together to be able to serve the responsibility of the Istio control plane. And you see in 1.5. that there will be an option to condense all of that down into a single binary, a single deployment. So think of the responsibilities of the Citadel, which are: certificate signing, request signing having and deployment of the certificate, rotating the certificate, expiring, and so forth – that will now be merged into this Istiod binary.  Things like the webhook injector. We don’t need a separate webhook injector, we’re going to combine that with this Istiod. And galley for doing if the API validation and configuration interchange with other environments – that will be pulled into his Istiod.


Now one of the main reasons for doing that is simplifying operations of Istio. For those of us that have been around the user community, we hear loud and clear that the users of Istio have found it to be complex and complicated at times. This is an effort to significantly reduce that reality – that the more that things are combined operationally, it will be easier to deal with.  Because what we’ve we found, what we’ve seen, is that the folks who are taking, using and running Istio are typically a single team or sometimes a single person, right? So there’s not much advantage to deploying as a sprawling set of microservices when as a single team operating the Istio installation. So if we can merge things down into a single binary, it’ll be easier to operate, it will be easier to upgrade, it’ll be easier to configure at runtime and ultimately to maybe run multiple of these control planes and multi-tenant environments, and so on. So Istiod is a big step forward, I believe, in simplifying some of the unnecessary complexity that we have in Istio today. And let me show you what that might look like.


The first thing that we’re going to do is make sure that we are on Istio 1.5, and it looks like we are. We’re using a snapshot that was built yesterday. So if this demo goes sideways, that’s not my problem. We’re still waiting for some stable releases here. So, the first thing that we’re going to do is install Istio 1.5, and we’re going to trim those extra controlling components and we’re going to use the Istio deployment of the controller. So, first thing, this going to be very difficult to type so let me just copy and paste this. And, again, this is not the final product.  There are quite a few values that we have to set here and we have to tune and trim, and so on. But like I said, this is a snapshot of a very early release of this, so a lot of us will get ironed out. But a couple of values you can see that we’re setting here is what we’re going to use. So, we’re getting rid of mixer. If you’ve heard this in the past the mixer component… First of all, it was split into telemetry and policy. And little by little, the capabilities of those two components in the control plane have been either merged into Envoy or into the data plane itself, or leveraging native capabilities so that we don’t need to separate components for it. So we’re going to enable v2 of this implementation. We’re going to turn off a bunch of different components. And then lastly, we are going to use a newer version of the installation package that you see us cover just to be able to do this. Sos let’s see what that does. We use the Istio manifest generate command. We can see that it spits out a bunch of YAML for us. Now what we’re just going to do is  


kubectl apply and now this one with version 1.5. and, hopefully with just the Istiod or just this single binary deployed. And we see that completed. If we take a look at the pods in the system… oops, it’s saying “error”. We´ll give that a second… But what’s immediately noticeable is that here’s only two pods. There are only two pods deployed here. Everything’s running successfully now. Excellent. So there are only two pods deployed here. One is the ingress gateway and one is the pilot. Now Istiod is a representation of the single daemon that we’re going to use for Istio. Right now things have been renamed. Things are still called “Pilot” and the functionality of the rest of the control plane has been merged into Pilot. So the name will stay the same, at least for right now for the 1.5 release. But we can see there’s only one of them running, which we saw in the minimal deployment or the minimal profile in Istio 1.4 earlier.


So, we’re able to significantly reduce the complexity of the deployment. Well, whereas in Istio 1.4 the minimal profile, we had approximately about the same number of moving pieces. But we a had reduced feature set as well because there were other components deployed as well.  In this case we have a reduced number of moving pieces and complexity, but we haven’t reduced the feature set. We still see things like the automatic sidecar injection, or we still get the security and mutual TLS. And, of course, we get the traffic routing because Pilot was already doing that.


Let’s take a look at applying… let’s do this with pods. We don’t have any pods running in the default namespace. If we do take a look at the default namespace, we will notice one important thing: that the Istio injection annotation is set.  Now, if we deploy the bookinfo application to the default namespace, we should see those pods automatically get their data plane injected into them even though you see that there’s no webhook running here, right? It was all now embedded inside of a pilot. So if we do…let’s see, if we can do bookinfo delete. So, this will create the bookinfo deployment and services – so this is the standard Istio bookinfo demo. And now if we do create po, we should see that, indeed, they are getting their data plane injected. So, Istio is working as expected. Let’s see if we can set up the correct routing so that we can actually hit the gateway. Let’s do ‘find the external IP’ for the ingress gateway.  I need to come here…so copy/paste. Okay. So, whenever you see this after a fresh installation, whether intended or not, this is sometimes related to mutual PLS being sent. Let’s see if that’s the case here. Yes, I think. Let’s see. Yeah, so let’s lets turn that off for a second. These are really early snapshot of things.


Okay, so now we should be able to get to the simple bookstore app. Right, and then from here we can follow the rest of the Istio tutorial on bookinfo, which I won’t do here. But another thing that I do want to show you, and the last thing that I want to show you, is in the command we used to install Istio and Istiod, we enabled V2 and telemetry.  Now, in V2 telemetry we don’t need the mixture or the telemetry and policy parts of this Istio, right? And we can see that none of those are right. The way that some of the telemetry components were implemented was by using WebAssembly. And building some of the capabilities of extending the Envoy stats, and the list of stats that Envoy keeps by doing that with WebAssembly instead of trying to do that outside of the process in the telemetry component.  So to show you that, let’s first of all take a look at the config that was deployed. Let’s take a look at any one of these. Yes, here. Let’s take a look at the config in the product page pod. So, we do kubectl exec – let’s see if we can do this correctly… Okay, let’s try one more thing. Let’s see… let us try Envoy and then name this… Okay. So, if we come into config dump, we can take a look at the full configuration for the Envoy proxy that’s running the data plane inside the product page pod. We see the full configuration.  This is what it ends up serving. Let’s look for one of the assembly configurations. And we see that one for HTTP. But then we also see the configuration for the stats. So, what config is doing is it’s loading up a module that handles creating the additional statistics that we want to keep for Istio, and those stats are going to be prefixed with Istio underscore something, something, something, which isn’t in the default or base envoy configuration. So, let’s see if we can come back here and take a look at the stats for Prometheus, we should – if this works correctly – we should…yep. So, we start to see the Istio underscore requests hold.  These are the different statistics that were originally generated by a mixer out of process of ongoing. Now through to this WebAssembly extension and without any other process manipulations, they’re being generated inside the proxy itself.


So, in this quick little overview from the coming Istio 1.5, we showed that the control plane and the complexity of the control plane has been improved and slimmed down.  The components that were running as complementary components to each other – collaborating components with each other – they’ve been merged into a single binary to the extent that they can and so the stuff has been pushed actually into the data plane itself. The Istio 1.5 release will be coming. like I said, in mid-February, sometime around then and if you have any questions or you’re interested in getting started with Istio and taking a look at it from a more simplified perspective, then definitely go to Istio.io.  The community is very active. I think I saw that it was of the top five fastest growing projects on GitHub. Come down here and take a look at the Istio Community tab and get involved.


Feedback on Istio 1.4 and 1.5 would be appreciated.  Feedback on this initial episode of a hoot is also appreciated. Let me see, are there …no, I don’t see any follow-ups here.


So stay tuned to the next episode, which will be in approximately one week, and  I look forward to getting to contribute and share with the community the stuff that we’re doing at Solo.io and even outside of Solo.io, and thanks for joining.