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

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

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

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

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

«Почему? — Говорят, он всё решит»

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

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

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

Главное бизнес-преимущество DevOps — снижается количество инвестиций на проверку теорий и запуск новой функциональности.

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

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

В чём польза Kubernetes?

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

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

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

С технической точки зрения Kubernetes на своём сайте акцентирует внимание на трёх преимуществах. Попробуем объяснить, что все они значат на практике.

• Масштабируемость любого уровня. С использованием технологий Kubernetes при правильной архитектуре масштабирование происходит автоматически. Если нагрузка выросла, просто добавляем новые узлы, новые серверы, и без проблем обслуживаем больше пользователей. В мире облаков, где добавить новый сервер предельно просто, это суперудобно.
• Бесконечная гибкость. Неважно, насколько сложно написано приложение, — благодаря Kubernetes, будет легко подстроить структуру. Вся инфраструктура описывается в конфигурационных файлах, на понятном языке, который знает много людей. Это даёт унифицированный доступ к ресурсам кластера и тому, как запускаются и работают приложения. Вторая сторона — это гибкость управления самим приложением. В Kubernetes огромное количество работы сделано за нас, поэтому запуск приложения в продакшен или организация Blue-Green-тестирования не требует перестройки всех систем.
• Может быть запущен где угодно. Kubernetes как язык эсперанто, на нём говорят все большие облачные провайдеры. Если потребуется сменить провайдера, это будет довольно просто сделать с помощью тех самых конфигурационных файлов. Можно без проблем поднять в AWS такой же кластер, как был в Google Cloud. Это снижает риски, связанные с провайдерами инфраструктуры.

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

Когда Kubernetes не нужен?

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

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

Kubernetes не нужен:

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

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

Где разворачивать Kubernetes?

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

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

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

Какие затраты учесть, готовясь внедрять Kubernetes?

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

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

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

Меняться всё равно придется. И переход на Kubernetes, скорее всего, — это необходимый вклад, чтобы не остаться на месте навсегда.

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

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

Вместо вывода

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

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

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