“Danger is my middle name,” Austin Powers, an international man of mystery, used to say. But what is held in high esteem by super agents and intelligence services is not at all suitable for computer services, where boredom is much better than danger.
And Istio, together with OpenShift and Kubernetes, makes deploying microservices truly boring and predictable - and that's great. We'll talk about this and much more in the fourth and final post in the Istio series.
When boredom is right
In our case, boredom occurs only in the final phase, when all that remains is to sit and watch the process. But for this you need to configure everything first, and a lot of interesting things await you here.
When deploying a new version of your software, it is worth considering all options for minimizing risks. Running in parallel is a very powerful and proven way to test, and Istio allows you to use a “secret service” (a hidden version of your microservice) to do this without interfering with the production system. There is even a special term for this - “Dark Launch”, which in turn is activated by a function with an equally spy name “traffic mirroring”.
Please note that the first sentence of the previous paragraph uses the term “deploy” rather than “release”. You should really be able to deploy—and, of course, use—your microservice as often as you want. This service must be able to receive and process traffic, produce results, and also write to logs and monitor. But at the same time, this service itself does not necessarily need to be released into production. Deploying and releasing software are not always the same thing. You can deploy whenever you want, but release only when you're ready.
Organizing boredom is interesting
Take a look at the following Istio routing rule, which routes all HTTP requests to the microservice recommendation v1 (all examples taken from ), while simultaneously mirroring them to the recommendation v2 microservice:
Pay attention to the label mirror: at the bottom of the screen - it is this that sets traffic mirroring. Yes, it's that simple!
The result of this rule will be that your production system (v1) will continue to process incoming requests, but the requests themselves will be asynchronously mirrored to v2, that is, their complete duplicates will go there. This way, you can test v2 in real conditions - on real data and traffic - without interfering in any way with the operation of the production system. Does this make organizing testing boring? Yes, definitely. But it's done in an interesting way.
Let's add drama
Please note that in the v2 code it is necessary to provide for situations where incoming requests may lead to data changes. The requests themselves are mirrored easily and transparently, but the choice of processing method in the test is up to you – and this is a bit worrying.
Let's repeat an important point
Secret launch with traffic mirroring (Dark Launch/Request Mirroring) can be performed without affecting the code in any way.
Food for thought
What if the place where requests are mirrored sends some of them not to v1, but to v2? For example, one percent of all requests or only requests from a certain group of users. And then, already looking at how v2 works, gradually transfer all requests to the new version. Or vice versa, return everything to v1 if something goes wrong with v2. I think it's called Canary Deployment. , and if it were of Russian origin, it would probably contain a reference to ), and now we will look at this in more detail.
Canary Deployment in Istio: simplifying commissioning
Carefully and gradually
The essence of the Canary Deployment deployment model is extremely simple: when you launch a new version of your software (in our case, a microservice), you first give access to it to a small group of users. If everything goes well, you slowly increase this group until the new version starts to act up, or - if it doesn't - eventually migrate all users to it. By thoughtfully and gradually introducing a new version and switching users to it in a controlled manner, you can reduce risks and maximize feedback.
Of course, Istio simplifies Canary Deployment by offering several good options for intelligent request routing. And yes, all this can be done without touching your source code in any way.
Filtering the browser
One of the simplest routing criteria is browser-based redirection. Let's say you want only requests from Safari browsers to go to v2. Here's how it's done:
Let's apply this routing rule and then use the command curl We will simulate real requests to the microservice in a loop. As you can see in the screenshot, they all go to v1:
Where is the traffic on v2? Since in our example all requests came only from our own command line, it simply does not exist. But pay attention to the bottom lines in the screen above: this is a reaction to the fact that we executed a request from the Safari browser, which in turn produced this:
Unlimited power
We have already written that regular expressions provide very powerful capabilities for routing requests. Take a look at the following example (we think you'll understand what it does):
By now you probably have an idea of what regular expressions can do.
Act Smart
Smart routing, in particular processing packet headers using regular expressions, allows you to manage traffic the way you want. And this greatly simplifies the implementation of new code - it’s simple, it doesn’t require changing the code itself, and if necessary, everything can be quickly returned as it was.
Interested?
Are you eager to experiment with Istio, Kubernetes and OpenShift on your computer? Team prepared an excellent on this topic and made all the accompanying files publicly available. So go ahead and don’t deny yourself anything.
Istio Egress: exit through the souvenir shop
By using Istio together with Red Hat OpenShift and Kubernetes, you can make your life with microservices much easier. Istio's service mesh is hidden inside Kubernetes pods, and your code runs (mostly) in isolation. Performance, ease of change, tracing, etc. – all this is easy to use thanks to the use of sidecar containers. But what if your microservice needs to communicate with other services that are located outside of your OpenShift-Kubernetes system?
This is where Istio Egress comes to the rescue. In a nutshell, it simply allows you to access resources (read: “services”) that are not part of your system of Kubernetes pods. If you do not perform additional configuration, then in the Istio Egress environment traffic is routed only within a cluster of pods and between such clusters based on internal IP tables. And such pupation works great as long as you do not need access to services from outside.
Egress allows you to bypass the above IP tables, either based on Egress rules or on a range of IP addresses.
Let's say we have a Java program that makes a GET request to httpbin.org/headers.
(httpbin.org is just a convenient resource for testing outgoing service requests.)
If you enter on the command line curl http://httpbin.org/headers, we will see the following:
Or you can open the same address in the browser:
As you can see, the service located there simply returns the headers passed to it.
We are replacing imports head-on
Now let’s take the Java code of this service, external to our system, and run it on our own, where, recall, Istio is installed. (You can do this yourself by contacting .) Having built the appropriate image and launched it on the OpenShift platform, we will call this service with the command curl egresshttpbin-istioegress.$(minishift ip).nip.io, after which we will see this on the screen:
Oops, what happened? Everything just worked. What does Not Found mean? We just did it for him curl.
Extending IP tables to the entire Internet
Istio should be blamed (or thanked) for this. After all, Istio is just sidecar containers that are responsible for detection and routing (and a lot of other things that we talked about earlier). For this reason, IP tables only know what's inside your cluster system. And httpbin.org is located outside and therefore inaccessible. And this is where Istio Egress comes to the rescue - without the slightest change to your source code.
The Egress rule below forces Istio to search (if necessary, then throughout the entire Internet) for the required service, in this case, httpbin.org. As you can see from this file (egress_httpbin.yml), the functionality here is quite simple:
All that remains is to apply this rule:
istioctl create -f egress_httpbin.yml -n istioegress
You can view Egress rules with the command istioctl get egressrules:
And finally, we run the command again curl – and we see that everything works:
We think openly
As you can see, Istio allows you to organize interaction with the outside world. In other words, you can still create OpenShift services and manage them through Kubernetes, keeping everything in pods that scale up and down as needed. And at the same time, you can safely access services external to your environment. And yes, we repeat once again that all this can be done without touching your code in any way.
This was the last post in the series on Istio. Stay tuned - there is a lot of interesting things ahead!
Source: habr.com