Self hosted что это
Эффективное использование 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 continuous integration систем
Введение
Сложно представить современную разработку без Continuous Integration. Многие компании выпускают по нескольку релизов в день и прогоняют тысячи тестов. Со времен Jenkins и Travis CI на рынке появилось много самых разнообразных инструментов. Большинство из них работают по модели SaaS — вы платите фиксированную плату за использование сервиса, или за количество пользователей.
Но использование hosted платформ не всегда возможно, например, если нельзя передавать код приложения, или не хочется зависеть от внешних сервисов. В таком случае выручают системы, которые можно установить на своих серверах (self-hosted). Бонусом вы имеете полный контроль над ресурсами и можете масштабировать их согласно вашим потребностям используя, к примеру, amazon ec2.
В этой статье представлен личный опыт использования нескольких opensource self-hosted continuous integration систем. Если вы использовали другие системы, расскажите об этом в комментариях.
Основные понятия
Основой любого CI является билд (build) — единичная сборка вашего проекта. Билд может собираться по различным триггерам — пуш в репозиторий, pull-request, по расписанию. Билд состоит из набора задач (jobs). Задачи могут выполняться как последовательно, так и параллельно. Набор задач задается перечислением всех задач или матрицей билда (build matrix) — характеристиками, по которым происходит разделение. Например, указанием версий языка программирования и переменных окружения — для каждой версии языка и каждого значения переменной будет создана своя задача.
В некоторых ci системах также есть конвейер задач (pipeline) — задачи объединяются в группы (stage), все задачи в текущей группе исполняются параллельно, следующая группа выполняется только если предыдущая группа завершилась успешно. Например, конвейер test — deploy: если все задачи в test завершились успешно, то можно запускать задачи из группы deploy.
Для эффективной работы ci важно наличие кэша — данных, которые используются для ускорения сборки. Это могут быть apt-пакеты, кэш npm, composer. Без кэша при запуске каждой задачи нужно будет заново скачивать и устанавливать все зависимости, что может занять времени больше, чем сам прогон тестов. Чем ближе расположен кэш к серверам, на которых выполняются задачи, тем лучше, например, если вы используете amazon ec2, то хорошим вариантом будет хранить кэш в amazon s3.
При выполнении билда могут генерироваться артефакты — результаты сборки, отчеты о чистоте кода, логи. CI-система, позволяющая просматривать и скачивать эти артефакты, существенно облегчает жизнь.
Если у вас большой проект с большим количеством одновременно запущенных задач, то вам не обойтись без масштабирования. Масштабирование бывает ручным и автоматическим. При ручном масштабировании вы сами запускаете и останавливаете runner-ы на свободных серверах. В случае автоматического масштабирования система сама решает, нужно ли создавать новые виртуальные машины и в каком количестве. Разные ci-системы поддерживают разных провайдеров — обычно это amazon, google compute, digital ocean и т.д.
Важным является то, как система запускает команды, указанные в конфигурации билда (executors). Есть несколько способов: непосредственное выполнение (на хосте, где запущен runner), выполнение в виртуальной машине, в docker-контейнере, через ssh. У каждого способа есть особенности, которые нужно учитывать при выборе ci-системы, например, при запуске задачи в docker-контейнере отсутствует сессия и терминал, из-за чего некоторые вещи не получится протестировать. А при выполнении на хосте не забывать о очистке ресурсов после окончания выполнения — удаления данных из бд, docker-образов и т.д.
Наконец, есть параметры, которые не критически важные, но делают работу с ci приятнее. Вывод лога — работает ли он в realtime режиме, или с каким-то интервалом? Можно ли прервать билд в случае проблем? Можно ли посмотреть конфигурацию билда и задачи?
Drone
Drone — система непрерывной интеграции, основанная на docker-контейнерах. Написана на языке Go. Текущая версия — 0.4, версия 0.5 находится в бете. В обзоре рассматривается версия 0.5.
Билд состоит из нескольких шагов, каждый шаг исполняется параллельно в отдельном docker-контейнере. Матрица билда задается за счет переменных окружения. Возможно использование сервис-контейнеров — например, если вы тестируете веб-приложение, которое работает с базой данных, то нужно задать docker-образ БД в секции services, и она автоматически будет доступна из build-контейнера. Можно использовать любые образы docker.
Drone состоит из drone server и drone agent. Drone server выполняет роль координатора, а один или несколько drone agent запускают билды. Масштабирование осуществляется за счет запуска дополнительных drone agent-ов. Возможности использовать облачные ресурсы для автозапуска агентов нет. Встроенной поддержки кэша не предусмотрено (есть сторонние плагины для загрузки и сохранения кэша на s3 хранилища).
Команды, указанные в билде, выполняются непосредственно в docker-контейнере интерпретатором sh, что создает проблемы, если нужно выполнять сложные команды с условной логикой.
Gitlab CI
Gitlab CI является частью проекта Gitlab — self-hosted аналога Github. Gitlab написан на ruby, а gitlab runner — на Go. Текущая версия gitlab — 8.15, gitlab runner — 1.9.
Поскольку Gitlab CI интегрирован с gitlab, то он использует только gitlab как репозиторий. Можно зеркалировать сторонние репозитории на gitlab, но на мой взгляд, это не очень удобно. Билд организован по принципу конвейера. Можно настраивать тип запуска задач — автоматически или вручную из веб-интерфейса.
Gitlab CI состоит из веб-интерфейса (координатора) и runner-ов. Координатор распределяет задачи по runner-ам, которые их выполняют. Есть большой выбор executors — shell, docker, docker-ssh, ssh, virtualbox, kubernetes. Лог билда не real-time — веб-интерфейс периодически опрашивает сервер, если появилась новая часть лога, то она добавляется в конец.
Имеется встроенная поддержка кэша, в качестве хранилища может использоваться любое s3-совместимое хранилище. Есть артефакты — можно просматривать отдельные файлы и скачивать артефакт целиком из веб-интерфейса.
Работа с облачными ресурсами организована с помощью docker mashine. При поступлении запроса на новый билд, если нет свободной машины, docker mashine создаст новую машину и запустит билд на ней. При этом образы, требуемые для билда, придется скачать заново, поэтому gitlab рекомендует поднять отдельный docker registry, который был бы в той же сети, что и провайдер docker mashine.
SimpleCI
SimpleCI — система непрерывной интеграции, которая была написана для максимально эффективного использования ресурсов. Frontend написан на php (Symfony3, es6), backend — на java. Текущая версия — 0.6, ведется активная разработка.
SimpleCI поддерживает github и gitlab репозитории. Билд, также, как и в gitlab, организован по принципу конвейера. Если все задачи в рамках одной стадии завершились успешно, то запускается следующая стадия.
Поддерживается работа с кэшэм. Кэш заливается в хранилище только, если в рамках задачи кэш-файлы изменились. Реализована работа с двумя типами хранилищ — s3-совместимым и google storage.
Билд выполняется путем запуска docker-контейнеров, подключения к build-контейнеру по ssh и запуску build-скрипта. Лог билда отображается в реальном времени (с помощью websockets и centrifugo).
Есть возможность автомасштабирования путем использования ресурсов облачных провайдеров (пока только google compute engine). При настройке масштабирования нужно указать snapshot, который будет использоваться при создании виртуальной машины. Это позволяет создать snapshot с необходимыми docker-образами, чтобы не загружать из каждый раз при создании новой машины. Поддержки артефактов пока нет.
Заключение
В обзоре представлено несколько self-hosted open source систем непрерывной интеграции. Кроме рассмотренных, также есть много hosted, коммерческих и открытых систем. Выбирая из всего многообразия CI-систем, обращайте внимание на то, что нужно вам, и тесты скажут вам спасибо.
Выбираем 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 или вообще ОС со своего образа, а ещё очень удобная панель управления серверами собственной разработки. Обязательно попробуйте!
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 бонусов для тестирования этого и других сервисов после полной верификации аккаунта.