Kubernetes Dashboard, ранее являвшийся основным визуальным интерфейсом для Kubernetes, был архивирован. Он служил важным инструментом для многих пользователей, упрощая обзор кластера и проверку ресурсов. Headlamp теперь продолжает это наследие, опираясь на основу Dashboard. Он предлагает четкий визуальный интерфейс, учитывая современные шаблоны использования Kubernetes. Headlamp обеспечивает обзор нескольких кластеров, представление приложений через проекты и расширяемость с помощью плагинов. Переход призван сохранить ориентированное на пользователя наследие Dashboard и предложить развивающееся решение для пользовательского интерфейса. Многие привычные рабочие процессы из Kubernetes Dashboard сохранены в Headlamp, обеспечивая преемственность и простоту использования. Headlamp расширяет возможности, позволяя управлять несколькими кластерами из одного интерфейса, снижая сложность для распределенных сред. Проекты в Headlamp предлагают представление приложений, группируя связанные ресурсы для лучшего понимания и устранения неполадок. Платформа также расширяема с помощью плагинов, таких как плагин Flux для рабочих процессов GitOps или AI-ассистент для получения рекомендаций. Headlamp предлагает гибкие варианты развертывания, его можно использовать как инструмент внутри кластера или как настольное приложение. Понимание текущего использования Dashboard, включая кластеры, пространства имен и аутентификацию, способствует плавному переходу на Headlamp.

Kubernetes улучшает прозрачность, уточняя свои записи CVE для повышения точности. Они обнаружили несоответствия в старых записях CVE, в некоторых из которых некорректно указаны исправленные версии. Комитет по реагированию на угрозы безопасности Kubernetes исправит эти записи 1 июня 2026 года. Это может привести к тому, что сканеры уязвимостей выявят ранее необнаруженные проблемы. Этот пост предлагает технические подробности о трех неисправленных уязвимостях: CVE-2020-8561, CVE-2020-8562 и CVE-2021-25740. Обновления обеспечивают корректное сканирование уязвимостей и разъясняют постоянные потребности в административном смягчении последствий. CVE-2020-8554, также неисправленная, получит стандартизированный формат номера версии. Выявленные уязвимости остаются неисправленными, потому что их исправление нарушит основную функциональность Kubernetes. Каждая уязвимость имеет конкретные меры по смягчению последствий, которые администраторы должны реализовать для защиты своих кластеров. Эти действия имеют решающее значение, учитывая архитектурный характер уязвимостей. Проект подчеркивает подход "безопасность через конфигурацию" для управления этими рисками. Обновление этих записей демонстрирует развитие экосистемы безопасности, способствующей прозрачности и точной оценке рисков.

SIG-Etcd выпустил первую бета-версию etcd v3.7.0, значительное обновление для распределенной базы данных. Эта версия вводит RangeStream, функцию, предназначенную для улучшения обработки больших наборов результатов, повышения задержки и управления памятью. В выпуске также включены рефакторинг и очистка устаревших компонентов и интерфейсов, улучшающих общую производительность. Разработчики призывают пользователей протестировать бета-версию и сообщить о любых проблемах, найденных в репозитории etcd. Одним из ключевых моментов является удаление последних остатков etcd v2store, завершение перехода на v3store. Этот переход может ввести изменения, нарушающие совместимость, особенно для пользователей, не использующих v3.6.11, поэтому запрошена обратная связь о любых проблемах, с которыми они столкнулись. Этот выпуск бета-версии также включает обновления библиотек bbolt и raft. Кроме того, график выпуска связан с датой окончания поддержки (EOL) для etcd v3.4, который перестанет получать обновления после мая. Сообщество готово выпустить дополнительный патч безопасности для v3.4, если это необходимо, до его окончательного устаревания. Пользователям рекомендуется обновиться с v3.4. Планируются будущие бета-версии, потенциально с дальнейшим рефакторингом protobuf, что приведет к кандидатам на выпуск и окончательной версии в июне или начале июля. Обратная связь активно запрашивается через проблемы GitHub, канал Kubernetes Slack и список рассылки etcd-dev.

Эта статья, изначально датированная неверно, теперь отражает дату публикации 15 мая 2026 года. Kubernetes v1.36 представляет новую альфа-метрику, `route_controller_route_sync_total`, для контроллера маршрутов Cloud Controller Manager. Эта метрика отслеживает операции синхронизации маршрутов с облачным провайдером, помогая в мониторинге функционального переключателя `CloudControllerManagerWatchBasedRoutesReconciliation`. Эта функция, представленная в v1.35, переключает контроллер маршрутов на подход, основанный на наблюдении. Это изменение уменьшает количество вызовов API, выполняя согласование маршрутов только при изменении узлов. Чтобы протестировать новую функцию, сравните поведение метрики с отключенным и включенным функциональным переключателем. С отключенным функциональным переключателем счетчик увеличивается через фиксированный интервал. И наоборот, с включенной функцией счетчик увеличивается только при изменении узлов. Эта разница наиболее заметна в стабильных кластерах с нечастыми изменениями узлов. Обратную связь можно предоставить через Kubernetes Slack, проблему GitHub и страницу сообщества SIG Cloud Provider. Более подробная информация доступна в KEP-5237.

Прокси смешанных версий (MVP) улучшает обновление кластеров Kubernetes, безопасно направляя запросы для неизвестных ресурсов на более новые API-серверы, предотвращая ошибки 404. Первоначально представленный как Alpha-функция в Kubernetes 1.28, MVP теперь переходит в Beta в версии 1.36 и будет включен по умолчанию. MVP решает проблему API-серверов с разными версиями во время обновлений, когда запросы для новых ресурсов могут завершиться неудачей на старых серверах. Вместо некорректной ошибки 404 запрос проксируется на сервер, способный его обработать. Бета-версия MVP использует агрегированное обнаружение вместо API StorageVersion для определения возможностей одноранговых узлов, улучшая функциональность. Это обновление также включает агрегированное обнаружение одноранговых узлов, предоставляя клиентам унифицированное представление всех доступных API. Чтобы включить MVP, API-серверам требуется флаг --peer-ca-file, а также --peer-advertise-ip и --peer-advertise-port, если необходимо. С kubeadm вы можете включить эти флаги в файл ClusterConfiguration, чтобы упростить процесс. Пользователям рекомендуется протестировать MVP в промежуточных средах и предоставить обратную связь SIG API Machinery в рамках обновления 1.36.

Поле `.spec.externalIPs` в сервисах Kubernetes, первоначально предназначенное для функциональности, не связанной с облачными балансировщиками нагрузки, теперь устарело из-за уязвимостей безопасности, выявленных в CVE-2020-8554. Это поле позволяет указывать дополнительные IP-адреса, на которые отвечает сервис, но оно имеет присущие ему риски безопасности, поскольку предполагает доверие между всеми пользователями. Kubernetes 1.21 уже рекомендовал отключить `.spec.externalIPs`, и был представлен контроллер допуска для обеспечения этого. Альтернативы, такие как сервисы LoadBalancer, управляемые вручную, или контроллеры балансировки нагрузки, не связанные с облаком, такие как MetalLB, предлагают лучшую безопасность и контроль. MetalLB позволяет администраторам контролировать назначение IP-адресов, смягчая проблемы безопасности. Gateway API также предоставляет безопасное решение, предоставляя администраторам контроль над IP-адресом через ресурс Gateway. Kubernetes 1.36 официально объявил `.spec.externalIPs` устаревшим и начал выдавать предупреждения об его использовании. Поддержка этой функции в kube-proxy будет отключена в будущей версии, а полное удаление запланировано в последующих версиях. Пользователям рекомендуется перейти от этой небезопасной функции.

Kubernetes v1.35 представил улучшения планирования с учетом рабочих нагрузок, включая Workload API и базовое групповое планирование для идентичных Pod'ов. Kubernetes v1.36 уточняет эту архитектуру, отделяя Workload API (статический шаблон) от нового PodGroup API (состояние во время выполнения). Это разделение упрощает kube-scheduler, позволяя ему напрямую считывать информацию PodGroup для повышения производительности. Новый цикл планирования PodGroup позволяет атомарно обрабатывать рабочие нагрузки, оценивая целые группы как единую операцию для предотвращения взаимоблокировок. Если найдено допустимое размещение и соблюдены ограничения группы, Pod'ы связываются вместе; в противном случае вся группа считается непланируемой и повторяет попытку позже. Это формирует основу для группового планирования, обеспечивая размещение "все или ничего" для строгих требований к рабочей нагрузке. Топологически-ориентированное планирование в v1.36 позволяет определять топологические ограничения на PodGroup, размещая Pod'ы в определенных физических или логических доменах для уменьшения задержки сети. Это включает в себя генерацию, оценку и ранжирование кандидатов на размещение на основе ограничений планирования. Предварительное вытеснение с учетом рабочей нагрузки введено для поддержки цикла планирования PodGroup, вытесняя Pod'ы с нескольких узлов одновременно, чтобы освободить место для всей PodGroup. Оно рассматривает PodGroup как единую единицу вытеснения, с полями приоритета PodGroup и disruptionMode, управляющими поведением вытеснения. Наконец, v1.36 интегрирует Dynamic Resource Allocation (DRA) с Workload API, позволяя PodGroup запрашивать и совместно использовать специализированные аппаратные ресурсы через ResourceClaims. Эти улучшения закладывают прочную основу для создания расширенных возможностей планирования рабочих нагрузок в будущих выпусках Kubernetes.

Информация о давлении (PSI) интегрирована в ядро Linux с 2018 года, предоставляя высокоточные сигналы для выявления насыщения ресурсов до того, как это приведет к сбоям. В отличие от традиционных метрик использования, PSI количественно оценивает зависшие задачи и потерянное время для CPU, памяти и ввода-вывода. С Kubernetes v1.36 теперь доступен стабильный интерфейс для наблюдения за борьбой за ресурсы на уровне узлов, подов и контейнеров. PSI предлагает совокупные итоги зависшего времени и скользящие средние (10 с, 60 с, 300 с), чтобы различать кратковременные всплески и устойчивое напряжение ресурсов. Обширное тестирование производительности, проведенное SIG Node на рабочих нагрузках высокой плотности (80+ подов), доказало готовность PSI к производству. Накладные расходы Kubelet, измеренные путем переключения флага функции KubeletPSI, показали незначительное влияние на использование ресурсов. Логика сбора данных Kubelet оказалась легкой, органично вписываясь в стандартные циклы обслуживания, потребляя менее 0,1 ядра или 2,5% от общей емкости узла. Что касается накладных расходов ядра, включение PSI в ядре Linux (psi=1 против psi=0) привело к стабильной дельте от 0,037 до 0,125 ядер (0,925% - 3,125% от емкости узла) при высокой нагрузке. Процесс kubelet, как основной сборщик, также поддерживал удивительно низкое использование CPU, при этом пики не превышали 0,25 ядер (6,25%) более чем на секунду. Улучшения в v1.36 включают более интеллектуальную выдачу метрик; Kubelet теперь обнаруживает поддержку PSI на уровне ОС через конфигурации cgroup перед отчетом, предотвращая вводящие в заблуждение метрики с нулевым значением. Чтобы использовать PSI, узлы должны работать под управлением ядра Linux 4.20+, использовать cgroup v2 и иметь включенную PSI на уровне ОС (CONFIG_PSI=y, без параметра загрузки psi=0). Метрики PSI обычно доступны в v1.36 и не требуют включения флага функции. Пользователи могут собирать данные с конечной точки /metrics/cadvisor или запрашивать Summary API. PSI является функцией ядра Linux и недоступна на узлах Windows. Проксирование к HTTP API Kubelet через API-сервер плоскости управления позволяет получать данные о давлении в реальном времени из Summary API, но является привилегированной операцией.

Kubernetes v1.36 вводит общедоступность (GA) для снимков групп томов, функцию, которая ранее была Alpha, а затем Beta-улучшением. Эта функциональность использует расширения API для включения согласованных сбоев снимков нескольких томов одновременно. Система группирует объекты PersistentVolumeClaim с помощью селекторов меток, что позволяет восстановить рабочие нагрузки до согласованной точки восстановления. Эта функция поддерживается исключительно для драйверов томов CSI, что дает значительное преимущество для приложений, использующих несколько томов, требующих согласованности порядка записи. Ранее индивидуальные снимки томов могли привести к несоответствиям, если они были сделаны в разное время, особенно для приложений с несколькими томами. Групповые снимки устраняют необходимость ручного приостановления приложений, обеспечивая согласованность сбоев во всех томах группы без утомительных, последовательных индивидуальных снимков. Kubernetes управляет групповыми снимками через три пользовательских вида API: VolumeGroupSnapshot, VolumeGroupSnapshotContent и VolumeGroupSnapshotClass. Эти CRD, теперь продвигаемые до v1 в выпуске GA, позволяют пользователям запрашивать групповые снимки, отслеживать их выделенные ресурсы и определять их политику создания соответственно. Выпуск GA приносит улучшенную стабильность, исправления ошибок и улучшенное отчетность о размере восстановления на основе обратной связи от предыдущих бета-версий. Чтобы использовать эту функцию, пользователи должны пометить свои PersistentVolumeClaims, чтобы сгруппировать их, а затем определить объект VolumeGroupSnapshot с селектором, соответствующим этим меткам, вместе с VolumeGroupSnapshotClass. Для восстановления создаются новые PersistentVolumeClaims из отдельных объектов VolumeSnapshot, которые являются частью более крупного VolumeGroupSnapshot. Поставщики хранилищ могут добавить поддержку, реализовав новые службы контроллера групп и RPC в своих драйверах CSI.

Динамическое распределение ресурсов (DRA) в Kubernetes v1.36 вводит значительные улучшения, расширяя свои возможности за пределы специализированного оборудования до родных ресурсов, таких как CPU и память. Поддержка драйверов для различных типов оборудования, включая сетевое оборудование, расширяется, что делает DRA более независимым от оборудования решением. Несколько ключевых функций стали доступны, повышая гибкость планирования и использование кластера. Функция списка с приоритетом позволяет задавать предпочтения для запросов устройств, улучшая эффективность распределения ресурсов. Расширенная поддержка ресурсов позволяет постепенно перейти на DRA, разрешая запросы ресурсов через традиционные расширенные ресурсы. Разделяемые устройства обеспечивают родную поддержку DRA для динамического разделения физического оборудования на более мелкие логические экземпляры. Метки устройств позволяют администраторам более эффективно управлять оборудованием, предотвращая выделение неисправных устройств или резервирование конкретного оборудования. Условия привязки устройств улучшают надежность планирования, задерживая привязку Pod до тех пор, пока внешние ресурсы не будут полностью подготовлены. Состояние здоровья ресурсов раскрывает информацию о здоровье устройства напрямую в статусе Pod, помогая быстро выявлять и реагировать на отказы оборудования. Новые функции альфа-версии включают поддержку ResourceClaim для рабочих нагрузок, оптимизирующую крупномасштабные задачи ИИ/МЛ путем управления общими ресурсами в группах Pod. Распределение ресурсов узла объединяет распределение CPU и памяти под зонтиком DRA, позволяя выполнять тонкую настройку производительности. Видимость доступности ресурсов DRA обеспечивает администраторам информацию о емкости устройств в режиме реального времени для лучшего планирования. Определенный выбор устройства позволяет драйверам влиять на планирование через лексикографический порядок. Метаданные устройств, обнаруживаемые в контейнерах, обеспечивают стандартный протокол для драйверов, чтобы раскрывать атрибуты устройств контейнерам. Будущая дорожная карта фокусируется на совершенствовании существующих функций, повышении производительности, масштабируемости и интеграции с планированием, осведомленным о рабочих нагрузках и топологии, с сильным акцентом на миграции пользователей с Device Plugin на DRA.