“Danger is my middle name,” said Austin Powers, a mystery man on an international scale. But what is held in high esteem by super-agents and special services is not at all suitable for computer services, where boring things are much better than dangers.
And Istio, together with OpenShift and Kubernetes, make micro-service deployments truly boring and predictable — and that's great. We will talk about this and much more in the fourth and last post of the Istio series.When boredom is right
In our case, boredom occurs only in the final phase, when it remains only to sit and watch the process. But for this you need to pre-configure everything, and here you will find a lot of interesting things.When deploying a new version of your software, you should consider all options for minimizing risks. Working in parallel mode is a very powerful and proven way of testing, and Istio allows you to use the “secret service” (a version of your microservice hidden from prying eyes) for this without interfering with the production system. There is even a special term for this - “Secret Launch” (Dark Launch), which in turn is activated by a function with the least spyware name “traffic mirroring”.Note that the first sentence of the previous paragraph uses the term “deploy” rather than “release”. You really should be able to deploy - and, of course, use - your microservice as often as you wish. This service should be able to receive and process traffic, produce results, as well as write to logs and monitor. But at the same time, this service itself does not have to be released into production at all. Software deployment and release are not always the same thing. You can perform deployment whenever you want, but release only when you are completely ready.Organizing boredom is interesting
Take a look at the following Istio routing rule, which routes all HTTP requests to recommendation v1 microservice (all examples are taken from the Istio Tutorial GitHub repo ), while mirroring them to recommendation v2 microservice:Pay attention to the label mirror:at the bottom of the screen - it is it that sets traffic mirroring. Yes, that’s so simple!The result of this rule will be that your production system (v1) will continue to process incoming requests, but the requests themselves will mirror asynchronously on v2, that is, their full duplicates will go there. Thus, you can test the work of v2 in real conditions - on real data and traffic - without interfering with the work of the production system. Does this make testing organization boring? Yes, of course. But this is being done interestingly.Add drama
Please note that in the v2 code, it is necessary to provide for situations when incoming requests can lead to data changes. The queries themselves are mirrored easily and transparently, but the choice of the processing method in the test is yours - and this is already a little exciting.Repeat the important point
A secret launch with traffic mirroring (Dark Launch / Request Mirroring) can be performed without affecting the code.Food for thought
But what if the place to mirror the requests is to send some of them not to v1, but to v2? For example, one percent of all requests or only requests from a specific user group. 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. It seems to be called Canary Deployment (“canary deployment” - the term goes back to mining , and if it was of Russian origin, it would probably contain a reference to cats ), and now we will examine this in more detail.Canary Deployment at Istio: simplifying commissioning
Caution and gradually
The essence of the Canary Deployment deployment model is extremely simple: when you start a new version of your software (in our case, 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 junk, or - if this does not happen - eventually transfer all users to it. Thoughtfully and gradually introducing a new version into operation 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 query routing. And yes, all of this can be done without touching your source code.Filter the browser
One of the simplest routing criteria is browser-based redirection. Suppose you want v2 to only send requests from Safari browsers. Here's how to do it:We apply this routing rule and then with the command curlwe will simulate real requests to the microservice in a loop. As you can see in the screenshot, they all go to v1:And where is the traffic on v2? Since in our example all the requests came only from our own command line, it simply does not exist. But pay attention to the bottom lines in the screenshot above: this is a reaction to the fact that we executed the request from the Safari browser, which in turn issued this:Unlimited power
We already wrote that regular expressions provide very powerful capabilities for routing queries. Take a look at the following example (we think you yourself will understand what it does):Now you probably already know what regular expressions are capable of.Act smart
Smart routing, in particular processing packet headers using regular expressions, allows you to drive traffic the way you want. And this greatly simplifies the commissioning of new code - it's simple, it does not require changing the code itself, and if necessary, everything can be quickly returned as it was.Interested in?
Are you eager to experiment with Istio, Kubernetes and OpenShift on your computer? The Red Hat Developer Team has prepared an excellent tutorial on this topic and shared all the related files. So go ahead, and do not deny yourself anything. Istio Egress: exit through the gift shop
Using Istio with Red Hat OpenShift and Kubernetes can greatly simplify your life with microservices. The Istio utility grid is hidden inside Kubernetes pods, and your code is executed (mostly) in isolation. Performance, ease of change, tracing and more - all this is easy to use precisely through 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 included in your Kubernetes pod system. If you do not perform additional configuration, then in the Istio Egress environment, traffic is routed only inside the cluster of pods and between such clusters based on internal IP tables. And this kind of pupping works great until you need access to services from the outside.Egress allows you to bypass the aforementioned IP tables, either based on Egress rules, or for a range of IP addresses.Suppose we have a Java program that executes a GET request to httpbin.org/headers.(httpbin.org is just a convenient resource for testing outgoing service requests.)If you type at the command promptcurl http://httpbin.org/headerswe will see the following:Or you can open the same address in a browser:As you can see, the service located there simply returns the headers passed to it.Import substitution in the forehead
Now, let's take the Java code of this service external to our system and run it at home, where, recall, Istio stands. (You can do this yourself by referring to our Istio tutorial .) After assembling the corresponding image and running it on the OpenShift platform, we will call this service with a command curl egresshttpbin-istioegress.$(minishift ip).nip.io, after which we will see on the screen this:Oops, what happened? Still, it just worked. What does Not Found mean? We just did it for him curl.Extend IP tables to the entire Internet
Blame (or thank) Istio for this. After all, Istio is just sidecar containers that are responsible for detection and routing (well, for a lot of other things that we talked about earlier). For this reason, IP tables only know what is inside your cluster system. And httpbin.org is located outside and therefore unavailable. And here Istio Egress comes to the rescue - without the slightest change in your source code.The Egress rule below makes Istio search (if necessary, then on the entire Internet) for the desired service, in this case, httpbin.org. As you can see from this file (egress_httpbin.yml), the functionality here is pretty simple:It remains only to apply this rule:istioctl create -f egress_httpbin.yml -n istioegress
You can view the Egress rules with the command istioctl get egressrules:And finally, run the curl command again - and 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 steer them through Kubernetes, holding 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.This was the last post in the Istio series. Stay with us - there is a lot of interesting things ahead!