We are starting a series of posts demonstrating some of the many features of the Istio Service Mesh in combination with Red Hat OpenShift and Kubernetes.
Part one today:
- Let's explain the concept of Kubernetes sidecar containers and formulate the leitmotif of this series of posts: "you don't need to change anything in your code".
- Let's imagine the fundamental thing of Istio - routing rules. All other Istio features are built on them, since it is the rules that allow you to direct traffic to microservices using YAML files external to the service code. We also consider the Canary Deployment deployment scheme. New Year's Bonus - 10 Interactive Istio Lessons
Part two, coming out soon, will tell you:
- How Istio implements Pool Ejection in conjunction with Circuit Breaker and demonstrates how Istio allows you to remove an idle or poorly performing pod from the balance scheme.
- We will also look at the Circuit Breaker topic from the first post on how Istio can be used here. We will show how to route traffic and handle network errors without the slightest change in the service code using YAML configuration files and terminal commands.
Part three:
- A story about tracing and monitoring that is already built in or easily added to Istio. We'll show you how to use tools like Prometheus, Jaeger, and Grafana in conjunction with OpenShift scaling to effortlessly manage your microservice architecture.
- We are moving from monitoring and handling errors to introducing them into the system intentionally. In other words, we learn to do fault injection without changing the source code, which is very important from the point of view of testing - because if you change the code itself for this, then there is a risk of introducing additional errors.
Finally, in the final post on Istio Service Mesh:
- Let's go to the Dark Side. More precisely, we will learn to use the Dark Launch scheme, when the code is deployed and tested directly on production data, but does not affect the operation of the system in any way. This is where Istio's ability to split traffic comes in handy. And the ability to perform testing on live production data without affecting the operation of the combat system in any way is the most convincing way to check.
- Building on Dark Launch, we'll show you how to use the Canary Deployment model to reduce risk and make it easier to deploy new code. Canary Deployment itself is not new, but Istio allows you to implement this scheme with just simple YAML files.
- In conclusion, we will show how to use Istio Egress to give access to services to those who are outside your clusters in order to use the capabilities of Istio when working with the Internet.
So, off we goβ¦
Istio monitoring and management toolkit - everything you need to coordinate microservices in a service mesh .
What is Istio Service Mesh
The service mesh implements for a group of services such functions as traffic monitoring, access control, discovery, security, fault tolerance and other useful things. Istio allows you to do all this without the slightest change in the code of the services themselves. What is the secret of magic? Istio attaches its own proxy to each service in the form of a sidecar container (sidecar is a motorcycle sidecar), after which all traffic to this service goes through the proxy, which, guided by the specified policies, decides how, when and whether this traffic should reach the service at all. Istio also gives you the ability to implement advanced DevOps techniques such as canary deployments, circuit breakers, fault injection, and more.
How Istio works with containers and Kubernetes
The Istio service mesh is a sidecar implementation of everything you need to create and manage microservices: monitoring, tracing, circuit breakers, routing, load balancing, fault injection, retries, timeouts, mirroring, access control, rate limiting, and more. other. And while there are tons of libraries today to implement these features directly in code, with Istio you can get the exact same thing without changing anything in your code.
According to the sidecar model, Istio runs in a Linux container, which is located in one -pod with a controlled service and implements (inject) and extracts (extract) functionality and information according to the given configuration. We emphasize that this is your own configuration, and it lives outside of your code. Therefore, the code becomes much simpler and shorter.
More importantly, the operational component of microservices is in no way connected with the code itself, which means that their operation can be safely transferred to IT specialists. Indeed, why should a developer be responsible for circuit breakers and fault injection? React, yes, but process and create them? If you remove all this from the code, programmers can fully focus on application functionality. And the code itself will become shorter and simpler.
Service grid
Istio, which implements the management functions of microservices outside of their code - this is the concept of the Service Mesh. In other words, it is a coordinated group of one or more binaries that form a grid of network functions.
How Istio works with microservices
This is how sidecar containers work in conjunction with ΠΈ bird's eye view: launch a Minishift instance, create an Istio project (let's call it "istio-system"), install and run all Istio-related components. Then, as you create projects and pods, add configuration information to your deployments and your pods start using Istio. A simplified diagram looks like this:
Now you can change Istio settings to, for example, organize fault injection, support or other features of Istio - and all this without touching the code of the applications themselves. Let's say you want to redirect all web traffic from users of your largest customer (Foo Corporation) to a new version of your site. All you need to do is create an Istio routing rule that looks for @foocorporation.com in the user ID and redirects accordingly. For all other users, nothing will change. In the meantime, you will be quietly testing the new version of the site. And note, for this it is absolutely not necessary to involve developers.
And how much do you have to pay for it?
Not at all. Istio is pretty fast, it's written in and creates a very small overhead. In addition, a possible loss in online productivity is offset by an increase in developer productivity. At least in theory: don't forget that developers' time is valuable. In terms of software costs, Istio is open source software, so it's free to get and use.
Master it yourself
The Red Hat Developer Experience Team has developed an in-depth hands-on by Istio (in English). It runs on Linux, MacOS, and Windows, and the code comes in Java and Node.js flavors.
10 Interactive Istio Lessons
Block 1 - For beginners
Introduction to Istio
30 minutes
We get acquainted with Service Mesh, learn how to install Istio in the Kubernetes OpenShift cluster.
Deploying microservices in Istio
30 minutes
We use Istio to deploy three microservices with Spring Boot and Vert.x.
Block 2 - intermediate level
Monitoring and tracing in Istio
60 minutes
Explore Istio's built-in monitoring tools, custom metrics, and OpenTracing via Prometheus and Grafana.
Simple routing in Istio
60 minutes
Learn how to control routing in Istio using simple rules.
Advanced Routing Rules
60 minutes
We get acquainted with smart routing in Istio, access control, load balancing and rate limiting.
Block 3 - Advanced User
Fault Injection in Istio
60 minutes
We study failure handling scenarios in distributed applications, creating HTTP errors and network delays, and learn how to apply chaos engineering to restore the environment.
Circuit Breaker in Istio
30 minutes
We install Siege for stress testing sites and learn how to ensure backend fault tolerance using retries, circuit breaker and pool ejection.
Egress and Istio
10 minutes
We use Egress routes to create rules for the interaction of internal services with external APIs and services.
Istio and Kiali
15 minutes
Learning how to use Kiali to get a big picture of the service mesh and study the flow of requests and data.
Mutual TLS in Istio
15 minutes
We create Istio Gateway and VirtualService, then study mutual TLS (mTLS) and its settings in detail.
Box 3.1 - Deep Dive: Istio Service Mesh for Microservices
What is the book about:
- What is a service mesh.
- Istio system and its role in microservice architecture.
- Using Istio for the following tasks:
- Fault tolerance;
- Routing;
- Chaos testing;
- Security;
- Collection of telemetry using tracing, metrics and Grafana.
Series of articles on service meshes and Istio
Try it yourself
This series of posts is not intended to provide a deep dive into the world of Istio. We just want to introduce you to the concept itself and maybe inspire you to try Istio for yourself. It's completely free, and Red Hat provides all the tools you need to get started with OpenShift, Kubernetes, Linux containers, and Istio, including: , and other resources on our . Don't delay, get started today!
Istio Routing Rules: Directing Service Requests to the Right Place
ΠΈ are excellent at dealing with routed to the required pods. This is one of the purposes of Kubernetes existence - routing and load balancing. But what if you need more subtle and sophisticated routing? For example, to use two versions of a microservice at the same time. How can Istio Route Rules help here?
Routing rules are the rules that, in fact, specify the choice of route. Regardless of the complexity of the system, the general principle behind these rules remains simple: requests are routed based on certain parameters and HTTP header values.
Let's look at examples:
Kubernetes Default: Trivial "50/50"
In our example, we will show how to use two versions of a microservice in OpenShift at the same time, let's call them v1 and v2. Each version runs in its own Kubernetes pod, and evenly balanced round robin routing works here by default. Each pod receives its share of requests according to the number of its microservice instances, in other words, replicas. Istio allows you to change this balance manually.
Let's say we deployed two versions of our recommendation service, recommendation-v1 and recommendation-v2, on OpenShift.
On fig. Figure 1 shows that when each service is represented in a single instance, requests are evenly interleaved between them: 1-2-1-2-β¦ This is how Kubernetes routing works by default:
Weighted Distribution Between Versions
On fig. Figure 2 shows what happens if you increase the number of v2 service replicas from one to two (this is done with the oc scale --replicas=2 deployment/recommendation-v2 command). As you can see, requests between v1 and v2 are now divided in a one-to-three relationship: 1-2-2-1-2-2-β¦:
Ignore version with Istio
Istio makes it easy to change the distribution of requests in the way we need. For example, send all traffic only to recommendation-v1 with the following Istio yaml file:
Here you need to pay attention to this: pods are selected according to labels. In our example, the label v1 is used. The "weight: 100" parameter means that 100% of the traffic will be routed to all pods of the service that have the v1 label.
Directive distribution between versions (Canary Deployment)
Further, using the weight parameter, you can direct traffic to both pods, ignoring the number of microservice instances running in each of them. For example, here we directively direct 90% of traffic to v1 and 10% to v2:
Separate mobile user routing
In conclusion, we will show how to force the traffic of mobile users to be routed to the v2 service, and all other users to v1. To do this, we use regular expressions to parse the user-agent value in the request header:
Now it's your turn
The regex example for parsing headers should motivate you to explore your own ways of applying Istio's routing rules. Moreover, the possibilities here are very extensive, since the header values ββcan be formed in the source code of applications.
And remember that Ops, not Dev
Everything that we showed in the examples above is done without the slightest change in the source code, well, except for those cases when it is necessary to form special request headers. Istio will be useful both for developers, who, for example, will be able to use it at the testing stage, and for IT system operators, whom it will greatly help in production.
So let's repeat the theme of this series of posts: you don't need to change anything in your code. No need to build new images or run new containers. All this is implemented outside the code.
turn on your imagination
Just imagine the prospects of parsing headlines with regular expressions. Want to redirect your biggest customer to a special version of your ? Easily! Need a separate version for the Chrome browser? No problem! You can route traffic according to almost any of its characteristics.
Try it yourself
Reading about Istio, Kubernetes, and OpenShift is one thing, but why not touch it all yourself? Team prepared a detailed guide (in English) that will help you master these technologies as quickly as possible. The guide is also 100% open source, so it's in the public domain. The file works on macOS, Linux, and Windows, and the source code is available in Java and node.js versions (more languages ββcoming soon). Just open the appropriate git repository in your browser .
In the next post: working out problems beautifully
Today you saw what Istio routing rules can do. Now imagine all the same, but only in relation to error handling. This is exactly what we will cover in the next post.
Source: habr.com