Kubernetes 1.23: обзор основных новшеств

Этой ночью официально выпустят новую версию 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 проще гуглить по-английски.

Хранилище

Honor Persistent Volume reclaim policy

#2644; KEP; Alpha

Политика возврата (reclaim policy) томов типа Persistent Volume (PV) может не соблюдаться, если PV работает в связке с PVC (Persistent Volume Claim): 

• PV соблюдает политику, если PVC удаляется до удаления PV.

• Если первым из пары удаляется PV, политика возврата не выполняется, а связанный с PV внешний ресурс хранения не удаляется.

Альфа-версия новой фичи отвечает за обязательное соблюдение политики возврата PV, если его удаление происходит раньше, чем удаление PVC. Как это обеспечивается:

• добавляется метка deletionTimestamp, которая вызывает обновление;

• если обновление обрабатывается до того, как PVC удален, удаление связанного PV игнорируется.

FSGroup to CSI driver on mount

#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.

Recovery from volume expansion failure

#1790; KEP; Alpha

С помощью PVC можно расширять емкость хранилища, запрашивая у провайдера том нужного объема. Иногда пользователи запрашивают больше, чем может выдать провайдер — например, 500 Гб, когда доступно только 100. При этом контроллер, который отвечает за расширение томов, хотя и получает отказ, продолжает повторять запросы. Процесс зацикливается.

С новым улучшением пользователи могут отменить запрос на расширение, если он еще не завершен или некорректен, и повторить его, указав меньший объем тома с помощью параметра pvc.Spec.Resources. Для это реализовано три ключевых изменения:

• ослаблена проверка API при обновлении PVC, чтобы разрешить уменьшение pvc.Spec.Resources;

• в API добавлено поле pvc.Status.AllocatedResources, чтобы отслеживать размер хранилища;

• добавлено поле pvc.Status.ResizeStatus, чтобы отслеживать статус процесса изменения размера тома.

Авторы KEP’а приводят алгоритм обработки запроса на изменение PVC:

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

Миграции на CSI

Примечание

Для более детального знакомства с CSI рекомендуем статьи:
«Понимаем Container Storage Interface (в Kubernetes и не только)»;
«Плагины томов для хранилищ в Kubernetes: от Flexvolume к CSI».

Portworx file in-tree to CSI driver migration

#2589; Alpha

Очередной прогресс в рамках большого проекта по миграции со встроенных в кодовую базу Kubernetes плагинов (in-tree) на CSI-драйверы. На этот раз свой CSI-драйвер получило хранилище Portworx от компании Pure Storage. Подробнее об этом драйвере можно почитать в документации проекта. 

Ceph RBD in-tree provisioner to CSI driver migration

#2923; KEP; Alpha

Фича, при активации которой все операции с плагинами RBD перенаправляются на внешний CSI-драйвер для Ceph. К слову, этот CSI-драйвер помогает избавиться от проблемы с блокировкой RBD, с которой мы регулярно сталкиваемся на практике при использовании containerd.

Stable-фичи

До стабильного уровня дошли:

• 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).

API

CRD Validation Expression Language

#2876; KEP; Alpha

Новая фича предлагает упрощенный вариант проверки пользовательских ресурсов (custom resources), которые добавляются в CRD (Custom Resource Definition). Ранее для этого использовались только вебхуки, в которых прописывались правила проверки. Такой механизм усложнял разработку и мог влиять на работоспособность CRD. Теперь правила можно писать на скриптовом языке Common Expression Language (CEL) прямо в схемах ​​CustomResourceDefinition с помощью x-kubernetes-validations extension:

...
openAPIV3Schema:
  type: object
  properties:
    spec:
      type: object
      x-kubernetes-validation-rules:
        - rule: "self.replicas <= self.maxReplicas"
          message: "replicas should be smaller than or equal to maxReplicas."
      properties:
        ...
        replicas:
          type: integer
        maxReplicas:
          type: integer
      required:
        - replicas
        - maxReplicas

CEL — достаточно легкий, простой и безопасный язык. Он поддерживает предварительный анализ и проверку выражений, чтобы обнаруживать синтаксические и другие ошибки во время проверки custom resources.

OpenAPI enum types

#2887; KEP; Alpha

Альфа-версия улучшения в OpenAPI, который теперь поддерживает перечисления, то есть данные типа enum. По умолчанию данные enum отображаются в конфигурации API как обычные строки с комментариями, в которых указывается тип данных. Это усложняет код и приводит к дублированию.

Теперь, если определить значения как строки:

type Protocol string
const (
	ProtocolTCP Protocol = "TCP"
	ProtocolUDP Protocol = "UDP"
	ProtocolSCTP Protocol = "SCTP"
)

… то далее с помощью маркера +enum можно явно вводить алиас, который найдет и использует все нужные возможные значения:

// +enum
type Protocol string

Генератор OpenAPI поймет, что допустимые значения — только TCP, UDP и SCTP.

Beta

Повысился статус у фичи Priority and Fairness Server Requests (#1040), которая предлагает более продвинутую систему приоритизации запросов типа max-in-flight. Подробнее о новом обработчике запросов мы рассказывали в обзоре K8s 1.18.

Узлы

cAdvisor-less, CRI-full Container and Pod stats

#2371; KEP; Alpha

Усовершенствование обобщает усилия по организации процесса, при котором вся статистика о запущенных контейнерах и Pod’ах извлекается из Container Runtime Interface (CRI). Тем самым отпадает необходимость в cAdvisor. 

В числе причин, по которым решили отказаться от cAdvisor: 

• среда исполнения контейнеров лучше «осведомлена» об их поведении, чем cAdvisor;

• cAdvisor не поддерживает некоторые среды, например виртуальные машины, а также Windows-контейнеры;

• сейчас метрики, которые обслуживают API и endpoint /metrics/cadvisor, собираются преимущественно cAdvidor’ом и дополняются CRI. Наличие двух источников лишает процесс ясности и приводит к дублированию. 

Поэтому было решено улучшить возможности CRI, чтобы предоставлять все требуемые метрики. Фича активируется с помощью feature gate PodAndContainerStatsFromCRI.

CPUManager policy option to distribute CPUs across NUMA nodes

#2902; KEP; Alpha

Политика CPU Manager получила обновление в альфа-версии, которое улучшает распределение ресурсов ЦПУ при работе с NUMA-узлами (Non-Uniform Memory Architecture). 

По умолчанию CPU Manager выделяет процессоры NUMA-узлам последовательно из общего пула ресурсов: сначала одному, затем второму и так далее. У некоторых узлов при этом может быть меньше ресурсов, чем у других — например, потому, что общий ресурс ЦПУ ограничен. Это приводит к появлению узких мест при исполнении параллельного кода, основанного на барьерах и других примитивах синхронизации. Код такого рода выполняется настолько быстро, насколько позволяет самый медленный worker — в нашем случае это тот NUMA-узел, которому досталось меньше процессорной мощности.

Новая фича распределяет ресурсы ЦПУ равномерно между всеми NUMA-узлами. Это ускоряет общую производительность приложений, которые создаются под NUMA-архитектуру. Опция устанавливается с помощью параметра distribute-cpus-across-numa в настройке политики CPU Manager типа static и активируется, когда запрос на ресурсы поступает от двух и более узлов.

Add gRPC probe to Pod

#2727; KEP; Alpha

Liveness-, Readiness- и Startup probes — три разных типа проверки состояния Pod’а. Сейчас они работают по протоколам HTTP(S) и TCP. Новая фича добавляет поддержку gRPC — открытого фреймворка для удаленного вызова процедур, который часто используется в микросервисной архитектуре. 

Возможность использовать встроенный gRPC среди прочего избавляет от необходимости использовать сторонние инструменты для проверки состояния контейнеров вроде grpc_health_probe(1). Вот как выглядит вариант конфигурации для readinessProbe:

    readinessProbe:
      grpc:                     
        port: 9090              
        service: my-service     
      initialDelaySeconds: 5
      periodSeconds: 10

Beta-фичи

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.

Приложения

Add count of ready Pods in Job status

#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’ы.

Beta-фичи

Job tracking without lingering Pods. Функция, которая позволяет Job’ам быстрее удалять неиспользуемые Pod’ы, чтобы освободить ресурсы кластера. Подробнее — в нашем предыдущем обзоре и в KEP.

Add minReadySeconds to StatefulSets. Возможность указывать в настройках StatefulSets минимальное количество секунд, за которые созданный Pod должен перейти в состояние готовности (KEP). То же самое ранее было реализовано, например, для Deployment и DaemonSet.

Stable-фичи

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).

Разное

Identify Pod's OS during API Server admission (Windows)

#2802; KEP; Alpha

По умолчанию при подключении Pod’а к API-серверу его ОС не идентифицируется. Поэтому некоторые плагины доступа — такие как PodSecurityAdmission — могут накладывать ненужные ограничения безопасности на Pod и мешать его работе. Другие же плагины, наоборот, вообще не применяют ограничения безопасности, что еще хуже.

Теперь плагины доступа могут автоматически определять ОС контейнеров Pod’а непосредственно во время подключения к API-серверу. Фича реализована с помощью добавления нового поля OS в спецификации PodSpec.

Deprecate klog specific flags in Kubernetes components

#2845; KEP; Alpha 

klog — библиотека для записи логов, реализованная на Go. klog применяется для логирования компонентов ядра K8s: kube-apiserver, kube-controller-manager, kube-scheduler, kubelet. У библиотеки масса недостатков. Например, запись логов при помощи klog в 7-8 раз медленнее, чем в JSON-формате. Еще — внушительное legacy от родительского проекта glog.

Сообщество решило, что устранять все проблемы и поддерживать klog нецелесообразно. Вместо этого предлагается использовать альтернативные форматы и оптимизировать существующие, например JSON. В этом релизе поддержка флагов для настройки klog признается устаревшей, а позже будет удалена (когда именно — пока неизвестно).

kubeadm: replace the legacy kubelet-config-x.y naming

#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.

kubectl events

#1440; KEP; Alpha

Существующий способ получить информацию о событиях в кластере — команда kubectl get events. У нее есть ограничения: события сортируются только по времени, причем: 

• сортировка неупорядоченная; 

• вывод команды с опцией --watch неинформативный, а иногда избыточный;

• есть и другие проблемы. 

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

Stable-фичи

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.

P.S.

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

• «Разработчики Kubernetes: Все ли готовы к отказу от Docker?»;

• «Kubernetes 1.22: обзор основных новшеств»;

• «В Kubernetes 1.22 режим seccomp сделают активным по умолчанию»;

• «Kubernetes 1.20: обзор основных новшеств».