Облачная платформаAdvanced

Kubernetes 1.29 Примечания к выпуску

Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

CCE прошёл Certified Kubernetes Conformance Program и является сертифицированным предложением Kubernetes. CCE теперь поддерживает функции кластера Kubernetes 1.29. В этом разделе описаны изменения в Kubernetes 1.29.

Индексы

Новые и улучшенные функции

  • Режим load balancer IP mode для Services находится в альфа‑состоянии.

    Режим load balancer IP mode для Services переведён в альфа. Kubernetes 1.29 добавляет поле ipMode в поле status Service для настройки переадресации трафика от Services внутри кластера к pod‑ам. Если ipMode установлен в VIP, трафик, доставляемый на узел с назначением, установленным на IP‑адрес и порт балансировщика нагрузки, будет перенаправлен на целевой узел kube-proxy. Если он установлен в Proxy, трафик, доставляемый на узел, будет отправлен к балансировщику нагрузки, а затем перенаправлен на целевой узел балансировщиком нагрузки. Эта функция решает проблему пропуска функций балансировщика нагрузки из‑за обхода трафика. Для подробностей см. Load Balancer IP Mode for Services.

  • Режим nftables proxy находится в альфа‑состоянии.

    Режим nftables proxy переведён в альфа. Эта функция позволяет kube-proxy работать в режиме nftables. В этом режиме kube-proxy настраивает правила переадресации пакетов, используя API nftables подсистемы ядра netfilter. Для подробностей см. nftables proxy mode.

  • Сборка мусора для неиспользуемых container images находится в альфа‑состоянии.

    Сборка мусора для неиспользуемых container images переведена в альфа. Эта функция позволяет указать максимальное время, в течение которого локальный образ может оставаться неиспользуемым на каждом узле. По истечении времени образ будет удалён сборкой мусора. Чтобы настроить параметр, укажите поле ImageMaximumGCAge для kubelet. Для подробностей см. Garbage collection for unused container images.

  • PodLifecycleSleepAction находится в состоянии alpha.

    PodLifecycleSleepAction переведено в состояние alpha. Эта функция вводит sleep‑hook в container lifecycle hooks. Вы можете приостановить контейнер на заданный период после его запуска или перед остановкой, включив эту функцию. Подробнее см. Hook handler implementations.

  • KubeletSeparateDiskGC находится в состоянии alpha.

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

  • matchLabelKeys и mismatchLabelKeys находятся в состоянии alpha.

    matchLabelKeys и mismatchLabelKeys переведено в состояние alpha. При включённых этих функциях поля matchLabelKeys и mismatchLabelKeys добавляются в конфигурации pod affinity и anti‑affinity. Это позволяет настраивать больше политик affinity и anti‑affinity между pod‑ами. Подробнее см. matchLabelKeys and mismatchLabelKeys.

  • clusterTrustBundle projected volumes находятся в состоянии alpha.

    clusterTrustBundle projected volumes переведено в состояние alpha. При включённой функции источник clusterTrustBundle projected volume внедряет содержимое одного или нескольких объектов ClusterTrustBundle в виде автоматически обновляемого файла. Подробнее см. clusterTrustBundle projected volumes.

  • Получение образов на основе runtime‑классов pod‑ов находится в состоянии alpha.

    Получение образов на основе runtime‑классов переведено в состояние alpha. При включённой функции kubelet ссылается на образы контейнеров кортежем (имени образа или runtime‑handler), а не только на имя образа или дайджест. Ваш runtime контейнера может адаптировать своё поведение в зависимости от выбранного runtime‑handler. Получение образов на основе runtime‑классов будет полезно для контейнеров на основе VM. Подробнее см. Image pull per runtime class.

  • PodReadyToStartContainers condition находится в состоянии beta.

    PodReadyToStartContainers condition переведено в состояние beta. Kubernetes 1.29 вводит условие PodReadyToStartContainers в поле status pod‑ов. Если оно установлено в true, песочница pod готова и можно создавать сервисные контейнеры. Эта функция позволяет администраторам кластера получить более чёткое и полное представление о завершении создания песочницы pod и готовности контейнеров. Такое улучшенное отображение позволяет принимать более обоснованные решения и эффективнее устранять проблемы. Подробнее см. PodReadyToStartContainers Condition Moves to Beta.

  • Две функции, связанные с job, находятся в состоянии beta.
    • Pod replacement policy (beta)

      Функция pod replacement policy переведена в состояние beta. Эта функция гарантирует, что pod заменяется только при переходе в состояние Failed, что означает, что status.phase становится Failed. Она не воссоздаёт pod, если метка времени удаления не пуста и pod всё ещё удаляется. Это предотвращает одновременное занятие индексных и узловых ресурсов двумя pod‑ами.

    • Backoff limit per index (beta)

      Backoff limit per index переходит в beta. По умолчанию pod failures для indexed jobs учитываются и ограничиваются глобальным лимитом повторов, указанным в .spec.backoffLimit. Это означает, что если в job есть постоянно падающий индекс, pod, указанные в job, будут перезапускаться неоднократно, пока pod failures не исчерпают лимит. После достижения лимита job помечается как failed, и pod для остальных индексов в job могут никогда не запуститься. Функция позволяет завершить выполнение всех индексов, несмотря на сбои некоторых индексов, и более эффективно использовать вычислительные ресурсы, избегая ненужных повторов постоянно падающих индексов.

  • Native sidecar containers находятся в beta‑состоянии.

    Native sidecar containers продвигаются в beta. Поле restartPolicy добавляется в initContainers. Когда это поле установлено в Always, sidecar container включается. Sidecar container и service container разворачиваются в одном pod. Это не может продлить жизненный цикл pod. Sidecar containers обычно используются в сценариях, таких как сетевой прокси и сбор логов. Подробности см. в Sidecar Containers.

  • Legacy ServiceAccount token cleaner находится в beta‑состоянии.

    Legacy ServiceAccount token cleaner продвигается в beta. Он работает как часть kube-controller-manager и каждые 24 часа проверяет, не использовался ли какой‑либо автоматически сгенерированный legacy ServiceAccount token в течение определённого периода времени (по умолчанию один год, задаётся параметром --legacy-service-account-token-clean-up-period). Если да, очиститель помечает такие токены как недействительные и добавляет метку kubernetes.io/legacy-token-invalid-since со значением текущей даты. Если недействительный токен не используется в течение определённого периода времени (по умолчанию один год, задаётся параметром --legacy-service-account-token-clean-up-period), очиститель удаляет его. Подробности см. в Legacy ServiceAccount token cleaner.

  • DevicePluginCDIDevices находится в beta‑состоянии.

    DevicePluginCDIDevices переходит в beta. При включённой функции разработчики плагинов могут использовать поле CDIDevices, добавленное в DeviceRunContainerOptions, чтобы передавать имена CDI‑устройств напрямую в CDI‑поддерживаемые среды выполнения.

  • PodHostIPs находится в beta‑состоянии.

    The PodHostIPs feature moves to beta. With this feature enabled, Kubernetes adds the hostIPs field to Status of pods and downward API to expose node IP addresses to workloads. This field specifies the dual-stack protocol version of the host IP address. The first IP address is always the same as the host IP address.

  • Функция API Priority and Fairness (APF) находится в состоянии GA.

    APF переходит в GA. APF классифицирует и изолирует запросы более детально. Он улучшает ограничения max‑inflight. Также вводится ограниченный объём очереди, чтобы API‑server не отклонял запросы при очень коротких всплесках. Запросы извлекаются из очередей с использованием техники справедливой очереди, так что, например, некорректно работающий контроллер не приводит к аномалиям у других (даже на том же уровне приоритета). Подробности см. в API Priority and Fairness.

  • APIListChunking находится в состоянии GA.

    Функция APIListChunking переходит в GA. Эта функция позволяет клиентам выполнять постраничный вывод в запросах List, чтобы избежать проблем с производительностью, вызванных возвратом слишком большого объёма данных за один раз.

  • ServiceNodePortStaticSubrange находится в состоянии GA.

    Функция ServiceNodePortStaticSubrange переходит в GA. При включённой функции kubelet вычисляет размер зарезервированных IP‑адресов на основе диапазонов сервисов NodePort и делит порты узла на статическую и динамическую полосу. При автоматическом назначении портов узла предпочтительно назначается динамическая полоса, что помогает избежать конфликтов портов при назначении статической полосы. Подробнее см. ServiceNodePortStaticSubrange.

  • Метка времени перехода фазы PersistentVolume (PV) находится в бета‑состоянии.

    Метка времени перехода фазы PV переходит в beta. При включённой функции Kubernetes добавляет поле lastPhaseTransitionTime в поле status PV, указывающее время последнего изменения фазы PV. Администраторы кластера теперь могут отслеживать время последнего перехода PV в другую фазу, что позволяет более эффективно и осознанно управлять ресурсами. Подробнее см. PersistentVolume Last Phase Transition Time in Kubernetes.

  • ReadWriteOncePod находится в состоянии GA.

    Функция ReadWriteOncePod переходит в GA. При включённой функции вы можете установить режим доступа ReadWriteOncePod в PersistentVolumeClaim (PVC), чтобы гарантировать, что только один pod может изменять данные в томе одновременно. Это может предотвратить конфликты данных или их повреждение. Подробнее см. ReadWriteOncePod.

  • CSINodeExpandSecret находится в состоянии GA.

    Функция CSINodeExpandSecret переходит в GA. Эта функция позволяет передавать данные секретной аутентификации драйверу CSI для использования при добавлении узла.

  • Возможность проверки CRD на основе CEL находится в состоянии GA.

    Возможность проверки CRD на основе CEL переходит в GA. При включённой функции вам разрешено использовать CEL для определения правил валидации в CRD, которые более эффективны, чем webhook. Подробнее см. CRD verification rules.

Изменения и удаление API

  • Часовой пояс только что созданного CronJob нельзя настроить с помощью TZ или CRON_TZ в .spec.schedule. Вместо этого используйте .spec.timeZone. Уже созданные CronJob не затронуты этим изменением.
  • Alpha‑API ClusterCIDR удалён.
  • Параметр запуска --authentication-config добавлен в kube-apiserver для указания адреса файла AuthenticationConfiguration. Этот параметр запуска взаимно исключает параметр запуска --oidc-*.
  • Версия API kubescheduler.config.k8s.io/v1beta3 для KubeSchedulerConfiguration удалена. Перенесите файлы конфигурации kube-scheduler на kubescheduler.config.k8s.io/v1.
  • Выражения CEL добавлены в v1alpha1 AuthenticationConfiguration.
  • Тип ServiceCIDR добавлен. Он позволяет динамически настраивать диапазон IP-адресов, используемый кластером для выделения Service ClusterIPs.
  • Параметры запуска --conntrack-udp-timeout и --conntrack-udp-timeout-stream добавлены в kube-proxy. Это параметры для настройки параметров ядра nf_conntrack_udp_timeout и nf_conntrack_udp_timeout_stream.
  • Поддержка выражений CEL добавлена в WebhookMatchCondition объекта v1alpha1 AuthenticationConfiguration.
  • Тип PVC.spec.Resource изменён с ResourceRequirements на VolumeResourceRequirements.
  • onPodConditions в PodFailurePolicyRule помечено как необязательное.
  • API‑версия flowcontrol.apiserver.k8s.io/v1beta3 объектов FlowSchema и PriorityLevelConfiguration повышена до flowcontrol.apiserver.k8s.io/v1, выполнены следующие изменения:
    • PriorityLevelConfiguration: Поле .spec.limited.nominalConcurrencyShares по умолчанию равно 30, если поле опущено. Чтобы обеспечить совместимость с API‑серверами версии 1.28, указание явного значения 0 в версии v1 в 1.29 не допускается. В версии 1.30 явные значения 0 будут разрешены в этом поле в API v1. API flowcontrol.apiserver.k8s.io/v1beta3 устарели и более не будут обслуживаться в 1.32.
  • Документация по командной строке kube-proxy обновлена. kube-proxy не привязывает ни один сокет к IP-адресу, указанному параметром --bind-address.
  • Плагин планировщика selectorSpread заменён на podTopologySpread.
  • Если CSI-Node-Driver не запущен, вызовы NodeStageVolume будут повторяться.
  • Проверка типов ValidatingAdmissionPolicy теперь поддерживает CRD. Чтобы использовать эту функцию, необходимо включить переключатель функции ValidatingAdmissionPolicy.
  • Параметр запуска --nf-conntrack-tcp-be-liberal добавлен в kube-proxy. Его можно настроить, задав параметр ядра nf_conntrack_tcp_be_liberal.
  • Параметр запуска --init-only добавлен в kube-proxy. Установка флага заставляет init‑контейнер kube-proxy работать в привилегированном режиме, выполнить первоначальную конфигурацию и затем завершиться.
  • Поле fileSystem контейнера добавлено в тело ответа CRI. Оно указывает использование файловой системы контейнером. Изначально поле fileSystem содержало только файловую систему образов контейнеров.
  • Все встроенные облачные провайдеры отключены по умолчанию. Если их всё же необходимо использовать, можно настроить переключатели функций DisableCloudProviders и DisableKubeletCloudCredentialProvider для отключения или включения облачных провайдеров.
  • --node-ips можно использовать в kubelet для настройки двойного стека IPv4/IPv6. Если --cloud-provider установлен в значение external, вам разрешено использовать --node-ips для настройки двойного стека IPv4/IPv6 для IP‑адресов узла. Чтобы использовать --node-ips, необходимо включить фича‑гейт CloudDualStackNodeIPs.

Несовместимые изменения

В Kubernetes 1.29 поведение запуска kube-proxy было изменено. Это обновление позволяет kube-proxy использовать значение, меньшее, чем настройка узла sysctl. Например, если значение ядра nf_conntrack_max на узле установлено в 1000000, но kube-proxy вычисляет значение 131072, будет использовано значение 131072, вычисленное kube-proxy.

Community PR: https://github.com/kubernetes/kubernetes/pull/120448

Улучшенный Kubernetes 1.29 в CCE

Во время периода обслуживания версии CCE периодически обновляет Kubernetes 1.29 и предоставляет расширенные функции.

Для получения подробной информации об обновлениях версии кластера см. Patch Versions.

Ссылки

Для получения более подробной информации о сравнении производительности и эволюции функций между Kubernetes 1.29 и другими версиями см. Kubernetes v1.29 Release Notes.