Argo Rollouts. Part II: Canary and PingPong Strategy In Kubernetes

Нещодавно я опублікував першу статтю про Argo Rollouts, де зупинився на прогресивних методах доставки та реалізацію BlueGreen із ALB балансувальником та без. Цього ж разу поговоримо про Canary та його імплементацію в Argo Rollouts.

Ця стаття потребує робочого EKS кластеру, AWS LB контролера і самого Argo Rollouts. Про все це можна почитати в попередніх статтях блогу, а останній Terraform-код знаходиться за наступною адресою.


1. CANARY W/O BALANCER

Офіційна документація пропонує різні варіанти, наприклад коли додаток виливається без сервіс-об'єктів взагалі, чого може бути достатньо для якихось воркерів, що працюють зі сторонньою базою та не мають входу через єдиний ендпоїнт/балансувальник. Чи варіант, коли група подів заводиться лише під один об'єкт сервісу, адже першим етапом такої виливки вже є включення відсотку нової версії коду в трафік. Існує також позиція, що першим етапом Canary має бути под/вузол нової версії, котрий ще не буде під трафіком, але його можна буде обкласти додатковими тестами. Власне варіацій багато, єдиного стандарту немає і все залежить від потреб продукту.

У цій секції ми ж розглянемо найпростіший варіант: єдиний об'єкт сервісу, за котрим будуть з'являтись лише деякі поди із новим кодом. Відсоток буде відраховуватись "вагою" нових подів: 1 пода із новим імеджом із 5 - це 20%, 2 поди - 40% тощо. Для більш просунутих варіантів буде потрібна інтеграція із AWS ALB, про яку поговоримо в наступній частині. На реальному прикладі це має бути більш зрозуміліше:

$ cat <<EOF | kubectl apply -f -
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-canary
spec:
  replicas: 5
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: rollout-canary
  template:
    metadata:
      labels:
        app: rollout-canary
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:blue
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {}
      - setWeight: 40
      - pause: {duration: 10}
---
apiVersion: v1
kind: Service
metadata:
  name: rollout-canary
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
  selector:
    app: rollout-canary
EOF
rollout.argoproj.io/rollout-canary created
service/rollout-canary created

Argo Rollouts. Part I: Intro And BlueGreen Strategy In Kubernetes

За замовчуванням Kubernetes управляє стратегією виливки нового коду за допомогою Deployment об'єкта. Він забезпечує доволі простий функціонал, котрий, тим не менш, задовільнить більшість потреб: rolling update чи recreate стратегії виливки; наявність історії, котра може забезпечити безпечний rollback на попередні версії та інші. Deployment забезпечує поступову заміну старіших подів на новіші, перевіривши проходження readiness-проби кожного перед включенням його в трафік, або ж, у випадку recreate стратегії, видаляє старі поди і водночас за раз замінює їх на нові.

Будь-який новий реліз йде із додатковими ризиками, що можуть вплинути на доступність сервісу. І тому простих стратегій, що з коробки надає Kubernetes, буває недостатньо. Скажімо, може бути бажання перемкнути на нову версію (тег імеджа) лише певний відсоток трафіку чи протестувати нову версію прямо перед перемиканням на неї. Тож такі прогресивні стратегії виливки потенційно зменшать ризики та допоможуть заздалегідь знайти критичні недоліки, не вплинувши на значну кількість запитів.

Увесь подальший код доступний за посиланням.

1. PROGRESSIVE DELIVERY

Як вже було сказано, progressive delivery - це набір технік доставки коду, що зменшують ймовірність простою роботи сервісу чи його некоректну роботу. Найпопулярнішими варіантами таких доставок є:

• Blue-Green. Виливається додаткова версія коду, після чого працює одночасно дві: blue (стара) та green (нова). Перемикання production трафіку на новий код зазвичай не миттєве, а лиш в тому разі, коли є впевненість у коректності його роботи, наприклад після прогону додаткових тестів. Дуже часто це робиться на рівні DNS, коли на нову версію прив'язують основне доменне ім'я сервісу. У разі проблем є швидка можливість повернення на попередню версію, адже старий сервіс про всяк випадок не вимикають одразу.
• Canary. На нову версію коду спрямовується лише якийсь відсоток трафіку. У разі відсутності помилок цей відсоток збільшується і доходить до 100. Є різні варіації цієї техніки: наприклад може виливатись якась частина сервісу на новій версії без включення його в трафік, для того щоб додатково прогнати на ній тести. Такий собі варіант Blue-Green іn Canary. Ця техніка також зменшує ризики виливки проблемного коду, адже є ймовірність, що клієнти на новій версії повідомлять, що щось пішло не так допоки цю версію отримають всі користувачі сервісу. Немає якихось чітких часових рамок того як швидко має бути досягнуто завершення виливки нової версії. Для деяких компаній це години, а для інших - дні чи навіть тижні.
• Feature Flags/Toggles. Способи активації додаткового (нового) функціоналу для групи користувачів у межах однієї версії коду, що імплементується додатковими змінними в межах самого коду чи окремих систем із якими він інтегрується. Все заради поступової виливки цих змін.
• A/B Тестування. У межах однієї версії коду клієнтам буде продемонстровано різний функціонал чи різний вигляд елементів сторінки. Якщо у разі такого "експерименту" над користувачами буде підтверджено бажаний результат - ці зміни можуть бути активовані для всієї бази користувачів.

У цій серії статей ми зосередимось на розгортанні коду, а саме на Canary та Blue-Green як техніках, котрі безпосередньо імплементуються на рівні інфраструктури, а не особливостях роботи кодової бази.