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

LLMS index: [llms.txt](/llms.txt)

---

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

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

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

У цьому випуску також визначаються [застарілими та видаленим деякі функції](#deprecations-removals-and-community-updates); обовʼязково ознайомтеся з ними.

## Тема та логотип релізу {#release-theme-and-logo}



<figure class="release-logo ">
    <img src="/zh-cn/blog/2026/04/22/kubernetes-v1-36-release/k8s-v1.36.svg"
         alt="Логотип Kubernetes v1.36 Haru: шестикутний значок з назвою Haru у плавному шрифті під v1.36; гора Фудзі піднімається праворуч, її вершина освітлена червоним світлом з смугами блідого снігу, японська каліграфія 晴れに翔け нанесена на схил; білий штурвал Kubernetes плаває в блакитному небі ліворуч серед стилізованих хмар у стилі укійо-е; на передньому плані стоять два коти як парні охоронці, сіробілий кіт ліворуч і рудий кіт праворуч, кожен носить нашийник з маленьким синім штурвалом Kubernetes"/> 
</figure>

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

Логотип створено [avocadoneko / Natsuho Ide](https://x.com/avocadoneko) під впливом серії [Тридцять шість видів Фудзі](https://en.wikipedia.org/wiki/Thirty-six_Views_of_Mount_Fuji) (富嶽三十六景, _Fugaku Sanjūrokkei_) художника [Кацусіка Хокусай](https://uk.wikipedia.org/wiki/Кацусіка_Хокусай), тієї ж серії, що подарувала світу [_Велику хвилю в Канаґаві_](https://uk.wikipedia.org/wiki/Велика_хвиля_в_Канаґаві). Наш логотип v1.36 переосмислює один з найвідоміших принтів серії, [_Ніжний вітер. Ясний ранок_][(https://en.wikipedia.org/wiki/Fine_Wind,_Clear_Morning](https://uk.wikipedia.org/wiki/Ніжний_вітер._Ясний_ранок)) (凱風快晴, _Gaifū Kaisei_), також відомий як Червона Фудзі (赤富士, _Aka Fuji_): гора освітлена червоним світлом на літньому світанку, без снігу після довгого відлиги. Тридцять шість видів здавалися підходящим числом для v1.36, і нагадуванням, що навіть Хокусай не зупинився на цьому.<sup>1</sup> Над сценою знаходиться штурвал Kubernetes, розташований у небі поруч з горою.

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

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

> **晴れに翔け、未来よ明け**\
> _hare ni kake, asu yo ake_\
> "Летімо в ясне небо, майбутнє, прокидайся!"<sup>2</sup>

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

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

## Основні оновлення {#spotlight-on-key-updates}

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

### Stable: Докладне налаштування авторизації API {#stable-fine-grained-api-authorization}

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

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

​Цю роботу було виконано в рамках [KEP #2862](https://kep.k8s.io/2862), яку очолювали SIG Auth та SIG Node.

### Beta: Статус справності ресурсів {#beta-resource-health-status}

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

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

Цю роботу було виконано в рамках [KEP #4680](https://kep.k8s.io/4680), яку очолював SIG Node.

### Alpha: Функції планування з урахуванням навантаження (Workload Aware Scheduling, WAS) {#alpha-workload-aware-scheduling-was-features}

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

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

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

## Функції, що переходять у стабільний стан {#features-graduating-to-stable}

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

### Volume group snapshots

Після кількох циклів у бета-версії, підтримка VolumeGroupSnapshot досягає загальної доступності (GA) в Kubernetes v1.36. Ця функція дозволяє робити аварійно-узгоджені знімки одночасно для кількох PersistentVolumeClaims. Підтримка знімків групи томів базується на наборі [розширених API для групових знімків](https://kubernetes-csi.github.io/docs/group-snapshot-restore-feature.html#volume-group-snapshot-apis). Ці API дозволяють користувачам робити аварійно-узгоджені знімки для набору томів. Основна мета полягає в тім, щоб дозволити відновлювати цей набір знімків для нових томів та відновлювати робоче навантаження на основі аварійно-узгодженої точки відновлення.

Цю роботу було виконано в рамках [KEP #3476](https://kep.k8s.io/3476) під керівництвом SIG Storage.

### Змінювані обмеження на підключення томів {#mutable-volume-attach-limits}

У Kubernetes v1.36 функція _mutable `CSINode` allocatable_ переходить у стабільний стан. Це покращення дозволяє драйверам [Container Storage Interface (CSI)](https://kubernetes-csi.github.io/docs/introduction.html) динамічно оновлювати повідомлену максимальну кількість томів, які вузол може обробляти.

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

Цю роботу було виконано в рамках [KEP #4876](https://kep.k8s.io/4876) під керівництвом SIG Storage.

### API для зовнішнього підписування токенів ServiceAccount {#api-for-external-signing-of-service-account-tokens}

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

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

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

Ця робота була виконана в рамках [KEP #740](https://kep.k8s.io/740) під керівництвом SIG Auth.

### Функції DRA переходять у стабільний стан {#dra-features-graduating-to-stable}

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

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

Ця робота була виконана в рамках [KEP #5018](https://kep.k8s.io/5018) та [KEP #4816](https://kep.k8s.io/4816) під керівництвом SIG Auth та SIG Scheduling.

### Змінювані політики допуску {#mutating-admission-policies}

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

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

Ця робота була виконана в рамках [KEP #3962](https://kep.k8s.io/3962) під керівництвом SIG API Machinery.

### Декларативна валідація нативних типів Kubernetes за допомогою `validation-gen` {#declarative-validation-of-kubernetes-native-types-with-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](https://kep.k8s.io/5073) під керівництвом SIG API Machinery.

### Видалення залежностей від gogo protobuf для типів API Kubernetes {#remove-gogo-protobuf-dependency-for-kubernetes-api-types}

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

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

Ця робота була виконана в рамках [KEP #5589](https://kep.k8s.io/5589) під керівництвом SIG API Machinery.

### Запит журналів вузлів {#node-log-query}

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

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

Ця робота була виконана в рамках [KEP #2258](https://kep.k8s.io/2258) під керівництвом SIG Windows.

### Підтримка просторів імен користувачів у подах {#support-user-namespaces-in-pods}

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

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

Ця робота була виконана в рамках [KEP #127](https://kep.k8s.io/127) під керівництвом SIG Node.

### Підтримка PSI на основі cgroupv2 {#support-psi-based-on-cgroupv2}

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

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

Ця робота була виконана в рамках [KEP #4205](https://kep.k8s.io/4205) під керівництвом SIG Node.

### Джерело томів: OCI-артефакт та/або образ {#volumesource-oci-artifact-and-or-image}

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

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

Ця робота була виконана в рамках [KEP #4639](https://kep.k8s.io/4639) під керівництвом SIG Node.

## Нові функції у бета-версії {#new-features-in-beta}

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

### Заходи щодо запобігання застаріванню контролерів {#staleness-mitigation-for-controllers}

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

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

Ця робота була виконана в рамках [KEP #5647](https://kep.k8s.io/5647) під керівництвом SIG API Machinery.

### Покращення перевірки IP/CIDR {#ip-cidr-validation-improvements}

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

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

Ця робота була виконана в рамках [KEP #4858](https://kep.k8s.io/4858) під керівництвом SIG Network.

### Відокремлення налаштувань користувача kubectl від конфігурацій кластера {#separate-kubectl-user-preferences-from-cluster-configs}

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

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

Ця робота була виконана в рамках [KEP #3104](https://kep.k8s.io/3104) під керівництвом SIG CLI, за допомогою SIG Auth.

### Змінювані ресурси контейнера, коли Job призупинено {#mutable-container-resources-when-job-is-suspended}

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

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

Ця робота була виконана в рамках [KEP #5440](https://kep.k8s.io/5440) під керівництвом SIG Apps.

### Обмежена імперсоніфікація {#constrained-impersonation}

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

Ця робота була виконана в рамках [KEP #5284](https://kep.k8s.io/5284) під керівництвом SIG Auth.

### Функції DRA у стані бета {#dra-features-in-beta}

Фреймворк [Dynamic Resource Allocation (DRA)](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) досяг ще одного етапу зрілості в Kubernetes v1.36, оскільки кілька основних функцій переходять у бета-версію та стають стандартно увімкненими. Цей перехід виводить DRA за межі базового розподілу завдяки класифікації [розділювальних пристроїв](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#partitionable-devices) та [споживчих ємностей](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#consumable-capacity), що дозволяє більш детально ділити апаратне забезпечення, таке як GPU, тоді як [позначки taint та толерування їх пристроями](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#device-taints-and-tolerations) забезпечують використання спеціалізованих ресурсів лише відповідними робочими навантаженнями.

Тепер користувачі отримують значно надійніший та спостережуваний життєвий цикл ресурсів через [стан пристрою ResourceClaim](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#resourceclaim-device-status) та можливість забезпечити приєднання пристрою перед плануванням Pod. Інтегруючи ці функції з підтримкою [розширених ресурсів](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#extended-resource), Kubernetes надає надійну альтернативу застарілій системі втулків пристроїв, що дозволяє складним AI та HPC робочим навантаженням керувати апаратним забезпеченням з безпрецедентною точністю та операційною безпекою.

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

### Statusz для компонентів Kubernetes {#statusz-for-kubernetes-components}

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

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

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

Ця робота була виконана в рамках [KEP #4827](https://kep.k8s.io/4827) під керівництвом SIG Instrumentation.

### Flagz для компонентів Kubernetes {#flagz-for-kubernetes-components}

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

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

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

Ця робота була виконана в рамках [KEP #4828](https://kep.k8s.io/4828) під керівництвом SIG Instrumentation.

### Проксі змішаноих версіц (також відомий як _проксі сумісності для невідомої версії_) {#mixed-version-proxy}

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

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

Ця робота була виконана в рамках [KEP #4020](https://kep.k8s.io/4020) під керівництвом SIG API Machinery.

### Memory QoS with cgroups v2 {#memory-qos-with-cgroups-v2}

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

Ця робота була виконана в рамках [KEP #2570](https://kep.k8s.io/2570) під керівництвом SIG Node.

## Нові функції в Alpha {#new-features-in-alpha}

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

### Масштабування HPA до нуля для власних метрик {#hpa-scale-to-zero-for-custom-metrics}

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

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

Ця робота була виконана в рамках [KEP #2021](https://kep.k8s.io/2021) під керівництвом SIG Autoscaling.

### Функції DRA в альфа {#dra-features-in-alpha}

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

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

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

### Нативна підтримка гістограм для метрик Kubernetes {#native-histogram-support-for-kubernetes-metrics}

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

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

Ця робота була виконана в рамках [KEP #5808](https://kep.k8s.io/5808) під керівництвом SIG Instrumentation.

### Конфігурація контролю допуску на основі маніфестів {#manifest-based-admission-control-config}

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

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

Ця робота була виконана в рамках [KEP #5793](https://kep.k8s.io/5793) під керівництвом SIG API Machinery.

### Потокова передача списку CRI {#cri-list-streaming}

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

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

Ця робота була виконана в рамках [KEP #5825](https://kep.k8s.io/5825) під керівництвом SIG Node.

## Інші значущі зміни {#other-notable-changes}

### Виведення з експлуатації Ingress NGINX {#ingress-nginx-retirement}

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

За повними деталями звертайтесь до [офіційного повідомлення про виведення Ingress NGINX з експлуатації](/blog/2025/11/11/ingress-nginx-retirement/).

### Швидше позначення мітками SELinux для томів (GA) {#volume-selinux-labelling}

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)](/blog/2026/04/22/breaking-changes-in-selinux-volume-labeling/) блог.

Для отримання додаткової інформації про це покращення звертайтесь до [KEP-1710: Speed up recursive SELinux label change](https://kep.k8s.io/1710).

## Зміна статусу, застарілі та видалені функції у v1.36 {#graduations-deprecations-and-removals-in-v1-36}

### Переходи до стабільного стану {#graduations-to-stable}

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

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

- [Підтримка користувацьких просторів імен у Podʼах](https://kep.k8s.io/127)
- [API для зовнішнього підписання токенів облікових записів сервісу](https://kep.k8s.io/740)
- [Прискорення рекурсивної зміни міток SELinux](https://kep.k8s.io/1710)
- [Міграція вбудованого файлу Portworx до драйвера CSI](https://kep.k8s.io/2589)
- [Тонке керування авторизацією API Kubelet](https://kep.k8s.io/2862)
- [Змінювані політики допуску](https://kep.k8s.io/3962)
- [Запит журналу вузла](https://kep.k8s.io/2258)
- [VolumeGroupSnapshot](https://kep.k8s.io/3476)
- [Змінювана властивість Allocatable CSINode](https://kep.k8s.io/4876)
- [DRA: Пріоритетні альтернативи в запитах на пристрої](https://kep.k8s.io/4816)
- [Підтримка PSI на основі cgroupv2](https://kep.k8s.io/4205)
- [Додавання опції ProcMount](https://kep.k8s.io/4265)
- [DRA: Розширення PodResources для включення ресурсів з Dynamic Resource Allocation](https://kep.k8s.io/3695)
- [VolumeSource: OCI Artifact та/або Image](https://kep.k8s.io/4639)
- [Розділення обізнаності про топологію кешу L3 у CPU Manager](https://kep.k8s.io/5109)
- [DRA: AdminAccess для ResourceClaims та ResourceClaimTemplates](https://kep.k8s.io/5018)
- [Видалення залежності gogo protobuf для типів API Kubernetes](https://kep.k8s.io/5589)
- [CSI драйвер opt-in для токенів облікових записів сервісу через поле secrets](https://kep.k8s.io/5538)

## Застарілі функції, видалення та оновлення від спільноти {#deprecations-removals-and-community-updates}

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

### Застарівання поля Service .spec.externalIPs {#deprecate-service-spec-externalips}

З цим випуском поле `externalIPs` у Service `spec` застаріло. Це означає, що функціональність існує, але більше не буде працювати в **майбутній** версії Kubernetes. Вам слід планувати міграцію, якщо ви наразі покладаєтеся на це поле. Це поле було відомою проблемою безпеки протягом багатьох років, дозволяючи атаки типу "людина посередині" на трафік вашого кластера, як це задокументовано в [CVE-2020-8554](https://github.com/kubernetes/kubernetes/issues/97076). Починаючи з Kubernetes v1.36, ви будете бачити попередження про застарівання при його використанні, з повним видаленням, запланованим на v1.43.

Якщо ваші Сервіси все ще покладаються на `externalIPs`, розгляньте можливість використання сервісів LoadBalancer для керованого хмарою ingress, NodePort для простого відкриття портів або [Gateway API](https://gateway-api.sigs.k8s.io/) для більш гнучкого та безпечного способу обробки зовнішнього трафіку.

Для отримання додаткової інформації про це поле та його застарівання, зверніться до [External IPs](/docs/concepts/services-networking/service/#external-ips) або прочитайте [KEP-5707: Deprecate service.spec.externalIPs](https://kep.k8s.io/5707).

### Видалення драйвера томів `gitRepo` {#remove-gitrepo-volume-driver}

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

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

Для отримання додаткової інформації про це видалення, зверніться до [KEP-5040: Remove gitRepo volume driver](https://kep.k8s.io/5040)

## Примітки до випуску {#release-notes}

Перегляньте повні деталі випуску Kubernetes v1.36 у наших [примітках до випуску](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.36.md).

## Доступність {#availability}

Kubernetes v1.36 доступний для завантаження на [GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.36.0) або на [сторінці завантаження Kubernetes](/releases/download/).

Щоб почати роботу з Kubernetes, ознайомтеся з [цими навчальними посібниками](/docs/tutorials/) або запустіть локальні кластери Kubernetes за допомогою [minikube](https://minikube.sigs.k8s.io/). Ви також можете легко [встановити v1.36 за допомогою kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).

## Команда випуску {#release-team}

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

Ми хотіли б подякувати всій [команді випуску](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.36/release-team.md) за години наполегливої праці, щоб зробити випуск Kubernetes v1.36 можливим. Склад команди випуску варіюється від новачків до досвідчених керівників команд, які мають досвід, здобутий за кілька циклів випуску. Особлива подяка нашому керівнику випуску, Ryota Sawada, за керівництво успішним циклом випуску, за його практичний підхід до вирішення проблем і за енергію та турботу, які рухають нашу спільноту вперед.

## Швидкість проєкту {#project-velocity}

Проєкт CNCF K8s [DevStats](https://k8s.devstats.cncf.io/d/11/companies-contributing-in-repository-groups?orgId=1&var-period=m&var-repogroup_name=All) обʼєднує низку цікавих даних, повʼязаних зі швидкістю розвитку Kubernetes та різних підпроєктів. Сюди входить все, від індивідуальних внесків до кількості компаній, які роблять внески, і це ілюструє глибину та широту зусиль, що докладаються для розвитку цієї екосистеми.

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

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

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

- [Companies contributing to Kubernetes](https://k8s.devstats.cncf.io/d/11/companies-contributing-in-repository-groups?orgId=1&from=1747609200000&to=1756335599000&var-period=d28&var-repogroup_name=Kubernetes&var-repo_name=kubernetes%2Fkubernetes)
- [Overall ecosystem contributions](https://k8s.devstats.cncf.io/d/11/companies-contributing-in-repository-groups?orgId=1&from=1747609200000&to=1756335599000&var-period=d28&var-repogroup_name=All&var-repo_name=kubernetes%2Fkubernetes)

## Оновлення подій {#events-update}

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

**Квітень 2026**

- KCD — [Kubernetes Community Days: Guadalajara](https://community.cncf.io/events/details/cncf-kcd-guadalajara-presents-kcd-guadalajara-2026/cohost-kcd-guadalajara/): 18 квітня 2026 | Гвадалахара, Мексика

**Травень 2026**

- KCD — [Kubernetes Community Days: Toronto](https://community.cncf.io/events/details/cncf-kcd-toronto-presents-kcd-toronto-2026/): 13 травня 2026 | Торонто, Канада
- KCD — [Kubernetes Community Days: Texas](https://community.cncf.io/events/details/cncf-kcd-texas-presents-kcd-texas-2026/cohost-kcd-texas/): 15 травня 2026 | Остін, США
- KCD — [Kubernetes Community Days: Istanbul](https://community.cncf.io/events/details/cncf-kcd-istanbul-presents-kcd-istanbul-2026/): 15 травня 2026 | Стамбул, Туреччина
- KCD — [Kubernetes Community Days: Helsinki](https://community.cncf.io/events/details/cncf-kcd-helsinki-presents-kubernetes-community-days-helsinki-2026/): 20 травня 2026 | Гельсінкі, Фінляндія
- KCD — [Kubernetes Community Days: Czech & Slovak](https://community.cncf.io/events/details/cncf-kcd-czech-slovak-presents-kcd-czech-amp-slovak-prague-2026/): 21 травня 2026 | Прага, Чехія

**Червень 2026**

- KCD — [Kubernetes Community Days: New York](https://community.cncf.io/events/details/cncf-kcd-new-york-presents-kcd-new-york-2026/): 10 червня 2026 | Нью-Йорк, США
- KCD - [Kubernetes Community Days: Kuala Lumpur](https://community2.cncf.io/events/details/cncf-kcd-kuala-lumpur-2026-presents-kcd-kuala-lumpur-2026/): 27 червня 2026 | Куала-Лумпур, Малайзія
- [KubeCon + CloudNativeCon India 2026: 18-19 червня 2026](https://events.linuxfoundation.org/kubecon-cloudnativecon-india/) | Мумбаї, Індія

**Липень 2026**

- [KubeCon + CloudNativeCon Japan 2026: 29-30 липня 2026](https://events.linuxfoundation.org/kubecon-cloudnativecon-japan/) | Йокогама, Японія

**Вересень 2026**

- KCD - [Kubernetes Community Days: San Francisco Bay Area](https://community2.cncf.io/events/details/cncf-kcd-sf-bay-area-presents-kcd-san-francisco-bay-area-2026/): 1 вересня 2026 | Маунтін-Вʼю, США
- [KubeCon + CloudNativeCon China 2026: 8-9 вересня 2026](https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/) | Шанхай, Китай

**Жовтень 2026**

- KCD — [Kubernetes Community Days: UK: 19 жовтня 2026](https://community.cncf.io/events/details/cncf-kcd-uk-presents-kubernetes-community-days-uk-edinburgh-2026/) | Едінбург, Великобританія

**Листопад 2026**

- KCD — [Kubernetes Community Days: Porto](https://community.cncf.io/events/details/cncf-kcd-porto-presents-kcd-porto-2026-collab-with-devops-days-portugal/): 19 листопада 2026 | Порту, Португалія
- [KubeCon + CloudNativeCon North America 2026](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/): 9-12 листопада 2026 | Солт-Лейк-Сіті, США

Ви можете знайти останні деталі подій в розділі [події](https://community.cncf.io/events/#/list) сайту спільноти CNCF.

## Вебінар присвячений новому випуску {#upcoming-release-webinar}

Приєднуйтесь до членів команди випуску Kubernetes v1.36 у **середу, 20 травня 2026 року о 16:00 (UTC)**, щоб дізнатися про основні моменти цього релізу. Для отримання додаткової інформації та реєстрації відвідайте [сторінку події](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cloud-native-live-kubernetes-v136-release/) на сайті CNCF Online Programs.

## Приєднуйтесь {#get-involved}

Найпростіший спосіб долучитися до Kubernetes — це приєднатися до однієї з багатьох [Груп спеціальних інтересів](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIG), які відповідають вашим інтересам. Маєте щось, що хочете донести до спільноти Kubernetes? Поділіться своїми ідеями на нашій щотижневій [зустрічі спільноти](https://github.com/kubernetes/community/tree/master/communication) та через наведені нижче канали. Дякуємо за вашу постійну підтримку та відгуки.

- Слідкуйте за нами в Bluesky [@kubernetes.io](https://bsky.app/profile/kubernetes.io) для останніх оновлень
- Приєднуйтесь до обговорення спільноти на [Discuss](https://discuss.kubernetes.io/)
- Приєднуйтесь до спільноти на [Slack](https://slack.k8s.io/)
- Задавайте питання (або відповідайте на питання) на [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
- Поділіться своєю історією про Kubernetes на [формі](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
- Читайте більше про те, що відбувається з Kubernetes на [блозі](https://kubernetes.io/blog/)
- Дізнайтеся більше про [команду випуску Kubernetes](https://github.com/kubernetes/sig-release/tree/master/release-team)