Попередній огляд Kubernetes v1.32

Автор Matteo Bianchi, Edith Puclla, William Rizzo, Ryota Sawada, Rashan Smith |

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

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

Процес видалення та застарівання API Kubernetes

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

  • Загальнодоступні (GA) або стабільні версії API можуть бути позначені як застарілі, але не повинні бути видалені в межах основної версії Kubernetes.

  • Бета або попередні версії API повинні підтримуватися протягом 3 випусків після застарівання.

  • Альфа або експериментальні версії API можуть бути видалені в будь-якому випуску без попереднього повідомлення про застарівання; цей процес може стати відкликанням у випадках, коли вже існує інша реалізація для тієї ж функції.

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

Примітка щодо відкликання старої реалізації DRA

Покращення #3063 ввело Динамічне виділення ресурсів (DRA — Dynamic Resource Allocation) в Kubernetes 1.26.

Однак у Kubernetes v1.32 цей підхід до DRA буде значно змінено. Код, повʼязаний з початковою реалізацією, буде видалено, залишаючи KEP #4381 як "нову" базову функціональність.

Рішення змінити поточний підхід виникло через його несумісність з автоматичним масштабуванням кластера, оскільки доступність ресурсів була непрозорою, ускладнюючи прийняття рішень як для Cluster Autoscaler, так і для контролерів. Нова додана модель Структурованих Параметрів замінює функціональність.

Це видалення дозволить Kubernetes обробляти нові апаратні вимоги та запити на ресурси більш передбачувано, обходячи складнощі зворотних викликів API до kube-apiserver.

Будь ласка, також перегляньте #3063 для отримання додаткової інформації.

Видалення API

Заплановано лише одне видалення API для Kubernetes v1.32:

  • Версія API flowcontrol.apiserver.k8s.io/v1beta3 для FlowSchema та PriorityLevelConfiguration була видалена. Щоб підготуватися до цього, ви можете відредагувати свої поточні маніфести та переписати клієнтське програмне забезпечення для використання версії API flowcontrol.apiserver.k8s.io/v1, доступної з v1.29. Всі поточні збережені обʼєкти доступні через новий API. Помітні зміни в flowcontrol.apiserver.k8s.io/v1beta3 включають те, що поле PriorityLevelConfiguration spec.limited.nominalConcurrencyShares стандартно встановлюється на 30, якщо не вказано явне значення 0, яке не змінюється на 30.

Для отримання додаткової інформації, будь ласка, зверніться до керівництва по застаріванню API.

Попередній огляд Kubernetes v1.32

Наступний список покращень, ймовірно, буде включений у випуск v1.32. Це не є зобовʼязанням, і вміст випуску може змінитися.

Ще більше покращень DRA!

У цьому випуску, як і в попередньому, проєкт Kubernetes продовжує пропонувати ряд покращень для Динамічного виділення ресурсів (DRA), ключового компонента системи управління ресурсами Kubernetes. Ці покращення спрямовані на підвищення гнучкості та ефективності виділення ресурсів для робочих навантажень, які потребують спеціалізованого обладнання, такого як GPU, FPGA та мережеві адаптери. Цей випуск вводить покращення, включаючи додавання статусу справності ресурсів у статус Pod, як описано в KEP #4680.

Додавання статусу справності ресурсів до статусу Pod

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

Windows повертається!

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

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

З переходом цього покращення у стан бета-версії, Kubernetes тепер дозволяє використовувати майже всі друковані символи ASCII (за винятком "=") в іменах змінних середовища. Ця зміна усуває обмеження, які раніше накладалися на імена змінних, сприяючи ширшому прийняттю Kubernetes, задовольняючи різні потреби застосунків. Функціональна можливість RelaxedEnvironmentVariableValidation буде стандартно увімкнена, надаючи користувачам можливість легко використовувати змінні середовища без суворих обмежень, підвищуючи гнучкість для розробників, які працюють з застосунками, такими як .NET Core, які потребують спеціальних символів у своїх конфігураціях.

Kubernetes буде обізнаним про поведінку LoadBalancer

KEP #1860 переходить до GA, вводячи поле ipMode для Service типу LoadBalancer, яке може бути встановлено на "VIP" або "Proxy". Це покращення спрямоване на покращення взаємодії балансувальників навантаження хмарних провайдерів з kube-proxy і є зміною, прозорою для кінцевого користувача. Поточна поведінка kube-proxy зберігається при використанні "VIP", де kube-proxy обробляє балансування навантаження. Використання "Proxy" призводить до того, що трафік надсилається безпосередньо до балансувальника навантаження, надаючи хмарним провайдерам більший контроль над залежністю від kube-proxy; це означає, що ви можете побачити покращення продуктивності вашого балансувальника навантаження для деяких хмарних провайдерів.

Повторна генерація імен для ресурсів

Це покращення покращує обробку конфліктів імен для ресурсів Kubernetes, створених з полем generateName. Раніше, якщо виникав конфлікт імен, API сервер повертав помилку 409 HTTP Conflict, і клієнти мали вручну повторювати запит. З цим оновленням, API сервер автоматично повторює генерацію нового імені до семи разів у разі конфлікту. Це значно знижує ймовірність зіткнення, забезпечуючи чітку генерацію до 1 мільйона імен з ймовірністю конфлікту менше 0,1%, забезпечуючи більшу стійкість для великих робочих навантажень.

Хочете дізнатися більше?

Нові функції та застарівання також оголошуються в примітках до випуску Kubernetes. Ми офіційно оголосимо, що нового в Kubernetes v1.32 як частину CHANGELOG для цього випуску.

Ви можете побачити оголошення про зміни в примітках до випуску для: