Ця стаття була опублікована більше року тому. Старіші статті можуть містити застарілу інформацію. Перевірте, чи інформація на цій сторінці не втратила актуальності з моменту її публікації.
Попередній огляд 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.
Вилучення підтримки мережі хосту для Podʼів Windows
Мережа Podʼів Windows мала на меті досягти паритету функцій із Linux і забезпечити кращу щільність кластерів, дозволяючи контейнерам використовувати мережевий простір імен вузла. Оригінальна реалізація зʼявилася як альфа у v1.26, але через несподівану поведінку containerd і наявність альтернативних рішень проєкт Kubernetes вирішив відкликати повʼязаний KEP. Очікується, що підтримка буде повністю вилучена у v1.33.
Детальніше дивіться в KEP-3503: Host network support for Windows pods.
Основне покращення Kubernetes v1.33
Як автори цієї статті, ми обрали одне покращення як найважливішу зміну, яку варто відзначити!
Підтримка просторів імен користувача у Podʼах Linux
Одним із найстаріших відкритих KEP сьогодні є KEP-127, покращення безпеки Podʼів за допомогою просторів імен користувача у Linux. Цей KEP був вперше відкритий наприкінці 2016 року, і після кількох ітерацій мав альфа-випуск у v1.25, початкову бета-версію у v1.30 (де він був типово вимкнений), і тепер має стати частиною v1.33, де функція буде типово доступна.
Ця підтримка не вплине на наявні Podʼи, якщо ви вручну не вкажете pod.spec.hostUsers, щоб увімкнути її. Як зазначено в дописі з попереднім оглядом v1.30, це важливий етап для усунення вразливостей.
Детальніше дивіться в KEP-127: Support User Namespaces in pods.
Вибрані інші покращення Kubernetes v1.33
Наведений нижче список удосконалень, ймовірно, буде включений до наступного випуску v1.33. Це не є зобовʼязанням, і вміст випуску може змінитися.
Зміна розміру ресурсів на місці для вертикального масштабування Podʼів
Під час створення Podʼа ви можете використовувати різні ресурси, такі як Deployment, StatefulSet тощо. Вимоги до масштабованості можуть вимагати горизонтального масштабування шляхом оновлення кількості реплік Podʼів або вертикального масштабування шляхом оновлення ресурсів, виділених контейнерам Podʼа. До цього удосконалення ресурси контейнера, визначені в spec Podʼа, були незмінними, і оновлення будь-яких із цих деталей у шаблоні Podʼа призводило до заміни Podʼа.
Але що, якби ви могли динамічно оновлювати конфігурацію ресурсів для ваших наявних Podʼів без їх перезапуску?
KEP-1287 створено саме для того, щоб дозволити такі оновлення Podʼів на місці. Це відкриває різні можливості вертикального збільшення масштабу для процесів зі станом без простоїв, безперебійного зменшення масштабу, коли трафік низький, і навіть виділення більших ресурсів під час запуску, які згодом зменшуються після завершення початкового налаштування. Це було випущено як альфа у v1.27 і очікується, що стане бета-версією у v1.33.
Детальніше дивіться в KEP-1287: In-Place Update of Pod Resources.
Статус пристрою ResourceClaim у DRA переходить до бета-версії
Поле devices у status ResourceClaim, яке було вперше введено у випуску v1.32, ймовірно, перейде до бета-версії у v1.33. Це поле дозволяє драйверам повідомляти дані про статус пристрою, покращуючи як можливості спостереження, так і усунення несправностей.
Наприклад, повідомлення імені інтерфейсу, MAC-адреси та IP-адрес мережевих інтерфейсів у статусі ResourceClaim може значно допомогти в налаштуванні та керуванні мережевими службами, а також у налагодженні мережевих проблем. Ви можете прочитати більше про статус пристрою ResourceClaim у документі Динамічне виділення ресурсів: статус пристрою ResourceClaim.
Також ви можете дізнатися більше про заплановане удосконалення в KEP-4817: DRA: Resource Claim Status with possible standardized network interface data.
Впорядковане видалення просторів імен
Цей KEP запроваджує більш структурований процес видалення просторів імен Kubernetes для забезпечення безпечного та детермінованого видалення ресурсів. Поточний напіввипадковий порядок видалення може створювати прогалини в безпеці або непередбачену поведінку, наприклад, Podʼи, що залишаються після видалення повʼязаних із ними NetworkPolicies. Запроваджуючи структуровану послідовність видалення, яка враховує логічні та безпекові залежності, цей підхід забезпечує видалення Podʼів перед іншими ресурсами. Дизайн покращує безпеку та надійність Kubernetes, зменшуючи ризики, повʼязані з недетермінованими видаленнями.
Детальніше дивіться в KEP-5080: Ordered namespace deletion.
Удосконалення керування індексованими завданнями
Ці два KEP мають перейти до GA, щоб забезпечити кращу надійність обробки Job, зокрема для Indexed Job. KEP-3850 забезпечує обмеження кількості повторних спроб для кожного індексу для Indexed Job, що дозволяє кожному індексу бути повністю незалежним від інших індексів. Також KEP-3998 розширює Job API, щоб визначити умови для позначення Indexed Job як успішно завершеного, коли не всі індекси було успішно виконано.
Детальніше дивіться в 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