Этой ночью представят новую версию Kubernetes. Удаление Dockershim — если не самое значимое, то уж точно самое обсуждаемое изменение в релизе 1.24. Также среди интересных нововведений: «мониторинг здоровья» томов; Network Policy Status для оценки состояния подресурсов; набор тестов, с помощью которых определяется готовность Windows-кластеров к production.

В обзоре рассказываем обо всех улучшениях — новых (alpha) и о тех, что перешли на уровень выше (beta, stable).

Для подготовки статьи использовалась информация из таблицы Kubernetes enhancements tracking, CHANGELOG-1.24, обзора Sysdig, а также конкретные issues, pull requests и Kubernetes Enhancement Proposals (KEPs).

Всего в новом релизе 45 изменений. Из них:

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

• 15 продолжают улучшаться (beta);

• 15 признаны стабильными (stable);

• 2 устарели.

Примечание

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

Dockershim removal

#2221; KEP, Stable

Поддержку Docker в kubelet признали устаревшей в конце 2020 года. Главная причина — проблемы с обслуживанием модуля dockershim, который реализует CRI для Docker. Вместо dockershim рекомендуется использовать containerd и CRI-O — проекты, готовые к production. В сообществе говорят, что избавление от Docker пойдет на пользу всем: и разработчикам, и инженерам, которые обслуживают кластеры K8s. Решение позиционируется как возможность дать больше гарантий стабильности и совместимости.

Полезные статьи для тех, кто планирует миграцию:

• Is Your Cluster Ready for v1.24?

• Migrating from dockershim

• Dockershim removal FAQ

Хранилище

CSI volume health monitoring

#1432; KEP; Alpha

Сейчас в K8s нельзя отслеживать состояние Persistent Volumes (PV) после их создания. Из-за этого, когда возникают проблемы с PV, выявить исходную причину не просто. Например, приложение сигнализирует, что больше не может записывать данные в PV, но почему — не ясно. Возможно, у PV закончилась свободная емкость. Или кто-то случайно удалил PV во внешнем хранилище. А если хранилище локальное, причиной могло стать отключение узла.

С новой функцией, буквально — «мониторингом здоровья» томов, проблемы с PV можно выявлять раньше, а исправлять быстрее. Для этого в архитектуру CSI добавлены два новых компонента:

1. внешний контроллер, который разворачивается как sidecar CSI-контроллера — по аналогии с тем, как разворачивается external-provisioner. Он отслеживает состояние CSI-томов и события, связанные с отказом узлов. Также контроллер может сообщать дополнительную информацию с помощью уже существующей функции NodeGetVolumeStats (kubelet использует ее для сбора данных о томах);

2. внешний Node-агент, который разворачивается как sidecar вместе с CSI node driver на каждом рабочем узле Kubernetes. Контролирует процесс монтирования PV.

Информацию о состоянии томов kubelet передает в виде метрик VolumeStats. Если том «нездоров», метрика kubelet_volume_stats_health_status_abnormal будет снабжена лейблом persistentvolumeclaim со значением 1; в противном случае — со значением 0.

Non-graceful node shutdown

#2268; KEP; Alpha 

В конце 2020-го в Kubernetes 1.20 появилась альфа-версия фичи Graceful Node Shutdown (KEP-2000). Если фича активна, kubelet «мягко» (graceful) выключает Pod'ы на узлах, которые завершают работу. 

Однако в некоторых случаях Node Shutdown Mananger не замечает, что узел отключен — например, из-за того, что пользователь неправильно заполнил поля ShutdownGracePeriod и ShutdownGracePeriodCriticalPods. Тогда Pod’ы, которые запущены StatefulSet’ом на выключенном узле, подвисают в статусе Terminating. При этом StatefulSet не может пересоздать Pod’ы на другом узле. Ситуация усугубляется, если Pod’ы используют тома: VolumeAttachments так и останутся привязанными к подвисшим Pod’ам. Приложение, запущенное в StatefulSet’е, будет работать некорректно.

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

Фича полезна не только для случаев, связанных с ошибочной конфигурацией Graceful Node Shutdown. Она может пригодиться, например, когда подвисание Pod’ов вызвано ошибками на уровне «железа» или из-за проблем с ОС узла.

Control volume mode conversion between source and target PVC

#3141; KEP; Alpha

С помощью API-ресурса VolumeSnapshot можно создавать PVC (PersistentVolumeClaim) из снапшота. Это делается через установку в PVC параметра Spec.dataSource, который указывает на существующий ​​VolumeSnapshot. При этом нет никакого механизма проверки, соответствует ли режим доступа к тому у вновь созданного PVC режиму доступа, заданному для исходного PVC. Авторы KEP’а считают, что это брешь, которой могут воспользоваться злоумышленники, чтобы взломать ядро Linux.

Пример негативного сценария

Пользователь:
1) создает PVC с параметром volumeMode: Block и запускает Pod с этим томом;
2) записывает на том модифицированные данные в формате ext4;
3) делает снапшот этого тома;
4) создает PVC с параметром volumeMode: Filesystem из снапшота выше;
5) использует этот PVC в Pod’е.

Далее kubelet пытается смонтировать том в процессе создания Pod’а. Пользователь при этом может взломать ядро, если в нем есть уязвимость.

Чтобы улучшить контроль режима доступа к тому: 

• внесены изменения в спецификацию API VolumeSnapshotContent: появилось новое поле SourceVolumeMode; в нем устанавливается режим доступа к тому, с которого сделан снапшот;

• добавлена аннотация со ссылкой на ресурс, который может использовать доверенный пользователь для VolumeSnapshot;

• изменены методы контроля за snapshot-controller и external-provisioner.

В качестве примера потенциально опасной уязвимости авторы KEP’а приводят CVE-2020-12655 — с ее помощью можно запустить DoS-атаку на ядро. Однако сейчас нет ни одной известной CVE, которая бы реально угрожала ядру (при работе с K8s), поэтому фича, по сути, защищает от гипотетических угроз.

Beta-фичи

Volume populator — функция, представленная в Kubernetes 1.18 и заложившая основу для создания томов с предварительно загруженными на них данными — Generic Data Populators (KEP). Чтобы источниками данных могли быть объекты произвольных типов, ослаблена валидация поля DataSource. Примеры: 

• предварительная загрузка диска виртуальной машины образом ОС;

• включение резервного копирования и восстановления данных.

Azure file in-tree to CSI driver migration подытоживает работу по переносу плагина Azure File за пределы «дерева» K8s (out-of-tree). Также это часть глобального проекта по миграции со встроенных (in-tree) плагинов на CSI-драйверы.

Always honor reclaim policy отвечает за обязательное соблюдение политики возврата PV, если его удаление происходит раньше, чем удаление PVC. Подробно об улучшении мы писали в обзоре Kubernetes 1.23.

Stable-фичи

CSI volume expansion — набор улучшений для расширения размера CSI-томов (PV). 

Storage Capacity Tracking предотвращает распределение Pod’ов по узлам, к которым подключены CSI-тома с недостаточной емкостью.

OpenStack in-tree to CSI driver migration подытоживает результат работы по переносу кода OpenStack Cinder за пределы «дерева» Kubernetes. 

Azure disk in-tree to CSI driver migration выводит Azure Disk за пределы кодовой базы Kubernetes.

Приложения

maxUnavailable for StatefulSets

#961; KEP; Alpha

Сейчас у Stateful-приложений плавающее обновление Pod’ов (rolling update) происходит последовательно, по одному Pod’у за раз. При этом Pod во время обновления удаляется и через некоторое время пересоздается. Плавающее обновление устанавливается в настройках StatefulSet’а в поле .spec.updateStrategy.type с помощью значения RollingUpdate.

Новая фича вводит в RollingUpdate дополнительное поле maxUnavailable, где указывается количество Pod’ов, которые можно обновить (и пересоздать) одновременно. Фича полезна, например, в случае stateful-приложений, реализующих подход с leader/followers: одновременное падение нескольких followers может быть менее критично, чем скорость обновления приложения. С помощью maxUnavailable выкат обновлений может происходить быстрее, чем сейчас.

Значение нового параметра нужно внимательно проверять. Если оно окажется слишком большим, плавающее обновление может переключиться на обновление типа recreate («пересоздание»), что приведет к недоступности сервиса.

TimeZone support in CronJob

#3140; KEP; Alpha

CronJob создает Job’ы в соответствии с графиком, который определен пользователем. Однако часовой пояс, используемый в процессе создания Job, соответствует часовому поясу kube-controller-manager’а. Если пользователь забыл это учесть, Job’а может быть выполнена не по плану.

Проблема решена с помощью нового поля в CronJob API — .spec.timeZone, где можно заранее установить часовой пояс для запуска Job.

Beta- и Stable-фичи

Track Ready Pods in Job status (Beta) снабжает API новым полем Job.status.ready для отслеживания всех Pod’ов в состоянии готовности, а не только в Running («запущен») или Pending («ожидает»). Аналогичный механизм ранее реализовали для Deployment и StatefulSet.

Indexed Job semantics in Job API (Stable) добавляет индексы завершения в Pod’ы тех Job, у которых количество завершений фиксировано. Фича помогает поддерживать нормальную работу сильно распараллеленных Job.

batch/v1: add suspend field to Jobs API (Stable) дает возможность приостанавливать Job’ы с помощью значения true в поле .spec.suspend и перезапускать позже, меняя значение на false.

Сеть

Network Policy Status

#2943; KEP; Alpha

Сейчас провайдеры Network Policy не предоставляют обратной связи о том, корректно ли настроена определенная политика. Пользователь может, к примеру, создать NetworkPolicy с неправильным набором портов, с протоколами, которые не поддерживаются провайдером, или не учесть некоторых ограничений. Однако никакой информации от провайдера о некорректной конфигурации пользователь не получает.

Фича добавляет новое поле в описании объекта NetworkPolicy с информацией о состоянии подресурса: NetworkPolicyStatus. Провайдер Network Policy сообщает о состоянии подресурса через контроллер конкретного объекта, к которому применяется политика. В целом фичу можно считать еще одним важным шагом, который поможет упростить отладку сетевых проблем в Kubernetes. 

Reserve Service IP Ranges For Dynamic and Static IP Allocation

#3070; KEP; Alpha

Когда пользователь создает сервис и назначает ему определенный статический Cluster IP, он может не знать, что этот адрес уже присвоен другому сервису динамически. Так возникают неожиданные конфликты. Например, администратор хочет автоматизировать некоторые параметры конфигурации кластера и зарезервировать диапазон IP для группы сервисов. Если при этом каком-нибудь сервису из группы будет назначен уже занятый IP-адрес, сервис не создастся.

Улучшение вводит жесткое закрепление определенного диапазона IP-адресов для статической и динамической раздачи — с тем, чтобы уменьшить вероятность конфликтов при создании сервисов со статическими IP.

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

Beta-фичи

Support of mixed protocols in Services with type=LoadBalancer разрешает назначать одни и те же порты для протоколов UDP и TCP в сервисах LoadBalancer. Например, один порт может обрабатывать и TCP-, и UDP-запросы от DNS- или SIP-сервера.

Service internal traffic policy расширяет возможности оптимизации трафика в кластере. С помощью поля spec.trafficPolicy в настройках объектов типа Service можно выбирать обычную маршрутизацию (Cluster), маршрутизацию с учетом топологии (Topology), жестко локализовать трафик на конкретном узле (Local) или сделать локализацию предпочтительной опцией (PreferLocal).

CLI

kubectl return code normalization (standardization)

#2551; KEP; Alpha

kubectl может вызываться внешними системными командами. При этом иногда сложно понять, была ли исходная команда kubectl выполнена корректно. А если была проблема — то где она: на стороне сервера, на стороне клиента или дело в ошибке внешней команды. Есть несколько issues на эту тему. Примеры:

• «kubectl diff --not-yet-supported возвращает 1, подразумевая "Обнаружены различия"» (#99354).

• «Неправильный код ошибки, если список определенных ресурсов пуст» (#847).

• «kubectl exec неожиданно завершается с кодом 0» (#73056).

Так возникла идея стандартизировать коды завершения kubectl для всех существующих команд. Для этого авторы KEP’а:

1. Определили большинство возможных ошибок на стороне клиента и сервера, с которыми может столкнуться запрос kubectl.

2. Составили таблицу с кодами ошибок, чтобы:

   а) разрешить внешним командам или подкомандам (например, diff и exec) как можно чаще возвращать свои коды завершения без изменений;

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

3. Реализовали общий метод, с помощью которого команды могут делегировать нормализацию (стандартизацию) кода завершения другой функции. 

Список новых кодов ошибок:

Фича активируется переменной KUBECTL_ERROR_CODES: ее значение должно быть непустым и отличным от 0 / false.

Add subresource support in kubectl

#2590; KEP; Alpha

Процесс извлечения продресурсов API-объектов status и scale через kubectl не очень удобен: приходится пользоваться kubectl --raw. А исправлять эти подресурсы можно только через curl. Это усложняет тестирование и отладку подресурсов.

Нововведение предлагает добавить новый флаг --subresource=[subresource-name] к командам kubectl get и kubectl patch. Это позволит извлекать и обновлять продресурсы status и scale, оперируя командами kubectl.

Например, для встроенных типов сочетание get и флага --subresource=status выдаст информацию о подресурсе по аналогии с тем, как это организовано для ресурса:

$ kubectl get deployment nginx-deployment --subresource=status
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           43s

$ kubectl get deployment nginx-deployment --subresource=scale
NAME               DESIREDREPLICAS   AVAILABLEREPLICAS
nginx-deployment   3                 3

То же самое — с Custom Resources:

$ kubectl get crontab cron --subresource=status
NAME   SPEC          REPLICAS   AGE
cron   * * * * */5   3          4m52s

$ kubectl get crontab cron --subresource=scale
NAME   DESIREDREPLICAS   AVAILABLEREPLICAS
cron   3                 0

Пример с patch, когда для встроенных типов нужно обновить spec.replicas:

$ kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":2}}'
scale.autoscaling/nginx-deployment patched

Далее можно увидеть, что spec.replicas обновлена для основного ресурса:

$ kubectl get deploy nginx-deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   2/2     2            2           4m

Также рассматривается возможность применять фичу и для команды kubectl apply — если будет соответствующий запрос от сообщества.

Узлы

Alpha-фич нет.

Beta- и Stable-фичи

Kubelet Credential Provider (Beta) заменяет встроенных поставщиков учетных данных container registry ACR, ECR и GCR внешними. Теперь kubelet может динамически получать учетные данные для любого облачного провайдера.

PriorityClassValueBasedGracefulShutdown (Beta) дает Pod’ам с высоким приоритетом больше времени на остановку, если они запущены на узлах с поддержкой «мягкого» выключения. Можно выбирать разное время в зависимости от значения priorityClassName. 

gRPC probes (Beta) появилась в альфа-версии в прошлом релизе K8s. Теперь liveness-, readiness- и startup-пробы, помимо HTTP(S) и TCP, поддерживают gRPC — открытый фреймворк для удаленного вызова процедур. gRPC популярен в микросервисной архитектуре. 

PodOverhead (Stable) разрешает Pod’у использовать дополнительные ресурсы сверх запрошенных, чтобы поддерживать среду исполнения. 

API

Alpha-фич нет.

Beta- и Stable-фичи

Beta Graduation Criteria for Field Validation (Beta) разрешает серверу не выполнять запрос на создание, обновление и изменение ресурса K8s, если в запросе указаны некорректные или неизвестные поля. Активируется через kubectl -validate=true.

OpenAPI enum types (Beta) расширяет возможности OpenAPI, который теперь поддерживает перечисления, то есть данные типа enum. Подробнее фиче — в нашем обзоре Kubernetes 1.23. 

OpenAPI v3 (Beta) добавляет kube-apiserver возможность обслуживать ресурсы и типы Kubernetes как объекты OpenAPI v3. Ранее конвертация определений OpenAPI v3 проводилась через CRD; делалось это не вполне корректно.

Efficient watch resumption (Stable) позволяет kube-apiserver’у после перезагрузки быстрее инициализировать watch-кэш.

Разное

A Windows-[operational readiness] definition and tooling convergence

#2578; KEP; Alpha

Поддержка Windows появилась в Kubernetes 1.14. С тех пор написано множество E2E-тестов, реализованных, например, с помощью Ginkgo («тесты на соответствие», или conformance tests). Однако их результаты мало говорят о реальной готовности K8s-кластера, которая требуется для бизнес-критичных приложений под Windows. Это связано с тем, что оценка production-готовности для Windows-кластеров проработана и стандартизована не так основательно, как для Linux-кластеров.

В рамках этого улучшения предусмотрено создание стандарта «готовности к эксплуатации» Kubernetes-кластеров на базе Windows. Он определяет готовность кластеров для запуска рабочих нагрузок в production, описывает правила создания и обслуживания существующих E2E-тестов, а также критерии соответствия Windows-кластера требованиям инструмента диагностики Sonobuoy. Еще одна задача стандарта — информировать рецензентов за пределами сообщества SIG-Windows об общих целях тестов.

Для оценки готовности Windows-кластеров планируется разработать тесты, которые покроют несколько областей:

• Базовое сетевое взаимодействие.

• Базовые служебные аккаунты и локальное хранилище.

• Базовое планирование.

• Базовая функциональность одновременной работы.

• Операционная готовность Windows HostProcess.

• Active Directory.

• Сетевые политики.

• Расширенные сетевые возможности Windows и проксирование служб.

• Конфигурация рабочих станций Windows.

Фича перейдет в статус бета-версии, когда будут внедрены основные тесты.

Contextual logging

#3077; KEP; Alpha

Это улучшение — очередной шаг, который снижает зависимость от klog (библиотеки логирования K8s) и ее ограничений. Контекстное логирование основано на структурированном, которое появилось в Kubernetes 1.19. Фича включает два изменения, ориентированных на разработчиков:

• Смена зависимостей: вместо глобального logger’а библиотеки теперь используют экземпляр, который им передается.

• Библиотеки могут использовать функции WithValues и WithName, чтобы добавлять дополнительную контекстную информацию logger’у (и на вывод лога).  

Новый logger может быть создан, например, с помощью WithName:

logger := klog.FromContext(ctx).WithName("foo")

Тогда при таком его вызове:

logger.Info("Done")

… вывод будет включать префикс foo. 

Один из актуальных кейсов — юнит-тестирование, когда разработчики хотят разделить логи каждого из тестов по отдельным выводам. Теперь это можно делать без необходимости изменять код библиотек.

Также смена зависимости помогает избавиться от влияния klog. Глобальный logger можно заменить на произвольную имплементацию logr.Logger.

Min domains in PodTopologySpread

#3022; KEP; Alpha

С помощью фичи Pod Topology Spread можно равномерно распределять Pod'ы по multi-zone-кластеру. У фичи есть параметр maxSkew; он контролирует, сколько Pod’ов может быть распределено неравномерно. Однако контроля количества доменов (topology domains — то есть регионов, зон и т. п.), по которым могут распределяться эти Pod’ы, нет. В некоторых случаях, например, требуется принудительно распределить Pod’ы по минимальному количеству доменов и, если доменов недостаточно, заставить Cluster Autoscaler их предоставить.

Может возникнуть и еще одна проблема: домен, который был перемасштабирован Cluster Autoscaler’ом до 0, становится невидимым для scheduler’а. Реальные ресурсы будут не востребованы.

Новая фича решает обе проблемы. Пользователь теперь может определить минимальное количество доменов, которые должны быть доступны — даже если они не существуют на момент планирования запуска новых Pod’ов. При необходимости домен будет масштабироваться, а Cluster Autoscaler — запрашивать новые узлы в пределах этого домена. 

Фича активируется через параметр minDomains — но при условии, что в поле whenUnsatisfiable установлено значение DoNotSchedule.

Пример:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 10
  template:
    metadata:
      labels:
        foo: bar
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
            - containerPort: 80
      topologySpreadConstraints:
        - maxSkew: 2
          minDomains: 5
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              foo: bar

Допустим, есть три узла, по которым могут распределяться Pod’ы. 6 из 10 Pod’ов будут распределены по этим трем узлам. Оставшиеся 4 Pod’а будут распределены, только если в кластер добавятся еще два узла. В итоге, согласно конфигурации, Deployment будет распределен по крайней мере по пяти узлам, и ограничение maxSkew будет соблюдено.

Signing release artifacts

#3031; KEP; Alpha

Улучшение нацелено на то, чтобы защитить ПО, развернутое в K8s, от атаки на цепочку поставок (supply chain attack). Для этого планируется определить и унифицировать способы подписи артефактов релиза, которые использует сообщество Kubernetes. Под артефактами подразумеваются бинарные файлы, образы, чек-суммы файлов, документация, метаданные и другое. За основу взят sigstore — проект Linux Foundation, который предлагает набор инструментов для цифровой подписи. 

Конкретный инструмент реализации безопасной цепочки поставки — cosign, утилита для подписи, проверки и хранения контейнеров в OCI-репозитории. 

Фичу переведут в статус Beta после того, как появится возможность подписывать стандартные для Kubernetes артефакты релиза — бинарники и образы; в Stable — когда механизм заработает для всех артефактов.

Beta-фичи

Reduction of Secret-based Service Account Tokens избавляет от необходимости использовать токен Secret с учетными данными для доступа к API. Теперь данные подтягиваются напрямую из TokenRequest API и монтируются в Pod с помощью защищенного тома.

Identify Windows pods at API admission level authoritatively добавляет поле OS в PodSpec, в котором можно указывать, на базе какой операционной системы должен запуститься Pod. Это расширяет возможности Kubernetes в части управления Pod’ами. Например, можно составить расписание работы Pod’ов на подходящих узлах и реализовать это через планировщик.

Deprecate klog specific flags in Kubernetes components реализует третий этап большого проекта по упрощению работы с логами в Kubernetes. Глобальная задача проекта — отказ от библиотеки klog. С этой фичей поддержка флагов для настройки klog признана устаревшей. По предварительным планам, флаги удалят в Kubernetes 1.26. Подробнее об улучшении — в нашем обзоре K8s 1.23.

Stable-фичи

Non-preempting Priority to GA добавляет опцию PreemptionPolicy: Never, при активации которой Pod’ы с высоким приоритетом могут быть размещены в очереди планировщика выше, чем низкоприоритетные. Однако при этом «привилегированные» Pod’ы не могут вытеснять другие Pod’ы.

Pod affinity NamespaceSelector to GA добавляет поле namespaceSelector в конфигурацию Pod’а, чтобы определять узлы по лейблу, а не по имени; делать это можно динамически. Фича расширяет возможности функции node affinity, с помощью которой Pod’ам можно указывать, на каких узлах им следует запускаться. Для этого используются лейблы. 

Service Type=LoadBalancer Class разрешает поддержку нескольких реализаций Service Type=LoadBalancer в кластере.

Leader migration to GA определяет процесс миграции для кластеров с жесткими требованиями к доступности управляющего слоя.

CSR Duration добавляет новое поле ExpirationSeconds в спецификацию CertificateSigningRequestSpec с возможностью устанавливать продолжительность действия сертификата с минимальным значением 600 секунд (10 минут).

Beta APIs are off by default запрещает использовать по умолчанию API, которые не достигли статуса Stable. Главная цель — уменьшить вероятность распространения багов. 

Некоторые из удаленных фич

• Экспериментальная функция динамической «санации» логов.

• Небезопасная конфигурация из пакета cloud-provider’а, которую использовали cloud-controller-managers.

• Флаги ​​--address и --port в kube-controller-manager.

• DynamicKubeletConfig в kubelet.

• Вместо VolumeSnapshot v1beta1 теперь нужно использовать v1.

• Вместо tolerate-unready-endpoints annotation в Service — Service.spec.publishNotReadyAddresses.

Обновления в зависимостях Kubernetes

• containerd v1.4.12;

• SELinux v1.10.0;

• eBPF v0.7.0;

• Go 1.17.4.

P.S.

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

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

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

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

• «На YouTube опубликован фильм Kubernetes: The Documentary. Мы добавили ему русские субтитры».