|
| 1 | +# Getting Started - App Mesh |
| 2 | + |
| 3 | +This guide covers how Argo Rollouts integrates with service-meshes managed by [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html). This guide builds upon the concepts of the [basic getting started guide](../../getting-started.md). |
| 4 | + |
| 5 | +## Requirements |
| 6 | +- Kubernetes cluster with AWS App Mesh Controller for K8s installed |
| 7 | + |
| 8 | +!!! tip |
| 9 | + |
| 10 | + See the [App Mesh Controler Installation instructions](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-kubernetes.html) on how to get started using App Mesh with Kubernetes. |
| 11 | + |
| 12 | +## 1. Deploy the Rollout, Services, App Mesh CRD |
| 13 | + |
| 14 | +When App Mesh is used as the traffic router, the Rollout canary strategy must define the following mandatory fields: |
| 15 | + |
| 16 | +```yaml |
| 17 | +apiVersion: argoproj.io/v1alpha1 |
| 18 | +kind: Rollout |
| 19 | +metadata: |
| 20 | + name: my-rollout |
| 21 | +spec: |
| 22 | + strategy: |
| 23 | + canary: |
| 24 | + # canaryService and stableService are references to Services which the Rollout will modify |
| 25 | + # to target the canary ReplicaSet and stable ReplicaSet respectively (required). |
| 26 | + canaryService: my-svc-canary |
| 27 | + stableService: my-svc-stable |
| 28 | + trafficRouting: |
| 29 | + appMesh: |
| 30 | + # The referenced virtual-service will be used to determine the virtual-router that is |
| 31 | + # manipulated to update canary weights. |
| 32 | + virtualService: |
| 33 | + # name of the virtual-service App Mesh CR |
| 34 | + name: my-svc |
| 35 | + # Optional set of routes to update. If empty, all routes associated with the virtual-service are updated. |
| 36 | + routes: |
| 37 | + - http-primary |
| 38 | + # virtualNodeGroup is a structure to refer App Mesh virtual-node CR corresponding to Canary and Stable versions |
| 39 | + virtualNodeGroup: |
| 40 | + # canaryVirtualNodeRef refers to virtual-node corresponding to canary version. Rollouts controller will |
| 41 | + # update the podSelector of this virtual-node to latest canary pod-hash generated by controller. |
| 42 | + canaryVirtualNodeRef: |
| 43 | + name: my-vn-canary |
| 44 | + # stableVirtualNodeRef refers to virtual-node corresponding to stable version. Rollouts controller will |
| 45 | + # update the podSelector of this virtual-node to latest stable pod-hash generated by controller. |
| 46 | + stableVirtualNodeRef: |
| 47 | + name: my-vn-stable |
| 48 | + steps: |
| 49 | + - setWeight: 25 |
| 50 | + - pause: {} |
| 51 | + ... |
| 52 | +``` |
| 53 | + |
| 54 | +In this guide, the two services are: `my-svc-canary` and `my-svc-stable` respectively. There are two |
| 55 | +virtual-node CRs corresponding to these services named `my-vn-canary` and `my-vn-stable` |
| 56 | +respectively. In addition, there is a virtual-service named `rollout-demo-vsvc` that is provided by a |
| 57 | +virtual-router CR named `rollout-demo-vrouter`. This virtual-router need have at least one route with action to forward |
| 58 | +traffic to the canary and stable virtual-nodes. Initially weight for canary is set to 0% while for stable it is 100%. |
| 59 | +During rollout, controller will modify the weights on route(s) based on the configuraiton defined in |
| 60 | +`steps[N].setWeight`. |
| 61 | + |
| 62 | +To summarize, run the following commands to deploy a service: |
| 63 | + |
| 64 | +* Two services (stable and canary) |
| 65 | +* One service (for VIP and DNS lookup) |
| 66 | +* Two App Mesh virtual-nodes (stable and canary) |
| 67 | +* One App Mesh virtual-router with routes to virtual-nodes |
| 68 | +* One App Mesh virtual-service corresponding to VIP service |
| 69 | +* A rollout |
| 70 | + |
| 71 | +```shell |
| 72 | +kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/appmesh/canary-service.yaml |
| 73 | +kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/appmesh/canary-rollout.yaml |
| 74 | +``` |
| 75 | +## 2. Verify service |
| 76 | + |
| 77 | +First make sure that rollout is stable. |
| 78 | + |
| 79 | +```shell |
| 80 | +kubectl argo rollouts get rollout my-rollout -n argo-examples -w |
| 81 | +``` |
| 82 | + |
| 83 | +Then make sure the service is functional. |
| 84 | + |
| 85 | +```shell |
| 86 | +kubectl -n argo-examples port-forward svc/my-svc 8181:80 |
| 87 | +``` |
| 88 | + |
| 89 | +## 3. Rollout new version |
| 90 | + |
| 91 | +Now its time to deploy new version. Update the rollout with new image. |
| 92 | + |
| 93 | +```shell |
| 94 | +kubectl argo rollouts set image my-rollout demo=argoproj/rollouts-demo:green -n argo-examples |
| 95 | +``` |
| 96 | + |
| 97 | +Rollout should deploy a new canary revision and update the weights under virtual-router. |
| 98 | + |
| 99 | +```shell |
| 100 | +kubectl get -n argo-examples virtualrouter my-vrouter -o json | jq ".spec.routes[0].httpRoute.action.weightedTargets" |
| 101 | +[ |
| 102 | + { |
| 103 | + "virtualNodeRef": { |
| 104 | + "name": "my-vn-canary" |
| 105 | + }, |
| 106 | + "weight": 25 |
| 107 | + }, |
| 108 | + { |
| 109 | + "virtualNodeRef": { |
| 110 | + "name": "my-vn-stable" |
| 111 | + }, |
| 112 | + "weight": 75 |
| 113 | + } |
| 114 | +] |
| 115 | +``` |
| 116 | + |
| 117 | +Now manually approve the rollout that is paused indefinitely, and continue watching the routes get updated |
| 118 | + |
| 119 | +```shell |
| 120 | +kubectl argo rollouts promote my-rollout -n argo-examples |
| 121 | + |
| 122 | +watch -d 'kubectl get -n argo-examples virtualrouter my-vrouter -o json | jq ".spec.routes[0].httpRoute.action.weightedTargets"' |
| 123 | +``` |
0 commit comments