Обзор нововведений Kubernetes 1.27

Режим stable

Заморозка реестра образов k8s.gcr.io

Проект Kubernetes создал и запускает реестр образов registry.k8s.io, который полностью контролируется сообществом. Это означает, что старый реестр k8s.gcr.io будет заморожен и никакие образы для Kubernetes и связанных с ним подпроектов не будут публиковаться в старом реестре.

Какие изменения это вносит для разработчиков и участников проекта?

Если вы являетесь контрибьютором подпроекта, вам необходимо обновить свои манифесты и Helm-чарты, чтобы использовать новый реестр. Детальнее вы можете ознакомиться здесь. 

Какие изменения это вносит для пользователей?

• • Релиз Kubernetes v1.27 не будет опубликован в реестре k8s.gcr.io.
  • Патч-релизы для v1.24, v1.25 и v1.26 больше не будут добавляться в старый реестр.
  • Начиная с версии v1.25, реестр образов по умолчанию установлен как registry.k8s.io. Это значение можно изменить в kubeadm и kubelet, но установка его как k8s.gcr.io не будет работать для новых релизов, так как они не будут доступны в старом реестре.
  • Если вы хотите повысить надежность вашего кластера и избавиться от зависимости от реестра, принадлежащего сообществу, рекомендуется рассмотреть возможность создания локальных зеркал реестров. Некоторые облачные провайдеры могут предоставлять готовые решения для этого.

Изменяемые директивы планирования для suspended Jobs  переходят в режим stable 

Эта возможность была впервые представлена в версии v1.22 в качестве бета-версии. Начиная с Kubernetes 1.22, появилась возможность обновлять поля node affinity, node selector, tolerations, labels ,annotations и scheduling gates в шаблоне пода Job’а перед его запуском. Это возможно только для suspended джоб,  которые ранее не были возобновлены.Это позволяет контролировать, где будут запущены поды, например, в одной зоне или на узлах с одинаковой моделью GPU. 

Детальнее вы можете ознакомиться здесь.

Бета-версия

Pod Scheduling Readiness переходит в бета-версию

Поды считаются готовыми к планированию сразу после того, как созданы. Планировщик Kubernetes находит узлы для размещения всех ожидающих подов. Однако в реальности некоторые поды могут находиться в состоянии miss-essential-resources (“отсутствия необходимых ресурсов”) в течение длительного времени. Эти поды «сбивают с толку» планировщик и компоненты типа Cluster Autoscaler.

Путем указания/удаления поля .spec.schedulingGates вы можете контролировать, когда под будет готов для рассмотрения планирования.

Поле schedulingGates (значение по умолчанию nil) содержит список строк, и каждая строка воспринимается как условие, которое должно быть выполнено, чтобы под был готов для планирования. Это поле может быть установлено только при создании пода . После создания, каждое schedulingGate может быть удалено в произвольном порядке, но добавление нового scheduling gate запрещено.

Детальнее вы можете ознакомиться здесь.

Режим доступа ReadWriteOncePod для PersistentVolume переходит в бета-версию

В Kubernetes v1.22 был введен новый режим доступа ReadWriteOncePod для PersistentVolume (PV) и PersistentVolumeClaim (PVC). Этот режим доступа позволяет ограничить доступ к томам только одному поду в кластере, гарантируя, что только один под может записывать данные в том в определенный момент времени. Это особенно полезно для состояний, требующих единственного доступа к хранилищу для записи.

Бета-версия ReadWriteOncePod добавляет поддержку приоритетного планировщика для подов, использующих PVC с режимом доступа ReadWriteOncePod. Приоритетный планировщик позволяет более приоритетным подам вытеснять поды с более низким приоритетом. Например, если для под (A), запланированного с использованием PVC ReadWriteOncePod, найден другой под (B), также использующий тот же PVC и под (A) имеет более высокий приоритет, планировщик вернет статус «Невозможно запланировать» и попытается вытеснить под (B). 

Детальнее вы можете ознакомиться здесь.

Ускоренное монтирование тома с  применением меток SELinux 

В этом релизе функция применения лейблов SELinux к томам, используемым подами, переходит в бета-версию. Функция позволяет пропустить этап переназначения лейблов и тем самым ускорить монтирование тома и , соответственно, ускорить запуск контейнера. Ядро Linux с поддержкой SELinux позволяет при первом монтировании всего тома установить метку SELinux на весь том с помощью опции монтирования -o context=. Таким образом, все файлы на томе получают правильную метку, без необходимости рекурсивного обхода и переназначения.

Детальнее вы можете ознакомиться здесь.

Поддержка gRPC для проб контейнеров

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

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

Список устаревших или удаленных фичей

Ниже приведен список переключателей функциональности, флагов и т.п., которые признаны устаревшими в Kubernetes 1.27:

Устаревшие версии API:

• • Kubeadm v1beta2; миграцию на v1beta3 можно провести с помощью kubeadm config migrate.
  • resource.k8s.io / v1alpha1.PodScheduling: переход на resource.k8s.io / v1alpha2.PodSchedulingContext.
  • DynamicResourceManagement v1alpha1: переход на v1alpha2.
  • CSIStorageCapacity: Storage.k8s.io/v1beta1: переход на v1

Устаревшие примитивы — перейти на альтернативу до выхода следующего релиза:

• • Аннотации seccomp.security. alpha.kubernetes.io/pod и container.seccomp.security. alpha.kubernetes.io: вместо них используйте поле securityContext.seccompProfile.
  • Плагин допуска SecurityContextDeny.
  • Аннотация service.kubernetes.io/ topology-aware-hints: переход на service.kubernetes.io/ topology-mode.