Привет, Хабр! 

Сегодня с вами Игорь Шишкин, тимлид команды облачной разработки в Рег.ру, и я расскажу о том, как и зачем мы запускаем Kubernetes as a Service (KaaS).

Мы в Рег.ру очень внимательно следим за трендами в облачных вычислениях и стараемся предоставлять нашим клиентам стабильные и надежные сервисы.

Внутри компании мы повсеместно используем и базы данных, и Kubernetes, но в разрезе публичного облака к этим услугам предъявляется особенный набор требований. Именно поэтому мы сначала запустили DBaaS внутри, а потом и для клиентов — такой подход позволил нам обеспечить собственные потребности масштабирования и при этом обкатать ряд решений аккуратно, изолированно, собрав все возможные грабли.

Ранее мы уже писали про устройство сервиса DBaaS, а теперь расскажем про следующий сервис в линейке платформенных сервисов — KaaS.

Навигация по тексту:

→ Что такое KaaS

→ Как устроен KaaS 

→ Куда будет расти Kubernetes и что мы будем делать

→ Немного про команду

Что такое KaaS

KaaS — это новый продукт Облака Рег.ру, призванный предоставить клиентам возможность запуска распределенных приложений в контейнерах, не заботясь об отказоустойчивости каждого отдельного инстанса и применяя все новейшие технологии разработки, тестирования и развертывания. При этом нет завязки на какие-либо вендорные решения, так как наш сервис на 99.9(9) % построен на основе свободных решений. Для клиентов это означает простоту и легкость миграции с Kubernetes, развернутого собственными силами, или от другого облачного провайдера.

Ключевая особенность KaaS — это managed service, то есть все заботы по развертыванию и поддержке работоспособности, мониторингу самого Kubernetes и его масштабированию мы берем на себя, а клиент в три клика получает кластер, готовый к использованию незамедлительно. Больше не нужно тратить свои силы и время на подготовку инфраструктуры, в течение нескольких минут станет доступна конфигурация, которую можно добавить в CI/CD-пайплайн, например, в GitLab, и уже начать деплоить приложения.

В Рунити (не только в Рег.ру) мы практически везде используем Kubernetes, следуя практике eat your own dog food, то есть такие сервисы как KaaS мы стараемся сначала запускать внутри компании, и только потом масштабировать на клиентов. Благодаря такому подходу мы унифицируем платформенные решения, получаем возможность собрать обратную связь с большего круга пользователей и обкатывать крутые фишки внутри. Получается, что по сути наш внутренний заказчик — это такой же бизнес-заказчик, как и остальные клиенты. И в том числе благодаря этому можем обеспечить скорость запуска услуг в облаке и сократить расходы на поддержку сервиса, что в конечном итоге обращается выгодой для клиента.

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

Практически любое облако строится по принципу пирамиды, где на самом низком уровне находятся решения вида Infrastructure as a Service (IaaS), включающие в себя выделение инфраструктурных ресурсов, сети как сервис, сервисы для хранения данных, сервисы для выделения вычислительных мощностей и ряд других. В Рег.ру IaaS представлен виртуальными машинами и сетями на базе OpenStack. Сервисы для хранения при этом делятся на Object Storage (для хранения объектов) и Block Storage (для дисков виртуальных машин). В зависимости от типа хранилища они могут быть представлены разными решениями: от локальных дисков на гипервизорах до наших собственных разработок — тут я немного придержу спойлеры для ближайших анонсов запускаемых сервисов :)

Следующий пласт пирамиды — Platform as a Service (PaaS). Платформы позволяют на своей базе использовать инструменты для выстраивания более высокоуровневых сущностей. Этот уровень в настоящий момент у нас представлен DBaaS и KaaS, но в ближайшее время добавятся и другие услуги.

На самом верхнем уровне — Software as a Service (SaaS). Здесь находятся конкретные приложения, например, GitLab, WordPress или любой другой софт, используемый конечным потребителем и предоставляемый по сервисной модели. Данный уровень у нас представлен внушительным, регулярно пополняемым и обновляемым списком образов, из которых можно развернуть готовое приложение.

Как устроен KaaS

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

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

Хоть все и звучит так просто, путь создания этого продукта, конечно, не был легким: мы
пробовали и ошибались, начинали снова. Три раза практически полностью все
переделывали в поисках нужного подхода для доставки и масштабирования. Ключевой
идеей было стараться избегать замыкания на собственной разработке — как раз для
дальнейшей доступности для клиентов и максимально возможного переиспользования
выбранных Open Source решений.

Куда будет расти Kubernetes и что мы будем делать

Прежде всего это, конечно, развитие самой услуги KaaS. У нас в планах расширять возможности по управлению сетевым трафиком и хранению данных внутри кластера. Как показывает наша статистика, это крайне важно для наших клиентов. Кроме этого, мы собираемся создавать на базе Kubernetes новые сервисы, для расширения линеек PaaS- и SaaS-продуктов. Это, в первую очередь, новые инструменты для обеспечения разработки, сервисы хранения данных и предоставления новых возможностей нашим клиентам. 

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

Немного про команду

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

Всю большую платформенную команду мы делим на три — по специализации:

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

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

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

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

В следующий раз мы расскажем про архитектуру нашего решения. С вами был Игорь Шишкин, спасибо за внимание и до новых встреч!