Попередній огляд Kubernetes v1.36

Автор: Chad Crowell, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Utkarsh Umre | Перекладач(і): Андрій Головін |

Випуск Kubernetes v1.36 планується наприкінці квітня 2026 року. Ця версія містить зміни, які прибирають та замінюють старі функції, а також містить значну кількість покращень. Ось деякі з функцій, які нам особливо цікаві!

Зверніть увагу, що ця інформація відображає поточний стан розробки v1.36 і може змінитися до моменту випуску.

Процес видалення та застарівання API Kubernetes

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

  • Загально доступні (Generally available, GA) або стабільні версії API можуть бути позначені як застарілі, але не можуть бути видалені в межах основної версії Kubernetes.
  • Бета або попередні версії API повинні підтримуватися протягом 3 випусків після застарівання.
  • Альфа або експериментальні версії API можуть бути вилучені з будь-якого випуску без попереднього повідомлення про припинення підтримки; у випадках, коли вже існує інша реалізація тієї самої функції, цей процес може призвести до повного вилучення.

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

Одним із нещодавніх прикладів застосування цього принципу є припинення підтримки проєкту ingress-nginx, про що 24 березня 2026 року оголосила SIG-Security. У зв’язку з передачею відповідальності за проєкт іншим стурктурам, спільноті було запропоновано розглянути альтернативні контролери ingress, які відповідають сучасним найкращим практикам у сфері безпеки та обслуговування. Цей перехід відображає ту саму дисципліну управління життєвим циклом, на якій ґрунтується сам Kubernetes, забезпечуючи безперервний розвиток без різких перебоїв.

Припинення підтримки Ingress NGINX

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

Для отримання повної інформації дивіться офіційне оголошення про припинення підтримки.

Застарівання та видалення в Kubernetes v1.36

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

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

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

Для отримання додаткової інформації дивіться 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

Наступний список покращень, ймовірно, буде включено в майбутній випуск v1.36. Це не є зобовʼязанням, і вміст випуску може змінюватися.

Швидше позначення мітками 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, правильно, є відповідальністю автора Podʼа. Розробники несуть цю відповідальність, незалежно від того, чи вони пишуть Deployment, StatefulSet, DaemonSet або навіть власний ресурс, який включає шаблон Podʼа. Недбалість з цими налаштуваннями може призвести до різних проблем, коли Podʼи спільно використовують томи.

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

Зовнішнє підписання токенів ServiceAccount

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

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

Для отримання додаткової інформації дивіться KEP-740: Support external signing of service account tokens

Драйвер DRA: підтримка позначок та толерантностей для пристроїв

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

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

Для отримання додаткової інформації дивіться Заплямованість та Толерантність. Також дивіться KEP-5055: DRA: device taints and tolerations.

Підтримка DRA для розділюваних пристроїв

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

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

Для отримання додаткової інформації дивіться KEP-4815: DRA Partitionable Devices

Бажаєте дізнатися більше?

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

Випуск Kubernetes v1.36 заплановано на середу, 22 квітня 2026 року. Слідкуйте за оновленнями!

Ви також можете переглянути оголошення про зміни в нотатках до випуску для:

Долучайтеся до спільноти Kubernetes

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