Попередній огляд Kubernetes v1.33
З наближенням релізу Kubernetes v1.33 проєкт Kubernetes продовжує розвиватися. Функції можуть застарівати вилучатись або замінятись для покращення загального стану проєкту. У цьому дописі описано деякі заплановані зміни для релізу v1.33, про які, на думку команди релізу, вам слід знати, щоб забезпечити безперебійну роботу вашого середовища Kubernetes та залишатися в курсі останніх розробок. Інформація нижче базується на поточному статусі релізу v1.33 і може змінитися до дати фінального випуску.
Процес видалення та застарівання API Kubernetes
Проєкт Kubernetes має добре задокументовану політику застарівання для функцій. Ця політика передбачає, що стабільні API можуть бути застарілими лише тоді, коли доступна новіша, стабільна версія того ж API, і що API мають мінімальний термін служби для кожного рівня стабільності. Застарілий API позначається для видалення в майбутніх релізах Kubernetes. Він продовжуватиме функціонувати до видалення (принаймні через рік після застарівання), але його використання призведе до показу попередження. Видалені API більше недоступні в поточній версії, і в цьому випадку вам потрібно перейти на використання заміни.
Загальнодоступні (GA) або стабільні версії API можуть бути позначені як застарілі, але не повинні бути видалені в межах основної версії Kubernetes.
Бета-версії або попередні версії API повинні підтримуватися протягом 3 релізів після застарівання.
Альфа-версії або експериментальні API можуть бути видалені в будь-якому релізі без попереднього повідомлення про застарівання; цей процес може стати відкликанням у випадках, коли вже існує інша реалізація для тієї ж функції.
Незалежно від того, чи API видаляється в результаті переходу функції з бета-версії до стабільної, чи тому, що цей API просто не досяг успіху, усі видалення відповідають цій політиці застарівання. Щоразу, коли API видаляється, варіанти міграції повідомляються в керівництві з застарівання.
Застарівання та видалення у Kubernetes v1.33
Застарівання стабільного API Endpoints
API EndpointSlices є стабільним з v1.21, що фактично замінило оригінальний API Endpoints. Хоча оригінальний API Endpoints був простим і зрозумілим, він також створював певні проблеми при масштабуванні до великої кількості мережевих точок доступу. API EndpointSlices запровадив нові функції, такі як двостекова мережа, що робить оригінальний API Endpoints готовим до застарівання.
Це застарівання впливає лише на тих, хто використовує API Endpoints безпосередньо з робочих навантажень або скриптів; таким користувачам слід перейти на використання EndpointSlices. У найближчі тижні буде опубліковано окремий допис у блозі з детальнішою інформацією про наслідки застарівання та плани міграції.
Детальніше дивіться в KEP-4974: Deprecate v1.Endpoints.
Видалення інформації про версію kube-proxy у статусі вузла
Після застарівання у v1.31, як зазначено в анонсі релізу, поле status.nodeInfo.kubeProxyVersion буде видалено у v1.33. Це поле встановлювалося kubelet, але його значення не завжди було точним. Оскільки воно було стандартно вимкнене з v1.31, у релізі v1.33 це поле буде повністю видалене.
Детальніше дивіться в KEP-4004: Deprecate status.nodeInfo.kubeProxyVersion field.
Видалення підтримки мережі хосту для Windows-подів
Мережа Windows-подів мала на меті досягти паритету функцій із Linux і забезпечити кращу щільність кластерів, дозволяючи контейнерам використовувати мережевий простір імен вузла. Оригінальна реалізація з’явилася як альфа у v1.26, але через несподівану поведінку containerd і наявність альтернативних рішень проєкт Kubernetes вирішив відкликати пов’язаний KEP. Очікується, що підтримка буде повністю видалена у v1.33.
Детальніше дивіться в KEP-3503: Host network support for Windows pods.
Основне покращення Kubernetes v1.33
Як автори цієї статті, ми обрали одне покращення як найважливішу зміну, яку варто відзначити!
Підтримка просторів імен користувача у Linux-подах
Одним із найстаріших відкритих KEP сьогодні є KEP-127, покращення безпеки подів за допомогою просторів імен користувача у Linux. Цей KEP був вперше відкритий наприкінці 2016 року, і після кількох ітерацій мав альфа-реліз у v1.25, початкову бета-версію у v1.30 (де він був стандартно вимкнений), і тепер має стати частиною v1.33, де функція буде стандартно доступна.
Ця підтримка не вплине на наявні поди, якщо ви вручну не вкажете pod.spec.hostUsers, щоб увімкнути її. Як зазначено в блозі про попередній огляд v1.30, це важливий етап для усунення вразливостей.
Детальніше дивіться в KEP-127: Support User Namespaces in pods.
Інші покращення Kubernetes v1.33
Зміна розміру ресурсів на місці для вертикального масштабування подів
Під час створення поду ви можете використовувати різні ресурси, такі як Deployment, StatefulSet тощо. Вимоги до масштабованості можуть вимагати горизонтального масштабування шляхом оновлення кількості реплік подів або вертикального масштабування шляхом оновлення ресурсів, виділених контейнерам поду. До цього покращення ресурси контейнера, визначені в spec поду, були незмінними, і оновлення будь-яких із цих деталей у шаблоні поду призводило до заміни поду.
Але що, якби ви могли динамічно оновлювати конфігурацію ресурсів для ваших поточних подів без їх перезапуску?
KEP-1287 був створений саме для того, щоб дозволити такі оновлення подів на місці. Це відкриває різні можливості вертикального масштабування для станів процесів без простоїв, безперебійного зменшення масштабу, коли трафік низький, і навіть виділення більших ресурсів під час запуску, які згодом зменшуються після завершення початкового налаштування. Це було випущено як альфа у v1.27 і очікується, що стане бета-версією у v1.33.
Детальніше дивіться в KEP-1287: In-Place Update of Pod Resources.
Статус пристрою ResourceClaim DRA переходить до бета-версії
Поле devices у статусі ResourceClaim, яке було вперше введено у релізі v1.32, ймовірно, перейде до бета-версії у v1.33. Це поле дозволяє драйверам повідомляти дані про статус пристрою, покращуючи як можливості спостереження, так і усунення несправностей.
Наприклад, повідомлення імені інтерфейсу, MAC-адреси та IP-адрес мережевих інтерфейсів у статусі ResourceClaim може значно допомогти в налаштуванні та керуванні мережевими службами, а також у налагодженні мережевих проблем. Ви можете прочитати більше про статус пристрою ResourceClaim у документі Dynamic Resource Allocation: ResourceClaim Device Status.
Також ви можете дізнатися більше про заплановане покращення в KEP-4817: DRA: Resource Claim Status with possible standardized network interface data.
Впорядковане видалення просторів імен
Цей KEP запроваджує більш структурований процес видалення просторів імен Kubernetes для забезпечення безпечного та детермінованого видалення ресурсів. Поточний напіввипадковий порядок видалення може створювати прогалини в безпеці або непередбачену поведінку, наприклад, поди, що залишаються після видалення пов’язаних із ними NetworkPolicies. Запроваджуючи структуровану послідовність видалення, яка враховує логічні та безпекові залежності, цей підхід забезпечує видалення подів перед іншими ресурсами. Дизайн покращує безпеку та надійність Kubernetes, зменшуючи ризики, пов’язані з недетермінованими видаленнями.
Детальніше дивіться в KEP-5080: Ordered namespace deletion.
Покращення для керування індексованими завданнями
Ці два KEP мають перейти до GA, щоб забезпечити кращу надійність обробки завдань, зокрема для індексованих завдань. KEP-3850 забезпечує обмеження відкату для кожного індексу для індексованих завдань, що дозволяє кожному індексу бути повністю незалежним від інших індексів. Також KEP-3998 розширює Job API, щоб визначити умови для успішного завершення індексованого завдання, якщо не всі індекси було успішно виконано.
Детальніше дивіться в KEP-3850: Backoff Limit Per Index For Indexed Jobs та KEP-3998: Job success/completion policy.
Хочете дізнатися більше?
Нові функції та застарівання також оголошуються в примітках до релізу Kubernetes. Ми офіційно оголосимо, що нового в Kubernetes v1.33 як частину CHANGELOG для цього релізу.
Реліз Kubernetes v1.33 заплановано на середу, 23 квітня 2025 року. Слідкуйте за оновленнями!
Ви також можете побачити оголошення про зміни в примітках до релізу для:
Долучайтеся
Найпростіший спосіб долучитися до Kubernetes – це приєднатися до однієї з багатьох груп спеціальних інтересів (SIG), які відповідають вашим інтересам. Хочете щось повідомити спільноті Kubernetes? Поділіться своєю думкою на нашій щотижневій зустрічі спільноти та через канали нижче. Дякуємо за ваші постійні відгуки та підтримку.
- Слідкуйте за нами на Bluesky @kubernetes.io для останніх оновлень
- Приєднуйтесь до обговорення спільноти на Discuss
- Приєднуйтесь до спільноти у Slack
- Публікуйте запитання (або відповідайте на запитання) на Server Fault або Stack Overflow
- Поділіться своєю історією про Kubernetes
- Читайте більше про те, що відбувається з Kubernetes в блозі
- Дізнайтеся більше про команду релізу Kubernetes