Этой ночью официально выпустят новую версию Kubernetes — 1.23. Рассказываем о самых интересных нововведениях (alpha), а также о некоторых фичах, которые перешли на уровень выше (beta, stable).
Для подготовки статьи использовалась информация из таблицы Kubernetes enhancements tracking, CHANGELOG-1.23, обзор Sysdig, а также конкретные issues, pull requests и Kubernetes Enhancement Proposals (KEPs).
В новом релизе 47 улучшений — это на 9 меньше, чем в прошлом. Из них:
Примечание
Мы сознательно не стали переводить названия фич на русский. Они преимущественно состоят из специальной терминологии, с которой инженеры чаще встречаются в оригинальной формулировке. К тому же соответствующие issues и KEPs проще гуглить по-английски.
Политика возврата (reclaim policy) томов типа Persistent Volume (PV) может не соблюдаться, если PV работает в связке с PVC (Persistent Volume Claim):
Перед тем, как 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.
С помощью PVC можно расширять емкость хранилища, запрашивая у провайдера том нужного объема. Иногда пользователи запрашивают больше, чем может выдать провайдер — например, 500 Гб, когда доступно только 100. При этом контроллер, который отвечает за расширение томов, хотя и получает отказ, продолжает повторять запросы. Процесс зацикливается.
С новым улучшением пользователи могут отменить запрос на расширение, если он еще не завершен или некорректен, и повторить его, указав меньший объем тома с помощью параметра pvc.Spec.Resources. Для это реализовано три ключевых изменения:
Также приводится шесть примеров различных пользовательских сценариев, при которых фича может быть полезна.
Для более детального знакомства с CSI рекомендуем статьи:
«Понимаем Container Storage Interface (в Kubernetes и не только)»;
«Плагины томов для хранилищ в Kubernetes: от Flexvolume к CSI».
Очередной прогресс в рамках большого проекта по миграции со встроенных в кодовую базу Kubernetes плагинов (in-tree) на CSI-драйверы. На этот раз свой CSI-драйвер получило хранилище Portworx от компании Pure Storage. Подробнее об этом драйвере можно почитать в документации проекта.
Фича, при активации которой все операции с плагинами RBD перенаправляются на внешний CSI-драйвер для Ceph. К слову, этот CSI-драйвер помогает избавиться от проблемы с блокировкой RBD, с которой мы регулярно сталкиваемся на практике при использовании containerd.
Новая фича предлагает упрощенный вариант проверки пользовательских ресурсов (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. По умолчанию данные enum отображаются в конфигурации API как обычные строки с комментариями, в которых указывается тип данных. Это усложняет код и приводит к дублированию.
Теперь, если определить значения как строки:
type Protocol string
const (
ProtocolTCP Protocol = "TCP"
ProtocolUDP Protocol = "UDP"
ProtocolSCTP Protocol = "SCTP"
)
… то далее с помощью маркера +enum можно явно вводить алиас, который найдет и использует все нужные возможные значения:
// +enum
type Protocol string
Генератор OpenAPI поймет, что допустимые значения — только TCP, UDP и SCTP.
Усовершенствование обобщает усилия по организации процесса, при котором вся статистика о запущенных контейнерах и Pod’ах извлекается из Container Runtime Interface (CRI). Тем самым отпадает необходимость в cAdvisor.
В числе причин, по которым решили отказаться от cAdvisor:
Политика CPU Manager получила обновление в альфа-версии, которое улучшает распределение ресурсов ЦПУ при работе с NUMA-узлами (Non-Uniform Memory Architecture).
По умолчанию CPU Manager выделяет процессоры NUMA-узлам последовательно из общего пула ресурсов: сначала одному, затем второму и так далее. У некоторых узлов при этом может быть меньше ресурсов, чем у других — например, потому, что общий ресурс ЦПУ ограничен. Это приводит к появлению узких мест при исполнении параллельного кода, основанного на барьерах и других примитивах синхронизации. Код такого рода выполняется настолько быстро, насколько позволяет самый медленный worker — в нашем случае это тот NUMA-узел, которому досталось меньше процессорной мощности.
Новая фича распределяет ресурсы ЦПУ равномерно между всеми NUMA-узлами. Это ускоряет общую производительность приложений, которые создаются под NUMA-архитектуру. Опция устанавливается с помощью параметра distribute-cpus-across-numa в настройке политики CPU Manager типа static и активируется, когда запрос на ресурсы поступает от двух и более узлов.
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
Ephemeral Containers. «Эфемерные контейнеры» — легковесные контейнеры, которые помогают при отладке обычных контейнеров. Впервые фича появилась еще в Kubernetes 1.16. По своему назначению «эфемерные контейнеры» схожи с плагином kubectl-debug, необходимость в котором теперь отпадает.
Kubelet CRI Support. Поддержка CRI (Container Runtime Interface). Меж тем распространение исполняемых сред на базе CRI типа containerd растет и CRI-O на фоне приближающегося устаревания Dockershim.
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’ы.
Add minReadySeconds to StatefulSets. Возможность указывать в настройках StatefulSets минимальное количество секунд, за которые созданный Pod должен перейти в состояние готовности (KEP). То же самое ранее было реализовано, например, для Deployment и DaemonSet.
TTL after finish. Фича автоматически очищает Job’ы в статусе Finished или Complete. Это помогает снизить нагрузку на API-сервер, потому что в противном случае система продолжает считать эти Job’ы незавершенными.
Две фичи перешли в категорию stable:
По умолчанию при подключении Pod’а к API-серверу его ОС не идентифицируется. Поэтому некоторые плагины доступа — такие как PodSecurityAdmission — могут накладывать ненужные ограничения безопасности на Pod и мешать его работе. Другие же плагины, наоборот, вообще не применяют ограничения безопасности, что еще хуже.
Теперь плагины доступа могут автоматически определять ОС контейнеров Pod’а непосредственно во время подключения к API-серверу. Фича реализована с помощью добавления нового поля OS в спецификации PodSpec.
klog — библиотека для записи логов, реализованная на Go. klog применяется для логирования компонентов ядра K8s: kube-apiserver, kube-controller-manager, kube-scheduler, kubelet. У библиотеки масса недостатков. Например, запись логов при помощи klog в 7-8 раз медленнее, чем в JSON-формате. Еще — внушительное legacy от родительского проекта glog.
Сообщество решило, что устранять все проблемы и поддерживать klog нецелесообразно. Вместо этого предлагается использовать альтернативные форматы и оптимизировать существующие, например JSON. В этом релизе поддержка флагов для настройки klog признается устаревшей, а позже будет удалена (когда именно — пока неизвестно).
Фича меняет формат именования правил для ConfigMap и RBAC. Привычный формат выглядит так: kubelet-config-x.y, где x — мажорная версия Kubernetes, y — минорная (например: kubelet-config-1.23). Новое именование исключает -x.y. Чем это мотивировано:
Существующий способ получить информацию о событиях в кластере — команда kubectl get events. У нее есть ограничения: события сортируются только по времени, причем:
Defend against logging secrets via static analysis. Защита от логирования секретов на основе статического анализа (#1933). Подробнее о работе фичи и причинах ее появления — в нашем обзоре K8s 1.20.
Reduce Kubernetes build maintenance. Улучшение во внутренней инфраструктуре Kubernetes, которое обобщает проделанную работу по перемещению всех сценариев сборки K8s в make build и удалению bazel build (KEP).
habr.com
Для подготовки статьи использовалась информация из таблицы 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 внешний ресурс хранения не удаляется.
- добавляется метка 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, чтобы отслеживать статус процесса изменения размера тома.
Также приводится шесть примеров различных пользовательских сценариев, при которых фича может быть полезна.
Миграции на 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. Наличие двух источников лишает процесс ясности и приводит к дублированию.
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; AlphaLiveness-, 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; AlphaJob 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; Alphaklog — библиотека для записи логов, реализованная на 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 не удаляются.
kubectl events
#1440; KEP; AlphaСуществующий способ получить информацию о событиях в кластере — команда kubectl get events. У нее есть ограничения: события сортируются только по времени, причем:
- сортировка неупорядоченная;
- вывод команды с опцией --watch неинформативный, а иногда избыточный;
- есть и другие проблемы.
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 1.23: обзор основных новшеств
Этой ночью официально выпустят новую версию Kubernetes — 1.23. Рассказываем о самых интересных нововведениях (alpha), а также о некоторых фичах, которые перешли на уровень выше (beta, stable). Для...
habr.com