Kubernetes 1.35 "Timbernetes" - Вертикальное Масштабирование и управление SLA

2025-12-18 19:21 Блог Безопасность

2025 годы завершается релизом Kubernetes v1.35 (кодовое имя «Timbernetes»), который принес 60 улучшений, из которых 17 перешли в статус Stable. Наши бэкенды, фронтенды и прочие инструменты деплоятся в Кубернетесе, поэтому мы с вниманием следим за изменениями в мире Cloud Native. В этом блоге коротко расскажем о самых важных изменениях в версии k8s 1.35.

Вертикальное масштабирование "на лету"

Еще в далеком феврале 2024 года мы писали об этой фиче - изменении ресурсов контейнера в поде без его перезагрузки. С релизом 1.35 эта функция перешла в Stable (KEP #1287). Если раньше для изменения лимитов CPU или RAM требовался перезапуск пода, что критично для Stateful-нагрузок, то теперь можно корректировать ресурсы без рестарта контейнеров.

Пользователи Vertical Pod Autoscaler, которые боялись перезагружать контейнеры, могут включить его в рабочий режим и не беспокоится о потенциальном даунтайме.

А вот такая ошибка больше не будет появлятся при изменении ресурсов контейнера:

The Pod "resize-test" is invalid: spec: Forbidden: pod updates may not change fields other than `spec.containers[*].image`,`spec.initContainers[*].image`,`spec.activeDeadlineSeconds`,`spec.tolerations` (only additions to existing tolerations),`spec.terminationGracePeriodSeconds` (allow it to be set to 1 if it was previously negative)

Gang Scheduling - контроль группы подов

Функция Gang Scheduling добавлена в Alpha ветку (KEP #4671). Она позволяет внедрить стратегию "все или ничего" для планирования запуска группы подов. Группа подов будет запущена, только если в кластере достаточно ресурсов для одновременного запуска всех ее подов. Это особенно удобно для сценариев, в которых поды взаимозависимы и должны работать вместе. В сообществе широко обсуждают важность этой фичи для распределенного обучения AI-моделей, когда необходимо, чтобы все обучающие поды стартовали одновременно. Это позволяет избежать ситуации, когда часть процессов ожидает выделения ресурсов, что приводит к простою вычислительных мощностей и снижению общей эффективности кластера.

KYAML - пока еще не JSON

KYAML — новый, более безопасный формат вывода для kubectl, призванный устранить самые частые ошибки при работе с YAML в Kubernetes. Он перешёл в статус Beta, начиная с версии k8s 1.35 (KEP #5295).

Это специальное подмножество YAML, в котором все строки в кавычках, а отступы не влияют на структуру данных. Это решает проблемы автоматического преобразования типов (когда NO превращается в false) и упрощает работу с шаблонами в Helm или Kustomize, поскольку код становится нечувствительным к пробелам.

Вместо стандартного YAML с риском ошибиться в отступах, KYAML использует явные скобки:

{
  apiVersion: "v1",
  kind: "Service",
  metadata: {
    name: "my-service",
    labels: {
      app: "my-app",
    },
  },
}

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

Числовые tolerations: планирование по SLA в Kubernetes

В Kubernetes 1.35 механизм taints и tolerations получил улучшение (KEP #5471) — поддержку числовых операторов Gt (больше) и Lt (меньше). Это позволяет разработать политики для работы с нодами с определенным уровнем надежности, что идеально для гибридных кластеров, сочетающих дорогие и дешёвые ноды (например, spot инстансы).

Ключевое отличие от NodeAffinity — поддержка NoExecute. Это позволяет не только контролировать размещение, но и автоматически вытеснять под с узла, если его SLA (например, доступность spot ноды) упадёт ниже заданного порога.

Вы ставите на spot инстанс taint sla=500:NoExecute. По умолчанию поды на неё не попадут. А вот какая-нибудь jobа может явно "согласиться" на работу, если SLA больше 400, добавив toleration:

tolerations:
- key: "sla"
  operator: "Gt"
  value: "400"
  effect: "NoExecute"

Это создаёт безопасную по модель: администратор централизованно задаёт риск на узлах, а разработчики явно "подписываются" на приемлемый для их сервисов уровень.

Node Declared Features: автоматическое управление версионной несовместимостью

Начиная с альфы в Kubernetes 1.35, добавляется фреймворк Node Declared Features. Его цель — автоматически решать проблему, когда новая функция включается на уровне кластера, но ноды обновляются постепенно и её не поддерживают.

Как это работает:

Ноды начинают автоматически объявлять в своём статусе список доступных функций. На основе этих данных система принимает решения:

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

Например: Фича "изменение ресурсов пода на лету". Если нода заявляет о поддержке GuaranteedQoSPodCPUResize, планировщик сможет разместить на нём соответствующие поды, а контроллер разрешит их динамическое обновление.

В чём выгода: Этот механизм устраняет рутинную работу. Администраторам больше не нужно вручную настраивать метки и правила для каждой новой функции Kubernetes — система автоматически обеспечивает совместимость.

Прощай, Ingress NGINX

В этом релизе продолжается активный переход от Ingress NGINX к Gateway API. Также прекращается поддержка первой версии контрольных групп Linux (cgroup v1), так как управление ресурсами полностью переходит на cgroup v2.

Полный список изменений в версии 1.35 доступен в официальном Changelog 1.35.

Сергей Пронин