Istio an introduction

Foreword

In the projects that we use Kubernetes, as the number of Services increased we started to lose observability and control. So I explored Istio, and before just jumping into it and having everything in production, I updated my sample application from the series Kubernetes and everything else  and tested Istio out, and then got it to production. Preface: Istio is JUST amazing!

In this series “Istio around everything else”, we will reuse the microservice application “Sentiment Analysis” to explore the Istio’s features, and it even mimics the real-world scenario we went through after adopting Kubernetes.

Introduction to Istio

When building microservice based application, a myriad of complexities arises, we need Service Discovery, Load balancing, Application resilience, Optimization of hardware utilization to name just a few. And as the application grows it gets progressively worse. Kubernetes providing a solution to these complexities was immediately well received and reached a wide adoption in all cloud computing service providers.

This simplification of Orchestrating Microservices enables teams to easily get to ten and then even more services, which causes a different set of problems, for example:

• Traffic management: Timeouts, retries, canary rollouts,
• Security: End-user Authentication and Authorization,
• Observability: Tracing, monitoring, and logging.

All of these can be solved and implemented in the application layer. But that’s an additional effort for the developer and a strain in the company’s resources. Resources that can and should be used to deliver business value to the customers. Istio take it away!

Istio is an Open Source project (developed in partnership between teams from Google, IBM, and Lyft) that solves all the above-mentioned problems, it is battle proven, as similar solutions have been used by these companies internally.

In this article we will:

• Be introduced to Istio,
• Install Istio in a Kubernetes managed  cluster,
• Run a microservice application.
• Implement and use routing rules, retries, failovers, and fault injection.
• Authenticate and Authorize end users for all services.

Note: This article assumes that you have a working knowledge of Kubernetes. If it’s not the case I recommend you to read my introduction to Kubernetes, and then continue with this article.

Let’s move on!

The Idea of Istio

Istio provides an ingenious solution to all the above-mentioned requirements. The gist of Istio is to be completely separated from the services and act only by intercepting all network communication. And it turns out that by intercepting network communication it can implement:

• Fault Tolerance – Using response status codes know when a request failed and retry.
• Canary Rollouts – Forward only the specified percentage of requests to a service.
• Monitoring and Metrics – The time it took for a service to respond.
• Tracing and Observability – It adds special headers in every request and traces them in the cluster.
• Security – Extracts the JWT Token and Authenticates and Authorizes users.

This must have got you intrigued by now! Let’s get started with the Technical details!

Istio’s Architecture

Istio needs to intercept all the network communication to and from every service and apply a set of rules. This is achieved and logically split into two planes: The Data Plane and The Control Plane.

The Data Plane

In Kubernetes the network traffic between pods is managed using Services as shown in Figure 1.

But to intercept all the network communication Istio injects an intelligent Envoy proxy as a sidecar in every pod. The injected proxies represent the data plane. Using those proxies Istio easily can achieve our requirements, for an example let’s check out the retrying and Circuit breaking functionalities.

To summarize:

1. Envoy sends a request to the first instance of service B and it fails.
2. The Envoy Sidecar retries. (1)
3. Returns a failed request to the calling proxy.
4. Which opens the Circuit Breaker and calls the next Service on subsequent requests. (2)

This means that you don’t have to use another Retry library, you don’t have to develop your own implementation of Circuit Breaking and Service Discovery in Programming Language X, Y or Z. All of those and more are provided out of the box by Istio and NO code changes are required.

Great! Now, you want to join the voyage, but you still have some doubts, some open questions. Is this a One-Size-Fits-All Solution, which you are suspicious about, as it always ends up being One-Size-Fits None solution!

You finally mutter the question: Is this configurable?

Welcome to the cruise and let’s get introduced to the Control Plane.

The Control Plane

Is composed of three components: The Pilot, the Mixer, and the Citadel that in combination configure Envoys to route traffic, enforce policies and collect telemetry data. Visually presented in the image below.

The envoys are configurable using Kubernetes Custom Resource Definitions provided by Istio and specialized for this purpose. Which means that for you it’s just another Kubernetes Resource with a familiar syntax. The same way you defined a service and applied it using the command kubectl apply the same we will do with Istio resources. And the control plane will take over applying the configuration to the envoys.

A deeper dive into the internals of the Control Plane is out of the scope of this article and would replicate the official documentation, a redundancy I would like to refrain from.

With a good overview and great enthusiasm let’s put this into practice in the next article.