ARGO Rollouts with Azure Kubernetes Services (AKS)

[ghostx3]

I'm looking for a way to use ARGO Rollouts with Azure AKS. In my case network plugin - Azure - and I'm also using Application Gateway to protect traffic.

Looking for use cases how-to implement ARGO Rollouts in a right way to get more flexibility managing traffic with Canary and BlueGreen scenarios.

I'd like to have native integration with Application Gateway in the first place, but I understand it doesn't support traffic weight. Azure Traffic Manager will be more appropriate service to use, but I concern about its global status and absence of ability to use private K8s services as backends.

Bu default AKS uses Azure Load Balancer as an ingress and it is not registered explicitly in AKS, so K8s Service just has a Kink of Service like Load Balancer and uses annotations to indicate it should be internal.

I'd appreciate any advice.

Thank you.

[carlosdoordash]

Argo Rollouts Blue/Green doesn't manipulate Kubernetes (K8s) Ingress resources nor Cloud load balancers. Instead, it only updates the K8s Service resource and specifically adds a selector rollouts-pod-template-hash to match the ReplicaSet hash of the active pods...

kubectl -n foo get service foo-service -o yaml
apiVersion: v1
items:
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: "2020-11-16T10:34:42Z"
    name: foo-service
    namespace: foo
  spec:
    ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: container-port
    selector:
      app: web
      rollouts-pod-template-hash: 78cf6689d8

Therefore, a Cloud load balancer that is provisioned by a K8s Ingress receives external requests and routes it to a K8s Service based on the K8s Ingress rule. This rule is defined by you and allows you to map an http/s domain or path to any K8s Service. The K8s service will then have a selector that initially points to blue pods (blue being the older version) using the blue ReplicaSet hash. If you then use Argo Rollouts to deploy a new green version with a new green hash, Argo Rollouts will wait for all green pods to become ready (i.e, all readiness probes pass). Once all green pods are ready, Argo Rollouts will update the Service selector with the new green hash to map new requests to the new green pods. Hence, neither the K8s Ingress nor Cloud load balancer were modified.

Regarding Argo Rollouts Canary, I haven't experimented with it enough to explain how Canary works.

[ghostx3]

Argo Rollouts Blue/Green doesn't manipulate Kubernetes (K8s) Ingress resources nor Cloud load balancers

Hi Carlos, thank you for you reply. Let me draw you attention on this topic: https://argoproj.github.io/argo-rollouts/getting-started/alb/

So it not that true ARGO Rollouts doesn't communicate with Cloud resources and doesn't work with them. We can clearly see in topic: "When looking at the listener rules, we see that the forward action weights have been modified by the controller to reflect the current weight of the canary.".

This means, that both scenarios (BlueGreen and Canary) could be (and might be already) managed in the same way, just manipulate weight of traffic. Either 100x0 or 10x90, whatever.

When you (we) work with K8s in the Cloud, this is extends list of Service types, Storage types etc. by new values supported by Cloud deployments and this brings to us new features, flexibility to stick more to Cloud managed services instead of using manual scripts and other handlers. That is what I'm trying to achieve, but being in Azure instead of AWS.

Nevertheless your reply was very useful for me, thank you, but I'll stick to wait for any other opinion as well.

[carlosdoordash]

Nice! Just to be clear, I only have experience with the blueGreen deployment strategy. From the traffic management doc, it seems that Argo Rollouts does manipulate Cloud resources but only when you use a canary deployment strategy and only by modifying the K8s Ingress resource...

Regardless of the Service Mesh used, the Rollout object has to set a canary Service and a stable Service in its spec.

But to answer your original question "Looking for use cases how-to implement ARGO Rollouts in a right way to get more flexibility managing traffic with Canary and BlueGreen scenarios."...

• If you want to use the BlueGreen deployment strategy, you can't manage traffic mostly because Argo Rollouts doesn't need for traffic to be shaped as it wants traffic to shift 100% at the time when the new green pods are ready.
• If you use the Canary deployment strategy, you can manage traffic if you choose a supported traffic solution (Istio, NGINX, SMI-Linkerd). Azure Traffic Manager is not in the list but still can be used to route traffic into your K8s Cluster where the traffic solution can then shape the traffic while Argo Rollouts automatically updates the k8s Ingress Resource following your steps in the Rollout's Canary Strategy spec.