Идея самостоятельного развертывания кластера Kubernetes на собственных серверах или в облаке выглядит привлекательно: кажется, это дешевле, чем платить за Managed решение от провайдера.
На самом деле все не так просто: на практике могут обнаружиться скрытые затраты и подводные камни.
В то же время для крупных компаний Self-Hosted может быть вариантом, поскольку у них есть условно-бесплатные ресурсы и штат специалистов для поддержки технологии, а иногда даже горячее желание строить и развивать свою платформу любой ценой.
А вот с малым и средним бизнесом ситуация немного иная; решение необходимо взвесить со всех сторон.
Я Дмитрий Лазаренко, директор по продукту облачной платформы.
Облачные решения Mail.ru (MCS) .
В этой статье я расскажу вам, каковы особенности развертывания Self-Hosted Kubernetes-кластера и что нужно знать перед началом.
Для начала вам понадобятся время, деньги и администраторы, понимающие Kubernetes.
Первая статья затрат — для специалистов, которые умеют работать с этой системой и смогут обслуживать кластер.Эти ребята дорогие, их не так много на рынке, и их сложно нанять.
Почему Kubernetes сильно увеличивает стоимость специалистов? Развернуть кластер вроде бы несложно; для этого есть инструмент. официальная документация и монтажники, например Кубеспрей или Кубеадм .
Однако если в компании есть инженер, который может прочитать строчку документации и разобраться, как установить Kubernetes на серверы с помощью одной команды, это еще не все, его работа на этом не остановится.
На самом деле развертывание кластера — это только полдела.
В таком виде он будет работать до первой проблемы, которая неизбежно возникнет через неделю или месяц.
Например, поды перестанут создаваться из-за неправильной конфигурации ресурсов в контроллере-менеджере.
Либо кластер начнет нестабильно работать из-за проблем с диском с etcd. Либо CronJob, запущенный из-за ошибок контроллера-менеджера, начнет бесконечно плодить новые поды.
Или в кластере возникнут сетевые ошибки из-за неправильной конфигурации DNS. В общем, проблем может быть много, поэтому нужен отдельный человек, который знает, как развернуть кластер, как его отлаживать, как запускать приложения в производственной среде.
Кроме того, вместе с Kubernetes в компании появляются новые потребности, такие как мониторинг для выявления ошибок, система хранения данных и сбор логов.
Кластер необходимо развивать, чтобы получить ожидаемую прибыль от технологии.
Это требует времени, поэтому даже опытный администратор не сможет уделить неделю настройке кластера и несколько часов администрированию.
Скорее всего, вам понадобится штатный человек, который будет заниматься только Kubernetes, поддержкой и развитием кластера.
В крупной компании может быть создан отдел поддержки инфраструктуры.
Конечно, если вы запускаете Kubernetes только ради развертывания контейнеров, то разбираться и развивать кластер вам не обязательно.По этой причине Self-Hosted Kubernetes в большинстве случаев могут успешно запустить только крупные компании, где есть возможность выделить сотрудников для обслуживания кластера и нет необходимости экономить ресурсы.Но тогда возникает вопрос: зачем вам Kubernetes? Вы можете использовать инструмент, который проще в настройке и поддержке, например Docker Swarm. Если вам нужно что-то простое от Kubernetes, просто не используйте его.
Нет смысла тратить время на развертывание кластера только для запуска простого кода.
Эта технология предназначена для проектов, где разработка ведется постоянно, часто выходят новые релизы и необходимо соблюдать требования HighLoad.
Кроме того, развертывание кластера самостоятельно — процесс не быстрый.
Если вам нужно в короткие сроки запустить кластер для проекта или тестовых сред, то с Self-Hosted это не получится: развертывание займет несколько часов, а то и недель.
Вы должны быть к этому готовы.
Для сравнения: в облаке можно запустить KaaS-кластер за 10 минут и сразу же его использовать, но это происходит потому, что специалисты провайдера уже заранее поработали над инфраструктурной частью.
Kubernetes требует прокачки: сам по себе не работает
Как я уже говорил выше, Kubernetes — это отдельная экосистема, с которой нужно разобраться и подключить к ней дополнительные инструменты.Если вы возьмете Self-Hosted, то все это вам придется делать самостоятельно.
Все инструменты, дополняющие Kubernetes, представляют собой решения с открытым исходным кодом, которые необходимо настраивать.
Вам потребуется установить систему мониторинга в кластере, реализовать балансировку нагрузки, собирать и хранить логи, настройки безопасности и авторизации пользователей, сети и многое другое.
Например, вам нужно будет следить как за самим кластером, так и за приложениями в нем.
Более того, стандартного мониторинга через Zabbix вам будет недостаточно; вам понадобится конкретный — Прометей или Телеграф.
С логами ситуация аналогичная: из коробки вы получаете только историю логов уже запущенных приложений; при перезапуске оно исчезнет. Вы не сможете вручную собирать логи из Kubernetes; вам необходимо подключить сборщики журналов, такие как Fluentd, и систему хранения, такую как Elasticsearch или Loki. Отдельно придется разобраться с балансировкой нагрузки: понадобится отказоустойчивый балансировщик типа MetalLB.
Системы хранения данных для Self-Hosted Kubernetes — еще одна головная боль
Kubernetes изначально разрабатывался для приложений без сохранения состояния — они ничего не хранят внутри контейнеров.При работе с Stateful-приложениями, хранящими данные, возникает вопрос о подключении внешнего хранилища.
Самый простой вариант, к которому часто прибегают, — это установка одного NFS-сервера, но это решение для бедных: он не обеспечит высокую доступность и сохранность данных.
Если производственные сервисы с важными данными переходят на медленный и ненадежный NFS, могут возникнуть большие проблемы.
Для нормальной работы приложения без изменения его логики вам потребуются Persistent Volumes — единицы хранения, связанные с подами.
Они подключаются внутри контейнеров как локальные каталоги, что позволяет приложению хранить данные «внизу».
Рабочие варианты включают CephFS, Glusterfs, FC (Fibre Channel), полный список систем хранения можно найти в официальная документация .
Интеграция Kubernetes с постоянными томами — нетривиальная задача.
Чтобы развернуть тот же Ceph, недостаточно взять мануал с Хабра и выполнить ряд команд. Плюс в дальнейшем кто-то должен заботиться о системе хранения — опять же нужен отдельный инженер, а то и несколько.
Если Self-Hosted кластер разворачивается не на железе, а на виртуальных машинах в облаке, то все немного проще — вам не нужно поднимать собственный кластер Ceph. Вы можете взять кластер хранения у провайдера и научить его работать с кластером K8s, если провайдер готов предоставить вам API для своей системы хранения, что не везде так.
В этом случае вам придется писать интеграцию самостоятельно.
Правда, у IaaS-провайдеров можно арендовать объектное хранилище или облачную СУБД, но только если логика приложения позволяет их использование.
А в решениях Managed Kubernetes уже встроены постоянные тома.
Отказоустойчивость кластера — отдельная проблема
С Kubernetes проще обеспечить отказоустойчивость приложений, но вам также потребуется реализовать отказоустойчивость кластера.У Kubernetes есть главный узел, который напрямую управляет кластером и содержит его конфигурацию, метаданные и статусы объектов Kubernetes. Отказоустойчивый кластер включает в себя три главных узла, отдельных от самого кластера и дублирующих друг друга.
Каждый узел представляет собой отдельный сервер или виртуальную машину; они не могут использоваться бизнес-приложениями.
То есть их нужно подключать и обслуживать отдельно или оплачивать аренду в облаке.
Это создает проблемы для малого бизнеса: раньше всем приложениям требовалось только два сервера, а с Kubernetes просто для отказоустойчивости нужно три дополнительных сервера.
Также у кластера Kubernetes есть отличная особенность — встроенный механизм самовосстановления.
Если один из узлов выходит из строя, то все процессы, ранее работавшие на этом узле, автоматически перезапускаются на других узлах кластера.
Но чтобы это произошло, остальным узлам нужен резерв ресурсов.
И его нельзя ничем занять, иначе приложения не смогут двигаться в случае проблем.
Резерв зависит от того, сколько вероятно вышедших из строя узлов в вашем случае:
- Если у вас одна стойка серверов в одном дата-центре, то, скорее всего, одновременно выйдет из строя максимум один узел на одном сервере, например, из-за ошибок ОС.
Это означает, что вам нужен резерв для одного узла.
Конечно, стойка может сломаться, но здесь нужна избыточность без использования Kubernetes.
- Если у вас несколько стоек серверов, то есть вероятность потери одной стойки, например из-за проблем со свитчем, когда все сервера в ней станут недоступны.
Это значит, что нам нужен резерв, равный количеству серверов в одной стойке.
- Если у вас несколько дата-центров, то в каждом нужно держать резерв размером с другой дата-центр, чтобы приложения работали в случае его выхода из строя.
Если приложения должны работать даже при потере 50% кластера, то всем узлам нужен резерв в 50%.
В этом случае лучше, если узлы в кластере будут небольшими по размеру, но их будет много.Получается, что риск выхода кластера из строя из-за сбоя или непредсказуемой нагрузки выше в традиционной инфраструктуре.Допустим, у вас есть пул ресурсов — 100 ГБ ОЗУ и 100 ядер ЦП.
Этот том позволяет запустить 10 виртуальных машин и 10 узлов кластера Kubernetes. А если один узел выйдет из строя, вы потеряете всего 10% кластера.
На железных серверах такую конфигурацию создать нельзя.
Например, используя 300 ГБ ОЗУ и 50 ядер ЦП, вы развернете всего 2–3 узла кластера.
А если один узел выйдет из строя, вы рискуете сразу потерять 30–50% кластера.
Кроме того, может быть и так: специалисты без достаточного опыта не всегда могут заранее предвидеть проблемы, понять, в чем их причина, и быстро устранить их.
Автомасштабирование кластера — нетривиальная задача
Чтобы кластер всегда был готов к любой нагрузке и новые узлы подключались и отключались по мере необходимости, нужно реализовать автомасштабирование.То есть позаботьтесь о том, чтобы ваши приложения автоматически получали необходимые ресурсы в необходимом объеме.
Автомасштабирование приложений в кластере возможно на любой инфраструктуре — это делается с помощью Kubernetes. А вот автомасштабирование кластера, позволяющее автоматически подключать и отключать узлы при изменении нагрузки, возможно только на Bare Metal путем покупки дополнительных серверов.
Это значит, что мы их заказываем и ждем — сразу масштабироваться не получится.
Плюс, если мы говорим о Self-Hosted on Bare Metal, то все серверы, необходимые для запуска приложений в случае нагрузки, придется поддерживать в рабочем состоянии и постоянно оплачивать.
Если Self-Hosted кластер развернут на IaaS, то схема аналогичная: инженер добавляет новую виртуальную машину и добавляет ее в кластер.
Другой вариант — взять API провайдера, если он его предоставляет, подключить через него Kubernetes-кластер, научить его запускать для себя новые серверы и таким образом реализовать автомасштабирование.
Но вам потребуется разработать отдельное решение — это сложная задача, требующая высокого уровня знаний в Kubernetes и облаках.
Кроме того, для быстрого масштабирования Self-Hosted кластера на IaaS вам придется зарезервировать необходимое количество ресурсов провайдера и создавать из них новые виртуальные машины по мере необходимости.
И за эти зарезервированные ресурсы придется платить: у реселлеров VMware есть практика взимания платы за отключенные ресурсы.
На нашей платформе в случае отключенных ВМ вы не платите за ресурсы, только за диски.
В некоторых управляемых решениях автомасштабирование активируется нажатием кнопки; проверьте эту функцию у своего провайдера.
Подводные камни самостоятельного размещения Kubernetes
- Чтобы управлять кластером самостоятельно, нужен штатный специалист, хорошо знающий технологию и понимающий, как все работает внутри Kubernetes.
- В кластере потребуется настроить мониторинг, сбор логов, балансировку нагрузки и многое другое.
- Отдельная проблема — развертывание и интеграция системы хранения данных с кластером.
- Для обеспечения отказоустойчивости кластера потребуются дополнительные серверы или виртуальные машины — это дополнительные затраты.
- Для масштабирования кластера под нагрузкой необходим запас серверов или виртуальных машин — это еще одни дополнительные расходы.
Какие ресурсы есть у вашей компании, ваш бэкграунд, навыки и другие детали во многом влияют на выбор решения, насколько выгодно вам будет развертывать Kubernetes самостоятельно или лучше сделать это в облаке с помощью готового сервиса.
И не будем забывать главный вопрос всех Kubernetes: нужна ли эта технология вообще вашему проекту, как и зачем вы собираетесь ее использовать?
Здесь вы можете прочитать, как это работает наш Kubernetes aaS на платформе Mail.ru Cloud Solutions: что под капотом и что еще в него входит, помимо самого Kubernetes. А вы можете подключить его здесь .Теги: #Системное администрирование #Kubernetes #Облачные вычисления #контейнеризация #DevOps #оркестрация #облачные решения vk #облачные решения vk #облачные решения mail.ru #sysadministrationНовые пользователи получают 3000 бонусов на тестирование этого и других сервисов после полной верификации аккаунта.
-
Выбор Лучшего Агентства Веб-Разработки
19 Oct, 24 -
Скорость Передачи Lte И Dl
19 Oct, 24 -
Обзор: Puppet, Chef, Ansible, Salt
19 Oct, 24 -
Как Пропал Ноутбук Ашманова И Другие Курьезы
19 Oct, 24 -
Фонлайновый Движок
19 Oct, 24
