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

Процесс удаления и прекращения поддержки компонентов API Kubernetes

Проект Kubernetes имеет хорошо документированную политику устаревания функций. Эта политика гласит, что стабильные API могут быть устаревшими только тогда, когда доступна более новая, стабильная версия этого API, и что API имеют минимальный срок службы для каждого уровня стабильности. Устаревший API был помечен для удаления в будущем выпуске Kubernetes. Он продолжит функционировать до удаления (по крайней мере, через год с момента устаревания), но при использовании будет отображаться предупреждение. Удаленные API больше не доступны в текущей версии, поэтому вам необходимо перейти на использование замены.

  • Общедоступные (GA) или стабильные версии API могут быть помечены как устаревшие, но их нельзя удалять в основной версии Kubernetes.

  • Бета- или предварительные версии API должны поддерживаться в течение 3 выпусков после попадания в статус “deprecation”.

  • Альфа-версии или экспериментальные версии API могут быть удалены в любом выпуске без предварительного уведомления об устаревании.

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

Примечание о поддержке подписи SHA-1

В go1.18 (выпущен в марте 2022 года) библиотека crypto/x509 начала отклонять сертификаты, подписанные с помощью хэш-функции SHA-1. Хотя SHA-1 признан небезопасным, а публично доверенные центры сертификации не выпускали сертификаты SHA-1 с 2015 года, в контексте Kubernetes все еще могут быть случаи, когда предоставленные пользователем сертификаты подписываются с помощью хэш-функции SHA-1 через частные центры сертификации, которые используются для агрегированных серверов API или веб-перехватчиков. Если вы полагались на сертификаты на основе SHA-1, вы должны явно отказаться от его поддержки, настроив GODEBUG=x509sha1=1в своей среде.

Учитывая политику совместимости Go с GODEBUG , x509sha1GODEBUG и поддержка сертификатов SHA-1 полностью исчезнут в go1.24, который выйдет в первой половине 2025 года. Если вы полагаетесь на сертификаты SHA-1, пожалуйста, начните отказываться от них.

Ознакомьтесь с проблемой Kubernetes #125689, чтобы получить более полное представление о сроках прекращения поддержки SHA-1, о том, когда Kubernetes обнародует планы по внедрению go1.24, а также получить более подробную информацию о том, как обнаружить использование сертификатов SHA-1 с помощью метрик и журналов аудита.

Устаревания и удаления в Kubernetes 1.31

Устаревание status.nodeInfo.kubeProxyVersion поля для узлов ( KEP 4004 )

Поле .status.nodeInfo.kubeProxyVersion Nodes устарело в Kubernetes v1.31 и будет удалено в более позднем выпуске. Оно устарело, поскольку значение этого поля не было (и не является) точным. Это поле задается kubelet, у которого нет надежной информации о версии kube-proxy или о том, запущен ли kube-proxy.

В версии 1.31 шлюз DisableNodeKubeProxyVersion функций будет установлен в true по умолчанию, и kubelet больше не будет пытаться задать .status.kubeProxyVersion поле для связанного с ним узла.

Удаление всех внутренних интеграций с облачными провайдерами

Последняя оставшаяся поддержка интеграции облачных провайдеров будет удалена в рамках выпуска v1.31. Это не означает, что вы не можете интегрироваться с облачным провайдером, однако теперь вы должны использовать рекомендуемый подход с использованием внешней интеграции. Некоторые интеграции являются частью проекта Kubernetes, а другие — сторонним программным обеспечением.

Эта веха знаменует завершение процесса экстернализации для всех интеграций облачных провайдеров из ядра Kubernetes ( KEP-2395 ), процесс, начатый с Kubernetes v1.26. Это изменение помогает Kubernetes приблизиться к тому, чтобы стать действительно независимой от поставщика платформой.

Другие обновления

Удаление --keep-terminated-pod-volumes флага командной строки kubelet

Флаг kubelet --keep-terminated-pod-volumes, который был объявлен устаревшим в 2017 году, будет удален в версии v1.31.

Более подробную информацию можно найти в запросе на включение изменений #122082 .

Удаление плагина тома CephFS

Плагин тома CephFS был удален в этом выпуске.

Вместо этого рекомендуется использовать драйвер CephFS CSI в качестве стороннего драйвера хранилища. Если вы использовали плагин тома CephFS до обновления версии кластера до v1.31, вам необходимо повторно развернуть свое приложение для использования нового драйвера.

Плагин тома CephFS был официально помечен как устаревший в версии 1.28.

Удаление плагина Ceph RBD Volume

В выпуске v1.31 будет удален плагин тома Ceph RBD и его поддержка миграции CSI, что сделает этот rbd тип тома нефункциональным.

Вместо этого рекомендуется использовать драйвер RBD CSI в кластерах. Если вы использовали плагин тома Ceph RBD до обновления версии кластера до v1.31, вам необходимо повторно развернуть приложение для использования нового драйвера.

Плагин тома Ceph RBD был официально помечен как устаревший в версии 1.28.

Устаревание плагинов non-CSI volume limit в kube-scheduler

В версии v1.31 будут отменены все плагины планировщика объема, не относящиеся к CSI, а также будут удалены некоторые устаревшие плагины из плагинов по умолчанию , в том числе:

  • AzureDiskLimits

  • CinderLimits

  • EBSLimits

  • GCEPDLimits

Рекомендуется использовать NodeVolumeLimits плагин, поскольку он может обрабатывать ту же функциональность, что и удаленные плагины, поскольку эти типы томов были перенесены в CSI. Следует заменить устаревшие плагины на плагин, NodeVolumeLimits если вы явно используете их в конфигурации планировщика. Плагины AzureDiskLimits, CinderLimits, EBSLimits, и GCEPDLimits будут удалены в будущем выпуске.

Эти плагины будут удалены из списка плагинов планировщика по умолчанию, поскольку они устарели с версии Kubernetes v1.14.

Будущие изменения

Официальный список удалений API, запланированных для Kubernetes v1.32, включает в себя:

  • Версия API flowcontrol.apiserver.k8s.io/v1beta3 FlowSchema и PriorityLevelConfiguration будет удалена. Чтобы подготовиться к этому, вы можете отредактировать существующие манифесты и переписать клиентское программное обеспечение для использования версии flowcontrol.apiserver.k8s.io/v1 API,  доступной с v1.29. Все существующие сохраненные объекты доступны через новый API.

  • Заметные изменения в flowcontrol.apiserver.k8s.io/v1beta3 включают то, что spec.limited.nominalConcurrencyShares поле PriorityLevelConfiguration по умолчанию имеет значение 30 только в том случае, если не указано, а явное значение 0 не изменяется на 30.

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

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

Если у вас несколько микросервисов и вы не хотите тратить время на настройку CI/CD, мониторинга и эксплуатации Kubernetes, попробуйте наше облако - Amvera Cloud. Amvera - это альтернатива managed Kubernetes. У нас вы сможете обновлять ваши сервисы через простые коммиты в Git и получите почти все преимущества Kubernetes, не задумываясь об администрировании, настройки CI/CD, мониторинга, алертинга и сопутствующих сервисов. Это выйдет намного дешевле, чем классический managed k8s. Kubernetes у нас внутри, но вы полностью абстрагированы от его администрирования, достаточно просто привязать к сервису ваш Git-репозиторий и обновлять приложения командой “git push amvera master”.

А если у вас сложный проект и вам нужна помощь в построении инфраструктуры на основе Kubernetes, или просто консультация, пишите нашему CEO в телеграм (Кирилл Косолапов), либо оставьте контакт для связи на странице нашей DevOps-команды. За спрос денег не берем, если это небольшая консультация или что-то простое, поможем бесплатно. А если сложное - договоримся.

Комментарии (4)


  1. Andreyika
    29.07.2024 18:33
    +6

    В версии v1.31 будут отменены все плагины планировщика ограничения громкости, не относящиеся к CSI

    жаль, надеюсь хоть с пульта громкость можно будет поменять


    1. NikitinIlya Автор
      29.07.2024 18:33

      Спасибо, поправил


  1. Melonom
    29.07.2024 18:33
    +1

    ну хоть бы прошлись по машинному переводу, ну читать невозможно.


  1. diafour
    29.07.2024 18:33
    +1

    Если вы полагались на сертификаты на основе SHA-1, вы должны явно отказаться от его поддержки, настроив GODEBUG=x509sha1=1в своей среде.

    x509sha1=1 это не "явный отказ от поддержки", а как раз возврат поддержки sha1, чтобы можно было использовать старый хэш.

    P.s. почитал дальше, перевод в целом неудачный какой-то.