Разработка публичных облаков *

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

На связи снова Александр Гришин, руководитель по развитию продуктов хранения данных Selectel. В этой статье я разберу доступные параметры конфигурации Kafka-кластеров в облачных базах данных: от настроек репликации и ретеншена до лимитов на продюсеров и потребителей. Мы посмотрим, как каждый параметр влияет на производительность и надежность, приведем практические рекомендации для разных сценариев — от высокочастотных событий до больших архивных потоков.

Материал будет полезен инженерам, которые проектируют архитектуру обмена данными, DevOps-специалистам, отвечающим за эксплуатацию, и разработчикам, которым важно предсказуемое поведение стриминга на продакшене. Погнали!

Как подключиться к облаку надёжно и гибко.

Привет, Хабр! Меня зовут Влад Одинцов, я техлид и product owner сетевых сервисов в K2 Cloud. Мы строим облачную платформу, где стабильное и безопасное подключение клиентов к инфраструктуре — ключевой элемент.

В этой статье расскажу про шесть способов подключения к инфраструктуре клиента в К2 Облаке: от Elastic IP до Direct Connect. Каждый из способов решает разные задачи — от простого доступа по публичным адресам до построения отказоустойчивых архитектур гибридного облака. Расскажу о плюсах, ограничениях и подводных камнях.

Control plane Kubernetes — как сейф с главными ключами. Он управляет кластером, хранит sensitive-информацию и зачастую представляет собой лакомую цель для злоумышленников. 

В этой статье — разбор того, как спрятать control plane в сервисе Managed Kubernetes, предоставляемом в облаке: зачем это нужно, какие варианты существуют и с какими проблемами мы столкнулись на практике. Рассмотрим несколько open source решений, которые протестировали у себя в поисках надёжного способа изолировать control plane-ноды от пользователя и сделать их недоступными для какого-либо внешнего взаимодействия.

Меня зовут Каиржан, я DevOps/Software-инженер в команде разработки
MWS Cloud Platform, пишу на Go под Kubernetes и ClusterAPI. Наша команда разрабатывает сервис Managed Kubernetes для публичного облака — от инфраструктуры до собственных провайдеров для ClusterAPI. Поэтому вопрос безопасности control plane (CP) для нас стоит особенно остро.  

Привет! Меня зовут Сергей Киселев, я Head of Development Platform в MWS Cloud Platform. В 2023 году я пришёл собирать команду Development Platform (DevP) для разработчиков нового облака. Эта статья написана по следам моего доклада «Как с нуля построить Development Platform в отдельно взятой компании» на DevOops 2024. Далее расскажу о том, почему мы заботимся об общем коде, растим культуру разработки и почему только разработчик может сделать инфраструктуру для другого разработчика.

Привет! Меня зовут Евгения Тарашкевич. Я инженер из группы эксплуатации К2 Cloud, и моя специализация — системы хранения данных. Сегодня хочу поделиться с вами опытом и знаниями о работе с объектным хранилищем S3.

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

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

Мы в K2 Cloud не всегда были такими. Наш путь начался более 15 лет назад, и сначала мы были просто провайдером. Но время, опыт и сотни проектов изменили всё: мы прошли путь от первого ЦОДа до облачной платформы собственной разработки с партнёрскими услугами под любой запрос бизнеса. И сегодня я расскажу, как это было — без маркетингового шума, просто как есть.

Меня зовут Кирилл Бойко, я технический директор K2 Cloud, и в облаках (в хорошем смысле) — давно.

Мой коллега, Андрей Квапил, недавно в своей статье «Эволюция платформ виртуализации: как мы пришли к миру managed‑сервисов и как сервис‑провайдерам конкурировать с AWS» выдвинул тезис, что AWS, GCP и Azure предоставляют своим пользователям удобные API.

Привет! На связи Михаил Шпаков, руководитель разработки в Timeweb Cloud.

Мы создаём облако, в котором удобно запускать и управлять проектами: от простых ВДС до масштабных решений с Kubernetes и десятками интеграций. Мы много думаем о том, как сделать инфраструктуру не только стабильной, но и понятной.

Когда вы работаете в облаке, всё выглядит структурировано: список серверов, IP-адресов, баз данных, кластеров. Но в какой-то момент возникает вопрос: а как всё это связано между собой?

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

Мы в Timeweb Cloud решили это изменить. Инфраструктура — это карта, а не таблица. Её нужно рисовать, а не запоминать.

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

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

Привет! Меня зовут Алексей Федулаев, я руковожу направлением Cloud Native Security в MWS Cloud Platform. Вместе с Андреем Моисеевым мы в этой статье подробно разбираем, как устроены атаки на CI/CD, и почему автоматизация без должной защиты может обернуться серьёзными инцидентами.

Мы покажем, как злоумышленник может получить секреты из пайплайна, обойти security-джобы через конфигурации, скомпрометировать Docker Registry и внедрить вредоносный образ в продакшн. Также разберём, почему даже подпись артефактов не всегда спасает, если есть доступ к раннерам и окружению сборки.

Предупреждён — значит вооружён.

Привет! При построении overlay-сети MWS Cloud Platform мы столкнулись с задачей: автоматически раздавать сетевые настройки виртуальным машинам на основе VRF — с полной изоляцией и без конфликтов.

Меня зовут Никита Усатов, я занимаюсь разработкой сервисов облачной сети MWS Cloud Platform. В этой статье расскажу, как устроена наша сеть, зачем понадобился DHCP-сервер с поддержкой VRF, как через VPP реализован DHCP Proxy с Option 82, и какие изменения мы внесли в CoreDHCP. Покажу, как передаются настройки от Control Plane к Data Plane, и как CoreDHCP отслеживает конфигурации без перезапуска. В конце — реальные кейсы отладки и мониторинга.

Привет, Хабр! Меня зовут Глеб Когтев, я руководитель команды VPC Host Components, которая занимается разработкой виртуальной облачной сети для MWS Cloud Platform. C этой статьёй мне помогал Юрий Кондратов — SRE в команде Kubernetes Operations, Research & Engineering (KORE). 

Сегодня поговорим об устройстве сети в Kubernetes-кластере, немного о нашем подходе к обеспечению связности сервисов и чем нам был полезен Multus CNI. Статья будет полезна тем, кто использует Kubernetes в своих задачах и хочет разобраться в устройстве сети, а ещё во взаимодействии компонентов K8s с контейнерами.

Привет! Меня зовут Алексей Баранов, я руковожу направлением Data Storage Systems в облаке MWS Cloud Platform. Мы начинаем серию статей, в которой расскажем, как устроены наши системы хранения, почему мы их делаем так и почему именно такие.

В этой статье расскажу, как мы подошли к выбору технологий для object storage новой облачной платформы. Обсудим плюсы и минусы популярных на рынке решений вроде Ceph RGW, какие требования мы предъявляли к системе, и какая архитектура в итоге получилась.

Привет! Меня зовут Игорь Михалюк, я Tech Lead команды IAM в MWS Сloud Platform. Сегодня поговорим, как мы делаем Identity and Access Management для нашего нового публичного облака.

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

Приветствую всех! На связи Родион Цалкин, Tech Product IaaS в MWS Cloud Platform. 

В этой статье расскажу, из каких решений на верхнем уровне состоит сердце нового облака — Compute — и как знания из разных областей помогают найти элегантные решения для возникающих проблем при его создании. Здесь не будет технического deep-dive’а (ждите в следующих статьях), поэтому статья будет интересна широкому кругу читателей.

Всем привет! Меня зовут Иван Гулаков, последние несколько лет я занимаюсь построением и поддержкой платформы по предоставлению Kubernetes-кластеров для внутренних команд разработки в MWS Cloud Platform. Эта статья — пересказ моего доклада с DevOps Conf 2024 о том, как мы наливаем железки и превращаем их в k8s-кластеры по всем канонам IaC.

За прошлый год наши подходы к наливке изменились. Тем не менее, это был важный шаг для становления нашей внутренней платформы Piñata.

Привет! Я Сергей Самойлов — техлид направления слоя Control Plane для блочных устройств в MWS Cloud Platform. В этой статье рассмотрим модель реконсиляции ресурсов в облаке на примере блочных устройств. Мы рассмотрим, что такое реконсиляция, когда она применяется и как это всё выглядит в MWS.

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

Привет! Я — Борис Хасанов, ведущий сетевой архитектор в MWS, а это продолжение моей статьи о телеметрии, начало можно изучить здесь. В этой части разберём основы сетевой телеметрии, её виды, протоколы и модели.

Привет! Меня зовут Борис Хасанов — ведущий сетевой архитектор в MWS. Работаю с сетями уже много лет, а последнее время занимаюсь сетевой телеметрией. Она помогет мониторить состояние сети облака в моменте.

Это первая статья из цикла о трендах в развитии сетевой телеметрии и её имплементации в облаке MWS. Идея цикла появилась из моего несостоявшегося доклада на сетевой конференции «Яндекс nexthop 2024». Хочу поблагодарить Антона Корнелюка, Евгения Зобницева, коллег из MWS, а ещё коллег из IETF за идеи для этого цикла статей.

Сегодня расскажу о фреймворке ОАМ, его механизмах и протоколах и как он помогает следить за сетью. Итак — начинаем.