TheNote
Kubernetes Blog на русском Заметка
GooglePlay AppStore

Kubernetes Blog на русском

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

Трэд заметок

Kubernetes v1.37: Advancing Workload-Aware Scheduling

Kubernetes v1.37 знаменует собой важную веху для планирования с учетом нагрузки, улучшая поддержку сложных пакетных и AI/ML рабочих нагрузок. Основные API Workload и PodGroup, необходимые для пакетного планирования, перешли в стадию Beta. Этот релиз представляет API CompositePodGroup для управления иерархическими требованиями к планированию для гетерогенных групп Pod. Новые API интеграции контроллеров и библиотека Go workloadbuilder упрощают интеграцию внешних контроллеров с функциями планирования с учетом нагрузки. Нативный контроллер Job теперь полностью использует эти расширенные API для продвинутых политик планирования и учета топологии. Пакетное планирование и API Workload/PodGroup стали более надежными благодаря переходу в стадию Beta и обновленному версионированию. Очередь PodGroup была улучшена, что сделало PodGroup полноправными участниками очереди планирования. Поле minCount для PodGroup теперь изменяемо, что позволяет динамически настраивать эластичные рабочие нагрузки. Прерывание с учетом нагрузки теперь интегрировано в функцию GenericWorkload и учитывает режимы прерывания PodGroup. API CompositePodGroup позволяет осуществлять многоуровневое планирование с учетом топологии, обеспечивая сложные ограничения совместного размещения на различных уровнях инфраструктуры.
Kubernetes v1.37: Advancing Workload-Aware Scheduling kubernetes.io
RSS Hunter RSS Hunter • Вчера

Kubernetes v1.37: KubeletInUserNamespace (он же режим без root) переходит в бета-версию

Kubernetes v1.37 продвигает KubeletInUserNamespace в бета-версию, позволяя компонентам узлов, таким как Kubelet и runtime, работать как некорневые пользователи. Этот rootless-режим, развивший эксперимент 2018 года, повышает безопасность, ограничивая потенциальные уязвимости контейнера. В отличие от под-пространств имён, этот режим сосредоточен на компонентах узлов хоста. Эта функция снижает риски уязвимостей, таких как CVE-2022-0811 и CVE-2023-27561, которые исторически могли предоставлять злоумышленникам корневые права. Работая в пользовательском пространстве имён, злоумышленник ограничивается учетной записью пользователя, не относящегося к корневому пользователю, препятствуя модификации ядра или прошивки. Пользовательские пространства имён сами по себе не защищают от уязвимостей ядра и должны сочетаться с другими мерами ужесточения, такими как seccomp. Эта функция имеет различные сценарии, включая производственные кластеры, общие машины, ноутбуки и песочницы ИИ. Он работает путём отображения пользователя хоста, не входящего в root, на фальшивый корень внутри пространства имён, что достаточно для большинства задач компонентов узлов. Пользовательское пространство имён должно быть создано внешне, например, с помощью Rootless Docker. Функция KubeletInUserNamespace, теперь включенная по умолчанию, позволяет Kubelet игнорировать определённые ошибки разрешения. Недавние улучшения включают лучшую поддержку idmapped tmpf, пользовательских подов с пространственными именами и записываемых cgroups, что позволяет внедрять вложенные Kubernetes. Инструменты, такие как kind, minikube, Usernetes и k3s, предлагают простые способы создания rootless кластеров Kubernetes. Проект планирует в будущем перейти эту функцию к статусу General Availability и приветствует участие сообщества.
Kubernetes v1.37: KubeletInUserNamespace (aka Rootless mode) Graduates to Beta kubernetes.io
RSS Hunter RSS Hunter • 4 сент.

Kubernetes v1.37: обновления DRA

Kubernetes 1.37 представляет значительные усовершенствования для динамического выделения ресурсов (DRA), при этом поддержка расширенных ресурсов достигла общего доступа. Это позволяет драйверам DRA управлять традиционными расширенными ресурсами без отдельных плагинов устройств. ResourceClaims теперь включают поле devices в своем статусе, обеспечивая лучшую видимость состояний устройств, таких как имена сетевых интерфейсов и IP-адреса. Taints и tolerations устройств DRA теперь стабильны, отражая taints узлов для управления доступностью и обслуживанием устройств. Стандартизированный атрибут устройства numaNode обеспечивает единообразное именование между различными драйверами.Поддержка рабочих нагрузок ResourceClaim перешла в бета-версию, позволяя использовать один claim несколькими Pod'ами, преодолевая предыдущие ограничения. DRA Device Attributes Downward API, теперь в бета-версии, облегчает внедрение атрибутов устройств непосредственно в рабочие нагрузки, упрощая пользовательские контроллеры. Альфа-функции включают списковые типы для атрибутов, позволяя более сложное сопоставление устройств, и запросы ресурсов, выделяемых узлом, для предотвращения чрезмерного выделения ресурсов узла.Видимость доступности ресурсов находится во второй альфа-версии, предлагая снимки состояния в определенный момент времени. Необязательные операции узлов DRA позволяют драйверам пропускать ненужные вызовы настройки узла. Производные атрибуты, новая альфа-функция, используют выражения CEL для гибкого сопоставления устройств на основе пользовательских правил. Группы совместимости устройств DRA предотвращают планирование несовместимых комбинаций устройств.Расширение PreQueueingHint, также в альфа-версии, оптимизирует планирование pod'ов, сокращая область сканирования при масштабировании. DRA Consumable Capacity теперь поддерживает дробные значения, повышая точность выделения ресурсов. Эти постоянные разработки подчеркивают приверженность Kubernetes улучшению возможностей управления ресурсами.
Kubernetes v1.37: DRA Updates kubernetes.io
RSS Hunter RSS Hunter • 3 сент.

Kubernetes v1.37: Масштабируйте рабочие нагрузки до нуля с помощью HorizontalPodAutoscaler

Kubernetes v1.37 теперь предлагает бета-поддержку API для масштабирования рабочих нагрузок до нуля реплик, по умолчанию. Это позволяет HorizontalPodAutoscaler сокращать неиспользуемые ресурсы до нуля, а затем масштабироваться обратно при необходимости. Ранее эта функциональность требовала внешних дополнений или альфа-флагов функций. Масштабирование до нуля особенно выгодно для таких рабочих нагрузок, как потребители очередей, где экономия ресурсов может быть значительной, особенно при использовании дорогостоящего выделенного оборудования.Основным компромиссом является увеличение времени холодного старта, поскольку системе необходимо наблюдать за метриками, планировать pod и запускать приложение. Этот подход наиболее эффективен, когда работа может быть временно удержана в долговечной очереди. В отличие от метрик CPU или памяти, которые перестают существовать при исчезновении pod, объектные и внешние метрики сохраняются независимо. Это позволяет HorizontalPodAutoscaler продолжать отслеживать метрики, такие как длина очереди, даже когда рабочие pod не запущены.Для масштабирования с нуля необходим адаптер внешних метрик, такой как Prometheus Adapter, для предоставления метрик, таких как отставание потребителя очереди, в Kubernetes. Затем HorizontalPodAutoscaler настраивается с минимальным количеством реплик, равным нулю, и нацеливается на внешнюю метрику для управления масштабированием. Специальное условие состояния ScaledToZero отличает автоматическое масштабирование вниз от ручной паузы, гарантируя, что HorizontalPodAutoscaler может возобновить управление. Эта функция, ранее находившаяся в альфа-версии, перешла в бета-версию в v1.37 и включена по умолчанию для повышения эффективности использования ресурсов.
Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscaler kubernetes.io
RSS Hunter RSS Hunter • 2 сент.

Kubernetes v1.37: etcd RangeStream сокращает использование памяти при чтении больших списков

etcd RangeStream переходит в бета-версию в Kubernetes v1.37, работая с etcd v3.7. Эта функция значительно снижает потребление памяти API-сервером и etcd при чтении больших коллекций ресурсов. Ранее заполнение кэша наблюдения API-сервера включало дорогостоящее полное чтение из etcd. Хотя пагинация существовала, она основывалась на количестве ключей, а не на размере объектов, что приводило к непредсказуемым скачкам потребления памяти и возможным ошибкам Out-Of-Memory. Унитарный RPC Range в etcd собирал целые страницы перед отправкой, усугубляя нагрузку на память как etcd, так и API-сервера.Новый RPC RangeStream в etcd v3.7 решает эту проблему, передавая результаты по частям. Размер части адаптивно настраивается в зависимости от размеров значений, ограничивая чтение по байтам, а не по количеству ключей. Это позволяет постепенно освобождать память по мере продвижения потока. Когда включен флаг функции EtcdRangeStream, API-сервер использует RangeStream как для инициализации кэша наблюдения, так и для резервных запросов списка. Он декодирует и освобождает части по мере их поступления, предотвращая одновременное хранение всей коллекции в памяти. Эта функция требует Kubernetes v1.37+ и etcd v3.7+. API-сервер автоматически определяет поддержку etcd и переключается на резервный вариант, если RangeStream не реализован. Чтобы убедиться, что RangeStream активен, отслеживайте метрику etcd_request_duration_seconds_count{operation="listStream"} на наличие ненулевых значений.
Kubernetes v1.37: etcd RangeStream Cuts Memory Use on Large List Reads kubernetes.io
RSS Hunter RSS Hunter • 1 сент.

Kubernetes v1.37: Миграция версий хранения включена по умолчанию

Миграция версий хранения (SVM) достигла общего доступа в Kubernetes v1.37 и теперь включена по умолчанию. Эта функция решает проблему обновления версии хранения ресурсов API Kubernetes. Ресурсы хранятся с использованием определенного представления схемы, и изменения в этом представлении требуют перезаписи существующих объектов. Распространенным сценарием использования является продвижение пользовательского определения ресурсов (CRD) к более новым версиям API при одновременной отмене устаревших. Без SVM удаление старых версий было небезопасным, если ресурсы все еще использовали их для хранения. Аналогично, шифрование в состоянии покоя или ротация ключей требовали перезаписи хранимых данных для применения нового шифрования. Ранее это требовало ручного написания скриптов или использования внешних инструментов, которые были подвержены ошибкам и сложны в управлении. SVM упрощает это, вводя декларативный объект API StorageVersionMigration. Встроенный контроллер отслеживает эти объекты и автоматически мигрирует ресурсы к указанной версии хранения по умолчанию. Инициирование миграции включает создание объекта StorageVersionMigration, который затем обрабатывается контроллером. Статус миграции можно отслеживать, а успешное завершение означает, что все ресурсы обновлены. Авторы CRD теперь могут включать манифесты миграции непосредственно с обновлениями CRD для оптимизации процесса.
Kubernetes v1.37: Storage Version Migration Enabled by Default kubernetes.io
RSS Hunter RSS Hunter • 31 авг.

Kubernetes v1.37: Сертификаты Pod'ов и доверенные пакеты кластера

Kubernetes представил сертификаты подов и пакеты доверия кластера как новый механизм идентификации для производственных сред. Эта функция, теперь общедоступная, интегрирует выдачу сертификатов X.509 для TLS и mTLS непосредственно в ядро Kubernetes. Это значительный шаг вперед по сравнению с предыдущим основным механизмом — JWT учетных записей служб. В то время как JWT предлагают простоту использования и широкую совместимость, они страдают от критического недостатка: это токены-носители, что делает их уязвимыми для несанкционированного доступа в случае компрометации. Сертификаты подов, с другой стороны, используют учетные данные с подтверждением владения, основанные на асимметричной криптографии, в первую очередь сертификатах X.509. Это повышает безопасность, требуя демонстрации владения, а не простого обмена самой учетной записью.Цель состоит в том, чтобы сделать использование сертификатов X.509 из рабочих нагрузок Kubernetes таким же простым, как и JWT, при сохранении высоких стандартов безопасности. Сертификаты подов разработаны с учетом гибкости, позволяя использовать различные типы сертификатов в одном кластере через подключаемый интерфейс. Это контрастирует с единым, стандартизированным форматом JWT учетных записей служб. Ожидается, что будущие версии Kubernetes предложат встроенные поставщики сертификатов для DNS-имен служб и клиентских сертификатов SPIFFE.Архитектура включает в себя приложение, запрашивающее сертификаты, Kubelet, выдающий запросы и управляющий пакетами доверия, и контроллер подписи, выполняющий эти запросы и публикующий пакеты доверия. Процесс выдачи является хронологическим, начиная с планирования пода и заканчивая доступом приложения к своим ключам и сертификатам. Автоматическое обновление встроено, и приложениям необходимо обрабатывать эти обновления. Проверки безопасности интегрированы в kube-apiserver для обеспечения изоляции и предотвращения получения необоснованного доступа скомпрометированными узлами. Чтобы поэкспериментировать с этими функциями, пользователям необходимо установить сторонний подписант, такой как Tinycert, который предоставляет примеры подписантов и библиотеку для помощи приложениям в загрузке сертификатов SPIFFE.
Kubernetes v1.37: Pod Certificates and Cluster Trust Bundles kubernetes.io
RSS Hunter RSS Hunter • 28 авг.

Kubernetes v1.37: Metrics API переходят к стабильному

Kubernetes v1.37 перевел API metrics.k8s.io в стабильную версию v1. Этот API предоставляет важные данные об использовании ЦП и памяти для узлов и подов. Он лежит в основе таких критически важных функций, как kubectl top и автомасштабирование на основе метрик ресурсов. Для операторов кластеров и разработчиков этот переход означает гарантированную стабильность API. API v1 сохраняет те же типы ресурсов и поля, что и его предшественник v1beta1. API метрик ресурсов, представленный как альфа-версия в v1.6, стал бета-версией в v1.8 и надежно используется в производстве в течение многих лет. API предоставляет NodeMetrics для использования ресурсов узла и PodMetrics для использования ресурсов пода, включая разбивку по контейнерам. Он намеренно предлагает только метрики, необходимые для автомасштабирования и базового анализа, а не полноценное решение для мониторинга. Поверхность API v1 идентична v1beta1, за исключением самой версии API. В то время как kubectl top поддерживает обе версии, отдавая предпочтение v1, контроллер Horizontal Pod Autoscaler в настоящее время поддерживает только v1beta1. Никакие функциональные ворота не должны быть включены, так как API предоставляется через агрегацию API реализациями, такими как metrics-server. Чтобы сделать v1 доступным, реализации должны предоставлять его и иметь зарегистрированный соответствующий APIService. Во время этого перехода реализации должны продолжать предоставлять как v1, так и v1beta1 для обратной совместимости.
Kubernetes v1.37: Metrics API graduates to stable kubernetes.io
RSS Hunter RSS Hunter • 27 авг.

Kubernetes v1.37: Garhwal

Выпущена Kubernetes v1.37 под названием Garhwal с 67 улучшениями. Шестнадцать функций перешли в стабильную версию, 23 — в бета-версию, а 27 — в альфа-версию. Тема релиза символизирует взаимосвязь вклада сообщества. Ключевым обновлением в стабильной версии является инициализация кэша отслеживания с повышенной отказоустойчивостью, улучшающая запуск и восстановление API-сервера за счет предотвращения перегрузки etcd. Поддержка масштабирования до нуля для Horizontal Pod Autoscaler, теперь в бета-версии, позволяет снижать нагрузку при простое для сокращения расходов, за исключением метрик ЦП и памяти. Конфигурация управления доступом на основе манифестов также переходит в бета-версию, позволяя загружать политики и вебхуки с диска. В альфа-версии представлены контрольные точки и восстановление на уровне Pod, расширяющие CRI новыми RPC для сред выполнения контейнеров. Среди заметных переходов в стабильную версию — KYAML для более безопасных подмножеств YAML и API metrics.k8s.io для использования ресурсов. Флаги SELinuxMount и SELinuxChangePolicy теперь стабильны и включены по умолчанию для томов. Несколько функций распределения ресурсов устройств (DRA) достигли стабильной версии, включая статус ResourceClaim для конфигурации устройств, обработку запросов расширенных ресурсов, метки и допуски устройств, а также стандартизированный атрибут устройства узла NUMA. Функции, объявленные узлом, — фреймворк для объявления возможностей узла с контролем доступа по функциям — также переходят в стабильную версию.
Kubernetes v1.37: Garhwal kubernetes.io
RSS Hunter RSS Hunter • 26 авг.

Как красиво отформатировать ваш Kubernetes YAML с помощью KYAML и зачем это нужно

KYAML предлагает более строгий и последовательный способ написания манифестов Kubernetes, устраняя проблемы, присущие стандартному YAML. Разработанный как подмножество YAML, KYAML сохраняет совместимость с существующими парсерами, одновременно сужая стилистические возможности. Он призван предотвратить распространенные ловушки, такие как чувствительность к пробелам и неявное приведение типов, которые могут привести к неожиданному поведению. В отличие от стандартного YAML, KYAML явно определяет структуру и типы, используя фигурные скобки для словарей и квадратные скобки для списков. Он требует заключения строковых значений в кавычки, чтобы избежать неявного преобразования типов, такого как "Норвежская ошибка", когда "NO" интерпретируется как логическое значение false. KYAML также поддерживает комментарии и завершающие запятые, улучшая процесс написания конфигураций по сравнению с JSON. Kubernetes 1.34+ позволяет генерировать вывод KYAML с помощью kubectl -o kyaml. Такие инструменты, как sigs.k8s.io/yamlfmt и google/yamlfmt, могут преобразовывать существующие файлы YAML в формат KYAML. Принятие KYAML — это выбор в пользу большей согласованности и меньшего количества ошибок, особенно в командной среде, без необходимости внесения изменений в существующие инструменты или конвейеры Kubernetes. Это новая привычка для написания более надежных конфигураций, а не обязательная миграция.
How to Pretty-Print Your Kubernetes YAML as KYAML and Why You'd Want To kubernetes.io
RSS Hunter RSS Hunter • 11 авг.

Gateway API v1.6: TCPRoute и UDPRoute переходят в стандартный статус

Kubernetes Gateway API выпустил версию 1.6.0, расширив свои возможности для сетевого взаимодействия сервисов. Этот новый релиз знаменует собой значительный прогресс за счет стандартизации маршрутизации протоколов уровня 4. Ранее стабильная основа Gateway API предназначалась в основном для HTTP и TLS трафика. Версия 1.6.0 теперь включает ресурсы TCPRoute и UDPRoute в стабильный API версии 1. Эти ресурсы позволяют маршрутизировать необработанный TCP и UDP трафик, устраняя пробел для таких рабочих нагрузок, как базы данных и телеметрия IoT. Экспериментальные инновации также оптимизируются за счет более четких границ API. Новые экспериментальные ресурсы теперь находятся в отдельной группе API, gateway.networking.x-k8s.io, и используют префикс 'X'. Это различие облегчает идентификацию экспериментальных и стандартных ресурсов. Например, ресурс XBackend является новым экспериментальным дополнением, обеспечивающим расширенные конфигурации бэкенда. Он позволяет использовать такие назначения, как ExternalHostname, которые ранее вызывали проблемы для стабильного ресурса Service. Эта экспериментальная функция предназначена для таких сценариев использования, как исходящий трафик к облачным API. Переход маршрутизации TCP и UDP в стандартный формат укрепляет Gateway API как универсальное сетевое решение. Пользователи теперь могут использовать версию 1.6.0 с различными совместимыми реализациями контроллеров Gateway. Сообщество Gateway API приветствует отзывы и вклад от пользователей и разработчиков.
Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard kubernetes.io
RSS Hunter RSS Hunter • 3 авг.

Kubernetes v1.37: Первое знакомство

Релиз Kubernetes v1.37 приближается с несколькими запланированными изменениями. Флаг --filename/-f для kubectl run будет объявлен устаревшим. Статические поды больше не смогут напрямую ссылаться на Secrets или ConfigMaps из-за исправления ошибки. Поддержка режима IPVS для Kube-proxy будет объявлена устаревшей и удалена к v1.43. Поддержка cgroup v1 постепенно прекращается, и пользователям следует перейти на cgroup v2. Перемаркировка томов SELinux, известная как SELinuxMount, переходит в стадию общего доступа (General Availability). API metrics.k8s.io также переходит в стадию общего доступа после почти девяти лет в бета-версии. Ожидается, что Kubelet в User Namespace, или Rootless Mode, перейдет в бета-версию. Функция мониторинга работоспособности томов будет вновь представлена в альфа-версии с новыми RPC CSI. Эти изменения направлены на улучшение обслуживания и работоспособности сред Kubernetes.
Kubernetes v1.37 Sneak Peek kubernetes.io
RSS Hunter RSS Hunter • 31 июл.

Как кэш controller-runtime на самом деле работает, и почему ваш контроллер не обрушивает API-сервер

Контроллеры Kubernetes, обычно написанные на Go с использованием kubebuilder и controller-runtime, обеспечивают эффективную разработку распределенных рабочих нагрузок. Однако по мере увеличения нагрузки понимание внутреннего устройства controller-runtime становится критически важным для предотвращения производственных проблем. Основная концепция заключается в том, что r.Get() и r.List() в реконсилере не обращаются напрямую к API-серверу; вместо этого они получают доступ к локальному кэшу в памяти. Этот кэш изначально заполняется операцией списка, а затем поддерживается с помощью отслеживания (watches).Такая конструкция делает локальные чтения исключительно быстрыми, избегая нагрузки на управляющий узел. Однако компромиссом является то, что локальный кэш может потреблять значительный объем памяти и возвращать устаревшие данные. Записи, напротив, всегда направляются на API-сервер, минуя кэш. Размер этого локального кэша и стратегии индексирования напрямую влияют на использование памяти. Неэффективная операция List() может непреднамеренно привести к медленному линейному сканированию большого количества объектов.Цикл реконсиляции непрерывно сравнивает желаемые состояния с фактическими, чтобы привести их в соответствие. События ставятся в очередь, что приводит к функции реконсиляции, которая считывает текущее состояние, определяет необходимые действия и потенциально генерирует новые события. Основная цель кэша — обеспечить быстрое и актуальное представление состояний объектов для этих циклов реконсиляции. Эта модель отслеживания, унаследованная от client-go, предотвращает постоянное опрашивание API, поддерживая одно долгоживущее соединение для обновлений.controller-runtime абстрагирует сложности низкоуровневых компонентов client-go, таких как Reflector, DeltaFIFO и Indexer. Менеджер (Manager) оркестрирует общий кэш, контроллеры и другие службы. Информатор (Informer) отслеживает определенный GVK, поддерживая локальное хранилище (Indexer) и отправляя события подписчикам. ResourceEventHandlers обрабатывают эти события, обновляя хранилище, которое затем отражается в представлении контроллера. Очередь задач (workqueue) управляет ключами объектов для обработки рабочими, а предикаты (Predicates) фильтруют события перед постановкой в очередь.Reflector является единственным компонентом, напрямую взаимодействующим с API-сервером, выполняя первоначальный список, а затем устанавливая отслеживание. Он использует resourceVersion для возобновления отслеживания и обеспечения того, чтобы ни одно событие не было пропущено. Если соединение отслеживания теряется или API-сервер указывает устаревший resourceVersion, выполняется повторный список (relist). DeltaFIFO действует как упорядоченный буфер для изменений, группируя дельты по ключу объекта. Он предоставляет все накопленные изменения для объекта с момента последнего вызова Pop(), обеспечивая упорядоченную пакетную обработку. Однако он не сворачивает последовательные события "Добавлено" или "Обновлено", что может привести к нескольким раундам обработки для быстро меняющихся объектов.
How the controller-runtime Cache Actually Works, and Why Your Controller Does Not Crash the API Server kubernetes.io
RSS Hunter RSS Hunter • 29 июл.

Создание пользовательского экспортера метрик для Kubernetes

Kubernetes масштабируется на основе ЦП и памяти, но реальные потребности часто требуют пользовательских метрик, таких как глубина очереди или активные соединения. Экспортер метрик Prometheus заполняет этот пробел, предоставляя состояние приложения в виде обычного текста в конечной точке HTTP /metrics для сбора Prometheus.Экспортеры могут быть автономными службами или встраиваться непосредственно в приложение, в зависимости от источника данных и контроля над кодом приложения. Prometheus ожидает метрики в определенных форматах: счетчики для постоянно увеличивающихся значений, датчики для колеблющихся значений и гистограммы для распределений. Имена метрик должны следовать четкому соглашению " __ " snake_case. Создание экспортера на Go включает инициализацию модуля, настройку библиотеки клиента Prometheus и регистрацию метрик, таких как счетчики, датчики и гистограммы. Затем эти метрики обновляются циклом опроса, который считывает данные из источников данных вашего приложения. HTTP-сервер предоставляет конечную точку /metrics, а также конечную точку /healthz для проверок работоспособности. Экспортер упаковывается в минимальный образ контейнера с использованием многоступенчатой сборки Docker, обеспечивая небольшой размер. Развертывание в кластере Kubernetes включает Deployment для управления подами и Service для предоставления стабильного адреса для Prometheus. Prometheus обнаруживает эти метрики через ServiceMonitor при использовании Prometheus Operator или через обнаружение на основе аннотаций в шаблоне Pod. Проверка включает проверку страницы целей Prometheus, чтобы убедиться, что экспортер находится в состоянии "UP", и запрос метрик в браузере выражений. Эта основа позволяет использовать автоматическое масштабирование с помощью HorizontalPodAutoscaler, который использует адаптер метрик (например, Prometheus Adapter) для интеграции пользовательских метрик с Kubernetes Custom Metrics API. Это позволяет рабочим нагрузкам масштабироваться на основе бизнес-значимых сигналов, а не только базового использования ресурсов.
Building a Custom Metrics Exporter for Kubernetes kubernetes.io
RSS Hunter RSS Hunter • 14 июл.

Эксплуатация рабочих нагрузок ИИ/МО на Kubernetes: плагин Headlamp для Kubeflow

Kubernetes все чаще становится стандартной платформой для рабочих нагрузок в области искусственного интеллекта и машинного обучения. Kubeflow — популярный инструмент, который использует пользовательские определения ресурсов (CRD) Kubernetes для управления этими задачами машинного обучения. Хотя специализированные панели управления Kubeflow помогают специалистам по данным, они часто скрывают базовый уровень Kubernetes, заставляя операторов использовать kubectl для устранения неполадок. Плагин Headlamp Kubeflow устраняет этот разрыв, отображая пользовательские ресурсы Kubeflow непосредственно в универсальном пользовательском интерфейсе Kubernetes. Это позволяет операторам наблюдать и управлять ресурсами машинного обучения, используя те же примитивы, что и другие компоненты кластера. Сам Headlamp — это расширяемый веб-интерфейс Kubernetes, поддерживаемый в рамках Kubernetes SIG UI. Плагин предоставляет информацию на уровне кластера, напрямую запрашивая API-сервер Kubernetes, предлагая подробные сведения о состояниях Pod, причинах сбоев и состояниях ресурсов в различных пространствах имен. Он поддерживает различные компоненты Kubeflow, такие как Notebooks, Pipelines, Katib для настройки гиперпараметров, Training и Spark. Плагин позволяет просматривать сведения о Pod ноутбуков, состояния проб Katib и состояния конвейеров без обращения к базе данных бэкенда Kubeflow. Он также отображает ресурсы машинного обучения в виде узлов графа в Headlamp, визуализируя взаимосвязи между ними. Этот подход демонстрирует шаблон для любой платформы с большим количеством CRD, позволяющий операторам получать необходимую видимость на уровне кластера непосредственно в их привычных инструментах.
Operating AI/ML Workloads on Kubernetes: A Headlamp Plugin for Kubeflow kubernetes.io
RSS Hunter RSS Hunter • 13 июл.

Kubernetes от приборной панели до фары: пошаговое руководство

Kubernetes Dashboard и Headlamp предоставляют видимость кластера, но работают по-разному. Headlamp — это клиент для рабочего стола или внутри кластера, который использует kubeconfig для подключения к нескольким кластерам, учитывая идентификацию пользователя. Kubernetes Dashboard — это веб-приложение внутри кластера, обычно доступное через аутентификацию по токену. Для миграции задокументируйте текущее использование Dashboard, проверьте работоспособность kubeconfig и выберите план развертывания, например, параллельное развертывание. Решите, будет ли Headlamp работать на вашем рабочем столе или внутри кластера; настольный вариант быстрее для индивидуального использования, а внутрикластерный лучше подходит для общего доступа. Установка на рабочий стол проста через менеджеры пакетов, в то время как установка внутри кластера использует Helm или YAML-манифесты. Аутентификация для настольного Headlamp зависит от kubeconfig, тогда как внутрикластерные настройки часто используют OpenID Connect (OIDC) или внешний слой аутентификации для входа. Headlamp уважает разрешения RBAC, что означает, что пользователи видят и могут выполнять только те действия, на которые они уполномочены. Headlamp превосходно справляется с управлением несколькими кластерами, позволяя пользователям переключаться между кластерами непосредственно в пользовательском интерфейсе, используя свой kubeconfig. Это обеспечивает более интегрированный опыт по сравнению с фокусировкой Kubernetes Dashboard на одном кластере.
Kubernetes Dashboard to Headlamp: A Step-by-Step Guide kubernetes.io
RSS Hunter RSS Hunter • 13 июл.

Анонсируем 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 мар.