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

Сегодня официально выходит новая версия Kubernetes — 1.28. Среди главных изменений — оптимизация работы с sidecar-контейнерами и задачами (jobs). Клиенты теперь будут переадресовываться на тот сервер API, который способен обработать их запрос, что упростит скользящие обновления. Проект Kubernetes продолжает размежевание с инфраструктурой Google — KEP 1731 описывает ряд шагов, направленных на оптимизацию и упрощение релизного процесса.

Для подготовки статьи использовалась информация из таблицы Kubernetes enhancements tracking, CHANGELOG-1.28, записи и конспекты встреч SIG’ов, информация от наших инженеров, которые являются контрибьюторами Kubernetes, а также обзор, подготовленный Víctor Jiménez Cerrada. Кроме того, анализировались конкретные Issues, Pull Requests и Kubernetes Enhancement Proposals (KEPs).

Для удобства пользования обзором как небольшим справочником, мы разбили все изменения на несколько разделов:

• Узлы

• Приложения

• Хранилище

• Сеть

• API

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

• CLI

• Разное

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

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

• alpha (19 новых функций);

• beta (14 функций продолжают улучшаться);

• stable (11 функций признаны стабильными).

Всего новый релиз насчитывает 44 изменения.

Примечание

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

Начать обзор мы бы хотели с KEP, который наши инженеры разработали вместе с коллегами из Google и Microsoft.

Новый KEP от компании «Флант»: Structured Authentication Config

KEP 3331 (Structured Authentication Config) — самое крупное за последние шесть лет обновление в системе аутентификации Kubernetes, в котором учитываются все просьбы пользователей. KEP реализует структурированную конфигурацию для аутентификации с рядом весомых преимуществ по сравнению с традиционным подходом (поддерживает любые JWT-совместимые токены, динамическое изменение конфигурации, одновременную работу с несколькими провайдерами аутентификации и Common Expression Language). Подробнее о KEP — в недавней заметке «Крупнейшее изменение системы аутентификации в K8s за последние годы: новый KEP от «Фланта», Google и Microsoft».

Примечание

Код из нашего KEP’а вошел в состав Kubernetes 1.28, однако его функциональность будет доступна, начиная со следующей версии.

Узлы

Alpha-фичи

Support User Namespaces in pods

#127, KEP

KEP добавляет пользовательские пространства имен. Смысл в том, чтобы иметь возможность запускать в подах процессы с user- и group-идентификаторами, отличными от идентификаторов на хосте. Другими словами, привилегированный процесс в поде будет непривилегированным на хосте. При попытке выйти за пределы контейнера такой процесс не сможет причинить значительного вреда хосту. Предложение полностью или частично закрывает ряд уязвимостей в области безопасности (их перечень доступен в разделе «Мотивация»).

В pod.Spec добавляется булево поле hostUsers. Если его значение true или не задано, то используется пространство имен хоста (как и раньше). Если же false, то для пода создается новый userns. По умолчанию поле не задано.

Sidecar Containers

#753, KEP

KEP предлагает ввести новое поле restartPolicy для init-контейнеров, указывающее на то, что init-контейнер является sidecar-контейнером. Агент kubelet будет запускать init-контейнеры с restartPolicy = Always в том же порядке, что и другие init-контейнеры. Но вместо того, чтобы дожидаться завершения их работы, он будет ждать завершения последовательности запуска контейнера (условием завершения последовательности запуска будет являться успешное выполнение startup-пробы и завершение обработчика postStart).

Политика RestartPolicy влияет только на init-контейнеры и определяет поведение их перезапуска в поде, при этом единственным допустимым значением поля restartPolicy является Always. Поведение перезапуска в остальных случаях — для обычных контейнеров или для init-контейнеров, у которых поле restartPolicy не задано — определяется политикой перезапуска пода и типом контейнера.

Если init-контейнеры подчиняются политике RestartPolicy (соответствующее поле установлено в значение Always), то они будут перезапускаться при выходе до тех пор, пока не завершатся все обычные контейнеры и только после этого завершатся сами.

Не трудно заметить отличия жизненных циклов init-контейнера и sidecar-контейнера (init-контейнера, у которого restartPolicy = Always). Последовательности запуска sidecar- и обычного init-контейнера одинаковые, однако kubelet не дожидается завершения работы sidecar-контейнера перед переходом к следующему init-контейнеру — тот запускается сразу же после запуска текущего контейнера или после успешного завершения любого startupProbe.

Pod conditions around readiness to start containers after completion of pod sandbox creation

#3085, KEP

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

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.

Add CDI devices to device plugin API

#4009, KEP

Данный KEP расширяет API плагинов устройств, добавляя поле с ID устройств Container Device Interface (CDI) в AllocateResponse. Оно дополняет существующие поля, такие как аннотации, и позволяет различным реализациям плагинов ссылаться на ресурсы однозначно, используя полные имена CDI-устройств.

Недавнее добавление идентификаторов устройств CDI в структуры CRI, как описано в #3731, позволяет безопасно передавать эти идентификаторы в CRI. Хотя изменения были мотивированы KEP 3063, добавление поддержки таких полей в существующий API плагинов устройств позволяет использовать подобный механизм и для устройств, поддерживаемых этими плагинами.

Discover cgroup driver from CRI

#4033, KEP

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

Dynamic resource allocation

#3063, KEP

Этот KEP появился еще в версии 1.27, но пока остается на стадии alpha. Он реализует API, позволяющий описывать новые типы ресурсов, необходимые поду. Поддерживаются следующие возможности:

• Ресурсы, подключаемые по сети. Существующий API плагинов устройств ограничен аппаратным обеспечением на узле.

• Совместное использование ресурсов несколькими контейнерами или подами. Существующий API диспетчера устройств вообще не поддерживает совместное использование. Его можно дополнить, после чего станет возможен обмен ресурсами между контейнерами в одном поде, но для обмена ресурсами между подами потребуется совершенно новый API, подобный тому, который представлен в этом KEP.

• Ресурсы, инициализация которых в разных подах обходится слишком дорого (на данный момент оптимизировать этот процесс невозможно).

• Пользовательские параметры, описывающие требования к ресурсам и их инициализацию. Параметры не всегда бывают линейными и счетными. В текущей реализации API пода для работы с такими параметрами используются аннотации, а для доступа к ним из драйвера CSI или плагина устройства приходится выдумывать различные «костыли».

Подробнее см. в обзоре Kubernetes 1.27.

Beta-фичи

Kubelet limit of Parallel Image Pulls

#3673, KEP

KEP добавляет в конфигурацию kubelet’а новый параметр maxParallelImagePulling, который ограничивает максимальное количество параллельно запрашиваемых образов. Любой запрос, превышающий заданный лимит, будет блокироваться до тех пор, пока не завершится скачивание одного из образов «в процессе». Подробнее о логике работы механизма можно узнать из предложения по улучшению.

Node memory swap support

#2400, KEP

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

Improved multi-numa alignment in Topology Manager

#3545, KEP

Компонент kubelet’а TopologyManager предоставляет политики, с помощью которых можно настраивать выравнивание ресурсов на одном или нескольких NUMA-узлах (Non-Uniform Memory Architecture). Однако TopologyManager не учитывает расстояние между NUMA-узлами — это важный показатель, который влияет на производительность приложений, критичных к задержкам.

Новая фича добавляет две ключевых опции:

• разрешает TopologyManager’у во всех его политиках предпочитать набор NUMA-узлов с наименьшим расстоянием между ними;

• вводит новый флаг topology-manager-policy-options, с помощью которого можно «заставлять» TopologyManager учитывать расстояние.

Подробнее о логике расчета и учета среднего расстояния между NUMA-узлами можно почитать в деталях реализации.

О других улучшениях, связанных с NUMA, читайте в наших обзорах выпусков Kubernetes 1.25 (CPU Manager policy: socket alignment) и 1.23 (CPUManager policy option to distribute CPUs across NUMA nodes).

Stable-фичи

Support 3rd party device monitoring plugins

#606, KEP (см. также #3743)

KEP 606 реализует поддержку сторонних плагинов для мониторинга устройств, вынося из kubelet (out-of-tree) специфичные для устройств знания (для этого создается отдельный эндпоинт PodResources). Администраторы кластеров получат метрики, которые получают от плагинов устройств на уровне контейнера, а производители — возможность создавать эти метрики без необходимости вносить изменения в ядро Kubernetes.

С подробностями реализации можно ознакомиться в предложении под названием «Kubelet Metadata API».

Цель KEP 3743 — довести готовность API PodResources до состояния готовности GA, что означает достаточно высокий уровень зрелости и стабильности, позволяющий с уверенностью его использовать в production.

Extend podresources API to report allocatable resources

#2403, KEP

KEP расширяет сервис PodResources, позволяя сторонним потребителям узнавать о количестве доступных вычислительных мощностей и правильно оценивать потенциал узла.

Дополнительный эндпоинт GetAllocatableResources возвращает ответ AllocatableResourcesResponse. С его помощью приложения для мониторинга могут запрашивать информацию о ресурсах на узле, доступных для распределения.

Приложения

Alpha-фичи

Backoff Limit Per Index For Indexed Jobs

#3850, KEP

KEP дополняет API Job, позволяя задавать число повторных попыток (backoff limit) для каждого индекса в индексированных задачах.

Мотивация

В настоящее время для индексированных задач устанавливается общий лимит повторных попыток (backoff limit). Как только он достигается, задача помечается как failed, а занятые ей ресурсы — высвобождаются (включая индексы, которые еще не завершили свою работу).

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

Например, если бы такие индексированные задачи использовались в качестве основы для набора длительных интеграционных тестов, то каждый прогон завершался бы после единственного найденного сбоя.

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

#3939, KEP

В настоящее время задачи (jobs) запускают новые поды на замену старым, как только те получают статус Terminating (имеют метку deletionTimestamp) или Failed (под находится в фазе жизненного цикла Failed). В статусе задачи поды, находящиеся в состоянии Terminating, учитываются как Failed. Однако на самом деле они находятся в переходном состоянии: не активны, но и не завершены полностью.

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

Мотивация

Многие распространенные фреймворки машинного обучения, такие как, например, Tensorflow и JAX, требуют уникальных подов для каждого индекса. Когда под переходит в состояние Terminating из-за приоритизации (preemption), вытеснения (eviction) или других внешних факторов, то создается замещающий под, однако попытка запустить его оканчивается неудачей.

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

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

Новое поле может также использоваться контроллерами очередей, такими как Kueue, не только для подсчета подов в состоянии Terminating, но и для расчета квот.

Beta-фичи

Add Pod Index Label for StatefulSets and Indexed Jobs

#4017, KEP

Примечание

Нововведение выпускается сразу в beta, поскольку риск столкнуться с проблемами минимален — добавляется всего лишь новый лейбл.

KEP добавляет лейбл индекса для индексированных задач и StatefulSet’ов.

В настоящее время под, работающий как StatefulSet, может определить свой индекс только с помощью парсинга имени, что не очень удобно. Гораздо проще было бы задавать его в виде аннотации, которую можно установить как переменную окружения, используя Downward API (это уже делается для индексированных задач).

Кроме того, и для индексированных задач, и для StatefulSet’ов хорошо бы иметь лейбл для индекса, чтобы упростить фильтрацию и выборку.

Retriable and non-retriable Pod failures for Jobs

#3329, KEP

Чтобы ограничить время выполнения задачи (Job), используются два параметра:

• activeDeadlineSeconds — максимальное время выполнения задачи;

• backoffLimit — количество попыток запуска задачи за отведенное (в предыдущем параметре) время.

Если задача не запускается, а политика перезапуска установлена в OnFailure, то Kubernetes попытается заново запустить ее — столько раз, сколько указано в backoffLimit.

Нововведение помогает учитывать некоторые причины незапуска задачи и, при необходимости, завершать ее досрочно, игнорируя backoffLimit. Для этого в Job API добавлено новое поле podFailurePolicy. Подробнее — в обзоре Kubernetes 1.25.

Add job creation timestamp to job annotations

#4026, KEP

Примечание

Нововведение выпускается сразу в beta, поскольку риск столкнуться с проблемами минимален — добавляется всего лишь новая аннотация.

KEP добавляет новую аннотацию batch.kubernetes.io/cronjob-scheduled-timestamp. Она используется для записи исходной (ожидаемой) временно́й метки создания задачи, когда эта задача является частью CronJob.

Управляющий слой устанавливает значение в формате RFC3339. Если задача определена в CronJob с указанным часовым поясом, то временна́я метка указывается в этом часовом поясе — в противном случае используется UTC.

Хранилище

Alpha-фичи

PersistentVolume last phase transition time

#3762, KEP

KEP добавляет новое поле PersistentVolumeStatus, которое содержит временну́ю метку последнего изменения фазы PersistentVolume.

Некоторые пользователи столкнулись с потерей данных при использовании политики Delete и вернулись к более безопасной политике Retain. При использовании политики Retain все тома, которые хранятся, но остаются невостребованными, находятся в состоянии Released. Со временем такие тома накапливаются. Возникает необходимость вручную удалять старые тома, основываясь на времени их последнего использования (т. е. времени, когда том перешел в состояние Released).

При этом к задаче можно подойти более глобально — просто сохранять временну́ю метку перехода тома в любое состояние, а не только в Released. Это позволит любому пользователю, в том числе и тестам производительности, измерять время перехода, например, между состояниями Pending и Bound. Кроме того, такая метка может пригодиться для метрик и SLO.

Support recovery from volume expansion failure

#1790, KEP

Пользователь может увеличить PersistentVolumeClaim (PVC), задав такой его размер, который превышает возможности хранилища. В этом случае контроллер обычно зависает в неудачных попытках увеличить том. KEP предотвращает подобное развитие событий, позволяя повторно попытаться увеличить том, но уже с другим значением.

Для этого в валидацию API вносятся некоторые послабления для объектов PVC, позволяющие уменьшать размер запрашиваемого пространства. Кроме того, добавляется поле pvc.Status.AllocatedResources для точного отслеживания квоты ресурсов при уменьшении размера PVC.

Мотивация

В некоторых случаях пользователь может попытаться увеличить PVC до размера, который превышает возможности хранилища. К примеру, размер PVC составлял 10 Гб, а пользователь решил поднять его до 500 Гб, что провайдером хранилища не поддерживается по той или иной причине. KEP позволяет скорректировать запрашиваемый размер, уменьшив его, скажем, до 100 Гб.

Проблема, связанная с возможностью уменьшения размера, состоит в том, что кто-то может использовать ее для злоупотребления системой квот, например, быстро увеличивая, а затем уменьшая размер PVC. Вообще говоря, как CSI, так и in-tree-плагины томов спроектированы таким образом, что никогда не выполняют реального сжатия базового тома. Однако действия злоумышленника могут обмануть систему квотирования, заставив ее поверить, что пользователь использует в хранилище места меньше, чем он занял на самом деле.

Для решения этой проблемы при расчете квоты будет использоваться max(pvc.Spec.Capacity, pvc.Status.AllocatedResources), а уменьшение pvc.Status.AllocatedResources будет производиться контроллером только после того, как ранее предпринятое увеличение завершилось каким-либо терминальным сбоем.

Stable-фичи

Retroactive default StorageClass assignment

#3333, KEP

KEP решает ряд проблем, изменяя поведение PV-контроллера. Как только любой StorageClass помечен в качестве используемого по умолчанию, контроллер сразу же назначает его всем не привязанным PVC со значением pvc.spec.storageClassName=nil. После того, как администратор создаст SC по умолчанию, вместо nil появится имя этого SC. Подробнее в обзоре Kubernetes 1.25.

Non-graceful node shutdown

#2268, KEP

KEP позволяет заранее активировать функцию принудительного отключения подов для случаев, когда не срабатывает Node Shutdown Manager и поды, запущенные StatefulSet’ом подвисают в статусе Terminating. При этом StatefulSet не может пересоздать поды на другом узле. Ситуация усугубляется, если поды используют тома: VolumeAttachments так и останутся привязанными к подвисшим подам. Делается это установкой taint’а out-of-service=nodeshutdown:NoExecute. При этом поды и привязанные к ним тома будут удалены, а новые — запущены на другом узле. Тем самым сохранится работоспособность приложения. Чтобы вернуть в строй старый узел, нужно вручную удалить taint после того, как поды запустятся на новом узле. Подробнее в обзоре Kubernetes 1.24.

Сеть

Alpha-фичи

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-адресов. Если поле задано, то 0-я запись должна соответствовать полю hostIP. Список пуст, если ни один IP-адрес еще не был выделен.

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

Kube-proxy improved ingress connectivity reliability

#3836, KEP

Контроллер сервисов в менеджере облачных контроллеров Kubernetes (KCCM) настраивает и балансировщик нагрузки, и соответствующую проверку работоспособности (health check, HC) по событиям, связанным с сервисом. Эту проверку балансировщик нагрузки затем использует для определения инстансов — кандидатов на балансировку трафика. Для некоторых облачных провайдеров (GCP) KCCM настраивает HC на получение этой информации через прокси-сервер Kubernetes. Данный KEP затрагивает только kube-proxy, поскольку это единственный сервисный прокси, находящийся в ведении проекта Kubernetes.

Можно выделить два класса сервисов, для которых задается HC:

• externalTrafficPolicy: Cluster / eTP:Cluster (по умолчанию)

• externalTrafficPolicy: Local / eTP:Local

Для сервисов класса eTP:Cluster kube-proxy в настоящее время возвращает ответ, соответствующий состоянию эндпоинта healthz. Для сервисов класса eTP:Local kube-proxy работает только в том случае, если у сервиса, для которого был создан балансировщик нагрузки, есть эндпоинт в состоянии Ready, запущенный на узле. Данный KEP охватывает первый случай. Предлагается следующее:

1. Реализовать механизм, позволяющий балансировщикам нагрузки осуществлять разгрузку соединений (connection draining) для узлов в состоянии Terminating. Для этого kube-proxy будет проверять поле .spec.unschedulable в объекте Node, указывающее на завершение работы узла, а при обнаружении этого поля начнет сбрасывать все попытки подключений на /healthz (соответственно, балансировщик нагрузки перестанет направлять трафик на узел).

2. Добавить путь /livez в сервер проверки работоспособности kube-proxy (proxier_health.go).

3. Данный KEP не стремится унифицировать то, как реализована проверка работоспособности сервисов eTP:Cluster у разных облачных провайдеров. При этом его авторы все же хотят рекомендовать поставщикам облачных услуг более эффективные способы проверки работоспособности кластеров Kubernetes. Для этого предлагается добавить на обзорную страницу документ, который будет выступать официальным руководством и использоваться для обмена знаниями с облачными провайдерами.

Мотивация

Во-первых, узлы, используемые в качестве промежуточных nexthop для сервисов eTP:Cluster, должны позволять всем соединениям, проходящим через узел во время завершения его работы, аккуратно приглушаться.

Во-вторых, добавление нового пути /livez позволит как вендорам, так и пользователям kube-proxy задавать livenessProbe, на который не влияет ни один индикатор завершения работы узла. Он будет показывать только состояние kube-proxy (как это происходит сегодня).

В-третьих, облачные провайдеры по-разному определяют, следует ли балансировщику нагрузки использовать конкретный узел для сервисов eTP:Cluster. Официальный документ позволит осветить преимущества одних методов и «подводные камни» других. В перспективе это должно помочь адаптировать различные реализации к механике кластера Kubernetes.

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

Beta-фичи

Remove transient node predicates from KCCM's service controller

#3458, KEP

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

1. Когда на узел навешивается/с узла удаляется taint ToBeDeletedByClusterAutoscaler;

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

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

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

Данный KEP предусматривает прекращение синхронизации набора узлов балансировщиков нагрузки в таких случаях. Для удобства в систему интегрирован переключатель функциональности (feature gate) StableLoadBalancerNodeSet.

Reserve nodeport ranges for dynamic and static allocation

#3668, KEP

KEP развивает идею KEP 3070 (см. обзор нововведений Kubernetes 1.24), помогая избежать конфликтов при резервировании портов для сервисов типа NodePort. Подробнее см. в обзоре нововведений Kubernetes 1.27.

Stable-фичи

Proxy Terminating Endpoints

#1669, KEP

KEP оптимизирует работу kube-proxy при обработке эндпоинтов, улучшая возможности по управлению трафиком и повышая общую надежность Kubernetes.

Expanded DNS configuration

#2595, KEP

KEP расширяет возможности для настройки DNS. После активации feature gate MaxDNSSearchPathsExpanded меняются два параметра в настройках DNS:

• MaxDNSSearchPaths увеличивается с 6 до 32;

• MaxDNSSearchListChars увеличивается с 256 до 2048.

Cleaning up IPTables Chain Ownership

#3178, KEP

KEP оптимизирует работу с цепочками iptables, создаваемыми kubelet’ом. Опция IPTablesOwnershipCleanup запрещает kubelet’у создавать цепочки KUBE-MARK-DROP, KUBE-MARK-MASQ, KUBE-POSTROUTING и KUBE-KUBELET-CANARY (остается лишь KUBE-FIREWALL для обработки марсианских пакетов). Кроме того, опция предупреждает, что аргументы kubelet’а --iptables-masquerade-bit и --iptables-drop-bit устарели и больше не работают.

Minimizing iptables-restore input size

#3453, KEP

KEP повышает производительность работы kube-proxy в режиме iptables, убирая из вызовов к iptables-restore правила, которые не изменились (подробнее см. в обзоре нововведений Kubernetes 1.26).

Move EndpointSlice Reconciler into Staging

#3685, KEP

KEP перемещает согласователь EndpointSlice и его зависимости в staging, чтобы out-of-tree-контроллеры EndpointSlice могли использовать его логику.

Чтобы переместить код согласователя в staging/src/k8s.io/endpointslice и затем импортировать его как модуль Go, необходимо внести некоторые изменения в pkg/controller/endpointslice, а именно, превратить приватные методы в публичные и обновить пути импорта.

Перенос согласователя EndpointSlice в staging дает ряд преимуществ:

1. Кастомные контроллеры EndpointSlice могут использовать его код, который уже прошел несколько итераций и достиг определенной зрелости. Известны случаи, когда код согласователя был либо форкнут, либо переписан, что проблематично с точки зрения его поддержки.

2. Упрощает полный переход с Endpoints на EndpointSlices. Написать собственный контроллер Endpoints относительно просто, в то время как с EndpointSlices это сделать не так просто. Поэтому для уже существующих кастомных контроллеров Endpoints путь миграции неясен. Наличие библиотеки, обрабатывающей сложные аспекты управления EndpointSlices, позволило бы снизить риски, связанные с миграцией таких контроллеров.

3. Помогает воплотить одну из целей разработки EndpointSlices, а именно, реализацию других контроллеров для управления EndpointSlices (именно для этого и была добавлена аннотация endpointslice.kubernetes.io/managed-by).

API

Alpha-фичи

Allow informers for getting a stream of data instead of chunking

#3157, KEP

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

Идея в том, чтобы использовать потоковую передачу из watch-кэша вместо подкачки из etcd (то есть использовать обычную механику WATCH-запроса для получения потока отдельных объектов, но использовать ее для LIST-запросов). Это позволит снизить потребление памяти при LIST-запросах и сделать его более предсказуемым. Первоначально предлагаемые изменения будут применены к информерам, поскольку именно они обычно выступают главными пользователями LIST-запросов (подробнее о работе информеров см. в Приложении к KEP).

Consistent Reads from Cache

#2340, KEP

Запросы Get и List гарантированно являются «согласованными операциями чтения» (consistent reads), если не указан параметр resourceVersion. Такие операции производятся из etcd с использованием «кворумного чтения». При этом watch-кэш часто содержит достаточно актуальные данные для ответа на запрос на чтение, и может удовлетворить его гораздо эффективнее.

Мы уже рассказывали о том, как однажды столкнулись со множественными запросами к API-серверу Kubernetes от одного из приложений, к чему это привело и каким образом приходилось решать проблему.

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

Включить новое поведение можно с помощью feature gate WatchCacheConsistentReads. Кроме того, для него требуется функция WatchProgressRequest, которая появилась в версии 3.4 etcd.

CRD Validation Ratcheting

#4008, KEP

В нынешнем виде валидация полей, которые не менялись, выступает препятствием и для авторов CRD, и для разработчиков Kubernetes.

KEP добавляет feature flag CRDValidationRatcheting. Если флаг установлен, то обновления custom resources, не прошедшие валидацию, будут завершаться успешно в случае, когда ошибки валидации были связаны с ключевыми путями, которые не менялись. Например, имеется следующая CRD-схема:

properties:
    myField:
        type: string
    myOtherField:
        type: string

Мы применили следующий ресурс:

apiVersion: stable.example.com/v1
kind: MyCRD
myField: ""

Теперь предположим, что CRD-схема изменилась — критерии валидации ужесточились:

properties:
    myField:
        type: string
        minLength: 2
    myOtherField:
        type: string

При попытке изменить одно поле…

apiVersion: stable.example.com/v1
kind: MyCRD
myField: ""
myOtherField: newly added field

…контроллер получает ошибку:

* myField: Invalid value: "": myField in body should be at least 2 chars long

Еще более печально то, что при попытке внести патч с новым полем будет выдаваться ошибка по полям, которые в этот патч не включены. Например, следующий патч также приведет к ошибке выше:

myOtherField: newly added field

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

Unknown Version Interoperability Proxy

#4020, KEP

При наличии в кластере нескольких серверов API разных версий (например, при апгрейде, даунгрейде или при изменении runtime-конфига и перевыкате) не каждый сервер API может обработать все ресурсы каждой версии.

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

Разработчики полагаются на StorageVersion для выяснения того, какие группы, версии и ресурсы может обрабатывать тот или иной сервер API. Для этого он будет дополнен идентификатором сервера API и информацией о поддерживаемых версиях (подробнее см. в соответствующем разделе KEP).

Beta-фичи

CRD Validation Expression Language

#2876, KEP

KEP реализует упрощенный вариант проверки пользовательских ресурсов в CRD (Custom Resource Definition). Теперь, помимо вебхуков, для описания правил можно использовать скриптовый язык CEL. Подробнее см. в обзоре Kubernetes 1.23.

CEL for Admission Control

#3488, KEP

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

В группу 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.

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

Beta-фичи

Reduction of Secret-based Service Account Tokens

#2799; KEP

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

KMS v2 Improvements

#3299, KEP

KEP предусматривает поэтапное улучшение сервиса KeyManagementService, который используется для шифрования данных etcd по схеме envelope encryption. Предполагается сделать следующее:

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

• повысить надежность проверки работоспособности KMS-плагинов;

• улучшить наблюдаемость envelope-операций между kube-apiserver, KMS-плагинами и KMS.

Stable-фичи

Auth API to get self user attributes

#3325, KEP

Еще один KEP от от компании «Флант» переходит в stable-фазу. Он добавляет в группу authentication.k8s.io новый эндпоинт API — SelfSubjectReview. С его помощью можно увидеть атрибуты текущего пользователя после завершения процесса аутентификации. Делается это с помощью команды kubectl auth who-am-i. Подробнее см. в обзоре Kubernetes 1.26.

CLI

Alpha-фичи

kubectl delete: Add interactive(-i) flag

#3895, KEP

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

При добавлении флага --interactive/-i в команду kubectl delete пользователь сможет перепроверить себя до применения необратимого действия. Только ответив y (yes) он запустит процесс удаления — любое другое значение прервет команду c нулевым exit code.

Несколько примеров:

$ kubectl delete --interactive -f test_deployment.yaml 
You are about to delete the following 2 resource(s):
Deployment/dockerd
Deployment/dockerd2
Do you want to continue? (y/n): n
deletion is cancelled

$ kubectl delete -i -f test_deployment.yaml
You are about to delete the following 2 resource(s):
Deployment/dockerd
Deployment/dockerd2
Do you want to continue? (y/n): y
deployment.apps "dockerd" deleted
deployment.apps "dockerd2" deleted

Stable-фичи

kubectl events

#1440, KEP

KEP реализует независимую подкоманду events, которая снимает ограничения команды kubectl get events и добавляет новые возможности , такие как: фильтрация по типу, смена порядка сортировки, выборка событий только за последние N минут, просмотр события для конкретного объекта и т. д.

Разное

Alpha-фичи

Publishing Kubernetes packages on community infrastructure

#1731, KEP

Пять лет назад Google инициировала процесс передачи прав собственности на Kubernetes фонду CNCF. Управление проектом также должно было отойти к участникам сообщества. Прошлый релиз (1.27) отметился окончательным переключением трафика на собственный реестр Kubernetes registry.k8s.io. Новый KEP 1731 развивает идею миграции K8s на независимую от Google инфраструктуру и описывает ряд шагов, направленных на оптимизацию и упрощение релизного процесса. В частности, ставятся следующие задачи:

• сделать инфраструктуру достаточно простой и универсальной, чтобы ее можно было легко передать в CNCF;

• выбрать решение Packages as a Service (например, Open Build Service, и т. п.) или создать инфраструктуру вручную;

• запускать сборку пакетов как часть krel-стадии и релиза;

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

• обеспечить автоматическое подписание репозитория и пакетов;

• автоматически собирать и публиковать пакеты еженочно (необязательно).

Beta-фичи

Extend metrics stability

#3498, KEP

Порядок стабилизации метрик первоначально был введен для защиты значимых метрик от проблем при использовании в downstream. Метрики могут быть alpha или stable. Гарантировано стабильны только stable-метрики.

KEP вводит дополнительные классы стабильности — в первую очередь, чтобы синхронизировать этапы стабилизации метрик с этапами стабилизации релизов Kubernetes. Такая необходимость стала очевидной с появлением проверки готовности новых фич к production (production readiness review process) и обратной связи от рецензентов, которые сообщали о том, что иногда метрики упускаются из виду или их путают с событиями. Подробнее см. в обзоре Kubernetes 1.26.

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

Ниже приведен список переключателей функциональности, флагов и т. п., которые признаны устаревшими в Kubernetes 1.28:

Изменившиеся версии API:

• KubeSchedulerConfiguration: v1beta2 ➜ v1.

• SelfSubjectReview: v1beta1 ➜ v1.

• ValidatingAdmissionPolicy: v1alpha1 ➜ v1beta1.

• ValidatingAdmissionPolicyBinding: v1alpha1 ➜ v1beta1.

Устаревшие примитивы — желательно перейти на альтернативу:

• in-tree-плагин томов CephFS: используйте драйвер CephFS CSI.

• in-tree-плагин томов RBD: используйте драйвер RBD CSI.

• k8s.io/code-generator: generate_groups.sh и generate_internal_groups.sh ➜ kube_codegen.sh.

• kube-controller-manager: флаги --volume-host-cidr-denylist и --volume-host-allow-local-loopback.

• kubelet: --azure-container-registry-config ➜ --image-credential-provider-config и --image-credential-provider-bin-dir.

• метрики:

  • apiserver_flowcontrol_request_concurrency_in_use ➜ apiserver_flowcontrol_current_executing_seats.

  • apiserver_storage_db_total_size_in_bytes ➜ apiserver_storage_size_bytes metric.

Удаленные примитивы:

• NetworkPolicyStatus;

• kubectl version теперь возвращает kubectl version --short, флаг --short удален;

• KUBECTL_EXPLAIN_OPENAPIV3.

Другие изменения:

• сервер метрик обновлен до версии 0.6.3;

• metric-resolution сервера метрик теперь составляет 15 с;

• текстовый вывод Klog теперь использует JSON для structs, maps и slices;

• etcd обновлен до версии 3.5.9-0;

• cri-tools обновлен до версии 1.27.0;

• distroless-iptables обновлен до версии 0.2.6.

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

P.S.

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

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

• Kubernetes 1.26: обзор нововведений, включая первый KEP «Фланта»

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

• Крупнейшее изменение системы аутентификации в K8s за последние годы: новый KEP от «Фланта», Google и Microsoft