Привет, Хабр! Меня зовут Игорь Балюк, совсем недавно я работал платформенным инженером в Авито. В этой статье я рассказываю про Service Mesh и показываю, что это, скорее, не конечная точка, где можно найти «серебряную пулю» от всех проблем, а путь, который, возможно, никогда не закончится: придется постоянно куда-то бежать и что-то дорабатывать. В тексте я также разбираю, как работает Service Mesh в Авито.
Переходите под кат, будет интересно!
Разбираю кейс построения отказоустойчивого пайплайна для аналитики спортивных данных на базе нестабильного API dingerodds com. В статье — реализация обёртки с ретраями и балансировкой, деплой в Kubernetes с автоскейлингом, CI/CD через GitLab и хранение данных в Parquet (MinIO). Показываю, как превратить ненадёжный источник в стабильную платформу для ML и аналитики.
В этом гайде мы рассмотрим 2 способа как легко перенести данные в Persistent Volume из одного Kubernetes кластера в другой без сложных манипуляций и промежуточных скачиваний с помощью Tuna туннелей. Гайд подойдет для любых типов данных, это может быть Wordpress приложение или каталог с картинками, бэкапами, в общем что угодно.
А что, если бы виртуалки вели себя как контейнеры — с миграциями, мониторингом, провижингом томов и GitOps? Мы во «Фланте» так и сделали: совместили Kubernetes с KubeVirt, там-сям допилили и получили решение, которое позволяет запускать виртуальные машины рядом с контейнерами и управляется как обычный кластер Kubernetes.
Привет, Хабр! Я — Олег Сапрыкин, технический директор по инфраструктуре компании «Флант». Сегодня я расскажу, как мы создавали виртуализацию в экосистеме Deckhouse от выбора инструмента для управления ВМ в 2023 году до полноценного продукта, готового к использованию в production весной 2025-го. Подробно опишу, с какими подводными камнями мы столкнулись в процессе эксплуатации и какие доработки потребовались.
В этой статье мы подробно расскажем о пути перехода платформы контейнеризации dBrain.cloud с MaaS на Metal³. Основная задача, которую решают оба этих проекта, состоит в установке операционной системы на серверы платформ. Озвучим причины, по которым мы искали альтернативные решения, и объясним, чем Metal³ превосходит MaaS.
Расскажу про то, как устроен мониторинг в OKD-кластерах, какие у него есть минусы и как мы их побороли, мигрируя основную функциональность на VictoriaMetrics Agent.
Как собрать домашний кластер виртуализации с нуля и зачем это вообще нужно? Автор делится личным опытом: от первых экспериментов с контейнерами и осознания их ограничений до построения полноценной инфраструктуры на мини-ПК.
В статье подробно разбираются этапы выбора и подготовки оборудования, настройка сети и операционной системы, особенности работы с Kubernetes для новичков, а также запуск первых виртуальных машин и организация отказоустойчивого хранилища данных. Материал будет полезен тем, кто хочет разобраться в современных подходах к управлению инфраструктурой и попробовать реализовать собственный проект виртуализации у себя дома.
Привет, Хабр! Меня зовут Алексей Быков, я занимаюсь развитием cloud-native-платформы для обработки данных Arenadata One (AD.ONE). В этой статье мы поговорим о neon-kubernetes-реализации PostgreSQL, её устройстве, особенностях и о том, почему классический подход к Postgres в Kubernetes не позволяет в полной мере использовать преимущества гибкой облачной инфраструктуры.
Тема не новая и активно развивается: уже давно существуют операторы (Zalando, Crunchy Data, CloudNativePG) для автоматизации развёртывания Postgres в Kubernetes. Однако они сохраняют монолитность базы, когда данные по-прежнему жёстко связаны с узлами, а горизонтальное или вертикальное масштабирование требует ручной настройки и остаётся непростым процессом. Подход Neon основан на полном разделении вычислений (compute) и хранилища (storage), что даёт нам возможность взглянуть на использование PostgreSQL в облаке по-новому, как на сервис с возможностью динамического масштабирования, мгновенного запуска инстансов, изолированных веток (branching) и других возможностей без необходимости в сложной инфраструктурной обвязке.
Представьте, что вас каждый день просят «быстренько развернуть стенд» — с OpenSearch, PPO и десятком доработанных инструментов, «ну чтобы все работало». Сначала вы автоматизируете то, что делали руками. Потом автоматизируете автоматизацию. А потом в какой-то момент понимаете: нужно не писать скрипты, а строить полноценный продукт. Так у нас в Orion soft появился HyperDrive — наш способ развернуть Kubernetes-контуры по-настоящему по кнопке. И в этой статье я расскажу, как мы это сделали: от боли и хаоса — к параллелизму, GitOps и здравой инженерной оркестрации.
Привет, Хабр! меня зовут Даниил Рахновский, я — ведущий архитектор в Orion soft. В индустрии DevOps — шесть лет, три из которых веду проекты по HighLoad-инфраструктуре. Основную часть этого времени работал на стороне заказчика, потом перешёл на «тёмную сторону» и теперь работаю на стороне вендора. Занимаюсь сложным проектированием в направлении Professional Services.
Orion soft — это вендор. Мы разрабатываем инфраструктурное программное обеспечение, в портфель которого входит целая экосистема продуктов, а именно zVirt, Nova и другие. В Professional Services мы занимаемся аудитом ИТ-процессов, построением программно-определяемых ЦОДов на собственных технологиях. А еще предоставляем экспертизу вендора и поддержку для пользователей, чтобы наши продукты и технологии правильно и эффективно использовались.
В этой статье по мотивам моего доклада для DevOpsConf 2025 расскажу, как мы решали задачи массового деплоя сложных K8s-окружений. Для этого собрали лучшие практики и применили Open-Source-инструменты, а что-то — дописали с командой самостоятельно. Благодаря этой истории вы убедитесь, что DevOps-инструменты при правильном подходе и оркестрации помогают решать задачи по клику на единственную кнопку.
Мой коллега, Андрей Квапил, недавно в своей статье «Эволюция платформ виртуализации: как мы пришли к миру managed‑сервисов и как сервис‑провайдерам конкурировать с AWS» выдвинул тезис, что AWS, GCP и Azure предоставляют своим пользователям удобные API.
Компания Linx — сервис-провайдер с дата-центрами в Москве и Санкт-Петербурге. Мы развиваем свою облачную платформу и недавно запустили Kubernetes as a Service на базе Deckhouse Kubernetes Platform (DKP).
DKP (№27871 в Едином реестре российского ПО) автоматизирует процессы администрирования и эксплуатации K8s-кластеров, связанные с аутентификацией и управлением доступом, мониторингом и логированием, работой с сертификатами и настройкой отказоустойчивости. В этой статье мы рассмотрим ключевые возможности решения и покажем интерфейс платформы. Будет полезно, если вы задумываетесь о том, чтобы попробовать Kubernetes как сервис из облака и хотите узнать больше о доступных на отечественном рынке вариантах.
Меня зовут Владимир Казеннов. С недавнего времени я руковожу группой развёртывания программного обеспечения (ПО) MES-систем в одном из подразделений нашей дружной ИТ-команды «Северстали». Сегодня я немного приоткрою завесу тайны, покрывающую корпоративный деплой.
По инструментам всё достаточно просто. На столе у нас GitLab, ему когда‑то очень‑очень давно помогал Jenkins, немного Vault, чуть‑чуть Helm. Далее погружаемся в кубер, в его лучшую версию на все времена — RKE (Rancher Kubernetes Engine), там уже и Graylog наблюдает за нами, рядом же крутится Kafka c Redis.
Перевели третий материал из цикла статей о технологической трансформации Mercado Libre. Эта часть посвящена углубленному анализу технических и стратегических аспектов, лежащих в основе решения о переходе на Kubernetes. В ней анализируют рассмотренные альтернативы, сложности, возникшие в процессе внедрения, а также то, как принятые решения продолжают поддерживать мультиоблачную стратегию и операционную устойчивость.
На нескольких проектах я сталкивался с ситуацией, когда есть Kubernetes с разными окружениями типа dev, stage, prod и т. д.
Код сервисов в эти самые окружения попадает в процессе CI/CD: то есть мы мержим какую‑то ветку с разрабатываемой фичей или исправлением бага в ветку, которая «привязана» к окружению и дальше наш код деплоится в кластер. Думаю, для многих — это уже стандартная история.
Давайте представим, что нужно сделать задачу, относящуюся к какому‑нибудь микросервису, эта задача подразумевает запрос по сети к другому микросервису, а тот, в свою очередь, посылает запрос к еще другим микросервисам. Как быть, когда мы хотим, чтобы нам были доступны данные из других микросервисов, чтобы протестировать то, что мы сделали не в тестах с моками, а в условиях, похожих на «боевые». Тут самым очевидным, как мне кажется, является разворачивание локально микросервиса, код которого мы «ковыряем» и проброс портов до целевого микросервиса в dev кластере (или в другом кластере, предназначенным для тестирования), например:
В статье — реальный опыт перехода от классических облачных инстансов к Kubernetes и созданию абстракции Serverless, которая полностью избавила разработчиков от забот об инфраструктуре. Узнайте, как это повлияло на скорость релизов и стабильность сервисов Mercado Libre.
Хабр, привет!
Меня зовут Алиса, и я руковожу командой разработки контейнерной платформы «Штурвал». В последнее время мы с командой много работали над реализацией мультитенантности и перепробовали множество разных вариантов. Ниже я расскажу, как тенанты помогают закрыть «боли» при работе с K8s на примере трех проблем и поделюсь полезными инструментами.
Эта статья будет интересна тем, кто:
👉 «с ноги» врывается в свой первый кубер;
👉 самостоятельно строит Kubernetes-платформу;
👉 управляет одним или множеством кластеров K8s.
P. S. 31 июля в Москве состоится первая независимая конфа Kubernetes Community Day. Два пространства с хардкорными докладами и воркшопами от крутых экспертов из VK, МКБ, Yandex Cloud, «Лаборатории Числитель», ecom.tеch, Cloud ru, Luntry, FUN&SUN, Lamoda Tech и др. Участие бесплатное. Регистрация тут.
Перевели для вас цикл статей об эволюции технологической платформы Mercado Libre — от монолитной архитектуры начала 2000-х к современной мультиоблачной платформе Fury, которая обеспечивает разработчикам удобную, масштабируемую и безопасную среду для создания, развёртывания и управления приложениями. В этой первой части описывается переход компании от единой базы и медленных релизов к микросервисам и облачным технологиям, что позволило значительно ускорить разработку и повысить надежность систем.
В статье рассматривается подход к снижению энергозатрат Kubernetes-кластера путём динамической подстройки ресурсов под реальный профиль нагрузки. Описан опыт внедрения системы сбора показателей энергопотребления, построения модели потребления сервисов и разработки «умного» контроллера на Go. Приведены примеры кода для Python и Go, а также разбор неожиданных подводных камней, с которыми столкнулся инженер.
В System Design нет «правильных» решений — только компромиссы. Бюджет, сроки, команда и законы диктуют, какие технологии выбрать, как масштабироваться и когда идти на жертвы. Разберём, почему определение бизнес-ограничений это важный этап System Design и почему они диктуют Айтишникам как и с чем работать.
В первой части мы разобрались с принципами работы Ingress-nginx контроллера. Теперь пришло время углубиться в то, как в Ingress-nginx устроен механизм обновления бэкендов и как реализована балансировка нагрузки на примере sticky sessions. Готовы узнать больше? Поехали!
Напомню, если вдруг забыли, эта статья написана по мотивам выступления на DevOpsConf’25, а меня зовут Алексей Колосков, я Lead DevOps из Hilbert Team.
Итак, рассмотрим, как реализовано обновление бэкендов в самом контроллере.
