Dry goods sharing | Using Istio to achieve grayscale publishing

As a basic platform, Kubernetes provides powerful container orchestration capabilities. However, there are still some complexities and limitations in deploying business and service governance on it. In terms of service governance, there are already many mature ServiceMesh frameworks used to expand their capabilities, such as Istio, Linkerd, Dapr, etc. This article will mainly introduce how to use Istio to expand the capabilities of Kubernetes grayscale publishing.

In terms of deployment, the open source project Rainbond will be used as the basic platform for practice. Rainbond is a cloud-native application management platform that uses an application-centric design pattern. Based on this design pattern, a standardized application model is abstracted. From the experience of use, you can realize the full life cycle management of business applications without learning and writing YAML. So use it to simplify the deployment and management of your business. At the same time, Rainbond supports the replacement of the ServiceMesh framework, so that we can choose the ServiceMesh framework that best matches the business for service governance.

How to implement grayscale publishing in Kubernetes

When you deploy a business in a Kubernetes cluster, you can use the grayscale publishing method natively provided by Kubernetes to launch the business. This method is to define a differentiated Label between the old version and the new version of the service, according to the public Label load traffic between different versions to the back-end Pod, and finally control the percentage of traffic according to the number of copies of the Pod.

As shown in the following figure: The user defines two Deployment objects, of which the old version is named frontend-stable and has 3 replicas. The new version is frontend-canary with 1 copy. At this point, a Service object is defined, and the common Label between them is used for selection. This allows users to access the two versions at the same time at a ratio of 3:1 when accessing the frontend service. And you can also continuously control the traffic ratio by adjusting the number of replicas, and finally achieve complete online.

The default implementation of Kubernetes is very effective in simple deployment scenarios, but in some complex scenarios, there are still major limitations, such as:

1. After the service is configured to automatically scale, it will directly affect the proportion of traffic released by Grayscale.
2. A low percentage of flow control consumes high resources, such as 1% of the traffic to the new version, at least 100 replicas are required
3. Precise traffic distribution control, so that users accessing the new version are always in the same batch, rather than randomly switching when a user accesses

Istio Grayscale Release Brief

Due to the limitations of the grayscale publishing method provided by Kubernetes, in some complex scenarios, we need to use Istio to implement a more refined grayscale publishing strategy. When publishing in grayscale with Istio, we need to understand two important concepts:

1. Virtual services : Virtual services define the path of requests to services. A set of routing rules can be included so that requests matching the corresponding rules can reach the specified target.
2. Destination rules : Destination rules can manage the traffic reaching the destination, such as grouping the instance pools corresponding to the service backend, and then combining with the routing rules defined by Virtual services, and finally forwarding the traffic to the correct instance.

As shown in the figure below, taking the Bookinfo sample program provided by istio's official website as an example, the main definitions of virtual services and destination rules are given. Among them, virtual services are mainly divided into two parts, host name and routing rules. A hostname is one or more addresses used by clients to send requests to the service. When a request reaches a virtual service, it is matched according to the routing rules it defines. The figure defines that the user traffic whose mailbox ends with gmail.com will only reach the v3 version of the instance. Other users access the v1 and v2 versions of the service at a ratio of 1:9. In this way, precise traffic distribution control is achieved.

When user traffic comes to the service reviews.demo.svc.cluster.local, you can see that in the rule definition of destination rules, different instance sets are defined according to the label version, which realizes the decoupling of the traffic ratio and the number of replicas. It doesn't matter how many instances of reviews-v1 there are. Only 10% of traffic always reaches the v1 subset of destination rules. This solves the conflict between the number of business replicas and the traffic ratio, and makes resource usage more reasonable.

Practice of Istio Grayscale Publishing on Rainbond

Based on the above understanding, we will take BookInfo as an example to experience the grayscale release of Istio.

1. Preparation:

Before starting, we need to install the required environment in advance.

1) Install Rainbond

Refer to the official Rainbond documentation for quick installation. After the installation is complete, you can install Istio and the corresponding components with one click by connecting to the Helm store.

2. Install Istio and Kiali

After logging in to the Rainbond console, create a team first. The English name of the team corresponds to the namespace in Kubernetes. The default installed namespace of Istio is istio-system , so fill in the English name of the team istio-system , The name can be filled in as istio项目 . Next, connect to the Helm store through 应用市场 -> 点击➕号 -> Helm 商店 docking. Fill in the store name at will, and fill in the address https://openchart.goodrain.com/goodrain/rainbond . After the store is connected, we can click to install istio, kiali and other applications. For details, please refer to Istio installation .

2. Deploy the BookInfo application

Before deploying BookInfo, we need to create a team and application in Rainbond and switch the governance mode of the application to Istio 治理模式 . Application governance mode switching in Rainbond means that the communication governance mode between components under the application can be changed non-invasively.

As shown in the figure below, a complete application will contain multiple microservice modules, and the ServiceMesh framework injects Proxy into all business containers. According to the difference of injected Proxy, it can support various types of ServiceMesh implementations, such as: Istio, Linkerd, Dapr, Applications can enable ServiceMesh capabilities on demand, or change the implementation framework. In order for the BookInfo application to use Istio's governance capabilities, it needs to switch to Istio 治理模式 .

1. Prepare for mirroring

The BookInfo application consists of 6 microservices, and the dependencies between them are shown in the following figure. The Productpage service provides access to the page and obtains book details from the Details service. Get book reviews from the Reviews service. Among them, Reviews-v2 and Reviews-v3 will obtain the rating information of books from the Ratings service. The images of these six microservices are as follows:

 docker.io/istio/examples-bookinfo-productpage-v1:1.17.0
docker.io/istio/examples-bookinfo-details-v1:1.17.0
docker.io/istio/examples-bookinfo-reviews-v1:1.17.0
docker.io/istio/examples-bookinfo-reviews-v2:1.17.0
docker.io/istio/examples-bookinfo-reviews-v3:1.17.0
docker.io/istio/examples-bookinfo-ratings-v1:1.17.0

2. Deploy components

Under the application, select 添加组件 -> 指定镜像 -> 填写镜像地址 -> 新建组件 -> 确认创建 to create the components corresponding to these five microservices in turn.

3. Generate available Service

Just now we have only completed the deployment of all services, and have not yet defined the access policies for these microservices. Taking Productpage as an example, we can enter the management page of this service by clicking the Productpage component in the topology diagram. Find 端口 -> 添加端口 -> 端口号填写9080 -> 打开对外服务 -> 点击生成的路由 , and you can access it successfully. At this point, you will find that the page of the Productpage component cannot pull the book evaluation information. This is because by default it uses the two Service names details and reviews to connect to the components it depends on. At this point, the components we deployed, such as Reviews-v1, do not have the correct Service names. So still enter the component management page, 组件端口 -> 添加端口 -> 端口号填写9080 -> 修改使用别名 -> 内部域名填写为 reviews-v1 -> 打开对内服务 . The same is true for components such as details, reviews-v2, and ratings. After filling in the corresponding Service name, open the internal service.

Finally, under the K8s resources of the application, we also need to create the following Service to load traffic between the three versions of Reviews.

 apiVersion: v1
kind: Service
metadata:
  labels:
    app: reviews
    service: reviews
  name: reviews
spec:
  ports:
  - name: http
    port: 9080
    protocol: TCP
    targetPort: 9080
  selector:
    component: reviews # 需要在 Reviews 三个版本中，均添加 Kubernetes 属性，设置上该 Label，才能正确生效
  sessionAffinity: None
  type: ClusterIP

4. Orchestration Dependencies

After completing the above operations, visit the Productpage application and you can see that the book reviews can be correctly switched between the three versions. At this time, you can switch to the arrangement mode in the application view, and connect according to the architecture diagram of the above BookInfo application to realize the arrangement of the topology diagram. As shown in the figure below, the advantage of this arrangement is that the application can be released as a whole in the later stage, and other users can directly install it to get the same topology relationship, and no longer have to worry about finding the components that each service depends on.

3. Grayscale release

After completing the above deployment operations, we got a complete BookInfo program, but the Istio related configuration has not been defined yet, so we need to define the traffic rules through Kiali. Realize grayscale publishing.

1. Configure routing rules

You can see the app by visiting the Kiali admin page. Select Services in the left sidebar, find the reviews service, click to enter, select Traffic Shifting in Actions in the upper right corner, and you can see the following configuration: Drag the slider to select the traffic ratio. In the figure below, 30% of the traffic will go to reviews-v1, and 70% of the traffic will go to reviews-v2. After clicking Create, you can see in the lower left corner of the page that Kiali automatically generates virtual services and destination rules resources for you. You can click in and edit it again according to your needs.

2. Verify that the routing rules are in effect

Find the first deployed component Productpage, enter the component management page, click on the upper right corner to access the entry, you can see the book details and ratings, refresh the page repeatedly, you can see the review information without star rating (reviews-v1) and black star rating The ratio of evaluation information (reviews-v2) is about 3:7. The red star review information (reviews-v3) never appeared.

3. Verify the impact of component expansion on traffic

Find the deployed component reviews-v1, enter 组件管理页面 -> 伸缩 -> 实例数量设置为4 , then visit the Productpage page again, refresh the page repeatedly, you can see that after the expansion of reviews-v1, the ratio of accessing reviews-v1 to reviews-v2 is still 3:7, the number of component instances has no effect on the traffic distribution strategy.