Вышел Kubernetes 1.34 — релиз с темой «Of Wind & Will» («О ветре и воле», сокращённо O’ WaW). Разработчики проекта традиционно сопровождают каждый выпуск девизом: по их словам, платформу вперёд двигают не идеальные условия, а воля тех, кто её строит и поддерживает. За красивым слоганом стоит вполне практичный набор изменений — и заметная часть касается именно сети.
Kubernetes используют все крупные облачные провайдеры: свои сервисы на его основе предлагают Microsoft, Google и Amazon. Для локальных и приватных облаков существуют дистрибутивы Red Hat, SUSE, Canonical и VMware. В основе всех коммерческих продуктов лежит один и тот же открытый проект, который выпускает три релиза в год.
Сколько всего изменений
В Kubernetes 1.34 вошли 58 доработок (enhancements): 23 получили статус stable, 22 — beta, 13 остаются в alpha. Каждое изменение проходит через процесс KEP (Kubernetes Enhancement Proposal), где фиксируется проблема, которую оно призвано решить.
Трафик остаётся рядом: PreferSameNode
Одна из давних болевых точек Kubernetes — неоптимальная маршрутизация трафика внутри кластера, из-за которой растут задержки на east-west-соединениях между подами. Решить эту проблему призвана инициатива KEP #3015 «PreferSameZone and PreferSameNode Traffic Distribution».
Поле spec.trafficDistribution в Kubernetes Service позволяет задавать предпочтения по маршрутизации трафика к эндпоинтам сервиса. В 1.34 значение PreferClose признано устаревшим, вместо него появляются два новых: PreferSameZone (по сути алиас для прежнего PreferClose, введённый для ясности) и PreferSameNode. Последнее значение указывает, что соединение должно по возможности направляться на локальный узел, а при отсутствии подходящего эндпоинта — переключаться на удалённый.
Технически это реализовано на уровне kube-proxy: теперь он учитывает заданные предпочтения и сначала пытается маршрутизировать трафик к эндпоинтам на локальном узле, и только затем рассматривает альтернативы. Для крупных кластеров это означает меньшую задержку и меньшую нагрузку на сеть при сохранении отказоустойчивости за счёт fallback-механизма.
DNS-пути стали менее строгими
KEP #4427 смягчает валидацию DNS search path для подов. Раньше строгая проверка часто мешала интеграции Kubernetes с корпоративной DNS-инфраструктурой в сложных или устаревших сетевых окружениях, вынуждая администраторов искать обходные пути. Изменение настройки резолвера предотвращает лишнюю пересылку запросов по внешним доменам на внутреннюю DNS-инфраструктуру кластера — это снижает нагрузку на внутренний DNS и устраняет конфликты, возникающие при пересечении внутреннего и внешнего доменных пространств.
Авторизация с учётом сетевой топологии
KEP #4601 расширяет возможности авторизации: теперь компоненты-авторизаторы Kubernetes API-сервера могут учитывать field- и label-селекторы из входящих запросов, включая сетевые. Это позволяет строить политики, ограничивающие доступ на основе топологии сети — например, разрешать листинг подов только для конкретного .spec.nodeName. При этом клиент (скажем, kubelet на определённом узле) обязан явно указать нужный field-селектор, иначе запрос будет отклонён. Функция особенно полезна для изоляции по узлам и мультитенантных сценариев, где сетевая топология играет роль границы безопасности.
DRA продолжает взрослеть
Релиз также демонстрирует общее взросление платформы — в частности, развитие функции Dynamic Resource Allocation (DRA), описанной в KEP-4381. Изначально планировщик Kubernetes учитывал только CPU и RAM, позже добавилась поддержка хранилища и дискретных пер-узловых расширенных ресурсов, но для многих современных устройств такого подхода уже не хватало. DRA даёт более гибкие способы выбирать, выделять, делить и настраивать GPU, TPU, сетевые карты и другие устройства, а также улучшает потоковую обработку крупных API-операций, снижая нагрузку на память при сетевоёмких рабочих нагрузках.
Источник: NetworkWorld.