Совершенствование управления приложениями в Kubernetes: возможности и стратегии Deployment

1. Введение

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

Цель – детально исследовать один из ключевых компонентов Kubernetes – объект Deployment. Объект Deployment предназначен для декларативного обновления и масштабирования приложений, а также для поддержания здоровья приложения и обновлений.

С применением Deployment, разработчики и системные администраторы получают возможность обновлять приложения без простоя, останавливая старые Pod'ы и создавая новые в автоматизированном и контролируемом процессе. Исследование также посвящено изучению различных стратегий обновления, предлагаемых Kubernetes, и определению ситуаций, в которых каждая из них является наиболее подходящей.

Такое понимание и умение применять Deployment в Kubernetes является ключевым для успешного и эффективного управления приложениями в производственной среде.

2. Объект Deployment в Kubernetes: Обзор и основные принципы работы

Объект Deployment в Kubernetes представляет собой ресурс, который управляет процессом развертывания и обновления приложений, делая этот процесс более предсказуемым и контролируемым. Deployment координирует создание и модификацию ReplicaSets, подмножеств Pod'ов, которые обеспечивают отказоустойчивость и масштабируемость приложения.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      Containers:
      - name: nginx
        image: nginx:1.14.2

Рис.

Описание Deployment включает в себя спецификации, такие как селекторы меток, количество реплик и шаблоны для создания Pod'ов. Это позволяет определить, какие Pod'ы должны быть созданы и как они должны функционировать в рамках приложения. Логическая структура объектов показана на рисунке.

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

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

3. Анализ стратегий обновления приложений в контексте объекта Deployment

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

Тут у нас есть 3 способа:

1. Сначала удалить все существующие поды, а затем запустить новые
2. Запустить новые и, как только они запустятся, удалить старые.
3. Или действовать поэтапно: если у нас несколько реплик одного пода, то можно добавлять по одному новому и удалять по одному старому.

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

Здесь логично будет использовать ReplicaSet. В статье “Репликация и автоматическое масштабирование в Kubernetes с помощью объекта ReplicaSet” подробно рассмотрено применение этого объекта.

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

В данном контексте мы можем выделить три стратегии обновления подов:

1. Удалить все существующие поды, а затем запустить новые.
2. Запустить новые поды и, по их активации, удалить существующие.
3. Реализовать поэтапное обновление: при наличии нескольких реплик одного пода, можно последовательно добавлять новые поды и удалять старые.

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

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

Пример спецификации:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      containers:
      - name: app
        image: app:v1.0

В представленной выше спецификации ReplicaSet видно, что имеется шаблон пода с названием 'app' и Docker образом 'app:v1.0'. Для обновления подов до новой версии можно вручную изменить образ на 'v2.0'. Однако, уже функционирующие поды ReplicaSet модифицировать не будет, а новый шаблон применяется исключительно к новым подам. В данной ситуации остается одна возможность: идентифицировать поды со старой версией и последовательно их удалять.

В этом случае ReplicaSet (RS) будет генерировать новые поды на основе нового шаблона с новой версией. Альтернативно, если приложение не поддерживает совместную работу двух версий, можно удалить все старые поды и дождаться создания новых. Однако, этот подход приводит к временному простою. Более гибким решением является создание нового RS с новым шаблоном пода, позволяя динамически регулировать значение параметра 'replicas' в новом и старом RS. Несмотря на свою эффективность, данная стратегия требует значительных ручных вмешательств.

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

Базовое описание Deployment очень похоже на описание ReplicaSet. Оно также состоит из селектора лейблов, количества реплик и шаблона будущего пода.

Создадим Deployment используя описание из примера спецификации выше.

#kubectl create -f deployment.yaml

Посмотреть существующие Deployment в кластере можно с помощью команды kubectl get deployment:

#kubectl get deployments.apps