Series of articles:
General Catalog Index: Nine Analysis Takes You Easy to Complete the Istio Service Grid Series Tutorial
table of Contents
1 Introduction
2 Invitation
3 Introduction
4 Grayscale
5 destination rule example
5.1 Client resource files
5.2 deployment resource file
5.3 service resource file
5.4 Istio virtual service resource file
5.5 Istio destination rule resource file
6 Istio injection
7 Verify the destination rule
1 Introduction
If you have any questions about the blog, please let me know.
2 Invitation
You can search for "Nine Analysis" from station b to get free, more vivid video materials:
3 Introduction
In the previous section, we introduced an example of using Virtual Service to distribute traffic by weight. The whole process is shown in the following architecture diagram:
The entire flow control process is solved by adding only a virtual service. The code of the virtual service is as follows:
But the above solution is that the caller can call the final Pod through two layers of services (for example: the client needs to pass web-svc and nginx-svc to finally call the Nginx Pod). Can this effect be achieved with just one layer of service? (Ie: only via web-svc). The answer is yes.
4 Grayscale
In fact, the above sample is very copycat, resulting in no actual work scene can be copied, just to show the independent virtual service function.
But distributing traffic by weight is indeed a common requirement in work, such as grayscale, canary, blue and green release, etc.
Grayscale means that things are not so open. For example, if you want to stage a Tokyo love story with a favorite woman, your approach is probably to ambiguous, caress, kiss, and finally applaud her. The essence of the whole process is to complete a state transfer, that is, from the state of fighting alone to the state of teamwork applauding.
The process of grayscale release is similar to the above process, and it is a step-by-step, follow-up process. That is: the service of version v1 is changed to version v2, but it does not adopt a brutal extreme approach. The specific method is to first cut 20% of the traffic to version v2, observe that for a while, nothing unusual happens, then cut 20% of the traffic, and then gradually switch the remaining traffic, and finally complete the replacement of the entire version and the transfer of all user traffic.
5 destination rule example
The following introduces the use of virtual service + destination rule to achieve grayscale release. The theory of destination rule is introduced in the next chapter. The architecture diagram of the entire sample is as follows:
The resource files required by the sample are described as follows:
# Client, used to access container resource files of httpd-v1 and httpd-v2
jiuxi-client.yaml
# deployment, declare and define the resource file of httpd
jiuxi-deploy.yaml
# service, resource file associated with httpd pod
jiuxin-svc.yaml
# Istio virtual service, a resource file that declares traffic routing and weights
jiuxi-vs.yaml
# Istio destination rule, resource file that defines traffic routing
jiuxin-dr.yaml
5.1 Client resource files
jiuxi-client.yaml:
5.2 deployment resource file
jiuxi-deploy.yaml:
5.3 service resource file
jiuxin-svc.yaml:
5.4 Istio virtual service resource file
jiuxi-vs.yaml:
5.5 Istio destination rule resource file
jiuxin-dr.yaml:
6 Istio injection
For the virtual service and destination rule to take effect, it is necessary to ensure that both communication parties are within the Istio service grid, that is, they must be injected by Istio, and the execution statement is as follows:
istioctl be-inject -f jiuxi-client.yaml | babectl apply -f -
istioctl be-inject -f jiuxi-deploy.yaml | babectl apply -f -
7 Verify the destination rule
Log in to the busybox client container, access jiuxi-svc, and find that dr has taken effect. The screenshot is as follows:
Since then, Nine Analysis took you to easily explode the Istio destination rule instance.