Сегодня официально выпустили новую версию Kubernetes — 1.34. Среди главных нововведений — отслеживание здоровья устройств при DRA, тонкая настройка рестарта контейнеров в подах, асинхронная обработка API-вызовов, нативная доставка сертификатов X.509 в поды и новая разновидность YAML для описания конфигураций.

Для подготовки статьи мы использовали информацию из блога Kubernetes, таблицы Kubernetes enhancements tracking, CHANGELOG-1.34, а также конкретные issues, pull requests и Kubernetes Enhancement Proposals (KEPs).

Мы разбили все изменения на следующие разделы:

• узлы;

• хранилище;

• сеть;

• API;

• аутентификация;

• CLI;

• планировщик;

• устаревшие и удалённые фичи.

Внутри каждого раздела упорядочили изменения по уровню их готовности к использованию. Всего в новом релизе 59 изменений. Из них:

• Alpha — 13 новых функций; 

• Beta — 23 продолжают улучшаться;

• Stable — 23 признаны стабильными.

Примечание

Мы сознательно не переводим названия фич на русский. Они в основном состоят из специальной терминологии, с которой инженеры чаще сталкиваются в оригинальной формулировке.

Узлы

Alpha-фичи

Add Resource Health Status to the Pod Status for Device Plugin and DRA 

#4680; KEP

Раньше в Kubernetes отсутствовал механизм для отслеживания состояния здоровья устройств, которые динамически выделяются подам через механизм Dynamic Resource Allocation (DRA). Это усложняло диагностику сбоев: было непонятно, вызвана ли проблема неисправностью самого устройства (например, GPU или FPGA) или ошибкой в приложении.

KEP добавляет новое поле resourceHealth в секцию status спецификации пода. Оно будет содержать информацию о здоровье используемых подом ресурсов. resourceHealth будет принимать одно из следующих значений: Healthy, Unhealthy или Unknown. 

Представьте, что вы запустили под с GPU. Из-за сбоя GPU под оказался в состоянии crash loop backoff. Теперь вы сможете просмотреть статус пода с помощью kubectl describe pod и убедиться, что устройство GPU нездорово. Другой вариант — контроллер увидит, что под нездоров, удалит его, а replicaSet перезапустит под на другом GPU.

Этот KEP выходит как альфа-2. В этой версии:

• плагины DRA получили возможность сообщать kubelet о здоровье устройств через новый gRPC-интерфейс (dra-health/v1alpha1);

• kubelet теперь постоянно отслеживает статусы. Если устройство выходит из строя, kubelet находит все поды, которые его используют;

• в статусе пода появилось новое поле allocatedResourcesStatus с актуальным состоянием выделенного подам оборудования. Это делает проблему видимой напрямую через API Kubernetes;

• дополнена документация.

Также доступен документ с подробностями реализации механизма отслеживания здоровья устройств при DRA.

Container restart rules to customize the pod restart policy 

#5307; KEP

Представьте, вы обучаете большую языковую модель (LLM) на сотнях подов, запущенных на дорогущих GPU. Они синхронно и пошагово обрабатывают данные, сохраняя общий прогресс в контрольных точках.

Вдруг один из контейнеров сталкивается с небольшой проблемой — временной, исправимой ошибкой, которую можно устранить простым перезапуском. Раньше Kubernetes (придерживаясь политики restartPolicy = Never, что часто используется для пакетных задач) помечал весь под как сбойный. После этого планировщик запускал дорогостоящий и трудоёмкий процесс: останавливал под и перезапускал его, скорее всего, уже на новом узле.

Тем временем остальные поды простаивали, сжигая ценное вычислительное время. Вся группа откатывалась к последней контрольной точке и ждала, пока единственный под вернётся в строй.

KEP-5307 даёт более тонкий контроль над перезапуском отдельных контейнеров в поде. Теперь Kubernetes сможет перезапускать контейнер «на месте», даже если у пода стоит restartPolicy = Never. Это особенно пригодится в ситуациях, когда пересоздание пода и его перенос на другой узел длятся долго и обходятся дорого.

В спецификацию контейнера добавилась новая секция restartPolicyRules со списком правил, которые описывают условия и действия. В альфа-версии доступны только одно условие — код завершения контейнера (onExitCodes) — и только одно действие — Restart (перезапуск). Пользователь может указать, например, что, если контейнер завершился с кодом 42, его нужно немедленно перезапустить (см. пример ниже). Если код завершения другой, будет применяться стандартная политика перезапуска, заданная для всего пода.

Пример

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx:latest
    # Чтобы задать restartPolicyRules, нужно указать restartPolicy.
    restartPolicy: Never
    restartPolicyRules:
    - action: Restart
      when:
        exitCodes:
          operator: In
          values: [42]

Следует отметить, что такой перезапуск контейнера не будет считаться сбоем пода и не повлияет на политики обработки сбоев, определённые на более высоком уровне контроллера, например в JobSet (то есть работающая задача не перейдёт в Failed). Следить за исполнением правил будет kubelet, оперативно реагируя непосредственно на узле, где запущен под. Кроме того, существующий механизм экспоненциальной задержки предотвратит бесконечные циклы перезапуска в случае повторяющихся сбоев.

Включить новую функциональность можно с помощью переключателя ContainerRestartRules.

Add FileEnvSource and FileKeySelector to add environment generated on the fly 

#3721; KEP

Существующий подход к доставке переменных окружения с помощью ConfigMap или Secret довольно трудоёмкий. Когда initContainer генерирует конфигурацию (скажем, временный токен доступа), её нужно передать основному контейнеру. Текущий подход требует создания дополнительного объекта ConfigMap или Secret через API-сервер.

KEP решает эту проблему, позволяя initContainer'у записывать переменные в файл в общем томе emptyDir, а основному контейнеру — считывать их оттуда напрямую при старте, без лишних вызовов к API.

В секцию env.valueFrom в API пода (PodSpec) добавляется новая структура fileKeyRef.

Пример

В примере ниже initContainer создаёт файл /data/config.env с переменной CONFIG_VAR=hello. Основной контейнер use-envfile использует fileKeyRef, чтобы прочитать значение ключа CONFIG_INIT из этого файла и установить его в свою переменную окружения CONFIG_VAR.

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  initContainers:
  - name: setup-envfile
    image: registry.k8s.io/busybox
    command: ['sh', '-c', 'echo "CONFIG_VAR=HELLO" > /data/config.env']
    volumeMounts:
    - name: config
      mountPath: /data
   containers:
  - name: use-envfile
    image: registry.k8s.io/distroless-app
    env:
    - name: CONFIG_VAR
      valueFrom:
        fileKeyRef:
          path: config.env
          volumeName: config
          key: CONFIG_VAR
  restartPolicy: Never
  volumes:
  - name: config
    emptyDir: {}

Примечания

• Установка значения одной переменной путём ссылки на другую (VAR1=${VAR2}) не поддерживается.

• Изменение файла, на который указывает fileKeyRef, после запуска контейнера не повлечёт за собой обновление переменных окружения внутри контейнера, а также не вызовет его перезапуск.

• В настоящее время авторы не планируют реализацию аналога envFrom для файлов. Все переменные нужно указывать явно по их именам (ключам).

Beta-фичи

Support User Namespaces in pods 

#127; KEP

KEP добавляет поддержку пользовательских пространств имён в stateless-подах. Идея в том, чтобы запускать процессы в подах с другими ID пользователя и ID группы, а не только с унаследованными с хоста. В этом случае привилегированный процесс в поде будет непривилегированным на хосте. Если такой процесс «вырвется» за пределы контейнера, потенциальный вред будет минимизирован, поскольку на хосте его привилегии будут ограничены. Подробнее — в обзоре Kubernetes 1.27.

KEP выходит как бета-2. В этой версии добавлены метрики для создания подов с использованием userns и ошибок, возникающих в процессе. Кроме того, при попытке использования volumeDevices совместно с пользовательскими пространствами имён теперь выдаётся ошибка, поскольку такая конфигурация неработоспособна. При этом сохраняется возможность модифицировать существующие объекты, в которых одновременно используются userns и volumeDevices. Дополнительно было обновлено название устаревшего теста и приведено в соответствие сообщение об ошибке validateHostUsers. Теперь, по аналогии с другими проверками, оно включает только имя поля, а не полный путь вроде pod.spec.field.

VolumeSource: OCI Artifact and/or Image

#4639; KEP

KEP добавляет в Kubernetes новый VolumeSource, поддерживающий OCI-образы и/или OCI-артефакты. Теперь пользователи смогут упаковывать файлы и шарить их в контейнерах пода, не включая в основной образ. Это позволит снизить уязвимости и упростит создание образов. Подробнее — в обзоре Kubernetes 1.31.

In-Place Update of Pod Resources

#1287; KEP

KEP позволяет обновлять запросы и лимиты пода «на месте», то есть без необходимости перезапускать под или его контейнеры. PodSpec теперь допускает изменение определённых ресурсов (то есть она сделана частично mutable). PodStatus также доработан — он предоставляет информацию о ресурсах, выделенных для пода, а также о фактических ресурсах, потребляемых подом и его контейнерами (подробнее).

Pod level resources

#2837; KEP

KEP вводит в спецификацию пода два новых поля: pod.spec.resources.requests и pod.spec.resources.limit. Они позволят задавать запросы и лимиты на уровне пода для нерасширяемых ресурсов (CPU, память и HugePages) в дополнение к существующим настройкам на уровне контейнеров. Подробнее — в обзоре Kubernetes 1.32.

В бета-версии появилась поддержка HPA. Теперь, принимая решения, горизонтальный автоскейлер будет отдавать предпочтение ресурсам на уровне пода, если используются метрики типа Resource и активирован переключатель функциональности PodLevelResources. Для метрик типа ContainerResource поведение не изменится — HPA, как и раньше, будет учитывать запросы и лимиты на уровне конкретных контейнеров.

Support PSI based on cgroupv2 

#4205; KEP

Механизм PSI (Pressure Stall Information) в ядре Linux измеряет, сколько времени задачи ждут доступа к ресурсам (CPU, память, ввод/вывод), даже если общая загрузка ресурсов не 100 %. Высокие значения PSI означают, что задачи тормозят из-за нехватки ресурсов, что напрямую влияет на производительность приложений. PSI позволяет получить более точную картину давления на ресурсы в отличие от классических метрик утилизации (usage %).

Иногда узел Kubernetes начинает тормозить из-за нехватки CPU, памяти или диска, но сам Kubernetes узнаёт об этом слишком поздно — после того как на узле начинаются проблемы (например, OOM Killer убивает процессы). Стандартные метрики загрузки не всегда показывают реальную картину потребления ресурсов. 

KEP реализует поддержку метрики PSI («давления»), которая показывает, как долго задачи ждут своей очереди для доступа к ресурсам. Если давление высокое, kubelet пометит узел как перегруженный. Планировщик увидит это и перестанет отправлять новые поды на этот узел, пока тот не «придёт в себя» (подробнее).

Windows Node Graceful Shutdown

#4802; KEP

KEP добавляет поддержку корректного завершения работы (graceful shutdown) подов на узлах Windows при выключении самого узла. Сейчас при выключении узла Windows поды просто убиваются без возможности подготовиться к завершению работы. Осведомлённость kubelet об отключении Windows-узла позволит инициировать процедуру корректного завершения работы подов с сохранением элементов жизненного цикла (типа хуков PreStop).

Pod Generation

#5067; KEP

KEP закрывает пробел в понимании, видел ли kubelet последнее изменение PodSpec. Разработчики воспользовались существующим полем metadata.generation. Теперь API-сервер будет устанавливать его значение в 1 (единицу) при создании пода и увеличивать на 1 (единицу) при каждом изменении в PodSpec. Кроме того, в PodStatus добавится новое целочисленное поле status.observedGeneration. Подробнее — в обзоре Kubernetes 1.33.

Split L3 Cache Topology Awareness in CPU Manager

#5109; KEP

KEP продолжает KEP 4800 (см. обзор Kubernetes 1.32), дополняя документацию, добавляя метрики для отслеживания распределения блоков кэша Uncore (он же L3), а также топологии процессоров с раздельным Uncore-кэшем и монолитным Uncore-кэшем для процессоров на базе x86 и ARM и др.

DRA: Extend PodResources to include resources from Dynamic Resource Allocation

#3695; KEP

KEP дополняет существующий сервис gRPC PodResources kubelet’а, включая повторяющееся поле DynamicResource в сообщение ContainerResources. Новое поле будет содержать информацию о классе DRA-ресурса, его ресурсных claim’ах и списке устройств CDI, распределённых драйвером DRA. Кроме того, к существующему сервису gRPC добавится метод Get(), с помощью которого можно будет опрашивать конкретные поды на предмет выделенных им ресурсов (подробнее).

Stable-фичи

AppArmor support

#24; Design proposal

В Kubernetes 1.4 появилась поддержка AppArmor. AppArmor — это модуль безопасности ядра Linux, который расширяет стандартный набор разрешений Linux, позволяя ограничивать доступ программ к ресурсам. AppArmor можно настроить для любого приложения. Для этого используются профили и белые списки — конкретная программа или контейнер получает, например, доступ к возможностям Linux, к сети и тому подобное. Профиль может быть запущен в жёстком режиме — в этом случае попытки доступа к запрещённым ресурсам блокируются — или в мягком режиме — тогда о нарушениях только сообщается.

Спустя долгих девять лет ожидания поддержка AppArmor в Kubernetes, наконец, становится GA.

Node memory swap support

#2400; KEP

KEP добавляет в Kubernetes поддержку свопинга памяти, позволяя более гибко управлять производительностью узлов и контейнеров: свопинг доступен на уровне хоста, узлов и конкретных рабочих нагрузок, а контролируется kubelet’ом. Подробнее — в обзоре Kubernetes 1.22.

Discover cgroup driver from CRI

#4033; KEP

KEP позволяет среде исполнения контейнеров указывать, какой драйвер cgroup использовать для kubelet. Теперь не нужно указывать драйвер cgroup в самой конфигурации kubelet. Это исключает возможность того, что настройки драйвера cgroup для kubelet и CRI будут отличаться.

DRA: structured parameters

#4381; KEP

KEP делает более прозрачными параметры запросов (claim) на ресурсы при динамическом распределении ресурсов (DRA). Вместо того чтобы самостоятельно обрабатывать семантику всех параметров запросов, драйверы теперь управляют ресурсами и описывают их с помощью определённой «структурированной модели». Это позволяет компонентам, осведомлённым об этой «структурированной модели», принимать решения о ресурсах, не передавая их сторонним контроллерам. Например, планировщик теперь может быстро размещать запросы на ресурсы, не обмениваясь данными с драйверами DRA. Подробнее — в обзоре Kubernetes 1.30.

Allow almost all printable ASCII characters in environment variables

#4369; KEP

KEP смягчает правила валидации имён env-переменных при проверке create-запросов к API. Теперь валидацию успешно проходят все ASCII-символы в диапазоне 32–126, кроме «=» (подробнее).

Introducing Sleep Action for PreStop Hook

#3960; KEP

KEP добавляет новое действие sleep для PreStop-хуков. Оно определяет, на какое время контейнер должен приостановиться перед завершением работы. Это упрощает корректное (graceful) завершение работы контейнерами и в целом делает управление их жизненным циклом более удобным. Также оно позволяет нормально закрывать клиентские соединения во время завершения работы пода. Подробнее — в обзоре Kubernetes 1.29.

Allow zero value for Sleep Action of PreStop Hook

#4818; KEP

KEP 3960 представил действие sleep для PreStop-хуков жизненного цикла контейнеров. Однако для него нельзя установить ноль (0) в качестве допустимого значения. Этот KEP исправляет ситуацию.

Хранилище

Beta-фичи

VolumeGroupSnapshot

#3476; KEP

KEP дополняет API Kubernetes, позволяя снимать согласованные снапшоты сразу с нескольких томов. Для этого вводятся новые CRD VolumeGroupSnapshot, VolumeGroupSnapshotContent и VolumeGroupSnapshotClass. Подробнее — в обзоре Kubernetes 1.27.

В этой версии K8s KEP выходит как бета-2: были обновлены/добавлены e2e-тесты и пополнена документация.

Mutable CSINode Allocatable Property

#4876; KEP

KEP делает поле CSINode.Spec.Drivers[*].Allocatable.Count изменяемым (mutable). Также добавляются механизмы динамического обновления его значения: kubelet может периодически посылать запросы на эндпойнт NodeGetInfo CSI-драйвера (интервал задаётся в новом поле CSIDriver.Spec.NodeAllocatableUpdatePeriodSeconds) или сразу реагировать на ошибки нехватки ресурсов (ResourceExhausted) при попытке подключения тома, обновляя значение в CSINode.

Stable-фичи

Support recovery from volume expansion failure

#1790; KEP

KEP позволяет отменить запрос на расширение ёмкости хранилища, если тот ещё не завершён или некорректен, и повторить его, указав меньший объём тома с помощью параметра pvc.Spec.Resources. Подробнее — в обзоре Kubernetes 1.23.

Kubernetes VolumeAttributesClass ModifyVolume

#3751; KEP

KEP дополняет API Kubernetes Persistent Volume, позволяя динамически управлять параметрами производительности тома (IOPS и пропускная способность). В API Kubernetes добавляются новый объект VolumeAttributesClass, новый admission-контроллер и контроллер защиты VAC. Подробнее — в обзоре Kubernetes 1.29.

Сеть

Alpha-фичи

Relaxed validation for Services names 

#5311; KEP

Сейчас имена сервисов в Kubernetes подчиняются более строгим правилам (RFC 1035), чем большинство других ресурсов Kubernetes (RFC 1123). KEP-5311 ослабляет правила валидации для имён объектов Service и приводит их в соответствие с правилами для большинства других ресурсов.

Включить новую фичу можно с помощью переключателя RelaxedServiceNameValidation (по умолчанию отключён). После его активации новые Service будут валидироваться по новому, менее строгому правилу (NameIsDNSLabel). Также после активации будут ослаблены правила валидации для поля, ссылающегося на сервис в Ingress-ресурсах (spec.rules[].http.paths[].backend.service.name).

Важно, что при обновлении существующих сервисов их имена не проверяются повторно, так как поле metadata.name неизменяемо. Это позволяет избежать проблем с уже созданными ресурсами, если вам по какой-то причине нужно отключить RelaxedServiceNameValidation.

Allows setting any FQDN as the pod's hostname 

#4762; KEP

KEP обеспечивает полный контроль над именем хоста внутри пода, позволяя устанавливать любое произвольное полное доменное имя (FQDN).

KEP добавляет новое поле hostnameOverride в podSpec. Если это поле заполнено, его значение будет использовано в качестве имени хоста пода, при этом текущие поля hostname, subdomain и setHostnameAsFQDN будут игнорироваться. Указанное FQDN будет прописано в файл /etc/hosts внутри контейнера, что позволит приложению самому узнавать его. Новое поведение можно активировать через переключатель функциональности HostnameOverride.

На что обратить внимание

Важно понимать, что эта функция изменяет только имя хоста внутри пода (то, что возвращают команды hostname и hostname -f). Она не создаёт соответствующих DNS-записей в кластерном DNS. Таким образом, другие поды не смогут разрешить это произвольное FQDN в IP-адрес пода без дополнительных настроек DNS.

Имя хоста не может превышать 64 символа, что является ограничением ядра Linux. Будет добавлена валидация на уровне API, чтобы предотвратить создание подов с более длинными именами.

Поле hostnameOverride нельзя использовать одновременно с setHostnameAsFQDN: true, так как их логика противоречит друг другу. API будет отклонять такие конфигурации с ошибкой, указывающей, что эти поля взаимоисключающие. Тем, кто хочет лучше прочувствовать логику того, как и при каких условиях будет работать новая фича, рекомендуем обратиться к таблице в разделе Design Details KEP’а.

Наконец, если для пода установлено hostNetwork: true, он, как и раньше, будет использовать имя хоста узла, на котором запущен; поле hostnameOverride будет проигнорировано.

Beta-фичи

PreferSameNode Traffic Distribution (formerly PreferLocal traffic policy / Node-level topology)

#3015; KEP

Раньше в Kubernetes была опция TrafficDistribution: PreferClose, которая должна была направлять трафик на близкие инстансы сервиса. Однако понятие «близкие» определялось неоднозначно — это мог быть тот же узел, та же зона доступности или что-то ещё.

KEP убирает неоднозначность: старое значение PreferClose переименовано в PreferSameZone — «предпочитать ту же зону доступности». Кроме того, появляется опция PreferSameNode, которая предписывает направлять трафик на тот же узел, если на нём есть копия целевого сервиса. Это очень полезно, например, для локальных DNS-кешей.

Stable-фичи

Relaxed DNS search string validation

#4427; KEP

KEP ослабляет правила валидации строк поиска DNS. В поле searches в dnsConfig можно будет указывать символы «_» и «.», в результате поды смогут правильно разрешать короткие имена в случаях, когда строка поиска содержит символ подчёркивания или точку. Подробнее — в обзоре Kubernetes 1.32.

API

Beta-фичи

Declarative Validation Of Kubernetes Native Types With validation-gen

#5073; KEP

KEP вводит механизм декларативной валидации для нативных API-типов Kubernetes, позволяя разработчикам определять правила проверки полей (например, минимальное значение, обязательность) с помощью специальных IDL-тегов прямо в файлах types.go. Новый инструмент validation-gen будет автоматически генерировать Go-код для валидации. Подробности и пример — в обзоре Kubernetes 1.33.

Allow informers for getting a stream of data instead of chunking

#3157; KEP

В некоторых случаях API-сервер Kubernetes страдает от взрывного роста потребления памяти. Эта проблема особенно очевидна в больших кластерах, где всего несколько LIST-запросов могут привести к серьёзным сбоям. Неконтролируемое и неограниченное потребление памяти серверами влияет не только на кластеры, работающие в режиме HA, но и на другие программы на узле.

KEP реализует запросы WATCH в качестве альтернативы запросам LIST. Чтобы снизить потребление памяти при получении списка данных и сделать его более предсказуемым, авторы предлагают использовать потоковую передачу из watch-cache вместо подкачки из etcd.

Mutating Admission Policies

#3962; KEP

KEP развивает идеи, заложенные в KEP-3488 (см. обзор K8s 1.30), и добавляет новый механизм для изменения (мутации) объектов перед их сохранением в etcd — Mutating Admission Policies, основанные на CEL (Common Expression Language). Они станут альтернативой Mutating Admission Webhooks, которые сейчас являются основным способом выполнения мутаций.

Snapshottable API server cache

#4988; KEP

KEP совершенствует кеширующий слой kube-apiserver, чтобы тот обслуживал все LIST-запросы из кеша. Также для гарантии корректности данных вводится механизм периодической проверки консистентности между кешем и etcd с использованием хеширования и публикацией результатов в виде метрик, которые будут указывать на неконсистентность. 

В бета-версии реализовано автоматическое переключение на etcd в случае обнаружения расхождений (активируется переключателем функциональности DetectCacheInconsistency); включено по умолчанию. Кроме того, введён механизм, благодаря которому каждый apiserver «подписывается» (watch) на события компактификации etcd, инициированные другими инстансами apiserver. Если apiserver видит, что была проведена компактификация, он запускает аналогичный процесс в своём локальном кеше (watch cache), чтобы привести своё состояние в соответствие с состоянием etcd.

Stable-фичи

Consistent Reads from Cache

#2340; KEP

KEP предлагает механизм, который позволяет удовлетворять большинство запросов на чтение с помощью watch-кеша и при этом обеспечивает те же гарантии согласованности, что и при получении данных из etcd.

Streaming Encoding for LIST Responses

#5116; KEP

KEP решает проблему высокого потребления памяти API-сервером при обработке LIST-запросов, особенно для больших CustomResourceDefinitions (CRDs), реализуя «потоковое кодирование» (streaming encoding) конкретно для ответов на LIST-запросы («коллекций»). Вместо загрузки всего списка API-сервер будет кодировать и отправлять каждый элемент списка по отдельности. Это радикально снизит требования к памяти для одного запроса и сделает её потребление более предсказуемым.

Ordered namespace deletion

#5080; KEP

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

KEP вводит механизм приоритетного удаления ресурсов в пространстве имён на основе логических зависимостей и соображений безопасности (например, поды удаляются раньше NetworkPolicies).

Resilient Watchcache Initialization

#4568; KEP

Есть ряд проблем, которые могут привести к значительной перегрузке kube-apiserver и etcd (или — в худшем случае — даже к его падению) во время инициализации или реинициализации слоя watchcache.

KEP описывает существующие проблемы и предлагает пути их решения/смягчения, чтобы избежать перебоев в работе управляющего слоя.

Аутентификация

Pod Certificates 

#4317; KEP

KEP-4317 позволяет нативно доставлять сертификаты X.509 в рабочие нагрузки кластера. Проблема была в том, что, хотя API certificates.k8s.io и даёт гибкий способ запрашивать сертификаты, их доставкой и управлением внутри подов приходилось заниматься разработчикам и администраторам.

Новый API-ресурс PodCertificateRequest (упрощённая версия CertificateSigningRequest) даёт поду возможность напрямую запросить сертификат у конкретного издателя, включив в запрос всю информацию о себе. Также в рамках KEP добавили новый источник для проецируемых томов (projected volumes) — PodCertificate. С этим томом, примонтированным в под, kubelet может осуществлять весь жизненный цикл управления учётными данными: генерировать приватный ключ, создавать PodCertificateRequest, дожидаться выпуска сертификата и монтировать ключ вместе с цепочкой сертификатов в файловую систему пода.

Основной вариант использования этого механизма — аутентификация подов в kube-apiserver с помощью mTLS (более безопасная альтернатива токенам сервисных аккаунтов). Новое расширение X.509, названное PodIdentity, встраивает в сертификат информацию о поде: его UID, пространство имён и хост, на котором он запущен. Kube-apiserver, в свою очередь, распознаёт и проверяет такие сертификаты, сопоставляя их с конкретными подами.

Для разработчиков использование этой фичи сводится к простому добавлению источника podCertificate и signerName (например, нового встроенного kubernetes.io/kube-apiserver-client-pod) в спецификацию пода — см. пример ниже.

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: pod-certificates-example
spec:
  restartPolicy: OnFailure
  automountServiceAccountToken: false   # Отключаем bearer-токены.
  containers:
  - name: main
    image: debian
    command: ['sleep', 'infinity']
    volumeMounts:
    - name: kube-apiserver-client-certificate
      mountPath: /var/run/secrets/kubernetes.io/serviceaccount
  volumes:
  - name: kube-apiserver-client-certificate
    projected:
      sources:
      - podCertificate:    # Новый источник.
          signerName: "kubernetes.io/kube-apiserver-client-pod"
          credentialBundlePath: credentialbundle.pem   # Файл с сертификатом.
      - configMap:
          localObjectReference: kube-root-ca.crt
          items:
          - key: ca.crt
            path: kube-apiserver-root-certificate.pem
      - downwardAPI:
          items:
          - path: namespace
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace

Add PSA to block setting .host field from ProbeHandler and LifecycleHandler 

#4940; KEP

Поле Host в структурах ProbeHandler и LifecycleHandler позволяет пользователям указывать собственный хост для TCP- и HTTP-проб, что создаёт риск SSRF-атак (Server-Side Request Forgery), так как kubelet можно заставить отправить запрос на любой IP-адрес.

Новый KEP добавляет политику Pod Security Admission (PSA), которая даёт администраторам кластера возможность запретить создание подов, использующих поле Host. Эта новая политика станет частью базового профиля безопасности Baseline по умолчанию, что упростит её внедрение. При этом полностью удалять поле Host из API не планируется из соображений обратной совместимости Kubernetes.

Beta-фичи

API for external signing of Service Account tokens

#740; KEP

Для аутентификации сервисных аккаунтов используются ключи. Сейчас за их хранение и управление ими отвечает Kubernetes. KEP 740 позволяет внешним специализированным системам, например HSMs и облачным KMS, делать то же самое.

Подробнее — в обзоре Kubernetes 1.32.

ClusterTrustBundles (previously Trust Anchor Sets)

#3257; KEP

KEP реализует объект certificates.k8s.io ClusterTrustBundle для использования в пределах кластера. Он позволяет удостоверяющим центрам доставлять сертификаты до рабочих нагрузок.

Projected service account tokens for Kubelet image credential providers

#4412; KEP

KEP расширяет существующий механизм kubelet credential provider. Это специальные плагины, через которые kubelet может получать учётные данные для доступа к репозиториям. В настройках kubelet (CredentialProvider) появляется новое поле TokenAttributes. В нём в секции ServiceAccountTokenAudience указывается целевая аудитория для учётных данных, а в ServiceAccountAnnotationKeys перечисляются ключи аннотаций, которые будут извлечены и переданы плагину как часть CredentialProviderRequest. Подробнее — в обзоре Kubernetes 1.33.

DRA: AdminAccess for ResourceClaims and ResourceClaimTemplates

#5018; KEP

KEP позволяет администраторам кластера помечать запрос в ResourceClaim или ResourceClaimTemplate флагом доступа администратора. Этот флаг разрешает привилегированный доступ к устройствам и позволяет выполнять административные задачи без ущерба для безопасности. Доступ есть только у пользователей, которые уполномочены создавать объекты ResourceClaim или ResourceClaimTemplate в пространствах имён, помеченных флагом доступа администратора, то есть пользователи, не являющиеся администраторами, не смогут злоупотребить этой функцией (см. обзор Kubernetes 1.33).

Stable-фичи

Structured Authentication Config

#3331; KEP

KEP от «Фланта» реализует структурированную конфигурацию для аутентификации, которая обладает рядом весомых преимуществ по сравнению с традиционным подходом. Он поддерживает любые JWT-совместимые токены, динамическое изменение конфигурации, одновременную работу с несколькими провайдерами аутентификации и Common Expression Language. Подробнее о KEP — в заметке.

Authorize with Field and Label Selectors

#4601; KEP

KEP предлагает новый механизм авторизации в Kubernetes на базе селекторов для управления доступом к ресурсам.

Запросы List, Watch и DeleteCollection смогут использовать селекторы полей и лейблов для более точной фильтрации ресурсов, которые возвращаются в ответ на запрос. Подробнее — в обзоре Kubernetes 1.31.

Only allow anonymous auth for configured endpoints.

#4633; KEP

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

CLI

Alpha-фичи

KYAML 

#5295; KEP

YAML достаточно легко читается, но при этом обладает рядом недостатков. Например, отбивка пробелами означает, что пользователям приходится внимательно следить за нестингом. Кроме того, в YAML кавычки вокруг строк, как правило, необязательны, при этом некоторые строковые элементы принудительно преобразуются в другие типы. Например, без кавычек NO, no, N, YES, yes, Y, On и Off обрабатываются как bool, 42, 4_2_ обрабатываются как числа, при этом строка вида 1:22:33 также переводится в Base-60-число. Это удобно, когда нужно подсчитать количество секунд. Проблема в том, что авторы забыли указать максимальное количество таких шестидесятичных разрядов, поэтому если вы введёте, например, шесть чисел, разделённых двоеточиями, как в MAC-адресе, то они будут восприняты как очень большой промежуток времени вместо строки.

Данный KEP вводит новый формат YAML — KYAML (Kubernetes YAML), который решает вышеупомянутые проблемы следующим образом:

• Все строки всегда заключаются в кавычки, чтобы избежать случайного преобразования типов (например, «no» не будет преобразовано в false).

• Явно используется flow-style-синтаксис: [] для lists и {} для maps.

• Снижена чувствительность к пробелам и отступам.

В долгосрочной перспективе предлагается сделать KYAML стандартным форматом для всей документации и примеров в проекте Kubernetes. Это должно подтолкнуть экосистему к использованию более безопасных и устойчивых к ошибкам практик при работе с конфигурациями.

$ kubectl get -o kyaml svc hostnames
---
{
  apiVersion: "v1",
  kind: "Service",
  metadata: {
    creationTimestamp: "2025-05-09T21:14:40Z",
    labels: {
      app: "hostnames",
    },
    name: "hostnames",
    namespace: "default",
    resourceVersion: "37697",
    uid: "7aad616c-1686-4231-b32e-5ec68a738bba",
  },
  spec: {
    clusterIP: "10.0.162.160",
    clusterIPs: [
      "10.0.162.160",
    ],
    internalTrafficPolicy: "Cluster",
    ipFamilies: [
      "IPv4",
    ],
    ipFamilyPolicy: "SingleStack",
    ports: [{
      port: 80,
      protocol: "TCP",
      targetPort: 9376,
    }],
    selector: {
      app: "hostnames",
    },
    sessionAffinity: "None",
    type: "ClusterIP",
  },
  status: {
    loadBalancer: {},
  },
}

Beta-фичи

Separate kubectl user preferences from cluster configs

#3104; KEP

KEP вводит новый опциональный конфигурационный файл kuberc для хранения пользовательских настроек утилиты kubectl, отделяя их от данных для подключения к кластерам, которые остаются в kubeconfig. Это позволяет избежать перезаписи настроек при смене kubeconfig. Теперь пользовательские настройки будут применяться независимо от значения флага --kubeconfig или переменной окружения $KUBECONFIG.

Планировщик

Alpha-фичи

Asynchronous API calls during scheduling 

#5229; KEP

Производительность планировщика Kubernetes критически важна. Одним из узких мест являются вызовы API к kube-apiserver, которые выполняются синхронно. Другими словами, планировщик ожидает завершения вызова, прежде чем продолжить работу, что замедляет весь процесс, особенно в больших кластерах. Некоторые операции, такие как привязка (binding) подов, уже асинхронны, однако единый унифицированный механизм для всех вызовов API пока отсутствует.

KEP вводит новый универсальный механизм для асинхронной обработки всех API-вызовов. Для этого создаётся специальный компонент, который будет управлять очередью и выполнением этих вызовов.

Таким образом, больше не нужно будет ждать завершения API-вызовов. Кроме того, появится возможность пропускать или объединять некоторые вызовы. Например, если под сначала помечается как unschedulable, а затем почти сразу успешно привязывается к узлу, вызов для обновления статуса на unschedulable можно отменить, так как он уже неактуален.

Это дизайн, на котором остановили свой выбор авторы, представляет собой гибридный подход, сочетающий новую очередь вызовов и использование кеша в качестве посредника (см. также альтернативные дизайны). Отдельный компонент APIQueue будет управлять очередью всех асинхронных вызовов API. 

Вместо того чтобы напрямую отправлять вызовы в APIQueue, плагины и внутренние циклы планировщика будут взаимодействовать с кешем планировщика. При выполнении API-операций (например, при обновлении статуса пода) те сначала будут регистрироваться в кеше, из которого соответствующие вызовы будут поступать в APIQueue.

APIQueue будет выполнять вызовы в фоновом режиме и при этом не блокировать основной поток планирования. Таким образом под, например, снова может встать в очередь на планирование, даже если его статус unschedulable ещё не достиг API. Кроме того, APIQueue сможет выполнять слияния операций или отменять их, например объединять два последовательных обновления статуса для одного и того же пода в один API-вызов.

Включить новую функциональность можно с помощью переключателя SchedulerAsyncAPICalls.

Use NominatedNodeName to express the expected pod placement 

#5278; KEP

Привязка (binding) подов может занимать продолжительное время (иногда даже минуты). В течение всего этого времени компоненты кластера ничего не знают о том, на какой именно узел планируется под. Без этой информации они могут предпринять конфликтующие действия. Например, компонент автомасштабирования кластера (Cluster Autoscaler) может удалить целевой узел. Кроме того, сам планировщик за это время может быть перезапущен и т. п. Если учесть, что решения о планировании хранятся только в памяти планировщика, его новая реинкарнация ничего не будет знать о прошлых решениях и может запланировать под на другой узел. Это приведет к пустой трате ресурсов и увеличению задержек.

KEP превращает поле NominatedNodeName из узкоспециализированного индикатора приоритизации (preemption) в двусторонний канал коммуникации между планировщиком и другими компонентами кластера, чем значительно расширяет его функциональность в спецификации пода. Основная цель — сделать процесс размещения подов более предсказуемым и эффективным.

Теперь не только планировщик сможет сообщать о своих намерениях, но и внешние компоненты, такие как Cluster Autoscaler или Karpenter, смогут влиять на его решения.

Планировщик теперь будет устанавливать NominatedNodeName в начале цикла привязки пода, но только в тех случаях, когда для пода требуются длительные операции на этапах Permit или PreBind (например, подготовка томов). Для определения необходимости установки поля в интерфейс PreBind-плагинов ввели новую легковесную функцию PreBindPreFlight. Если все эти функции в плагинах возвратят статус Skip, планировщик не будет устанавливать поле NominatedNodeName.

С другой стороны, внешние компоненты теперь могут официально использовать NominatedNodeName для передачи «подсказок» планировщику. Например, компонент автомасштабирования кластера при создании нового узла для ожидающих подов может заранее указать NominatedNodeName для этих подов. Планировщик, получив заказ на размещёние такого пода, в первую очередь проверит возможность его запуска на указанном узле.

Ключевым изменением в поведении является то, что планировщик больше не будет очищать поле NominatedNodeName, если указанный в нём узел временно недоступен или не соответствует требованиям (например, ещё не готов после создания). Это предотвращает сброс полезной информации от компонента автомасштабирования кластера. Ответственность за обновление или очистку этого поля теперь ложится на тот компонент, который его установил.

Наконец, для предотвращения путаницы и обеспечения чистоты данных kube-apiserver после успешного размещения пода будет автоматически очищать поле NominatedNodeName в момент выполнения binding request. Таким образом, это поле будет содержать информацию только о намерениях по размещению, а не о его финальном результате.

DRA: Handle extended resource requests via DRA Driver 

#5004; KEP

KEP-5004 перебрасывает мост между привычными расширенными ресурсами (Extended Resources) и новым, более гибким фреймворком Dynamic Resource Allocation, DRA. Его главная цель — сделать переход на DRA плавным и безболезненным. Нововведение обеспечивает полную обратную совместимость для существующих приложений, что позволяет разработчикам и администраторам постепенно внедрять DRA без необходимости немедленно переписывать все манифесты. Кроме того, теперь можно запускать гибридные кластеры, где для одного и того же оборудования на одних узлах используются старые device-плагины, а на других — новые DRA-драйверы.

Администратор кластера теперь может указать в спецификации DeviceClass новое поле extendedResourceName через присвоение ему имени знакомого расширенного ресурса, например example.com/gpu. Так Kubernetes поймёт, что запросы на данный ресурс могут быть удовлетворены с помощью устройств, управляемых через DRA.

Если пользователь запросит такой ресурс в спецификации пода, планировщик Kubernetes самостоятельно создаст специальный объект ResourceClaim для внутреннего отслеживания выделенных ресурсов, чем избавит пользователя от необходимости создавать его вручную.

Чтобы kubelet на узле знал, какому именно контейнеру передать выделенное устройство, планировщик запишет необходимую информацию в новое поле pod.status.extendedResourceClaimStatus. Этот статус содержит имя автоматически созданного ResourceClaim и, что более важно, точную карту соответствия, которая связывает конкретный контейнер и его запрос с выделенным ему устройством. С помощью этих данных kubelet сконфигурирует и запустит контейнер с нужными ресурсами.

На что обратить внимание

Поскольку устройство можно запросить и через ResourceClaim, и как расширенный ресурс, администратор кластера должен создать две квоты с одинаковым лимитом на один класс устройств, чтобы квотирование работало эффективно.

Например, если нужно разрешить десять устройств example.com/gpu в конкретном пространстве имён, он должен создать следующее:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: gpu
spec:
  hard:
    requests.example.com/gpu: 10
    gpu.example.com.deviceclass.resource.k8s.io/devices: 10

Это работает при условии, что DeviceClass с именем gpu.example.com связан с расширенным ресурсом example.com/gpu:

apiVersion: resource.k8s.io/v1beta1
kind: DeviceClass
metadata:
  name: gpu.example.com
spec:
  extendedResourceName: example.com/gpu

Контроллер ResourceQuota согласовывает различия (если они появляются) между использованием этих двух квот и гарантирует, что их значения всегда совпадают. Для этого контроллеру нужно разрешение на просмотр списка DeviceClass в кластере, чтобы установить связь между классом устройств и расширенным ресурсом.

DRA: Device Binding Conditions 

#5007; KEP

Стандартный планировщик Kubernetes предполагает, что все ресурсы на узле доступны в момент привязки пода. Однако это не всегда справедливо для таких устройств, как GPU с подключением через коммутируемую матрицу (fabric-attached), которым нужно динамическое присоединение по PCIe или CXL, и FPGA, требующих затратного по времени перепрограммирования перед использованием. Преждевременная привязка пода к узлу до того, как такое устройство будет полностью готово, приводит к сбоям при запуске пода и требует ручного вмешательства.

Новая фича BindingConditions решает эту проблему, чем позволяет планировщику откладывать финальную привязку пода (фаза PreBind) до тех пор, пока внешний контроллер не подтвердит готовность необходимого ресурса. Это делает процесс планирования более предсказуемым и надёжным.

Механизм работает следующим образом: провайдер устройства через API ResourceSlice определяет набор условий BindingConditions, которые должны получить статус True для успешной привязки. Также могут быть заданы BindingFailureConditions, которые при срабатывании, наоборот, отменяют привязку. Чтобы избежать бесконечного ожидания, вводится BindingTimeoutSeconds — таймаут, по истечении которого, если устройство не готово, попытка привязки отменяется, а под возвращается в очередь на перепланирование.

Внешний контроллер, управляющий устройством, отвечает за обновление статусов этих условий в объекте ResourceClaim, чем сигнализирует планировщику о прогрессе подготовки. Таким образом, планировщик принимает решение о привязке, основываясь на актуальной информации о готовности, без тесной интеграции с логикой конкретного устройства.

Если подготовка устройства завершается неудачей, контроллер устанавливает одно из BindingFailureConditions в True. Планировщик обнаруживает это, отменяет привязку, освобождает выделенный ресурс и отправляет под на повторное планирование, в идеале уже на другой узел или с другим ресурсом.

На что обратить внимание:

• На одно устройство можно назначить максимум по четыре условия BindingConditions и BindingFailureConditions. Это нужно, чтобы планировщик не тормозил при их проверке и ResourceSlice не разрастался до гигантских размеров.

• Чтобы планирование работало надёжно, внешние контроллеры должны своевременно и правильно обновлять BindingConditions. Любые задержки или ошибки с их стороны напрямую скажутся на стабильности планирования.

DRA: Consumable Capacity 

#5075; KEP

Ранее можно было совместно использовать устройства только в том случае, если несколько подов или контейнеров ссылались на один и тот же ResourceClaim, который уже выделил это устройство. KEP 5075 даёт возможность независимым запросам ResourceClaim претендовать на доли одного и того же устройства. Теперь никак не связанные поды (даже из разных пространств имён) могут использовать ресурсы совместно.

Новый механизм позволяет устройству объявлять, что оно допускает множественное распределение. Для этого служит поле allowMultipleAllocations в разделе devices ResourceSlice. Кроме того, пользователи теперь могут запросить определённую «ёмкость» от такого делимого устройства с помощью нового поля CapacityRequests в ResourceClaim. На основе этих запросов и политики совместного использования устройства планировщик Kubernetes точно рассчитает фактически потребляемую ёмкость, которая может быть округлена до ближайшего допустимого значения согласно политике устройства. Результат этого выделения, включая фактическую потребленную ёмкость, будет отражён в поле ConsumedCapacities в статусе выделенного ресурса (DeviceRequestAllocationResult), а для уникальной идентификации каждой доли будет присвоен ShareID.

kind: ResourceSlice
...
spec:
  driver: guaranteed-cni.dra.networking.x-k8s.io
  devices:
  - name: eth1
    basic:
      allowMultipleAllocations: true   # Ключевое поле из нового KEP'а. Сообщает планировщику, что устройство eth1 можно разделить между несколькими независимыми ResourceClaim'ами.
      attributes:
        name:
          string: "eth1"
      capacity:
        bandwidth:
          sharingPolicy:   # Определяет политику распределения ресурсов (пропускной способности).
            default: "1Mi"
            validRange:
              minimum: "1Mi"
              chunkSize: "8"
          value: "10Gi"

Beta-фичи

Respect PodTopologySpread after rolling upgrades

#3243; KEP

KEP решает проблему с несбалансированным распределением подов при плавающих обновлениях Deployment’а.

В TopologySpreadConstraint вводится новое поле MatchLabelKeys в качестве дополнения к существующему labelSelector. В новом поле передаётся набор ключей для лейблов подов — их планировщик учитывает при распределении.

Фича позволяет применять ограничения PodTopologySpread только в границах новой ревизии Depolyment’а, а не во всех ревизиях. Подробнее — в обзоре Kubernetes 1.25.

DRA: Prioritized Alternatives in Device Requests

#4816; KEP

KEP 4831 «Динамическое распределение ресурсов с помощью структурированных параметров» (см. обзор Kubernetes 1.30) позволил запрашивать специфические типы ресурсов с помощью ResourceClaim. Однако текущая реализация API не позволяет пользователю задавать приоритеты, если потребностям рабочей нагрузки удовлетворяют несколько типов или конфигураций устройств. KEP 4816 решает эту проблему: теперь можно указать несколько вариантов запросов на динамические ресурсы (например, разные типы GPU) в виде упорядоченного списка. Планировщик попытается удовлетворить эти запросы по очереди, начиная с самого предпочтительного. Подробнее — в обзоре Kubernetes 1.33.

Stable-фичи

Per-plugin callback functions for accurate requeueing in kube-scheduler

#4247; KEP

KEP базируется на KEP 3063 (см. обзор Kubernetes 1.26) и добавляет в планировщик функцию QueueingHint, которая позволяет получать от плагинов предложения о том, как повторно ставить поды в очередь. Это сократит число бесполезных повторных попыток и повысит эффективность планировщика. Попытка планирования будет осуществляться, только если высока вероятность её успеха.

Decouple TaintManager from NodeLifecycleController

#3902; KEP

NodeLifecycleController навешивает на нездоровые узлы, которые не готовы или без связи, taint’ы NoExecute, например Unreachable, NotReady. После этого TaintManager приступает к удалению работающих на этих узлах подов.

KEP отделяет TaintManager, который вытесняет (evict) поды на основе taint’ов, от NodeLifecycleController и превращает их в два отдельных контроллера:

• NodeLifecycleController будет навешивать taint’ы на нездоровые узлы; 

• TaintEvictionController будет удалять поды на узлах с NoExecute.

Такое разделение не только улучшает организацию кода, но и облегчает работу над контроллером TaintEvictionController или создание собственных eviction-реализаций на основе taint’ов.

Разное

Stable-фичи

Kubelet OpenTelemetry Tracing

#2831; KEP

При возникновении проблем на узле (например, при задержках при запуске пода) сложно отследить, на каком именно этапе произошёл сбой: при взаимодействии apiserver с kubelet, kubelet с CRI или где-либо ещё. Трассировка позволяет получить детальную картину всего жизненного цикла запроса, проходящего через разные компоненты. KEP добавляет в kubelet возможность трассировки gRPC- и HTTP-запросов. Подробнее — в обзоре Kubernetes 1.25.

Allow for recreation of pods once fully terminated in the job controller

#3939; KEP

KEP вводит новое поле в API Job, которое определяет, будут ли поды на замену стартовать сразу после того, как старые поды переходят в Terminating (обычное поведение), или только после полного завершения их работы (новое поведение). Кроме того, ещё одно новое поле — Status.terminating — поможет отследить количество подов со статусом Terminating. Подробнее — в обзоре Kubernetes 1.28.

Support for Direct Service Return (DSR) and overlay networking in Windows kube-proxy 

#5100; KEP

KEP формализует поддержку DSR (Direct Server Return) и оверлей-сетей для Windows-узлов. Обе эти фичи появились в Kubernetes 1.14, поэтому KEP носит ретроактивный характер — он документирует и позволяет закрепить stable-статус за функциональностью, которая появилась некоторое время назад и уже доказала свою работоспособность.

API Server tracing

#647; KEP

KEP расширяет возможности трассировки API-сервера с помощью стандарта распределённого трейсинга и мониторинга OpenTelemetry. Коллектор OpenTelemetry умеет собирать метрики и трейсы из множества источников и транслировать их в нужный пользователю формат: Prometheus, Jaeger, VictoriaMetrics и т. д.

Устаревшие или удалённые фичи

Ручная настройка драйвера cgroup

Раньше настройкой правильного драйвера cgroup приходилось заниматься администраторам кластера. В Kubernetes 1.28 kubelet получил возможность запрашивать у CRI-реализации, какой драйвер cgroup использовать (KEP-4033). Теперь такое автоматическое определение настоятельно рекомендуется, а в версии 1.34 его поддержка стала стабильной. Если среда исполнения контейнеров в вашем кластере не умеет сообщать, какой драйвер cgroup ей нужен, её следует обновить или сменить.

Параметр cgroupDriver в конфигурационном файле kubelet теперь считается устаревшим (deprecated). Флаг командной строки --cgroup-driver устарел ещё раньше, поскольку Kubernetes рекомендует проводить настройку через конфигурационный файл. Оба способа будут удалены, но это произойдёт не раньше релиза v1.36.

Прекращение поддержки containerd 1.x в 1.36

Kubernetes 1.34 всё ещё поддерживает containerd 1.7 и другие LTS-релизы. Однако из-за перехода на автоматическое определение драйвера cgroup сообщество SIG Node официально утвердило финальные сроки поддержки линейки containerd v1.x. Последним релизом Kubernetes с её поддержкой станет v1.36. Если вы используете containerd 1.x, задумайтесь о скором переходе на 2.0+. Определить, есть ли в кластере узлы с версией containerd, которая скоро устареет, можно с помощью метрики kubelet_cri_losing_support.

Устарела политика распределения трафика PreferClose

Поле spec.trafficDistribution Kubernetes позволяет указать предпочитаемый способ распределения трафика эндпойнтами сервиса. KEP-3015 объявляет PreferClose устаревшим и вводит два новых значения: PreferSameZone и PreferSameNode. PreferSameZone — это, по сути, синоним для PreferClose, созданный, чтобы сделать его назначение более понятным. PreferSameNode позволяет по возможности направлять трафик на эндпойнт, расположенный на том же узле. Если локальный эндпойнт недоступен, трафик будет перенаправлен на удалённый. Эта возможность появилась в v1.33 (была скрыта за переключателем функциональности PreferSameTrafficDistribution), а в v1.34 перешла в бету и включена по умолчанию.

P. S.

Читайте также в нашем блоге:

• Kubernetes 1.33: упорядоченное удаление ресурсов, изменение алгоритма CrashLoopBackOff и декларативная валидация

• Kubernetes 1.32: возможность задавать ресурсы на уровне пода и асинхронное вытеснение подов планировщиком

• Kubernetes 1.31: новый VolumeSource, эмуляция старых версий и настройка анонимного доступа к эндпойнтам

• Kubernetes 1.30: структурированные параметры для DRA, рекурсивное монтирование read-only-томов и другие фичи