Стоит ли запускать приложения с отслеживанием состояния в Kubernetes?

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

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

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

Проблемы с государством

Термин «состояние» описывает данные, связанные с приложением в конкретный момент времени. Это долгоживущая информация, такая как содержимое базы данных и учетные записи пользователей, которую необходимо будет извлекать на протяжении всего жизненного цикла системы. Состояние постоянно меняется по мере создания и изменения данных во время использования службы.

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

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

Запуск сервисов с отслеживанием состояния в Kubernetes

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

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

StatefulSets — это объекты API, представляющие приложения с отслеживанием состояния. Они функционируют аналогично развертываниям, но присваивают уникальный идентификатор каждому поду, который они инкапсулируют. Поды сохраняют свои идентификаторы, даже если они перезапускаются или планируются на другой узел. Это позволяет вам реализовывать процедуры, в которых важны порядок и идентификация подов. Надежные идентификаторы позволяют повторно сопоставлять тома с модулями после запланированного события и последовательно развертывать обновления приложений.

Эти функции означают, что теперь можно запускать приложения с отслеживанием состояния внутри вашего кластера Kubernetes. Вы можете записывать данные в постоянные тома и использовать StatefulSets вместо Deployments, когда модулям необходимо помнить свои идентификаторы.

Управление состоянием вне Kubernetes

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

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

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

Отказ от Kubernetes для сервисов с отслеживанием состояния

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

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

В этих обстоятельствах вам, возможно, придется обратиться к альтернативным подходам к развертыванию, которые дадут вам больший контроль над хранением данных и операциями ввода-вывода. Однако в экосистеме продолжается работа по расширению возможностей хранения для контейнерных систем. Облачные решения для хранения данных появляются как абстракции более высокого уровня таких концепций, как постоянные тома и наборы с отслеживанием состояния, реализующие распределенные файловые системы, которые сохраняют свою производительность при использовании на нескольких узлах. Ceph, Minio и Portworx являются одними из претендентов на это место.

Стоит ли запускать приложения с отслеживанием состояния в Kubernetes?

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

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

Относительно немногие драйверы предлагают режим ReadWriteMany, который позволяет привязывать том к нескольким узлам одновременно, при этом каждый из них может читать и записывать данные. Режим ReadWriteOnce является наиболее широко поддерживаемым, позволяя каждому узлу читать данные, но только одному из них записывать. Эти ограничения могут повлиять на планирование вашего приложения — система с несколькими модулями, которым необходимо выполнять запись в общий экземпляр базы данных, должна будет запускать их все на одном узле, если только не доступен ReadWriteMany. Это ограничивает ваши возможности масштабирования ваших услуг.

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

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

Краткое содержание

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

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

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