Kuber Conf от АОТ

От бизнес-требования к ядру Linux

Ночью наша нода занята наполовину, а платим мы за все ядра. Расскажу, как запускать batch-нагрузки, не нарушая SLO low-latency-сервиса, и добиться более плотной утилизации нод.

Как дать агенту управление кластером вашей инфраструктуры?

В эпоху агентоцентричной системы часто приходится взаимодействовать с внешними данными за пределами вашего IDE. Но что если дать возможность агенту работать и настраивать ваш кластер K8s, Deckhouse, Nomad и другими? Расскажу о том, как мы прошли путь от агента, который выключил наш production, до полностью автономной системы и настройки всего кластера.

Как мы в MWS Cloud Platform доставляем системный софт в managed K8s

Проблема доставки provider-софта в Kubernetes всегда была местом для творчества команд, предоставляющих Kubernetes as a Service. Поделюсь тем, как это делаем мы в MWS Cloud Platform.

Bare metal в Managed Kubernetes: как мы узнали, что железо — это не большая виртуалка

Добавить поддержку bare-metal-нод в Managed Kubernetes — задача из серии «поменяйте тип c VM на bare metal». На практике исчезновение слоя виртуализации ломает почти все допущения, на которых построен managed-сервис.

В докладе я проведу вас по пути, который мы прошли от списка требований до работающего сервиса. Расскажу:

Круглый стол: «Kubernetes победил, и это проблема?»

Король оркестраторов выбран единогласно — Kubernetes. Насколько это хорошо, целесообразно ли всё оборачивать в операторы и описывать через Custom Resources, есть ли сегодня альтернатива k8s и какой смысл в создании своих инструментов для оркестрации — про всё это и многое другое мы подискутируем на круглом столе.

Круглый стол: «Из-за ИИ нас всех уволят, что будем делать?»

С приходом LLM мир в целом, и особенно наш профессиональный уютный ИТ-уголок изменился навсегда: ОГРОМНОЕ количество работы забрал на себя ИИ, а людям осталось только получать зарплату. А зачем тогда компаниям нанимать сотрудников в принципе? Останется ли работа для нас вообще? Порекомендуете ли вы нынешним школьникам становиться айтишниками? А агента в прод пустите?

Об этом и о многом другом поговорим на нашем круглом столе. Участники смогут задать вопросы и поспорить со спикерами. Приходите, будет весело!

Проект вместо namespace: как сделать мультитенантность в Kubernetes-платформе

Namespace группирует объекты и на этом заканчивается. Потребление ресурсов по умолчанию не ограничено, сетевая связность работает из любой точки кластера, доступ к ресурсам узла не урезан, а сбора логов, аудита и сканирования уязвимостей нет вообще. Поэтому в Deckhouse Platform единица мультитенантности — это проект: namespace вместе с квотами, сетевой изоляцией, Pod Security Standards, политиками и доступом, собранными по одному шаблону, который администратор пишет один раз, а не повторяет руками в каждой команде.

В докладе я разберу устройство этой машинерии целиком. Поговорим о том, как описывается проект, что и кем рендерится в его namespace, где живут квоты, как тенант получает доступ к кластерным ресурсам вроде StorageClass и ClusterIssuer и что удерживает границу между проектами, когда шаблон писал не тот, кто его применяет.

Отдельно расскажу про честную цену решения. Это и выпиленный в пользу нативного ResourceQuota движок квот на объекты, и шаблон в виде Helm-строки — одновременно путь для инъекции постороннего объекта в манифест и право, эквивалентное cluster-admin. Поделюсь ситуацией из опыта с собственными вебхуками, заклинившими очередь платформы.

Слушатели унесут с доклада переносимые решения: как выдавать права на растущий набор namespace, где в мультитенантности реально проходят границы привилегий, какие грабли ждут при переименовании ролей в живых кластерах и в какой момент честнее отдать команде отдельный кластер, а не проект.

Одна строчка положила весь парк Kubernetes-кластеров: грабли ClusterClass и архитектура, которая из них выросла

Cluster API и ClusterClass позволяют описать кластер Kubernetes один раз и штамповать его как продукт. Именно так мы построили Managed Kubernetes на своей on-prem-инфраструктуре: vSphere, OpenStack, Proxmox, самообслуживание через UI и CLI и как результат — кластер за пять минут.

Пятнадцатого апреля одна строчка в Go-структуре — совершенно правильное изменение, закрывающее анонимный доступ к kube-apiserver, — вывела из строя сразу весь парк клиентских кластеров. На восстановление ушло два часа сорок пять минут, и часть кластеров пришлось чинить руками по SSH. Это была не чья-то ошибка, а прямое следствие того, как работает ClusterClass, если пользоваться им по инструкции из раздела «Getting started» на сайте Kubernetes.

В докладе — пять граблей, на которые может наступить любой, кто дошёл до второго десятка кластеров, и архитектура версионирования, которая из них выросла. С реальным кодом, реальным постмортемом и честной ценой принятых решений.

AI-чат, который видит все ваши системы

LibreChat, большая языковая модель на vLLM, 2 H200 GPU, 13+ MCP-серверов как мост между агентом и инфраструктурой — всё это self-hosted внутри периметра.

LLM-диагностика инцидентов в Kubernetes и OpenStack: расследуем один раз, дальше выполняем без модели

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

В докладе расскажу про альтернативный вариант для диагностики Kubernetes и OpenStack, где результат расследования становится исполняемым артефактом. После проверки инженером он попадает в библиотеку диагностических процедур и используется повторно без участия LLM. Таким образом модель занимается только поиском нового знания, а воспроизводимые сценарии выполняются детерминировано.

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

Отдельно поговорим о том, почему «память» таких систем деградирует. Я покажу, какие механизмы позволяют этого избежать и сохранить базу знаний пригодной для автоматического выполнения. А также сравню между собой три подхода на обезличенных инцидентах: классический LLM-агент, агент с доступом к текстам прошлых расследований и наш ассистент с библиотекой исполняемых процедур.

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

Отечественная кластерная суперкомпьютерная OS: Почему операционная система становится следующим этапом развития HPC

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