Ця стаття була опублікована більше року тому. Старіші статті можуть містити застарілу інформацію. Перевірте, чи інформація на цій сторінці не втратила актуальності з моменту її публікації.
Попередній огляд Kubernetes v1.32
З наближенням дати випуску 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, так і для контролерів. Нещодавно додана модель структурованих параметрів (Structured Parameters) замінює цю функціональність.
Це вилучення дозволить Kubernetes обробляти нові апаратні вимоги та заявки на ресурси більш передбачувано, оминаючи складнощі постійного обміну викликами API з kube-apiserver.
Будь ласка, також перегляньте тікет удосконалення #3063, щоб дізнатися більше.
Вилучення API
Заплановано лише одне вилучення API для Kubernetes v1.32:
- Версія API
flowcontrol.apiserver.k8s.io/v1beta3для FlowSchema та PriorityLevelConfiguration була вилучена. Щоб підготуватися до цього, ви можете відредагувати свої поточні маніфести та переписати клієнтське програмне забезпечення для використання версіїflowcontrol.apiserver.k8s.io/v1 API, доступної з v1.29. Всі поточні збережені обʼєкти доступні через новий API. Помітні зміни вflowcontrol.apiserver.k8s.io/v1beta3включають те, що полеspec.limited.nominalConcurrencySharesу PriorityLevelConfiguration типово встановлюється на 30 лише тоді, коли його не вказано, а явно вказане значення 0 не змінюється на 30.
Для отримання додаткової інформації, будь ласка, зверніться до керівництва із застарівання API.
Попередній огляд Kubernetes v1.32
Наступний список удосконалень, ймовірно, буде включений у випуск v1.32. Це не є зобовʼязанням, і вміст випуску може змінитися.
Ще більше удосконалень DRA!
У цьому випуску, як і в попередньому, проєкт Kubernetes продовжує пропонувати низку удосконалень для динамічного виділення ресурсів (DRA), ключового компонента системи управління ресурсами Kubernetes. Ці удосконалення спрямовані на підвищення гнучкості та ефективності виділення ресурсів для робочих навантажень, які потребують спеціалізованого обладнання, такого як GPU, FPGA та мережеві адаптери. Цей випуск вводить покращення, включаючи додавання статусу справності ресурсів до статусу Podʼа, як описано в KEP #4680.
Додавання статусу справності ресурсів до статусу Podʼа
Важко дізнатися, коли Pod використовує пристрій, який вийшов з ладу або тимчасово несправний. KEP #4680 пропонує показувати справність пристрою через status 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 з type: 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 для цього випуску.
Ви можете побачити оголошення про зміни в примітках до випуску для: