Связаться по Skype: vkarabedyants
Позвонить Написать
+7 (499) 404-28-83

Блог о системном администрировании серверов и сайтов

Установка, настройка программного обеспечения Linux, Windows операционных систем

Как определить подходит ли Kubernetes для вашего SaaS

Kubernetes — это прекрасная технология, с помощью которой лично я увидел прогресс в моих возможностях масштабировать, внедрять и управлять своим SaaS. Но не все сразу же начнут извлекать пользу от его использования по нескольким причинам:

  • Отсутствие опыта работы с контейнерной технологией
  • Архитектура приложения не способствует использованию преимуществ Kubernetes
  • Больше усилий по сравнению с затраченным временем

Если вы заинтересовались Kubernetes, но все еще сомневаетесь, стоит ли тратить на него время и необходимые ресурсы, то это статья для вас.

Насколько вы опытны в работе с контейнерами?

Чтобы понять, на что способен Kubernetes, сперва нужно знать, какая польза от контейнеров. Прежде, чем потратить время на Kubernetes вам нужно:

Контейнезировать приложение

Прежде всего, ваше приложение должно быть контейнеризировано. Это означает определение шагов, необходимых для получения базового образа ОС и установки приложения на него в файле (обычно это Dockerfile).

Прохождение через этот процесс так же, как и задание переменных среды необходимых для настройки приложения ( URL, имя пользователя и пароль базы данных, который использует ваше приложение) будут иметь решающее значение для создания образа контейнера, который может использоваться Kubernetes.

Также примите во внимание зависимости, необходимые для функционирования вашего приложения и ознакомьтесь с использованием их контейнеризированной версии.

Понять, как работает хранилище

Контейнеры созданы для того, чтобы содержать код, необходимый для запуска приложения.Любые постоянные данные необходимо хранить в другом месте, так как процесс разрывания и разворачивания контейнеров (очень распространено при работе с контейнерами) также уничтожает любые данные, хранящиеся в файловой системе этого контейнера.

При рассмотрении Kubernetes очень важно знать, как контейнерное хранилище должно работать и как справиться с такими вещами, как резервное копирование данных, перемещая эти данные между контейнерами, и доступ к данным вне контейнера.

Kubernetes с помощью, например, автоматического резервирования упрощает управление хранилищем. Это дает возможность вашему хранилищу (например, AWS EBS) создавать новые тома «на лету», поскольку создаются новые контейнеры, автоматически устанавливая их.

Понять, как работает сеть

В зависимости от того, как вы внедряете сеть, в большой степени зависит использование Kubernetes. Новичку важно знать, как открыть специфические системы для публичной сети и скрыть другие, такие, как базы данных, при поддержке связи между сервисами. Еще более сложными операциями, которые мне нужно было изучить, было то, как интегрировать балансировку нагрузки, а также предоставить экземпляру каждого клиента собственное имя хоста (вещи, которые Kubernetes делает намного проще).

Решает ли Kubernetes текущие проблемы?

Если вы не используете контейнеры для внедрения вашего приложения, то, скорее всего, вам еще не следует использовать Kubernetes. Kubernets направлен на решение проблем, возникших в процессе проверки и масштабирования инфраструктуры, основанной на контейнерах.

Вот несколько проблем, которые Kubernetes легко решает при попытке справиться с контейнерами во время масштабирования

  • Расширение ресурсов

Kubernetes – это, в основном, кластер узлов, которые предоставляют вычислительные ресурсы, которые могут потребляться рабочими нагрузками контейнеров. Эта кластерная архитектура позволяет очень просто увеличивать или уменьшать ресурсы. Вам только нужно добавлять или удалять узлы из кластера, а Kubernetes автоматическииспользует эти ресурсы или переназначит рабочую нагрузку на существующие ресурсы.

Большинство проблем, с которыми я встретился, были устранены таким способом, потому что я совершил переход от одного сервера, который я должен был масштабировать (раздражающий ручной процесс), чтобы иметь возможность масштабировать мою инфраструктуру с помощью одной команды с использованием CLI.

  • Осуществление массовых обновлений

Другая проблема, решаемая Kubernetes – это возможность обновлять все ваши контейнеры. Раньше я писал shell-скрипты, которые собирали каждый соответствующий контейнер и воссоздавали его с помощью нового тега образа. Процесс занимает более часа, и я не смог проверить прошло ли обновление успешно. С Kubernetes я смог выполнить обновление с помощью одной команды, как в примере ниже:

Kubernetes также позволяет вам обновлять любую часть Kubernetes (сети, хранилище и т. д.) с помощью команд, основанных на любых критериях. Это огромный шаг вперед от написания собственных скриптов для внесения изменений в инфраструктуру.

  • Самоизлечение

Последней и одной из самых важных частей Kubernetes, о которой я бы хотел поговорить, — это способность к самоизлечению. Если Kubernetes обнаруживает, что что-то не так с частью его инфраструктуры, например, если узел не отвечает или контейнер не проходит проверку работоспособности, он будет выполнять шаги по воссозданию этих частей, пока все не начнет снова работать.

Это чрезвычайно полезно, потому что, если часть кластера по какой-либо причине перестает работать, рабочая нагрузка будет переназначена, и вы можете даже заставить Kubernetes воссоздать целые серверы, чтобы устранить проблему.

Нужно ли изменяться вашей архитектуре приложения?

Иногда адаптация приложения к Kubernetes похожа на квадратный колышек в круглом отверстии.внедрение кубернетес

Когда я перешел на Kubernetes, не было большого количества изменений, которые я должен был совершить, потому что он первоначально был спроектирован как платформа с несколькими экземплярами, развернутая через контейнеры.

Вот то, что я изучил, перемещая мои рабочие процессы в Kubernetes.

  • Время запуска вашего приложения важно

При создании новоговнедрения, вам нужно дождаться, когда ваше приложение начнет работу до того, как оно станет доступным для конечного пользователя. Проблемой становится, если ваш процесс развертывания включает в себя создание новых экземпляров, когда конечный пользователь нажимает кнопку или выполняет обновления во всех экземплярах ваших клиентов, поскольку для этого требуется пересоздание контейнеров.

При переходе на Kubernetes вам может потребоваться внести некоторые изменения в вашу кодовую базу, чтобы сделать процесс запуска более эффективным, чтобы конечный пользователь не былоплохого опыта использования вашего продукта.

  • Адаптация многопользовательских архитектур сложна

Многопользовательская архитектура означает, что у вас есть один экземпляр вашего приложения, который управляет всеми вашими конечными пользователями в разделенных «арендованных» участках, обычно с единой базой данных, разделенной между всеми.

Если ваше приложение не создано для использования кластеризации (несколько серверов, действующих как один инстанс), вам еще не следует использовать Kubernetes.

В общем, я вижу два типа архитектур при работе с Kubernetes:

  • Multi-instance с одним экземпляром приложения для каждого клиента
  • Многопользовательская архитектура с возможностями кластеризации, поскольку они могут использовать масштабирование ресурсов

Я лично предпочитаю multi-instance, потому что их намного проще внедрить по сравнению с кластерной многопользовательской архитектурой. Кроме того, работа, связанная с переходом от многопользовательского к multi-instance, не так уж плоха по сравнению с добавлением возможностей кластера к multi-instance архитектуре.

Переход на приложение «без состояния» требует больше количество усилий.

Одной из отличных особенностей Kubernetes является возможность масштабирования количества блоков в развертывании. Но, если ваше приложение не кластеризовано или не является «без состояния», эта функция теряется, поскольку дополнительные модули в развертывании не будут правильно настроены и не могут быть использованы.

Процесс использования несостояния в Kubernetes часто приносит большое количеством проблем, которых он не стоит, так как в большинстве случаев вам придется полностью переработать способ обработки конфигурации в своем приложении.

Не теряйте дух, если вы не хотите тратить время, чтобы сделать ваше приложение без состояния или кластеризованным, поскольку существует множество способов адаптации развертывания с помощью состояния для использования Kubernetes. Но у них есть свои проблемы, о которых я не буду рассказывать в этой статье.

Стоит ли вам применять Kubernetes?

Задав себе эти вопросы, вы должны хорошо понимать, будет ли Kubernetes хорошо подходить вам в данный момент времени. Большинству стартапов на начальных этапах, вероятно, он не понадобятся, а у более зрелых есть необходимость инвестировать в другие технологии, поэтому переключение было бы невозможным.

Я думаю, что лучший пример для кого-то, кто переходит в Kubernetes, — это стартап, стремящийся перейти от облачной инфраструктуры с минимальной жизнеспособностью, которая использует контейнеры для увеличения рабочих нагрузок на продуктивную более стабильную. Именно у меня был такой случай, и я могу сказать, что у меня были периодические простои из-за плохого управления ресурсами и перегруженных серверов, чтобы не беспокоиться о моей инфраструктуре благодаря мощности Kubernetes.

Ваш проект вырос до необходимости Kubernetes, мы поможем внедрить и поддерживать управление контейнерами, обращайтесь [email protected]

Оставить комментарий

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.