Flux with Argo Rollouts

[artem-nefedov]

I want to use Flux v2 as a GitOpts solution in combination with Argo Rollouts for canary deployment. The problem is, unlike Flagger (which creates its own k8s objects), Argo Rollouts does sometimes modify fields in objects that are deployed as part of the application . And for some of those fields it's impossible to not include them in the original manifest stored in git (e.g. weights in Istio VirtualService). This can cause potential issues if Flux decides to reconcile the object that is currently being modified by Argo Rollouts.

Are there any potential solutions/workarounds for that?

[joberdick-rcd]

@artem-nefedov I have same interest. Argo-cd does not currently support centralized Helm repo's well like Flux. We are exploring the idea using rollouts but it seems the image update process in flux is not compatible. It seems by using Helm and flux in read-only, it might work fine. It would be good if there was more collaboration around this and argo+flux in general. I am not sure what the state of the "partnership" is, but it seems like we have to more or less choose between flux+flagger or argo-cd+rollouts right now.

[joberdick-rcd]

@artem-nefedov I am having success with Flux v2+Rollouts using HelmReleases and Istio. Using the canary subset option seems to not get step on by helm.

[ShibataTakao]

The problem is, unlike Flagger (which creates its own k8s objects), Argo Rollouts does sometimes modify fields in objects that are deployed as part of the application . And for some of those fields it's impossible to not include them in the original manifest stored in git (e.g. weights in Istio VirtualService). This can cause potential issues if Flux decides to reconcile the object that is currently being modified by Argo Rollouts.

I face this problem. I try to do blue-green deployment using AWS ALB. This is my Service resource manifest stored in git repository.

apiVersion: v1
kind: Service
metadata:
  name: rollouts-demo-service
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: http
  selector:
    app: rollouts-demo
  type: ClusterIP

Argo Rollouts controller add .spec.selector.rollouts-pod-template-hash field for traffic management.

apiVersion: v1
kind: Service
metadata:
  name: rollouts-demo-service
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: http
  selector:
    app: rollouts-demo
    rollouts-pod-template-hash: 5bb9b45cf9  # This is added by Argo Rollouts
  type: ClusterIP

But Flux controller re-apply Service resource manifest stored in git repository again in its reconcile loop. It delete .spec.selector.rollouts-pod-template-hash field for traffic management. It cause Argo Rollouts' traffic management failed.

Does anyone know any solutions/workarounds for this problem? Or Argo Rollouts can't be used with Flux v2?

My environment is following.

• EKS v1.22
• Flux v2 v0.30.2
• Argo Rollouts v1.2.0
• AWS Load Balancer Controller v2.4.1

[ShibataTakao]

But Flux controller re-apply Service resource manifest stored in git repository again in its reconcile loop. It delete .spec.selector.rollouts-pod-template-hash field for traffic management. It cause Argo Rollouts' traffic management failed.

In EKS v1.21, Flux controller re-apply manifest but it doesn't delete .spec.selector.rollouts-pod-template-hash . Forementioned problem occur after I upgrade EKS cluster to v1.22. I guess following changes in kubernetes v1.22 had some effect on this problem.

• Make selectors atomic kubernetes/kubernetes#97989
• Server Side Apply - Selectors are not atomic kubernetes/kubernetes#97970

[munai-das]

Hi @ShibataTakao , how did you solve this?

[ShibataTakao]

@munai-das I gave up to use Flux with Argo Rollouts. Now I use Argo CD with Argo Rollouts.

[mclarke47]

Rollouts also don't work with Kustomization healthchecking