В этом кратком обзоре мы расскажем об основных улучшениях и нововведениях. В конце каждого пункта будут ссылки на KEPы для более детального ознакомления.
Заморозка реестра образов k8s.gcr.io
Проект Kubernetes создал и запускает реестр образов registry.k8s.io, который полностью контролируется сообществом. Это означает, что старый реестр k8s.gcr.io будет заморожен и никакие образы для Kubernetes и связанных с ним подпроектов не будут публиковаться в старом реестре.
Какие изменения это вносит для разработчиков и участников проекта?
Если вы являетесь контрибьютором подпроекта, вам необходимо обновить свои манифесты и Helm-чарты, чтобы использовать новый реестр. Детальнее вы можете ознакомиться здесь.
Какие изменения это вносит для пользователей?
Для использования профиля по умолчанию seccomp необходимо запускать kubelet с включенным флагом командной строки —seccomp-default на каждом узле, где вы планируете его использовать. При включении этого флага, kubelet будет использовать RuntimeDefault seccomp профиль по умолчанию, который определяется контейнерным рантаймом, вместо режима Unconfined (seccomp отключен).
Профили по умолчанию направлены на обеспечение надежных настроек безопасности, сохраняя при этом функциональность рабочей нагрузки. Важно отметить, что профили по умолчанию могут отличаться в зависимости от контейнерных рантаймов и их версий.
Детальнее вы можете ознакомиться здесь.
Pod Scheduling Readiness переходит в бета-версию
Поды считаются готовыми к планированию сразу после того, как созданы. Планировщик Kubernetes находит узлы для размещения всех ожидающих подов. Однако в реальности некоторые поды могут находиться в состоянии miss-essential-resources (“отсутствия необходимых ресурсов”) в течение длительного времени. Эти поды «сбивают с толку» планировщик и компоненты типа Cluster Autoscaler.
Путем указания/удаления поля .spec.schedulingGates вы можете контролировать, когда под будет готов для рассмотрения планирования.
Поле schedulingGates (значение по умолчанию nil) содержит список строк, и каждая строка воспринимается как условие, которое должно быть выполнено, чтобы под был готов для планирования. Это поле может быть установлено только при создании пода . После создания, каждое schedulingGate может быть удалено в произвольном порядке, но добавление нового scheduling gate запрещено.
Чтобы посмотреть логи сервисов на узле, например, containerd, kubelet’а и т.п., администратор кластера Kubernetes должен подключиться к узлу по SSH и смотреть файлы логов напрямую. Более простым способом было бы задействование CLI kubectl для просмотра логов на узле по аналогии с тем, как это делается при других взаимодействиях с кластером.
Для использования этой функции убедитесь, что включена опция NodeLogQuery на узле, а также, что опции конфигурации kubelet enableSystemLogHandler и enableSystemLogQuery установлены в значение true. Администратор кластера может опробовать эту альфа-версию функции на всех узлах своего кластера или на их подмножестве.
В Kubernetes v1.22 был введен новый режим доступа ReadWriteOncePod для PersistentVolume (PV) и PersistentVolumeClaim (PVC). Этот режим доступа позволяет ограничить доступ к томам только одному поду в кластере, гарантируя, что только один под может записывать данные в том в определенный момент времени. Это особенно полезно для состояний, требующих единственного доступа к хранилищу для записи.
Бета-версия ReadWriteOncePod добавляет поддержку приоритетного планировщика для подов, использующих PVC с режимом доступа ReadWriteOncePod. Приоритетный планировщик позволяет более приоритетным подам вытеснять поды с более низким приоритетом. Например, если для под (A), запланированного с использованием PVC ReadWriteOncePod, найден другой под (B), также использующий тот же PVC и под (A) имеет более высокий приоритет, планировщик вернет статус «Невозможно запланировать» и попытается вытеснить под (B).
С помощью matchLabelKeys пользователям не нужно обновлять поле pod.spec между разными версиями. Контроллер просто должен устанавливать различные значения для одного и того же ключа лейбла для разных версий. Планировщик автоматически будет использовать значения, опираясь на matchLabelKeys. Например, если пользователи используют Deployment, они могут использовать метку, связанную с pod-template-hash, которая автоматически добавляется контроллером развертывания, для отличия разных версий в рамках одного развертывания.
В этом релизе функция применения лейблов SELinux к томам, используемым подами, переходит в бета-версию. Функция позволяет пропустить этап переназначения лейблов и тем самым ускорить монтирование тома и , соответственно, ускорить запуск контейнера.
Ядро Linux с поддержкой SELinux позволяет при первом монтировании всего тома установить метку SELinux на весь том с помощью опции монтирования -o context=. Таким образом, все файлы на томе получают правильную метку, без необходимости рекурсивного обхода и переназначения.
Цель — уменьшить время, необходимое kubelet’у для восстановления информации о примонтированных томах после перезапуска.
Такая информация теряется после перезапуска kubelet’а, и для ее восстановления ему приходится сопоставлять данные сервера API и ОС хоста. Kubelet проверяет, какие поды должны быть запущены и какие тома примонтированы на самом деле.
Однако этот процесс несовершенен и лишен некоторой ключевой информации, например, о том, какие опции для монтирования томов использовал прежний kubelet.
Этот KEP снабжен отдельным переключателем функциональности (feature flag) NewVolumeManagerReconstruction, при включении которого на узле вы получаете улучшенное обнаружение смонтированных томов при запуске kubelet.
Liveness, Readiness и Startup probes — три разных типа проверки состояния пода. Сейчас они работают по протоколам HTTP(S) и TCP. Новая фича добавляет поддержку gRPC — открытого фреймворка для удаленного вызова процедур, который часто используется в микросервисной архитектуре.
Возможность использовать встроенный gRPC среди прочего избавляет от необходимости использовать сторонние инструменты для проверки состояния контейнеров вроде grpc_health_probe.
В поды была добавлена аннотация kubectl.kubernetes.io/default-container для определения контейнера по умолчанию.
Это упрощает использование таких инструментов, как kubectl logs или kubectl exec на подах с sidecar-контейнерами.
Ниже приведен список переключателей функциональности, флагов и т.п., которые признаны устаревшими в Kubernetes 1.27:
Устаревшие версии API:
Устаревшие примитивы — перейти на альтернативу до выхода следующего релиза:
Удаленные примитивы — перейти на альтернативу до обновления:
Вместо k8s.gcr.io используйте registry.k8s.io.
Переключатели функциональности:
appProtocol: kubernetes.io/grpc.
Флаг kube-apiserver’а: —master-service-namespace.
Флаги CLI: —enable-taint-manager и —pod-eviction-timeout.
Флаги kubelet’а: —container-runtime, —master-service-namespace.
In-tree-плагин дискового хранилища Azure.
Поставщик учетных данных kubelet’а AWS: используйте ecr-credential-provider.
Метрики: