Destination Rules support

[chriskolenko]

Looking to migrate to your tool however we use Destination Rules all over the place. Will you be supporting them in the future?

[stefanprodan]

Hi @chriskolenko

Flagger generates the Istio objects and it has a control loop that keeps the Virtual Service in sync with the Canary CRD. This means you'll not be setting the routing with Istio but with the canary.service spec. When I started with Flagger, the first PoC was using Destination Rules, besides adding complexity to the sync logic I've seen no benefits from an automation perspective. Why would you think Flagger needs to use destination routes, do you have a use case not covered by the Virtual service generated for the canary deployment?

[stefanprodan]

Here are the docs on how Flagger does routing https://docs.flagger.app/how-it-works#virtual-service

[volatilemolotov]

@stefanprodan flagger should use DestinationRule as per official documentation https://istio.io/blog/2017/0.1-canary/
Issue that we currently see is that we cannot easily use ambassador as an ingress because your implementation uses two different kuberentes services while the istio can work with just one using destination subsets defined in DestinationRule to enable canaries.

[stefanprodan]

Having a dedicated ClusterIP service for the canary makes a lot of sense if you want to run integration tests. Using a single service will make the load tests and integration tests hit both versions.

[volatilemolotov]

I was trying to think of a way to handle that using istio magic but nothing comes to mind. Could you deploy 3 services, one general to use with istio and to define subsets and the other two (primary, canary) for integration tests?

[stefanprodan]

I'm looking at the Ambassador integration with Istio and there is no requirement for destination rules. As far as I can tell it needs some YAML embedded in the ClusterIP service annotations 🤦‍♂️

Please open up a new issue regarding Ambassador and describe how you use it to replace the Istio Ingress Gateway. My guess is that adding those annotations to the main svc will work if Ambassador uses the Istio routing to reach the pods.

[volatilemolotov]

There is no requirement for destination rules yes, but ambassador needs a single service to route to. Using destirantionrules subsets enables us to have a single service while still utilising Istio canary mechanism.

Is it viable to have 3 services. One to route the traffic while other two can be used for the tests?

[chriskolenko]

Hi @stefanprodan

After using Istio for a while now we have observed 503s when starting up new services. And this is because it takes a couple of seconds to propagate the changes back to mixer. The way to avoid that is to launch the services with Destination Rules then wait.. then apply the Virtual Services. As anyone reported any 503s using this operator? If so I can live without Destination Rules.

Have you come across any A/B testing scenarios. Or Weighted rules between multiple versions?

[stefanprodan]

@chriskolenko the 503s should've been resolved in 1.1. Here is a list of things to consider for zero downtime deployments https://docs.flagger.app/tutorials/zero-downtime-deployments

The latest Flagger version supports A/B testing check out the docs:

• https://docs.flagger.app/how-it-works#a-b-testing
• https://docs.flagger.app/usage/ab-testing

[chriskolenko]

@stefanprodan

We are currently using some load balancing rules inside destination rules.

Is there a way to implement them with flagger?

Sorry for the question in an issue

[stefanprodan]

@chriskolenko indeed this is a limitation of the virtual service. Looks like the LB settings are only available in the destination rules.

[chriskolenko]

@stefanprodan Thanks for all the replies.

At the moment we require A/B with sticky sessions and different weights. Soon we'll be able to remove the Sticky session problem then we can test out Flagger. Thanks for working on this project. It is one of the good ones.

[stefanprodan]

@chriskolenko as far as I know there is no way to ensure sticky sessions across weighted destinations.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: podinfo
  namespace: test
spec:
  gateways:
    - public-gateway.istio-system.svc.cluster.local
    - mesh
  hosts:
    - podinfo.istio.weavedx.com
    - podinfo
  http:
    - route:
        - destination:
            host: podinfo
            subset: primary
          weight: 50
        - destination:
            host: podinfo
            subset: canary
          weight: 50
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: podinfo-destination
  namespace: test
spec:
  host: podinfo
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpCookie:
          name: istiouser
          ttl: 30s
  subsets:
    - name: primary
      labels:
        app: podinfo
        role: primary
    - name: canary
      labels:
        app: podinfo
        role: canary

The above configuration will create a cookie for each destination, making the consistent hashing load balancer useless.