self hosted что это
Выбираем self-hosted замену IFTTT
If This Then That — сервис для автоматизации задач и создания пайплайнов из действий в разных сервисах. Это самый известный и функциональный продукт на рынке, но популярность ему навредила: полноценное создание апплетов теперь возможно только с платной подпиской, а на реддите периодически появляются жалобы на нестабильную работу сервиса. Как и в случае с любым полезным но платным продуктом, ищущий альтернативы обрящет их в опен-сорсном комьюнити. Мы сравним три self-hosted инструмента: Huginn, Beehive и Node-RED, попробуем их в действии и выберем лучший по функционалу и удобству использования.
Huginn
Huginn — один из старейших сервисов автоматизации рутинных задач, первая версия была выпущена весной 2013 года. В скандинавской мифологии Хугин и Мунин — вороны Одина, приносящие ему новости обо всё происходящем в мире, здесь же это менеджер агентов, выполняющих небольшие задания по заданным триггерам. Агентов можно объединять в цепочки и вообще организовывать в структуры произвольной сложности. Hugginn даже иногда используют целые компании для автоматизации процессов (пример>). Агенты могут:
За семь лет разработки Huginn собрал сообщество, дописывающее новых агентов по мере необходимости. Также у него открыта программа на Bountysource.
Установка
Здесь и далее мы будем рассматривать только серверную установку, потому что на домашней машине таким сервисам, очевидно, делать нечего. Сервис должен крутиться на отдельной машине с выделенным адресом и прогнозируемым аптаймом и быть доступен с разных устройств, поэтому домашняя установка подойдет только для разработки.
Huginn распространяется в виде докер-образа, поэтому устанавливаем докер, затем просто запускаем:
Ждём установки и запуска, затем идём на 3000 порт, логинимся под дефолтной учёткой admin:password и видим полностью готовый к работе сервис. По умолчанию в Huginn уже есть несколько агентов (они были на графе выше), но мы создадим свою цепочку с нуля.
Сначала создадим агента, читающего RSS-версию хабра:
Затем создаём сценарий из этих двух агентов и ставим на запуск.
Beehive
В Beehive агенты называются ульями (hives) сейчас список на вики насчитывает 43 готовых улья. Они могут:
Установка
Нам снова потребуется докер и одна команда:
Вот только админка уверенно откажется загружаться из-за запросов на localhost, поэтому придётся пробросить адрес:
Авторизация не предусмотрена — видимо, подразумевается что без аутентификации в админку просто не попасть.
Процесс создания заданий и цепочек целиком показан на гифках из репозитория:
Node-RED
Здесь мы уже имеем дело не просто с агент-менеджером, а с полноценной платформой для организации задач, ориентированной не только на программистов, но и на обычных пользователей. Как и аналоги, Node-RED помимо использования готовых сценариев и модулей (нод) позволяет определять кастомные задачи, их логику и триггеры. Но если в других менеджерах любая кастомизация означает написание интерфейса (или целого модуля) с нуля или переписывание существующего, то здесь создавать все задачи и сценарии можно не выходя из браузера с помощью визуального программирования потоков данных. Создание модулей всё ещё требует навыков программирования, как и работа с API или ядром системы, но в целом из всех трёх вариантов только этот действительно близок к IFTTT по простоте использования, и помимо самого широкого функционала, у него еще и самое обширное сообщество, выкладывающее тысячи самописных модулей и сценариев.
Пример организации сценария
Установка
Node-RED предлагает несколько вариантов установки, включая npm, деплой в облака и даже установку на Raspberry Pi. Подробные инструкции по всем вариантам здесь, а вот простейшая установка докер-образа:
-v node_red_data:/data примонтирует каталог node_red_data в /data контейнера чтобы любые изменения, внесенные в сценарии, сохранялись.
Инстанс Node-RED будет доступен (без авторизации) на 1880 порту. Так как hello-world пример вообще не поможет понять довольно сложное устройство сценария, лучше прочитать полный туториал здесь.
Заключение
Можно с уверенностью сказать что повторить успех IFTTT в self-hosted не сможет ни один опенсорсный продукт — слишком много времени и ресурсов придётся инвестировать в разработку, которая скорее всего не выстрелит и не принесёт доходов. Поэтому у всех трёх инструментов есть более узкая ниша: они помогают автоматизировать задачи не всем-и-каждому-в-два-клика, а только настоящим нёрдам, которые готовы писать свои модули и копаться в чужом коде, потому что именно им действительно важны недостатки бизнес-модели IFTTT, связывающей им руки.
Подведём итоги:
На правах рекламы
VDSina предлагает мощные и недорогие VDS с посуточной оплатой для установки практически любого программного обеспечения. Интернет-канал для каждого сервера — 500 Мегабит, защита от DDoS-атак включена в тариф, возможность установить Windows, Linux или вообще ОС со своего образа, а ещё очень удобная панель управления серверами собственной разработки. Обязательно попробуйте!
Эффективное использование WebAPI: self hosting REST-сервисов
С выходом ASP.NET WebAPI у разработчиков появилась возможность быстро создавать REST-сервисы в удобном виде, с одной стороны полностью реализуя принципы REST, а с другой используя всю мощь платформы ASP.NET.
Про возможности и применение WebAPI написано уже достаточно много статей, например, вы можете узнать о интересной функции самодокументирования API сервиса через ApiExplorer.
Существует еще одна замечательная возможность WebAPI, про которую написано не так много — это возможность WebAPI осуществлять самостоятельный хостинг сервиса (self hosting). В этой статье на примере разбирается, как создавать и запускать REST selfhosting-сервисы на базе WebAPI.
Self hosting REST-сервиса
Для предоставления доступа к API сервиса не всегда является целесообразным разворачивать его на базе сервера IIS. Если сервис не является частью какого-либо веб-приложения, имеет смысл запускать его на базе собственной инфраструктуры.
Другим вариантом использования механизма self hosting может быть запуск сервисов на платформах, которые не содержат сервер IIS либо на которых запуск IIS осложнен или излишен.
Сервис внутри консольного приложения
Рассмотрим функцию самостоятельного хостинга на простейшем примере консольного приложения. Создайте в Visual Studio 2012 консольное приложение на базе шаблона для языка C#.
С помощью консоли пакетного менеджера NuGet установите пакет AspNetWebApi.Selfhost. Это можно проделать следующей командой:
Данная команда установит все необходимые компоненты в проект консольного приложения. После этого добавьте в проект ссылку на сборку System.Web, если такой ссылки еще нет.
Первым шагом для создания selfhosting-сервиса будет его конфигурирование. За конфигурирование отвечает класс HttpSelfHostConfiguration. Ниже пример конфигурирования сервиса:
Первая строка создает экземпляр класса сервера с установленным адресом. Вторая строка конфигурирует механизм маршрутизации сервера для того, чтобы мы могли запускать на нем свои REST API.
Пришло время добавить в наше приложение REST-сервис, который будет хоститься на нашем сервере. Для этого добавьте в проект новый элемент Web API Controller Class, например, с именем ProductController. Добавьте в проект новый класс с именем Product:
В только что созданном контроллере ProductController добавьте новый метод GetAllProducts:
Для того чтобы избежать конфликтов, вам нужно будет удалить или закомментировать сгенерированный в шаблоне метод Get().
В связи с тем, что наше приложение будет представлять собой сервер, слушающий определенные порты, приложение должно быть запущено с повышенными привилегиями. Вы можете запустить скомпилированный исполняемый файл от имени администратора самостоятельно либо запустить проект на исполнение в VS2012 запущенной от имени администратора. Другой возможностью может быть использование команды Netsh.exe для предоставления полномочий резервировать URL текущему пользователю.
Запустите приложение на исполнение.
Теперь, пока запущено наше приложение мы можем обращаться к selfhosting-сервису, который запушен без использования IIS. Просто перейдите по адресу http://localhost:5555/api/product/. Для тестирования можно воспользоваться браузером либо использовать Fiddler (рисунок 1).
Рис.1. Результат обращения к selfhosting-сервису
Запуск selfhosting-сервисов в качестве сервиса Windows
Для запуска selfhosting-сервиса хорошей идеей может стать запуск приложения-сервера в виде сервиса Windows. Сделать это достаточно просто.
Для быстрого создания системных служб может использоваться очень удобный инструмент TopShelf. В консоли пакетного менеджера NuGet выполните команду установки пакета:
После установки пакета вы получите доступ к API, который позволит вам упрощенно создать из своего приложения службу Windows.
Немного изменим код нашего проекта. Во-первых, вынесем запуск сервера в отдельный класс ProductService:
Затем модифицируем код метода Main для запуска сервиса с помощью API TopShelf:
Здесь с помощью специальных методов, которые предлагает TopShelf мы регистрируем сервис, задавая необходимый для запуска класс, его методы старта и прекращения работы, данные описание сервиса и его название.
После необходимых модификаций скомпилируйте проект. Теперь вы можете запустить свое приложение в виде сервиса Windows, это делается с помощью команды:
Сервис будет установлен (рисунок 2).
Рис.2. Установка сервиса Windows
Теперь, если вы перейдете в список системных служб Windows вы без труда обнаружите свое приложение (рисунок 3).
Рис.3. Служба в списке системных служб
Вам может потребоваться запустить ваш сервис, если он не запущен (рисунок 4)
Рис.4. Запуск службы
Проверим работу selfhosting-сервиса запущенного в качестве сервиса Windows в Fiddler и убедимся, что все работает.
Никогда такого не было и вот опять. Почему нужно использовать self-hosted VPN. Релиз Amnezia
Вот и пришло время для релиза VPN-клиента, родившегося благодаря хакатону DemHack, и выращенного при поддержке РосКомСвободы, PrivacyAccelerator и Теплицы социальных технологий.
Спустя полгода с того момента, как идея была впервые озвучена, мы презентуем готовый продукт — бесплатный опенсорсный клиент для self-hosted VPN, с помощью которого вы сможете установить VPN на свой сервер в несколько кликов.
Вместо скучной технической статьи о том, что вот оно: что-то сделали, что-то не успели, что-то пересмотрели, которую можно сократить до нескольких абзацев сути, я решил написать о своих размышлениях, о том, что вообще происходит, о бешеных принтерах, о развитии Интернета, в контексте его приватности, анонимности и блокировок.
Кто сразу хочет узнать подробности и технические характеристики клиента AmneziaVPN — перематывайте в конец статьи.
Будущее интернета и VPN
Давайте пофантазируем, каким может быть или каким мы хотим видеть Интернет в обозримом будущем, через несколько лет и в необозримом, в десятки лет.
Начну с того, что политические игры/войны тех, кто у руля, тех, кто управляет миром, вряд ли закончатся в обозримом будущем. А значит и не закончатся идеологические баталии. Места скопления людей в Интернете будут оставаться полем идеологических сражений и пропаганды, и с каждым годом эти сражения будут только набирать обороты. Блокировки неугодного контента будут совершенней, инквизиция смелее, проявлять в Интернете инакомыслие станет всё страшнее — только в каждой империи причины и поводы разные.
Дальше должны были идти несколько строк про бешеные принтеры, но, к сожалению, этот контент не прошёл модерацию.
Вчера мы все видели, как это происходит — вот только что ты сидел в Твиттере… Бац, и ты уже просто в свитере.
Стоит ожидать, что и средства для обхода блокировок тоже будут совершенствоваться. Вы так думаете? А я так не думаю. И вот почему.
Некоторые современные государственные фаерволы умеют не только выполнять глубокий анализ пакетов (DPI), но и осуществлять “активные проверки” серверов, с которыми соединяется клиент. Смысл этих активных проверок заключается в том, что фаервол не просто анализирует трафик, но и делает разные хитрые запросы на сервер, с целью определить, а не замаскирован ли на этом сервере VPN сервис. Игра в кошки-мышки дошла до того, что некоторые VPN протоколы уже умеют полноценно маскироваться под настоящий зашифрованный web трафик, а фаервол пытается определить валидность SSL сертификата, которым подписан трафик. Похоже, что это тупик. Дальше — только white list. Это означает, что вся эта игра в кошки-мышки подходит к концу.
DPI со своими активными проверками проиграл битву, и при определенных настройках VPN трафик невозможно отличить от обычного web-трафика.
Финальный аккорд, который нужно сыграть на стороне того, кто обходит блокировки — это приобретение любого домена, и выпуск валидного (бесплатного вполне хватает) SSL сертификата. Далее на сервере настраиваются ShadowSocks с плагином обфускации (маскировки трафика), фейковый веб сервер, и сплиттер трафика. Но это последний аккорд борьбы с фаерволами, в большинстве случаев пока достаточно простого ShadowSocks с обфускацией.
А давайте попробуем заглянуть в чуть более отдаленное будущее. Биткоин жив, и, по всей видимости, будет жив, даркнет тоже никуда не денется. Нефть потихоньку убывает, до токамаков в продакшене ещё лет 30, и глобальной политической стабильности не видать нам, видимо, до первых термоядерных электроватов в безлимитных электросчётчиках.
Квантовые компьютеры могут, конечно, нас устремить в технологическую сингулярность, но, думаю, что это тоже ближе к середине века намечено. Даже если к концу этого десятилетия соберут что-то годное, там сразу военные, силовики понабегут, да и сами корпорации будут не против подоить рынок, а там, глядишь, и власть “попеределить” захотят. Бррр, как-то всё апатично-удручающе, может кто поделится более оптимистичными вариантами развития событий в комментариях?
Так что же там с нашими VPN-ами в гипотетическом 2033м?
Первое, что можно предположить, гос. регуляторы разных стран, за неимением возможности блокировать замаскированный VPN трафик, продолжат устраивать массовые шатдауны — во время очередного идеологического сражения, как на просторах Интернета, так и вне его, да и вообще во время любой политической нестабильности.
Можно предположить, что будут продолжаться попытки гос. регуляторов влезать в корневые удостоверяющие центры, чтоб там хоть как-то закрепиться, а потом, глядишь, и объявить все остальные неверными и вражескими на своей территории. С технической точки зрения выглядит как-то нереально, но пробовать будут, денег уж точно там освоят бюджетных немерено.
По всей видимости, к VPN-ам качественно прикрутят блокчейн, и это может даже станет мейнстримом. Прикручивать уже начали несколько лет тому назад — уже есть такой проект — Mysterium. Я вообще за ними слежу, уже года четыре пилят, третий раз переписывают, их токен MYST наглядно показывает положение дел — он на дне, и расти, видимо, не собирается. Идея то хорошая, но с реализацией у них что-то возникли проблемы. А в сторону маскировки трафика они пока вообще не смотрят, что сильно снижает их конкурентоспособность, особенно на ближайших отрезках времени.
Бесплатный сыр
Последнее время новостные ленты запестрели новостями о том, что утекли данные 21 млн пользователей популярных (первый раз вижу эти названия) VPN-сервисов, а до этого мелькали новости, что во Frigate зашит троян (xakep.ru), а до этого, что утекли данные каких-то других VPN сервисов (www.rbc.ru).
А что с данными пользователей других VPN — они ещё не утекли, но уже проданы?
Находили ли вы по-настоящему бесплатные VPN, которым можно доверять? Есть ли гарантия что платные VPN не продают ваши данные? Несомненно, существуют честные VPN-сервисы, которые явно не намерены торговать вашими данными, и защищают их всеми своими силами.
Но мы считаем, что этого не достаточно. Мы и огромное количество других пользователей предпочитаем self-hosted VPN.
Итак, попробую пояснить своё видение. Начну издалека.
Начну с приватности и анонимности. Если по-простому, приватность — это когда вы заходите на сайт и третьим лицам видно, что зашли именно вы, но что вы там делаете им не видно, всё зашифровано. А анонимность — это когда невозможно (или предельно сложно) вычислить, кто же зашел на сайт, сопоставить факт захода на ресурс с конкретным человеком.
Зачем нужны VPN
А теперь зачем вообще нужны VPN. Ниже я попробую перечислить основные сценарии использования VPN, в контексте анонимности и приватности. Если что-то забыл — пишите в комментах, добавлю, это же интересно!
Дисклеймер: список сценариев приведен в ознакомительных целях, мы категорически против использования сети Интернет по сценариям, находящимся вне закона. Для разных пользователей и разных юрисдикций соответствие упомянутых сайтов к конкретным сценариям может различаться.
Проще говоря, вам анонимность не нужна, от слова совсем. Маловероятно, что те, кому она реально нужна, читают эту статью. Кому надо, уже всё знают, а кому не надо, им и не надо.
Теперь поговорим о приватности.
Комментарий из интернетов, оставлен совсем недавно на презентацию Privacy Day 2021 на Ютубе. Орфография и пунктуация сохранены. Слабонервным не открывать.
ну и Фригейт это частный случай, мы же говорим о плагинах в широком смысле, я понимаю, что они как-то монетезируются на мне, раз они бесплатны ну значит собирают что то, биг дату наприпер, ну и пускай, не юзать же платные впн, большинству не нужна сверх анонимность, надо чтобы на заблоченные сайты заходилось, и чтоб бесплатно было, всё, проекты типа антизапрет живущий на донаты будут популярны и любимы, а всякие платные решения не будут иметь и одной тысячный от их аудитории, платить готов бизнес, рядовому же юзеру коих большинство это не нужно, поставил приложеньку, включил и забыл, всё работает годами, на торренты заходит, ну чё та там шпионит, пускай, главное чтоб обезличенно и берега видело, ну Фригейт берега попутал, до этого были и другие типа Фокси Прокси, ну что поделать, не юзать же платные с абоненткой
Да, вот именно так, это среднестатистический пользователь сценария №1.
Хорошо это или плохо, что большинство готово платить такую цену за обход блокировок — риторический вопрос, как говорится — “как есть”. Но напрашивается логичный вывод: раз даже среди “бесплатных” VPN есть большая конкуренция, значит пользователи будут выбирать более надежные, проверенные, технически продвинутые решения среди бесплатных. Пользователей всех остальных сценариев приватность волнует, кого-то сильнее, кого-то слабее. Они готовы либо платить деньги за коммерческие VPN, либо всё настраивать своими силами.
Self-hosted VPN
Так вот, вообще-то это статья о релизе клиента для self-hosted VPN. Сейчас попытаюсь обосновать зачем он нужен, и куда мы хотим его развивать. Выше я писал про типичные сценарии использования VPN. Пройдёмся по ним ещё раз, в контексте self-hosted VPN.
Amnezia VPN
Вот мы и плавно подошли к техническим характеристикам клиента AmneziaVPN.
AmneziaVPN — это бесплатное приложение с открытым исходным кодом для создания вашего собственного VPN на вашем собственном сервере.
AmneziaVPN не является VPN сервисом, и не предоставляет возможности подключения к каким-либо преднастроенным серверам. В отличие от VPN сервисов, мы публикуем в свободный доступ не только исходные коды клиентской части, но и исходные коды серверной части. Для подключения вам необходимо приобрести любой VPS сервер любого провайдера самостоятельно.
А вот что планируется дальше, в порядке приоритетов:
→ Сайт со ссылкой на инсталляторы: amnezia.org
→ Исходники на GitHub
→ Telegram
P.S. Мессэдж провайдерам VPS
Несмотря на наличие инструкций для покупки, многим пользователям во время первого тестирования было сложно разобраться с покупкой виртуального сервера (VPS). Мы сделали полезный и простой клиент, и хотим, чтобы как можно больше пользователей могли настроить на нем свои собственные VPN. Если среди читателей есть представители VPS провайдеров, готовые услышать нас и сделать специальный VPN-Ready тариф, без технических настроек, только личные и платежные данные, мы с удовольствием добавим ваш хостинг на наш сайт со ссылкой на тариф и инструкцией.
Self-Hosted, или Kubernetes для богатых: почему самостоятельное развертывание кластера — не всегда способ сэкономить
Идея самостоятельно развернуть кластер Kubernetes на собственных серверах или в облаке выглядит привлекательной: кажется, что это дешевле, чем платить за Managed-решение от провайдера. На самом деле все не так однозначно: на практике можно обнаружить скрытые расходы и подводные камни.
При этом для крупных компаний Self-Hosted может быть вариантом, так как у них есть условно бесплатные ресурсы и штат специалистов для поддержки технологии, а иногда еще горячее желание построить и развивать свою платформу во что бы то ни стало. А вот с малым и средним бизнесом ситуация немного другая, решение нужно взвесить со всех сторон.
Я Дмитрий Лазаренко, директор по продукту облачной платформы Mail.ru Cloud Solutions (MCS). В статье расскажу, в чем особенности развертывания Self-Hosted-кластера Kubernetes и о чем нужно знать перед запуском.
Для старта понадобятся время, деньги и администраторы, разбирающиеся в Kubernetes
Первая статья расходов — на специалистов, которые умеют работать с этой системой и смогут обслуживать кластер. Это дорогие ребята, на рынке их немного, и нанять трудно.
Почему Kubernetes сильно увеличивает расходы на специалистов? Вроде бы развернуть кластер несложно, для этого есть официальная документация и инсталляторы, например Kubespray или Kubeadm. Однако если в компании есть инженер, который может прочитать строчку документации и разобраться, как поставить Kubernetes на серверы с помощью одной команды, это еще не все, этим его работа не ограничится.
В реальности развернуть кластер только половина дела. В таком виде он будет работать до первой проблемы, которая неизбежно возникнет через неделю или месяц. Например, перестанут создаваться поды из-за неверной конфигурации ресурсов на controller-manager. Или кластер начнет работать нестабильно из-за проблем с дисками у etcd. Или запущенные СronJob из-за ошибок controller-manager начнут бесконечно плодить новые поды. Или в кластере будут возникать сетевые ошибки из-за неправильного выбора конфигурации DNS.
В общем, проблем может быть много, поэтому нужен отдельный человек, знающий, как развернуть кластер, как дебажить, как запускать приложения в производственной среде.
Кроме того, вместе с Kubernetes в компании появляются новые потребности, например мониторинг для выявления ошибок, система хранения данных, сбор логов. Кластер нужно развивать, чтобы получить от технологии ожидаемый профит. Это требует времени, поэтому даже опытному администратору не получится выделить неделю для настройки кластера и какие-то часы для администрирования.
Скорее всего, понадобится человек на фултайм, который будет заниматься только Kubernetes, поддержкой и развитием кластера. В большой компании может родиться отдел для поддержки инфраструктуры.
Конечно, если запускать Kubernetes только ради деплоя контейнеров, то можно не разбираться и не развивать кластер. Но тогда возникает вопрос: зачем вам Kubernetes? Можно взять более простой в настройке и поддержке инструмент, тот же Docker Swarm. Если вы хотите от Kubernetes что-то простое, просто его не используйте. Нет смысла тратить время на развертывание кластера лишь ради запуска простого кода. Эта технология предназначена для проектов, где постоянно идет разработка, часто запускаются новые релизы и нужно выдерживать требования HighLoad.
По этой причине Self-Hosted Kubernetes в большинстве случаев могут успешно запустить только крупные компании, где есть возможность выделить сотрудников для обслуживания кластера и нет потребности экономить ресурсы.
Кроме того, самостоятельное развертывание кластера — дело небыстрое. Если понадобится запустить кластер в короткие сроки для проекта или тестовых сред, то на Self-Hosted это не выйдет: развертывание займет несколько часов, а то и недель. К этому стоит быть готовыми. Для сравнения: в облаке вы запустите кластер KaaS за 10 минут и сможете сразу его использовать, но это получается потому, что над инфраструктурной частью уже заранее поработали специалисты провайдера.
Kubernetes требует прокачки: он не работает сам по себе
Как я уже говорил выше, Kubernetes — отдельная экосистема, которой нужно заниматься и подключать к ней дополнительные инструменты. Если брать Self-Hosted, то все это придется делать самостоятельно.
Все инструменты, дополняющие Kubernetes, — Open Source-решения, которые нужно настраивать. В кластер потребуется установить систему мониторинга, реализовать балансировку нагрузки, сбор и хранение логов, настройки безопасности и авторизации пользователей, сети и многое другое.
Например, понадобится мониторить и сам кластер, и приложения в нем. Причем стандартного мониторинга через Zabbix вам не хватит, потребуется специфический — Prometheus или Telegraph.
С логами аналогичная ситуация: из коробки вы получите только историю логов для уже запущенных приложений, при передеплое она исчезнет. Вручную собирать логи с Kubernetes не получится, нужно подключать сборщики логов вроде Fluentd и систему хранения, например Elasticsearch или Loki. Отдельно придется заниматься балансировкой нагрузки: понадобится отказоустойчивый балансер вроде MetalLB.
Системы хранения для Self-Hosted Kubernetes — еще одна головная боль
Kubernetes изначально разработан для Stateless-приложений — они ничего не хранят внутри контейнеров. При работе со Stateful-приложениями, хранящими данные, встает вопрос подключения внешних хранилищ.
Самый простой вариант, к которому часто прибегают, — поднять один NFS-сервер, но это решение для бедных: оно не обеспечит высокую доступность и сохранность данных. Если в медленный и ненадежный NFS будут ходить продакшен-сервисы с важными данными, могут возникнуть большие проблемы.
Для нормальной работы приложения без изменения его логики понадобятся Persistent Volumes — хранилища, связанные с подами. Они подключаются внутрь контейнеров как локальные директории, позволяя приложению хранить данные «под собой». Среди рабочих вариантов — CephFS, Glusterfs, FC (Fiber Channel), полный список СХД можно посмотреть в официальной документации.
Интеграция Kubernetes c Persistent Volumes — нетривиальная задача. Чтобы развернуть тот же Ceph, недостаточно взять мануал с Хабра и выполнить ряд команд. Плюс в дальнейшем СХД должен кто-то заниматься — опять нужен отдельный инженер, а то и несколько.
Если же Self-Hosted-кластер развернут не на железе, а на виртуальных машинах в облаке, то все немного проще — собственный кластер Ceph поднимать не нужно. Можно взять кластер хранилища у провайдера и научить его работать с кластером K8s, если провайдер готов предоставить вам API к своей системе хранения данных, что есть не везде. Писать интеграцию при этом придется самостоятельно.
Правда, у провайдеров, предоставляющих IaaS, можно арендовать объектное хранилище или облачную СУБД, но только если логика приложения позволяет их использовать. А в Managed-решениях Kubernetes уже «из коробки» есть интегрированные Persistent Volumes.
Отказоустойчивость кластера — отдельная проблема
С Kubernetes проще обеспечить отказоустойчивость приложений, однако потребуется еще и реализовать отказоустойчивость кластера.
В Kubernetes есть мастер-нода, непосредственно управляющая кластером и содержащая его конфигурацию, метаданные и статусы объектов Kubernetes. Отказоустойчивый кластер включает три мастер-ноды, отдельные от самого кластера и дублирующие друг друга. Каждая нода — отдельный сервер или виртуальная машина, их не могут использовать бизнес-приложения. То есть их нужно отдельно подключать и обслуживать либо оплачивать аренду в облаке.
Это создает сложности для малого бизнеса: раньше для всех приложений требовалось всего два сервера, а с Kubernetes только ради отказоустойчивости нужно три дополнительных сервера.
Также в кластере Kubernetes есть прекрасная фича — встроенный механизм самовосстановления. Если одна из нод выходит из строя, то все процессы, ранее работающие на этой ноде, автоматически перезапускаются на других нодах кластера. Вот только чтобы это произошло, на остальных нодах нужен резерв по ресурсам. И его нельзя ничем занимать, иначе приложения не смогут переехать в случае проблем.
Резерв зависит от того, какое количество вышедших из строя нод вероятно в вашем случае:
Если проще, то это выглядит так: когда в кластере 10 нод и вы хотите без проблем пережить потерю одной ноды, то вам потребуется 10-процентный запас ресурсов. Если же приложения должны работать даже при потере 50% кластера, значит, на всех нодах нужен запас в 50%.
При этом лучше, если ноды в кластере небольшие по объему, но их много. Допустим, у вас есть пул ресурсов — 100 ГБ оперативной памяти и 100 ядер CPU. Такой объем позволяет запустить 10 виртуалок и 10 нод кластера Kubernetes. И в случае выхода из строя одной ноды вы теряете только 10% кластера.
На железных серверах такую конфигурацию не создашь. Например, используя 300 ГБ оперативной памяти и 50 ядер CPU, вы развернете всего 2–3 ноды кластера. И в случае выхода из строя одной ноды рискуете сразу потерять 30–50% кластера.
Получается, что риск того, что кластер «ляжет» вследствие сбоя или непредсказуемой нагрузки, на традиционной инфраструктуре выше. Кроме того, может быть так: специалисты без достаточного опыта не всегда могут заранее предусмотреть проблемы, понять, в чем их причина, и быстро устранить.
Автомасштабирование кластера — нетривиальная задача
Чтобы кластер всегда был готов к любой нагрузке и новые ноды подключались и отключались по необходимости, нужно реализовать автомасштабирование. То есть сделать так, чтобы ваши приложения автоматически получали нужные ресурсы в необходимом объеме.
Автоскейлинг приложений в кластере возможен на любой инфраструктуре — это делается средствами Kubernetes. А вот автоскейлинг кластера, который позволяет автоматически подключать и отключать ноды при изменении нагрузки, на Bare Metal реализуется только покупкой дополнительных серверов. Значит, заказываем их и ждем — сразу масштабироваться не выйдет.
Плюс если мы говорим о Self-Hosted на Bare Metal, то все серверы, необходимые для работы приложений на случай нагрузки, придется держать в рабочем состоянии и постоянно за них платить.
Если Self-Hosted-кластер развернут на IaaS, то схема похожая: инженер добавляет новую виртуальную машину и вносит ее в кластер. Другой вариант — взять API провайдера, если он его предоставляет, подключить через него кластер Kubernetes, научить его запускать для себя новые серверы и так реализовать автомасштабирование. Но потребуется разрабатывать отдельное решение — это сложная задача, предполагающая высокий уровень экспертности в Kubernetes и облаках.
Кроме того, для быстрого масштабирования Self-Hosted-кластера на IaaS придется резервировать нужное количество ресурсов провайдера и создавать из них новые виртуальные машины по мере надобности. И за эти зарезервированные ресурсы придется платить: практика брать плату за выключенные ресурсы бывает у реселлеров VMware. На нашей платформе в случае отключенных ВМ вы не платите за ресурсы, только за диски. В некоторых Managed-решениях автоскейлинг включается по кнопке, уточните эту возможность у вашего провайдера.
Подводные камни Self-Hosted Kubernetes
Рассчитывайте ваши возможности при старте проекта. То, какие ресурсы есть у вашей компании, ваш бэкграунд, навыки и другие детали сильно влияют на выбор решения, насколько вам будет выгодно разворачивать Kubernetes самостоятельно или лучше это сделать в облаке с помощью готового сервиса. И не забываем главный вопрос всего Kubernetes: нужна ли вообще эта технология на вашем проекте, как и для чего вы собираетесь ее использовать?
Тут можно почитать, как устроен наш Kubernetes aaS на платформе Mail.ru Cloud Solutions: что у него под капотом и что в него еще входит, кроме собственно Kubernetes.
А подключить его можно здесь. Новые пользователи получают 3000 бонусов для тестирования этого и других сервисов после полной верификации аккаунта.