Внедрение Kubernetes – когда это необходимо?
В связи со всеобщей цифровизацией популярность метода контейнеризации приложений стремительно растёт. Технология способствует быстрому выводу сервисов компаний в продуктивную среду, где выигрывать помогает короткий time-to-market, а промедление грозит потерей очков в конкурентной гонке. А использование такого инструмента управления контейнерами, как Kubernetes, стало трендом, причем не просто так. Мы считаем, что это действительно прорывная технология, у которой есть большие преимущества. Этот оркестратор контейнеров от Google помогает управлять серверами и контейнерами, запущенными на них, автоматизировано контролировать использование ресурсов в зависимости от нагрузки, экономить на железе благодаря запуску нескольких контейнеров на одном сервере и унифицировать взаимодействие между соответствующими сервисами компании.
Эти плюсы сделали Kubernetes сильным помощником для некоторых видов проектов. Однако у платформы есть и минусы, точнее, такие свойства, которые весьма усложняют применение Kubernetes на практике, в результате чего он может просто не подходить вашему проекту. Цель этой статьи – не в том, чтобы сделать акцент на недостатках оркестратора, а в том, чтобы те компании, которые ещё не определились, насколько им подходит контейнеризация (или те, которые используют Docker не целиком), задумались, действительно ли Kubernetes им необходим.
А для тех, кто всё-таки решил «попробовать» этот оркестратор, в конце статьи будет небольшой туториал по созданию безопасного кластера Kubernetes.
А для тех, кто всё-таки решил «попробовать» этот оркестратор, в конце статьи будет небольшой туториал по созданию безопасного кластера Kubernetes.
Для каких проектов Kubernetes хорош
Идея контейнеризации в ИТ сродни контейнеризации от Малькольма Маклина в логистике. Контейнер позволяет упаковать единые настройки в универсальный модуль, который можно сразу же запускать в любом облачном или физическом окружении. Это очень удобно и очевидно, что за такой технологией будущее: по прогнозам более 70% рынка в ближайшие годы перейдёт на контейнеризацию.
В CI/CD с контейнерами работать намного проще – можно построить надёжный конвейер, практически ничего не перенастраивая. И у Kubernetes есть интересные функции для ИТ-инженеров, которые делают оркестрацию контейнеров более управляемой – тот же автоскейлинг (автомасштабирование) или такой компонент платформы, как Kubelet, который автоматически запускает и останавливает контейнеры приложений при обнаружении проблем. Однако чаще всего действительно выигрывает от всего этого лишь масштабная оркестрация.
В CI/CD с контейнерами работать намного проще – можно построить надёжный конвейер, практически ничего не перенастраивая. И у Kubernetes есть интересные функции для ИТ-инженеров, которые делают оркестрацию контейнеров более управляемой – тот же автоскейлинг (автомасштабирование) или такой компонент платформы, как Kubelet, который автоматически запускает и останавливает контейнеры приложений при обнаружении проблем. Однако чаще всего действительно выигрывает от всего этого лишь масштабная оркестрация.
Kubernetes больше подходит для высоконагруженных, масштабируемых big-data проектов, в которых нужно работать с обилием контейнерных кластеров и облачных PaaS/IaaS-решений. Именно поэтому контейнеры и Kubernetes используют такие гиганты, как Google, Amazon, Tinder, BlaBlaCar, CERN, Huawei, Microsoft.
Каким проектам не подходит Kubernetes
Не останавливаясь подробно на минусах технологии, перечислим те из них, которые делают практическое применение оркестратора менее удобным.
Дополнительный уровень абстракции усложняет систему и увеличивает её хрупкость
Экосистема изобилует специфическими понятиями и взаимоувязанными компонентами: нода, под, узел, лейбл, контроллер, сервис и другие. К тому же она быстро развивается и требует немало времени и внимания разработчика на то, чтобы оставаться в курсе новых инструментов и практик – особенно в начале использования, когда неизвестно, что из этого всего может понадобиться
Документация описания системы довольно объёмная, и изучать её для реализации срочных проектов долго и дорого- Высокие эксплуатационные расходы. Kubernetes – довольно дорогой в обслуживании оркестратор, поскольку требует опытных специалистов с высокой стоимостью услуг, которых на сегодняшний момент довольно мало. К тому же это проприетарная технология, которая вносит своеобразный «vendor-lock». Однако появляются и полностью совместимые с Kubernetes Open Source продукты оркестрации: например, исполняемая среда CRI-O
- Kubernetes – многокомпонентная, сложная, относительно новая и поэтому регулярно изменяющаяся система. Это развитие и эта сложность ожидаемо влекут за собой разные сбои и уязвимости, поскольку для полной отлаженности процессов нужно время, часто исчисляемое годами. При этом внешние угрозы эволюционируют стремительно. Поэтому могут возникать некоторые вопросы к безопасности оркестратора, которые сейчас успешно закрывают разработчики сторонних сервисов, повышающих безопасность Kubernetes и микросервисных приложений, но их наличие только доказывает проблему. Это, например, Luntry, Anchore, KubeXray, Falco, Aporeto, Cilium и множество других продуктов
Из нашей практики
Мы заметили, что в маленькой или средней компании технология контейнеризации, и в частности Kubernetes, не только усложняет работу ИТ-специалистам, но и приходится не по карману. Поэтому на рынке реальных внедрений этого продукта не так много, ведь большинству компаний не нужны системы управления контейнеризированными приложениями – это удел крупных разработок сложных систем, где издержки технологии микросервисов (трудоёмкость, высокая стоимость специалистов) точно окупятся.
Если в ваших проектах можно справиться со сложностью системы силами монолитной архитектуры, то это решение будет более предпочтительным, чем использование микросервисов. Либо, если стало сложно поддерживать код, то можно решить проблему, «нарезав» проект на микросервисы, у которых есть свой интерфейс, и управлять ими либо без оркестратора, либо менее сложным оркестратором. Вертикальное масштабирование может оставаться эффективным, если нет большого объёма данных и больших нагрузок: общий размер баз до 50 Гб, таблицы до 1 млн. записей, сетевые нагрузки до 50 запросов/сек. Придерживаться рамок монолитной архитектуры стоит и тогда, когда нет возможности распределять работу между разными командами. Если проблема в безопасности, её можно решить оборачиванием запросов к БД в хранимые процедуры. Есть и другие способы решать возникающие проблемы без перехода к Kubernetes.
Если бюджет не рассчитан на высокую оплату труда дополнительных специалистов, то стоит посмотреть в сторону использования виртуальных машин, которые создаются с помощью системы управления конфигурациями Ansible и не требуют высокой квалификации обслуживающих сотрудников или более простых систем оркестрации. В практике нашей компании есть кейсы, когда мы снимали клиентов «с иглы» Kubernetes, и они до сих пор нам благодарны. Например, к нам обратился клиент с проблемами на сервере, находящемся на co-location: сервер постоянно сбоил, перезагружался, имел аппаратные проблемы, время простоя на продуктивной среде составляло до 30 минут в неделю. Архитектура изначально была настроена на Kubernetes и по мнению многих компаний, к которым клиент обращался до нас, ликвидация проблем вышла бы очень дорого.
Если в ваших проектах можно справиться со сложностью системы силами монолитной архитектуры, то это решение будет более предпочтительным, чем использование микросервисов. Либо, если стало сложно поддерживать код, то можно решить проблему, «нарезав» проект на микросервисы, у которых есть свой интерфейс, и управлять ими либо без оркестратора, либо менее сложным оркестратором. Вертикальное масштабирование может оставаться эффективным, если нет большого объёма данных и больших нагрузок: общий размер баз до 50 Гб, таблицы до 1 млн. записей, сетевые нагрузки до 50 запросов/сек. Придерживаться рамок монолитной архитектуры стоит и тогда, когда нет возможности распределять работу между разными командами. Если проблема в безопасности, её можно решить оборачиванием запросов к БД в хранимые процедуры. Есть и другие способы решать возникающие проблемы без перехода к Kubernetes.
Если бюджет не рассчитан на высокую оплату труда дополнительных специалистов, то стоит посмотреть в сторону использования виртуальных машин, которые создаются с помощью системы управления конфигурациями Ansible и не требуют высокой квалификации обслуживающих сотрудников или более простых систем оркестрации. В практике нашей компании есть кейсы, когда мы снимали клиентов «с иглы» Kubernetes, и они до сих пор нам благодарны. Например, к нам обратился клиент с проблемами на сервере, находящемся на co-location: сервер постоянно сбоил, перезагружался, имел аппаратные проблемы, время простоя на продуктивной среде составляло до 30 минут в неделю. Архитектура изначально была настроена на Kubernetes и по мнению многих компаний, к которым клиент обращался до нас, ликвидация проблем вышла бы очень дорого.
Мы же перенесли инфраструктуру со сложной системы оркестрации Kubernetes на более простую и понятную для клиента систему оркестрации контейнеров Docker Compose. Также были проведены все необходимые настройки, а инфраструктура поставлена на мониторинг и на техническую поддержку. Данный «downgrade» позволил в сжатые сроки вернуть на рельсы собственный процесс разработки в компании, и каждый разработчик смог сам без помощи DevOps инженеров развернуть локальную тестовую среду у себя на рабочем месте. В результате накопившиеся за несколько месяцев ошибки и баги были очень быстро исправлены, протестированы и, опять же, без помощи DevOps инженеров была обновлена продуктивная среда. На продуктивной среде был реализован простой и понятный способ резервного копирования и восстановления на общей тестовой среде, и каждый разработчик смог получить для разработки последнюю версию БД и статического контента для полноценного QA-тестирования.
Если вы не планируете разворачивать множество схожих, однотипных служб на крупномасштабной инфраструктуре, а ищете надёжный, расширяемый, простой в поддержке оркестратор, то присмотритесь к альтернативам. Если же безопасность и надёжность у вашего бизнеса во главе угла, то тоже стоит подумать об альтернативных или комбинированных технологиях.
Если вы не планируете разворачивать множество схожих, однотипных служб на крупномасштабной инфраструктуре, а ищете надёжный, расширяемый, простой в поддержке оркестратор, то присмотритесь к альтернативам. Если же безопасность и надёжность у вашего бизнеса во главе угла, то тоже стоит подумать об альтернативных или комбинированных технологиях.
Альтернативы Кубернетесу
В качестве альтернативы можно использовать такие системы оркестрации контейнеров, которые не так масштабны, как Kubernetes, но которые позволяют быстро разворачивать приложения и запускать микросервисы на виртуальных кластерах. Эти простые оркестраторы существенно облегчают работу DevOps-инженерам:
Бесплатные (free)
Также на рынке есть такие продукты как Rancher – OpenSource решение, которое упрощает и систематизирует работу с кластерами Kubernetes, и RedHat OpenShift – платформа Enterprise-класса.
Руководствуясь нашим опытом, отдельно отметим, что в продуктивных средах мы зачастую предлагаем своим клиентам выкладывать код на виртуальных машинах – это безопаснее. Мы уверены, что старая добрая виртуализация как решение не так страшна и в некоторых случаях более надежна. Например, выход за пределы контейнера через 0-day уязвимость cgroups – гораздо менее затратная по количеству приложенных злоумышленниками усилий операция, чем проникновение на отдельный виртуальный хост, в арсенале которого могут быть применены политики SELinux и набор практик по OS hardening.
Конечно, такой подход подойдёт не всем. Если компания изначально строит всю архитектуру на контейнерах и располагает для этого ресурсами, то неоправданно будет перепаковывать всё в обычные виртуальные машины. Современная разработка всё более перетекает в Docker, и разработчики вынуждены внедрять системы управления и оркестрации контейнерами, вместо того чтобы разворачивать приложения в облачных виртуальных машинах.
Бесплатные (free)
- Docker Compose
- Docker Swarm
- Apache Mesos/Marathon
- Vagrant
- Panamax
- Cloudify
- Deis
- 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 в качестве оркестратора контейнеров используйте следующий гайд по обеспечению безопасности.
При выборе Kubernetes в качестве оркестратора контейнеров используйте следующий гайд по обеспечению безопасности.
Не пропустите последние новости. Подписывайтесь!