VK — одна из ведущих ИТ-корпораций России, сервисами которой пользуется около 95% аудитории Рунета. В нашем продуктовом портфеле более 200 проектов, созданием и развитием которых занимается большое количество команд. Для решения продуктовых задач мы используем широкий стек инструментов и технологий, в том числе активно работаем с Kubernetes. Причем наши подходы и паттерны к работе с K8s нередко отличаются от типовых решений.

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

Статья подготовлена по мотивам моего доклада на VK Kubernetes Conf 2024. Вы можете посмотреть его здесь.

Технический департамент и основные принципы разработки

Пользователями внутренних платформ и решений VK являются около 6000 человек. В большинстве своем это специалисты, которые занимаются разработкой и администрированием наших проектов и сервисов (ВКонтакте, Одноклассники, Дзен, Почта, RuStore, VK Pay и другие). Причем многие команды в своей работе используют широкие стеки инструментов и задействуют значительные мощности. 

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

• департамент единого облака, который отвечает за управление платформой в целом и выделение нужных ресурсов;

• департамент сетевых технологий, в задачи которого входит обеспечение взаимодействия всех систем и компонентов сети;

• департамент больших данных, который занимается построением инфраструктуры для всех циклов работы с Big Data;

• департамент информационных технологий, который отвечает за предоставление сервисов безопасности и управления (например, авторизации).

Таким образом, слаженная работа всех команд фактически решает основной пласт задач Platform Engineering.

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

1. Построение и оптимизация Cloud-Agnostic-архитектуры. Основные компоненты строятся таким образом, чтобы работать одинаково хорошо как на Bare-metal, так и в облаках.

2. Глубокая оптимизация и RnD. Исследуем и внедряем последние технологии, делая упор на стабильность и производительность. Особое внимание уделяем совместимости, бесшовным миграциям, рациональному использованию бюджета.

3. Разработка собственных решений. Свои команды разработки и продвинутые навыки программирования SRE-инженеров позволяют разрабатывать собственные решения там, где не хватает готовых.

4. Прокачка и применение внутренней экспертизы. Команды владеют экспертизой в построении полного цикла технологий и применяют ее на разных этапах: от доработки на уровне ядра системы до построения сложных мультистейдж-пайплайнов.

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

Ключевые интеграции

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

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

• информационной безопасности и выстраивания DevSecOps;

• инструментов разработки;

• систем мониторинга и SOC (Security Operations Center, центров по обеспечению информационной безопасности);

• систем управления сетью и дата-центрами.

Среди прочего, в контексте именно нашего Kubernetes мы используем внешние интеграции для автоматизации развертывания и управления жизненным циклом кластеров. Это позволяет быстро предоставлять инфраструктуру для разработки и, как результат, сократить зависимость команд от согласований, снизить влияние на цикл поставки ценностей, уменьшить Time-to-market.

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

Безусловно, у нас есть проекты и сценарии, в которых нужны специфические инструменты и подходы, но мы стараемся их минимизировать, чтобы сокращать «зоопарк технологий» и уходить от Bus Factor в части узкоспециализированной экспертизы.

Здесь стоит отметить два момента.

• Мы стремимся интегрировать все сервисы и управлять ими из одной точки. 

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

Наш K8s-стек

В работе с Kubernetes мы используем классический набор инструментов и решений.

• Kubernetes 1.29. Мы работаем со свежей версией K8s, активно исследуем и внедряем новые фичи (например, Static Provisioners). 

• Cilium. Используем большинство новых возможностей. Строим мультикластеры. Применяем сетевые решения в едином стеке, накапливая уникальную экспертизу разработки и эксплуатации.

• MultiDNS (доработанный нами Core-DNS). С его помощью строим мультикластерные решения с применением различных CNI одновременно (Calico, Cilium).

• GatewayAPI. Внедряем как единый способ доставки трафика. Строим типичные конфигурации для всех, не привязываясь к конкретному вендору для Ingress.

• Storage (OpenEBS, Maya). Внедряем в разных вариациях, разрабатываем схему оборудования в ДЦ для полностью синхронных реплик.

• CoreLogs. Своя система логирования, которая позволяет собирать и санитайзить логи со всего кластера, обрабатывая в зависимости от приложения и его типа.

Векторы развития

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

Сейчас для себя мы выделяем четыре основных трека дальнейшего развития:

1. Продуктовый подход к платформе.

2. Формирование общей стратегии.

3. Преобразование инфраструктуры в продукт.

4. Full Cycle Platform Engineering.

Продуктовый подход к платформе

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

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

Также концепция предполагает, что каждый элемент внутренней платформы разработки становится продуктом: мощности, сеть, сбор метрик и другие. То есть с направлениями надо работать, как с внешними пользователями, вплоть до выделения роли Product Owner под каждый продукт.

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

Это значит полный уход от модели «получаем все, что хотим, по запросу и используем по своему усмотрению».

Формирование общей стратегии

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

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

• Краткосрочное и долгосрочное планирование. Нам важно, чтобы развитие было не просто «дорогой», а имело интерпретируемые цели, результаты достижения которых можно было бы оценить, в том числе с точки зрения бизнес-ценности. В свою очередь, команды должны быть уверены, что гарантированно будут иметь в распоряжении нужные ресурсы и инструменты.

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

• Стратегии юнитов — основа. Каждый внешний проект наших бизнес-юнитов — отдельный продукт со своей целевой аудиторией. Причем иногда ЦА продуктов не пересекаются или пересекаются минимально. Поэтому вместо навязывания строгих правил и требований к разработке мы придерживаемся подхода, при котором каждый юнит сам определяет стратегию развития и движения к достижению общей для всей группы компаний VK целей. 

Преобразование инфраструктуры в продукт

С переходом к продуктовому подходу вся инфраструктура также должна становиться продуктом. То есть железо, сеть и связанность превращаются в продукт, который бизнес-юниты получают либо в определенном (фиксированном) объеме (например, по CPU и RAM), либо по времени. Такая модель работы с инфраструктурой позволяет эффективнее утилизировать ресурсы, доступные в разных дата-центрах, повышает точность и прозрачность планирования, а также дает возможность по необходимости распределять команды по разным ЦОДам. Команды, в свою очередь, получают понимание относительно того, сколько ресурсов они гарантированно будут иметь.

При этом управление всем доступным пулом мощностей можно осуществлять из одной точки.

Full Cycle Platform Engineering

Одним из основных трендов для нас становится переход к Full Cycle Platform Engineering, в рамках которого разработчики смогут не отвлекаться на «второстепенные» задачи, используя уже практически готовые и преднастроенные решения. В том числе это подразумевает, что за доставку, сборку, мониторинг, метрики, логи, управление и биллинг будет полностью отвечать платформенная команда. 

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

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

Наша специфика работы с Kubernetes: инструменты и сущности

В своей работе с Kubernetes, Kubernetes-Native-сервисами и Platform Engineering мы используем несколько ключевых подходов, инструментов и решений. 

Геокластеры

Мы строим географически распределенную сеть локальных кластеров, связанных между собой глобальными WAN-каналами. Соответственно, вся платформа разработки «растягивается» между доступными площадками.

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

• объединение нескольких кластеров в Mesh. Дает повышенную отказоустойчивость и быстрое восстановление сервисов;

• нагрузка распределяется равномернее. Выход из строя ключевых компонентов не приводит к недоступности рабочей нагрузки в кластере;

• CI/CD делает процесс деплоя прозрачным. Не надо думать, в каком кластере развернуть еще одну реплику. Достаточно один раз описать политики деплоя.

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

Система сбора и доставки логов

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

С помощью этой системы мы добились оптимизации сжатия и экономим 70% дисков (по сравнению с логами без сжатия).

Что особенно важно — наша система быстрее бесплатных Open-Source-аналогов. По результатам наших внутренних замеров, с переходом на нее мы смогли в 3,7 раза ускорить чтение и доставку логов, что в нашем масштабе данных — огромный прирост.

Nanny

У нас есть внутренний инструмент Nanny, который глобально отвечает за автоматизацию контроля над кластерами. Сервис:

• умеет устранять проблемы на хостах, опираясь на метрики и тип запущенной нагрузки;

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

  

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

API

В нашем кейсе API — единая точка входа для всех данных и интеграций. Поэтому через API строится целый пул процессов, в том числе:

• сквозная интеграция всех используемых систем;

• сбор данных и построение удобных дашбордов для пользователей и администраторов;

• полное управление жизненным циклом системы из одной точки;

• разделение ролей — каждый видит и использует необходимые ему инструменты.

Таким образом, API является «сердцем» User Space, к которому при необходимости можно добавить новые фичи и абстракции.

Небольшое послесловие

Кейс VK однозначно нетипичный для всего рынка (ввиду доступных нам ресурсов, масштаба сервисов, экспертизы и не только). Но наш случай в очередной раз подтверждает, что одним из главных трендов в ИТ становится переход к Platform Engineering, а также смена парадигмы относительно работы с инструментами и технологиями, в том числе с Kubernetes. Это оправданный и эволюционный путь, движение по которому потенциально позволит решать более сложные задачи доступными ресурсами и, как результат, получить конкурентные преимущества.