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, мережевих карт (NIC) та інших пристроїв.

Починаючи з випуску v1.30, DRA базується на заявках на пристрої за допомогою структурованих параметрів, які є непрозорими для ядра Kubernetes. Це удосконалення було натхненне динамічним наданням томів сховища. DRA зі структурованими параметрами спирається на набір допоміжних видів API: типи API ResourceClaim, DeviceClass, ResourceClaimTemplate та ResourceSlice у 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-драйвер, специфічний для провізіонера, повинен підтримувати новий API ModifyVolume, який є стороною 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-серверу потрібно було серіалізувати всю колекцію обʼєктів в один великий буфер памʼяті перед відправленням. Цей процес створював значний тиск на памʼять і міг призвести до погіршення продуктивності, впливаючи на загальну стабільність кластера.
Щоб усунути це обмеження, було впроваджено механізм потокового кодування для колекцій (відповідей list). Для форматів відповіді JSON та Kubernetes Protobuf цей механізм потокового передавання автоматично активний, а відповідна функціональна можливість є стабільною. Основна перевага цього підходу полягає в уникненні великих виділень памʼяті на API-сервері, що призводить до набагато меншого та більш передбачуваного споживання памʼяті. Внаслідок цього кластер стає більш стійким і продуктивним, особливо в середовищах великого масштабу, де часті запити на великі списки ресурсів є звичайними.

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

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

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

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

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

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

Раніше сувора перевірка шляху пошуку DNS (search) Podʼа у 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 було введено, щоб забезпечити простий спосіб керування належним (graceful) завершенням роботи та покращити загальне управління життєвим циклом контейнерів.
Дія Sleep дозволяє контейнерам призупинятися на вказаний період після запуску або перед завершенням. Використання відʼємної або нульової тривалості сну спричиняє негайне повернення, тобто дія нічого не робить (no-op).
Дію 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 щодо застосування позначок taint 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ʼів з кількома контейнерами. Це гарантує, що загальні ресурси, які використовуються всіма контейнерами, не перевищують визначених обмежень 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 виконано ущільнення (compaction), або доки кеш не заповниться подіями, старшими за 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 це означає, що запити list ефективніше передаються потоком, тоді як kube-controller-manager отримує ефективніший з точки зору памʼяті та передбачуваний спосіб роботи з інформерами. Разом ці покращення зменшують тиск на памʼять під час великих операцій list та покращують надійність під час тривалого навантаження, роблячи потокову передачу списків передбачуванішою та ефективнішою.

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

Обробка належного вимкнення для вузлів Windows

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

Ця робота була виконана в рамках 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 без покладання виключно на токени на предʼявника (bearer tokens), узгоджуючи Kubernetes зі стандартними практиками безпеки та спрощуючи інтеграцію з інструментами спостереження та безпеки, що працюють із сертифікатами.

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

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

Поле host у перевірках (probes) та обробниках життєвого циклу дозволяє користувачам вказувати для перевірки kubelet іншу сутність, ніж podIP. Однак це відкриває шлях для зловживань та атак, які обходять засоби безпеки, оскільки в поле host можна встановити будь-яке значення, включаючи чутливі з погляду безпеки зовнішні хости або localhost на вузлі. У Kubernetes v1.34 Podʼи відповідають стандарту безпеки Podʼів Restricted лише в тому випадку, якщо вони або залишають поле host не встановленим, або взагалі не використовують цей тип перевірки. Ви можете використовувати допуск безпеки Podʼів (Pod security admission) або стороннє рішення, щоб забезпечити відповідність 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. Коли її увімкнено, restartPolicy можна вказати для кожного контейнера в межах Podʼа. Також можна визначити список restartPolicyRules, щоб перевизначати restartPolicy на основі останнього коду виходу. Це надає детальний контроль, необхідний для обробки складних сценаріїв, та краще використання обчислювальних ресурсів.

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

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

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

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

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

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

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

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

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

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

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

У міру розвитку та дозрівання Kubernetes функції можуть ставати застарілими, вилучатися або замінюватися кращими для покращення загального стану проєкту. Докладніше про цей процес дивіться в політиці застарівання та вилучення 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 дозволяє користувачам висловлювати переваги щодо того, як трафік повинен маршрутизуватися до точок доступу 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 для нашої спільноти. Склад команди випуску варіюється від новачків-стажерів (shadows) до досвідчених лідерів команд, що повертаються, з досвідом, набутим протягом кількох циклів випуску. Особлива подяка нашому лідеру випуску, Вйому Ядаву, за те, що провів нас через успішний цикл випуску, за його практичний підхід до розвʼязання проблем та за енергію й турботу, які рухають нашу спільноту вперед.

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

Проєкт 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
Змінено November 05, 2026 at 6:26 PM PST: [uk] Add blog post: Kubernetes v1.34 release announcement (e38eade2b7)