Kubernetes v1.37: Garhwal

Автор Команда випуску Kubernetes v1.37 | Перекладач(і) Андрій Головін |

Редактори: Arsh Sharma, Christopher Tineo, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Troy Connor

Подібно до попередніх випусків, реліз Kubernetes v1.37 представляє нові стабільні, бета- та альфа-функції. Постійний випуск високоякісних версій підкреслює силу нашого циклу розробки та активну підтримку з боку нашої спільноти.

Цей випуск складається з 67 вдосконалень. З них 16 стали стабільними, 23 переходять у бета-версію, 27 стали альфа-функціями, а 1 функція визнана застарілою.

Темою для Kubernetes v1.37 є Гарвал (गढ़वाल, вимовляється як gaṛhvāl) — гімалайський регіон штату Уттаракханд, Індія. Засніжені вершини Гімалаїв у Гарвалі, ліси деодара, терасові поля, річки та струмки, а також гірські стежки формують як сам регіон, так і логотип. Усі ці елементи разом відображають спільноту, в якій кожен шар, кожен шлях і кожен внесок пов’язані між собою.

Логотип уявляється як вікно в пейзаж Гарвалу.1 Всередині терасові поля піднімаються до засніжених вершин, кожен рівень підтримується тим, що нижче, так само як кожен випуск Kubernetes залежить від роботи, виконаної раніше. Річка звивається долиною і збирає гірські потоки, відображаючи внески багатьох SIG та спільнот, що об’єднуються в один проєкт.

Деодаровий ліс — це ширша екосистема Kubernetes, де різні проєкти ділять спільну основу та ростуть пліч-о-пліч. Камʼяна кладка та деревʼяні конструкції формують стежку та гірський будинок, ставлячи людей у центр і викликаючи спільні основи, підтримувані для тих, хто йде слідом. Над річкою барвисті прапори ловлять вітер і оживляють сцену.

Сцену оточує фігурний каркас, натхненний кошикарством із рингаала — гнучкого карликового гімалайського бамбука. Окремі смужки набувають міцності, коли їх переплітають, так само як код, ревізії, тести, документація та координація об’єднуються для створення релізу.

У рамці зображений гімалайський монал — державний птах штату Уттаракханд, який мешкає на великих висотах у Гімалаях. Його райдужне пірʼя має безліч кольорів одночасно, подібно до того, як спільнота Kubernetes об’єднує різноманітні навички та погляди в одному проєкті. Квіти червоного буранша (Rhododendron arboreum), державного дерева штату Уттаракханд, мають у центрі символи Kubernetes, поєднуючи знайомий цвіт Гархвала із символом, який поділяє спільнота. На будинку зображено数字 १.३७ (1,37 у цифрах деванагарі), що вкорінює цей реліз у місцевий ландшафт.

1. Продовжуйте дивитися у вікно (логотип). Спостерігайте, як тече річка і як прапори майоріють на вітрі. За 37 секунд пейзаж відкриє свою магію.. 😉

Основні оновлення

Kubernetes v1.37 насичений новими функціями та покращеннями. Ось кілька оновлень, які Команда випуску хотіла б виділити!

Stable: Стійка ініціалізація watchcache

Kubernetes v1.37 завершує роботу над стійкою ініціалізацією watchcache: функціональна можливість ResilientWatchCacheInitialization досягла стану Stable ще в v1.34, а в v1.37 інша функціональна можливість WatchCacheInitializationPostStartHook переходить у Stable і заблокована. З v1.36 вона стандартно увімкнена, що посилює API-сервер при старті та під час відновлення. Ініціалізація та повторна ініціалізація watchcache більше не створюють стрибка трафіку запитів до etcd, а запити обробляються коректно замість накопичення під час прогрівання кешу.

Щоб уникнути надмірного навантаження etcd або вичерпання можливостей механізмів API Priority та Fairness через дорогі запити типу «list» та «watch», kube-apiserver тепер безпечно делегує запити з обмеженим обсягом, а інші відхиляє, повертаючи відповіді HTTP 429. Це знижує ризик відмови панелі управління у великих кластерах. Клієнти (включно з власними контролерами та операторами) мають коректно обробляти відповіді HTTP 429 Too Many Requests, дотримуючись заголовків Retry-After та використовуючи експоненційну затримку.

Ця робота була виконана як частина KEP #4568 під керівництвом SIG API Machinery.

Beta: Масштабування HorizontalPodAutoscaler до нуля

У Kubernetes v1.37 підтримка масштабування до нуля для HorizontalPodAutoscaler переходить у Beta. Вперше представлена в Kubernetes v1.16, вона тепер стандартно увімкнена.

Для робочих навантажень, що використовують метрики обʼєктів або зовнішні метрики, ця функція дозволяє HorizontalPodAutoscaler масштабуватися до нуля Podʼів у стані простою, а потім відновлювати їх, коли попит повертається. Це може знизити витрати для обробників черг, пакетних завдань та навантажень з GPU.

Масштабування до нуля на основі метрик CPU та памʼяті не підтримується, оскільки ці метрики залежать від активних Podʼів. Натомість ця функція призначена для сценаріїв, коли кількість реплік залишається нульовою, доки не зʼявиться робота в черзі для обробки.

Поки HorizontalPodAutoscaler утримує робоче навантаження з нульовою кількістю реплік, він фіксує стан ScaledToZero зі значенням True у статусі HorizontalPodAutoscaler. Контролер HorizontalPodAutoscaler потім використовує цей стан, щоб відрізнити робоче навантаження, яке він масштабував до нуля (і яке масштабується назад, коли показник повертається), від робочого навантаження, яке було вручну деактивоване встановленням кількості реплік у 0. Коли робоче навантаження масштабується назад, стан встановлюється у False з причиною NotScaledToZero.

Ця робота була виконана як частина KEP #2021 під керівництвом SIG Autoscaling.

Beta: Конфігурація контролю допусків на основі маніфестів

Kubernetes v1.37 переводить конфігурацію контролю допусків на основі маніфестів у Beta. Admission webhooks та політики на основі CEL тепер можуть завантажуватися з маніфестів на диску через поле staticManifestsDir у AdmissionConfiguration, замість того, щоб існувати лише в Kubernetes API. Політики, завантажені таким чином, застосовуються з моменту запуску сервера API, продовжують діяти навіть під час недоступності etcd і можуть захищати самі ресурси допуску на основі API від модифікації.

Ця робота була виконана як частина KEP #5793 під керівництвом SIG API Machinery.

Alpha: Контрольна точка та відновлення на рівні Podʼів

Kubernetes v1.37 представляє підтримку Alpha для контрольних точок та відновлення на рівні Podʼів, розширюючи CRI за допомогою RPC CheckpointPod та RestorePod, які дозволяють kubelet та сумісним рушіям виконання контейнерів створювати контрольну точку Podʼа та відновлювати Podʼа з неї. Щоб використати цю функцію, середовище виконання контейнерів також має реалізувати ці нові RPC.

Ця робота була виконана як частина KEP #5823 під керівництвом SIG Node.

Функції, що переходять у стабільний стан

Цей розділ перераховує всі функції, що перейшли в Stable (також відомий як стан загальної доступності (GA, General Availability)). Для повного списку оновлень, включаючи нові функції та переходи з Alpha в Beta, дивіться примітки до випуску.

Цей випуск включає загалом 16 вдосконалень, переведених у Stable:

KYAML

KYAML — це безпечніша та менш неоднозначна підмножина YAML, розроблена спеціально для Kubernetes, а не заміна для нього. Кожен файл KYAML є валідним YAML, тож KYAML є валідним вхідним форматом для будь-якої версії kubectl, а файли специфікацій не потрібно писати саме в KYAML, щоб їх можна було обробити. Ваші наявні маніфести, інструменти та конвеєри не потребують змін. KYAML вперше представлений як альфа-функція у v1.34 і перейшов у бета-версію в v1.35. KYAML переходить у стабільний стан у v1.37 після завершення тестування на відповідність, і команда kubectl get -o kyaml тепер також є стабільною.

Щоб дізнатися більше про KYAML, перегляньте допис «Як форматувати ваш Kubernetes YAML у форматі KYAML і навіщо це потрібно».

Ця робота була виконана як частина KEP #5295 під керівництвом SIG CLI.

API metrics.k8s.io

API metrics.k8s.io переходить у Stable в Kubernetes v1.37 після майже девʼяти років у Beta. API надає стандартний спосіб отримання відомостей про використання CPU та памʼяті для podʼів та вузлів, живлячи широко використовувані функції Kubernetes такі як HorizontalPodAutoscaler (HPA) та команди на кшталт kubectl top.

Перехід відповідає цілі проєкту Kubernetes уникати постійних API у Beta. Тепер, коли v1 існує, майбутні випуски Kubernetes перейдуть на нього; v1beta1 залишається придатним для використання протягом переходу, відповідно до політики застарівання API, тому ви можете прийняти Stable API, не ламаючи існуючі робочі процеси.

Ця робота була виконана як частина KEP #5207 під керівництвом SIG Instrumentation.

SELinuxMount та SELinuxChangePolicy

У Kubernetes v1.37 прапорці SELinuxMount та SELinuxChangePolicy переходять у Stable і стандартно ввімкнені: це означає, що томи монтуються з -o context=<label> (типово MountOption) замість рекурсивного перейменування, але лише коли CSI драйвер тому обирає через .spec.seLinuxMount: true для обʼєкта CSIDriver.

Монтування може нести лише один контекст SELinux, тому Podʼи з різними мітками SELinux, що разом використовують том на одному вузлі, які раніше співіснували під час рекурсивного перейменування, тепер можуть не запуститися. Щоб зберегти стару поведінку для роботи, рекомендується встановити .spec.seLinuxChangePolicy у Recursive для Pod.

Ця поведінка сама по собі не заблокована до v1.38, тому відключення її на рівні кластера залишається варіантом на ще один випуск. Кластери без увімкненого SELinux не відчувають жодного ефекту. Щоб дізнатися більше, перегляньте Зміни міток томів SELinux переходять у GA (і ймовірні наслідки в v1.37).

Ця робота була виконана як частина KEP #1710 під керівництвом SIG Storage.

Функції DRA, що переходять у стабільний стан

DRA: Статус ResourceClaim з можливими стандартизованими даними мережевого інтерфейсу

Статус .status.devices ResourceClaim переходить у Stable в Kubernetes v1.37, що дозволяє драйверам повідомляти специфічні для пристрою дані статусу для кожного виділеного пристрою в заявці на ресурс. Це полегшує розуміння того, як налаштовано пристрій, усунення несправностей та використання пристрою разом з іншими сервісами.

Це особливо корисно для мережевих пристроїв; до додавання цього поля, якщо Pod запитував мережевий пристрій через DRA, жоден інший компонент системи не мав можливості дізнатися IP-адресу, присвоєну цьому мережевому пристрою. Нове поле стану забезпечує стандартизований спосіб, за допомогою якого драйвер DRA може передавати цю інформацію компонентам, які її потребують, що робить DRA повністю придатним для підключення додаткових мережевих інтерфейсів до Podів.

Ця робота була виконана як частина KEP #4817 під керівництвом SIG Node та SIG Network.

DRA: обробка запитів розширених ресурсів через драйвер DRA

Підтримка розширених ресурсів DRA переходить у Stable в Kubernetes v1.37. Ця функція дозволяє драйверам DRA задовольняти запити, зроблені через традиційний механізм розширених ресурсів, наприклад abc.example/gpu: 3 у специфікації Podʼа, без необхідності окремого втулка пристрою.

За допомогою цього механізму імʼя розширеного ресурсу може бути призначене безпосередньо DeviceClass. Podʼи, що запитують цей ресурс, можуть мати пристрій, виділений через DRA, без необхідності визначати ResourceClaim у робочому навантаженні.

Ця робота була виконана як частина KEP #5004 під керівництвом SIG Scheduling.

DRA: позначки taint та toleration пристроїв

Підтримка taints та tolerations для фізичних пристроїв, керованих через DRA, тепер є Stable в Kubernetes v1.37. Стандартно будь-який доступний пристрій може розглядатися для планування. Це вдосконалення надає більший контроль над плануванням пристроїв, дозволяючи драйверам DRA позначати конкретні пристрої позначкою taint, запобігаючи їхньому вибору для робочих навантажень. Крім того, адміністратори кластера можуть створити DeviceTaintRule для позначення пристроїв як taint на основі конкретних критеріїв відбору, наприклад, усіх пристроїв, керованих певним драйвером.

Ця робота була виконана як частина KEP #5055 під керівництвом SIG Scheduling.

DRA: стандартний атрибут пристрою numaNode

Kubernetes v1.37 визначає новий стандартний атрибут пристрою NUMA-вузла. Він стандартизує resource.kubernetes.io/numaNode як спільне імʼя атрибуту для інформації про NUMA-вузол пристрою, дозволяючи пристроям, керованим різними драйверами DRA, порівнюватися на основі одного й того ж NUMA-вузла. Це дозволяє уникати ситуації, коли кожен драйвер визначає власну назву атрибуту, і надає послідовний спосіб ідентифікації NUMA-розміщення між пристроями. Це вдосконалення одразу переходить у стабільний стан, оскільки це KEP щодо іменування та реєстрації без функціональної можливості чи змін поведінки в кодовій базі.

Ця робота була виконана як частина KEP #6072 під керівництвом SIG Node.

Функції, оголошені вузлом

Функції, оголошені вузлом переходять у Stable в Kubernetes v1.37, надаючи фреймворк для оголошення доступності конкретних, керованих функціональними можливостями функцій Kubernetes для вузлів. Ці функції потім використовуються компонентами панелі управління (такими як kube-scheduler, контролери допуску або сам API-сервер) для керування розбіжністю версій (version skew).

Функція вводить нове поле .status.declaredFeatures для вузлів, яке використовується для оголошення функції, що проходить через етапи Alpha → Beta → Stable. Панель управління може використовувати це поле для забезпечення правильної роботи навіть у кластері, де одночасно працюють вузли з різними версіями.

Коли функції переходять у Stable і панель управління може припустити, що всі вузли підтримують їх у межах вікна розбіжності версій, вузли припиняють повідомляти про них.

kubelet визначає свої оголошені функції при запуску, базуючись лише на функціональних можливостях та статичній конфігурації вузла (отже, будь-які зміни вимагають перезапуску kubelet).

Ця робота була виконана як частина KEP #5328 під керівництвом SIG Node.

Мігратор версій сховища

Kubernetes v1.37 переводить API StorageVersionMigration (storagemigration.k8s.io/v1) у Stable і стандартно його вмикає. Він допомагає виконувати мігрувацію наявних ресурсів, як вбудованих, так і власних ресурсів користувача, зі старішої версії сховища на нову після оновлення API, наприклад, коли бажана версія сховища змінюється з v1beta1 на v1. Його також можна використати для перезапису наявних даних після зміни шифрування у стані спокою, щоб застарілі дані зберігалися з новими налаштуваннями шифрування.

Історично адміністраторам кластерів та авторам CustomResourceDefinition доводилося використовувати ручні скрипти kubectl get або kubectl replace, або розгортати out-of-tree компонент kube-storage-version-migrator для переписування наявних ресурсів. Ці підходи часто були важкими, схильними до помилок і важкими для моніторингу.

Щоб розпочати міграцію версії сховища, користувачам потрібно створити декларативний обʼєкт StorageVersionMigration. Вбудований контролер StorageVersionMigrator у панелі управління Kubernetes слідкує за цими обʼєктами і виконує автоматичну міграцію наявних ресурсів до базової версії сховищення для цього API. Оскільки StorageVersionMigration є стандартним Kubernetes API, автори CRD можуть запускати міграції як частину оновлення CRD замість окремого керування міграцією.

Ця робота була виконана як частина KEP #4192 під керівництвом SIG API Machinery.

Stable: Сертифікати Podʼів та Cluster Trust Bundles

Сертифікати Podʼів та тісно повʼязані ClusterTrustBundles обидва переходять у Stable в Kubernetes v1.37, надаючи першокласну підтримку для розповсюдження приватних ключів, X.509 сертифікатів та пакунків довіри до Podʼів.

Щоб це використати, розробник або адміністратор обирає імʼя підписувача і розгортає контролер підписувача, який спостерігає за обʼєктами PodCertificateRequest, видає та оновлює сертифікати для придатних Podʼів і підтримує відповідні обʼєкти ClusterTrustBundles, що містять довірчі точки (trust anchors), необхідні для перевірки цих сертифікатів. Робоче навантаження потім підключається до цієї ідентичності, визначаючи проєкційний том podCertificate з обраним імʼям підписувача. Робочі навантаження також можуть монтувати проєкційний том ClusterTrustBundle для завантаження інформації про довірчі точки.

Ця робота була виконана як частина двох KEP — KEP #4317 та KEP #3257 під керівництвом SIG Auth.

Функції, що перейшли в Beta

Підтримка групового планування (Gang scheduling) в Kubernetes

Оскільки Kubernetes стає де-факто стандартом для керування AI/ML навантаженнями в масштабі, планування таких робіт, як тренування AI/ML моделей та HPC-симуляції, стає важливішим ніж будь-коли. Однак планування стає викликом, оскільки стандартний планувальник Kubernetes планує Podʼи індивідуально, що може призвести до того, що деякі Podʼи плануються, тоді як інші залишаються у стані очікування через нестачу ресурсів. Таке часткове планування може призвести до взаємних блокувань (deadlock) та неефективного використання ресурсів кластера.

Групове планування (Gang scheduling) переходить у Beta в Kubernetes v1.37, вдосконалюючи нативну підтримку групового планування через Workload API та концепцію PodGroup. Ця функція реалізує стратегію планування «все або нічого», забезпечуючи, що визначена група Podʼів планується лише тоді, коли кластер має достатньо ресурсів для розміщення всієї групи. Перехід у Beta також вводить планування з урахуванням навантаження (workload-aware preemption), щоб уникнути передчасних витіснень, які не допомагають навантаженню просуватись в роботі, а також чергування PodGroup для кращої координації конкуруючих навантажень.

Важливо, що це вирішує сценарії активного очікування (livelock), які можуть виникати, коли кілька навантажень плануються одночасно kube-schedulerʼом, запобігаючи їхньому взаємному блокуванню без прогресу.

Ця робота була виконана як частина KEP #4671 під керівництвом SIG Scheduling.

Нативна підтримка гістограм для метрик Kubernetes

Kubernetes експонує сотні метрик-гістограм у форматі Prometheus у компонентах панелі управління, які є необхідними для моніторингу стану кластера та відстеження проблем продуктивності. Однак класичні гістограми Prometheus покладалися на статичні, заздалегідь визначені кошики (buckets), що змушувало йти на компроміс між точністю даних та використанням памʼяті. Для помʼякшення цього Prometheus представив нативні гістограми, які використовують динамічні експоненційні межі кошиків замість фіксованих, забезпечуючи значну ефективність зберігання, покращену продуктивність запитів та детальнішу видимість розподілів, зберігаючи при цьому повну зворотну сумісність з наявною інфраструктурою моніторингу.

Kubernetes v1.37 переводить нативну підтримку гістограм для метрик Kubernetes у бета-версію. Базуючись на реалізації Alpha, яка ввела функціональну можливість NativeHistograms, фаза Beta покращує реалізацію та досвід розгортання. Коли увімкнено, компоненти Kubernetes експонують гістограми як у класичному, так і в нативному форматах, коли запитуваний протокол скрейпінгу підтримує Нативні Гістограми (зокрема PrometheusProto), дозволяючи наявним дашбордам та сповіщенням продовжувати працювати, поки користувачі виконують міграцію у власному темпі. Реалізація також переробила гістограми, створені в функціях init(), для використання лінивої ініціалізації, гарантуючи, що опції нативних гістограм правильно застосовуються після обробки функціональних можливостей. Ці зміни надають більш надійну реалізацію, зберігаючи при цьому безпечні розгортання та відкат через функціональну можливість або конфігурацію на стороні Prometheus для користувачів Prometheus 3.x.

Ця робота була виконана як частина KEP #5808 під керівництвом SIG Instrumentation.

WAS: Функції, що переходять у Beta

Витіснення з урахуванням навантаження

Традиційно Kubernetes виконує витіснення на рівні Podʼів, що може бути неефективним для навантажень, що складаються з кількох тісно повʼязаних Podʼів. У Kubernetes v1.37 витіснення з урахуванням навантаження (workload-aware preemption, WAP) переходить у Beta, дозволяючи планувальнику враховувати PodGroup при прийнятті рішень про витіснення. Це допомагає планувальнику розглядати навантаження як єдину сутність при витісненні навантажень нижчого пріоритету, зменшуючи випадки, коли індивідуальні Podʼи витісняються без забезпечення достатньої потужності для роботи корисного навантаження.

Ця робота була виконана як частина KEP #5710 під керівництвом SIG Scheduling.

DRA: Підтримка ResourceClaim для навантажень

Dynamic Resource Allocation (DRA) дозволяє Podʼам запитувати спеціалізовані ресурси через ResourceClaims. У Kubernetes v1.37 підтримка DRA ResourceClaims для навантажень переходить у Beta, дозволяючи Workload та PodGroup API асоціювати ResourceClaims та ResourceClaimTemplates з групами Podʼів. Це дозволяє ResourceClaims бути спільними для всього навантаження замість індивідуального резервування для кожного Podʼа, тоді як ResourceClaimTemplates можуть автоматично створювати claims для PodGroup.

Ця робота була виконана як частина KEP #5729 під керівництвом SIG Scheduling.

Статистика контейнерів та Podʼів без cAdvisor, повністю через CRI

kubelet історично отримував статистику контейнерів та Podʼів з cAdvisor, тоді як Container Runtime Interface (CRI) експонував власну статистику. Наявність двох джерел для однакових метрик ускладнює розуміння, звідки взялося конкретне значення.

У Kubernetes v1.37 покращення «статистика контейнерів та Podʼів без cAdvisor, повністю через CRI» переходить у Beta. Це покращення розширює CRI для надання статистики контейнерів та Podʼів, необхідної Kubernetes, дозволяючи kubelet отримувати ці метрики безпосередньо від рушія виконання контейнерів замість залежності від cAdvisor.

Це переміщує метрики контейнерів та Podʼів до єдиного джерела правди, одночасно зменшуючи дублювання збору метрик та спрощуючи те, як kubelet збирає та виставляє ці статистики.

Ця функція є Beta у v1.37, але стандартно вимкнена; увімкніть функціональну можливість PodAndContainerStatsFromCRI, щоб спробувати її.

Ця робота була виконана як частина KEP #2371 під керівництвом SIG Node.

Підтримка memory QoS з cgroups v2

Kubernetes покращує свої механізми якості обслуговування (QoS) для покриття захисту та ізоляції памʼяті для навантажень Kubernetes. Для вузлів, що працюють на Linux, функція memory QoS використовує запити та ліміти памʼяті для налаштування cgroup-контролів, які можуть захистити запитану памʼять від відновлення (reclamation) та обмежити (throttle) використання памʼяті до досягнення жорстких лімітів навантаженням. Це може допомогти зменшити вплив тиску памʼяті на чутливі до памʼяті навантаження та покращити стабільність вузла.

У Kubernetes v1.37 підтримка memory QoS переходить у Beta. Функція використовує cgroups v2 контролі памʼяті, такі як memory.min, memory.low та memory.high, для надання різних рівнів захисту памʼяті та обмеження. Наприклад, запити памʼяті можуть використовуватися для захисту памʼяті від відновлення, тоді як memory.high може використовуватися для обмеження навантажень, що перевищують свої налаштовані пороги.

Функціональна можливість MemoryQoS стандартно увімкнена у v1.37. Оператори кластерів можуть контролювати захист памʼяті через налаштування memoryReservationPolicy у kubelet та налаштовувати обмеження памʼяті за допомогою memoryThrottlingFactor. Типово вони розроблені так, щоб уникнути несподіваного обмеження памʼяті для існуючих навантажень при оновленні до v1.37, одночасно дозволяючи операторам підключитися до додаткових можливостей захисту памʼяті.

Ця робота була виконана як частина KEP #2570 під керівництвом SIG Node.

Менеджери ресурсів на рівні Podʼів

У Kubernetes v1.37 менеджери ресурсів на рівні Podʼів переходять у Beta з функціональною можливістю PodLevelResourceManagers, яка залишається стандартно вимкненою. Її увімкнення дозволяє менеджерам топології, CPU та памʼяті використовувати ресурси, визначені для всього Podʼа, при прийнятті рішень про виділення та NUMA-вирівнювання. Це робить можливим керування Podʼом як єдиною одиницею ресурсів, одночасно підтримуючи різні вимоги до ресурсів між контейнерами всередині нього.

З управлінням ресурсів на рівні Podʼа, Pod може резервувати NUMA-вирівняний пул CPU та памʼяті на основі свого загального ресурсного бюджету. Контейнери, що вимагають виділених ресурсів, можуть отримати ексклюзивні частини цього пулу, тоді як інші контейнери, такі як sidecar або підтримуючі навантаження, можуть спільно використовувати залишкові ресурси. Це особливо корисно для промислових чутливих навантажень, таких як AI/ML та HPC, де зберігання ресурсів близько один до одного на одному NUMA-вузлі може покращити продуктивність без вимоги, щоб кожен контейнер у Podʼі мав виділені ресурси.

Ця функція також підтримує область дії контейнера, в якій контейнери можуть і надалі отримувати незалежні виділення ресурсів, вирівняні за NUMA. Це забезпечує більшу гнучкість для робочих навантажень, що поєднують контейнер, чутливий до продуктивності, з іншими контейнерами, які мають інші вимоги до ресурсів.

Ця робота була виконана як частина KEP #5526 під керівництвом SIG Node.

Узгоддження контролера маршрутів на основі watch (Watch-based route controller reconciliation)

Контролер маршрутів у бібліотеці cloud-controller-manager раніше виконував узгодження маршрутів за фіксованим інтервалом, типово кожні 10 секунд. Це могло призводити до непотрібних запитів до провайдерів інфраструктури, навіть коли нічого не змінювалося, а також затримувати оновлення маршрутів при додаванні нового вузла.

Узгодження контролера маршрутів на основі watch перейшло в Beta в Kubernetes v1.37. Цей випуск також додає спостережуваність для цієї роботи: Alpha-метрика контролера маршрутів route_sync_total отримує дві мітки — trigger (periodic або node_change) та outcome (changed, noop або error), щоб оператори могли бачити, чи періодична реконсиляція дійсно виправляє дрифт маршрутів або просто працює як no-op, і відстежувати невдалі узгодження.

З узгодженням на основі watch, контролер маршрутів може узгоджувати маршрути з подій watch замість очікування наступного фіксованого інтервалу: узгодження може розпочатися негайно, коли відбуваються відповідні зміни вузла, такі як додавання або видалення вузла, або коли змінюються його адреси або призначені Pod CIDR. Менш часте періодичне узгодження все ще виконується для виявлення застарілих маршрутів та підтримки узгодженості стану. Ця поведінка знаходиться за функціональною можливістю CloudControllerManagerWatchBasedRoutesReconciliation і стандартно вимкнена, отже, перехід не змінив типову поведінку.

Це зменшує непотрібні запити до провайдерів інфраструктури, дозволяючи одночасно швидше узгоджувати маршрути для щойно доданих вузлів. Зміна не змінює логіку узгодження маршрутів саму по собі; вона змінює те, коли запускається узгодження.

Ця робота була виконана як частина KEP #5237 під керівництвом SIG Cloud Provider.

Оцінка ємності сховища вузлів

Втулок планувальника VolumeBinding завжди міг робити оцінку (scoring) вузлів для статично привʼязаних PV на основі вільної ємності, але ця оцінка ніколи не поширювалася на динамічне провизионування.

Коли CSI-драйвер провизионує новий том за запитом, планувальник не мав способу віддати перевагу вузлу з більшою або меншою вільною областю.

Це було прогалиною для локального сховища, оскільки адміністратор міг хотіти, щоб Podʼи потрапляли на вузол з найбільшою вільною ємністю, щоб залишити місце для пізнішого розширення тома, або на вузол з найменшою (але все ще достатньою) вільною ємністю, щоб упакувати навантаження щільніше (bin-pack) і зменшити кількість вузлів, необхідних для роботи хмарного кластера.

Kubernetes v1.37 переводить оцінювання ємності сховища для динамічного провізіонування у бета-версію за допомогою функціональної можливості StorageCapacityScoring. Її вперше представили в альфа-версії в v1.33, а ця функція обʼєднує й оголошує застарілою старішу функціональну можливість VolumeCapacityPriority з KEP #1845. Коли її увімкнено, точка розширення Score втулка VolumeBinding зчитує обʼєкти CSIStorageCapacity, опубліковані зовнішнім sidecar-контейнером провізіонера драйвера, й оцінює вузли для динамічного провізіонування так само, як уже робить для статичних привʼязок. Адміністратори обирають стратегію через параметр Shape у VolumeBindingArgs — типово це «надавати перевагу вузлу з максимальною доступною ємністю», щоб залишити простір для подальшого розширення.

Функція залежить виключно від функціональної можливості StorageCapacityScoring: оцінка для статично привʼязаних PV запускається одразу при увімкненні, незалежно від будь-якого CSI-драйвера. Драйверу потрібно лише StorageCapacity: true на своєму обʼєкті CSIDriver, щоб його динамічно надані томи також отримували оцінку з урахуванням ємності. Функція повністю зворотня, і вимкнення функціональної можливості зупиняє всю оцінку ємності VolumeBinding, як статичну, так і динамічну, без впливу на вже заплановані Podʼи.

Ця робота була виконана як частина KEP #4049 під керівництвом SIG Storage.

Інтеграція CSI лімітів підключення томів з Cluster Autoscaler

У Kubernetes v1.37 покращено інтеграцію Cluster Autoscaler з обмеженнями підключення томів CSI, завдяки чому під час створення нових вузлів для Podʼів, що очікують на обробку, Cluster Autoscaler може точніше визначити, скільки нових вузлів потрібно для підключення всіх Podʼів, що очікують на обробку та використовують томи CSI. Cluster Autoscaler вже мав доступ до інформації про обмеження підключення томів CSI для наявних вузлів, але не для вузлів, які він збирався створити, що означало: він міг недостатньо масштабувати систему і залишати Podʼи, що використовують томи, у стані очікування навіть після додавання ємності. Проблема ускладнюється з боку планування: втулок NodeVolumeLimits розглядає вузол без опублікованої інформації про драйвер CSI як такий, що не має жодних обмежень, тому щойно створений вузол, який ще не повідомив про свій об’єкт CSINode, може бути переповнений більшою кількістю Podʼів, підкріплених томами, ніж він фактично може підключити, що є конкурентною ситуацією, яку дотепер адміністратори кластерів не мали можливості усунути.

У версії Kubernetes v1.37 функція автоматичного масштабування з підтримкою CSI переходить у стадію бета-тестування з функціональною можливістю VolumeLimitScaling, яка вперше була представлена у версії v1.35 у стадії альфа-тестування. Cluster autoscaler тепер запускає симуляції масштабування вгору для шаблонних обʼєктів CSINode, щоб правильно враховувати ліміти підключення, чи то він масштабує наявну групу вузлів, чи створює її з нуля. З боку планувальника, адміністратори можуть підключитися на рівні CSIDriver, через нове поле PreventPodSchedulingIfMissing, щоб заблокувати розміщення Podʼів на вузлах, що ще не повідомили свій драйвер, з виділеними помилками CSIDriverMissingOnNode та CSINodeMissing, що роблять ці помилки планування легшими для відстеження. Фаза Beta додає наскрізне покриття для поведінки масштабування вниз та сценаріїв CSI opt-in, та оновлює метрики failed_scale_ups_total та scaled_up_nodes_total, щоб включати інформацію про CSI-драйвери. Зміни як в автомасштабувачі, так і в планувальнику залишаються суто опціональними: вимкнення функціональної можливості відновлює поточне стандартне значення — необмежене розміщення подів на вузлах без даних CSINode, тому дистрибутиви та адміністратори, які використовують автомасштабувачі, що ще не підтримують CSI (наприклад, Karpenter), не змушені переходити на нову модель роботи.

Ця робота була виконана як частина KEP #5030 під керівництвом SIG Autoscaling.

Звіт про час останнього використання PVC

PersistentVolumeClaims зазвичай живуть довше за навантаження, що їх створили. Коли застосунок видаляється або мігрує, його PVC залишається, споживаючи сховище та збільшуючи витрати. Сьогодні Kubernetes не дає адміністраторам кластерів жодного способу дізнатися, як довго PVC просидів бездіяльно; kubelet є єдиним компонентом, який дійсно знає, коли том був змонтований останній раз, але немає чогось що не виводить цю інформацію на рівні API, тому адміністратори залишаються вгадувати, які PVC насправді безпечні для очищення.

Kubernetes v1.37 переводить відстеження «останнього використання» PVC у Beta з функціональною можливістю PersistentVolumeClaimUnusedSinceTime, яка у Alpha (v1.36) була стандартно вимкнена, а тепер стандартно увімкнена. Функція додає новий стан Unused до PersistentVolumeClaimStatus, якою керує наявний контролер захисту PVC: Status=True (Reason=NoPodsUsingPVC) коли останній нетермінальний Pod, що посилається на PVC, зникає, і назад до Status=False (Reason=PodUsingPVC) якомога швидше, як тільки Pod починає посилатися на нього знову. lastTransitionTime цього стану використовується як позначка часу «невикористано з», тому адміністратори можуть запитати, та як довго PVC дійсно просидів бездіяльно, без того, щоб Kubernetes відстежував, який саме Pod використав його останнім, чи приймав будь-які рішення про видалення — це залишається повністю на розсуд адміністратора. Варто зазначити, що позначка часу відображає момент, коли контролер спостерігав відсутність Podʼів, що використовують PVC, а не точний момент розмонтування тома на рівні інфраструктури, тому повідомлений час бездіяльності може бути дещо меншим за справжній, але ніколи не перевищить його.

Ця робота була виконана як частина KEP #5541 під керівництвом SIG Storage.

Підтримка etcd RangeStream

Унарний RPC-виклик Range в etcd формує повну відповідь у пам’яті перед її відправкою, що стає проблемою при масштабуванні. У випадку великого списку, наприклад, під час розігріву кешу спостереження kube-apiserver у великому кластері, необроблений фрагмент «ключ-значення», його серіалізована форма protobuf та буфер відправки gRPC мають одночасно співіснувати в пам’яті, а внаслідок цього спалахи навантаження поширюються й на kube-apiserver. Разбиття на сторінки також не вирішує проблему базових витрат, оскільки кожна сторінка все одно проходить весь індекс B-дерева для обчислення загальної кількості результатів, перетворюючи операцію, яка мала б бути O(limit), на операцію O(total_keys) для кожної окремої сторінки.

У Kubernetes v1.37 підтримка etcd RangeStream надається безпосередньо у версії Beta, з функціональною можливістю EtcdRangeStream (лише для kube-apiserver, стандартно увімкнено). У цьому випуску додано новий RPC-інтерфейс RangeStream для потокової передачі на сервері, який використовує наявний RangeRequest але повертає фрагменти замість одного буферованого блоку: сервер внутрішньо розбиває дані на сторінки з адаптивним розміром фрагментів (цільовий розмір кожного фрагмента коригується на основі MaxRequestBytes та розмірів значень, зафіксованих на даний момент), фіксує одну ревізію MVCC, щоб об’єднаний потік залишався узгодженим зі знімком, та обчислює загальну кількість ключів на основі поточного підрахунку, який формується під час потокової передачі, а не шляхом окремого обходу індексу. Ініціалізація кешу спостереження kube-apiserver є основним споживачем, і тепер вона декодує кожен фрагмент у синтетичні події created безпосередньо під час їх надходження, замість того, щоб спочатку збирати повний список у пам’яті; така сама обробка застосовується до прямих викликів GetList, коли WatchList вимкнено.

Ця функція вимагає etcd версії 3.7 або вище; у разі використання старішої версії etcd, kube-apiserver виявляє відповідь Unimplemented і автоматично переходить на унарний Range, без жодних змін у поведінці. Якщо закріплена ревізія ущільнюється в процесі роботи, kube-apiserver трактує це так само, як і будь-яку іншу помилку ініціалізації кешу спостереження, і робить повторну спробу, що не гірше, ніж гонитви за ущільнення, з якими вже сьогодні може зіткнутися виклик List з розбиттям на сторінки. Критерії виходу з бета-версії включають тест на масштабованість, що вимірює затримку при роботі з великими списками на кластері з 5000 вузлів, а команда etcdctl get --stream поставляється разом із нею для тих, хто хоче безпосередньо протестувати новий RPC.

Ця робота була виконана як частина KEP #5966 під керівництвом SIG etcd.

Конкурентне декодування обʼєктів watch

kube-apiserver декодує та перетворює кожну подію спостереження з etcd по черзі в одній goroutine, тому одне повільне перетворення на подію, зокрема виклик вебхука для конвертації CRD, блокує всі події, що стоять у черзі за ним. Це здебільшого створює незручності для вбудованих ресурсів, але для CRD, версія якого в сервісі відрізняється від збереженої, послідовне перетворення «холодного» кешу може займати кілька хвилин. Якщо це перевищує стандартний 5-хвилинний інтервал ущільнення etcd, ревізія, з якої кеш почав читати, ущільнюється до завершення ініціалізації, спостереження не може поновитися, а ініціалізація просто перезапускається і ніколи не завершується для достатньо великого ресурсу, при цьому кожен клієнт, який намагається перелічити або спостерігати за ним, отримує помилки.

Функціональна можливість ConcurrentWatchObjectDecode фактично була у Beta, стандартно вимкнена, з v1.31, і Kubernetes v1.37 стандартно увімкнув її. Це увімкнення переміщує крок декодування/трансформації на обмежений пул робітничих goroutines (10 типово, налаштовано з перебору, що показав, що вигоди отримуються навколо 8–12) замість однієї, з колектором, що збирає події назад у їхній оригінальний порядок перед доставкою, тому порядок подій зберігається точно. У бенчмарках на 150k+ podʼах, лише паралельне декодування скорочує ініціалізацію кешу приблизно на 40%, а приблизно на 55% в поєднанні з новою функцією EtcdRangeStream, що також виходить в цьому випуску (див. KEP 5966). Головний компроміс, за яким варто слідкувати — навантаження на conversion webhook. З увімкненою функцією, до 10 конвертацій тепер можуть одночасно виконуватися для webhookʼа під час ініціалізації кешу замість однієї за раз. Загальний обсяг викликів не змінюється, лише кількість, що виконуються одночасно, отже це переважно стосується webhookʼів, які обмежують власну конкурентність нижче 10.

Ця робота була виконана як частина KEP #6178 під керівництвом SIG API Machinery.

Заходи щодо усунення наслідків використання застарілого контролера

Кожен контролер у kube-controller-manager працює з локального кешу, побудованого шляхом спостереження за kube-apiserver, а цей watch-потік є лише зрештою консистентним. Зміна може зʼявитися за мілісекунди, або це може зайняти секунди чи навіть хвилини під навантаженням. Наразі оператори не мають уявлення про це відставання і не можуть відрізнити нормальну затримку від ситуації, коли контролер небезпечно втратив синхронізацію, тому контролер може продовжувати узгоджувати свої дані з уявленням про стан системи, яке вже є застарілим.

Заходи щодо мінімізації ризиків, пов’язаних із застарілими контролерами, перебувають у стадії бета-тестування з версії v1.36 і є стандартними для кожного контролера за функціональною можливісьтю StaleControllerConsistency<Controller>; у Kubernetes v1.37 ці заходи поширено на контролер HorizontalPodAutoscaler та додано варіант із механізмом відключення (circuit-breaking) і додаткові метрики, описані нижче. Основний механізм — це гарантія read your writes: ResourceEventHandlerFuncs у client-go отримує новий callback BookmarkFunc, щоб контролер міг надійно відстежувати версію ресурсу обʼєктів, які йому цікаві, навіть через крайні випадки, які наявні callbackʼи add/update/delete пропускають. Контролер записує версію ресурсу власних записів і, при наступному узгодженні, пропускає та повторно ставить у чергу, доки його інформер-кеш дійсно не наздогнав цей запис. Контролер DaemonSet — хороший приклад цього. Він відстежує версії ресурсів DaemonSet → Pod, щоб не переузгоджувати проти власного застарілого pod-кешу. Другий, circuit-breaking варіант націлений на контролери, чутливі до затримок, на кшталт node-lifecycle, які інакше могли б прочитати застарілий node lease з кешу і помилково вирішити, що він закінчився; замість цього він робить живий GET на руйнівному рішенні і позначає свій кеш як «not ready», доки він не догонить його, замість того щоб діяти на основі застарілого читання. StaleControllerConsistency контролює саму процедуру пом’якшення наслідків (спочатку застосовується до контролерів, які KCM позначив як великомасштабні), MonitorInformerStaleness — це окремий контрольний механізм, призначений лише для спостереження, який кожні 5 секунд безпосередньо опитує apiserver виключно для того, щоб виявити, наскільки насправді відстає кеш інформера, а AtomicFIFO / UnlockWhileProcessingFIFO — це базові механізми черги завдань client-go, від яких залежить робота механізму помʼякшення наслідків. Ніщо з цього не змінює стандартну поведінку узгоджувача; контролер, який було призупинено та знову поставлено в чергу, може здаватися застряглим, хоча насправді він просто чекає на свій кеш, і він коректно відкочується, оскільки жодна його дія не є незворотною.

Ця робота була виконана як частина KEP #5647 під керівництвом SIG API Machinery.

Конфігурація контролю допуску на основі маніфесту

У Kubernetes контроль допуску відповідає за забезпечення дотримання політик щодо ресурсів до того, як вони будуть прийняті сервером API. Однак вебхуки та політики допуску, налаштовані через API Kubernetes, під час запуску кластера залежать від сервера API та etcd і не можуть захистити самі ресурси конфігурації допуску. Це створює вразливість під час початкового запуску кластера та дозволяє користувачам із достатніми привілеями змінювати або видаляти критично важливі політики допуску.

У Kubernetes v1.37 конфігурація контролю доступу на основі маніфестів перейшла у стадію бета-тестування, що дозволяє завантажувати вебхуки доступу та політики на основі CEL із файлів маніфестів на диску та застосовувати їх із моменту запуску сервера API. Оскільки ця конфігурація управляється незалежно від API Kubernetes, вона також може захищати ресурси контролю доступу на основі API від модифікацій. Файли маніфестів відстежуються на наявність змін, і дійсні оновлення перезавантажуються автоматично, тоді як недійсні оновлення залишають попередньо завантажену конфігурацію без змін.

Ця робота була виконана як частина KEP #5793 під керівництвом SIG API Machinery

Покращена обробка нерозшифровуваних ресурсів

Kubernetes зберігає ресурси в etcd, де шифрування в стані спокою може бути використане для захисту чутливих даних. Однак, коли зашифровані ресурси більше не можуть бути розшифровані, наприклад, тому що ключ шифрування недоступний, API-сервер не може читати або керувати цими ресурсами нормально. Це може залишити ресурси в кластері, до яких неможливо отримати доступ через Kubernetes API, вимагаючи від адміністраторів вручну модифікувати базові дані etcd для відновлення.

Kubernetes v1.37 включає Beta підтримку для адміністраторів кластерів для ідентифікації та видалення ресурсів, які не можуть бути розшифровані API-сервером.

Раніше Alpha, і введена в Kubernetes v1.32, ця підтримка дозволяє видаляти проблемні API-ресурси через Kubernetes API замість безпосереднього маніпулювання файлом etcd. Ця функція також надає засоби безпеки для адміністраторів для перевірки задіяних ресурсів перед видаленням.

Ця робота була виконана як частина KEP #3926 під керівництвом SIG Auth.

Нові функції в Alpha

Нова стратегія Recreate для розгортання StatefulSet

Kubernetes v1.37 вводить стратегію Recreate для розгортання StatefulSet. StatefulSet API раніше пропонував лише дві стратегії оновлення: OnDelete (ручна) та RollingUpdate (автоматична, типово). Схоже на Deployments, стратегія оновлення Recreate видаляє всі Podʼи StatefulSet перед створенням нових Podʼів, що відображають модифікації, зроблені до .spec.template StatefulSet. Використання цієї стратегії вимагає увімкнення функціональної можливості StatefulSetRecreateStrategy.

Ця робота була виконана як частина KEP #3541 під керівництвом SIG Apps.

DRA: Alpha функції, на які варто звернути увагу

DRA: Запит на ресурси, що розподіляються вузлом

Kubernetes v1.37 покращує Alpha підтримку керування ресурсами вузла, такими як CPU, памʼять та huge pages, через DRA. Це обʼєднує стандартний та DRA облік ресурсів, допомагаючи запобігти подвійному рахуванню однієї й тієї ж можливості вузла.

Це оновлення вводить окремі API-поля для mapping (для пристроїв, що безпосередньо моделюють основні ресурси, на кшталт CPU/памʼяті DRA драйверів) та overhead (як допоміжна хост-памʼять для пристроїв прискорення). Kubelet тепер примушує ці виділення між pod та container cgroups, інтегрує їх з Memory QoS, розрахунками OOM score та in-place зміною розміру podʼа.

Ця робота була виконана як частина KEP #5517, під керівництвом SIG Scheduling з участю SIG Node.

DRA: Похідні атрибути

Kubernetes v1.37 вводить Alpha підтримку похідних атрибутів у DRA. Навантаження можуть використовувати CEL-вирази для створення віртуальних атрибутів з інформації про пристрої та використання їх при виборі повʼязаних пристроїв.

Це полегшує ко-локацію пристроїв, таких як GPU та мережеві інтерфейси, навіть коли їх драйвери використовують різні імена атрибутів або формати. Наприклад, навантаження може вивести спільний NUMA ідентифікатор і використати його для вибору пристроїв з відповідною топологією.

Ця робота була виконана як частина KEP #6080, під керівництвом SIG Scheduling з участю SIG Network.

DRA: Групи сумісності пристроїв

DRA можна використовувати для управління пристроями, що підтримують різні схеми розділення або віртуалізації. Однак деякі з цих конфігурацій не можна використовувати одночасно на одному фізичному пристрої, наприклад MIG і vGPU на графічному процесорі. Раніше ці несумісності можна було виявити лише під час підготовки пристрою, після того як планувальник уже прийняв своє рішення.

У Kubernetes v1.37 DRA додає групи сумісності пристроїв, дозволяючи драйверам ресурсів описувати, які пристрої можуть бути виділені разом. Планувальник може використовувати цю інформацію при прийнятті рішень про виділення, запобігаючи призначенню некомплектних пристроїв разом і уникаючи помилок запуску Podʼів, спричинених некомплектними конфігураціями пристроїв.

Ця робота була виконана як частина KEP #5963, під керівництвом SIG Scheduling.

Витіснення планувальником для in-place зміни розміру Podʼа

Kubernetes v1.37 вводить витіснення планувальником для in-place зміни розміру podʼа, за (opt-in, Alpha) функціональною можливістю InPlacePodVerticalScalingSchedulerPreemption. Ця зміна вирішує важливу прогалину функціоналу, що залишилася після того, як основна функція вертикального масштабування Podʼа на місці перейшла в Stable: якщо запущений pod запитував додаткові ресурси, що перевищували доступну ємність вузла, kubelet позначав запит як Deferred, залишаючи pod очікувати, поки достатньо ресурсів не стане доступними на вузлі. Завдяки цьому вдосконаленню панель управління Kubernetes може активно звільняти ємність на повністю завантаженому вузлі та витісняти навантаження з нижчим пріоритетом, дозволяючи відкладеним in-place запитам на зміну розміру критичних застосунків з вищим пріоритетом успішно завершитися.

Ця робота була виконана як частина KEP #5836 під керівництвом SIG Scheduling.

Динамічна зміна розміру memory-backed томів

Також спираючись на вертикальне масштабування Podʼів «на місці», функція Alpha масштабування на місці для томів, що підтримуються памʼяттю розширює субресурс pod /resize, який раніше дозволяв лише динамічне регулювання CPU та памʼяті без перезапуску контейнерів, щоб підтримати оновлення параметра sizeLimit томів emptyDir, що підтримуються памʼяттю (medium: Memory), у запущених Podʼах. Коли параметр sizeLimit тома явно регулюється за допомогою субресурсу /resize, Kubelet динамічно оновлює базове монтування tmpfs без переривання роботи контейнера, одночасно надійно запобігаючи помилкам нестачі памʼяті або помилковим спрацьовуванням механізмів витіснення. Це особливо корисно для робочих навантажень із збереженням стану та з інтенсивним використанням памʼяті, які покладаються на тимчасове зберігання даних у памʼяті, що дозволяє їм динамічно масштабувати межі зберігання разом із об’ємом пам’яті контейнера без перезапуску подів або простоїв застосунків.

Це альфа-функція, яка вмикається за бажанням користувача і зазвичай вимкнена. Щоб спробувати її, увімкніть функціональну можливість InPlacePodVerticalScalingMemoryBackedVolumes.

Ця робота була виконана як частина KEP #6030 під керівництвом SIG Node та SIG Storage.

Спеціалізоване управління життєвим циклом вузлів

Декілька компонентів Kubernetes потребують інформації про стан життєвого циклу вузла, і на сьогодні кожен із них визначає його на основі різного поєднання готовності вузла, позначок taint, стану Pod, міток, анотацій та API-інтерфейсів провайдерів. Це вдосконалення запроваджує загальновизнані умови життєвого циклу для вузлів, надаючи адміністраторам єдине місце в Kubernetes для публікації стану життєвого циклу, яке можуть використовувати основні контролери та інструменти екосистеми. Ці нові умови вузлів (Node Conditions) такі: DrainInProgress, Drained, MaintenancePlanned, MaintenanceInProgress та GracefulNodeShutdownInProgress

Ця робота була виконана як частина KEP #5683 під керівництвом SIG Node.

WAS: Alpha функції, на які варто звернути увагу

CompositePodGroup API

Попередні випуски вводили підтримку групового планування навантажень з плоскою структурою, сучасні AI/ML навантаження є складними і мають більш витончені вимоги до планування. У Kubernetes v1.37 новий Alpha CompositePodGroup API дозволяє Kubernetes описувати складні навантаження як ієрархію груп замість плаского набору Podʼів. Це дозволяє багаторівневе групове планування, workload-aware preemption та topology-aware планування.

Ця робота була виконана як частина KEP #6012 під керівництвом SIG Scheduling.

API контролера планування з урахуванням навантаження

Як Alpha функція, в Kubernetes v1.37 надається спільний фреймворк для інтеграції контролерів навантажень (таких як JobSet, TrainJob, LWS, та RayJob, поряд з основними навантаженнями, такими як Job) з Workload-aware Scheduling (WAS). Які функція альфа-версії, Kubernetes v1.37 надає загальну платформу для інтеграції контролерів робочих навантажень (таких як JobSet, TrainJob, LWS та RayJob, а також основних робочих навантажень, таких як Job) із плануванням з урахуванням робочих навантажень (WAS).

Ця робота була виконана як частина KEP #6089 під керівництвом SIG Scheduling.

Інтеграція Workload API з Job контролером

Спочатку введена в Kubernetes v1.36 з обмеженим функціоналом, ця функція будує на Workload Aware Scheduling Controller APIs, додаючи нове поле spec.scheduling для користувача до batch/v1 Job у Kubernetes v1.37, дозволяючи користувачам явно конфігурувати політики планування, обмеження топології, режими розладів (disruption modes) та resource claims. Якщо spec.scheduling виключено, Job типово використовує Basic планування, зберігаючи наявну поведінку, при цьому створюючи Basic Workload/PodGroup для workload-aware планування, без використання minCount gate. Користувачі можуть явно використовувати (opt in) Gang планування, де minCount типово дорівнює паралелізму Jobʼа, а контролер використовує спільну бібліотеку workloadbuilder для перекладу конфігурації планування у відповідні обʼєкти Workload та PodGroup замість реалізації власної логіки перекладу.

Ця робота була виконана як частина KEP #5547 під керівництвом SIG Scheduling.

Проксі користувацького простору (userspace) для localhost NodePort для nftables

Kubernetes v1.37 додає opt-in userspace проксі до nftables бекенду kube-proxy, дозволяючи NodePort сервісам бути доступними через localhost поверх IPv4 та IPv6. Це закриває прогалину між nftables та iptables бекендами, оскільки nftables раніше не міг обслуговувати localhost NodePortʼи.

Проксі увімкнено, коли localhost або loopback-адреса включена в конфігурацію --nodeport-addresses kube-proxy. Це може бути корисним для навантажень, таких як локальні контейнерні реєстрі, що покладаються на зʼєднання localhost:<NodePort>. Наявна поведінка iptables та ipvs бекендів незмінна.

Ця робота була виконана як частина KEP #6032 під керівництвом SIG Network.

Інші значущі зміни

maxUnavailable для StatefulSets знову стандартно увімкнено

Поле maxUnavailable для StatefulSets було знову стандартно увімкнено у Kubernetes v1.37 (після того, як баг був виявлений у v1.36).

Баг виникав, коли несправна початкова ревізія StatefulSet створювала Pod, який ніколи не ставав ready, і з увімкненим MaxUnavailableStatefulSet, контролер StatefulSet не міг оновити той Pod до новій, виправленій ревізії. Коли баг спрацьовував, зазначений Pod міг застрягти в стані CrashLoopBackOff безкінечно (див. kubernetes#137409).

Покращена продуктивність nftables

kube-proxy тепер використовує kernel netlink інтерфейс для операцій з правилами nftables, обходячи утиліту командного рядка nft. Це робить kube-proxy ефективнішим при перевірці та управлінні правилами nftables, покращуючи продуктивність управління правилами.

Обробка контексту та контекстне логування в client-go

Підтримка розповсюдження контексту та контекстного логування в client-go завершена, за винятком невеликої кількості викликів логування втулків автентифікації, які все ще покладаються на глобальний klog логер, бо базові API не підтримують передачу контексту.

Зміна статусу, застарілі та видалені функції у v1.37

Переходи в Stable

Цей розділ перераховує всі функції, що перейшли в Stable (також відомі як загальна доступність). Для повного списку оновлень, включаючи нові функції та переходи з Alpha в Beta, дивіться примітки до випуску.

Цей випуск включає загалом 16 вдосконалень, переведених у Stable:

Застарілі функції, видалення та оновлення від спільноти

У міру розвитку та вдосконалення Kubernetes окремі функції можуть бути визнані застарілими, видалені або замінені кращими з метою забезпечення загального стабільного функціонування проєкту. Деталі цього процесу дивіться в політиці застарівання та видалення Kubernetes. Багато з цих застарівань та видалень були оголошені в блозі про застарівання та видалення.

Застарівання kube-dns

CoreDNS є стандартною надбудовою для кластерного DNS, починаючи з версії Kubernetes v1.113, і з того часу kube-dns не встигає за ним; такі функції, як EndpointSlices та сервіси з подвійним стеком, у ньому недоступні.

Kubernetes вже вивів kube-dns субпроєкт і виділив node-local-dns в окремий репозиторій, де він продовжує підтримуватися і працює з CoreDNS. Очікується, що нові пакети для kube-dns не будуть збиратися після v1.40.

Якщо ви все ще використовуєте kube-dns, почніть планувати міграцію ваших кластерів на CoreDNS.

Припинення підтримки режиму ipvs у kube-proxy

Підтримка режиму ipvs в kube-proxy була введена в v1.8 для вирішення вузьких місць продуктивності iptables. Однак, оскільки kernel ipvs API самостійно не може повністю реалізувати Kubernetes Services, режим ipvs продовжує використовувати iptables під капотом (KEP-3866, "The ipvs mode of kube-proxy will not save us").

Кластери, що запускають kube-proxy в режимі ipvs (або mode: ipvs в KubeProxyConfiguration), тепер логують попередження про застарівання при запуску. Графік застарівання виглядає так:

  • До v1.40, режим ipvs для kube-proxy очікується стандартно вимкненим (його все ще можна вибірково включати через функціональну можливість)
  • До v1.43, підтримка режиму ipvs буде видалена повністю KEP #5495, Graduation Criteria.

Для підтвердження того, який режим ви зараз використовуєте, виконайте:

kubectl -n kube-system get configmap kube-proxy -o jsonpath=ʼ{.data.config\.conf}ʼ | grep ʼmode:ʼ

Щоб зрозуміти обґрунтування цього застарівання, дивіться KEP #5495.

kubectl: прапорець kubectl run --filename/-f застаріває

Прапорець --filename (або -f) для kubectl run оголошується застарілим, оскільки генерований pod завжди будується виключно з CLI аргументів на кшталт NAME та --image.

Дивіться kubernetes/kubernetes#138671 для оригінального issue та обговорення.

kubelet: статичні Podʼи більше не можуть посилатися на Secrets або ConfigMaps

Статичні Podʼи ніколи не призначалися для читання API-ресурсів безпосередньо, оскільки вони не створюються через API-сервер — але баг дозволяв їм посилатися на Secrets або ConfigMaps через поля на кшталт configMapRef або secretRef. Цей баг тепер виправлений: починаючи з v1.37 ці посилання суворо заборонені, а функціональна можливість PreventStaticPodAPIReferences, що раніше дозволяв відмовитися від обмеження, був видалений.

Дивіться kubernetes/kubernetes#140226 для оригінального issue та обговорення.

Поточна велика зміна: майбутнє видалення підтримки cgroup v1

Оскільки сучасні Linux дистрибутиви та рушії виконання контейнерів стандартно використовують cgroup v2, підтримка застарілих cgroup v1 офіційно виводиться з експлуатації. З випуску v1.35 налаштування failCgroupV1 типово дорівнює true. Отже, kubelet не зможе ініціалізуватися на будь-яких вузлах, що все ще покладаються на cgroup v1, якщо не застосовано явний перевизначення конфігурації.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false # тимчасове перевизначення

Використання цього перевизначення слід розглядати як короткострокове виправлення. Розширені можливості керування ресурсами, такі як memory QoS та in-place масштабування для memory-backed томів, працюють лише на cgroups v2. Хоча перевизначення залишається доступним у Kubernetes v1.37, користувачів заохочують мігрувати на cgroups v2, оскільки підтримка cgroups v1 планується бути видаленою у майбутньому випуску.

Щоб дізнатися більше про це застарівання, зверніться до KEP #5573.

Примітки до випуску

Перегляньте повні деталі релізу Kubernetes v1.37 в наших примітках до випуску.

Доступність

Kubernetes v1.37 доступний для завантаження з сторінки завантаження Kubernetes або безпосередньо з GitHub.

Щоб розпочати роботу з Kubernetes, перегляньте ці настанови або запустіть локальні Kubernetes кластери за допомогою minikube. Ви також можете легко встановити v1.37 за допомогою kubeadm.

Команда випуску

Kubernetes можливий лише завдяки підтримці, відданості та важкій роботі своєї спільноти. Кожна команда випуску складається з відданих волонтерів спільноти, які працюють разом, щоб створити багато частин, що складають Kubernetes релізи, на які ви покладаєтеся.

Це вимагає спеціалізованих навичок людей з усіх куточків нашої спільноти, від самого коду до його документації та управління проєктом.

Ми хотіли б подякувати всій команді, що працювала над випуском за години наполегливої праці, завдяки яким випуск Kubernetes v1.37 став доступним для нашої спільноти.

До складу команди з випуску входять як новачки, які вперше беруть участь у проєкті, так і досвідчені керівники команд, які вже брали участь у кількох циклах випуску.

Особлива подяка нашому керівнику випуску, Діпешу Равату, за підтримку протягом успішного циклу випуску, за те, що він відстоював наші інтереси, дбав про те, щоб ми всі могли зробити свій внесок якнайкраще, та спонукав нас вдосконалювати процес випуску.

Швидкість проєкту

Проєкт CNCF K8s DevStats агрегує ряд цікавих даних, повʼязаних із швидкістю Kubernetes та різних субпроєктів.

Це включає все від індивідуальних внесків до кількості компаній, що роблять внесок, і є ілюстрацією глибини та широти зусиль, що йдуть на еволюцію цієї екосистеми.

У циклі релізу v1.37, що тривав 15 тижнів з 18 травня 2026 року по 26 серпня 2026 року, внески в Kubernetes досягли максимуму у 212 різних компаній та 1,754 окремих осіб.

Джерело цих даних:

Під внеском ми маємо на увазі, коли хтось виконує коміт, проводить рецензію коду, залишає коментар, створює тікет або PR, рецензує PR (включно з блогами та документацією) або коментує тікети та PR.

Якщо ви бажаєте долучитися до проєкту, перегляньте нашу сторінку «Як розпочати».

Події

Дізнайтесь про майбутні KubeCon по всьому світу:

Дізнайтесь про майбутні Kubernetes Community Days (KCDs), які відбуватимуться до кінця 2026 року:

Вересень 2026

Жовтень 2026

  • KCD UK – Edinburgh: 19–20 жовтня 2026, Единбург, Велика Британія
  • KCD Nigeria: 24 жовтня 2026, Лагос, Нігерія

Листопад 2026

  • KCD Porto: 19–20 листопада 2026, Порто, Португалія
  • KCD Hangzhou: 28 листопада 2026, Ханчжоу, Китай

Грудень 2026

Актуальну інформацію про заходи можна знайти на сторінці заходів CNCF.

Вебінар присвячений релізу

Приєднуйтесь до членів команди випуску Kubernetes v1.37 у середу, 23 вересня 2026 о 16:00 (UTC), щоб дізнатися про головні моменти цього релізу. Для отримання інформації та реєстрації відвідайте сторінку події на сайті CNCF Online Programs.

Приєднуйтесь

Найпростіший спосіб залучитися до Kubernetes — приєднатися до однієї з багатьох Special Interest Groups (SIGs), що відповідають вашим інтересам.

Якщо ви не знаєте, з чого почати, приєднуйтесь до наших щомісячних навчальних семінарів для нових учасників New Contributor Orientations, де ми розповідаємо учасникам спільноти про структуру проєкту та допоможемо вам зробити свій перший внесок у проєкт.

  • Прочитайте більше про те, як стати Kubernetes Contributor
  • Прочитайте більше про те, що відбувається з Kubernetes у нашому блозі
  • Приєднуйтесь до нас у Slack
  • Слідкуйте за нами в Bluesky для останніх оновлень
  • Слідкуйте за нами в LinkedIn
  • Слідкуйте за нами в X
  • Приєднуйтесь до обговорення спільноти в Discuss
  • Задавайте питання (або відповідайте на них) на Stack Overflow
  • Поділіться вашою Kubernetes End User Story
  • Дізнайтеся більше про Kubernetes Release Team
Востаннє змінено August 30, 2026 at 10:31 AM PST: [uk] Ukrainian translation (all-in-one) (ac41b20ac1)