Этой ночью официально выпустят новую версию Kubernetes — 1.23. Рассказываем о самых интересных нововведениях (alpha), а также о некоторых фичах, которые перешли на уровень выше (beta, stable). Для подготовки статьи использовалась информация из таблицы Kubernetes enhancements tracking, CHANGELOG-1.23, обзор Sysdig, а также конкретные issues, pull requests и Kubernetes Enhancement Proposals (KEPs). В новом релизе 47 улучшений — это на 9 меньше, чем в прошлом. Из них: 19 новых функций (alpha);  17 продолжают улучшаться (beta); 11 признаны стабильными (stable). По количеству нововведений и функций, которые стабилизировались, в этот раз лидируют связанные с хранилищем — начнем с них. Мы сознательно не стали переводить названия фич на русский. Они преимущественно состоят из специальной терминологии, с которой инженеры чаще встречаются в оригинальной формулировке. К тому же соответствующие issues и KEPs проще гуглить по-английски. #2644; KEP; Alpha Политика возврата (reclaim policy) томов типа Persistent Volume (PV) может не соблюдаться, если PV работает в связке с PVC (Persistent Volume Claim):  PV соблюдает политику, если PVC удаляется до удаления PV. Если первым из пары удаляется PV, политика возврата не выполняется, а связанный с PV внешний ресурс хранения не удаляется. Альфа-версия новой фичи отвечает за обязательное соблюдение политики возврата PV, если его удаление происходит раньше, чем удаление PVC. Как это обеспечивается: добавляется метка deletionTimestamp, которая вызывает обновление; если обновление обрабатывается до того, как PVC удален, удаление связанного PV игнорируется. #2317; KEP; Alpha Перед тем, как CSI-том монтируется внутрь контейнера, Kubernetes изменяет владение томом через поле fsGroup. Для большинства плагинов kubelet делает это рекурсивно с помощью chown и chmod файлов и директорий. Но поскольку chown и chmod — Unix-примитивы, они недоступны для некоторых CSI-драйверов, например для AzureFile. Нововведение предлагает предоставить CSI-драйверу fsGroup Pod’ов в виде явного поля, чтобы применять политику сразу во время монтирования. Механизм активируется с помощью feature gate’а DelegateFSGroupToCSIDriver для CSI-драйверов, которые поддерживают node capability под названием VOLUME_MOUNT_GROUP. Поле fsGroup должно быть определено в securityContext. #1790; KEP; Alpha С помощью PVC можно расширять емкость хранилища, запрашивая у провайдера том нужного объема. Иногда пользователи запрашивают больше, чем может выдать провайдер — например, 500 Гб, когда доступно только 100. При этом контроллер, который отвечает за расширение томов, хотя и получает отказ, продолжает повторять запросы. Процесс зацикливается. С новым улучшением пользователи могут отменить запрос на расширение, если он еще не завершен или некорректен, и повторить его, указав меньший объем тома с помощью параметра pvc.Spec.Resources. Для это реализовано три ключевых изменения: ослаблена проверка API при обновлении PVC, чтобы разрешить уменьшение pvc.Spec.Resources; в API добавлено поле pvc.Status.AllocatedResources, чтобы отслеживать размер хранилища; добавлено поле pvc.Status.ResizeStatus, чтобы отслеживать статус процесса изменения размера тома. Авторы KEP’а приводят алгоритм обработки запроса на изменение PVC: Также приводится шесть примеров различных пользовательских сценариев, при которых фича может быть полезна. Для более детального знакомства с CSI рекомендуем статьи: «Понимаем Container Storage Interface (в Kubernetes и не только)»;«Плагины томов для хранилищ в Kubernetes: от Flexvolume к CSI». #2589; Alpha Очередной прогресс в рамках большого проекта по миграции со встроенных в кодовую базу Kubernetes плагинов (in-tree) на CSI-драйверы. На этот раз свой CSI-драйвер получило хранилище Portworx от компании Pure Storage. Подробнее об этом драйвере можно почитать в документации проекта.  #2923; KEP; Alpha Фича, при активации которой все операции с плагинами RBD перенаправляются на внешний CSI-драйвер для Ceph. К слову, этот CSI-драйвер помогает избавиться от проблемы с блокировкой RBD, с которой мы регулярно сталкиваемся на практике при использовании containerd. До стабильного уровня дошли: AWS EBS in-tree to CSI driver migration — миграция на CSI-драйвер для AWS EBS (#1487). Non-recursive volume ownership (FSGroup) — оптимизация процесса делегирования прав при bind-монтировании томов в контейнер (KEP).  Config FSGroup Policy in CSI Driver object — возможность для CSI-драйверов определять права доступа на основе FSGroup (KEP). ​​Generic inline ephemeral volumes — API, чтобы определять встроенные эфемерные тома непосредственно в спецификации Pod’ов (KEP). #2876; KEP; Alpha Новая фича предлагает упрощенный вариант проверки пользовательских ресурсов (custom resources), которые добавляются в CRD (Custom Resource Definition). Ранее для этого использовались только вебхуки, в которых прописывались правила проверки. Такой механизм усложнял разработку и мог влиять на работоспособность CRD. Теперь правила можно писать на скриптовом языке Common Expression Language (CEL) прямо в схемах ​​CustomResourceDefinition с помощью x-kubernetes-validations extension: CEL — достаточно легкий, простой и безопасный язык. Он поддерживает предварительный анализ и проверку выражений, чтобы обнаруживать синтаксические и другие ошибки во время проверки custom resources. #2887; KEP; Alpha Альфа-версия улучшения в OpenAPI, который теперь поддерживает перечисления, то есть данные типа enum. По умолчанию данные enum отображаются в конфигурации API как обычные строки с комментариями, в которых указывается тип данных. Это усложняет код и приводит к дублированию. Теперь, если определить значения как строки: … то далее с помощью маркера +enum можно явно вводить алиас, который найдет и использует все нужные возможные значения: Генератор OpenAPI поймет, что допустимые значения — только TCP, UDP и SCTP. Повысился статус у фичи Priority and Fairness Server Requests (#1040), которая предлагает более продвинутую систему приоритизации запросов типа max-in-flight. Подробнее о новом обработчике запросов мы рассказывали в обзоре K8s 1.18. #2371; KEP; Alpha Усовершенствование обобщает усилия по организации процесса, при котором вся статистика о запущенных контейнерах и Pod’ах извлекается из Container Runtime Interface (CRI). Тем самым отпадает необходимость в cAdvisor.  В числе причин, по которым решили отказаться от cAdvisor:  среда исполнения контейнеров лучше «осведомлена» об их поведении, чем cAdvisor; cAdvisor не поддерживает некоторые среды, например виртуальные машины, а также Windows-контейнеры; сейчас метрики, которые обслуживают API и endpoint /metrics/cadvisor, собираются преимущественно cAdvidor’ом и дополняются CRI. Наличие двух источников лишает процесс ясности и приводит к дублированию.  Поэтому было решено улучшить возможности CRI, чтобы предоставлять все требуемые метрики. Фича активируется с помощью feature gate PodAndContainerStatsFromCRI. #2902; KEP; Alpha Политика CPU Manager получила обновление в альфа-версии, которое улучшает распределение ресурсов ЦПУ при работе с NUMA-узлами (Non-Uniform Memory Architecture).  По умолчанию CPU Manager выделяет процессоры NUMA-узлам последовательно из общего пула ресурсов: сначала одному, затем второму и так далее. У некоторых узлов при этом может быть меньше ресурсов, чем у других — например, потому, что общий ресурс ЦПУ ограничен. Это приводит к появлению узких мест при исполнении параллельного кода, основанного на барьерах и других примитивах синхронизации. Код такого рода выполняется настолько быстро, насколько позволяет самый медленный worker — в нашем случае это тот NUMA-узел, которому досталось меньше процессорной мощности. Новая фича распределяет ресурсы ЦПУ равномерно между всеми NUMA-узлами. Это ускоряет общую производительность приложений, которые создаются под NUMA-архитектуру. Опция устанавливается с помощью параметра distribute-cpus-across-numa в настройке политики CPU Manager типа static и активируется, когда запрос на ресурсы поступает от двух и более узлов. #2727; KEP; Alpha Liveness-, Readiness- и Startup probes — три разных типа проверки состояния Pod’а. Сейчас они работают по протоколам HTTP(S) и TCP. Новая фича добавляет поддержку gRPC — открытого фреймворка для удаленного вызова процедур, который часто используется в микросервисной архитектуре.  Возможность использовать встроенный gRPC среди прочего избавляет от необходимости использовать сторонние инструменты для проверки состояния контейнеров вроде grpc_health_probe(1). Вот как выглядит вариант конфигурации для readinessProbe: Add options to reject non SMT-aligned workload. Фичу представили в предыдущем релизе. Благодаря ей CPU Manager более точечно распределяет ресурсы CPU между специфическими рабочими нагрузками. В частности — дает больший приоритет приложениям, адаптированным под одновременную многопоточность (SMT). Подробности — в KEP. Ephemeral Containers. «Эфемерные контейнеры» — легковесные контейнеры, которые помогают при отладке обычных контейнеров. Впервые фича появилась еще в Kubernetes 1.16. По своему назначению «эфемерные контейнеры» схожи с плагином kubectl-debug, необходимость в котором теперь отпадает. Kubelet CRI Support. Поддержка CRI (Container Runtime Interface). Меж тем распространение исполняемых сред на базе CRI типа containerd растет и CRI-O на фоне приближающегося устаревания Dockershim. #2879; KEP; Alpha Job controller отслеживает статус Job’ы по полю active (внутри Job.status.active), которое показывает количество запущенных Pod’ов в состоянии Running (запущен) или Pending (ожидает). В реальности Job’а может находиться в состоянии Pending долгое время — например, если у кластера ограниченные ресурсы и образы скачиваются медленно. Поскольку Job.status.active показывает еще и Pod’ы в состоянии ожидания, конечный пользователь или контроллер может не знать реального прогресса по запущенным Pod’ам — готовы они или нет. Это особенно важно, если Pod’ы работают как worker’ы и общаются между собой. Инициаторы улучшения предложили добавить в API поле Job.status.ready, чтобы отслеживать все Pod’ы в состоянии готовности. Этот принцип уже реализован для двух рабочих нагрузок — Deployment и StatefulSet. Новая фича избавит от необходимости контролировать отдельные Pod’ы. Job tracking without lingering Pods. Функция, которая позволяет Job’ам быстрее удалять неиспользуемые Pod’ы, чтобы освободить ресурсы кластера. Подробнее — в нашем предыдущем обзоре и в KEP. Add minReadySeconds to StatefulSets. Возможность указывать в настройках StatefulSets минимальное количество секунд, за которые созданный Pod должен перейти в состояние готовности (KEP). То же самое ранее было реализовано, например, для Deployment и DaemonSet. CronJobs периодически запускают в кластере Kubernetes задания по аналогии с тем, как это делает cron в UNIX-подобных системах. Фича была представлена в Kubernetes 1.4 и переведена в beta-статус в версии 1.8. TTL after finish. Фича автоматически очищает Job’ы в статусе Finished или Complete. Это помогает снизить нагрузку на API-сервер, потому что в противном случае система продолжает считать эти Job’ы незавершенными. Статус beta получило улучшение Topology Aware Hints, которое помогает контролировать трафик между зонами в мультикластерной инфраструктуре и увеличивать производительность сети (KEP). Две фичи перешли в категорию stable: Add IPv4/IPv6 dual-stack support. Поддержка двойного сетевого стека, которая позволяет назначать Pod’ам оба протокола (KEP). Namespace Scoped Ingress Class Parameters. Возможность определять в параметрах IngressClass пространство имен для scope (KEP). #2802; KEP; Alpha По умолчанию при подключении Pod’а к API-серверу его ОС не идентифицируется. Поэтому некоторые плагины доступа — такие как PodSecurityAdmission — могут накладывать ненужные ограничения безопасности на Pod и мешать его работе. Другие же плагины, наоборот, вообще не применяют ограничения безопасности, что еще хуже. Теперь плагины доступа могут автоматически определять ОС контейнеров Pod’а непосредственно во время подключения к API-серверу. Фича реализована с помощью добавления нового поля OS в спецификации PodSpec. #2845; KEP; Alpha  klog — библиотека для записи логов, реализованная на Go. klog применяется для логирования компонентов ядра K8s: kube-apiserver, kube-controller-manager, kube-scheduler, kubelet. У библиотеки масса недостатков. Например, запись логов при помощи klog в 7-8 раз медленнее, чем в JSON-формате. Еще — внушительное legacy от родительского проекта glog. Сообщество решило, что устранять все проблемы и поддерживать klog нецелесообразно. Вместо этого предлагается использовать альтернативные форматы и оптимизировать существующие, например JSON. В этом релизе поддержка флагов для настройки klog признается устаревшей, а позже будет удалена (когда именно — пока неизвестно). #2915; KEP; Alpha Фича меняет формат именования правил для ConfigMap и RBAC. Привычный формат выглядит так: kubelet-config-x.y, где x — мажорная версия Kubernetes, y — минорная (например: kubelet-config-1.23). Новое именование исключает -x.y. Чем это мотивировано:  ссылка на -x.y берется из управляющего слоя, хотя было бы логичнее — из kubelet; во время обновления новые правила ConfigMap и RBAC создаются с учетом новой версии K8s, но правила со старыми значениями -x.y не удаляются. Цель улучшения — устранить сложности, которые добавляет привычный процесс управления версиями, оставив единственным «источником правды» kube-system/kubelet-config. #1440; KEP; Alpha Существующий способ получить информацию о событиях в кластере — команда kubectl get events. У нее есть ограничения: события сортируются только по времени, причем:  сортировка неупорядоченная;  вывод команды с опцией --watch неинформативный, а иногда избыточный; есть и другие проблемы.  Новая команда kubectl events снимает эти ограничения и добавляет новые возможности. Теперь, например, определенные события можно отфильтровать по типу, менять порядок сортировки событий, отбирать события только за последние N минут, увидеть изменения конкретного объекта. Разработчики получают более детальную информацию о событиях, от которых непосредственно зависит работа приложения. HPA API. После пяти лет «боевой» эксплуатации в статусе beta и многих доработок 2-я версия ​HPA (Horizontal Pod Autoscaler) признана стабильной. Важно: это значит, что во всех манифестах с kind: HorizontalPodAutoscaler нужно заменить apiVersion: autoscaling/v2beta2 на apiVersion: autoscaling/v2. Defend against logging secrets via static analysis. Защита от логирования секретов на основе статического анализа (#1933). Подробнее о работе фичи и причинах ее появления — в нашем обзоре K8s 1.20. Reduce Kubernetes build maintenance. Улучшение во внутренней инфраструктуре Kubernetes, которое обобщает проделанную работу по перемещению всех сценариев сборки K8s в make build и удалению bazel build (KEP). Метрика scheduler_volume_scheduling_duration_seconds. Флаг --experimental-bootstrap-kubeconfig. Этап update-cluster-status при выполнении команды kubeadm reset. Kubectl-опция --dry-run теперь поддерживает только значения server, client или none. Обновления в зависимостях Kubernetes: cri-tools v1.22.0; etcd 3.5.1; используемая версия Go 1.17.3; containerd v1.4.11. Читайте также в нашем блоге: «Разработчики Kubernetes: Все ли готовы к отказу от Docker?»; «Kubernetes 1.22: обзор основных новшеств»; «В Kubernetes 1.22 режим seccomp сделают активным по умолчанию»; «Kubernetes 1.20: обзор основных новшеств».