Kubernetes v1.33: Octarine

Автор Kubernetes v1.33 Release Team |

Редактори: Agustina Barbetta, Aakanksha Bhende, Udi Hofesh, Ryota Sawada, Sneha Yadav

Як і у попередніх випусках, у Kubernetes v1.33 представлено нові стабільні, бета та альфа-версії. Послідовний випуск високоякісних випусків підкреслює силу нашого циклу розробки та активну підтримку нашої спільноти.

Цей випуск складається з 64 покращень. З них 18 отримали статус Stable, 20 переходять до бета-версії, 24 — до альфа-версії, а 2 функції вважаються застарілими або вилученими.

У цьому випуску також є кілька помітних застарілостей і вилучень; обовʼязково прочитайте про них, якщо ви вже використовуєте старішу версію Kubernetes.

Тема для Kubernetes v1.33 — Октарин: Колір магії1, натхненням для якої стала серія Дискосвіт Террі Пратчетта. Цей випуск підкреслює магію відкритого вихідного коду2, яку Kubernetes використовує в усій екосистемі.

Якщо ви знайомі зі світом Дискосвіту, ви можете впізнати маленького болотного дракона, що сидить на вежі Небаченого Університету, дивлячись на місяць Кубернетес над містом Анх-Морпорк з 64 зірками3 на задньому плані.

Оскільки Kubernetes вступає у своє друге десятиліття, ми відзначаємо майстерність його супровідників, допитливість нових учасників та дух співпраці, який живить проєкт. Випуск v1.33 є нагадуванням про те, що, як писав Пратчетт, «це все одно магія, навіть якщо ви знаєте, як це робиться». Навіть якщо ви знаєте всі тонкощі кодової бази Kubernetes, відійшовши на крок назад в кінці циклу випуску, ви зрозумієте, що Kubernetes залишається чарівним.

Kubernetes v1.33 — це свідчення незмінної сили інновацій з відкритим вихідним кодом, де сотні учасників3 з усього світу працюють разом, щоб створити щось справді надзвичайне. За кожною новою функцією стоїть робота спільноти Kubernetes над підтримкою та вдосконаленням проєкту, гарантуючи, що він залишається безпечним, надійним та випускається вчасно. Кожен реліз спирається на інший, створюючи щось більше, ніж ми могли б досягти поодинці.

1. Октарин — це міфічний восьмий колір, який бачать лише ті, хто має певний стосунок до таємничого: маги, чаклунки та, звісно, коти. І іноді хтось, хто занадто довго витріщається на правила IPtable.
2. Будь-яка достатньо прогресивна технологія не відрізняється від магії...?
3. Це не випадково, що 64 KEP (Kubernetes Enhancement Proposals) також включені в v1.33.
4. Див. розділ «Швидкість проєкту» для версії 1.33 🚀

У центрі уваги ключові оновлення

Kubernetes v1.33 містить багато нових можливостей та покращень. Ось кілька особливо важливих оновлень, на які команда розробників хотіла б звернути увагу!

Stable: контейнери Sidecar

Шаблон використання sidecar передбачає розгортання окремих допоміжних контейнерів для роботи з додатковими можливостями в таких сферах, як мережа, ведення журналів і збір показників. У версії 1.33 контейнери Sidecar переходять у статус Stable.

Kubernetes впроваджує sidecar як спеціальний клас контейнерів ініціалізації що мають restartPolicy: Always, це гарантує, що sidecars запускаються перед контейнерами застосунків, залишаються запущеними протягом усього життєвого циклу podʼа і автоматично завершують свою роботу після завершення роботи основних контейнерів.

Крім того, sidecarʼи можуть використовувати проби (запуску, готовності, життєздатності) для повідомлення про свій робочий стан, а їхні показники Out-Of-Memory (OOM) узгоджуються з основними контейнерами, щоб запобігти передчасному завершенню роботи під тиском обмеження використання памʼяті.

Щоб дізнатися більше, читайте Контейнери Sidecar.

Ця робота була виконана в рамках KEP-753: Sidecar Containers під керівництвом SIG Node.

Beta: Зміна розміру ресурсів на місці для вертикального масштабування Podʼів

Робочі навантаження можна визначити за допомогою API, таких як Deployment, StatefulSet тощо. Вони описують шаблон для Podʼів, які мають бути запущені, включаючи ресурси памʼяті та процесора, а також кількість реплік Podʼів, які мають бути запущені. Робочі навантаження можна масштабувати горизонтально, оновлюючи кількість реплік Podʼів, або вертикально, оновлюючи ресурси, необхідні в контейнері (контейнерах) Podʼів. До цього вдосконалення ресурси контейнера, визначені в spec, були незмінними, і оновлення будь-якої з цих деталей у шаблоні Pod призводило до заміни Podʼа.

Але що, якби ви могли динамічно оновлювати конфігурацію ресурсів для наявних Podʼів, не перезапускаючи їх?

KEP-1287 було створено саме для того, щоб дозволити такі оновлення на місці. Він був випущений як альфа-версія у версії v1.27, а у версії v1.33 перейшов до бета-версії. Це відкриває різні можливості для вертикального масштабування процесів зі станом без простоїв, плавного зменшення масштабу, коли трафік низький, і навіть виділення більших ресурсів під час запуску, які потім можуть бути зменшені після завершення початкового налаштування.

Цю роботу було виконано в рамках KEP-1287: In-Place Update of Pod Resources під керівництвом SIG Node та SIG Autoscaling.

Alpha: Новий параметр конфігурації kubectl за допомогою .kuberc для налаштувань користувача

У версії 1.33 у kubectl зʼявилася нова альфа-версія з опціональним конфігураційним файлом .kuberc для налаштувань користувача. Цей файл може містити аліаси та перевизначення kubectl (наприклад, стандартне використання server-side apply), водночас залишаючи облікові дані кластера та інформацію про хост у kubeconfig. Таке розділення дозволяє використовувати однакові параметри взаємодії з kubectl, незалежно від цільового кластера і використовуваного kubeconfig.

Щоб увімкнути цю альфа-версію, користувачі можуть встановити змінну середовища KUBECTL_KUBERC=true і створити файл конфігурації .kuberc. Зазвичай kubectl шукає цей файл у ~/.kube/kuberc. Ви також можете вказати альтернативне розташування за допомогою прапорця --kuberc, наприклад: kubectl --kuberc /var/kube/rc.

Цю роботу було виконано у рамках KEP-3104: Відокремлення налаштувань користувача kubectl від конфігів кластера під керівництвом SIG CLI.

Функції, що переходять до статусу Stable

Це добірка деяких поліпшень, які тепер мають статус стабільних після релізу v1.33.

Ліміти повторних спроб для індексів в Індексованих Завданнях (Indexed Job)

У цьому випуску реалізовано функцію, яка дозволяє встановлювати ліміти повторних спроб на основі кожного індексу для індексованих завдань. Традиційно параметр backoffLimit у Завданнях Kubernetes задає кількість повторних спроб, після яких завдання вважається невдалим. Це вдосконалення дозволяє кожному індексу в Індексованому Завданні мати власний ліміт повторних спроб, забезпечуючи більш детальний контроль над поведінкою повторних спроб для окремих завдань. Це гарантує, що збій певних індексів не призведе до передчасного завершення всього Завдання, дозволяючи іншим індексам продовжувати обробку незалежно.

Ця робота була виконана в рамках KEP-3850: Backoff Limit Per Index For Indexed Jobs під керівництвом SIG Apps.

Політика успіху Job

Використовуючи .spec.successPolicy, користувачі можуть вказати, які індекси завдань мають бути успішними (succeededIndexes), скільки завдань мають бути успішними (succeededCount), або комбінацію обох параметрів. Ця функція корисна для різних робочих навантажень, включаючи симуляції, де достатньо часткового завершення, і моделі «лідер-працівник», де тільки успіх лідера визначає загальний результат роботи.

Ця робота була виконана в рамках KEP-3998: Job success/completion policy під керівництвом SIG Apps.

Покращення безпеки токенів повʼязаних ServiceAccount

Це вдосконалення впровадило такі функції, як включення унікального ідентифікатора токена (наприклад, JWT ID Claim, також відомий як JTI) та інформації про вузол в токенах, що дозволяє більш точно перевіряти та проводити аудит. Крім того, він підтримує обмеження для конкретних вузлів, гарантуючи, що токени можуть бути використані тільки на визначених вузлах, тим самим знижуючи ризик зловживання токенами і потенційних порушень безпеки. Ці покращення, які тепер є загальнодоступними, мають на меті покращити загальний стан безпеки токенів службових облікових записів у кластерах Kubernetes.

Ця робота була виконана в рамках KEP-4193: Bound service account token improvements під керівництвом SIG Auth.

Підтримка субресурсів у kubectl

Аргумент --subresource тепер є загальнодоступним для таких команд kubectl, як get, patch, edit, apply і replace, що дозволяє користувачам отримувати та оновлювати субресурси для всіх ресурсів, які їх підтримують. Щоб дізнатися більше про підтримувані субресурси, відвідайте довідник kubectl.

Цю роботу було виконано у рамках KEP-2590: Add subresource support to kubectl під керівництвом SIG CLI.

Кілька CIDR Сервісів

Це покращення запровадило нову реалізацію логіки розподілу IP-адрес Service. У всьому кластері кожен сервіс типу type: ClusterIP повинен мати унікальну IP-адресу, призначену йому. Спроба створити Сервіс з певною кластерною IP-адресою, яку вже було призначено, призведе до помилки. Оновлена логіка розподільника IP-адрес використовує два нових стабільних обʼєкти API: ServiceCIDR і IPAddress. Тепер ці API є загальнодоступними і дозволяють адміністраторам кластерів динамічно збільшувати кількість IP-адрес, доступних для `type: ClusterIP' (шляхом створення нових обʼєктів ServiceCIDR).

Ця робота була виконана в рамках KEP-1880: Multiple Service CIDRs під керівництвом SIG Network.

Бекенд nftables для kube-proxy

Бекенд nftables для kube-proxy тепер стабільний, додано нову реалізацію, яка значно покращує продуктивність і масштабованість для реалізації Сервісів у кластерах Kubernetes. З міркувань сумісності, iptables залишається стандартним на вузлах Linux. Ознайомтеся з посібником з міграції, якщо ви хочете спробувати.

Ця робота була виконана в рамках KEP-3866: nftables kube-proxy backend під керівництвом SIG Network.

Маршрутизація з урахуванням топології за допомогою trafficDistribution: PreferClose

У цьому випуску маршрутизація з урахуванням топології та розподілення трафіку переходить до рівня GA, що дозволить нам оптимізувати службовий трафік у багатозонних кластерах. Підказки з урахуванням топології в EndpointSlices дозволять таким компонентам, як kube-proxy, визначати пріоритети маршрутизації трафіку до точок доступу в межах однієї зони, тим самим зменшуючи затримки і витрати на передачу даних між зонами. На основі цього до специфікації Service додано поле trafficDistribution, а опція PreferClose спрямовує трафік до найближчих доступних точок доступу, виходячи з топології мережі. Така конфігурація підвищує продуктивність та економічну ефективність за рахунок мінімізації міжзонового звʼязку.

Ця робота була виконана в рамках KEP-4444: Traffic Distribution for Services та KEP-2433: Topology Aware Routing під керівництвом SIG Network.

Опції для відхилення не узгодженого з SMT навантаження

Ця функція додає параметри політики до CPU Manager, що дозволяє відхиляти робочі навантаження, які не відповідають конфігурації одночасної багатопоточності (Simultaneous Multithreading, SMT). Це вдосконалення, яке тепер є загальнодоступним, гарантує, що коли pod запитує ексклюзивне використання ядер процесора, диспетчер процесорів може примусово розподіляти цілі пари ядер (що складаються з основного і дочірнього потоків) на системах з підтримкою SMT, таким чином запобігаючи сценаріям, коли робочі навантаження використовують ресурси процесора у непередбачуваний спосіб.

Цю роботу було виконано у рамках KEP-2625: node: cpumanager: add options to reject non SMT-aligned workloads під керівництвом SIG Node.

Визначення спорідненості або неспорідненості Pod за допомогою matchLabelKeys та mismatchLabelKeys

Поля matchLabelKeys і mismatchLabelKeys доступні у термінах спорідненості Pod, що дозволяє користувачам точно контролювати область, в якій очікується співіснування Podʼів (Affinity) чи ні (AntiAffinity). Ці нові стабільні опції доповнюють наявний механізм labelSelector. Поля спорідненості полегшують планування універсальних циклічних оновлень, а також ізоляцію сервісів, керованих інструментами або контролерами на основі глобальних конфігурацій.

Цю роботу було виконано в рамках проекту KEP-3633: Introduce MatchLabelKeys to Pod Affinity and Pod Anti Affinity під керівництвом SIG Scheduling.

Врахування позначок taint та toleration при обчисленні відхилення поширення топології Pod

Це покращило PodTopologySpread, додавши два поля: nodeAffinityPolicy та nodeTaintsPolicy. Ці поля дозволяють користувачам вказати, чи слід враховувати правила спорідненості вузлів та плями вузлів при обчисленні розподілу podʼів між вузлами. Стандартно nodeAffinityPolicy має значення Honor, що означає, що до розрахунку розподілу включаються лише вузли, які відповідають правилам спорідненості або селектору вузла. Значення nodeTaintsPolicy стандартно дорівнює Ignore, що вказує на те, що заплямованість вузлів не враховується, якщо це не вказано. Це покращення забезпечує кращий контроль за розміщенням podʼів, гарантуючи, що podʼи будуть заплановані на вузлах, які відповідають вимогам спорідненості та толерантності щодо заплямованості, таким чином запобігаючи сценаріям, коли podʼи залишаються нерозподіленими через незадовільнення обмежень.

Ця робота була виконана у рамках KEP-3094: Take taint/tolerances into consideration when calculating PodTopologySpread skew під керівництвом SIG Scheduling.

Заповнювачі тома

Після випуску бета-версії у v1.24, заповнювачі томів стали доступними у GA у v1.33. Ця нова стабільна функція дозволяє користувачам попередньо заповнювати томи даними з різних джерел, а не лише з клонів PersistentVolumeClaim (PVC) або знімків томів. Механізм ґрунтується на полі dataSourceRef у запиті PersistentVolumeClaim. Це поле забезпечує більшу гнучкість, ніж поточне поле dataSource, і дозволяє використовувати власні ресурси як джерела даних.

Спеціальний контролер, volume-data-source-validator, перевіряє ці посилання на джерела даних, разом з новим стабільним CustomResourceDefinition (CRD) для API типу VolumePopulator. API VolumePopulator дозволяє контролерам заповнвачів тому реєструвати типи джерел даних, які вони підтримують. Вам потрібно налаштувати ваш кластер з відповідним CRD, щоб користуватися заповнювачами томів.

Цю роботу було виконано в рамках KEP-1495: Generic data populators під керівництвом SIG Storage.

Завжди дотримуватися політики повторного використання PersistentVolume

Це вдосконалення вирішило проблему, коли політика повторного використання постійних томів (Persistent Volume, PV) не завжди виконується, що призводить до потенційних витоків ресурсів сховища. Зокрема, якщо постійний том видаляється раніше, ніж повʼязана з ним заявка на постійний том (Persistent Volume Claim, PVC), політика повторного використання "Delete" може не виконуватися, залишаючи базові ресурси сховища недоторканими. Щоб запобігти цьому, Kubernetes тепер встановлює завершувачі на відповідні PV, гарантуючи, що політика повторного використання буде застосована незалежно від послідовності видалення. Це покращення запобігає ненавмисному збереженню ресурсів сховища та підтримує узгодженість в управлінні життєвим циклом PV.

Ця робота була виконана в рамках проекту KEP-2644: Always Honor PersistentVolume Reclaim Policy під керівництвом SIG Storage.

Нові можливості у Бета

Це добірка деяких покращень, які зараз є бета-версією після випуску v1.33._.

Підтримка Прямого Повернення Сервісу (DSR, Direct Service Return) у Windows kube-proxy

DSR забезпечує оптимізацію продуктивності, дозволяючи зворотному трафіку, що проходить через балансувальники навантаження, оминати балансувальник навантаження і відповідати безпосередньо клієнту; зменшуючи навантаження на балансувальник навантаження, а також загальну затримку. Для отримання інформації про DSR в Windows, прочитайте Direct Server Return (DSR) in a nutshell.

Підтримка DSR, вперше представлена в версії 1.14, була доведена SIG Windows до бета-версії в рамках KEP-5100: Support for Direct Service Return (DSR) and overlay networking in Windows kube-proxy.

Підтримка структурованих параметрів

Хоча підтримка структурованих параметрів залишається бета-версією Kubernetes v1.33, ця основна частина динамічного розподілу ресурсів (DRA) зазнала значних покращень. Нова версія v1beta2 спрощує API resource.k8s.io, і звичайні користувачі з роллю edit кластера з простором імен тепер можуть використовувати DRA.

У kubelet додано підтримку безперебійного оновлення, що дозволяє драйверам, розгорнутим як DaemonSets, використовувати механізм постійного оновлення. Для реалізацій DRA це запобігає видаленню і повторному створенню ResourceSlices, дозволяючи їм залишатися незмінними під час оновлень. Крім того, було введено 30-секундний пільговий період перед очищенням kubelet після скасування реєстрації драйвера, що забезпечує кращу підтримку для драйверів, які не користуються механізмом rolling updates.

Ця робота була виконана в рамках KEP-4381: DRA: структуровані параметри робочою групою з управління пристроями, до складу якої входять представники SIG Node, SIG Scheduling і SIG Autoscaling.

Динамічний розподіл ресурсів (DRA) для мережевих інтерфейсів

Стандартизоване звітування про дані мережевих інтерфейсів за допомогою DRA, запроваджене у версії 1.32, перейшло до бета-версії у версії 1.33. Це уможливлює більш природну інтеграцію з мережею Kubernetes, спрощуючи розробку та керування мережевими пристроями. Раніше про це було написано у блозі з анонсом випуску v1.32.

Ця робота була виконана в рамках KEP-4817: DRA: Resource Claim Status with possible standardized network interface data під керівництвом SIG Network, SIG Node та WG Device Management.

Обробка незапланованих podʼів раніше, коли планувальник не має жодного pod у activeQ

Ця функція покращує поведінку планування черги. За лаштунками планувальник досягає цього, вибираючи з backoffQ pods, які не було відкладено через помилки, коли activeQ порожній. Раніше планувальник простоював, навіть якщо activeQ було порожнім; це вдосконалення покращує ефективність планування, запобігаючи цьому.

Ця робота була виконана у рамках KEP-5142: Pop pod from backoffQ when activeQ is empty під керівництвом SIG Scheduling.

Асинхронне випередження у планувальнику Kubernetes

Випередження гарантує, що більш пріоритетні podʼи отримають необхідні їм ресурси, виселивши менш пріоритетні. Асинхронне випередження, представлене у версії 1.32 як альфа-версія, у версії 1.33 перейшло у бета-версію. Завдяки цьому вдосконаленню, важкі операції, такі як виклики API для видалення podʼів, обробляються паралельно, що дозволяє планувальнику продовжувати планувати інші podʼи без затримок. Це покращення особливо корисне для кластерів з високим рівнем відтоку Podʼів або частими збоями в плануванні, забезпечуючи більш ефективний та стійкий процес планування.

Ця робота була виконана в рамках KEP-4832: Asynchronous preemption in the scheduler під керівництвом SIG Scheduling.

ClusterTrustBundle

ClusterTrustBundle, кластерний ресурс, призначений для зберігання довірчих якорів X.509 (кореневих сертифікатів), перейшов у бета-версію 1.33. Цей API полегшує підписантам кластерних сертифікатів публікацію та передачу довірчих якорів X.509 кластерним робочим навантаженням.

Ця робота була виконана в рамках KEP-3257: ClusterTrustBundles (раніше Trust Anchor Sets) під керівництвом SIG Auth.

Детальний контроль SupplementalGroups

Вперше зʼявившись у v1.31, ця можливість перейшла у бета-версію у v1.33 і тепер є стандартно увімкненою. За умови, що у вашому кластері увімкнено функціональну можливість SupplementalGroupsPolicy, поле SupplementalGroupsPolicy у securityContext у Pod підтримує дві політики: стандартна політика Merge підтримує зворотну сумісність, обʼєднуючи вказані групи з групами з файлу /etc/group образу контейнера, в той час як нова політика Strict застосовується тільки до явно визначених груп.

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

Ця робота була виконана в рамках KEP-3619: Fine-grained SupplementalGroups control під керівництвом SIG Node.

Підтримка монтування образів як томів

Підтримка використання образів Open Container Initiative (OCI) як томів у Podʼах, що зʼявилася у версії 1.31, перейшла у стан бета-версії. Ця функція дозволяє користувачам вказувати посилання на образ як том у Pod, а також повторно використовувати його як монтування томів у контейнерах. Це відкриває можливість пакувати дані тома окремо і розподіляти їх між контейнерами в Pod, не включаючи їх до основного образу, тим самим зменшуючи вразливості і спрощуючи створення образів.

Ця робота була виконана в рамках KEP-4639: VolumeSource: OCI Artifact and/or Image під керівництвом SIG Node та SIG Storage.

Підтримка просторів імен користувачів у Linux Podʼах

Одним із найстаріших відкритих KEP на момент написання цієї статті є KEP-127, Покращення безпеки Pod за допомогою використання Просторів імен користувачів Linux для Pods. Цей KEP був вперше відкритий наприкінці 2016 року і після декількох ітерацій отримав альфа-реліз у версії 1.25, початкову бета-версію у версії 1.30 (де він був стандартно вимкнений), а у версії 1.33 перейшов у режим стандартно увімкненої бета-версії.

Ця підтримка не вплине на наявні Podʼи, якщо ви вручну не вкажете pod.spec.hostUsers, щоб увімкнути її. Як зазначено у v1.30 sneak peek blog, це важлива віха для усунення вразливостей.

Ця робота була виконана в рамках KEP-127: Support User Namespaces in pods під керівництвом SIG Node.

Опція procMount для Pod

Параметр procMount, представлений як альфа-версія у версії 1.12 і стандартно вимкнений у бета-версії 1.31, у версії 1.33 став увімкненим у бета-версії 1.33. Це вдосконалення покращує ізоляцію Pod, дозволяючи користувачам тонко налаштовувати доступ до файлової системи /proc. Зокрема, воно додає поле до securityContext, яке дозволяє перевизначити стандартну поведінку маскування та позначення певних шляхів до /proc як таких, що доступні лише для читання. Це особливо корисно у випадках, коли користувачі хочуть запускати непривілейовані контейнери всередині Kubernetes Pod з використанням просторів імен користувачів. Зазвичай, середовище виконання контейнера (через реалізацію CRI) запускає зовнішній контейнер із суворими параметрами монтування /proc. Однак, для успішного запуску вкладених контейнерів з непривілейованим Pod, користувачам потрібен механізм для послаблення цих стандартних налаштувань, і ця функція надає саме це.

Цю роботу було виконано у рамках проекту KEP-4265: add ProcMount option під керівництвом SIG Node.

Політика CPUManager для розподілу CPU між вузлами NUMA

Цей параметр додає нову опцію політики для CPU Manager, яка дозволяє розподіляти CPU між вузлами з нерівномірним доступом до памʼяті (NUMA, Non-Uniform Memory Access), замість того, щоб концентрувати їх на одному вузлі. Він оптимізує розподіл ресурсів CPU, балансуючи робочі навантаження між декількома вузлами NUMA, тим самим покращуючи продуктивність і використання ресурсів у багатопроцесорних системах з NUMA.

Цю роботу було виконано у рамках KEP-2902: Add a CPUManager policy option to distribute CPUs between NUMA nodes instead of packing them під керівництвом SIG Node.

Нуль-секундний сон для хуків PreStop контейнера

У Kubernetes 1.29 було введено дію Sleep для хука життєвого циклу preStop у Podʼах, яка дозволяє контейнерам призупиняти роботу на певний час перед завершенням. Це забезпечує простий спосіб затримки вимкнення контейнера, полегшуючи виконання таких завдань, як очищення зʼєднань або операцій очищення.

Дія Sleep у хуку preStop тепер може приймати нульову тривалість як бета-версію. Це дає змогу визначати хук preStop без затримки, що є корисним у випадках, коли хук preStop потрібен, але затримка не бажана.

Ця робота була виконана в рамках KEP-3960: Introducing Sleep Action for PreStop Hook та KEP-4818: Allow zero value for Sleep Action of PreStop Hook під керівництвом SIG Node.

Внутрішній інструментарій для декларативної валідації нативних типів Kubernetes

За лаштунками, внутрішні механізми Kubernetes починають використовувати новий механізм валідації обʼєктів та змін до обʼєктів. У Kubernetes v1.33 представлено внутрішній інструмент validation-gen, який учасники Kubernetes використовують для створення декларативних правил валідації. Загальна мета полягає у підвищенні надійності та зручності підтримки валідації API, надаючи розробникам можливість декларативно вказувати обмеження валідації, зменшуючи кількість помилок ручного кодування та забезпечуючи узгодженість у кодовій базі.

Ця робота була виконана у рамках проекту KEP-5073: Declarative Validation Of Kubernetes Native Types With validation-gen під керівництвом SIG API Machinery.

Нові можливості в альфа-версії

Це добірка деяких покращень, які тепер доступні у альфа-версії після випуску v1.33.

Налаштовуване допустиме відхилення для HorizontalPodAutoscalers

Ця функція вводить настроюване відхилення для HorizontalPodAutoscalers, яке помʼякшує реакцію масштабування на невеликі зміни метрики.

Цю роботу було виконано як частину KEP-4951: Configurable tolerance for Horizontal Pod Autoscalers під керівництвом SIG Autoscaling.

Настроювана затримка перезапуску контейнера

Представлена у версії 1.32 як alpha1, ця функція надає набір конфігурацій на рівні kubelet, які дозволяють налаштування способу обробки CrashLoopBackOff.

Цю роботу було виконано у рамках KEP-4603: Tune CrashLoopBackOff під керівництвом SIG Node.

Власні сигнали зупинки контейнера

До версії Kubernetes 1.33 сигнали зупинки можна було встановити лише у визначенні образу контейнера (наприклад, за допомогою конфігураційного поля StopSignal у метаданих образу). Якщо ви хочете змінити поведінку завершення, вам потрібно створити власний образ контейнера. Увімкнувши (альфа-версію) ContainerStopSignals у Kubernetes v1.33, ви можете визначати власні сигнали зупинки безпосередньо у специфікаціях Pod. Вони визначаються у полі lifecycle.stopSignal контейнера і вимагають наявності поля spec.os.name у специфікації Pod. Якщо його не вказано, контейнери повертаються до визначеного образом сигналу зупинки (якщо він присутній) або до стандартного сигналу виконання контейнера (зазвичай це SIGTERM для Linux).

Цю роботу було виконано у рамках KEP-4960: Сигнали зупинки контейнерів під керівництвом SIG Node.

Покращення DRA!

У Kubernetes v1.33 продовжено розробку динамічного розподілу ресурсів (DRA) з функціями, призначеними для сучасних складних інфраструктур. DRA — це інтерфейс API для запиту і розподілу ресурсів між podʼами і контейнерами всередині podʼів. Зазвичай такими ресурсами є пристрої, такі як графічні процесори, FPGA та мережеві адаптери.

Нижче перераховані всі можливості альфа-версії DRA, представлені у версії 1.33:

  • Подібно до забруднень Вузлів, увімкнувши функціональну можливість DRADeviceTaints, пристрої підтримують taints та tolerations. Адміністратор або компонент панелі управління може позначити пристрої, щоб обмежити їхнє використання. Планування podʼів, які залежать від цих пристроїв, може бути призупинено, поки існує taint, і/або podʼи, які використовують пристрій з taint, можуть бути виселені.
  • Увімкнувши функціональну можливість DRAPrioritizedList, DeviceRequests отримують нове поле, з назвою firstAvailable. Це поле є впорядкованим списком, який дозволяє користувачеві вказати, що запит може бути задоволено різними способами, зокрема не виділяти нічого, якщо певне обладнання недоступне.
  • З активованою функціональною можливістю DRAAdminAccess лише користувачі, які мають право створювати обʼєкти ResourceClaim або ResourceClaimTemplate у просторах імен, позначених resource.k8s.io/admin-access: "true" можуть використовувати поле adminAccess. Це гарантує, що користувачі, які не мають прав адміністратора, не зможуть зловживати функцією adminAccess.
  • Починаючи з версії 1.31 стало можливим використовувати розділи пристроїв, але виробникам доводилося попередньо розбивати пристрої на розділи і оголошувати про це відповідним чином. Увімкнувши функціональну можливість DRAPartitionableDevices у версії 1.33, постачальники пристроїв можуть оголошувати декілька розділів, у тому числі ті, що перетинаються. Планувальник Kubernetes вибере розділ на основі запитів робочого навантаження і запобігатиме одночасному виділенню конфліктуючих розділів. Ця функція дає постачальникам можливість динамічно створювати розділи під час їх виділення. Виділення та динамічне створення розділів відбувається автоматично і є прозорим для користувачів, що сприяє кращому використанню ресурсів.

Ці елементи не матимуть ефекту, якщо ви не увімкнете функціональну можливість DynamicResourceAllocation.

Цю роботу було виконано в рамках KEP-5055: DRA: device taints and tolerations, KEP-4816: DRA: Prioritized Alternatives in Device Requests, KEP-5018: DRA: AdminAccess for ResourceClaims and ResourceClaimsTemplates та KEP-4815: DRA: Add support for partitionable devices, під керівництвом SIG Node, SIG Scheduling та SIG Auth.

Надійна політика отримання образів для автентифікації образів для IfNotPresent та Never

Ця можливість дозволяє користувачам переконатися, що kubelet вимагає перевірки автентичності образів для кожного нового набору облікових даних, незалежно від того, чи образ вже присутній на вузлі.

Цю роботу було виконано у рамках KEP-2535: Ensure secret pulled images під керівництвом SIG Auth.

Мітки топології вузлів доступні через низхідний API

Ця функція дозволяє показувати мітки топології вузлів за допомогою низхідного API. До версії Kubernetes v1.33 обхідний шлях передбачав використання контейнера init для запиту API Kubernetes для базового вузла; ця альфа-версія спрощує доступ робочих навантажень до інформації про топологію вузла.

Цю роботу було виконано у рамках KEP-4742: Expose Node labels via downward API під керівництвом SIG Node.

Покращення статусу podʼів з генерацією та спостережуваною генерацією

До цієї зміни поле metadata.generation не використовувалося у podʼах. Разом з розширенням підтримки metadata.generation, ця функція додасть status.observedGeneration, щоб забезпечити більш чіткий статус підкадру.

Цю роботу було виконано у рамках KEP-5067: Pod Generation під керівництвом SIG Node.

Підтримка архітектури розділеного кешу 3-го рівня з менеджером процесорів kubelet

Попередній менеджер процесорів kubelet не знав про архітектуру розділеного кешу L3 (також відомого як кеш останнього рівня, або LLC), і потенційно міг розподіляти призначення CPU без урахування розділеного кешу L3, що призводило до виникнення проблеми шумних сусідів. Ця альфа-версія вдосконалює диспетчер процесорів, щоб краще призначати ядра CPU для кращої продуктивності.

Ця робота була виконана в рамках KEP-5109: Split L3 Cache Topology Awareness in CPU Manager під керівництвом SIG Node.

Метрики PSI (Pressure Stall Information) для покращень планування

Ця можливість додає підтримку на вузлах Linux для надання статистики та метрик PSI за допомогою cgroupv2. Вона може виявляти дефіцит ресурсів і надавати вузлам більш детальний контроль за плануванням podʼів.

Цю роботу було виконано у рамках KEP-4205: Support PSI based on cgroupv2 під керівництвом SIG Node.

Витягування образів без секретів за допомогою kubelet

Постачальник облікових даних на диску kubelet тепер підтримує додаткову можливість отримання токенів Kubernetes ServiceAccount (SA). Це спрощує автентифікацію за допомогою реєстрів образів, дозволяючи хмарним провайдерам краще інтегруватися з OIDC-сумісними рішеннями для ідентифікації.

Ця робота була виконана в рамках KEP-4412: Projected service account tokens for Kubelet image credentials providers під керівництвом SIG Auth.

Перехід до стабільного стану, застарівання та вилучення у v1.33

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

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

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

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

У міру розвитку та зрілості Kubernetes деякі функції можуть ставати застарілими, вилучатися або замінюватися на кращі, щоб покращити загальний стан проєкту. Детальніше про цей процес можна дізнатися у документі Kubernetes [політика застарівання та вилучення] (/docs/reference/using-api/deprecation-policy/). Про багато з цих застарівань і вилучень було оголошено у блозі про застарівання і вилучення.

Застарівання стабільного API Endpoints

API EndpointSlices є стабільним з версії 1.21, яка фактично замінила оригінальний API Endpoints. Хоча оригінальний API Endpoints був простим і зрозумілим, він також створював деякі проблеми при масштабуванні на велику кількість точок доступу в мережі. API EndpointSlices представив нові функції, такі як двостекова мережа, що робить оригінальний API Endpoints готовим до застарівання.

Це застарівання впливає тільки на тих, хто використовує API Endpoints безпосередньо з робочих навантажень або скриптів; ці користувачі повинні перейти на використання EndpointSlices. Буде опублікована спеціальна стаття в блозі з більш детальною інформацією про наслідки застарівання і плани міграції.

Ви можете знайти більше інформації в KEP-4974: Deprecate v1.Endpoints.

Видалення інформації про версію kube-proxy зі статусу вузла {#removal-of-kube-proxy-version-information-in-node-status}.

Після застарівання у v1.31, як зазначено в [анонсі випуску] v1.31 (/blog/2024/07/19/kubernetes-1-31-upcoming-changes/#deprecation-of-status-nodeinfo-kubeproxyversion-field-for-nodes-kep-4004-https-github-com-kubernetes-enhancements-issues-4004), у v1.33 було вилучено поле .status.nodeInfo.kubeProxyVersion для вузлів.

Це поле встановлювалося kubelet, але його значення не було стабільно точним. Оскільки воно було стандартно вимкнено з версії 1.31, у версії 1.33 це поле було повністю вилучено.

Ви можете знайти більше інформації у KEP-4004: Deprecate status.nodeInfo.kubeProxyVersion field.

Видалення внутрішнього драйвера тома gitRepo

Тип тома gitRepo був застарілим з версії 1.11, майже 7 років тому. Після його застарівання виникли проблеми з безпекою, зокрема, як типи томів gitRepo можуть бути використані для віддаленого виконання коду від імені користувача root на вузлах. У версії 1.33 код внутрішнього драйвера було вилучено.

Існують альтернативи, такі як git-sync та initContainers. gitVolumes в API Kubernetes які не вилучено, а отже, podʼи з томами gitRepo будуть прийматися kube-apiserverʼом, але kubeletʼи з функціональною можливістю GitRepoVolumeDriver, встановленою в false, не запускатимуть їх і повертатимуть користувачеві відповідну помилку. Це дозволяє користувачам вибрати повторне ввімкнення драйвера для 3 версій, щоб мати достатньо часу для виправлення робочих навантажень.

Функціональну можливість у kubelet та внутрішньому втулку планується вилучити у випуску v1.39.

Ви можете знайти більше інформації в KEP-5040: Видалити драйвер тома gitRepo.

Видалення підтримки хост-мережі для Windows podʼів

Мережа Windows Pod мала на меті досягти паритету можливостей з Linux і забезпечити кращу щільність кластера, дозволивши контейнерам використовувати мережевий простір імен вузла. Початкова реалізація була випущена як альфа-версія у версії 1.26, але оскільки вона зіткнулася з неочікуваною поведінкою контейнерів і були доступні альтернативні рішення, проєкт Kubernetes вирішив відкликати повʼязаний з нею KEP. Підтримка була повністю вилучена у v1.33.

Зверніть увагу, що це не впливає на HostProcess контейнери, які надають доступ до мережі хоста, а також на рівні хоста. KEP, вилучений у версії 1.33, надавав доступ лише до мережі хоста, що ніколи не було стабільним через технічні обмеження мережевої логіки Windows.

Ви можете знайти більше інформації у KEP-3503: Host network support for Windows pods.

Примітки до випуску

Ознайомтеся з повною інформацією про випуск Kubernetes v1.33 у наших примітках до випуску.

Доступність

Kubernetes v1.33 доступний для завантаження на GitHub або на сторінці завантаження Kubernetes.

Щоб розпочати роботу з Kubernetes, перегляньте ці інтерактивні підручники або запустіть локальні кластери Kubernetes за допомогою minikube. Ви також можете легко встановити версію 1.33 за допомогою kubeadm.

Команда випуску

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

Ми хотіли б подякувати всій Команді випуску за години, проведені за важкою роботою над випуском Kubernetes v1.33 для нашої спільноти. Членство в команді Release Team варіюється від новачків до досвідчених лідерів команд, які повернулися з досвідом, отриманим протягом декількох циклів випуску релізів. У цьому циклі було прийнято нову структуру команди, яка полягає в обʼєднанні підкоманд Release Notes і Docs в єдину підкоманду Docs. Завдяки ретельним зусиллям з організації відповідної інформації та ресурсів від нової команди Docs, перехід до відстеження релізів та Docs пройшов гладко і успішно. Нарешті, особлива подяка нашому керівнику релізу, Ніні Полшаковій, за її підтримку протягом усього успішного циклу релізу, її адвокацію, зусилля, спрямовані на те, щоб кожен міг зробити ефективний внесок, а також за її виклики, спрямовані на покращення процесу релізу.

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

Проєкт CNCF K8s DevStats обʼєднує декілька цікавих даних, повʼязаних зі швидкістю розвитку Kubernetes та різних підпроєктів. Це включає все, від індивідуальних внесків до кількості компаній, що беруть участь, і ілюструє глибину і широту зусиль, які докладаються для розвитку цієї екосистеми.

Під час циклу випуску v1.33, який тривав 15 тижнів з 13 січня по 23 квітня 2025 року, Kubernetes отримав внески від 121 компанії та 570 приватних осіб (на момент написання статті, за кілька тижнів до дати випуску). У ширшій хмарній екосистемі ця цифра зростає до 435 компаній, що налічує 2400 учасників. Ви можете знайти джерело даних на цій інформаційній панелі. У порівнянні з даними про швидкість з попереднього випуску, v1.32, ми бачимо аналогічний рівень внеску компаній і приватних осіб, що свідчить про сильний інтерес і залученість спільноти.

Зверніть увагу, що «внесок» зараховується, коли хтось робить комміти, рецензує код, коментує, створює випуск або PR, переглядає PR (включаючи блоги і документацію) або коментує випуски і PR. Якщо ви зацікавлені у внеску, відвідайте Початок роботи на нашому веб-сайті для учасників.

Check out DevStats, щоб дізнатися більше про загальну швидкість проекту та спільноти Kubernetes.

Інформація про події

Дізнайтеся про майбутні події, повʼязані з Kubernetes та хмарними технологіями, включаючи KubeCon + CloudNativeCon, KCD та інші визначні конференції по всьому світу. Будьте в курсі подій та долучайтеся до спільноти Kubernetes!

Травень 2025

червень 2025

липень 2025

Серпень 2025

Ви можете знайти найновішу інформацію про KCD тут.

Вебінар про випуск нового релізу

Приєднуйтесь до команди розробників Kubernetes v1.33 у пʼятницю, 16 травня 2025 року о 16:00 (UTC), щоб дізнатися про основні моменти цього випуску, а також про застарілі та вилучені компоненти, які допоможуть спланувати оновлення. Для отримання додаткової інформації та реєстрації відвідайте сторінку події на сайті Онлайн-програм CNCF.

Долучайтеся

Найпростіший спосіб долучитися до Kubernetes — приєднатися до однієї з численних Special Interest Groups (SIG), які відповідають вашим інтересам. Маєте щось, про що хотіли б розповісти спільноті Kubernetes? Поділіться своєю думкою на нашій щотижневій зустрічі спільноти, а також за допомогою каналів нижче. Дякуємо за ваші відгуки та підтримку.

  • Слідкуйте за нами у Bluesky @kubernetes.io, щоб бути в курсі останніх оновлень
  • Приєднуйтесь до обговорення спільноти на Discuss
  • Приєднуйтесь до спільноти на Slack
  • Задавайте питання (або відповідайте на питання) на Server Fault або Stack Overflow
  • Поділіться своєю історією про Kubernetes
  • Дізнайтеся більше про те, що відбувається з Kubernetes у блозі
  • Дізнайтеся більше про команду розробників Kubernetes