Skip to content

Best Practices

This document describes some best practices, tips and tricks when using Argo Rollouts.

Ingress desired/stable host routes

For various reasons, it is often desired that external services are able to reach the desired pods (aka canary/preview) or stable pods specifically, without the possibility of traffic arbitrarily being split between the two versions. Some use cases include:

  • The new version of the service is able to be reach internally/privately (e.g. for manual verification), before exposing it externally.
  • An external CI/CD pipeline runs tests against the blue-green preview stack before it is promoted to production.
  • Running tests which compare the behavior of old version against the new version.

If you are using an Ingress to route traffic to the service, additional host rules can be added to the ingress rules so that it is possible to specifically reach to the desired (canary/preview) pods or stable pods.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: guestbook
spec:
  rules:
  # host rule to only reach the desired pods (aka canary/preview)
  - host: guestbook-desired.argoproj.io
    http:
      paths:
      - backend:
          serviceName: guestbook-desired
          servicePort: 443
        path: /*
  # host rule to only reach the stable pods
  - host: guestbook-stable.argoproj.io
    http:
      paths:
      - backend:
          serviceName: guestbook-stable
          servicePort: 443
        path: /*
  # default rule which omits host, and will split traffic between desired vs. stable
  - http:
      paths:
      - backend:
          serviceName: guestbook-root
          servicePort: 443
        path: /*

The above technique has the a benefit in that it would not incur additional cost of allocating additional load balancers.