Kubernetes v1.35: Timbernetes (Випуск «Світове дерево»)

Автор Команда випуску Kubernetes v1.35 | Перекладач(і) Андрій Головін |

Редактори: 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-контейнерів або контейнерів ініціалізації. Kubernetes v1.35 забезпечує вбудовану ідентифікацію робочого навантаження з автоматизованою ротацією сертифікатів, що значно спрощує використання сервісних мереж та архітектур нульової довіри.

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

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

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

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

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

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

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

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

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

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

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

Механізм managed-by для Job API

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

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

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

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

Історично в API Pod не було поля metadata.generation, яке є в інших обʼєктах Kubernetes, таких як Deployment. Через це контролери та користувачі не мали надійного способу перевірити, чи 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 не є тим самим, що й Node в 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ʼа зазвичай потрібно було надсилати запит до API-сервера Kubernetes. Хоча цей підхід є функціональним, він створює складності та ризики для безпеки, оскільки вимагає широких дозволів 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, для оновлення схем або повторного шифрування даних у стані спокою. Цей метод був неефективним і схильним до конфліктів, особливо для великих ресурсів, таких як Secret. У цьому випуску вбудований контролер автоматично обробляє конфлікти оновлень і токени узгодженості, забезпечуючи безпечний, оптимізований і надійний спосіб гарантувати актуальність збережених даних з мінімальними операційними витратами.

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

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

Опортуністична пакетна обробка

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

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

Механізм пакетної обробки складається з двох операцій, які можна викликати в будь-який час, коли це необхідно — 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, щоб зберегти попередню поведінку оновлення лише одного Podʼа за раз. Це вдосконалення дозволяє застосункам зі збереженням стану (які можуть витримати недоступність більше ніж одного Podʼа) швидше завершувати оновлення.

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

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

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

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

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

KYAML

YAML — це формат серіалізації даних, зрозумілий для людини. У Kubernetes файли YAML використовуються для визначення та конфігурації ресурсів, таких як Pod, Service та Deployment. Однак складний 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ʼа часто потрібно надати дані, бінарні файли або файли конфігурації для контейнерів. Це означало включення вмісту в основний образ контейнера або використання власного контейнера ініціалізації для завантаження та розпакування файлів у 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 впроваджує механізм добровільного ввімкнення (opt-in) для драйверів 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ʼів у Deployment, що закладає основу для майбутніх політик щодо створення нових Podʼів під час розгортання.

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

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

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

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

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

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

Kubernetes v1.35 впроваджує вбудовану підтримку так званого «групового планування» (gang scheduling) за допомогою нового API Workload та концепції 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 впроваджує стратегію узгодження на основі спостереження для контролера маршрутів. Замість того, щоб покладатися на таймер, контролер тепер використовує інформери для спостереження за конкретними подіями Node, такими як додавання, видалення або відповідні оновлення полів, і запускає синхронізацію маршрутів тільки тоді, коли насправді відбувається зміна.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Taint та toleration для пристроїв

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

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

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

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

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

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

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

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

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

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

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

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

Переходи, застарівання та вилучення у v1.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. Склад команди випуску охоплює як тих, хто вперше бере участь як shadow, так і керівників команд, які повертаються з досвідом, набутим протягом кількох циклів випуску. Ми надзвичайно вдячні нашому керівнику випуску, Дрю Хагену, чиї практичні поради та енергійність не тільки допомогли нам подолати складні виклики, але й підживили дух спільноти, що стоїть за цим успішним випуском.

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

Проєкт 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 у середу, 14 січня 2026 року, о 17:00 (UTC), щоб дізнатися про основні особливості цього випуску. Для отримання додаткової інформації та реєстрації відвідайте сторінку події на сайті CNCF Online Programs.

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

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

  • Слідкуйте за нами у Bluesky @Kubernetesio, щоб бути в курсі останніх новин
  • Приєднуйтесь до обговорення спільноти у Discuss
  • Приєднуйтесь до спільноти в Slack
  • Ставте запитання (або відповідайте на запитання) в Stack Overflow
  • Поділіться своєю історією про Kubernetes
  • Дізнайтеся більше про те, що відбувається з Kubernetes, у блозі
  • Дізнайтеся більше про команду випуску Kubernetes
Змінено November 06, 2026 at 1:53 AM PST: Update content/uk/blog/_posts/2025/kubernetes-v1-35-release/index.md (63eada237e)