Kubernetes v1.34: Of Wind & Will (O' WaW)

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

Редактори: Agustina Barbetta, Alejandro Josue Leon Bellido, Graziano Casto, Melony Qin, Dipesh Rawat

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

Цей реліз складається з 58 покращень. З них 23 перейшли до стабільного стану, 22 входять до бета-версії, а 13 перейшли до альфа-версії.

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

Випуск, що рухається силою вітру навколо нас — і силою нашої волі.

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

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

Цей реліз, Of Wind & Will (O' WaW), вшановує вітри, які сформували нас, і волю, яка штовхає нас вперед.

^ О, і ви здивовані, чому ведмеді? Продовжуйте дивуватися!

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

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

Stable: Ядро DRA тепер GA

Динамічне виділення ресурсів (DRA) дозволяє використовувати потужніші способи вибору, виділення, спільного використання та налаштування GPU, TPU, мережевих карт та інших пристроїв.

Починаючи з релізу v1.30, DRA базується на заявках на пристрої за допомогою структурованих параметрів, які є непрозорими для ядра Kubernetes. Це покращення було натхненне динамічним провізуванням для сховищ. DRA зі структурованими параметрами спирається на набір допоміжних API-видів: ResourceClaim, DeviceClass, ResourceClaimTemplate та ResourceSlice API-типів в рамках resource.k8s.io, одночасно розширюючи .spec для Podʼів новим полем resourceClaims. API resource.k8s.io/v1 стали стабільними і тепер є стандартно доступними.

Ця робота була виконана в рамках KEP #4381, очолюваної WG Device Management.

Beta: Захищені токени ServiceAccount для провайдерів облікових даних образів kubelet

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

Ця робота була виконана в рамках KEP #4412, очолюваної SIG Auth та SIG Node.

Alpha: Підтримка KYAML, діалекту YAML для Kubernetes

KYAML має бути більш безпечним і менш неоднозначною підмножиною YAML, і був спроектований спеціально для Kubernetes. Незалежно від версії Kubernetes, яку ви використовуєте, починаючи з Kubernetes v1.34 ви можете використовувати KYAML як новий формат виводу для kubectl.

KYAML вирішує специфічні проблеми як з YAML, так і з JSON. Значний пробіл YAML вимагає уважної уваги до відступів та вкладеності, тоді як необовʼязкове взяття рядків в лапки може призвести до неочікуваного приведення типів (наприклад: "The Norway Bug"). Тим часом, JSON не підтримує коментарі та має суворі вимоги до наявності ком та ключів в лапках.

Ви можете писати KYAML та передавати його як вхідні дані будь-якій версії kubectl, оскільки всі файли KYAML також є дійсними YAML. З kubectl v1.34 ви також можете запитувати вивід у форматі KYAML (як у kubectl get -o kyaml …), встановивши змінну середовища KUBECTL_KYAML=true. Якщо ви бажаєте, ви все ще можете запитувати вивід у форматі JSON або YAML.

Ця робота була виконана в рамках KEP #5295, очолюваної SIG CLI.

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

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

Відкладене створення замінних Podʼів для Job

Стандартно, контролери Job створюють замінні Podʼи негайно, коли Pod починає завершення своєї роботи, що призводить до одночасного виконання обох Podʼів. Це може спричинити конкуренцію за ресурси в обмежених кластерах, де замінний Pod може зіткнутися з труднощами при пошуку доступних вузлів, поки оригінальний Pod повністю не завершиться. Ситуація також може спровокувати небажане збільшення масштабу кластеру. Крім того, деякі фреймворки машинного навчання, такі як TensorFlow та JAX, вимагають, щоб на індекс припадав лише один Pod, що робить одночасне виконання Podʼів проблематичним. Ця функція вводить .spec.podReplacementPolicy у Jobs. Ви можете вибрати створення замінних Podʼів лише тоді, коли Pod повністю завершено (має .status.phase: Failed). Для цього встановіть .spec.podReplacementPolicy: Failed. Представлена як альфа у v1.28, ця функція стала стабільною у v1.34.

Ця робота була виконана в рамках KEP #3939, очолюваної SIG Apps.

Відновлення після збою розширення тому

Ця функція дозволяє користувачам скасовувати розширення тому, які не підтримуються підляглими постачальниками зберігання, і повторно спробувати розширити том з меншими значеннями, які можуть бути успішними. Представлена як альфа у v1.23, ця функція стала стабільною у v1.34.

Ця робота була виконана в рамках KEP #1790, очолюваної SIG Storage.

VolumeAttributesClass для зміни томів

VolumeAttributesClass став стабільним у v1.34. VolumeAttributesClass — це загальний, рідний для Kubernetes API для зміни параметрів тому, таких як виділений IO. Він дозволяє робочим навантаженням вертикально масштабувати свої томи онлайн для балансування вартості та продуктивності, якщо це підтримується їх провайдером. Як і всі нові функції томів в Kubernetes, цей API реалізується через інтерфейс зберігання контейнерів (CSI). Ваш специфічний для провайдерів CSI драйвер повинен підтримувати новий ModifyVolume API, який є CSI стороною цієї функції.

Ця робота була виконана в рамках KEP #3751, очолюваної SIG Storage.

Структурована конфігурація автентифікації

Kubernetes v1.29 представив формат файлу конфігурації для управління автентифікацією клієнта API сервера, відмовившись від попередньої залежності від великої кількості параметрів командного рядка. AuthenticationConfiguration дозволяє адміністраторам підтримувати кілька автентифікаторів JWT, перевірку виразів CEL та динамічну перезагрузку. Ця зміна суттєво покращує керованість та можливість аудиту налаштувань автентифікації кластеру, і стала стабільною у v1.34.

Ця робота була виконана в рамках KEP #3331, очолюваної SIG Auth.

Більш детальна авторизація на основі селекторів

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

Наприклад, ви можете написати політику авторизації, яка дозволяє лише вивід переліку Podʼів, привʼязаних до конкретного .spec.nodeName. Клієнт (можливо, kubelet на певному вузлі) повинен вказати селектор поля, який вимагає політика, в іншому випадку запит заборонено. Ця зміна робить можливим налаштування правил найменшого привілею, за умови, що клієнт знає, як відповідати встановленим вами обмеженням. Kubernetes v1.34 тепер підтримує більш детальний контроль у таких середовищах, як ізоляція на рівні вузлів або спеціальні багатокористувацькі налаштування.

Ця робота була виконана в рамках KEP #4601, очолюваної SIG Auth.

Обмеження анонімних запитів за допомогою детальних налаштувань контролю

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

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

Ця робота була виконана в рамках KEP #4633, очолюваної SIG Auth.

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

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

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

Ця робота була виконана в рамках KEP #4247, очолюваної SIG Scheduling.

Впорядковане видалення Namespace

Напіввипадковий порядок видалення ресурсів може створювати прогалини в безпеці або непередбачувану поведінку, таку як збереження Podʼів після видалення їх асоційованих NetworkPolicies. Це покращення впроваджує більш структурований процес видалення для просторів імен Kubernetes, щоб забезпечити безпечне та детерміноване видалення ресурсів. Дотримуючись структурованої послідовності видалення, яка враховує логічні та безпекові залежності, цей підхід забезпечує видалення Podʼів перед іншими ресурсами. Ця функція була представлена в Kubernetes v1.33 і стала стабільною в v1.34. Підвищення безпеки та надійності завдяки зменшенню ризиків від недетермінованих видалень, включаючи вразливість, описану в CVE-2024-7598.

Ця робота була виконана в рамках KEP #5080, очолюваної SIG API Machinery.

Потокове передавання list відповідей

Обробка великих list відповідей у Kubernetes раніше становила значну проблему масштабованості. Коли клієнти запитували великі списки ресурсів, такі як тисячі Podʼів або Custom Resources, API серверу потрібно було серіалізувати всю колекцію обʼєктів в один великий буфер памʼяті перед відправленням. Цей процес створював значний тиск на памʼять і міг призвести до погіршення продуктивності, впливаючи на загальну стабільність кластера. Щоб розвʼязати це обмеження, було впроваджено механізм кодування потоків для колекцій (відповідей списку). Цей механізм потокового передавання автоматично активний для форматів відповіді JSON та Kubernetes Protobuf, і відповідна функціональна можливість є стабільною. Основна перевага цього підходу полягає в уникненні великих алокацій памʼяті на API сервері, що призводить до набагато меншої та більш передбачуваної витрати памʼяті. Внаслідок цього кластер стає більш стійким і продуктивним, особливо в середовищах великого масштабу, де часті запити на великі списки ресурсів є звичайними.

Ця робота була виконана в рамках KEP #5116, очолюваної SIG API Machinery.

Ініціалізація стійкого кешу спостереження

Watch cache — це шар кешування всередині kube-apiserver, який підтримує врешті-решт узгоджений кеш стану кластера, збереженого в etcd. У минулому могли виникати проблеми, коли кеш спостереження ще не був ініціалізований під час запуску kube-apiserver або коли він вимагав повторної ініціалізації.

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

Ця робота була виконана в рамках KEP #4568, очолюваної SIG API Machinery та SIG Scalability.

Послаблення перевірки шляху пошуку DNS

Раніше сувора перевірка шляху DNS search у Kubernetes часто створювала проблеми інтеграції в складних або застарілих мережевих середовищах. Ця обмеженість могла блокувати конфігурації, які були необхідні для інфраструктури організації, змушуючи адміністраторів впроваджувати складні обхідні шляхи. Щоб вирішити цю проблему, була введена послаблена перевірка DNS як альфа у v1.32, і вона стала стабільною у v1.34. Загальний випадок використання включає Podʼи, які повинні спілкуватися як з внутрішніми службами Kubernetes, так і з зовнішніми доменами. Встановивши одну крапку (.) як перший запис у списку searches поля .spec.dnsConfig Pod, адміністратори можуть запобігти додаванню внутрішніх доменів пошуку кластера до зовнішніх запитів. Це запобігає створенню непотрібних DNS-запитів до внутрішнього DNS-сервера для зовнішніх імен хостів, покращуючи ефективність та запобігаючи потенційним помилкам резолюції.

Ця робота була виконана в рамках KEP #4427, очолюваної SIG Network.

Підтримкадля Direct Service Return (DSR) у Windows kube-proxy

DSR забезпечує оптимізацію продуктивності, дозволяючи поверненню трафіку, що маршрутизується через балансувальники навантаження, обходити балансувальник і безпосередньо відповідати клієнту, зменшуючи навантаження на балансувальник і покращуючи загальну затримку. Для отримання інформації про DSR у Windows читайте Direct Server Return (DSR) in a nutshell. Спочатку представлена у v1.14, ця функція стала стабільною у v1.34.

Ця робота була виконана в рамках KEP #5100, очолюваної SIG Windows.

Дія Sleep для хуків життєвого циклу контейнерів

Дія Sleep для хуків життєвого циклу контейнерів PreStop і PostStart була введена, щоб забезпечити простий спосіб керування процесом відповідного завершення роботи та покращити загальне управління життєвим циклом контейнерів. Дія Sleep дозволяє контейнерам призупинятися на вказаний період після запуску або перед завершенням. Використання негативної або нульової тривалості сну призводить до негайного повернення, що призводить до відсутності операції. Дія Sleep була представлена в Kubernetes v1.29, з підтримкою нульового значення, доданою в v1.32. Обидві функції стали стабільними в v1.34.

Ця робота була виконана в рамках KEP #3960 та KEP #4818, очолюваної SIG Node.

Підтримка свопу на вузлах Linux

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

Щоб вирішити цю проблему, підтримка свопу з налаштуваннями на рівні вузлів була представлена у v1.22. Вона пройшла через альфа- та бета-етапи і стала стабільною у v1.34. Основний режим, LimitedSwap, дозволяє Podʼам використовувати своп всередині їх наявних обмежень памʼяті, надаючи безпосереднє розвʼязання проблеми. Стандартно, kubelet налаштований у режимі NoSwap, що означає, що робочі навантаження Kubernetes не можуть використовувати своп.

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

Ця робота була виконана в рамках KEP #2400, очолюваної SIG Node.

Дозвіл на використання спеціальних символів в змінних середовища

Правила валідації змінних середовища в Kubernetes були послаблені, щоб дозволити майже всі друковані символи ASCII в іменах змінних, за винятком =. Ця зміна підтримує сценарії, коли робочі навантаження вимагають нестандартних символів в іменах змінних, наприклад, фреймворки, такі як .NET Core, які використовують : для представлення вкладених ключів конфігурації.

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

Ця робота була виконана в рамках KEP #4369, очолюваної SIG Node.

Керування позначками taint тепер відокремлено від життєвого циклу вузлів

Історично, логіка TaintManager щодо застосування taints NoSchedule та NoExecute до вузлів на основі їх стану (NotReady, Unreachable тощо) була тісно повʼязана з контролером життєвого циклу вузлів. Це тісне зʼєднання ускладнювало обслуговування та тестування коду, а також обмежувало гнучкість механізму виселення на основі taint. Цей KEP переносить TaintManager у свій власний окремий контролер у межах менеджера контролерів Kubernetes. Це внутрішнє архітектурне покращення, спрямоване на підвищення модульності та підтримуваності коду. Ця зміна дозволяє логіці виселення на основі taint тестуватися та розвиватися незалежно, але не має прямого впливу на користувацький інтерфейс щодо використання taints.

Ця робота була виконана в рамках KEP #3902, очолюваної SIG Scheduling та SIG Node.

Нові Beta функції

Це деякі покращення, які тепер є бета після випуску v1.34.

Запити та обмеження ресурсів на рівні Pod

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

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

Ця робота була виконана в рамках KEP #2837, очолюваної SIG Scheduling та SIG Autoscaling.

Файл .kuberc для налаштувань користувача kubectl

Файл конфігурації .kuberc дозволяє визначити уподобання для kubectl, такі як стандартні параметри та псевдоніми команд. На відміну від файлу kubeconfig, файл конфігурації .kuberc не містить інформації про кластер, імен користувачів або паролів. Ця функція була представлена як альфа у v1.33, під контролем змінної середовища KUBECTL_KUBERC. Вона стала бета у v1.34 і є стандартно увімкненою.

Ця робота була виконана в рамках KEP #3104, очолюваної SIG CLI.

Підписування токенів зовнішніх ServiceAccount

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

Представлена як альфа у v1.32, ця зовнішня можливість підпису JWT переходить у бета-версію та є стандартно увімкненою у v1.34.

Ця робота була виконана в рамках KEP #740, очолюваної SIG Auth.

Функції DRA у бета-версії

Адміністративний доступ для безпечного моніторингу ресурсів

DRA підтримує контрольований адміністративний доступ через поле adminAccess у ResourceClaims або ResourceClaimTemplates, що дозволяє операторам кластерів отримувати доступ до пристроїв, які вже використовуються іншими, для моніторингу або діагностики. Цей привілейований режим обмежений користувачами, уповноваженими створювати такі обʼєкти в просторах імен, помічених як resource.k8s.io/admin-access: "true", що забезпечує, щоб звичайні робочі навантаження залишалися неушкодженими. Перехід до бета-версії у v1.34 надає цю функцію безпечних інструментів для спостереження, зберігаючи при цьому ізоляцію робочих навантажень через авторизаційні перевірки на основі просторів імен.

Ця робота була виконана в рамках KEP #5018, очолюваної WG Device Management та SIG Auth.

Пріоритетні альтернативи в ResourceClaims та ResourceClaimTemplates

Хоча робоче навантаження може найкраще працювати на одному високопродуктивному GPU, воно також може працювати на двох слабших GPU. З перемикачем функцій DRAPrioritizedList (тепер стандартно увімкнено) ResourceClaims та ResourceClaimTemplates отримують нове поле firstAvailable. Це поле є впорядкованим списком, що дозволяє користувачам вказувати, що запит може бути задоволений різними способами, включаючи виділення нічого, якщо специфічне обладнання недоступне. Планувальник намагатиметься задовольнити альтернативи в списку за порядком, тому робоче навантаження отримає найкращий набір доступних пристроїв у кластері.

Ця робота була виконана в рамках KEP #4816, очолюваної WG Device Management.

kubelet сповіщає про виділені ресурси DRA

API kubelet було оновлено для звіту про ресурси Pod, виділені через DRA. Це дозволяє агентам моніторингу вузлів виявляти виділені ресурси DRA для Podʼів на вузлі. Крім того, це дозволяє вузловим компонентам використовувати PodResourcesAPI та використовувати цю інформацію про DRA при розробці нових функцій та інтеграцій. Починаючи з Kubernetes v1.34, ця функція є стандартно увімкненою.

Ця робота була виконана в рамках KEP #3695, очолюваної WG Device Management.

Неблокуючі виклики API kube-scheduler

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

Ця робота була виконана в рамках KEP #5229, очолюваної SIG Scheduling.

Змінювані політики допуску

MutatingAdmissionPolicies пропонують декларативну, внутрішню альтернативу змінюваним веб-хукам допуску. Ця функція використовує інсталяцію обʼєктів CEL та стратегії JSON Patch, в поєднанні з алгоритмами злиття Server Side Apply. Це суттєво спрощує контроль допуску, дозволяючи адміністраторам визначати правила мутації безпосередньо в API сервері. Представлені як альфа у v1.32, політики мутації допуску стали бета у v1.34.

Ця робота була виконана в рамках KEP #3962, очолюваної SIG API Machinery.

Кеш сервера API, доступний для знімків

Механізм кешування kube-apiserver (кеш спостереження) ефективно обслуговує запити на останній спостережуваний стан. Однак, list запити на попередні стани (наприклад, через пагінацію або вказуючи resourceVersion) часто обходять цей кеш і обслуговуються безпосередньо з etcd. Це пряме звернення до etcd значно збільшує витрати на продуктивність і може призвести до проблем зі стабільністю, особливо з великими ресурсами, через тиск на памʼять від передачі великих обсягів даних. Зі стандартно увімкненою функцією ListFromCacheSnapshot kube-apiserver намагатиметься обслуговувати відповідь з моментальних знімків, якщо такий є з resourceVersion, старішим за запитуваний. kube-apiserver починає без знімків, створює новий знімок на кожну подію спостереження і зберігає їх, поки не виявить, що etcd стиснуто, або якщо кеш заповнений подіями старшими за 75 секунд. Якщо вказаний resourceVersion недоступний, сервер повернеться до etcd.

Ця робота була виконана в рамках KEP #4988, очолюваної SIG API Machinery.

Інструменти для декларативної перевірки типів, властивих Kubernetes

Перед цим випуском правила валідації для вбудованих у Kubernetes API писалися повністю вручну, що ускладнює їх виявлення, розуміння, покращення або тестування для супроводжуючих. Не було єдиного способу знайти всі правила валідації, які можуть застосовуватися до API. Декларативна валідація приносить користь супроводжувачам Kubernetes, спрощуючи розробку, обслуговування та перевірку API, одночасно дозволяючи програмну інспекцію для кращого інструментування та документації. Для людей, які використовують бібліотеки Kubernetes для написання свого коду (наприклад: контролера), новий підхід спрощує додавання нових полів через IDL теґи, а не складні функції валідації. Ця зміна допомагає прискорити створення API, автоматизуючи шаблони валідації, та надає більш релевантні повідомлення про помилки, виконуючи валідацію на версійованих типах.​​​​​​​​​​​​​​​​ Це вдосконалення (яке стало бета у v1.33 і продовжується як бета у v1.34) приносить правила валідації на основі CEL до рідних типів Kubernetes. Це дозволяє визначати більш детальну та декларативну валідацію безпосередньо в визначеннях типів, покращуючи узгодженість API та взаємодію з розробниками.

Ця робота була виконана в рамках KEP #5073, очолюваної SIG API Machinery.

Потокові інформери для запитів list

Функція потокових інформерів, яка була в бета-версії з v1.32, отримує подальші вдосконалення бета-версії в v1.34. Ця можливість дозволяє list запитам повертати дані як безперервний потік обʼєктів з кешу спостереження API сервера, а не збиратися з пагінованих результатів безпосередньо з etcd. Повторюючи ті ж механізми, що використовуються для операцій watch, API сервер може обслуговувати великі набори даних, зберігаючи при цьому стабільне використання памʼяті та уникаючи піків алокації, які можуть вплинути на стабільність.

У цьому релізі kube-apiserver та kube-controller-manager обидва типово використовують новий механізм WatchList. Для kube-apiserver це означає, що запити списку тепер обслуговуються більш ефективно, тоді як kube-controller-manager отримує більш ефективний з точки зору памʼяті та передбачуваний спосіб роботи з інформерами. Разом ці покращення зменшують тиск на памʼять під час великих операцій list та покращують надійність під час тривалого навантаження, роблячи потокову передачу списків більш передбачуваною та ефективною.

Ця робота була виконана в рамках KEP #3157, очолюваної SIG API Machinery та SIG Scalability.

Управління належним вимкненням для вузлів на Windows

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

Ця робота була виконана в рамках KEP #4802, очолюваної SIG Windows.

Покращення в зміні розмірів Podʼа на місці

Підвищена до бета-версії та стандартно увімкнена у v1.33, функція зміни розміру Podʼа на місці отримує подальші вдосконалення в v1.34. До них відноситься підтримка зменшення використання памʼяті та інтеграція з ресурсами на рівні Podʼа.

Ця функція залишається в бета-версії в v1.34. Для отримання детальних інструкцій щодо використання та прикладів зверніться до документації: Зміна ресурсів CPU та памʼяті, призначених контейнерам.

Ця робота була виконана в рамках KEP #1287, очолюваної SIG Node та SIG Autoscaling.

Нові функції в Alpha

Це деякі з покращень, які тепер є альфа після випуску v1.34.

Сертифікати Pod для автентифікації mTLS

Автентифікація робочих навантажень всередині кластера, особливо для звʼязку з API сервером, в основному покладалася на токени ServiceAccount. Хоча це ефективно, ці токени не завжди є ідеальними для встановлення сильної, перевіряємої ідентичності для взаємного TLS (mTLS) і можуть створювати проблеми при інтеграції з зовнішніми системами, які очікують автентифікації на основі сертифікатів. Kubernetes v1.34 вводить вбудований механізм для Podʼів для отримання сертифікатів X.509 через PodCertificateRequests. kubelet може запитувати та керувати сертифікатами для Podʼів, які потім можуть використовуватися для автентифікації на сервері API Kubernetes та інших службах за допомогою mTLS. Основна перевага полягає в більш надійному та гнучкому механізмі ідентифікації для Podʼів. Це надає рідний спосіб реалізації надійної автентифікації mTLS без покладання виключно на маркерні токени, узгоджуючи Kubernetes зі стандартними практиками безпеки та спрощуючи інтеграцію з інструментами спостереження та безпеки, які використовують сертифікати.

Ця робота була виконана в рамках KEP #4317, очолюваної SIG Auth.

Стандарт безпеки Pod "Restricted" тепер забороняє віддалені перевірки

Поле host в рамках перевірок та обробників життєвого циклу дозволяє користувачам вказувати іншу сутність, ніж podIP, для перевірки kubelet. Однак, це відкриває шлях для зловживань та атак, які обходять засоби безпеки, оскільки поле host може бути встановлено на будь-яке значення, включаючи чутливі до безпеки зовнішні хости або localhost на вузлі. У Kubernetes v1.34, Podʼи відповідають стандарту безпеки Restricted лише в тому випадку, якщо вони або залишають поле host не налаштованим, або якщо вони навіть не використовують цей тип перевірки. Ви можете використовувати автоматизацію безпеки Pod, або сторонніх рішень, щоб забезпечити відповідність Podʼів цьому стандарту. Оскільки це засоби безпеки, ознайомтеся з документацією, щоб зрозуміти обмеження та поведінку механізму примусового виконання, який ви обираєте.

Ця робота була виконана в рамках KEP #4940, очолюваної SIG Auth.

Використовуйте .status.nominatedNodeName для показу розміщення Podʼа

Коли kube-scheduler затримується з привʼязкою Podʼів до вузлів, кластерні автомасштабувальники можуть не розуміти, що Pod буде привʼязаний до певного вузла. Внаслідок цього вони можуть помилково вважати вузол недовикористаним і видалити його. Щоб вирішити цю проблему, kube-scheduler може використовувати .status.nominatedNodeName не лише для вказівки на триваюче примусове виконання, але й для показу намірів розміщення Pod. Увімкнувши функціональну можливість NominatedNodeNameForExpectation, планувальник використовує це поле, щоб вказати, куди Pod буде призначений. Це відкриває внутрішні резервування, щоб допомогти зовнішнім компонентам приймати обґрунтовані рішення.

Ця робота була виконана в рамках KEP #5278, очолюваної SIG Scheduling.

Функції DRA в альфа-версії

Стан ресурсів для DRA

Може бути важко дізнатися, коли Pod використовує пристрій, який вийшов з ладу або тимчасово не працює, що ускладнює усунення неполадок, повʼязаних з аварією Pod. Стан справності ресурсу для DRA покращує спостережуваність, відкриваючи стан справності пристроїв, виділених Podʼу, у статусі Podʼа. Це полегшує виявлення причин проблем Podʼа, повʼязаних з несправними пристроями, та відповідь на них. Щоб увімкнути цю функціональність, потрібно активувати функціональну можливість ResourceHealthStatus, а драйвер DRA повинен реалізувати сервіс gRPC DRAResourceHealth.

Ця робота була виконана в рамках KEP #4680, очолюваної WG Device Management.

Зіставлення розширених ресурсів

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

Ця робота була виконана в рамках KEP #5004, очолюваної WG Device Management.

Споживча спроможність DRA

У Kubernetes v1.33 додано підтримку драйверів ресурсів для оголошення доступних частин пристрою, замість того, щоб виставляти весь пристрій як ресурс «все або нічого». Однак, цей підхід не міг впоратися зі сценаріями, де драйвери пристроїв керують тонкими, динамічними частинами ресурсу пристрою на основі попиту користувача або ділять ці ресурси незалежно від ResourceClaims, які обмежені їх специфікацією та простором іменем. Увімкнення функціональної можливості DRAConsumableCapacity (представленої як альфа у v1.34) дозволяє драйверам ресурсів ділити один й той же пристрій, або навіть частину пристрою, між кількома ResourceClaims або між кількома DeviceRequests. Ця функція також розширює планувальник, щоб підтримувати виділення частин ресурсів пристрою, як визначено в полі capacity. Ця функція DRA покращує спільне використання пристроїв між просторами імен та заявками, налаштовуючи його на потреби Pod. Вона дозволяє драйверам забезпечувати обмеження ємності, покращує планування та підтримує нові випадки використання, такі як обізнаний про пропускну здатність мережевий звʼязок та багатокористувацьке спільне використання.

Ця робота була виконана в рамках KEP #5075, очолюваної WG Device Management.

Умови привʼязки пристроїв

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

Ця робота була виконана в рамках KEP #5007, очолюваної WG Device Management.

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

В даний час всі контейнери в межах Podʼа будуть дотримуватися однієї й тієї ж політики перезапуску .spec.restartPolicy під час виходу або аварії. Однак, Podʼи, які виконують кілька контейнерів, можуть мати різні вимоги до перезапуску для кожного контейнера. Наприклад, для ініціалізаційних контейнерів, які використовуються для виконання ініціалізації, ви, можливо, не захочете повторювати спроби ініціалізації, якщо вони зазнають невдачі. Аналогічно, в середовищах дослідження ML з тривалими навчальними навантаженнями, контейнери, які зазнають невдачі з кодами виходу, що підлягають повторному спробуванню, повинні швидко перезапускатися на місці, а не викликати відтворення Pod і втрату прогресу. Kubernetes v1.34 вводить перемикач функцій ContainerRestartRules. Коли він увімкнений, політика перезапуску може бути вказана для кожного контейнера в межах Pod. Також можна визначити список restartPolicyRules, щоб переважити restartPolicy на основі останнього коду виходу. Це надає детальний контроль, необхідний для обробки складних сценаріїв та кращого використання обчислювальних ресурсів.

Ця робота була виконана в рамках KEP #5307, очолюваної SIG Node.

Завантаження змінних середовища з файлів, створених під час виконання

Розробники застосунків давно просять про більшу гнучкість у оголошенні змінних середовища. Традиційно, змінні середовища оголошуються на стороні сервера API через статичні значення, ConfigMaps або Secrets.

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

Ця функція особливо корисна для навчальних навантажень AI/ML, де кожен Pod у навчальному завданні вимагає ініціалізації з значеннями, визначеними під час виконання.

Ця робота була виконана в рамках KEP #5307, очолюваної SIG Node.

Зміна станів, застарівання та видалення в v1.34

Перехід до стабільного стану

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

Цей реліз включає в себе в цілому 23 вдосконалення, які стали стабільними:

Застарівання та вилучення

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

Ручна конфігурація драйвера cgroup застаріла

Історично, налаштування правильного драйвера cgroup було болючою точкою для користувачів, які використовували кластери Kubernetes. Kubernetes v1.28 додав спосіб для kubelet запитувати реалізацію CRI та дізнаватися, який драйвер cgroup використовувати. Це автоматичне виявлення тепер наполегливо рекомендується і підтримка цього функціоналу стала стабільною у v1.34. Якщо ваш CRI рушій виконання контейнерів не підтримує можливість повідомляти про драйвер cgroup, який йому потрібен, вам слід оновити або змінити його. Налаштування cgroupDriver у файлі конфігурації kubelet тепер застаріло. Відповідна опція командного рядка --cgroup-driver була раніше застаріла, оскільки Kubernetes рекомендує використовувати замість цього файл конфігурації. Як і налаштування конфігурації, так і опція командного рядка будуть видалені в майбутньому релізі, але це видалення не відбудеться раніше, ніж у мінорному релізі випуску v1.36.

Ця робота була виконана в рамках KEP #4033, очолюваної SIG Node.

Kubernetes припинить підтримку containerd 1.x у v1.36

Хоча Kubernetes v1.34 все ще підтримує containerd 1.7 та інші LTS релізи containerd, внаслідок автоматичного виявлення драйвера cgroup, спільнота Kubernetes SIG Node формально погодилася на остаточний графік підтримки для containerd v1.X. Останнім релізом Kubernetes, який запропонує цю підтримку, буде v1.35 (узгоджений з EOL containerd 1.7). Це раннє попередження про те, що якщо ви використовуєте containerd 1.X, розгляньте можливість переходу на 2.0+ найближчим часом. Ви можете моніторити метрику kubelet_cri_losing_support, щоб визначити, чи використовують якісь вузли у вашому кластері версію containerd, яка незабаром стане застарілою.

Ця робота була виконана в рамках KEP #4033, очолюваної SIG Node.

Розподіл трафіку PreferClose є застарілим

Поле spec.trafficDistribution в рамках Kubernetes Service дозволяє користувачам висловлювати переваги щодо того, як трафік повинен маршрутизуватися до точок доступу сервісу.

KEP-3015 визнає застарілим PreferClose і вводить два додаткових значення: PreferSameZone та PreferSameNode. PreferSameZone є псевдонімом для наявного PreferClose, щоб прояснити його семантику. PreferSameNode дозволяє зʼєднанням доставлятися до локальної точки доступу, коли це можливо, з переходом на віддалену точку доступу, коли це неможливо.

Ця функція була представлена у v1.33 під перемикачем функцій PreferSameTrafficDistribution. Вона стала бета у v1.34 і є стандартно увімкненою.

Ця робота була виконана в рамках KEP #3015, очолюваної SIG Network.

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

Перегляньте всі деталі випуску Kubernetes v1.34 у наших примітках до випуску.

Доступність

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

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

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

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

Ми вшановуємо памʼять Рудольфо "Родо" Мартінеса Веги, відданого учасника, чия пристрасть до технологій та побудови спільноти залишила слід у спільноті Kubernetes. Родо був учасником команди випуску Kubernetes протягом кількох релізів, включаючи v1.22-v1.23 та v1.25-v1.30, демонструючи непохитну відданість успіху та стабільності проєкту. Поза участтю в команді випуску, Родо активно сприяв розвитку спільноти Cloud Native LATAM, допомагаючи подолати мовні та культурні барʼєри в цій сфері. Його робота над іспанською версією документації Kubernetes та глосарію CNCF є прикладом його відданості справі зробити знання доступними для розробників, які говорять іспанською мовою, по всьому світу. Спадщина Родо живе через безліч членів спільноти, яких він наставляв, релізи, які він допоміг випустити, та яскраву спільноту Kubernetes LATAM, яку він допоміг виростити.

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

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

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

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

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

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

Майбутні події

Ознайомтесь з майбутніми подіями Kubernetes та Cloud Native, включаючи KubeCon + CloudNativeCon, KCD та інші помітні конференції по всьому світу. Залишайтеся в курсі та беріть участь у житті спільноти Kubernetes!

Серпень 2025

Вересень 2025

Жовтень 2025

Листопад 2025

Грудень 2025

Ви можете знайти останні деталі подій тут.

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

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

Долучайтесь

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

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