Анонсирован Kubernetes v1.29: выпуск Mandala, последний выпуск 2023 года!

Выпуск Kubernetes v1.29, как и предыдущие версии, содержит новые функции стабильной версии (Stable), тестовой версии (бета) и версии для разработки (альфа). Этот выпуск еще раз доказывает наш эффективный цикл разработки и восторженную поддержку сообщества, отражающую нашу сильную силу.

Эта версия содержит 49 улучшений,в 11 дозрел до стабильной версии, 19 вход Beta стадия версии, кроме того 19 достиг Alpha уровень версии.

#01

Темы и логотип

Kubernetes v1.29：Mandala

Присоединяйтесь к нам в этом путешествии по исследованию вселенной с Kubernetes v1.29!

Эта версия вдохновлена ​​Мандалой, символом идеальной вселенной. Наша сплоченная команда запуска, состоящая примерно из 40 человек при поддержке многих участников сообщества, преодолевает трудности и приносит радость миллионам пользователей по всему миру.

Тема Мандала демонстрирует тесные связи между членами нашего сообщества, это красочный гобелен, сотканный страстными энтузиастами и экспертами. Каждый участник подобен уникальному образцу в искусстве Мандалы, привнося в проект свою уникальную энергию. Kubernetes процветает благодаря этому сотрудничеству и гармонии, воплощенной в искусстве Мандалы.

Логотип для этого выпуска, разработанный Марио Джейсоном Браганса (основное изображение Мандалы было предоставлено Фибрелом Охала), символизирует маленькую вселенную, которую составляют проект Kubernetes и его команда.

Руководствуясь духом Мандалы, символизирующим перемены, Kubernetes v1.29 отмечает рост нашего проекта. Как и каждая звезда во вселенной Kubernetes, каждый участник, пользователь и сторонник освещает нам путь. Вместе мы создали вселенную, полную безграничных возможностей, и каждое обновление версии — результат нашего совместного творчества.

#02

Основные улучшения

Вот некоторые ключевые улучшения, которые становятся стабильными функциями с выпуском Kubernetes v1.29.

Режим доступа к постоянному тому ReadWriteOncePod

В мире Kubernetes шаблоны доступа к томам определяют, как используется постоянное хранилище. Эти режимы являются частью спецификаций PersistentVolumes (PV) и PersistentVolumeClaims (PVC). Когда мы используем хранилище, существуют разные модели для описания потребления хранилища.

Например, такая система хранения, как сетевой файловый ресурс, может позволять нескольким пользователям одновременно читать и писать. В других сценариях каждый может читать данные, но не писать. Для чрезвычайно конфиденциальных данных только одному пользователю может быть разрешено чтение и запись, а другим нет.

До версии 1.22 Kubernetes предоставлял три режима доступа для PV и PVC:

• ReadWriteOnce: том может быть смонтирован для чтения и записи одним узлом.
• ReadOnlyMany: том может быть установлен только для чтения несколькими узлами.
• ReadWriteMany: том может быть смонтирован в режиме чтения-записи несколькими узлами.

Режим доступа ReadWriteOnce ограничивает доступ к тому одному узлу, что означает, что несколько модулей Pod на одном узле могут читать и записывать в один и тот же том. Это может быть большой проблемой для некоторых приложений, особенно тех, где по соображениям безопасности данных требуется максимум один писатель.

Чтобы решить эту проблему, в версии 1.22 представлен четвертый режим доступа — ReadWriteOncePod — как альфа-функция томов CSI. Если вы создаете под с PVC, используя режим доступа ReadWriteOncePod, Kubernetes гарантирует, что этот под будет единственным подом во всем кластере, который может читать и записывать в PVC. Начиная с версии 1.29 эта функция общедоступна.

Секретная поддержка драйвера CSI при расширении тома узла.

В Kubernetes операции расширения тома могут включать расширение тома на узле, включая настройку файловой системы. Некоторым драйверам CSI требуются секреты во время расширения узла, например учетные данные для доступа к сети SAN. Это особенно важно в следующих ситуациях.

• когда PersistentVolume При представлении зашифрованного изблок-хранилище, например, используйте LUKS, вам может потребоваться ввести парольную фразу для расширения действия устройства.
• для проведения различных проверок, CSI При управлении расширением узла существования вам необходимо использовать команду «Прибытие» для связи с внутренней системой хранения данных из учетных данных.

Чтобы удовлетворить эту потребность, в Kubernetes v1.25 была введена функция CSI Node Expand Secret. Эта функция позволяет передавать необязательное поле Secret в NodeExpandVolumeRequest, используемое драйвером CSI для операций расширения тома узла в базовой системе хранения. Начиная с версии Kubernetes 1.29, эта функция стала общедоступной.

Официально запущена функция статического шифрования KMS v2

Среди многих соображений по обеспечению безопасности кластера Kubernetes шифрование хранимых данных API в состоянии покоя является одним из главных приоритетов. KMS предоставляет интерфейс, который позволяет выполнять это шифрование с использованием ключей, хранящихся во внешней службе ключей. С выпуском Kubernetes v1.29 KMS v2 стабильно работает в сети, что принесло множество улучшений в области повышения производительности, ротации ключей, проверок работоспособности и мониторинга состояния, а также наблюдаемости. Эти улучшения предоставляют пользователям надежное решение для шифрования всех ресурсов в их кластере Kubernetes.

Для получения дополнительной информации об этом, пожалуйста, обратитесь к:

https://kep.k8s.io/3299

Рекомендуется использовать KMS v2. Функциональная дверь KMS v1 по умолчанию закрыта. Если вы хотите продолжать использовать его, вам необходимо активно согласиться.

#03

повышен до beta новые возможности

Вот некоторые из Kubernetes v1.29 После выхода версииповышен до beta Новые возможности версии.

Пропускная способность планировщика — это постоянная проблема, с которой мы сталкиваемся. Функция QueueingHint предлагает новые идеи по повышению эффективности повторной очереди и может значительно сократить количество недопустимых повторных попыток планирования.

Разделение жизненного цикла узла и управления испорченными данными

Как говорится в заголовке, этот шаг заключается в том, чтобы отделить TaintManager, который выполняет выселение подов на основе испорченных данных, из NodeLifecycleController и превратить их в два независимых контроллера: NodeLifecycleController отвечает за добавление испорченных данных в неработоспособные узлы, а TaintManager отвечает за удаление испорченных узлов. . Поды на испорченных узлах с эффектом NoExecute.

Очистка устаревших токенов ServiceAccount на основе секрета.

В версии 1.22 Kubernetes перешел на более безопасные токены сервисных учетных записей, которые ограничены по времени и привязаны к конкретным модулям. Начиная с версии 1.24, автоматическое создание токенов учетных записей устаревших служб на основе секрета было прекращено. Впоследствии, в версии 1.27, автоматически сгенерированные токены на основе секрета, которые все еще используются, стали помечаться датой последнего использования.

В версии v1.29, чтобы уменьшить поверхность возможной атаки, функция LegacyServiceAccountTokenCleanUp помечает как недействительные те устаревшие автоматически сгенерированные секретные токены, которые не использовались в течение длительного времени (по умолчанию — 1 год), а затем продлевает их после помечается как недействительный. Он автоматически удаляется через длительный период времени (по умолчанию еще 1 год) без попыток использования.

Более подробную информацию можно найти по адресу:

https://kep.k8s.io/2799

#04

Недавно запущенный alpha характеристика

Используйте matchLabelKeys, чтобы определить сходство или антисходство модуля.

PodAffinity/PodAntiAffinity представит усовершенствование в альфа-версии. Это улучшит возможность расчета точности во время чередующихся обновлений.

nftables как бэкенд для kube-proxy

Текущая реализация kube-proxy в Linux по умолчанию основана на iptables, которая долгое время была предпочтительной системой фильтрации и обработки пакетов в ядре Linux (начиная с ядра 2.4 в 2001 году). Однако некоторые неразрешимые проблемы с iptables побудили разработать его преемника nftables. Разработка iptables в основном прекращена, а новые функции и улучшения производительности в основном сосредоточены на nftables.

этотхарактеристикадля kube-proxy Добавлен новый на основе nftables новый бэкэнд, потому что некоторые Linux Началось прекращение поддержки и удаление дистрибутива iptables, в то время как nftables утверждал, что решил iptables основные проблемы с производительностью.

API для управления диапазонами IP-адресов служб

Служба — это абстрактный способ предоставления доступа к приложению, работающему на наборе модулей Pod. Службам может быть назначен виртуальный IP-адрес всего кластера из CIDR по умолчанию, определенного в флаге kube-apiserver. Однако пользователи могут захотеть добавить, удалить или настроить существующие диапазоны IP-адресов, назначенные службам, без перезапуска kube-apiserver.

этотхарактеристикапроходитьиспользоватьдва новыхиз API Объект: СервисCIDR и IPAddress реализует новую логику распределителя, которая позволяет пользователям создавать новые ServiceCIDR Динамическое увеличение доступных услуг IP количество. это помогает решить IP истощен или IP Такие вопросы, как перенумерация.

Добавьте поддержкуContainerd/kubelet/CRI, чтобы можно было извлекать изображения на основе категорий времени выполнения.

Kubernetes v1.29 Добавлена ​​новая база Pod из RuntimeClass Функция Pull контейнерзеркалоиз. Эта функциясуществовать v1.29 По умолчанию в данной версии он отключен и относится к категории с именем RuntimeClassInImageCriApi нехарактерная дверь.

контейнерзеркало может быть списком или индексом. Когда извлекаемое иззеркало является индексом (т. е. индекс зеркала содержит список списков иззеркало, отсортированных по платформам),Среда выполнения контейнера извлечет соответствующий список иззеркал из логики сопоставления платформы использования с помощью index. По умолчанию,Логика сопоставления платформы выберет и выполнитзеркалотянутьиз Соответствие хостаиз Контрольный список。этотверно На основе VM изконтейнер может иметь ограничения. Например, пользователь может захотеть вытащить зеркало с намерением использовать его как основу. VM изконтейнер запустить, например Windows Hyper-V контейнер.

При извлечении зеркалахарактеристическаяподдержка по категории времени выполнения извлекаются разные иззеркало в зависимости от указанной категории времени выполнения. Это по ссылке （imageID, runtimeClass） Yuan GroupГруппа в иззеркало реализует и не только imageName или идентификатор изображения. Контейнер можно выбрать при запуске подтверждения этой характеристики. Если они не поддерживают, то Kubernetes v1.29 До kubelet Строка по умолчанию для будет сохранена.

верно Windows Pod из Pod Ресурсы обновляются на месте

как alpha характеристика,Kubernetes Pod Теперь изменения можно вносить на стороне ресурса, что позволяет пользователям Pod из Изменение регистра Pod из лимита запросов ресурсов. существовать v1.29 версии, эта функция теперь поддерживается Windows контейнер.

#05

Выпуск, устаревание и функция Удалять

повышен до Стабильная версия

Все розы перечислены ниже до Стабильная версия (также известная как универсально доступная) изхарактеристика. О включении новых функций и от alpha приезжать beta Полный список обновлений см.:

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md

В этой версии всего 11 Улучшенияповышен до Стабильная версия：

• от KCCM из Служить Удалять утверждение временного узла в контроллере
• для динамического и статического распределения диапазон портов зарезервированного узла
• API Служить серверным запросам по приоритету и справедливости
• KMS v2 из Улучшений
• поддерживатьот Kubernetes API Пагинация LIST Запрос
• Режим доступа к постоянному тому ReadWriteOncePod
• Kubernetes Группакусочки здоровья SLI
• Язык выражений проверки CRD
• Ввести nodeExpandSecret в источник CSI PV.
• Отслеживание рабочего статуса модуля «Готов»
• Конечная точка метрик ресурсов Kubelet

Устарело и Удавать

Удалятьиоблачный провайдериз Интеграция внутри дерева

Kubernetes v1.29 No more облачный интегрирован по умолчанию провайдериз встроенной интеграции. Если ты зависишь от дерева, облачный интеграция провайдера (например, Azure、GCE или vSphere), вы можете:

• Включить эквивалентную интеграцию внешнего диспетчера облачных контроллеров (рекомендуется)
• Установив соответствующую функцию двери для false Чтобы продолжить использовать устаревшую интеграцию, необходимо изменить функцию Gate include; DisableCloudProviders и DisableKubeletCloudCredentialProviders

Включение внешнего диспетчера облачных контроллеров означает, что у вас должен быть соответствующий диспетчер облачных контроллеров, работающий в плоскости управления кластером; также необходимо, чтобы каждый соответствующий узел был подключен к kubelet kubelet и вся плоскость управления (kube-apiserver и Установить); параметры командной строки в kube-controller-manager) --cloud-provider=external.

Дополнительная информация о том, как включить и запустить внешние диспетчеры облачных контроллеров.,Видеть:

https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/

а также:

https://kubernetes.io/docs/tasks/administer-cluster/controller-manager-leader-migration/

Если вам нужен один из устаревших поставщиков внутридерева и менеджеров облачных контроллеров, перейдите по следующей ссылке:

• Облачный провайдер AWS: https://github.com/kubernetes/cloud-provider-aws.
• Поставщик облачных услуг Azure: https://github.com/kubernetes-sigs/cloud-provider-azure.
• Облачный провайдер GCE: https://github.com/kubernetes/cloud-provider-gcp.
• Облачный провайдер OpenStack: https://github.com/kubernetes/cloud-provider-openstack.
• Поставщик облачных услуг vSphere: https://github.com/kubernetes/cloud-provider-vsphere.

Для более подробной информации читайте: https://kep.k8s.io/2395.

Удалить группу API управления потоком v1beta2.

Kubernetes v1.29 Устаревшая версия больше не доступна flowcontrol.apiserver.k8s.io/v1beta2 API Версия из FlowSchema и PriorityLevelConfiguration。

Если вы использовали устаревший beta API Группировали клиентское программное обеспечение, которое необходимо обновить. v1.29 До Измените их. Для получения подробной информации рекомендуется посмотреть Устарело. API из Руководство по миграции:

https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-29

Поле kubeProxyVersion в объекте Node устарело.

Node вернослониз .status.kubeProxyVersion Поле теперь помечено как устаревшее, Kubernetes Это поле включено в план проекта, существующий для будущих версий. Это устаревшее поле не является точным, и исторически начальство было kubelet Управление - на самом деле kubelet Не понимаю kube-proxy Точная версия даже не известна kube-proxy Оно работает?

Если вы использовали это поле в своем клиентском программном обеспечении, немедленно прекратите использование этой информации: эта информация ненадежна, и это поле устарело.

наследиеиз Linux хранение пакетов

Обратите внимание, что в 2023 Год 8 месяц, хранение наследства пакетов（apt.kubernetes.io и yum.kubernetes.io) официально устарел, Kubernetes Проект анонсирован Debian и RPM Пакет из муниципального хранения пакетовиз Универсальная доступность,Можетсуществовать https://pkgs.k8s.io Получать.

Это наследие хранится в 2023 Год 9 месяц заморожен и будет 2024 Год 1 Луна полностью исчезла. Если вы в настоящее время полагаетесь на эти репозитории, вам необходимо выполнить миграцию.

Эта девальвация не связана напрямую с v1.29 Зависит от версии. подробнее,Включите информацию о том, как эти изменения могут повлиять на вас и какие шаги вам следует предпринять, если они затронут вас.,Пожалуйста, ознакомьтесь с объявлением об устаревании репозитория устаревших пакетов:

https://kubernetes.io/blog/2023/08/31/legacy-package-repository-deprecation/

#06

Другая информация

Хотите знать Kubernetes v1.29 Версия из Полная информация,Пожалуйста, ознакомьтесь с примечаниями к выпуску:

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md

Ссылка для скачивания на GitHub:

https://github.com/kubernetes/kubernetes/releases/tag/v1.29.0

Исходная ссылка: https://kubernetes.io/blog/2023/12/13/kubernetes-v1-29-release/