Попередній огляд 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 до ваших Service. Це поле вже багато років є відомою проблемою безпеки, оскільки дає змогу здійснювати атаки типу «людина посередині» на трафік вашого кластера, як задокументовано в CVE-2020-8554. Починаючи з Kubernetes v1.36, ви будете бачити попередження про застарівання під час його використання, а повне вилучення заплановано на v1.43.

Якщо ваші Service все ще використовують 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, повинні перейти на підтримувані підходи, такі як контейнери ініціалізації або зовнішні інструменти на кшталт 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ʼи або CSIDriver можуть увімкнути її через 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 taints та tolerations для пристроїв

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

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

Щоб дізнатися про taints та tolerations, дивіться Taints та tolerations.
Для отримання додаткової інформації про це покращення дивіться KEP-5055: DRA: device taints and tolerations.

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

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

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

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

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

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

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

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

Долучайтеся

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

  • Слідкуйте за нами в Bluesky @kubernetes.io для останніх оновлень
  • Приєднуйтесь до обговорень спільноти на Discuss
  • Приєднуйтесь до спільноти в Slack
  • Задавайте питання (або відповідайте на питання) на Server Fault або Stack Overflow
  • Поділіться своєю історією про Kubernetes
  • Дізнайтеся більше про те, що відбувається з Kubernetes, у блозі
  • Дізнайтеся більше про Kubernetes Release Team
Змінено November 05, 2026 at 5:42 PM PST: [uk] Add blog posts: Kubernetes v1.36 sneak peek, fine-grained supplemental groups control GA (3d9dd20bfc)