1. Обзор текущей ситуации.

  2. Что такое Canary deployment.

  3. Развертывание Canary Deployment c помощью Kubernetes.

  4. Разделение трафика

  5. Мониторинг и проверка

  6. Масштабирование canary-deployment.

  7. Заключение.

  8. Список источников.

Не так давно я начал изучение контейнеризации, виртуализации и прочего сопутствующего инструментария для настройки сервисов и приложений.

Изучая разные ресурсы в просторах интернета для изучения docker и kubernetes, я наткнулся на интересную проблему, которая существует в разработке.

А именно: сложное и дорогое тестирование новых версий сервисов и приложений перед деплоем в prod(продакшн).

В настоящее время существуют следующие пути минимизации ошибок новых версии приложений перед отправкой в продакшн:

  1. Писать код максимально «чистый» и без «багов».

  2. Максимальное покрытие разрабатываемого приложения тестами.

  3. Тестирование на стейдже.

    Найди 100 отличий версии на stage и production
    Найди 100 отличий версии на stage и production
  4.  Smoke-тесты. Можно доверять, но не совсем. Сложно поддерживать! Где взять тот же трафик, что и на продакшн?

Потребности бизнеса:

  • Обнаруживать проблемы быстрее клиентов.

  • Рационально использовать человеческие ресурсы.

  • Ускорить деплоймент.

Что мешает удовлетворить "хотелки" бизнеса:

  • Непредсказуемость клиентского траффика.

  • Доступность провайдеров непредсказуема.

  • Распределенные команды.

  • Дата-центры нельзя повторить на стейдже

Выход есть?

Можно применять ручное тестирование либо покрывать все автоматическими тестами, можно не тестировать — проблемы возникнут в любом случае. В результате, при наличии существенных проблем придется откатываться на работающую версию. И после этого разбираться с проблемами и  причинами.  

Самый простой и правильный способ их решить — откатиться назад на работающую версию. Уже потом можно разбираться с ущербом, с причинами и устранять их.

А в это время компания могла бы заработать!

В этих обстоятельствах необходимость в эффективных стратегиях развертывания становится первостепенной. Среди этих стратегий одна, которая привлекла большое внимание и восхищение, — это использование Canary deployment в контексте Kubernetes.

2. Что такое Canary Deployment?

Canary Deployment — это deployment с обновленной версией приложения и это развертывание вы можете протестировать на небольшой группе пользователей. Если все работает стабильно можно будет смело развернуть новую версию на остальные узлы приложения.

Принцип данного развертывания можно изобразить на схеме. Допустим, у нас есть приложение, которое использует группа пользователей, инфраструктура приложения выглядит примерно следующим образом:

Заменим один узел из приложения на узел с новой версий и перенаправим часть трафика, скажем 10% на этот узел:

Если эти 10% не сообщают об ошибках, вы можете постепенно распространить ее на большее количество пользователей, пока новая версия не станет использоваться всеми. 

Как только Version 2 будет признана стабильной и успешной, вы сможете постепенно расширять ее охват, увеличивая процент трафика, направляемого на новую версию. Такое постепенное расширение сводит к минимуму влияние на ваших пользователей, обеспечивая при этом надежность и производительность вашего приложения.

После того, как canary-версия доказала свою стабильность и ценность, можно заменить оставшиеся узлы на новую версию. На этом этапе развертывание canary становится новой стабильной версией, и переход завершен. 

Такой итеративный подход к развертыванию не только улучшает общее качество работы пользователей, но и снижает риск простоев или сбоев. Он предоставляет разработчикам возможность точно настроить свой код, исправить любые потенциальные ошибки или проблемы, а также обрести уверенность в стабильности и надежности своих сервисов.

3. Развертывание Canary Deployment c помощью Kubernetes

Canary-deployment в кластере Kubernetes управляется службой через селекторы и метки . Служба направляет трафик к модулям с указанной меткой. Это позволяет легко добавлять или удалять развертывания. Объем трафика, который получает такое развертывание, соответствует количеству подов, которые она запускает. 

Как и на схеме, мы будем работать с двумя версиями приложения: v1 и v2.

Создадим deployment для текущей версии нашего приложения с помощью манифеста app-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app
      version: v1
  template:
    metadata:
      labels:
        app: app
        version: v1 #эта метка по которой сможем отслеживать нашу версию
    spec:
      containers:
      - name: app
        image: app-image:v1 #укажем образ нашего приложения
        ports:
        - containerPort: 8080

Создадим deployment с 3 репликами, каждый pod будет иметь метку version: “v1”, что даст нам возможность гибко отслеживать состояние созданных pod’ов  и переключаться между версиями в дальнейшем.

  Применим манифест для создания deployment. Ах, да, если вы не установили или еще не запустили minikube кластер, самое время сделать это. Я делаю это в ОС Windows 10.

 kubectl apply -f app-deployment.yaml

Также понадобится сервис для обслуживания данного развертывания. Создадим service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

И применим его: kubectl apply -f service.yaml

Создание canary deployment.

Создадим файл манифеста canary-app.yaml для новой версии приложения:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app
      version: v2
  template:
    metadata:
      labels:
        app: app
        version: v2
    spec:
      containers:
      - name: app
        image: my-app:v2
        ports:
        - containerPort: 8080

Применим манифест: kubectl apply -f canary-app.yaml

4. Разделение трафика

Чтобы направить часть трафика на версию v2, мы воспользуемся Istio. Убедитесь, что Istio установлен и включен в вашем кластере. Далее приведу краткое руководство по установке под Windows 10 (инструкция на официальной странице):

  •  Скачиваем последний релиз под виндоус.

  • Вносим изменения в переменную path текущего пользователя: для этого в строке поиска Панели задач пишем «Изменение переменных среды текущего пользователя":

  • Далее добавляем в path абсолютный путь до папки .. \ istio-1.20.1\bin:

  • далее я устанавливал Istio через PowerShell(под администратором):

    istioctl install --set profile=demo –y

Чтобы настроить разделение трафика, создайте файл virtual-service.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: app-virtual-service
spec:
  hosts:
    - app-service
  http:
    - route:
        - destination:
            host: app-service
            subset: v1
          weight: 90
        - destination:
            host: app-service
            subset: v2
          weight: 10

В этой конфигурации мы направляем 90% трафика на версию v1 и 10% на версию v2 (canary release). Примените  сервис с помощью kubectl:

kubectl apply -f virtual-service.yaml

5. Мониторинг и проверка

После того как среда canary заработает и трафик будет разделен между стабильной и новой (canary) версиями, крайне важно отслеживать производительность и проверять стабильность новой версии. Это можно сделать с помощью различных инструментов мониторинга и наблюдения, доступных в экосистеме Kubernetes, таких как Prometheus, Grafana, Lumigo.

Они могут помочь собирать и визуализировать показатели, связанные с использованием ресурсов, временем отклика, частотой ошибок и другими показателями производительности. Внедрение автоматических тестов и проверок может гарантировать, что canary-версия соответствует требуемым критериям перед ее полным развертыванием. 

Для мониторинга кластеров я рассмотрел Lumigo. Этот сервис обеспечивает комплексное наблюдение за бессерверными приложениями, микросервисами и кластерами Kubernetes. Lumigo позволяет вам отслеживать производительность и стабильность ваших Canary-развертываний с помощью аналитической информации в режиме реального времени, помогая обнаруживать потенциальные проблемы на ранних этапах процесса.

Чтобы начать работу с Lumigo Kubernetes, следуйте инструкциям по установке и настройке:

  • Для установки нужен helm. Ну что ж, идем на официальный сайт helm.sh, устанавливаем с помощью choco:

  • Установка  Lumigo Kubernetes operator в кластере Kubernetes с помощью helm:

helm repo add lumigo https://lumigo-io.github.io/lumigo-kubernetes-operator

helm install lumigo lumigo/lumigo-operator --namespace lumigo-system --create-namespace

  • Можно проверить, что Lumigo Kubernetes operator запущен и работает с помощью команды:

kubectl get pods -n lumigo-system

Lumigo предоставляет метрики и визуализации в реальном времени, что позволяет легко сравнивать производительность версий вашего приложения v1 и v2. Если вы обнаружите какие-либо проблемы или аномалии, вы можете быстро откатить canary release, настроив разделение трафика в виртуальной службе или удалив развертывание версии 2.

6. Масштабирование canary-deployment

Убедившись, что Canary-версия стабильна и работает должным образом, вы можете постепенно увеличивать трафик до версии v2, корректируя веса в Virtual service. Это позволяет безопасно развернуть новую версию для большего числа пользователей, сохраняя при этом контроль над показателями производительности.

Чтобы полностью перейти на новую версию, обновите первоначальный deployment, чтобы использовать образ v2, и удалите canary development:


apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app
      version: v1
  template:
    metadata:
      labels:
        app: app
        version: v1
    spec:
      containers:
      - name: app
        image: app:v2
        ports:
        - containerPort: 8080

7. Заключение

Развертывания Canary в Kubernetes предоставляют надежный и эффективный способ постепенного развертывания новых функций, позволяя разработчикам выявлять и решать проблемы до того, как они повлияют на всю базу пользователей.

В данной статье я  рассмотрел основную проблему в выпуске новых версий приложений в production, также описал суть canary deployment и процесс развертывания с помощью Kubernetes.

Таким образом можно сделать некоторые ВЫВОДЫ.

Преимущества canary deployment

  1. Постепенное внедрение.

  2. Минимизация риска и воздействия.

  3. Мониторинг и анализ производительности.

  4. Петля обратной связи.

  5. Оптимизация использования ресурсов.

  6. Возможность отката.

  7. Гибкость.

Canary deployment подходит в следующих ситуациях

  1. Сложность приложения.

  2. Влияние потенциальных проблем.

  3. Масштабируемость и производительность.

  4. Мониторинг и наблюдаемость.

  5. Стратегия отката.


8. Список источников

https://habr.com/ru/companies/slurm/articles/519130/

https://zeet.co/blog/kubernetes-canary-deployment

https://dev.to/developersteve/a-guide-on-mastering-canary-deployments-in-kubernetes-3b3f

https://martinfowler.com/bliki/CanaryRelease.html

https://patelsandeep88.medium.com/kubernetes-deployments-using-canary-c7d88afeca0f#:~:text=A%20canary%20deployment%2C%20or%20canary,functionality%20in%20the%20other%20version

https://phoenixnap.com/kb/kubernetes-canary-deployments

https://phoenixnap.com/glossary/canary-deployment

Комментарии (3)


  1. GRAlll
    30.12.2023 10:28
    +3

    Выводы как будто chatGPt писал, несогласованность и абстрактность некоторых фраз очень сбивает с толку.

    Также бы добавил в статью кейсы с тем как использовать канарейку в случае когда у вас в релизе N сервисов. Подход в статье усложнится раза в три, так как придется настраивать балансировку между версиями на уровне http или что ещё сложнее на уровне Kafka и аналогичных тулов по работе с событиями.

    Так что слепо вкрячить деплой через Хелм не поможет в системах чуть сложнее чем пара crud сервисов.


  1. DHeart
    30.12.2023 10:28

    Не понял, откуда появились subsetы в VirtualService, если они создаются в DestinationRule, а в статье про это ничего не написано


  1. jidckii
    30.12.2023 10:28

    Интересно, ака тестируют канарейки, если есть миграции в базу с сменой структуры?)