Этой ночью официально выпустят новую версию 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
Политика возврата (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
Перед тем, как 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
С помощью 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
Фича, при активации которой все операции с плагинами 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
Новая фича предлагает упрощенный вариант проверки пользовательских ресурсов (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
Альфа-версия улучшения в 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
Усовершенствование обобщает усилия по организации процесса, при котором вся статистика о запущенных контейнерах и 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
Политика 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
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
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)
По умолчанию при подключении Pod’а к API-серверу его ОС не идентифицируется. Поэтому некоторые плагины доступа — такие как PodSecurityAdmission
— могут накладывать ненужные ограничения безопасности на Pod и мешать его работе. Другие же плагины, наоборот, вообще не применяют ограничения безопасности, что еще хуже.
Теперь плагины доступа могут автоматически определять ОС контейнеров Pod’а непосредственно во время подключения к API-серверу. Фича реализована с помощью добавления нового поля OS
в спецификации PodSpec
.
Deprecate klog specific flags in Kubernetes components
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
Фича меняет формат именования правил для 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
Существующий способ получить информацию о событиях в кластере — команда 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.
Читайте также в нашем блоге:
Автор: Oleg Zinovyev