Kubernetes *

Hugging Face взломали через датасет: автономный AI-агент дошёл до внутренних кластеров

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

Цепочка атаки

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

Агентный фреймворк выполнил тысячи операций в короткоживущих средах, а C2 мигрировал между публичными сервисами. Какая LLM использовалась, неизвестно. Независимого подтверждения полностью автономной атаки нет.

Что раскрывают исправления

Hugging Face не опубликовала CVE, payload или карту эксплуатации, но изменения в публичном dataset-viewer раскрывают часть механики.

13 июля разработчики обновили fsspec и ввели allowlist: worker теперь принимает только hf, s3, zip, file и local, а остальные реализации удаляются из registry. Использовавшийся ранее fsspec.ReferenceFileSystem обрабатывал конфигурацию через несандбоксированный jinja2.Template(...).render(...). Это согласуется с заявленным внедрением шаблона и возможным SSTI-to-RCE, но компания официально не связала этот код с атакой.

В тот же день усилили worker-поды: отключили Kubernetes ServiceAccount token, включили seccompProfile: RuntimeDefault и сбросили дополнительные возможности ядра Linux. Точный способ перехода к уровню узла не раскрыт.

Следующие изменения соответствуют ротации секретов. 14 июля в production слили переход на IRSA, убирающий статические S3-ключи. 15 июля MONGO_URL перевели на MONGODB-AWS через IRSA, затем добавили ротацию JWT-ключей. PR совпадают с реагированием, но не названы официальным postmortem.

Масштаб и атрибуция

Подтверждён доступ к части внутренних датасетов и служебным учётным данным. Их количество, права и объём возможной выгрузки не названы. Признаков изменения публичных моделей, датасетов или Spaces не обнаружено; контейнерные образы и пакеты признаны чистыми.

Ни одна группировка не представила проверяемого заявления об ответственности или доказательства доступа. Публичных IoC тоже нет. Связь с JADEPUFFER, имена OpenAI или Anthropic, «первый полностью автономный взлом», а также сообщения о 4200 токенах и 1800 приватных моделях источниками не подтверждаются.

Как расследовали

Атаку обнаружила корреляция телеметрии с LLM-триажем. Аналитические агенты обработали более 17 000 событий, восстановили хронологию, извлекли IoC для внутреннего расследования, сопоставили затронутые credentials и отделили реальные действия от отвлекающей активности.

Коммерческие модели блокировали запросы с командами атакующего, эксплойтами и C2-артефактами. Форензику перенесли на локальную GLM 5.2 от Z.ai: журналы и найденные секреты остались внутри инфраструктуры. GLM использовали защитники; модель атакующего не установлена.

Hugging Face закрыла оба пути исполнения кода, пересобрала скомпрометированные узлы, отозвала затронутые токены, начала более широкую ротацию секретов и усилила admission controls. Пользователям рекомендуют заменить токены и проверить недавнюю активность аккаунта.

Источники

• Официальное раскрытие Hugging Face

• The Hacker News

• Исходник fsspec.ReferenceFileSystem

AI-нагрузка пришла в прод: Serverless или Kubernetes?

Когда команда приносит очередную AI-фичу, инфраструктуре быстро приходится отвечать на вполне приземлённые вопросы: где её запускать, как масштабировать, что делать с GPU, состоянием и холодным стартом — и во сколько всё это обойдётся после выхода в прод.

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

21 июля в 20:00 на бесплатном уроке разберём, как сравнивать Serverless и Kubernetes для AI-ворклоадов и какие ограничения учитывать до того, как архитектурное решение превратится в дорогую миграцию. Отдельно посмотрим на холодный старт, работу с состоянием, поддержку GPU, масштабирование и гибридные сценарии.

Другие бесплатные уроки от экспертов по инфраструктуре, Linux, K8s, сетям, безопасности и наблюдаемости собрали в дайджесте.

Астрономический научный центр модернизировал оркестрацию космического мониторинга с помощью ITFB Group

Астрономический научный центр (АНЦ) завершил масштабную модернизацию своей управляющей платформы. Интегратором выступила компания ITFB Group, которая помогла центру перейти на более надёжную и масштабируемую инфраструктуру, автоматизировать процессы разработки и обновления, а также гарантировать безотказную доставку критически важных данных о космических объектах.

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

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

Михаил Атрахимович, директор направления разработки ITFB Group, отметил: «В проекте для АО "АНЦ" мы использовали накопленный опыт создания высоконадежных платформ оркестрации бизнес-процессов. Основная сложность заключалась в том, что модернизацию необходимо было проводить без остановки уже работающей системы. В результате заказчик получил отказоустойчивую и масштабируемую платформу, готовую к дальнейшему развитию и увеличению объемов обработки данных».

Николай Савин, технический директор АО «АНЦ», добавил: «Сотрудничество с ITFB Group стало для нас важным этапом в развитии нашей системы оркестрации. Мы получили не только исправление текущих недочётов, но и чёткую дорожную карту, а также полный пакет эксплуатационной документации. Благодаря этому проекту мы уверены в надёжности и масштабируемости нашей платформы и готовы к дальнейшему расширению функционала».

В результате проекта АНЦ получил отказоустойчивую инфраструктуру enterprise-уровня, гарантированную доставку событий, автоматизированный релизный цикл и полный комплект эксплуатационной документации (мониторинг, алертинг, процедуры backup с RTO, регламенты при инцидентах).

Как на собственных серверах настроить систему сбора и хранения данных с датчиков и снизить нагрузку на команду эксплуатации

Собрать данные с датчиков — это полбеды. Главная боль — заставить Kafka, PostgreSQL и ClickHouse стабильно работать в приватном облаке без выгорания команды на Day-2-операциях и ручном масштабировании stateful-сервисов.

На вебинаре покажем, как на Deckhouse Kubernetes Platform (DKP) и managed-сервисах упаковать IoT-сценарии и аналитический контур в единую платформу, чтобы снизить стоимость эксплуатации и уйти от DIY-подхода к data-инфраструктуре.

Зарегистрироваться на вебинар

В программе:

• Разберём схему event-driven-платформы и разделение операционного и аналитического контуров.

• Покажем live-demo: ingest событий с датчиков, потоковая обработка и вывод в дашборды.

• Проверим, как паттерны из умного дома масштабируются до промышленного IoT на DKP.

• Разберём жизненный цикл data-сервисов (backup, scaling, observability) и то, сколько времени занимает их обслуживание.

Бонусы: промокод на все курсы Deckhouse Академии.

Будет полезно DevOps и SRE-инженерам, инфраструктурным и платформенным командам, enterprise-архитекторам и всем, кто строит IoT- и data-платформы в private cloud или on-prem.

Спикер — Дмитрий Гайворонский, менеджер по развитию направления Deckhouse Data Orchestration.

Регистрируйтесь и подключайтесь 10 июля в 12:00 (МСК). 

Релиз ≠ деплой: почему прод падает именно после обновлений

Большинство крупных инцидентов происходят сразу после релиза. Не во время нагрузочного теста, не в случайный вторник — а именно тогда, когда команда только что что-то выкатила и выдохнула. Почему так, если всё прошло тестирование?

В новом выпуске «В SREду на кухне» вместе с Артёмом Гетманским, техруком юнитов в Авито, и Андреем Мухиным, TechLead из MWS, разобрались: что вообще считается релизом, чем он отличается от деплоя — и как не превратить каждое обновление в рулетку.

Что на повестке

Оказывается, релиз может сломать прод даже без единой строчки нового кода — и это не баг, а особенность современных систем. Разбираем, как Feature Flags, Canary, Blue-Green и Rolling-стратегии помогают снизить риск, когда hotfix тоже считается релизом и что с этим делать, и как error budget влияет на то, насколько смело команда вообще решается катить изменения.

Отдельно досталось вопросу, должны ли SRE участвовать в продуктовых релизах — и у участников выпуска на этот счёт нашлись весьма конкретные мнения.

🔵 VK Видео 
📺 YouTube
📌 RuTube
Ⓜ️ Mave

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

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

На вебинаре расскажем, как собрать весь зоопарк решений в единую систему с помощью MWS B2B Store. Разберем деплой инсталляций, когда разные ноды находятся на разных инфраструктурных провайдерах, доставку и обновления в закрытых контурах, версионирование и распространение внутренних и внешних решений.

В прямом эфире в режиме демо покажем:

• Деплой сервисов (VMware + K8S) для разных сред, имплементацию Terraform as a service.

• Автоматическое развертывание в изолированные контуры: от стандарта упаковки до «раскатки» в гибридную инфраструктуру.

• Как управлять лицензиями на серверное ПО и контролировать, кто, где и сколько использовал.

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

Будет полезно CTO, DevOps, директорам по инфраструктуре и тимлидам инфраструктурных команд.

📅 Когда: 30 июня в 11:00 мск.

📍 Где: онлайн. Зарегистрируйтесь, подключайтесь и задавайте вопросы нашим экспертам в чате трансляции.

Подборка материалов, которые помогут снизить стоимость, стабилизировать прод и перестать гадать с ресурсами

Среди читателей Хабра много ML‑инженеров, дата‑сайентистов и дата‑инженеров — и мы, как команда провайдера облачных и ИИ-сервисов, догадываемся, где у вас чаще всего болит. Ниже подборка материалов, которые помогут в решении задач: чуть ускорить, чуть удешевить, чуть упростить жизнь в проде. 

👨‍💻 ML/DS‑инженеры и бэкенд

Боль №1

Суть: вы крутите LLM в проде, токены стоят денег, контекст забивается громоздким JSON, а латентность растет.
Что делать:  прочитать статью — как практическое руководство по переходу с JSON на компактный TOON‑формат для структурированных ответов. 
Почему: в ряде кейсов можно сэкономить до ~40% токенов, но есть нюансы. Формат лучше работает при небольшой вложенности (3–4 уровня) и однородных массивах. Для плоских данных чаще выгоднее CSV. Плюс потребуется свой парсер/SDK — это усложняет дебаг и интеграцию.

Боль№2

Суть: нужно обогатить поисковую выдачу или интерфейс LLM‑функциональностью, но непонятно, как выдержать нагрузку и не превратить кластер в черную дыру для бюджета.
Что делать: взять на вооружение материал от Avito Tech — эдакий «рентген» продакшен‑архитектуры с LLM/мультимоделями под серьезной нагрузкой. 
Почему: хороший слепок боевой системы с vLLM и LoRA, организацией GPU‑кластера, схемой запросов и мониторинга качества. Учитывая масштабы, команду и бюджеты Avito, «копировать-вставить» вряд ли получится, но по крайней мере есть опорная схема, как декомпозировать сервисы, и на какие метрики смотреть при проектировании.

👨‍💻 Data Science, MLOps, DevOps

Боль №3 

Суть: модели живут в «ручных» скриптах, развертывание нестабильно, автоскейлинг либо отсутствует, либо работает хаотично. Не всегда получается договориться с коллегами о процессе вывода из ноутбуков в прод, который бы всех устроил. 
Что делать: читать нашу статью, где разбирается жизненный цикл ML‑модели в Kubernetes.
Почему: показана связка контейнеризации, CI/CD и деплоя с учетом ML‑нагрузок. Это не универсальный рецепт (пример завязан на инфраструктуру Cloud.ru), но помогает синхронизировать ожидания между DS и MLOps, чтобы было от чего оттолкнуться. 

👨‍💻 ML‑инженеры и исследователи 

Боль №4

Суть: эксперименты падают из-за CUDA out-of-memory, приходится наугад крутить размер батча, длину контекста и конфигурацию кластера. Каждый запуск — лотерея и потерянные GPU‑часы.
Что делать: читать перевод зарубежной статьи с разбором оценки потребления памяти на примере GRPO.
Почему: объясняет, из чего складывается потребление памяти и как прикинуть конфигурацию до запуска. Это не калькулятор «до байта», поскольку значения зависят от стека, наличия обучения со смешанной точностью или распределенного обучения, — но как ориентир экономит время и нервы.

👨‍💻 Enterprise DS (ритейл, финтех, телеком, индустрия)

Боль №5

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

Пишите в комментариях, где еще болит. В следующий заход попробуем принести что-то точечно под ваши задачи.

GitOps без романтики: эксплуатация, советы, решения

Есть подходы, которые в докладах на конференциях звучат как откровение. Git — единственный источник правды, всё декларативно, прод руками не трогаем, система сама себя лечит. А потом наступает понедельник, и выясняется, что кто-то всё-таки поправил что-то руками, конфиг задрейфовал, а rollback работает ровно до того момента, пока не нужен по-настоящему.

В новом выпуске «В SREду на кухне» поговорили о GitOps без хайпа — с Михаилом Кожемским, Lead DevOps в Банк 131, и Павлом Селивановым, руководителем продуктового направления DevTools в Яндекс Клауд.

Что на повестке

Разбираем, чем push-модель отличается от pull и почему выбор между ними — это не вкусовщина, как Argo CD и Flux ведут себя в реальной жизни, а не в туториалах, и почему иллюзия «Git = реальность» — одна из самых дорогостоящих в инфраструктуре. Отдельно — про конфигурационный drift, Terraform и Crossplane, и что GitOps до сих пор так и не научился решать.

Если вы уже внедрили GitOps и думаете «что-то пошло не так» — или только собираетесь и хотите знать, что именно пойдёт не так — этот выпуск для вас.

Смотрите видео на площадках:

🔵 VK Видео 
📺 YouTube
📌 RuTube
Ⓜ️ Mave

Опубликовали митигацию CVE-2026-31431 для Deckhouse Kubernetes Platform

Уязвимость затрагивает модуль ядра Linux algif_aead (интерфейс AF_ALG). До выхода обновлений ядра в дистрибутивах предлагаем временное решение на уровне платформы.

В репозитории:

• NodeGroupConfiguration, который блокирует загрузку модуля и выгружает его, если он загружен;

• FalcoAuditRules для детекта попыток эксплуатации (доступно в DKP EE и CSE).

Применяется через kubectl apply, подробности и инструкции в README.

Selectel начисляет до 30 000 бонусов на облачные сервисы

Привет, Хабр! Если вы ИП или юрлицо и ранее не использовали облачные базы данных или Managed Kubernetes в Selectel — можете получите до 30 000 бонусных рублей на тест этих продуктов.

Сервисы позволяют:

✔️ повысить стабильность высоконагруженных сервисов,

✔️ сократить время на релиз новых продуктов,

✔️ уменьшить расходы на IT-инфраструктуру.

Чтобы получить грант, нужно создать тикет от юридического лица или ИП с описанием нужной конфигурации — и мы начислим до 30 000 бонусов на облачные базы данных и Managed Kubernetes в Selectel.

Вебинар: от Pod Security Standards к полноценной модели безопасности подов в Deckhouse Kubernetes Platform

Pod Security Standards ограничивают privileged-контейнеры, hostPath и capabilities. Однако реальные риски безопасности шире. Неконтролируемые registry, отсутствие лимитов на ресурсы, образы без фиксированных тегов, контейнеры без health-проверок — всё это расширяет поверхность атаки. 

28 апреля в 12:00 на вебинаре Deckhouse Академии разберём, как выстроить полноценную модель безопасности пода средствами Deckhouse Kubernetes Platform:

• как SecurityPolicy и OperationPolicy в DKP закрывают то, что PSS оставляют открытым;

• как Gatekeeper превращает декларативные политики в версионируемый код, который можно проверить в CI/CD;

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

Зарегистрироваться на вебинар →

ingress-nginx официально переведён в архив

24 марта 2026 года репозиторий kubernetes/ingress-nginx переведён в архив и стал read-only.

Проект просуществовал более восьми лет, набрал 20 тысяч звёзд на GitHub и стал стандартом для HTTP-маршрутизации в Kubernetes. Теперь поддержка и разработка полностью прекращена: новых релизов, багфиксов и патчей безопасности не будет.

Причина архива: ресурс Ingress изначально был слишком ограничен. Весь расширенный функционал реализовали через vendor-специфичные аннотации, нормального RBAC не было, протоколы: только HTTP/HTTPS. Gateway API решает все эти проблемы на уровне спецификации.

Мейнтейнеры рекомендуют переходить на реализации Gateway API:

"If you are not already using ingress-nginx, you should not be deploying it as it is not being developed. Instead you should identify a Gateway API implementation and use it."

Источник

Актуальные варианты: NGINX Gateway Fabric, Cilium, Envoy Gateway, Istio, Traefik.

Не только расскажем про железо, но и покажем ⚙️

Регулярно делимся новостями про наше оборудование, а сегодня сделаем это в видеоформате.

Сняли ролик с Владом Олейником, ведущим инженером ЦОД.

Он разобрал серверные платформы ASUS на базе AMD и Intel и рассказал, где их использовать, чем они нам понравились и на что обратить внимание.

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

Смотрим на ютубе, в вк и на рутубе.

Кстати, скоро покажем больше видео про внутрянку облака и интересные кейсы. На очереди — Kubernetes.

Разворачиваем приватную LLM в кластере Kubernetes в прямом эфире

Начинаем через 30 минут, в 12:00 мск. Эксперты вместе с вами пройдут весь путь от подготовки кластера до готового интерфейса: настроят мониторинг, распределенные модели, интеграции и даже автоматизацию инфраструктуры.

Подключиться к трансляции →

Будет полезно DevOps- и SRE- и ML-инженерам, архитекторам и продакт-менеджерам.

О чем поговорим

— Почему клиенты все чаще выбирают приватные LLM.

— Как выделенные GPU-серверы решают задачи безопасности, производительности и стоимости. 

— Сравним стоимость владения облаком и физическими серверами на реальных кейсах. 

— Почему Kubernetes — идеальная платформа для управления LLM в проде.

— Воркшоп: разворачиваем приватную LLM от подготовки кластера до удобного интерфейса.

Подключайтесь к трансляции в VK и на YouTube.

Kubernetes, Swarm, Nomad — как выбрать оркестратор и не пожалеть

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

Оркестратор берет это на себя. Но выбор между Kubernetes, Docker Swarm, Nomad, Mesos и OpenShift — не очевидный. У каждого своя ниша, и «взять Kubernetes, потому что все берут» — одна из самых частых ошибок при внедрении.

Разобрали, как работают оркестраторы изнутри, чем они отличаются на практике и по каким критериям выбирать под конкретный проект. Плюс чек-лист запуска и типичные грабли — от избыточной сложности на старте до игнорирования безопасности.

Ищите подробную инструкцию на сайте Рег.облака.

Основы работы с Helm: как упростить деплой в Kubernetes

Helm — это менеджер пакетов для Kubernetes. По сути, он делает для кластеров то же, что apt для Linux или npm для JavaScript: позволяет устанавливать приложения как готовые пакеты, а не собирать всё вручную из десятков YAML-файлов.

В основе Helm — чарт: набор шаблонов с описанием ресурсов Kubernetes. При установке создается релиз с собственной историей версий — можно обновлять приложения, отслеживать изменения и при необходимости быстро откатываться. А еще Helm объединяет десятки ресурсов в один пакет и позволяет переиспользовать конфигурации для разных окружений через values.yaml.

В блоге разобрали установку Helm, основные команды, работу с репозиториями и релизами, проверку чартов перед деплоем, управление зависимостями и откаты. Читайте на сайте Рег.облака.

Что такое Portainer и зачем он нужен для управления Docker

Ранее мы уже разбирали базовые команды Docker и повседневную работу с контейнерами. Следующий логичный шаг — упростить управление окружениями и сделать его наглядным.

Сегодня поговорим о Portainer — графическом интерфейсе для управления Docker, Kubernetes и Podman. В новой статье показали, какие задачи он решает, в каких сценариях действительно полезен и чем отличается от работы через командную строку. Отдельно разобрали ключевые возможности: управление контейнерами и образами, просмотр логов и статистики, работу с сетями и томами, запуск приложений через docker-compose и готовые шаблоны.

Пошаговая инструкция по установке Portainer через Docker-контейнер и подсказки, с каких разделов удобнее начать работу — в базе знаний Рег.облака.

Делюсь находкой...

Если тебе надо быстро потыкать что-то из Linux / контейнеров / сетей / namespaces / cgroups, но при этом не хочется поднимать VM, ставить Docker, ковырять окружение, то iximiuz labs playgrounds - это прям топ штука.

Это набор готовых интерактивных лаб, где ты заходишь в браузере и просто:

• запускаешь контейнеры

• смотришь namespace’ы

• играешься с сетью

Причём самое классное, что там не “прочитай статью”, а прям сценарий + терминал + что делать. То есть зашёл → запустил → увидел результат → понял, как оно работает.

---

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Kubernetes Zero to Hero — базовый видеокурс от «Фланта»

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

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

• поднимете локальный кластер и разберётесь в ключевых сущностях Kubernetes;

• научитесь развёртывать приложения, пройдя путь от коммита кода в Git-репозиторий до его выката в кластер;

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

• познакомитесь с werf и Helm, шаблонизацией чартов и практиками реальных проектов.

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

• YouTube

• Rutube

• ВК Видео

Каждую неделю будет выходить по два ролика — по вторникам и четвергам. Присоединяйтесь, будем вместе проходить путь от новичка до Kubernetes Hero.

Уже в следующий вторник — развернем Kubernetes-кластер за 15 минут

2 декабря в 11:00 по мск подключайтесь к next-next-next инсталляции кластера из GUI.

После нее пройдемся и по другим обновлениям релиза «Штурвал 2.12»:

• Изменение UI создания кластера: статусная модель и контроллер управления кластерами.

• Развертывание на OpenStack с использованием нативных балансеров и сертификатов Let's Encrypt.

• Поддержка Cinder CSI и Ubuntu 24.04.

Вебинар будет интересен DevOps-инженерам и архитекторам, разработчикам, специалистам служб эксплуатации.

Регистрация

PostgreSQL на 4 ТБ, Patroni на две столицы и 16 000 фур в реалтайме: как мы «перевозили» CARGO.RUN

Привет, Хабр! Представьте ситуацию: один логист управляет 80 машинами одновременно. Маршруты, топливо, простои — все в реальном времени. Остановись сервер — бизнес сразу теряет деньги, а на перевозчиков сваливается хаос.

Именно таков мир, в котором работает команда CARGO.RUN — SaaS-платформа, которая автоматизирует грузоперевозки для топ-игроков рынка. Мы подготовили кейс о том, как помогли CARGO.RUN мигрировать к нам в Selectel. Внутри — настоящий технический детектив и архитектурный дзен.

• Базы данных — почему для PostgreSQL с расширениями PostGIS и Timescale (а это 4 ТБ «горячих» данных!) выбрали именно выделенные серверы, а не облако.

• Отказоустойчивость — как развернули кластер Patroni, физически разнесенный между дата-центрами в Москве и Санкт-Петербурге, чтобы пережить падение целого региона.

• Оркестрация — переход от Docker Swarm к Managed Kubernetes для микросервисов, когда в штате всего три DevOps-инженера.

• IaC — как Terraform и GitOps помогли навести порядок и сделать инфраструктуру прозрачной.

Результат миграции — рост производительности логистов в 2,5 раза и сокращение порожнего пробега фур на 53%.

Читайте полную историю переезда, а также оставляйте заявку на бесплатную миграцию➡️

25 ноября в 17:00 мы проведем вебинар «5 способов потерять кластер Kubernetes. Угрозы, о которых вспоминают слишком поздно».

Разберем реальные инциденты, связанные с:

🔹 аспектом хвостовой ОС кластера,
🔹 проблемой настройки Kubernetes,
🔹 безопасностью образов,
🔹 YAML-ресурсами K8s,
🔹 контейнерами.

Вебинар будет полезен DevOps- и DevSecOps-инженерам, архитекторам, руководителям инфраструктурных команд, — всем, кто отвечает за устойчивость и безопасность сервисов.

Спикеры — эксперты в вопросах обеспечения безопасности в контейнерезированных средах.

🔹 Алексей Волков, лидер направления Developer Productivity в VK Cloud, VK Tech

🔹 Дмитрий Евдокимов, основатель и технический директор Luntry, Kubernetes-native платформы для контроля и безопасности контейнерной инфраструктуры

Регистрируйтесь, чтобы получить напоминание и ссылку на трансляцию вебинара.

Минималистичные healthcheck-утилиты для Docker-контейнеров

Однажды я был маленький, и задавался вопросом - вот собираешь ты свое приложение, нежно помещаешь его в Docker-образ, заботишься о том чтоб и зависимостей было поменьше, и скомпилируешь его так чтоб итоговая каша из байт было погуще, но покомпактее; используешь scratch, статическую линковку, но чтоб "из коробки" был еще и healthcheck - приходится или писать свой мальний чекер каждый раз, или тянуть статичкски слинкованный curl/wget, если приложение работает как http сервер.

Потому что без healthcheck жизнь ну совсем не торт, даже при локальной разработке, когда запускаешь уже готовые образы, ставишь их в зависимость для других (в том же docker compose) - без него это все работать не будет так, как тебе хочется - демоны будут стучаться друг к другу без уважения и учета, готово оно в этому или нет.

Так родился microcheck - набор крошечных статически скомпилированных бинарников, созданных специально для healthcheck-ов. Они не имеют зависимостей от динамических библиотек, написаны на C, и работают даже в scratch и distroless образах, да умеют корректно возвращать exit-коды, понятные Docker’у (0 - здоров, 1 - приходи завтра).

В комплекте:

• httpcheck — проверка HTTP-эндпоинтов (~75 KB)

• httpscheck — то же самое, но с TLS и автоопределением протокола (~500 KB)

• portcheck — проверка TCP/UDP-портов (~70 KB)

У вас в продакшене наверняка Kubernetes, и все проверки делает kubelet - скорее всего, вам не нужно ничего менять. Но если вы запускаете контейнеры в «голом» Docker’е или других рантаймах без встроенных healthcheck-ов - такие инструменты могут здорово упростить жизнь.

Как выглядит в деле:

# Было (+~10MB)
RUN apt update && apt install -y curl && rm -r /var/lib/apt/lists/*
HEALTHCHECK --interval=10s CMD curl -f http://localhost:8080/ || exit 1

# Стало (+~75KB)
COPY --from=ghcr.io/tarampampam/microcheck /bin/httpcheck /bin/httpcheck
HEALTHCHECK --interval=10s CMD ["httpcheck", "http://localhost:8080/"]

Разница по размеру в десяток мегабайт против семи десятков килобайт, а в качестве бонуса - не нужен shell-процесс, всё работает напрямую и быстро (а еще и в переменные окружения умет).

Поддерживаются все популярные архитектуры (x86_64, ARM, ppc64le, s390x и др.), есть готовые образы в GitHub Container Registry и Docker Hub.

Посмотреть исходники, примеры Dockerfile и prebuilt-бинарники можно тут: github.com/tarampampam/microcheck

Как масштабироваться в Kubernetes автоматически и экономически выгодно? Расскажем через 15 минут

Подключайтесь к вебинару сегодня в 16:00 мск. Покажем, как Karpenter в кластерах Managed Kubernetes помогает оптимизировать затраты на инфраструктуру, и объясним, как использовать этот инструмент. Присоединяйтесь!

В программе:

✔️ Обзор возможностей Karpenter и его сравнение с Cluster Autoscaler;

✔️ Воркшоп по настройке решения в кластерах Managed Kubernetes;

✔️ Кейсы применения Karpenter. Оптимизация GPU-инфраструктуры с сервисом.

В конце ответим на вопросы — задавайте их в форме регистрации. На вебинаре особенно полезно будет DevOps-инженерам, техлидам и СТО, системным администраторам и архитекторам.

Подключайтесь к трансляции:

👉 YouTube

👉 VK

Как построить ML- AI-инфраструктуру или ускорить существующие AI-проекты

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

Приглашаем на вебинар о новой редакции нашей платформы котнейнеризации – Nova AI. Покажем новую версию платформы, созданную специально для ML-и AI-задач и расскажем, как она упрощает запуск инфраструктуры для ML/DS-команд, ускоряет развертывание локальных LLM-и AI-сервисов и сокращает расходы на GPU до 95%.

О чем еще поговорим:

 Как развивается рынок AI и почему компании переходят на локальные LLM

Что представляет собой Nova AI и чем она отличается от классического Kubernetes

Как построить инфраструктуру для ML-проектов за 1 день

Реальные кейсы, технологический стек, безопасность и комплаенс

Дорожная карта продукта и шаги внедрения

Вебинар будет особенно актуален для ИТ-директоров, архитекторов, инженеров по данным и всех, кто отвечает за развитие ИИ в компании. Регистрация доступна по ссылке.

Orion soft выпустил новую редакцию платформы контейнеризации – Nova AI

Мы представили новую редакцию платформы контейнеризации Nova Container Platform, созданную специально для работы с ИИ и машинным обучением. Это первое отечественное Kubernetes-решение, оптимизированное под инфраструктурные и эксплуатационные задачи ML/AI. 

Nova AI помогает ИТ-командам и ML/DS-специалистам быстро запускать и масштабировать инфраструктуру для обучения моделей, развертывания LLM-сервисов и инференса, обеспечивая при этом безопасность, совместимость с российскими операционными системами и эффективность использования GPU.

Новая редакция разработана как решение ключевых проблем, с которыми сталкиваются компании при запуске и развитии проектов, связанных с ML и AI. Среди них высокая стоимость GPU и оборудования, дефицит опытных MLOps-инженеров, сложности с безопасностью и соответствием требованиям регуляторов, низкая утилизация ресурсов, долгое развертывание и настройка инфраструктуры под LLM и AI-сервисы.

Ключевые преимущества Nova AI

Для ИТ-руководителей Nova AI обеспечивает ощутимую экономию ресурсов: за счет виртуализации и дробления мощностей она позволяет сократить затраты на GPU до 70%. Решение ускоряет выдачу инфраструктуры, помогает соблюдать SLA и упрощает управление благодаря унифицированному кластеру, подходящему для всех AI- и ML-задач. Nova AI также поддерживает требования по информационной безопасности и комплаенсу, обеспечивая защиту токенов и данных. Платформа гибка в размещении, она может быть развернута как на bare-metal, так и в виртуализированной среде (включая отечественную платформу виртуализации zVirt), с полной поддержкой российских операционных систем, таких как Astra Linux и РЕД ОС.

Инженеры и ML-специалисты получают готовое рабочее окружение на базе таких инструментов, как JupyterHub, MLflow, Airflow и MinIO, что позволяет быстро приступить к работе. Кроме этого, Nova AI обеспечивает стабильную работу драйверов и предсказуемость поведения инфраструктуры. Безопасность встроена по умолчанию: используется контейнерная защита NeuVector и централизованное управление секретами с помощью StarVault. Платформа сокращает время на запуск и настройку, а также сопровождается подробной документацией и технической поддержкой на всех этапах внедрения и эксплуатации.

«Сегодня мы видим особый спрос на нашу платформу со стороны промышленных и нефтегазовых предприятий, банков и финтех-организаций, ритейлеров с развитыми аналитическими командами, а также государственных структур, где важно быстро и безопасно развернуть инфраструктуру для ИИ и машинного обучения. Nova AI выбирают там, где нужно ускорить запуск LLM- и AI-сервисов, снизить затраты на оборудование и перейти от разрозненных экспериментов с моделями к управляемой и масштабируемой ML-платформе уровня Enterprise», – прокомментировал Александр Фикс, лидер продукта Nova Container Platform в Orion soft.

Задача с system design interview как тема для пет проекта

Здравствуйте, уважаемые читатели. Интересуюсь микро сервисной архитектурой. Хотел бы написать серию статей, в которых поделюсь своим опытом создания пет проекта на микросервисах. Общее название - "Задача с system design interview как тема для пет проекта". В качестве задачи будет система сокращения ссылок. Хочу показать весь путь от реализации первой крайне упрощенной версии до полноценной версии с кешированием, базой данных и размещением на сервере. Система будет реализована на Golang. На Хабре уже есть статья с такой темой. Как Вы думаете нужны ли еще статьи по данной тематике?

Лучший стэк для запуска MVP SaaS-стартапа в РФ на 2025 год.

Вот наш боевой стэк, который мы сейчас используем для разработки SaaS-стартапа.

Проверено на собственной шкуре!

✅ Frontend:

- NextJS 15 (+React 19, Turbopack, Server Actions) - актуальный стек для веб-приложений.

- Shadcn UI (сделана на Tailwind) - библиотека UI-компонентов, чтобы сделать крутой интерфейс без дизайнеров.

- Netlify - бесплатный хостинг для тестовой версии продукта.

✅ Backend:

Supabase:

- База данных

- Database SQL Functions (функции сразу в базе PostgreSQL)

- Edge Functions (серверные функции на TypeScript)

Nextauth:

- Авторизация

✅ Инфраструктура:

Kubernetes:

- Репликация БД и сервисов на 3-х Worker-нодах

- Rollout-обновления без простоя

- Политики безопасности и изоляция

- CI/CD из GitHub.

+ Пароли/ключи в KeePass XC.

✅ Инструменты:

- IDEA Ultimate - среда разработки

- Cursor - для вайбкодинга (чистый, без всяких инфоцыганских MCP)

- DBeaver - для работы с БД

- GitHub - репозиторий

✅ Платежка

- Robokassa (РФ + иностранные платежи)

✅ Лендинг + блог

- Tilda (проще сделать сайт на конструкторе, чем все это вайбкодить)

Как мы все настроили

- Развернули проект в облачном хостинге в РФ, чтобы хранить данные в соответствии со 152 ФЗ. Выбрали хостинг с k0s, потому что он дешевле классического k8s.

- Supabase поставили на свой сервер (Cloud не подходит, так как данные хранятся не в РФ).

- Настроили регулярные бэкапы (хотя мы еще не релизились, но 1 раз у нас уже отлетали жесткие диски).

Почему именно такой стэк?

- Проще работать с технологиями, которые ты уже хорошо знаешь.

- Нам важна надежность, быстрое переключение новых версий на проде без простоя и возможность разделить продукт на версию под РФ и "мир".

- Для работы в РФ нужно хранить персональные данные в РФ и избегать трансграничной передачи данных.

- Конструктор сайтов как простой и недорогой вариант для лендингов и блога. Чтобы не вайбкодить целую CMS.

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

А какие технологии используете вы для разработки MVP?

Не Standup, a Stackup: ИT-Дженга. Контейнеризация.

21 ноября 2025 в 16:00 приглашаем на онлайн-митап «Не Standup, a Stackup: ИT-Дженга. Контейнеризация».

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

Присоединяйтесь к онлайн-трансляции ИТ-Дженги, чтобы:

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

• Узнать нестандартные способы их решения от экспертов

• Проголосовать за самого креативного участника в конце события

• Вдохновиться, посмеяться и просто приятно провести время

Кому будет интересно:

• Техническим менеджерам

• DevOps-специалистам

• CTO

• CIO

• Директорам по разработке

Представители команд:

• Михаил Федоров, ведущий специалист по вопросам внедрения и эксплуатации Kubernetes и Linux, Ингосстрах

• Александр Фикс, лидер продукта Nova Container Platform, Orion soft

• Александр Чубов, руководитель практики «Контейнеризация», К2Тех

Регистрируйтесь на ИТ-Дженгу и присоединяйтесь к трансляции.

Почему Kyverno и Gatekeeper: рассказываем об инструментах, сравниваем их и решаем, какой удобнее 🔐

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

О чем расскажем:

• что предлагает рынок для управления политиками в Kubernetes;

• почему выбираем между Kyverno и Gatekeeper, какие у них сильные и слабые стороны;

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

Ждем всех, кому интересна безопасность в Kubernetes, в частности DevOps-инженеров, техлидов, директоров по разработке и специалистов по кибербезопасности.

📅 Когда? 13 ноября в 11:00 мск.

📍Где? Онлайн. Зарегистрируйтесь, чтобы обсудить сетевые политики в кубере и задать вопросы экспертам.

Делимся горячими новостями нашей платформы Cloud.ru Evolution 🚀

🎁 Акции

• Работайте бесплатно с 20+ мощными open sourse моделями из Evolution Foundation Models. Все уже готово: вам не придется тратить время на развертывание инференса или код, нужно только подключиться через API. Акция действует до 31 октября.

• Получите 35 000 бонусов для работы в Evolution Data Platform. Используйте бонусные рубли, чтобы управлять Big Data, собирать данные для бизнеса и ML. Предложение только для юрлиц, действует до 31 декабря 2025 года.

🛡️ Новые сертификаты

Надежность наших сервисов подтверждена регуляторами. Платформа Cloud.ru Evolution теперь в реестре отечественного ПО (РОПО), а еще она получила сертификаты PCI DSS и ФСТЭК России.

🤖 Evolution ML Inference

• Появился каталог с готовыми моделями, которые доступны для инференса. Среди них — Qwen, DeepSeek, Gemma и не только.

• Среди поддерживаемых GPU теперь есть мощная NVIDIA A100 80GB SXM.

• Стал доступен тестовый вызов модели в Model RUN через OpenAPI. Во вкладке OpenAPI найдете полную спецификацию API, описание эндпоинтов, параметров, моделей, запросов и ответов.

🧑‍💻 Evolution Notebooks

Что мы добавили в сервис:

• CLI-утилиту, чтобы управлять Conda-окружениями. Инструмент облегчит работу с версиями окружений, поддержкой чистоты и согласованности IDE.

• Выбор кастомного образа из Evolution Artifact Registry при создании ноутбука.

• Запуск веб-интерфейса на базе Panel.

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

• Интеграцию с сервисами аудитных логов, нотификации и менеджера ресурсов.

🌐 Evolution DNS

• Стало проще добавлять публичные доменные зоны. Доменные зоны с уникальным FQDN подтверждать теперь не надо, сервис сделает это автоматически.

• Для публичных доменных зон теперь можно использовать GSLB-записи. Технология GSLB распределяет трафик между серверами из разных регионов.

💻 Evolution Managed Kubernetes

Управляйте контейнерными приложениями в Kubernetes 1.33 — теперь Evolution Managed Kubernetes поддерживает и эту версию. Что в ней есть:

• В бета-тесте — использование образов Open Container Initiative (OCI) в качестве томов в подах, а еще In-place resource resize для вертикального масштабирования подов.

• Общедоступными стали поддержка Sidecar-контейнеров, Multiple Service CIDRs, нового бэкенда nftables для kube-proxy, subresource для kubectl. Полный обзор изменений есть в официальном блоге Kubernetes.

📚 Evolution Managed PostgreSQL

• Для кластеров в режиме «Бизнес» теперь можно создать отдельный WAL-диск. Так вы сможете увеличить размер как основного, так и WAL-диска.

• В документации сервиса новый раздел — справочник API. Узнайте, как управлять вашими ресурсами в облаке и получать о них информацию с помощью REST API.

📀 Evolution Object Storage

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

🔋 Evolution Compute

• Удаляйте и создавайте несколько виртуалок одновременно.

• Отключайте и подключайте загрузочные диски между ВМ.

• Переустанавливайте ОС на ВМ, которая работает в данный момент.

Привет, Хабр! Мы только что получили из типографии топовую DevOps-новинку этого года — книгу Камиль Фурнье и Иэна Ноуленда «Инжиниринг платформ: техническое и управленческое руководство». Промокод для читателей Хабра (скидка 32%) - fournier.

Переведённая нами статья Камиль Фурнье с описанием круга проблем и задач, которые решает книга - Инжиниринг платформ: не CFEngine единым / Хабр

Аннотация книги

Базовая книга по инжинирингу платформ – новому подходу к управлению программными системами, при работе с которыми требуется обслуживать множество разных аппаратных архитектур и операционных систем. Показано развитие концепции DevOps и объяснено, как  учитывать запросы и возможности пользователей независимо от способа работы с приложением, минимизировать задержки при обработке данных и упрощать масштабирование и поддержку многоплатформенных продуктов. Описан комплексный  подход к управлению продуктом с учетом потребностей клиентов, разработчиков, системных администраторов и предприятия в целом, актуальный на любых программных платформах.

Для специалистов DevOps, системных администраторов, руководителей команд

Как перенести инфраструктуру из Docker на управляемый Kubernetes в облаке? 

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

30 октября мы проведем вебинар по миграции приложений. 

Инженеры VK Cloud пройдут по шагам весь процесс миграции с Docker: от подготовки до деплоя. Все участники получат план миграции и рекомендации по переносу инфраструктуры. 

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

Что будем делать? 

• Пройдем по шагам процесс миграции

• Разберем стратегии

• Проведем livedemo переноса: от подготовки до деплоя

• Отправим участникам план миграции 

В конце мы разберем типичные ошибки, дадим рекомендации и отправим участникам план миграции.  

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

Регистрируйтесь, чтобы получить напоминание и ссылку на трансляцию вебинара. 

Зарегистрироваться

Публичное облако Cloud.ru Evolution теперь в реестре российского ПО 🎉

И это не последние новости Cloud.ru Evolution к этому часу. Присоединяйтесь к нашему вебинару, где расскажем о новостях платформы. Ждем всех, кто хочет быть в курсе новостей и в числе первых узнать, как использовать обновления на пользу бизнесу.

Что обсудим:

• Какие возможности дает то, что Cloud.ru Evolution в реестре отечественного ПО (РОПО).

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

• Инструменты и сервисы для работы с AI&ML — и как бесплатно их потестировать.

• Как улучшилась работа с приложениями в Kubernetes.

• Новые инструменты для аналитики: как с ними работать, чтобы оптимизировать ресурсы облака.

А в конце вебинара вас ждет демо — в прямом эфире покажем, как развернуть веб-приложение с обновленными сервисами Cloud.ru Evolution.

📅 Когда? 21 октября в 11 по мск.

📍Где? Онлайн. Чтобы зарегистрироваться, переходите на страницу вебинара →

Контейнеры не панацея: скрытые затраты на содержание Kubernetes, о которых молчат вендоры

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

Что не учитывают при внедрении:

• Эффективность нод: В среднем 35-40% ресурсов простаивают "на всякий случай"

• Стоимость сетей: Service mesh + CNI добавляют 15-20% к потреблению CPU

• Трудозатраты: 1 инженер на 3-5 кластеров — утопия для средних компаний

Реальные метрики из практики:

bash

# Анализ утилизации за 3 месяца
kubectl top nodes | awk '{sum += $3} END {print "Средняя загрузка:", sum/NR "%"}'
# Результат: 41% по CPU, 28% по памяти

Где теряем деньги:

1. Overprovisioning
   "На всякий случай" развертываем на 200% больше ресурсов

2. Сложность мониторинга
   Требуется отдельный стек: Prometheus + Grafana + Alertmanager

3. Безопасность
   Pod Security Policies, network policies — +20% к времени развертывания

Когда Kubernetes оправдан:

• 50+ микросервисов

• Непредсказуемая нагрузка

• Команда из 3+ DevOps инженеров

Альтернативы для средних проектов:

• Nomad — проще оркестратор без привязки к контейнерам

• Docker Swarm — для простых сценариев

• Managed k8s — если нет своей экспертизы

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

#Kubernetes #DevOps #контейнеризация #TCO #микросервисы

А как у вас с реальной утилизацией ресурсов в k8s? Делитесь наблюдениями в комментариях.

Записки параноика: почему Zero Trust — это не мода, а новая реальность для ИТ-инфраструктуры

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

Почему Zero Trust — это не просто buzzword:

• 68% компаний сталкивались с инцидентами внутренних угроз

• Среднее время обнаружения нарушителя в сети — 207 дней

• Традиционные VPN стали главным вектором атак в 2024

Как мы внедряли Zero Trust без переписывания всей инфраструктуры:

Сегментация на микроуровне:

yaml

# Instead of: Allow 10.0.0.0/8
# We use: 
- name: db-access
  source: app-server-01
  destination: postgres-01
  port: 5432
  auth: mTLS + service-account

Service Mesh вместо VPN:

• Istio для взаимной аутентификации сервисов

• Автоматическое шифрование всего трафика

• Детальный контроль доступа на уровне L7
  
  Непрерывная верификация:

bash

# Проверка целостности хостов каждые 30 сек
sudo attestation-agent verify --policy strict

Технические вызовы, с которыми столкнулись:

• Производительность: Overhead Istio ~3ms на hop

• Сложность отладки: Трассировка запросов через 5+ сервисов

• Миграция: Постепенный перенос legacy-систем

Метрики после 6 месяцев работы:

• Время сдерживания атаки сократилось с часов до минут

• Количество инцидентов снизилось на 73%

• Audit trail для compliance стал детализированным

Ключевые инсайты:

1. Начинайте с идентификации — без точной инвентаризации сервисов ничего не выйдет

2. Поэтапное внедрение — от критичных workload к периферии

3. Автоматизация политик — ручное управление не масштабируется

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

Стоит ли в тексте статей про Docker переводить "image" как "образ"?

Какой термин вам ближе и понятнее?

Подборка обучающих материалов по Docker и Kubernetes

Привет, Хабр! Сегодня пятница, поэтому я снова со своей нерегулярной подборкой полезных материалов для начинающих специалистов. На этот раз несу статьи о Docker и Kubernetes. Как обычно: все бесплатно, без регистрации и смс. Читайте и практикуйте.

Первые шаги в Kubernetes

Здесь 12 статей примерно на два часа чтения. Будет полезно, если нужно освоить базу: что такое K8s, какие задачи помогает решить, основные понятия, с чего начать, как работать с контейнерами и настроить мониторинг.

Docker с нуля: как работают контейнеры и зачем они нужны

Эта подборка из шести статей — ваш гид в мир контейнеризации. Вы узнаете, что такое Docker, как запускать контейнеры, собирать образы и использовать Docker Compose, а еще разберетесь, чем эта технология отличается от Kubernetes. Все материалы подкреплены практическими примерами и будут понятны начинающим. На полное изучение уйдет менее двух часов.

Основы безопасности в Docker-контейнерах

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

Live-демо графического установщика Deckhouse Kubernetes Platform

Мы создали графический установщик, который превращает развёртывание Deckhouse Kubernetes Platform в несколько кликов и упрощает начало использования платформы через веб-интерфейс.

На вебинаре 25 сентября технический директор веб-интерфейсов Deckhouse покажет live-демо Installer: 

• Развернёт полноценный кластер Deckhouse Kubernetes Platform за 10 минут. 

• Включит виртуализацию ещё за 10 — и запустит Doom на виртуальной машине.

• Расскажет, какие проблемы установки закрывает Installer. 

• Покажет планы развития графического установщика и где его взять.

Заглядывайте на трансляцию 25 сентября в 12:00. Для участия нужно зарегистрироваться.

А у нас для вас сразу два вебинара про Kubernetes 🖥️☁️

Присоединяйтесь к встречам с экспертами Cloud.ru, чтобы узнать, как эффективнее работать в кубере и обеспечить безопасность контейнеров.

📅 16 сентября архитектор решений Илья Смирнов расскажет, как мультикластерная архитектура повышает отказоустойчивость сервисов. А еще — когда именно пригодится мультикластер и как его организовать с помощью фреймворка Karmada.

Зарегистрироваться →

📅 18 сентября менеджер продукта Вера Орлова поделится, какую роль в защите контейнеров играет Admission Control, какие есть типы контроллеров и в чем разница между Kyverno и Gatekeeper.

Зарегистрироваться →

Записывайтесь на вебинары и до встречи в 11:00 по мск ⏱️ Будет полезно всем, кого интересует, как организовать защиту и отказоустойчивость контейнеров: DevOps-инженерам, техлидам, специалистам по кибербезопасности — и не только.