k8s rollouts

canaries and rollouts in k8s

k8s rollouts

canaries and rollouts in k8s

rollouts

So you want to deploy a new version (of some request based service) of your deployment with some guarantee that it actually works.

This usually comes with 2 parts: rolling out the service and routing the traffic.

networking

The k8s Ingress API is the least common denominator, and the least flexible, doing simple round robin by the number of backing pods. So we get a proliferation of CRDs for each API Gateway / Service Mesh each with similar but different capabilities. These have the ability to route traffic based on a weight in the routing spec. Actual canary deployments are done by gradually updating the spec to shift traffic.

• k8s Ingress: abuse round robin by maintaining ratios of pods
• istio VirtualService (replaces Service): routes take weights
• traefik IngressRoute (replaces Ingress): routes take weights
• contour HTTPProxy (replaces Ingress): routes take weights
• ambassador Mapping (between Ingress and Service or replaces Ingress): mapping takes weights
• gloo VirtualService (replaces Ingress) and1 Upstream (on top of Service): routes take weights

and more: linkerd, aws app mesh, skipper, nginx, SMI (Service Mesh Interface) TrafficSplit, ...

• knative Service: requires one of the above, and presents a simplified CRD that replaces Deployment+Service+Ingress

controller

These are the things that watch for updates and deploy your new version, handle the routing by updating the above specs and canary testing before finalizing everything into a stable state, either a successful deploy of a new version or a rollback to the old.

• flagger Canary: creates Services and extra Deployments and manipulates ingresses
• argo rollouts Rollout: replaces Deployment, manipulates services

Both can do Canaries (progressive traffic shift) and BlueGreen (atomic(?) traffic switch). Flagger can do header/cookie based routing (A/B Testing) and traffic mirroring (for istio), both are on the roadmap for Argo Rollouts.