ITTales :(){ :|:& };:

Зацените какую штуку тут товарищ написал: https://github.com/crust-gather/crust-gather Она сохраняет стейт Kubernetes кластера в файл (со всеми CRD, статусами, подами и их логами) Потом его можно запустить локально и в нем покопаться обычным kubectl. Можно клода натравить, можно k9s, и т.п. Идеально подходит чтобы интегрировать в свой пайплайн. Написано на rust'е. Завтра будет рассказывать о ней на KCD https://kcd-czech-slovak-2026.sessionize.com/session/1195463 (есть прямая трансляция)

Пользуюсь майндкартами ровно для одного кейса — когда готовлюсь к презентации. На мой взгляд, главное преимущество майндкарт — это быстрое и удобное перемещение по дереву. Мне крайне важно видеть всё дерево целиком и иметь простую навигацию по нему: создавать элементы, удалять, сворачивать/разворачивать — и конечно же всё это с клавиатуры. К сожалению, все доступные сейчас реализации либо ужасно неудобные, либо ужасно нефункциональные. Есть формат Markmap, который позволяет писать майндкарты на Markdown. Он весьма неплохой, но в нём нет возможности генерировать Markdown обратно из самой майндкарты, а мне как раз нужно именно это. Хочется спокойно накидать мысли, не отвлекаясь на форматирование, получить готовый Markdown и уже с ним идти к нейронке. В общем, сделал для себя тулзу, теперь несу её вам. https://kvaps.github.io/stackmind/ Прощай FreeMind, пора отправлять тебя на помойку.

Переписываем LINSTOR на go с Claude Code В качестве пятничного эксперимента решил запустить шайтан машину и посмотреть что из этого получится. Минимум вовлечённости, максимум слопа! 👃 Стрим в реальном времени: https://asciinema.org/s/wO0WH3M3bTqdSvm1 Репозиторий: https://github.com/cozystack/blockstor Чат в котором ведётся обсуждение: @cozystack_ru

Магия кэша в controller-runtime: почему ваши контроллеры быстрые, стабильные и не убивают apiserver Если вы когда-нибудь писали Kubernetes-контроллер на Go, то почти наверняка использовали controller-runtime. А если использовали — значит, пользовались одной из самых недооценённых и мощных частей всего Kubernetes-стека: кэшем controller-runtime. https://habr.com/ru/companies/aenix/articles/1031818/

Если ещё беспокоитесь за copy.fail в своих кластерах - вот изи-фикс. Маленький 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

Вышел подкаст DevOps Paradox со мной 🎙️ Поговорили про Kubernetes, путь Ænix и Cozystack, попытки собрать "свой AWS" для on-prem. Обсудили современные тренды и конечно же AI, как он помогает нам в работе уже сегодня. https://www.devopsparadox.com/episodes/cozystack-turns-bare-metal-into-a-managed-services-platform-347/

Мне тут закинули интересный проект - T4. По сути это такой git с S3-бэкендом и фронтендом в виде etcd. Снаружи всё выглядит как обычный etcd-compatible datastore, а внутри вместо привычного "храним состояние" - просто поток изменений, который складывается в виде WAL в object storage. Если подумать, модель довольно нетипичная: источником истины становится не состояние, а лог изменений. А дальше из этого уже вытекают все побочные эффекты — можно откатываться, воспроизводить состояние, делать форки и гонять эксперименты отдельно от прода. Автор явно смотрит в сторону сценария "а давайте заменим etcd в Kubernetes", и это звучит странно ровно до того момента, пока не задумываешься, что control plane - это по сути и есть машина состояний, которую мы постоянно мучаем бэкапами, ресторами и попытками понять "а что вообще произошло". Пока это всё выглядит как эксперимент и есть куча вопросов по перформансу и консистентности. Но сама идея сильная: не хранить состояние как главную сущность, а хранить историю, из которой оно получается. И это как раз тот случай, когда сначала думаешь “что за дичь”, а потом “блин, а ведь в этом что-то и правда есть” 🙂

Исторя #22 По мотивам обновления кластера клиента

Короче, прямо сейчас разворачивается довольно показательная история из мира supply chain атак 👇 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)

У нас тут появился запрос на то чтобы упростить нашим пользователям путь для запуска своих приложений в 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 на базе этого решения.

Тут поресёрчил тему, как распилить 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

Тут поресёрчил тему, как распилить GPU между виртуалками. MIG сам по себе не подходит, т.к. для QEMU/KVM нужен passthrough через VFIO. Полный passthrough работает с PCI-устройством целиком, а для шаринга одного GPU между несколькими VM нужен механизм vGPU. vGPU реализуется через mediated devices (mdev), которые создаются на хосте и затем пробрасываются в виртуалки через VFIO. Именно этот функционал у NVIDIA исторически доступен только в рамках проприетарного NVIDIA vGPU софта и требует лицензии. При этом NVIDIA сейчас двигается в сторону open-source GPU virtualization: есть RFC-патчи для реализации vGPU в Linux, которые должны работать для VM passthrough. Но это пока не в mainline, патчи на стадии обсуждения, и когда (и в каком виде) их смерджат — непонятно. https://www.phoronix.com/news/NVIDIA-Open-GPU-Virtualization

Kubernetes 1.35 — что завезли ⭐️ Стабильно в прод • In-place Pod Resize — наконец-то GA! Можно менять requests/limits (CPU/RAM) на лету без рестарта пода. Киллер-фича для тяжелых stateful-приложений и AI-инференса (вертикальный автоскейлинг без даунтайма). • Traffic Distribution — стратегия PreferSameNode теперь stable. Трафик сервиса старается не покидать узел, если эндпоинт есть локально. Минус хоп — ниже latency. • Job ManagedBy — залочили в true. Упрощает жизнь внешним контроллерам (Kueue и прочим ML-оркестраторам), которые управляют джобами. 🧪 Беты (почти готово) • Pod Certificates — Kubelet научился сам выпускать и ротировать X.509 сертификаты для подов. Нативный mTLS/Workload Identity без лишних сайдкаров. • Job Recovery — теперь можно менять ресурсы (CPU/Mem) у Suspended Job’ов. Если ML-обучение упало с OOM через 5 часов — ставим на паузу, накидываем памяти и продолжаем, не пересоздавая объект. 🤖 AI и Альфы (пощупать) • Gang Scheduling — нативная поддержка "all-or-nothing". Критично для распределенного ML-обучения: запускать группу подов только если есть ресурсы на всех сразу, иначе не запускать ничего. Реализовано через новый Workload API. • Node Declared Features — ноды сами сообщают планировщику, какие фичи поддерживают. Помогает, когда в кластере зоопарк версий или разное железо. • Restart Policies — новая логика RestartAllContainersOnContainerExit: если упал основной контейнер (app), куб пристрелит и сайдкары (логи/прокси), чтобы под перезапустился целиком. 🛡️ Ломают/Убирают • IPVS в kube-proxy — всё, deprecated. Рекомендуют мигрировать на nftables. • Gogo Protobuf — вычистили из API-типов. https://kubernetes.io/blog/2025/12/17/kubernetes-v1-35-release/

Сегодня тестировал kilo (свободный кластер меш для Kubernetes) и не смог прокачать 10г. Оказалось что wireguard изначально придуман так чтобы имел очень простую архитектуру. Но по факту каждый wg интерфейс не может утилизировать больше одного ядра и это заложено в дизайне. Это подтолкнуло меня рассмотреть альтернативные реализации. И тут старый-добрый IPsec выглядит весьма перспективно, AES-шифрование можно оффлоадить на CPU и такой проблемы с привязкой к одному ядру вроде как нет. В догонку отличная статья с разбором бенчмарков Wireguard vs IPsec https://docs.cilium.io/en/latest/operations/performance/benchmark/

Начал писать пост, случайно получилась целая статья https://habr.com/ru/companies/aenix/articles/975324/

Недавно узнал что в go можно эмбедить файлы прямо в бинарник. Это прям супер удобно, особенно для написания различных CLI-утилит, которые традиционно распространяются в формате: "скачай бинарник из запусти". Раньше я использовал кодогенерацию, но в большинстве случаев можно обойтись без неё. Можно эмбедить Kubernetes-манифесты, Helm-чарты, так и вообще любую статику. //go:embed позволяет на этапе сборки положить файлы прямо в бинарь. Go читает указанные пути, запаковывает содержимое в секцию данных, а в рантайме это выглядит как обычная переменная или embed.FS. Дальше с этим можно работать так же, как с привычной файловой системой из пакета io/fs: открывать файлы, читать директории, перечислять содержимое. Фактически это виртуальный read-only FS, который живёт внутри бинарника и полностью повторяет структуру исходных путей. Примеры: - Довольно исчерпывающий пример от Go by example - Мой пример в Talm, где я эмбежу ./charts в гошный пакет

А вот еще интересная статья. Ученые из университета Мэриленда вместе с учёными из Microsoft проверяли одну любопытную вещь: как ИИ-модели ведут себя на очень длинных текстах в разных языках. Не просто "переведи фразу" или "ответь на вопрос", а вот прям дать модели 80–120 тысяч токенов текста (это примерно книга), спрятать в нём кусок инфы и попросить найти. Тест этот называется ONERULER. Тестировали 26 языков: от английского, русского и испанского, до хинди, суахили, тамильского и сесото. Результаты любопытные: яснопонятно, что языки не равны. ВНЕЗАПНО, промпты на английском языке не самые эффективные. Оказалось, что лучше всего модели понимают польский (≈ 88% эффективность). Чуть ниже, но всё ещё в топе: русский, украинский, французский и итальянский. А английский вообще только на шестом месте (≈ 83.9% эффективность). Так что если модель иногда отвечает странно, возможно, она просто ждёт, пока вы напишите в промпт "Бобр курва!"

Мы подружили Talos с ванильным Kubernetes control-plane 🎉 Недавно, благодаря совместным усилиям Ænix и CLASTIX, появилась рабочая группа, для добавления поддержки ванильного Kubernetes control-plane в Talos Linux. В рамках этой задачи только что был опубликован проект talos-csr-signer. Он реализует функциональность сервиса trustd, встроенного в Talos Linux. Принцип работы простой: когда Talos-нода загружается и подключается к кластеру, она отправляет запрос на <control-plane>:50001, чтобы получить подписанный сертификат. После этого можно общаться с нодой через Talos API, используя сертификат, подписанный тем же CA. Что это нам даёт? - Думаю что в скором вы сможете ожидать полноценную поддержку Talos Linux воркеров в Kamaji - В Cozystack появится возможность на лету менять версию Kubernetes-воркеров, и использовать предустановленные GPU-драйверы. Ещё один рабочий пример совместной работы с комьюнити. Рад, что такой формат продолжает себя оправдывать.

Через 20 минут буду рассказывать про Kubernetes Aggregation API Layer на DevOpsDays Almaty Прямая трансляция: https://www.youtube.com/live/8WLM2zrn8Qw