Kubernetes v1.35: Timbernetes («Світове дерево»)

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

Редактори: Aakanksha Bhende, Arujjwal Negi, Chad M. Crowell, Graziano Casto, Swathi Rao

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

Цей випуск містить 60 вдосконалень, включаючи 17 стабільних, 19 бета- та 22 альфа-функції.

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

2025 рік розпочався у сяйві Octarine: The Color of Magic (v1.33) і промайнув під поривами Of Wind & Will (v1.34). Ми завершуємо цей рік, тримаючись за Світове дерево, натхненні Іггдрасілем, деревом життя, що поєднує багато світів. Як і будь-яке велике дерево, Kubernetes росте кільце за кільцем і реліз за релізом, формуючись під опікою глобальної спільноти.

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

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

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

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

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

Stable: Оновлення ресурсів Podʼів на місці

Kubernetes перевів оновлення ресурсів Podʼів на місці в статус загальної доступності (GA). Ця функція дозволяє користувачам налаштовувати ресурси CPU та памʼяті без перезапуску Podʼів або контейнерів. Раніше такі зміни вимагали повторного створення Podʼів, що могло порушити робочі процеси, особливо для застосунків із збереженням стану або пакетних застосунків. У попередніх версіях Kubernetes можна було змінювати лише налаштування ресурсів інфраструктури (запити та обмеження) для поточних Podʼів. Новий функціонал дозволяє здійснювати більш плавне вертикальне масштабування без перебоїв, підвищує ефективність, а також спрощує розробку.

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

Beta: Сертифікати Podʼів для ідентифікації та безпеки робочого навантаження

Раніше для доставки сертифікатів до Podʼів були потрібні зовнішні контролери (cert-manager, SPIFFE/SPIRE), оркестрування CRD та управління Secret, а ротація здійснювалася за допомогою sidecarʼів або init-контейнерів. Kubernetes v1.35 забезпечує вбудовану ідентифікацію робочого навантаження з автоматизованою ротацією сертифікатів, що значно спрощує використання сервісних мереж та архітектур нульової довіри.

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

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

Alpha: Функції, що декларуються вузлом перед плануванням

Коли панелі управління вмикають нові функції, але вузли відстають (дозволено політикою Kubernetes skew), планувальник може розміщувати podʼи, що потребують цих функцій, на несумісних старих вузлах. Фреймворк оголошення функцій вузлів дозволяє вузлам декларувати підтримувані ними функції Kubernetes. З увімкненою новою альфа-можливістю вузол повідомляє про функції, які він підтримує, публікуючи цю інформацію в панелі управління через нове поле .status.declaredFeatures. Потім kube-scheduler, контролери допуску та сторонні компоненти можуть використовувати ці декларації. Наприклад, ви можете застосувати обмеження планування та перевірки API, щоб гарантувати, що Podʼи працюють тільки на сумісних вузлах.

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

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

Це підбірка деяких поліпшень, які тепер є стабільними після випуску версії 1.35.

Розподіл трафіку PreferSameNode

Поле trafficDistribution для Services було оновлено, щоб забезпечити більш чіткий контроль за маршрутизацією трафіку. Було додано нову опцію PreferSameNode, яка дозволяє сервісам суворо пріоритезувати точки доступу на локальному вузлі, якщо вони доступні, а в іншому випадку переходити на віддалені точки доступу.

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

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

Механізм управління Job API

Job API тепер включає поле managedBy, яке дозволяє зовнішньому контролеру обробляти синхронізацію статусу Job. Ця функція, яка перейшла в стабільний стан у Kubernetes v1.35, в першу чергу реалізована за допомогою MultiKueue — системи диспетчеризації для декількох кластерів, в якій Job, створений в кластері управління, дзеркально відображається і виконується в робочому кластері, а оновлення статусу передаються назад. Щоб уможливити цей робочий процес, вбудований контролер Job не повинен діяти на конкретний ресурс Job, щоб контролер Kueue міг замість цього керувати оновленнями статусу.

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

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

Надійне відстеження оновлень Podʼів за допомогою .metadata.generation

Історично, в API Pod не було поля metadata.generation, яке є в інших обʼєктах Kubernetes, таких як Deployments. Через це контролери та користувачі не мали надійного способу перевірити, чи kubelet дійсно обробив останні зміни в специфікації Podʼа. Ця неоднозначність була особливо проблематичною для таких функцій, як вертикальне масштабування Podʼів на місці, де було важко точно визначити, коли було виконано запит на зміну розміру ресурсу.

У Kubernetes v1.33 було додано поля .metadata.generation для Podʼів як альфа-функція. Це поле тепер є стабільним у Pod API v1.35, що означає, що кожного разу, коли оновлюється spec Podʼа, значення .metadata.generation збільшується. В рамках цього вдосконалення Pod API також отримав поле .status.observedGeneration, яке повідомляє про покоління, яке kubelet успішно побачив і обробив. Умови Podʼів також містять власне індивідуальне поле observedGeneration, яке клієнти можуть повідомляти та/або спостерігати.

Оскільки ця функція стала стабільною у v1.35, вона доступна для всіх робочих навантажень.

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

Настроюваний ліміт NUMA-вузлів для менеджера топології

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

У Kubernetes v1.31 було введено нову опцію beta max-allowable-numa-nodes для конфігурації політики менеджера топології. У Kubernetes v1.35 ця опція є стабільною. Адміністратори кластерів, які її вмикають, можуть використовувати сервери з більш ніж 8 вузлами NUMA.

Хоча опція конфігурації є стабільною, спільнота Kubernetes усвідомлює низьку продуктивність великих хостів NUMA, і існує пропозиція щодо вдосконалення (KEP-5726), яка має на меті її покращити. Більше про це можна дізнатися, прочитавши Політики управління топологією на вузлі.

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

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

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

Експонування міток топології вузлів через Downward API

Для доступу до інформації про топологію вузлів, такої як регіон і зона, зсередини Podʼа зазвичай потрібно було надсилати запит до сервера Kubernetes API. Хоча цей підхід є функціональним, він створює складності та ризики для безпеки, оскільки вимагає широких дозволів RBAC або sidecar-контейнерів лише для отримання метаданих інфраструктури. Kubernetes v1.35 просуває можливість експонування міток топології вузлів безпосередньо через Downward API до бета-версії.

Тепер kubelet може робити інʼєкцію стандартних міток топології, таких як topology.kubernetes.io/zone та topology.kubernetes.io/region, у Pod як змінні середовища або у файли спроєцьоованих томів. Основна перевага полягає в більш безпечному та ефективному способі забезпечення топологічної обізнаності робочих навантажень. Це дозволяє застосункам природно адаптуватися до своєї зони доступності або регіону без залежності від API-сервера, посилюючи безпеку завдяки дотриманню принципу мінімальних привілеїв та спрощуючи конфігурацію кластера.

Примітка: Kubernetes тепер робить інʼєкцію доступних міток топології в кожен Pod, щоб їх можна було використовувати як вхідні дані для downward API. З оновленням до версії v1.35 більшість адміністраторів кластерів побачать кілька нових міток, доданих до кожного Podʼа; це очікується як частина дизайну.

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

Вбудована підтримка міграції версій сховища

У Kubernetes v1.35 вбудована підтримка міграції версій сховища перейшла в стадію бета-тестування і є типово увімкненою. Цей крок інтегрує логіку міграції безпосередньо в основну панелі управління Kubernetes («in-tree»), усуваючи залежність від зовнішніх інструментів.

Раніше адміністратори покладалися на ручні «цикли читання/запису», часто підключаючи kubectl get до kubectl replace—to для оновлення схем або повторного шифрування даних у стані спокою. Цей метод був неефективним і схильним до конфліктів, особливо для великих ресурсів, таких як Secrets. У цій версії вбудований контролер автоматично обробляє конфлікти оновлень і токени узгодженості, забезпечуючи безпечний, оптимізований і надійний спосіб гарантувати актуальність збережених даних з мінімальними оперативними витратами.

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

Обмеження приєднання змінюваних томів

Драйвер CSI (Container Storage Interface) — це втулок Kubernetes, який забезпечує послідовний спосіб підключення систем зберігання даних до контейнеризованих робочих навантажень. Обʼєкт CSINode записує детальну інформацію про всі драйвери CSI, встановлені на вузлі. Однак може виникнути невідповідність між заявленою та фактичною ємністю на вузлах. Коли після запуску драйвера CSI використовуються слоти томів, kube-scheduler може призначити podʼи зі збереженням стану вузлам без достатньої ємності, що в решті решт призведе до зависання в стані ContainerCreating.

Kubernetes v1.35 робить CSINode.spec.drivers[*].allocatable.count змінним, щоб доступна ємність підключення томів вузла могла оновлюватися динамічно. Це також дозволяє драйверам CSI контролювати частоту оновлення значення allocatable.count на всіх вузлах шляхом введення настроюваного інтервалу оновлення, визначеного через обʼєкт CSIDriver. Крім того, він автоматично оновлює CSINode.spec.drivers[*].allocatable.count при виявленні збою в підключенні томів через недостатню ємність. Хоча ця функція перейшла в бета-версію в v1.34 з функціональною можливістю MutableCSINodeAllocatableCount, яка є типово вимкненою, вона залишається в бета-версії для v1.35, щоб дати час для відгуків, але функціональна можливість є типово увімкненою.

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

Випадкова пакетна обробка

Історично склалося так, що планувальник Kubernetes обробляє поди послідовно з часовою складністю O(num pods × num nodes), що може призвести до надмірних обчислень для сумісних подів. Цей KEP вводить механізм випадкової пакетної обробки, який має на меті покращити продуктивність шляхом ідентифікації таких сумісних подів за допомогою Pod scheduling signature та їх пакетної обробки, що дозволяє застосовувати спільні результати фільтрування та оцінювання до всіх них.

Підпис планування подів гарантує, що два поди з однаковим підписом є «однаковими» з точки зору планування. Він враховує не тільки атрибути подів і вузлів, але й інші поди в системі та глобальні дані про розміщення подів. Це означає, що будь-який под із заданим підписом отримає однакові результати оцінки/реалістичності від будь-якого довільного набору вузлів.

Механізм обʼєднання складається з двох операцій, які можна викликати в будь-який час, коли це необхідно — create та nominate. Create призводить до створення нового набору інформації про пакет на основі результатів планування Podʼів, які мають дійсний підпис. Nominate використовує інформацію про пакет з create, щоб встановити імʼя номінованого вузла з нового Podʼа, підпис якого відповідає канонічному підпису Podʼа.

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

maxUnavailable для StatefulSets

StatefulSet запускає групу Podʼів і підтримує фіксовану ідентичність для кожного з них. Це критично важливо для робочих навантажень із збереженням стану, які вимагають стабільних мережевих ідентифікаторів або постійного зберігання. Коли .spec.updateStrategy.<type> StatefulSet встановлено на RollingUpdate, контролер StatefulSet видалить і перестворить кожен Pod у StatefulSet. Він буде діяти в тому ж порядку, що і при припиненні роботи Podʼів (від найбільшого порядкового номера до найменшого), оновлюючи кожен Pod по черзі.

У Kubernetes v1.24 до налаштувань конфігурації rollingUpdate StatefulSet додано нове поле alpha з назвою maxUnavailable. Це поле не було частиною API Kubernetes, якщо адміністратор кластера явно не вибрав його. У Kubernetes v1.35 це поле є бета-версією і є стандартно доступним. Ви можете використовувати його для визначення максимальної кількості Podʼів, які можуть бути недоступними під час оновлення. Це налаштування є найбільш ефективним у поєднанні з .spec.podManagementPolicy, встановленим на Parallel. Ви можете встановити maxUnavailable як додатне число (наприклад: 2) або відсоток від бажаної кількості Podʼів (наприклад: 10%). Якщо це поле не вказано, стандартно буде встановлено значення 1, щоб зберегти попередню поведінку оновлення лише одного пода за раз. Це вдосконалення дозволяє застосункам зі збереженням стану (які можуть терпіти відмову більше ніж одного пода) швидше завершувати оновлення.

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

Настроювана політика втулків для облікових даних у kuberc

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

У рамках випуску v1.35 kuberc отримує додаткову функціональність, яка дозволяє користувачам налаштовувати політику втулків для облікових даних. Ця зміна вводить два поля credentialPluginPolicy, яке дозволяє або забороняє всі втулки, та дозволяє вказати список дозволених втулків за допомогою credentialPluginAllowlist.

Ця робота була виконана в рамках KEP #3104 у співпраці між SIG Auth та SIG CLI.

KYAML

YAML — це формат серіалізації даних, зрозумілий для людини. У Kubernetes файли YAML використовуються для визначення та конфігурації ресурсів, таких як Pods, Services та Deployments. Однак складний YAML важко читати. Значні пробіли в YAML вимагають ретельної уваги до відступів та вкладеності, а опціональне цитування рядків може призвести до несподіваного примусового перетворення типів (див.: The Norway Bug). Хоча JSON є альтернативою, він не підтримує коментарі та має суворі вимоги до кінцевих ком та цитованих ключів.

KYAML — це безпечніший та менш неоднозначний піднабір YAML, розроблений спеціально для Kubernetes. Введена як опціональна альфа-функція у версії 1.34, ця функція перейшла у бета-версію в Kubernetes 1.35 і стала стандартно увімкненою. Її можна вимкнути, встановивши змінну середовища KUBECTL_KYAML=false.

KYAML вирішує проблеми, повʼязані як з YAML, так і з JSON. Усі файли KYAML також є дійсними файлами YAML. Це означає, що ви можете писати KYAML і передавати його як вхідні дані до будь-якої версії kubectl. Це також означає, що вам не потрібно писати в суворому KYAML, щоб вхідні дані були розібрані.

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

Настроювана толерантність для HorizontalPodAutoscalers

Horizontal Pod Autoscaler (HPA) історично покладався на фіксовану глобальну толерантність 10% для дій з масштабування. Недоліком цього жорстко заданого значення було те, що робочі навантаження, які вимагають високої чутливості, наприклад ті, що потребують масштабування при збільшенні навантаження на 5%, часто блокувалися, тоді як інші могли коливатися без необхідності.

У Kubernetes v1.35 функція настроюваної толерантності перейшла в бета-версію і є стандартно увімкненою. Це вдосконалення дозволяє користувачам визначати власне вікно толерантності для кожного ресурсу в полі HPA behavior. Встановивши конкретну толерантність (наприклад, знизивши її до 0,05 для 5%), оператори отримують точний контроль над чутливістю автомасштабування, забезпечуючи швидку реакцію критичних робочих навантажень на невеликі зміни метрик без необхідності коригування конфігурації всього кластера.

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

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

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

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

VolumeSource: артефакт OCI та/або образ

Під час створення Podʼа часто потрібно надати дані, бінарні файли або файли конфігурації для контейнерів. Це означало включення вмісту в основний образ контейнера або використання спеціального контейнера init для завантаження та розпакування файлів у emptyDir. Обидва ці підходи залишаються дійсними. У Kubernetes v1.31 додано підтримку типу томів image, що дозволяє Podʼам декларативно витягувати та розпаковувати артефакти образу контейнера OCI у том. Це дозволяє пакувати та доставляти артефакти, що містять лише дані, такі як конфігурації, бінарні файли або моделі машинного навчання, використовуючи стандартні інструменти реєстру OCI.

Завдяки цій функції ви можете повністю відокремити свої дані від образу контейнера та усунути необхідність у додаткових контейнерах ініціалізації або скриптах запуску. Тип тома image перебуває в бета-версії з v1.33 і є стандартно увімкненим у v1.35. Зверніть увагу, що для використання цієї функції потрібен сумісний рушій виконання контейнерів, такий як containerd v2.1 або пізнішої версії.

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

Примусова перевірка облікових даних kubelet для кешованих образів

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

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

У Kubernetes v1.35 ця функція перейшла в бета-версію і є стандартно увімкненою. Користувачі все ще можуть вимкнути її, встановивши для функції KubeletEnsureSecretPulledImages значення false. Крім того, прапорець imagePullCredentialsVerificationPolicy дозволяє операторам налаштувати бажаний рівень безпеки, від режиму, що надає пріоритет зворотній сумісності, до режиму суворого виконання, що забезпечує максимальну безпеку.

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

Деталізовані правила перезапуску контейнерів

Історично поле restartPolicy визначалося суворо на рівні Podʼа, що змушувало всі контейнери в Podʼі поводитися однаково. Недоліком цього глобального налаштування була відсутність деталізації для складних робочих навантажень, таких як завдання навчання AI/ML. Вони часто вимагали restartPolicy: Never для управління завершенням завдань Podʼа, але окремі контейнери могли б скористатися перевагами перезапуску на місці для конкретних помилок, які можна повторити (наприклад, збої мережі або помилки ініціалізації GPU).

Kubernetes v1.35 вирішує цю проблему, увімкнувши restartPolicy та restartPolicyRules у самому API контейнера. Це дозволяє користувачам визначати стратегії перезапуску для окремих звичайних та ініціалізаційних контейнерів, які працюють незалежно від загальної політики Podʼа. Наприклад, контейнер тепер можна налаштувати так, щоб він автоматично перезапускався тільки в разі виходу з певним кодом помилки, що дозволяє уникнути значних витрат на перепланування всього Podʼа через тимчасові збої.

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

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

Включення драйвера CSI для токенів службових облікових записів через поле секретів

Надання токенів ServiceAccount драйверам Container Storage Interface (CSI) традиційно базувалося на їх інʼєкції у поле volume_context. Такий підхід становить значний ризик для безпеки, оскільки volume_context призначене для нечутливих даних конфігурації і часто реєструється драйверами та інструментами налагодження у вигляді звичайного тексту, що може призвести до витоку облікових даних.

Kubernetes v1.35 впроваджує механізм опції для драйверів CSI, що дозволяє отримувати токени ServiceAccount через спеціальне поле секретів у запиті NodePublishVolume. Тепер драйвери можуть увімкнути цю функцію, встановивши поле serviceAccountTokenInSecrets на значення true у своєму обʼєкті CSIDriver, даючи вказівку kubelet безпечно заповнити токен.

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

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

Стан Deployment: кількість реплік, що завершують роботу

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

Kubernetes v1.35 переводить поле terminatingReplicas у статусі Deployment у статус бета-версії. Це поле надає кількість Podʼів, для яких встановлено час видалення, але які ще не були видалені з системи. Ця функція є фундаментальним кроком у більш масштабній ініціативі щодо поліпшення способу обробки заміни Podʼів у Deployments, що закладає основу для майбутніх політик щодо створення нових Podʼів під час розгортання.

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

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

Нові функції в альфа-версії

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

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

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

Kubernetes v1.35 впроваджує вбудовану підтримку так званого «планування груп» за допомогою нового API робочого навантаження та концепції PodGroup. Ця функція реалізує стратегію планування «все або нічого», гарантуючи, що визначена група Podʼів планується тільки в тому випадку, якщо кластер має достатньо ресурсів для одночасного розміщення всієї групи.

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

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

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

Історично, дієслово impersonate в Kubernetes RBAC функціонувало за принципом «все або нічого»: як тільки користувач отримував дозвіл на наслідування цільової ідентичності, він отримував усі повʼязані з нею дозволи. Недоліком такого широкого дозволу було порушення принципу мінімальних привілеїв, що не дозволяло адміністраторам обмежувати дії або ресурси, доступні для імперсоніфікаторів.

Kubernetes v1.35 впроваджує нову альфа-функцію, обмежене наслідування, яка додає вторинну перевірку авторизації до процесу наслідування. Коли ця функція вмикається через функціональну можливість ConstrainedImpersonation, API-сервер перевіряє не тільки базовий дозвіл impersonate, але й перевіряє, чи уповноважений імітатор на конкретну дію, використовуючи нові префікси дієслів (наприклад, impersonate-on:<mode>:<verb>). Це дозволяє адміністраторам визначати детальні політики, наприклад, дозволяти інженеру технічної підтримки імітувати адміністратора кластера виключно для перегляду журналів, не надаючи повного адміністративного доступу.

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

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

Для перевірки конфігурації компонентів Kubernetes, таких як API-сервер або kubelet, традиційно був необхідний привілейований доступ до вузла хоста або аргументів процесу. Щоб вирішити цю проблему, було введено кінцеву точку доступу /flagz для експонування опцій командного рядка через HTTP. Однак спочатку її вивід був обмежений простим текстом, що ускладнювало автоматизованим інструментам надійний аналіз і перевірку конфігурацій.

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

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

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

Для відладки компонентів Kubernetes, таких як kube-apiserver або kubelet, традиційно використовувався аналіз неструктурованих журналів або текстового виводу, що було ненадійним і важким для автоматизації. Хоча попередньо існувала базова кінцева точка /statusz, вона не мала стандартизованого, машиночитаного формату, що обмежувало її корисність для зовнішніх систем моніторингу.

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

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

CCM: узгодження контролера маршрутів на основі спостереження за допомогою інформерів

Управління мережевими маршрутами в хмарних середовищах традиційно базувалося на періодичному опитуванні API хмарного провайдера за допомогою Cloud Controller Manager (CCM) для перевірки та оновлення таблиць маршрутів. Цей підхід узгодження з фіксованим інтервалом може бути неефективним, часто генеруючи великий обсяг непотрібних викликів API та створюючи затримку між зміною стану вузла та відповідним оновленням маршруту.

Для версії Kubernetes v1.35 бібліотека cloud-controller-manager впроваджує стратегію узгодження на основі спостереження для контролера маршрутів. Замість того, щоб покладатися на таймер, контролер тепер використовує інформери для спостереження за конкретними подіями вузла, такими як додавання, видалення або відповідні оновлення полів, і запускає синхронізацію маршрутів тільки тоді, коли насправді відбувається зміна.

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

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

Розширені оператори толерантності для розміщення на основі порогових значень

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

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

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

Змінні ресурси контейнера у випадку призупинення Job

Виконання пакетних робочих навантажень часто супроводжується спробами та помилками з обмеженнями ресурсів. Наразі специфікація Job є незмінною, що означає: якщо завдання Job завершується з помилкою Out of Memory (OOM) або через недостатню кількість ресурсів CPU, користувач не може просто налаштувати ресурси; він повинен видалити завдання Job і створити нове, втрачаючи історію виконання та статус.

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

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

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

Інші важливі зміни

Подальші інновації в динамічному розподілі ресурсів (DRA)

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

Розширені запити на ресурси через DRA

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

Позначення та толерантність пристроїв

Новий ефект "None" можна використовувати для повідомлення про проблему без негайного впливу на планування або роботу подів. DeviceTaintRule тепер надає інформацію про стан поточного виселення. Ефект "None" можна використовувати для «пробного запуску» перед фактичним виселенням подів:

  • Створіть DeviceTaintRule з "effect: None".
  • Перевірте стан, щоб побачити, скільки подів буде виселено.
  • Замініть "effect: None" на "effect: NoExecute".

Пристрої, що розділяються на розділи

Пристрої, що належать до одних і тих самих пристроїв, які можна розділити, тепер можна визначати в різних ResourceSlices. Більше інформації можна знайти в офіційній документації.

Споживана ємність, умови привʼязки пристроїв

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

Семантика порівнянних версій ресурсів

У Kubernetes v1.35 змінено спосіб, у який клієнти можуть інтерпретувати версії ресурсів.

До версії v1.35 єдиним підтримуваним порівнянням, яке клієнти могли виконувати, була перевірка рівності рядків: якщо дві версії ресурсів були рівними, вони вважалися однаковими. Клієнти також могли надавати версію ресурсу серверу API і просити панель управління виконувати внутрішні порівняння, наприклад, передавати всі події з певної версії ресурсу.

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

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

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

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

Переходи до стабільної версії

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

Цей випуск містить загалом 15 вдосконалень, які перейшли до стабільної версії:

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

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

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

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

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

Як наслідок, проєкт Kubernetes оголосив, що Ingress NGINX отримуватиме лише мінімальне обслуговування до березня 2026 року. Після цієї дати він буде заархівований без подальших оновлень. Рекомендований варіант подальших дій — перехід на Gateway API, який пропонує більш сучасний, безпечний і розширюваний стандарт управління трафіком.

Більше інформації ви можете знайти в офіційному дописі в блозі.

Видалення підтримки cgroup v1

Що стосується управління ресурсами на вузлах Linux, Kubernetes історично покладався на cgroups (контрольні групи). Хоча оригінальний cgroup v1 був функціональним, він часто був непослідовним і обмеженим. Ось чому Kubernetes ще в версії v1.25 запровадив підтримку cgroup v2, пропонуючи набагато чистішу, уніфіковану ієрархію та кращу ізоляцію ресурсів.

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

Щоб дізнатися більше, прочитайте про cgroup v2; ви також можете стежити за переходом в KEP-5573: Remove cgroup v1 support.

Виведення з експлуатації режиму ipvs в kube-proxy

Кілька років тому Kubernetes застосував режим ipvs у kube-proxy, щоб забезпечити швидше балансування навантаження, ніж стандартний режим iptables. Хоча це забезпечило підвищення продуктивності, синхронізація з мінливими вимогами до мережі створила занадто великий технічний борг і складність.

Через це навантаження на обслуговування Kubernetes v1.35 відмовляється від режиму ipvs. Хоча цей режим залишається доступним у цій версії, kube-proxy тепер видаватиме попередження під час запуску, якщо він налаштований на його використання. Мета полягає в оптимізації кодової бази та зосередженні уваги на сучасних стандартах. Для вузлів Linux слід почати перехід на nftables, який зараз є рекомендованою заміною.

Більше інформації можна знайти в KEP-5495: Deprecate ipvs mode in kube-proxy.

Останній дзвоник для containerd v1.X

Хоча Kubernetes v1.35 все ще підтримує containerd 1.7 та інші випуски LTS, це остання версія з такою підтримкою. Спільнота SIG Node визначила v1.35 як останній випуск, що підтримує серію containerd v1.X.

Це важливе нагадування: перед оновленням до наступної версії Kubernetes ви повинні перейти на containerd 2.0 або новішу версію. Щоб визначити, які вузли потребують уваги, ви можете відстежувати метрику kubelet_cri_losing_support у своєму кластері.

Більше інформації ви можете знайти в офіційному дописі в блозі або в KEP-4033: Discover cgroup driver from CRI.

Покращена стабільність Podʼів під час перезапуску kubelet

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

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

Більше інформації ви можете знайти в KEP-4781: Fix inconsistent container ready state after kubelet restart.

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

Ознайомтеся з повною інформацією про випуск Kubernetes v1.35 у наших примітках до випуску.

Доступність

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

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

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

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

Ми вшановуємо памʼять Хана Канга, багаторічного учасника та шановного інженера, чия технічна досконалість та заразливий ентузіазм залишили незабутній слід у спільноті Kubernetes. Хан був значною силою в SIG Instrumentation та SIG API Machinery, отримавши нагороду Kubernetes Contributor Award 2021 за свою важливу роботу та постійну відданість стабільності проєкту. Окрім технічного внеску, Хана глибоко поважали за його щирість як наставника та пристрасть до налагодження звʼязків між людьми. Він був відомий тим, що «відкривав двері» для інших, чи то допомагаючи новим учасникам з їхніми першими pull-request, чи то підтримуючи колег з терпінням і добротою. Спадщина Хана живе в інженерах, яких він надихнув, у надійних системах, які він допоміг створити, та в теплій атмосфері співпраці, яку він культивував у хмарній екосистемі.

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

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

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

Під час циклу випуску версії 1.35, який тривав 14 тижнів з 15 вересня 2025 року по 17 грудня 2025 року, Kubernetes отримав внески від 85 різних компаній та 419 окремих осіб. У ширшій екосистемі хмарних технологій ця цифра зростає до 281 компанії, що налічує 1769 учасників.

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

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

Огляд подій

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

Лютий 2026 року

**Березень 2026

**Травень 2026

Червень 2026 р.

Липень 2026 р.

Останні подробиці про подію можна знайти тут. ​

Вебінар про майбутній реліз

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

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

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

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