More Virtual Services and Destination Rules

To enable canary deployments, we’ll need to create some additional Istio resources. Specifically, our API will get a new Virtual Service, and we will create subsets for the frontend and API services using Destination Rules. These subsets will allow us to route traffic to different versions of our services during the canary deployment process.

Creating Destination Rules

Destination Rules in Istio define policies that apply to traffic after routing has occurred. They are used to configure load balancing, connection pool settings, and subsets for services. In our case, we will create subsets for the frontend and API services based on the version of the application. Although we haven’t created different versions of our services yet, we will prepare the necessary configuration for it.

For the frontend service, create a file named dr-frontend.yaml with the following content:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: learning-tracker-frontend
spec:
  host: learning-tracker-frontend
  subsets:
  - name: canary   # referenced in canary.trafficRouting.istio.destinationRule.canarySubsetName
    labels:        # labels will be injected with canary rollouts-pod-template-hash value
      app: learning-tracker-frontend
  - name: stable   # referenced in canary.trafficRouting.istio.destinationRule.stableSubsetName
    labels:        # labels will be injected with stable rollouts-pod-template-hash value
      app: learning-tracker-frontend

This Destination Rule defines two subsets for the learning-tracker-frontend service: canary and stable. The labels will be injected automatically by Argo Rollouts based on the pod template hash of the respective versions. Istio will take this consideration when routing traffic to the virtual service specified by the host field.

For the API service, create a file named dr-api.yaml with the following content:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: learning-tracker-api
spec:
  host: learning-tracker-api
  subsets:
  - name: canary   # referenced in canary.trafficRouting.istio.destinationRule.canarySubsetName
    labels:        # labels will be injected with canary rollouts-pod-template-hash value
      app: learning-tracker-api
  - name: stable   # referenced in canary.trafficRouting.istio.destinationRule.stableSubsetName
    labels:        # labels will be injected with stable rollouts-pod-template-hash value
      app: learning-tracker-api

This is the same as the previous Destination Rule, but for the learning-tracker-api service. Again, we define two subsets: canary and stable, with labels that will be injected by Argo Rollouts.

Next, let’s change the existing Virtual Service for the frontend service to use these subsets. Therefore, change the route section of vs-frontend.yaml to look like this:

[...]
    route:
    - destination:
        host: learning-tracker-frontend
        subset: stable
        port:
          number: 80
      weight: 100
    - destination:
        host: learning-tracker-frontend
        subset: canary
        port:
          number: 80
      weight: 0
[...]

This change specifies that 100% of the traffic should be routed to the stable subset and 0% to the canary subset. This is the initial state and Argo Rollouts will manage the traffic shifting during the canary deployment process.

Finally, we need to create a new Virtual Service for the API service. Create a file named vs-api.yaml with the following content:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: learning-tracker-api
  namespace: learning-tracker
spec:
  hosts:
  - "learning-tracker-api"
  http:
  - name: "learning-tracker-api"
    match:
    - uri:
        prefix: "/"

    route:
    - destination:
        host: learning-tracker-api
        subset: stable
        port:
          number: 80
      weight: 100
    - destination:
        host: learning-tracker-api
        subset: canary
        port:
          number: 80
      weight: 0

This is the same as the previous Virtual Service, but for the learning-tracker-api service. Again, we define two routes: one for the stable subset and one for the canary subset, with weights of 100% and 0%, respectively.

After creating these files, apply all the resources using the following commands:

kubectl apply -f dr-frontend.yaml
kubectl apply -f dr-api.yaml
kubectl apply -f vs-frontend.yaml
kubectl apply -f vs-api.yaml

With this, we have successfully created the necessary Istio resources to enable canary deployments using Argo Rollouts. In the next step, we will migrate our existing deployments to Argo Rollouts.