Progressive Delivery in a Hosted Mesh Worker Cluster Based on GitOps¶
Scenario: How can customers perform a progressive delivery in a hosted mesh worker cluster using GitOps?
Prerequisites¶
Refer to the documentation Deploy Istio Resources in a Hosted Mesh Worker Cluster Based on GitOps and complete all steps before Create a Hosted Mesh and Manage the Worker Cluster
.
Implementing Weight-Based Progressive Delivery with GitOps¶
-
Navigate to Workbench, and Create Application in
GitOps
, with the repository address:https://github.com/amamba-io/rollout-examples
. Path should be set torollouts/v1
, and select the namespace in the worker cluster. -
After the application is successfully created, synchronize the application resources.
-
Go to the service mesh and check the vs, dr, and gateway resources synchronized in the worker cluster under the hosted mesh. If not found, check if the notes in the Create a Hosted Mesh and Manage the Worker Cluster section are configured correctly.
-
By default, the load balancer of the worker cluster exposes port
80
, so you need to modify the gateway port of the service to 80 in the worker cluster to access the service. -
Access
http://<worker cluster node IP>/hello?name=test-v1
in the browser. -
Navigate to Workbench, in the Progressive Delivery list, select
dubbo3-provider
to edit the YAML, and changeversion: v1
toversion: v2
. -
After the modification,
dubbo3-provider
begins the progressive process.As shown above: You can distinguish based on the workload labels rollouts-pod-template-hash and version.
Note
- v1 Pod: dubbo3-provider-5d96bf8bbd-v9c28
- v2 Pod: dubbo3-provider-f44c7c68f-95pfb
-
Explanation of the canary rules can be found in the git repository under the directory
rollouts-legacy/v1/rollout-provider.yaml
.... strategy: canary: trafficRouting: istio: virtualService: name: provider routes: - test-v1 destinationRule: name: dubbo-provider stableSubsetName: stable canarySubsetName: canary # When entering the progressive deivery, the traffic weight of the new version is set to 5%. After 10 minutes, the weight is set to 50%. steps: - setWeight: 5 - pause: duration: 10m - setWeight: 50 - pause: duration: 10m
-
The terminal simulation results are as follows:
-
When the new version's weight is 5%, the traffic distribution between v1 Pod and v2 Pod is as follows:
-
When the new version's weight is 50%, the traffic distribution between v1 Pod and v2 Pod is as follows:
-
After a successful release, all the traffic is directed to the v2 Pod.
-
Implementing Header-Based Progressive Delivery with GitOps¶
Introduction¶
Demonstration example repository: https://github.com/amamba-io/rollout-examples
The dubbo3-consumer
and dubbo3-provider
services are related. When accessing the /hello interface of dubbo3-consumer, dubbo3-consumer will forward the request to dubbo3-provider. The release process will update the dubbo3-provider service and route according to the preset header information.
Steps¶
-
Navigate to Workbench, Create Application in
GitOps
, with the repository address:https://github.com/amamba-io/rollout-examples
. Path should be set torollouts-legacy/v1
, and select the namespace in the worker cluster. -
After an applcation is successfully created, synchronize the application resources.
-
Go to the service mesh and check the vs, dr, and gateway resources synchronized in the worker cluster under the hosted mesh. If not found, check if the notes in the Create a Hosted Mesh and Manage the Worker Cluster section are configured correctly.
-
By default, the load balancer of the worker cluster exposes port
80
, so you need to modify the gateway port of the service to 80 in the worker cluster to access the service. -
Access
http://<worker cluster node IP>/hello?name=test-v1
in the browser. -
Navigate to Workbench, in the Progressive Delivery list, select
dubbo3-provider
to edit the YAML, and changeversion: v1
toversion: v2
. -
After the modification,
dubbo3-provider
begins the progressive process.As shown above: You can distinguish based on the workload labels rollouts-pod-template-hash and version.
Note
- v1 Pod: dubbo3-provider-5d96bf8bbd-v9c28
- v2 Pod: dubbo3-provider-f44c7c68f-95pfb
-
Explanation of the canary rules can be found in the git repository under the directory
rollouts-legacy/v1/rollout-provider.yaml
.... strategy: canary: canaryService: dubbo3-provider-canary stableService: dubbo3-provider trafficRouting: managedRoutes: - name: test-v2 istio: virtualService: name: provider routes: - test-v1 # During the delivery, the vs header is set to test-v2. If the request header contains `lane: test-v2`, it will be routed to the new version. steps: - setCanaryScale: weight: 100 - setHeaderRoute: name: test-v2 match: - headerName: lane headerValue: exact: test-v2 - pause: {}
-
The terminal simulation results are as follows:
FAQ¶
Does the above process support multi-cluster progressive delivery?¶
Yes, it does. The following operations are required:
-
First, you need to place multiple clusters under the same hosted mesh.
-
You need to create namespaces with the same name, and deploy the same GitOps application in each cluster's namespace.
-
During the delivery, you need to operate the corresponding services in both clusters separately.