Kubernetes v1.36: ハル (Хару)

Автор: Kubernetes v1.36 Release Team | Перекладач(і): Андрій Головін |

Редактори: Chad M. Crowell, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Utkarsh Umre

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

Цей випуск складається з 70 вдосконалень. З них 18 стали стабільними, 25 переходять у бета-версію, а 25 стали альфа-функціями.

У цьому випуску також визначаються застарілими та видаленим деякі функції; обовʼязково ознайомтеся з ними.

Ми відкриваємо 2026 рік з Kubernetes v1.36, випуском, який приходить, коли сезон змінюється і світло змінюється на горі. ハル (Харуu) — це звук у японській мові, який несе багато значень; серед них ми найбільше цінуємо 春 (весна), 晴れ (харе, ясне небо) та 遥か (харука, далекий, віддалений). Сезон, небо та горизонт. Ви знайдете всі три в наступному тексті.

Логотип створено avocadoneko / Natsuho Ide під впливом серії Тридцять шість видів Фудзі (富嶽三十六景, Fugaku Sanjūrokkei) художника Кацусіка Хокусай, тієї ж серії, що подарувала світу Велику хвилю в Канаґаві. Наш логотип v1.36 переосмислює один з найвідоміших принтів серії, [Ніжний вітер. Ясний ранок](https://en.wikipedia.org/wiki/Fine_Wind,_Clear_Morning) (凱風快晴, Gaifū Kaisei), також відомий як Червона Фудзі (赤富士, Aka Fuji): гора освітлена червоним світлом на літньому світанку, без снігу після довгого відлиги. Тридцять шість видів здавалися підходящим числом для v1.36, і нагадуванням, що навіть Хокусай не зупинився на цьому.1 Над сценою знаходиться штурвал Kubernetes, розташований у небі поруч з горою.

Біля підніжжя Фудзі сидять Стелла (ліворуч) та Начо (праворуч), два коти з штурвалом Kubernetes на нашийниках, які виконують роль комаїну — пари охоронців у вигляді левоподібних собак, що стережуть японські святилища. Саме пари, адже ніхто не охороняє самотужки. Стелла та Начо символізують набагато більшу групу: SIG та робочі групи, розробників та рецензентів, людей, які стоять за документацією, блогами та перекладами, команду випуску, нових учасників, які роблять свої перші кроки, та досвідчених учасників, які повертаються сезон за сезоном. Kubernetes v1.36, як завжди, підтримується багатьма руками.

На Червоній Фудзі в логотипі знаходиться напис 晴れに翔け (hare ni kake), "летімо у ясне небо". Це перша половина куплету, який був занадто довгим, щоб поміститися на горі:

晴れに翔け、未来よ明け
hare ni kake, asu yo ake
"Летімо в ясне небо, майбутнє, прокидайся!"2

Саме таке бажання ми вкладаємо в цей випуск: злетіти в ясне небо, для самого випуску, для проєкту та для всіх, хто його спільно реалізує. Світанок над Червоною Фудзі не є кінцем, а переходом: цей випуск веде нас до наступного, а той — до наступного, у напрямку горизонтів, що виходять далеко за межі будь-якого окремого погляду.

1. Ця серія була настільки популярною, що Хокусай додав ще десять принтів, довівши загальну кількість до сорока шести.
2. 未来 означає "майбутнє" у найширшому сенсі, не лише завтра, а все, що ще попереду. Зазвичай читається як mirai; тут використовується неформальне читання asu.

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

Kubernetes v1.36 містить безліч нових функцій та вдосконалень. Ось кілька оновлень, на які команда розробників хотіла б звернути вашу увагу!

Stable: Докладне налаштування авторизації API

Від імені Kubernetes SIG Auth та SIG Node, ми раді оголосити про перехід докладного налаштування авторизації API kubelet у стан загальної доступності (GA) в Kubernetes v1.36!

Функціональна можливість KubeletFineGrainedAuthz була впроваджена як необовʼязкова альфа-функція в Kubernetes v1.32, потім перейшла в бета-версію (стала стандартно увімкненою) в v1.33. Тепер ця функція стала загально доступною. Ця функція забезпечує більш точний контроль доступу з мінімальними привілеями для HTTPS API kubelet, усуваючи необхідність надавати надто широкі дозволи вузлам/проксі-серверам для типових випадків використання в сферах моніторингу та спостереження.

​Цю роботу було виконано в рамках KEP #2862, яку очолювали SIG Auth та SIG Node.

Beta: Статус справності ресурсів

До випуску v1.34, Kubernetes не мав вбудованого способу повідомляти про стан виділених для роботи пристроїв, що ускладнювало діагностику аварій Podʼів через апаратні збої. Спираючись на початковий альфа-реліз у v1.31, який зосереджувався на Device Plugins, Kubernetes v1.36 розширює цю функцію, підвищуючи поле allocatedResourcesStatus у .status для кожного Podʼа до бета-версії. Це поле забезпечує єдиний механізм звітування про стан для всього спеціалізованого апаратного забезпечення.

Користувачі тепер можуть запускати kubectl describe pod, щоб визначити, чи є цикл аварій контейнера через стан пристрою Unhealthy або Unknown, незалежно від того, чи було апаратне забезпечення надано через традиційні втулки або новий фреймворк DRA. Така покращена наочність дозволяє адміністраторам та системам автоматизованого управління швидко виявляти несправне обладнання та оптимізувати відновлення високопродуктивних робочих навантажень.

Цю роботу було виконано в рамках KEP #4680, яку очолював SIG Node.

Alpha: Функції планування з урахуванням навантаження (Workload Aware Scheduling, WAS)

Раніше планувальник Kubernetes та контролери завдань керували Podʼами як незалежними одиницями, що часто призводило до фрагментованого планування або неоптимального використання ресурсів для складних розподілених робочих навантажень. Kubernetes v1.36 представляє комплексний набір функцій Workload Aware Scheduling (WAS) в альфа-версії, нативно інтегруючи контролер завдань з оновленим Workload API та новим розділеним PodGroup API, щоб розглядати повʼязані Podʼи як єдину логічну сутність.

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

Цю роботу було виконано в рамках кількох KEP (включаючи #4671, #5547, #5832, #5732 та #5710), яку очолювали SIG Scheduling та SIG Apps.

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

В цьому розділі представлено деякі з покращень, які тепер є стабільними після випуску v1.36.

Volume group snapshots

Після кількох циклів у бета-версії, підтримка VolumeGroupSnapshot досягає загальної доступності (GA) в Kubernetes v1.36. Ця функція дозволяє робити аварійно-узгоджені знімки одночасно для кількох PersistentVolumeClaims. Підтримка знімків групи томів базується на наборі розширених API для групових знімків. Ці API дозволяють користувачам робити аварійно-узгоджені знімки для набору томів. Основна мета полягає в тім, щоб дозволити відновлювати цей набір знімків для нових томів та відновлювати робоче навантаження на основі аварійно-узгодженої точки відновлення.

Цю роботу було виконано в рамках KEP #3476 під керівництвом SIG Storage.

Змінювані обмеження на підключення томів

У Kubernetes v1.36 функція mutable CSINode allocatable переходить у стабільний стан. Це покращення дозволяє драйверам Container Storage Interface (CSI) динамічно оновлювати повідомлену максимальну кількість томів, які вузол може обробляти.

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

Цю роботу було виконано в рамках KEP #4876 під керівництвом SIG Storage.

API для зовнішнього підписування токенів ServiceAccount

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

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

З випуском GA у версії 1.36 підписання токенів зовнішнім ServiceAccount тепер є повністю підтримуваною опцією для платформ, що централізують ідентифікацію та підписання, спрощуючи інтеграцію із зовнішніми системами IAM та зменшуючи необхідність керувати ключами підписання безпосередньо всередині панелі управління.

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

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

Частина системи Dynamic Resource Allocation (DRA) досягає повної промислової зрілості в Kubernetes v1.36, оскільки ключові функції управління та вибору переходять у стабільний стан. Перехід DRA admin access до GA забезпечує постійний, безпечний каркас для адміністраторів кластера для доступу та управління апаратними ресурсами на глобальному рівні, тоді як стабілізація prioritized lists гарантує, що логіка вибору ресурсів залишається послідовною та передбачуваною у всіх середовищах кластера.

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

Ця робота була виконана в рамках KEP #5018 та KEP #4816 під керівництвом SIG Auth та SIG Scheduling.

Змінювані політики допуску

Декларативне керування кластерами досягає нового рівня складності в Kubernetes v1.36 з переходом MutatingAdmissionPolicies у стабільний стан. Ця подія забезпечує нативну, високопродуктивну альтернативу традиційним вебхукам, дозволяючи адміністраторам визначати зміни ресурсів безпосередньо в API-сервері за допомогою Common Expression Language (CEL), повністю замінюючи потребу в зовнішній інфраструктурі для багатьох поширених випадків використання.

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

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

Декларативна валідація нативних типів Kubernetes за допомогою validation-gen

Розробка власних ресурсів досягає нового рівня ефективності в Kubernetes v1.36, оскільки декларативна валідація (з validation-gen) переходить у стабільний стан. Ця подія замінює ручне та часто схильне до помилок завдання написання складних схем OpenAPI, дозволяючи розробникам визначати складну логіку валідації безпосередньо в тегах структур Go за допомогою Common Expression Language (CEL).

Замість написання власних функцій валідації, учасники Kubernetes тепер можуть визначати правила валідації за допомогою коментарів маркерів IDL (таких як +k8s:minimum або +k8s:enum) безпосередньо в визначеннях типів API (types.go). Інструмент validation-gen аналізує ці коментарі для автоматичної генерації надійного коду валідації API під час компіляції. Це зменшує витрати на обслуговування та забезпечує, що валідація API залишається послідовною та синхронізованою з вихідним кодом.

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

Видалення залежностей від gogo protobuf для типів API Kubernetes

Безпека та довгострокова підтримуваність кодової бази Kubernetes роблять великий крок уперед у Kubernetes v1.36 з завершенням видалення gogoprotobuf. Ця ініціатива усунула значну залежність від непідтримуваної бібліотеки gogoprotobuf, яка стала джерелом потенційних вразливостей безпеки та блокером для впровадження сучасних функцій мови Go.

Замість переходу на стандартне генерування Protobuf, що представляло ризики сумісності для типів API Kubernetes, проєкт вирішив інтегрувати необхідну логіку генерації всередині k8s.io/code-generator. Цей підхід успішно усуває непідтримувані залежності часу виконання з графа залежностей Kubernetes, зберігаючи при цьому поточну поведінку API та сумісність серіалізації. Для споживачів типів Go API Kubernetes ця зміна зменшує технічний борг і запобігає випадковому неправильному використанню зі стандартними бібліотеками protobuf.

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

Запит журналів вузлів

Раніше Kubernetes вимагав від адміністраторів кластера входу на вузли через SSH або реалізації клієнтського читача для відстеження проблем, що стосуються панелі управління або робочих вузлів. Хоча деякі проблеми все ще потребують прямого доступу до вузлів, проблеми з kube-proxy або kubelet можна діагностувати, переглядаючи їх журнали. Журнали вузлів надають адміністраторам кластера метод перегляду цих журналів за допомогою API kubelet та втулка kubectl, спрощуючи відстеження проблем без входу на вузли, подібно до відстеження проблем, повʼязаних з подом або контейнером. Цей метод є незалежним від операційної системи і вимагає, щоб сервіси або вузли записували журнали в /var/log.

З переходом цієї функції до GA в Kubernetes 1.36 після ретельної перевірки продуктивності на робочих навантаженнях, вона є стандартно увімкненою в kubelet через функціональну можливість NodeLogQuery. Крім того, також потрібно увімкнути параметр конфігурації kubelet enableSystemLogQuery.

Ця робота була виконана в рамках KEP #2258 під керівництвом SIG Windows.

Підтримка просторів імен користувачів у подах

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

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

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

Підтримка PSI на основі cgroupv2

Управління ресурсами вузлів та їх спостережуваність стають більш точними в Kubernetes v1.36, оскільки експорт метрик Pressure Stall Information (PSI) переходить у стабільну версію. Ця функція надає kubelet можливість повідомляти про "тиск" на CPU, памʼять та I/O, пропонуючи більш детальний погляд на конфлікти ресурсів, ніж традиційні метрики використання.

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

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

Джерело томів: OCI-артефакт та/або образ

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

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

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

Нові функції у бета-версії

Цей розділ містить вибірку деяких покращень, які тепер доступні у бета-версії після випуску v1.36.

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

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

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

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

Покращення перевірки IP/CIDR

У Kubernetes v1.36 функція StrictIPCIDRValidation для полів API IP та CIDR переходить у бета-версію, посилюючи перевірку для виявлення некоректних адрес і префіксів, які раніше могли проходити непоміченими. Це допомагає запобігти непомітних помилок конфігурації, коли Services, Pods, NetworkPolicies або інші ресурси посилаються на недійсні IP-адреси, що в іншому випадку могло б призвести до заплутаної поведінки під час виконання або проблем з безпекою.

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

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

Відокремлення налаштувань користувача kubectl від конфігурацій кластера

Функція .kuberc для налаштування параметрів користувача kubectl продовжує бути в бета-версії та є стандартно увімкнененою. Файл ~/.kube/kuberc дозволяє користувачам зберігати псевдоніми, стандартні прапорці та інші особисті налаштування окремо від файлів kubeconfig, які містять точки доступу кластера та облікові дані. Це відокремлення запобігає впливу особистих налаштувань на CI-конвеєри або спільні файли kubeconfig, забезпечуючи при цьому послідовний досвід роботи з kubectl у різних кластерах і контекстах.

У Kubernetes v1.36 .kuberc було розширено можливістю визначати політики для втулків облікових даних (allowlists або denylists) для забезпечення безпечнішої автентифікації. Користувачі можуть вимкнути цю функціональність, якщо потрібно, встановивши змінні середовища KUBECTL_KUBERC=false або KUBERC=off.

Ця робота була виконана в рамках KEP #3104 під керівництвом SIG CLI, за допомогою SIG Auth.

Змінювані ресурси контейнера, коли Job призупинено

У Kubernetes v1.36 функція MutablePodResourcesForSuspendedJobs переходить у бета-версію та є стандартно увімкненою. Це оновлення послаблює валідацію Job, дозволяючи оновлювати запити та обмеження ресурсів контейнера, таких як CPU, памʼять, GPU та розширені ресурси, поки Job призупинено.

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

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

Обмежена імперсоніфікація

У Kubernetes v1.36 функція ConstrainedImpersonation для імперсоніфікації користувачів переходить у бета-версію, перетворюючи історичний механізм все-або-нічого на щось, що дійсно може дотримуватися принципів найменших привілеїв. Коли ця функція увімкнена, імперсонатор повинен мати два окремі набори дозволів: один для імперсоніфікації певної особи, а інший для виконання конкретних дій від імені цієї особи. Це запобігає використанню інструментами підтримки, контролерами або агентами вузлів імперсоніфікації для отримання ширшого доступу, ніж їм дозволено, навіть якщо їхні правила RBAC для імперсоніфікації налаштовані неправильно. Наявні правила імперсоніфікації продовжують працювати, але сервер API віддає перевагу новим обмеженим перевіркам, роблячи перехід поступовим, а не одномоментним. З бета-версією в v1.36, ConstrainedImpersonation протестована, задокументована і готова до ширшого використання командами платформ, які покладаються на імперсоніфікацію для налагодження, проксирування або контролерів на рівні вузлів.

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

Функції DRA у стані бета

Фреймворк Dynamic Resource Allocation (DRA) досяг ще одного етапу зрілості в Kubernetes v1.36, оскільки кілька основних функцій переходять у бета-версію та стають стандартно увімкненими. Цей перехід виводить DRA за межі базового розподілу завдяки класифікації розділювальних пристроїв та споживчих ємностей, що дозволяє більш детально ділити апаратне забезпечення, таке як GPU, тоді як позначки taint та толерування їх пристроями забезпечують використання спеціалізованих ресурсів лише відповідними робочими навантаженнями.

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

Ця робота була виконана в рамках кількох KEP (включаючи #5004, #4817, #5055, #5075, #4815 та #5007) під керівництвом SIG Scheduling та SIG Node.

Statusz для компонентів Kubernetes

У Kubernetes v1.36 функція ComponentStatusz для основних компонентів Kubernetes переходить у бета-версію, надаючи точку доступу /statusz (стандартно увімкнено), яка показує деталі збірки та версії в реальному часі для кожного компонента. Ця z-сторінка показує інформацію, таку як час запуску, час роботи, версія Go, версія бінарного файлу, версія емуляції та мінімальна сумісна версія, що дозволяє операторам та розробникам швидко бачити, що саме працює, без необхідності переглядати журнали або конфігурації.

Точка доступу стандартно пропонує текстовий вигляд зрозумілий для людей, а також версіоноване структуроване API (config.k8s.io/v1beta1) для програмного доступу у форматах JSON, YAML або CBOR через явне узгодження вмісту. Доступ надається групі system:monitoring, що забезпечує відповідність наявним захистам на кінцевих точках справності та метрик і запобігає витоку конфіденційних даних.

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

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

Flagz для компонентів Kubernetes

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

Точка доступу підтримує як текстовий вигляд, зрозумілий для людей, так і версіоноване структуроване API (спочатку config.k8s.io/v1beta1), тож ви можете або використовувати curl під час інциденту, або інтегрувати його в автоматизовані інструменти, коли будете готові. Доступ надається групі system:monitoring, а конфіденційні значення можуть бути приховані, що забезпечує відповідність існуючим практикам безпеки щодо точок доступу справності та стану.

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

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

Проксі змішаноих версіц (також відомий як проксі сумісності для невідомої версії)

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

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

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

Memory QoS with cgroups v2

Тепер Kubernetes покращує якість обслуговування (QoS) памʼяті на вузлах Linux із cgroup v2 завдяки більш інтелектуальній багаторівневій системі захисту памʼяті, яка краще узгоджує механізми керування ядра з запитами та обмеженнями подів, зменшуючи взаємні перешкоди та перевантаження для робочих навантажень, що використовують один і той самий вузол. У цій версії також вдосконалено спосіб, у який kubelet програмує параметри memory.high та memory.min, додано метрики та захисні механізми для запобігання взаємним блокуванням, а також запроваджено параметри конфігурації, що дозволяють операторам кластерів налаштовувати поведінку системи захисту памʼяті відповідно до своїх середовищ.

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

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

Цей розділ містить вибір деяких покращень, які тепер знаходяться в альфа-версії після випуску v1.36.

Масштабування HPA до нуля для власних метрик

Дотепер HorizontalPodAutoscaler (HPA) вимагав, щоб принаймні одна репліка залишалася активною, оскільки він міг розраховувати потреби в масштабуванні лише на основі показників (таких як завантаження процесора або обсяг пам’яті) від активних подів. Kubernetes v1.36 продовжує розвиток функції HPA scale to zero (стандартно вимкнено) в альфа-версії, дозволяючи робочим навантаженням масштабуватися до нуля реплік, зокрема при використанні метрик обʼєктів або зовнішніх метрик.

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

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

Функції DRA в альфа

Історично, фреймворк Dynamic Resource Allocation (DRA) не мав безшовної інтеграції з високорівневими контролерами та забезпечував обмежену видимість метаданих або доступності пристроїв. Kubernetes v1.36 представляє хвилю покращень DRA в альфа-версії, включаючи нативну підтримку ResourceClaim для робочих навантажень та нативні ресурси DRA для забезпечення гнучкості управління CPU.

Зараз користувачі можуть використовувати downward API для експонування складних атрибутів ресурсів безпосередньо в контейнери та отримувати переваги від покращеної видимості доступності ресурсів для більш передбачуваного планування. Ці оновлення, у поєднанні з підтримкою типів списків у атрибутах пристроїв, перетворюють DRA з низькорівневого примітиву на потужну систему, здатну обробляти складні мережеві та обчислювальні вимоги сучасних стеків штучного інтелекту та високопродуктивних обчислень (HPC).

Ця робота була виконана в рамках кількох KEP (включаючи #5729, #5304, #5517, #5677 та #5491) під керівництвом SIG Scheduling та SIG Node.

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

Моніторинг високої роздільної здатності досягає нового рівня в Kubernetes v1.36 з введенням нативної підтримки гістограм в альфа-версії. У той час як класичні гістограми Prometheus покладалися на статичні, заздалегідь визначені кошики, що часто вимагало компромісу між точністю даних та використанням памʼяті, це оновлення дозволяє панелі управління експортувати розріджені гістограми, які динамічно регулюють свою роздільну здатність на основі даних у реальному часі.

Тепер оператори кластерів можуть отримувати точні розподіли затримок для kube-apiserver та інших основних компонентів без додаткових витрат на ручне керування кошиками. Ця архітектурна зміна забезпечує більш надійні SLIs та SLOs, надаючи високоточні теплові мапи, які залишаються точними навіть під час найнепередбачуваніших піків навантаження.

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

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

Управління контролерами допуску рухається до більш декларативної та узгодженої моделі в Kubernetes v1.36 з введенням конфігурації manifest-based admission control в альфа-версії. Ця зміна вирішує давню проблему налаштування допуску через різні командні прапорці або окремі, складні файли конфігурації, дозволяючи адміністраторам визначати бажаний стан контролю допуску безпосередньо через структурований маніфест.

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

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

Потокова передача списку CRI

З введенням CRI list streaming в альфа-версії, Kubernetes v1.36 використовує нові внутрішні операції потокової передачі. Це покращення вирішує проблему тиску на памʼять та піків затримки, які часто спостерігаються на вузлах великого масштабу, замінюючи традиційні, монолітні запити List між kubelet та контейнерним середовищем на більш ефективний серверний потоковий RPC.

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

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

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

Виведення з експлуатації Ingress NGINX

Щоб забезпечити безпеку та надійність екосистеми, Kubernetes SIG Network та Комітет з реагування на безпеку вивели з експлуатації Ingress NGINX 24 березня 2026 року. З цієї дати не було випущено жодних нових версій, виправлень помилок або оновлень для усунення виявлених вразливостей безпеки. Наявні розгортання Ingress NGINX продовжуватимуть працювати, а артефакти встановлення, такі як Helm charts та образи контейнерів, залишатимуться доступними.

За повними деталями звертайтесь до офіційного повідомлення про виведення Ingress NGINX з експлуатації.

Швидше позначення мітками SELinux для томів (GA)

Kubernetes v1.36 робить покращення монтування томів SELinux загальнодоступним. Ця зміна замінила рекурсивне переназначення міток файлів на опцію mount -o context=XYZ, застосовуючи правильну мітку SELinux до всього тому під час монтування. Це забезпечує більш стабільну продуктивність і зменшує затримки запуску Podʼів на системах з увімкненим SELinux.

Ця функція була впроваджена як бета у v1.28 для томів ReadWriteOncePod. У v1.32 вона отримала метрики та опцію відмови (securityContext.seLinuxChangePolicy: Recursive) для допомоги у виявленні конфліктів. Тепер у v1.36 вона досягає стабільного стану і стандартно застосовується до всіх томів, з можливістю вибору для Podʼів або CSIDrivers через spec.seLinuxMount.

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

Розробники несуть відповідальність за налаштування поля seLinuxChangePolicy та міток томів SELinux на Podʼах. Незалежно від того, чи вони створюють Deployment, StatefulSet, DaemonSet або навіть власний ресурс, що включає шаблон Podʼа, недбалість у цих налаштуваннях може призвести до різних проблем, таких як неправильний запуск Podʼів при спільному використанні тому.

Kubernetes v1.36 є ідеальним випуском для аудиту ваших кластерів. Щоб дізнатися більше, перегляньте SELinux Volume Label Changes goes GA (and likely implications in v1.37) блог.

Для отримання додаткової інформації про це покращення звертайтесь до KEP-1710: Speed up recursive SELinux label change.

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

Переходи до стабільного стану

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

У цьому випуску всього 18 покращень, які були переведені до стабільного стану:

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

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

Застарівання поля Service .spec.externalIPs

З цим випуском поле externalIPs у Service spec застаріло. Це означає, що функціональність існує, але більше не буде працювати в майбутній версії Kubernetes. Вам слід планувати міграцію, якщо ви наразі покладаєтеся на це поле. Це поле було відомою проблемою безпеки протягом багатьох років, дозволяючи атаки типу "людина посередині" на трафік вашого кластера, як це задокументовано в CVE-2020-8554. Починаючи з Kubernetes v1.36, ви будете бачити попередження про застарівання при його використанні, з повним видаленням, запланованим на v1.43.

Якщо ваші Сервіси все ще покладаються на externalIPs, розгляньте можливість використання сервісів LoadBalancer для керованого хмарою ingress, NodePort для простого відкриття портів або Gateway API для більш гнучкого та безпечного способу обробки зовнішнього трафіку.

Для отримання додаткової інформації про це поле та його застарівання, зверніться до External IPs або прочитайте KEP-5707: Deprecate service.spec.externalIPs.

Видалення драйвера томів gitRepo

Тип томів gitRepo був визнаний застарілим з версії v1.11. У Kubernetes v1.36 втулок томів gitRepo назавжди відключено і його не можна буде знову увімкнути. Ця зміна захищає кластери від критичної проблеми безпеки, коли використання gitRepo могло дозволити зловмиснику виконувати код від імені root на вузлі.

Хоча gitRepo був застарілим протягом багатьох років і рекомендувалися кращі альтернативи, його все ще технічно можна було використовувати в попередніх випусках. Починаючи з v1.36, цей шлях закрито назавжди, тому будь-які наявні робочі навантаження, що залежать від gitRepo, треба мігрувати на підтримувані підходи, такі як init-контейнери або зовнішні інструменти типу git-sync.

Для отримання додаткової інформації про це видалення, зверніться до KEP-5040: Remove gitRepo volume driver

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

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

Доступність

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

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

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

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

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

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

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

Під час циклу випуску v1.36, який тривав 15 тижнів з 12 січня 2026 року по 22 квітня 2026 року, Kubernetes отримав внески від 106 різних компаній та 491 окремого учасника. У ширшій екосистемі хмарних технологій ця цифра зростає до 370 компаній, враховуючи 2235 загальних учасників.

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

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

Оновлення подій

Дізнайтеся про майбутні події, присвячені Kubernetes та хмарним технологіям, зокрема KubeCon + CloudNativeCon, KCD та інші важливі конференції по всьому світу. Будьте в курсі подій та долучайтеся до спільноти Kubernetes!

Квітень 2026

Травень 2026

Червень 2026

Липень 2026

Вересень 2026

Жовтень 2026

Листопад 2026

Ви можете знайти останні деталі подій в розділі події сайту спільноти CNCF.

Вебінар присвячений новому випуску

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

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

Найпростіший спосіб долучитися до Kubernetes — це приєднатися до однієї з багатьох Груп спеціальних інтересів (SIG), які відповідають вашим інтересам. Маєте щось, що хочете донести до спільноти Kubernetes? Поділіться своїми ідеями на нашій щотижневій зустрічі спільноти та через наведені нижче канали. Дякуємо за вашу постійну підтримку та відгуки.

  • Слідкуйте за нами в Bluesky @kubernetes.io для останніх оновлень
  • Приєднуйтесь до обговорення спільноти на Discuss
  • Приєднуйтесь до спільноти на Slack
  • Задавайте питання (або відповідайте на питання) на Stack Overflow
  • Поділіться своєю історією про Kubernetes на формі
  • Читайте більше про те, що відбувається з Kubernetes на блозі
  • Дізнайтеся більше про команду випуску Kubernetes