Ця стаття була опублікована більше року тому. Старіші статті можуть містити застарілу інформацію. Перевірте, чи інформація на цій сторінці не втратила актуальності з моменту її публікації.

Kubernetes v1.33: Octarine

Автор Команда випуску Kubernetes v1.33 | Перекладач(і) Андрій Головін |

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

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

Цей випуск складається з 64 удосконалень. З них 18 перейшли до стабільного стану, 20 переходять до бета-версії, 24 зʼявилися в альфа-версії, а 2 є застарілими або відкликаними.

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

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

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

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

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

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

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

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

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

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

Kubernetes реалізує sidecar-контейнери як спеціальний клас контейнерів ініціалізації з restartPolicy: Always, що гарантує, що sidecar-контейнери запускаються перед контейнерами застосунків, залишаються запущеними протягом усього життєвого циклу 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ʼа.

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

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

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

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

У v1.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: Separate kubectl user preferences from cluster configs під керівництвом SIG CLI.

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

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

Ліміти повторних спроб для кожного індексу для Indexed Job

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

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

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

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

Цю роботу було виконано в рамках 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.

Кілька Service CIDR

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

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

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

Бекенд nftables для kube-proxy тепер стабільний; він додає нову реалізацію, яка значно покращує продуктивність і масштабованість реалізації Service у кластерах 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 запитує ексклюзивне використання ядер процесора, CPU Manager може примусово виділяти цілі пари ядер (що складаються з основного і сусіднього потоків) на системах з увімкненим SMT, таким чином запобігаючи сценаріям, коли робочі навантаження ненавмисно спільно використовують ресурси процесора.

Цю роботу було виконано в рамках KEP-2625: node: cpumanager: add options to reject non SMT-aligned workload під керівництвом 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. Ці поля дозволяють користувачам вказати, чи слід враховувати правила спорідненості вузлів та позначки taint вузлів під час обчислення розподілу Podʼів між вузлами. Типово nodeAffinityPolicy має значення Honor, що означає, що до обчислення розподілу включаються лише вузли, які відповідають спорідненості вузлів або селектору вузлів Podʼа. Значення nodeTaintsPolicy типово дорівнює Ignore, що вказує на те, що позначки taint вузлів не враховуються, якщо це не вказано. Це удосконалення забезпечує детальніший контроль за розміщенням Podʼів, гарантуючи, що Podʼи будуть заплановані на вузлах, які відповідають як вимогам спорідненості, так і вимогам toleration до позначок taint, таким чином запобігаючи сценаріям, коли Podʼи залишаються в стані очікування через незадоволені обмеження.

Цю роботу було виконано в рамках KEP-3094: Take taints/tolerations 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) не завжди дотримується, що призводить до потенційних витоків ресурсів сховища. Зокрема, якщо PV видаляється раніше, ніж повʼязана з ним заявка на постійний том (Persistent Volume Claim, PVC), політика повторного використання "Delete" може не виконуватися, залишаючи базові ресурси сховища недоторканими. Щоб запобігти цьому, Kubernetes тепер встановлює завершувачі на відповідні PV, гарантуючи, що політика повторного використання буде застосована незалежно від послідовності видалення. Це удосконалення запобігає ненавмисному збереженню ресурсів сховища та підтримує узгодженість в управлінні життєвим циклом PV.

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

Нові функції в Beta

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

Підтримка Direct Service Return (DSR) у Windows kube-proxy

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

Підтримку DSR, вперше представлену у v1.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 додано підтримку безперебійного оновлення, що дозволяє драйверам, розгорнутим як DaemonSet, використовувати механізм поступового оновлення. Для реалізацій DRA це запобігає видаленню і повторному створенню ResourceSlice, дозволяючи їм залишатися незмінними під час оновлень. Крім того, було введено 30-секундний пільговий період перед тим, як kubelet виконає очищення після скасування реєстрації драйвера, що забезпечує кращу підтримку для драйверів, які не використовують поступові оновлення.

Цю роботу було виконано в рамках KEP-4381: DRA: structured parameters силами WG Device Management, міжфункціональної команди, до складу якої входять SIG Node, SIG Scheduling і SIG Autoscaling.

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

Стандартизоване звітування про дані мережевих інтерфейсів за допомогою DRA, запроваджене у v1.32, перейшло до бета-версії у v1.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 Podʼи, які не було відкладено через помилки, коли activeQ порожня. Раніше планувальник простоював, навіть якщо activeQ була порожньою; це удосконалення покращує ефективність планування, запобігаючи цьому.

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

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

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

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

ClusterTrustBundles

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

Цю роботу було виконано в рамках KEP-3257: ClusterTrustBundles (previously 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ʼах, що зʼявилася у v1.31, перейшла до бета-версії. Ця функція дозволяє користувачам вказувати посилання на образ як том у Podʼі, повторно використовуючи його як точку монтування тому в контейнерах. Це відкриває можливість пакувати дані тому окремо і спільно використовувати їх між контейнерами в Podʼі, не включаючи їх до основного образу, тим самим зменшуючи вразливості і спрощуючи створення образів.

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

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

Одним із найстаріших відкритих 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 під керівництвом SIG Node.

Опція procMount для Podʼа

Параметр procMount, представлений як альфа-версія у v1.12 і як типово вимкнена бета-версія у v1.31, у v1.33 став типово увімкненою бета-версією. Це удосконалення покращує ізоляцію Podʼів, дозволяючи користувачам тонко налаштовувати доступ до файлової системи /proc. Зокрема, воно додає до securityContext Podʼа поле, яке дозволяє перевизначити типову поведінку маскування та позначення певних шляхів /proc як доступних лише для читання. Це особливо корисно у випадках, коли користувачі хочуть запускати непривілейовані контейнери всередині Podʼа Kubernetes з використанням просторів імен користувачів. Зазвичай середовище виконання контейнерів (через реалізацію 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 CPUManager policy option to distribute CPUs across NUMA nodes instead of packing them під керівництвом SIG Node.

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

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

Дія Sleep у хуку preStop тепер може приймати нульову тривалість як бета-функція. Це дає змогу визначати хук preStop, який нічого не робить (no-op), що корисно у випадках, коли хук 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.

Нові функції в Alpha

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

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

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

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

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

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

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

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

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

Цю роботу було виконано в рамках KEP-4960: Container Stop Signals під керівництвом SIG Node.

Безліч удосконалень DRA!

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

Нижче перераховані всі альфа-функціональні можливості DRA, представлені у v1.33:

  • Подібно до позначок taint вузлів, якщо увімкнути функціональну можливість DRADeviceTaints, пристрої підтримують taint та toleration. Адміністратор або компонент панелі управління може додати пристроям позначки taint, щоб обмежити їхнє використання. Планування Podʼів, які залежать від цих пристроїв, може бути призупинено, поки існує taint, і/або Podʼи, які використовують пристрій з taint, можуть бути виселені.
  • Якщо увімкнути функціональну можливість DRAPrioritizedList, DeviceRequests отримують нове поле з назвою firstAvailable. Це поле є впорядкованим списком, який дозволяє користувачеві вказати, що запит може бути задоволено різними способами, зокрема не виділяючи взагалі нічого, якщо певне обладнання недоступне.
  • З увімкненою функціональною можливістю DRAAdminAccess лише користувачі, які мають право створювати обʼєкти ResourceClaim або ResourceClaimTemplate у просторах імен, позначених міткою resource.k8s.io/admin-access: "true", можуть використовувати поле adminAccess. Це гарантує, що користувачі, які не мають прав адміністратора, не зможуть зловживати функцією adminAccess.
  • Хоча використовувати розділи пристроїв можна було ще з v1.31, постачальникам доводилося попередньо розбивати пристрої на розділи і оголошувати їх відповідним чином. Якщо увімкнути функціональну можливість DRAPartitionableDevices у v1.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 ResourceClaimTemplates та 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.

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

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

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

Кращий статус Podʼів завдяки generation та observed generation

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

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

Підтримка архітектури розділеного кешу 3-го рівня в CPU Manager kubelet

Попередній CPU Manager kubelet не знав про архітектуру розділеного кешу L3 (також відомого як кеш останнього рівня, Last Level Cache, LLC) і потенційно міг розподіляти призначення CPU без урахування розділеного кешу L3, що спричиняло проблему шумних сусідів. Ця альфа-функція вдосконалює CPU Manager, щоб краще призначати ядра 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.

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

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

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

Зміна станів, застарівання та вилучення у v1.33

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

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

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

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

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

Застарівання стабільного 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, як зазначено в анонсі випуску v1.31, у v1.33 було вилучено поле .status.nodeInfo.kubeProxyVersion для Node.

Це поле встановлювалося kubelet, але його значення не завжди було точним. Оскільки воно було типово вимкнене з v1.31, у v1.33 це поле було повністю вилучено.

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

Вилучення вбудованого драйвера тому gitRepo

Тип тому gitRepo є застарілим з v1.11, тобто майже 7 років. Після його застарівання виникали проблеми з безпекою, зокрема те, як типи томів gitRepo можуть бути використані для віддаленого виконання коду від імені root на вузлах. У v1.33 код вбудованого (in-tree) драйвера вилучено.

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

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

Більше інформації можна знайти в KEP-5040: Remove gitRepo volume driver.

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

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

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

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

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

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

Доступність

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

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

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

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

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

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

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

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

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

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

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

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

Травень 2025

Червень 2025

Липень 2025

Серпень 2025

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

Майбутній вебінар про випуск

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

Долучайтеся

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

  • Слідкуйте за нами в Bluesky @kubernetes.io, щоб бути в курсі останніх оновлень
  • Приєднуйтеся до обговорення спільноти на Discuss
  • Приєднуйтеся до спільноти в Slack
  • Ставте запитання (або відповідайте на запитання) на Server Fault або Stack Overflow
  • Поділіться своєю історією про Kubernetes
  • Дізнайтеся більше про те, що відбувається з Kubernetes, у блозі
  • Дізнайтеся більше про команду випуску Kubernetes
Змінено November 06, 2026 at 4:44 PM PST: Update content/uk/blog/_posts/2025/kubernetes-v1-33-release/index.md (04e19bf6dc)