Getting Started - Istio¶
This guide covers how Argo Rollouts integrates with the Istio Service Mesh for traffic shaping. This guide builds upon the concepts of the basic getting started guide.
Requirements¶
- Kubernetes cluster with Istio installed
Tip
See the environment setup guide for Istio on how to setup a local minikube environment with Istio
1. Deploy the Rollout, Services, Istio VirtualService, and Istio Gateway¶
When Istio is used as the traffic router, the Rollout canary strategy must define the following mandatory fields:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: rollouts-demo
spec:
strategy:
canary:
# Reference to a Service which the controller updates to point to the canary ReplicaSet
canaryService: rollouts-demo-canary
# Reference to a Service which the controller updates to point to the stable ReplicaSet
stableService: rollouts-demo-stable
trafficRouting:
istio:
virtualService:
# Reference to a VirtualService which the controller updates with canary weights
name: rollouts-demo-vsvc
routes:
- primary # At least one route is required
...
The VirtualService and route referenced in trafficRouting.istio.virtualService
is required
to have a HTTP route which splits between the stable and canary Services, referenced in the rollout.
In this guide, those Services are named: rollouts-demo-stable
and rollouts-demo-canary
respectively. The weight values for these services used should be initially set to 100% stable,
and 0% on the canary. During an update, these values will be modified by the controller.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: rollouts-demo-vsvc
spec:
gateways:
- rollouts-demo-gateway
hosts:
- rollouts-demo.local
http:
- name: primary # Should match spec.strategy.canary.trafficRouting.istio.virtualService.routes
route:
- destination:
host: rollouts-demo-stable # Should match spec.strategy.canary.stableService
weight: 100
- destination:
host: rollouts-demo-canary # Should match spec.strategy.canary.canaryService
weight: 0
Run the following commands to deploy:
- A Rollout
- Two Services (stable and canary)
- An Istio VirtualService
- An Istio Gateway
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/istio/rollout.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/istio/services.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/istio/virtualsvc.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/istio/gateway.yaml
After applying the manifests you should see the following rollout, services, virtualservices, and gateway resources in the cluster:
$ kubectl get ro
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE
rollouts-demo 1 1 1 1
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
rollouts-demo-canary ClusterIP 10.103.146.137 <none> 80/TCP 37s
rollouts-demo-stable ClusterIP 10.101.158.227 <none> 80/TCP 37s
$ kubectl get virtualservice
NAME GATEWAYS HOSTS AGE
rollouts-demo-vsvc [rollouts-demo-gateway] [rollouts-demo.local] 54s
$ kubectl get gateway
NAME AGE
rollouts-demo-gateway 71s
kubectl argo rollouts get rollout rollouts-demo
2. Perform an update¶
Update the rollout by changing the image, and wait for it to reached the paused state.
kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow
kubectl argo rollouts get rollout rollouts-demo
At this point, both the canary and stable version of the Rollout are running, with 5% of the traffic directed to the canary. To understand how this works, inspect the VirtualService which the Rollout was referencing. When looking at the VirtualService, we see that the route destination weights have been modified by the controller to reflect the current weight of the canary.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: rollouts-demo-vsvc
namespace: default
spec:
gateways:
- rollouts-demo-gateway
hosts:
- rollouts-demo.local
http:
- name: primary
route:
- destination:
host: rollouts-demo-stable
weight: 95
- destination:
host: rollouts-demo-canary
weight: 5
As the Rollout progresses through steps, the HTTP route destination weights will be adjusted to match the current setWeight of the steps.