Kubernetes исправляет некоторые вполне реальные проблемы. Но действительно ли это проблемы, с которыми вы сталкиваетесь?

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

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

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

Создается впечатление, что, хотя Docker и является отличной технологией, ему не хватает компонента, который связывает все это воедино. Kubernetes - именно такой компонент. Kubernetes решает все эти проблемы, особенно в полностью управляемой форме, предлагаемой облачными платформами, такими как Azure, AWS и DigitalOcean, абстрагируя их от конечного пользователя с помощью своих так называемых концепций.

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

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

Кривая обучения

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

Чтобы дать вам представление, вот общий обзор архитектуры Kubernetes:

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

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

  • Deployment объект, представляющий ваше приложение
  • ReplicaSet для масштабирования Pod (ов), связанных с вашим развертыванием
  • Необязательно, один или несколько Service (s), которые отвечают требованиям вашего развертывания к сети.
  • Один или несколько Pod (s), которые представляют фактические контейнеры. Это лучшее зерно в архитектуре Kubernetes.

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

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

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

Требуется ли масштабирование приложения?

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

Эта функция очень ценна, если в приложении есть один или несколько горячих компонентов, которые должны иметь возможность справляться с внезапными всплесками активности - например, службы аутентификации для онлайн-игр, которые могут внезапно увеличивать количество запросов на вход при каждом новом расширении или его добавлении. запущен. Или для игр, которые становятся невероятно популярными после запуска и требуют быстрого масштабирования инфраструктуры, не беспокоясь о сети, хранилище и всем остальном. Примером такой игры является Pokémon Go, которая сразу после запуска увидела огромный приток игроков. Они широко использовали Kubernetes для обслуживания огромного количества игроков по всему миру.

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

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

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

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

Запуск микросервисов

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

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

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

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

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

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

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

Заключение

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

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

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

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

Иногда это хорошо подходит, но определенно не всегда.