TheNote
RSS Блог о Kubernetes Заметка
GooglePlay AppStore

RSS Блог о Kubernetes

Официальная домашняя страница Kubernetes, системы оркестровки контейнеров для автоматизации развертывания, масштабирования и управления контейнерными приложениями. На этой платформе представлена исчерпывающая документация по Kubernetes, проекту, поддерживаемому Cloud Native Computing Foundation. Она включает в себя подробную информацию о запуске приложений без состояния и с состоянием, пакетных заданиях и рабочих процессах CI/CD с использованием Kubernetes. Сайт содержит подробные руководства, учебники, справочные материалы, документацию по API и инициативы по вовлечению сообщества, чтобы помочь пользователям начать работу с Kubernetes и эффективно использовать его возможности для управления облачными приложениями.
RSS kubernetes.io
Kubernetes Blog kubernetes.io
RSS Hunter RSS Hunter • 22 авг. 2024 г.

Трэд заметок

Анонсируем etcd v3.7.0

SIG etcd объявляет о выпуске etcd v3.7.0, значительного обновления распределенного хранилища ключ-значение. Этот выпуск представляет долгожданную функцию RangeStream, обеспечивающую эффективную потоковую передачу больших наборов результатов. Он также включает различные улучшения производительности, в том числе более быстрые операции с арендой и оптимизированные запросы диапазона только для ключей. Зависимость от устаревшего хранилища v2 полностью устранена, теперь etcd загружается исключительно из v3store, что упрощает операции. Комплексный пересмотр protobuf заменяет устаревшие библиотеки поддерживаемыми версиями, улучшая безопасность и удобство сопровождения. В выпуске также обновлены основные зависимости: bbolt до v1.5.1 и raft до v3.7.0. Дополнительные улучшения включают поддержку Unix-сокетов для локальной разработки и тестирования. Команды etcdutl теперь имеют аргументы тайм-аута для предотвращения бесконечной блокировки. Клиент v3 предлагает большую гибкость аутентификации с прямой установкой JWT и возможностью получения AuthStatus без предварительной аутентификации. Добавлены новые метрики длительности наблюдения и запросов для улучшения наблюдаемости. Команды etctl были реорганизованы для ясности, а устаревшие экспериментальные флаги удалены. Также проведена значительная очистка устаревших пакетов и кода API v2.
Announcing etcd v3.7.0 kubernetes.io
RSS Hunter RSS Hunter • 8 июл.

Поддержка открытого исходного кода в эпоху ИИ

ИИ преобразует разработку программного обеспечения, позволяя большему количеству участников благодаря генерации кода. Однако это развитие опережает улучшения в обслуживании кода, что представляет собой проблему. Сообщество Kubernetes активно адаптируется к кодированию с помощью ИИ, устанавливая комплексную политику ИИ. Эта политика направлена на баланс инноваций и подотчетности, обеспечивая качество кода и человеческий надзор. Основным принципом является прозрачность, которая требует от участников раскрытия использования ИИ в их запросах на включение.Критически важно, что человеческая подотчетность остается главной; ИИ не может быть указан в качестве соавтора или соавторства. Участники также должны лично объяснить любой код, сгенерированный ИИ, предотвращая пробелы в знаниях. Проект обеспечивает соблюдение соглашений о лицензии участников для всех соавторов, включая те, которые используют ИИ, помечая неполные запросы на включение. Автоматические обзоры ИИ исследуются для улучшения качества кода и предоставления первоначальной обратной связи.Инструменты, такие как GitHub Copilot и CodeRabbit, оцениваются и тестируются в конкретных проектах Kubernetes. Эти инструменты могут действовать как ворота качества, предлагая быстрые проверки перед человеческим обзором. Сообщество активно ищет помощь в настройке инструментов обзора, оценке новых технологий ИИ и изучении потенциала ИИ в снижении выгорания обслуживающих и помощи в тестировании.
Open source maintainership in the age of AI kubernetes.io
RSS Hunter RSS Hunter • 26 июн.

Представляем плагин Cluster API для Headlamp

Налобный фонарь — это проект пользовательского интерфейса Kubernetes с открытым исходным кодом для управления ресурсами кластера из браузера. Cluster API (CAPI) предоставляет декларативные API в стиле Kubernetes для управления жизненным циклом кластера. Плагин Headlamp Cluster API упрощает управление ресурсами CAPI, устраняя необходимость в необработанных командах kubectl. Этот плагин добавляет выделенный раздел CAPI в Headlamp, предлагая полную видимость основных ресурсов CAPI через согласованные представления списка и деталей. Ключевые функции включают обзор кластера, видимость машин и централизованную панель мониторинга Cluster API для мониторинга состояния. Пользователи могут отслеживать реплики KubeadmControlPlane, масштабировать MachineDeployments и MachineSets, а также визуализировать иерархии принадлежащих ресурсов. Плагин также позволяет проверять KubeadmConfig без необработанного YAML и обеспечивает осведомленность о топологии. Представление карты визуализирует отношения кластера, плоскости управления и рабочих узлов, поддерживая версии Cluster API как v1beta1, так и v1beta2. Метрики Prometheus интегрированы для получения оперативных данных о производительности непосредственно на страницах с подробностями. Разработанный в рамках программы наставничества CNCF LFX, плагин призван улучшить опыт управления Cluster API. Это альфа-версия, и сообществу предлагается оставлять отзывы для дальнейшего развития.
Introducing the Cluster API plugin for Headlamp kubernetes.io
CdXz5zHNQW_bupmQg41I4.png
RSS Hunter RSS Hunter • 25 июн.

Быстрее проверяйте нагрузки Volcano с помощью налобного фонаря

Volcano — это облачный планировщик пакетных заданий для Kubernetes, разработанный для высокопроизводительных вычислений, ИИ/МО и других пакетных рабочих нагрузок. Kubernetes изначально был создан для долгоживущих сервисов, тогда как пакетные рабочие нагрузки часто требуют динамического поступления заданий, конкуренции за ресурсы и одновременного запуска нескольких рабочих процессов. Volcano расширяет Kubernetes такими концепциями, как очереди, приоритеты, квоты и групповое планирование, рассматривая рабочие нагрузки как единое целое, а не как независимые поды. Плагин Volcano для Headlamp, расширяемого веб-интерфейса Kubernetes, выводит эти детали планирования в единый интерфейс.Плагин предоставляет специализированные представления для заданий Volcano, очередей и групп подов, что упрощает эксплуатацию и устранение неполадок пакетных рабочих нагрузок. Представление заданий отображает статус рабочей нагрузки, детали задач, статус подов и позволяет выполнять прямые действия, такие как приостановка/возобновление и доступ к журналам. Представление очередей предоставляет информацию о распределении ресурсов, емкости и деталях резервирования. Представление групп подов разъясняет состояния группового планирования и потенциальные блокировки.Ключевой особенностью является представление карты, которое визуально отображает взаимосвязь заданий, очередей, групп подов и подов, помогая быстро выявлять проблемы в ожидающих или не продвигающихся рабочих нагрузках. Этот плагин улучшает интерактивное устранение неполадок, централизуя связанные ресурсы, структурированные детали и выходные данные времени выполнения, не заменяя инструменты командной строки для автоматизации. Будущие улучшения могут включать интеграцию с Prometheus и более глубокое понимание планирования. Пользователи могут установить плагин через каталог плагинов Headlamp и предоставить обратную связь для формирования его развития.
Inspect Volcano workloads faster with Headlamp kubernetes.io
CdXz5zHNQW_lVauTs2nj6.png
RSS Hunter RSS Hunter • 25 июн.

Управляйте бессерверными приложениями: представляем плагин Headlamp для Knative

Headlamp — это проект с открытым исходным кодом, предназначенный для управления и отладки ресурсов Kubernetes. Knative позволяет запускать бессерверные рабочие нагрузки на Kubernetes, но может быть сложным в эксплуатации с использованием нескольких инструментов. Для решения этой проблемы был разработан плагин Headlamp для Knative. Этот плагин позволяет пользователям всесторонне управлять Knative из Headlamp. Он интегрирует ресурсы Knative в представление сопоставления ресурсов Headlamp, показывая взаимосвязи между KServices, Revisions и DomainMappings. Плагин предлагает подробное представление для KServices, позволяя вносить изменения в режиме реального времени в распределение трафика и конфигурации автомасштабирования. Пользователи также могут перезапускать поды и получать доступ к логам непосредственно из заголовка KService. Плагин облегчает детальное распределение трафика между ревизиями для поэтапных развертываний и A/B-тестирования. Он визуально отображает распределение трафика, статус готовности и теги для каждой ревизии. Конфигурации автомасштабирования четко представлены, указывая, являются ли настройки явными или унаследованными от кластерных значений по умолчанию. В сочетании с плагином Prometheus он предоставляет метрики, такие как частота запросов и задержка для KServices и Revisions. Плагин также предлагает представления списка и деталей для других CRD Knative, включая Revisions, DomainMappings и обзор сети. Установка включает поиск и установку плагина Knative из каталога плагинов Headlamp. Отзывы и сообщения об ошибках можно отправлять через проблемы GitHub или канал Kubernetes Slack.
See your serverless: introducing the Headlamp plugin for Knative kubernetes.io
CdXz5zHNQW_uA3Yt1MH58.png
RSS Hunter RSS Hunter • 25 июн.

Фокус на управлении устройствами WG

Рабочая группа по управлению устройствами занимается растущей потребностью в специализированном управлении аппаратным обеспечением в Kubernetes. Традиционные методы распределения ресурсов недостаточны для рабочих нагрузок в области ИИ, периферийных вычислений и телекоммуникаций, требующих графических процессоров, тензорных процессоров и специфических сетевых интерфейсов. Основной проект группы, Динамическое распределение ресурсов (DRA), достиг общей доступности, что является значительным достижением. DRA предоставляет структурированную четырехэтапную основу для управления устройствами: моделирование, запрос, планирование и активация. Этот новый подход позволяет поставщикам рекламировать детальные аппаратные возможности, а пользователям — указывать точные аппаратные потребности. Затем планировщик Kubernetes интеллектуально сопоставляет эти требования с доступным аппаратным обеспечением. DRA заменяет устаревший API плагинов устройств, который рассматривал устройства как простые целые числа, гибким и декларативным API. Рабочая группа представляет собой меж-SIG усилия, в которых участвуют несколько SIG для обеспечения комплексной интеграции компонентов Kubernetes. Текущие инициативы сосредоточены на повышении выразительности DRA, поддержке операционной видимости и улучшении управления многоузловыми и сложными аппаратными топологиями. Будущая работа включает мониторинг состояния устройств и лучшую поддержку использования сгруппированных устройств. Рабочая группа стремится создать более программируемое и аппаратное-ориентированное будущее для Kubernetes.
Spotlight on WG Device Management kubernetes.io
RSS Hunter RSS Hunter • 24 июн.

Внимание к хранилищу SIG

Статья подчеркивает SIG Storage, группу специальных интересов Kubernetes, ответственного за постоянное хранение данных и управление томами. Син Ян, сопредседатель SIG Storage, обсуждает эволюцию группы от обработки основных постоянных томов до продвижения сложных функций хранения. Первоначально разработанный для безсостояний рабочих нагрузок, Kubernetes теперь поддерживает состоянийные приложения, требующие выделенных решений хранения. SIG Storage была сформирована для решения этих проблем, введя примитивы, такие как PersistentVolumes и PersistentVolumeClaims.Значительным достижением стало Container Storage Interface (CSI), которое позволяет сторонним поставщикам хранения интегрировать свои системы без изменений в ядре Kubernetes. Текущая работа включает Volume Group Snapshot для согласованных сбоем снимков нескольких томов и Changed Block Tracking для эффективных резервных копий, оба из которых недавно стали стабильными версиями. Container Object Storage Interface (COSI) также продвигается для стандартизации интеграции объектного хранения.Недавние успехи для пользователей включают выпуск VolumeAttributesClass в общедоступную версию, позволяющую динамически настраивать свойства хранения, такие как IOPS. Будущие планы развития включают Volume Health для улучшения операционной видимости и потенциального автоматического исправления. SIG Storage ищет помощь сообщества в исправлении ошибок, тестировании, проверке и предоставлении обратной связи о функциях, таких как Mutable PV Affinity и репликация томов.Проблемы для состоянийных рабочих нагрузок включают гравитацию данных, операционную сложность на второй день и подвижность данных. По мере роста рабочих нагрузок ИИ хранение в Kubernetes, как ожидается, станет более интеллектуальным, с растущей популярностью объектного хранения. Высокопроизводительное, низкозадержечное хранение и осведомленное о данных планирование также являются ожидаемыми тенденциями. SIG Storage приглашает сообщество участвовать в решении этих эволюционирующих требований к хранению.
Spotlight on SIG Storage kubernetes.io
RSS Hunter RSS Hunter • 15 июн.

От Kubernetes Dashboard к Headlamp: понимание перехода

Kubernetes Dashboard, ранее являвшийся основным визуальным интерфейсом для Kubernetes, был архивирован. Он служил важным инструментом для многих пользователей, упрощая обзор кластера и проверку ресурсов. Headlamp теперь продолжает это наследие, опираясь на основу Dashboard. Он предлагает четкий визуальный интерфейс, учитывая современные шаблоны использования Kubernetes. Headlamp обеспечивает обзор нескольких кластеров, представление приложений через проекты и расширяемость с помощью плагинов. Переход призван сохранить ориентированное на пользователя наследие Dashboard и предложить развивающееся решение для пользовательского интерфейса. Многие привычные рабочие процессы из Kubernetes Dashboard сохранены в Headlamp, обеспечивая преемственность и простоту использования. Headlamp расширяет возможности, позволяя управлять несколькими кластерами из одного интерфейса, снижая сложность для распределенных сред. Проекты в Headlamp предлагают представление приложений, группируя связанные ресурсы для лучшего понимания и устранения неполадок. Платформа также расширяема с помощью плагинов, таких как плагин Flux для рабочих процессов GitOps или AI-ассистент для получения рекомендаций. Headlamp предлагает гибкие варианты развертывания, его можно использовать как инструмент внутри кластера или как настольное приложение. Понимание текущего использования Dashboard, включая кластеры, пространства имен и аутентификацию, способствует плавному переходу на Headlamp.
From Kubernetes Dashboard to Headlamp: Understanding the Transition kubernetes.io
CdXz5zHNQW_NGyZ88sXD3.png
RSS Hunter RSS Hunter • 1 июн.

Примирение с прошлым: исправление записей для неисправленных уязвимостей Kubernetes

Kubernetes улучшает прозрачность, уточняя свои записи CVE для повышения точности. Они обнаружили несоответствия в старых записях CVE, в некоторых из которых некорректно указаны исправленные версии. Комитет по реагированию на угрозы безопасности Kubernetes исправит эти записи 1 июня 2026 года. Это может привести к тому, что сканеры уязвимостей выявят ранее необнаруженные проблемы. Этот пост предлагает технические подробности о трех неисправленных уязвимостях: CVE-2020-8561, CVE-2020-8562 и CVE-2021-25740. Обновления обеспечивают корректное сканирование уязвимостей и разъясняют постоянные потребности в административном смягчении последствий. CVE-2020-8554, также неисправленная, получит стандартизированный формат номера версии. Выявленные уязвимости остаются неисправленными, потому что их исправление нарушит основную функциональность Kubernetes. Каждая уязвимость имеет конкретные меры по смягчению последствий, которые администраторы должны реализовать для защиты своих кластеров. Эти действия имеют решающее значение, учитывая архитектурный характер уязвимостей. Проект подчеркивает подход "безопасность через конфигурацию" для управления этими рисками. Обновление этих записей демонстрирует развитие экосистемы безопасности, способствующей прозрачности и точной оценке рисков.
Reconciling the Past: Correcting Records for Unfixed Kubernetes CVEs kubernetes.io
RSS Hunter RSS Hunter • 26 мая

Анонс etcd 3.7.0-beta.0

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.
Announcing etcd 3.7.0-beta.0 kubernetes.io
RSS Hunter RSS Hunter • 20 мая

Kubernetes v1.36: Новый метрик для синхронизации маршрутов в Cloud Controller Manager

Эта статья, изначально датированная неверно, теперь отражает дату публикации 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.
Kubernetes v1.36: New Metric for Route Sync in the Cloud Controller Manager kubernetes.io
RSS Hunter RSS Hunter • 15 мая

Kubernetes v1.36: Прокси с разными версиями переходит в бета-версию

Прокси смешанных версий (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.
Kubernetes v1.36: Mixed Version Proxy Graduates to Beta kubernetes.io
RSS Hunter RSS Hunter • 15 мая

Kubernetes v1.36: Устаревание и удаление Service ExternalIPs

Поле .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.36: Deprecation and removal of Service ExternalIPs kubernetes.io
RSS Hunter RSS Hunter • 14 мая

Kubernetes v1.36: Улучшение планирования с учетом рабочих нагрузок

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.
Kubernetes v1.36: Advancing Workload-Aware Scheduling kubernetes.io
RSS Hunter RSS Hunter • 13 мая

Kubernetes v1.36: Метрики PSI для Kubernetes переходят в GA

Информация о давлении (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: PSI Metrics for Kubernetes Graduates to GA kubernetes.io
CdXz5zHNQW_xWB13lRlZh.png
RSS Hunter RSS Hunter • 12 мая

Kubernetes v1.36: Перенос снимков групп объёмов в GA

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.
Kubernetes v1.36: Moving Volume Group Snapshots to GA kubernetes.io
RSS Hunter RSS Hunter • 8 мая

Kubernetes v1.36: Больше драйверов, новые функции и следующая эра DRA

Динамическое распределение ресурсов (DRA) в Kubernetes v1.36 вводит значительные улучшения, расширяя свои возможности за пределы специализированного оборудования до родных ресурсов, таких как CPU и память. Поддержка драйверов для различных типов оборудования, включая сетевое оборудование, расширяется, что делает DRA более независимым от оборудования решением. Несколько ключевых функций стали доступны, повышая гибкость планирования и использование кластера. Функция списка с приоритетом позволяет задавать предпочтения для запросов устройств, улучшая эффективность распределения ресурсов. Расширенная поддержка ресурсов позволяет постепенно перейти на DRA, разрешая запросы ресурсов через традиционные расширенные ресурсы. Разделяемые устройства обеспечивают родную поддержку DRA для динамического разделения физического оборудования на более мелкие логические экземпляры. Метки устройств позволяют администраторам более эффективно управлять оборудованием, предотвращая выделение неисправных устройств или резервирование конкретного оборудования. Условия привязки устройств улучшают надежность планирования, задерживая привязку Pod до тех пор, пока внешние ресурсы не будут полностью подготовлены. Состояние здоровья ресурсов раскрывает информацию о здоровье устройства напрямую в статусе Pod, помогая быстро выявлять и реагировать на отказы оборудования. Новые функции альфа-версии включают поддержку ResourceClaim для рабочих нагрузок, оптимизирующую крупномасштабные задачи ИИ/МЛ путем управления общими ресурсами в группах Pod. Распределение ресурсов узла объединяет распределение CPU и памяти под зонтиком DRA, позволяя выполнять тонкую настройку производительности. Видимость доступности ресурсов DRA обеспечивает администраторам информацию о емкости устройств в режиме реального времени для лучшего планирования. Определенный выбор устройства позволяет драйверам влиять на планирование через лексикографический порядок. Метаданные устройств, обнаруживаемые в контейнерах, обеспечивают стандартный протокол для драйверов, чтобы раскрывать атрибуты устройств контейнерам. Будущая дорожная карта фокусируется на совершенствовании существующих функций, повышении производительности, масштабируемости и интеграции с планированием, осведомленным о рабочих нагрузках и топологии, с сильным акцентом на миграции пользователей с Device Plugin на DRA.
Kubernetes v1.36: More Drivers, New Features, and the Next Era of DRA kubernetes.io
RSS Hunter RSS Hunter • 7 мая

Kubernetes v1.36: Серверный список шардингов и просмотр

Контроллеры Kubernetes сталкиваются с проблемами масштабирования по мере увеличения размеров кластеров, особенно при наблюдении за ресурсами с высокой кардинальностью. Шардинг на стороне клиента, хотя и функционален, не уменьшает объем данных от сервера API, что приводит к неэффективности. Шардинг списка и наблюдения на стороне сервера, представленный в Kubernetes v1.36 в качестве альфа-функции (KEP-5866), решает эту неэффективность. Сервер API фильтрует события на основе указанного контроллером диапазона хэша, отправляя только релевантные данные каждой реплике. Контроллеры используют информеры для перечисления и наблюдения за ресурсами, включая селектор шардинга через WithTweakListOptions. Селектор шардинга используется для фильтрации ресурсов на основе metadata.uid или metadata.namespace объекта. Сервер API возвращает поле shardInfo в метаданных ответа списка для подтверждения правильного применения селектора шардинга. Если оно отсутствует, клиент должен обрабатывать полную, нефильтрованную коллекцию, потенциально прибегая к фильтрации на стороне клиента. Эта функция требует включения функционального переключателя ShardedListAndWatch. Сообщество Kubernetes ищет обратную связь от авторов контроллеров и операторов, особенно тех, кто управляет большими кластерами. Этот подход предназначен для улучшения производительности и масштабируемости контроллера в требовательных средах Kubernetes.
Kubernetes v1.36: Server-Side Sharded List and Watch kubernetes.io
RSS Hunter RSS Hunter • 6 мая

Kubernetes v1.36: Выпускники декларативной валидации в GA

Kubernetes v1.36 представляет декларативную валидацию для нативных типов, теперь общедоступную. Это переходит от написанного вручную кода Go к тегам IDL для определения правил валидации, повышая надежность и предсказуемость API. Предыдущая зависимость от написанного вручную кода приводила к техническому долгу, несоответствиям и непрозрачным API. Решение использует validation-gen, генератор кода, который анализирует теги для автоматической генерации функций валидации Go. Эта структура включает различные маркерные теги для присутствия, ограничений, коллекций, объединений и неизменяемости. Ключевым преимуществом является "фоновое затягивание", позволяющее немедленно ужесточать или ослаблять валидацию, не нарушая существующие объекты. Декларативная валидация делает обзоры API проще и более согласованными с такими инструментами, как kube-api-linter. Проект планирует перенести оставшийся устаревший код и ввести обязательную декларативную валидацию для новых API. Это также открывает будущие преимущества экосистемы, такие как валидация на стороне клиента с помощью таких инструментов, как kubectl, и интеграция с такими инструментами, как Kubebuilder. Миграция продолжается, с возможностями внести вклад в кодовую базу Kubernetes. Документ завершается благодарностью участникам, приветствуя декларативное будущее валидации Kubernetes.
Kubernetes v1.36: Declarative Validation Graduates to GA kubernetes.io
RSS Hunter RSS Hunter • 5 мая

Kubernetes v1.36: Правила приема, которые нельзя удалить

Механизм контроля доступа на основе манифестов Kubernetes, представленный в версии v1.36, устраняет пробелы в обеспечении безопасности политики во время инициализации кластера. Существующий контроль доступа на основе API имеет уязвимости: политики являются объектами API и могут быть удалены, создавая окно безопасности. Эта новая функция позволяет определять веб-хуки и политики на основе CEL как файлы, загружаемые сервером API при запуске. Это гарантирует, что политики активны до того, как будут обработаны какие-либо запросы, защищая от несанкционированных изменений. Она использует поле staticManifestsDir в файле AdmissionConfiguration для указания каталога, содержащего файлы YAML-политик. Эти файлы должны иметь имена, оканчивающиеся на .static.k8s.io, чтобы отличать их от конфигураций на основе API. Эта функция может защитить сами конфигурации доступа от удаления или изменения. Изменения в файлах манифеста автоматически обновляются во время выполнения. Сервер API обеспечивает строгую проверку при запуске и обрабатывает обновления во время выполнения атомарно. Чтобы реализовать эту функцию, необходимо включить функциональный переключатель ManifestBasedAdmissionControlConfig.
Kubernetes v1.36: Admission Policies That Can't Be Deleted kubernetes.io
RSS Hunter RSS Hunter • 4 мая

Kubernetes v1.36: Менеджеры ресурсов на уровне подов (альфа)

Kubernetes v1.36 вводит менеджеры ресурсов на уровне подов в качестве функции альфа-тестирования, улучшая управление ресурсами для задач, чувствительных к производительности. Он расширяет возможности менеджеров топологии, CPU и памяти kubelet до модели распределения ресурсов, ориентированной на под, выходя за рамки спецификаций на уровне контейнеров. Это решает проблему обеспечения эксклюзивных, выровненных по NUMA ресурсов для основных контейнеров приложений, а также поддержки легковесных sidecar-компонентов эффективно. Ранее достижение предсказуемой производительности часто означало выделение эксклюзивных ресурсов всем контейнерам, что было расточительным для sidecar-компонентов. Альтернативно, не делая этого, жертвовала гарантированным качеством обслуживания (QoS) пода. Менеджеры ресурсов на уровне подов позволяют использовать гибридное распределение, позволяя задачам с высокой производительностью достигать выравнивания по NUMA без расточительства ресурсов. Например, под базы данных, чувствительный к задержке, может иметь основной контейнер, получающий эксклюзивный CPU и память, в то время как sidecar-компоненты делят отдельный общий пул пода, изолированный от других ресурсов узла. Другой случай использования включает задачи машинного обучения, где контейнер обучения получает эксклюзивные ресурсы, выровненные по NUMA, а sidecar-компонент сервисной сетки запускается в общем пуле узла. Изоляция CPU управляется путем отключения принудительного выполнения квоты CFS для эксклюзивных контейнеров и принудительного выполнения на уровне пода для контейнеров общего пула. Включение требует конкретных функциональных возможностей kubelet, политик менеджера топологии и статических конфигураций менеджеров CPU и памяти. Новые метрики kubelet обеспечивают наблюдаемость распределения ресурсов и назначения контейнеров. В настоящее время эта функция находится в стадии альфа-тестирования, имеет известные ограничения и оговорки, и пользовательская обратная связь приветствуется через каналы сообщества Kubernetes.
Kubernetes v1.36: Pod-Level Resource Managers (Alpha) kubernetes.io
RSS Hunter RSS Hunter • 1 мая

Kubernetes v1.36: вертикальное масштабирование на месте для ресурсов на уровне подов переходит в бета-версию

Kubernetes v1.36 вводит масштабирование ресурсов на уровне подов в месте, теперь в бета-версии и включено по умолчанию. Эта функция позволяет пользователям динамически регулировать агрегированные ограничения ресурсов работающего пода. Это особенно полезно для подов с общими ресурсами и без ограничений, специфичных для контейнеров. Kubelet определяет метод обновления на основе политики изменения размера (resizePolicy) каждого контейнера, выбирая между обновлениями в месте или перезапусками. Когда происходит изменение размера, Kubelet сначала проверяет, достаточно ли ресурсов на узле. Затем он последовательно обновляет cgroup, чтобы предотвратить превышение ресурсов, расширяя cgroup на уровне пода до того, как будут увеличены cgroup отдельных контейнеров. Состояния подов, такие как PodResizeInProgress, отслеживают прогресс и статус изменения размера. Эта функция требует cgroup v2, поддержки CRI, определенных флагов функций и узлов на основе Linux. Следующий шаг - интеграция этой функции с вертикальным автомасштабированием подов (VPA). Пользователям рекомендуется протестировать эту функцию и предоставить обратную связь через каналы сообщества.
Kubernetes v1.36: In-Place Vertical Scaling for Pod-Level Resources Graduates to Beta kubernetes.io
RSS Hunter RSS Hunter • 30 апр.

Kubernetes v1.36: многоуровневая защита памяти с помощью Memory QoS

Kubernetes v1.36 представляет обновления функции Memory QoS, которая использует cgroup v2 для лучшего управления памятью контейнеров. Ключевые обновления в v1.36 включают резервирование памяти по выбору, обеспечивающее многоуровневую защиту на основе классов QoS Pod. Гарантированные Pods теперь получают жесткую защиту памяти (memory.min), в то время как Burstable Pods получают мягкую защиту (memory.low). BestEffort Pods остаются полностью восстанавливаемыми без специальной защиты. Новый memoryReservationPolicy позволяет раздельно управлять дросселированием и резервированием. Предоставляются метрики наблюдаемости для мониторинга использования memory.min и memory.low по всему узлу. Проверка версии ядра предупреждает пользователей, если ядро старше 5.9 из-за потенциальных проблем с взаимоблокировками. Реализация использует интерфейсы cgroup v2 memory.max, memory.min, memory.low и memory.high. Распределение памяти узла управляется kubelet, обеспечивая надлежащую защиту для каждого pod и класса QoS. Функция может быть включена через конфигурацию kubelet, при этом TieredReservation является ключевой настройкой. Рекомендуемым требованием является Kubernetes v1.36 или более поздняя версия, Linux с cgroup v2 и ядром 5.9 или выше. Пользователи могут взаимодействовать с сообществом SIG Node для обратной связи и внесения вклада.
Kubernetes v1.36: Tiered Memory Protection with Memory QoS kubernetes.io
RSS Hunter RSS Hunter • 29 апр.

Kubernetes v1.36: Снижение устаревания и улучшение наблюдаемости контроллеров

Контроллеры Kubernetes могут страдать от устаревания данных, что приводит к некорректным или отложенным действиям из-за устаревших кэшированных данных. Устаревание возникает из-за того, что локальный кэш контроллера не синхронизирован с фактическим состоянием кластера. Kubernetes v1.36 представляет функции для уменьшения устаревания и улучшения поведения контроллеров. Эти улучшения включают атомарную обработку FIFO в client-go, повышающую согласованность очереди. Kube-controller-manager интегрировал эти улучшения client-go в несколько ключевых контроллеров, таких как DaemonSet и ReplicaSet. Эти контроллеры теперь проверяют версии ресурсов кэша перед выполнением действий, предотвращая действия с устаревшими данными. Авторы информеров могут использовать ConsistencyStore для отслеживания и управления версиями ресурсов, уменьшая устаревание в своих контроллерах. ConsistencyStore предоставляет функции для записи операций записи, проверки готовности кэша и очистки устаревших записей объектов. Kubernetes v1.36 также предлагает новые метрики для мониторинга работоспособности контроллеров, включая количество пропущенных синхронизаций из-за устаревания. Client-go теперь также выдает метрики, показывающие последние версии ресурсов общих информеров. Команда Kubernetes планирует расширить эти функции по уменьшению устаревания на большее количество контроллеров и интегрировать их в controller-runtime. Они призывают пользователей оставлять отзывы и участвовать в дальнейшей разработке.
Kubernetes v1.36: Staleness Mitigation and Observability for Controllers kubernetes.io
RSS Hunter RSS Hunter • 28 апр.

Kubernetes v1.36: Изменяемые ресурсы Pod для приостановленных заданий (бета)

В Kubernetes v1.36 возможность изменять запросы и лимиты ресурсов контейнеров в шаблоне пода приостановленного задания переходит в статус бета-версии. Эта функция, представленная как альфа-версия в v1.35, позволяет контроллерам очередей и администраторам корректировать спецификации ресурсов, такие как CPU, память и GPU, для задания в приостановленном состоянии, до его выполнения. Ранее требования к ресурсам были неизменяемыми после установки, что вынуждало удалять и создавать задания заново для их изменения, теряя ценные метаданные. Эта новая возможность решает проблемы, когда потребности в ресурсах не точно известны при создании задания или когда емкость кластера колеблется. Например, контроллер очереди теперь может уменьшить запрос GPU для задания машинного обучения с четырех до двух, если доступны только два. Сервер API Kubernetes ослабляет ограничения неизменяемости для определенных полей ресурсов для приостановленных заданий, требуя, чтобы spec.suspend задания был установлен в true и все активные поды были завершены, если оно ранее выполнялось. В бета-версии функция MutablePodResourcesForSuspendedJobs включена по умолчанию в v1.36. Пользователи могут протестировать это, создав приостановленное задание, отредактировав его ресурсы, а затем возобновив его. Крайне важно убедиться, что все активные поды завершены перед изменением ресурсов для приостановленного выполняющегося задания, чтобы предотвратить несоответствия.
Kubernetes v1.36: Mutable Pod Resources for Suspended Jobs (beta) kubernetes.io
RSS Hunter RSS Hunter • 27 апр.

Kubernetes v1.36: Детализированная авторизация API Kubelet переходит в GA

Детализированная авторизация API kubelet достигла общей доступности в Kubernetes v1.36. Эта функция заменяет чрезмерно широкое разрешение nodes/proxy для доступа к HTTPS API kubelet, повышая безопасность. Инициатива направлена на устранение риска безопасности, связанного с предоставлением избыточных разрешений инструментам мониторинга. До этого часто использовалось nodes/proxy, что позволяло выполнять команды. Детализированная авторизация сопоставляет конкретные пути API kubelet с более специализированными подресурсами. Система выполняет двойную проверку авторизации для обратной совместимости. Существующие рабочие нагрузки с разрешениями nodes/proxy будут продолжать работать как прежде. Встроенная роль ClusterRole system:kubelet-api-admin обновляется автоматически. Инструменты мониторинга теперь могут использовать конкретные ресурсы, такие как nodes/metrics, улучшая доступ с минимальными привилегиями. Обновление не требует изменений для большинства кластеров. Чтобы проверить функцию, можно запустить pod, проверяющий флаг функции с помощью curl. Следующие шаги включают в себя больше адаптации экосистемы; также может произойти устаревание nodes/proxy.
Kubernetes v1.36: Fine-Grained Kubelet API Authorization Graduates to GA kubernetes.io
RSS Hunter RSS Hunter • 24 апр.

Kubernetes v1.36: Пользовательские пространства имен в Kubernetes наконец-то достигли статуса GA

В Kubernetes v1.36 появилась поддержка в режиме общей доступности (General Availability) для пространств имен пользователей (User Namespaces) — функции, доступной только в Linux, которая обеспечивает улучшенную изоляцию безопасности для контейнеризированных рабочих нагрузок. Эта долгожданная веха позволяет осуществлять изоляцию безопасности "без root" (rootless) для приложений Kubernetes. Важной возможностью является запуск рабочих нагрузок с привилегиями, но при этом ограниченных в пределах пространства имен пользователя, путем установки hostUsers: false. Это делает определенные возможности, такие как CAP_NET_ADMIN, пространственно-зависимыми, предоставляя административные права только на локальные ресурсы контейнера. Ранее процесс, являющийся root внутри контейнера, также был root на хосте, что представляло значительный риск безопасности при побеге из контейнера. Ключевым средством для этой функции являются монтирования с отображением идентификаторов (ID-mapped mounts), которые прозрачно переотображают UID и GID во время монтирования без изменения прав собственности на диске. Это решает проблемы производительности, связанные с обновлением прав собственности томов, которые омрачали ранние этапы разработки. Реализация пространств имен пользователей проста: установите hostUsers: false в спецификации Pod, что не требует изменений в образах контейнеров или сложной конфигурации. Функция использует тот же интерфейс, который был представлен на этапе Alpha. Это достижение является результатом многолетней межпроектной совместной работы между Kubernetes SIG Node, средами выполнения контейнеров и ядром Linux.
Kubernetes v1.36: User Namespaces in Kubernetes are finally GA kubernetes.io
RSS Hunter RSS Hunter • 23 апр.

Изменения меток томов SELinux становятся общедоступными (и вероятные последствия в v1.37)

В Kubernetes v1.37 планируется включить по умолчанию feature gate SELinuxMount, что повысит скорость настройки томов. Это изменение может сломать приложения, полагающиеся на старый метод рекурсивной перемаркировки, особенно те, которые совместно используют тома между привилегированными и непривилегированными подами. Статья призывает к аудиту кластеров в v1.36 для выявления и устранения потенциальных конфликтов, связанных с SELinux. Когда SELinux включен, kubelet применяет метки SELinux к томам для контроля доступа, а новый подход использует параметры монтирования для более быстрой перемаркировки. Поле SELinuxChangePolicy и опция Recursive были созданы, чтобы позволить отказаться от этого метода ускорения производительности. Если условия соблюдены, kubelet теперь может монтировать тома непосредственно с соответствующей меткой SELinux, устраняя необходимость в рекурсивной перемаркировке. selinux-warning-controller выявляет конфликтующие Pods, которые могут сломаться с новой конфигурацией, генерируя события и метрики. Используя предоставленные метрики, администраторы кластера могут обнаружить потенциальные проблемы и внести соответствующие корректировки. Рекомендуемый путь обновления включает в себя включение контроллера, устранение конфликтов, а затем обновление до версии с включенным SELinuxMount, одновременно отслеживая ошибки. Администраторы могут использовать различные методы для принудительного отказа для определенных Pods. Новое поведение обеспечивает более высокую производительность, но изменяет совместное использование томов между разными подами.
SELinux Volume Label Changes goes GA (and likely implications in v1.37) kubernetes.io
RSS Hunter RSS Hunter • 22 апр.

Kubernetes v1.36: Хару

Выпущена версия Kubernetes v1.36, включающая 70 улучшений, из которых 18 перешли в стабильную версию и 25 — в бета-версию. Тема выпуска, «Хару», символизирует весну, ясное небо и далекие горизонты, а логотип вдохновлен картиной Хокусая «Красная Фудзи». Этот выпуск подчеркивает сотрудничество сообщества, многие люди и команды внесли свой вклад в его успех.Ключевые стабильные функции включают детализированную авторизацию API kubelet для улучшенного контроля доступа с минимальными привилегиями. Статус работоспособности ресурсов для выделенных устройств перешел в бета-версию, предлагая унифицированную отчетность о сбоях оборудования. Альфа-версия представляет Workload Aware Scheduling, рассматривая связанные поды как единую логическую сущность для лучшего управления ресурсами.Снимки групп томов теперь стабильны, что позволяет создавать согласованные сбои снимки для нескольких PersistentVolumeClaims. Изменяемые лимиты CSI node allocatable также достигли стабильности, позволяя динамически обновлять емкость томов узлов. Функция внешнего подписанта токенов ServiceAccount теперь стабильна для выгрузки подписи токенов во внешние системы.Административный доступ к динамическому выделению ресурсов (DRA) и приоритетные списки теперь стабильны, обеспечивая безопасную основу для управления ресурсами. Декларативные изменяющие политики допуска стабильны, предлагая нативную альтернативу веб-хукам для изменения ресурсов. Декларативная валидация для нативных типов Kubernetes с validation-gen также перешла в стабильную версию, упрощая разработку пользовательских ресурсов. Удаление зависимости gogo protobuf для типов API Kubernetes знаменует собой значительный шаг вперед для безопасности и удобства обслуживания.
Kubernetes v1.36: ハル (Haru) kubernetes.io
RSS Hunter RSS Hunter • 22 апр.

API Gateway v1.5: Перенос функций в стабильную версию

Gateway API v1.5, выпущенный 14 марта 2026 года, знаменует собой самый значительный релиз на сегодняшний день. Эта версия ориентирована на продвижение нескольких ранее экспериментальных функций в стабильный канал. Ключевые продвижения включают ListenerSet, TLSRoute, HTTPRoute CORS Filter, Client Certificate Validation, Certificate Selection for Gateway TLS Origination и ReferenceGrant. Проект принял модель релизного поезда, синхронизируясь с Kubernetes SIG Release для более предсказуемых обновлений. Этот новый процесс включает выделенные роли Release Manager и Release Shadow. ListenerSet позволяет определять слушатели независимо и объединять их в Gateways, повышая масштабируемость и многопользовательский режим. TLSRoute обеспечивает маршрутизацию на основе SNI для TLS-соединений, поддерживая режимы Passthrough и Terminate. Фильтр HTTPRoute CORS обеспечивает детальный контроль над настройками совместного использования ресурсов между источниками. Проверка клиентских сертификатов, или взаимный TLS (mTLS), позволяет Gateways проверять идентификаторы клиентов, проверяя сертификаты по отношению к доверенным центрам сертификации. Эта функция может быть настроена глобально или для каждого порта для повышения безопасности.
Gateway API v1.5: Moving features to Stable kubernetes.io
RSS Hunter RSS Hunter • 21 апр.

Kubernetes v1.36 Sneak Peek

Kubernetes v1.36, запланированный на конец апреля 2026 года, введет значительные удаления, устаревания и многочисленные улучшения. Проект придерживается строгой политики устаревания, гарантируя, что стабильные API удаляются только после того, как доступна более новая стабильная версия и имеют минимальный срок службы. Недавний пример этой политики - вывод из эксплуатации проекта Ingress NGINX с 24 марта 2026 года, без дальнейшей поддержки или обновлений безопасности. Для v1.36 поле .spec.externalIPs в Service объявляется устаревшим из-за проблем с безопасностью (CVE-2020-8554), с полным удалением, запланированным на v1.43, что побуждает к миграции на LoadBalancer, NodePort или Gateway API. Драйвер тома gitRepo, объявленный устаревшим с v1.11, будет постоянно отключен в v1.36 из-за критической уязвимости безопасности, позволяющей выполнять код от имени root. Нагрузки, в настоящее время использующие gitRepo, должны перейти на альтернативы, такие как контейнеры инициализации или внешние инструменты git-sync.Ключевые улучшения в v1.36 включают общедоступность (GA) более быстрой маркировки SELinux для томов, которая использует параметры монтирования для последовательной производительности и уменьшения задержек запуска Pod. Эта функция, представленная в виде бета-версии в v1.28, теперь включена по умолчанию для всех томов с Pod, в которых указан spec.SELinuxMount. Внешняя подпись токенов ServiceAccount, функция бета-версии, ожидается, что станет стабильной в v1.36, позволяя кластерам интегрироваться с внешними системами управления ключами для повышения безопасности. Динамическое распределение ресурсов (DRA) также претерпевает улучшения, с тaint и tolerations устройств, переходящих в бета-версию, что позволяет ограничить специализированные аппаратные ресурсы для определенных нагрузок. Кроме того, DRA будет поддерживать разделение устройств, позволяя разделить один аппаратный ускоритель на несколько логических единиц, что улучшает использование ресурсов для дорогих ресурсов, таких как GPU. Эти изменения подчеркивают продолжающийся акцент на безопасности, эффективности и продвинутом управлении ресурсами в Kubernetes.
Kubernetes v1.36 Sneak Peek kubernetes.io
RSS Hunter RSS Hunter • 30 мар.

Анонс Ingress2Gateway 1.0: ваш путь к Gateway API

Ingress-NGINX запланирован к выводу из эксплуатации в марте 2026 года, что создаёт необходимость перехода на Gateway API. Переход с Ingress на Gateway API — это значительный сдвиг, переход от расширенных аннотаций к модульному, расширяемому API. Инструмент Ingress2Gateway помогает командам в этом переходе, переводя ресурсы Ingress и их аннотации. SIG Network выпустила Ingress2Gateway версии 1.0 — стабильный помощник по миграции. Этот новый релиз значительно улучшает поддержку аннотаций Ingress-NGINX, охватывая более 30 распространённых аннотаций. Комплексные интеграционные тесты обеспечивают поведенческую эквивалентность конфигураций Ingress-NGINX и сгенерированных манифестов Gateway API. Ingress2Gateway также предоставляет чёткие уведомления о непереводимых конфигурациях и предлагает рекомендации по ручному вмешательству. Инструмент направлен на миграцию поддерживаемых конфигураций, выявление неподдерживаемых и оперативное переосмысление существующих настроек. Пользователи устанавливают и запускают Ingress2Gateway, предоставляя манифесты Ingress или подключаясь к кластеру. Крайне важно, что пользователи должны просматривать сгенерированные результаты и предупреждения, чтобы обеспечить точный перевод и выявить возможные проблемы. Хотя Ingress2Gateway автоматизирует большую часть процесса, ручная проверка и корректировка манифестов Gateway API крайне важны.
Announcing Ingress2Gateway 1.0: Your Path to Gateway API kubernetes.io
RSS Hunter RSS Hunter • 20 мар.

Запуск агентов на Kubernetes с помощью Agent Sandbox

Генеративный ИИ развивается от вызовов stateless функций к системе непрерывно работающих, координированных ИИ-агентов. Эти агенты требуют постоянного контекста, использования инструментов, выполнения кода и меж-агентного взаимодействия в течение длительных периодов времени. Kubernetes — идеальная инфраструктура для этих рабочих нагрузок, но традиционные примитивы не совсем соответствуют потребностям этих stateful, singleton агентов. Новый проект Kubernetes Agent Sandbox, разрабатываемый SIG Apps, направлен на устранение этого разрыва. Он представляет определение пользовательского ресурса (CRD) для управления средами выполнения ИИ-агентов. CRD Sandbox обеспечивает строгую изоляцию для выполнения непроверенного кода с использованием сред выполнения, таких как gVisor или Kata Containers. Он также предлагает надежное управление жизненным циклом, позволяя агентам масштабироваться до нуля в состоянии простоя и мгновенно возобновляться. Кроме того, каждому Sandbox присваивается стабильная идентификация для бесшовного меж-агентного взаимодействия. Для ускорения разработки в быстро развивающейся области ИИ доступен слой API Extensions. Расширение SandboxWarmPool устраняет холодные старты, поддерживая пул предварительно подготовленных подов Sandbox, готовых к немедленному использованию. Пользователи могут установить основные компоненты и компоненты расширений в свои кластеры Kubernetes. Проект Agent Sandbox является проектом с открытым исходным кодом и приглашает сообщество к участию в создании будущего облачных ИИ-агентов.
Running Agents on Kubernetes with Agent Sandbox kubernetes.io
RSS Hunter RSS Hunter • 20 мар.

Обеспечение отладки в производстве в Kubernetes

Отладка в производственной среде часто зависит от широкого доступа, что создает риски для аудита и безопасности. В этой статье рекомендуется внедрять безопасные методы отладки в Kubernetes. Основные стратегии включают использование принципа наименьших привилегий с помощью Role-Based Access Control (RBAC). Ключевое значение для безопасности сессии и подотчетности имеют краткосрочные учетные данные, привязанные к идентификатору. Шлюз в стиле SSH действует как "парадный вход", делая доступ временным. Брокер доступа может улучшить RBAC, контролируя команды и требуя одобрения. Kubernetes RBAC определяет разрешенные действия, обычно предоставляя доступ группам, а не отдельным лицам. Краткосрочные учетные данные, такие как токены OIDC или клиентские сертификаты, связывают сессии с пользователями и истекают. Эти учетные данные в идеале должны быть подписаны регулярно ротируемым центром сертификации. Шлюз доступа по запросу, часто через SSH, обеспечивает безопасный сеанс отладки. Шлюз использует учетные данные для аутентификации пользователя, а затем применяет политики перед взаимодействием с API Kubernetes. Область действия сессии может быть ограничена определенными кластерами и пространствами имен.
Securing Production Debugging in Kubernetes kubernetes.io
RSS Hunter RSS Hunter • 18 мар.

Невидимая перепись: Модернизация Kubernetes Image Promoter

Kubernetes image promoter, kpromo, был полностью переписан для улучшения производительности и удобства обслуживания. Его основная функция - копирование образов контейнеров из промежуточных в производственные реестры, их подписание, репликация подписей и генерация аттестаций, что необходимо для релизов Kubernetes. Переписывание было вызвано сложностью существующей кодовой базы, низкой производительностью и частыми ошибками ограничения скорости. Проект следовал поэтапному подходу, решая проблемы ограничения скорости, интерфейсов, механизма конвейера и функций безопасности. Основные улучшения включали оптимизацию механизма конвейера, параллелизацию операций чтения из реестра и реализацию таймаутов и повторного использования соединений. Переписывание привело к уменьшению кодовой базы на 20% с улучшенной производительностью, надежностью и новыми функциями, такими как происхождение. Несмотря на обширные изменения, команда, занимавшаяся переписыванием, была привержена принципу не нарушать рабочие процессы пользователей. Команда быстро выявляла и исправляла незначительные регрессии во время поэтапного выпуска. Планы на будущее включают дальнейшую оптимизацию путем исключения репликации подписей, потенциальное использование archeio для маршрутизации или интеграцию подписания ближе к инфраструктуре реестра. Проект стал результатом длительных усилий сообщества.
The Invisible Rewrite: Modernizing the Kubernetes Image Promoter kubernetes.io
RSS Hunter RSS Hunter • 17 мар.

Объявление о создании рабочей группы по AI Gateway

Сообщество Kubernetes расширяется за счет формирования Рабочей группы по AI-шлюзам, которая сосредоточится на сетевом взаимодействии для рабочих нагрузок ИИ. AI-шлюз — это сетевая инфраструктура, использующая Gateway API и расширяющая его для рабочих нагрузок ИИ. Это включает такие функции, как ограничение скорости на основе токенов, контроль доступа и инспекция полезной нагрузки. Рабочая группа стремится создать стандарты и лучшие практики для инфраструктуры ИИ в Kubernetes. Их цели включают создание API, содействие сотрудничеству и обеспечение расширяемости для специфичных для ИИ расширений шлюзов. Активные предложения касаются обработки полезной нагрузки для обеспечения безопасности и оптимизации, а также определения исходящих шлюзов. Эти предложения позволяют безопасно интегрировать внешние сервисы ИИ и осуществлять расширенное управление трафиком. Группа удовлетворяет потребности операторов платформ, разработчиков и инженеров по соответствию требованиям. Рабочая группа представит свои выводы на KubeCon + CloudNativeCon Europe 2026. Рабочая группа по AI-шлюзам приветствует вклад различных заинтересованных сторон для формирования будущего возможностей шлюзов с поддержкой ИИ в Kubernetes. Заинтересованные лица могут ознакомиться с предложениями, присоединиться к встречам и участвовать в обсуждениях. Группа работает по модели открытого вклада для разработки стандартов сетевого взаимодействия для рабочих нагрузок ИИ.
Announcing the AI Gateway Working Group kubernetes.io
RSS Hunter RSS Hunter • 9 мар.

Прежде чем мигрировать: пять удивительных поведений Ingress-NGINX, которые вам нужно знать

Kubernetes прекратит поддержку Ingress-NGINX в марте 2026 года, и пользователям необходимо перейти на другие решения, такие как Gateway API. Ingress-NGINX имеет несколько неожиданных настроек по умолчанию и побочных эффектов, которые могут вызвать сбои, если не будут учтены во время миграции. Пост в блоге подчеркивает эти особенности, чтобы помочь пользователям безопасно мигрировать и принимать обоснованные решения о том, какие поведения сохранить. Одной из ключевых проблем является то, что Ingress-NGINX рассматривает шаблоны regex как префиксные и регистронезависимые совпадения, что может привести к неожиданному маршрутизацию. Gateway API, с другой стороны, использует реализацию специфического сопоставления regex, и пользователям необходимо проверить свою реализацию, чтобы подтвердить семантику сопоставления regex. Пост также обсуждает, как сохранить поведение Ingress-NGINX в Gateway API, включая использование сопоставлений HTTP-путей с типом RegularExpression и настройку перенаправлений с помощью фильтра перенаправления HTTP-запроса. Кроме того, пост отмечает, что Ingress-NGINX и NGINX Ingress - это два отдельных контроллера входящих данных, и пост обсуждает только Ingress-NGINX. Аннотация nginx.ingress.kubernetes.io/use-regex применяется ко всем путям хоста во всех входящих данных Ingress-NGINX, и аннотация nginx.ingress.kubernetes.io/rewrite-target бесшумно добавляет аннотацию nginx.ingress.kubernetes.io/use-regex, вместе со всеми ее побочными эффектами. Ingress-NGINX также перенаправляет запросы, не имеющие завершающей косой черты, на тот же путь с завершающей косой чертой, что может вызвать сбои, если не настроено явно в Gateway API. В целом, пост направлен на то, чтобы помочь пользователям понять особенности Ingress-NGINX и безопасно перейти на Gateway API. Пользователям необходимо быть осведомленными об этих поведениях и принять меры для их сохранения в Gateway API, чтобы избежать сбоев.
Before You Migrate: Five Surprising Ingress-NGINX Behaviors You Need to Know kubernetes.io
RSS Hunter RSS Hunter • 27 февр.

Внимание к архитектуре SIG: управление API

Джордан Лиггитт руководит подпроектом управления API Kubernetes, стремясь сбалансировать стабильность API с инновациями. Этот проект курирует все API Kubernetes, включая флаги командной строки и файлы конфигурации, а не только REST API. Обеспечение согласованности и качества включает в себя руководящие принципы, соглашения и автоматизированные инструменты, такие как линтеры. Управление API предоставляет информацию как во время разработки, так и во время реализации API, особенно через процесс KEP. Введение пользовательских ресурсов стало поворотным моментом, расширив возможности API и потребовав расширенной проверки. Управление API сотрудничает с SIG Architecture и API Machinery для определения соглашений и обеспечения последовательного использования API Machinery. Участие в проекте увеличивается перед улучшениями и заморозкой кода в цикле выпуска. Новым участникам следует начать с отслеживания изменений API и наблюдения за процессом обзора. Проект отдает приоритет совместимости и стабильности для пользователей, даже если это требует дополнительных усилий. Цель управления API - планировать будущую эволюцию API, сводя к минимуму нарушения совместимости. Они учитывают, что ошибки будут сделаны, и готовятся к улучшению, сохраняя при этом обещания совместимости.
Spotlight on SIG Architecture: API Governance kubernetes.io
RSS Hunter RSS Hunter • 12 февр.

Знакомство с контроллером готовности узлов

Kubernetes часто сталкивается со сложностями в готовности узлов, выходящими за рамки стандартного статуса "Ready". Контроллер готовности узлов (NRC) решает эту проблему, предоставляя декларативную систему для управления тейнтами узлов. NRC гарантирует, что рабочие нагрузки планируются только на узлах, соответствующих конкретным инфраструктурным требованиям, используя пользовательские сигналы работоспособности. Он заполняет критический пробел, позволяя операторам определять пользовательские шлюзы планирования, адаптированные к конкретным группам узлов. Это предлагает пользовательские определения готовности, автоматизированное управление тейнтами и декларативные возможности начальной загрузки узлов. Контроллер использует API NodeReadinessRule (NRR) для определения этих шлюзов, поддерживая как непрерывные, так и режимы принудительного применения только при начальной загрузке. Он реагирует на условия узла, легко интегрируясь с существующими инструментами, такими как Node Problem Detector. Режим сухой прогонки позволяет операторам моделировать влияние перед применением фактических тейнтов, повышая безопасность. Пример демонстрирует, как NRC обеспечивает функциональность агента CNI с пользовательским условием и тейнтом. Проект активно ищет отзывы сообщества и поощряет вклад через свои каналы GitHub, Slack и документации. NRC стремится усовершенствовать процесс готовности узлов и улучшить возможности планирования Kubernetes. На предстоящей KubeCon Europe 2026 будет организована сессия для сопровождающих, посвященная этой теме.
Introducing Node Readiness Controller kubernetes.io
RSS Hunter RSS Hunter • 3 февр.

Новое преобразование из cgroup v1 CPU Shares в v2 CPU Weight

Документ анонсирует улучшенную формулу преобразования для сопоставления долей ЦП из cgroup v1 с весом ЦП в cgroup v2. Исходная линейная формула имела две основные проблемы, ограничивающие производительность рабочих нагрузок Kubernetes. Первая проблема приводила к снижению приоритета ЦП для рабочих нагрузок Kubernetes по сравнению с процессами, не относящимися к Kubernetes, в cgroup v2. Вторая заключалась в отсутствии детализации для распределения ресурсов внутри контейнеров.Новый подход использует более сложную квадратичную формулу для решения этих проблем. Новая формула преобразования призвана обеспечить лучшее выравнивание приоритетов, особенно для контейнеров, запрашивающих один ЦП. Новая формула также обеспечивает улучшенную детализацию для распределения ресурсов внутри контейнеров, лучше поддерживая мелкозернистое распределение ресурсов ЦП.Это улучшение реализовано на уровне OCI, что означает, что оно зависит от среды выполнения OCI. Runc версии 1.3.2 и crun версии 1.23 и выше поддерживают новую формулу. Существующие развертывания, использующие инструменты или системы мониторинга, полагающиеся на старую линейную формулу, могут потребовать обновлений. Проект Kubernetes рекомендует протестировать обновленную формулу в непроизводственных средах, чтобы обеспечить совместимость. Пользователи могут найти более подробную информацию по предоставленным ссылкам. Группа специальных интересов Kubernetes Node приветствует новых участников для решения связанных задач.
New Conversion from cgroup v1 CPU Shares to v2 CPU Weight kubernetes.io
CdXz5zHNQW_JPSBeYnEfs.png
RSS Hunter RSS Hunter • 30 янв.

Ingress NGINX: Заявление от Руководящего комитета Kubernetes и Комитета по реагированию на угрозы безопасности

Комитет по управлению Kubernetes и Комитет по реагированию на угрозы безопасности объявили о прекращении поддержки Ingress NGINX, критически важного компонента инфраструктуры, используемого примерно половиной облачных сред, начиная с марта 2026 года. Проект уже много лет остро нуждается в участниках и сопровождающих, и, несмотря на публичные предупреждения, не получил необходимой поддержки. После прекращения поддержки больше не будет выпусков исправлений ошибок, патчей безопасности или обновлений, что сделает пользователей уязвимыми для атак, если они не перейдут на альтернативные решения. Комитет подчеркивает серьезность ситуации и важность немедленного начала миграции на альтернативы, такие как Gateway API или сторонние контроллеры Ingress. Решение остаться с Ingress NGINX после прекращения поддержки сделает пользователей уязвимыми для атак, и ни одна из доступных альтернатив не является прямой заменой, требующей планирования и инженерного времени. Существующие развертывания будут продолжать работать, но пользователи могут не знать, что они затронуты, пока не будут взломаны, и они могут проверить свою зависимость от Ingress NGINX, выполнив определенную команду с правами администратора кластера. Проект Ingress NGINX поддерживался всего одним или двумя людьми, работающими в свободное время, и, несмотря на его широкое использование, он не получил необходимых участников для безопасного сопровождения. Комитет принял решение о прекращении поддержки Ingress NGINX нелегко, но это необходимо для безопасности всех пользователей и экосистемы в целом из-за технического долга и фундаментальных проектных решений, которые усугубляют недостатки безопасности. Комитет настоятельно призывает пользователей проверить свои кластеры сейчас и начать планировать миграцию, если они зависят от Ingress NGINX, чтобы избежать серьезного риска. Прекращение поддержки Ingress NGINX — это значительное изменение, которое затрагивает большой процент пользователей Kubernetes, и крайне важно, чтобы пользователи приняли немедленные меры для решения этой проблемы.
Ingress NGINX: Statement from the Kubernetes Steering and Security Response Committees kubernetes.io
RSS Hunter RSS Hunter • 29 янв.

Эксперименты с Gateway API с использованием Kind

Этот документ представляет собой руководство по настройке локальной экспериментальной среды для изучения концепций Gateway API с использованием kind. Подчеркивается, что эта настройка не предназначена для использования в рабочей среде. Процесс включает в себя создание кластера Kubernetes kind и развертывание cloud-provider-kind, который предоставляет сервисы LoadBalancer и контроллер Gateway API. Затем пользователи создадут Gateway, развернут демонстрационное эхо-приложение и настроят HTTPRoute для направления трафика к этому приложению. Руководство включает шаги по тестированию конфигурации Gateway API и предоставляет советы по устранению неполадок для распространенных проблем. Наконец, в нем описывается процесс очистки для удаления всех созданных ресурсов и предлагаются следующие шаги для изучения готовых к производству реализаций и расширенных функций Gateway API. Эта локальная настройка специально разработана для понимания принципов Gateway API без производственных сложностей. Для этого требуется установка Docker, kubectl, kind и curl. Компонент cloud-provider-kind имитирует облачную среду, предоставляя необходимые контроллеры и CRD. Создание Gateway включает в себя определение GatewayClass и конфигураций слушателей, которые принимают определенные имена хостов и протоколы. Развертывание эхо-приложения включает в себя создание пространства имен, сервиса и развертывания. Настройка HTTPRoute связывает Gateway с эхо-приложением для определенного имени хоста. Тестирование включает в себя использование curl для отправки запроса на IP-адрес Gateway с определенным именем хоста. Для устранения неполадок рекомендуется проверка статусов ресурсов и журналов контроллера. Очистка включает в себя удаление пространств имен, остановку контейнера cloud-provider-kind и удаление кластера kind.
Experimenting with Gateway API using kind kubernetes.io
RSS Hunter RSS Hunter • 28 янв.

Cluster API v1.12: представляем обновления на месте и цепочные обновления

Cluster API обеспечивает декларативное управление жизненным циклом кластеров Kubernetes. Он использует контроллеры для согласования состояний кластеров, подобно тому, как Kubernetes управляет подами с помощью Deployments. Выпуск v1.12.0 вводит значительные улучшения, а именно обновления на месте и цепочечные обновления, для оптимизации распространенных операций. Обновления на месте позволяют изменять машины без полного их пересоздания, принимая принцип неизменной инфраструктуры для простоты и предсказуемости. Эта новая функция позволяет Cluster API интеллектуально выбирать между неизменными развертываниями и обновлениями на месте в зависимости от характера изменения. Cluster API считает обновления на месте наиболее полезными для изменений, не требующих слитья узлов, таких как обновления учетных данных. Цепочечные обновления, с другой стороны, позволяют пользователям сразу перейти на несколько минорных версий Kubernetes в одной операции. Эта функция вычисляет и выполняет план обновления, оркестрируя обновления контрольной плоскости и рабочих машин последовательно. Рабочие машины интеллектуально пропускают промежуточные версии, когда политики отклонения версий Kubernetes это разрешают. Расширяемость за счет расширений обновлений и расширений плана обновления во время выполнения обеспечивает гибкость. Cluster API продолжает развиваться, сосредотачиваясь на более безопасных обновлениях и снижении нарушений при управлении Kubernetes в крупном масштабе.
Cluster API v1.12: Introducing In-place Updates and Chained Upgrades kubernetes.io
RSS Hunter RSS Hunter • 27 янв.

Налобный фонарь в 2025 году: основные моменты проекта

Фарная фара значительно развилась в течение 2025 года, увеличив вовлеченность сообщества, охват платформы и интеграцию плагинов. Проект теперь официально является частью Kubernetes SIG UI, укрепляя свою роль в основном сообществе Kubernetes. Важным аспектом разработки Headlamp стало сотрудничество с участниками программы наставничества Linux Foundation, что привело к созданию нескольких ценных плагинов. Добавлены новые функции, такие как многокластерные представления и проекты, для оптимизации управления ресурсами и повышения эффективности устранения неполадок. Также были реализованы улучшенная навигация с моделью активности, улучшенный поиск и функциональность карты. OIDC и аутентификация теперь более надежны, особенно для развертываний внутри кластера. Каталог приложений и поддержка Helm были расширены. Приоритетом были производительность, доступность и пользовательский опыт, что привело к более быстрому времени загрузки и улучшениям. Headlamp также представила AI Assistant для упрощения управления Kubernetes. Экосистема плагинов была расширена, с улучшенными инструментами разработки плагинов и лучшими обновлениями безопасности. Также была создана страница плагинов, позволяющая упростить обнаружение плагинов.
Headlamp in 2025: Project Highlights kubernetes.io
RSS Hunter RSS Hunter • 22 янв.

Объявление рабочей группы по контрольно-пропускным пунктам/восстановлению

Сформирована новая рабочая группа (WG) Kubernetes, которая займется интеграцией функциональности контрольных точек/восстановления в Kubernetes. Эта инициатива направлена на изучение различных сценариев использования посредством обсуждения в сообществе. Эти сценарии включают оптимизацию использования ресурсов для интерактивных рабочих нагрузок, таких как Jupyter notebooks и AI-чатботы. Также рассматривается ускорение запуска приложений с длительным периодом инициализации. Кроме того, рабочая группа изучит отказоустойчивость для длительных задач посредством периодического создания контрольных точек. Важной областью является планирование с учетом прерываний, позволяющее вытеснять поды с более низким приоритетом, сохраняя при этом состояние приложения. Целью также является миграция подов между узлами для балансировки нагрузки и обслуживания без прерывания работы сервиса. Дополнительно рассматривается возможность создания контрольных точек для анализа инцидентов безопасности. Рабочая группа стремится наладить диалог между сообществом Kubernetes и экосистемой Checkpoint/Restore in Userspace (CRIU). Проекты, такие как CRIU, checkpointctl, criu-coordinator и checkpoint-restore-operator, имеют отношение к этим сценариям использования. Заинтересованные участники могут присоединяться к собраниям, участвовать в Slack или использовать список рассылки для взаимодействия с рабочей группой.
Announcing the Checkpoint/Restore Working Group kubernetes.io
RSS Hunter RSS Hunter • 21 янв.

Единый доступ к серверу API с помощью clientcmd

Текст описывает использование библиотеки clientcmd в Go для создания командных клиентов для Kubernetes API, имитирующих поведение kubectl. clientcmd обрабатывает загрузку конфигурации из различных источников, таких как ~/.kube/config и переменная окружения KUBECONFIG. Она позволяет переопределять конфигурации с помощью флагов командной строки, аналогично kubectl. Библиотека поддерживает такие функции, как выбор kubeconfig, выбор контекста и пространства имен, а также аутентификацию пользователя. Слияние конфигураций отдает приоритет первому определению в карте и последнему в не-карте. Использование включает в себя загрузку правил, настройку переопределений, построение и привязку флагов с помощью pflag, построение самой конфигурации и, наконец, получение клиента Kubernetes API. Пакет clientcmd предоставляет функции для этого процесса, включая те, которые позволяют устанавливать аргументы командной строки и получать выбранное пространство имен. Приведен полный пример, показывающий реализацию в коде. Пример демонстрирует, как анализировать аргументы командной строки с помощью флагов, настраивать клиент и взаимодействовать с Kubernetes API. Текст рекомендует проверять ошибки пустой конфигурации и корректно их обрабатывать.
Uniform API server access using clientcmd kubernetes.io
RSS Hunter RSS Hunter • 19 янв.

Kubernetes v1.35: Добавлен allowList для ограничения исполняемых файлов, вызываемых kubeconfig через плагин exec, в kuberc

Kubectl использует плагины учетных данных, исполняемые файлы, указанные в файлах kubeconfig, для аутентификации. Эта функция, хотя и полезна, вызывает опасения по поводу безопасности, поскольку эти плагины запускаются с привилегиями пользователя. Злоумышленник может использовать скомпрометированные конвейеры генерации kubeconfig для выполнения вредоносного кода. Kubernetes 1.35 представляет бета-функцию для управления этими плагинами с помощью политик плагинов учетных данных. Пользователи могут устанавливать политики в своих файлах конфигурации kuberc, чтобы контролировать, какие плагины могут запускаться. credentialPluginPolicy можно установить в значение AllowAll, DenyAll или Allowlist. Опция Allowlist разрешает определенные плагины, либо по полному пути, либо по базовому имени. Полные пути предпочтительны для повышения безопасности, исключая использование подстановок и шаблонов. Будущие улучшения включают проверку контрольной суммы и проверку цифровой подписи для повышения безопасности. Сообщество Kubernetes приветствует отзывы и вклад для дальнейшего улучшения этой функции безопасности. Пользователям рекомендуется участвовать в обсуждениях в каналах sig-cli и sig-auth. Это дополнение к безопасности предоставляет пользователям способ ограничить и контролировать выполнение плагинов учетных данных в их средах.
Kubernetes v1.35: Restricting executables invoked by kubeconfigs via exec plugin allowList added to kuberc kubernetes.io
RSS Hunter RSS Hunter • 9 янв.

Kubernetes v1.35: Изменяемая привязка узлов PersistentVolume (альфа)

Kubernetes v1.35 представляет изменяемую привязку узлов PersistentVolume (PV), позволяющую изменять доступность тома после его создания. Эта функция, ранее неизменяемая, облегчает онлайн-управление томами, учитывая развивающиеся возможности поставщиков хранилищ. Основная мотивация исходит из сценариев, таких как миграция дисков между регионами и обновление дисков, где меняется доступ к узлам. Например, миграция с зональных на региональные диски требует корректировки привязки узлов PV для отражения нового региона. Аналогично, обновление дисков может потребовать указания новых поколений узлов. При включении этой функции администраторы должны убедиться, что базовый том обновлен перед изменением привязки узлов PV. Может возникнуть состояние гонки при ужесточении привязки узлов, если планировщик не сразу отражает изменения. В настоящее время обсуждается возможность смягчения последствий, когда Kubelet не запускает Pod при нарушении привязки узлов. Цель состоит в том, чтобы интегрировать это с VolumeAttributesClass, позволяя автоматические обновления через PersistentVolumeClaim. Эта альфа-функция требует включения шлюза функций и соответствующих разрешений RBAC. Сообщество Kubernetes призывает пользователей и разработчиков драйверов CSI предоставить отзывы о ее реализации и удобстве использования. Это рассматривается как первый шаг к более гибкому и динамичному управлению томами.
Kubernetes v1.35: Mutable PersistentVolume Node Affinity (alpha) kubernetes.io
RSS Hunter RSS Hunter • 8 янв.

Kubernetes v1.35: Лучший способ передачи токенов учетных записей служб в драйверы CSI

Kubernetes v1.35 вводит функцию бета-тестирования - CSI Driver Opt-in для токенов учетной записи службы через поле Secrets. Ранее токены учетной записи службы для драйверов CSI передавались через поле volume_context, что не идеально для конфиденциальных данных и привело к случайному логированию токенов. Эта новая функция позволяет драйверам CSI получать эти токены через поле secrets в NodePublishVolumeRequest, предназначенное для конфиденциальной информации в спецификации CSI. Существующие драйверы CSI по умолчанию продолжат получать токены через volume_context, поскольку новое поле serviceAccountTokenInSecrets в спецификации CSIDriver по умолчанию равно false.Чтобы принять эту функцию, авторы драйверов CSI должны сначала реализовать логику обратной совместимости в коде драйвера. Эта логика проверяет как поле secrets, так и volume_context на наличие токенов, обеспечивая совместимость как с более старыми, так и с более новыми версиями Kubernetes. После развертывания этого обновленного драйвера кластер должен быть обновлен до Kubernetes v1.35 или позже, включая как kube-apiserver, так и kubelet. Как только кластер и драйвер обновлены, манифест CSIDriver можно обновить, чтобы установить serviceAccountTokenInSecrets: true.Очень важно следовать определенной последовательности развертывания, чтобы избежать поломки существующих томов. Обновление драйвера с логикой обратной совместимости должно быть развернуто и полностью внедрено до обновления объекта CSIDriver для включения нового поведения. Этот механизм опт-ин устраняет риск случайного логирования токенов, использует правильное поле спецификации CSI для конфиденциальных данных и управляется инструментом protosanitizer без необходимости специальных обходных путей. Авторам драйверов CSI рекомендуется принять эту функцию и предоставить обратную связь.
Kubernetes v1.35: A Better Way to Pass Service Account Tokens to CSI Drivers kubernetes.io
RSS Hunter RSS Hunter • 7 янв.

Kubernetes v1.35: Расширены операторы терпимости для поддержки числовых сравнений (Альфа)

Kubernetes v1.35 вводит расширенные операторы терпимости, добавляя операторы Gt (больше) и Lt (меньше) к терпимости для более гибкого планирования. Это улучшение позволяет выполнять размещение на основе пороговых значений, выходя за рамки точного совпадения пятен и терпимостей. Новые операторы позволяют подам указывать числовые пороги, такие как вероятность отказа или стоимость в час. Это позволяет выполнять размещение рабочей нагрузки на основе соглашений об уровне обслуживания, позволяя критически важным приложениям избегать узлов с высоким риском. Узлы помечаются числовыми значениями, а поды используют операторы Lt или Gt в своих терпимостях, чтобы выражать предпочтения. Этот подход предлагает ориентацию политики, удаление и эргономические преимущества над NodeAffinity для этих случаев использования. Примеры включают планирование отказоустойчивых заданий на экземплярах со скидкой при ограничении критически важных рабочих нагрузок. Рабочие нагрузки ИИ могут использовать уровни GPU на основе баллов вычислений. Также облегчается оптимизация затрат, позволяя пакетным заданиям предпочитать более дешевые узлы. Размещение на основе производительности также возможно, например, планирование подов на узлах с достаточным количеством операций ввода-вывода в секунду. Чтобы использовать эту функцию, необходимо включить ворота функции и пометить узлы числовыми значениями. Затем поды определяют терпимости, используя новые операторы, сопоставляя их с пятнами узлов. Эта альфа-функция, управляемая сообществом SIG Scheduling, все еще развивается. Будущие планы включают поддержку языка общих выражений (CEL) и улучшение интеграции с автоматическим масштабированием кластера.
Kubernetes v1.35: Extended Toleration Operators to Support Numeric Comparisons (Alpha) kubernetes.io
RSS Hunter RSS Hunter • 5 янв.