Continuous learning
  • My continuous learning
  • Algorithms
    • Big O notation
    • Binary Search
    • Bloom filters
    • Heap vs Stack
    • HyperLogLog
    • MapReduce
  • Architecture
    • Distributed architectures
    • Event-Driven architectures
    • Kubernetes architectures
    • Micro-service architectures
    • Multi-cluster architectures
    • OpenStack architectures
    • SDN architectures
    • Storage architectures
    • Video streaming architectures
  • Book Reviews
    • 97 things every SRE should know
    • Antifragility: Things That Gain from Disorder
    • Atomic Habits
    • The Black Swan: The Impact of the Highly Improbable
    • The Culture Map
    • The First 90 Days
    • Fooled by Randomness
    • The Phoenix Project
    • The Unicorn Project
    • The Three-Body Problem
  • Engineering
    • Problem Solving
  • Mind Maps
  • Miscellaneous
    • Building a modern development environment
    • Complexity
    • Conway’s law
    • Feynman technique
    • Food as a reflection of a culture
    • Leadership
    • Leading a team
    • Memory Chunking
    • Rules for life
    • Software architecture
    • Moral of understanding what you are doing
    • UX
  • Projects
    • Blue-Green Deployments with Argo Rollouts
    • Canary Deployments with Argo Rollouts and Istio
  • Reading material sources
  • Tech Stacks
    • Chaos
    • Kubernetes
      • kubectl
      • Kubernetes deep dive
      • Managing Kubernetes Clusters
      • Multi Cluster deployments
      • Topology awareness
      • Cert manager with let's encrypt
      • Harbor
      • Inspektor Gadget
      • Komodor
      • Kubershark
      • kubevirt
      • Kyverno
      • Let's encrypt
      • Mailhog
      • MetalLB
      • OpenShift
      • Robusta
      • ingress
        • Nginx Ingress
    • Home Lab
    • SRE
    • FaaS
      • Knative
    • FaaS
      • OpenFaaS
    • automation
      • CD
      • Argo Events
      • Workflows
      • Dagger
      • Gitea
      • GitHub
      • GitLab
        • GitLab image mapping
        • Deploying GitLab in multiple clusters
      • Pipeline definitions
        • Test multiple python versions for a release
      • Pulumi
      • stack
        • Full platform stack
      • Terraform
    • cloud-providers
      • AWS
      • Fly.io
    • databases
      • Atlas
      • Postgres
        • Postgres for Sysadmins
      • Redis
      • Vault
    • development
      • GraphQL
      • Development experience for the next century
      • UX
        • devcontainer
      • Using code server as a service
      • Go
      • nim
      • Python
        • Making Python Fast
        • Poetry
        • Python Zero Copy
      • Rust
      • UX
        • Skaffold
      • UX
        • Telepresence
      • UX
        • tilt
          • Tilt
    • linux
      • LXC
    • management
      • Backstage
      • Crossplane
    • monitoring
      • Grafana
      • Loki
      • OpenTelemetry
      • Prometheus
      • Spawn a full monitoring stack
      • Tempo
      • Victoriametrics
    • network
      • Calico
      • external Nginx for kubernetes ingress
    • os
      • mac
        • Configure MacOS
    • scm
      • Git
        • hooks
          • Pre-commit hook
    • security
      • CodeQL
    • service-mesh
      • Cilium service mesh
      • Consul
      • istio
        • Istio from the ground up
        • Istio Monitoring
        • Ambient mesh
        • Istio Sidecar Mode
      • Jaeger
      • LinkerD
    • storage
      • Ceph
      • MinIO
    • testing
      • k6
Powered by GitBook
On this page
  • Requirements
  • Configuration
  1. Projects

Canary Deployments with Argo Rollouts and Istio

A canary deployment is more complex than a blue-green deployment. It requires a service mesh to route traffic to the canary version of the application. In this example, we will use Istio.

Requirements

  • Istio

  • ArgoCD

  • Argo Rollouts

  • Prometheus (required for analysis templates)

Configuration

Create a service definition:

apiVersion: v1
kind: Service
metadata:
  name: demo-app
spec:
  selector:
    app: demo-app
  ports:
    - name: http-web
      appProtocol: http
      port: 80

Create a destination rule definition:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: demo-app-destination-rule
spec:
  host: demo-app.demo-app.svc.cluster.local
  subsets:
  - name: stable
    labels:
      app: demo-app
  - name: canary
    labels:
      app: demo-app

Create a virtual service definition with destination routing rules:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: demo-app-vs
spec:
  hosts:
  - "demo-app.ms1.com"
  gateways:
  - demo-app-gateway
  http:
  - name: primary
    route:
    - destination:
        host: demo-app.demo-app.svc.cluster.local
        subset: stable
      weight: 100
    - destination:
        host: demo-app.demo-app.svc.cluster.local
        subset: canary
      weight: 0

Create a gateway definition:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: demo-app-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http-web
      protocol: HTTP
    hosts:
    - "demo-app.ms1.com"

Create an analysis template

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: istio-success-rate
spec:
  args:
  - name: demo-app
  - name: demo-app
  metrics:
  - name: success-rate
    initialDelay: 60s
    interval: 20s
    successCondition: result[0] > 0.90
    provider:
      prometheus:
        address: http://prometheus.istio-system:9090
        query: >+
          sum(irate(istio_requests_total{
            reporter="source",
            destination_service=~"{{args.service}}.{{args.namespace}}.svc.cluster.local",
            response_code!~"5.*"}[40s])
          )
          /
          sum(irate(istio_requests_total{
            reporter="source",
            destination_service=~"{{args.service}}.{{args.namespace}}.svc.cluster.local"}[40s])
          )

Create a rollout resource with the following configuration:

A rollout configuration encapulates a replicaset definition. No need to write both the rollout and the replicaset.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: demo-app-canary-rollout
spec:
  strategy:
    canary:
      trafficRouting:
        istio:
          virtualService: 
            name: demo-app-vs
            routes:
              - primary
          destinationRule:
            name: demo-app-destination-rule
            canarySubsetName: canary
            stableSubsetName: stable
      steps:
        - setWeight: 10
        - pause:
            duration: 2s
        - setWeight: 30
        - pause:
            duration: 2s
        - setWeight: 50
        - pause:
            duration: 2s
      analysis:
          templates:
            - templateName: istio-success-rate
          startingStep: 1
          args:
            - name: service
              value: demo-app.demo-app.svc.cluster.local
            - name: namespace
              value: demo-app
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      serviceAccountName: demo-app
      containers:
        - name: demo-app
          image: memogarcia10/demo-app:v4
          imagePullPolicy: Always
          ports:
            - containerPort: 80
              name: http-web
          securityContext:
            runAsUser: 1000
          resources:
            limits:
              cpu: 5m
              memory: 64Mi
PreviousBlue-Green Deployments with Argo RolloutsNextReading material sources

Last updated 2 years ago