10 - Traffic Management

Updated 2 weeks ago by Michael Cretzman

Harness provides traffic splitting to gradually migrate traffic between application versions. For example, in a Canary Workflow, as the new application is verified, you can shift traffic from the previous version to a new version.

In Istio, traffic splitting is set in each VirtualService using route rules:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 75
- destination:
host: reviews
subset: v2
weight: 25

In Harness, you can use a simple DestinationRule and a VirtualService without route rules, and then specify the routing in the Workflow that uses the VirtualService, via the Traffic Split step:

Set Up Traffic Splitting

Setting up Traffic Splitting involves adding standard traffic management manifest to your Harness Service, and then using the Traffic Split step in your Workflow.

Harness Service Setup

In your Harness Service, add manifests for a simple DestinationRule and a VirtualService without route rules. Both will act as templates using the Service values.yaml file for names via its {{.Values.name}} placeholder.

Here is a simple DestinationRule:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
annotations:
harness.io/managed: true
name: {{.Values.name}}-destinationrule
spec:
host: {{.Values.name}}-svc
trafficPolicy:
loadBalancer:
simple: RANDOM

Here is a simple VirtualService:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
annotations:
harness.io/managed: true
name: {{.Values.name}}-virtualservice
spec:
gateways:
- {{.Values.name}}-gateway
hosts:
- test.com
http:
- route:
- destination:
host: {{.Values.name}}-svc
For traffic management using the Traffic Split step, Harness only supports HTTP in the VirtualService manifest. If you want to use HTTPS or TLS, you can use another manifest and apply it using the Apply Step. For more information, see Deploy Manifests Separately using Apply Step.

You do not need to enter weights in the destination section. By default, Harness adds a weight value of 100 for the existing (stable) service and 0 for the (canary) service, regardless of whether you use the Traffic Split step. Here is a sample from the deployment log of a VirtualService without weights specified that where Harness has applied weights.

- destination:
host: "anshul-traffic-split-demo-svc"
subset: "stable"
weight: 100
- destination:
host: "anshul-traffic-split-demo-svc"
subset: "canary"
weight: 0

If you do specify weights in your VirtualService, Harness will still use its defaults for Canary deployments and you can use the Traffic Split to change the weights.

The VirtualService includes a reference to a Gateway. Typically, you will also add a Gateway manifest to your Service, describing the load balancer for the mesh receivingHTTP/TCP connections. The Gateway manifest can also use the values.yaml placeholder:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: {{.Values.name}}-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"

That's all you need to set up simple traffic management in your Service. Next, you use the Traffic Split step in your Workflow to control routing weights for the existing service and the new service you are deploying.

Harness Workflow Setup

You perform traffic management in your Workflow using the Traffic Split step.

You can use the Traffic Split step anywhere in your Workflow, but you will typically apply it the Verify section after the Canary Deployment step was successful.

  1. To add the Traffic Split step, in your Workflow, click Add Command.
  2. In the Kubernetes section, click Traffic Split. The Traffic Split dialog appears.

By default, the Traffic Split step includes Harness variables to refer the VirtualService set up in the Service the Workflow is deploying, and the named destination service subsets Harness deploys.

In Virtual Service Name, Traffic Split takes the name of the VirtualService set up in the Service:

The variable ${k8s.virtualServiceName} refers to the value of the name label in your VirtualService manifest in the Harness Service.

If you have multiple VirtualService manifests in your Harness Service Manifests, you can enter the name of the VirtualService you want to use manually.

In Destination, Harness provides two variables:

  • ${k8s.canaryDestination} - Refers to the new Kubernetes service the Workflow is deploying.
  • ${k8s.stableDestination} - Refers to the previous Kubernetes service.

Harness will use these variables to initialize destinations and then apply the traffic split by adding destination subsets and weights into the VirtualService it deploys. Here is an example of a Traffic Split step and the logs from its deployment showing how the destinations are initialized and then applied by Traffic Split:

In cases where you are using multiple subsets in destination rules and you want to assign different values to them, you can use your own subsets in Traffic Split as well. Here is a simple example:

The only requirement of Destination field values is that they contain a host, subset and are valid YAML. See Destination from Istio for details.

You can use multiple Traffic Split steps in your Workflow to change the routing to your old and new service versions. Here is an example with Approval steps between each Traffic Split step:

Canary Delete and Traffic Management

If you are using the Traffic Split step or doing Istio traffic shifting using the Apply step, move the Canary Delete step from Wrap Up section of the Canary phase to the Wrap Up section of the Primary phase.

Moving the Canary Delete step to the Wrap Up section of the Primary phase will prevent any traffic from being routed to deleted pods before traffic is routed to stable pods in the Primary phase.

For more information, see Canary Delete Step.


How did we do?