CCE прошел Программу соответствия Certified Kubernetes и является сертифицированным предложением Kubernetes. CCE теперь поддерживает возможности кластера Kubernetes 1.28. Этот раздел описывает изменения, внесённые в Kubernetes 1.28.
Функции в alpha stage отключены по умолчанию, функции в beta stage включены по умолчанию, а функции в GA stage всегда включены и их нельзя отключить. Возможность включения или отключения функций в GA stage будет удалена в последующих версиях Kubernetes. Политики CCE для новых функций такие же, как в сообществе.
Начиная с control plane версии 1.28 и worker node версии 1.25, политика Kubernetes skew расширяет поддерживаемый сдвиг control plane и worker node до трёх версий. Это позволяет ежегодно выполнять минорные обновления узлов, оставаясь на поддерживаемых минорных версиях. Для подробностей смотрите Политика Version Skew.
Назначение retroactive default StorageClass переходит в GA. Это улучшение приносит значительное повышение того, как default StorageClasses назначаются PersistentVolumeClaims (PVCs).
Контроллер PV был изменён, чтобы автоматически назначать default StorageClass любому незакреплённому PVC с storageClassName не настроено. Кроме того, механизм проверки допуска PVC внутри API server был скорректирован, чтобы разрешить изменение значений из неустановленного состояния в реальное имя StorageClass. Для подробностей смотрите Назначение Retroactive default StorageClass.
Нативные sidecar контейнеры доступны в альфа. Kubernetes 1.28 добавляет restartPolicy к Init контейнерам. Это поле доступно, когда включён feature gate SidecarContainers. Однако всё ещё есть некоторые проблемы, которые нужно решить в нативных sidecar контейнерах. Поэтому сообщество Kubernetes рекомендует использовать этот feature gate только в короткоживущих тестовых кластеров на альфа-фазе. Для подробностей см. Введение нативных sidecar контейнеров.
Новый механизм (mixed version proxy) выпущен для улучшения обновления кластера. Это альфа‑функция в Kubernetes 1.28. Когда кластер проходит обновление, API‑серверы разных версий в кластере могут обслуживать разные наборы (группы, версии или ресурсы) встроенных ресурсов. Запрос ресурса, сделанный в этом сценарии, может быть обслужен любым из доступных API‑серверов, что потенциально приводит к тому, что запрос попадёт на API‑сервер, который может не знать о запрашиваемом ресурсе. В результате запрос завершается ошибкой. Эта функция может решить эту проблему. (Обратите внимание, что CCE предоставляет безпрерывное обновление. Поэтому эта функция не используется в кластерах CCE.) Для получения подробностей см. Новый (alpha) механизм для более безопасных обновлений кластера.
Неаккуратное выключение узла теперь доступно в GA в Kubernetes 1.28. Когда узел был выключен, и это выключение не было обнаружено Node Shutdown Manager kubelet'а, Pods StatefulSet, работающие на этом узле, останутся в состоянии terminated и не смогут быть перемещены на работающий узел. Если вы подтвердили, что узел с выключением непоправим, вы можете добавить вне сервиса taint на узле. Это гарантирует, что pod'ы StatefulSet и VolumeAttachments на этом узле могут быть принудительно удалены, а соответствующие pod'ы будут созданы на здоровом узле. Для получения подробностей см. Non-Graceful Node Shutdown Moves to GA.
Поддержка NodeSwap переходит в beta в Kubernetes 1.28. NodeSwap выключен по умолчанию и может быть включен с помощью переключателя функции NodeSwap. NodeSwap позволяет конфигурировать использование swap‑памяти для рабочих нагрузок Kubernetes, работающих на Linux, на уровне каждого узла. Обратите внимание, что хотя NodeSwap достиг beta, остаются некоторые проблемы, требующие решения, и необходимо усилить меры безопасности. Для получения подробностей см. Beta Support for Using Swap on Linux.
Введены две альфа‑функции: отложенное создание заменяющих pod'ов и лимит backoff на индекс.
По умолчанию, когда под переходит в состояние завершения (например, из‑за вытеснения или выселения), Kubernetes сразу создаёт заменяющий под. Поэтому оба пода работают одновременно.
В Kubernetes 1.28 эту возможность можно включить, включив фич‑гейт JobPodReplacementPolicy. При включённом фич‑гейте вы можете задать podReplacementPolicy поле в spec джобы для Сбой. Таким образом, поды будут заменяться только когда они достигают фазы сбоя, а не когда находятся в состоянии завершения. Кроме того, вы можете проверить .status.termination поле джобы. Значение этого поля определяет количество подов, связанных с джобой во время завершения.
По умолчанию сбои подов для индексированных джоб записываются и ограничиваются глобальным пределом повторных попыток, указанным в .spec.backoffLimit. Это означает, что если в задаче есть постоянно сбойный индекс, pods, указанные в задаче, будут перезапускаться неоднократно, пока сбои pods не исчерпают лимит. Когда лимит достигается, задача помечается как неудачная, и pods для других индексов в задаче могут никогда не запуститься.
В Kubernetes 1.28 эту возможность можно включить, включив feature gate JobBackoffLimitPerIndex кластера. При включённом feature gate, .spec.backoffLimitPerIndex может быть указано при создании индексированной задачи. Только если сбои pods со всеми индексами, указанными в этой задаче, превысят верхний лимит, pods, указанные в задаче, не будут перезапускаться.
Функции, связанные с CEL, улучшены.
Эта возможность была повышена до beta, начиная с Kubernetes 1.25. Встраивая выражения CEL в CRD, разработчики могут решать большинство сценариев проверки CR без использования webhooks. Более функций CEL, таких как поддержка значений по умолчанию и конверсия CRD, будут разработаны в более поздних версиях Kubernetes.
CEL admission control настраиваемый. С помощью CEL expressions вы можете решить, принимать или отклонять запросы, полученные kube-apiserver. CEL expressions также могут служить заменой admission webhooks. Kubernetes 1.28 обновил CEL admission control до beta и внедрил новые функции, такие как:
Во время периода технического обслуживания версии, CCE периодически обновляет Kubernetes 1.28 и предоставляет расширенные функции.
Для получения подробной информации об обновлениях версии кластера см Примечания к выпуску для версий кластера CCE.
Для получения дополнительных сведений о сравнении производительности и функциональной эволюции между Kubernetes 1.28 и другими версиями, см. Примечания к выпуску Kubernetes v1.28.