Тут поресёрчил тему, как распилить GPU между виртуалками. Для QEMU/KVM всё завязано на VFIO: можно пробрасывать как целое PCI-устройство (полный passthrough), так и виртуализированные GPU через vGPU-подход, когда хост создаёт mediated devices (mdev) или PCI-based виртуальные GPU и уже их отдаёт в VM. Именно этот вариант нужен, если один физический GPU должен использоваться несколькими виртуалками.
Я думал, что можно как-то заиспользовать MIG, но MIG — это лишь аппаратное разбиение GPU. Сам по себе MIG не создаёт mediated devices и VFIO-устройств для виртуалок: чтобы отдельные MIG-инстансы можно было пробрасывать в VM, всё равно нужен vGPU-стек, который экспортирует их как mdev или PCI-устройства.
У NVIDIA этот функционал исторически доступен только в рамках проприетарного NVIDIA vGPU софта и требует лицензии.
При этом NVIDIA сейчас двигается в сторону open-source GPU virtualization: есть RFC-патчи для реализации vGPU в Linux, которые должны работать с VFIO и VM passthrough. Но это пока не mainline, патчи на стадии обсуждения, и когда (и в каком виде) их смерджат — непонятно.
https://www.phoronix.com/news/NVIDIA-Open-GPU-Virtualization
Я думал, что можно как-то заиспользовать MIG, но MIG — это лишь аппаратное разбиение GPU. Сам по себе MIG не создаёт mediated devices и VFIO-устройств для виртуалок: чтобы отдельные MIG-инстансы можно было пробрасывать в VM, всё равно нужен vGPU-стек, который экспортирует их как mdev или PCI-устройства.
У NVIDIA этот функционал исторически доступен только в рамках проприетарного NVIDIA vGPU софта и требует лицензии.
При этом NVIDIA сейчас двигается в сторону open-source GPU virtualization: есть RFC-патчи для реализации vGPU в Linux, которые должны работать с VFIO и VM passthrough. Но это пока не mainline, патчи на стадии обсуждения, и когда (и в каком виде) их смерджат — непонятно.
https://www.phoronix.com/news/NVIDIA-Open-GPU-Virtualization
Phoronix
NVIDIA Publishes Open-Source Linux Driver Code For GPU Virtualization "vGPU" Support
NVIDIA engineers have sent out an exciting set of Linux kernel patches for enabling NVIDIA vGPU software support for virtual GPU support among multiple virtual machines (VMs)
👍14🔥9❤2👏2
У нас тут появился запрос на то чтобы упростить нашим пользователям путь для запуска своих приложений в Cozystack.
Основной поинт такой: Я хочу писать код, и не думать о докерфайлах и кубернетисах ваших.
Я целился в то, что-бы выстроить что-то вроде heroku, т.е. максимально простой интерфейс для девелоперов.
За сегодня протестировал OpenFaaS и knative, но кажется serverless и FaaS - это не совсем то, что нужно чтобы полноценно удовлетворить этот запрос.
Копнув чуть глубже в тему наткнулся на epinio.io
Epinio развивается за счёт комьюнити. Под капотом у него buildpacks - это своего рода стандарт для доставки кода в различные контейнерные окружения.
А ещё оно потенциально очень хорошо интегрируется с Cozystack.
Логика такая:
- Запускаем кластер Kubernetes, ставим туда epinio (это может быть легко автоматизировано со стороны Cozystack)
- Пользователь заходит в UI
- Указывает путь до гит репы
- Buildpacks билдит приложение
- Деплоит его в Kubernetes
Бонусом в Cozystack уже есть container-registry, S3 и множество готовых баз данных
В самом epinio есть service-catalog из которого можно деплоить dev-версии mysql, postgres, mongodb и прочее. Есть мысли что этот сервискаталог немного переделать и предоставлять в нём готовые продакшен версии баз данных из Cozystack
Здесь есть видео с демонстрацией работы:
- https://youtu.be/jia6Laqz2WM?si=f1RElFLoesrbCFIU&t=919
На данный момент есть мысли чтобы выстроить полноценный IDP на базе этого решения.
Основной поинт такой: Я хочу писать код, и не думать о докерфайлах и кубернетисах ваших.
Я целился в то, что-бы выстроить что-то вроде heroku, т.е. максимально простой интерфейс для девелоперов.
За сегодня протестировал OpenFaaS и knative, но кажется serverless и FaaS - это не совсем то, что нужно чтобы полноценно удовлетворить этот запрос.
Копнув чуть глубже в тему наткнулся на epinio.io
Epinio развивается за счёт комьюнити. Под капотом у него buildpacks - это своего рода стандарт для доставки кода в различные контейнерные окружения.
А ещё оно потенциально очень хорошо интегрируется с Cozystack.
Логика такая:
- Запускаем кластер Kubernetes, ставим туда epinio (это может быть легко автоматизировано со стороны Cozystack)
- Пользователь заходит в UI
- Указывает путь до гит репы
- Buildpacks билдит приложение
- Деплоит его в Kubernetes
Бонусом в Cozystack уже есть container-registry, S3 и множество готовых баз данных
В самом epinio есть service-catalog из которого можно деплоить dev-версии mysql, postgres, mongodb и прочее. Есть мысли что этот сервискаталог немного переделать и предоставлять в нём готовые продакшен версии баз данных из Cozystack
Здесь есть видео с демонстрацией работы:
- https://youtu.be/jia6Laqz2WM?si=f1RElFLoesrbCFIU&t=919
На данный момент есть мысли чтобы выстроить полноценный IDP на базе этого решения.
YouTube
PROD 1307 A prescriptive approach to application development with Epinio
Learn how you can go from commit to deploy with Epinio's application development engine.
❤8👍4👎1
Короче, прямо сейчас разворачивается довольно показательная история из мира supply chain атак 👇
AI-агент (да, уже не человек руками) нашёл уязвимость в GitHub Actions у Trivy — популярного security-сканера.
Через небезопасный workflow (
А дальше стало совсем неприятно:
— переписали почти все теги релизов
— подменили GitHub Action
— и встроили вредоносный код
В итоге, любой CI, который использовал Trivy через
То есть одна точка компрометации каскадно затронула тысячи пайплайнов. Внутри пайплайна payload собирал: SSH-ключи, cloud credentials, Kubernetes-токены и прочее добро прямо из CI runner’ов.
Главный инсайт:
теги в GitHub — это не immutable.
Если ты не пинишь actions по commit SHA — ты буквально исполняешь код “по доверию”.
Ну и второй инсайт:
AI уже не просто помогает писать код — он сканирует GitHub и ломает CI быстрее, чем ты успеваешь ревью сделать 🙂
Ссылки:
- Разбор атаки (Socket)
- Детали payload и последствий (The Hacker News)
- Чуть больше про механику работы GitHub от @kruchkov_alexandr
AI-агент (да, уже не человек руками) нашёл уязвимость в GitHub Actions у Trivy — популярного security-сканера.
Через небезопасный workflow (
pull_request_target) он смог получить токен с правами записи в репозиторий.А дальше стало совсем неприятно:
— переписали почти все теги релизов
— подменили GitHub Action
— и встроили вредоносный код
В итоге, любой CI, который использовал Trivy через
uses: aquasecurity/trivy-action@vX.Y.Z, автоматически начинал исполнять чужой код.То есть одна точка компрометации каскадно затронула тысячи пайплайнов. Внутри пайплайна payload собирал: SSH-ключи, cloud credentials, Kubernetes-токены и прочее добро прямо из CI runner’ов.
Главный инсайт:
теги в GitHub — это не immutable.
Если ты не пинишь actions по commit SHA — ты буквально исполняешь код “по доверию”.
Ну и второй инсайт:
AI уже не просто помогает писать код — он сканирует GitHub и ломает CI быстрее, чем ты успеваешь ревью сделать 🙂
Ссылки:
- Разбор атаки (Socket)
- Детали payload и последствий (The Hacker News)
- Чуть больше про механику работы GitHub от @kruchkov_alexandr
❤12😱7🔥5😢2👍1👎1
This media is not supported in your browser
VIEW IN TELEGRAM
Исторя #22 По мотивам обновления кластера клиента
🤣17🙈8💩4💅1
Мне тут закинули интересный проект - T4.
По сути это такой git с S3-бэкендом и фронтендом в виде etcd.
Снаружи всё выглядит как обычный etcd-compatible datastore, а внутри вместо привычного "храним состояние" - просто поток изменений, который складывается в виде WAL в object storage.
Если подумать, модель довольно нетипичная: источником истины становится не состояние, а лог изменений.
А дальше из этого уже вытекают все побочные эффекты — можно откатываться, воспроизводить состояние, делать форки и гонять эксперименты отдельно от прода.
Автор явно смотрит в сторону сценария "а давайте заменим etcd в Kubernetes", и это звучит странно ровно до того момента, пока не задумываешься, что control plane - это по сути и есть машина состояний, которую мы постоянно мучаем бэкапами, ресторами и попытками понять "а что вообще произошло".
Пока это всё выглядит как эксперимент и есть куча вопросов по перформансу и консистентности. Но сама идея сильная:
не хранить состояние как главную сущность, а хранить историю, из которой оно получается.
И это как раз тот случай, когда сначала думаешь "что за дичь", а потом "блин, а ведь в этом и правда что-то есть" 🙂
По сути это такой git с S3-бэкендом и фронтендом в виде etcd.
Снаружи всё выглядит как обычный etcd-compatible datastore, а внутри вместо привычного "храним состояние" - просто поток изменений, который складывается в виде WAL в object storage.
Если подумать, модель довольно нетипичная: источником истины становится не состояние, а лог изменений.
А дальше из этого уже вытекают все побочные эффекты — можно откатываться, воспроизводить состояние, делать форки и гонять эксперименты отдельно от прода.
Автор явно смотрит в сторону сценария "а давайте заменим etcd в Kubernetes", и это звучит странно ровно до того момента, пока не задумываешься, что control plane - это по сути и есть машина состояний, которую мы постоянно мучаем бэкапами, ресторами и попытками понять "а что вообще произошло".
Пока это всё выглядит как эксперимент и есть куча вопросов по перформансу и консистентности. Но сама идея сильная:
не хранить состояние как главную сущность, а хранить историю, из которой оно получается.
И это как раз тот случай, когда сначала думаешь "что за дичь", а потом "блин, а ведь в этом и правда что-то есть" 🙂
GitHub
GitHub - t4db/t4: S3-durable key-value storage with etcd v3 compatibility
S3-durable key-value storage with etcd v3 compatibility - t4db/t4
❤17🔥5👀5
Вышел подкаст DevOps Paradox со мной 🎙️
Поговорили про Kubernetes, путь Ænix и Cozystack, попытки собрать "свой AWS" для on-prem. Обсудили современные тренды и конечно же AI, как он помогает нам в работе уже сегодня.
https://www.devopsparadox.com/episodes/cozystack-turns-bare-metal-into-a-managed-services-platform-347/
Поговорили про Kubernetes, путь Ænix и Cozystack, попытки собрать "свой AWS" для on-prem. Обсудили современные тренды и конечно же AI, как он помогает нам в работе уже сегодня.
https://www.devopsparadox.com/episodes/cozystack-turns-bare-metal-into-a-managed-services-platform-347/
Devopsparadox
DOP 347: Cozystack Turns Bare Metal Into a Managed Services Platform
Andrei Kvapil on Cozystack, building managed clouds on bare metal, and why his AI agent should be talking to your AI agent instead of either of you.
👍7🔥7❤3
Если ещё беспокоитесь за copy.fail в своих кластерах - вот изи-фикс.
Маленький DaemonSet, грузит
Работает на Talos Linux, где
Ставится одной командой:
https://github.com/cozystack/copy-fail-blocker
Маленький DaemonSet, грузит
BPF-LSM хук на socket_create и режет любые попытки открыть AF_ALG. Без ребута, без пересборки ядра, без правки cmdline.Работает на Talos Linux, где
rmmod архитектурно недоступен (SELinux + lockdown + контроллер не умеет unload).Ставится одной командой:
kubectl apply -f https://raw.githubusercontent.com/cozystack/copy-fail-blocker/main/manifests/copy-fail-blocker.yaml
https://github.com/cozystack/copy-fail-blocker
GitHub
GitHub - cozystack/copy-fail-blocker: BPF-LSM mitigation for CVE-2026-31431 (Copy Fail) — denies AF_ALG socket creation cluster…
BPF-LSM mitigation for CVE-2026-31431 (Copy Fail) — denies AF_ALG socket creation cluster-wide - cozystack/copy-fail-blocker
👍13🔥7💩5🤡1🤓1
Магия кэша в controller-runtime: почему ваши контроллеры быстрые, стабильные и не убивают apiserver
Если вы когда-нибудь писали Kubernetes-контроллер на Go, то почти наверняка использовали controller-runtime.
А если использовали — значит, пользовались одной из самых недооценённых и мощных частей всего Kubernetes-стека: кэшем controller-runtime.
https://habr.com/ru/companies/aenix/articles/1031818/
Если вы когда-нибудь писали Kubernetes-контроллер на Go, то почти наверняка использовали controller-runtime.
А если использовали — значит, пользовались одной из самых недооценённых и мощных частей всего Kubernetes-стека: кэшем controller-runtime.
https://habr.com/ru/companies/aenix/articles/1031818/
👍9🔥6❤2
Переписываем LINSTOR на go с Claude Code
В качестве пятничного эксперимента решил запустить шайтан машину и посмотреть что из этого получится.
Минимум вовлечённости, максимум слопа!👃
Стрим в реальном времени: https://asciinema.org/s/wO0WH3M3bTqdSvm1
Репозиторий: https://github.com/cozystack/blockstor
Чат в котором ведётся обсуждение: @cozystack_ru
В качестве пятничного эксперимента решил запустить шайтан машину и посмотреть что из этого получится.
Минимум вовлечённости, максимум слопа!
Стрим в реальном времени: https://asciinema.org/s/wO0WH3M3bTqdSvm1
Репозиторий: https://github.com/cozystack/blockstor
Чат в котором ведётся обсуждение: @cozystack_ru
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - cozystack/blockstor: Go reimplementation of LINSTOR (block storage controller for Kubernetes)
Go reimplementation of LINSTOR (block storage controller for Kubernetes) - cozystack/blockstor
🔥6😁5🥴3👀2🌚1
Пользуюсь майндкартами ровно для одного кейса — когда готовлюсь к презентации.
На мой взгляд, главное преимущество майндкарт — это быстрое и удобное перемещение по дереву. Мне крайне важно видеть всё дерево целиком и иметь простую навигацию по нему: создавать элементы, удалять, сворачивать/разворачивать — и конечно же всё это с клавиатуры.
К сожалению, все доступные сейчас реализации либо ужасно неудобные, либо ужасно нефункциональные.
Есть формат Markmap, который позволяет писать майндкарты на Markdown. Он весьма неплохой, но в нём нет возможности генерировать Markdown обратно из самой майндкарты, а мне как раз нужно именно это.
Хочется спокойно накидать мысли, не отвлекаясь на форматирование, получить готовый Markdown и уже с ним идти к нейронке.
В общем, сделал для себя тулзу, теперь несу её вам.
https://kvaps.github.io/stackmind/
Прощай FreeMind, пора отправлять тебя на помойку.
На мой взгляд, главное преимущество майндкарт — это быстрое и удобное перемещение по дереву. Мне крайне важно видеть всё дерево целиком и иметь простую навигацию по нему: создавать элементы, удалять, сворачивать/разворачивать — и конечно же всё это с клавиатуры.
К сожалению, все доступные сейчас реализации либо ужасно неудобные, либо ужасно нефункциональные.
Есть формат Markmap, который позволяет писать майндкарты на Markdown. Он весьма неплохой, но в нём нет возможности генерировать Markdown обратно из самой майндкарты, а мне как раз нужно именно это.
Хочется спокойно накидать мысли, не отвлекаясь на форматирование, получить готовый Markdown и уже с ним идти к нейронке.
В общем, сделал для себя тулзу, теперь несу её вам.
https://kvaps.github.io/stackmind/
Прощай FreeMind, пора отправлять тебя на помойку.
❤11👍8🔥2🥴1
Зацените какую штуку тут товарищ написал:
https://github.com/crust-gather/crust-gather
Она сохраняет стейт Kubernetes кластера в OCI-имадж (со всеми CRD, статусами, ивентами, подами и их логами)
Потом его можно запустить локально и в нем покопаться обычным kubectl. Можно клода натравить, можно k9s, и т.п.
Идеально подходит чтобы интегрировать в свой пайплайн. Написано на rust'е.
Завтра будет рассказывать о ней на KCD
https://kcd-czech-slovak-2026.sessionize.com/session/1195463
(есть прямая трансляция)
https://github.com/crust-gather/crust-gather
Она сохраняет стейт Kubernetes кластера в OCI-имадж (со всеми CRD, статусами, ивентами, подами и их логами)
Потом его можно запустить локально и в нем покопаться обычным kubectl. Можно клода натравить, можно k9s, и т.п.
Идеально подходит чтобы интегрировать в свой пайплайн. Написано на rust'е.
Завтра будет рассказывать о ней на KCD
https://kcd-czech-slovak-2026.sessionize.com/session/1195463
(есть прямая трансляция)
GitHub
GitHub - crust-gather/crust-gather: kubectl debugging plugin to collect full or partial cluster state and serve via an api server.…
kubectl debugging plugin to collect full or partial cluster state and serve via an api server. Kubernetes time machine - crust-gather/crust-gather
🔥26👍4
Сегодня наткнулся на интересный тред про серый рынок “дешёвого Claude API”.
На TaoBao и других площадках сейчас можно купить “безлимитный Claude Opus” за пару баксов.
На практике же вам дают не “дешёвый доступ к Opus”, а обычный relay между вами и настоящим API.
И, кажется, весь смысл таких сервисов вообще не в продаже токенов. А в сборе всего, что через них проходит. Причём речь уже даже не столько про SSH keys, kubeconfig’и или внутренние документы компаний. Основная цель всей этой истории — попытка массово спарсить frontier-модели.
Собирать:
— промпты,
— reasoning,
— agent workflows,
— код,
— ответы модели,
— реакции пользователей,
— паттерны использования,
а дальше использовать это для distillation, fine-tuning и обучения собственных моделей. Иначе экономика таких сервисов выглядит довольно странно.
И да, в какой-то момент вместо Opus вам вполне может отвечать вообще другая модель, а вы этого даже не заметите. Зато всё, что вы через неё прогоняете, остаётся у владельцев relay.
https://x.com/i/status/2056626175959826692
На TaoBao и других площадках сейчас можно купить “безлимитный Claude Opus” за пару баксов.
На практике же вам дают не “дешёвый доступ к Opus”, а обычный relay между вами и настоящим API.
И, кажется, весь смысл таких сервисов вообще не в продаже токенов. А в сборе всего, что через них проходит. Причём речь уже даже не столько про SSH keys, kubeconfig’и или внутренние документы компаний. Основная цель всей этой истории — попытка массово спарсить frontier-модели.
Собирать:
— промпты,
— reasoning,
— agent workflows,
— код,
— ответы модели,
— реакции пользователей,
— паттерны использования,
а дальше использовать это для distillation, fine-tuning и обучения собственных моделей. Иначе экономика таких сервисов выглядит довольно странно.
И да, в какой-то момент вместо Opus вам вполне может отвечать вообще другая модель, а вы этого даже не заметите. Зато всё, что вы через неё прогоняете, остаётся у владельцев relay.
https://x.com/i/status/2056626175959826692
👍10
Forwarded from Безумный кот
Век живи — век учись ☹️
Через каждого инженера проходит такое количество информации, что часть вещей вроде бы и слышал, но до конца не осознал или просто никогда не применял на практике.
Сегодня словил себя на этом же👀
Всегда думал, что в Kubernetes есть только:
• SelfSubjectAccessReview — проверка «могу ли Я сделать действие»
• SubjectAccessReview — проверка «может ли другой пользователь/SA сделать действие»
Например:
А оказывается есть еще и:
Эта штука позволяет получить effective RBAC rules для текущего пользователя в рамках namespace.
Пример:
или привычнее:
Но тут есть интересный нюанс:
SelfSubjectRulesReview namespace-oriented и не умеет нормально показывать “все права во всем кластере”.
То есть cluster-scope права приходится проверять точечно:
Может это и хорошо забытое старое но приятное😇
Через каждого инженера проходит такое количество информации, что часть вещей вроде бы и слышал, но до конца не осознал или просто никогда не применял на практике.
Сегодня словил себя на этом же
Всегда думал, что в Kubernetes есть только:
• SelfSubjectAccessReview — проверка «могу ли Я сделать действие»
• SubjectAccessReview — проверка «может ли другой пользователь/SA сделать действие»
Например:
kubectl auth can-i create pods
А оказывается есть еще и:
kind: SelfSubjectRulesReview
Эта штука позволяет получить effective RBAC rules для текущего пользователя в рамках namespace.
Пример:
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectRulesReview
spec:
namespace: default
или привычнее:
kubectl auth can-i --list -n default
Но тут есть интересный нюанс:
SelfSubjectRulesReview namespace-oriented и не умеет нормально показывать “все права во всем кластере”.
То есть cluster-scope права приходится проверять точечно:
kubectl auth can-i list nodes
kubectl auth can-i list namespaces
****
Может это и хорошо забытое старое но приятное
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11❤4👍2😱2
ITTales :(){ :|:& };:
Магия кэша в controller-runtime: почему ваши контроллеры быстрые, стабильные и не убивают apiserver Если вы когда-нибудь писали Kubernetes-контроллер на Go, то почти наверняка использовали controller-runtime. А если использовали — значит, пользовались одной…
Вторая часть серии про внутренности controller-runtime и Kubernetes API — теперь про запись.
Если в прошлый раз говорили про кэш, watch'и и чтение объектов, то теперь разберём: как работает three way merge и server side apply, зачем нужны managedFields, как apiserver хранит ownership полей.
И главное — как всё это позволяет нескольким контроллерам безопасно менять один объект одновременно.
https://habr.com/ru/companies/aenix/articles/1039282/
Если в прошлый раз говорили про кэш, watch'и и чтение объектов, то теперь разберём: как работает three way merge и server side apply, зачем нужны managedFields, как apiserver хранит ownership полей.
И главное — как всё это позволяет нескольким контроллерам безопасно менять один объект одновременно.
https://habr.com/ru/companies/aenix/articles/1039282/
🔥10