Через 20 минут буду рассказывать про Kubernetes Aggregation API Layer на DevOpsDays Almaty

Прямая трансляция:
https://www.youtube.com/live/8WLM2zrn8Qw

Мы подружили 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-драйверы.

Ещё один рабочий пример совместной работы с комьюнити. Рад, что такой формат продолжает себя оправдывать.

А вот еще интересная статья. Ученые из университета Мэриленда вместе с учёными из Microsoft проверяли одну любопытную вещь: как ИИ-модели ведут себя на очень длинных текстах в разных языках. Не просто "переведи фразу" или "ответь на вопрос", а вот прям дать модели 80–120 тысяч токенов текста (это примерно книга), спрятать в нём кусок инфы и попросить найти. Тест этот называется ONERULER.

Тестировали 26 языков: от английского, русского и испанского, до хинди, суахили, тамильского и сесото.

Результаты любопытные: яснопонятно, что языки не равны. ВНЕЗАПНО, промпты на английском языке не самые эффективные. Оказалось, что лучше всего модели понимают польский (≈ 88% эффективность). Чуть ниже, но всё ещё в топе: русский, украинский, французский и итальянский. А английский вообще только на шестом месте (≈ 83.9% эффективность).

Так что если модель иногда отвечает странно, возможно, она просто ждёт, пока вы напишите в промпт "Бобр курва!"

Недавно узнал что в go можно эмбедить файлы прямо в бинарник. Это прям супер удобно, особенно для написания различных CLI-утилит, которые традиционно распространяются в формате: "скачай бинарник из запусти".

Раньше я использовал кодогенерацию, но в большинстве случаев можно обойтись без неё. Можно эмбедить Kubernetes-манифесты, Helm-чарты, так и вообще любую статику.

//go:embed позволяет на этапе сборки положить файлы прямо в бинарь. Go читает указанные пути, запаковывает содержимое в секцию данных, а в рантайме это выглядит как обычная переменная или embed.FS.

Дальше с этим можно работать так же, как с привычной файловой системой из пакета io/fs: открывать файлы, читать директории, перечислять содержимое. Фактически это виртуальный read-only FS, который живёт внутри бинарника и полностью повторяет структуру исходных путей.

Примеры:
- Довольно исчерпывающий пример от Go by example
- Мой пример в Talm, где я эмбежу ./charts в гошный пакет

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

Сегодня тестировал kilo (свободный кластер меш для Kubernetes) и не смог прокачать 10г.

Оказалось что wireguard изначально придуман так чтобы имел очень простую архитектуру. Но по факту это означает что каждый wg интерфейс не может утилизировать больше одного ядра и это заложено в дизайне.

Это подтолкнуло меня рассмотреть альтернативные реализации. И тут старый-добрый IPsec выглядит весьма перспективно, AES-шифрование можно оффлоадить на CPU и такой проблемы с привязкой к одному ядру вроде как нет.

В догонку отличная статья с разбором бенчмарков Wireguard vs IPsec от создателей Cilium.
https://docs.cilium.io/en/latest/operations/performance/benchmark/

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/

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

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

Короче, прямо сейчас разворачивается довольно показательная история из мира 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)
- Чуть больше про механику работы GitHub от @kruchkov_alexandr

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

Мне тут закинули интересный проект - T4.

По сути это такой git с S3-бэкендом и фронтендом в виде etcd.
Снаружи всё выглядит как обычный etcd-compatible datastore, а внутри вместо привычного "храним состояние" - просто поток изменений, который складывается в виде WAL в object storage.

Если подумать, модель довольно нетипичная: источником истины становится не состояние, а лог изменений.
А дальше из этого уже вытекают все побочные эффекты — можно откатываться, воспроизводить состояние, делать форки и гонять эксперименты отдельно от прода.

Автор явно смотрит в сторону сценария "а давайте заменим etcd в Kubernetes", и это звучит странно ровно до того момента, пока не задумываешься, что control plane - это по сути и есть машина состояний, которую мы постоянно мучаем бэкапами, ресторами и попытками понять "а что вообще произошло".

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

И это как раз тот случай, когда сначала думаешь "что за дичь", а потом "блин, а ведь в этом и правда что-то есть" 🙂

Вышел подкаст DevOps Paradox со мной 🎙️

Поговорили про Kubernetes, путь Ænix и Cozystack, попытки собрать "свой AWS" для on-prem. Обсудили современные тренды и конечно же AI, как он помогает нам в работе уже сегодня.

https://www.devopsparadox.com/episodes/cozystack-turns-bare-metal-into-a-managed-services-platform-347/

Если ещё беспокоитесь за 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

Магия кэша в controller-runtime: почему ваши контроллеры быстрые, стабильные и не убивают apiserver

Если вы когда-нибудь писали Kubernetes-контроллер на Go, то почти наверняка использовали controller-runtime.
А если использовали — значит, пользовались одной из самых недооценённых и мощных частей всего Kubernetes-стека: кэшем controller-runtime.

https://habr.com/ru/companies/aenix/articles/1031818/