В конце мая мы провели онлайн-митап на тему «Современная инфраструктура и контейнеры: проблемы и перспективы». Поговорили о контейнерах, Kubernetes и оркестрации в принципе, о критериях выбора инфраструктуры и многом другом. Участники поделились кейсами из собственной практики.

Участники:

• Евгений Потапов, CEO «ITSumma». Больше половины его клиентов либо уже переходят, либо хотят перейти на Kubernetes.
• Дмитрий Столяров, CTO «Флант». Обладает 10+ годами опыта работы с контейнерными системами.
• Денис Ремчуков (aka Eric Oldmann), COO argotech.io, ex-РАО ЕЭС. Пообещал рассказать о кейсах в «кровавом» энтерпрайзе.
• Андрей Федоровский, CTO «News360.com»После покупки компании другим игроком отвечает за ряд ML и AI проектов и за инфраструктуру.
• Иван Круглов, системный инженер, ex–Booking.com.Тот самый человек, который своими руками сделал с Kubernetes очень многое.

Темы:

• Инсайты участников про контейнеры и оркестрацию (Docker, Kubernetes и прочее); что пробовали на практике или анализировали.
• Кейс: В компании строят план развития инфраструктуры на годы. Как принимается решение, строить (или переводить текущую) инфраструктуру на контейнерах и Кубер или нет?
• Проблемы в мире cloud-native, чего не хватает, давайте пофантазируем, что будет завтра.

Завязалась интересная дискуссия, мнения участников оказались настолько разными и вызвали столько комментариев, что хочется поделиться ими с вами. Есть видео на три часа, а ниже – выжимка из дискуссии.

Kubernetes это уже стандарт или отличный маркетинг?

«Мы к нему (Kubernetes. — Ред.) пришли тогда, когда о нем еще никто не знал. Мы к нему пришли еще тогда, когда его не было. Мы его хотели до этого» — Дмитрий Столяров


Фото с Reddit.com

Лет 5-10 назад существовало огромное количество инструментов, и не было единого стандарта. Каждые полгода появлялся новый продукт, а то и не один. Сначала Vagrant, затем Salt, Chef, Puppet,… «и ты каждые полгода перестраиваешь свою инфраструктуру. У тебя пять админов, которые постоянно заняты тем, что переписывают конфиги» — вспоминает Андрей Федоровский. Он считает, что Docker и Kubernetes «задавили» остальных. Docker стал стандартом в течение последних пяти лет, Kubernetes — в последние два года. И это хорошо для индустрии.

Дмитрий Столяров и его команда любят Кубер. Они хотели такой инструмент до того как он появился, и пришли к нему когда о нем еще никто не знал. На текущий момент, из соображений удобства, они не берут клиента, если понимают, что не внедрят у него Kubernetes. При этом, по словам Дмитрия, у компании «множество гигантских success story по переделке жуткого legacy».

Kubernetes — это не только контейнерная оркестрация, это система управления конфигурацией с развитым API, компонентом работы с сетью, L3 балансировкой и Ingress контроллерами, которая позволяет относительно легко управлять ресурсами, масштабироваться и абстрагироваться от нижних слоев инфраструктуры.

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

Евгений провел аналогию с ситуацией в 1990-х годах, когда появилось объектно-ориентированное программирование, как способ программирования сложных приложений. На тот момент не прекращались дебаты и появлялись новые инструменты, поддерживающие ООП. Затем появились микросервисы как способ уйти от монолитной концепции. Это, в свою очередь, привело к появлению контейнеров и инструментов их управления. «Я думаю, что скоро мы придем к тому времени, когда не будет стоять вопрос о том, стоит ли писать микросервисно маленькое приложение, его будут писать по дефолту микросервисом», — считает он. Аналогично, Docker и Kubernetes со временем станут стандартным решением без необходимости выбора.

Проблема баз в stateless

Photo by Twitter: @jankolario on Unsplash

В наше время найдется много рецептов запуска баз данных в Kubernetes. Даже как отделять часть, работающую с диском I/O от, условно, application — части базы. Возможно ли, что в будущем базы данных видоизменятся настолько, что будут поставляться в коробке, где одна часть будет оркестрироваться через Docker и Kubernetes, а в другой части инфраструктуры, через отдельный софт, будет предоставляться storage часть? Базы видоизменятся как продукт?

Это описание похоже на менеджмент очередей, но требования к надежности и синхронности информации в традиционных базах данных предъявляются гораздо выше, считает Андрей. Cache hit ratio в нормальных базах держится на уровне 99 %. Если worker ложится, запускается новый, и кэш «разогревается» с нуля. Пока кэш не разогрет, worker работает медленно, значит на него нельзя пускать пользовательскую нагрузку. Пока нет пользовательской нагрузки, кэш не разогревается. Это замкнутый круг.

Дмитрий в корне не согласен, — кворумы и шардирование решают проблему. Но Андрей настаивает, что решение подходит не всем. В некоторых ситуациях подойдет кворум, но он дает дополнительную нагрузку на сеть. База NoSQL подходит не во всех случаях.

Участники митапа разделились на два лагеря.

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

Даже современные cloud native базы, такие как MongoDB и Cassandra, или очереди сообщений, как Kafka или RabbitMQ, требуют постоянные хранилища данных вне Kubernetes.

Евгений возражает: «Базы в Кубере — травма околороссийская, или околоэнтерпрайзная, которая связана с тем, что в России Cloud Adoption нет». Малые или средние компании на Западе — это Cloud. Базы Amazon RDS использовать проще, чем самим возиться с Kubernetes. В России используют Кубер “on-premise” и переносят в него базы, когда пытаются избавиться от зоопарка.

Дмитрий тоже не согласился с утверждением, что никакие базы нельзя держать в Kubernetes: «База базе рознь. И если пихать гигантскую реляционную базу — то ни в коем случае. Если пихать что-то небольшое и cloud native, что морально готово к полуэфемерной жизни, все будет хорошо.» Дмитрий упомянул также, что инструменты управления базами не готовы ни к Docker, ни к Kuber, поэтому возникают большие сложности.

Иван, в свою очередь, уверен, что даже если абстрагироваться от понятий stateful и stateless, экосистема энтерпрайзных решений в Kubernetes еще не готова. С Кубером сложно поддерживать требования законодательных и регулирующих органов. Например, невозможно сделать решение предоставления identity, где требуются строгие гарантии идентификации сервера, вплоть до железа, которое вставляется в серверы. Эта сфера развивается, но пока решения нет.
Участникам не удалось договориться, поэтому в этой части выводов не последует. Лучше приведем пару практических примеров.

Кейс 1. Кибербезопасность «мегарегулятора» с базами вне Кубера

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

Кейс 2. Частичный переезд баз данных Booking.com в Kubernetes

В Booking.com основная база данных — это MySQL с асинхронной репликацией — есть master и целая иерархия слейвов. К моменту ухода Ивана из компании был запущен проект по переносу cлейвов, которые можно «отстрелить» с определенным ущербом.

Помимо основной базы есть инсталляция Cassandra с самописной оркестрацией, которую писали еще до того как Кубер вышел в мейнстрим. Проблем в этом плане нет, но у нее persistent на локальные SSD. Удаленный хранилища, даже в рамках одного дата-центра, не используются из-за проблемы с высокой задержкой.

Третий класс баз данных — это поисковый сервис Booking.com, где каждая нода сервиса является базой данных. Попытки перенести поисковый сервис в Кубер не удались, потому что каждая нода — это 60—80 Гб локального storage, которые сложно «поднять» и «разогреть».

В итоге поисковый движок в Kubernetes не перенесли, и Иван не думает, что будут новые попытки в ближайшее время. База MySQL была перенесена наполовину: только Слейвы, которые не страшно «отстрелить». Cassandra «прижилась» отлично.

Выбор инфраструктуры как задача без общего решения

Photo by Manuel Geissinger from Pexels

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

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

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

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

Налог заплатить придется в любом случае, и Иван платил бы тот, который позволил ему в будущем платить меньше. «Потому что просто за счет того, что я еду в поезде, который двигают другие, я проеду намного дальше, чем если я сяду в другой поезд, в который мне придется топливо закидывать самому.» — говорит Иван. Когда компания новая, и требования к latency — десятки миллисекунд, то Иван смотрел бы в сторону «операторов», в которые сегодня «заворачивают» классические базы данных. Они поднимают replication chain, который сам переключается в случае failover и т.п…

Для маленькой компании с парой серверов в Кубере смысла нет, — утверждает Андрей. Но если она планирует вырасти до сотни серверов и больше, то нужна автоматизация и система управления ресурсами. 90 % случаев оправдывают затраты. Причем вне зависимости от уровня нагрузки и ресурсов. Всем, начиная от стартапов, заканчивая крупными компаниями с миллионной аудиторией, имеет смысл постепенно смотреть в сторону продуктов для оркестрации контейнеров. «Да, это действительно будущее», — уверен Андрей.

Денис обозначил два главных критерия — масштабируемость и устойчивость работы. Он выберет те инструменты, которые лучше всего подходят для этой задачи. «Это может быть на коленке собранный ноунейм, и на нем Nutanix Community Edition. Это может быть вторая линия в виде application на Kuber с базой данных на бэкенде, которая реплицируется и имеет заданные параметры RTO и RPO» (recovery time/point objectives — прим).

Евгений обозначил возможную проблему с кадрами. На текущий момент на рынке не так много высококлассных специалистов, разбирающихся «в кишках». Действительно, если выбранная технология стара, то сложно нанять кого-то, кроме немолодых скучающих и уставших от жизни людей. Хотя другие участники считают, что это вопрос подготовки кадров.
Если поставить вопрос выбора: запускать небольшую компанию в Public Cloud с базами в Amazon RDS или “on premise” с базами в Kubernetes, то несмотря на некоторые недостатки, выбором участников стал Amazon RDS.

Так как большинство слушателей митапа не из «кровавого» энтерпрайза, то распределенные решения — это то, к чему надо стремиться. Системы хранения данных должны быть распределенными, надежными, и создавать latency, измеряемые единицами миллисекунд, максимум десятками, — резюмировал Андрей.

Оценка использования Kubernetes

Слушатель Антон Жбанков задал вопрос-западню апологетам Kubernetes: как выбирали и проводили технико-экономическое обоснование? Почему Kubernetes, почему не виртуальные машины, например?


Photo by Tatyana Eremina on Unsplash

На него ответили Дмитрий и Иван. В обоих случаях методом проб и ошибок, была сделана последовательность решений, в результате которой оба участника пришли к Kubernetes. Сейчас бизнес начинает самостоятельно разрабатывать софт, который имеет смысл переносить в Кубер. Речь не идет о классических сторонних системах, типа 1С. Kubernetes помогает, когда разработчикам нужно оперативно делать релизы, при безостановочном Continuous Improvement.

Команда Андрея пробовала делать масштабируемый кластер на основе виртуальных машин. Ноды падали как домино, что иногда приводило к падению кластера. «Теоретически можно доделать и поддерживать руками, но муторно. И если на рынке есть решение, которое позволяет работать из коробки, то мы с удовольствием идем к нему. И мы перешли в результате.», — рассказывает Андрей.

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

Что нас ждёт

Photo by Drew Beamer on Unsplash

Когда технологии развиваются, появляется все больше разрозненных кусочков, а затем происходит фазовый переход, появляется вендор, который убил достаточно «бабла», чтобы все соединилось вместе в едином инструменте.

Не кажется ли вам, что наступит момент, когда появится инструмент, каким стала Ubuntu для мира Linux? Возможно, единый инструмент контейнеризации и оркестрации включит в себя и Кубер. С ним станет просто строить on-premise облака.

Ответ дал Иван: «Google сейчас строит Anthos — это их пакетное предложение, которое разворачивает облако и включает в себя Kuber, Service Mesh, мониторинг, — всю обвязку, которая нужна для микросервисов в «on-premise». Мы почти в будущем.»

Денис также упомянул Nutanix и VMWare с продуктом vRealize Suite, которые могут справляются с подобной задачей без контейнеризации.

Дмитрий поделился мнением, что уменьшение «боли» и снижение налога — это два направления, где стоит ожидать улучшений.

Подводя итог дискуссии, выделим следующие проблемы современной инфраструктуры

• Сразу трое участников обозначили проблему со stateful.
• Различного рода проблемы поддержки безопасности, включая вероятность того, что итоге в Docker окажутся несколько версий Python, application-серверов и компонент.
  Перерасход, о котором лучше сделать отдельный митап.
  Проблема обучения, так как оркестрация представляет собой сложную экосистему.
  Общая проблема отрасли — использование инструментов не по назначению.
  
  Остальные выводы делать вам. Пока остается ощущение, что связке Docker+Kubernetes непросто стать «центральной» частью системы. Например, операционные системы ставятся на железку первыми, чего нельзя сказать о контейнерах и оркестрации. Возможно, в будущем срастутся операционки и контейнеры с cloud management софтом.
  
  
  Photo by Gabriel Santos Fotografia from Pexels
  
  Пользуясь случаем хочу передать привет маме напомню, что у нас есть фейсбук-группа «Управление и разработка крупных IT-проектов», канал @feedmeto с интересными публикациями из разных техно-блогов. И мой канал @rybakalexey, где я рассказываю об управлении разработкой в продуктовых компаниях.