Общие сведения об управлении состоянием в Kubernetes
Если говорить о приложениях в целом, вы часто услышите о состоянии приложения. В этом блоке мы рассмотрим определение состояния и различные типы состояний, чтобы лучше подготовить ваше приложение к их обработке.
Государство
Состояние приложения — это все, что хранится в памяти по времени запуска приложения. Состояние может включать различные вещи, но в основном мы сосредоточимся на пользовательских данных.
Чтобы дать пример состояния приложения, представьте, что у вас открыт музыкальный проигрыватель. У этого приложения есть состояние. Он знает, кто вы, что вы хотите услышать, и какую музыку вы скачали. Все эти сведения являются частью состояния приложения.
Состояние в памяти — это информация, которую приложение не нужно искать в другом месте. Состояние диска содержит сведения, которые у приложения нет, поэтому он должен получить его из другого источника данных.
Типы государств
Существует два типа состояний приложения. Первый тип — это эфемерное состояние, которое не является постоянным и исчезает сразу после закрытия приложения.
Контейнеры имеют эфемерное состояние. Все данные, хранящиеся в них, мгновенно теряются при удалении контейнера. Некоторые приложения вполне могут работать с этим, так как они могут воссоздать состояние из других источников и не нуждаются в локальном хранении состояния. Эти приложения называются stateless приложениями.
Все оставшееся состояние, которое не является временным, называется сохраняемым состоянием. Постоянное состояние сохраняется после завершения жизненного цикла контейнера. Большинство технологий контейнеров, которые мы используем, имеют понятие тома, места на диске, где хранится состояние. Даже если удалить контейнер и включить снова, состояние сохраняется в безопасном месте и может использоваться вновь.
Приложения, использующие извлекаемое внешнее состояние, называются stateful приложениями.
Штаты и Kubernetes
Kubernetes может обрабатывать как приложения без отслеживания состояния, так и приложения с отслеживанием состояния. Приложения без состояния проще, так как мы можем сосредоточиться только на самом приложении, а не на его состоянии (поскольку его не существует).
Для большинства приложений, не имеющих состояния, простая рабочая нагрузка развертывания с подом может быть достаточной, чтобы иметь полностью функционирующую систему и эффективно использовать ваш кластер.
Работа с приложениями с отслеживанием состояния является противоположной. В таких случаях необходимо рассмотреть приложение и его состояние, где хранится состояние и как можно безопасно хранить состояние.
Поэтому в Kubernetes также есть концепция PersistentVolumes (PVs) и PersistentVolumeClaims (PVCs).
Совет
В этом модуле больше не рассматриваются понятия хранения, но вы можете обратиться к ресурсам службы Azure Kubernetes в сводке, чтобы узнать больше.
PersistentVolumes — это диски, которые выделяются в узлах для хранения состояний из контейнера «pod». Так как Kubernetes лучше всего подходит для распределенных приложений, все созданные тома лежат в пуле доступных томов . Затем контейнеры занимают это пространство для себя. Вы можете использовать PersistentVolumeClaims для привязки PersistentVolume к pod и использовать его пространство для хранения необходимых данных.
Все поставщики баз данных являются приложениями с отслеживанием состояния. Если вы развертываете поставщика базы данных в кластере, вам потребуются PV и PVC для хранения данных базы данных в безопасном месте, что позволит поставщику получать эти данные, даже если его контейнеры были удалены.
Лучшие практики обработки состояния
Состояние присутствует в большинстве приложений. Однако, лучшей практикой управления состоянием считается вообще не вмешиваться в него.
Вы разрабатываете любое эффективное приложение с целью сделать его высокодоступным и масштабируемым. Состояние движется в противоположном направлении. Несмотря на варианты, предоставляемые поставщиками хранилища, и простоту развертывания и использования, объём данных не может легко масштабироваться. Он тоже не отличается высокой доступностью.
Состояние высокой доступности
Чтобы быть высокодоступным, приложение должно быть в сети в любое время. Это делается с помощью репликации между зонами и регионами. Kubernetes учитывает географическую зону в большинстве своих рабочих нагрузок. Это означает, что у вас может быть несколько экземпляров приложения, развернутого в разных зонах. Однако диски не поддерживают распознавание зон.
При развертывании нового объекта PersistentVolume в Kubernetes он привязан к диску на узле. Этот диск также привязан к определенной зоне в определенном регионе. Использование репликации между зонами или регионами с помощью PVs является сложной задачей и требует значительных усилий по обслуживанию, как для самой репликации, так и для синхронизации данных.
Высокомасштабируемое состояние
Чтобы обеспечить высокую масштабируемость, приложение должно увеличивать пропускную способность вместе с количеством пользователей, подключенных к нему. Это сложно в управлении состояниями, так как любое внешнее состояние по сути является диском, а диск имеет ограниченную скорость ввода и вывода. Управление пропускной способностью помогает решить эту проблему.
Компания Database Solutions выдвинула концепцию ReplicaSets, которая реплицирует всю базу данных в несколько экземпляров. Репликация увеличивает количество дисков и ввода-вывода для состояния.
При каждом изменении базы данных необходимо синхронизировать состояние, чтобы все диски содержали одни и те же данные. Эта синхронизация также сложна.
Экстернализация состояния
Azure имеет решения как услуга (PaaS), такие как Azure Cosmos DB, которые являются высокодоступными и масштабируемыми и устраняют большинство проблем управления состояниями.
Внешнее хранение состояния и удаление необходимости обслуживания может помочь вам сосредоточиться на приложении и сократить затраты на работу с целостностью данных в инфраструктуре.