Постоянное хранилище для масштабируемых bare-metal контейнеров Kubernetes
28, июль 2020 Контейнеры появились как способ сделать программное обеспечение переносимым. Контейнер содержит все пакеты, необходимые для запуска сервиса. Обеспеченная изоляция делает контейнеры чрезвычайно портативными и удобными в разработке. Контейнер может быть перемещен из разработки в тестовую среду или в производство без каких-либо или относительно небольших изменений конфигурации. По мнению некоторых аналитиков, контейнеры идут на смену виртуальным машинам и в последнее время все больше привлекают к себе внимание как клиентов, так и поставщиков. Контейнеры обычно используют меньше ресурсов, чем виртуальные машины, и могут связывать воедино библиотеки приложений и зависимости в одно удобное, развертываемое устройство. Контейнеры и платформы управления для них в основном разрабатывались для поддержки высокодинамичных операций (например, микросервисов) без сохранения состояния, при этом контейнеры непрерывно создавались и уничтожались для удовлетворения различных рабочих нагрузок. Одновременно удалялись и данные, созданные с помощью приложения в контейнерах (в основном, это было свойственно для приложений в ранних облачных архитектурах, которые плохо масштабировались). В приложении без сохранения состояния каждый сеанс выполняется, как в первый раз, а ответы не зависят от данных предыдущего сеанса. Приложения без сохранения состояния лучше подходят для облачных вычислений, так как их легче развертывать в случае сбоя и масштабировать с учетом изменений. Однако многие операции требуют, чтобы данные сохранялись после срока службы контейнера, что может противоречить природе контейнера. Для решения этой проблемы стали разрабатываться stateful-приложения, которые сохраняют данные клиента после действий одного сеанса для использования в следующем сеансе. Чтобы решить эти проблемы, например, Kubernetes представил плагин FlexVolume. Недавно Kubernetes выпустил плагин, соответствующий новому стандарту Container Storage Interface (CSI), который обещает упростить процесс сохранения данных на различных платформах хранения. Все приложения, имеющие базу данных и необходимость постоянного хранения, требуют постоянного хранилища. Внедрение постоянного хранилища для контейнеров является одной из главных задач администраторов Kubernetes, DevOps и облачных инженеров, т.к необходимо обеспечить его выживание в случае удаления контейнера или сбоя оборудования. Kubernetes является отраслевым стандартом для развертывания контейнеров в масштабе. С беспрецедентным уровнем принятия, Kubernetes стал основой для современной инфраструктуры и новых информационных технологий, как показал ОПРОС CNCF 2019 ( https://www.cncf.io/wp-content/uploads/2020/03/CNCF_Survey_Report.pdf ) – 78% респондентов используют Kubernetes в производстве (по сравнению с 58% годом ранее). По мере развития экосистемы пользователи понимают, что им необходимо постоянное общее хранилище для своих контейнеров. Именно это привело к созданию и массовому внедрению постоянных томов и CSI (интерфейс хранения контейнеров). Эта эволюция уже произошла в более зрелых экосистемах – например, Amazon AWS или OpenStack, обе они начинали с локальных дисков для виртуальных машин / экземпляров, а затем поняли, что им требуется постоянная общая база данных хранения, и в настоящее время все рабочие нагрузки выполняются таким образом. Проблемы с постоянными томами Постоянные тома (PV, Persistent Volumes) являются неотъемлемой частью кластера Kubernetes. Система хранения, которая предоставляет PV, как минимум, должна быть:
В общедоступном облаке PV предоставляются собственной службой в общедоступном облаке: EBS в Amazon ECS и Persistent Disk в Google Cloud GKE. Однако многие компании имеют необходимость запускать кластеры Kubernetes за пределами общедоступного облака – в этом случае им необходимо создавать локальные развертывания K8S. Более того, не каждый вариант использования подходит для работы в публичных облаках. Иногда эксплуатационные расходы на данные (загрузка, сохранение, загрузка) могут быть очень высокими, как в случае, когда NASA забыло о выходных затратах для своего хранилища данных объемом 247 петабайт в случае AWS ( https://www.computing.co.uk/news/4012760/nasa-egress-costs-aws ). В других случаях использование общедоступных облачных сервисов может быть неприемлемым или невозможным из-за норм и местного законодательства. Даже сервисные ограничения (например, максимальное количество ядер ЦП, объем ОЗУ и т. д.) могут быть ограничителем. StorPool (http://storpool.com/) одно из лучших в своем классе SDS-решений, которое позволяет заново создать стек общедоступных облаков в центре обработки данных и отвечает всем вышеперечисленным основным требованиям современного хранилища Persistent Volumes для Kubernetes. Читать полный обзор - http://www.storagenews.ru/news/2020/StorPool_76.pdf |
|