Кто и как использует Kubernetes в России

Kubernetes в России — давно не экзотика, а повседневный рабочий инструмент крупнейших компаний страны. Банки, маркетплейсы, телеком и ритейл публично делятся опытом эксплуатации кластеров на конференциях и в технических блогах. Собрали общеизвестные примеры и типовые сценарии внедрения.

Как устроен этот обзор

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

Сбер

Начнём с финансового сектора — исторически главного локомотива контейнеризации в стране.

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

• Сбер строит собственную облачную платформу (внешний бренд — Cloud.ru), где Kubernetes является базовой технологией оркестрации.
• Дочерняя компания СберТех развивает семейство продуктов Platform V, включающее контейнерную платформу корпоративного уровня — опыт внутренней эксплуатации лёг в основу коммерческого продукта.
• Инженеры Сбера регулярно выступают на профильных конференциях с докладами об эксплуатации крупных Kubernetes-инсталляций, сетевых архитектурах и платформенных командах.
• В вакансиях экосистемы Сбера Kubernetes фигурирует как стандартное требование для backend-, DevOps- и SRE-ролей.

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

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

Т-Банк

Т-Банк (ранее Тинькофф) — технологический банк без отделений, для которого ИТ-инфраструктура является ядром бизнеса. Публично известно:

• Банк исторически делился опытом построения внутренней платформы на базе Kubernetes: доклады и статьи о собственном PaaS, сетевой архитектуре, эксплуатации stateful-нагрузок в кластерах.
• Команды банка ведут активную издательскую деятельность на Хабре и в собственных медиа — многие материалы о практиках Kubernetes стали хрестоматийными для русскоязычного сообщества.
• Т-Банк развивает внутренние платформенные инструменты и open source-проекты, связанные с облачной инфраструктурой.

Пример банка показателен: Kubernetes здесь — не просто оркестратор, а фундамент внутренней developer platform, на которой команды самообслуживанием разворачивают сервисы.

Чему учит пример: ценность Kubernetes раскрывается полностью, когда поверх него построена удобная платформа для разработчиков — с шаблонами, автоматическим CI/CD и разумными ограничениями по умолчанию. Оркестратор — это фундамент, а не готовый дом.

Ozon

Ozon — один из крупнейших маркетплейсов страны с микросервисной архитектурой огромного масштаба. Публично известные факты:

• Ozon публично рассказывал о работе с очень большим числом микросервисов и о том, как Kubernetes справляется с пиковыми нагрузками распродаж.
• Инженеры компании делились опытом миграции между кластерами и облаками, построения сетевой инфраструктуры на Cilium, внедрения GitOps-подходов.
• Компания активно использует и дорабатывает открытые инструменты экосистемы CNCF и периодически публикует собственные разработки в open source.
• Технический блог Ozon — один из самых содержательных источников практических материалов о Kubernetes на русском языке.

Чему учит пример: при большом числе сервисов выживаемость определяют сети и наблюдаемость. Публичные материалы Ozon о Cilium, GitOps и переносе нагрузок между площадками — отличный учебник по эксплуатации k8s в масштабе.

VK

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

• VK использует Kubernetes для значительной части внутренних сервисов, о чём инженеры компании рассказывали на конференциях и в блоге.
• Компания — один из пионеров управляемого Kubernetes в России: облачное направление VK Cloud рано предложило managed k8s внешним клиентам.
• Команды VK делились опытом эксплуатации stateful-систем в Kubernetes, построения балансировки и работы с большими нагрузками.

Чему учит пример: двойная перспектива VK — и как пользователя, и как поставщика managed k8s — даёт редкую полноту картины: в своих материалах компания освещает эксплуатацию с обеих сторон сервисной модели.

Итоговая картина по «большой тройке» e-commerce и финтеха сходится: Kubernetes — не эксперимент, а основа их повседневной эксплуатации уже много лет.

Яндекс

Яндекс — крупнейшая технологическая компания страны с давней историей собственных инфраструктурных разработок. Публично известные факты:

• Яндекс исторически развивал собственные системы управления вычислительными ресурсами, а Kubernetes применяется в ряде сервисов и внутренних платформ.
• Yandex Cloud предоставляет Managed Service for Kubernetes — один из самых известных облачных сервисов k8s в России, а также Serverless-направление, построенное на контейнерных технологиях.
• Инженеры Яндекса активно участвуют в жизни сообщества: доклады, переводы, собственные конференции по инфраструктуре (например, Yet another Conference).

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

Авито, X5, ритейл и другие

Авито

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

X5 Group и «Магнит»

Крупнейшие ритейлеры страны — X5 Group (сети «Пятёрочка» и «Перекрёсток») и «Магнит» — публично делились опытом цифровой трансформации, в которой контейнерные платформы играют центральную роль: программы лояльности, e-commerce, доставка, внутренние аналитические системы. Ритейл примечателен сочетанием огромного физического масштаба (десятки тысяч магазинов и распределительных центров) с быстрорастущей цифровой нагрузкой — и активным наймом Kubernetes-специалистов.

Wildberries

Второй гигант российского e-commerce также строит микросервисную инфраструктуру и рекрутирует инженеров с экспертизой Kubernetes. Публичных технических подробностей у компании исторически меньше, чем у Ozon, но сам факт системного найма k8s-специалистов говорит о масштабе внутренних платформ.

Телеком

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

Производители ПО и ИБ-компании

Kaspersky, Positive Technologies и другие российские вендоры используют контейнеризацию в собственной разработке и — что важнее для рынка — выпускают продукты для k8s-сред: средства защиты контейнеров, сканеры, системы мониторинга. Это создаёт вокруг Kubernetes индустрию, а не только потребление.

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

Как применить это к своей ситуации

Практический алгоритм: выберите две-три компании из этого раздела, близкие вам по отрасли или масштабу; найдите их свежие технические материалы; выпишите повторяющиеся решения (инструменты, практики, стандарты); сопоставьте со своим текущим стеком. Расхождения и есть ваша персональная программа развития — бесплатная, составленная лучшими инженерами страны.

Замечание о полноте картины

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

Локальный колорит: факторы российской специфики

Российские внедрения имеют несколько особенностей, которые редко встретишь в западных кейсах и которые полезно учитывать:

• Обязательность офлайн-сценариев. Часть контуров изолирована полностью — отсюда особое внимание к офлайн-поставке дистрибутивов, локальным реестрам образов и зеркалам зависимостей.
• Стек отечественного ПО. Российские ОС на узлах, российские платформы и СЗИ — не опция, а требование многих проектов.
• Гибрид по необходимости и по расчёту. Сочетание собственных мощностей с несколькими российскими облаками стало стандартной архитектурой.
• Русскоязычная эксплуатация. Документация, поддержка, обучение на русском — заметный фактор продуктивности команд.

Мифы о внедрении Kubernetes

Публичный опыт российских компаний развеивает несколько устойчивых заблуждений:

Миф 1. «Kubernetes нужен только гигантам»

Реальность: кластер из трёх узлов обслуживает и небольшой проект. Управляемый k8s в облаке сделал порог входа минимальным — пользуются и команды из нескольких человек. Вопрос не в размере компании, а в характере нагрузки и планах роста.

Миф 2. «Kubernetes всё сделает сам»

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

Миф 3. «Базы данных в k8s — это всегда плохо»

Реальность: ранний совет «не держите stateful в Kubernetes» давно уточнён. С операторами, быстрыми дисками и дисциплиной бэкапов СУБД в кластере работают надёжно — это подтверждают публичные доклады российских команд. Вопрос зрелости эксплуатации, а не запрета.

Миф 4. «Один кластер на всё»

Реальность: зрелые компании оперируют множеством кластеров — по окружениям, площадкам, доменам отказа. Мультикластерность — норма, и платформы управления развивались именно под неё.

Миф 5. «Переезд на k8s — разовый проект»

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

Как читать публичные кейсы

Материалов много, и важно извлекать из них максимум:

• Ищите доклады о неудачах. Рассказы «как мы всё сломали и починили» ценнее гладких успешных историй — в них настоящая эксплуатационная мудрость.
• Смотрите на дату. Экосистема меняется быстро; практики пятилетней давности (например, ранние подходы к ingress или хранению) могли устареть.
• Отделяйте масштаб. Решения для тысячи микросервисов избыточны для кластера из пяти сервисов. Перенимайте принципы, а не конкретный размер инфраструктуры.
• Проверяйте на практике. Любой разобранный в докладе приём воспроизводится в локальном кластере — так знание становится навыком.

Общие уроки из российских внедрений

Если обобщить публичный опыт многих компаний, повторяются одни и те же выводы:

1. Платформенная команда окупается. Централизованная команда, которая предоставляет кластеры и стандарты продуктовым командам, — общий паттерн всех зрелых внедрений.
2. Стандарты важнее инструментов. Единые подходы к манифестам, меткам, пробам и ресурсам экономят больше сил, чем выбор конкретного CNI.
3. Наблюдаемость — с первого дня. Компании, отложившие мониторинг и логирование «на потом», возвращались к теме после первых инцидентов.
4. Stateful в k8s возможен, но требует зрелости. Базы в кластере успешно работают у команд, которые сначала выстроили бэкапы, мониторинг и дисциплину обновлений.
5. Обучение — часть внедрения. Во всех историях успеха есть блок про рост компетенций команды: курсы, внутренние школы, участие в сообществе.

Типовые сценарии применения

Обобщая публичный опыт российских компаний, Kubernetes чаще всего внедряют для следующих задач:

1. Микросервисная архитектура

Самый массовый сценарий: десятки и сотни сервисов, независимые релизы, автоматическое масштабирование под нагрузкой. Kubernetes даёт единый стандарт развёртывания для всех команд. Характерный признак зрелости: продуктовые команды не «просят сервер», а декларативно описывают сервис и получают его в эксплуатацию через часы, а не недели.

2. Внутренняя платформа разработчика (IDP)

Крупные компании строят поверх Kubernetes платформу самообслуживания: разработчик описывает сервис, а платформа сама создаёт окружение, CI/CD, мониторинг и доступы. Примеры — платформенные команды банков и маркетплейсов.

3. CI/CD и тестовые окружения

Динамические окружения для каждой ветки кода, прогоны тестов в изолированных namespace, эфемерные стенды — Kubernetes делает это дешёвым и быстрым.

4. Данные и ML

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

5. Stateful в Kubernetes

Зрелые команды запускают в кластерах и базы данных: через операторы (PostgreSQL, Kafka, ClickHouse, Redis) с автоматизацией бэкапов и обновлений. Это требует высокой культуры эксплуатации, но публичные примеры успешны.

6. Гибрид и мультиоблако

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

Типовой технологический стек российских внедрений

Судя по публичным материалам, вокруг ядра Kubernetes в российских компаниях чаще всего встречается схожий набор открытых технологий:

Вывод практический: стек cloud native в России максимально интернационален и открыт. Осваивая перечисленные технологии, вы готовите себя к работе в любой из перечисленных компаний.

Если отрасли в таблице нет — скорее всего, она просто пока на более раннем этапе кривой принятия. Судя по темпам, вопрос там не «если», а «когда».

Отрасли, где Kubernetes стал стандартом

Анатомия типичного пути внедрения

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

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

И главное: каждый пример в этом разделе — не повод для преклонения, а приглашение. Все эти компании начинали с первого кластера и первого пода, как и вы сегодня.

Шпаргалка: что взять из публичного опыта

Государственный сектор

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

Карта публичных источников опыта

Форматы команд вокруг Kubernetes

Публичные рассказы компаний показывают, как меняются роли при внедрении k8s:

Эта матрица — хороший ориентир и для личного развития: видно, какие компетенции к какой роли ведут и куда расти дальше.

Типичные ошибки при внедрении

В публичных постмортемах российских компаний повторяются одни и те же уроки:

• Отсутствие requests/limits — самая частая причина нестабильности узлов в молодых кластерах.
• Пробы «для галочки» — readiness, проверяющий «процесс жив», а не готовность обслуживать трафик, пропускает полумёртвые поды в балансировку.
• Игнорирование DNS-нагрузки — CoreDNS становится узким местом раньше, чем о нём задумываются.
• Секреты в git — классика, о которой вспоминают на первом же аудите.
• Обновления «на страх и риск» — без тестового кластера и плана отката; зрелые команды репетируют обновления.
• Перенос монолита «как есть» — контейнеризация без пересмотра архитектуры даёт худшее из двух миров.

Хорошая новость: все эти ошибки уже описаны сообществом, и повторять их необязательно.

Малый и средний бизнес

Не только гиганты. Доступность управляемого Kubernetes в российских облаках изменила рынок и для небольших компаний: интернет-магазины, SaaS-сервисы, студии разработки запускают production в managed k8s, не нанимая отдельных администраторов control plane. Типичный сценарий небольшой команды: один кластер, несколько namespace под окружения, Helm-чарты приложений, мониторинг из облачного маркетплейса — и вся инфраструктура описана кодом в репозитории. Такой же подход годится и для домашних проектов: переносимость навыков между «домашкой» и работой — одно из главных достоинств технологии.

Что спрашивают о Kubernetes на собеседованиях

Анализ публичных требований российских работодателей показывает устойчивый набор тем:

• устройство кластера и роль компонентов control plane;
• поды, Deployment, Service — и чем они отличаются друг от друга;
• сетевая модель, CNI, NetworkPolicy, DNS;
• пробы, ресурсы, QoS, поведение при нехватке памяти и CPU;
• Ingress, TLS, cert-manager;
• RBAC и безопасность манифестов;
• Helm и подходы к доставке (GitOps — большой плюс);
• диагностика инцидентов: что делать, когда «под не стартует»;
• опыт реальной эксплуатации: обновления, отказ узла, бэкапы.

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

Что из этого следует изучающему Kubernetes

1. Спрос системный. Kubernetes нужен не «модным стартапам», а крупнейшим работодателям страны: банкам, маркетплейсам, телекому. Это видно по вакансиям и докладам.
2. Глубина важнее ширины. Компании ищут не «знаком с k8s», а понимание: сети, безопасность, observability, эксплуатация. Именно на эти темы завязаны разделы нашего сайта.
3. Российский контекст реален. Знание отечественных платформ и облаков — конкурентное преимущество при трудоустройстве в РФ.
4. Сообщество открыто. Огромный пласт знаний опубликован бесплатно на русском языке — пользуйтесь.

Следующий шаг — посмотреть на отрасль шире: как устроен рынок, на котором работают все эти компании. Об этом — раздел «Рынок Kubernetes в России».