Подробное описание стратегий развертывания Kubernetes

С ростом использования контейнерных приложений и микросервисов сейчас самое подходящее время, чтобы стать экспертом по Kubernetes.

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

Сегодня мы на шаг приблизим вас к опыту Kubernetes с пошаговым руководством по объекту Deployment, средствам Kubernetes для управления ReplicaSet и обновлениям системы в реальном времени.

Содержание

Что такое развертывание в Kubernetes?
ReplicaSets
Обновление с развертыванием
Стратегии развертывания обновлений
Стратегия непрерывного обновления
Внедрение скользящего обновления
Воссоздать стратегию обновления
Воссоздать реализацию обновления
Стратегия обновления канарейки
Реализация канареечного обновления
Версия 1 Развертывание
Версия 2 Развертывание

Что такое развертывание в Kubernetes?

Развертывание — это объект ресурса в Kubernetes, который определяет желаемое состояние для вашей программы.

Развертывания являются декларативными, что означает, что вы не диктуете, как достичь состояния. Вместо этого вы объявляете свою конечную точку (называемую «желаемым состоянием») и позволяете контроллеру развертывания автоматически достичь этой конечной цели наиболее эффективным способом.

После запуска развертывание сравнивает текущее состояние программы с желаемым состоянием. Если они не совпадают, контроллер развертывания автоматически изменяет состояние, чтобы оно соответствовало.

Это автоматическое поддержание состояния — это то, что придает Kubernetes его любимые свойства самовосстановления.

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

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

ReplicaSets

Основной способ, которым развертывания поддерживают желаемое состояние программы, — это использование ReplicaSets.

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

Если Pod из ReplicaSet выходит из строя, он автоматически создает дополнительный Pod из шаблона.

Модули в ReplicaSet разрабатываются с использованием единого шаблона модуля, предоставляемого развертыванием, который определяет спецификации, общие для кластера модулей. Спецификации шаблона — это такие свойства, как:

Какие приложения следует запускать в модулях?
Какие ярлыки должны быть у стручков?
При каких условиях Pod перезапустится?

Лучше всего не управлять ReplicaSets напрямую. Вы должны выполнить все действия с объектом Deployment и оставить Deployment для управления ReplicaSets.

Каждое развертывание может управлять только одним шаблоном Pod, но может управлять несколькими модулями Replica Pod из одного и того же шаблона.

Вам нужно будет создать несколько развертываний для поддержки нескольких разных ReplicaSet.

Обновление с развертыванием

Основное преимущество развертываний — автоматическое обновление вашей программы Kubernetes.

Без развертывания вам пришлось бы вручную завершить все старые модули, запустить новые версии модулей и выполнить проверку, чтобы увидеть, возникли ли какие-либо проблемы во время создания модуля.

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

Вы даже можете откатить обновления до предыдущей версии. Старые ReplicaSet все еще существуют с полными конфигурациями Pod, но просто не управляют никакими Pod’ами после создания нового ReplicaSet.

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

Стратегии развертывания обновлений

Kubernetes предлагает стратегии развертывания, которые позволяют выполнять обновления различными способами в зависимости от потребностей системы. Три самых распространенных:

Стратегия непрерывного обновления: минимизирует время простоя за счет скорости обновления.
Стратегия восстановления: вызывает простои, но быстро обновляется.
Canary Strategy: быстрое обновление для избранных пользователей с полным развертыванием позже.

Давайте подробнее рассмотрим каждую из этих трех стратегий!

Стратегия непрерывного обновления

Стратегия скользящего обновления — это постепенный процесс, который позволяет обновлять вашу систему Kubernetes с незначительным влиянием на производительность и без простоев.

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

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

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

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

Как моя система отреагирует на мгновенное дублирование модулей?
Достаточно ли существенное обновление для того, чтобы некоторые модули работали со старыми спецификациями?
Сильно ли незначительное снижение производительности повлияет на удобство использования моей системы? Насколько точно моя система чувствительна ко времени?

Например, представьте, что мы хотим изменить спецификации наших модулей. Сначала мы изменим шаблон Pod на новые спецификации, которые передаются из развертывания в ReplicaSet.

Затем развертывание распознает, что текущее состояние программы (модули со старыми спецификациями) отличается от желаемого состояния (модули с новыми спецификациями).

Развертывание создаст модули и ReplicaSet с обновленными спецификациями и поочередно перенесет рабочую нагрузку из старых модулей в новые.

К концу у нас будет совершенно новый набор модулей и ReplicaSet без простоев обслуживания.

Внедрение скользящего обновления

Мы будем использовать объявление файла YAML с именем deploy.yamlдля создания нашего развертывания.

apiVersion: apps/v1  #Older versions of k8s use apps/v1beta1

kind: Deployment

metadata:

  name: hello-deploy

spec:

  replicas: 10

  selector:

    matchLabels:

      app: hello-world

  minReadySeconds: 10

  strategy:

    type: RollingUpdate

    rollingUpdate:

      maxUnavailable: 1

      maxSurge: 1

  template:

    metadata:

      labels:

        app: hello-world

    spec:

      containers:

      — name: hello-Pod

        image: educative/k8sbook:latest

        ports:

        — containerPort: 8080

В самом верху вы указываете версию Kubernetes API для использования. Предполагая, что вы используете последнюю версию Kubernetes, объекты развертывания находятся в группе apps/v1API.

Затем.kindполе сообщает Kubernetes, что вы определяете объект развертывания.

В этом.metadataразделе мы даем развертыванию имя и ярлыки.

В этом.specразделе происходит большая часть действий. Все, что находится ниже,.specотносится к модулю. Все, что вложено ниже,.spec.templateотносится к шаблону Pod, которым будет управлять развертывание. В этом примере шаблон Pod определяет один контейнер.

.spec.replicas сообщает Kubernetes, сколько реплик Pod нужно развернуть.
spec.selector — это список ярлыков, которые должны быть у модулей, чтобы развертывание могло ими управлять.
.spec.strategyсообщает Kubernetes, как в этом случае выполнять обновления модулей, управляемых развертыванием RollingUpdate.

Наконец, мы применим это развертывание к нашему кластеру Kubernetes с помощью команды:

$ kubectl apply -f deploy.yml

Воссоздать стратегию обновления

Стратегия обновления «воссоздать» — это процесс «все или ничего», который позволяет обновлять все аспекты системы одновременно с коротким периодом простоя.

В этой стратегии развертывание выбирает все устаревшие модули и сразу деактивирует их.

После деактивации всех старых модулей развертывание создает обновленные модули для всей системы. Система не работает, начиная с деактивации старого модуля и заканчивая созданием последнего обновленного модуля.

Стратегия воссоздания используется для систем, которые не могут функционировать в частично обновленном состоянии или если вы предпочитаете простои, чем предоставлять пользователям меньшее удобство. Чем больше размер обновления, тем больше вероятность того, что последовательное обновление вызовет ошибку.

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

Когда вы обдумываете стратегию воссоздания, спросите себя:

Будет ли у моих пользователей больше впечатлений от простоев или временного снижения производительности?
Может ли моя система работать во время непрерывного обновления?
Могу ли я обновить систему, не затрагивая значительное количество пользователей?

Воссоздать реализацию обновления

Эта реализация очень похожа на стратегию скользящего обновления.

apiVersion: apps/v1  #Older versions of k8s use apps/v1beta1

kind: Deployment

metadata:

  name: hello-deploy

spec:

  replicas: 10

  selector:

    matchLabels:

      app: hello-world

  minReadySeconds: 10

  strategy:

    type: Recreate

    rollingUpdate:

      maxUnavailable: 1

      maxSurge: 1

  template:

    metadata:

      labels:

        app: hello-world

    spec:

      containers:

      — name: hello-Pod

        image: educative/k8sbook:latest

        ports:

        — containerPort: 8080

Как видите, единственная разница между реализацией скользящего обновления и воссоздания заключается в строке 12, где мы заменили strategy.type: RollingUpdateна strategy.type: Recreate.

Как и в прошлый раз, мы развернем развертывание через командную строку, используя:

$ kubectl apply -f deploy.yml

Стратегия обновления канарейки

Стратегия канареечного обновления — это процесс частичного обновления, который позволяет вам протестировать новую версию программы на реальной пользовательской базе без обязательства полного развертывания.

В этой стратегии развертывание создает несколько новых модулей, в то время как большинство модулей остается в предыдущей версии, обычно в соотношении 1: 4.

Большинство пользователей по-прежнему используют предыдущую версию, но небольшая группа пользователей, не осознавая этого, использует новую версию в качестве тестировщиков.

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

Если мы действительно обнаружим ошибку, мы можем легко откатить несколько обновленных модулей, пока не исправим ошибку.

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

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

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

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

Обдумывая канареечную стратегию, спросите себя:

Каков наихудший сценарий, если это обновление не удастся?
Как скоро мне нужно будет завершить полное развертывание?
Сколько я провел внутреннего тестирования?

Реализация канареечного обновления

Для этой реализации нам нужно создать два развертывания в двух файлах YAML.

Версия 1 Развертывание

Нашим первым файлом k8s-deployment.yamlбудет устаревшая версия, на которой будет работать большинство наших модулей.

apiVersion: apps/v1

kind: Deployment

metadata:

  name: helloworld

spec:

  replicas: 3

  strategy:

    rollingUpdate:

    maxSurge: 1

    maxUnavailable: 1

  minReadySeconds: 5

  template:

    metadata:

      labels:

        app: helloworld

        track: stable

    spec:

      containers:

      — name: helloworld

        image: educative/helloworld:1.0

        ports:

        — containerPort: 80

        resources:

          requests:

            cpu: 50m

          limits:

            cpu: 100m

Это создаст 3 модуля v1с app:helloworldметкой, которую ищет наш сервис Kubernetes. Наш образ для этих модулей — это educative/helloworld:1.0означает, что эти модули будут созданы на основе старых спецификаций модулей.

Это развертывание равномерно разделит любую рабочую нагрузку между доступными модулями.

Вы развернете это, введя эту строку в командную строку:

kubectl apply -f k8s-deployment.yaml

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

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

Версия 2 Развертывание

Теперь мы создадим наш второй файл yaml k8s-deployment-canary.yaml, который является нашей новой канареечной v2версией.

apiVersion: apps/v1

kind: Deployment

metadata:

  name: helloworld-canary

spec:

  replicas: 1

  strategy:

    rollingUpdate:

      maxSurge: 1

      maxUnavailable: 1

  minReadySeconds: 5

  template:

    metadata:

      labels:

        app: helloworld

        track: canary

    spec:

      containers:

      — name: helloworld

        image: educative/helloworld:2.0

        ports:

        — containerPort: 80

        resources:

          requests:

            cpu: 50m

          limits:

            cpu: 100m

Для этого развертывания мы создаем только один модуль (строка 6), чтобы обеспечить взаимодействие с большей частью нашей пользовательской базы v1.

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

Вы можете развернуть это развертывание через командную строку, используя:

kubectl apply -f k8s-deployment-canary.yaml

Как только вы убедитесь, что это v2работает, просто замените изображение в нашем первом YAML-файле развертывания k8s-deployment.yaml, educative/helloworld:2.0вместо educative/helloworld:1.0.

Затем удалите Canary Deployment с помощью:

kubectl delete -f k8s-deployment-canary.yaml

В таком случае мы желаем, чтобы все модули были с, v2а рабочая нагрузка была сбалансирована между оставшимися 3 v2модулями.