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

Сегодня официально выпустили новую версию Kubernetes — 1.30. Среди главных нововведений — структурированные параметры для DRA, рекурсивное монтирование read-only-томов, синхронизация статусов задач сторонними контроллерами, более гибкие критерии успешности индексированных задач, обновлённое управление маршрутизацией трафика.

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

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

• Узлы

• Приложения

• Хранилище

• Сеть

• API

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

• CLI

• Планировщик

• Разное

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

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

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

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

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

Примечание

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

Узлы

Alpha-фичи

Allow almost all printable ASCII characters in environment variables

#4369; KEP

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

Переходить от строгой валидации к смягчённой можно с помощью переключателя функциональности RelaxedEnvironmentVariableValidation (по умолчанию false):

• Строгая валидация. Разрешены только имена envvar, удовлетворяющие регулярному выражению [-._a-zA-Z][-._a-zA-Z0-9]*.

Смягчённая валидация. В имени envvar можно использовать все символы ASCII в диапазоне 32–126, удовлетворяющие регулярному выражению ^[ -<>-~]+$ (то есть символы ASCII от пробела до < и от > до ~, исключая =, длиной не менее одного символа).

Мотивация

Kubernetes не должен налагать ограничения на именование переменных окружения, поскольку заранее невозможно узнать, что может понадобиться приложению. При этом пользователи не всегда могут выбирать имена переменных по своему вкусу.

Например, в случае .Net Core-приложений параметры приложения при загрузке из файла appsettings.json разбиваются символом «:»:

"Logging": { "IncludeScopes": false, "LogLevel": { "Default": "Warning" } }

При запуске в контейнерах эти параметры обычно превращаются в переменную окружения:

-e Logging:LogLevel:Default=Debug

Recursive Read-only (RRO) mounts

#3857; KEP

Монтирование read-only-томов появилось в Kubernetes с самого начала. Проблема в том, что в Linux read-only-тома при определённых условиях являются не совсем read-only. 

Например, мы можем ожидать, что после применения приведённого ниже манифеста директория /mnt и все её субдиректории в контейнере станут read-only. Но это не так:

apiVersion: v1
kind: Pod
spec:
 volumes:
   - name: mnt
     hostPath:
       path: /mnt
 containers:
   - volumeMounts:
       - name: mnt
         mountPath: /mnt
         readOnly: true

Попытки записи в /mnt* будут отклонены, в то время как /mnt/my-nfs-server/* останется доступной для записи.

Параметр recursiveReadOnly в v1.30 исправляет этот недочёт, чем позволяет проводить read-only-монтирования рекурсивно. Для обратной совместимости поле recursiveReadOnly не заменяет readOnly, а используется совместно с ним. То есть чтобы включить рекурсивный режим read-only, необходимо задать оба поля (readOnly: true и recursiveReadOnly: Enabled).

Kubelet Support for Image Filesystem being split

#4191; KEP

У kubelet’а есть две файловые системы: Node и Image. Обычно они находятся на одном диске. Но иногда их нужно распределить на несколько дисков, например отделить writable-уровень от read-only-уровня. В этом случае данные kubelet’а и контейнера будут на одном диске, а образы — на другом. Плюс такого разделения в том, что образы, как правило, занимают много места, в то время как writable-слой обычно небольшой.

В существующей реализации раздельных дисков контейнеры и образы должны храниться на одном диске. В этом случае сборщик мусора сможет при необходимости их удалить. Чтобы успешно отделить writable-слой (контейнеры) от read-only-слоя (образы), необходимо соответствующим образом настроить сборку мусора и статистику. В противном случае это может привести к поломке kubelet’а. 

Изначально KEP появился в версии 1.29. Тогда были внесены первичные изменения в API kublet’а и CRI. В версии 1.30 работа над функциональностью продолжилась. В частности, KEP: 

• дополняет API CRI;

• добавляет эндпоинт imagefsinfo для файловых систем контейнера и образа;

• дополняет логику работы менеджера вытеснения (eviction);

• позволяет клиентам CRI-O работать с imagestore;

• позволяет cadvisor определять статистику диска, когда writeable- и read-only-слои находятся на разных дисках;

• вносит изменения в CRI-O, который реализуют поддержку разделённой файловой системы.

DRA: structured parameters

#4381; KEP

Функция динамического распределения ресурсов (Dynamic Resource Allocation, DRA) появилась в Kubernetes 1.26 (см. #3063, KEP, блог K8s, а также обзор Kubernetes 1.26). Она определяет альтернативу традиционному API для устройств-плагинов для запроса доступа к сторонним ресурсам.

Параметры ресурсов в DRA непрозрачны для Kubernetes. Они интерпретируются контроллером драйвера DRA (для размещения claim’ов) и kubelet-плагином драйвера DRA (для конфигурирования ресурсов на узле). При планировании пода kube-scheduler и контроллер(ы) драйвера DRA, обрабатывающий(ие) claim’ы для пода, обмениваются данными через apiserver, обновляя объект PodSchedulingContext. В итоге все активные claim’ы учитываются и под планируется на узел.

Такой подход создаёт проблемы для Cluster Autoscaler (CA) или любого контроллера более высокого уровня, которому необходимо принимать решения для группы подов (например, планировщика заданий). Он не может смоделировать эффект аллокации или реаллокации claim’ов с течением времени. Только у драйверов DRA есть необходимая для этого информация.

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

Beta-фичи

Introducing Sleep Action for PreStop Hook

#3960; KEP

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

Node memory swap support

#2400, KEP

Впервые KEP был представлен в версии 1.22. В 1.28 была реализована первая часть бета-функциональности. В 1.30 добавляются тесты соответствия свопа. Также добавляется условие, которое проверяет версию cgroup (требуется v2) и предотвращает запуск kubelet, если своп включен, а узел использует cgroup v1. Подробнее смотрите в обзоре Kubernetes 1.22.

Add support for a drop-in kubelet configuration directory

#3983, KEP

KEP добавляет поддержку drop-in-директории для конфигов kubelet. Её можно задать с помощью флага --config-dir (например, /etc/kubernetes/kubelet.conf.d). Напомним, что конфигурационные файлы обрабатываются в алфавитно-цифровом порядке. По умолчанию флаг будет пустым, и если его не указать, то поддержка drop-in не будет включена. Синтаксис в файлах конфигурации должен быть такой же, как в kubelet.conf.

[KEP-3085] Add condition for sandbox creation (xposted from original issue)

#4138, KEP

Готовность к запуску контейнеров в поде, отмеченная успешным созданием песочницы пода, является критической фазой его жизненного цикла. Для её подготовки kubelet задействует множество компонентов: in-tree-плагины томов (ConfigMap, Secret, EmptyDir и др.), плагины CSI и рантайм контейнера (который инициирует рантайм-обработчик и плагины CNI). Успешное завершение всех этих этапов переводит песочницу пода в состояние, готовое к запуску контейнеров. KEP добавляет условие PodReadyToStartContainers к статусу пода для индикации этого состояния. PodReadyToStartContainers станет важной вехой в жизненном цикле пода подобно ContainersReady и остальным ready-состояниям пода.

kubelet image GC after a maximum age

#4210; KEP

В настоящее время сборка мусора для удаления образов запускается при превышении порогового значения использования диска (ImageGCLowThresholdPercent). Но в некоторых случаях могут пригодиться дополнительные условия, например максимальный возраст. Если образ длительное время не используется, он вряд ли будет использован снова. Точное значение возраста определяется для конкретного случая, например несколько недель.

KEP добавляет в объект KubeletConfiguration опцию ImageMaximumGCAge. Она позволяет администратору указать время, по истечении которого неиспользуемые образы будут удаляться независимо от использования диска.

add ProcMount option

#4265; KEP

В средах исполнения, которые следуют спецификации OCI, контейнеры по умолчанию работают в режиме, когда есть masked-пути и пути, доступные только для чтения. Иногда необходимо обойти эти ограничения, например при запуске контейнеров внутри Kubernetes-контейнера в поде. Для этого KEP добавляет поле procMount в секцию securityContext, которое позволяет сделать директорию /proc контейнера Unmasked или смонтировать её как доступную для чтения/записи процессом контейнера. То же самое справедливо для /sys/firmware:

securityContext:
  procMount: Unmasked

Support User Namespaces in stateless pods

#127; KEP

KEP добавляет поддержку пользовательских пространств имён в stateless-подах.

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

Stable-фичи

AppArmor support

#24; Design proposal

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

В Kubernetes 1.30 поддержка AppArmor, наконец, доросла до статуса GA (общей доступности).

Приложения

Alpha-фичи

Job success/completion policy

#3998; KEP

У задач в Kubernetes есть два способа определения успешного завершения:

• NonIndexed (по умолчанию): задача считается завершённой, если количество успешно завершённых подов равно числу, указанному в .spec.completions. Другими словами, все события завершения работы подов гомологичны друг другу.

• Indexed: задача считается завершённой, если с каждым индексом от 0 до .spec.completions-1 связан один успешно завершённый под. Индекс навешивается на под с помощью аннотации batch.kubernetes.io/job-completion-index и переменной окружения JOB_COMPLETION_INDEX.

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

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

Job API managed-by mechanism

#4368; KEP

Поле managedBy в спецификации задачи (Job) позволяет делегировать её синхронизацию внешнему контроллеру.

В рамках проекта Kueue ведется работа над мультикластерным диспетчером задач MultiKueue. В MultiKueue, построенном по архитектуре менеджер-воркер, пользователь заводит задачу в управляющем кластере, а её зеркальная копия создаётся и выполняется в одном из кластеров-воркеров. Контроллер Kueue доносит обновления статуса задачи из воркера до управляющего кластера — они отражаются в статусе оригинальной задачи, созданной пользователем.

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

Хранилище

Beta-фичи

SELinux relabeling using mount options

#1710; KEP

На хостах с SELinux в принудительном режиме (enforcing mode) пользователи одного контейнера не могут получить доступ к другому контейнеру или хосту. Это обеспечивается за счёт:

• контекста, который уникален для каждого контейнера. Например: system_u:system_r:container_t:s0:c309,c383;

• соответствующих лейблов, которые назначаются каждому файлу на каждом томе хранилища. Например: system_u:object_r:container_file_t:s0:c309,c383. 

Доступ к файлам с лейблом container_file_t:s0:c309,c383 может получить только процесс с контекстом ...:container_t:s0:c309,c383. Злоумышленник, которому удалось выбраться из контейнера, не сможет получить доступ к данным в других контейнерах, потому что у каждого контейнера свои тома со своими лейблами.

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

Новая функция даёт возможность пропустить этап переназначения лейблов, чтобы ускорить монтирование тома. Для этого при монтировании используется опция -o context=XYZ, которая устанавливает общий контекст для всех файлов тома. Поскольку все файлы тома уже снабжены нужным контекстом и соответствующим лейблом, переназначения лейблов не происходит.

Stable-фичи

Prevent unauthorised volume mode conversion during volume restore

#3141; KEP

С помощью API-ресурса VolumeSnapshot можно создавать PVC (PersistentVolumeClaim) из снапшота. Это делается через установку в PVC параметра Spec.dataSource, который указывает на существующий ​​VolumeSnapshot. При этом нет механизма проверки, который скажет, соответствует ли режим доступа к то́му у вновь созданного PVC режиму доступа, заданному для исходного PVC. KEP предлагает решение для предотвращения несанкционированного преобразования режима доступа к тому. Подробнее смотрите обзор Kubernetes 1.24.

Robust VolumeManager reconstruction after kubelet restart

#3756; KEP

Цель KEP’а — уменьшить время, необходимое kubelet для восстановления информации о примонтированных томах после перезапуска. Такая информация теряется после перезапуска kubelet, и для её восстановления ему приходится сопоставлять данные сервера API и ОС хоста. Kubelet проверяет, какие поды должны быть запущены и какие тома должны быть примонтированы на самом деле. Подробнее смотрите в обзоре Kubernetes 1.27.

Сеть

Alpha-фичи

Traffic Distribution for Services

#4444; KEP

KEP вводит новое поле routingPreference в спецификацию сервисов Kubernetes. Оно должно заменить аннотацию service.kubernetes.io/topology-mode и её предшественника — поле topologyKeys (устарело в Kubernetes 1.21).

Базовая реализация будет учитывать новое поле, принимая решения о маршрутизации (строгих гарантий маршрутизации не предусмотрено). Будут поддерживаться следующие начальные значения:

• Default: отсутствие конкретных предпочтений по маршрутизации. Пользователь делегирует решение о маршрутизации реализации.

• Close: отдавать предпочтение эндпоинтам, которые топологически близки к клиенту. Интерпретация «топологической близости» зависит от конкретной реализации. Могут подразумеваться эндпоинты в пределах одного узла, стойки, зоны или даже региона.

Пример сценария использования

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

Решение: установить routingPreference: Close.

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

Beta-фичи

Kube-proxy improved ingress connectivity reliability

#3836; KEP

KEP реализует механизм разгрузки соединений (connection draining) для terminating-узлов и добавляет путь /livez в сервер проверки работоспособности kube-proxy (proxier_health.go) (подробнее — в обзоре K8s 1.28). Также планируется выпустить рекомендации для поставщиков облачных услуг с перечнем более эффективных способов проверки работоспособности кластеров Kubernetes.

Примечание: KEP затрагивает только kube-proxy, так как это единственный сервисный прокси, который находится в ведении проекта Kubernetes.

Make Kubernetes aware of the LoadBalancer behaviour

#1860; KEP

KEP добавляет новое поле ipMode в поле loadBalancer в статусе сервиса. С его помощью kube-proxy будет решать, когда не привязывать внешний IP LoadBalancer’а к узлу как в режиме ipvs, так и в режиме iptables. Значение по умолчанию VIP будет означать обычное поведение, если оно не задано для инстанса. Значение Proxy будет пускать трафик через LoadBalancer. Подробнее — в обзоре Kubernetes 1.29.

Stable-фичи

Field status.hostIPs added for Pod

#2681; KEP

KEP добавляет поле status.hostIPs и вносит необходимые изменения в Downward API — позволяет контейнерам получать информацию о себе или кластере без использования клиента Kubernetes или сервера API.

Поле status.hostIP в Downward API хранит существующий IP-адрес пода. Новое поле status.hostIPs будет содержать список IP-адресов, выделенных хосту. Потребность в этом возникла из-за того, что новый API пода обзаведётся рядом структур для дополнительных IP-адресов.

Kubelet будет возвращать status.hostIPs в виде разделённой запятыми строки.

Remove transient node predicates from KCCM's service controller

#3458; KEP

Контроллер сервисов в Kubernetes cloud controller manager (KCCM) добавляет/удаляет узлы из набора узлов балансировщиков нагрузки в следующих случаях:

• когда на узел навешивается / с узла удаляется taint ToBeDeletedByClusterAutoscaler; 

• когда узел переходит в состояние Ready/NotReady.

Однако второй случай относится только к сервисам с externalTrafficPolicy: Cluster. При этом в обоих случаях удаление узла из набора узлов балансировщиков нагрузки приведёт к тому, что все соединения на этом узле будут мгновенно прерваны. Подобное поведение представляется неоптимальным для узлов в переходном состоянии готовности или завершающих свою работу и выглядит как ошибка, поскольку в таких случаях соединениям не разрешается разрываться, даже если балансировщик нагрузки поддерживает это. 

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

Cloud Dual-Stack --node-ip Handling

#3705; KEP

KEP позволяет администраторам кластеров, в которых используются внешние облачные ресурсы, гибко менять IP-адреса узлов, назначаемые облаком. В частности, администраторы могут:

• переопределять IP-адрес узла в dual-stack-кластере, и это не будет приводить к тому, что узел станет single-stack;

• переопределять оба IP-адреса узла в dual-stack-кластере;

• изменять порядок IP-адресов узлов в dual-stack-кластере (то есть задавать первичность IPv6 или IPv4);

• переключать узлы в single-stack-режим, когда поставщик облачных услуг предлагает dual-stack-режим, без необходимости указывать конкретный IP-адрес узла в формате IPv4 или IPv6.

Дополнительные сведения — в обзоре Kubernetes 1.27.

API

Alpha-фичи

Custom Resource Field Selectors

#4358; KEP

KEP добавляет поддержку селекторов полей для кастомных ресурсов. В CustomResourceDefinition появляется секция selectableFields:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: selector.stable.example.com
spec:
  group: stable.example.com
  versions:
    - name: v1
      selectableFields:
      - jsonPath: .spec.color 
      - jsonPath: .spec.size 
      additionalPrinterColumns:
      - jsonPath: .spec.color
        name: Color
        type: string
      - jsonPath: .spec.size
        name: Size
        type: string

Мотивация

Все API Kubernetes поддерживают выбор полей для metadata.name, metadata.namespace. Кроме того, встроенные API поддерживают выбор определённых полей, таких как status.phase для подов, однако в CustomResourceDefinition отсутствует соответствующая функциональность.

Move Storage Version Migrator in-tree

#4192; KEP

Kubernetes полагается на активную перезапись данных в ресурсах при работе с at-rest-хранилищами. Два ярких примера, когда такая перезапись необходима:

• обновление предпочтительной схемы хранения для ресурса, например переход с v1beta1 на v1;

• обновление способа шифрования at-rest-данных, например перезапись stale-данных с учетом изменившегося метода шифрования.

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

Основная цель KEP — облегчить пользователям выполнение таких миграций хранилищ, не заботясь о технических деталях, сделать процесс более автоматизированным и простым. Для это предлагается:

• перенести существующую логику контроллера SVM in-tree в KCM;

• перенести существующие API SVM REST in-tree (возможно, в новую группу API, чтобы избежать конфликтов со старыми API, работающими параллельно).

Alpha-версия не предусматривает автоматическую миграцию версий хранилищ — решение остаётся за пользователем.

Retry Generate Name

#4420; KEP

KEP вносит ряд изменений в apiserver, которые предписывают повторять попытки генерации новых имён в случае, если create-запрос с использованием generateName заканчивается ошибкой «конфликт имен».

Мотивация

Kubernetes генерирует случайный суффикс из пяти символов, который добавляется к префиксу, указанному в .metadata.generateName. Допускаются следующие символы: «bcdfghjklmnpqrstvwxz2456789». Всего получается 27 в пятой степени возможных комбинаций (14 348 907). Хотя существуют кластеры, в которых может быть до миллиона кастомных ресурсов, проблема с нехваткой суффиксов пока не стоит.

Однако есть проблема с конфликтами имён. Существует 50%-ная вероятность возникновения конфликта при генерации 5000 имён, а при генерации всего 500 имён она составляет 0,1%.

KEP помогает устранить эту проблему — теперь apiserver будет автоматически повторять попытки генерации.

Beta-фичи

Transition from SPDY to WebSockets

#4006; KEP

KEP предлагает перейти с SPDY/3.1 на WebSockets для kubectl exec, kubectl attach и kubectl cp в части взаимодействия между kubectl и сервером API. Также предлагается расширить участок, на котором коммуникация ведётся по протоколу WebSockets от API Server до kubelet. После этого между kubectl и kubelet будет происходить потоковая передача данных по WebSockets, проксируемая через API Server. Подробнее — в обзоре Kubernetes 1.29.

CRD Validation Ratcheting

#4008; KEP

В нынешнем виде валидация полей, которые не менялись, выступает препятствием для авторов CRD и разработчиков Kubernetes. KEP добавляет переключатель функциональности (feature flag) CRDValidationRatcheting. Если флаг установлен, обновления custom resources, которые не прошли валидацию, будут завершаться успешно. Это будет происходить, когда ошибки валидации связаны с ключевыми путями, которые не менялись (пример смотрите в обзоре Kubernetes 1.28). 

Stable-фичи

CEL for Admission Control

#3488; KEP

KEP предлагает новый способ admission-контроля без необходимости задействовать вебхуки. Это базируется на #2876 (смотрите обзор Kubernetes 1.27).

В группу admissionregistration.k8s.io вводится новый ресурс ValidatingAdmissionPolicy. Он содержит CEL-выражения для валидации запросов и объявляет, как политика может быть сконфигурирована для использования. Подробнее — в обзоре Kubernetes 1.26.

CEL-based admission webhook match conditions

#3716; KEP

KEP добавляет так называемые условия соответствия (match conditions) к admission-вебхукам как расширение существующих правил для определения области применения вебхука. matchCondition представляет собой CEL-выражение. Если оно истинно, admission-запрос будет отправлен на вебхук. Если оно ложно, вебхук запрос пропустит (неявно разрешено). Подробности смотрите в обзоре Kubernetes 1.27.

Aggregated Discovery

#3352; KEP

Улучшение предлагает централизовать механизм «обнаружения», публикуя все ресурсы, поддерживаемые кластером, через два эндпоинта (/api и /apis). В результате значительно сокращается количество соответствующих запросов. Подробнее — в обзоре Kubernetes 1.26.

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

Beta-фичи

Structured Authorization Configuration

#3221; KEP

Сегодня kube-apiserver позволяет настраивать цепочку авторизации с помощью набора флагов командной строки вида --authorization-*. При этом администраторы кластеров могут включить в цепочку авторизации только один вебхук, используя флаг --authorization-modes. В текущей реализации нет возможности указать несколько вебхуков для авторизации пользователей, но KEP позволяет передавать apiserver структурированный файл конфигурации. С его помощью можно решить проблемы, которые раньше были нерешаемы. Что появилось:

• возможность задавать несколько авторизационных вебхуков;

• новые опции для авторизационных вебхуков;

• hot reload (горячая перезагрузка) конфигурации без перезагрузки apiserver.

Пример конфигурации с описанием всех полей доступен в разделе Design Details KEP’а.

Structured Authentication Config

#3331; KEP

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

Bound service account token improvements

#4193; KEP

KEP дополняет генерируемые токены при обработке вызова TokenRequest create kube-apiserver функциями для автоматического включения name и uid узла, с которым ассоциирован под (через spec.nodeName).

 Так как в этой области кода уже есть под, который содержит имя узла, необходимо пробросить геттер (get) для объектов Node на уровень хранения TokenRequest. Это нужно, чтобы можно было получать UID узла аналогично тому, как это делается для объектов Pod и Secret.

Stable-фичи

Reduction of Secret-based Service Account Tokens

#2799; KEP

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

CLI

Alpha-фичи

Custom profile in kubectl debug

#4292; KEP

KEP добавляет кастомное профилирование поверх предопределённых профилей в команде kubectl debug, избавляя от необходимости открывать Issue для очередного «нового» флага.

У kubectl debug есть набор предопределённых профилей. Пользователи могут выбрать подходящий в соответствии со своими потребностями и ролями. Однако в некоторых случаях — возможно, даже в большинстве — требуется настроить эти профили, добавив:

• переменные окружения;

• реплицирование точек монтирования томов;

• контексты безопасности;

• лейблы (1, 2);

• секреты для извлечения образов (imagePullSecret).

Преодолеть эти сложности можно вручную, правя спецификации подов (если только такое вмешательство не препятствует их доступности). Но это непрактично, особенно если приходится это делать постоянно. В таких случаях обычно пользователи открывают Issue или готовят Pull Request, в котором предлагают очередной флаг для управления определёнными полями в спецификациях подов. В итоге команда debug рискует превратиться в нечто неуправляемое — её будет сложно поддерживать хранителям, да и пользователям будет тяжело разобраться в её нюансах. Но KEP предлагает более изящный способ решения этой проблемы.

Stable-фичи

kubectl delete: Add interactive(-i) flag

#3895; KEP

KEP вводит интерактивный режим для команды kubectl delete, чтобы защитить администраторов кластера от случайного безвозвратного удаления критических ресурсов.

При добавлении флага --interactive/-i в команду kubectl delete все ресурсы, которые планируется удалить, будут показываться пользователю в виде превью. Чтобы подтвердить удаление, необходимо будет нажать y, пользователь подтвердит удаление. n или другое значение, отличное от y, прервёт процесс удаления, а команда вернёт сообщение с нулевым кодом выхода.

Планировщик

Stable-фичи

Min domains in PodTopologySpread

#3022; KEP

С помощью фичи Pod Topology Spread можно равномерно распределять поды по multi-zone-кластеру. У фичи есть параметр maxSkew, который контролирует, сколько подов может быть распределено неравномерно. Однако контроля количества доменов (topology domains, то есть регионов, зон и т. п.), по которым могут распределяться эти поды, нет. В некоторых случаях, например, требуется принудительно распределить поды по минимальному количеству доменов и, если доменов недостаточно, заставить Cluster Autoscaler их предоставить.

Может возникнуть и другая проблема: домен, который был перемасштабирован Cluster Autoscaler’ом до 0, становится невидимым для планировщика. Реальные ресурсы будут не востребованы.

Новая фича решает обе проблемы. Теперь пользователь может определить минимальное количество доменов, которые должны быть доступны, даже если они не существуют на момент планирования запуска новых подов. При необходимости домен будет масштабироваться, а Cluster Autoscaler — запрашивать новые узлы в пределах этого домена. Подробнее смотрите в обзоре Kubernetes 1.24.

Pod scheduling readiness

#3521; KEP

Поды считаются готовыми к планированию сразу после их создания. Планировщик Kubernetes ищет узлы для размещения всех ожидающих подов. Однако в реальности некоторые поды могут долго оставаться в состоянии miss-essential-resources («отсутствие необходимых ресурсов»). Такие поды сбивают с толку планировщик и компоненты типа Cluster Autoscaler.

KEP дорабатывает API и механику процесса. Теперь пользователи или оркестраторы знают, когда под полностью готов для планирования. В Pod API добавляется новое поле .spec.schedulingGates со значением по умолчанию nil. Поды, у которых значение этого поля не равно nil, будут «припаркованы» во внутреннем пуле unschedulablePods планировщика. Он обработает их, когда поле изменится на nil.

Разное

Beta-фичи

Node log query

#2258; KEP

KEP реализует клиент для работы с просмотрщиком эндпоинта /var/log/ kubelet’а. Дополнительную информацию о специфике реализации для разных ОС можно узнать из раздела Proposal KEP’а. 

Contextual logging

#3077; KEP

KEP — очередной шаг по снижению зависимости от klog (библиотеки логирования K8s) и её ограничений. Фича включает два изменения, ориентированных на разработчиков:

• Смена зависимостей: вместо глобального logger’а библиотеки теперь используют экземпляр, который им передаётся.

• Библиотеки могут использовать функции WithValues и WithName, чтобы добавлять дополнительную контекстную информацию logger’у (и на вывод лога).

Подробности смотрите в обзоре Kubernetes 1.24.

Stable-фичи

Container Resource based Pod Autoscaling

#1610; KEP

В настоящее время Horizontal Pod Autoscaler (HPA) может масштабировать рабочие нагрузки на основе ресурсов, используемых их подами. То есть учитывается совокупное использование ресурсов всеми контейнерами пода.

KEP позволяет HPA масштабировать рабочие нагрузки на основе использования ресурсов отдельными контейнерами.

API Server Tracing

#647; KEP

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

Metric cardinality enforcement

#2305; KEP

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

Go workspaces for k/k

#4402; KEP

Примечание: k/k — просторечное название главного репозитория Kubernetes (github.com/kubernetes/kubernetes).

KEP предлагает перейти на рабочие пространства Go и привести инструменты разработчиков K8s в соответствие с современными стандартами (полностью избавившись от зависимости от GOPATH). Для этого предлагается добавить файл go.work и исправить все инструменты, которые поломаются из-за этого. Скрипты verify и update смогут использовать стандартные правила Go для сборки и запуска кода. Пережитки прошлого вроде run-in-gopath.sh будут удалены.

KEP стартует сразу как stable-фича и не предполагает изменений, затрагивающих пользовательский опыт.

Список устаревших или удалённых фичей

Ниже приведён список фичей, которые признаны устаревшими в Kubernetes 1.30.

Удалённые примитивы/версии API

• Admission-плагин SecurityContextDeny (признан устаревшим в v1.27).

• In-tree storage-плагин azureFile.

• In-tree облачные провайдеры для Azure и vSphere.

Устаревшие примитивы — перейти на альтернативу до выхода следующего релиза

Kubeadm: версия v1alpha2 output-API признана устаревшей и будет удалена в будущем релизе. Рекомендуется перейти на v1alpha3. 

Перед обновлением рекомендуем ознакомиться с changelog’ом.

P. S.

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

• Kubernetes 1.29: бэкенд на nftables, изменение атрибутов тома и другие фичи

• Kubernetes 1.28: прощание с Google, оптимизация работы с контейнерами и задачами, новый KEP от «Фланта»

• Kubernetes 1.27: обзор нововведений