Istio – Service Mesh for Kubernetes and Cloud-native Systems

Microservices, especially cloud-native, container-based microservices have radically changed how applications are built and deployed. This shift has been driven by a number of positives that container-based microservices provide (eg. speed, portability, …). However, traditional monitoring tools don’t’ work with these new systems. The service mesh concept (and in particular the Isto implementation of a service mesh) bring an ability to regain system visibility, improve authorization and security, manage routing, collect metrics and more. Click on the video above to watch the episode and get all the details.

Show Notes
Mentioned Projects

Istio Project – https://istio.io/
Istio Mixer – https://istio.io/docs/concepts/policies-and-telemetry/overview/
Envoy Proxy – https://www.envoyproxy.io/
Kubernetes – https://kubernetes.io/

 

Kumulus Tech’s Istio Course on Udemy
Use this link to get our Introduction to Istio course for only $9.99 on Udemy. Learn how to install and use service mesh to simplify microservice application management.

 

 

 

Edited Transcript
For those of you that prefer reading, we’ve run the transcript past our editors for a smoother reading experience, below.

If you’ve been working in the microservices space at all over the past couple of years, the concept of a service mesh is probably not new to you. For the rest of us, it’s sort of born out of some of the needs that the microservices space has is driving us to, specifically some needs around visibility, traffic routing, authentication, security, and metrics collection. The problem stems from the fact that within the cloud space and specifically the microservices space, as we move our services into containers, which is a very common model, we lose some of the instrumentation that we were able to use to gain visibility into a classic monolithic application.

For example in a monolithic application, the internal services within the application would communicate through internal messaging and those message communications paradigms would often be managed through interaction within the application itself. You could basically monitor memory spaces for messages being passed between different resources. When we went to microservices suddenly that was no longer easily accomplished. When we went to containers we suddenly lost the ability to just add some additional services into our base virtual machine to gather that information.

Well, this is kind of where the service mesh concept comes into play. Let’s put something in between all of our microservices and then capture all the traffic that goes between them. This creates a bit of a problem. Especially in a distributed system where I suddenly have to figure out how do I manage all of those interacting little components that are actually monitoring and metering my services.

Well along comes Kubernetes and suddenly the game changes pretty dramatically. It’s not that we couldn’t implement those service functions but now we have a way of just injecting that functionality directly next to the individual service containers themselves. This is done through a technique called service injection or effectively adding another container into our environment. Then on top of that, since we’re usually looking at network traffic, we are again talking about microservices being the principal model for this communication, we can actually start tying the services within the pod itself, we’re actually redirecting the local traffic now.

By doing that we fix some of the problems that microservices have. Specifically the ability to monitor communications between resources. That’s one of the things that Google actually brought into the Istio space, the ability to sort of capture this data effectively extending the concept of the container engine, the cAdvisor engine, for the container runtime that people are using into the application space. Basically then being able to look at the application data stream and then centralizing that metrics data and potentially the monitoring of communications.

Once I’ve done that- once I’ve injected myself at that level- I’m looking at packets flowing back and forth I could do some really interesting things. I can add authentication and so this is one of the things that IBM contributed to the mix. On top of routing was the ability to sort of secure the connections between these different services. Routing is another thing I have control over; where any frame gets sent rather than just saying well I’m gonna always forward to a load balancer that’s going to distribute to n number of resources that load balancer becomes part of my communication. Now I can actually decide which target am I actually going to send these frames to- very powerful.

And since I have this level of control I can even do some interesting things like injecting fault. So when I start distributing my application to these microservices, it gets harder to figure out how my application is going to behave if something breaks. How do I actually force failures in any one particular microservice to check how my application remains resilient in the face of that kind of a failure? Well, I can now start injecting that as a part of either my QA or development process all the way up to even including the injection at the production level. I can continue to create faults to make sure that my system continues to behave properly and if not I can actually alert against that.

So these are some of the interaction that the microservices mesh – service mesh – space actually provides and Istio helps provide this through an injectable proxy. So basically, I’m going to take a proxy engine, in this case, the Istio space is using the Envoy proxy. Envoy was initially developed by Lyft and is now an open-source project a part of the CNCF. Actually, Isto is also part of the CNCF and for those of you that haven’t heard of that, it is the Cloud Native Computing Foundation which is a sub-sub foundation within the Linux Foundation space.

So this service functionality is really what Istio is providing. Istio provides this Envoy proxy capability that gets injected with each container in the Kubernetes space or gets inserted into the forwarding path if you want to use a non-Kubernetes model. Either with containers like Docker or even virtual machines; you could actually add this proxy as a process within a virtual machine and inject traffic through that way. So we can use microservices… we can use mega services, monolithic services as well and we can use this service mesh to tie them all together.

But with Istio specifically we get authentication, so because all traffic is going through these Envoy proxies, I can actually authenticate and end communication. I can monitor and meter traffic to understand what’s going on with latency; see what kind of throughput I’m getting on a path by path basis. I can send that to a central tracing service open tracing like- the Jaeger project is one of the fairly common ones that gets used there. I can also start looking at routing like I said. I can redirect traffic and within the Kubernetes space, for example, I can just use labels to actually define where my endpoints are and what services are supposed to go where.

That’s all incredibly powerful but now I also have central control. This is sort of the last thing that this Istio brings- central certificate control. That’s important for the TLS authentication. Central metrics gathering with a tool called Mixer that actually gathers all the metrics data together and then central configuration control and this is actually why Envoy was picked as a proxy. Because with Envoy, I now have a central controller that can distribute the configuration to all of the distributed proxies that are out there within that mesh. Envoy does this in a very efficient fashion because it doesn’t actually require a restart on reconfiguration; it can do a hot reconfiguration- a pretty powerful function!

So service mesh is an important component of the microservices space. It really changes how microservices are stitched together, how they’re metered/monitored and really even looking at improving the performance and the resiliency of those services by injecting fault all from a centralized control plane with security. So lots of things all in that one big bundle but that’s really the Istio capabilities. More generally, it’s part of that greater service mesh space within the cloud-native engine that is really taking over how applications are built these days.