Как узнать, подходит ли Kubernetes для вашего SaaS

1656667221 kak uznat podhodit li kubernetes dlya vashego saas

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

  • Незнание контейнерной технологии
  • Архитектура программы не способствует использованию преимуществ Kubernetes
  • Увеличение количества усилий по сравнению с затраченным временем

Если вы заинтересованы в Kubernetes, но не уверены, что вам нужно инвестировать время/ресурсы, эта статья для вас.

Каков ваш опыт работы с контейнерами? ?

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

Контейнеруйте свою программу

AZhfT1f8jS0KnbLrYz7QXj1LYdXd9pADqp2r

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

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

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

Поймите, как работает хранилище

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

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

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

Поймите, как работает сеть

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

Разрешает ли Kubernetes проблемы, с которыми вы сейчас сталкиваетесь? ?

zqFzeEAsKrXpWWtkZBdh-ju7DgxgV4-RvEcz

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

Вот несколько проблем, которые, по моему мнению, Kubernetes отлично решает, пытаясь иметь дело с контейнерами в масштабе.

Увеличение ресурсов

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

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

Выполнение массовых обновлений

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

// Update all the pods of frontend to a new image tag
$ kubectl rolling-update frontend --image=image:v2

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

Самовосстановление

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

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

Нужно ли будет изменить архитектуру вашей программы?

I0-fuTV0uXQR1xoGvWjcyCI-eDJLgJlkrxHZ
Иногда адаптация программы к Kubernetes похожа на вставление квадратного колка в круглое отверстие

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

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

Время запуска программы важно

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

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

Адаптация мультитенантной архитектуры сложна

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

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

Обычно я вижу два типа архитектур во время работы с Kubernetes:

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

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

Переход к программе без состояния требует больших усилий

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

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

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

Стоит ли использовать Kubernetes? ?

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

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

Хотите подключить Kubernetes к своему SaaS? Поговорим – ben@servicebot.io

Doj-pHbdszxakMEVRnRFpJmZdW8nkJmsKoXo

Добавить комментарий

Ваш адрес email не будет опубликован.