DevOps Deflope News

Cloudflare открыла исходный код Cloudflare OS, платформы, которую сами используют внутри компании для работы с ИИ-агентами. Агент там опирается на внутренний контекст компании, лезет в корпоративные системы, собирает приложения и автоматизирует рутину. Особое внимание уделено комплаенсу и безопасности. Агент не имеет полного доступа к системе: полномочия жёстко ограничены через механизм Gatekeepers. Эта система контролирует доступ к ресурсам, логирует все действия и требует подтверждения человека для выполнения критических операций. Cloudflare также отслеживает цепочку использования данных (data lineage), фиксируя, какие сведения агент использовал для формирования результата. Это исключает риски утечки данных, гарантируя, что конечный пользователь не получит доступ к чувствительной информации, скрытой за итоговым отчётом или дашбордом. В итоге Cloudflare OS — это полноценная рабочая среда вокруг агента с подключёнными тулами, где он может делать что-то сам, но под контролем на уровне платформы.

22 октября в Москве пройдёт Kuber Conf от АОТ — уже второй раз. АОТ — ассоциация профессионалов индустрии облачно-ориентированных технологий, та самая первая в России некоммерческая организация для внедрения и распространения cloud-native-подходов. Её создали Yandex Cloud, VK Cloud и Флант, чтобы развитие облачных технологий в России не зависело от одного вендора. В прошлом году на дебютную Kuber Conf пришло больше 550 человек. Желаем организаторам, чтобы в этом году нас, участников, стало ещё больше :) Тем в этот раз много: • AI и облачная инфраструктура; • экономика платформ; • безопасность в эпоху LLM; • Platform Engineering; • эксплуатация Kubernetes в production; • наблюдаемость, сеть и Service Mesh; • железо, ЦОДы и bare-metal. И это не считая воркшопов, демо и наших любимых fail-секций. Кстати, если есть свой кейс по темам выше, то до 15 сентября открыты заявки на доклады. Особенно интересны новые инструменты и подходы к работе с K8s. Подать заявку на доклад можно тут. В билет входит не только посещение конференции. Ещё материалы конференции, обед, нетворкинг и, конечно, афтерпати. Больше инфы по ссылке.

Прикольная штука для сетей в Kubernetes. Умеет докручивать то, чего не хватает underlay-CNI — вроде Macvlan, ipvlan и SR-IOV. Ещё в декабре 2023 CNCF взяла в sandbox проект Spiderpool — сетевое решение для Kubernetes на базе underlay и RDMA. За это время он неплохо прокачался по фичам, так что рассказываем, что там сейчас. Spiderpool расширяет возможности Macvlan, ipvlan и SR-IOV CNI. Пригодится там, где overlay-сети уже начинают тормозить. Например, в приложениях с высокой сетевой нагрузкой и низкой задержкой, в хранилищах, middleware, при обучении ИИ-моделей. Underlay-подход убирает туннельную инкапсуляцию и маршрутизацию третьего уровня на хосте. В результате растёт пропускная способность, снижается нагрузка на CPU, а пакеты идут с реальными IP подов, без NAT. По фичам всё серьёзно. CRD-based IPAM с dual-stack, статические IP для stateful-приложений вроде MySQL и Redis, RDMA через RoCE и InfiniBand, совместимость с Calico, Cilium и KubeVirt. Замена kube-proxy на eBPF, по данным проекта, даёт прирост до 25% по задержке и до 50% по пропускной способности сети. Правда, не всё готово. Network Policy и Bandwidth для macvlan и SR-IOV пока остаются в статусе «в планах», а у ipvlan — только alpha. Проект на GitHub

Образ не меняется. Меняется то, что мы о нём знаем)) Собрали, просканировали, получили зелёный отчёт, положили в реестр. Через месяц в базах CVE появляются дыры в тех же пакетах. А ведь образ прежний и отчёт прежний, только вот он больше не про реальность. Сканирование на сборке — это разовый снимок. Дальше нужен регулярный пересбор и перепроверка того, что уже лежит в реестре и крутится в проде. Остальные слабые места собраны в статье на Cloud Native Now (link). Минимальные базовые образы, SBOM, отказ от latest, политики в CI/CD, runtime-защита. Ничего нового там нет, но как чеклист вполне работает :) Вопрос для самопроверки: когда последний раз пересобирался ваш самый старый образ в продакшене?

Возвращаемся в подкаст DevOps Deflope с выпуском, где вместе с Игорем Курочкиным (Enabling.team) разбираем индустрию исследований. Обсудили: • Для кого на самом деле пишут отчёты: для CTO или для работяг. • Почему все отчёты сейчас массово ушли в ИИ-хайп. • Где искать реальные инсайты (спойлер: в поле «Другое»). • И почему лучший способ изучить инструмент — пойти пить пиво с его автором. Слушать: → На любой удобной площадке → На YouTube → Наш сайт

Коллеги, ситуация. Отчётов и исследований сейчас по нашей теме выходит много, а времени прочитать всё — нет. И заранее не всегда понятно, какой из них даст что-то полезное, а какой будет просто красиво оформленный текст ни о чём. Как вы выбираете, что читать целиком, а что пролистать по диагонали?

Заканчивается набор в экспертный совет по cloud-native-технологиям АОТ (Ассоциация профессионалов индустрии облачно-ориентированных технологий) набирает первый состав экспертного совета. Коллеги ищут практиков со значимым опытом в области Cloud Native и Kubernetes. Совет будет определять направления развития и работы ассоциации: какие практики продвигать, какие темы исследовать, какой быть Kuber Conf. Также члены совета будут участвовать в разработке образовательных программ и профстандартов по облачным технологиям. Что нужно: — 5+ лет практики в Cloud Native / Kubernetes (разработка, архитектура или менеджмент) — публичный трек: статьи, доклады, участие в Open Source-проектах — 10–20 часов в месяц на дела совета, своя позиция и готовность её аргументировать в дискуссиях Важно: работа в совете общественная, срок — год. Это возможности влияния на то, куда двигается индустрия, и подтверждения своего экспертного статуса на уровне сообщества. Заявки принимаются до 22 июля, результаты объявят в августе. Детали и форма заявки здесь.

MetalBear выкатили mirrord под Windows и решили это отметить, сделали браузерный сапёр в стиле ретро-Windows на неделю запуска. Обещали мерч тем, кто к пятнице удержится в топе рейтинга (неделя запуска уже прошла, так что конкурс закрыт). Само собой, игру тут же взломали) Nitzan, security-инженер из Daylight (это клиент MetalBear), быстро нашла дыру. Сервер не валидировал тайминги, клиент сам присылал таймштампы по каждому ходу и итоговое время прохождения, а сервер принимал их без проверки. Плюс seed для генерации поля и сам PRNG лежали в клиентском JS, то есть браузер уже на старте знал полную раскладку мин. В сумме это давало возможность сгенерировать идеальную последовательность ходов скриптом и отправить её с любым правдоподобным временем :D Вообще прикольно, что Nitzan прислала готовый regression-тест, где честное быстрое прохождение — ок, мгновенное прохождение бота — бан, а самое хитрое — заявленное время без реального ожидания — тоже бан. MetalBear починили ровно так, как она и предложила. Но признали, что до полной неуязвимости всё ещё далеко. Seed по-прежнему виден клиенту, так что терпеливый бот в теории может дождаться нужного момента и пройти игру и-де-а-ль-но. Игра всё ещё тут, если хотите пощупать. А разбор взлома — в блоге MetalBear.

Стандартизирован HTTP-метод QUERY, комбинирующий возможности GET и POST GET много лет тащил на себе задачи, для которых он не особо предназначен. Сложные фильтры, большие списки параметров — со всем этим он справлялся так себе, упираясь в лимит 8000 байт на размер URI. IETF наконец закрыл эту дыру: HTTP-метод QUERY получил статус Proposed Standard, вышел RFC 10008. По сути это гибрид GET и POST. Тело как у POST, а идемпотентность как у GET. Под этой новостью набежало больше сотни комментариев. Для рядового RFC это довольно много :) И знаете, о чём там спорили? Не о технологии. Люди устали. Не от QUERY конкретно, от того, что стандартов и так вагон, а тут ещё один в копилку. Один из комментаторов вспомнил старый мем, мол, раньше было 14 конкурирующих стандартов, решили сделать один универсальный — получили 15. Вот примерно это все и почувствовали) При этом в комментах реально были толковые технические разборы. Кто-то напомнил, что тело в GET и так никто не запрещал слать, люди этим годами пользуются, так что QUERY просто узаконивает то, что уже давно все делают. Кто-то поднял более практичный вопрос: браузер новый verb проглотит без проблем, а вот nginx и прочие reverse-proxy его просто не распознают, придётся патчить руками. Но все эти аргументы прошли мимо основного внимания, читатели зацепились не за них. Тред благополучно свалился в спор про то, что браузеры жрут память. И там страстей было ничуть не меньше, чем в разговоре про сам метод. В общем, повод был технический, а получилось скорее про настроение. Люди не столько разбирали RFC, сколько показывали, как они вообще относятся к очередному "мы придумали ещё один стандарт". Согласны с этим настроением или считаете, что лишнего сгущаются краски?

OpenTelemetry получил статус Graduation в CNCF. Это высший уровень зрелости проекта в экосистеме фонда. Обычно до Graduation доходят проекты, которые уже массово используются в проде и не зависят от одного вендора или команды. Рынок давно принял OpenTelemetry как стандарт. Graduation — скорее формальность, чем сюрприз. Раньше каждый вендор тащил собственных агентов, SDK и форматы данных. Хочешь перейти с одной платформы на другую? – Удачи! Это был тот ещё квест) С OpenTelemetry приложения могут отдавать телеметрию единообразно. А backend для анализа, хранения и визуализации выбирается отдельно. В результате конкуренция сместилась выше по стеку. Вендоры всё меньше конкурируют агентами и закрытыми форматами, а всё больше — качеством аналитики, удобством работы, снижением шума и дополнительными возможностями платформ. Сейчас об OpenTelemetry всё чаще говорят уже не только в контексте классической observability. С ростом ИИ-систем выясняется, что без качественной телеметрии там тоже далеко не уедешь. По сути это те же распределённые системы, только с новыми слоями сложности: агентами, моделями, внешними инструментами, промптами и длинными цепочками вызовов. И если для микросервисов нам важно понимать, где сломался запрос, то для ИИ-платформ нужно ещё больше подробностей: какой агент что вызвал, какая модель ответила, где выросла задержка и сколько всё это стоило. Так что OpenTelemetry перестал быть “перспективной технологией” и стал инфраструктурным стандартом для наблюдаемости. По сути, это общий язык, на котором приложения, платформы и observability-системы договариваются о метриках, логах и трейсах.