Gitlab Autodevops Как всегда поддерживать в живых одну капсулу - PullRequest
Новая
       13

Gitlab Autodevops Как всегда поддерживать в живых одну капсулу

1 голос
/ 10 марта 2019

Я использую Gitlab Autodevops для развертывания приложения в моем кластере kubernetes. В этом приложении всегда должен быть запущен только один экземпляр. Проблема заключается в том, что во время процесса обновления Helm убивает текущий запущенный модуль, прежде чем новый модуль будет готов. Это вызывает период простоя, когда старая версия уже убита, а новая еще не готова. Что еще хуже, приложению требуется значительное время для запуска (2+ минуты).

Я попытался установить minAvailable: 1 в PodDisruptionBudget, но без помощи. Любая идея, как я могу сказать Хелму ждать готовности обновленного модуля, прежде чем убить старый? (Наличие двух экземпляров, работающих одновременно в течение нескольких секунд, для меня не такая проблема)

1 Ответ

1 голос
/ 11 марта 2019

Вы можете выпустить новую версию приложения несколькими способами, необходимо выбрать ту, которая соответствует вашим потребностям.Я бы порекомендовал одно из следующего:

Ramped - медленное развертывание

Пакеты обновлений с ускоренным развертыванием в непрерывном обновлении вторичный ReplicaSet создается с новой версией приложения, затем количество реплик старой версии уменьшается, а новая версия увеличивается, пока не будет достигнуто правильное количество реплик. 

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2        # how many pods we can add at a time
      maxUnavailable: 0  # maxUnavailable define how many pods can be unavailable
                         # during the rolling update

Полный пример и шаги можно найти здесь .

Синий / Зеленый - лучше всего избегать проблем с версиями API

Синий /Зеленое развертывание отличается от ускоренного развертывания, поскольку «зеленая» версия приложения разворачивается вместе с «синей» версией.После проверки соответствия новой версии требованиям мы обновляем объект службы Kubernetes, который играет роль балансировщика нагрузки для отправки трафика в новую версию, заменяя метку версии в поле селектора. 

apiVersion: v1
kind: Service
metadata:
 name: my-app
 labels:
   app: my-app
spec:
 type: NodePort
 ports:
 - name: http
   port: 8080
   targetPort: 8080

 # Note here that we match both the app and the version.
 # When switching traffic, we update the label “version” with
 # the appropriate value, ie: v2.0.0
 selector:
   app: my-app
   version: v1.0.0

Полный пример и шаги можно найти здесь .

Canary - для тестирования

Канарное развертывание состоит из маршрутизации подмножествапользователей на новый функционал.В Kubernetes канареечное развертывание может быть выполнено с использованием двух Deployments с общими метками pod.Одна реплика новой версии выпущена вместе со старой версией.Затем по прошествии некоторого времени и, если ошибки не обнаружены, увеличьте количество реплик новой версии и удалите старое развертывание.

Для использования этого метода ReplicaSet требуется развернуть столько пакетов, сколько необходимо для получения права.процент трафика.Тем не менее, если вы хотите отправить 1% трафика в версию B, вам нужно иметь один модуль, работающий с версией B, и 99 модулей, работающий с версией A. Это может быть довольно неудобно для управления, поэтому, если вы ищете более управляемыйраспределение трафика, посмотрите на балансировщики нагрузки, такие как HAProxy или сервисные сетки, такие как Linkerd , которые обеспечивают больший контроль над трафиком.

Манифест для версии A: 

spec:
  replicas: 3

Манифест для версии B: 

spec:
  replicas: 1

Полный пример и шаги можно найти здесь .

Вы также можете играть с Интерактивное учебное пособие - Обновление вашего приложения в Kubernetes.

Я рекомендую прочитать Развертывание, масштабирование и обновление приложения в Kubernetes с рулем .

...