Phenquestions
Давайте начнем с наивного определения «безгражданства», а затем постепенно перейдем к более строгому и реальному мировоззрению.
Приложение без состояния - это приложение, которое не зависит от постоянного хранилища. Единственное, за что отвечает ваш кластер, это код и другое статическое содержимое, размещенное на нем. Вот и все, без изменения баз данных, без записи и без остатков файлов при удалении модуля.
У приложения с отслеживанием состояния, с другой стороны, есть несколько других параметров, за которыми оно должно следить в кластере. Существуют динамические базы данных, которые, даже когда приложение отключено или удалено, сохраняются на диске. В распределенной системе, такой как Kubernetes, возникает несколько проблем. Мы рассмотрим их подробно, но сначала проясним некоторые заблуждения.
Сервисы без гражданства на самом деле не являются безгражданскими
Что это значит, когда мы говорим о состоянии системы? Что ж, давайте рассмотрим следующий простой пример автоматической двери.
Дверь открывается, когда датчик обнаруживает, что кто-то приближается, и закрывается, когда датчик не получает соответствующего входного сигнала.
На практике ваше приложение без сохранения состояния похоже на этот механизм, описанный выше. Он может иметь гораздо больше состояний, чем просто закрытый или открытый, а также множество различных типов ввода, что делает его более сложным, но по сути одинаковым.
Он может решать сложные проблемы, просто получая ввод и выполняя действия, которые зависят как от ввода, так и от «состояния», в котором он находится. Количество возможных состояний предопределено.
Таким образом, безгражданство - неправильное название.
Приложения без сохранения состояния на практике также могут немного обмануть, сохраняя детали, скажем, о клиентских сеансах на самом клиенте (отличным примером являются HTTP-файлы cookie), и при этом имеют приятное отсутствие состояния, которое позволяет им безупречно работать в кластере.
Например, сведения о сеансе клиента, такие как продукты, которые были сохранены в корзине и не были извлечены, могут быть сохранены на клиенте, и в следующий раз, когда сеанс начнется, эти соответствующие данные также будут запомнены.
В кластере Kubernetes приложение без сохранения состояния не имеет связанного с ним постоянного хранилища или тома. С точки зрения эксплуатации, это отличная новость. Различные поды по всему кластеру могут работать независимо с несколькими запросами, поступающими к ним одновременно. Если что-то пойдет не так, вы можете просто перезапустить приложение, и оно вернется в исходное состояние с небольшим временем простоя.
Сервисы с отслеживанием состояния и теорема CAP
С другой стороны, сервисам с отслеживанием состояния придется беспокоиться о множестве крайних случаев и странных проблем. Модуль сопровождается по крайней мере одним томом, и если данные в этом томе повреждены, это сохраняется, даже если весь кластер перезагружается.
Например, если вы запускаете базу данных в кластере Kubernetes, все поды должны иметь локальный том для хранения базы данных. Все данные должны быть идеально синхронизированы.
Поэтому, если кто-то изменяет запись в базе данных, и это было сделано в модуле A, и на модуль B поступает запрос на чтение, чтобы увидеть эти измененные данные, тогда модуль B должен показать эти последние данные или выдать вам сообщение об ошибке. Это называется согласованностью.
Последовательность, в контексте кластера Kubernetes означает каждое чтение получает самую последнюю запись или сообщение об ошибке.
Но это режет доступность, одна из важнейших причин наличия распределенной системы. Доступность означает, что ваше приложение работает как можно ближе к совершенству, круглосуточно, с минимально возможными ошибками.
Кто-то может возразить, что всего этого можно избежать, если у вас есть только одна централизованная база данных, которая отвечает за обработку всех потребностей в постоянном хранилище. Теперь мы вернулись к единой точке отказа, что является еще одной проблемой, которую кластеры Kubernetes должны решать в первую очередь.
Вам нужен децентрализованный способ хранения постоянных данных в кластере. Обычно называется разделением сети. Более того, ваш кластер должен выдерживать отказ узлов, на которых запущено приложение с отслеживанием состояния. Это известно как толерантность к разделению.
Любой сервис (или приложение) с отслеживанием состояния, запускаемый в кластере Kubernetes, должен иметь баланс между этими тремя параметрами. В отрасли это известно как теорема CAP, в которой компромиссы между согласованностью и доступностью рассматриваются при наличии разделения сети.
Дальнейшие ссылки
Для более глубокого понимания теоремы CAP вы можете просмотреть этот превосходный доклад Брайана Кантрилла, который гораздо внимательнее рассматривает запуск распределенных систем в производственной среде.
