Про Kubernetes все уши прожужжали. А нужен ли он вашему проекту?

Недавно мы писали статью на VC про аудит Kubernetes. И получили несколько личных сообщений примерно такого характера: "А вы можете по-человечески объяснить, зачем и в каких случаях этот кубернетис нужен? А то все ставят, все хвалят, а понять, нужен ли он моему проекту, — не получается..."

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

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

Давайте представим, что большое приложение — это дом. В нём нельзя просто убрать одну из стен, другую переместить, а третью переделать на лету из какого-то совершенно иного материала: дом станет неустойчивым или вообще рассыплется. А теперь представим, что приложение похоже на улей. В нём гораздо проще передвигать и изменять соты… Но когда в улье десятки тысяч компонентов, этих микросервисов, и все они работают сами по себе, появляется вопрос: как этим всем управлять? Как узнать, что все они правильно общаются между собой и что ничего не отвалилось? Как не сойти с ума, дирижируя этим оркестром?

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

С точки зрения бизнеса будет правильнее сказать: «Мы решили быть гибкими, способными легко подстраиваться под запросы рынка и внедрять фичи быстрее конкурентов. И для этого используем подходящую из доступных технологий». А доступная технология, в свою очередь, сейчас это Kubernetes.

Чтобы найти ответ на вопрос "почему?" из заголовка, полезно понять, почему же другие компании стали использовать Kubernetes, какой в этом был бизнес-интерес. Примерить на себя, подходит ли компании переход к микросервисной архитектуре и DevOps. И если да, то имеет смысл внедрить Kubernetes. Но не «внедрить Kubernetes и всё», а изменить процесс разработки.

Исследование DORA's State of DevOps подсказывает, какие понадобятся изменения, и одно из самых существенных — это сокращение цикла разработки от идеи до доставки пользователю. Чем он короче, чем чаще разработчик выкладывает свой код в продакшен-окружение, тем ниже риск аварий и тем выше гибкость. Частые изменения позволяют быстро проверять гипотезы, но при этом, так как они малы, меньше вероятность серьезных аварий. А если всё же что-то пошло не так, изменения легче откатить и устранить последствия аварии.

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

Раньше, когда эксперимент оказывался неудачным и пользователи требовали «вернуть стену», нужно было откатывать всё приложение на предыдущую версию, разворачивать бэкапы, чтобы вернуть структуру данных, и грустить. Теперь же с современными технологиями можно сделать небольшой редизайн и проверить его на части аудитории (часто экспериментируют на отдельных странах, например, Турции), посмотреть на реакцию пользователей и дальше уже по ситуации, распространить на всех, либо немедленно откатить. К тому же в DevOps-идеологии и с использованием возможностей, которые дают Kubernetes и микросервисная архитектура, меньше ресурсов требуется на тестирование. Так как изменения маленькие, то в процессе разработки новой фичи тестирование и анализ занимают небольшое место. Потому что, если окажется, что есть проблема и она простая, — мы исправим её за несколько минут и выкатим новую версию. Если проблема серьезная — быстро откатимся к предыдущей версии и пользователи не пострадают. Если будет ошибка в тестировании — проверим на стране с маленьким трафиком, поймём, что нужно оптимизировать, и пустим больше трафика. Это всё также сокращает цену эксперимента.

Kubernetes дает унификацию в способе обслуживания всего «улья приложений». Можно сказать, что это задача любой системы оркестрации, но Kubernetes здесь де-факто стандарт. С практической точки зрения распространённость Kubernetes означает уверенность в том, что это решение, которое:

Большое сообщество вокруг ПО — важный (если не решающий) момент. Например, вспомним ситуацию с операционными системами лет пятнадцать лет назад: кроме Linux, были ещё FreeBSD, SunOS и др. У них были свои преимущества, но так получилось, что Linux стал популярней. Во многом это произошло, потому что у Linux была большая группа поддержки, многие люди его использовали, работали над улучшениями и продолжают это делать. С технической точки зрения Kubernetes на своём сайте акцентирует внимание на трёх преимуществах. Попробуем объяснить, что все они значат на практике.

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

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

Kubernetes не нужен:

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

Если вы всё-таки берётесь за внедрение Kubernetes, то нужно решить ещё один вопрос: поднимать его на выделенных серверах или в облаке.

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

К тому же облачные провайдеры уже справились с болезнями стабильного дискового хранилища, с которыми придётся столкнуться при разворачивании кластера на собственных серверах. Нет смысла набивать собственные шишки, когда есть AWS, Google Cloud, Azure Cloud, DigitalOcean и российские Яндекс.Облако, Selectel, Mail.Ru Cloud Solutions и другие. С точки зрения гибкости, для которой, собственно, и применяется Kubernetes, правильно использовать их.

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

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

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

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

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

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

Если вы по-прежнему не понимаете, почему все вокруг говорят Kubernetes и зачем он конкретно вам — то и нафиг он вам нужен. Серьёзно.

А если не хотите отставать от лидеров, но вам нужна помощь с адаптацией инфраструктуры под работу с контейнеризированными приложениями или с тем, как, собственно, измениться, — вы знаете, как её найти :-)

#kubernetes #devops #itsumma