Внедрение Kubernetes — когда это необходимо?

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

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

А для тех, кто всё-таки решил «попробовать» этот оркестратор, в конце статьи будет небольшой туториал по созданию безопасного кластера Kubernetes.

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

В CI/CD с контейнерами работать намного проще — можно построить надёжный конвейер, практически ничего не перенастраивая. И у Kubernetes есть интересные функции для ИТ-инженеров, которые делают оркестрацию контейнеров более управляемой — тот же автоскейлинг (автомасштабирование) или такой компонент платформы, как Kubelet, который автоматически запускает и останавливает контейнеры приложений при обнаружении проблем. Однако чаще всего действительно выигрывает от всего этого лишь масштабная оркестрация.

Kubernetes больше подходит для высоконагруженных, масштабируемых big-data проектов, в которых нужно работать с обилием контейнерных кластеров и облачных PaaS/IaaS-решений. Именно поэтому контейнеры и Kubernetes используют такие гиганты, как Google, Amazon, Tinder, BlaBlaCar, CERN, Huawei, Microsoft.

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

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

Если в ваших проектах можно справиться со сложностью системы силами монолитной архитектуры, то это решение будет более предпочтительным, чем использование микросервисов. Либо, если стало сложно поддерживать код, то можно решить проблему, «нарезав» проект на микросервисы, у которых есть свой интерфейс, и управлять ими либо без оркестратора, либо менее сложным оркестратором. Вертикальное масштабирование может оставаться эффективным, если нет большого объёма данных и больших нагрузок: общий размер баз до 50 Гб, таблицы до 1 млн. записей, сетевые нагрузки до 50 запросов/сек. Придерживаться рамок монолитной архитектуры стоит и тогда, когда нет возможности распределять работу между разными командами. Если проблема в безопасности, её можно решить оборачиванием запросов к БД в хранимые процедуры. Есть и другие способы решать возникающие проблемы без перехода к Kubernetes.

Если бюджет не рассчитан на высокую оплату труда дополнительных специалистов, то стоит посмотреть в сторону использования виртуальных машин, которые создаются с помощью системы управления конфигурациями Ansible и не требуют высокой квалификации обслуживающих сотрудников или более простых систем оркестрации. В практике нашей компании есть кейсы, когда мы снимали клиентов «с иглы» Kubernetes, и они до сих пор нам благодарны. Например, к нам обратился клиент с проблемами на сервере, находящемся на co-location: сервер постоянно сбоил, перезагружался, имел аппаратные проблемы, время простоя на продуктивной среде составляло до 30 минут в неделю. Архитектура изначально была настроена на Kubernetes и по мнению многих компаний, к которым клиент обращался до нас, ликвидация проблем вышла бы очень дорого.

Мы же перенесли инфраструктуру со сложной системы оркестрации Kubernetes на более простую и понятную для клиента систему оркестрации контейнеров Docker Compose. Также были проведены все необходимые настройки, а инфраструктура поставлена на мониторинг и на техническую поддержку. Данный «downgrade» позволил в сжатые сроки вернуть на рельсы собственный процесс разработки в компании, и каждый разработчик смог сам без помощи DevOps инженеров развернуть локальную тестовую среду у себя на рабочем месте. В результате накопившиеся за несколько месяцев ошибки и баги были очень быстро исправлены, протестированы и, опять же, без помощи DevOps инженеров была обновлена продуктивная среда. На продуктивной среде был реализован простой и понятный способ резервного копирования и восстановления на общей тестовой среде, и каждый разработчик смог получить для разработки последнюю версию БД и статического контента для полноценного QA-тестирования.

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

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

Бесплатные

• Docker Compose
• Docker Swarm
• Apache Mesos/Marathon
• Vagrant
• Panamax
• Cloudify
• Deis

Условно бесплатные (freemium)

• Microsoft Azure Container Service
• Heroku

Платные

• Nomad
• Amazon EC2 Container Service
• AZK
• appfleet

Также на рынке есть такие продукты как Rancher — OpenSource решение, которое упрощает и систематизирует работу с кластерами Kubernetes, и RedHat OpenShift — платформа Enterprise-класса.

Руководствуясь нашим опытом, отдельно отметим, что в продуктивных средах мы зачастую предлагаем своим клиентам выкладывать код на виртуальных машинах — это безопаснее. Мы уверены, что старая добрая виртуализация как решение не так страшна и в некоторых случаях более надежна. Например, выход за пределы контейнера через 0-day уязвимость cgroups — гораздо менее затратная по количеству приложенных злоумышленниками усилий операция, чем проникновение на отдельный виртуальный хост, в арсенале которого могут быть применены политики SELinux и набор практик по OS hardening.

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

Да, Kubernetes — удобный инструмент, но для крупных проектов. Это удобство послужило причиной тому, что оркестратор стал хайпом в инженерной среде. Однако популярность Kubernetes не означает, что он подойдёт и вам. На практике небольшие и среднего масштаба приложения могут даже «проиграть» из-за его использования. Вам следует тщательно оценить требования к проекту и проверить, какой инструмент будет успешно справляться с его задачами, но будет требовать меньше вашего внимания и денег компании.

При выборе Kubernetes в качестве оркестратора контейнеров используйте следующий гайд по обеспечению безопасности.