Kubernetes Blog

Від робочої групи до SIG Architecture: у центрі уваги AI Conformance

Thu, 29 Oct 2026 05:00:00 +0000

У цьому випуску «У центрі уваги» від SIG Architecture ми поговорили з Janet Kuo (Google) та Yuan Tang (TensorScale AI) про шлях AI Conformance у Kubernetes: від початкової робочої групи до інтеграції в SIG Architecture як підпроєкту.

Знайомство

Frederico Muñoz і Kirti Goyal (FK): Вітаємо, Janet і Yuan, і дякуємо за можливість дізнатися трохи більше про AI Conformance. Чи можете розповісти трохи про себе та про те, як ви долучилися до Kubernetes?

Janet Kuo: Я старший інженер-програміст рівня Staff (Senior Staff Software Engineer) у Google і супроводжую Kubernetes з 2015 року, приєднавшись до спільноти саме тоді, коли ми мчали до запуску версії 1.0. Я починала з написання основних контролерів робочих навантажень, які унормували те, як застосунки оркеструються в Kubernetes. Сьогодні я очолюю SIG Apps як співголова та технічний лідер (TL), а також очолюю програму AI Conformance. Мій теперішній фокус — гарантувати, що Kubernetes залишається найкращою платформою для наступного покоління робочих навантажень, як-от AI.

Yuan Tang: Я співзасновник TensorScale AI, де ми створюємо інфраструктуру AI для моделей світу. До цього я був старшим головним інженером-програмістом (Senior Principal Software Engineer) у Red Hat, де керував розробкою платформи Red Hat AI та стратегією розвитку проєктів із відкритим кодом в апстрімі. Я долучився до Kubernetes на ранньому етапі, сприяючи співпраці між спільнотою Kubernetes і проєктами, які я очолював, зокрема Kubeflow, Argo та KServe. Згодом я допоміг заснувати й очолити WG Serving та програму AI Conformance, просуваючи інновації та зміцнюючи співпрацю спільноти навколо запуску AI-навантажень у Kubernetes.

Програма, робоча група, підпроєкт: яких форм набуває AI Conformance

FK: AI Conformance починався як програма CNCF — саме тоді ви долучилися?

Janet Kuo: Насправді я брала участь із першого дня, адже запропонувала початкову ідею. Тоді стало очевидно, що всі починають запускати AI в Kubernetes, але постачальники будували свої інфраструктурні стеки по-різному. Я занепокоїлася через фрагментацію екосистеми. Тож я написала початкову пропозицію Kubernetes AI Conformance, подала її керівництву CNCF для схвалення й започаткувала програму AI Conformance. Отримавши зелене світло, я звернулася до своїх співголів Yuan Tang, Rita Zhang і Mario Fahlandt, щоб згуртувати спільноту навколо неї.

Yuan Tang: Так. На той час я був співголовою WG Serving, і деякі ініціативи, як-от Gateway AI Inference Extension, швидко набули популярності. У спільноті був сильний інтерес включити вимоги, повʼязані з інференсом, до програми Kubernetes AI Conformance.

FK: Як би ви описали мотивацію створення робочої групи AI Conformance?

Janet і Yuan: Мотивацією створення робочої групи Kubernetes AI Conformance (AI WG) було впоратися зі стрімкою конвергенцією AI-навантажень у Kubernetes і водночас запобігти фрагментації екосистеми.

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

Робочу групу AI WG було створено, щоб обʼєднати спільноту навколо:

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

FK: Робочі групи за своєю природою тимчасові й орієнтовані на результат: чи можна сказати, що головні цілі WG було досягнуто?

Janet і Yuan: Так, WG досягла своїх головних початкових цілей.

WG досягла успіху в переході екосистеми від фрагментованих, специфічних для окремих постачальників підходів до AI-інфраструктури до спільної, визначеної спільнотою базової лінії для AI-навантажень у Kubernetes.

Серед конкретних показників успіху:

запуск програми Certified Kubernetes AI Conformance;
визначення формальних вимог Kubernetes AI Requirements (KARs);
широка участь провідних гравців екосистеми;
зростання кількості сертифікованих платформ з 18 до 31 за кілька місяців;
узгодження щодо новіших примітивів Kubernetes, потрібних для AI-навантажень;
формування дорожньої карти для автоматизованої перевірки відповідності.

Найголовніше — WG сформувала консенсус щодо того, що AI-навантаження тепер є першорядним сценарієм використання Kubernetes.

FK: AI Conformance було окремо відзначено на останньому KubeCon — чи є це відображенням зростання важливості AI в межах усього проєкту?

Janet і Yuan: Так, те, наскільки помітною була тема AI Conformance на останньому KubeCon + CloudNativeCon, — яскраве свідчення того, наскільки центральним AI став для всієї екосистеми Kubernetes.

Кілька років тому AI-навантаження в Kubernetes все ще вважалися доволі спеціалізованими й переважно повʼязаними з ML-платформами чи дослідницькими середовищами з великим обсягом GPU. Що змінилося — те, що AI тепер стає мейнстримною інфраструктурною проблемою майже для кожного великомасштабного оператора платформ.

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

Ініціатива AI Conformance відображає цю еволюцію. Вона сигналізує, що спільнота тепер вважає вимоги до AI-інфраструктури — як-от планування прискорювачів, високопродуктивні мережі, оркестрацію з урахуванням навантаження та інференс із низькою затримкою — достатньо важливими, щоб стандартизувати їх на рівні екосистеми.

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

Тож наголос на AI Conformance — це не просто гонитва за ажіотажем навколо AI; це про те, що Kubernetes адаптується до значного зсуву в моделях навантажень і забезпечує згуртований розвиток екосистеми, а не її розпад на специфічні для кожного постачальника AI-стеки.

Від робочої групи до підпроєкту SIG Architecture

FK: Як би ви описали перехід від WG до SIG? Чи є це відображенням того, що AI потребує постійного архітектурного нагляду?

Janet і Yuan: У Kubernetes робочі групи задумані як тимчасові. Наша WG мала конкретну мету — опублікувати початкові вимоги Kubernetes AI Conformance і запустити процес сертифікації. Щойно ми досягли цих віх, ми заархівували WG і перевели AI Conformance у статус постійного підпроєкту під егідою SIG Architecture.

Перехід до SIG Architecture безперечно доводить, що AI потребує постійного нагляду. AI — це не просто минуща тенденція чи разове навантаження. Він став ключовою частиною того, що Kubernetes запускає щодня. Оскільки SIG Architecture вже опікується загальною відповідністю Kubernetes і принципами проєктування API, розміщення підпроєкту AI Conformance саме там цілком логічне. Це гарантує, що наші вимоги AI Conformance залишатимуться узгодженими з рештою екосистеми Kubernetes у довгостроковій перспективі.

FK: І з урахуванням цієї зміни, як би ви описали головні цілі та сфери втручання підпроєкту?

Janet і Yuan: Тепер, коли ми є підпроєктом, наша головна мета — підтримувати стандарти AI Conformance актуальними, нейтральними щодо постачальників і такими, що встановлюють стандарти. Ми хочемо, щоб Kubernetes охоплював найновіші досягнення в AI-інфраструктурі й водночас зберігав екосистему справедливою для всіх. Коли ми виявляємо прогалини, де немає чіткого зразка спільноти, ми допомагаємо виростити й сформувати нові стандарти для їх розвʼязання.

AI Conformance і Kubernetes

FK: AI-інфраструктура розвивається дуже швидко, тоді як API Kubernetes створені, щоб залишатися стабільними протягом років. Чи вважаєте ви це викликом?

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

По-перше, ми використовуємо багаторівневу модель поетапного підвищення. Коли зʼявляються нові концепції AI-інфраструктури, ми вводимо їх як рекомендовані вимоги SHOULD. Це дає екосистемі простір експериментувати й домовлятися про найкращі практики, не привʼязуючи Kubernetes до жорстких API занадто рано. Коли ці API стабілізуються й набувають поширення в екосистемі, ми підвищуємо їх до обовʼязкових вимог MUST.

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

FK: DRA розвинувся, зокрема завдяки роботі WG Device Management, як важлива частина Kubernetes (особливо для AI-навантажень), і SIG Architecture відіграє важливу роль у тому, як його інтегровано в Kubernetes: чи вбачаєте ви в цьому паралель? Зокрема, чи вважаєте ви, що акцент на інтеграції з архітектурою Kubernetes, що розвивається, посилиться в межах SIG Architecture?

Janet і Yuan: Тут є величезна паралель. Щоразу, коли ми стикаємося з масштабним, складним викликом, який зачіпає кілька частин кодової бази та стосується кількох SIG, робоча група — найкраще місце для початку. Вона дає експертам з різних SIG зібратися разом, щоб розібратися з проблемою й вибудувати консенсус.

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

Завершальні зауваження

FK: Для зацікавлених контрибʼюторів — який найкращий спосіб долучитися до підпроєкту AI Conformance?

Janet і Yuan: Ми завжди шукаємо нових контрибʼюторів. Найпростіший спосіб почати — зазирнути до нашого головного репозиторію kubernetes-sigs/ai-conformance і долучитися до наших зустрічей. Якщо вам цікаво визначати нові вимоги AI Conformance, ви можете долучитися до рецензування PR або запропонувати власні, скориставшись нашим шаблоном KAR. Якщо ви хочете писати код, нам завжди потрібна допомога в розширенні наших автоматизованих наборів тестів на Go у каталозі test/.

Постачальникам, які бажають сертифікувати свої платформи, усі подробиці — у cncf/k8s-ai-conformance.

FK: Чи є якісь завершальні коментарі, якими ви хотіли б поділитися?

Janet і Yuan: Ми вражені тим, як швидко спільнота згуртувалася навколо цього. Коли ми вперше оголосили програму AI Conformance під час пленарної доповіді на KubeCon NA 2025, ми не були впевнені, якою буде реакція. Але на момент, коли ми виступали з оновленою доповіддю на KubeCon EU 2026, ми зросли з 18 сертифікованих платформ до 31 лише за кілька місяців.

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

Якщо ви постачальник платформи, ми будемо раді бачити вас серед сертифікованих. Якщо ви розробник, якого цікавить перетин AI та хмарно-нативної інфраструктури, долучайтеся до нас у SIG Architecture!

FK: Чудово, дякуємо вам обом за те, що провели нас цією подорожжю світом AI та AI Conformance у Kubernetes.

Оголошуємо робочу групу Workload Conformance

Tue, 27 Oct 2026 04:30:00 +0000

Ми раді оголосити, що у спільноті Kubernetes тепер є робоча група з відповідності робочих навантажень. Робоча група розробляє спільний стандарт поведінки робочих навантажень під час виконання в Kubernetes. Щоб зробити це належним чином, нам потрібні думки тих, хто створює ці робочі навантаження, і тих, хто керує кластерами, у яких вони запускаються.

Навіщо потрібен спільний стандарт для робочих навантажень

Сертифікований Kubernetes перевіряє кластер, а Kubernetes AI Conformance — здатність кластера запускати робочі навантаження AI та машинного навчання. Нічого подібного для самих робочих навантажень не існує, тому перед плановим обслуговуванням або оновленням Kubernetes оператори кластерів досі перевіряють кожен застосунок вручну.

Проблеми, які вони виявляють, добре знайомі. Зазвичай саме під час drain вузла зʼясовується, що застосунок не витримує порушень. Оновлення може зламати застосунок, який досі залежить від видаленої версії API. Інші проблеми проявляються у повсякденній роботі: робочі навантаження запитують непотрібні їм привілеї або резервують ресурси, якими ніколи не користуються.

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

Що розробить робоча група

Статут визначає три результати роботи:

Специфікацію поведінки робочих навантажень для кожної мінорної версії Kubernetes.
Метод перевірки кожної вимоги на запущеному робочому навантаженні.
Інструменти перевірки відповідності в апстрімі, що реалізують ці тести.

Перший крок — вирішити, які робочі навантаження та аспекти поведінки охоплюватиме специфікація. Її сфера охоплює безпеку, стійкість до порушень, використання ресурсів, мережу, сховище, використання API та спостережуваність, але група ще не узгодила конкретні вимоги чи способи їх перевірки. Однак одне правило вже визначено: кожна вимога має бути обʼєктивно перевірюваною тестовим виконуваним файлом, тому до специфікації не включатимуть субʼєктивні критерії.

Специфікація описує те, як працює робоче навантаження, а не те, що воно робить. Отже, логіка застосунку не входить до сфери відповідності робочих навантажень. Виконуваний файл не перевірятиме повторно те, що вже охоплено сертифікацією Kubernetes, і не вимагатиме певного формату пакування робочих навантажень або інструментів постачальника, як-от механізму політик чи сканера безпеки.

Як організовано роботу

Робочу групу підтримують дві групи за інтересами (SIG):

SIG Architecture відповідатиме за специфікацію та інструменти через підпроєкт, який створять після того, як робоча група запропонує перші результати.
SIG Apps представлятиме погляд розробників застосунків.

Щойно вимога стосуватиметься сфери іншої SIG Kubernetes, наприклад поведінки вузлів чи мережі, робоча група також розпочне обговорення з відповідною SIG.

Робоча група — це майданчик, на якому SIG можуть долучатися до роботи та визначати напрям розвитку відповідності робочих навантажень під час написання специфікації. Ми прагнемо підготувати першу стабільну специфікацію та робочі тести протягом двох-трьох циклів випуску Kubernetes.

Долучайтеся

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

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

Знайти нас можна в каналі #wg-workload-conformance у Slack Kubernetes (запрошення можна отримати на slack.k8s.io) та в списку розсилки. Робоча група збирається кожні два тижні, у середу о 15:00 UTC. Посилання на Zoom і порядок денний доступні в нотатках зустрічей. Якщо ви хочете порушити певне питання, додайте його до порядку денного. Після приєднання до списку розсилки запрошення на зустріч зазвичай автоматично додається до календаря.

Дякуємо всім, хто переглянув і підтримав пропозицію створити робочу групу.

Чому мій Kubernetes Job досі в черзі? Відстеження допуску Kueue в Headlamp

Wed, 14 Oct 2026 10:35:00 -0800

Ви подаєте Kubernetes Job і чекаєте, поки зʼявляться його Podʼи. Хвилина минає. Потім ще одна. Job досі призупинено, журналів застосунку немає, а Podʼа для перевірки може й не бути.

У кластері, керованому Kueue, це цілком може бути нормою. Kueue досі може вирішувати, чи може Job використати запитані ресурси. Корисне питання полягає не лише в тому, «чому Pod у стані очікування?». Насамперед варто запитати: «Чи здійснив Kueue допуск (admission) цього Workload?».

Втулок Kueue для Headlamp переносить це розслідування в інтерфейс Headlamp. Замість того, щоб відтворювати шлях допуску за допомогою кількох команд і обʼємних YAML-обʼєктів, ви можете почати з Workload, прочитати повідомлення його стану (condition) і перейти за посиланнями до LocalQueue, ClusterQueue, ResourceFlavor і Cohort.

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

Підготовка

Вам потрібен кластер Kubernetes зі встановленим Kueue, встановлений Headlamp та втулок Kueue 0.1.0-alpha. Ваш обліковий запис Kubernetes повинен мати права на читання ресурсів Kueue, що використовуються в цій статті.

Альфа-версія надає режими перегляду лише для читання ресурсів Kueue v1beta2: Cohorts, ClusterQueues, LocalQueues, ResourceFlavors та Workloads. Вона не додає власних робочих процесів створення, редагування, зупинки, відновлення чи видалення. Headlamp як і раніше надає стандартні дії з YAML і ресурсами, якщо ваші дозволи це допускають.

Спершу відокремте допуск від планування Podʼів

Kueue та планувальник Kubernetes відповідають на різні питання.

Допуск Kueue (admission): чи слід запускати цей Workload зараз, з урахуванням політики черги (queue), квоти, ResourceFlavorʼів, перевірок допуску (admission checks) та інших Workloadʼів в очікуванні?
Планування Podʼів: після того як Kueue здійснює допуск Workload і Job поновлюється, на яких вузлах можна виконати його Podʼи?

Межа між цими двома змінює саме розслідування. Якщо Workload не допущено, залишайтеся в розділі Kueue в Headlamp. Якщо допущено, але Podʼи досі в стані Pending, переходьте до звичайних режимів перегляду Job і Pod у Headlamp і перевіряйте події планувальника.

Архітектура допуску Kueue

Шлях усунення несправностей із Headlamp на першому місці

Найшвидше розслідування починається з Workload, а не з командного рядка.

Відстеження Job в очікуванні за допомогою Headlamp

Крок 1. Відкрийте режим перегляду Workloads

У Headlamp відкрийте Kueue → Workloads. Виберіть простір імен (namespace), що містить Job, а потім знайдіть Workload, створений для нього.

Kueue створює Workload, що представляє запит ресурсів і стан допуску Job. В альфа-версії втулка посилання на власника показані як текст у форматі Kind/name, але поки не є посиланнями. Назва Workload зазвичай містить назву Job, тож фільтр за простором імен і пошук у таблиці — найпростіший спосіб його знайти.

Ще до відкриття сторінки подробиць список уже дає корисний перший огляд:

LocalQueue
пріоритет і клас пріоритету
активний стан
стан допуску (admitted)
стан завершення
зрозумілий поточний статус, як-от Admitted, Finished або Inadmissible
вік

Якщо відповідного Workload немає, перевірте три речі, перш ніж іти далі: вибраний простір імен, чи було Job подано до LocalQueue, і чи може ваш обліковий запис Kubernetes перелічувати Workloads. Втулок виконує перевірки дозволів і показує повідомлення про доступ, коли поточний обліковий запис не може прочитати ресурс.

Крок 2. Прочитайте статус, стани та події

Відкрийте Workload. Почніть з його поточного статусу та станів (conditions), а не з повного YAML.

Для усунення несправностей допуску найважливіші типи станів — це QuotaReserved і Admitted.

Admitted=True означає, що Kueue здійснив допуск Workload. Job може поновитися, тож усі Podʼи, що лишилися в стані Pending, належать гілці розслідування, повʼязаній із плануванням.
QuotaReserved=False з причиною, як-от Pending, означає, що Kueue не зарезервував квоту. Повідомлення стану пояснює, що завадило резервуванню.
Статус Inadmissible означає, що Workload поки не вміщується в доступну конфігурацію черги. До цього можуть призвести відсутність ресурсу в наборі квот, непридатний ResourceFlavor, зупинена черга чи перевірка допуску (admission check).

Наприклад, повідомлення стану може сповіщати, що Kueue не зміг призначити ResourceFlavor, оскільки ClusterQueue має недостатню квоту CPU. Таке повідомлення — перша справжня відповідь на запитання «Чому мій Job досі в черзі?». Решта шляху в Headlamp пояснює конфігурацію, що стоїть за цим.

Також перевірте розділ Events. Стани описують поточний стан; події допомагають побачити, що змінилося нещодавно або що Kueue намагався зробити.

Крок 3. Порівняйте запит Workload із його призначенням

Залишайтеся на сторінці подробиць Workload і перевірте PodSets та запити ресурсів. Втулок показує кількість Podʼів, CPU, памʼять та інші ресурси, які Kueue оцінює разом.

Це важливо, бо Job із parallelism: 3 та запитом один CPU на Pod просить у Kueue загалом три CPU. Погляд лише на шаблон одного Podʼа недооцінить Workload.

Якщо квоту вже зарезервовано, та сама сторінка також показує призначений ClusterQueue, ResourceFlavorʼи та використання допущених ресурсів. Якщо цих призначень допуску немає, Workload ще не дійшов до цього етапу.

У нашому прикладі Workload запитує:

три Podʼи
загалом три CPU
загалом 600 MiB памʼяті

Наступне питання — куди цей запит потрапив у Kueue.

Крок 4. Перейдіть за посиланням на LocalQueue

Скористайтеся посиланням LocalQueue на сторінці подробиць Workload. LocalQueue — це точка входу на рівні простору імен, яку використовує Job. Вона зʼєднує Workloads у межах простору імен із ClusterQueue, що охоплює весь кластер.

Сторінка LocalQueue показує:

її простір імен і підключений ClusterQueue
політику зупинки (stop policy) та поточний статус
кількість Workload в очікуванні, з резервуванням і допущених
стани Kueue та події Kubernetes
повʼязані Workloads у тому самому просторі імен

Ця сторінка відповідає на два практичні питання: чи потрапив Job до черги, яку ви очікували, і чи є він єдиним Workload в очікуванні там.

Якщо LocalQueue неактивний або зупинений, це може вже пояснювати очікування. Якщо він активний, перейдіть за посиланням на ClusterQueue, щоб перевірити ємність, що стоїть за ним.

Крок 5. Перевірте ємність і використання ClusterQueue

ClusterQueue представляє квоту та політику допуску на рівні кластера, доступні для одного чи кількох LocalQueue.

На його сторінці подробиць у Headlamp порівняйте запит Workload із такими параметрами:

ресурси в межах квоти (covered resources)
номінальна квота для кожного ResourceFlavor
поточні резервування та використання
обмеження запозичення та надання квоти
кількість Workload в очікуванні, з резервуванням і допущених
стратегія постановки в чергу (queueing strategy) та політика зупинки
налаштування витіснення (preemption), чесного поділу (fair sharing), взаємозамінності flavor (flavor fungibility) та перевірок допуску
стани Kueue та події Kubernetes

Для прикладу в цій статті ClusterQueue надає номінальну квоту в два CPU та два слоти Pod. Workload просить по три з кожного. Повідомлення стану та сторінка ClusterQueue тепер розповідають ту саму історію: Workload не вміщується, тож Kueue залишає Job призупиненим.

Це проблема ємності для допуску, а не доказ того, що kube-scheduler не зміг знайти вузол.

Крок 6. За потреби перевірте ResourceFlavor і Cohort

Квота не завжди є єдиним пулом. ResourceFlavor може представляти клас обчислень за допомогою міток вузлів, taints, tolerations або налаштувань топології. Скористайтеся посиланням на ResourceFlavor із ClusterQueue, коли стан згадує призначення flavor або коли Workload потребує певного класу обладнання, як-от вузли з GPU.

Якщо ClusterQueue належить Cohort, перейдіть і за цим посиланням. Cohort дає змогу ClusterQueue ділитися невикористаною квотою. Сторінка в Headlamp показує батьківські та дочірні Cohort, ClusterQueue-учасники, задіяні ResourceFlavorʼи, групи ресурсів, обмеження запозичення та надання квоти, а також відомості про чесний поділ.

Ці сторінки допомагають відповісти на більш тонке питання: чи заблоковано Workload тому, що черга не має власної квоти, тому, що вона не може позичити достатньо, чи тому, що не можна призначити придатний flavor?

Чого ми навчилися, не залишаючи Headlamp

Для прикладу Job в очікуванні інтерфейс дає нам повне пояснення:

Workload не допущено.
Його стан QuotaReserved має значення false, а повідомлення вказує на недостатню квоту.
Workload запитує три CPU та три слоти Pod.
Його LocalQueue активний і вказує на очікуваний ClusterQueue.
ClusterQueue надає лише два CPU та два слоти Pod.
Тому Kueue тримає Job призупиненим, доки квота не стане доступною або конфігурацію черги не змінять.

Важлива не та обставина, що Headlamp вигадує новий статус. Він зчитує ті самі обʼєкти API Kubernetes, що й інші клієнти, а потім збирає повʼязані ресурси та зрозумілі значення в одному цілісному розслідуванні.

Якщо Workload допущено — перемикайтеся на інші режими

Уявімо, що сторінка подробиць Workload показує Admitted=True, але застосунок досі не працює. Kueue завершив свою частину рішення. Продовжуйте в стандартних режимах перегляду Kubernetes у Headlamp:

Відкрийте Workloads → Jobs і перевірте стан та події Job.
Відкрийте Workloads → Pods і фільтруйте за назвою Job або простором імен.
Виберіть Pod у стані Pending і прочитайте його розділ Events.

На цьому етапі шукайте ознаки проблем планувальника, як-от недостатня ємність вузла, спорідненість вузлів (node affinity), taints і tolerations, обмеження топології, привʼязування постійних томів чи помилки завантаження образів.

Це перемикання — найкорисніше правило усунення несправностей у статті:

Не допущено: розслідуйте ресурси Kueue в Headlamp.
Admitted, але Podʼи в стані Pending: розслідуйте відомості про Job, Podʼи, вузли та планувальник у Headlamp.

Повторюваний чекліст Headlamp

Коли наступний Job не запускається, скористайтеся цим коротким шляхом:

Відкрийте Kueue → Workloads і виберіть правильний простір імен.
Знайдіть Workload, повʼязаний із Job.
Перевірте зрозумілий поточний статус, а також стани Admitted і QuotaReserved.
Прочитайте повідомлення стану та нещодавні події.
Порівняйте запити ресурсів PodSet із призначеннями допуску.
Перейдіть за посиланням LocalQueue та підтвердьте його статус і ClusterQueue.
Перейдіть за посиланням ClusterQueue і порівняйте квоту, резервування, використання та політику.
Перевірте подробиці ResourceFlavor або Cohort, коли повідомлення вказує на вибір flavor або спільну квоту.
Якщо допущено, перейдіть до режимів перегляду Job і Pod у Headlamp.

Що Headlamp замінює під час цього розслідування

Втулок не замінює kubectl чи kueuectl для скриптів, точного виведення обʼєктів чи змін. Він замінює монотонну навігацію без інтерфейсу, потрібну під час інтерактивного розслідування.

Питання	Шлях у Headlamp	Еквівалент у командному рядку
Чи допущено Workload?	Kueue → Workloads → статус і стани	`kubectl describe workload <workload-name> -n <namespace>`
До якого LocalQueue він потрапив?	Workload → повʼязаний LocalQueue	`kubectl get localqueue <localqueue-name> -n <namespace> -o yaml`
Який ClusterQueue надає квоту?	LocalQueue → повʼязаний ClusterQueue	`kubectl get clusterqueue <clusterqueue-name> -o yaml`
Який flavor чи спільна квота мають значення?	ClusterQueue → ResourceFlavor або Cohort	`kubectl get resourceflavor <flavor-name> -o yaml` або `kubectl get cohort <cohort-name> -o yaml`
Що сталося після допуску?	Workloads → Jobs і Pods → події	`kubectl describe job <job-name> -n <namespace>` або `kubectl describe pod <pod-name> -n <namespace>`

Для скриптів і робочих процесів GitOps командний рядок залишається правильним інструментом. Для людини, яка запитує «чому це очікує?», зазвичай швидше прочитати звʼязний шлях у Headlamp.

Необовʼязково: відтворіть сценарій очікування

Репозиторій втулка містить приклади маніфестів Cohort, ClusterQueue, LocalQueue, ResourceFlavor і Job для локального тестування. Застосуйте ці приклади до кластера зі встановленим Kueue, а потім відкрийте розділ Kueue в Headlamp.

Щоб відтворити конкретну невідповідність квоти, використану в цій статті, налаштуйте ClusterQueue з двома CPU та двома слотами Pod, а потім подайте Job із трьома Podʼами, що запитує один CPU на Pod. Job потрапляє до свого LocalQueue, Kueue створює Workload, і Workload залишається в очікуванні, бо сукупний запит більший за доступну квоту.

Цей сценарій навмисно винесено за межі основного огляду: щойно ресурси створено, саме розслідування слід вести в Headlamp.

Поточні обмеження альфа-версії

Випуск 0.1.0-alpha — це початковий режим перегляду шляху допуску Kueue лише для читання.

Втулок не додає власних процесів створення, редагування, призупинення, відновлення чи видалення.
Посилання на власника Workload показуються як текст і поки не є посиланнями.
Інтерфейс залежить від дозволів Kubernetes облікового запису, який використовує Headlamp.
Метрики та візуальна мапа взаємозвʼязків — можливі напрями подальшої роботи, а не можливості цього випуску.

Ці обмеження корисно висловити чітко: поточна мета втулка — зробити стан допуску та взаємозвʼязки ресурсів простішими для перевірки.

Розроблено в межах наставництва LFX

Втулок розроблено в межах наставництва CNCF LFX 2026 Term 2 з використанням TypeScript, React, API Kubernetes та системи втулків Headlamp.

Utkarsh Raj реалізував втулок за наставництва та рецензування René Dudfield (@illume) і Kevin Hannon (@kannon92). Відгуки спільнот Headlamp і Kueue сформували режими перегляду ресурсів, подання статусу, навігацію, документацію, тести та перший альфа-випуск.

Перегляньте сирці втулка та README, прочитайте документацію до випуску 0.1.0-alpha або поділіться відгуками в тікеті випуску.

Якщо Workload в очікуванні досі важко пояснити після проходження шляху в Headlamp, саме такий відгук допоможе покращити втулок.

Перехід на cgroup v2 у Kubernetes: що вам потрібно знати

Tue, 06 Oct 2026 10:00:00 -0800

У Linux cgroups (control groups) — це функція ядра, яка використовується для керування системними ресурсами. Kubernetes використовує cgroups для виділення контейнерам таких ресурсів, як CPU та памʼять, гарантуючи, що застосунки працюють безперебійно, не заважаючи один одному. Починаючи з релізу Kubernetes v1.31, підтримка керування cgroup v1 перейшла в режим підтримки. Підтримка керування cgroup v2 стабільна, починаючи з Kubernetes v1.25.

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

Застарівання cgroup v1

Kubernetes оголосив cgroup v1 застарілим. Починаючи з Kubernetes v1.35, failCgroupV1 має типове значення true, тому kubelet типово не запускається на вузлі з cgroup v1. Адміністратори можуть тимчасово встановити failCgroupV1: false у файлі конфігурації kubelet, але вилучення відбуватиметься відповідно до політики застарівання Kubernetes. Подальша робота з вилучення відстежується в KEP-5573: Remove cgroup v1 support.

Якщо ви все ще використовуєте реліз старіший за v1.35, виконайте міграцію кожного Linux-вузла на cgroup v2 перед оновленням або плануйте встановити тимчасове перевизначення failCgroupV1: false. Якщо ви вже на v1.35 або пізнішій версії, підтвердьте, що кожен Linux-вузол працює з cgroup v2 (або що ви навмисно зберігаєте перевизначення). За типової конфігурації вузол, що залишився на cgroup v1, зазнає збою під час запуску kubelet.

Для кластерів, що управляються kubeadm, у Kubernetes v1.35 ця перевірка також відбувається раніше і є більш суворою. Попередня перевірка SystemVerification, яку надає k8s.io/system-validators, повертає помилку під час kubeadm init, kubeadm join та kubeadm upgrade, коли виявляє cgroup v1 з kubelet v1.35 або пізнішої версії; зі старішим kubelet перевірка залишається попередженням. Деталі дивіться в примітках до релізу kubernetes/system-validators#1.12.1.

Найчастіші запитання охоплюють три основні сфери: чому варто мігрувати, переваги та недоліки, і ключові моменти, про які слід памʼятати при використанні cgroup v2.

Обмеження cgroup v1 та покращення з cgroup v2

Документація ядра Linux описує обидва інтерфейси:

Перелічимо деякі відомі проблеми.

Памʼять `active_file` не вважається доступною памʼяттю

Kubelet вважає памʼять active_file невідновлюваною. Тому для навантажень з інтенсивним вводом/виводом великий кеш сторінок може змусити kubelet повідомляти про тиск на памʼять та виселяти Podʼи. Це відома проблема kubelet (kubernetes/kubernetes#43916); міграція на cgroup v2 сама по собі не змінює цей розрахунок. Задокументований обхідний шлях — встановити однакові запити та ліміти памʼяті для контейнерів, які виконують інтенсивний ввід/вивід, попередньо вимірявши відповідне значення.

Оновлення Memory QoS у Kubernetes v1.36

Memory QoS було представлено як альфа-функцію в Kubernetes v1.22 і оновлено у v1.27. Ця функція залишається альфа-функцією у v1.36, але тепер відокремлює обмеження памʼяті від її резервування та додає багаторівневий захист памʼяті:

Memory QoS доступний лише на Linux-вузлах, які використовують cgroup v2. Він покладається на контролер памʼяті cgroup v2: memory.high забезпечує обмеження, тоді як memory.min і memory.low забезпечують жорсткий і мʼякий захист, коли увімкнено багаторівневе резервування. cgroup v1 не може надати таку модель захисту.

Увімкнення функціональної можливості MemoryQoS застосовує обмеження memory.high до контейнерів Burstable. Поріг визначається із запиту, ліміту та memoryThrottlingFactor (типово 0.9).
memoryReservationPolicy: None є типовим значенням. Воно не записує memory.min чи memory.low.
memoryReservationPolicy: TieredReservation зіставляє запити памʼяті Podʼів Guaranteed з memory.min (жорсткий захист), а запити Podʼів Burstable — з memory.low (мʼякий захист). Podʼи BestEffort не отримують жодного захисту.
Kubelet надає альфа-метрики для загальних резервувань memory.min та memory.low на вузлі.
Рекомендується ядро 5.9 або пізнішої версії. На старіших ядрах відновлення memory.high може спричинити відомий livelock; починаючи з v1.36, kubelet записує попередження в лог, коли Memory QoS увімкнено на ураженому ядрі.

Наприклад, щоб увімкнути багаторівневий захист:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  MemoryQoS: true
memoryReservationPolicy: TieredReservation
memoryThrottlingFactor: 0.9

Загальна рекомендація Kubernetes — не вмикати альфа-функції у промисловому середовищі; однак, якщо ви вважаєте Memory QoS з багаторівневим резервуванням корисним для вашої платформи у промисловому середовищі, обовʼязково протестуйте конфігурацію та врахуйте жорстко зарезервовану памʼять, перш ніж увімкнути функціональну можливість TieredReservation. Поточне зіставлення класів QoS Kubernetes з параметрами керування cgroup v2 дивіться у документації Pod QoS.

Обробка OOM з урахуванням контейнера

На вузлах з cgroup v2 kubelet типово встановлює singleProcessOOMKill у false. Тому він встановлює memory.oom.group для кожного cgroup контейнера, щоб подія OOM вбивала всі процеси в цьому контейнері разом, а не залишала частково працездатний багатопроцесний контейнер. Встановіть singleProcessOOMKill: true, лише якщо вам потрібна поведінка, сумісна з cgroup v1, коли ядро може вбивати по одному процесу за раз. Дивіться довідку KubeletConfiguration для цього налаштування.

Ця поведінка обмежена cgroup контейнера, а не всього Podʼа. Крім того, cgroup.kill — це окремий адміністративний інтерфейс: запис 1 у нього надсилає SIGKILL кожному процесу в цьому cgroup та його нащадках; він не налаштовує поведінку OOM. Контролер памʼяті cgroup v2 додатково надає лічильники memory.events, які можуть спостерігати системи моніторингу та OOM-менеджери у просторі користувача.

Підтримка rootless

У cgroup v1 делегування контролерів менш привілейованим контейнерам може бути небезпечним.

На відміну від cgroup v1, cgroup v2 офіційно підтримує делегування. Більшість реалізацій rootless-контейнерів покладаються на systemd для делегування контролерів v2 користувачам, відмінним від root.

Цей механізм делегування відокремлений від просторів імен користувачів Podʼів Kubernetes, які зіставляють користувачів контейнерів з непривілейованими користувачами хоста. Підтримка просторів імен користувачів Podʼів досягла стабільності в Kubernetes v1.36; перевірте її вимоги до файлової системи, ядра, середовища виконання CRI та OCI перед увімкненням.

Що ще?

Історії eBPF:
- У cgroup v1 контроль доступу до пристроїв відображається через файли інтерфейсу.
- Контролер пристроїв cgroup v2 не має файлів інтерфейсу і реалізований поверх cgroup BPF.
- Cilium прикріплює BPF-програми cgroup для балансування навантаження на основі сокетів. Його типовий кореневий cgroup — це /run/cilium/cgroupv2.
Pressure Stall Information (PSI) повідомляє про конкуренцію за CPU, памʼять та ввід/вивід на рівні вузла, Podʼа та контейнера. На підтримуваних кластерах kubelet типово надає PSI (KubeletPSI стабільна і заблокована в увімкненому стані). PSI вимагає cgroup v2, Linux 4.20 або пізнішої версії, CONFIG_PSI=y та ядро, завантажене без psi=0. Kubelet показує ці дані через Summary API та /metrics/cadvisor.
Під час міграції оновіть програмне забезпечення, яке читає файлову систему cgroup безпосередньо. Поради щодо міграції рекомендують cAdvisor v0.43.0 або пізнішої версії та перелічують сумісні версії Java, Node.js та automaxprocs.

Перетворення ваги CPU у новіших OCI-середовищах виконання

cgroup v1 використовує cpu.shares, тоді як cgroup v2 використовує cpu.weight. Новіші середовища виконання OCI використовують покращене нелінійне перетворення, яке зберігає типовий пріоритет і надає малим CPU-запитам кориснішу гранулярність. Зміну реалізовано в середовищі виконання OCI, а не в Kubernetes: вона доступна в crun v1.23 та runc v1.3.2. Після оновлення середовища виконання інструменти моніторингу або політик, які передбачають точні значення cpu.weight, можуть потребувати оновлень. Читайте «Нове перетворення з cgroup v1 CPU Shares на v2 CPU Weight» щодо формули, прикладів та міркувань сумісності.

Оновлення ресурсів на місці

Вертикальне масштабування Podʼів на місці досягло стабільності в Kubernetes v1.35. Kubernetes v1.36 потім типово увімкнув вертикальне масштабування на місці для ресурсів рівня Podʼа, як бета-функцію. Kubelet координує зміни між cgroups рівня Podʼа та рівня контейнерів так, щоб збільшення створювали запас простору до зростання лімітів контейнера, тоді як зменшення обмежували контейнери перед звуженням межі рівня Podʼа. Точне сукупне застосування цієї функції v1.36 вимагає cgroup v2.

Впровадження cgroup версії 2

Вимоги

Ось що вам потрібно для використання cgroup v2 з Kubernetes. По-перше, вам потрібна версія Kubernetes з підтримкою керування cgroup v2; вона стабільна, починаючи з Kubernetes v1.25, і всі підтримувані релізи Kubernetes включають цю підтримку.

Вам потрібен щонайменше один Linux-вузол; cgroup — це суто Linux-концепція
Ваше встановлення ОС має працювати з увімкненим cgroup v2
Версія ядра має бути 5.8 або пізнішою (5.9 або пізніша рекомендується при використанні Memory QoS)
Середовище виконання контейнерів має підтримувати cgroup v2. Наприклад:
- containerd v1.4 або пізніша підтримує cgroup v2; використовуйте containerd v2.0 або пізнішу для автоматичного виявлення cgroup-драйвера
- CRI-O v1.20 або пізніша
Kubelet і середовище виконання контейнерів мають бути налаштовані на використання правильного cgroup-драйвера. Дивіться Налаштування cgroup-драйвера kubelet відповідно до cgroup-драйвера середовища виконання контейнерів.

Наразі ви можете повернутися до використання cgroup v1; проєкт Kubernetes рекомендує використовувати cgroup v2, але в Kubernetes 1.36 (поточний реліз) варіант cgroup v1 все ще підтримується як запасний. Цей запасний варіант заплановано вилучити в Kubernetes v1.38. Якщо ви запускаєте старіший кластер, плануйте міграцію; якщо ви налаштовуєте новий кластер з Linux-вузлами, вам слід віддати перевагу cgroup v2. В обох випадках перегляньте документацію Kubernetes щодо середовищ виконання контейнерів та (якщо застосовно) матрицю сумісності containerd.

Оновлення ядра, що стосуються cgroup v2

Коли Kubernetes був вперше анонсований, у 2014 році, існував лише cgroup v1. Керування cgroup версії 2 вперше зʼявилося в ядрі Linux 4.5, випущеному у 2016 році.

У Linux 4.5 підтримувалися контролери cgroup v2 io, memory та pids.
Linux 4.15 додав підтримку контролера cpu cgroup v2.
Підтримка Pressure Stall Information (PSI) почалася з Linux 4.20.
Проєкт Kubernetes не рекомендує використовувати cgroup v2 з ядром Linux старішим за 5.2 через відсутність підтримки заморожувача завдань на рівні cgroup.
Kubernetes визначає версію 5.8 як мінімальну версію ядра для cgroup v2; системний файл cpu.stat кореневого cgroup було додано в Linux 5.8.
Виправлення livelock memory.high, яке використовує Memory QoS, присутнє в Linux 5.9 та пізніших.
memory.peak було додано в Linux 5.19.

Конфігурація cgroup-драйвера

Налаштуйте cgroup-драйвер kubelet відповідно до cgroup-драйвера середовища виконання контейнерів.

Якщо ви використовуєте kubeadm для керування кластером, Kubernetes рекомендує використовувати cgroup-драйвер systemd, оскільки kubeadm керує kubelet як службою systemd. Для інших інструментів керування перевірте документацію інструмента, який ви використовуєте для керування кластером.

Якщо ви можете обрати будь-який варіант, я рекомендую використовувати драйвер systemd.

Який би інструмент ви не обрали, kubelet автоматично намагається виявити рекомендований cgroup-драйвер середовища виконання. Це автоматичне виявлення покладається на використання середовища виконання, яке реалізує RPC RuntimeConfig CRI (наприклад: containerd v2.0+ або CRI-O v1.28+).

Якщо ви використовуєте середовище виконання контейнерів, яке підтримує cgroup v2, але не підтримує автоматичне виявлення cgroup-драйвера, ви можете вручну налаштувати перевизначення, відредагувавши файл конфігурації kubelet. Наприклад:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd

Автоматичне виявлення cgroup-драйвера середовища виконання через CRI, яке відстежується KEP-4033, досягло стабільності в Kubernetes v1.34. Воно вимагає середовища виконання, яке реалізує CRI RPC RuntimeConfig (containerd v2.0+ або CRI-O v1.28+). Коли воно доступне, kubelet використовує значення, повідомлене середовищем виконання, замість налаштованого значення cgroupDriver.

Інструменти та команди для усунення несправностей

Інструменти та команди, про які вам слід знати щодо cgroups:

stat -fc %T /sys/fs/cgroup/: Перевірте, чи увімкнено cgroup v2; вона повертає cgroup2fs.
systemctl list-units 'kube*' --type=slice або --type=scope: Перелічіть одиниці, повʼязані з Kubernetes, які systemd наразі має в памʼяті.
bpftool cgroup list /sys/fs/cgroup/*: Перелічіть усі програми, прикріплені до CGROUP cgroup.
systemd-cgls /sys/fs/cgroup/*: Рекурсивно покажіть вміст контрольних груп.
systemd-cgtop: Покажіть верхні контрольні групи за їхнім використанням ресурсів.
tree -L 2 -d /sys/fs/cgroup/kubepods.slice: Покажіть теки cgroups, повʼязані з Podʼами.

Як перевірити, чи ліміт CPU або памʼяті Podʼа успішно застосовано до файлу cgroup?

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

kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.spec.nodeName}{"\n"}'

kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{range .spec.containers[*]}{.name}{" spec\t"}{.resources}{"\n"}{end}'

kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{range .status.containerStatuses[*]}{.name}{" status\t"}{.resources}{"\n"}{end}'

На цьому вузлі, від імені root, з cgroup-драйвером systemd та cgroup v2 (ці фрагменти також потребують jq). Визначте контейнер за мітками kubelet; сама лише назва контейнера не є унікальною на вузлі. Використовуйте crictl ps -a, якщо контейнер не запущено:

CONTAINER_ID=$(crictl ps \
  --label io.kubernetes.pod.namespace=<namespace> \
  --label io.kubernetes.pod.name=<pod-name> \
  --name <container-name> -q | head -n1)

# OCI-представлення (не імена полів protobuf CRI)
crictl inspect "$CONTAINER_ID" | jq '.info.runtimeSpec.linux.resources'

# Шлях cgroup ядра для цього контейнера
PID=$(crictl inspect "$CONTAINER_ID" | jq -r '.info.pid')
CGROUP="/sys/fs/cgroup$(awk -F: '$1=="0"{print $3}' /proc/$PID/cgroup)"

cat "$CGROUP/cpu.weight"   # request.cpu → shares → weight; не ліміт
cat "$CGROUP/cpu.max"      # limit.cpu як "quota period"; без ліміту — "max <period>"
cat "$CGROUP/memory.max"   # limit.memory; без ліміту — "max"

# Cgroup рівня Podʼа (батьківський slice), використовується ресурсами рівня Podʼа
cat "$(dirname "$CGROUP")/cpu.max" "$(dirname "$CGROUP")/memory.max"

# Присутні, коли увімкнено MemoryQoS
cat "$CGROUP/memory.high" "$CGROUP/memory.min" "$CGROUP/memory.low"

SCOPE=$(basename "$CGROUP")
systemctl show "$SCOPE" \
  -p CPUWeight -p CPUQuotaPerSecUSec -p CPUQuotaPeriodUSec -p MemoryMax

Не трактуйте info.runtimeSpec.linux.cgroupsPath як шлях файлової системи, коли середовище виконання використовує драйвер systemd; це значення — шлях одиниці systemd (slice:runtime:id), а не тека під /sys/fs/cgroup.

Очікуване зіставлення на кожному рівні:

Kubernetes: spec.containers[*].resources (бажані) та status.containerStatuses[*].resources (фактичні після зміни розміру на місці). Ресурси рівня Podʼа знаходяться в spec.resources та батьківському pod-slice.
CRI (kubelet → середовище виконання; ці назви protobuf залишаються в стилі cgroup v1 навіть на v2): cpu_shares, cpu_quota, cpu_period, memory_limit_in_bytes, плюс unified для Memory QoS. crictl inspect не показує ці назви; він показує OCI-специфікацію, яку середовище виконання отримало з них.
OCI-специфікація: linux.resources.cpu.{shares,quota,period}, linux.resources.memory.limit та linux.resources.unified. Середовище виконання перетворює shares, quota та period у файли cgroup v2. Після оновлення crun або runc формула перетворення shares у weight може змінитися; дивіться перетворення ваги CPU.
scope systemd: CPUWeight, CPUQuotaPerSecUSec, CPUQuotaPeriodUSec, MemoryMax. Безлімітні або невстановлені значення часто відображаються як [not set] або нескінченність.
cgroupfs: cpu.weight (з CPU-запиту; невстановлений запит все одно дає типове значення у 2 shares), cpu.max та memory.max у scope контейнера. Memory QoS додає memory.high, memory.min та memory.low.

Подальше читання

Kubernetes 1.31: Moving cgroup v1 Support into Maintenance Mode
Kubernetes v1.36: Tiered Memory Protection with Memory QoS
Kubernetes v1.36: PSI Metrics for Kubernetes Graduates to GA
Kubernetes 1.25: cgroup v2 graduates to GA
KubeCon NA 2022 cgroup v2: Before You Jump In від Tony Gosselin та Mike Tougeron, Adobe Systems
KubeCon NA 2022 Cgroupv2 Is Coming Soon To a Cluster Near You — David Porter, Google та Mrunal Patel, RedHat
KubeCon EU 2020 Kubernetes On cgroup v2 від Giuseppe Scrivano, Red Hat.
Цей допис охоплює лише базові вимоги та конфігурацію компонентів Kubernetes. Він не включатиме, як увімкнути cgroup fs у дистрибутивах ОС. Для міграції ви можете звернутися до міграції на cgroup v2

Kubernetes v1.37: Захист зберігання контейнерів через параметри bind mount та режими EmptyDir

Wed, 16 Sep 2026 10:30:00 -0800

Kubernetes v1.37 приносить важливі можливості безпеки зберігання: режими дозволів emptyDir та параметри bind mount. Вони допомагають розробникам застосунків та фахівцям з безпеки впроваджувати суворі політики безпеки, наприклад, забороняти видалення файлів між контейнерами або виконання довільних бінарних файлів із томів з правами запису, безпосередньо в Kubernetes без будь-яких складних обхідних шляхів.

Основи Linux: зберігання та дозволи

Перш ніж заглибитись у нові можливості Kubernetes, коротко оглянемо низькорівневі механізми безпеки Linux, які роблять їх можливими.

Прапорці bind mount

Коли Linux монтує або повторно монтує теку, прапорці Virtual File System (VFS) контролюють, які дії дозволені в цій файловій системі:

noexec: Не дозволяє безпосереднє виконання будь-яких бінарних файлів у змонтованій файловій системі.
nosuid: Не дозволяє бітам set-user-identifier або set-group-identifier діяти.
nodev: Не інтерпретує символьні або блокові спеціальні пристрої у файловій системі.

Дозволи теки та sticky-біт

Стандартні Unix-дозволи регулюють доступ у трьох областях: Власник, Група та Інші (наприклад, 0755 або 0777).

Окрім стандартних бітів читання, запису та виконання, Linux підтримує sticky-біт (як у режимі 01777). Коли sticky-біт застосовується до теки, він гарантує, що файл у цій теці може бути видалений або перейменований лише власником файлу або root. Це є необхідним для спільних тек з правом на запис, таких як /tmp.

Причини для вдосконалень

Чому Kubernetes потребує параметрів bind mount та дозволів emptyDir?

Основна мета цих можливостей — підвищити безпеку робочих навантажень Kubernetes, дозволяючи параметри bind mount, повʼязані з безпекою, при монтуванні томів. Типово томи монтуються як bind mount у контейнери середовищем виконання контейнерів та kubelet без прапорців noexec, nosuid або nodev. Така типова поведінка може підривати безпеку. Наприклад, без noexec, скомпрометований процес може використовувати будь-який том з правами на запис (emptyDir, PersistentVolume тощо) для завантаження, chmod +x та виконання довільних бінарних файлів, навіть коли коренева файлова система контейнера доступна лише для читання (readOnlyRootFilesystem: true). Підтримка noexec, nodev та nosuid надає користувачам вбудований спосіб посилення монтування томів відповідно до стандартів безпеки та політик.

Проблема найбільш помітна з томами emptyDir, які є найпоширенішим типом тому з правом на запис та були предметом кількох повідомлень про проблеми з безпекою:

Issue #48912: Визнано прогалину в безпеці — нездатність встановити параметри монтування для emptyDir була виявлена під час аудиту, але залишилася невирішеною до теперішнього часу.
Issue #119627: Аудит безпеки Kubernetes 1.24 (Finding NCC-E003660-7HM) — зовнішній аудит спеціально зазначав, що нездатність монтувати emptyDir з noexec являє собою збій в безпеці.

Однак та ж прогалина стосується всіх типів томів. У PersistentVolume є поле mountOptions, але ці параметри є прапорцями рівня файлової системи, які застосовуються CSI-драйвером на вузлі, тому вони не надійно перетворюються на прапорці bind mount всередині контейнера. Раніше не було механізму для встановлення noexec, nosuid або nodev на bind mount, який створює середовище виконання контейнерів для будь-якого типу тому.

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

Ви могли, і все ще можете, використовувати init-контейнер для встановлення іншого режиму доступу, але це складніше і важче перевірити на відповідність вимогам.

Це викликає реальні проблеми:

Podʼи з кількома контейнерами, що спільно використовують emptyDir, не могли завадити одному контейнеру видаляти файли іншого. Sticky-біт (01777) вирішує цю проблему, але не було вбудованого способу його встановити.
Деякі застосунки та фреймворки безпеки очікують, що теки /tmp мають встановлений sticky-біт (режим 01777). Без вбудованої підтримки встановлення режиму emptyDir користувачам доводилося використовувати init-контейнери або альтернативні типи томів, щоб задовольнити цю вимогу.
Інженерам платформ, які бажають більш суворі дозволи (наприклад, 0750 лише для власника та групи), доводилося використовувати init-контейнери з chmod, що додає зайву складність.

Тип тому emptyDir був помітною прогалиною. Як один із найпоширеніших типів томів з можливістю запису у Kubernetes, він не мав жодного способу контролювати свої дозволи створення.

Приклади використання в реальних умовах

Розробники застосунків, працюючи тісно з інженерами з безпеки, несуть відповідальність за підтримку профілю безпеки своїх застосунків та забезпечення того, щоб робочі навантаження не створювали ризиків для загальної інфраструктури. Ці можливості дозволяють командам розробників впевнено розвʼязувати критичні сценарії безпеки:

Запобігання підвищенню привілеїв на змонтованих томах із правом запису: Розробник застосунку, який налаштовує тимчасові робочі томи (як emptyDir або монтування /tmp), може переконатися, що вони монтуються з nosuid та noexec. Це гарантує, що навіть якщо застосунок скомпрометовано та завантажено зловмисне навантаження, робоче навантаження не може виконати це навантаження або використати його для підвищення привілеїв на вузлі.

Захист спільного тимчасового простору в Podʼах з кількома контейнерами: Розробник, який налаштовує Podʼи конвеєрів CI/CD, часто потребує кількох контейнерів (наприклад, контейнера збірки та sidecar-контейнера логування) для спільного робочого простору. Встановивши mode: 01777 на emptyDir, розробник гарантує, що спільний робочий простір працює як традиційна Unix-тека /tmp. Кожен контейнер може незалежно записувати файли, але скомпрометований процес в одному контейнері не може видалити артефакти збірки, створені іншим.

Впровадження принципу найменшого привілею для даних застосунку: Розробник застосунку, який розгортає Pod бази даних, може заблокувати доступ до тимчасового сховища бази даних. Встановивши mode: 0750 на emptyDir, розробник гарантує, що лише конкретний користувач та група бази даних можуть читати або записувати до тому, явно відмовляючи в доступі до будь-яких інших процесів або sidecar-контейнерів у тому самому Podʼі.

Примітка: Обидві можливості доступні за функціональними можливостями рівня Alpha в Kubernetes v1.37. Для їх використання увімкніть VolumeBindMountOptions та EmptyDirVolumeMode на API-сервері та kubelet.

Приклад 1: Впровадження параметрів bind mount

Цей повний маніфест Podʼа монтує том emptyDir у /tmp з bindMountOptions: [noexec, nosuid].

apiVersion: v1
kind: Pod
metadata:
  name: hardened-bindmount-pod
  namespace: default
spec:
  os:
    name: linux
  containers:
    - name: hardened-app
      image: alpine:latest
      command: ["sleep", "3600"]
      securityContext:
        readOnlyRootFilesystem: true
      volumeMounts:
        - name: temp-storage
          mountPath: /tmp
          bindMountOptions:
            - noexec
            - nosuid
  volumes:
    - name: temp-storage
      emptyDir: {}

Приклад 2: Режим дозволів тому `emptyDir` зі sticky-бітом

Цей повний маніфест Podʼа створює том emptyDir із використанням mode: 01777 для впровадження стандартних захисних механізмів Unix sticky-біту /tmp між контейнерами.

apiVersion: v1
kind: Pod
metadata:
  name: hardened-emptydir-pod
  namespace: default
spec:
  os:
    name: linux
  containers:
    - name: app-container
      image: alpine:latest
      command: ["sleep", "3600"]
      volumeMounts:
        - name: shared-tmp
          mountPath: /tmp
  volumes:
    - name: shared-tmp
      emptyDir:
        mode: 01777

Перевірка можливостей у Linux

Щоб перевірити, що ці можливості активно впроваджують обмеження, ви можете виконати kubectl exec у контейнері. Наведені нижче приклади імітують спроби виконати дії, які ці можливості успішно блокують.

Перевірка noexec

Спроба запису та виконання скрипту на тому, змонтованому з noexec:

# 1. Виконайте exec у Podʼі
kubectl exec -it hardened-bindmount-pod -- sh

# 2. Створіть виконуваний скрипт на змонтованому томі
cd /tmp
echo '#!/bin/sh' > test.sh
echo 'echo "Executing untrusted code..."' >> test.sh
chmod +x test.sh

# 3. Спроба виконати скрипт
./test.sh

Очікуваний результат:

sh: ./test.sh: Permission denied

Навіть якщо виконуваний файл створено, ядро Linux відмовляє у виконанні, оскільки MS_NOEXEC впроваджується на рівні bind mount.

Перевірка sticky-біту

Спроба видалення файлу іншого користувача в emptyDir із режимом дозволів 01777:

# 1. Виконайте exec у Podʼі
kubectl exec -it hardened-emptydir-pod -- sh

# 2. Перевірте дозволи теки /tmp
ls -ld /tmp
# Вивід: drwxrwxrwt 2 root root ... /tmp (Зверніть увагу на 't', що вказує на sticky-біт)

# 3. Створіть файл як користувач guest
su -s /bin/sh -c "touch /tmp/guest_file" guest

# 4. Спроба видалити цей файл як nobody
su -s /bin/sh -c "rm /tmp/guest_file" nobody

Очікуваний результат:

rm: can't remove '/tmp/guest_file': Operation not permitted

Ядро блокує видалення, оскільки sticky-біт (01777) обмежує видалення файлів суворо власником файлу.

Важливі деталі

Починаючи користуватися цими можливостями, майте на увазі ці ключові моменти. Повні деталі доступні в офіційній документації для параметрів bind mount, режиму тому emptyDir та томів emptyDir.

Типова поведінка не змінилася: Якщо ви пропускаєте bindMountOptions або не встановлюєте mode для emptyDir, ви отримуєте типову поведінку (як-от дозволи 0777) точно так само, як і раніше.
Широка підтримка томів: bindMountOptions працює з emptyDir, PersistentVolume, CSI-томами, проєкційними томами, ConfigMap, Secret та іншими. Єдиним винятком є томи образів, які явно не підтримуються. Поле mode працює з усіма типами середовища emptyDir: default (на основі диска), Memory (tmpfs) та HugePages.
Можливості середовища виконання мають значення (для bindMountOptions): Середовище виконання контейнерів повинно підтримувати поле CRI mount_options та оголошувати це через runtimeFeatures. Планувальник використовує оголошені вузлом можливості, щоб уникати розміщення Podʼів на несумісних вузлах. Якщо Pod все ж досягає такого вузла, kubelet відхиляє його. Непомітної деградації не буває. Однак використання mode для emptyDir не потребує підтримки середовища виконання.
Не те саме, що PV mountOptions: mountOptions PersistentVolume застосовуються на рівні сховища через CSI-драйвер. Нові bindMountOptions контролюють прапорці bind mount, які застосовуються всередині контейнера середовищем виконання. Вони працюють на різних рівнях і не конфліктують.
Взаємодія fsGroup: Якщо fsGroup встановлено в контексті безпеки Podʼа, дозволи групи, які застосовуються fsGroup, перевизначать mode, вказаний для тому emptyDir. Це та сама поведінка, що існує для defaultMode на томах Secret та ConfigMap.
Тільки Linux: Прапорці на кшталт noexec, nosuid, nodev та Unix-дозволи є концепціями Linux. bindMountOptions не має ефекту на вузлах Windows. На Windows поле mode також пропускається для томів emptyDir, оскільки Windows не підтримує Unix-дозволи на файли.
Безпека при розбіжності версій: Обидві можливості є додатковими. Для emptyDir mode: якщо на API-сервері функціональну можливість увімкнено, а на kubelet — ні, поле приймається, але ігнорується — kubelet повертається до 0777. Для bindMountOptions: планувальник використовує Node Declared Features, щоб запобігти розміщенню Podʼів на вузлах без підтримки середовища виконання; якщо Pod досягає такого вузла, kubelet відхиляє його, а не ігнорує параметри мовчки.
Функціональні можливості: Обидві можливості доступні як Alpha-можливості в Kubernetes v1.37:
- VolumeBindMountOptions: Контролює прапорці bind mount при монтуванні томів.
- EmptyDirVolumeMode: Контролює режими дозволів створення на томах emptyDir.

Як долучитись?

Розвиток цих нових можливостей ведуть SIG Node та SIG Storage. Ви можете знайти більше деталей у KEP для цих покращень: KEP-5855 (параметри bind mount) та KEP-5502 (режим дозволів emptyDir).

Звʼяжіться з SIG Node:

Slack: #sig-node
Список розсилки

Звʼяжіться з SIG Storage:

Slack: #sig-storage
Список розсилки

Kubernetes v1.37: Менеджери ресурсів на рівні Pod переходять у бета

Tue, 15 Sep 2026 10:30:00 -0800

З випуском Kubernetes v1.37, можливість Pod-Level Resource Managers перейшла в статус Beta (типово вимкнена)!

Вперше представлена як можливість Alpha у Kubernetes v1.36, це вдосконалення розширює можливості Pod-Level Resources, надаючи Topology Manager, CPU Manager і Memory Manager у kubelet змогу використовувати декларації ресурсів на рівні Podʼа (.spec.resources) безпосередньо під час ухвалення рішень про розміщення на апаратних ресурсах.

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

До появи цієї можливості отримання ексклюзивних CPU-ядер, вирівняних за NUMA, або памʼяті для застосунків з критичною затримкою змушувало операторів кластерів робити вибір "все або нічого": призначати цілі запити ресурсів кожному контейнеру в Podʼі або повністю відмовитися від ексклюзивного вирівнювання за NUMA. Для сучасних робочих навантажень, що запускають легкі sidecar-контейнери (такі як агенти логування або експортери телеметрії), виділення спеціальних фізичних ядер допоміжним контейнерам було марнотратним.

Функція Pod-Level Resource Managers вирішує цю проблему, дозволяючи гібридні моделі розподілу ресурсів. Kubelet може резервувати ексклюзивні ресурси, вирівняні за NUMA, для основних контейнерів застосунків, одночасно розміщуючи sidecar-контейнери без класу Guaranteed у спільному пулі, ізольованому в межах Podʼа. Це забезпечує основним робочим навантаженням необмежену продуктивність, локальну для NUMA, тоді як sidecar-контейнери працюють в ізольованому спільному пулі Podʼа, отримуючи локальним вирівнюванням за NUMA та захистом від зовнішніх втручань вузла без використання спеціальних фізичних ядер.

Що нового у бета-версії

Перехід у бета-версію приносить ключові операційні та API покращення:

Перехід у бета-версію: Керується функціональною можливістю PodLevelResourceManagers, яку можна ввімкнути (типово вимкнена) у Kubernetes v1.37.
Звітування PodResources API: gRPC-сервіс v1 PodResources (PodResourcesLister) вводить поля верхнього рівня cpu_ids і memory у відповідях PodResources. Інструменти моніторингу та втулки пристроїв можуть безпосередньо запитувати ексклюзивні призначення на рівні Podʼа без подвійного підрахунку виділень контейнерів.

Початок роботи та надання відгуків

Для детального ознайомлення з технічними деталями та налаштуванням цієї можливості дивіться офіційну документацію:

Щоб ознайомитися з покроковим посібником з налаштування та розгортання робочих навантажень:

Використання ресурсів рівня Podʼа з менеджерами ресурсів kubelet

Щоб дізнатися більше про те, як призначати ресурси Podʼам:

Призначення ресурсів CPU і памʼяті рівня Pod

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

Kubernetes v1.37: Витіснення планувальником для зміни розміру Podʼів на місці (Alpha)

Thu, 10 Sep 2026 10:30:00 -0800

У Kubernetes виділення ресурсів історично було статичним рішенням, прийнятим під час початкового планування та розміщення Podʼа. З переходом основної можливості in-Place Pod resize до загальної доступності (GA) у v1.35, розробники застосунків та оператори кластерів отримали потужну здатність динамічно коригувати виділення CPU та памʼяті запущених контейнерів без руйнівних перезапусків або простою застосунків.

Однак зміна розміру на місці створила унікальну прогалину в плануванні ресурсів: якщо запущений Pod запитував масштабування ресурсів, що перевищувало запас ресурсів хост-вузла, доступних для розподілу, Kubelet був змушений позначити запит як Deferred. Pod залишався у цьому стані невизначений час, очікуючи, доки ресурси на вузлі не звільняться природним шляхом.

Для закриття цієї прогалини в плануванні Kubernetes v1.37 вводить витіснення планувальником для зміни розміру Podʼа на місці (Alpha), з функціональною можливістю InPlacePodVerticalScalingSchedulerPreemption. Ця можливість дозволяє планувальнику Kubernetes активно звільняти ресурси на повністю завантаженому вузлі шляхом витіснення робочих навантажень з нижчим пріоритетом, уможливлюючи успіх очікуваних in-place масштабувань критичних застосунків з вищим пріоритетом.

Проблема відкладеної («deferred») зміни розміру

Щоб зрозуміти, чому цей механізм витіснення потрібен, корисно подивитися, як Kubernetes обробляє зміну розміру запущених Podʼів. Коли користувач або контролер (такий як Vertical Pod Autoscaler) оновлює запити ресурсів активного контейнера, Kubelet оцінює, чи базовий вузол має достатньо вільної потужності для задоволення збільшення.

Якщо ресурси вузла повністю використані і не можуть задовольнити нові обмеження, Kubelet встановлює resizeStatus контейнера (повідомлений у status.containerStatuses[] Podʼа) на Deferred. На відміну від запиту на зміну розміру Infeasible (який негайно відхиляється, бо він перевищує фізичні межі машини, LimitRange простору імен або квоти допуску), статус Deferred вказує на те, що запит є дійсним, але тимчасово не може бути реалізований, очікуючи, доки потужність вузла не стане доступною.

Перед введенням цього механізму витіснення запит на in-place масштабування Podʼа міг стати постійно заблокованим, якщо вузол був інтенсивно використаний. Навіть коли критичному застосунку (такому як in-memory база даних або real-time веб-сервер) потрібно більше памʼяті для запобігання неминучому збою out-of-memory (OOM), а вузол не мав вільної потужності, resize залишався Deferred.

У цьому сценарії оператори кластера мали обмежений вибір:

Вручну виселити Podʼи з нижчим пріоритетом з вузла, щоб звільнити запас ресурсів.
Покладатися на кластерний автомасштабувач, який зрештою запустить більший вузол і перепланує Pod. Однак це операція, яка є надзвичайно руйнівною і порушує основну пропозицію цінності «без перезапуску» in-place масштабування.
Покладатися на власне рішення автоматичного масштабування, наприклад, кластерний автомасштабувач, який може сам ініціювати операції динамічної зміни розміру вузла.

Оскільки kube-scheduler не знав про відкладені зміни розміру на запущених Podʼах, він не міг використовувати стандартне витіснення на основі пріоритетів для виселення робочих навантажень з нижчим пріоритетом і звільнення місця для зростання ресурсів запущеного Podʼа з вищим пріоритетом.

Чому це важливо

У промислових середовищах Kubernetes оператори кластерів прагнуть максимізувати використання ресурсів та ефективність. Поширена стратегія — bin-pack (упакування) невикористаної потужності на ще не повних вузлах робочими навантаженнями з нижчим пріоритетом, такими як пакетні завдання, фонова обробка даних або best-effort задачі.

Без витіснення планувальником для зміни розміру на місці це створювало велику операційну дилему. Якщо робочі навантаження з нижчим пріоритетом споживали залишковий запас на вузлі, застосунки з вищим пріоритетом, що запущені на тому самому вузлі, ставали заблокованими (Deferred), коли їм потрібно було масштабуватися для обробки раптових стрибків трафіку або сплесків використання памʼяті. Оператори були змушені вибирати між запуском кластерів з низьким використанням та вільним буферним запасом або ризиком того, що критичні робочі навантаження не зможуть масштабуватися, коли це потрібно.

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

Архітектурна механіка: Як це працює

Витіснення планувальником для зміни розміру Podʼа на місці інтегрується безпосередньо в основний цикл планування для динамічної та безпечної координації ресурсів.

Централізоване відстеження планувальником

kube-scheduler відстежує в кластері Podʼи, що виконуються зі статусом зміни розміру Deferred. Зазвичай Podʼи із заповненим полем spec.nodeName вважаються успішно розміщеними й оминають активну чергу планування. У рамках цієї функціональної можливості планувальник перехоплює Podʼи зі статусом Deferred, дозволяючи їм залишатися в активній черзі планування спеціально для запуску витіснення. Планувальник здійснює безперервне відстеження цих Podʼів, доки Kubelet не завершить успішно операцію зміни розміру.

Межа витіснення на одному вузлі

На відміну від витіснення при розміщенні, яке аналізує всі вузли в кластері для пошуку оптимального варіанту планування, витіснення для зміни розміру на місці суворо обмежується вузлом, якому наразі призначено Pod. Планувальник визначає відповідні Podʼи з нижчим пріоритетом — «жертви» — на тому самому хості та ініціює їх належне виселення, звільняючи локальні ресурси. Витіснення суворо обмежується тим самим вузлом, на якому працює Pod із відкладеним зміненням розміру; якщо вузол не може забезпечити змінення розміру навіть після виселення всіх відповідних робочих навантажень з нижчим пріоритетом, змінення розміру залишається у стані Deferred.

Безпека резервування ресурсів

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

Розділення зон відповідальності та критичний допуск

Коли вузол перебуває під тиском нестачі ресурсів, Kubelet включає локальний механізм, відомий як critical Pod admission handler (обробник критичного допуску Podʼів). Під час початкового допуску Podʼа, якщо критичний системний Pod надходить на вузол, в якого бракує вільної потужності, цей локальний обробник може безпосередньо виселити Podʼи з нижчим пріоритетом на цьому вузлі для гарантування допуску критичного робочого навантаження.

Значною архітектурною перевагою цієї нової можливості є суворе розділення зон відповідальності між Kubelet та планувальником. З функціональною можливістю InPlacePodVerticalScalingSchedulerPreemption обробник допуску критичних Podʼів Kubelet НЕ виконує локальні перевірки витіснення і НЕ ініціює локальні витіснення для операцій зміни розміру на місці. Замість цього Kubelet відкладає запит і повністю делегує рішення про витіснення планувальнику. Це гарантує, що єдиний централізований оркестратор керує всією логікою витіснення, повʼязаною зі зміною розміру на місці, поважаючи глобальні пріоритети, Pod Disruption Budgets (PDB) та політики належного завершення роботи.

Керування конкурентними оновленнями та станами гонитви

Якщо під час активного циклу витіснення надходить конкуруючий запит на зміну розміру з вищим пріоритетом для іншого Podʼа, що виконується на тому самому вузлі, Kubelet надає пріоритет запиту з вищим пріоритетом. Планувальник призначений для відстеження таких оновлень і динамічно запускатиме новий цикл витіснення, якщо для досягнення нового стану знадобиться більше ресурсів.

Конфігурація витіснення на рівні вузла

Адміністратори та автоматизовані контролери (наприклад, автомасштабувальник кластера) можуть вимкнути витіснення спеціально для зміни розміру на місці на окремих вузлах. Це налаштовується за допомогою нового поля spec.podPreemptionPolicy у специфікації вузла:

apiVersion: v1
kind: Node
metadata:
  name: batch-workload-node
spec:
  podPreemptionPolicy:
    disableResizePreemption:
      - "cluster-autoscaler.kubernetes.io/disable-preemption"
      - "operator.example.com/policy-override"

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

Спробуйте це!

Для використання витіснення планувальника для зміни розміру Podʼа на місці:

Ваш кластер має працювати на Kubernetes версії v1.37 або новішій, як на панелі управління, так і на всіх робочих вузлах.
Функціональна можливість InPlacePodVerticalScalingSchedulerPreemption має бути увімкнена на всіх компонентах панелі управління (kube-apiserver, kube-scheduler) та kubelet.

Міні-посібник: Спостереження за витісненням планувальника для зміни розміру на місці в дії

Щоб побачити цю можливість в дії локально, ви можете протестувати витіснення планувальника на одновузловому кластері kind з обмеженим запасом CPU.

1. Створіть kind-кластер з увімкненим витісненням планувальника для зміни розміру на місці

Створіть файл конфігурації кластера kind з назвою kind-config.yaml з увімкненою функціональною можливістю InPlacePodVerticalScalingSchedulerPreemption:

# kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
featureGates:
  InPlacePodVerticalScalingSchedulerPreemption: true

Створіть кластер, використовуючи цю конфігурацію, передаючи прапорець --image, щоб переконатися, що кластер працює на Kubernetes v1.37 (або новішій):

kind create cluster --config kind-config.yaml --image kindest/node:v1.37.0

Примітка:

Переконайтеся, що образ вузла, який ви вказуєте, відповідає Kubernetes-кластеру v1.37 або новішому (такому як kindest/node:v1.37.0). Старіші релізи Kubernetes не підтримують функціональну можливість InPlacePodVerticalScalingSchedulerPreemption.

Після готовності кластера перевірте вузол, щоб дізнатися, скільки ядер CPU, доступних для розподілу, він має:

kubectl get nodes -o custom-columns=NAME:.metadata.name,ALLOCATABLE_CPU:.status.allocatable.cpu

У стандартному локальному середовищі kind вивід показує 8 ядер CPU, доступних для розподілу:

NAME                 ALLOCATABLE_CPU
kind-control-plane   8

2. Створіть PriorityClasses та розгорніть Podʼи

Створіть два PriorityClasses та розгорніть Pod з низьким пріоритетом (що запитує 3 CPU) поруч з Podʼом з високим пріоритетом (що запитує 4 CPU). Разом ці робочі навантаження споживають 7 з 8 доступних ядер CPU, залишаючи 1 CPU вільного запасу, доступного для розподілу, на вузлі.

# preemption-demo.yaml
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
  value: 1000000
  globalDefault: false
  description: "High priority workload"
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: low-priority
  value: 1000
  globalDefault: false
  description: "Low priority workload"
---
apiVersion: v1
kind: Pod
metadata:
  name: low-priority-pod
spec:
  priorityClassName: low-priority
  containers:
  - name: worker
    image: nginx
    resources:
      requests:
        cpu: "3"
        memory: "500Mi"
      limits:
        cpu: "3"
        memory: "500Mi"
---
apiVersion: v1
kind: Pod
metadata:
  name: high-priority-pod
spec:
  priorityClassName: high-priority
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: "4"
        memory: "1Gi"
      limits:
        cpu: "4"
        memory: "1Gi"

Збережіть цей маніфест у preemption-demo.yaml і застосуйте його:

kubectl apply -f preemption-demo.yaml

Почекайте, поки обидва Podʼи запустяться на вузлі:

kubectl get pods

Вивід:

NAME                READY   STATUS    RESTARTS   AGE
high-priority-pod   1/1     Running   0          9s
low-priority-pod    1/1     Running   0          9s

3. Запит на in-place scale-up

Застосуйте patch до Podʼа з високим пріоритетом, щоб збільшити його запит CPU з 4 до 6 (+2 CPU). Оскільки на вузлі вільний лише 1 CPU, цей запит на зміну розміру перевищує залишкову доступну ємність:

kubectl patch pod high-priority-pod --subresource resize --patch \
  '{"spec":{"containers":[{"name":"app", "resources":{"requests":{"cpu":"6"}, "limits":{"cpu":"6"}}}]}}'

4. Перевірка події витіснення на Podʼі з низьким пріоритетом

Якщо увімкнено InPlacePodVerticalScalingSchedulerPreemption, планувальник перехоплює стан зміни розміру Deferred у high-priority-pod і вибирає low-priority-pod для витіснення.

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

kubectl get events --field-selector involvedObject.name=low-priority-pod

У потоці подій (або через kubectl describe pod low-priority-pod) ви побачите подію Preempted, згенеровану планувальником:

LAST SEEN   TYPE     REASON      OBJECT                 MESSAGE
5s          Normal   Preempted   pod/low-priority-pod   Preempted by pod 97dba925-6b5f-4e2f-99f9-d51c30016586 on node kind-control-plane
5s          Normal   Killing     pod/low-priority-pod   Stopping container worker

5. Відстеження життєвого циклу події зміни розміру на Podʼі з високим пріоритетом

Далі перегляньте історію подій на high-priority-pod, щоб спостерегти, як зміна розміру перейшла від стану deferred до успішного завершення:

kubectl get events --field-selector involvedObject.name=high-priority-pod

Ви спостерігатимете послідовність подій, коли Kubelet координується з планувальником:

LAST SEEN   TYPE      REASON            OBJECT                  MESSAGE
33s         Warning   ResizeDeferred    pod/high-priority-pod   Pod resize OutOfcpu: {"containers":[{"name":"app","resources":{"limits":{"cpu":"6","memory":"1Gi"},"requests":{"cpu":"6","memory":"1Gi"}}}],"generation":2,"error":"Node didn't have enough resource: cpu, requested: 6000, used: 3950, capacity: 8000"}
32s         Normal    ResizeStarted     pod/high-priority-pod   Pod resize started: {"containers":[{"name":"app","resources":{"limits":{"cpu":"6","memory":"1Gi"},"requests":{"cpu":"6","memory":"1Gi"}}}],"generation":2}
32s         Normal    ResizeCompleted   pod/high-priority-pod   Pod resize completed: {"containers":[{"name":"app","resources":{"limits":{"cpu":"6","memory":"1Gi"},"requests":{"cpu":"6","memory":"1Gi"}}}],"generation":2}

ResizeDeferred: Kubelet початково позначає запит на зміну розміру як deferred (Warning) через нестачу запасу CPU на вузлі (OutOfcpu).
ResizeStarted: Як тільки планувальник витісняє low-priority-pod і потужність звільняється, Kubelet приймає нове виділення і починає застосування зміни розміру.
ResizeCompleted: Kubelet успішно оновлює обмеження cgroup контейнера через середовище виконання контейнерів без перезапуску Podʼа.

Нарешті, перевірте, що виділений CPU на контейнері відображає новий запит (додавання {"\n"} до JSONPath запиту забезпечує завершальний новий рядок у вашому терміналі):

kubectl get pod high-priority-pod -o jsonpath='{.status.containerStatuses[0].allocatedResources.cpu}{"\n"}'

Вивід:

Це підтверджує, що зміна розміру на місці вдалася.

Як долучитися

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

Якщо ви хочете поділитися своїм досвідом з цією функцією, будь ласка, звʼяжіться зі спільнотою через канали SIG Scheduling або SIG Node!

Kubernetes v1.37: Представляємо стани життєвого циклу вузла

Wed, 09 Sep 2026 10:30:00 -0800

Kubernetes має багато способів описати те, що відбувається на вузлі. Готовність (readiness), taints, стан Podʼів, мітки, анотації та API конкретних провайдерів — кожен розкриває частину картини. Бракувало спільного способу, що належить Kubernetes, повідомити, що для вузла виконується drain, що він перебуває на обслуговуванні або що на ньому триває коректне вимкнення вузла.

Kubernetes v1.37 вводить пʼять загальновідомих станів вузла (Node conditions), що надають цей опис:

DrainInProgress
Drained
MaintenancePlanned
MaintenanceInProgress
GracefulNodeShutdownInProgress

Нові стани життєвого циклу вузла

Стан	Що він повідомляє
`DrainInProgress`	Для вузла активно виконується drain відповідно до обраних адміністратором критеріїв drain.
`Drained`	Вузол досяг обраних адміністратором критеріїв drain.
`MaintenancePlanned`	Очікується, що вузол пройде через зміну в майбутньому.
`MaintenanceInProgress`	Вузол перебуває в стані обслуговування.
`GracefulNodeShutdownInProgress`	Визначено, що на вузлі триває коректне вимкнення вузла.

Обслуговування може включати оновлення апаратного або програмного забезпечення, виправлення, виведення з експлуатації або налагодження. Чи потребує обслуговування drain, залежить від його впливу. Оновлення Kubernetes зазвичай слід виконувати після drain, тоді як live patch ядра може не потребувати його.

Як і інші стани вузла, кожен стан життєвого циклу використовує status для повідомлення про те, чи активне спостереження:

True: стан життєвого циклу зараз спостерігається.
False: стан життєвого циклу зараз не спостерігається.
Unknown: Kubernetes не може визначити, чи активний стан життєвого циклу.

reason надає стабільну, машиночитану причину для поточного статусу, а message може надати додаткові людиночитані деталі.

Наприклад, авторизований контролер обслуговування може опублікувати:

# Node .status excerpt
status:
  conditions:
  - type: MaintenancePlanned
    status: "True"
    reason: MaintenanceWindow
    lastTransitionTime: "2026-12-09T12:00:00Z"
    message: "Hardware maintenance is scheduled for this Node"

Що змінюється в Kubernetes v1.37

У версії v1.37 ці імена зарезервовано як загальновідомі константи NodeConditionType, а також запроваджено функціональну можливість Alpha-рівня NodeLifecycleConditions, яка типово вимкнена. У версії 1.37 ця функціональна можливість фактично нічого не робить: вона не обмежує коло користувачів, які можуть встановлювати ці стани, і жоден основний компонент їх не зчитує. Вона існує для того, щоб у майбутніх версіях можна було увімкнути заплановану вбудовану поведінку — контролери, які використовують ці стани. Вам не потрібно вмикати цю функціональну можливість, щоб почати публікувати стани вже сьогодні.

У цьому випуску за встановлення та скидання станів життєвого циклу відповідає адміністратор або авторизований адміністратором контролер.

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

Як використовувати стани життєвого циклу сьогодні

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

Наприклад, автоматизація обслуговування може встановити MaintenancePlanned, коли заплановане майбутнє вікно обслуговування, потім встановити MaintenanceInProgress, коли робота починається. Автоматизація drain може встановити DrainInProgress, коли починає виселяти Podʼи, і Drained, коли обрані адміністратором критерії drain виконано. Стан GracefulNodeShutdownInProgress може повідомляти, що на вузлі триває коректне вимкнення вузла.

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

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

Чому спільний сигнал важливий

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

Сьогодні кожен компонент має реконструювати це розуміння з непрямих сигналів. Один контролер може дивитися на готовність вузла, інший — на taints, третій — на Podʼи, що завершуються або відсутні. Провайдери інфраструктури та оператори часто додають власні мітки або анотації.

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

Без спільного контексту життєвого циклу компоненти, які окремо є коректними, можуть приймати суперечливі рішення. Контролер DaemonSet може замінити Pod, який kubelet навмисно завершив під час коректного вимкнення. Контролер Job може безкінечно чекати на кінцеву фазу Podʼа на вузлі, який адміністратор видаляє. Оператор системи зберігання даних може дізнатися про технічне обслуговування лише після того, як drain уже розпочався.

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

Фундамент для Kubernetes, що враховує життєвий цикл

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

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

Контролер DaemonSet знає, що Pod недоступний, але він не може сказати, чи нова ревізія провалилася чи адміністратор навмисно вивів вузол з експлуатації. Готовність, taints та стан Podʼів показують частини ситуації, але жоден не надає авторитетного контексту обслуговування.

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

Майбутні розширення та як долучитись

Життєвий цикл вузла — це перехресна проблема. Її розвʼязання починається з того, що компоненти обмінюються достатнім контекстом для прийняття сумісних рішень. Наступний етап — спиратися на Node Lifecycle Conditions для покращення таких сценаріїв, як Graceful Node Shutdown, drain та обслуговування. Довгострокова координація життєвого циклу може вимагати явної власності, блокування та потенційно спеціалізованого API.

Екосистема Kubernetes вже включає багато рішень для обслуговування вузлів, виправлення, drain, автоматичного масштабування та керування парком вузлів. Досвід цих проєктів необхідний для побудови фундаменту, що працює в різних середовищах та операційних моделях. Node Lifecycle Working Group, SIG Node та SIG Apps запрошують супровідників та користувачів поділитися своїми випадками використання та ідеями для формування майбутньої роботи.

Слідкуйте за роботою через KEP-5683: Node Lifecycle Conditions. Для участі в наших обговореннях, приєднуйтесь до однієї з наших груп:

Kubernetes v1.37: Storage Version Migration типово увімкнена

Mon, 31 Aug 2026 10:30:00 -0800

Я радий, що міграція версії зберігання (SVM) досягла загальної доступності (GA) у Kubernetes v1.37!

Після кількох випусків роботи та тестування вбудований API StorageVersionMigration (storagemigration.k8s.io/v1) та контролер панелі управління тепер повністю стабільні та типово увімкнені у всіх кластерах Kubernetes v1.37.

Проблема застарілих версій зберігання

У Kubernetes збережені API-ресурси записуються з використанням певної версії зберігання (представлення схеми). Те, як Kubernetes взаємодіє з обʼєктним сховищем, принципово вимагає зміни ресурсу, щоб гарантувати використання останньої версії зберігання для всіх ресурсів. Це створює проблеми, коли ви хочете змінити версію зберігання ресурсу.

Один із прикладів сценарію, коли ви можете захотіти змінити версію зберігання ресурсу, — це коли ви просуваєте CRD, щоб відмовитися від старішої версії API (наприклад, v1alpha1) на користь новішої (залишивши лише v1beta1 та v1). Відмова від старішої версії API є проблемою, поки в сховищі все ще залишаються ресурси, збережені зі старою альфа-версією.

Щоб уникнути проблем, ви призначаєте v1 як нову версію зберігання; але само по собі цього недостатньо. Поки нові записи зберігаються як v1, будь-який наявний ресурс може залишатися збереженим як v1alpha1 або v1beta1 у сховищі. Ви не можете безпечно видалити v1alpha1 з .status.storedVersions CRD або припинити підтримку обслуговування, доки кожен окремий ресурс у сховищі не буде переписаний так, щоб не серіалізуватися та не зберігатися з альфа-версією.

Іншим доречним прикладом є шифрування у стані спокою та, повʼязана з ним, ротація ключів. Коли ви налаштовуєте шифрування у стані спокою або виконуєте ротацію ключів шифрування, наявні ресурси у сховищі залишаються незашифрованими (або зашифрованими старими ключами), доки вони не будуть активно переписані через API-сервер Kubernetes.

Історично адміністратори кластерів та автори CRD мали покладатися на ручні скрипти kubectl get / kubectl replace або розгортати зовнішній компонент kube-storage-version-migrator, щоб примусово виконувати перезапис. Ці підходи часто були марудними, схильними до помилок та важкими для моніторингу.

Як працює міграція версії зберігання

Запустити міграцію версії зберігання так само просто, як створити декларативний обʼєкт StorageVersionMigration. Вбудований контролер StorageVersionMigrator у панелі управління Kubernetes відстежує ці обʼєкти та автоматично переносить наявні ресурси до типової версії зберігання для цього API.

Приклад: міграція API власного ресурсу

Припустимо, ви оновили CustomResourceDefinition (crontabs.example.com), щоб використовувати v1 як версію зберігання. Щоб мігрувати всі наявні збережені ресурси зі старіших версій, створіть StorageVersionMigration:

apiVersion: storagemigration.k8s.io/v1
kind: StorageVersionMigration
metadata:
  name: crontabs-migration
spec:
  resource:
    group: example.com
    resource: crontabs

Застосуйте маніфест за допомогою kubectl:

kubectl apply -f crontabs-migration.yaml

Моніторинг та перевірка міграцій

Контролер StorageVersionMigrator оновлює status обʼєкта StorageVersionMigration у міру виконання міграції. Ви можете переглянути стан міграції за допомогою kubectl:

kubectl get storageversionmigration.storagemigration.k8s.io/crontabs-migration -o yaml

Успішна міграція повідомить про умову Succeeded зі значенням True:

status:
  conditions:
    - type: Running
      status: "False"
      lastUpdateTime: "2026-08-02T10:05:00Z"
      reason: StorageVersionMigrationInProgress
    - type: Succeeded
      status: "True"
      lastUpdateTime: "2026-08-02T10:05:00Z"
      reason: StorageVersionMigrationSucceeded

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

Включення міграцій у ваші маніфести CRD

Оскільки StorageVersionMigration — це стандартний декларативний API Kubernetes, автори CRD можуть постачати або запускати міграції безпосередньо разом з оновленнями CRD. Наприклад, ви можете включити міграцію в той самий маніфест, що й оновлений CustomResourceDefinition:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.example.com
spec:
  group: example.com
  # Оновлений список версій, де v1 має storage: true
  ...
---
apiVersion: storagemigration.k8s.io/v1
kind: StorageVersionMigration
metadata:
  name: crontabs-migration
spec:
  resource:
    group: example.com
    resource: crontabs

Що далі?

Дізнайтеся більше про концепції, що стоять за версіями зберігання.
Прочитайте покроковий посібник: міграція обʼєктів Kubernetes з використанням міграції версії зберігання.

SIG API Machinery буде рада почути ваш відгук, коли ви впроваджуватимете вбудовану міграцію версії зберігання у своїх кластерах. Звертайтеся до нас на каналі #sig-api-machinery у Slack або беріть участь у наших обговореннях у спільноті!

Kubernetes v1.37: Garhwal

Wed, 26 Aug 2026 00:00:00 +0000

Редактори: Arsh Sharma, Christopher Tineo, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Troy Connor

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

Цей випуск складається з 67 вдосконалень. З них 16 стали стабільними, 23 переходять у бета-версію, 27 стали альфа-функціями, а 1 функція визнана застарілою.

Тема та логотип релізу

Темою для Kubernetes v1.37 є Гарвал (गढ़वाल, вимовляється як gaṛhvāl) — гімалайський регіон штату Уттаракханд, Індія. Засніжені вершини Гімалаїв у Гарвалі, ліси деодара, терасові поля, річки та струмки, а також гірські стежки формують як сам регіон, так і логотип. Усі ці елементи разом відображають спільноту, в якій кожен шар, кожен шлях і кожен внесок пов’язані між собою.

Логотип уявляється як вікно в пейзаж Гарвалу.¹ Всередині терасові поля піднімаються до засніжених вершин, кожен рівень підтримується тим, що нижче, так само як кожен випуск Kubernetes залежить від роботи, виконаної раніше. Річка звивається долиною і збирає гірські потоки, відображаючи внески багатьох SIG та спільнот, що об’єднуються в один проєкт.

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

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

У рамці зображений гімалайський монал — державний птах штату Уттаракханд, який мешкає на великих висотах у Гімалаях. Його райдужне пірʼя має безліч кольорів одночасно, подібно до того, як спільнота Kubernetes об’єднує різноманітні навички та погляди в одному проєкті. Квіти червоного буранша (Rhododendron arboreum), державного дерева штату Уттаракханд, мають у центрі символи Kubernetes, поєднуючи знайомий цвіт Гархвала із символом, який поділяє спільнота. На будинку зображено数字 १.३७ (1,37 у цифрах деванагарі), що вкорінює цей реліз у місцевий ландшафт.

_{1. Продовжуйте дивитися у вікно (логотип). Спостерігайте, як тече річка і як прапори майоріють на вітрі. За 37 секунд пейзаж відкриє свою магію.. 😉}

Основні оновлення

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

Stable: Стійка ініціалізація watchcache

Kubernetes v1.37 завершує роботу над стійкою ініціалізацією watchcache: функціональна можливість ResilientWatchCacheInitialization досягла стану Stable ще в v1.34, а в v1.37 інша функціональна можливість WatchCacheInitializationPostStartHook переходить у Stable і заблокована. З v1.36 вона стандартно увімкнена, що посилює API-сервер при старті та під час відновлення. Ініціалізація та повторна ініціалізація watchcache більше не створюють стрибка трафіку запитів до etcd, а запити обробляються коректно замість накопичення під час прогрівання кешу.

Щоб уникнути надмірного навантаження etcd або вичерпання можливостей механізмів API Priority та Fairness через дорогі запити типу «list» та «watch», kube-apiserver тепер безпечно делегує запити з обмеженим обсягом, а інші відхиляє, повертаючи відповіді HTTP 429. Це знижує ризик відмови панелі управління у великих кластерах. Клієнти (включно з власними контролерами та операторами) мають коректно обробляти відповіді HTTP 429 Too Many Requests, дотримуючись заголовків Retry-After та використовуючи експоненційну затримку.

Ця робота була виконана як частина KEP #4568 під керівництвом SIG API Machinery.

Beta: Масштабування HorizontalPodAutoscaler до нуля

У Kubernetes v1.37 підтримка масштабування до нуля для HorizontalPodAutoscaler переходить у Beta. Вперше представлена в Kubernetes v1.16, вона тепер стандартно увімкнена.

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

Масштабування до нуля на основі метрик CPU та памʼяті не підтримується, оскільки ці метрики залежать від активних Podʼів. Натомість ця функція призначена для сценаріїв, коли кількість реплік залишається нульовою, доки не зʼявиться робота в черзі для обробки.

Поки HorizontalPodAutoscaler утримує робоче навантаження з нульовою кількістю реплік, він фіксує стан ScaledToZero зі значенням True у статусі HorizontalPodAutoscaler. Контролер HorizontalPodAutoscaler потім використовує цей стан, щоб відрізнити робоче навантаження, яке він масштабував до нуля (і яке масштабується назад, коли показник повертається), від робочого навантаження, яке було вручну деактивоване встановленням кількості реплік у 0. Коли робоче навантаження масштабується назад, стан встановлюється у False з причиною NotScaledToZero.

Ця робота була виконана як частина KEP #2021 під керівництвом SIG Autoscaling.

Beta: Конфігурація контролю допусків на основі маніфестів

Kubernetes v1.37 переводить конфігурацію контролю допусків на основі маніфестів у Beta. Admission webhooks та політики на основі CEL тепер можуть завантажуватися з маніфестів на диску через поле staticManifestsDir у AdmissionConfiguration, замість того, щоб існувати лише в Kubernetes API. Політики, завантажені таким чином, застосовуються з моменту запуску сервера API, продовжують діяти навіть під час недоступності etcd і можуть захищати самі ресурси допуску на основі API від модифікації.

Ця робота була виконана як частина KEP #5793 під керівництвом SIG API Machinery.

Alpha: Контрольна точка та відновлення на рівні Podʼів

Kubernetes v1.37 представляє підтримку Alpha для контрольних точок та відновлення на рівні Podʼів, розширюючи CRI за допомогою RPC CheckpointPod та RestorePod, які дозволяють kubelet та сумісним рушіям виконання контейнерів створювати контрольну точку Podʼа та відновлювати Podʼа з неї. Щоб використати цю функцію, середовище виконання контейнерів також має реалізувати ці нові RPC.

Ця робота була виконана як частина KEP #5823 під керівництвом SIG Node.

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

Цей розділ перераховує всі функції, що перейшли в Stable (також відомий як стан загальної доступності (GA, General Availability)). Для повного списку оновлень, включаючи нові функції та переходи з Alpha в Beta, дивіться примітки до випуску.

Цей випуск включає загалом 16 вдосконалень, переведених у Stable:

KYAML

KYAML — це безпечніша та менш неоднозначна підмножина YAML, розроблена спеціально для Kubernetes, а не заміна для нього. Кожен файл KYAML є валідним YAML, тож KYAML є валідним вхідним форматом для будь-якої версії kubectl, а файли специфікацій не потрібно писати саме в KYAML, щоб їх можна було обробити. Ваші наявні маніфести, інструменти та конвеєри не потребують змін. KYAML вперше представлений як альфа-функція у v1.34 і перейшов у бета-версію в v1.35. KYAML переходить у стабільний стан у v1.37 після завершення тестування на відповідність, і команда kubectl get -o kyaml тепер також є стабільною.

Щоб дізнатися більше про KYAML, перегляньте допис «Як форматувати ваш Kubernetes YAML у форматі KYAML і навіщо це потрібно».

Ця робота була виконана як частина KEP #5295 під керівництвом SIG CLI.

API metrics.k8s.io

API metrics.k8s.io переходить у Stable в Kubernetes v1.37 після майже девʼяти років у Beta. API надає стандартний спосіб отримання відомостей про використання CPU та памʼяті для podʼів та вузлів, живлячи широко використовувані функції Kubernetes такі як HorizontalPodAutoscaler (HPA) та команди на кшталт kubectl top.

Перехід відповідає цілі проєкту Kubernetes уникати постійних API у Beta. Тепер, коли v1 існує, майбутні випуски Kubernetes перейдуть на нього; v1beta1 залишається придатним для використання протягом переходу, відповідно до політики застарівання API, тому ви можете прийняти Stable API, не ламаючи існуючі робочі процеси.

Ця робота була виконана як частина KEP #5207 під керівництвом SIG Instrumentation.

`SELinuxMount` та `SELinuxChangePolicy`

У Kubernetes v1.37 прапорці SELinuxMount та SELinuxChangePolicy переходять у Stable і стандартно ввімкнені: це означає, що томи монтуються з -o context=<label> (типово MountOption) замість рекурсивного перейменування, але лише коли CSI драйвер тому обирає через .spec.seLinuxMount: true для обʼєкта CSIDriver.

Монтування може нести лише один контекст SELinux, тому Podʼи з різними мітками SELinux, що разом використовують том на одному вузлі, які раніше співіснували під час рекурсивного перейменування, тепер можуть не запуститися. Щоб зберегти стару поведінку для роботи, рекомендується встановити .spec.seLinuxChangePolicy у Recursive для Pod.

Ця поведінка сама по собі не заблокована до v1.38, тому відключення її на рівні кластера залишається варіантом на ще один випуск. Кластери без увімкненого SELinux не відчувають жодного ефекту. Щоб дізнатися більше, перегляньте Зміни міток томів SELinux переходять у GA (і ймовірні наслідки в v1.37).

Ця робота була виконана як частина KEP #1710 під керівництвом SIG Storage.

Функції DRA, що переходять у стабільний стан

DRA: Статус ResourceClaim з можливими стандартизованими даними мережевого інтерфейсу

Статус .status.devices ResourceClaim переходить у Stable в Kubernetes v1.37, що дозволяє драйверам повідомляти специфічні для пристрою дані статусу для кожного виділеного пристрою в заявці на ресурс. Це полегшує розуміння того, як налаштовано пристрій, усунення несправностей та використання пристрою разом з іншими сервісами.

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

Ця робота була виконана як частина KEP #4817 під керівництвом SIG Node та SIG Network.

DRA: обробка запитів розширених ресурсів через драйвер DRA

Підтримка розширених ресурсів DRA переходить у Stable в Kubernetes v1.37. Ця функція дозволяє драйверам DRA задовольняти запити, зроблені через традиційний механізм розширених ресурсів, наприклад abc.example/gpu: 3 у специфікації Podʼа, без необхідності окремого втулка пристрою.

За допомогою цього механізму імʼя розширеного ресурсу може бути призначене безпосередньо DeviceClass. Podʼи, що запитують цей ресурс, можуть мати пристрій, виділений через DRA, без необхідності визначати ResourceClaim у робочому навантаженні.

Ця робота була виконана як частина KEP #5004 під керівництвом SIG Scheduling.

DRA: позначки taint та toleration пристроїв

Підтримка taints та tolerations для фізичних пристроїв, керованих через DRA, тепер є Stable в Kubernetes v1.37. Стандартно будь-який доступний пристрій може розглядатися для планування. Це вдосконалення надає більший контроль над плануванням пристроїв, дозволяючи драйверам DRA позначати конкретні пристрої позначкою taint, запобігаючи їхньому вибору для робочих навантажень. Крім того, адміністратори кластера можуть створити DeviceTaintRule для позначення пристроїв як taint на основі конкретних критеріїв відбору, наприклад, усіх пристроїв, керованих певним драйвером.

Ця робота була виконана як частина KEP #5055 під керівництвом SIG Scheduling.

DRA: стандартний атрибут пристрою numaNode

Kubernetes v1.37 визначає новий стандартний атрибут пристрою NUMA-вузла. Він стандартизує resource.kubernetes.io/numaNode як спільне імʼя атрибуту для інформації про NUMA-вузол пристрою, дозволяючи пристроям, керованим різними драйверами DRA, порівнюватися на основі одного й того ж NUMA-вузла. Це дозволяє уникати ситуації, коли кожен драйвер визначає власну назву атрибуту, і надає послідовний спосіб ідентифікації NUMA-розміщення між пристроями. Це вдосконалення одразу переходить у стабільний стан, оскільки це KEP щодо іменування та реєстрації без функціональної можливості чи змін поведінки в кодовій базі.

Ця робота була виконана як частина KEP #6072 під керівництвом SIG Node.

Функції, оголошені вузлом

Функції, оголошені вузлом переходять у Stable в Kubernetes v1.37, надаючи фреймворк для оголошення доступності конкретних, керованих функціональними можливостями функцій Kubernetes для вузлів. Ці функції потім використовуються компонентами панелі управління (такими як kube-scheduler, контролери допуску або сам API-сервер) для керування розбіжністю версій (version skew).

Функція вводить нове поле .status.declaredFeatures для вузлів, яке використовується для оголошення функції, що проходить через етапи Alpha → Beta → Stable. Панель управління може використовувати це поле для забезпечення правильної роботи навіть у кластері, де одночасно працюють вузли з різними версіями.

Коли функції переходять у Stable і панель управління може припустити, що всі вузли підтримують їх у межах вікна розбіжності версій, вузли припиняють повідомляти про них.

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

Ця робота була виконана як частина KEP #5328 під керівництвом SIG Node.

Мігратор версій сховища

Kubernetes v1.37 переводить API StorageVersionMigration (storagemigration.k8s.io/v1) у Stable і стандартно його вмикає. Він допомагає виконувати мігрувацію наявних ресурсів, як вбудованих, так і власних ресурсів користувача, зі старішої версії сховища на нову після оновлення API, наприклад, коли бажана версія сховища змінюється з v1beta1 на v1. Його також можна використати для перезапису наявних даних після зміни шифрування у стані спокою, щоб застарілі дані зберігалися з новими налаштуваннями шифрування.

Історично адміністраторам кластерів та авторам CustomResourceDefinition доводилося використовувати ручні скрипти kubectl get або kubectl replace, або розгортати out-of-tree компонент kube-storage-version-migrator для переписування наявних ресурсів. Ці підходи часто були важкими, схильними до помилок і важкими для моніторингу.

Щоб розпочати міграцію версії сховища, користувачам потрібно створити декларативний обʼєкт StorageVersionMigration. Вбудований контролер StorageVersionMigrator у панелі управління Kubernetes слідкує за цими обʼєктами і виконує автоматичну міграцію наявних ресурсів до базової версії сховищення для цього API. Оскільки StorageVersionMigration є стандартним Kubernetes API, автори CRD можуть запускати міграції як частину оновлення CRD замість окремого керування міграцією.

Ця робота була виконана як частина KEP #4192 під керівництвом SIG API Machinery.

Stable: Сертифікати Podʼів та Cluster Trust Bundles

Сертифікати Podʼів та тісно повʼязані ClusterTrustBundles обидва переходять у Stable в Kubernetes v1.37, надаючи першокласну підтримку для розповсюдження приватних ключів, X.509 сертифікатів та пакунків довіри до Podʼів.

Щоб це використати, розробник або адміністратор обирає імʼя підписувача і розгортає контролер підписувача, який спостерігає за обʼєктами PodCertificateRequest, видає та оновлює сертифікати для придатних Podʼів і підтримує відповідні обʼєкти ClusterTrustBundles, що містять довірчі точки (trust anchors), необхідні для перевірки цих сертифікатів. Робоче навантаження потім підключається до цієї ідентичності, визначаючи проєкційний том podCertificate з обраним імʼям підписувача. Робочі навантаження також можуть монтувати проєкційний том ClusterTrustBundle для завантаження інформації про довірчі точки.

Ця робота була виконана як частина двох KEP — KEP #4317 та KEP #3257 під керівництвом SIG Auth.

Функції, що перейшли в Beta

Підтримка групового планування (Gang scheduling) в Kubernetes

Оскільки Kubernetes стає де-факто стандартом для керування AI/ML навантаженнями в масштабі, планування таких робіт, як тренування AI/ML моделей та HPC-симуляції, стає важливішим ніж будь-коли. Однак планування стає викликом, оскільки стандартний планувальник Kubernetes планує Podʼи індивідуально, що може призвести до того, що деякі Podʼи плануються, тоді як інші залишаються у стані очікування через нестачу ресурсів. Таке часткове планування може призвести до взаємних блокувань (deadlock) та неефективного використання ресурсів кластера.

Групове планування (Gang scheduling) переходить у Beta в Kubernetes v1.37, вдосконалюючи нативну підтримку групового планування через Workload API та концепцію PodGroup. Ця функція реалізує стратегію планування «все або нічого», забезпечуючи, що визначена група Podʼів планується лише тоді, коли кластер має достатньо ресурсів для розміщення всієї групи. Перехід у Beta також вводить планування з урахуванням навантаження (workload-aware preemption), щоб уникнути передчасних витіснень, які не допомагають навантаженню просуватись в роботі, а також чергування PodGroup для кращої координації конкуруючих навантажень.

Важливо, що це вирішує сценарії активного очікування (livelock), які можуть виникати, коли кілька навантажень плануються одночасно kube-schedulerʼом, запобігаючи їхньому взаємному блокуванню без прогресу.

Ця робота була виконана як частина KEP #4671 під керівництвом SIG Scheduling.

Нативна підтримка гістограм для метрик Kubernetes

Kubernetes експонує сотні метрик-гістограм у форматі Prometheus у компонентах панелі управління, які є необхідними для моніторингу стану кластера та відстеження проблем продуктивності. Однак класичні гістограми Prometheus покладалися на статичні, заздалегідь визначені кошики (buckets), що змушувало йти на компроміс між точністю даних та використанням памʼяті. Для помʼякшення цього Prometheus представив нативні гістограми, які використовують динамічні експоненційні межі кошиків замість фіксованих, забезпечуючи значну ефективність зберігання, покращену продуктивність запитів та детальнішу видимість розподілів, зберігаючи при цьому повну зворотну сумісність з наявною інфраструктурою моніторингу.

Kubernetes v1.37 переводить нативну підтримку гістограм для метрик Kubernetes у бета-версію. Базуючись на реалізації Alpha, яка ввела функціональну можливість NativeHistograms, фаза Beta покращує реалізацію та досвід розгортання. Коли увімкнено, компоненти Kubernetes експонують гістограми як у класичному, так і в нативному форматах, коли запитуваний протокол скрейпінгу підтримує Нативні Гістограми (зокрема PrometheusProto), дозволяючи наявним дашбордам та сповіщенням продовжувати працювати, поки користувачі виконують міграцію у власному темпі. Реалізація також переробила гістограми, створені в функціях init(), для використання лінивої ініціалізації, гарантуючи, що опції нативних гістограм правильно застосовуються після обробки функціональних можливостей. Ці зміни надають більш надійну реалізацію, зберігаючи при цьому безпечні розгортання та відкат через функціональну можливість або конфігурацію на стороні Prometheus для користувачів Prometheus 3.x.

Ця робота була виконана як частина KEP #5808 під керівництвом SIG Instrumentation.

WAS: Функції, що переходять у Beta

Витіснення з урахуванням навантаження

Традиційно Kubernetes виконує витіснення на рівні Podʼів, що може бути неефективним для навантажень, що складаються з кількох тісно повʼязаних Podʼів. У Kubernetes v1.37 витіснення з урахуванням навантаження (workload-aware preemption, WAP) переходить у Beta, дозволяючи планувальнику враховувати PodGroup при прийнятті рішень про витіснення. Це допомагає планувальнику розглядати навантаження як єдину сутність при витісненні навантажень нижчого пріоритету, зменшуючи випадки, коли індивідуальні Podʼи витісняються без забезпечення достатньої потужності для роботи корисного навантаження.

Ця робота була виконана як частина KEP #5710 під керівництвом SIG Scheduling.

DRA: Підтримка ResourceClaim для навантажень

Dynamic Resource Allocation (DRA) дозволяє Podʼам запитувати спеціалізовані ресурси через ResourceClaims. У Kubernetes v1.37 підтримка DRA ResourceClaims для навантажень переходить у Beta, дозволяючи Workload та PodGroup API асоціювати ResourceClaims та ResourceClaimTemplates з групами Podʼів. Це дозволяє ResourceClaims бути спільними для всього навантаження замість індивідуального резервування для кожного Podʼа, тоді як ResourceClaimTemplates можуть автоматично створювати claims для PodGroup.

Ця робота була виконана як частина KEP #5729 під керівництвом SIG Scheduling.

Статистика контейнерів та Podʼів без cAdvisor, повністю через CRI

kubelet історично отримував статистику контейнерів та Podʼів з cAdvisor, тоді як Container Runtime Interface (CRI) експонував власну статистику. Наявність двох джерел для однакових метрик ускладнює розуміння, звідки взялося конкретне значення.

У Kubernetes v1.37 покращення «статистика контейнерів та Podʼів без cAdvisor, повністю через CRI» переходить у Beta. Це покращення розширює CRI для надання статистики контейнерів та Podʼів, необхідної Kubernetes, дозволяючи kubelet отримувати ці метрики безпосередньо від рушія виконання контейнерів замість залежності від cAdvisor.

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

Ця функція є Beta у v1.37, але стандартно вимкнена; увімкніть функціональну можливість PodAndContainerStatsFromCRI, щоб спробувати її.

Ця робота була виконана як частина KEP #2371 під керівництвом SIG Node.

Підтримка memory QoS з cgroups v2

Kubernetes покращує свої механізми якості обслуговування (QoS) для покриття захисту та ізоляції памʼяті для навантажень Kubernetes. Для вузлів, що працюють на Linux, функція memory QoS використовує запити та ліміти памʼяті для налаштування cgroup-контролів, які можуть захистити запитану памʼять від відновлення (reclamation) та обмежити (throttle) використання памʼяті до досягнення жорстких лімітів навантаженням. Це може допомогти зменшити вплив тиску памʼяті на чутливі до памʼяті навантаження та покращити стабільність вузла.

У Kubernetes v1.37 підтримка memory QoS переходить у Beta. Функція використовує cgroups v2 контролі памʼяті, такі як memory.min, memory.low та memory.high, для надання різних рівнів захисту памʼяті та обмеження. Наприклад, запити памʼяті можуть використовуватися для захисту памʼяті від відновлення, тоді як memory.high може використовуватися для обмеження навантажень, що перевищують свої налаштовані пороги.

Функціональна можливість MemoryQoS стандартно увімкнена у v1.37. Оператори кластерів можуть контролювати захист памʼяті через налаштування memoryReservationPolicy у kubelet та налаштовувати обмеження памʼяті за допомогою memoryThrottlingFactor. Типово вони розроблені так, щоб уникнути несподіваного обмеження памʼяті для існуючих навантажень при оновленні до v1.37, одночасно дозволяючи операторам підключитися до додаткових можливостей захисту памʼяті.

Ця робота була виконана як частина KEP #2570 під керівництвом SIG Node.

Менеджери ресурсів на рівні Podʼів

У Kubernetes v1.37 менеджери ресурсів на рівні Podʼів переходять у Beta з функціональною можливістю PodLevelResourceManagers, яка залишається стандартно вимкненою. Її увімкнення дозволяє менеджерам топології, CPU та памʼяті використовувати ресурси, визначені для всього Podʼа, при прийнятті рішень про виділення та NUMA-вирівнювання. Це робить можливим керування Podʼом як єдиною одиницею ресурсів, одночасно підтримуючи різні вимоги до ресурсів між контейнерами всередині нього.

З управлінням ресурсів на рівні Podʼа, Pod може резервувати NUMA-вирівняний пул CPU та памʼяті на основі свого загального ресурсного бюджету. Контейнери, що вимагають виділених ресурсів, можуть отримати ексклюзивні частини цього пулу, тоді як інші контейнери, такі як sidecar або підтримуючі навантаження, можуть спільно використовувати залишкові ресурси. Це особливо корисно для промислових чутливих навантажень, таких як AI/ML та HPC, де зберігання ресурсів близько один до одного на одному NUMA-вузлі може покращити продуктивність без вимоги, щоб кожен контейнер у Podʼі мав виділені ресурси.

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

Ця робота була виконана як частина KEP #5526 під керівництвом SIG Node.

Узгоддження контролера маршрутів на основі watch (Watch-based route controller reconciliation)

Контролер маршрутів у бібліотеці cloud-controller-manager раніше виконував узгодження маршрутів за фіксованим інтервалом, типово кожні 10 секунд. Це могло призводити до непотрібних запитів до провайдерів інфраструктури, навіть коли нічого не змінювалося, а також затримувати оновлення маршрутів при додаванні нового вузла.

Узгодження контролера маршрутів на основі watch перейшло в Beta в Kubernetes v1.37. Цей випуск також додає спостережуваність для цієї роботи: Alpha-метрика контролера маршрутів route_sync_total отримує дві мітки — trigger (periodic або node_change) та outcome (changed, noop або error), щоб оператори могли бачити, чи періодична реконсиляція дійсно виправляє дрифт маршрутів або просто працює як no-op, і відстежувати невдалі узгодження.

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

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

Ця робота була виконана як частина KEP #5237 під керівництвом SIG Cloud Provider.

Оцінка ємності сховища вузлів

Втулок планувальника VolumeBinding завжди міг робити оцінку (scoring) вузлів для статично привʼязаних PV на основі вільної ємності, але ця оцінка ніколи не поширювалася на динамічне провизионування.

Коли CSI-драйвер провизионує новий том за запитом, планувальник не мав способу віддати перевагу вузлу з більшою або меншою вільною областю.

Це було прогалиною для локального сховища, оскільки адміністратор міг хотіти, щоб Podʼи потрапляли на вузол з найбільшою вільною ємністю, щоб залишити місце для пізнішого розширення тома, або на вузол з найменшою (але все ще достатньою) вільною ємністю, щоб упакувати навантаження щільніше (bin-pack) і зменшити кількість вузлів, необхідних для роботи хмарного кластера.

Kubernetes v1.37 переводить оцінювання ємності сховища для динамічного провізіонування у бета-версію за допомогою функціональної можливості StorageCapacityScoring. Її вперше представили в альфа-версії в v1.33, а ця функція обʼєднує й оголошує застарілою старішу функціональну можливість VolumeCapacityPriority з KEP #1845. Коли її увімкнено, точка розширення Score втулка VolumeBinding зчитує обʼєкти CSIStorageCapacity, опубліковані зовнішнім sidecar-контейнером провізіонера драйвера, й оцінює вузли для динамічного провізіонування так само, як уже робить для статичних привʼязок. Адміністратори обирають стратегію через параметр Shape у VolumeBindingArgs — типово це «надавати перевагу вузлу з максимальною доступною ємністю», щоб залишити простір для подальшого розширення.

Функція залежить виключно від функціональної можливості StorageCapacityScoring: оцінка для статично привʼязаних PV запускається одразу при увімкненні, незалежно від будь-якого CSI-драйвера. Драйверу потрібно лише StorageCapacity: true на своєму обʼєкті CSIDriver, щоб його динамічно надані томи також отримували оцінку з урахуванням ємності. Функція повністю зворотня, і вимкнення функціональної можливості зупиняє всю оцінку ємності VolumeBinding, як статичну, так і динамічну, без впливу на вже заплановані Podʼи.

Ця робота була виконана як частина KEP #4049 під керівництвом SIG Storage.

Інтеграція CSI лімітів підключення томів з Cluster Autoscaler

У Kubernetes v1.37 покращено інтеграцію Cluster Autoscaler з обмеженнями підключення томів CSI, завдяки чому під час створення нових вузлів для Podʼів, що очікують на обробку, Cluster Autoscaler може точніше визначити, скільки нових вузлів потрібно для підключення всіх Podʼів, що очікують на обробку та використовують томи CSI. Cluster Autoscaler вже мав доступ до інформації про обмеження підключення томів CSI для наявних вузлів, але не для вузлів, які він збирався створити, що означало: він міг недостатньо масштабувати систему і залишати Podʼи, що використовують томи, у стані очікування навіть після додавання ємності. Проблема ускладнюється з боку планування: втулок NodeVolumeLimits розглядає вузол без опублікованої інформації про драйвер CSI як такий, що не має жодних обмежень, тому щойно створений вузол, який ще не повідомив про свій об’єкт CSINode, може бути переповнений більшою кількістю Podʼів, підкріплених томами, ніж він фактично може підключити, що є конкурентною ситуацією, яку дотепер адміністратори кластерів не мали можливості усунути.

У версії Kubernetes v1.37 функція автоматичного масштабування з підтримкою CSI переходить у стадію бета-тестування з функціональною можливістю VolumeLimitScaling, яка вперше була представлена у версії v1.35 у стадії альфа-тестування. Cluster autoscaler тепер запускає симуляції масштабування вгору для шаблонних обʼєктів CSINode, щоб правильно враховувати ліміти підключення, чи то він масштабує наявну групу вузлів, чи створює її з нуля. З боку планувальника, адміністратори можуть підключитися на рівні CSIDriver, через нове поле PreventPodSchedulingIfMissing, щоб заблокувати розміщення Podʼів на вузлах, що ще не повідомили свій драйвер, з виділеними помилками CSIDriverMissingOnNode та CSINodeMissing, що роблять ці помилки планування легшими для відстеження. Фаза Beta додає наскрізне покриття для поведінки масштабування вниз та сценаріїв CSI opt-in, та оновлює метрики failed_scale_ups_total та scaled_up_nodes_total, щоб включати інформацію про CSI-драйвери. Зміни як в автомасштабувачі, так і в планувальнику залишаються суто опціональними: вимкнення функціональної можливості відновлює поточне стандартне значення — необмежене розміщення подів на вузлах без даних CSINode, тому дистрибутиви та адміністратори, які використовують автомасштабувачі, що ще не підтримують CSI (наприклад, Karpenter), не змушені переходити на нову модель роботи.

Ця робота була виконана як частина KEP #5030 під керівництвом SIG Autoscaling.

Звіт про час останнього використання PVC

PersistentVolumeClaims зазвичай живуть довше за навантаження, що їх створили. Коли застосунок видаляється або мігрує, його PVC залишається, споживаючи сховище та збільшуючи витрати. Сьогодні Kubernetes не дає адміністраторам кластерів жодного способу дізнатися, як довго PVC просидів бездіяльно; kubelet є єдиним компонентом, який дійсно знає, коли том був змонтований останній раз, але немає чогось що не виводить цю інформацію на рівні API, тому адміністратори залишаються вгадувати, які PVC насправді безпечні для очищення.

Kubernetes v1.37 переводить відстеження «останнього використання» PVC у Beta з функціональною можливістю PersistentVolumeClaimUnusedSinceTime, яка у Alpha (v1.36) була стандартно вимкнена, а тепер стандартно увімкнена. Функція додає новий стан Unused до PersistentVolumeClaimStatus, якою керує наявний контролер захисту PVC: Status=True (Reason=NoPodsUsingPVC) коли останній нетермінальний Pod, що посилається на PVC, зникає, і назад до Status=False (Reason=PodUsingPVC) якомога швидше, як тільки Pod починає посилатися на нього знову. lastTransitionTime цього стану використовується як позначка часу «невикористано з», тому адміністратори можуть запитати, та як довго PVC дійсно просидів бездіяльно, без того, щоб Kubernetes відстежував, який саме Pod використав його останнім, чи приймав будь-які рішення про видалення — це залишається повністю на розсуд адміністратора. Варто зазначити, що позначка часу відображає момент, коли контролер спостерігав відсутність Podʼів, що використовують PVC, а не точний момент розмонтування тома на рівні інфраструктури, тому повідомлений час бездіяльності може бути дещо меншим за справжній, але ніколи не перевищить його.

Ця робота була виконана як частина KEP #5541 під керівництвом SIG Storage.

Підтримка etcd RangeStream

Унарний RPC-виклик Range в etcd формує повну відповідь у пам’яті перед її відправкою, що стає проблемою при масштабуванні. У випадку великого списку, наприклад, під час розігріву кешу спостереження kube-apiserver у великому кластері, необроблений фрагмент «ключ-значення», його серіалізована форма protobuf та буфер відправки gRPC мають одночасно співіснувати в пам’яті, а внаслідок цього спалахи навантаження поширюються й на kube-apiserver. Разбиття на сторінки також не вирішує проблему базових витрат, оскільки кожна сторінка все одно проходить весь індекс B-дерева для обчислення загальної кількості результатів, перетворюючи операцію, яка мала б бути O(limit), на операцію O(total_keys) для кожної окремої сторінки.

У Kubernetes v1.37 підтримка etcd RangeStream надається безпосередньо у версії Beta, з функціональною можливістю EtcdRangeStream (лише для kube-apiserver, стандартно увімкнено). У цьому випуску додано новий RPC-інтерфейс RangeStream для потокової передачі на сервері, який використовує наявний RangeRequest але повертає фрагменти замість одного буферованого блоку: сервер внутрішньо розбиває дані на сторінки з адаптивним розміром фрагментів (цільовий розмір кожного фрагмента коригується на основі MaxRequestBytes та розмірів значень, зафіксованих на даний момент), фіксує одну ревізію MVCC, щоб об’єднаний потік залишався узгодженим зі знімком, та обчислює загальну кількість ключів на основі поточного підрахунку, який формується під час потокової передачі, а не шляхом окремого обходу індексу. Ініціалізація кешу спостереження kube-apiserver є основним споживачем, і тепер вона декодує кожен фрагмент у синтетичні події created безпосередньо під час їх надходження, замість того, щоб спочатку збирати повний список у пам’яті; така сама обробка застосовується до прямих викликів GetList, коли WatchList вимкнено.

Ця функція вимагає etcd версії 3.7 або вище; у разі використання старішої версії etcd, kube-apiserver виявляє відповідь Unimplemented і автоматично переходить на унарний Range, без жодних змін у поведінці. Якщо закріплена ревізія ущільнюється в процесі роботи, kube-apiserver трактує це так само, як і будь-яку іншу помилку ініціалізації кешу спостереження, і робить повторну спробу, що не гірше, ніж гонитви за ущільнення, з якими вже сьогодні може зіткнутися виклик List з розбиттям на сторінки. Критерії виходу з бета-версії включають тест на масштабованість, що вимірює затримку при роботі з великими списками на кластері з 5000 вузлів, а команда etcdctl get --stream поставляється разом із нею для тих, хто хоче безпосередньо протестувати новий RPC.

Ця робота була виконана як частина KEP #5966 під керівництвом SIG etcd.

Конкурентне декодування обʼєктів watch

kube-apiserver декодує та перетворює кожну подію спостереження з etcd по черзі в одній goroutine, тому одне повільне перетворення на подію, зокрема виклик вебхука для конвертації CRD, блокує всі події, що стоять у черзі за ним. Це здебільшого створює незручності для вбудованих ресурсів, але для CRD, версія якого в сервісі відрізняється від збереженої, послідовне перетворення «холодного» кешу може займати кілька хвилин. Якщо це перевищує стандартний 5-хвилинний інтервал ущільнення etcd, ревізія, з якої кеш почав читати, ущільнюється до завершення ініціалізації, спостереження не може поновитися, а ініціалізація просто перезапускається і ніколи не завершується для достатньо великого ресурсу, при цьому кожен клієнт, який намагається перелічити або спостерігати за ним, отримує помилки.

Функціональна можливість ConcurrentWatchObjectDecode фактично була у Beta, стандартно вимкнена, з v1.31, і Kubernetes v1.37 стандартно увімкнув її. Це увімкнення переміщує крок декодування/трансформації на обмежений пул робітничих goroutines (10 типово, налаштовано з перебору, що показав, що вигоди отримуються навколо 8–12) замість однієї, з колектором, що збирає події назад у їхній оригінальний порядок перед доставкою, тому порядок подій зберігається точно. У бенчмарках на 150k+ podʼах, лише паралельне декодування скорочує ініціалізацію кешу приблизно на 40%, а приблизно на 55% в поєднанні з новою функцією EtcdRangeStream, що також виходить в цьому випуску (див. KEP 5966). Головний компроміс, за яким варто слідкувати — навантаження на conversion webhook. З увімкненою функцією, до 10 конвертацій тепер можуть одночасно виконуватися для webhookʼа під час ініціалізації кешу замість однієї за раз. Загальний обсяг викликів не змінюється, лише кількість, що виконуються одночасно, отже це переважно стосується webhookʼів, які обмежують власну конкурентність нижче 10.

Ця робота була виконана як частина KEP #6178 під керівництвом SIG API Machinery.

Заходи щодо усунення наслідків використання застарілого контролера

Кожен контролер у kube-controller-manager працює з локального кешу, побудованого шляхом спостереження за kube-apiserver, а цей watch-потік є лише зрештою консистентним. Зміна може зʼявитися за мілісекунди, або це може зайняти секунди чи навіть хвилини під навантаженням. Наразі оператори не мають уявлення про це відставання і не можуть відрізнити нормальну затримку від ситуації, коли контролер небезпечно втратив синхронізацію, тому контролер може продовжувати узгоджувати свої дані з уявленням про стан системи, яке вже є застарілим.

Заходи щодо мінімізації ризиків, пов’язаних із застарілими контролерами, перебувають у стадії бета-тестування з версії v1.36 і є стандартними для кожного контролера за функціональною можливісьтю StaleControllerConsistency<Controller>; у Kubernetes v1.37 ці заходи поширено на контролер HorizontalPodAutoscaler та додано варіант із механізмом відключення (circuit-breaking) і додаткові метрики, описані нижче. Основний механізм — це гарантія read your writes: ResourceEventHandlerFuncs у client-go отримує новий callback BookmarkFunc, щоб контролер міг надійно відстежувати версію ресурсу обʼєктів, які йому цікаві, навіть через крайні випадки, які наявні callbackʼи add/update/delete пропускають. Контролер записує версію ресурсу власних записів і, при наступному узгодженні, пропускає та повторно ставить у чергу, доки його інформер-кеш дійсно не наздогнав цей запис. Контролер DaemonSet — хороший приклад цього. Він відстежує версії ресурсів DaemonSet → Pod, щоб не переузгоджувати проти власного застарілого pod-кешу. Другий, circuit-breaking варіант націлений на контролери, чутливі до затримок, на кшталт node-lifecycle, які інакше могли б прочитати застарілий node lease з кешу і помилково вирішити, що він закінчився; замість цього він робить живий GET на руйнівному рішенні і позначає свій кеш як «not ready», доки він не догонить його, замість того щоб діяти на основі застарілого читання. StaleControllerConsistency контролює саму процедуру пом’якшення наслідків (спочатку застосовується до контролерів, які KCM позначив як великомасштабні), MonitorInformerStaleness — це окремий контрольний механізм, призначений лише для спостереження, який кожні 5 секунд безпосередньо опитує apiserver виключно для того, щоб виявити, наскільки насправді відстає кеш інформера, а AtomicFIFO / UnlockWhileProcessingFIFO — це базові механізми черги завдань client-go, від яких залежить робота механізму помʼякшення наслідків. Ніщо з цього не змінює стандартну поведінку узгоджувача; контролер, який було призупинено та знову поставлено в чергу, може здаватися застряглим, хоча насправді він просто чекає на свій кеш, і він коректно відкочується, оскільки жодна його дія не є незворотною.

Ця робота була виконана як частина KEP #5647 під керівництвом SIG API Machinery.

Конфігурація контролю допуску на основі маніфесту

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

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

Ця робота була виконана як частина KEP #5793 під керівництвом SIG API Machinery

Покращена обробка нерозшифровуваних ресурсів

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

Kubernetes v1.37 включає Beta підтримку для адміністраторів кластерів для ідентифікації та видалення ресурсів, які не можуть бути розшифровані API-сервером.

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

Ця робота була виконана як частина KEP #3926 під керівництвом SIG Auth.

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

Нова стратегія `Recreate` для розгортання StatefulSet

Kubernetes v1.37 вводить стратегію Recreate для розгортання StatefulSet. StatefulSet API раніше пропонував лише дві стратегії оновлення: OnDelete (ручна) та RollingUpdate (автоматична, типово). Схоже на Deployments, стратегія оновлення Recreate видаляє всі Podʼи StatefulSet перед створенням нових Podʼів, що відображають модифікації, зроблені до .spec.template StatefulSet. Використання цієї стратегії вимагає увімкнення функціональної можливості StatefulSetRecreateStrategy.

Ця робота була виконана як частина KEP #3541 під керівництвом SIG Apps.

DRA: Alpha функції, на які варто звернути увагу

DRA: Запит на ресурси, що розподіляються вузлом

Kubernetes v1.37 покращує Alpha підтримку керування ресурсами вузла, такими як CPU, памʼять та huge pages, через DRA. Це обʼєднує стандартний та DRA облік ресурсів, допомагаючи запобігти подвійному рахуванню однієї й тієї ж можливості вузла.

Це оновлення вводить окремі API-поля для mapping (для пристроїв, що безпосередньо моделюють основні ресурси, на кшталт CPU/памʼяті DRA драйверів) та overhead (як допоміжна хост-памʼять для пристроїв прискорення). Kubelet тепер примушує ці виділення між pod та container cgroups, інтегрує їх з Memory QoS, розрахунками OOM score та in-place зміною розміру podʼа.

Ця робота була виконана як частина KEP #5517, під керівництвом SIG Scheduling з участю SIG Node.

DRA: Похідні атрибути

Kubernetes v1.37 вводить Alpha підтримку похідних атрибутів у DRA. Навантаження можуть використовувати CEL-вирази для створення віртуальних атрибутів з інформації про пристрої та використання їх при виборі повʼязаних пристроїв.

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

Ця робота була виконана як частина KEP #6080, під керівництвом SIG Scheduling з участю SIG Network.

DRA: Групи сумісності пристроїв

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

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

Ця робота була виконана як частина KEP #5963, під керівництвом SIG Scheduling.

Витіснення планувальником для in-place зміни розміру Podʼа

Kubernetes v1.37 вводить витіснення планувальником для in-place зміни розміру podʼа, за (opt-in, Alpha) функціональною можливістю InPlacePodVerticalScalingSchedulerPreemption. Ця зміна вирішує важливу прогалину функціоналу, що залишилася після того, як основна функція вертикального масштабування Podʼа на місці перейшла в Stable: якщо запущений pod запитував додаткові ресурси, що перевищували доступну ємність вузла, kubelet позначав запит як Deferred, залишаючи pod очікувати, поки достатньо ресурсів не стане доступними на вузлі. Завдяки цьому вдосконаленню панель управління Kubernetes може активно звільняти ємність на повністю завантаженому вузлі та витісняти навантаження з нижчим пріоритетом, дозволяючи відкладеним in-place запитам на зміну розміру критичних застосунків з вищим пріоритетом успішно завершитися.

Ця робота була виконана як частина KEP #5836 під керівництвом SIG Scheduling.

Динамічна зміна розміру memory-backed томів

Також спираючись на вертикальне масштабування Podʼів «на місці», функція Alpha масштабування на місці для томів, що підтримуються памʼяттю розширює субресурс pod /resize, який раніше дозволяв лише динамічне регулювання CPU та памʼяті без перезапуску контейнерів, щоб підтримати оновлення параметра sizeLimit томів emptyDir, що підтримуються памʼяттю (medium: Memory), у запущених Podʼах. Коли параметр sizeLimit тома явно регулюється за допомогою субресурсу /resize, Kubelet динамічно оновлює базове монтування tmpfs без переривання роботи контейнера, одночасно надійно запобігаючи помилкам нестачі памʼяті або помилковим спрацьовуванням механізмів витіснення. Це особливо корисно для робочих навантажень із збереженням стану та з інтенсивним використанням памʼяті, які покладаються на тимчасове зберігання даних у памʼяті, що дозволяє їм динамічно масштабувати межі зберігання разом із об’ємом пам’яті контейнера без перезапуску подів або простоїв застосунків.

Це альфа-функція, яка вмикається за бажанням користувача і зазвичай вимкнена. Щоб спробувати її, увімкніть функціональну можливість InPlacePodVerticalScalingMemoryBackedVolumes.

Ця робота була виконана як частина KEP #6030 під керівництвом SIG Node та SIG Storage.

Спеціалізоване управління життєвим циклом вузлів

Декілька компонентів Kubernetes потребують інформації про стан життєвого циклу вузла, і на сьогодні кожен із них визначає його на основі різного поєднання готовності вузла, позначок taint, стану Pod, міток, анотацій та API-інтерфейсів провайдерів. Це вдосконалення запроваджує загальновизнані умови життєвого циклу для вузлів, надаючи адміністраторам єдине місце в Kubernetes для публікації стану життєвого циклу, яке можуть використовувати основні контролери та інструменти екосистеми. Ці нові умови вузлів (Node Conditions) такі: DrainInProgress, Drained, MaintenancePlanned, MaintenanceInProgress та GracefulNodeShutdownInProgress

Ця робота була виконана як частина KEP #5683 під керівництвом SIG Node.

WAS: Alpha функції, на які варто звернути увагу

CompositePodGroup API

Попередні випуски вводили підтримку групового планування навантажень з плоскою структурою, сучасні AI/ML навантаження є складними і мають більш витончені вимоги до планування. У Kubernetes v1.37 новий Alpha CompositePodGroup API дозволяє Kubernetes описувати складні навантаження як ієрархію груп замість плаского набору Podʼів. Це дозволяє багаторівневе групове планування, workload-aware preemption та topology-aware планування.

Ця робота була виконана як частина KEP #6012 під керівництвом SIG Scheduling.

API контролера планування з урахуванням навантаження

Як Alpha функція, в Kubernetes v1.37 надається спільний фреймворк для інтеграції контролерів навантажень (таких як JobSet, TrainJob, LWS, та RayJob, поряд з основними навантаженнями, такими як Job) з Workload-aware Scheduling (WAS). Які функція альфа-версії, Kubernetes v1.37 надає загальну платформу для інтеграції контролерів робочих навантажень (таких як JobSet, TrainJob, LWS та RayJob, а також основних робочих навантажень, таких як Job) із плануванням з урахуванням робочих навантажень (WAS).

Ця робота була виконана як частина KEP #6089 під керівництвом SIG Scheduling.

Інтеграція Workload API з Job контролером

Спочатку введена в Kubernetes v1.36 з обмеженим функціоналом, ця функція будує на Workload Aware Scheduling Controller APIs, додаючи нове поле spec.scheduling для користувача до batch/v1 Job у Kubernetes v1.37, дозволяючи користувачам явно конфігурувати політики планування, обмеження топології, режими розладів (disruption modes) та resource claims. Якщо spec.scheduling виключено, Job типово використовує Basic планування, зберігаючи наявну поведінку, при цьому створюючи Basic Workload/PodGroup для workload-aware планування, без використання minCount gate. Користувачі можуть явно використовувати (opt in) Gang планування, де minCount типово дорівнює паралелізму Jobʼа, а контролер використовує спільну бібліотеку workloadbuilder для перекладу конфігурації планування у відповідні обʼєкти Workload та PodGroup замість реалізації власної логіки перекладу.

Ця робота була виконана як частина KEP #5547 під керівництвом SIG Scheduling.

Проксі користувацького простору (userspace) для `localhost` NodePort для `nftables`

Kubernetes v1.37 додає opt-in userspace проксі до nftables бекенду kube-proxy, дозволяючи NodePort сервісам бути доступними через localhost поверх IPv4 та IPv6. Це закриває прогалину між nftables та iptables бекендами, оскільки nftables раніше не міг обслуговувати localhost NodePortʼи.

Проксі увімкнено, коли localhost або loopback-адреса включена в конфігурацію --nodeport-addresses kube-proxy. Це може бути корисним для навантажень, таких як локальні контейнерні реєстрі, що покладаються на зʼєднання localhost:<NodePort>. Наявна поведінка iptables та ipvs бекендів незмінна.

Ця робота була виконана як частина KEP #6032 під керівництвом SIG Network.

Інші значущі зміни

`maxUnavailable` для StatefulSets знову стандартно увімкнено

Поле maxUnavailable для StatefulSets було знову стандартно увімкнено у Kubernetes v1.37 (після того, як баг був виявлений у v1.36).

Баг виникав, коли несправна початкова ревізія StatefulSet створювала Pod, який ніколи не ставав ready, і з увімкненим MaxUnavailableStatefulSet, контролер StatefulSet не міг оновити той Pod до новій, виправленій ревізії. Коли баг спрацьовував, зазначений Pod міг застрягти в стані CrashLoopBackOff безкінечно (див. kubernetes#137409).

Покращена продуктивність `nftables`

kube-proxy тепер використовує kernel netlink інтерфейс для операцій з правилами nftables, обходячи утиліту командного рядка nft. Це робить kube-proxy ефективнішим при перевірці та управлінні правилами nftables, покращуючи продуктивність управління правилами.

Обробка контексту та контекстне логування в client-go

Підтримка розповсюдження контексту та контекстного логування в client-go завершена, за винятком невеликої кількості викликів логування втулків автентифікації, які все ще покладаються на глобальний klog логер, бо базові API не підтримують передачу контексту.

Зміна статусу, застарілі та видалені функції у v1.37

Переходи в Stable

Цей розділ перераховує всі функції, що перейшли в Stable (також відомі як загальна доступність). Для повного списку оновлень, включаючи нові функції та переходи з Alpha в Beta, дивіться примітки до випуску.

Цей випуск включає загалом 16 вдосконалень, переведених у Stable:

Застарілі функції, видалення та оновлення від спільноти

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

Застарівання `kube-dns`

CoreDNS є стандартною надбудовою для кластерного DNS, починаючи з версії Kubernetes v1.113, і з того часу kube-dns не встигає за ним; такі функції, як EndpointSlices та сервіси з подвійним стеком, у ньому недоступні.

Kubernetes вже вивів kube-dns субпроєкт і виділив node-local-dns в окремий репозиторій, де він продовжує підтримуватися і працює з CoreDNS. Очікується, що нові пакети для kube-dns не будуть збиратися після v1.40.

Якщо ви все ще використовуєте kube-dns, почніть планувати міграцію ваших кластерів на CoreDNS.

Припинення підтримки режиму `ipvs` у `kube-proxy`

Підтримка режиму ipvs в kube-proxy була введена в v1.8 для вирішення вузьких місць продуктивності iptables. Однак, оскільки kernel ipvs API самостійно не може повністю реалізувати Kubernetes Services, режим ipvs продовжує використовувати iptables під капотом (KEP-3866, "The ipvs mode of kube-proxy will not save us").

Кластери, що запускають kube-proxy в режимі ipvs (або mode: ipvs в KubeProxyConfiguration), тепер логують попередження про застарівання при запуску. Графік застарівання виглядає так:

До v1.40, режим ipvs для kube-proxy очікується стандартно вимкненим (його все ще можна вибірково включати через функціональну можливість)
До v1.43, підтримка режиму ipvs буде видалена повністю KEP #5495, Graduation Criteria.

Для підтвердження того, який режим ви зараз використовуєте, виконайте:

kubectl -n kube-system get configmap kube-proxy -o jsonpath=ʼ{.data.config\.conf}ʼ | grep ʼmode:ʼ

Щоб зрозуміти обґрунтування цього застарівання, дивіться KEP #5495.

`kubectl`: прапорець `kubectl run --filename/-f` застаріває

Прапорець --filename (або -f) для kubectl run оголошується застарілим, оскільки генерований pod завжди будується виключно з CLI аргументів на кшталт NAME та --image.

Дивіться kubernetes/kubernetes#138671 для оригінального issue та обговорення.

`kubelet`: статичні Podʼи більше не можуть посилатися на Secrets або ConfigMaps

Статичні Podʼи ніколи не призначалися для читання API-ресурсів безпосередньо, оскільки вони не створюються через API-сервер — але баг дозволяв їм посилатися на Secrets або ConfigMaps через поля на кшталт configMapRef або secretRef. Цей баг тепер виправлений: починаючи з v1.37 ці посилання суворо заборонені, а функціональна можливість PreventStaticPodAPIReferences, що раніше дозволяв відмовитися від обмеження, був видалений.

Дивіться kubernetes/kubernetes#140226 для оригінального issue та обговорення.

Поточна велика зміна: майбутнє видалення підтримки cgroup v1

Оскільки сучасні Linux дистрибутиви та рушії виконання контейнерів стандартно використовують cgroup v2, підтримка застарілих cgroup v1 офіційно виводиться з експлуатації. З випуску v1.35 налаштування failCgroupV1 типово дорівнює true. Отже, kubelet не зможе ініціалізуватися на будь-яких вузлах, що все ще покладаються на cgroup v1, якщо не застосовано явний перевизначення конфігурації.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false # тимчасове перевизначення

Використання цього перевизначення слід розглядати як короткострокове виправлення. Розширені можливості керування ресурсами, такі як memory QoS та in-place масштабування для memory-backed томів, працюють лише на cgroups v2. Хоча перевизначення залишається доступним у Kubernetes v1.37, користувачів заохочують мігрувати на cgroups v2, оскільки підтримка cgroups v1 планується бути видаленою у майбутньому випуску.

Щоб дізнатися більше про це застарівання, зверніться до KEP #5573.

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

Перегляньте повні деталі релізу Kubernetes v1.37 в наших примітках до випуску.

Доступність

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

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

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

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

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

Ми хотіли б подякувати всій команді, що працювала над випуском за години наполегливої праці, завдяки яким випуск Kubernetes v1.37 став доступним для нашої спільноти.

До складу команди з випуску входять як новачки, які вперше беруть участь у проєкті, так і досвідчені керівники команд, які вже брали участь у кількох циклах випуску.

Особлива подяка нашому керівнику випуску, Діпешу Равату, за підтримку протягом успішного циклу випуску, за те, що він відстоював наші інтереси, дбав про те, щоб ми всі могли зробити свій внесок якнайкраще, та спонукав нас вдосконалювати процес випуску.

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

Проєкт CNCF K8s DevStats агрегує ряд цікавих даних, повʼязаних із швидкістю Kubernetes та різних субпроєктів.

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

У циклі релізу v1.37, що тривав 15 тижнів з 18 травня 2026 року по 26 серпня 2026 року, внески в Kubernetes досягли максимуму у 212 різних компаній та 1,754 окремих осіб.

Джерело цих даних:

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

Якщо ви бажаєте долучитися до проєкту, перегляньте нашу сторінку «Як розпочати».

Події

Дізнайтесь про майбутні KubeCon по всьому світу:

KubeCon + CloudNativeCon China: 7–9 вересня 2026, Шанхай, Китай
KubeCon + CloudNativeCon North America: 9–12 листопада 2026, Солт-Лейк-Сіті, США

Дізнайтесь про майбутні Kubernetes Community Days (KCDs), які відбуватимуться до кінця 2026 року:

Вересень 2026

KCD x Ceph x OpenInfra Day Korea: 1 вересня 2026, Сеул, Південна Корея
KCD San Francisco Bay Area: 1 вересня 2026, Маунтн-Вʼю, США
KCD Washington DC: 15 вересня 2026, Вашингтон, округ Колумбія, США
KCD Gujarat: 19 вересня 2026, Ахмедабад, Індія
KCD São Paulo: 26 вересня 2026, Сан-Паулу, Бразилія
KCD Sofia: 29 вересня 2026, Софія, Болгарія

Жовтень 2026

KCD UK – Edinburgh: 19–20 жовтня 2026, Единбург, Велика Британія
KCD Nigeria: 24 жовтня 2026, Лагос, Нігерія

Листопад 2026

KCD Porto: 19–20 листопада 2026, Порто, Португалія
KCD Hangzhou: 28 листопада 2026, Ханчжоу, Китай

Грудень 2026

KCD Suisse Romande: 9–10 грудня 2026, Мейрін, Швейцарія
KCD Provence: 10 грудня 2026, Екс-ан-Прованс, Франція
KCD Florida – Miami: 11 грудня 2026, Маями, США

Актуальну інформацію про заходи можна знайти на сторінці заходів CNCF.

Вебінар присвячений релізу

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

Приєднуйтесь

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

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

Прочитайте більше про те, як стати Kubernetes Contributor
Прочитайте більше про те, що відбувається з Kubernetes у нашому блозі
Приєднуйтесь до нас у Slack
Слідкуйте за нами в Bluesky для останніх оновлень
Слідкуйте за нами в LinkedIn
Слідкуйте за нами в X
Приєднуйтесь до обговорення спільноти в Discuss
Задавайте питання (або відповідайте на них) на Stack Overflow
Поділіться вашою Kubernetes End User Story
Дізнайтеся більше про Kubernetes Release Team

Створення власного експортера метрик для Kubernetes

Tue, 14 Jul 2026 10:00:00 -0800

Kubernetes має вбудовану підтримку моніторингу CPU та памʼяті, але більшість рішень щодо масштабування в реальних сценаріях залежать від сигналів, які знаходяться повністю поза цими вузькими межами: скільки повідомлень чекають у черзі, скільки часу тривало останнє пакетне завдання, скільки активних WebSocket-зʼєднань утримує Pod. Коли вбудованих метрик недостатньо, експортер метрик заповнює цю прогалину.

У цій статті ми розглянемо створення такого експортера з нуля, пакування його в контейнер та підключення до кластера, щоб Prometheus, і зрештою HorizontalPodAutoscaler, могли його використовувати.

Що насправді робить експортер метрик

Експортер — це невеликий HTTP-сервер з єдиним завданням: повідомляти стан застосунку у вигляді тексту в точці доступу /metrics. Prometheus збирає дані з цієї точки доступу з певним інтервалом, зберігає часові ряди та робить їх доступними для запитів, сповіщень і правил автомасштабування.

У деяких випадках ви можете інструментувати застосунок безпосередньо — вбудувати клієнтську бібліотеку Prometheus та відкрити /metrics всередині того ж процесу, замість запуску окремого експортера. Окремий експортер має більше сенсу, коли джерело даних знаходиться зовні вашого застосунку або коли ви не контролюєте код застосунку.

Формат, який очікує Prometheus — це звичайний текст: одна метрика на рядок, з назвою, опціональними мітками та числовим значенням. Клієнтські бібліотеки беруть на себе серіалізацію, тому на практиці вам потрібно лише вирішити, що вимірювати, та викликати відповідну функцію, коли значення змінюється.

Вибір того, що вимірювати

Перед написанням коду варто визначитися, з яким типом сигналу ви маєте справу. Модель даних Prometheus має три основні типи:

Лічильники (Counters) лише збільшуються. Вони підходять для підсумкових значень: кількість оброблених запитів, виконаних завдань, виниклих помилок. Ніколи не використовуйте лічильник для значення, яке може зменшуватися.
Вимірювачі (Gauges) представляють поточний знімок значення, яке може вільно зростати та спадати. Глибина черги, активні зʼєднання та розмір кешу — все це вимірювачі.
Гістограми (Histograms) записують розподіл спостережуваних значень, наприклад, затримку запитів. Вони дозволяють обчислювати перцентилі (p99, p50), а не лише середні значення.

Коли ви знаєте, який тип підходить для вашого сигналу, оберіть назву відповідно до конвенції <namespace>_<name>_<unit> у форматі snake_case. Обробник завдань може надавати worker_jobs_processed_total (лічильник), worker_queue_depth (вимірювач) та worker_job_duration_seconds (гістограма). Зрозумілі назви заощаджують час усім під час налагодження.

Налаштування проєкту

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

mkdir my-exporter && cd my-exporter
go mod init example.com/my-exporter
go get github.com/prometheus/client_golang/prometheus
go get github.com/prometheus/client_golang/prometheus/promhttp

Реєстрація метрик

Створіть main.go. Перше, що потрібно зробити — оголосити метрики та зареєструвати їх у типовому реєстрі Prometheus. Реєстрація повідомляє бібліотеці, що ці метрики існують, тому вони зʼявляться у виводі навіть до того, як буде записано перше спостереження:

package main

import (
    "log"
    "net/http"

    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

var (
    jobsProcessed = prometheus.NewCounterVec(
        prometheus.CounterOpts{
            Name: "worker_jobs_processed_total",
            Help: "Total number of jobs processed, partitioned by status.",
        },
        []string{"status"},
    )

    queueDepth = prometheus.NewGauge(prometheus.GaugeOpts{
        Name: "worker_queue_depth",
        Help: "Current number of jobs waiting in the queue.",
    })

    jobDuration = prometheus.NewHistogram(prometheus.HistogramOpts{
        Name:    "worker_job_duration_seconds",
        Help:    "Time spent processing a single job.",
        Buckets: prometheus.DefBuckets,
    })
)

func init() {
    prometheus.MustRegister(jobsProcessed, queueDepth, jobDuration)
}

prometheus.MustRegister викликає паніку у разі дублювання реєстрації, що дозволяє виявити помилки в налаштуваннях одразу під час запуску, а не непомітно під час роботи. Якщо ви вбудовуєте цей експортер у бібліотеку, яку будуть інструментувати інші пакети, використовуйте prometheus.Register та обробляйте помилку самостійно.

Збір реальних значень

Після реєстрації метрик наступний крок — підтримувати їх в актуальному стані. Ви можете або постійно оновлювати дані в міру їх зміни, або запустити власний внутрішній цикл оновлення. У прикладі нижче показано цикл опитування — goroutine, що періодично читає дані з вашого джерела даних та оновлює зареєстровані метрики. Замініть імітовані значення реальними викликами до вашої бази даних, внутрішнього API або брокера повідомлень:

import (
    "math/rand"
    "time"
)

func collectMetrics() {
    for {
        // Замініть це на реальні дані з вашого застосунку.
        depth := float64(rand.Intn(50))
        queueDepth.Set(depth)

        start := time.Now()
        time.Sleep(time.Duration(rand.Intn(200)) * time.Millisecond)
        jobDuration.Observe(time.Since(start).Seconds())
        jobsProcessed.WithLabelValues("success").Inc()

        time.Sleep(5 * time.Second)
    }
}

Інтервал опитування (тут пʼять секунд) має бути коротшим за інтервал збору Prometheus, щоб кожен збір бачив свіже значення. Типовий інтервал збору в більшості розгортань кластера становить пʼятнадцять секунд, що дає комфортний запас.

Експонування точки доступу

Обʼєднайте цикл збору та HTTP-обробник у main. Шлях /healthz разом із /metrics надає Kubernetes ціль для проб життєздатності (liveness probe), не експонуючи дані метрик на цьому шляху:

func main() {
    go collectMetrics()

    http.Handle("/metrics", promhttp.Handler())
    http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(http.StatusOK)
    })

    log.Println("Listening on :8080")
    if err := http.ListenAndServe(":8080", nil); err != nil {
        log.Fatalf("server error: %v", err)
    }
}

Перевірте вивід локально перед створенням образу:

go run .
curl http://localhost:8080/metrics | grep worker_

Ви маєте побачити три блоки # HELP та # TYPE, за якими слідують поточні значення метрик. Якщо ці рядки зʼявилися, експортер працює правильно та готовий до контейнеризації.

Створення образу контейнера

Багатоетапна збірка зберігає кінцевий образ невеликим та дозволяє не постачати інструменти Go у промислове середовище. Перший етап компілює статично зібраний бінарний файл; другий етап копіює лише цей бінарний файл у мінімальний базовий образ. Приклад нижче використовує Docker, але той самий підхід працює з будь-яким OCI-сумісним інструментом, як-от Buildah або Podman:

FROM golang:1.21-alpine AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /exporter .

FROM gcr.io/distroless/static:nonroot
COPY --from=builder /exporter /exporter
EXPOSE 8080
ENTRYPOINT ["/exporter"]

distroless/static:nonroot не містить оболонки, менеджера пакунків і типово працює від імені непривілейованого користувача, що відповідає більшості політик безпеки кластера без додаткового налаштування.

Зберіть та відправте образ, замінивши <registry> на адресу вашого реєстру:

docker build -t <registry>/my-exporter:v1.0.0 .
docker push <registry>/my-exporter:v1.0.0

(Примітка: використання конвеєра CI/CD для автоматизації цього процесу зазвичай є кращим підходом, ніж ручне виконання цих команд.)

Розгортання в кластері

Двох маніфестів достатньо для запуску експортера: Deployment, який керує життєвим циклом Podʼів, та Service, який надає Prometheus стабільну адресу для збору даних. (Ви можете налаштувати Prometheus на збір даних з кожного Podʼа; якщо це має сенс для вашого випадку використання, то це також допустимо).

Приклади нижче використовують простір імен monitoring, що є поширеною практикою при запуску Prometheus та повʼязаних компонентів разом. Відкоригуйте простір імен відповідно до налаштувань вашого кластера.

Deployment встановлює консервативні обмеження ресурсів, прийнятні для легковагового процесу в стилі sidecar, та використовує шлях /healthz для своєї проби життєздатності (liveness probe):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-exporter
  namespace: monitoring
  labels:
    app.kubernetes.io/name: my-exporter
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: my-exporter
  template:
    metadata:
      labels:
        app.kubernetes.io/name: my-exporter
    spec:
      containers:
      - name: exporter
        image: <registry>/my-exporter:v1.0.0
        ports:
        - name: metrics
          containerPort: 8080
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        resources:
          requests:
            cpu: 50m
            memory: 32Mi
          limits:
            cpu: 100m
            memory: 64Mi

Service називає порт metrics, на який посилатиметься ServiceMonitor у наступному розділі:

apiVersion: v1
kind: Service
metadata:
  name: my-exporter
  namespace: monitoring
  labels:
    app.kubernetes.io/name: my-exporter
spec:
  selector:
    app.kubernetes.io/name: my-exporter
  ports:
  - name: metrics
    port: 8080
    targetPort: metrics

Застосуйте обидва:

kubectl apply -f deployment.yaml -f service.yaml

Налаштування Prometheus для пошуку експортера

Спосіб налаштування збору даних залежить від того, як встановлено Prometheus.

Варіант 1: Prometheus Operator (ServiceMonitor)

Якщо ви встановили Prometheus за допомогою Prometheus Operator або Helm-чарту kube-prometheus-stack, оператор має бути запущений у вашому кластері перед створенням ServiceMonitor. Мітка release має збігатися з селектором міток, налаштованим у вашому ресурсі Prometheus — kube-prometheus-stack є типовим значенням для стандартного встановлення Helm:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-exporter
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: my-exporter
  endpoints:
  - port: metrics
    interval: 15s
    path: /metrics

Варіант 2: Виявлення на основі анотацій

Якщо ваш Prometheus використовує виявлення Podʼів на основі анотацій, вам знадобиться відповідне правило scrape_config у конфігурації Prometheus — перевірте з тим, хто керує вашим примірником Prometheus, щоб підтвердити наявність такого правила.

Ви можете додати наступні три анотації до шаблону Podʼа незалежно від методу збору. Вони ігноруються Prometheus Operator, але автоматично підхоплюються системами на основі анотацій:

annotations:
  prometheus.io/scrape: "true"
  prometheus.io/port: "8080"     # опустіть, якщо не використовуєте виявлення на основі анотацій
  prometheus.io/path: "/metrics" # опустіть, якщо не використовуєте виявлення на основі анотацій

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

Перевірка збору даних

Виконайте перенаправлення порту до сервісу Prometheus та відкрийте сторінку targets, щоб підтвердити, що експортер знайдено:

kubectl port-forward svc/prometheus-operated 9090 -n monitoring

Перейдіть на http://localhost:9090/targets. Ціль my-exporter має відображатися зі статусом UP. Якщо відображається DOWN, перевірте, чи збігається мітка release у ServiceMonitor та чи працює Pod:

kubectl get pods -n monitoring -l app.kubernetes.io/name=my-exporter
kubectl describe servicemonitor my-exporter -n monitoring

Коли ціль стане працездатною, виконайте швидкий запит у браузері виразів (expression browser), щоб підтвердити надходження даних:

rate(worker_jobs_processed_total{status="success"}[2m])

Ненульовий результат означає, що весь конвеєр працює: ваш застосунок генерує дані, Prometheus їх збирає, а часові ряди зберігаються та доступні для запитів.

Що далі

Робочий експортер — це фундамент, а не кінцева мета. Наступним логічним кроком є передача цих метрик до HorizontalPodAutoscaler, щоб ваше навантаження масштабувалося на основі сигналів, які дійсно визначають навантаження, а не лише CPU. Для цього потрібен адаптер метрик (найпоширеніший варіант — Prometheus Adapter), який реєструє ваші власні метрики в Kubernetes Custom Metrics API. Після реєстрації будь-який HorizontalPodAutoscaler у кластері може посилатися на worker_queue_depth або worker_jobs_processed_total безпосередньо у своєму блоці metrics.

Інструкцію з налаштування дивіться в Автомасштабування на основі кількох метрик і власних метрик. Каталог готових експортерів для баз даних, брокерів повідомлень і хмарних сервісів доступний на сторінці Prometheus exporters and integrations.

Керування AI/ML навантаженнями в Kubernetes: втулок Headlamp для Kubeflow

Mon, 13 Jul 2026 12:00:00 -0800

Kubernetes непомітно став стандартною платформою для AI та машинного навчання. Незалежно від того, чи ви запускаєте сервери notebook для дослідників даних, плануєте розподілені тренувальні завдання, налаштовуєте гіперпараметри чи керуєте багатоступеневими ML-пайплайнами, ці навантаження дедалі частіше потрапляють в кластер Kubernetes. Kubeflow — одна з найпопулярніших платформ для складання такого стеку, і вона робить це природним для Kubernetes способом: кожна можливість надається як Custom Resource Definition (CRD).

Такий дизайн є подарунком для операторів кластерів, оскільки це означає, що за ML-навантаженнями можна спостерігати та керувати ними тими ж примітивами, що й усіма іншими в кластері. Але на практиці спеціалізовані ML-інфопанелі, що постачаються з цими платформами, приховують Kubernetes-рівень під собою. Коли notebook застрягає або тренувальний запуск завершується невдало, оператор часто змушений повернутися до kubectl, щоб дізнатися, що насправді сталося на рівні Podʼа.

Тут представлено втулок Headlamp для Kubeflow, який усуває цю прогалину, показуючи власні ресурси Kubeflow безпосередньо в універсальному інтерфейсі Kubernetes. Це наочний приклад підходу, якого може дотримуватися будь-яка платформа, що активно використовує CRD: взаємодіяти з операторами там, де вони вже працюють, і надавати їм достовірну інформацію на рівні кластера.

Сам Headlamp — це розширюваний веб-інтерфейс Kubernetes, що підтримується Kubernetes SIG UI та ліцензований за ліцензією Apache 2.0. Він працює як десктоп-застосунок або в кластері, а його система втулків дозволяє будь-кому додавати першокласні представлення для власних ресурсів.

Чому операторам потрібне інше представлення

Спеціалізовані ML-інфопанелі допомагають дослідникам даних подавати експерименти, пайплайни та notebookʼи. Оператори кластерів та інженери надійності сайтів (SRE) шукають несправності в Kubernetes-ресурсах, що лежать в їх основі, і вони задають інші запитання:

Чому notebook застряг? Чи це ImagePullBackOff, OOMKilled чи Pod, що очікує PersistentVolumeClaim?
Які ресурси Run нещодавно завершилися невдало в різних просторах імен?
Який набір параметрів Katib Experiment визнає оптимальним?
Чи посилаються ресурси TrainJob на очікувані ресурси TrainingRuntime?
Які пакетні навантаження виконуються та який стан показує Kubernetes?

Втулок Headlamp Kubeflow допомагає відповісти на ці запитання, зчитуючи дані безпосередньо з API-сервера Kubernetes. Він показує умови Podʼів, причини збоїв в Kubernetes та ресурси в різних просторах імен без необхідності посередницького ML-сервісу чи бази даних.

Що охоплює цей втулок

Kubeflow є модульним, і команди часто встановлюють лише ті компоненти, які їм потрібні. Втулок виявляє API-групи Kubeflow у кластері та показує лише відповідні розділи.

Втулок підтримує такі родини компонентів та API-ресурси:

Компоненти Kubeflow та API-ресурси, підтримувані втулком Headlamp
Компонент	Призначення	API-ресурси
Notebooks	Надає середовища розробки, такі як Jupyter, VS Code та RStudio	Notebook, Profile, PodDefault
Pipelines	Визначає та відстежує пайплайни, версії, експерименти, запуски та розклади	Pipeline, PipelineVersion, Run, RecurringRun, Experiment
Katib	Автоматизує налаштування гіперпараметрів та пошук нейронних архітектур	Experiment, Trial, Suggestion
Training	Виконує розподілені тренувальні навантаження, такі як завдання PyTorch та TensorFlow	TrainJob, TrainingRuntime, ClusterTrainingRuntime
Spark	Виконує масштабну обробку даних за допомогою Apache Spark	SparkApplication, ScheduledSparkApplication

Що ви можете побачити

Інспектуйте Podʼи notebook

Детальний вигляд Notebook показує умови Podʼів та їхні поля reason та message. Він також показує запити та обмеження CPU, памʼяті та GPU; монтування томів та їхні типи, такі як PersistentVolumeClaim, ConfigMap, Secret чи emptyDir; змінні середовища, що посилаються на Secret чи ConfigMap обʼєкти; sidecar-контейнери; та toleration вузлів. Цей вигляд консолідує інформацію, яка в іншому випадку вимагала б кількох команд kubectl describe.

Інспектуйте налаштування гіперпараметрів

Представлення Katib показують алгоритм налаштування, простір пошуку, кожен Trial з його поточним статусом та поточний найкращий Trial з його метричними значеннями та призначеннями параметрів. Вони також показують конфігурацію раннього зупинення та кількість ресурсів Trial, що зупинилися рано, щоб ви могли слідкувати за пошуком, не виходячи з UI кластера.

Інспектуйте стан пайплайну без бази даних бекенду

Представлення Pipelines зчитують Kubernetes-ресурси API безпосередньо та не запитують Kubeflow Pipelines API-сервіс чи базу даних бекенду. Ви можете інспектувати збережений стан пайплайну навіть коли цей сервіс недоступний. Детальний вигляд Pipeline надає порівняння останньої та попередньої версій PipelineVersion у вигляді паралельного порівняння у форматі YAML. Представлення Run показують стан та тривалість, представлення RecurringRun показують зрозумілі розклади, а представлення artifacts агрегує значення pipelineRoot з останніх ресурсів Run.

Мапа ML-ресурсів

Втулок реєструє Headlamp map source, що показує ресурси Notebook, Profile, PodDefault, Experiment, Pipeline, SparkApplication та TrainJob як вузли графа. Він малює ребра між підтримуваними ресурсами на основі .metadata.ownerReferences. Headlamp також показує вбудовані зведення для цих типів ресурсів, коли ви наводите на них курсор.

Спробуйте

README втулка Kubeflow пояснює встановлення та налаштування локального кластера, включаючи полегшений варіант лише з CRD для ознайомлення. Оскільки втулок виявляє встановлені API-групи, ви можете використовувати його з наявною модульною інсталяцією Kubeflow чи створити кластер для ознайомлення лише з CRD та зразковими ресурсами.

Застосуйте шаблон до інших платформ

Kubeflow ілюструє ширший шаблон. Платформи часто моделюють предметно-орієнтовані робочі процеси за допомогою власних ресурсів. Їхні інфопанелі зосереджені на цих робочих процесах, тоді як Kubernetes-оператори також потребують стану базових API-ресурсів та Podʼів. Втулок, що працює на основі CRD, у загальному Kubernetes UI може показувати цей стан, не змушуючи операторів перемикатися між незвʼязаними інструментами.

Втулок використовує ліцензію Apache 2.0 та розробляється під егідою Kubernetes SIG UI. Щоб повідомити про проблему чи зробити покращення, скористайтеся issue tracker чи pull requests репозиторію втулків Headlamp.

Від Kubernetes Dashboard до Headlamp: покроковий посібник

Mon, 13 Jul 2026 10:00:00 -0800

1. До того, як почати: що змінюється

Kubernetes Dashboard та Headlamp обидва показують, що працює в кластері, але вони працюють по-різному. Коли Headlamp запускається на робочому столі, він використовує ваш наявний kubeconfig для підключення до одного або кількох кластерів і може бути розширений втулками. Коли Headlamp запускається всередині кластера, він використовує Kubernetes ServiceAccount для доступу до API та дотримання правил RBAC. Kubernetes Dashboard, навпаки, працює лише всередині кластера і завжди покладається на токени службового облікового запису. Розуміння цих моделей на ранньому етапі допомагає вибрати правильну конфігурацію та дозволи.

1.1 Як працює Kubernetes Dashboard

Dashboard — це вебзастосунок, який працює всередині вашого кластера.

Ви встановлюєте його в кластері, часто за допомогою Helm.
Зазвичай ви запускаєте один Dashboard на кластер.
Часто ви отримуєте доступ до нього через kubectl port-forward або ingress.
Ви входите за допомогою токена на предʼявника. Цей токен часто походить від службового облікового запису.
Він включає форми, які допомагають створювати ресурси.
Він спирається на таблиці та списки для навігації.

Відчуття таке: інтерфейс користувача, який живе разом із кластером.

1.2 Як працює Headlamp

Headlamp діє більше як клієнт Kubernetes з інтерфейсом користувача.

Він може працювати на вашому робочому столі або в кластері.
Він читає ваш kubeconfig, як це робить kubectl.
Він може показувати більше одного кластера в одному місці.
Він віддає перевагу YAML при створенні або зміні ресурсів.
Він включає списки та візуальну мапу.
Ви можете додавати функції за допомогою втулків.

Headlamp — це інтерфейс користувача, який слідує за вашою ідентичністю, а не за кластером.

1.3 Що залишається без змін

Багато робочих процесів здаватимуться знайомими:

Перегляд робочих навантажень та ресурсів
Фільтрація за простором імен
Перегляд YAML, подій та стану
Перегляд журналів
Виконання дій, дозволених вашим RBAC

1.4 Що змінюється

Деякі речі будуть відчуватися інакше:

Вхід змінюється з вставлених токенів на kubeconfig (а іноді і SSO).
Створення змінюється з заповнення форм на "застосування YAML".
Багатокластерність стає нормою, а не особливим випадком.
Візуальна мапа допомагає бачити, як повʼязані ресурси.

2. Контрольний список перед міграцією

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

2.1 Запишіть, що ви використовуєте сьогодні

Перелічіть основне:

Які кластери ви використовуєте (dev, staging, prod)
Які простори імен ви використовуєте найчастіше
Що ви робите найчастіше (перегляд, редагування, масштабування, видалення, налагодження)
Як ви отримуєте доступ до Dashboard сьогодні (port-forward або ingress)
Як ви входите (токен службового облікового запису та які RBAC-приʼязки)

Це ваша відправна точка.

2.2 Перевірте, чи працює kubeconfig

Headlamp використовує kubeconfig, особливо на робочому столі. Переконайтеся, що ваш працює, перш ніж встановлювати будь-що.

Запустіть:

kubectl config current-context

Потім спробуйте:

kubectl get nodes

Якщо ви не можете вивести список вузлів, спробуйте це зробити в просторі імен, до якого у вас є доступ:

kubectl get pods -n <namespace>

Якщо ці команди працюють, Headlamp може використовувати ту ж ідентичність та RBAC.

2.3 Виберіть план розгортання

Немає потреби поспішати. Більшість команд обирають один з цих варіантів:

Паралельне розгортання (рекомендовано)

Встановіть Headlamp
Дайте людям спробувати його
Залиште Dashboard на короткий час
Видаліть Dashboard після того, як команда буде готова

Перемикання

Встановіть Headlamp
Перемкніть документацію та посилання
Видаліть Dashboard незабаром після цього

Паралельне розгортання безпечніше для спільних кластерів.

2.4 Виберіть, де буде працювати Headlamp

Ви можете використовувати будь-який варіант. Багато команд використовують обидва.

Робочий стіл

Використовує ваш kubeconfig
Не використовує ресурси кластера
Не потребує port-forward
Багатокластерність працює з коробки

У кластері

Працює добре для спільного доступу через оглядач
Може керуватися як інші застосунки в кластері
Часто використовується разом з ingress та SSO

2.5 Зверніть увагу на необовʼязкові залежності

Це поширені залежності. Ви можете налаштувати їх пізніше.

metrics-server (для графіків використання CPU та памʼяті)
ingress (для URL всередині кластера)
OIDC / SSO (для входу через оглядач)
очищення старих службових облікових записів Dashboard та RBAC

3. Виберіть, де буде працювати Headlamp (робочий стіл або в кластері)

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

Варіант A: Робочий стіл (керується користувачем)

Headlamp для робочого столу запускається на компʼютері кожного користувача. Він читає той самий kubeconfig, який ви використовуєте з kubectl. Завдяки цьому доступ залишається привʼязаним до ідентичності та RBAC кожного користувача.

Чому команди обирають цей варіант

Немає сервісу в кластері для розгортання або відкриття.
Не використовує ресурси кластера (CPU або памʼять).
Використовує ваш kubeconfig і RBAC.
Працює з багатьма кластерами в одному застосунку.
Не потребує port-forward для щоденного використання.

Варіант B: У кластері (найкраще для спільного доступу)

Headlamp у кластері встановлюється як робоче навантаження Kubernetes (часто через Helm). Це дозволяє адміністраторам кластера керувати ним як іншими застосунками в кластері.

Адміністратори кластера керують встановленням, оновленнями та конфігурацією через Helm-чарт та стандартні інструменти Kubernetes.
Адміністратори контролюють ingress і можуть налаштувати вхід через OIDC для спільного доступу.
Підтримує спільне використання в командних середовищах.

4. Встановлення Headlamp (робочий стіл та в кластері)

Цей розділ допоможе запустити Headlamp. Дотримуйтесь шляху, який ви обрали в розділі 3.

4.1 Встановлення на робочий стіл (найшвидший спосіб почати)

Встановіть Headlamp на вашому компʼютері. Потім відкрийте його як будь-який інший застосунок. Headlamp читає ваш kubeconfig і використовує ту саму ідентичність і ті самі правила RBAC, що й kubectl.

Windows

Встановлення за допомогою WinGet:

winget install headlamp

Або з Chocolatey:

choco install headlamp

macOS

Встановлення за допомогою Homebrew:

brew install --cask headlamp

Linux

Встановлення за допомогою Flatpak (Flathub):

flatpak install flathub io.kinvolk.Headlamp

Швидка перевірка

Запустіть Headlamp.
Підтвердьте, що ви бачите контекст кластера.
Відкрийте простір імен, до якого у вас є доступ, і підтвердьте, що ви можете переглядати робочі навантаження. Headlamp покаже лише ті дії, які дозволяє ваш RBAC.

4.2 Встановлення в кластері (спільний доступ)

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

Встановлення за допомогою Helm

Додайте репозиторій і оновіть його:

helm repo add headlamp https://kubernetes-sigs.github.io/headlamp/
helm repo update

Створіть простір імен (приклад):

kubectl create namespace headlamp

Встановіть чарт:

helm install headlamp headlamp/headlamp --namespace headlamp

Встановлення за допомогою YAML-маніфесту (опціонально)

Headlamp також надає YAML-маніфест, який ви можете застосувати, а потім налаштувати відповідно до ваших потреб.

Перевірка встановлення

Підтвердьте, що Pod запущено:

kubectl get pods -n headlamp

Підтвердьте, що сервіс існує:

kubectl get svc -n headlamp

Доступ до нього (два поширені способи)

Швидка перевірка за допомогою port-forward

Це найшвидший спосіб перевірити, чи працює сервіс:

kubectl port-forward -n headlamp svc/headlamp 8080:80

Потім відкрийте: http://localhost:8080

Спільний доступ через ingress

Якщо ви хочете мати стабільний URL, відкрийте сервіс через ваш контролер Ingress. Точний YAML для ingress залежить від вашої конфігурації. URL зворотного виклику OIDC у Headlamp — це ваш публічний URL плюс /oidc-callback, тому налаштування ingress і TLS мають значення.

4.3 Оновлення Headlamp

Оновлення залежить від того, як ви встановили Headlamp. Менеджери пакунків оновлюють застосунок на місці. Встановлення через DMG або EXE оновлюється шляхом повторного встановлення нової версії.

macOS

Якщо ви встановили за допомогою Homebrew, виконайте:

brew upgrade headlamp

Якщо ви встановили з DMG, завантажте новий DMG і перетягніть Headlamp у /Applications, замінивши стару версію. Встановлення через DMG не оновлюється автоматично.

Windows

Якщо ви встановили за допомогою WinGet, виконайте:

winget upgrade headlamp

Якщо ви встановили за допомогою Chocolatey, виконайте:

choco upgrade headlamp

Якщо ви встановили з EXE, завантажте новий інсталятор і запустіть його знову. Встановлення через EXE не оновлюється автоматично.

Linux

Якщо ви встановили за допомогою Flatpak, виконайте:

flatpak update io.kinvolk.Headlamp

Якщо ви встановили за допомогою AppImage, завантажте новий AppImage і запустіть цей файл замість старого.

Якщо ви встановили за допомогою tarball, завантажте новий tarball, розпакуйте його і запустіть новий бінарний файл headlamp.

4.4 Примітки щодо доступу в кластері (тримайте в безпеці)

Ставтеся до інтерфейсу користувача в кластері як до будь-якого іншого сервісу, що надає доступ до кластера. Використовуйте TLS, обмежте коло тих, хто може до нього дістатися, і покладайтеся на автентифікацію Kubernetes та RBAC для контролю дій користувачів.

5. Автентифікація та RBAC

Headlamp використовує API Kubernetes так само, як і kubectl. Ваш кластер все ще вирішує, хто що може робити. Headlamp лише показує дії, які дозволені вашій ідентичності.

Цей розділ охоплює два варіанти налаштування: на робочому столі та в кластері.

5.1 Робочий стіл: використання kubeconfig

На робочому столі Headlamp читає ваш kubeconfig і використовує ті ж облікові дані, що й kubectl. Немає окремого потоку входу з токеном для керування.

Крок 1: Підтвердьте, що ваш kubeconfig працює

Виконайте:

kubectl config current-context

Потім перевірте доступ:

kubectl get nodes

Якщо ви не можете отримати список вузлів, перевірте простір імен, до якого у вас є доступ:

kubectl get pods -n <namespace>

Якщо ці команди працюють, ваш kubeconfig і облікові дані дійсні для Headlamp також.

Крок 2: Вкажіть Headlamp правильний kubeconfig (якщо потрібно)

Headlamp може використовувати типовий шлях до kubeconfig. Він також може використовувати власний шлях до файлу. Ви можете встановити KUBECONFIG, щоб вибрати конкретний файл.

Приклад:

KUBECONFIG=/path/to/config headlamp

Ви також можете використовувати більше одного файлу kubeconfig одночасно. В системах Unix розділяйте шляхи за допомогою :. У Windows розділяйте шляхи за допомогою ;.

Що очікувати в інтерфейсі користувача

Headlamp адаптується до ваших дозволів RBAC. Якщо у вас немає дозволу редагувати або видаляти ресурс, Headlamp не запропонує ці дії.

Headlamp у кластері спільно використовують багато користувачів. Вам потрібен чіткий план для входу та доступу. Headlamp підтримує OpenID Connect (OIDC) для потоку "Sign in".

Зазвичай ви обираєте один із цих варіантів:

A. Налаштуйте Headlamp з OIDC (вбудований).
B. Розмістіть шар автентифікації перед Headlamp (поширено на підприємствах).

A. Вбудований OIDC (Headlamp)

Щоб використовувати OIDC, Headlamp потребує:

Ідентифікатор клієнта (Client ID)
Секрет клієнта (Client secret)
URL видавця (Issuer URL)
(Необовʼязково) області доступу (scopes)

Ваш провайдер OIDC також повинен дозволяти URL зворотного виклику Headlamp. URL зворотного виклику — це ваш URL Headlamp плюс:

/oidc-callback

Приклад:

https://headlamp.example.com/oidc-callback

Примітка щодо Ingress

Якщо Headlamp знаходиться за ingress або балансувальником навантаження, переконайтеся, що він пересилає X-Forwarded-Proto. Якщо ні, Headlamp може згенерувати URL зворотного виклику з http замість https. Це може порушити вхід.

B. Шар автентифікації перед Headlamp

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

5.3 RBAC: дотримуйтесь принципу найменших привілеїв

Безпека Kubernetes починається з автентифікації та авторизації API (RBAC). Headlamp дотримується цих правил.

Практичні поради:

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

5.4 Швидке усунення несправностей

Робочий стіл: "Я не бачу свій кластер"

Ваш kubeconfig може не знаходитися в типовому місці. Вкажіть Headlamp файл за допомогою KUBECONFIG або шляху до файлу.

У кластері: "Після перенаправлення не вдається увійти в OIDC"

Підтвердьте, що ваш провайдер дозволяє https://YOUR_URL/oidc-callback. Якщо ви використовуєте ingress, переконайтеся, що він пересилає X-Forwarded-Proto.

6. Керування кількома кластерами

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

Кластери беруться з вашого kubeconfig

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

Перемикання між кластерами в інтерфейсі

Після завантаження kubeconfig у Headlamp, ви можете перемикатися між кластерами за допомогою селектора кластерів. Це полегшує переміщення між dev, staging та prod без зміни інструментів.

Опціонально: використання більше ніж одного файлу kubeconfig

Якщо у вас є окремі файли kubeconfig, ви можете завантажити їх разом. Headlamp підтримує кілька шляхів до kubeconfig у KUBECONFIG.

Unix/macOS/Linux (роздільник :):

KUBECONFIG=~/.kube/dev:~/.kube/prod headlamp

Windows (роздільник ;):

$env:KUBECONFIG="$HOME\.kube\dev;$HOME\.kube\prod"

Опціонально: додавання кластера зсередини Headlamp

Ви також можете додавати кластери, завантажуючи додаткові файли kubeconfig з інтерфейсу користувача.

Дозволи залишаються тими ж

Робота з кількома кластерами не змінює правила безпеки. Кожен кластер все ще застосовує власний RBAC. Headlamp показує лише те, що ваша ідентичність може робити в обраному кластері.

7. Навігація та розуміння ресурсів

Якщо ви використовували Kubernetes Dashboard, ця частина буде знайома. Headlamp зберігає ті ж основні перегляди ресурсів, але полегшує переміщення та розуміння того, що з чим повʼязано.

Знаходження ресурсів у знайомих місцях

Headlamp групує ресурси таким чином, що це близько до Dashboard:

Workloads для Pods, Deployments, StatefulSets та Jobs
Network для Services та Ingress
Storage для PersistentVolumes та Claims
Configuration для ConfigMaps та Secrets
Nodes для інфраструктури кластера

Ви можете фільтрувати за простором імен у верхній частині інтерфейсу, так само як у Dashboard.

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

З будь-якого списку ви можете натиснути на ресурс, щоб побачити деталі:

Статус і стани (conditions)
Події
Мітки та анотації
Повне визначення в YAML

Якщо ваш RBAC дозволяє, ви можете редагувати YAML безпосередньо з інтерфейсу. Якщо ні, Headlamp показує ресурс лише для читання. Це відповідає поведінці kubectl.

Використання пошуку та фільтрів для швидшої роботи

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

Розуміння взаємозвʼязків за допомогою Map View

Dashboard в основному показує ресурси у вигляді списків. Headlamp також включає Map View.

Map View показує, як ресурси взаємоповʼязані:

Deployments
ReplicaSets
Pods
Services

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

Коли використовувати списки, а коли Map View

Використовуйте списки, коли ви знаєте, який ресурс шукаєте.
Використовуйте Map View, коли ви намагаєтеся зрозуміти, чому щось не працює.

Обидва перегляди працюють з одними й тими ж даними. Ви просто обираєте, скільки контексту вам потрібно в даний момент.

8. Розгортання застосунків за допомогою YAML

Цей момент є найбільшою зміною для більшості користувачів Kubernetes Dashboard. Dashboard покладався на форми. Headlamp покладається на маніфести. Мета не в тому, щоб уповільнити вас. Мета — узгодити інтерфейс користувача з тим, як Kubernetes зазвичай працює на практиці.

Від форм до маніфестів

У Kubernetes Dashboard ви часто розгортали застосунок, заповнюючи форму:

образ контейнера
кількість реплік
тип сервісу

Headlamp не включає той самий майстер. Замість цього він дозволяє застосовувати YAML безпосередньо з інтерфейсу.

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

маніфести зберігаються в Git
CI/CD застосовує їх
Helm або інструменти GitOps керують змінами

Headlamp вписується в цей процес, а не замінює його.

Створення ресурсів за допомогою YAML

Щоб розгорнути застосунок у Headlamp:

Виберіть кластер і простір імен.
Натисніть Create.
Вставте або завантажте YAML-маніфест.
Перегляньте його.
Натисніть Apply.

Ресурс зʼявляється негайно в інтерфейсі.

Якщо маніфест недійсний, Headlamp показує ті самі помилки, які ви б побачили від API Kubernetes.

Генерація YAML простим способом

Якщо вам не вистачає майстра Dashboard, ви все ще можете швидко згенерувати YAML.

Наприклад:

kubectl create deployment nginx \
  --image=nginx \
  --dry-run=client \
  -o yaml > nginx.yaml

Ви можете відредагувати файл за потреби, а потім вставити його в Headlamp і застосувати.

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

Що робити, якщо ви використовуєте Helm або GitOps?

Це добре працює з Headlamp.

Встановлюйте за допомогою Helm як зазвичай.
Розгортайте за допомогою GitOps-конвеєрів як зазвичай.
Використовуйте Headlamp для перегляду, інспекції та налагодження того, що працює.

Headlamp не замінює ці інструменти. Він дає вам видимість того, що вони створюють.

Чого очікувати порівняно з Dashboard

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

9. Розгортання та налагодження робочих навантажень

Однією з основних причин, чому люди використовували Kubernetes Dashboard, було щоденне налагодження. Headlamp охоплює ті самі завдання і додає кілька корисних покращень.

Перегляд журналів

Ви можете переглядати журнали Podʼів безпосередньо в інтерфейсі користувача.

Щоб перевірити журнали:

Відкрийте Workloads.
Виберіть Pods.
Натисніть на Pod.
Відкрийте вкладку Logs.

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

Виконання команд у запущених Podʼах

Headlamp також дозволяє відкрити оболонку всередині контейнера.

Зі сторінки Podʼа:

Відкрийте меню дій Podʼа.
Виберіть Terminal або Exec.

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

Ця дія дотримується правил RBAC. Якщо ви не можете виконати kubectl exec, Headlamp також не дозволить це зробити.

Перевірка метрик та використання ресурсів

Headlamp може показувати використання CPU та памʼяті для Podʼів і вузлів. Це працює так само, як і в Dashboard.

Декілька речей, які варто знати:

Метрики вимагають встановлення metrics-server у кластері.
Якщо метрики відсутні, Headlamp показує чітке повідомлення.
Після того як метрики стануть доступними, використання показується на сторінках Podʼів і вузлів.

Це дозволяє легко відповісти на прості запитання:

Чи використовує цей Pod занадто багато памʼяті?
Чи знаходиться вузол під тиском навантаження?

Перегляд подій, коли щось пішло не так

Події часто є найшвидшим способом зрозуміти причини збоїв.

У Headlamp ви можете:

Переглядати події на сторінках деталей ресурсів.
Бачити попередження та помилки, повʼязані з Podʼами, вузлами або розгортаннями.

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

Як це в порівнянні з Dashboard

Що залишається без змін:

Перегляд журналів
Перегляд подій
Дії, що враховують RBAC

Що покращується:

Вбудовані сесії exec
Чіткіше розташування та фільтрація
Менше перемикань між UI та CLI

10. Видалення Kubernetes Dashboard

Після того як Headlamp працює і ваша команда звикла до нього, ви можете видалити Kubernetes Dashboard. Це останній крок очищення.

Видалення Dashboard зменшує безлад і запобігає збереженню невикористовуваних шляхів доступу.

Підтвердження, що Headlamp відповідає вашим потребам

Перед видаленням будь-чого переконайтеся, що:

Користувачі можуть отримати доступ до потрібних кластерів у Headlamp.
Основні завдання працюють:
- перегляд ресурсів
- розгортання за допомогою YAML
- перегляд журналів та подій
- виконання команд у Podʼах (якщо дозволено)
RBAC працює відповідно до очікувань для різних ролей.

Після того як ці перевірки пройдено, ви готові видалити Dashboard.

Видалення Dashboard

Якщо ви встановили Kubernetes Dashboard за допомогою Helm, видаліть його за допомогою:

helm uninstall kubernetes-dashboard -n kubernetes-dashboard

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

Після видалення переконайтеся, що ресурси зникли:

kubectl get pods -n kubernetes-dashboard

Очищення артефактів доступу (рекомендовано)

Багато налаштувань Dashboard використовували виділені службові облікові записи та ролі на рівні кластера.

Перегляньте та видаліть усе, що було створено лише для доступу до Dashboard, наприклад:

службові облікові записи
привʼязки ролей або привʼязки ролей кластера
стара документація, яка вказує користувачам на URL-адреси Dashboard або команди port-forward

Це зменшує кількість довготривалих облікових даних та невикористовуваних дозволів.

Повідомлення про зміну

Переконайтеся, що ваша команда знає:

Headlamp тепер є основним інтерфейсом Kubernetes.
Як отримати до нього доступ (застосунок для робочого столу або URL).
Куди звертатися за допомогою, якщо щось виглядає інакше.

11. Контрольний список після міграції

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

Доступ та видимість

Headlamp відкривається без помилок.
Користувачі можуть отримати доступ до правильних кластерів.
Фільтрація за просторами імен працює належним чином.
Перемикання між кластерами працює правильно.

Автентифікація та RBAC

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

Основні робочі процеси

Ресурси завантажуються у Workloads, Network та Configuration.
YAML можна переглядати та редагувати там, де дозволяють права.
Застосунки можна розгортати за допомогою Create та YAML.
Журнали завантажуються правильно для запущених Podʼів.
Exec працює для користувачів, яким дозволено його використовувати.
Метрики зʼявляються, якщо встановлено metrics-server.

Операційна впевненість

Команди можуть усувати несправності без перемикання інструментів.
Map View допомагає пояснити взаємозвʼязки під час налагодження.
Команди платформи або DevOps знають, як встановлюється та керується Headlamp.

Підтвердження очищення

Kubernetes Dashboard більше не працює.
Службові облікові записи і привʼязки RBAC, призначені лише для Dashboard, видалені.
Внутрішня документація більше не містить посилань на URL-адреси Dashboard або команди port-forward.

Узгодження з командою

Команда знає, що Headlamp є типовим інтерфейсом Kubernetes.
Документація для новачків вказує новим користувачам на Headlamp.
Існує чіткий шлях для зворотного звʼязку або запитань.

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

Якщо ви хочете допомогти формувати майбутнє Headlamp, приєднуйтесь до спільноти Headlamp і робіть внесок на headlamp.dev.

Представляємо втулок Cluster API для Headlamp

Thu, 25 Jun 2026 14:00:00 -0800

Headlamp — це відкритий, розширюваний проєкт Kubernetes SIG UI, призначений для огляду, керування та налагодження ресурсів кластера безпосередньо з вебоглядача.

Cluster API (CAPI) є субпроєктом Kubernetes, який надає декларативні API у стилі Kubernetes для керування життєвим циклом кластерів. Він дозволяє командам платформи створювати, оновлювати та керувати життєвим циклом кластерів Kubernetes за допомогою стандартних обʼєктів Kubernetes, збережених і узгоджених у кластері керування.

Керування ресурсами Cluster API історично вимагало використання команд kubectl та глибокого розуміння ієрархій власності. Втулок Headlamp Cluster API забезпечує візуальну ясність, швидше налагодження та спрощені операції для команд платформи безпосередньо всередині Headlamp.

Що надає цей втулок

Втулок Cluster API додає спеціальний розділ Cluster API до Headlamp і забезпечує повну видимість основних ресурсів CAPI через узгоджені списки та детальні перегляди.

Можливість	Опис
Огляд кластерів	Перегляд кластерів з актуальним станом панелі управління та реплік робочих вузлів.
Видимість машин	Перевірка MachineDeployments, MachineSets, Machines та MachinePools зі станом та умовами.
Інфопанель Cluster API	Отримання централізованого огляду стану ресурсів Cluster API, активних проблем зі станами, інформації про провайдера та рекомендацій щодо усунення несправностей.
Моніторинг панелі управління	Відстеження реплік KubeadmControlPlane, версій та повʼязаних Machines.
Масштабування з інтерфейсу	Масштабування MachineDeployments та MachineSets безпосередньо з Headlamp.
Ієрархія підлеглих ресурсів	Відстеження взаємозвʼязків між кластерами, розгортаннями, наборами та машинами.
Перегляд KubeadmConfig	Перегляд конфігурацій завантаження, файлів, аргументів kubelet та налаштувань приєднання/ініціалізації.
Врахування топології	Автоматичне виявлення ресурсів, керованих ClusterClass, і призначення їм міток.
Мапа	Візуалізація взаємозвʼязків між Cluster, Control Plane та Worker.
Динамічне версіонування API	Підтримка обох версій Cluster API: v1beta1 та v1beta2.
Метрики Prometheus	Перегляд метрик наживо з втулка Headlamp Prometheus безпосередньо на сторінках деталей ресурсів Cluster API.

Огляд втулка

Втулок Headlamp Cluster API надає основні ресурси Cluster API в узгодженому візуальному інтерфейсі всередині Headlamp. Ось деякі з ключових переглядів, включених у перший випуск.

Інфопанель Cluster API

Інфопанель надає централізований огляд ресурсів Cluster API та їх стану в кластері керування.

Огляд підсумовує стан кластерів, Machines, MachineDeployments, MachinePools, MachineSets та панелей управління. Він також виділяє поточні проблеми станів, інформацію про провайдера та кількість шаблонів конфігурацій, щоб допомогти операторам швидко виявляти деградовані або несправні ресурси.

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

Забезпечте повну видимість Cluster API в Headlamp

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

Перегляд деталей кластера надає інформацію про статус ресурсів, стани, посилання на інфраструктуру, посилання на панель керування та повʼязані Machines на одній сторінці.

Досліджуйте ресурси Cluster API у візуальному інтерфейсі

Для MachineDeployments, MachineSets, Machines та MachinePools доступні окремі перегляди. Ці сторінки відображають кількість реплік, відносини власності, ідентифікатори провайдерів, версії та стани для підтримки щоденних операцій та налагодження.

Масштабування робочих навантажень безпосередньо з Headlamp

MachineDeployments та MachineSets включають вбудовану дію масштабування, що дозволяє регулювати кількість реплік безпосередньо з Headlamp без використання команд терміналу.

Для кластерів із топологічним керуванням втулок також вказує, коли масштабування слід виконувати на рівні кластера.

Перегляд конфігурації bootstrap без сирого YAML

Конфігурації bootstrap можна переглядати у структурованому форматі, включаючи вбудовані файли, аргументи kubelet, додаткові томи та налаштування join або init. Це усуває необхідність вручну переглядати сирий YAML або Secret.

Візуалізація взаємозвʼязків кластера за допомогою мапи

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

Інтеграція метрик Prometheus

Втулок Cluster API інтегрується з втулком Headlamp Prometheus, щоб показувати метрики безпосередньо на сторінках деталей ресурсів Cluster API.

Коли втулок Prometheus встановлено та налаштовано, метрики вбудовуються безпосередньо на сторінках деталей для Cluster, MachineDeployments, MachineSets та Machines. Ви можете переглядати стан ресурсів та дані про продуктивність разом із станами та відносинами власності, не переходячи на окрему панель.

Це спрощує зіставлення стану інфраструктури з поточними показниками під час налагодження або повсякденної експлуатації кластера — і все це безпосередньо в Headlamp.

Як використовувати

Дивіться plugins/cluster-api/README.md для інструкцій з встановлення та використання.

Розроблено під час програми LFX Mentorship

Цей втулок був розроблений в рамках програми CNCF LFX Mentorship в проєкті Headlamp. Програма наставництва надала можливість тісно співпрацювати зі спільнотою Headlamp під час створення можливостей для покращення керування Cluster API.

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

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

Робота над втулком триває, з додатковими покращеннями та можливостями, запланованими після початкового випуску Alpha.

Питання та відгуки

Це випуск Alpha, і відгуки спільноти безпосередньо впливають на подальший розвиток.

Повідомлення про помилки: Створити issue
Запити на нові можливості: Почати обговорення
Внесок: PR вітаються
Kubernetes Slack: Приєднатися до каналу #headlamp для питань та обговорень

Kubernetes v1.36: Застарівання та видалення Service ExternalIPs

Thu, 14 May 2026 10:35:00 -0800

Поле .spec.externalIPs для Service було ранньою спробою забезпечити функціональність, подібну до балансувальника навантаження в хмарі, для кластерів без хмари. На жаль, API передбачає, що кожному користувачу в кластері повністю довіряють, і в будь-якій ситуації, коли це не так, це відкриває можливості для різних зловживань у системі безпеки, як описано в CVE-2020-8554.

Починаючи з Kubernetes 1.21, проєкт Kubernetes рекомендує усім користувачам вимкнути .spec.externalIPs. Щоб спростити цей процес, у Kubernetes також було додано контролер допуску (DenyServiceExternalIPs), який можна увімкнути для цього. На той час SIG Network вважала, що типове блокування цієї функціональності було б надто великою зміною, що порушує сумісність.

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

У результаті поле .spec.externalIPs для Service тепер офіційно визнано застарілим в Kubernetes 1.36. Ми очікуємо, що в майбутньому мінорному випуску Kubernetes реалізацію цієї поведінки буде видалено з kube-proxy, а критерії відповідності Kubernetes будуть оновлені, щоб вимагати, щоб відповідні реалізації не надавали таку підтримку.

Примітка щодо термінології та того, що не застаріло

Фраза external IP має дещо перевантажене значення в Kubernetes:

API Service має поле .spec.externalIPs, яке можна використовувати для додавання додаткових IP-адрес, на які Service буде відповідати.
API Node має поле .status.addresses, яке може містити адреси кількох різних типів, один з яких називається ExternalIP.
Інструмент kubectl, при виводі інформації про Service типу LoadBalancer у типовому форматі виводу, покаже IP-адресу балансувальника навантаження в стовпці з заголовком EXTERNAL-IP.

Це застарівання стосується саме першого з них. Якщо ви не задаєте поле externalIPs у жодному зі своїх Service, то це вас не стосується.

Проте, як запобіжний захід, ви все одно можете увімкнути контролер допуску DenyServiceExternalIPs, щоб заблокувати будь-яке майбутнє використання поля externalIPs.

Альтернативи для `externalIPs`

Якщо ви використовуєте .spec.externalIPs, то існує кілька альтернатив.

Розглянемо Service, як показано нижче:

apiVersion: v1
kind: Service
metadata:
  name: my-example-service
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: my-example-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  externalIPs:
    - "192.0.2.4"

Використання вручну керованих Service типу LoadBalancer замість `externalIPs`

Найпростіший (але також найгірший) варіант — просто перейти від використання externalIPs до використання Service з type: LoadBalancer і призначення IP-адреси балансувальника навантаження вручну. Це, по суті, точно те ж саме, що і externalIPs, з однією важливою відмінністю: IP-адреса балансувальника навантаження є частиною .status Service, а не його .spec, і в кластері з увімкненим RBAC її типово не можуть редагувати звичайні користувачі. Таким чином, ця заміна для externalIPs буде доступна лише користувачам, яким адміністратори надали дозволи (хоча ці користувачі тоді будуть повністю уповноважені повторити CVE-2020-8554; все одно не буде жодних додаткових перевірок, щоб переконатися, що один користувач не краде IP-адреси іншого користувача тощо).

Через те, як працює .status у Kubernetes, спочатку потрібно створити Service без IP-адреси балансувальника навантаження, а потім додати IP як другий крок:

$ cat loadbalancer-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-example-service
spec:
  # prevent any real load balancer controllers from managing this service
  # by using a non-existent loadBalancerClass
  loadBalancerClass: non-existent-class
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: my-example-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
$ kubectl apply -f loadbalancer-service.yaml
service/my-example-service created
$ kubectl patch service my-example-service --subresource=status --type=merge -p '{"status":{"loadBalancer":{"ingress":[{"ip":"192.0.2.4"}]}}}'

Використання контролера балансування навантаження, що працює не у хмарі

Хоча Service типу LoadBalancer спочатку були розроблені для підтримки хмарних балансувальників навантаження, Kubernetes також може підтримувати їх на не хмарних платформах за допомогою стороннього контролера балансування навантаження, такого як MetalLB. Це вирішує проблеми безпеки, повʼязані з externalIPs, оскільки адміністратор може налаштувати, які діапазони IP-адрес контролер призначатиме Service, і контролер забезпечить, щоб два Service не могли одночасно використовувати одну й ту ж IP-адресу.

Отже, наприклад, після встановлення та налаштування MetalLB, адміністратор кластера може налаштувати пул IP-адрес для використання в кластері:

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: production
  namespace: metallb-system
spec:
  addresses:
  - 192.0.2.0/24
  autoAssign: true
  avoidBuggyIPs: false

Після цього користувач може створити Service з type: LoadBalancer, і MetalLB обробить призначення IP-адреси. MetalLB навіть підтримує застаріле поле loadBalancerIP у Service, тому кінцевий користувач може запитати конкретну IP-адресу (за умови, що вона доступна) для зворотної сумісності з підходом externalIPs, замість того, щоб отримати її випадковим чином:

apiVersion: v1
kind: Service
metadata:
  name: my-example-service
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: my-example-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  loadBalancerIP: "192.0.2.4"

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

Використання Gateway API

Ще одним потенційним рішенням є використання реалізації Gateway API.

Gateway API дозволяє адміністраторам кластера визначати ресурс Gateway, до якого можна прикріпити IP-адресу через поле .spec.addresses. Оскільки ресурси Gateway призначені для керування адміністраторами кластера, можна встановити правила RBAC, щоб лише привілейовані користувачі могли ними керувати.

Приклад того, як це може виглядати:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  addresses:
  - type: IPAddress
    value: "192.0.2.4"
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
  - name: example-gateway
  rules:
  - backendRefs:
    - name: example-svc
      port: 80
---
apiVersion: v1
kind: Service
metadata:
  name: example-svc
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: example-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Проєкт Gateway API — це нове покоління API-інтерфейсів Kubernetes для Ingress, балансування навантаження та Service Mesh. Gateway API було створено з метою усунення недоліків ресурсів Service та Ingress, що робить його надзвичайно надійним і стабільним рішенням, яке наразі активно розвивається.

План дій щодо припинення підтримки `externalIPs`

Орієнтовний план дій щодо припинення підтримки виглядає так:

З випуском Kubernetes 1.36 поле було визнане застарілим; Kubernetes тепер видає попередження, коли користувач використовує це поле
Приблизно через рік (v1.40 найраніше) підтримка .spec.externalIPs буде вимкнена в kube-proxy, але користувачі матимуть можливість повторно ввімкнути її, якщо їм знадобиться більше часу для міграції
Приблизно через ще один рік (v1.43 найраніше) підтримка буде повністю вимкнена; користувачі не матимуть можливості повторно ввімкнути її

Kubernetes v1.36: ハル (Хару)

Wed, 22 Apr 2026 00:00:00 +0000

Редактори: Chad M. Crowell, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Utkarsh Umre

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

Цей випуск складається з 70 удосконалень. З них 18 стали стабільними, 25 переходять у бета-версію, а 25 стали альфа-функціями.

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

Тема випуску та логотип

Ми відкриваємо 2026 рік з Kubernetes v1.36, випуском, який приходить, коли сезон змінюється і світло на горі зміщується. ハル (Хару) — це звук у японській мові, який несе багато значень; серед них ми найбільше цінуємо 春 (весна), 晴れ (харе, ясне небо) та 遥か (харука, далекий, віддалений). Сезон, небо та горизонт. Ви знайдете всі три в наступному тексті.

Логотип створено avocadoneko / Natsuho Ide під впливом серії Тридцять шість видів Фудзі (富嶽三十六景, Fugaku Sanjūrokkei) художника Кацусіки Хокусая, тієї ж серії, що подарувала світу Велику хвилю в Канаґаві. Наш логотип v1.36 переосмислює одну з найвідоміших гравюр серії, Ніжний вітер. Ясний ранок (凱風快晴, Gaifū Kaisei), також відому як Червона Фудзі (赤富士, Aka Fuji): гора, освітлена червоним світлом літнього світанку, без снігу після довгої відлиги. Тридцять шість видів здавалися підходящим числом для v1.36, і нагадуванням, що навіть Хокусай не зупинився на цьому.¹ За сценою пильнує штурвал Kubernetes, вміщений у небо поруч з горою.

Біля підніжжя Фудзі сидять Стелла (ліворуч) та Начо (праворуч), два коти зі штурвалом Kubernetes на нашийниках, які виконують роль комаїну — пари охоронців у вигляді левоподібних собак, що стережуть японські святилища. Саме пари, адже ніщо не охороняють поодинці. Стелла та Начо символізують набагато більшу групу: SIG та робочі групи, супровідників та рецензентів, людей, які стоять за документацією, блогами та перекладами, команду випуску, нових учасників, які роблять свої перші кроки, та досвідчених учасників, які повертаються сезон за сезоном. Kubernetes v1.36, як завжди, тримається на багатьох руках.

На Червоній Фудзі в логотипі пензлем виписано каліграфію 晴れに翔け (hare ni kake), «злітай у ясне небо». Це перша половина двовірша, який був занадто довгим, щоб поміститися на горі:

晴れに翔け、未来よ明け
hare ni kake, asu yo ake
«Злітай у ясне небо; назустріч завтрашньому світанку».²

Саме таке бажання ми вкладаємо в цей випуск: злетіти в ясне небо — для самого випуску, для проєкту та для всіх, хто спільно його випускає. Світанок над Червоною Фудзі не є кінцем, а переходом: цей випуск веде нас до наступного, а той — до наступного, у напрямку горизонтів, що виходять далеко за межі того, що може вмістити будь-який окремий вид.

_{1. Ця серія була настільки популярною, що Хокусай додав ще десять гравюр, довівши загальну кількість до сорока шести.}
_{2. 未来 означає «майбутнє» у найширшому сенсі, не лише завтра, а все, що ще попереду. Зазвичай читається як mirai; тут використовується неформальне читання asu.}

Основні оновлення

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

Stable: Детальна авторизація API

Від імені Kubernetes SIG Auth та SIG Node ми раді оголосити про перехід детальної авторизації API kubelet у стан загальної доступності (GA) в Kubernetes v1.36!

Функціональна можливість KubeletFineGrainedAuthz була впроваджена як необовʼязкова альфа-функція в Kubernetes v1.32, потім перейшла в бета-версію (стала типово увімкненою) в v1.33. Тепер ця функція стала загальнодоступною. Ця функція забезпечує більш точний контроль доступу з мінімальними привілеями до HTTPS API kubelet, усуваючи необхідність надавати надто широкий дозвіл nodes/proxy для типових сценаріїв моніторингу та спостереження.

Цю роботу було виконано в рамках KEP #2862, яку очолювали SIG Auth та SIG Node.

Beta: Статус справності ресурсів

До випуску v1.34 Kubernetes не мав вбудованого способу повідомляти про справність виділених пристроїв, що ускладнювало діагностику аварій Podʼів через апаратні збої. Спираючись на початковий альфа-випуск у v1.31, який зосереджувався на Device Plugins, Kubernetes v1.36 розширює цю функцію, підвищуючи поле allocatedResourcesStatus у .status для кожного Podʼа до бета-версії. Це поле забезпечує єдиний механізм звітування про справність для всього спеціалізованого апаратного забезпечення.

Користувачі тепер можуть запускати kubectl describe pod, щоб визначити, чи спричинений цикл аварійних перезапусків контейнера станом пристрою Unhealthy або Unknown, незалежно від того, чи було апаратне забезпечення надано через традиційні втулки або новіший фреймворк DRA. Така покращена наочність дозволяє адміністраторам та автоматизованим контролерам швидко виявляти несправне обладнання та оптимізувати відновлення високопродуктивних робочих навантажень.

Цю роботу було виконано в рамках KEP #4680, яку очолював SIG Node.

Alpha: Функції планування з урахуванням навантаження (Workload Aware Scheduling, WAS)

Раніше планувальник Kubernetes та контролери завдань керували Podʼами як незалежними одиницями, що часто призводило до фрагментованого планування або марнування ресурсів для складних розподілених робочих навантажень. Kubernetes v1.36 представляє комплексний набір функцій Workload Aware Scheduling (WAS) в альфа-версії, нативно інтегруючи контролер Job з оновленим Workload API та новим відокремленим PodGroup API, щоб розглядати повʼязані Podʼи як єдину логічну сутність.

Kubernetes v1.35 вже підтримував групове планування, вимагаючи, щоб мінімальна кількість Podʼів могла бути запланована, перш ніж будь-який з них буде привʼязано до вузлів. v1.36 іде далі з новим циклом планування PodGroup, який оцінює всю групу атомарно: або всі Podʼи в групі привʼязуються разом, або жоден з них.

Цю роботу було виконано в рамках кількох KEP (включаючи #4671, #5547, #5832, #5732 та #5710) під керівництвом SIG Scheduling та SIG Apps.

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

В цьому розділі представлено деякі з покращень, які тепер є стабільними після випуску v1.36.

Знімки груп томів

Після кількох циклів у бета-версії підтримка VolumeGroupSnapshot досягає загальної доступності (GA) в Kubernetes v1.36. Ця функція дозволяє робити аварійно-узгоджені знімки одночасно для кількох PersistentVolumeClaims. Підтримка знімків груп томів базується на наборі API розширень для групових знімків. Ці API дозволяють користувачам робити аварійно-узгоджені знімки для набору томів. Основна мета полягає в тім, щоб дозволити відновлювати цей набір знімків у нові томи та відновлювати робоче навантаження на основі аварійно-узгодженої точки відновлення.

Цю роботу було виконано в рамках KEP #3476 під керівництвом SIG Storage.

Змінювані обмеження на підключення томів

У Kubernetes v1.36 функція mutable CSINode allocatable переходить у стабільний стан. Це удосконалення дозволяє драйверам Container Storage Interface (CSI) динамічно оновлювати повідомлену максимальну кількість томів, які вузол може обробляти.

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

Цю роботу було виконано в рамках KEP #4876 під керівництвом SIG Storage.

API для зовнішнього підписування токенів ServiceAccount

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

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

З випуском GA у версії 1.36 зовнішнє підписування токенів ServiceAccount тепер є повністю підтримуваною опцією для платформ, що централізують ідентифікацію та підписування, спрощуючи інтеграцію із зовнішніми системами IAM та зменшуючи необхідність керувати ключами підписування безпосередньо всередині панелі управління.

Ця робота була виконана в рамках KEP #740 під керівництвом SIG Auth.

Функції DRA переходять у стабільний стан

Частина екосистеми динамічного виділення ресурсів (Dynamic Resource Allocation, DRA) досягає повної промислової зрілості в Kubernetes v1.36, оскільки ключові функції управління та вибору переходять у стабільний стан. Перехід адміністративного доступу DRA до GA забезпечує постійний, безпечний каркас для адміністраторів кластера для доступу та управління апаратними ресурсами на глобальному рівні, тоді як стабілізація пріоритетних списків гарантує, що логіка вибору ресурсів залишається послідовною та передбачуваною у всіх середовищах кластера.

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

Ця робота була виконана в рамках KEP #5018 та #4816 під керівництвом SIG Auth та SIG Scheduling.

Змінювальні політики допуску

Декларативне керування кластерами досягає нового рівня досконалості в Kubernetes v1.36 з переходом MutatingAdmissionPolicies у стабільний стан. Ця подія забезпечує нативну, високопродуктивну альтернативу традиційним вебхукам, дозволяючи адміністраторам визначати зміни ресурсів безпосередньо в API-сервері за допомогою Common Expression Language (CEL), повністю замінюючи потребу в зовнішній інфраструктурі для багатьох поширених випадків використання.

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

Ця робота була виконана в рамках KEP #3962 під керівництвом SIG API Machinery.

Декларативна валідація нативних типів Kubernetes за допомогою `validation-gen`

Розробка власних ресурсів досягає нового рівня ефективності в Kubernetes v1.36, оскільки декларативна валідація (з validation-gen) переходить у стабільний стан. Ця подія замінює ручне та часто схильне до помилок завдання написання складних схем OpenAPI, дозволяючи розробникам визначати складну логіку валідації безпосередньо в тегах структур Go за допомогою Common Expression Language (CEL).

Замість написання власних функцій валідації, учасники Kubernetes тепер можуть визначати правила валідації за допомогою коментарів маркерів IDL (таких як +k8s:minimum або +k8s:enum) безпосередньо у визначеннях типів API (types.go). Інструмент validation-gen аналізує ці коментарі для автоматичної генерації надійного коду валідації API під час компіляції. Це зменшує витрати на обслуговування та забезпечує, що валідація API залишається послідовною та синхронізованою з вихідним кодом.

Ця робота була виконана в рамках KEP #5073 під керівництвом SIG API Machinery.

Вилучення залежності від gogo protobuf для типів API Kubernetes

Безпека та довгострокова підтримуваність кодової бази Kubernetes роблять великий крок уперед у Kubernetes v1.36 із завершенням вилучення gogoprotobuf. Ця ініціатива усунула значну залежність від непідтримуваної бібліотеки gogoprotobuf, яка стала джерелом потенційних вразливостей безпеки та блокером для впровадження сучасних функцій мови Go.

Замість переходу на стандартне генерування Protobuf, що несло ризики сумісності для типів API Kubernetes, проєкт вирішив створити форк необхідної логіки генерації та перенести її всередину k8s.io/code-generator. Цей підхід успішно усуває непідтримувані залежності часу виконання з графа залежностей Kubernetes, зберігаючи при цьому поточну поведінку API та сумісність серіалізації. Для споживачів типів Go API Kubernetes ця зміна зменшує технічний борг і запобігає випадковому неправильному використанню зі стандартними бібліотеками protobuf.

Ця робота була виконана в рамках KEP #5589 під керівництвом SIG API Machinery.

Запит журналів вузлів

Раніше Kubernetes вимагав від адміністраторів кластера входу на вузли через SSH або реалізації клієнтського читача для налагодження проблем, що стосуються вузлів панелі управління або робочих вузлів. Хоча деякі проблеми все ще потребують прямого доступу до вузлів, проблеми з kube-proxy або kubelet можна діагностувати, переглядаючи їх журнали. Журнали вузлів надають адміністраторам кластера метод перегляду цих журналів за допомогою API kubelet та втулка kubectl, спрощуючи пошук несправностей без входу на вузли, подібно до налагодження проблем, повʼязаних з Podʼом або контейнером. Цей метод є незалежним від операційної системи і вимагає, щоб сервіси або вузли записували журнали в /var/log.

З переходом цієї функції до GA в Kubernetes 1.36 після ретельної перевірки продуктивності на робочих навантаженнях у промисловій експлуатації, вона типово увімкнена в kubelet через функціональну можливість NodeLogQuery. Крім того, також потрібно увімкнути параметр конфігурації kubelet enableSystemLogQuery.

Ця робота була виконана в рамках KEP #2258 під керівництвом SIG Windows.

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

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

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

Ця робота була виконана в рамках KEP #127 під керівництвом SIG Node.

Підтримка PSI на основі cgroupv2

Управління ресурсами вузлів та їх спостережуваність стають більш точними в Kubernetes v1.36, оскільки експорт метрик Pressure Stall Information (PSI) переходить у стабільну версію. Ця функція надає kubelet можливість повідомляти метрики «тиску» на CPU, памʼять та I/O, пропонуючи більш детальний погляд на конкуренцію за ресурси, ніж традиційні метрики використання.

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

Ця робота була виконана в рамках KEP #4205 під керівництвом SIG Node.

Джерело томів: OCI-артефакт та/або образ

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

Тепер розробники та інженери платформ можуть пакувати дані застосунків, моделі або статичні ресурси як OCI-артефакти та доставляти їх у Podʼи, використовуючи ті самі реєстри та робочі процеси версіонування, які вони вже використовують для образів контейнерів. Це поєднання управління образами та томами спрощує CI/CD-пайплайни, зменшує залежність від спеціалізованих сховищ для контенту лише для читання та забезпечує переносимість і безпечний доступ до даних у будь-якому середовищі.

Ця робота була виконана в рамках KEP #4639 під керівництвом SIG Node.

Нові функції у бета-версії

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

Зменшення неактуальності даних у контролерах

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

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

Ця робота була виконана в рамках KEP #5647 під керівництвом SIG API Machinery.

Покращення перевірки IP/CIDR

У Kubernetes v1.36 функція StrictIPCIDRValidation для полів API IP та CIDR переходить у бета-версію, посилюючи перевірку для виявлення некоректних адрес і префіксів, які раніше могли проходити непоміченими. Це допомагає запобігти непомітним помилкам конфігурації, коли Service, Pod, NetworkPolicy або інші ресурси посилаються на недійсні IP-адреси, що в іншому випадку могло б призвести до заплутаної поведінки під час виконання або проблем з безпекою.

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

Ця робота була виконана в рамках KEP #4858 під керівництвом SIG Network.

Відокремлення налаштувань користувача kubectl від конфігурацій кластера

Функція .kuberc для налаштування параметрів користувача kubectl продовжує бути в бета-версії та є типово увімкненою. Файл ~/.kube/kuberc дозволяє користувачам зберігати псевдоніми, типові прапорці та інші особисті налаштування окремо від файлів kubeconfig, які містять точки доступу кластера та облікові дані. Це відокремлення запобігає впливу особистих налаштувань на CI-конвеєри або спільні файли kubeconfig, забезпечуючи при цьому послідовний досвід роботи з kubectl у різних кластерах і контекстах.

У Kubernetes v1.36 .kuberc було розширено можливістю визначати політики для втулків облікових даних (allowlists або denylists) для забезпечення безпечнішої автентифікації. Користувачі можуть вимкнути цю функціональність, якщо потрібно, встановивши змінні середовища KUBECTL_KUBERC=false або KUBERC=off.

Ця робота була виконана в рамках KEP #3104 під керівництвом SIG CLI, за допомогою SIG Auth.

Змінювані ресурси контейнера, коли Job призупинено

У Kubernetes v1.36 функція MutablePodResourcesForSuspendedJobs переходить у бета-версію та є типово увімкненою. Це оновлення послаблює валідацію Job, дозволяючи оновлювати запити та обмеження ресурсів контейнера, таких як CPU, памʼять, GPU та розширені ресурси, поки Job призупинено.

Ця можливість дозволяє контролерам черг і операторам коригувати вимоги до пакетних робочих навантажень на основі умов кластера в реальному часі. Наприклад, система черг може призупинити вхідні Job, скоригувати їхні вимоги до ресурсів відповідно до доступної ємності або квоти, а потім відновити їх. Функція суворо обмежує змінюваність призупиненими Job (або Job, чиї Podʼи були завершені під час призупинення), щоб запобігти руйнівним змінам в активно працюючих Podʼах.

Ця робота була виконана в рамках KEP #5440 під керівництвом SIG Apps.

Обмежена імперсоніфікація

У Kubernetes v1.36 функція ConstrainedImpersonation для імперсоніфікації користувачів переходить у бета-версію, перетворюючи історичний механізм все-або-нічого на щось, що дійсно може дотримуватися принципів найменших привілеїв. Коли ця функція увімкнена, імперсонатор повинен мати два окремі набори дозволів: один для імперсоніфікації певної особи, а інший для виконання конкретних дій від імені цієї особи. Це запобігає використанню інструментами підтримки, контролерами або агентами вузлів імперсоніфікації для отримання ширшого доступу, ніж їм дозволено, навіть якщо їхні правила RBAC для імперсоніфікації налаштовані неправильно. Наявні правила імперсоніфікації продовжують працювати, але API-сервер спочатку віддає перевагу новим обмеженим перевіркам, роблячи перехід поступовим, а не одномоментним. З бета-версією в v1.36 ConstrainedImpersonation протестована, задокументована і готова до ширшого використання командами платформ, які покладаються на імперсоніфікацію для налагодження, проксирування або контролерів на рівні вузлів.

Ця робота була виконана в рамках KEP #5284 під керівництвом SIG Auth.

Функції DRA у стані бета

Фреймворк динамічного виділення ресурсів (Dynamic Resource Allocation, DRA) досягає ще одного етапу зрілості в Kubernetes v1.36, оскільки кілька основних функцій переходять у бета-версію та стають типово увімкненими. Цей перехід виводить DRA за межі базового виділення завдяки переходу в бета-версію пристроїв, що розділяються на розділи, та споживчої ємності, що дозволяє більш детально ділити апаратне забезпечення, таке як GPU, тоді як позначки taint та toleration пристроїв забезпечують використання спеціалізованих ресурсів лише відповідними робочими навантаженнями.

Тепер користувачі отримують значно надійніший та спостережуваний життєвий цикл ресурсів завдяки статусу пристрою ResourceClaim та можливості забезпечити підключення пристрою перед плануванням Podʼа. Інтегруючи ці функції з підтримкою розширених ресурсів, Kubernetes надає надійну, готову до промислового використання альтернативу застарілій системі втулків пристроїв, що дозволяє складним робочим навантаженням AI та HPC керувати апаратним забезпеченням з безпрецедентною точністю та операційною безпекою.

Ця робота була виконана в рамках кількох KEP (включаючи #5004, #4817, #5055, #5075, #4815 та #5007) під керівництвом SIG Scheduling та SIG Node.

Statusz для компонентів Kubernetes

У Kubernetes v1.36 функціональна можливість ComponentStatusz для основних компонентів Kubernetes переходить у бета-версію, надаючи точку доступу /statusz (типово увімкнена), яка показує деталі збірки та версії в реальному часі для кожного компонента. Ця z-сторінка з низькими накладними витратами показує інформацію, таку як час запуску, час роботи, версія Go, версія бінарного файлу, версія емуляції та мінімальна сумісна версія, що дозволяє операторам та розробникам швидко бачити, що саме працює, без необхідності переглядати журнали або конфігурації.

Точка доступу типово пропонує текстовий вигляд, зрозумілий для людей, а також версіоноване структуроване API (config.k8s.io/v1beta1) для програмного доступу у форматах JSON, YAML або CBOR через явне узгодження вмісту. Доступ надається групі system:monitoring, що забезпечує відповідність наявним захистам на точках доступу справності та метрик і запобігає витоку конфіденційних даних.

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

Ця робота була виконана в рамках KEP #4827 під керівництвом SIG Instrumentation.

Flagz для компонентів Kubernetes

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

Точка доступу підтримує як текстовий вигляд, зрозумілий для людей, так і версіоноване структуроване API (спочатку config.k8s.io/v1beta1), тож ви можете або використовувати curl під час інциденту, або інтегрувати його в автоматизовані інструменти, коли будете готові. Доступ надається групі system:monitoring, а конфіденційні значення можуть бути приховані, що забезпечує відповідність наявним практикам безпеки щодо точок доступу справності та стану.

З бета-версією ComponentFlagz тепер типово увімкнено та реалізовано в усіх основних компонентах панелі управління та агентах вузлів, із підтримкою модульних, інтеграційних та наскрізних тестів, які гарантують надійність точки доступу в продуктивних кластерах.

Ця робота була виконана в рамках KEP #4828 під керівництвом SIG Instrumentation.

Проксі змішаних версій (також відомий як проксі сумісності для невідомої версії)

У Kubernetes v1.36 функція проксі змішаних версій переходить у бета-версію, будуючись на її альфа-впровадженні у v1.28, щоб забезпечити безпечніше оновлення панелі управління для кластерів зі змішаними версіями. Тепер кожен запит API може бути направлений до екземпляра apiserver, який обслуговує запитану групу, версію та ресурс, зменшуючи кількість помилок 404 та збоїв через розбіжності версій.

Функція покладається на агреговане виявлення між однорідними екземплярами (peer), тому apiserver обмінюються інформацією про те, які ресурси та версії вони надають, а потім використовують ці дані для прозорого перенаправлення запитів за потреби. Нові метрики щодо перенаправленого трафіку та поведінки проксі допомагають операторам зрозуміти, як часто запити пересилаються і до яких екземплярів. Разом ці зміни полегшують запуск високодоступних панелей управління API зі змішаними версіями в продуктивному середовищі під час виконання багатокрокових або часткових оновлень панелі управління.

Ця робота була виконана в рамках KEP #4020 під керівництвом SIG API Machinery.

QoS памʼяті з cgroups v2

Тепер Kubernetes покращує якість обслуговування (QoS) памʼяті на вузлах Linux із cgroup v2 завдяки більш інтелектуальній багаторівневій системі захисту памʼяті, яка краще узгоджує механізми керування ядра з запитами та обмеженнями Podʼів, зменшуючи взаємні перешкоди та перевантаження (thrashing) для робочих навантажень, що використовують один і той самий вузол. У цій версії також вдосконалено спосіб, у який kubelet програмує параметри memory.high та memory.min, додано метрики та захисні механізми для запобігання активним блокуванням (livelock), а також запроваджено параметри конфігурації, що дозволяють операторам кластерів налаштовувати поведінку системи захисту памʼяті відповідно до своїх середовищ.

Ця робота була виконана в рамках KEP #2570 під керівництвом SIG Node.

Нові функції в альфа-версії

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

Масштабування HPA до нуля для власних метрик

Дотепер HorizontalPodAutoscaler (HPA) вимагав, щоб принаймні одна репліка залишалася активною, оскільки він міг розраховувати потреби в масштабуванні лише на основі метрик (таких як CPU або памʼять) від запущених Podʼів. Kubernetes v1.36 продовжує розвиток функції HPA scale to zero (типово вимкнена) в альфа-версії, дозволяючи робочим навантаженням масштабуватися до нуля реплік саме при використанні метрик Object або External.

Тепер користувачі можуть експериментувати зі значним зменшенням витрат на інфраструктуру, повністю зупиняючи важкі робочі навантаження, коли немає завдань в очікуванні. Хоча функція залишається за функціональною можливістю HPAScaleToZero, вона дозволяє HPA залишатися активним навіть при нульовій кількості запущених Podʼів, автоматично масштабуючи розгортання назад, як тільки зовнішня метрика (наприклад, довжина черги) вказує на появу нових завдань.

Ця робота була виконана в рамках KEP #2021 під керівництвом SIG Autoscaling.

Функції DRA в альфа-версії

Історично фреймворк динамічного виділення ресурсів (DRA) не мав безшовної інтеграції з високорівневими контролерами та забезпечував обмежену видимість метаданих пристроїв або їх доступності. Kubernetes v1.36 представляє хвилю удосконалень DRA в альфа-версії, включаючи нативну підтримку ResourceClaim для робочих навантажень та нативні ресурси DRA, що надають гнучкість DRA для управління CPU.

Зараз користувачі можуть використовувати downward API для надання складних атрибутів ресурсів безпосередньо контейнерам та отримувати переваги від покращеної видимості доступності ресурсів для більш передбачуваного планування. Ці оновлення, у поєднанні з підтримкою типів списків у атрибутах пристроїв, перетворюють DRA з низькорівневого примітиву на потужну систему, здатну обробляти складні мережеві та обчислювальні вимоги сучасних стеків штучного інтелекту та високопродуктивних обчислень (HPC).

Ця робота була виконана в рамках кількох KEP (включаючи #5729, #5304, #5517, #5677 та #5491) під керівництвом SIG Scheduling та SIG Node.

Нативна підтримка гістограм для метрик Kubernetes

Моніторинг високої роздільної здатності досягає нового рівня в Kubernetes v1.36 з введенням нативної підтримки гістограм в альфа-версії. У той час як класичні гістограми Prometheus покладалися на статичні, заздалегідь визначені кошики, що часто вимагало компромісу між точністю даних та використанням памʼяті, це оновлення дозволяє панелі управління експортувати розріджені гістограми, які динамічно регулюють свою роздільну здатність на основі даних у реальному часі.

Тепер оператори кластерів можуть отримувати точні розподіли затримок для kube-apiserver та інших основних компонентів без додаткових витрат на ручне керування кошиками. Ця архітектурна зміна забезпечує більш надійні SLI та SLO, надаючи високоточні теплові мапи, які залишаються точними навіть під час найнепередбачуваніших піків навантаження.

Ця робота була виконана в рамках KEP #5808 під керівництвом SIG Instrumentation.

Конфігурація контролю допуску на основі маніфестів

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

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

Ця робота була виконана в рамках KEP #5793 під керівництвом SIG API Machinery.

Потокова передача списків CRI

З введенням потокової передачі списків CRI в альфа-версії Kubernetes v1.36 використовує нові внутрішні операції потокової передачі. Це удосконалення вирішує проблему тиску на памʼять та піків затримки, які часто спостерігаються на вузлах великого масштабу, замінюючи традиційні, монолітні запити List між kubelet та середовищем виконання контейнерів на більш ефективний серверний потоковий RPC.

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

Ця робота була виконана в рамках KEP #5825 під керівництвом SIG Node.

Інші значущі зміни

Виведення з експлуатації Ingress NGINX

Щоб забезпечити безпеку та надійність екосистеми, Kubernetes SIG Network та Комітет з реагування на загрози безпеці вивели з експлуатації Ingress NGINX 24 березня 2026 року. З цієї дати не було випущено жодних нових версій, виправлень помилок або оновлень для усунення виявлених вразливостей безпеки. Наявні розгортання Ingress NGINX продовжуватимуть працювати, а артефакти встановлення, такі як Helm charts та образи контейнерів, залишатимуться доступними.

За повними деталями звертайтесь до офіційного повідомлення про виведення Ingress NGINX з експлуатації.

Швидше позначення мітками SELinux для томів (GA)

Kubernetes v1.36 робить покращення монтування томів SELinux загальнодоступним. Ця зміна замінила рекурсивне переназначення міток файлів на опцію mount -o context=XYZ, застосовуючи правильну мітку SELinux до всього тому під час монтування. Це забезпечує більш стабільну продуктивність і зменшує затримки запуску Podʼів на системах з увімкненим SELinux.

Ця функція була впроваджена як бета у v1.28 для томів ReadWriteOncePod. У v1.32 вона отримала метрики та опцію відмови (securityContext.seLinuxChangePolicy: Recursive) для допомоги у виявленні конфліктів. Тепер у v1.36 вона досягає стабільного стану і типово застосовується до всіх томів, а Podʼи або CSIDrivers вмикають її через spec.seLinuxMount.

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

Розробники несуть відповідальність за налаштування поля seLinuxChangePolicy та міток томів SELinux на Podʼах. Незалежно від того, чи вони створюють Deployment, StatefulSet, DaemonSet або навіть власний ресурс, що включає шаблон Podʼа, недбалість у цих налаштуваннях може призвести до різних проблем, таких як неправильний запуск Podʼів при спільному використанні тому.

Kubernetes v1.36 є ідеальним випуском для аудиту ваших кластерів. Щоб дізнатися більше, перегляньте допис у блозі SELinux Volume Label Changes goes GA (and likely implications in v1.37).

Для отримання додаткової інформації про це удосконалення звертайтесь до KEP-1710: Speed up recursive SELinux label change.

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

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

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

У цьому випуску всього 18 удосконалень, які були переведені до стабільного стану:

Застарівання, вилучення та оновлення спільноти

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

Застарівання поля Service .spec.externalIPs

З цим випуском поле externalIPs у Service spec визнано застарілим. Це означає, що функціональність існує, але більше не буде працювати в майбутній версії Kubernetes. Вам слід планувати міграцію, якщо ви наразі покладаєтеся на це поле. Це поле було відомою проблемою безпеки протягом багатьох років, дозволяючи атаки типу «людина посередині» на трафік вашого кластера, як це задокументовано в CVE-2020-8554. Починаючи з Kubernetes v1.36, ви будете бачити попередження про застарівання при його використанні, а повне вилучення заплановано на v1.43.

Якщо ваші Service все ще покладаються на externalIPs, розгляньте можливість використання Service типу LoadBalancer для керованого хмарою ingress, NodePort для простого відкриття портів або Gateway API для більш гнучкого та безпечного способу обробки зовнішнього трафіку.

Для отримання додаткової інформації про це поле та його застарівання зверніться до розділу Зовнішні IP або прочитайте KEP-5707: Deprecate service.spec.externalIPs.

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

Тип томів gitRepo був визнаний застарілим з версії v1.11. У Kubernetes v1.36 втулок томів gitRepo назавжди вимкнено і його не можна знову увімкнути. Ця зміна захищає кластери від критичної проблеми безпеки, коли використання gitRepo могло дозволити зловмиснику виконувати код від імені root на вузлі.

Хоча gitRepo був застарілим протягом багатьох років і рекомендувалися кращі альтернативи, його все ще технічно можна було використовувати в попередніх випусках. Починаючи з v1.36, цей шлях закрито назавжди, тому будь-які наявні робочі навантаження, що залежать від gitRepo, треба мігрувати на підтримувані підходи, такі як контейнери ініціалізації або зовнішні інструменти типу git-sync.

Для отримання додаткової інформації про це вилучення зверніться до KEP-5040: Remove gitRepo volume driver

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

Перегляньте повні деталі випуску Kubernetes v1.36 у наших примітках до випуску.

Доступність

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

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

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

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

Ми хотіли б подякувати всій команді випуску за години наполегливої праці, щоб представити випуск Kubernetes v1.36 нашій спільноті. Склад команди випуску варіюється від новачків-стажерів (shadows) до досвідчених керівників команд, які повертаються з досвідом, здобутим за кілька циклів випуску. Особлива подяка нашому керівнику випуску, Ryota Sawada, за керівництво успішним циклом випуску, за його практичний підхід до вирішення проблем і за енергію та турботу, які рухають нашу спільноту вперед.

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

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

Під час циклу випуску v1.36, який тривав 15 тижнів з 12 січня 2026 року по 22 квітня 2026 року, Kubernetes отримав внески від 106 різних компаній та 491 окремого учасника. У ширшій екосистемі хмарних технологій ця цифра зростає до 370 компаній, а загальна кількість учасників становить 2235.

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

Джерела цих даних:

Оновлення подій

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

Квітень 2026

KCD — Kubernetes Community Days: Guadalajara: 18 квітня 2026 | Гвадалахара, Мексика

Травень 2026

KCD — Kubernetes Community Days: Toronto: 13 травня 2026 | Торонто, Канада
KCD — Kubernetes Community Days: Texas: 15 травня 2026 | Остін, США
KCD — Kubernetes Community Days: Istanbul: 15 травня 2026 | Стамбул, Туреччина
KCD — Kubernetes Community Days: Helsinki: 20 травня 2026 | Гельсінкі, Фінляндія
KCD — Kubernetes Community Days: Czech & Slovak: 21 травня 2026 | Прага, Чехія

Червень 2026

KCD — Kubernetes Community Days: New York: 10 червня 2026 | Нью-Йорк, США
KCD — Kubernetes Community Days: Kuala Lumpur: 27 червня 2026 | Куала-Лумпур, Малайзія
KubeCon + CloudNativeCon India 2026: 18-19 червня 2026 | Мумбаї, Індія

Липень 2026

KubeCon + CloudNativeCon Japan 2026: 29-30 липня 2026 | Йокогама, Японія

Вересень 2026

KCD — Kubernetes Community Days: San Francisco Bay Area: 1 вересня 2026 | Маунтін-Вʼю, США
KubeCon + CloudNativeCon China 2026: 8-9 вересня 2026 | Шанхай, Китай

Жовтень 2026

KCD — Kubernetes Community Days: UK: 19 жовтня 2026 | Едінбург, Велика Британія

Листопад 2026

KCD — Kubernetes Community Days: Porto: 19 листопада 2026 | Порту, Португалія
KubeCon + CloudNativeCon North America 2026: 9-12 листопада 2026 | Солт-Лейк-Сіті, США

Найсвіжіші відомості про події можна знайти тут.

Вебінар, присвячений новому випуску

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

Приєднуйтесь

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

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

Забезпечення безпечного налагодження в Kubernetes

Wed, 18 Mar 2026 10:00:00 -0800

Під час налагодження в промисловому середовищі найшвидший шлях часто передбачає широкий доступ, такий як cluster-admin (ClusterRole, що надає доступ рівня адміністратора), спільні bastions/jump boxes або довготривалі SSH-ключі. Це працює в моменті, але має дві поширені проблеми: аудит стає складним, а тимчасові винятки мають тенденцію ставати звичними.

Цей допис пропонує рекомендації, які можна застосувати до поточних середовищ Kubernetes з мінімальними змінами інструментів:

Мінімальні привілеї з RBAC
Короткострокові облікові дані, привʼязані до ідентичності
Модель рукостискання в стилі SSH для хмарно-орієнтованого налагодження

Хороша архітектура для забезпечення безпечного налагодження в промислових середовищах полягає у використанні шлюзу SSH за принципом "just-in-time" (часто розгортається як Pod на вимогу в кластері). Він діє як SSH-подібні "парадні двері", що робить тимчасовий доступ дійсно тимчасовим. Ви можете автентифікуватися за допомогою короткострокових облікових даних, привʼязаних до ідентичності, встановити сеанс до шлюзу, а шлюз використовує API Kubernetes та RBAC для контролю того, що вони можуть робити, наприклад pods/log, pods/exec та pods/portforward. Сеанси автоматично закінчуються, а логи шлюзу та логи аудиту Kubernetes фіксують, хто отримав доступ до чого і коли, без облікових записів bastion для спільного використання або довготривалих ключів.

1) Використання брокера доступу поверх RBAC Kubernetes

RBAC контролює, хто і що може робити в Kubernetes. Багато середовищ Kubernetes покладаються в основному на RBAC для авторизації, хоча Kubernetes також підтримує інші режими авторизації, такі як авторизація через Webhook. Ви можете забезпечити доступ безпосередньо за допомогою Kubernetes RBAC або розмістити брокера доступу перед кластером, який все ще покладається на дозволи Kubernetes під капотом. У будь-якій моделі Kubernetes RBAC залишається джерелом істини щодо того, що дозволяє API Kubernetes і в якому обсязі.

Брокер доступу додає елементи керування, які RBAC покриває погано. Наприклад, він може вирішувати, чи запит автоматично схвалюється або потребує ручного схвалення, чи може користувач виконувати команду, і які команди дозволені в сеансі. Він також може керувати членством у групах, щоб ви надавали дозволи групам замість окремих користувачів. Kubernetes RBAC може дозволяти дії, такі як pods/exec, але не може обмежити, які команди виконуються всередині сеансу exec.

З цією моделлю Kubernetes RBAC визначає дозволені дії для користувача або групи (наприклад, чергової команди в одному просторі імен). Рекомендується визначати правила доступу лише для груп або ServiceAccount — ніколи для окремих користувачів. Брокер або постачальник ідентичності потім додає або видаляє користувачів з цієї групи за потреби.

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

Приклад: роль налагодження для чергового в межах простору імен

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: oncall-debug
  namespace: <namespace>
rules:
  # Дізнатись, що працює
  - apiGroups: [""]
    resources: ["pods", "events"]
    verbs: ["get", "list", "watch"]

  # Читання логів
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]

  # Інтерактивні дії налагодження
  - apiGroups: [""]
    resources: ["pods/exec", "pods/portforward"]
    verbs: ["create"]

  # Розуміння стану розгортання/контролера
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets"]
    verbs: ["get", "list", "watch"]

  # Необовʼязково: дозволити ефемерні контейнери для kubectl debug
  - apiGroups: [""]
    resources: ["pods/ephemeralcontainers"]
    verbs: ["update"]

Прикріпіть роль до групи (а не до окремих користувачів), щоб членством можна було керувати через вашого провайдера ідентичності:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: oncall-debug
  namespace: <namespace>
subjects:
  - kind: Group
    name: oncall-<team-name>
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: oncall-debug
  apiGroup: rbac.authorization.k8s.io

2) Короткострокові облікові дані, привʼязані до особи

Мета полягає в тому, щоб використовувати короткострокові облікові дані, привʼязані до особи, які чітко повʼязують сеанс з реальною людиною та швидко закінчуються. Ці облікові дані можуть включати ідентичність користувача та обсяг того, що йому дозволено робити. Вони зазвичай підписуються за допомогою приватного ключа, який залишається у інженера, наприклад, апаратно захищеного ключа (наприклад, YubiKey), тому їх не можна підробити без доступу до цього ключа.

Ви можете реалізувати це за допомогою автентифікації, вбудованої в Kubernetes (наприклад, клієнтські сертифікати або потік на основі OIDC), або дозволити брокеру доступу з попереднього розділу видавати короткострокові облікові дані від імені користувача. У багатьох налаштуваннях Kubernetes все ще використовує RBAC для застосування дозволів на основі автентифікованої особи та груп/тверджень. Якщо ви використовуєте брокера доступу, він також може кодувати додаткові обмеження обсягу в облікових даних і застосовувати їх під час сеансу, наприклад, до якого кластера або простору імен застосовується сеанс і які дії (або затверджені команди) дозволені для Podʼів або вузлів. У будь-якому випадку облікові дані повинні бути підписані сертифікаційним центром (CA), і цей CA слід регулярно оновлювати (наприклад, щоквартально), щоб обмежити довгострокові ризики.

Варіант A: короткострокові токени OIDC

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

Наприклад:

users:
- name: oncall
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1
      command: cred-helper
      args: ["--cluster=prod", "--ttl=30m"]

Варіант B: короткострокові клієнтські сертифікати (X.509)

Якщо ваш API-сервер (або брокер доступу з попереднього розділу) налаштований на довіру до клієнтського CA, ви можете використовувати короткострокові клієнтські сертифікати для доступу до відлагодження. Ідея така:

Приватний ключ створюється і зберігається на машині інженера (бажано з апаратною підтримкою, наприклад, ключ, який неможливо експортувати, у YubiKey/PIV токені)
Видається короткостроковий сертифікат (часто через API CertificateSigningRequest або вашого брокера доступу з попереднього розділу, з TTL).
RBAC зіставляє автентифіковану особу з мінімальною роллю

Це просто реалізувати за допомогою API Kubernetes CertificateSigningRequest.

Згенеруйте ключ і CSR локально:

# Згенеруйте приватний ключ.
# Це можна зробити всередині апаратного токена;
# OpenSSL та кілька подібних інструментів підтримують це.
openssl genpkey -algorithm Ed25519 -out oncall.key

openssl req -new -key oncall.key -out oncall.csr \
  -subj "/CN=user/O=oncall-payments"

Створіть CertificateSigningRequest з коротким терміном дії:

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: oncall-<user>-20260218
spec:
  request: <base64-encoded oncall.csr>
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 1800  # 30 minutes
  usages:
    - client auth

Після того як CSR буде затверджено та підписано, ви можете витягти виданий сертифікат і використовувати його разом із приватним ключем для автентифікації, наприклад через kubectl.

3) Використання шлюзу доступу "just-in-time" для виконання команд відлагодження

Після отримання короткострокових облікових даних ви можете використовувати їх для відкриття сеансу безпечного доступу до шлюзу доступу "just-in-time", часто доступного через SSH і створюваного за потреби. Якщо шлюз доступу доступний через SSH, поширеним підходом є видача інженеру короткострокового сертифіката користувача OpenSSH для сеансу. Шлюз довіряє вашому SSH CA, автентифікує інженера під час підключення, а потім застосовує затверджену політику сеансу перед виконанням викликів API Kubernetes від імені користувача. Сертифікати OpenSSH відокремлені від клієнтських сертифікатів Kubernetes X.509, тому зазвичай вони розглядаються як окремі рівні.

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

Приклад: Привʼязки ролей у межах простору імен

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: jit-debug
  namespace: <namespace>
  annotations:
    kubernetes.io/description: >
      Colleagues performing semi-privileged debugging, with access provided
      just in time and on demand.
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jit-debug
  namespace: <namespace>
subjects:
  - kind: Group
    name: jit:oncall:<namespace>   # зіставлено з короткостроковим обліковим записом (сертифікат/OIDC)
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: jit-debug
  apiGroup: rbac.authorization.k8s.io

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

Приклад: Привʼязки ролей у межах кластера

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: jit-cluster-read
rules:
  - apiGroups: [""]
    resources: ["nodes", "namespaces"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: jit-cluster-read
subjects:
  - kind: Group
    name: jit:oncall:cluster
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: jit-cluster-read
  apiGroup: rbac.authorization.k8s.io

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

Більш детальні обмеження, такі як «тільки цей Pod/вузол» або «тільки ці команди», зазвичай застосовуються шлюзом/брокером доступу під час сеансу, але Kubernetes також пропонує інші варіанти, такі як ValidatingAdmissionPolicy для обмеження записів і webhook authorization для власної авторизації за діями.

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

Посилання

Відмова від відповідальності: Думки, висловлені в цьому дописі, належать виключно автору і не відображають погляди роботодавця автора або будь-якої іншої організації.

Що потрібно знати перед міграцією: пʼять несподіваних особливостей поведінки Ingress-NGINX

Fri, 27 Feb 2026 07:30:00 -0800

Як було оголошено в листопаді 2025 року, Kubernetes виведе Ingress-NGINX з експлуатації у березні 2026 року. Незважаючи на широке використання, Ingress-NGINX має безліч несподіваних типових налаштувань і побічних ефектів, які, ймовірно, присутні у вашому кластері зараз. У цьому дописі описано ці особливості, щоб ви могли безпечно здійснити міграцію та свідомо вирішити, які з них зберегти. У дописі також порівнюється Ingress-NGINX та Gateway API і показано, як зберегти особливості Ingress-NGINX у Gateway API. Ризик, що повторюється в кожному розділі, є однаковим: на перший погляд правильно виконане перетворення все одно може спричинити перебої в роботі, якщо не врахувати особливості Ingress-NGINX.

Я припускаю, що ви, читачі, маєте певне уявлення про Ingress-NGINX та Ingress API. У більшості прикладів як бекенд використовується httpbin.

Також зверніть увагу, що Ingress-NGINX і NGINX Ingress — це два окремі контролери Ingress. Ingress-NGINX — це контролер Ingress, який підтримується та керується спільнотою Kubernetes і який буде виведений з експлуатації в березні 2026 року. NGINX Ingress — це контролер Ingress від F5. Обидва використовують NGINX як площину даних, але в іншому не повʼязані між собою. Відтепер у цій публікації ми будемо обговорювати лише Ingress-NGINX.

1. Збіги регулярних виразів базуються на префіксах і нечутливі до регістру

Припустимо, ви хочете маршрутизувати всі запити зі шляхом, що складається лише з трьох великих літер, до сервісу httpbin. Ви можете створити наступний Ingress з анотацією nginx.ingress.kubernetes.io/use-regex: "true" та шаблоном регулярного виразу /[A-Z]{3}.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: regex-match-ingress
  annotations:
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: regex-match.example.com
    http:
      paths:
      - path: "/[A-Z]{3}"
        pathType: ImplementationSpecific
        backend:
          service:
            name: httpbin
            port:
              number: 8000

Однак, оскільки збіги регулярних виразів є префіксними та нечутливими до регістру, Ingress-NGINX маршрутизує до httpbin будь-який запит зі шляхом, що починається з будь-яких трьох літер:

curl -sS -H "Host: regex-match.example.com" http://<your-ingress-ip>/uuid

Результат буде схожим на:

{
  "uuid": "e55ef929-25a0-49e9-9175-1b6e87f40af7"
}

Примітка: Точка доступу /uuid httpbin повертає випадковий UUID. UUID у тілі відповіді означає, що запит було успішно маршрутизовано до httpbin.

За допомогою Gateway API ви можете використовувати зіставлення шляху HTTP з type, що має значення RegularExpression, для зіставлення шляхів за регулярним виразом. Зіставлення RegularExpression залежать від конкретної реалізації, тому перевірте реалізацію Gateway API, щоб переконатися в семантиці зіставлення RegularExpression. Популярні реалізації Gateway API на основі Envoy, такі як Istio¹, Envoy Gateway та Kgateway, виконують повне зіставлення з урахуванням регістру.

Отже, якщо ви не знаєте, що шаблони Ingress-NGINX є префіксними і нечутливими до регістру, і без вашого відома клієнти або застосунки надсилають трафік до /uuid (або /uuid/some/other/path), ви можете створити такий маршрут HTTP.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: regex-match-route
spec:
  hostnames:
  - regex-match.example.com
  parentRefs:
  - name: <your gateway>  # Змінюйте це залежно від вашого випадку використання
  rules:
  - matches:
    - path:
        type: RegularExpression
        value: "/[A-Z]{3}"
    backendRefs:
    - name: httpbin
      port: 8000

Однак, якщо ваша реалізація Gateway API виконує повне зіставлення з урахуванням регістру, вищевказаний маршрут HTTP не буде відповідати запиту зі шляхом /uuid. Таким чином, вищевказаний маршрут HTTP спричинить збій, оскільки запити, які Ingress-NGINX маршрутизував до httpbin, завершаться з помилкою 404 Not Found на шлюзі.

Щоб зберегти зіставлення регулярних виразів без урахування регістру, ви можете використовувати наступний маршрут HTTP.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: regex-match-route
spec:
  hostnames:
  - regex-match.example.com
  parentRefs:
  - name: <your gateway>  # Змінюйте це залежно від вашого випадку використання
  rules:
  - matches:
    - path:
        type: RegularExpression
        value: "/[a-zA-Z]{3}.*"
    backendRefs:
    - name: httpbin
      port: 8000

Крім того, вищезазначені проксі підтримують прапорець (?i) для позначення збігів, нечутливих до регістру. Використовуючи цей прапорець, шаблон може бути таким: (?i)/[a-z]{3}.*.

2. `nginx.ingress.kubernetes.io/use-regex` застосовується до всіх шляхів хоста в усіх обʼєктах Ingress (Ingress-NGINX)

Тепер припустимо, що у вас є Ingress з анотацією nginx.ingress.kubernetes.io/use-regex: "true", але ви хочете маршрутизувати до httpbin запити зі шляхом, що точно дорівнює /headers. На жаль, ви зробили одруківку і встановили шлях /Header замість /headers.

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: regex-match-ingress
  annotations:
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: regex-match.example.com
    http:
      paths:
      - path: "<some regex pattern>"
        pathType: ImplementationSpecific
        backend:
          service:
            name: <your backend>
            port:
              number: 8000
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: regex-match-ingress-other
spec:
  ingressClassName: nginx
  rules:
  - host: regex-match.example.com
    http:
      paths:
      - path: "/Header" # тут одруківка, має бути /headers
        pathType: Exact
        backend:
          service:
            name: httpbin
            port:
              number: 8000

Більшість очікує, що запит до /headers поверне відповідь 404 Not Found, оскільки /headers не відповідає Exact шляху /Header. Однак, оскільки Ingress regex-match-ingress має анотацію nginx.ingress.kubernetes.io/use-regex: "true" і хост regex-match.example.com, всі шляхи з хостом regex-match.example.com розглядаються як регулярні вирази в усіх обʼєктах Ingress (Ingress-NGINX). Оскільки шаблони регулярних виразів є префіксними збігами, нечутливими до регістру, /headers збігається з шаблоном /Header, і Ingress-NGINX маршрутизує такі запити до httpbin. Виконання команди

curl -sS -H "Host: regex-match.example.com" http://<your-ingress-ip>/headers

дасть наступний результат:

{
  "headers": {
    ...
  }
}

Примітка: Точка доступу /headers httpbin повертає заголовки запиту. Те, що відповідь містить заголовки запиту в тілі, означає, що запит було успішно маршрутизовано до httpbin.

Gateway API не перетворює і не інтерпретує непомітно збіги Exact і Prefix як шаблони регулярних виразів. Тому, якщо ви перетворили вищезазначені обʼєкти Ingress у наступний маршрут HTTP і зберегли одруківку та типи збігів, запити до /headers будуть відповідати кодом 404 Not Found замість 200 OK.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: regex-match-route
spec:
  hostnames:
  - regex-match.example.com
  rules:
  ...
  - matches:
    - path:
        type: Exact
        value: "/Header"
    backendRefs:
    - name: httpbin
      port: 8000

Щоб зберегти зіставлення префіксів без урахування регістру, можна змінити

  - matches:
    - path:
        type: Exact
        value: "/Header"

на

  - matches:
    - path:
        type: RegularExpression
        value: "(?i)/Header"

А ще краще, ви могли б виправити одруківку і змінити збіг на

  - matches:
    - path:
        type: Exact
        value: "/headers"

3. Ціль перезапису передбачає використання регулярних виразів

У цьому випадку припустимо, що ви хочете перезаписати шлях запитів зі шляхом /ip на /uuid перед їх маршрутизацією до httpbin, і, як у розділі 2, ви хочете маршрутизувати до httpbin запити зі шляхом, що точно дорівнює /headers. Однак ви випадково зробили одруківку і встановили шлях /IP замість /ip і /Header замість /headers.

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-target-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "/uuid"
spec:
  ingressClassName: nginx
  rules:
  - host: rewrite-target.example.com
    http:
      paths:
      - path: "/IP"
        pathType: Exact
        backend:
          service:
            name: httpbin
            port:
              number: 8000
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-target-ingress-other
spec:
  ingressClassName: nginx
  rules:
  - host: rewrite-target.example.com
    http:
      paths:
      - path: "/Header"
        pathType: Exact
        backend:
          service:
            name: httpbin
            port:
              number: 8000

Анотація nginx.ingress.kubernetes.io/rewrite-target: "/uuid" призводить до того, що шляхи запитів, які відповідають шляхам в Ingress rewrite-target-ingress, перезаписуються на /uuid перед маршрутизацією до бекенду.

Незважаючи на те, що жоден Ingress не має анотації nginx.ingress.kubernetes.io/use-regex: "true", наявність анотації nginx.ingress.kubernetes.io/rewrite-target в Ingress rewrite-target-ingress призводить до того, що всі шляхи з хостом rewrite-target.example.com розглядаються як шаблони регулярних виразів. Іншими словами, nginx.ingress.kubernetes.io/rewrite-target непомітно додає анотацію nginx.ingress.kubernetes.io/use-regex: "true" разом з усіма побічними ефектами, описаними вище.

Наприклад, шлях запиту до /ip перезаписується на /uuid, оскільки /ip відповідає префіксному шаблону /IP, нечутливому до регістру, в Ingress rewrite-target-ingress. Після виконання команди

curl -sS -H "Host: rewrite-target.example.com" http://<your-ingress-ip>/ip

результат буде схожим на:

{
  "uuid": "12a0def9-1adg-2943-adcd-1234aadfgc67"
}

Як і в прикладі з nginx.ingress.kubernetes.io/use-regex, Ingress-NGINX обробляє path інших обʼєктів Ingress з хостом rewrite-target.example.com як префіксні шаблони, нечутливі до регістру. Виконання команди

curl -sS -H "Host: rewrite-target.example.com" http://<your-ingress-ip>/headers

дає результат, який виглядає так

{
  "headers": {
    ...
  }
}

Ви можете налаштувати перезапис шляхів у Gateway API за допомогою фільтра перезапису HTTP URL, який не перетворює непомітно ваші збіги Exact та Prefix у шаблони регулярних виразів. Однак, якщо ви не знаєте про побічні ефекти анотації nginx.ingress.kubernetes.io/rewrite-target і не розумієте, що /Header і /IP є одруківками, ви можете створити такий маршрут HTTP.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: rewrite-target-route
spec:
  hostnames:
  - rewrite-target.example.com
  parentRefs:
  - name: <your-gateway>
  rules:
  - matches:
    - path:
        type: Exact
        value: "/IP"
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplaceFullPath
          replaceFullPath: /uuid
    backendRefs:
    - name: httpbin
      port: 8000
  - matches:
    - path:
        # Це точний збіг, незалежно від інших правил
        type: Exact
        value: "/Header"
    backendRefs:
    - name: httpbin
      port: 8000

Як і в розділі 2, оскільки /IP тепер є типом збігу Exact у вашому маршруті HTTP, запити до /ip будуть відповідати кодом 404 Not Found замість 200 OK. Аналогічно, запити до /headers також будуть відповідати кодом 404 Not Found замість 200 OK. Таким чином, цей маршрут HTTP порушить роботу застосунків і клієнтів, які покладаються на маршрути /ip і /headers.

Щоб виправити це, ви можете змінити збіги в маршруті HTTP на збіги регулярних виразів і змінити шаблони шляхів на префіксні збіги, нечутливі до регістру, як показано нижче.

  - matches:
    - path:
        type: RegularExpression
        value: "(?i)/IP.*"
...
  - matches:
    - path:
        type: RegularExpression
        value: "(?i)/Header.*"

Або ви можете залишити тип збігу Exact і виправити одруківки.

4. Запити, в яких відсутній кінцевий слеш, перенаправляються на той самий шлях з кінцевим слешем

Розглянемо наступний Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: trailing-slash-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: trailing-slash.example.com
    http:
      paths:
      - path: "/my-path/"
        pathType: Exact
        backend:
          service:
            name: <your-backend>
            port:
              number: 8000

Ви можете очікувати, що Ingress-NGINX відповість на /my-path кодом 404 Not Found, оскільки /my-path не збігається точно з Exact шляхом /my-path/. Однак Ingress-NGINX перенаправляє запит на /my-path/ з кодом 301 Moved Permanently, оскільки єдина відмінність між /my-path і /my-path/ — це кінцевий слеш.

curl -isS -H "Host: trailing-slash.example.com" http://<your-ingress-ip>/my-path

Результат виглядає так:

HTTP/1.1 301 Moved Permanently
...
Location: http://trailing-slash.example.com/my-path/
...

Те саме стосується випадків, коли ви змінюєте pathType на Prefix. Однак перенаправлення не відбувається, якщо шлях є шаблоном регулярного виразу.

Сумісні реалізації Gateway API не налаштовують непомітно жодних перенаправлень. Якщо клієнти або сервіси нижчого рівня залежать від цього перенаправлення, міграція до Gateway API, під час якої перенаправлення запитів не налаштовано явно, спричинить збій, оскільки запити до /my-path тепер будуть відповідати кодом 404 Not Found замість 301 Moved Permanently. Ви можете явно налаштувати перенаправлення за допомогою фільтра перенаправлення HTTP-запитів наступним чином:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: trailing-slash-route
spec:
  hostnames:
  - trailing-slash.example.com
  parentRefs:
  - name: <your-gateway>
  rules:
  - matches:
    - path:
        type: Exact
        value: "/my-path"
    filters:
      requestRedirect:
        statusCode: 301
        path:
          type: ReplaceFullPath
          replaceFullPath: /my-path/
  - matches:
    - path:
        type: Exact # або Prefix
        value: "/my-path/"
    backendRefs:
    - name: <your-backend>
      port: 8000

5. Ingress-NGINX нормалізує URL-адреси

Нормалізація URL-адреси — це процес перетворення URL-адреси в канонічну форму перед її зіставленням з правилами Ingress і маршрутизацією. Особливості нормалізації URL-адреси визначені в RFC 3986, розділ 6.2, але ось декілька прикладів

видалення сегментів шляху, які є лише .: my/./path -> my/path
сегмент шляху .. видаляє попередній сегмент: my/../path -> /path
усунення дублювання послідовних косих рисок у шляху: my//path -> my/path

Ingress-NGINX нормалізує URL-адреси перед їх зіставленням з правилами Ingress. Наприклад, розглянемо наступний Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: path-normalization-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: path-normalization.example.com
    http:
      paths:
      - path: "/uuid"
        pathType: Exact
        backend:
          service:
            name: httpbin
            port:
              number: 8000

Ingress-NGINX нормалізує шлях наступних запитів до /uuid. Тепер, коли запит відповідає шляху Exact /uuid, Ingress-NGINX відповідає або кодом 200 OK, або кодом 301 Moved Permanently до /uuid.

Для наступних команд

curl -sS -H "Host: path-normalization.example.com" http://<your-ingress-ip>/uuid
curl -sS -H "Host: path-normalization.example.com" http://<your-ingress-ip>/ip/abc/../../uuid
curl -sSi -H "Host: path-normalization.example.com" http://<your-ingress-ip>////uuid

результати схожі на

{
  "uuid": "29c77dfe-73ec-4449-b70a-ef328ea9dbce"
}

{
  "uuid": "d20d92e8-af57-4014-80ba-cf21c0c4ffae"
}

HTTP/1.1 301 Moved Permanently
...
Location: /uuid
...

Ваші бекенди можуть покладатися на реалізацію Ingress/Gateway API для нормалізації URL-адрес. При цьому більшість реалізацій Gateway API мають типово увімкнену певну нормалізацію шляхів. Наприклад, Istio, Envoy Gateway та Kgateway нормалізують сегменти . та .. без додаткових налаштувань. Для отримання детальнішої інформації перегляньте документацію для кожної реалізації Gateway API, яку ви використовуєте.

Підсумок

Оскільки ми всі поспішаємо реагувати на виведення з експлуатації Ingress-NGINX, сподіваюся, що ця публікація додасть вам впевненості в тому, що ви зможете безпечно та ефективно здійснити міграцію, незважаючи на всі складнощі Ingress-NGINX.

SIG Network також працює над підтримкою найпоширеніших анотацій Ingress-NGINX (та деяких із цих несподіваних особливостей поведінки) в Ingress2Gateway, щоб допомогти вам перетворити конфігурацію Ingress-NGINX на Gateway API та запропонувати альтернативи для непідтримуваної поведінки.

SIG Network сьогодні (27 лютого 2026 року) випустила Gateway API 1.5, у якому до стабільного стану переходять такі функції, як ListenerSet (що дозволяє розробникам застосунків краще управляти сертифікатами TLS) та фільтр HTTPRoute CORS, що дозволяє конфігурувати CORS.

Ви можете використовувати Istio виключно як контролер Gateway API без інших функцій сервісної мережі. ↩︎

Представляємо контролер готовності вузлів

Tue, 03 Feb 2026 10:00:00 +0800

У стандартній моделі Kubernetes придатність вузла для робочих навантажень залежить від єдиного бінарного стану «Ready» («Готовий»). Однак у сучасних середовищах Kubernetes вузли потребують складних інфраструктурних залежностей, таких як мережеві агенти, драйвери сховищ, прошивка GPU або спеціальні перевірки працездатності, щоб бути повністю готовими до роботи, перш ніж вони зможуть надійно обслуговувати Podʼи.

Сьогодні від імені проєкту Kubernetes я оголошую про запуск Node Readiness Controller. Цей проєкт впроваджує декларативну систему для керування taints вузлів, розширюючи захисні барʼєри готовності під час завантаження вузлів за межі стандартних станів. Динамічно керуючи taints на основі власних сигналів працездатності, контролер гарантує, що робочі навантаження розміщуються тільки на вузлах, які відповідають усім вимогам інфраструктури.

Навіщо потрібен контролер готовності вузлів?

Основний статус «Ready» вузлів Kubernetes часто є недостатнім для кластерів із складними вимогами до ініціалізації. Оператори часто стикаються з труднощами, намагаючись переконатися, що певні DaemonSets або локальні сервіси працюють належним чином, перш ніж вузол потрапить до пулу планування.

Контролер готовності вузлів заповнює цю прогалину, дозволяючи операторам визначати власні scheduling gates, адаптовані до конкретних груп вузлів. Це дозволяє застосовувати різні вимоги до готовності в гетерогенних кластерах, гарантуючи, наприклад, що вузли, оснащені GPU, приймають Podʼи тільки після перевірки спеціалізованих драйверів, тоді як вузли загального призначення дотримуються стандартного шляху.

Він надає три основні переваги:

Налаштовані визначення готовності: визначте, що означає готовий для вашої конкретної платформи.
Автоматичне керування taints: контролер автоматично застосовує або видаляє taints вузлів залежно від статусу станів, запобігаючи потраплянню Podʼів на непідготовлену інфраструктуру.
Декларативна ініціалізація вузлів: надійно керуйте багатоетапною ініціалізацією вузлів із чітким спостереженням за процесом ініціалізації.

Основні поняття та можливості

Контролер базується на API NodeReadinessRule (NRR), який дозволяє визначати декларативні gates для ваших вузлів.

Гнучкі режими виконання

Контролер підтримує два різних режими роботи:

Безперервне виконання: Активно підтримує гарантію готовності протягом усього життєвого циклу вузла. Якщо критична залежність (наприклад, драйвер пристрою) пізніше дає збій, на вузол негайно додається taint, щоб запобігти новому плануванню.
Виконання тільки під час завантаження: Спеціально для одноразових кроків ініціалізації, таких як попереднє завантаження важких образів або підготовка обладнання. Після виконання умов контролер позначає завантаження як завершене і припиняє моніторинг цього конкретного правила для вузла.

Звітування про стани

Контролер реагує на стани вузлів (Node Conditions), а не виконує перевірки працездатності самостійно. Така роздільна конструкція дозволяє йому безперешкодно інтегруватися з іншими інструментами, що існують в екосистемі, а також із власними рішеннями:

Node Problem Detector (NPD): використовуйте наявні налаштування NPD та власні скрипти для звітування про стан вузлів.
Readiness Condition Reporter: легкий агент, наданий проєктом, який можна розгорнути для періодичної перевірки локальних HTTP-точок доступу та відповідного оновлення станів вузлів.

Операційна безпека з тестовим запуском

Впровадження нових правил готовності у всьому парку вузлів несе в собі певний ризик. Щоб його зменшити, режим тестового запуску (dry run) дозволяє операторам спочатку змоделювати вплив на кластер. У цьому режимі контролер записує в логи заплановані дії та оновлює статус правила, щоб показати вузли, на які це вплине, без фактичного застосування taints, що дозволяє безпечно перевірити правило перед застосуванням.

Приклад: ініціалізація CNI

Наведене нижче правило NodeReadinessRule гарантує, що вузол залишатиметься таким, що не підлягає плануванню, доки його агент CNI не почне функціонувати. Контролер відстежує власний стан cniplugin.example.net/NetworkReady і видаляє taint readiness.k8s.io/acme.com/network-unavailable лише тоді, коли статус стає True.

apiVersion: readiness.node.x-k8s.io/v1alpha1
kind: NodeReadinessRule
metadata:
  name: network-readiness-rule
spec:
  conditions:
    - type: "cniplugin.example.net/NetworkReady"
      requiredStatus: "True"
  taint:
    key: "readiness.k8s.io/acme.com/network-unavailable"
    effect: "NoSchedule"
    value: "pending"
  enforcementMode: "bootstrap-only"
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker: ""

Демо:

Приєднуйтесь

Node Readiness Controller тільки починає свою роботу, і ми випустили перші версії. Зараз ми чекаємо на відгуки від спільноти, щоб вдосконалити план розвитку. Після плідних дискусій на Unconference під час KubeCon NA 2025 ми з радістю продовжимо розмову віч-на-віч.

Приєднуйтесь до нас на KubeCon + CloudNativeCon Europe 2026 на сесії треку супровідників: Вирішення проблеми недетермінованого планування: представлення Node Readiness Controller.

Тим часом ви можете долучитися до нашої роботи або стежити за нашими досягненнями тут:

GitHub: https://sigs.k8s.io/node-readiness-controller
Slack: долучіться до обговорення в #sig-node-readiness-controller
Документація: Початок роботи

Експерименти з Gateway API за допомогою kind

Wed, 28 Jan 2026 00:00:00 +0000

Цей документ проведе вас через налаштування локального експериментального середовища з Gateway API з використанням kind. Це середовище розроблено для навчання та тестування. Воно допомагає вам зрозуміти концепції Gateway API без складності промислового середовища.

Увага:

Це експериментальне навчальне середовище, яке не слід використовувати в промисловому середовищі. Компоненти, використані в цьому документі, не придатні для промислового використання. Коли ви будете готові розгорнути Gateway API в промисловому середовищі, виберіть реалізацію, яка відповідає вашим потребам.

Огляд

У цьому посібнику ви:

Налаштуєте локальний кластер Kubernetes за допомогою kind (Kubernetes in Docker)
Розгорнете cloud-provider-kind, який надає як LoadBalancer Services, так і контролер Gateway API
Створите Gateway і HTTPRoute для маршрутизації трафіку до демо-застосунку
Протестуєте вашу конфігурацію Gateway API локально

Це середовище ідеально підходить для навчання, розробки та експериментування з концепціями Gateway API.

Передумови

Перед початком переконайтеся, що у вас встановлено наступне на локальному компʼютері:

Docker — потрібен для запуску kind та cloud-provider-kind
kubectl — інструмент командного рядка Kubernetes
kind — Kubernetes in Docker
curl — потрібен для тестування маршрутів

Створення кластера kind

Створіть новий кластер kind, запустивши:

kind create cluster

Це створить одновузловий кластер Kubernetes, який працює в контейнері Docker.

Встановлення cloud-provider-kind

Далі вам потрібен cloud-provider-kind, який надає два ключові компоненти для цього середовища:

Контролер LoadBalancer, який призначає адреси Service типу LoadBalancer
Контролер Gateway API, який реалізує специфікацію Gateway API

Він також автоматично встановлює Custom Resource Definitions (CRDs) Gateway API у вашому кластері.

Запустіть cloud-provider-kind як контейнер Docker на тому ж хості, де ви створили кластер kind:

VERSION="$(basename $(curl -s -L -o /dev/null -w '%{url_effective}' https://github.com/kubernetes-sigs/cloud-provider-kind/releases/latest))"
docker run -d --name cloud-provider-kind --rm --network host -v /var/run/docker.sock:/var/run/docker.sock registry.k8s.io/cloud-provider-kind/cloud-controller-manager:${VERSION}

Примітка: На деяких системах можуть знадобитися підвищені привілеї для доступу до сокета Docker.

Перевірте, що cloud-provider-kind запущений:

docker ps --filter name=cloud-provider-kind

Ви повинні побачити контейнер у списку та в стані виконання. Ви також можете перевірити логи:

docker logs cloud-provider-kind

Експериментування з Gateway API

Тепер, коли ваш кластер налаштований, ви можете почати експериментування з ресурсами Gateway API.

cloud-provider-kind автоматично надає GatewayClass під назвою cloud-provider-kind. Ви будете використовувати цей клас для створення вашого Gateway.

Варто зауважити, що хоча kind не є хмарним провайдером, проєкт названий cloud-provider-kind, оскільки він надає можливості, які імітують хмарне середовище.

Розгортання Gateway

Наведений нижче маніфест:

Створить новий простір імен gateway-infra
Розгорне Gateway, який слухає на порту 80
Прийматиме HTTPRoutes з іменами хостів, які відповідають шаблону *.exampledomain.example
Дозволить маршрутам з будь-якого простору імен приєднуватися до Gateway. Примітка: У реальних кластерах використовуйте значення Same або Selector у полі allowedRoutes namespace selector, щоб обмежити приєднання.

Застосуйте наступний маніфест:

---
apiVersion: v1
kind: Namespace
metadata:
  name: gateway-infra
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway
  namespace: gateway-infra
spec:
  gatewayClassName: cloud-provider-kind
  listeners:
  - name: default
    hostname: "*.exampledomain.example"
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: All

Потім перевірте, що ваш Gateway правильно запрограмований і має призначену адресу:

kubectl get gateway -n gateway-infra gateway

Очікуваний результат:

NAME      CLASS                 ADDRESS      PROGRAMMED   AGE
gateway   cloud-provider-kind   172.18.0.3   True         5m6s

Стовпець PROGRAMMED повинен показувати True, а поле ADDRESS повинно містити IP-адресу.

Розгортання демо-застосунку

Далі розгорніть простий echo-застосунок, який допоможе вам протестувати конфігурацію вашого Gateway. Цей застосунок:

Слухає на порту 3000
Повертає деталі запиту, включаючи шлях, заголовки та змінні середовища
Запускається у просторі імен demo

Застосуйте наступний маніфест:

apiVersion: v1
kind: Namespace
metadata:
  name: demo
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: echo
  name: echo
  namespace: demo
spec:
  ports:
  - name: http
    port: 3000
    protocol: TCP
    targetPort: 3000
  selector:
    app.kubernetes.io/name: echo
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: echo
  name: echo
  namespace: demo
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: echo
  template:
    metadata:
      labels:
        app.kubernetes.io/name: echo
    spec:
      containers:
      - env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.name
        - name: NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        image: registry.k8s.io/gateway-api/echo-basic:v20251204-v1.4.1
        name: echo-basic

Створення HTTPRoute

Тепер створіть HTTPRoute для маршрутизації трафіку з вашого Gateway до echo-застосунку. Цей HTTPRoute буде:

Реагувати на запити для імені хоста some.exampledomain.example
Маршрутизувати трафік до echo-застосунку
Приєднуватися до Gateway у просторі імен gateway-infra

Застосуйте наступний маніфест:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: echo
  namespace: demo
spec:
  parentRefs:
  - name: gateway
    namespace: gateway-infra
  hostnames: ["some.exampledomain.example"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: echo
      port: 3000

Тестування вашого маршруту

Завершальний крок — перевірка вашого маршруту за допомогою curl. Ви зробите запит на IP-адресу Gateway з іменем хоста some.exampledomain.example. Наступна команда підходить тільки для POSIX shell і може потребувати налаштування для вашого середовища:

GW_ADDR=$(kubectl get gateway -n gateway-infra gateway -o jsonpath='{.status.addresses[0].value}')
curl --resolve some.exampledomain.example:80:${GW_ADDR} http://some.exampledomain.example

Ви повинні отримати JSON-відповідь подібну до цієї:

{
 "path": "/",
 "host": "some.exampledomain.example",
 "method": "GET",
 "proto": "HTTP/1.1",
 "headers": {
  "Accept": [
   "*/*"
  ],
  "User-Agent": [
   "curl/8.15.0"
  ]
 },
 "namespace": "demo",
 "ingress": "",
 "service": "",
 "pod": "echo-dc48d7cf8-vs2df"
}

Якщо ви бачите цю відповідь, вітаємо! Ваше середовище Gateway API працює правильно.

Усунення несправностей

Якщо щось працює не так, як очікується, ви можете усунути несправності, перевіривши стан ваших ресурсів.

Перевірка стану Gateway

Спочатку перевірте ресурс Gateway:

kubectl get gateway -n gateway-infra gateway -o yaml

Перевірте стани в розділі status. Ваш Gateway повинен мати:

Accepted: True - Gateway був прийнятий контролером
Programmed: True - Gateway був успішно налаштований
.status.addresses заповнений IP-адресою

Перевірка стану HTTPRoute

Далі перевірте ваш HTTPRoute:

kubectl get httproute -n demo echo -o yaml

Перевірте стани в розділі status.parents. Поширені проблеми включають:

ResolvedRefs встановлено False з причиною BackendNotFound; це означає, що Service бекенду не існує або має неправильне імʼя
Accepted встановлено False; це означає, що маршрут не міг приєднатися до Gateway (перевірте дозволи простору імен або відповідність імені хоста)

Приклад помилки, коли бекенд не знайдено:

status:
  parents:
  - conditions:
    - lastTransitionTime: "2026-01-19T17:13:35Z"
      message: backend not found
      observedGeneration: 2
      reason: BackendNotFound
      status: "False"
      type: ResolvedRefs
    controllerName: kind.sigs.k8s.io/gateway-controller

Перевірка логів контролера

Якщо стан ресурсів не допомагає виявити проблему, перевірте логи cloud-provider-kind:

docker logs -f cloud-provider-kind

Це покаже детальні логи як з контролерів LoadBalancer, так і Gateway API.

Очищення

Коли ви закінчите з експериментами, ви можете очистити ресурси:

Видалення ресурсів Kubernetes

Видаліть простори імен (це видалить усі ресурси в них):

kubectl delete namespace gateway-infra
kubectl delete namespace demo

Зупинка cloud-provider-kind

Зупиніть та видаліть контейнер cloud-provider-kind:

docker stop cloud-provider-kind

Оскільки контейнер був запущений з прапорцем --rm, він буде автоматично видалений при зупинці.

Видалення кластера kind

Нарешті, видаліть кластер kind:

kind delete cluster

Наступні кроки

Тепер, коли ви поекспериментували з Gateway API локально, ви готові дослідити готові до промислової експлуатації реалізації:

Розгортання в промисловій експлуатації: Перегляньте реалізації Gateway API, щоб знайти контролер, який відповідає вашим вимогам до промислового середовища
Дізнайтеся більше: Ознайомтеся з документацією Gateway API, щоб дізнатися про розширені можливості, такі як TLS, розподіл трафіку та маніпуляція заголовками
Розширена маршрутизація: Експериментуйте з маршрутизацією на основі шляху, узгодженням заголовків, дзеркальним відображенням запитів та іншими можливостями, дотримуючись посібникам користувача Gateway API

Фінальне попередження

Це середовище kind призначене лише для розробки та навчання. Завжди використовуйте реалізацію Gateway API промислового рівня для реальних робочих навантажень.

Cluster API v1.12: Впровадження оновлень на місці та ланцюгових оновлень

Tue, 27 Jan 2026 08:00:00 -0800

Cluster API забезпечує декларативне керування життєвим циклом кластерів Kubernetes, дозволяючи користувачам і платформним командам визначати бажаний стан кластерів і покладатися на контролери, які постійно приводять кластери до нього.

Подібно до того, як ви можете використовувати StatefulSet або Deployment в Kubernetes для керування групою Podʼів, в Cluster API ви можете використовувати KubeadmControlPlane для керування набором машин панелі управління або MachineDeployments для керування групою робочих вузлів.

Випуск Cluster API v1.12.0 розширює можливості Cluster API, зменшуючи складності у звичайних операціях життєвого циклу завдяки впровадженню оновлень на місці та ланцюгових оновлень.

Акцент на простоті та зручності використання

З версією v1.12.0 проєкт Cluster API ще раз демонструє, що ця спільнота здатна запроваджувати велику кількість інновацій, одночасно мінімізуючи вплив на користувачів Cluster API.

Що це означає на практиці?

Користувачам просто потрібно змінити специфікацію Cluster або Machine (так само, як і в попередніх версіях Cluster API), і Cluster API автоматично запустить оновлення на місці або ланцюгові оновлення, коли це можливо і доцільно.

Оновлення на місці

Як і Kubernetes для Podʼів у Deployment, коли змінюється специфікація Machine, Cluster API також виконує розгортання, створюючи нову машину та видаляючи стару.

Цей підхід, навіяний принципом незмінної інфраструктури, має низку значних переваг:

Він простий для пояснення, передбачуваний, послідовний і легкий для розуміння користувачами та інженерами.
Він простий у реалізації, оскільки базується лише на двох основних операціях: створенні та видаленні.
Реалізація не залежить від конкретних параметрів машини, таких як ОС, механізм завантаження тощо.

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

Однак, хоча переваги незмінності не підлягають обговоренню, як Kubernetes, так і Cluster API проходять подібний шлях, впроваджуючи зміни, що дозволяють користувачам мінімізувати порушення роботи навантажень, коли це можливо.

Згодом Cluster API також запровадив кілька вдосконалень до незмінних розгортань, зокрема:

Підтримка поширення змін, що впливають тільки на ресурси Kubernetes, що дозволяє уникнути непотрібних розгортань
Спосіб додавання taint PreferNoSchedule до застарілих вузлів, що дозволяє зменшити плинність Podʼів шляхом оптимізації перепланування Podʼів під час розгортань.
Підтримка стратегії «спочатку видалити, потім розгорнути», що спрощує незмінні розгортання на фізичних серверах/у середовищах з обмеженими ресурсами.

Нова можливість оновлення на місці в Cluster API є наступним кроком на цьому шляху.

З випуском версії 1.12.0 Cluster API впроваджує підтримку розширень оновлення, що дозволяє користувачам вносити зміни в діючі машини на місці, без видалення та повторного створення машин.

Як KubeadmControlPlane, так і MachineDeployments підтримують оновлення на місці на основі нового розширення оновлення, а це означає, що межі можливостей Cluster API тепер значно змінилися.

Як працюють оновлення на місці?

Найпростіше пояснити це так: коли користувач запускає оновлення, змінюючи бажаний стан машин, Cluster API вибирає найкращий інструмент для досягнення бажаного стану.

Новина полягає в тому, що тепер Cluster API може вибирати між незмінними розгортаннями та розширеннями оновлень на місці для виконання необхідних змін.

Важливо, що це не незмінні розгортання проти оновлень на місці; Cluster API розглядає обидва варіанти як дійсні та вибирає найбільш відповідний механізм для даної зміни.

З точки зору супровідників Cluster API, оновлення на місці найбільш корисні для внесення змін, які не вимагають drain вузла або перезапуску Podʼів; наприклад: зміна облікових даних користувача для машини. З іншого боку, коли робоче навантаження все одно буде порушено, просто виконайте розгортання.

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

Щоб глибше ознайомитися з цією функцією, обовʼязково відвідайте сесію Оновлення на місці з Cluster API: золота середина між незмінною та змінною інфраструктурою на KubeCon EU в Амстердамі!

Ланцюгові оновлення

ClusterClass та керовані топології в Cluster API спільно забезпечили потужну та ефективну структуру, яка слугує будівельним блоком для багатьох платформ, що пропонують Kubernetes-as-a-Service.

Тепер, з версією v1.12.0, ця можливість робить ще один важливий крок вперед, дозволяючи користувачам оновлюватися більш ніж на одну мінорну версію Kubernetes за одну операцію, що зазвичай називається ланцюговим оновленням.

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

Найпростіший спосіб пояснити, як працюють ланцюгові оновлення, полягає в тому, що після того, як користувач запускає оновлення, змінюючи бажану версію для кластера, Cluster API обчислює план оновлення, а потім починає його виконувати. Замість того, щоб (наприклад) оновлювати кластер до v1.33.0, потім до v1.34.0, а потім до v1.35.0, перевіряючи прогрес на кожному кроці, ланцюгове оновлення дозволяє перейти безпосередньо до v1.35.0.

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

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

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

На наш погляд, ланцюгові оновлення найбільш корисні для користувачів, яким важко встигати за мінорними релізами Kubernetes і які, наприклад, хочуть оновлюватися лише раз на рік, а потім оновлюватися на три версії (n-3 → n). Але майте на увазі: те, що тепер ви можете легко оновлюватися більш ніж на одну мінорну версію, не є приводом для того, щоб не встановлювати регулярно патчі у свій кластер!

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

Я хотів би подякувати всім учасникам, супровідникам та інженерам, які добровільно долучилися до команди випуску.

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

Висловлюємо подяку всій спільноті Cluster API за випуск версії 1.12.0 та всі чудові випуски, представлені у 2025 році! Якщо ви зацікавлені у співпраці, ознайомтеся з рекомендаціями щодо співпраці з Cluster API.

Що далі?

Якщо ви прочитаєте Маніфест Cluster API, то побачите, як в рамках субпроєкту Cluster API проголошується право залишатися незавершеним, визнаючи необхідність постійного розвитку, вдосконалення та адаптації до мінливих потреб користувачів Cluster API та ширшої екосистеми Cloud Native.

Оскільки Kubernetes продовжує розвиватися, субпроєкт Cluster API буде просуватися разом з ним, зосереджуючись на безпечніших оновленнях, зменшенні порушень та зміцненні будівельних блоків для платформ, що керують Kubernetes у великих масштабах.

Інновації залишаються в центрі уваги Cluster API, тож чекайте на насичений подіями 2026 рік!

Корисні посилання:

Уніфікований доступ до API-сервера за допомогою clientcmd

Mon, 19 Jan 2026 10:00:00 -0800

Якщо ви коли-небудь хотіли створювати консольного клієнта для API Kubernetes, особливо якщо ви розглядали можливість використання вашого клієнта як втулка kubectl, ви, можливо, замислювалися над тим, як зробити вашого клієнта звичним для користувачів kubectl. Швидкий погляд на вихідні дані kubectl options може вас збентежити: «Невже я повинен реалізувати всі ці опції?»

Не бійтеся, інші вже зробили за вас велику частину роботи. Насправді проєкт Kubernetes надає дві бібліотеки, які допоможуть вам обробляти аргументи командного рядка в стилі kubectl у програмах Go: clientcmd та cli-runtime (яка використовує clientcmd). У цій статті ми покажемо, як використовувати першу з них.

Загальна філософія

Як і слід було очікувати, оскільки це частина client-go, кінцевою метою clientcmd є надання екземпляра restclient.Config, який може надсилати запити до API-сервера.

Він дотримується семантики kubectl:

типові значення беруться з ~/.kube або еквівалентного файлу;
файли можна вказати за допомогою змінної середовища KUBECONFIG;
усі вищезазначені налаштування можна додатково замінити за допомогою аргументів командного рядка.

Він не встановлює аргумент командного рядка --kubeconfig, що може знадобитися для узгодження з kubectl; як це зробити, ви дізнаєтеся в розділі «Привʼязування прапорців».

Доступні можливості

clientcmd дозволяє програмам обробляти

вибір kubeconfig (за допомогою KUBECONFIG);
вибір контексту;
вибір простору імен;
сертифікати клієнта та приватні ключі;
імітацію користувача;
підтримку базової автентифікації HTTP (імʼя користувача/пароль).

Обʼєднання конфігурацій

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

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

Якщо KUBECONFIG не визначено, замість нього використовується типовий файл конфігурації ~/.kube/config, якщо він є.

Загальний процес

Загальна схема використання стисло викладена в документації до пакунка clientcmd:

loadingRules := clientcmd.NewDefaultClientConfigLoadingRules()
// якщо ви хочете змінити правила завантаження (які файли в якому порядку), ви можете зробити це тут

configOverrides := &clientcmd.ConfigOverrides{}
// якщо ви хочете змінити значення перевизначення або привʼязати їх до прапорців, є методи, які допоможуть вам

kubeConfig := clientcmd.NewNonInteractiveDeferredLoadingClientConfig(loadingRules, configOverrides)
config, err := kubeConfig.ClientConfig()
if err != nil {
	// Щось робимо
}
client, err := metav1.New(config)
// ...

У контексті цієї статті є шість кроків:

Налаштування правил завантаження

clientcmd.NewDefaultClientConfigLoadingRules() створює правила завантаження, які будуть використовувати або вміст змінної середовища KUBECONFIG, або типове імʼя файлу конфігурації (~/.kube/config). Крім того, якщо використовується типовий файл конфігурації, він може перенести налаштування з (дуже) старого типового файлу конфігурації (~/.kube/.kubeconfig).

Ви можете створити власні ClientConfigLoadingRules, але в більшості випадків типові налаштування підходять.

Налаштування перевизначення

clientcmd.ConfigOverrides — це struct, що зберігає перевизначення, які будуть застосовані до налаштувань, завантажених із конфігурації, отриманої за допомогою правил завантаження. У контексті цієї статті її основною метою є зберігання значень, отриманих з аргументів командного рядка. Вони обробляються за допомогою бібліотеки pflag, яка є повноцінною заміною пакунка Go flag і додає підтримку аргументів з подвійним дефісом і довгими іменами.

У більшості випадків в перевизначеннях нічого не потрібно встановлювати; я лише привʼяжу їх до прапорців.

Створення набору прапорців

У цьому контексті прапорець є уособленням аргументу командного рядка, що вказує його повну назву (наприклад, --namespace), його скорочену назву, якщо така є (наприклад, -n), його типове значення та опис, що показується в інформації про використання. Прапорці зберігаються в екземплярах структури FlagInfo.

Доступні три набори прапорців, що представляють такі аргументи командного рядка:

аргументи автентифікації (сертифікати, токени, імітації іншого користувача, імʼя користувача/пароль);
аргументи кластера (API-сервер, центр сертифікації, конфігурація TLS, проксі, стиснення)
аргументи контексту (імʼя кластера, імʼя користувача kubeconfig, простір імен)

Рекомендований вибір включає всі три з аргументом вибору іменованого контексту та аргументом часу очікування.

Всі вони доступні за допомогою функцій Recommended…Flags. Функції приймають префікс, який додається до всіх довгих імен аргументів.

Отже, виклик clientcmd.RecommendedConfigOverrideFlags("") призводить до появи аргументів командного рядка, таких як --context, --namespace тощо. Аргументу --timeout присвоюється типове значення 0, а аргумент --namespace має відповідний короткий варіант -n. Додавання префікса, наприклад "from-", призводить до появи аргументів командного рядка, таких як --from-context, --from-namespace тощо. Це може здатися не особливо корисним для команд, що стосуються одного API-сервера, але вони стають у пригоді, коли залучено кілька API-серверів, наприклад у сценаріях із кількома кластерами.

Тут є потенційна проблема: префікси не змінюють коротке імʼя, тому --namespace потребує певної обережності, якщо використовується кілька префіксів: лише один із префіксів може бути повʼязаний із коротким імʼям -n. Вам доведеться очистити короткі імена --namespace для інших префіксів або, можливо, для всіх префіксів, якщо немає логічної привʼязки до -n. Короткі імена можна очистити таким чином:

kflags := clientcmd.RecommendedConfigOverrideFlags(prefix)
kflags.ContextOverrideFlags.Namespace.ShortName = ""

Аналогічним чином прапорці можна повністю вимкнути, очистивши їх довге імʼя:

kflags.ContextOverrideFlags.Namespace.LongName = ""

Привʼязування прапорців

Після визначення набору прапорців його можна використовувати для привʼязки аргументів командного рядка до перевизначення за допомогою clientcmd.BindOverrideFlags. Для цього потрібен pflag FlagSet, а не пакунок flag з Go.

Якщо ви також хочете привʼязати --kubeconfig, зробіть це зараз, привʼязавши ExplicitPath у правилах завантаження:

flags.StringVarP(&loadingRules.ExplicitPath, "kubeconfig", "", "", "absolute path(s) to the kubeconfig file(s)")

Створення обʼєднаної конфігурації

Для створення обʼєднаної конфігурації доступні дві функції:

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

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

Отримання клієнта API

Обʼєднана конфігурація повертається як екземпляр ClientConfig. API-клієнт можна отримати з нього, викликавши метод ClientConfig().

Якщо конфігурація не вказана (KUBECONFIG порожній або вказує на відсутні файли, ~/.kube/config не існує, а конфігурація не вказана за допомогою аргументів командного рядка), типове налаштування поверне незрозумілу помилку, що посилається на KUBERNETES_MASTER. Це застаріла поведінка; було зроблено кілька спроб позбутися її, але вона збереглася для аргументів командного рядка --local та --dry-run у --kubectl. Ви повинні перевіряти наявність помилок «порожньої конфігурації», викликаючи clientcmd.IsEmptyConfig(), і надавати чіткіше повідомлення про помилку.

Метод Namespace() також корисний: він повертає простір імен, який слід використовувати. Він також вказує, чи був простір імен перевизначений користувачем (за допомогою --namespace).

Повний приклад

Ось повний приклад.

package main

import (
	"context"
	"fmt"
	"os"

	"github.com/spf13/pflag"
	v1 "k8s.io/apimachinery/pkg/apis/meta/v1"
	"k8s.io/client-go/kubernetes"
	"k8s.io/client-go/tools/clientcmd"
)

func main() {
	// Правила завантаження, без налаштувань
	loadingRules := clientcmd.NewDefaultClientConfigLoadingRules()

	// Перевизначення та налаштування прапорців (аргументів командного рядка)
	configOverrides := &clientcmd.ConfigOverrides{}
	flags := pflag.NewFlagSet("clientcmddemo", pflag.ExitOnError)
	clientcmd.BindOverrideFlags(configOverrides, flags,
		clientcmd.RecommendedConfigOverrideFlags(""))
	flags.StringVarP(&loadingRules.ExplicitPath, "kubeconfig", "", "", "absolute path(s) to the kubeconfig file(s)")
	flags.Parse(os.Args)

	// Створення клієнта
	kubeConfig := clientcmd.NewNonInteractiveDeferredLoadingClientConfig(loadingRules, configOverrides)
	config, err := kubeConfig.ClientConfig()
	if err != nil {
		if clientcmd.IsEmptyConfig(err) {
			panic("Please provide a configuration pointing to the Kubernetes API server")
		}
		panic(err)
	}
	client, err := kubernetes.NewForConfig(config)
	if err != nil {
		panic(err)
	}

	// Як дізнатися, який простір імен використовувати
	namespace, overridden, err := kubeConfig.Namespace()
	if err != nil {
		panic(err)
	}
	fmt.Printf("Chosen namespace: %s; overridden: %t\n", namespace, overridden)

	// Використаємо клієнта
	nodeList, err := client.CoreV1().Nodes().List(context.TODO(), v1.ListOptions{})
	if err != nil {
		panic(err)
	}
	for _, node := range nodeList.Items {
		fmt.Println(node.Name)
	}
}

Приємного програмування та дякуємо за ваш інтерес до впровадження інструментів зі звичними моделями використання!

Kubernetes v1.35: allowList для exec-втулків у kuberc обмежує виконувані файли, які запускає kubeconfig

Fri, 09 Jan 2026 10:30:00 -0800

Чи знали ви, що kubectl може запускати довільні виконувані файли, включаючи скрипти оболонки, з повними правами користувача, який їх викликає, і навіть без вашого відома? Кожного разу, коли ви завантажуєте або автоматично генеруєте kubeconfig, поле users[n].exec.command може вказати виконуваний файл для отримання облікових даних від вашого імені. Не зрозумійте мене неправильно, це неймовірна можливість, яка дозволяє вам пройти автентифікацію в кластері за допомогою зовнішніх постачальників ідентифікації. Проте, ви, мабуть, бачите проблему: чи знаєте ви точно, які виконувані файли ваш kubeconfig запускає у вашій системі? Чи довіряєте ви конвеєру, який згенерував ваш kubeconfig? Якщо на код, що генерує kubeconfig, було здійснено атаку на ланцюжок постачання, або якщо конвеєр генерації було скомпрометовано, зловмисник може робити неприємні речі з вашою машиною, змушуючи ваш kubeconfig виконувати довільний код.

Щоб надати користувачам більше контролю над тим, що виконується в їхній системі, SIG-Auth та SIG-CLI додали політику втулків для облікових даних та список дозволених елементів як бета-можливість до Kubernetes 1.35. Це доступно для всіх клієнтів, які використовують бібліотеку client-go, шляхом заповнення структури ExecProvider.PluginPolicy у конфігурації REST. Щоб розширити вплив цієї зміни, Kubernetes v1.35 також дозволяє керувати цим без написання жодного рядка коду застосунку. Ви можете налаштувати kubectl для застосування політики та списку дозволеного, додавши два поля до файлу конфігурації kuberc: credentialPluginPolicy та credentialPluginAllowlist. Додавання одного або обох цих полів обмежує втулки облікових даних, які kubectl може виконувати.

Як це працює

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

Наступний приклад є найпростішим: просто не вказуйте нові поля.

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference

Це дозволить kubectl працювати як і раніше, а всі втулки будуть дозволені.

Наступний приклад функціонально ідентичний, але він є чіткішим і тому кращим, якщо це саме те, що вам потрібно:

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: AllowAll

Якщо ви не знаєте, чи ви використовуєте exec-втулки облікових даних, спробуйте встановити політику на DenyAll:

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: DenyAll

Якщо ви використовуєте втулки облікових даних, ви швидко зʼясуєте, що намагається виконати kubectl. Ви отримаєте помилку, подібну до наведеної нижче.

Unable to connect to the server: getting credentials: plugin "cloudco-login" not allowed: policy set to "DenyAll"

Якщо вам не вистачає інформації для усунення проблеми, збільште детальність логування під час виконання наступної команди. Наприклад:

# збільшити або зменшити детальність, якщо проблема все ще залишається незрозумілою
kubectl get pods --verbosity 5

Вибіркові дозволи для втулків

Що робити, якщо для щоденної роботи вам потрібен втулок cloudco-login? Саме для цього існує третій варіант політики — Allowlist. Щоб дозволити використання певного втулка, встановіть політику та додайте credentialPluginAllowlist:

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
  - name: /usr/local/bin/cloudco-login
  - name: get-identity

Ви помітите, що в allowlist є два записи. Один з них вказаний повним шляхом, а інший, get-identity, є лише базовим іменем. Коли ви вказуєте лише базове імʼя, повний шлях буде шукатися за допомогою exec.LookPath, який не розширює globbing і не обробляє символи-замінники. Globbing наразі не підтримується. Обидві форми (базове імʼя та повний шлях) є прийнятними, але повний шлях є кращим, оскільки він ще більше звужує діапазон дозволених бінарних файлів.

Майбутні вдосконалення

Наразі запис у списку дозволеного (allowlist) має лише одне поле, name. У майбутньому ми (Kubernetes SIG CLI) хочемо додати інші вимоги. Однією з корисних ідей є перевірка контрольної суми, за допомогою якої, наприклад, бінарний файл можна буде запустити, тільки якщо він має суму sha256 b9a3fad00d848ff31960c44ebb5f8b92032dc085020f857c98e32a5d5900ff9c і знаходиться за адресою /usr/bin/cloudco-login.

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

Приєднуйтесь

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

#sig-cli,
#sig-auth.

Kubernetes v1.35: Кращий спосіб передачі токенів ServiceAccount до драйверів CSI

Wed, 07 Jan 2026 10:30:00 -0800

Якщо ви підтримуєте драйвер CSI, який використовує токени ServiceAccount, Kubernetes v1.35 приносить удосконалення, про яке вам варто знати. З моменту введення можливості TokenRequests, токени ServiceAccount, запитувані драйверами CSI, передавалися їм через поле volume_context. Хоча це працювало, це не ідеальне місце для конфіденційної інформації, і ми бачили випадки, коли токени випадково потрапляли в логи драйверів CSI.

Kubernetes v1.35 вводить рішення бета-версії для вирішення цієї проблеми: Добровільне ввімкнення драйвером CSI отримання токенів ServiceAccount через поле Secrets. Це дозволяє драйверам CSI отримувати токени ServiceAccount через поле secrets у NodePublishVolumeRequest, яке є відповідним місцем для конфіденційних даних у специфікації CSI.

Розуміння поточного підходу

Коли драйвери CSI використовують можливість TokenRequests, вони можуть запитувати токени ServiceAccount для ідентичності робочого навантаження, налаштовуючи поле TokenRequests у специфікації CSIDriver. Ці токени передаються драйверам як частина мапи атрибутів тому, використовуючи ключ csi.storage.k8s.io/serviceAccount.tokens.

Поле volume_context працює, але воно не призначене для конфіденційних даних. Через це виникають кілька викликів:

По-перше, інструмент protosanitizer, який використовують драйвери CSI, не розглядає контекст тому як конфіденційний, тому токени ServiceAccount можуть потрапити в логи, коли gRPC-запити логуються. Це сталося з CVE-2023-2878 у Secrets Store CSI Driver та CVE-2024-3744 у Azure File CSI Driver.

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

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

Як працює механізм увімкнення

Kubernetes v1.35 вводить механізм увімкнення, який дозволяє драйверам CSI вибирати, як вони отримують токени ServiceAccount. Таким чином, поточні драйвери продовжують працювати як і раніше, а драйвери можуть перейти до більш відповідного поля secrets, коли будуть готові.

Драйвери CSI можуть встановити нове поле у своїй специфікації CSIDriver:

#
# УВАГА: це приклад конфігурації.
#          Не використовуйте це для власного кластера!
#
apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: example-csi-driver
spec:
  # ... наявні поля ...
  tokenRequests:
  - audience: "example.com"
    expirationSeconds: 3600
  # Нове поле для ввімкнення доставки через secrets
  serviceAccountTokenInSecrets: true  # типово false

Поведінка залежить від поля serviceAccountTokenInSecrets:

Коли встановлено false (типово), токени розміщуються у VolumeContext з ключем csi.storage.k8s.io/serviceAccount.tokens, як і сьогодні. Коли встановлено true, токени розміщуються лише у полі Secrets з тим самим ключем.

Про бета-реліз

Функціональна можливість CSIServiceAccountTokenSecrets типово увімкнена як для kubelet, так і для kube-apiserver. Оскільки поле serviceAccountTokenInSecrets типово має значення false, увімкнення функціональної можливості не змінює жодної поточної поведінки. Усі драйвери продовжують отримувати токени через контекст тому, якщо вони явно не ввімкнуть нову поведінку. Це пояснює, чому ми почувалися комфортно, починаючи з бета-версії, а не альфа.

Посібник для авторів драйверів CSI

Якщо ви підтримуєте драйвер CSI, який використовує токени ServiceAccount, ось як запровадити цю можливість.

Додавання резервної логіки

Спочатку оновіть код вашого драйвера, щоб перевіряти обидва місця на наявність токенів. Це робить ваш драйвер сумісним з обома підходами, старим і новим:

const serviceAccountTokenKey = "csi.storage.k8s.io/serviceAccount.tokens"

func getServiceAccountTokens(req *csi.NodePublishVolumeRequest) (string, error) {
    // Перевірити поле secrets спочатку (нова поведінка, коли драйвер увімкнув її)
    if tokens, ok := req.Secrets[serviceAccountTokenKey]; ok {
        return tokens, nil
    }
    
    // Повернення до контексту тому (поточна поведінка)
    if tokens, ok := req.VolumeContext[serviceAccountTokenKey]; ok {
        return tokens, nil
    }
    
    return "", fmt.Errorf("service account tokens not found")
}

Ця резервна логіка є зворотно сумісною та безпечною для випуску в будь-якій версії драйвера, навіть до оновлення кластерів до v1.35.

Послідовність розгортання

Автори драйверів CSI повинні дотримуватися певної послідовності під час впровадження цієї можливості, щоб уникнути порушення наявних томів.

Підготовка драйвера (може відбутися будь-коли)

Ви можете почати підготовку вашого драйвера прямо зараз, додавши резервну логіку, яка перевіряє як поле secrets, так і контекст тому на наявність токенів. Ця зміна коду є зворотно сумісною та безпечною для випуску в будь-якій версії драйвера, навіть до оновлення кластерів до v1.35. Ми заохочуємо вас додати цю логіку раніше, випускати релізи та навіть переносити її (backport) до гілок обслуговування, де це можливо.

Оновлення кластера та увімкнення можливості

Після того, як ваш драйвер має резервну логіку, ось безпечний порядок розгортання для увімкнення можливості в кластері:

Завершити оновлення kube-apiserver до 1.35 або пізнішої версії
Завершити оновлення kubelet до 1.35 або пізнішої версії на всіх вузлах
Переконатися, що версія драйвера CSI з резервною логікою розгорнута (якщо не зроблено в фазі підготовки)
Повністю завершити розгортання DaemonSet драйвера CSI на всіх вузлах
Оновити ваш маніфест CSIDriver, щоб встановити serviceAccountTokenInSecrets: true

Важливі обмеження

Найважливіше, що потрібно памʼятати, — це порядок у часі. Якщо ваш DaemonSet драйвера CSI та обʼєкт CSIDriver знаходяться в одному маніфесті або чарті Helm, вам потрібно два окремі оновлення. Спочатку розгорніть нову версію драйвера з резервною логікою, зачекайте завершення розгортання DaemonSet, потім оновіть специфікацію CSIDriver, щоб встановити serviceAccountTokenInSecrets: true.

Також не оновлюйте CSIDriver перед тим, як завершиться розгортання всіх Podʼів драйвера. Якщо ви це зробите, монтування томів зазнають невдачі на вузлах, які все ще працюють зі старою версією драйвера, оскільки ті Podʼи перевіряють лише контекст тому.

Чому це важливо

Впровадження цієї можливості допомагає в кількох аспектах:

Це усуває ризик випадкового потрапляння токенів ServiceAccount у логи як частини контексту тому в gRPC-запитах
Використовується призначене специфікацією CSI поле для конфіденційних даних, і це правильно
Інструмент protosanitizer автоматично правильно обробляє поле secrets, тому вам не потрібні специфічні для драйвера обхідні шляхи
Це опціонально, тому ви можете мігрувати у власному темпі без порушення наявних розгортань

Заклик до дії

Ми (Kubernetes SIG Storage) заохочуємо авторів драйверів CSI впровадити цю можливість та надати відгуки про досвід міграції. Якщо у вас є думки щодо дизайну API або виникають будь-які проблеми під час впровадження, будь ласка, зверніться до нас у каналі #csi на Kubernetes Slack (для запрошення відвідайте https://slack.k8s.io/).

Ви можете стежити за KEP-5538, щоб відстежувати прогрес у наступних релізах Kubernetes.

Kubernetes v1.35: Розширені оператори tolerations для підтримки числових порівнянь (Alpha)

Mon, 05 Jan 2026 10:30:00 -0800

Багато кластерів Kubernetes у промисловому середовищі поєднують вузли на вимогу (вищий рівень SLA) та спотові вузли або вузли з можливістю витіснення (нижчий рівень SLA), щоб оптимізувати витрати й водночас зберегти надійність критичних робочих навантажень. Командам платформи потрібен безпечний типовий варіант, який тримає більшість робочих навантажень подалі від ризикованих потужностей і водночас дозволяє окремим робочим навантаженням явно погоджуватися на них із чіткими пороговими значеннями, як-от «Я можу толерувати вузли з імовірністю відмови до 5%».

Сьогодні taints і tolerations у Kubernetes можуть перевіряти збіг точних значень або наявність ключа, але не можуть порівнювати числові пороги. Вам довелося б створювати дискретні категорії taint, використовувати зовнішні контролери допуску або погоджуватися на неоптимальні рішення щодо розміщення.

У Kubernetes v1.35 ми представляємо розширені оператори tolerations (Extended Toleration Operators) як альфа-можливість. Це вдосконалення додає оператори Gt (більше ніж) і Lt (менше ніж) до spec.tolerations, що дозволяє ухвалювати рішення про планування на основі порогових значень і відкриває нові можливості для розміщення на основі SLA, оптимізації витрат і розподілу робочих навантажень з урахуванням продуктивності.

Розвиток tolerations

Історично Kubernetes підтримував два основні оператори tolerations:

Equal: toleration відповідає taint, якщо ключ і значення точно збігаються
Exists: toleration відповідає taint, якщо ключ існує, незалежно від значення

Хоча ці оператори добре працювали для категорійних сценаріїв, для числових порівнянь їх було недостатньо. Починаючи з v1.35, ми усуваємо цю прогалину.

Розглянемо такі реальні ситуації:

Вимоги SLA: планувати робочі навантаження з високою доступністю тільки на вузлах із ймовірністю відмови нижче певного порогу
Оптимізація витрат: дозволити чутливим до витрат пакетним завданням виконуватися на дешевших вузлах, які перевищують певне значення вартості за годину
Гарантії продуктивності: забезпечити, щоб чутливі до затримок застосунки виконувалися тільки на вузлах, де дискові IOPS або пропускна здатність мережі перевищують мінімальні пороги

Без операторів числового порівняння оператори кластерів мусили вдаватися до обхідних рішень, таких як створення декількох дискретних значень taint або використання зовнішніх контролерів допуску, жоден з яких не масштабується добре і не забезпечує гнучкості, необхідної для динамічного планування на основі порогових значень.

Навіщо розширювати tolerations замість використання NodeAffinity?

Ви можете запитати: NodeAffinity вже підтримує числові оператори порівняння, тож навіщо розширювати tolerations? Хоча NodeAffinity добре підходить для вираження вподобань Podʼів, taints і tolerations дають важливі операційні переваги:

Орієнтованість на політику: NodeAffinity задається для кожного Podʼа окремо, тож кожне робоче навантаження має явно відмовлятися від ризикованих вузлів. Taints інвертують контроль — вузли оголошують свій рівень ризику, і лише Podʼи з відповідними tolerations можуть на них потрапити. Це дає безпечнішу типову поведінку: більшість Podʼів тримаються подалі від spot/preemptible вузлів, якщо явно не погодилися на них.
Семантика виселення: NodeAffinity не вміє виселяти. Taints підтримують ефект NoExecute з tolerationSeconds, що дозволяє операторам виконувати drain і виселяти Podʼи, коли SLA вузла погіршується або спотові екземпляри отримують повідомлення про завершення роботи.
Ергономіка експлуатації: централізована політика на боці вузла узгоджується з іншими захисними taints, як-от disk-pressure і memory-pressure, що робить керування кластером інтуїтивнішим.

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

Представляємо оператори Gt та Lt

Kubernetes v1.35 представляє два нові оператори для tolerations:

Gt (більше ніж): toleration спрацьовує, якщо числове значення taint більше за значення toleration
Lt (менше ніж): toleration спрацьовує, якщо числове значення taint менше за значення toleration

Коли Pod толерує taint з Lt, це означає: «Я можу толерувати вузли, де цей показник менший за мій поріг». Оскільки tolerations дозволяють планування, Pod може працювати на вузлах, де значення taint більше за значення toleration. Думайте про це так: «Я толерую вузли, які перевищують мої мінімальні вимоги».

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

Примітка:

Числові значення для операторів Gt і Lt мають бути додатними 64-бітними цілими числами без нулів на початку. Наприклад, "100" є дійсним, але "0100" (з нулем на початку) і "0" (нульове значення) не допускаються.

Оператори Gt і Lt працюють з усіма ефектами taint: NoSchedule, NoExecute і PreferNoSchedule.

Випадки використання та приклади

Розгляньмо, як розширені оператори tolerations розвʼязують реальні завдання планування.

Приклад 1: Захист спотових екземплярів за допомогою порогових значень SLA

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

Спочатку додайте до спотових вузлів taint з їхньою ймовірністю відмови (наприклад, 15% відмов на рік):

apiVersion: v1
kind: Node
metadata:
  name: spot-node-1
spec:
  taints:
  - key: "failure-probability"
    value: "15"
    effect: "NoExecute"

Вузли на вимогу мають набагато нижчий рівень відмов:

apiVersion: v1
kind: Node
metadata:
  name: ondemand-node-1
spec:
  taints:
  - key: "failure-probability"
    value: "2"
    effect: "NoExecute"

Критичні робочі навантаження можуть задавати суворі вимоги до SLA:

apiVersion: v1
kind: Pod
metadata:
  name: payment-processor
spec:
  tolerations:
  - key: "failure-probability"
    operator: "Lt"
    value: "5"
    effect: "NoExecute"
    tolerationSeconds: 30
  containers:
  - name: app
    image: payment-app:v1

Цей Pod буде плануватися тільки на вузлах з failure-probability менше 5 (тобто ondemand-node-1 з 2%, але не spot-node-1 з 15%). Ефект NoExecute з tolerationSeconds: 30 означає, що якщо SLA вузла погіршується (наприклад, хмарний провайдер змінює значення taint), Pod отримує 30 секунд для коректного завершення роботи перед примусовим виселенням.

Тим часом відмовостійке пакетне завдання може явно погодитися на спотові екземпляри:

apiVersion: v1
kind: Pod
metadata:
  name: batch-job
spec:
  tolerations:
  - key: "failure-probability"
    operator: "Lt"
    value: "20"
    effect: "NoExecute"
  containers:
  - name: worker
    image: batch-worker:v1

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

Приклад 2: Розміщення робочих навантажень ШІ за рівнями GPU

Робочі навантаження ШІ та машинного навчання часто мають специфічні вимоги до обладнання. За допомогою розширених операторів tolerations ви можете створювати рівні GPU-вузлів і гарантувати, що робочі навантаження потраплять на обладнання відповідної потужності.

Додайте до вузлів GPU taint з їхнім показником обчислювальної потужності:

apiVersion: v1
kind: Node
metadata:
  name: gpu-node-a100
spec:
  taints:
  - key: "gpu-compute-score"
    value: "1000"
    effect: "NoSchedule"
---
apiVersion: v1
kind: Node
metadata:
  name: gpu-node-t4
spec:
  taints:
  - key: "gpu-compute-score"
    value: "500"
    effect: "NoSchedule"

Важке навчальне навантаження може вимагати високопродуктивних GPU:

apiVersion: v1
kind: Pod
metadata:
  name: model-training
spec:
  tolerations:
  - key: "gpu-compute-score"
    operator: "Gt"
    value: "800"
    effect: "NoSchedule"
  containers:
  - name: trainer
    image: ml-trainer:v1
    resources:
      limits:
        nvidia.com/gpu: 1

Це гарантує, що Pod для навчання плануватиметься лише на вузлах з показником обчислювальної потужності понад 800 (як-от вузол A100), і не потрапить на GPU нижчого рівня, які сповільнили б навчання.

Тим часом робочі навантаження інференсу з менш суворими вимогами можуть використовувати будь-який доступний GPU:

apiVersion: v1
kind: Pod
metadata:
  name: model-inference
spec:
  tolerations:
  - key: "gpu-compute-score"
    operator: "Gt"
    value: "400"
    effect: "NoSchedule"
  containers:
  - name: inference
    image: ml-inference:v1
    resources:
      limits:
        nvidia.com/gpu: 1

Приклад 3: Розміщення робочого навантаження з оптимізацією витрат

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

До вузлів можна додати taint з їхнім рейтингом вартості:

spec:
  taints:
  - key: "cost-per-hour"
    value: "50"
    effect: "NoSchedule"

Чутливе до вартості пакетне завдання може задати, наскільки дорогі вузли воно готове толерувати:

tolerations:
- key: "cost-per-hour"
  operator: "Lt"
  value: "100"
  effect: "NoSchedule"

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

Приклад 4: Розміщення на основі продуктивності

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

tolerations:
- key: "disk-iops"
  operator: "Gt"
  value: "3000"
  effect: "NoSchedule"

Ця toleration гарантує, що Pod планується тільки на вузли, де disk-iops перевищує 3000. Оператор Gt означає «Мені потрібні вузли, у яких значення більше за цей мінімум».

Як використовувати цю можливість

Розширені оператори tolerations є альфа-можливістю в Kubernetes v1.35. Щоб спробувати її:

Увімкніть функціональну можливість на API-сервері та планувальнику:
```
--feature-gates=TaintTolerationComparisonOperators=true
```
Додайте до вузлів taints з числовими значеннями метрик, важливих для ваших потреб планування:
```
  kubectl taint nodes node-1 failure-probability=5:NoSchedule
  kubectl taint nodes node-2 disk-iops=5000:NoSchedule
```

Використовуйте нові оператори у специфікаціях ваших Podʼів:

  spec:
    tolerations:
    - key: "failure-probability"
      operator: "Lt"
      value: "1"
      effect: "NoSchedule"

Примітка:

Оскільки це альфа-можливість, розширені оператори tolerations можуть змінитися в майбутніх випусках, тож у промислових середовищах їх слід використовувати обережно. Завжди спершу ретельно тестуйте їх у непромислових кластерах.

Що далі?

Ця альфа-версія — лише початок. Збираючи відгуки від спільноти, ми плануємо:

Додати підтримку виразів CEL (Common Expression Language) у tolerations і спорідненості вузлів (node affinity) для ще гнучкішої логіки планування, зокрема порівняння семантичних версій
Поліпшити інтеграцію з автоматичним масштабуванням кластерів для планування потужностей з урахуванням порогових значень
Перевести можливість у бета-версію, а згодом і в GA зі стабільністю, придатною для промислового використання

Нам особливо цікаво дізнатися про ваші випадки використання! Чи є у вас сценарії, в яких планування на основі порогових значень вирішило б проблеми? Чи є додаткові оператори або можливості, які ви хотіли б бачити?

Як долучитися

Розвиток цієї можливості веде спільнота SIG Scheduling. Приєднуйтесь до нас, щоб спілкуватися зі спільнотою та ділитися своїми ідеями й відгуками щодо цієї можливості та не тільки.

Звʼязатися із супровідниками цієї можливості можна тут:

Slack: #sig-scheduling у Kubernetes Slack
Список розсилки: kubernetes-sig-scheduling@googlegroups.com

З питаннями щодо розширених операторів tolerations звертайтеся до спільноти SIG Scheduling. Чекаємо на ваші відгуки!

Як дізнатися більше?

Taints та Tolerations — основи
Оператори числового порівняння — докладніше про використання операторів Gt і Lt
KEP-5471: Extended Toleration Operators for Threshold-Based Placement

Kubernetes v1.35: Новий рівень ефективності завдяки перезапуску Podʼів на місці

Fri, 02 Jan 2026 10:30:00 -0800

У версії Kubernetes 1.35 представлено нову потужну можливість, яку давно чекали: змогу викликати повний перезапуск Podʼа на місці. Ця можливість, Restart All Containers (альфа-версія в 1.35), дозволяє ефективно скинути стан Podʼів порівняно з ресурсоємним підходом, що передбачає видалення та повторне створення всього Podʼа. Ця можливість особливо корисна для робочих навантажень AI/ML, дозволяючи розробникам застосунків зосередитися на основній логіці тренування, перекладаючи складні механізми обробки збоїв і відновлення на sidecar-контейнери та декларативну конфігурацію Kubernetes. За допомогою RestartAllContainers та інших запланованих вдосконалень Kubernetes продовжує додавати будівельні блоки для створення найбільш гнучких, надійних та ефективних платформ для робочих навантажень AI/ML.

Ця нова функціональність доступна після увімкнення функціональної можливості RestartAllContainersOnContainerExits. Ця альфа-можливість розширює можливість Правила перезапуску контейнерів, яка перейшла в бета-версію в Kubernetes 1.35.

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

Kubernetes вже давно підтримує політики перезапуску на рівні Podʼів (restartPolicy) і, з недавнього часу, на рівні окремих контейнерів. Ці політики чудово підходять для обробки збоїв в одному ізольованому процесі. Однак багато сучасних застосунків мають більш складні взаємозалежності між контейнерами. Наприклад:

Init-контейнер готує середовище, монтуючи том або створюючи файл конфігурації. Якщо основний контейнер застосунку пошкоджує це середовище, простого перезапуску цього контейнера недостатньо. Необхідно запустити весь процес ініціалізації заново.
Watcher sidecar контролює стан системи. Якщо він виявляє невідновлюваний, але повторюваний стан помилки, він повинен ініціювати перезапуск основного контейнера застосунку з чистого аркуша.
Sidecar, який керує віддаленим ресурсом, виходить з ладу. Навіть якщо sidecar перезапускається самостійно, основний контейнер може застрягнути, намагаючись отримати доступ до застарілого або пошкодженого зʼєднання.

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

Ця неефективність стає ще гіршою при обробці великомасштабних робочих навантажень AI/ML (>= 1000 вузлів з одним Podʼом на вузол). Загальною вимогою для цих синхронних робочих навантажень є те, що в разі виникнення збою (наприклад, збою вузла) всі Podʼи у групі повинні бути створені заново, щоб скинути стан перед відновленням навчання, навіть якщо всі інші Podʼи не були безпосередньо уражені збоєм. Одночасне видалення, створення та планування тисяч Podʼів створює величезне вузьке місце. Орієнтовні витрати, повʼязані з цією несправністю, можуть становити 100 000 доларів на місяць у вигляді втрачених ресурсів.

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

Ще однією важливою перевагою перезапуску Podʼів на місці є те, що збереження Podʼів на призначених їм вузлах дозволяє проводити подальшу оптимізацію. Наприклад, можна реалізувати кешування на рівні вузлів, повʼязане з конкретною ідентичністю Podʼа, що неможливо, коли Podʼи без необхідності створюються заново на різних вузлах.

Представляємо дію `RestartAllContainers`

Щоб вирішити цю проблему, у Kubernetes v1.35 додано нову дію до правил перезапуску контейнерів: RestartAllContainers. Коли контейнер завершується у спосіб, що відповідає правилу з цією дією, kubelet ініціює швидкий перезапуск Podʼа на місці.

Цей перезапуск на місці є дуже ефективним, оскільки зберігає найважливіші ресурси Podʼа:

UID, IP-адресу та мережевий простір імен Podʼа.
Пісочницю Podʼа та будь-які підключені пристрої.
Усі томи, включаючи emptyDir та томи, змонтовані з PVC.

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

Випадки використання

1. Ефективний перезапуск завдань ML/Batch

Для завдань навчання ML перепланування робочого Podʼа у разі збою є дорогою операцією, яка марнує цінні обчислювальні ресурси. На кластері навчання з 1000 вузлів накладні витрати на перепланування можуть призвести до втрати понад 100 000 доларів на обчислювальні ресурси щомісяця.

За допомогою дій RestartAllContainers ви можете вирішити цю проблему, увімкнувши набагато швидшу гібридну стратегію відновлення: відтворюйте лише «пошкоджені» Podʼи (наприклад, ті, що знаходяться на несправних вузлах), одночасно запускаючи RestartAllContainers для решти справних Podʼів. Тести показують, що це зменшує накладні витрати на відновлення з хвилин до декількох секунд.

Завдяки перезапуску на місці, watcher sidecar може контролювати основний процес навчання. Якщо він зустрічає конкретну помилку, яку можна повторити, watcher може вийти з призначеним кодом, щоб запустити швидке скидання робочого Podʼа, що дозволяє йому перезапуститися з останньої контрольної точки без залучення контролера Job. Ця можливість тепер нативно підтримується Kubernetes.

Детальніше про майбутній розвиток та можливості JobSet читайте в KEP-467 JobSet in-place restart.

apiVersion: v1
kind: Pod
metadata:
  name: ml-worker-pod
spec:
  restartPolicy: Never
  initContainers:
  # Цей init-контейнер буде перезапускатися при кожному перезапуску на місці.
  - name: setup-environment
    image: my-repo/setup-worker:1.0
  - name: watcher-sidecar
    image: my-repo/watcher:1.0
    restartPolicy: Always
    restartPolicyRules:
    - action: RestartAllContainers
      exitCodes:
        operator: In
        # Конкретний код виходу від watcher запускає повний перезапуск Podʼа.
        values: [88]
  containers:
  - name: main-application
    image: my-repo/training-app:1.0

2. Повторний запуск init-контейнерів для отримання чистого стану

Уявіть ситуацію, коли init-контейнер відповідає за отримання облікових даних або налаштування спільного тому. Якщо основний застосунок виходить з ладу, що призводить до пошкодження цього спільного стану, вам потрібно перезапустити init-контейнер.

Налаштувавши основний застосунок так, щоб він завершувався з певним кодом після виявлення такого пошкодження, ви можете запустити дію RestartAllContainers, гарантуючи, що init-контейнер забезпечить чисте налаштування перед перезапуском застосунку.

3. Обробка великої кількості подібних завдань

Іноді завдання найкраще виконувати у вигляді Podʼів. Кожне завдання вимагає чистого виконання. Завданням може бути бекенд ігрової сесії або обробка елементів черги. Якщо швидкість виконання завдань висока, запуск повного циклу створення, планування та ініціалізації Podʼів є надто дорогим, особливо якщо завдання можуть бути короткими. Можливість перезапустити всі контейнери з нуля дозволяє Kubernetes обробляти такі сценарії без використання спеціальних рішень або фреймворків.

Як користуватися

Щоб спробувати цю можливість, ви повинні увімкнути функціональну можливість RestartAllContainersOnContainerExits у компонентах кластера Kubernetes (API-сервер та kubelet) з Kubernetes v1.35+. Ця альфа-можливість розширює можливість ContainerRestartRules, яка перейшла в бета-версію в v1.35 та типово увімкнена.

Після увімкнення ви можете додати restartPolicyRules до будь-якого контейнера (init, sidecar або звичайного) та використовувати дію RestartAllContainers.

Можливість розроблена для зручного використання в наявних застосунках. Однак, якщо застосунок не відповідає певним рекомендаціям, це може спричинити проблеми для застосунку або інструментів спостереження. Увімкнувши цю можливість, переконайтеся, що всі контейнери є такими, що можуть бути повторно запущені, і що зовнішні інструменти готові до повторного запуску init-контейнерів. Крім того, під час перезапуску всіх контейнерів kubelet не запускає хуки preStop. Це означає, що контейнери повинні бути створені таким чином, щоб витримувати раптове завершення роботи, не покладаючись на хуки preStop для належного завершення роботи.

Спостереження за перезапуском

Щоб зробити цей процес спостережуваним, до статусу Podʼа додається нова умова AllContainersRestarting. Коли перезапуск ініційовано, ця умова стає True і повертається до False, коли всі контейнери завершили роботу і Pod готовий розпочати свій життєвий цикл заново. Це забезпечує чіткий сигнал для користувачів та інших компонентів кластера про стан Podʼа.

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

Дізнайтеся більше

Прочитайте офіційну документацію про життєвий цикл Podʼів.
Прочитайте детальну пропозицію в KEP-5532: Перезапуск усіх контейнерів при виході з контейнера.
Прочитайте пропозицію щодо перезапуску JobSet на місці в JobSet issue #467.

Ми хочемо почути вашу думку!

Як альфа-можливість, RestartAllContainers готова до експериментів, і будь-які випадки використання та відгуки вітаються. Ця можливість розробляється спільнотою SIG Node. Якщо ви зацікавлені долучитися, поділитися своїми думками або зробити внесок, будь ласка, приєднуйтеся до нас!

Ви можете звʼязатися з SIG Node через:

Slack: #sig-node
Mailing list

Уникнення зомбі-учасників кластера при оновленні до etcd v3.6

Sun, 21 Dec 2025 00:00:00 +0000

Ця стаття є дзеркалом оригіналу, нещодавно опублікованого в офіційному блозі etcd. Основний висновок? Завжди оновлюйтеся до etcd v3.5.26 або новішої версії перед переходом до v3.6. Це гарантує автоматичне відновлення кластера та дає змогу уникнути появи зомбі-учасників.

Підсумок проблеми

Нещодавно спільнота etcd вирішила проблему, яка може виникнути, коли користувачі оновлюються з v3.5 до v3.6. Цей баг може призвести до того, що кластер повідомлятиме про "зомбі-учасників", які є вузлами etcd, що були видалені з кластера бази даних деякий час тому, і які знову зʼявляються та приєднуються до консенсусу бази даних. Кластер etcd потім стає непрацездатним, доки ці зомбі-учасники не будуть видалені.

У etcd v3.5 та раніше v2store був джерелом істини для даних про членство, навіть якщо v3store також був присутній. Як частина нашого плану припинення підтримки v2store, у v3.6 v3store стає джерелом істини для інформації про членство в кластері. Зі звіту про баг ми дізналися, що в деяких старих кластерах v2store та v3store могли стати неузгодженими. Ця неузгодженість проявляється після оновлення як поява старих, видалених "зомбі" учасників кластера, які знову зʼявляються в кластері.

Виправлення та шлях оновлення

Ми додали механізм у etcd v3.5.26 для автоматичної синхронізації v3store з v2store, гарантуючи, що уражені кластери будуть відновлені перед оновленням до 3.6.x.

Щоб підтримати багатьох користувачів, які зараз оновлюються до 3.6, ми пропонуємо такий безпечний шлях оновлення:

Оновіть ваш кластер до v3.5.26 або пізнішої версії.
Зачекайте та підтвердіть, що всі учасники є справними після оновлення.
Оновіться до v3.6.

Ми не можемо надати безпечний обхідний шлях для користувачів, які мають перепони, що перешкоджають оновленню до v3.5.26. Таким чином, якщо v3.5.26 недоступна з вашого джерела пакунків або постачальника, ви повинні відкласти оновлення до v3.6, доки вона не стане доступною.

Додаткові технічні деталі

Інформація нижче надається лише для довідки. Користувачі можуть слідувати безпечному шляху оновлення без знання подальших деталей.

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

Супровідники etcd, працюючи з авторами повідомлення про проблему, виявили три можливі причини виникнення проблеми на основі симптомів та аналізу коду та логів etcd:

Баг у etcdctl snapshot restore (v3.4 та старих версіях): Під час відновлення знімка за допомогою etcdctl snapshot restore, etcdctl мав видалити наявних учасників перед додаванням нових. У v3.4 через баг старі учасники не були видалені, що призвело до появи зомбі-учасників. Зверніться до коментаря щодо etcdctl.
--force-new-cluster у v3.5 та попередніх версіях: У рідкісних випадках примусове створення нового кластера з одним учасником не повністю видаляло старих учасників, залишаючи зомбі. Проблема була вирішена у v3.5.22. Будь ласка, зверніться до цього PR у проєкті Raft для детальної технічної інформації.
Увімкнено --unsafe-no-sync: Якщо --unsafe-no-sync увімкнено, у рідкісних випадках etcd може зберегти зміну членства у v3store, але аварійно завершити роботу перед записом у WAL, спричиняючи неузгодженість між v2store та v3store. Це проблема для кластерів з одним учасником. Для кластерів з багатьма учасниками примусове створення нового кластера з одним учасником з даних вузла, що аварійно завершив роботу, може призвести до появи зомбі-учасників.

Примітка

--unsafe-no-sync загалом не рекомендується, оскільки може порушити гарантії, надані протоколом консенсусу.

Важливо, що можуть бути інші причини неузгодженості даних членства v2store та v3store, які ми ще не виявили. Це означає, що ви не можете припустити, що ви в безпеці лише тому, що не виконували жодної з трьох дій вище. Після оновлення користувачів до etcd v3.6 v3store стає джерелом даних про членство, і подальша неузгодженість неможлива.

Досвідчені користувачі, які хочуть перевірити узгодженість між v2store та v3store, можуть слідувати крокам, описаним у цьому коментарі. Ця перевірка не потрібна для виправлення проблеми, і SIG etcd не рекомендує обходити оновлення v3.5.26 незалежно від результатів перевірки.

Основний висновок

Завжди оновлюйтеся до v3.5.26 або новішої версії перед переходом до v3.6. Це гарантує автоматичне відновлення кластера та дає змогу уникнути появи зомбі-учасників.

Подяки

Ми хотіли б подякувати Christian Baumann за повідомлення про цю давню проблему оновлення. Його звіт та подальша робота допомогли привернути нашу увагу до проблеми, щоб ми могли дослідити та вирішити її в upstream.

Kubernetes v1.35: Timbernetes (Випуск «Світове дерево»)

Wed, 17 Dec 2025 10:30:00 -0800

Редактори: Aakanksha Bhende, Arujjwal Negi, Chad M. Crowell, Graziano Casto, Swathi Rao

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

Цей випуск містить 60 удосконалень, включаючи 17 стабільних, 19 бета- та 22 альфа-функції.

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

Тема та логотип випуску

2025 рік розпочався у сяйві Octarine: The Color of Magic (v1.33) і пронісся на поривах Of Wind & Will (v1.34). Ми завершуємо цей рік, тримаючись за Світове дерево, натхненні Іггдрасілем, деревом життя, що поєднує багато світів. Як і будь-яке велике дерево, Kubernetes росте кільце за кільцем і випуск за випуском, формуючись під опікою глобальної спільноти.

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

Три білки охороняють дерево: чарівник, що тримає сувій LGTM, — для рецензентів, воїн із сокирою та щитом Kubernetes — для команд випуску, які зрізають нові гілки, та розбійник із ліхтарем — для сортувальників, які проливають світло на темні черги тікетів.

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

Основні оновлення

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

Stable: Оновлення ресурсів Podʼів на місці

Kubernetes перевів оновлення ресурсів Podʼів на місці в статус загальної доступності (GA). Ця функція дозволяє користувачам налаштовувати ресурси CPU та памʼяті без перезапуску Podʼів або контейнерів. Раніше такі зміни вимагали повторного створення Podʼів, що могло порушити роботу робочих навантажень, особливо застосунків зі збереженням стану або пакетних застосунків. У попередніх випусках Kubernetes можна було змінювати лише налаштування ресурсів інфраструктури (запити та обмеження) для наявних Podʼів. Нова функціональність зміни на місці дозволяє здійснювати більш плавне вертикальне масштабування без перебоїв, підвищує ефективність, а також може спростити розробку.

Ця робота була виконана в рамках KEP #1287 під керівництвом SIG Node.

Beta: Сертифікати Podʼів для ідентифікації та безпеки робочого навантаження

Раніше для доставки сертифікатів до Podʼів були потрібні зовнішні контролери (cert-manager, SPIFFE/SPIRE), оркестрування CRD та управління Secret, а ротація здійснювалася за допомогою sidecar-контейнерів або контейнерів ініціалізації. Kubernetes v1.35 забезпечує вбудовану ідентифікацію робочого навантаження з автоматизованою ротацією сертифікатів, що значно спрощує використання сервісних мереж та архітектур нульової довіри.

Тепер kubelet генерує ключі, запитує сертифікати через PodCertificateRequest і записує пакети облікових даних безпосередньо у файлову систему Podʼа. kube-apiserver застосовує обмеження вузлів під час допуску, усуваючи найпоширенішу пастку для сторонніх підписантів: випадкове порушення меж ізоляції вузлів. Це забезпечує чисті потоки mTLS без токенів на предʼявника у шляху видачі.

Ця робота була виконана в рамках KEP #4317 під керівництвом SIG Auth.

Alpha: Функції, що декларуються вузлом перед плануванням

Коли панелі управління вмикають нові функції, але вузли відстають (що дозволено політикою розбіжності версій Kubernetes), планувальник може розміщувати Podʼи, що потребують цих функцій, на несумісних старих вузлах. Фреймворк оголошення функцій вузлів дозволяє вузлам декларувати підтримувані ними функції Kubernetes. З увімкненою новою альфа-функцією вузол повідомляє про функції, які він підтримує, публікуючи цю інформацію для панелі управління через нове поле .status.declaredFeatures. Потім kube-scheduler, контролери допуску та сторонні компоненти можуть використовувати ці декларації. Наприклад, ви можете застосувати обмеження планування та перевірки API, щоб гарантувати, що Podʼи працюють тільки на сумісних вузлах.

Ця робота була виконана в рамках KEP #5328 під керівництвом SIG Node.

Функції, що перейшли в стабільний стан

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

Розподіл трафіку PreferSameNode

Поле trafficDistribution для Service було оновлено, щоб забезпечити більш чіткий контроль за маршрутизацією трафіку. Було додано нову опцію PreferSameNode, яка дозволяє сервісам суворо пріоритезувати точки доступу на локальному вузлі, якщо вони доступні, а в іншому випадку переходити на віддалені точки доступу.

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

Ця робота була виконана в рамках KEP #3015 під керівництвом SIG Network.

Механізм managed-by для Job API

Job API тепер включає поле managedBy, яке дозволяє зовнішньому контролеру обробляти синхронізацію статусу Job. Ця функція, яка перейшла в стабільний стан у Kubernetes v1.35, розвивається насамперед завдяки потребам MultiKueue — системи диспетчеризації для декількох кластерів, в якій Job, створений в кластері управління, дзеркально відображається і виконується в робочому кластері, а оновлення статусу передаються назад. Щоб уможливити цей робочий процес, вбудований контролер Job не повинен діяти на конкретний ресурс Job, щоб контролер Kueue міг замість цього керувати оновленнями статусу.

Метою є забезпечення чіткого делегування синхронізації Job іншому контролеру. Мета не полягає в передачі власних параметрів цьому контролеру або зміні політик паралельності CronJob.

Ця робота була виконана в рамках KEP #4368 під керівництвом SIG Apps.

Надійне відстеження оновлень Podʼів за допомогою `.metadata.generation`

Історично в API Pod не було поля metadata.generation, яке є в інших обʼєктах Kubernetes, таких як Deployment. Через це контролери та користувачі не мали надійного способу перевірити, чи kubelet дійсно обробив останні зміни в специфікації Podʼа. Ця неоднозначність була особливо проблематичною для таких функцій, як вертикальне масштабування Podʼів на місці, де було важко точно визначити, коли було виконано запит на зміну розміру ресурсу.

У Kubernetes v1.33 було додано поля .metadata.generation для Podʼів як альфа-функцію. Це поле тепер є стабільним у Pod API v1.35, що означає, що кожного разу, коли оновлюється spec Podʼа, значення .metadata.generation збільшується. В рамках цього вдосконалення Pod API також отримав поле .status.observedGeneration, яке повідомляє про покоління, яке kubelet успішно побачив і обробив. Кожна з умов Podʼа також містить власне індивідуальне поле observedGeneration, яке клієнти можуть повідомляти та/або спостерігати.

Оскільки ця функція стала стабільною у v1.35, вона доступна для всіх робочих навантажень.

Ця робота була виконана в рамках KEP #5067 під керівництвом SIG Node.

Настроюваний ліміт NUMA-вузлів для менеджера топології

Історично менеджер топології використовував жорстко заданий ліміт у 8 для максимальної кількості NUMA-вузлів, які він може підтримувати, запобігаючи вибуху стану під час обчислення спорідненості. (Тут є важлива деталь: вузол NUMA не є тим самим, що й Node в API Kubernetes.) Це обмеження кількості вузлів NUMA заважало Kubernetes повною мірою використовувати сучасні високопродуктивні сервери, які все частіше оснащуються архітектурами ЦП з більш ніж 8 вузлами NUMA.

У Kubernetes v1.31 було введено нову опцію beta max-allowable-numa-nodes для конфігурації політики менеджера топології. У Kubernetes v1.35 ця опція є стабільною. Адміністратори кластерів, які її вмикають, можуть використовувати сервери з більш ніж 8 вузлами NUMA.

Хоча опція конфігурації є стабільною, спільнота Kubernetes усвідомлює низьку продуктивність великих хостів NUMA, і існує пропозиція щодо вдосконалення (KEP-5726), яка має на меті її покращити. Більше про це можна дізнатися, прочитавши Керування політиками топології на вузлі.

Ця робота була виконана в рамках KEP #4622 під керівництвом SIG Node.

Нові функції в бета-версії

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

Експонування міток топології вузлів через Downward API

Для доступу до інформації про топологію вузлів, такої як регіон і зона, зсередини Podʼа зазвичай потрібно було надсилати запит до API-сервера Kubernetes. Хоча цей підхід є функціональним, він створює складності та ризики для безпеки, оскільки вимагає широких дозволів RBAC або sidecar-контейнерів лише для отримання метаданих інфраструктури. Kubernetes v1.35 просуває можливість експонування міток топології вузлів безпосередньо через Downward API до бета-версії.

Тепер kubelet може робити інʼєкцію стандартних міток топології, таких як topology.kubernetes.io/zone та topology.kubernetes.io/region, у Podʼи як змінні середовища або у файли проєкційних томів. Основна перевага полягає в більш безпечному та ефективному способі забезпечення топологічної обізнаності робочих навантажень. Це дозволяє застосункам природно адаптуватися до своєї зони доступності або регіону без залежності від API-сервера, посилюючи безпеку завдяки дотриманню принципу мінімальних привілеїв та спрощуючи конфігурацію кластера.

Примітка: Kubernetes тепер робить інʼєкцію доступних міток топології в кожен Pod, щоб їх можна було використовувати як вхідні дані для downward API. З оновленням до версії v1.35 більшість адміністраторів кластерів побачать кілька нових міток, доданих до кожного Podʼа; це очікувана поведінка, передбачена дизайном.

Ця робота була виконана в рамках KEP #4742 під керівництвом SIG Node.

Вбудована підтримка міграції версій сховища

У Kubernetes v1.35 вбудована підтримка міграції версій сховища переходить до бета-версії і є типово увімкненою. Цей крок інтегрує логіку міграції безпосередньо в основну панель управління Kubernetes («in-tree»), усуваючи залежність від зовнішніх інструментів.

Раніше адміністратори покладалися на ручні «цикли читання/запису», часто передаючи вивід kubectl get до kubectl replace, для оновлення схем або повторного шифрування даних у стані спокою. Цей метод був неефективним і схильним до конфліктів, особливо для великих ресурсів, таких як Secret. У цьому випуску вбудований контролер автоматично обробляє конфлікти оновлень і токени узгодженості, забезпечуючи безпечний, оптимізований і надійний спосіб гарантувати актуальність збережених даних з мінімальними операційними витратами.

Ця робота була виконана в рамках KEP #4192 під керівництвом SIG API Machinery.

Змінювані ліміти підключення томів

Драйвер CSI (Container Storage Interface) — це втулок Kubernetes, який забезпечує послідовний спосіб підключення систем зберігання даних до контейнеризованих робочих навантажень. Обʼєкт CSINode записує детальну інформацію про всі драйвери CSI, встановлені на вузлі. Однак може виникнути невідповідність між заявленою та фактичною ємністю підключень на вузлах. Коли після запуску драйвера CSI використовуються слоти томів, kube-scheduler може призначити Podʼи зі збереженням стану вузлам без достатньої ємності, і зрештою вони зависнуть у стані ContainerCreating.

Kubernetes v1.35 робить CSINode.spec.drivers[*].allocatable.count змінюваним, щоб доступна ємність підключення томів вузла могла оновлюватися динамічно. Це також дозволяє драйверам CSI контролювати частоту оновлення значення allocatable.count на всіх вузлах шляхом введення настроюваного інтервалу оновлення, визначеного через обʼєкт CSIDriver. Крім того, Kubernetes автоматично оновлює CSINode.spec.drivers[*].allocatable.count при виявленні збою в підключенні томів через недостатню ємність. Хоча ця функція перейшла в бета-версію в v1.34 з функціональною можливістю MutableCSINodeAllocatableCount, яка була типово вимкненою, вона залишається в бета-версії для v1.35, щоб дати час для відгуків, але функціональна можливість тепер є типово увімкненою.

Ця робота була виконана в рамках KEP #4876 під керівництвом SIG Storage.

Опортуністична пакетна обробка

Історично склалося так, що планувальник Kubernetes обробляє Podʼи послідовно з часовою складністю O(num pods × num nodes), що може призвести до надмірних обчислень для сумісних Podʼів. Цей KEP вводить механізм опортуністичної пакетної обробки, який має на меті покращити продуктивність шляхом ідентифікації таких сумісних Podʼів за допомогою Pod scheduling signature та їх обʼєднання в пакет, що дозволяє застосовувати спільні результати фільтрування та оцінювання до всіх них.

Підпис планування Podʼа гарантує, що два Podʼи з однаковим підписом є «однаковими» з точки зору планування. Він враховує не тільки атрибути Podʼів і вузлів, але й інші Podʼи в системі та глобальні дані про розміщення Podʼів. Це означає, що будь-який Pod із заданим підписом отримає однакові результати оцінювання/придатності на будь-якому довільному наборі вузлів.

Механізм пакетної обробки складається з двох операцій, які можна викликати в будь-який час, коли це необхідно — create та nominate. Create призводить до створення нового набору інформації про пакет на основі результатів планування Podʼів, які мають дійсний підпис. Nominate використовує інформацію про пакет з create, щоб встановити імʼя номінованого вузла для нового Podʼа, підпис якого відповідає підпису канонічного Podʼа.

Ця робота була виконана в рамках KEP #5598 під керівництвом SIG Scheduling.

`maxUnavailable` для StatefulSets

StatefulSet запускає групу Podʼів і підтримує фіксовану ідентичність для кожного з них. Це критично важливо для робочих навантажень зі збереженням стану, які вимагають стабільних мережевих ідентифікаторів або постійного зберігання. Коли .spec.updateStrategy.<type> StatefulSet встановлено на RollingUpdate, контролер StatefulSet видалить і перестворить кожен Pod у StatefulSet. Він буде діяти в тому ж порядку, що і при припиненні роботи Podʼів (від найбільшого порядкового номера до найменшого), оновлюючи кожен Pod по черзі.

У Kubernetes v1.24 до налаштувань конфігурації rollingUpdate StatefulSet додано нове поле alpha з назвою maxUnavailable. Це поле не було частиною API Kubernetes, якщо адміністратор кластера явно його не вмикав. У Kubernetes v1.35 це поле є бета-версією і є типово доступним. Ви можете використовувати його для визначення максимальної кількості Podʼів, які можуть бути недоступними під час оновлення. Це налаштування є найбільш ефективним у поєднанні з .spec.podManagementPolicy, встановленим на Parallel. Ви можете встановити maxUnavailable як додатне число (наприклад: 2) або відсоток від бажаної кількості Podʼів (наприклад: 10%). Якщо це поле не вказано, типово буде встановлено значення 1, щоб зберегти попередню поведінку оновлення лише одного Podʼа за раз. Це вдосконалення дозволяє застосункам зі збереженням стану (які можуть витримати недоступність більше ніж одного Podʼа) швидше завершувати оновлення.

Ця робота була виконана в рамках KEP #961 під керівництвом SIG Apps.

Настроювана політика втулків для облікових даних у `kuberc`

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

У рамках випуску v1.35 kuberc отримує додаткову функціональність, яка дозволяє користувачам налаштовувати політику втулків для облікових даних. Ця зміна вводить два поля: credentialPluginPolicy, яке дозволяє або забороняє всі втулки, та credentialPluginAllowlist, за допомогою якого можна вказати список дозволених втулків.

Ця робота була виконана в рамках KEP #3104 у співпраці між SIG Auth та SIG CLI.

KYAML

YAML — це формат серіалізації даних, зрозумілий для людини. У Kubernetes файли YAML використовуються для визначення та конфігурації ресурсів, таких як Pod, Service та Deployment. Однак складний YAML важко читати. Значущі пробіли в YAML вимагають ретельної уваги до відступів та вкладеності, а необовʼязкове взяття рядків у лапки може призвести до несподіваного примусового перетворення типів (див.: The Norway Bug). Хоча JSON є альтернативою, він не підтримує коментарі та має суворі вимоги до кінцевих ком і ключів у лапках.

KYAML — це безпечніший та менш неоднозначний піднабір YAML, розроблений спеціально для Kubernetes. Введена як опціональна альфа-функція у версії 1.34, ця функція перейшла у бета-версію в Kubernetes 1.35 і стала типово увімкненою. Її можна вимкнути, встановивши змінну середовища KUBECTL_KYAML=false.

KYAML вирішує проблеми, повʼязані як з YAML, так і з JSON. Усі файли KYAML також є дійсними файлами YAML. Це означає, що ви можете писати KYAML і передавати його як вхідні дані до будь-якої версії kubectl. Це також означає, що вам не потрібно писати в суворому KYAML, щоб вхідні дані були розібрані.

Ця робота була виконана в рамках KEP #5295 під керівництвом SIG CLI.

Настроюваний допуск для HorizontalPodAutoscalers

Horizontal Pod Autoscaler (HPA) історично покладався на фіксований глобальний допуск 10% для дій з масштабування. Недоліком цього жорстко заданого значення було те, що робочі навантаження, які вимагають високої чутливості, наприклад ті, що потребують масштабування при збільшенні навантаження на 5%, часто блокувалися, тоді як інші могли коливатися без необхідності.

У Kubernetes v1.35 функція настроюваного допуску переходить до бета-версії і є типово увімкненою. Це вдосконалення дозволяє користувачам визначати власне вікно допуску для кожного ресурсу в полі HPA behavior. Встановивши конкретний допуск (наприклад, знизивши його до 0,05 для 5%), оператори отримують точний контроль над чутливістю автомасштабування, забезпечуючи швидку реакцію критичних робочих навантажень на невеликі зміни метрик без необхідності коригування конфігурації всього кластера.

Ця робота була виконана в рамках KEP #4951 під керівництвом SIG Autoscaling.

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

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

Ця робота була виконана в рамках KEP #127 під керівництвом SIG Node.

VolumeSource: артефакт OCI та/або образ

Під час створення Podʼа часто потрібно надати дані, бінарні файли або файли конфігурації для контейнерів. Це означало включення вмісту в основний образ контейнера або використання власного контейнера ініціалізації для завантаження та розпакування файлів у emptyDir. Обидва ці підходи залишаються дійсними. У Kubernetes v1.31 додано підтримку типу томів image, що дозволяє Podʼам декларативно завантажувати та розпаковувати артефакти образів контейнерів OCI у том. Це дозволяє пакувати та доставляти артефакти, що містять лише дані, такі як конфігурації, бінарні файли або моделі машинного навчання, використовуючи стандартні інструменти реєстру OCI.

Завдяки цій функції ви можете повністю відокремити свої дані від образу контейнера та усунути необхідність у додаткових контейнерах ініціалізації або скриптах запуску. Тип тома image перебуває в бета-версії з v1.33 і є типово увімкненим у v1.35. Зверніть увагу, що для використання цієї функції потрібне сумісне середовище виконання контейнерів, таке як containerd v2.1 або пізнішої версії.

Ця робота була виконана в рамках KEP #4639 під керівництвом SIG Node.

Примусова перевірка облікових даних `kubelet` для кешованих образів

Налаштування imagePullPolicy: IfNotPresent наразі дозволяє Podʼу використовувати образ контейнера, який вже кешований на вузлі, навіть якщо сам Pod не має облікових даних для завантаження цього образу. Недоліком такої поведінки є те, що вона створює вразливість безпеки в багатокористувацьких кластерах: якщо Pod з дійсними обліковими даними завантажує конфіденційний приватний образ на вузол, наступний неавторизований Pod на тому самому вузлі може отримати доступ до цього образу, просто використовуючи локальний кеш.

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

У Kubernetes v1.35 ця функція перейшла в бета-версію і є типово увімкненою. Користувачі все ще можуть вимкнути її, встановивши для функціональної можливості KubeletEnsureSecretPulledImages значення false. Крім того, прапорець imagePullCredentialsVerificationPolicy дозволяє операторам налаштувати бажаний рівень безпеки, від режиму, що надає пріоритет зворотній сумісності, до режиму суворого застосування, що забезпечує максимальну безпеку.

Ця робота була виконана в рамках KEP #2535 під керівництвом SIG Node.

Деталізовані правила перезапуску контейнерів

Історично поле restartPolicy визначалося суворо на рівні Podʼа, що змушувало всі контейнери в Podʼі поводитися однаково. Недоліком цього глобального налаштування була відсутність деталізації для складних робочих навантажень, таких як завдання навчання AI/ML. Вони часто вимагали restartPolicy: Never для Podʼа, щоб керувати завершенням завдання, але окремі контейнери могли б скористатися перевагами перезапуску на місці для конкретних помилок, після яких можна повторити спробу (наприклад, збої мережі або помилки ініціалізації GPU).

Kubernetes v1.35 вирішує цю проблему, увімкнувши restartPolicy та restartPolicyRules у самому API контейнера. Це дозволяє користувачам визначати стратегії перезапуску для окремих звичайних контейнерів та контейнерів ініціалізації, які працюють незалежно від загальної політики Podʼа. Наприклад, контейнер тепер можна налаштувати так, щоб він автоматично перезапускався тільки в разі виходу з певним кодом помилки, що дозволяє уникнути значних витрат на перепланування всього Podʼа через тимчасові збої.

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

Ця робота була виконана в рамках KEP #5307 під керівництвом SIG Node.

Добровільне ввімкнення драйвером CSI отримання токенів службових облікових записів через поле секретів

Надання токенів ServiceAccount драйверам Container Storage Interface (CSI) традиційно базувалося на їх інʼєкції у поле volume_context. Такий підхід становить значний ризик для безпеки, оскільки volume_context призначене для нечутливих даних конфігурації і часто записується драйверами та інструментами налагодження в журнали у вигляді звичайного тексту, що може призвести до витоку облікових даних.

Kubernetes v1.35 впроваджує механізм добровільного ввімкнення (opt-in) для драйверів CSI, що дозволяє отримувати токени ServiceAccount через спеціальне поле секретів у запиті NodePublishVolume. Тепер драйвери можуть увімкнути цю поведінку, встановивши поле serviceAccountTokenInSecrets на значення true у своєму обʼєкті CSIDriver, даючи вказівку kubelet безпечно заповнити токен.

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

Ця робота була виконана в рамках KEP #5538 під керівництвом SIG Auth у співпраці з SIG Storage.

Стан Deployment: кількість реплік, що завершують роботу

Раніше стан Deployment надавав детальну інформацію про доступні та оновлені репліки, але не містив чіткої інформації про Podʼи, які перебували в процесі вимкнення. Недоліком такого упущення було те, що користувачі та контролери не могли легко відрізнити стабільний Deployment від такого, в якому Podʼи все ще виконували завдання з очищення або дотримувалися тривалих пільгових періодів.

Kubernetes v1.35 переводить поле terminatingReplicas у статусі Deployment до бета-версії. Це поле надає кількість Podʼів, для яких встановлено час видалення, але які ще не були видалені з системи. Ця функція є фундаментальним кроком у більш масштабній ініціативі щодо поліпшення способу обробки заміни Podʼів у Deployment, що закладає основу для майбутніх політик щодо створення нових Podʼів під час розгортання.

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

Ця робота була виконана в рамках KEP #3973 під керівництвом SIG Apps.

Нові функції в альфа-версії

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

Підтримка групового планування в Kubernetes

Планування взаємозалежних робочих навантажень, таких як завдання з навчання AI/ML або HPC-симуляції, традиційно було складним завданням, оскільки типовий планувальник Kubernetes розміщує Podʼи індивідуально. Це часто призводить до часткового планування, коли деякі Podʼи запускаються, а інші безкінечно чекають на ресурси, що призводить до взаємних блокувань і марнування ємності кластера.

Kubernetes v1.35 впроваджує вбудовану підтримку так званого «групового планування» (gang scheduling) за допомогою нового API Workload та концепції PodGroup. Ця функція реалізує стратегію планування «все або нічого», гарантуючи, що визначена група Podʼів планується тільки в тому випадку, якщо кластер має достатньо ресурсів для одночасного розміщення всієї групи.

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

Ця робота була виконана в рамках KEP #4671 під керівництвом SIG Scheduling.

Обмежена імперсонізація

Історично дієслово impersonate в Kubernetes RBAC функціонувало за принципом «все або нічого»: як тільки користувач отримував дозвіл на імперсонізацію цільової ідентичності, він отримував усі повʼязані з нею дозволи. Недоліком такого широкого дозволу було порушення принципу мінімальних привілеїв, що не дозволяло адміністраторам обмежувати імперсонаторів конкретними діями або ресурсами.

Kubernetes v1.35 впроваджує нову альфа-функцію, обмежену імперсонізацію, яка додає вторинну перевірку авторизації до процесу імперсонізації. Коли ця функція вмикається через функціональну можливість ConstrainedImpersonation, API-сервер перевіряє не тільки базовий дозвіл impersonate, але й перевіряє, чи уповноважений імперсонатор на конкретну дію, використовуючи нові префікси дієслів (наприклад, impersonate-on:<mode>:<verb>). Це дозволяє адміністраторам визначати детальні політики, наприклад, дозволяти інженеру технічної підтримки імперсонувати адміністратора кластера виключно для перегляду журналів, не надаючи повного адміністративного доступу.

Ця робота була виконана в рамках KEP #5284 під керівництвом SIG Auth.

Flagz для компонентів Kubernetes

Для перевірки конфігурації компонентів Kubernetes, таких як API-сервер або kubelet, під час виконання традиційно був необхідний привілейований доступ до вузла хоста або аргументів процесу. Щоб вирішити цю проблему, було введено точку доступу /flagz для експонування опцій командного рядка через HTTP. Однак спочатку її вивід був обмежений простим текстом, що ускладнювало автоматизованим інструментам надійний аналіз і перевірку конфігурацій.

У Kubernetes v1.35 точка доступу /flagz була вдосконалена для підтримки структурованого, машиночитаного виводу JSON. Авторизовані користувачі тепер можуть запитувати версійну відповідь JSON за допомогою стандартного узгодження вмісту HTTP, тоді як оригінальний формат простого тексту залишається доступним для перевірки людиною. Це оновлення значно покращує спостережуваність і робочі процеси відповідності, дозволяючи зовнішнім системам програмно перевіряти конфігурації компонентів без нестабільного аналізу тексту або прямого доступу до інфраструктури.

Ця робота була виконана в рамках KEP #4828 під керівництвом SIG Instrumentation.

Statusz для компонентів Kubernetes

Усунення несправностей компонентів Kubernetes, таких як kube-apiserver або kubelet, традиційно передбачало аналіз неструктурованих журналів або текстового виводу, що було ненадійним і важким для автоматизації. Хоча раніше існувала базова точка доступу /statusz, вона не мала стандартизованого, машиночитаного формату, що обмежувало її корисність для зовнішніх систем моніторингу.

У Kubernetes v1.35 точка доступу /statusz була покращена для підтримки структурованого, машиночитаного JSON-виводу. Авторизовані користувачі тепер можуть запитувати цей формат за допомогою стандартного узгодження вмісту HTTP, щоб отримати точні дані про стан, такі як інформація про версію та показники справності, без залежності від крихкого аналізу тексту. Це покращення забезпечує надійний, узгоджений інтерфейс для автоматизованих інструментів налагодження та спостережуваності у всіх основних компонентах.

Ця робота була виконана в рамках KEP #4827 під керівництвом SIG Instrumentation.

CCM: узгодження контролера маршрутів на основі спостереження за допомогою інформерів

Управління мережевими маршрутами в хмарних середовищах традиційно базувалося на періодичному опитуванні API хмарного провайдера за допомогою Cloud Controller Manager (CCM) для перевірки та оновлення таблиць маршрутів. Цей підхід узгодження з фіксованим інтервалом може бути неефективним, часто генеруючи великий обсяг непотрібних викликів API та створюючи затримку між зміною стану вузла та відповідним оновленням маршруту.

У випуску Kubernetes v1.35 бібліотека cloud-controller-manager впроваджує стратегію узгодження на основі спостереження для контролера маршрутів. Замість того, щоб покладатися на таймер, контролер тепер використовує інформери для спостереження за конкретними подіями Node, такими як додавання, видалення або відповідні оновлення полів, і запускає синхронізацію маршрутів тільки тоді, коли насправді відбувається зміна.

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

Ця робота була виконана в рамках KEP #5237 під керівництвом SIG Cloud Provider.

Розширені оператори toleration для розміщення на основі порогових значень

Kubernetes v1.35 впроваджує планування з урахуванням SLA, дозволяючи робочим навантаженням формулювати вимоги до надійності. Ця функція додає оператори числового порівняння до toleration, дозволяючи Podʼам обирати або уникати вузлів на основі SLA-орієнтованих позначок taint, таких як гарантії обслуговування або якість домену збоїв.

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

Ця робота була виконана в рамках KEP #5471 під керівництвом SIG Scheduling.

Змінювані ресурси контейнера, коли Job призупинено

Виконання пакетних робочих навантажень часто супроводжується спробами та помилками з обмеженнями ресурсів. Наразі специфікація Job є незмінною, що означає: якщо Job завершується з помилкою Out of Memory (OOM) або через недостатню кількість ресурсів CPU, користувач не може просто налаштувати ресурси; він повинен видалити Job і створити новий, втрачаючи історію виконання та статус.

Kubernetes v1.35 впроваджує можливість оновлення запитів на ресурси та обмежень для Job, які перебувають у призупиненому стані. Це вдосконалення, яке вмикається за допомогою функціональної можливості MutablePodResourcesForSuspendedJobs, дозволяє користувачам призупиняти Job, що завершується збоєм, змінювати його шаблон Pod з відповідними значеннями ресурсів, а потім поновлювати виконання з виправленою конфігурацією.

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

Ця робота була виконана в рамках KEP #5440 під керівництвом SIG Apps.

Інші важливі зміни

Подальші інновації в динамічному виділенні ресурсів (DRA)

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

Розширені запити на ресурси через DRA

Було усунено кілька функціональних прогалин порівняно з розширеними запитами на ресурси через втулки пристроїв, наприклад, оцінювання та повторне використання пристроїв у контейнерах ініціалізації.

Taint та toleration для пристроїв

Новий ефект "None" можна використовувати для повідомлення про проблему без негайного впливу на планування або роботу Podʼів. DeviceTaintRule тепер надає інформацію про стан поточного виселення. Ефект "None" можна використовувати для «пробного запуску» перед фактичним виселенням Podʼів:

Створіть DeviceTaintRule з "effect: None".
Перевірте стан, щоб побачити, скільки Podʼів буде виселено.
Замініть "effect: None" на "effect: NoExecute".

Пристрої, що розділяються на розділи

Пристрої, що належать до одних і тих самих пристроїв, які можна розділити, тепер можна визначати в різних ResourceSlice. Більше інформації можна знайти в офіційній документації.

Споживча ємність, умови привʼязки пристроїв

Було виправлено кілька помилок та/або додано більше тестів. Більше інформації про Споживчу ємність та Умови привʼязки можна знайти в офіційній документації.

Семантика порівнянних версій ресурсів

У Kubernetes v1.35 змінено спосіб, у який клієнти можуть інтерпретувати версії ресурсів.

До версії v1.35 єдиним підтримуваним порівнянням, яке клієнти могли виконувати, була перевірка рівності рядків: якщо дві версії ресурсів були рівними, вони вважалися однаковими. Клієнти також могли надавати версію ресурсу API-серверу і просити панель управління виконувати внутрішні порівняння, наприклад, передавати всі події з певної версії ресурсу.

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

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

Ця робота була виконана в рамках KEP #5504 під керівництвом SIG API Machinery.

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

Переходи до стабільної версії

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

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

Застарівання, вилучення та новини спільноти

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

Виведення з експлуатації Ingress NGINX

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

Однак підтримка проєкту стала неможливою. Через гостру нестачу мейнтейнерів та зростаючий технічний борг спільнота нещодавно прийняла важке рішення про його виведення з експлуатації. Строго кажучи, це не є частиною випуску v1.35, але це настільки важлива зміна, що ми хотіли б наголосити на ній тут.

Як наслідок, проєкт Kubernetes оголосив, що Ingress NGINX отримуватиме лише підтримку в міру можливостей до березня 2026 року. Після цієї дати він буде заархівований без подальших оновлень. Рекомендований варіант подальших дій — перехід на Gateway API, який пропонує більш сучасний, безпечний і розширюваний стандарт управління трафіком.

Більше інформації ви можете знайти в офіційному дописі в блозі.

Вилучення підтримки cgroup v1

Що стосується управління ресурсами на вузлах Linux, Kubernetes історично покладався на cgroups (контрольні групи). Хоча оригінальний cgroup v1 був функціональним, він часто був непослідовним і обмеженим. Ось чому Kubernetes ще у версії v1.25 запровадив підтримку cgroup v2, пропонуючи набагато чистішу, уніфіковану ієрархію та кращу ізоляцію ресурсів.

Оскільки cgroup v2 тепер є сучасним стандартом, Kubernetes готовий відмовитися від підтримки застарілого cgroup v1 у версії v1.35. Це важливе повідомлення для адміністраторів кластерів: якщо ви все ще використовуєте вузли на старих дистрибутивах Linux, які не підтримують cgroup v2, ваш kubelet не запуститься. Щоб уникнути простою, вам потрібно буде перенести ці вузли на системи, де ввімкнено cgroup v2.

Щоб дізнатися більше, прочитайте про cgroup v2;
ви також можете стежити за роботою з переходу в KEP-5573: Remove cgroup v1 support.

Застарівання режиму ipvs у kube-proxy

Кілька років тому Kubernetes застосував режим ipvs у kube-proxy, щоб забезпечити швидше балансування навантаження, ніж стандартний режим iptables. Хоча це забезпечило підвищення продуктивності, синхронізація з мінливими вимогами до мережі створила занадто великий технічний борг і складність.

Через це навантаження на обслуговування Kubernetes v1.35 оголошує режим ipvs застарілим. Хоча цей режим залишається доступним у цьому випуску, kube-proxy тепер видаватиме попередження під час запуску, якщо він налаштований на його використання. Мета полягає в оптимізації кодової бази та зосередженні уваги на сучасних стандартах. Для вузлів Linux слід почати перехід на nftables, який зараз є рекомендованою заміною.

Більше інформації можна знайти в KEP-5495: Deprecate ipvs mode in kube-proxy.

Останній дзвоник для containerd v1.X

Хоча Kubernetes v1.35 все ще підтримує containerd 1.7 та інші випуски LTS, це остання версія з такою підтримкою. Спільнота SIG Node визначила v1.35 як останній випуск, що підтримує серію containerd v1.X.

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

Більше інформації ви можете знайти в офіційному дописі в блозі або в KEP-4033: Discover cgroup driver from CRI.

Покращена стабільність Podʼів під час перезапуску `kubelet`

Раніше перезапуск служби kubelet часто спричиняв тимчасове порушення стану Podʼів. Під час перезапуску kubelet скидав стан контейнерів, через що справні Podʼи позначалися як NotReady і видалялися з балансувальників навантаження, навіть якщо застосунок сам по собі працював належним чином.

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

Більше інформації ви можете знайти в KEP-4781: Fix inconsistent container ready state after kubelet restart.

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

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

Доступність

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

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

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

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

Ми вшановуємо памʼять Хана Канга, багаторічного учасника та шановного інженера, чия технічна досконалість та заразливий ентузіазм залишили незабутній слід у спільноті Kubernetes. Хан був значною силою в SIG Instrumentation та SIG API Machinery, отримавши нагороду Kubernetes Contributor Award 2021 за свою важливу роботу та постійну відданість стабільності ядра проєкту. Окрім технічного внеску, Хана глибоко поважали за його щедрість як наставника та пристрасть до налагодження звʼязків між людьми. Він був відомий тим, що «відкривав двері» для інших, чи то допомагаючи новим учасникам з їхніми першими pull request, чи то підтримуючи колег з терпінням і добротою. Спадщина Хана живе в інженерах, яких він надихнув, у надійних системах, які він допоміг створити, та в теплій атмосфері співпраці, яку він культивував у хмарній екосистемі.

Ми хотіли б подякувати всій команді випуску за години наполегливої праці, щоб надати нашій спільноті випуск Kubernetes v1.35. Склад команди випуску охоплює як тих, хто вперше бере участь як shadow, так і керівників команд, які повертаються з досвідом, набутим протягом кількох циклів випуску. Ми надзвичайно вдячні нашому керівнику випуску, Дрю Хагену, чиї практичні поради та енергійність не тільки допомогли нам подолати складні виклики, але й підживили дух спільноти, що стоїть за цим успішним випуском.

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

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

Під час циклу випуску версії 1.35, який тривав 14 тижнів з 15 вересня 2025 року по 17 грудня 2025 року, Kubernetes отримав внески від 85 різних компаній та 419 окремих осіб. У ширшій екосистемі хмарних технологій ця цифра зростає до 281 компанії, що налічує 1769 учасників.

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

Джерела цих даних:

Огляд подій

Лютий 2026

KCD — Дні спільноти Kubernetes: Нью-Делі: 21 лютого 2026 р. | Нью-Делі, Індія
KCD — Дні спільноти Kubernetes: Гвадалахара: 23 лютого 2026 р. | Гвадалахара, Мексика

Березень 2026

KubeCon + CloudNativeCon Europe 2026: 23–26 березня 2026 р. | Амстердам, Нідерланди

Травень 2026

KCD — Дні спільноти Kubernetes: Торонто: 13 травня 2026 р. | Торонто, Канада
KCD — Дні спільноти Kubernetes: Гельсінкі: 20 травня 2026 р. | Гельсінкі, Фінляндія

Червень 2026

KubeCon + CloudNativeCon India 2026: 18–19 червня 2026 р. | Мумбаї, Індія
KCD — Дні спільноти Kubernetes: Куала-Лумпур: 27 червня 2026 р. | Куала-Лумпур, Малайзія

Липень 2026

KubeCon + CloudNativeCon Japan 2026: 29–30 липня 2026 р. | Йокогама, Японія

Останні подробиці про події можна знайти тут.

Найближчий вебінар про випуск

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

Приєднуйтесь

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

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

Gateway API 1.4: Нові можливості

Thu, 06 Nov 2025 09:00:00 -0800

Готові до революції у сфері мережевих технологій Kubernetes? Спільнота Kubernetes SIG Network представила загальнодоступну версію Gateway API (v1.4.0)! Випущена 6 жовтня 2025 року версія 1.4.0 зміцнює позиції сучасних, динамічних і розширюваних мережевих технологій у Kubernetes.

Gateway API v1.4.0 приносить три нові можливості до Стандартного каналу (канал GA-випусків Gateway API):

BackendTLSPolicy для TLS між шлюзами та бекендами
supportedFeatures у статусі GatewayClass
Іменовані правила для маршрутів

та вводить три нові експериментальні можливості:

Ресурс Mesh для конфігурації service mesh
Типові Gateways для спрощення конфігурації
Фільтр externalAuth для HTTPRoute

Перехід до Стандартного каналу

Політика TLS для бекендів

Керівники: Candace Holman, Norwin Schnyder, Katarzyna Łach

GEP-1897: BackendTLSPolicy

BackendTLSPolicy — це новий тип Gateway API для визначення конфігурації TLS зʼєднання між шлюзом і Podʼами бекенду. До впровадження BackendTLSPolicy не існувало API-специфікації, яка б дозволяла шифрувати трафік на шляху від шлюзу до бекенду.

Конфігурація BackendTLSPolicy validation вимагає імені хоста. Цей hostname має два призначення. Він використовується як заголовок SNI під час підключення до бекенду, а для автентифікації сертифікат, представлений бекендом, повинен відповідати цьому імені хоста, якщо subjectAltNames не вказано явно.

Якщо subjectAltNames (SAN) вказано, hostname використовується тільки для SNI, а автентифікація виконується на основі SAN. Якщо в цьому випадку все одно потрібно виконати автентифікацію на основі значення імені хоста, його НЕОБХІДНО додати до списку subjectAltNames.

Конфігурація BackendTLSPolicy validation також вимагає або caCertificateRefs, або wellKnownCACertificates. caCertificateRefs посилається на один або декілька (до 8) пакунків сертифікатів TLS, закодованих у форматі PEM. Якщо немає конкретних сертифікатів для використання, то залежно від вашої реалізації ви можете використовувати wellKnownCACertificates, встановлений у значення "System", щоб повідомити шлюз про необхідність використання набору довірених сертифікатів CA, характерних для конкретної реалізації.

У цьому прикладі BackendTLSPolicy налаштований на використання сертифікатів, визначених у ConfigMap auth-cert, для підключення до зашифрованого TLS-зʼєднання, де Podʼи, що підтримують сервіс автентифікації, повинні надавати дійсний сертифікат для auth.example.com. Він використовує subjectAltNames з типом Hostname, але ви також можете використовувати тип URI.

apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
  name: tls-upstream-auth
spec:
  targetRefs:
  - kind: Service
    name: auth
    group: ""
    sectionName: "https"
  validation:
    caCertificateRefs:
    - group: "" # основна група API
      kind: ConfigMap
      name: auth-cert
    subjectAltNames:
    - type: "Hostname"
      hostname: "auth.example.com"

У цьому прикладі BackendTLSPolicy налаштований на використання системних сертифікатів для підключення до зашифрованого TLS бекенду, де Podʼи, що обслуговують Service dev, повинні надавати дійсний сертифікат для dev.example.com.

apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
  name: tls-upstream-dev
spec:
  targetRefs:
  - kind: Service
    name: dev
    group: ""
    sectionName: "btls"
  validation:
    wellKnownCACertificates: "System"
    hostname: dev.example.com

Більш детальну інформацію про конфігурацію TLS в Gateway API можна знайти в статті Gateway API - TLS Configuration.

Інформація про стан можливостей, які підтримує реалізація

Керівники: Lior Lieberman, Beka Modebadze

GEP-2162: Supported features in GatewayClass Status

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

Назва цієї можливості для тестів на відповідність (та звітування про статус GatewayClass) — SupportedFeatures. Реалізації повинні заповнити поле supportedFeatures у .status GatewayClass до прийняття GatewayClass або в рамках тієї ж операції.

Ось приклад supportedFeatures, опублікованого в .status GatewayClass:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
...
status:
  conditions:
  - lastTransitionTime: "2022-11-16T10:33:06Z"
    message: Handled by Foo controller
    observedGeneration: 1
    reason: Accepted
    status: "True"
    type: Accepted
  supportedFeatures:
    - HTTPRoute
    - HTTPRouteHostRewrite
    - HTTPRoutePortRedirect
    - HTTPRouteQueryParamMatching

Перехід SupportedFeatures до Standard допоміг поліпшити процес тестування відповідності для Gateway API. Набір тестів на відповідність тепер автоматично виконуватиме тести на основі можливостей, визначених у статусі GatewayClass. Це створює міцний, перевірюваний звʼязок між заявленими можливостями реалізації та результатами тестування, що полегшує для розробників виконання правильних тестів на відповідність, а для користувачів — довіру до звітів про відповідність.

Це означає, що коли поле SupportedFeatures заповнюється в статусі GatewayClass, не буде потреби в додаткових прапорцях тестів на відповідність, таких як –suported-features, або –exempt, або –all-features. Важливо зазначити, що можливості Mesh є винятком із цього правила і можуть бути перевірені на відповідність за допомогою Conformance Profiles або шляхом ручного введення будь-якої комбінації прапорців, повʼязаних з можливостями, доки спеціальний ресурс не вийде з експериментального каналу.

Іменовані правила для Routes

GEP-995: Adding a new name field to all xRouteRule types (HTTPRouteRule, GRPCRouteRule, etc.)

Керівники: Guilherme Cassolato

Це вдосконалення дозволяє чітко ідентифікувати правила маршрутизації та посилатися на них у всій екосистемі Gateway API. Ось деякі з основних випадків використання:

Статус: можливість для станів (conditions) у статусі посилатися на конкретні правила безпосередньо за назвою.
Спостережуваність: спрощення ідентифікації окремих правил у логах, трейсах та метриках.
Політики: дозволяє політикам (GEP-713) орієнтуватися на конкретні правила маршрутизації через поле sectionName у їх targetRef[s].
Інструменти: спрощення фільтрування та посилання на правила маршрутизації в таких інструментах, як gwctl, kubectl, а також в універсальних утилітах, таких як jq та yq.
Внутрішнє зіставлення конфігурацій: спрощення генерації внутрішніх конфігурацій, які посилаються на правила маршрутизації за іменем у реалізаціях шлюзів і мереж.

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

Хоча нове поле імені є необовʼязковим (тож наявні ресурси залишаються дійсними), його використання наполегливо рекомендується. Від реалізацій не очікується призначення типового значення, але можуть застосовувати обмеження, такі як незмінність.

Нарешті, майте на увазі, що формат імені перевіряється, а інші поля (такі як sectionName) можуть накладати додаткові непрямі обмеження.

Зміни в експериментальному каналі

Увімкнення зовнішньої автентифікації для HTTPRoute

Надання Gateway API можливості забезпечувати автентифікацію, а можливо, і авторизацію на рівні Gateway або HTTPRoute є дуже запитуваною можливістю протягом тривалого часу. (Див. тікет GEP-1494 для отримання додаткової інформації.)

Цей реліз Gateway API додає експериментальний фільтр у HTTPRoute, який вказує реалізації Gateway API викликати зовнішній сервіс для автентифікації (а за бажанням, і авторизації) запитів.

Цей фільтр базується на Envoy ext_authz API і дозволяє спілкуватися із сервісом Auth, яка використовує протокол gRPC або HTTP.

Обидва методи дозволяють налаштувати, які заголовки пересилати до сервісу Auth, причому протокол HTTP дозволяє передавати додаткову інформацію, таку як префікс шляху.

Приклад HTTP може виглядати так (зверніть увагу, що для цього прикладу потрібно встановити експериментальний канал та реалізація, яка підтримує зовнішню автентифікацію, щоб вона справді розуміла цю конфігурацію):

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: require-auth
  namespace: default
spec:
  parentRefs:
    - name: your-gateway-here
  rules:
    - matches:
      - path:
          type: Prefix
          value: /admin
      filters:
        - type: ExternalAuth
          externalAuth:
            protocol: HTTP
            backendRef:
              name: auth-service
            http:
              # Ці заголовки завжди надсилаються для протоколу HTTP,
              # але включені сюди для наочності.
              allowedHeaders:
                - Host
                - Method
                - Path
                - Content-Length
                - Authorization
      backendRefs:
        - name: admin-backend
          port: 8080

Це дозволяє бекенд-сервісу Auth використовувати надані заголовки для прийняття рішення про автентифікацію запиту.

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

Оскільки заголовок Authorization використовується в багатьох методах автентифікації, цей метод можна використовувати для Basic, Oauth, JWT та інших поширених методів автентифікації та авторизації.

Ресурс Mesh

Керівники: Flynn

GEP-3949: Mesh-wide configuration and supported features

Gateway API v1.4.0 представляє новий експериментальний ресурс Mesh, який надає можливість налаштовувати параметри для всього mesh та виявляти можливості, що підтримуються певною реалізацією mesh. Цей ресурс аналогічний ресурсу Gateway і спочатку буде використовуватися переважно для тестування відповідності, а в майбутньому планується розширити його використання на шлюзи поза кластером.

Ресурс Mesh має область дії на рівні кластера і, як експериментальна можливість, має назву XMesh і знаходиться в групі API gateway.networking.x-k8s.io. Ключовим полем є controllerName, яке визначає реалізацію mesh, відповідальну за ресурс. Розділ status ресурсу вказує, чи прийняла його реалізація mesh, і перелічує можливості, які підтримує mesh.

Однією з цілей цього GEP є не ускладнювати користувачам впровадження mesh. Для спрощення впровадження очікується, що реалізації mesh створюватимуть типовий ресурс Mesh під час запуску, якщо такий з відповідним controllerName ще не існує. Це усуває необхідність ручного створення ресурсу для початку використання mesh.

Новий тип XMesh API в групі API gateway.networking.x-k8s.io/v1alpha1 забезпечує центральний пункт для конфігурації mesh і виявлення можливостей (джерело).

Мінімальний обʼєкт XMesh вказує controllerName:

apiVersion: gateway.networking.x-k8s.io/v1alpha1
kind: XMesh
metadata:
  name: one-mesh-to-mesh-them-all
spec:
  controllerName: one-mesh.example.com/one-mesh

Реалізація mesh заповнює поле статусу, щоб підтвердити, що вона прийняла ресурс, і показує список підтримуваних можливостей (джерело):

status:
  conditions:
    - type: Accepted
      status: "True"
      reason: Accepted
  supportedFeatures:
    - name: MeshHTTPRoute
    - name: OffClusterGateway

Представляємо типові Gateways

Керівники: Flynn

GEP-3793: Allowing Gateways to program some routes by default.

Розробники застосунків часто зазначали, що необхідно явно вказувати батьківський шлюз для кожного маршруту північ-південь. Хоча така явність запобігає двозначності, вона створює додаткові труднощі, особливо для розробників, які просто хочуть відкрити свій застосунок для зовнішнього світу, не турбуючись про схему іменування базової інфраструктури. Щоб вирішити цю проблему, ми запровадили поняття типових Gateways (Default Gateways).

Для розробників застосунків: просто «використовуйте типовий»

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

Для цього потрібно встановити нове поле useDefaultGateways у spec вашого маршруту.

Ось простий HTTPRoute, який використовує типовий шлюз:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  useDefaultGateways: All
  rules:
  - backendRefs:
    - name: my-service
      port: 80

Ось і все! Більше не потрібно шукати правильну назву шлюзу для вашого середовища. Ваш маршрут тепер є «маршрутом із типовим шлюзом» (defaulted Route).

Для операторів кластерів: ви все ще контролюєте ситуацію

Ця можливість не забирає контроль у операторів кластерів («Chihiro»¹). Насправді, вони мають явний контроль над тим, які шлюзи можуть діяти як типові. Шлюз прийме ці маршрути з типовим шлюзом лише в тому випадку, якщо він налаштований на це.

Ви також можете використовувати ValidatingAdmissionPolicy, щоб вимагати або навіть забороняти маршрутам покладатися на типовий Gateway.

Як оператор кластера, ви можете призначити шлюз як типовий, встановивши (нове) поле .spec.defaultScope:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-default-gateway
  namespace: default
spec:
  defaultScope: All
  # ... інша конфігурація шлюзу

Оператори можуть обрати не використовувати типові шлюзи або навіть використовувати декілька.

Як це працює та основні деталі

Щоб підтримувати чистий, дружній до GitOps робочий процес, типовий шлюз не змінює spec.parentRefs вашого маршруту. Натомість, звʼязок відображається у полі status маршруту. Ви завжди можете перевірити розділ status.parents вашого маршруту, щоб точно побачити, який шлюз або шлюзи його прийняли. Це зберігає ваш початковий намір і уникає конфліктів з інструментами CD.
Дизайн явно підтримує наявність кількох шлюзів, призначених як типові в межах кластера. Коли це відбувається, маршрут із типовим шлюзом буде привʼязаний до всіх з них. Це дозволяє операторам кластерів виконувати міграції без простоїв і тестування нових типових шлюзів.
Ви можете створити один маршрут, який обробляє як північ-південь (трафік, що входить або виходить з кластера, через типовий шлюз), так і схід-захід/mesh-трафік (трафік між сервісами в межах кластера), явно посилаючись на Service в parentRefs.

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

Налаштування перевірки сертифіката клієнта

Керівники: Arko Dasgupta, Katarzyna Łach

GEP-91: Address connection coalescing security issue

Цей випуск містить оновлення для налаштування перевірки клієнтських сертифікатів, що усуває критичну вразливість безпеки, повʼязану з повторним використанням зʼєднання. Обʼєднання HTTP-зʼєднань — це оптимізація веб-продуктивності, яка дозволяє клієнту повторно використовувати наявне TLS-зʼєднання для запитів до різних доменів. Хоча це зменшує накладні витрати на встановлення нових зʼєднань, воно створює ризик для безпеки в контексті шлюзів API. Можливість повторного використання одного TLS-зʼєднання для декількох прослуховувачів вимагає впровадження спільної конфігурації клієнтських сертифікатів, щоб уникнути несанкціонованого доступу.

Чому mTLS на основі SNI не є рішенням

Можна було б подумати, що використання Server Name Indication (SNI) для розрізнення між прослуховувачами вирішить цю проблему. Однак TLS SNI не є надійним механізмом для забезпечення політик безпеки в сценарії обʼєднання зʼєднань. Клієнт може використовувати одне TLS-зʼєднання для кількох зʼєднань з партнерами, якщо вони всі покриті одним і тим же сертифікатом. Це означає, що клієнт може встановити зʼєднання, вказавши одну ідентичність партнера (використовуючи SNI), а потім повторно використовувати це зʼєднання для доступу до іншого віртуального хоста, який прослуховує на тій же IP-адресі та порту. Це повторне використання, яке контролюється евристикою з боку клієнта, може обійти політики взаємного TLS, які були специфічні для конфігурації другого прослуховувача.

Ось приклад, щоб допомогти пояснити це:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: wildcard-tls-gateway
spec:
  gatewayClassName: example
  listeners:
  - name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
    tls:
      certificateRefs:
      - group: "" # основна група API
        kind: Secret
        name: foo-example-com-cert  # SAN: foo.example.com
  - name: wildcard-https
    protocol: HTTPS
    port: 443
    hostname: "*.example.com"
    tls:
      certificateRefs:
      - group: "" # основна група API
        kind: Secret
        name: wildcard-example-com-cert # SAN: *.example.com

Я налаштував шлюз із двома прослуховувачами, обидва з яких мають імена хостів, що перетинаються. Моя мета полягає в тому, щоб прослуховувач foo-http був доступний тільки для клієнтів, які мають сертифікат foo-example-com-cert. На відміну від цього, прослуховувач wildcard-https повинен дозволяти доступ ширшій аудиторії, яка використовує будь-який сертифікат, дійсний для домену *.example.com.

Розглянемо сценарій, в якому клієнт спочатку підключається до foo.example.com. Сервер запитує і успішно перевіряє сертифікат foo-example-com-cert, встановлюючи зʼєднання. Згодом той самий клієнт бажає отримати доступ до інших сайтів у цьому домені, таких як bar.example.com, який обробляється прослуховувачем wildcard-https. Завдяки повторному використанню зʼєднання клієнти можуть отримати доступ до бекендів wildcard-https без додаткового TLS-рукостискання на наявному зʼєднанні. Цей процес працює як очікується.

Однак критична вразливість безпеки виникає, коли порядок доступу змінюється на протилежний. Якщо клієнт спочатку підключається до bar.example.com і надає дійсний сертифікат bar.example.com, зʼєднання встановлюється успішно. Якщо потім цей клієнт намагається отримати доступ до foo.example.com, сертифікат клієнта наявного зʼєднання не буде повторно перевірено. Це дозволяє клієнту обійти конкретну вимогу щодо сертифіката для бекенду foo, що призводить до серйозного порушення безпеки.

Рішення: конфігурація TLS для кожного порту

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

Ось погляд на оновлені визначення API (показані як вихідний код Go):

// GatewaySpec визначає бажаний стан Gateway.
type GatewaySpec struct {
    ...
    // GatewayTLSConfig визначає конфігурацію TLS для шлюзу.
    TLS *GatewayTLSConfig `json:"tls,omitempty"`
}

// GatewayTLSConfig визначає конфігурацію TLS для шлюзу.
type GatewayTLSConfig struct {
    // Default визначає типову конфігурацію перевірки сертифіката клієнта
    Default TLSConfig `json:"default"`

    // PerPort визначає конфігурацію TLS, призначену для кожного порту.
    PerPort []TLSPortConfig `json:"perPort,omitempty"`
}

// TLSPortConfig описує конфігурацію TLS для конкретного порту.
type TLSPortConfig struct {
    // Port вказує номер порту, до якого буде застосовано конфігурацію TLS.
    Port PortNumber `json:"port"`

    // TLS зберігає конфігурацію, яка буде застосована до всіх прослуховувачів, що обробляють
    // HTTPS-трафік і відповідають заданому порту.
    TLS TLSConfig `json:"tls"`
}

Несумісні зміни

Standard GRPCRoute - поле `.spec` обовʼязкове (технічний аспект)

Переведення GRPCRoute до статусу Standard вносить незначну, але формально несумісну зміну щодо наявності поля верхнього рівня .spec. В рамках досягнення статусу Standard, Gateway API посилив перевірку схеми OpenAPI в GRPCRoute CustomResourceDefinition (CRD), щоб чітко забезпечити необхідність поля spec для всіх ресурсів GRPCRoute. Ця зміна забезпечує більш суворе дотримання стандартів обʼєктів Kubernetes та підвищує стабільність і передбачуваність ресурсу. Хоча дуже малоймовірно, що користувачі намагалися визначити GRPCRoute без будь-яких специфікацій, будь-які наявні автоматизації або маніфести, які могли покладатися на вільну інтерпретацію, що дозволяла повну відсутність поля spec, тепер не пройдуть перевірку і повинні бути оновлені, щоб включити поле .spec, навіть якщо воно порожнє.

Експериментальна підтримка CORS в HTTPRoute — несумісна зміна для поля `allowCredentials`

В рамках підпроєкту Gateway API було внесено несумісну зміну до експериментальної підтримки CORS в HTTPRoute, що стосуються поля allowCredentials в політиці CORS. Визначення цього поля було приведене у повну відповідність до специфікації CORS, яка вимагає, щоб відповідний заголовок Access-Control-Allow-Credentials мав булеве значення. Раніше реалізація могла бути надто дозвільною, потенційно приймаючи нестандартні або рядкові представлення, такі як true, через послаблення перевірки схеми. Користувачі, які налаштовували правила CORS, тепер повинні переглянути свої маніфести та переконатися, що значення allowCredentials суворо відповідає новій, більш обмежувальній схемі. Будь-які наявні визначення HTTPRoute, які не відповідають цій більш суворій перевірці, тепер будуть відхилені API-сервером, що вимагатиме оновлення конфігурації для збереження функціональності.

Поліпшення досвіду розробки та використання

В рамках цього випуску ми вдосконалили деякі робочі процеси для розробників:

Додано Kube API Linter до конвеєрів CI/CD, що зменшує навантаження на рецензентів API, а також зменшує кількість типових помилок.
Покращено час виконання тестів CRD за допомогою envtest.

Крім того, в рамках зусиль, спрямованих на поліпшення досвіду використання Gateway API, було зроблено деякі кроки для усунення неоднозначностей та старих технічних боргів з нашого вебсайту з документацією:

Тепер у довідці API чітко вказано, коли поле є experimental.
Навігаційна панель GEP (GatewayAPI Enhancement Proposal) генерується автоматично, показуючи реальний стан вдосконалень.

Спробуйте

На відміну від інших API Kubernetes, вам не потрібно оновлюватися до останньої версії Kubernetes, щоб отримати останню версію Gateway API. Якщо ви використовуєте Kubernetes 1.26 або новішу версію, ви зможете швидко розпочати роботу з цією версією Gateway API.

Щоб спробувати API, дотримуйтесь Посібника для початківців.

На момент написання цієї статті сім реалізацій вже відповідають Gateway API v1.4.0. В алфавітному порядку:

Долучайтеся

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

Ознайомтеся з посібниками для користувачів, щоб дізнатися, які випадки використання можна вирішити.
Спробуйте один з наявних контролерів Gateway.
Або долучайтеся до нашої спільноти та допоможіть нам разом створити майбутнє Gateway API!

Супровідники хотіли б подякувати усім, хто долучився до Gateway API, чи то через коміти в репозиторії, обговорення, ідеї чи загальну підтримку. Ми ніколи не змогли б досягти такого прогресу без підтримки цієї відданої та активної спільноти.

Gateway API v1.3.0: Advancements in Request Mirroring, CORS, Gateway Merging, and Retry Budgets (червень 2025)
Gateway API v1.2: WebSockets, Timeouts, Retries, and More (листопад 2024)
Gateway API v1.1: Service mesh, GRPCRoute, and a whole lot more (травень 2024)
New Experimental Features in Gateway API v1.0 (листопад 2023)
Gateway API v1.0: GA Release (жовтень 2023)

Chihiro — одна з персон Gateway API, що уособлює оператора кластера, див. https://gateway-api.sigs.k8s.io/docs/concepts/roles-and-personas/#key-roles-and-personas ↩︎

7 типових помилок Kubernetes (і як я навчився їх уникати)

Mon, 20 Oct 2025 08:30:00 -0700

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

1. Оминання запитів на ресурси та обмежень

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

Контекст: У Kubernetes запити та обмеження ресурсів є критично важливими для ефективного керування кластерами. Запити ресурсів гарантують, що планувальник зарезервує відповідну кількість CPU та памʼяті для кожного Podʼа, гарантуючи, що він має необхідні ресурси для роботи. Обмеження ресурсів обмежують кількість CPU та памʼяті, яку може використовувати Pod, запобігаючи тому, щоб жоден окремий Pod не споживав надмірні ресурси та потенційно не позбавляв ресурсів інші Podʼи. Коли запити та обмеження ресурсів не встановлені:

Нестача ресурсів: Podʼи можуть отримувати недостатньо ресурсів, що призводить до зниження продуктивності або збоїв. Це відбувається тому, що Kubernetes планує Podʼи на основі цих запитів. Без них планувальник може розмістити занадто багато Podʼів на одному вузлі, що призводить до конкуренції за ресурси та вузьких місць у продуктивності.
Привласнення ресурсів: З іншого боку, без обмежень Pod може споживати більше, ніж йому належить, впливаючи на продуктивність і стабільність інших Podʼів на тому ж вузлі. Це може призвести до таких проблем, як виселення або знищення інших Podʼів за допомогою Out-Of-Memory (OOM) killer через брак доступної памʼяті.

Як уникнути цього:

Почніть з помірних requests (наприклад, 100m CPU, 128Mi памʼяті) і подивіться, як ваш застосунок поводиться.
Моніторте реальне використання та уточнюйте свої значення; HorizontalPodAutoscaler може допомогти автоматизувати масштабування на основі метрик.
Слідкуйте за kubectl top pods або вашим інструментом логування/моніторингу, щоб переконатися, що ви не виділяєте забагато чи замало ресурсів.

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

2. Недооцінка проб життєздатності та готовності

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

Контекст: Проби життєздатності, готовності та запуску — це механізми, які Kubernetes використовує для моніторингу стану контейнерів та їх доступності.

Liveness probes визначають, чи все ще працює застосунок. Якщо проба життєздатності не проходить, контейнер перезапускається.
Readiness probes контролюють, чи готовий контейнер обслуговувати трафік. Поки проба готовності не пройде, контейнер видаляється з точок доступу Service.
Startup probes допомагають відрізнити тривалі часи запуску від фактичних збоїв.

Як уникнути цього:

Додайте просту HTTP livenessProbe, щоб перевірити точку доступу справності (наприклад, /healthz), щоб Kubernetes міг перезапустити контейнер, якщо він перестане відповідати.
Використовуйте readinessProbe, щоб трафік не потрапляв до вашого застосунку, поки той не прогріється.
Робіть проби простими. Надто складні перевірки можуть створити хибні сповіщення та непотрібні перезапуски.

Перевірка життям: Одного разу я забув про пробу готовності для вебсервісу, який потребував деякого часу для завантаження. Користувачі зверталися до нього передчасно, отримували дивні тайм-аути, і я витратив години на роздуми. Проба готовності на три рядки врятувала б ситуацію.

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

3. «Ми просто переглянемо логи контейнерів» (відомі останні слова)

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

Як уникнути цього:

Централізуйте логи за допомогою інструментів CNCF, таких як Fluentd або Fluent Bit, щоб агрегувати вихідні дані з усіх Podʼів.
Використовуйте OpenTelemetry для уніфікованого перегляду логів, метрик і (за потреби) трейсів. Це дозволяє виявляти кореляції між подіями інфраструктури та поведінкою на рівні застосунків.
Поєднуйте логи з метриками Prometheus, щоб відстежувати дані на рівні кластера разом із логами застосунків. Якщо вам потрібне розподілене трасування, розгляньте проєкти CNCF, такі як Jaeger.

Перевірка життям: Коли я вперше втратив логи Podʼа через швидкий перезапуск, я зрозумів, наскільки ненадійним може бути «kubectl logs» сам по собі. З того часу я налаштував належний конвеєр для кожного кластера, щоб уникнути втрати важливих підказок.

4. Однакове ставлення до середовищ розробки та промислової експлуатації

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

Як уникнути цього:

Використовуйте оверлеї або kustomize, щоб підтримувати спільну базу, налаштовуючи запити ресурсів, репліки або конфігурацію для кожного середовища.
Витягніть специфічну для середовища конфігурацію в ConfigMap і / або Secret. Ви можете використовувати спеціалізований інструмент, такий як Sealed Secrets, для керування конфіденційними даними.
Плануйте масштабування в промисловому середовищі. Ваш кластер розробки, ймовірно, може обійтися мінімальними ресурсами CPU/памʼяті, але промислове середовище може потребувати значно більше.

Перевірка життям: Одного разу я збільшив replicaCount з 2 до 10 у невеликому середовищі розробки, просто щоб «перевірити». Я швидко вичерпав ресурси і півдня витратив на подолання наслідків. Ой.

5. Коли старі речі залишаються на місці

Пастка: У кластері залишаються невикористані або застарілі ресурси, такі як Deployment, Service, ConfigMap або PersistentVolumeClaim. Це часто відбувається тому, що Kubernetes не видаляє ресурси автоматично, якщо не вказано явно, і немає вбудованого механізму для відстеження приналежності або терміну придатності. З часом ці забуті обʼєкти можуть накопичуватися, споживаючи ресурси кластера, збільшуючи витрати на хостинг у хмарі та створюючи операційну плутанину, особливо коли застарілі Service або LoadBalancer продовжують маршрутизувати трафік.

Як уникнути цього:

Позначте все мітками з метою або власником. Таким чином, ви зможете легко знайти ресурси, які вам більше не потрібні.
Регулярно перевіряйте свій кластер: запустіть kubectl get all -n <namespace>, щоб побачити, що насправді працює, і підтвердити, що все це так має бути.
Використовуйте збір сміття в Kubernetes: документація K8s показує, як автоматично видаляти залежні обʼєкти.
Використовуйте автоматизацію політики: Інструменти, такі як Kyverno, можуть автоматично видаляти або блокувати застарілі ресурси після певного періоду, або впроваджувати політики життєвого циклу, щоб вам не доводилося памʼятати про кожен окремий крок очищення.

Перевірка життям: Після хакатону я забув знести «test-svc», привʼязаний до зовнішнього балансувальника навантаження. Три тижні потому я зрозумів, що платив за цей балансувальник навантаження весь цей час. Facepalm.

6. Занадто глибоке занурення в мережу занадто рано

Пастка: Впровадження розширених мережевих рішень, таких як service mesh, власні втулки CNI або міжкластерна комунікація, до повного розуміння нативних мережевих примітивів Kubernetes. Це часто трапляється, коли команди реалізують такі можливості, як маршрутизація трафіку, спостережуваність або mTLS, використовуючи зовнішні інструменти, не освоївши спочатку, як працює основна мережа Kubernetes: включаючи комунікацію Pod-to-Pod, Service типу ClusterIP, DNS-резолюцію та базову обробку вхідного трафіку. В результаті проблеми, повʼязані з мережею, стають важчими для усунення, особливо коли оверлеї вводять додаткові абстракції та точки відмови.

Як уникнути цього:

Почніть з малого: Deployment, Service та базовий контролер Ingress, наприклад, на основі NGINX (наприклад, Ingress-NGINX).
Переконайтеся, що ви розумієте, як трафік проходить у кластері, як працює виявлення сервісів і як налаштована DNS.
Переходьте до повноцінного service mesh або розширених можливостей CNI лише тоді, коли це дійсно необхідно, оскільки складна мережа додає накладні витрати.

Перевірка життям: Я спробував Istio на невеликому внутрішньому застосунку, а потім витратив більше часу на налагодження самого Istio, ніж на сам застосунок. Врешті-решт, я відступив, видалив Istio, і все запрацювало нормально.

7. Занадто легковажне ставлення до безпеки та RBAC

Пастка: Розгортання робочих навантажень з ненадійними конфігураціями, такими як запуск контейнерів від імені користувача root, використання теґу образів latest, відключення контекстів безпеки або призначення надто широких ролей RBAC, таких як cluster-admin. Ці практики зберігаються, оскільки Kubernetes не забезпечує суворих типових налаштувань безпеки, а платформа розроблена для гнучкості, а не для жорстких обмежень. Без явних політик безпеки кластери можуть залишатися вразливими до ризиків, таких як втеча контейнерів, несанкціоноване підвищення привілеїв або випадкові зміни в промисловому середовищі через незафіксовані образи.

Як уникнути цього:

Використовуйте RBAC для визначення ролей і дозволів у Kubernetes. Хоча RBAC є типовим і найширше підтримуваним механізмом авторизації, Kubernetes також дозволяє використовувати альтернативні авторизатори. Для більш складних або зовнішніх потреб у політиці розгляньте рішення, такі як OPA Gatekeeper (на основі Rego), Kyverno або власні вебхуки з використанням мов політики, таких як CEL або Cedar.
Привʼяжіть образи до конкретних версій (більше ніякого :latest!). Це допоможе вам знати, що насправді розгорнуто.
Розгляньте Pod Security Admission (або інші рішення, такі як Kyverno), щоб забезпечити використання контейнерів без прав root, файлових систем лише для читання тощо.

Перевірка життям: Я ніколи не стикався з серйозними порушеннями безпеки, але чув безліч застережливих історій. Якщо не посилити заходи безпеки, то це лише питання часу, коли щось піде не так.

І на останок

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

Вдалих розгортань!

Kubernetes v1.34: Перехід Volume Group Snapshots на v1beta2

Tue, 16 Sep 2025 10:30:00 -0800

Volume group snapshots було представлено як альфа-можливість у випуску Kubernetes 1.27, а у випуску Kubernetes 1.32 вони перейшли в Beta. Останній випуск Kubernetes v1.34 переніс цю підтримку на другий бета-етап. Підтримка знімків групи томів спирається на набір додаткових API для групових знімків. Ці API дозволяють користувачам робити знімки набору томів, узгоджені на момент збою. За лаштунками Kubernetes використовує селектор міток для групування кількох PersistentVolumeClaims для знімків. Основна мета полягає в тому, щоб дозволити вам відновити цей набір знімків на нові томи та відновити ваше робоче навантаження на основі точки відновлення, узгодженої на момент збою.

Ця нова можливість підтримується лише для CSI драйверів томів.

Що нового в Beta 2?

Під час тестування бета-версії ми зіткнулися з проблемою, коли поле restoreSize не встановлюється для окремих VolumeSnapshotContents і VolumeSnapshots, якщо драйвер CSI не реалізує виклик RPC ListSnapshots. Ми оцінили різні варіанти тут і вирішили внести цю зміну, випустивши нову бета-версію для API.

Конкретно, у v1beta2 додано структуру VolumeSnapshotInfo, яка містить інформацію про окремий знімок тома, що є членом знімка групи томів. VolumeSnapshotInfoList, список VolumeSnapshotInfo, додано до VolumeGroupSnapshotContentStatus, замінюючи VolumeSnapshotHandlePairList. VolumeSnapshotInfoList — це список інформації про знімки, повернутий драйвером CSI для ідентифікації знімків у системі зберігання. VolumeSnapshotInfoList заповнюється sidecar-контейнером csi-snapshotter на основі відповіді CSI CreateVolumeGroupSnapshotResponse, поверненої викликом CreateVolumeGroupSnapshot драйвера CSI.

Наявні обʼєкти API v1beta1 будуть перетворені на нові обʼєкти API v1beta2 за допомогою вебхука перетворення.

Що далі?

Залежно від відгуків та впровадження, проєкт Kubernetes планує перенести реалізацію знімків групи томів у загальну доступність (GA) у майбутньому випуску.

Як дізнатися більше?

Дизайн-специфікація для можливості знімків групи томів.
Репозиторій коду для API знімків групи томів та контролера.
CSI документація про можливість знімків групи.

Як взяти участь?

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

Ben Swartzlander (bswartz)
Hemant Kumar (gnufied)
Jan Šafránek (jsafrane)
Madhu Rajanna (Madhu-1)
Michelle Au (msau42)
Niels de Vos (nixpanic)
Leonardo Cecchi (leonardoce)
Saad Ali (saad-ali)
Xing Yang (xing-yang)
Yati Padia (yati1998)

Якщо ви зацікавлені взяти участь у проєктуванні та розробці CSI або будь-якої частини системи зберігання Kubernetes, приєднуйтесь до Kubernetes Storage Special Interest Group (SIG). Ми завжди раді новим учасникам.

Ми також проводимо регулярні зустрічі Data Protection Working Group. Нові учасники завжди можуть приєднатися до наших обговорень.

Kubernetes v1.34: Автоматичне налаштування драйвера cgroup вузла переходить у GA

Fri, 12 Sep 2025 10:30:00 -0800

Історично, налаштування правильного драйвера cgroup було болючою точкою для користувачів, які запускали нові кластери Kubernetes. У системах Linux існують два різні драйвери cgroup: cgroupfs і systemd. У минулому як kubelet, так і реалізація CRI (така як CRI-O або containerd) повинні були бути налаштовані на використання одного й того ж драйвера cgroup, інакше kubelet поводився б неправильно без жодного явного повідомлення про помилку. Це було джерелом головного болю для багатьох адміністраторів кластерів. Тепер ми (майже) поклали край цьому головному болю.

Автоматичне виявлення драйвера cgroup

У v1.28.0 спільнота SIG Node представила функціональну можливість KubeletCgroupDriverFromCRI, яка вказує kubelet запитувати у реалізації CRI, який драйвер cgroup використовувати. Ви можете прочитати більше тут. Після багатьох випусків очікування, поки кожна реалізація CRI випустить основні версії та упакує їх у основні операційні системи, ця можливість стала загальнодоступною (GA) з Kubernetes 1.34.0.

На додачу до налаштування функціональної можливості, адміністратори кластерів повинні переконатися, що їх реалізації CRI є достатньо новими:

containerd: Підтримка була додана в v2.0.0
CRI-O: Підтримка була додана в v1.28.0

Оголошення: Kubernetes припиняє підтримку containerd v1.y

Хоча CRI-O випускає версії, які відповідають версіям Kubernetes, і, отже, версії CRI-O без цієї поведінки більше не підтримуються, containerd підтримує свій власний цикл випуску. Підтримка цієї можливості в containerd доступна лише в v2.0 і пізніших версіях, але Kubernetes 1.34 все ще підтримує containerd 1.7 та інші LTS-випуски containerd.

Спільнота Kubernetes SIG Node формально погодилася на остаточний графік підтримки для containerd v1.y. Останній випуск Kubernetes, який запропонує цю підтримку, буде останньою випущеною версією v1.35, а підтримка буде припинена у v1.36.0. Щоб допомогти адміністраторам з майбутнім переходом, доступний новий механізм виявлення. Ви можете моніторити метрику kubelet_cri_losing_support, щоб визначити, чи використовують будь-які вузли у вашому кластері версію containerd, яка незабаром стане застарілою. Наявність цієї метрики з міткою версії 1.36.0 вказуватиме на те, що середовище виконання containerd на вузлі недостатньо нове для майбутніх вимог. Відповідно, адміністратору потрібно буде оновити containerd до v2.0 або пізнішої версії до або одночасно з оновленням kubelet до v1.36.0.

Kubernetes v1.34: Mutable CSI Node Allocatable переходить у бета

Thu, 11 Sep 2025 10:30:00 -0800

Можливість драйверів CSI оновлювати інформацію про кількість томів, які можна підключити на вузлах, вперше представлена в альфа-версії Kubernetes v1.33, перейшла в бета-версію у випуску Kubernetes v1.34! Це є важливою віхою у підвищенні точності планування Podʼів зі станом шляхом зменшення кількості збоїв, спричинених застарілою інформацією про кількість томів, які можна підключити.

Background

Традиційно драйвери CSI Kubernetes повідомляють про статичний максимальний ліміт підключення томів під час ініціалізації. Однак фактичні ємності підключення можуть змінюватися протягом життєвого циклу вузла з різних причин, таких як:

Ручні або зовнішні операції з підключення/відключення томів поза контролем Kubernetes.
Динамічно підключені мережеві інтерфейси або спеціалізоване обладнання (GPU, NIC тощо), що споживає доступні слоти.
Сценарії з кількома драйверами, коли операції одного драйвера CSI впливають на доступну ємність, про яку повідомляє інший.

Статичне звітування може призвести до того, що Kubernetes запланує Podʼи на вузли, які, здається, мають ємність, але насправді не мають, що призводить до зависання Podʼів у стані ContainerCreating.

Динамічна адаптація лімітів томів CSI

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

Як це працює

Kubernetes підтримує два механізми для оновлення інформації про ліміти томів вузлів:

Періодичні оновлення: Драйвери CSI вказують інтервал для періодичного оновлення доступної для розподілу ємності вузла.
Реактивні оновлення: Негайне оновлення, яке викликається, коли операція підключення тому не вдається через вичерпані ресурси (помилка ResourceExhausted).

Увімкнення можливості

Щоб використовувати цю бета-можливість, необхідно увімкнути функціональну можливість MutableCSINodeAllocatableCount у таких компонентах:

kube-apiserver
kubelet

Приклад конфігурації драйвера CSI

Нижче наведено приклад конфігурації драйвера CSI для увімкнення періодичних оновлень кожні 60 секунд:

apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: example.csi.k8s.io
spec:
  nodeAllocatableUpdatePeriodSeconds: 60

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

Негайні оновлення у разі збоїв підключення

Коли операція підключення тому не вдається через помилку ResourceExhausted (код gRPC 8), Kubernetes негайно оновлює доступну для розподілу кількість томів замість того, щоб чекати наступного періодичного оновлення. Потім kubelet позначає відповідні Podʼи як Failed, що дає змогу їхнім контролерам створити їх знову. Це запобігає тому, щоб Podʼи назавжди застрягали в стані ContainerCreating.

Як почати використовувати

Щоб увімкнути цю можливість у вашому кластері Kubernetes v1.34:

Увімкніть функціональну можливість MutableCSINodeAllocatableCount в компонентах kube-apiserver та kubelet.
Оновіть конфігурацію вашого драйвера CSI, встановивши nodeAllocatableUpdatePeriodSeconds.
Моніторте та спостерігайте за покращеннями в точності планування та надійності розміщення Podʼів.

Наступні кроки

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

Приєднуйтесь до обговорень у Kubernetes Storage Special Interest Group (SIG-Storage), щоб сформувати майбутнє можливостей зберігання Kubernetes.

Kubernetes v1.34: VolumeAttributesClass для зміни атрибутів томів тепер GA

Mon, 08 Sep 2025 10:30:00 -0800

API VolumeAttributesClass, який надає можливість користувачам динамічно змінювати атрибути томів, офіційно перейшов у стадію загальної доступності (GA) у Kubernetes v1.34. Це важлива віха, яка забезпечує надійний і стабільний спосіб налаштування вашого постійного сховища безпосередньо в Kubernetes.

Що таке VolumeAttributesClass?

По суті, VolumeAttributesClass — це ресурс рівня кластера, який визначає набір змінних параметрів для тому. Розглядайте це як "профіль" для вашого сховища, що дозволяє адміністраторам кластерів надавати різні рівні якості обслуговування (QoS) або продуктивності.

Користувачі можуть вказати volumeAttributesClassName у своїх PersistentVolumeClaim (PVC), щоб вказати, який клас атрибутів вони бажають. Уся магія відбувається через Container Storage Interface (CSI): коли PVC, що посилається на VolumeAttributesClass, оновлюється, відповідний драйвер CSI взаємодіє з базовою системою зберігання, щоб застосувати вказані зміни до тому.

Це означає, що ви тепер можете:

Динамічно масштабувати продуктивність: збільшити IOPS або пропускну здатність для завантаженої бази даних або зменшити її для менш критичного застосунку.
Оптимізувати витрати: налаштовувати атрибути на льоту, щоб відповідати вашим поточним потребам, уникаючи надлишкового виділення ресурсів.
Спростити операції: керувати змінами томів безпосередньо в API Kubernetes, а не покладатися на зовнішні інструменти або ручні процеси.

Що нового в GA порівняно з бета

Є два основних вдосконалення порівняно з бета.

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

Щоб покращити стійкість і зручність використання, випуск GA вводить явну підтримку скасування, коли під час запиту на зміну тома виникає помилка. Якщо базова система зберігання або драйвер CSI вказує, що запитувані зміни не можуть бути застосовані (наприклад, через недійсні аргументи), користувачі можуть скасувати операцію і повернути том до його попередньої стабільної конфігурації, щоб том не залишився в неузгодженому стані.

Підтримка квот на основі області дії

Хоча VolumeAttributesClass не додає нового типу квот, панель управління Kubernetes може бути налаштована для примусового дотримання квот на PersistentVolumeClaim, які посилаються на конкретний VolumeAttributesClass.

Це досягається за допомогою поля scopeSelector в ResourceQuota для націлювання на PVC, які мають .spec.volumeAttributesClassName, встановлене на конкретне імʼя VolumeAttributesClass. Докладніше див. тут.

Підтримка драйверами VolumeAttributesClass

Драйвер Amazon EBS CSI: Драйвер AWS EBS CSI має надійну підтримку VolumeAttributesClass і дозволяє динамічно змінювати такі параметри, як тип тому (наприклад, gp2 на gp3, io1 на io2), IOPS і пропускну здатність томів EBS.
Драйвер Google Compute Engine (GCE) Persistent Disk CSI (pd.csi.storage.gke.io): цей драйвер також підтримує динамічну зміну атрибутів постійного диска, включаючи IOPS і пропускну здатність, за допомогою VolumeAttributesClass.

Контакти

Якщо у вас є запитання або конкретні запити, повʼязані з VolumeAttributesClass, звертайтеся до спільноти SIG Storage.

Kubernetes v1.34: Метрики PSI для Kubernetes переходять у бета-версію

Thu, 04 Sep 2025 10:30:00 -0800

У міру зростання розміру та складності кластерів Kubernetes розуміння стану та продуктивності окремих вузлів стає все більш важливим. Ми раді оголосити, що з Kubernetes v1.34 Метрики інформації про затримки (PSI) перейшли в бета-версію.

Що таке інформація про затримки (PSI)?

Pressure Stall Information (PSI) є функцією ядра Linux (версія 4.20 і новіші), яка забезпечує канонічний спосіб кількісно оцінити тиск на інфраструктурні ресурси з точки зору того, чи перевищує попит на ресурс поточну пропозицію. Вона виходить за межі простих метрик використання ресурсів і натомість вимірює кількість часу, протягом якого завдання затримуються через конкуренцію за ресурси. Це потужний спосіб виявлення та діагностування вузьких місць у ресурсах, які можуть вплинути на продуктивність застосунків.

PSI надає метрики для CPU, памʼяті та I/O, які класифікуються як тиск some або full:

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

PSI: Тиск 'Some' та 'Full'

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

Метрики PSI в Kubernetes

З увімкненою функціональною можливістю KubeletPSI, kubelet тепер може збирати метрики PSI з ядра Linux і надавати їх через два канали: Summary API та точку доступу /metrics/cadvisor Prometheus. Це дозволяє вам відстежувати та отримувати сповіщення про тиск на ресурси на рівні вузла, Podʼа та контейнера.

Такі нові метрики доступні у форматі експозиції Prometheus через /metrics/cadvisor:

container_pressure_cpu_stalled_seconds_total
container_pressure_cpu_waiting_seconds_total
container_pressure_memory_stalled_seconds_total
container_pressure_memory_waiting_seconds_total
container_pressure_io_stalled_seconds_total
container_pressure_io_waiting_seconds_total

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

Виявлення витоків памʼяті: Постійно зростаючий тиск some для памʼяті може вказувати на витік памʼяті в застосунку.
Оптимізація запитів та обмежень ресурсів: Розуміючи тиск на ресурси ваших робочих навантажень, ви можете точніше налаштувати їх запити та обмеження ресурсів.
Автоматичне масштабування робочих навантажень: Ви можете використовувати метрики PSI для ініціювання подій автоматичного масштабування, забезпечуючи, щоб ваші робочі навантаження мали ресурси, необхідні для оптимальної роботи.

Як увімкнути метрики PSI

Щоб увімкнути метрики PSI у вашому кластері Kubernetes, вам потрібно:

Переконатися, що ваші вузли працюють на версії ядра Linux 4.20 або новішій та використовують cgroup v2.
Увімкнути функціональну можливість KubeletPSI у kubelet.

Після увімкнення ви можете почати збирати дані з точки доступу /metrics/cadvisor за допомогою вашого рішення для моніторингу, сумісного з Prometheus, або запитувати Summary API для збору та візуалізації нових метрик PSI. Зверніть увагу, що PSI є функцією ядра Linux, тому ці метрики недоступні на вузлах Windows. Ваш кластер може містити комбінацію вузлів Linux та Windows, але на вузлах Windows kubelet не надає метрики PSI.

Що далі?

Ми раді представити метрики PSI спільноті Kubernetes і чекаємо на ваші відгуки. Оскільки це бета-можливість, ми активно працюємо над поліпшенням і розширенням цієї функціональності до стабільного випуску GA. Ми закликаємо вас спробувати її та поділитися своїм досвідом з нами.

Щоб дізнатися більше про метрики PSI, ознайомтеся з офіційною документацією Kubernetes. Ви також можете долучитися до обговорення на каналі #sig-node в Slack.

Kubernetes v1.34: Of Wind & Will (O' WaW)

Wed, 27 Aug 2025 10:30:00 -0800

Редактори: Agustina Barbetta, Alejandro Josue Leon Bellido, Graziano Casto, Melony Qin, Dipesh Rawat

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

Цей випуск складається з 58 удосконалень. З них 23 перейшли до стабільного стану, 22 перейшли до бета-версії, а 13 — до альфа-версії.

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

Тема та логотип випуску

Випуск, що рухається силою вітру навколо нас — і волею всередині нас.

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

Те, що тримає Kubernetes в русі, — не ідеальні вітри, а воля наших моряків, які регулюють вітрила, тримають штурвал, прокладають курси і втримують корабель на рівному кілі. Випуск відбувається не тому, що умови завжди ідеальні, а завдяки людям, які його створюють, людям, які його випускають, і ведмедям^{^}, котам, собакам, чарівникам і допитливим умам, завдяки яким Kubernetes впевнено тримає курс — незалежно від того, в якому напрямку дме вітер.

Цей випуск, Of Wind & Will (O' WaW), вшановує вітри, які сформували нас, і волю, яка рухає нас уперед.

_{^ О, і ви здивовані, чому ведмеді? Продовжуйте дивуватися!}

Основні оновлення

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

Stable: Ядро DRA тепер GA

Динамічне виділення ресурсів (DRA) надає потужніші способи вибору, виділення, спільного використання та налаштування GPU, TPU, мережевих карт (NIC) та інших пристроїв.

Починаючи з випуску v1.30, DRA базується на заявках на пристрої за допомогою структурованих параметрів, які є непрозорими для ядра Kubernetes. Це удосконалення було натхненне динамічним наданням томів сховища. DRA зі структурованими параметрами спирається на набір допоміжних видів API: типи API ResourceClaim, DeviceClass, ResourceClaimTemplate та ResourceSlice у resource.k8s.io, водночас розширюючи .spec для Podʼів новим полем resourceClaims.
API resource.k8s.io/v1 стали стабільними і тепер є типово доступними.

Ця робота була виконана в рамках KEP #4381 під керівництвом WG Device Management.

Beta: Спроєцьовані токени ServiceAccount для провайдерів облікових даних образів `kubelet`

Провайдери облікових даних kubelet, які використовуються для отримання приватних образів контейнерів, традиційно покладалися на довгострокові Secrets, збережені на вузлі або в кластері. Такий підхід збільшував ризики безпеки та накладні витрати на управління, оскільки ці облікові дані не були привʼязані до конкретного робочого навантаження і не ротувалися автоматично.
Щоб вирішити цю проблему, kubelet тепер може запитувати короткочасні, привʼязані до певної аудиторії токени ServiceAccount для автентифікації в реєстрах контейнерів. Це дозволяє авторизувати отримання образів на основі власної ідентичності Podʼа, а не облікових даних на рівні вузла.
Основна перевага полягає в значному поліпшенні безпеки. Це усуває необхідність у довгострокових Secrets для отримання образів, зменшуючи поверхню атаки та спрощуючи управління обліковими даними як для адміністраторів, так і для розробників.

Ця робота була виконана в рамках KEP #4412 під керівництвом SIG Auth та SIG Node.

Alpha: Підтримка KYAML, діалекту YAML для Kubernetes

KYAML покликаний бути безпечнішою та менш неоднозначною підмножиною YAML і був розроблений спеціально для Kubernetes. Незалежно від версії Kubernetes, яку ви використовуєте, починаючи з Kubernetes v1.34 ви можете використовувати KYAML як новий формат виводу для kubectl.

KYAML вирішує специфічні проблеми як YAML, так і JSON. Значущі пробіли в YAML вимагають пильної уваги до відступів та вкладеності, тоді як необовʼязкове взяття рядків у лапки може призвести до неочікуваного приведення типів (наприклад: "The Norway Bug"). Тим часом JSON не підтримує коментарі та має суворі вимоги щодо кінцевих ком і ключів у лапках.

Ви можете писати KYAML та передавати його як вхідні дані будь-якій версії kubectl, оскільки всі файли KYAML також є дійсними YAML. З kubectl v1.34 ви також можете запитувати вивід у форматі KYAML (як у kubectl get -o kyaml …), встановивши змінну середовища KUBECTL_KYAML=true. Якщо бажаєте, ви все ще можете запитувати вивід у форматі JSON або YAML.

Ця робота була виконана в рамках KEP #5295 під керівництвом SIG CLI.

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

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

Відкладене створення замінних Podʼів для Job

Типово контролери Job створюють замінні Podʼи негайно, коли Pod починає завершувати свою роботу, що призводить до одночасного виконання обох Podʼів. Це може спричинити конкуренцію за ресурси в обмежених кластерах, де замінний Pod може зіткнутися з труднощами при пошуку доступних вузлів, поки оригінальний Pod повністю не завершиться. Ситуація також може спровокувати небажане збільшення кластера автомасштабувальником кластера. Крім того, деякі фреймворки машинного навчання, такі як TensorFlow та JAX, вимагають, щоб для кожного індексу одночасно працював лише один Pod, що робить одночасне виконання Podʼів проблематичним. Ця функція вводить .spec.podReplacementPolicy у Jobs. Ви можете вибрати створення замінних Podʼів лише тоді, коли Pod повністю завершено (має .status.phase: Failed). Для цього встановіть .spec.podReplacementPolicy: Failed.
Представлена як альфа у v1.28, ця функція стала стабільною у v1.34.

Ця робота була виконана в рамках KEP #3939 під керівництвом SIG Apps.

Відновлення після збою розширення тому

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

Ця робота була виконана в рамках KEP #1790 під керівництвом SIG Storage.

VolumeAttributesClass для зміни томів

VolumeAttributesClass став стабільним у v1.34. VolumeAttributesClass — це загальний, рідний для Kubernetes API для зміни параметрів тому, таких як виділений IO. Він дозволяє робочим навантаженням вертикально масштабувати свої томи онлайн для балансування вартості та продуктивності, якщо це підтримується їхнім провайдером.
Як і всі нові функції томів у Kubernetes, цей API реалізується через інтерфейс зберігання контейнерів (CSI). Ваш CSI-драйвер, специфічний для провізіонера, повинен підтримувати новий API ModifyVolume, який є стороною CSI цієї функції.

Ця робота була виконана в рамках KEP #3751 під керівництвом SIG Storage.

Структурована конфігурація автентифікації

Kubernetes v1.29 представив формат файлу конфігурації для управління автентифікацією клієнтів API-сервера, відмовившись від попередньої залежності від великої кількості параметрів командного рядка. Вид AuthenticationConfiguration дозволяє адміністраторам підтримувати кілька автентифікаторів JWT, перевірку виразів CEL та динамічне перезавантаження. Ця зміна суттєво покращує керованість та можливість аудиту налаштувань автентифікації кластера, і стала стабільною у v1.34.

Ця робота була виконана в рамках KEP #3331 під керівництвом SIG Auth.

Більш детальна авторизація на основі селекторів

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

Наприклад, ви можете написати політику авторизації, яка дозволяє лише отримання переліку Podʼів, привʼязаних до конкретного .spec.nodeName. Клієнт (можливо, kubelet на певному вузлі) повинен вказати селектор поля, який вимагає політика, інакше запит буде заборонено. Ця зміна робить можливим налаштування правил найменших привілеїв за умови, що клієнт знає, як відповідати встановленим вами обмеженням. Kubernetes v1.34 тепер підтримує більш детальний контроль у таких середовищах, як ізоляція на рівні вузлів або спеціальні багатокористувацькі налаштування.

Ця робота була виконана в рамках KEP #4601 під керівництвом SIG Auth.

Обмеження анонімних запитів за допомогою детальних налаштувань контролю

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

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

Ця робота була виконана в рамках KEP #4633 під керівництвом SIG Auth.

Більш ефективне повторне додавання в чергу за допомогою зворотних викликів, специфічних для відповідних втулків

kube-scheduler тепер може приймати більш точні рішення про те, коли повторно намагатися запланувати Podʼи, які раніше не вдалося запланувати. Кожен втулок планування тепер може реєструвати функції зворотного виклику, які повідомляють планувальнику, чи ймовірно, що вхідна подія кластера знову зробить відхилений Pod придатним для планування.

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

Ця робота була виконана в рамках KEP #4247 під керівництвом SIG Scheduling.

Впорядковане видалення Namespace

Напіввипадковий порядок видалення ресурсів може створювати прогалини в безпеці або непередбачувану поведінку, таку як збереження Podʼів після видалення повʼязаних з ними NetworkPolicies.
Це покращення впроваджує більш структурований процес видалення для просторів імен Kubernetes, щоб забезпечити безпечне та детерміноване видалення ресурсів. Завдяки дотриманню структурованої послідовності видалення, яка враховує логічні та безпекові залежності, цей підхід забезпечує видалення Podʼів перед іншими ресурсами.
Ця функція була представлена в Kubernetes v1.33 і стала стабільною в v1.34. Цей перехід підвищує безпеку та надійність, зменшуючи ризики від недетермінованих видалень, зокрема повʼязані з вразливістю, описаною в CVE-2024-7598.

Ця робота була виконана в рамках KEP #5080 під керівництвом SIG API Machinery.

Потокове передавання відповідей list

Обробка великих відповідей list у Kubernetes раніше становила значну проблему масштабованості. Коли клієнти запитували великі списки ресурсів, такі як тисячі Podʼів або Custom Resources, API-серверу потрібно було серіалізувати всю колекцію обʼєктів в один великий буфер памʼяті перед відправленням. Цей процес створював значний тиск на памʼять і міг призвести до погіршення продуктивності, впливаючи на загальну стабільність кластера.
Щоб усунути це обмеження, було впроваджено механізм потокового кодування для колекцій (відповідей list). Для форматів відповіді JSON та Kubernetes Protobuf цей механізм потокового передавання автоматично активний, а відповідна функціональна можливість є стабільною. Основна перевага цього підходу полягає в уникненні великих виділень памʼяті на API-сервері, що призводить до набагато меншого та більш передбачуваного споживання памʼяті. Внаслідок цього кластер стає більш стійким і продуктивним, особливо в середовищах великого масштабу, де часті запити на великі списки ресурсів є звичайними.

Ця робота була виконана в рамках KEP #5116 під керівництвом SIG API Machinery.

Стійка ініціалізація кешу спостереження

Кеш спостереження (watch cache) — це шар кешування всередині kube-apiserver, який підтримує зрештою узгоджений кеш стану кластера, збереженого в etcd. У минулому могли виникати проблеми, коли кеш спостереження ще не був ініціалізований під час запуску kube-apiserver або коли він вимагав повторної ініціалізації.

Щоб вирішити ці проблеми, процес ініціалізації кешу спостереження став більш стійким до збоїв, що покращує надійність панелі управління та гарантує, що контролери й клієнти можуть надійно встановлювати спостереження (watch). Це покращення було представлено як бета у v1.31 і тепер є стабільним.

Ця робота була виконана в рамках KEP #4568 під керівництвом SIG API Machinery та SIG Scalability.

Послаблення перевірки шляху пошуку DNS

Раніше сувора перевірка шляху пошуку DNS (search) Podʼа у Kubernetes часто створювала проблеми інтеграції в складних або застарілих мережевих середовищах. Ця обмеженість могла блокувати конфігурації, які були необхідні для інфраструктури організації, змушуючи адміністраторів впроваджувати складні обхідні шляхи.
Щоб вирішити цю проблему, послаблену перевірку DNS було представлено як альфа у v1.32, і тепер вона стала стабільною у v1.34. Поширений випадок використання стосується Podʼів, які повинні взаємодіяти як з внутрішніми службами Kubernetes, так і з зовнішніми доменами. Встановивши одну крапку (.) як перший запис у списку searches у .spec.dnsConfig Podʼа, адміністратори можуть запобігти тому, щоб системний резолвер додавав внутрішні домени пошуку кластера до зовнішніх запитів. Це запобігає створенню непотрібних DNS-запитів до внутрішнього DNS-сервера для зовнішніх імен хостів, покращуючи ефективність та запобігаючи потенційним помилкам розвʼязання імен.

Ця робота була виконана в рамках KEP #4427 під керівництвом SIG Network.

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

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

Ця робота була виконана в рамках KEP #5100 під керівництвом SIG Windows.

Дія Sleep для хуків життєвого циклу контейнерів

Дію Sleep для хуків життєвого циклу контейнерів PreStop і PostStart було введено, щоб забезпечити простий спосіб керування належним (graceful) завершенням роботи та покращити загальне управління життєвим циклом контейнерів.
Дія Sleep дозволяє контейнерам призупинятися на вказаний період після запуску або перед завершенням. Використання відʼємної або нульової тривалості сну спричиняє негайне повернення, тобто дія нічого не робить (no-op).
Дію Sleep було представлено в Kubernetes v1.29, а підтримку нульового значення додано в v1.32. Обидві функції стали стабільними в v1.34.

Ця робота була виконана в рамках KEP #3960 та KEP #4818 під керівництвом SIG Node.

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

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

Щоб вирішити цю проблему, у v1.22 було представлено підтримку свопу з налаштуваннями на рівні вузлів. Вона пройшла через альфа- та бета-етапи і стала стабільною у v1.34. Основний режим, LimitedSwap, дозволяє Podʼам використовувати своп у межах їхніх наявних обмежень памʼяті, надаючи безпосереднє розвʼязання проблеми. Типово kubelet налаштований у режимі NoSwap, що означає, що робочі навантаження Kubernetes не можуть використовувати своп.

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

Ця робота була виконана в рамках KEP #2400 під керівництвом SIG Node.

Дозвіл на використання спеціальних символів у змінних середовища

Правила валідації змінних середовища в Kubernetes були послаблені, щоб дозволити майже всі друковані символи ASCII в іменах змінних, за винятком =. Ця зміна підтримує сценарії, коли робочі навантаження вимагають нестандартних символів в іменах змінних, — наприклад, фреймворки, такі як .NET Core, які використовують : для представлення вкладених ключів конфігурації.

Послаблена валідація застосовується до змінних середовища, визначених безпосередньо в специфікації Podʼа, а також до тих, що додаються за допомогою посилань envFrom на ConfigMaps і Secrets.

Ця робота була виконана в рамках KEP #4369 під керівництвом SIG Node.

Керування позначками taint тепер відокремлено від життєвого циклу вузлів

Історично логіка TaintManager щодо застосування позначок taint NoSchedule та NoExecute до вузлів на основі їхнього стану (NotReady, Unreachable тощо) була тісно повʼязана з контролером життєвого циклу вузлів. Це тісне зʼєднання ускладнювало обслуговування та тестування коду, а також обмежувало гнучкість механізму виселення на основі taint. Цей KEP переносить TaintManager у власний окремий контролер у межах менеджера контролерів Kubernetes. Це внутрішнє архітектурне покращення, спрямоване на підвищення модульності та підтримуваності коду. Ця зміна дозволяє тестувати та розвивати логіку виселення на основі taint незалежно, але не має прямого впливу на те, як користувачі використовують taints.

Ця робота була виконана в рамках KEP #3902 під керівництвом SIG Scheduling та SIG Node.

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

Це деякі покращення, які тепер є бета після випуску v1.34.

Запити та обмеження ресурсів на рівні Podʼа

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

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

Ця робота була виконана в рамках KEP #2837 під керівництвом SIG Scheduling та SIG Autoscaling.

Файл `.kuberc` для налаштувань користувача `kubectl`

Файл конфігурації .kuberc дозволяє визначити уподобання для kubectl, такі як типові параметри та псевдоніми команд. На відміну від файлу kubeconfig, файл конфігурації .kuberc не містить інформації про кластер, імен користувачів або паролів.
Ця функція була представлена як альфа у v1.33 і вмикалась змінною середовища KUBECTL_KUBERC. Вона стала бета у v1.34 і є типово увімкненою.

Ця робота була виконана в рамках KEP #3104 під керівництвом SIG CLI.

Зовнішнє підписування токенів ServiceAccount

Традиційно Kubernetes управляє токенами ServiceAccount, використовуючи статичні ключі підпису, які завантажуються з диска під час запуску kube-apiserver. Ця функція впроваджує сервіс gRPC ExternalJWTSigner для підписування поза процесом, що дозволяє дистрибутивам Kubernetes інтегруватися з зовнішніми рішеннями для управління ключами (наприклад, HSM, хмарні KMS) для підписування токенів ServiceAccount замість статичних ключів на диску.

Представлена як альфа у v1.32, ця можливість зовнішнього підписування JWT переходить у бета-версію та є типово увімкненою у v1.34.

Ця робота була виконана в рамках KEP #740 під керівництвом SIG Auth.

Функції DRA у бета-версії

Адміністративний доступ для безпечного моніторингу ресурсів

DRA підтримує контрольований адміністративний доступ через поле adminAccess у ResourceClaims або ResourceClaimTemplates, що дозволяє операторам кластерів отримувати доступ до пристроїв, які вже використовуються іншими, для моніторингу або діагностики. Цей привілейований режим доступний лише користувачам, уповноваженим створювати такі обʼєкти в просторах імен, позначених міткою resource.k8s.io/admin-access: "true", що гарантує, що звичайні робочі навантаження не зазнають впливу. Перейшовши до бета-версії у v1.34, ця функція надає можливості безпечної інтроспекції, зберігаючи при цьому ізоляцію робочих навантажень завдяки перевіркам авторизації на основі просторів імен.

Ця робота була виконана в рамках KEP #5018 під керівництвом WG Device Management та SIG Auth.

Пріоритетні альтернативи в ResourceClaims та ResourceClaimTemplates

Хоча робоче навантаження може найкраще працювати на одному високопродуктивному GPU, воно також може працювати на двох GPU середнього рівня.
З функціональною можливістю DRAPrioritizedList (тепер типово увімкненою) ResourceClaims та ResourceClaimTemplates отримують нове поле firstAvailable. Це поле є впорядкованим списком, що дозволяє користувачам вказувати, що запит може бути задоволений різними способами, зокрема й без виділення будь-чого, якщо певне обладнання недоступне. Планувальник намагатиметься задовольнити альтернативи в списку за порядком, тому робочому навантаженню буде виділено найкращий набір доступних у кластері пристроїв.

Ця робота була виконана в рамках KEP #4816 під керівництвом WG Device Management.

`kubelet` звітує про виділені ресурси DRA

API kubelet було оновлено, щоб звітувати про ресурси Podʼів, виділені через DRA. Це дозволяє агентам моніторингу вузлів виявляти виділені ресурси DRA для Podʼів на вузлі. Крім того, це дозволяє компонентам вузлів використовувати PodResourcesAPI та використовувати цю інформацію про DRA при розробці нових функцій та інтеграцій.
Починаючи з Kubernetes v1.34, ця функція є типово увімкненою.

Ця робота була виконана в рамках KEP #3695 під керівництвом WG Device Management.

Неблокуючі виклики API `kube-scheduler`

kube-scheduler виконує блокуючі виклики API під час циклів планування, створюючи вузькі місця в продуктивності. Ця функція впроваджує асинхронну обробку API через систему пріоритетних черг з дедуплікацією запитів, що дозволяє планувальнику продовжувати обробку Podʼів, поки операції API завершуються у фоновому режимі. Основні переваги включають зменшення затримки планування, запобігання голодуванню потоків планувальника під час затримок API та можливість негайної повторної спроби для Podʼів, які не вдалося запланувати. Реалізація зберігає зворотну сумісність і додає метрики для моніторингу операцій API, що очікують на виконання.

Ця робота була виконана в рамках KEP #5229 під керівництвом SIG Scheduling.

Змінювані політики допуску

MutatingAdmissionPolicies пропонують декларативну альтернативу змінюваним вебхукам допуску, що працює всередині процесу. Ця функція використовує створення екземплярів обʼєктів у CEL та стратегії JSON Patch у поєднанні з алгоритмами злиття Server Side Apply.
Це суттєво спрощує контроль допуску, дозволяючи адміністраторам визначати правила мутації безпосередньо в API-сервері.
Представлені як альфа у v1.32, змінювані політики допуску стали бета у v1.34.

Ця робота була виконана в рамках KEP #3962 під керівництвом SIG API Machinery.

Кеш API-сервера з підтримкою знімків

Механізм кешування kube-apiserver (кеш спостереження) ефективно обслуговує запити на останній спостережуваний стан. Однак запити list на попередні стани (наприклад, через пагінацію або із зазначенням resourceVersion) часто обходять цей кеш і обслуговуються безпосередньо з etcd. Таке пряме звернення до etcd значно збільшує витрати на продуктивність і може призвести до проблем зі стабільністю, особливо з великими ресурсами, через тиск на памʼять від передачі великих обсягів даних.
Оскільки функціональна можливість ListFromCacheSnapshot тепер типово увімкнена, kube-apiserver намагатиметься обслуговувати відповідь зі знімків, якщо доступний знімок з resourceVersion, старішим за запитуваний. kube-apiserver починає роботу без знімків, створює новий знімок на кожну подію спостереження і зберігає їх, доки не виявить, що в etcd виконано ущільнення (compaction), або доки кеш не заповниться подіями, старшими за 75 секунд. Якщо вказаний resourceVersion недоступний, сервер повернеться до etcd.

Ця робота була виконана в рамках KEP #4988 під керівництвом SIG API Machinery.

Інструменти для декларативної перевірки типів, властивих Kubernetes

До цього випуску правила валідації для вбудованих у Kubernetes API писалися повністю вручну, що ускладнює їх виявлення, розуміння, покращення або тестування для супроводжувачів. Не було єдиного способу знайти всі правила валідації, які можуть застосовуватися до API. Декларативна валідація приносить користь супроводжувачам Kubernetes, спрощуючи розробку, обслуговування та рецензування API, водночас уможливлюючи програмну інспекцію для кращого інструментарію та документації. Для людей, які використовують бібліотеки Kubernetes для написання власного коду (наприклад: контролера), новий підхід спрощує додавання нових полів через теґи IDL замість складних функцій валідації. Ця зміна допомагає прискорити створення API, автоматизуючи шаблонний код валідації, та надає релевантніші повідомлення про помилки, виконуючи валідацію на версійованих типах.
Це удосконалення (яке стало бета у v1.33 і залишається бета у v1.34) приносить правила валідації на основі CEL до вбудованих типів Kubernetes. Воно дозволяє визначати більш детальну та декларативну валідацію безпосередньо у визначеннях типів, покращуючи узгодженість API та зручність для розробників.

Ця робота була виконана в рамках KEP #5073 під керівництвом SIG API Machinery.

Потокові інформери для запитів list

Функція потокових інформерів, яка перебуває в бета-версії з v1.32, отримує подальші вдосконалення в межах бета-версії у v1.34. Ця можливість дозволяє запитам list повертати дані як безперервний потік обʼєктів з кешу спостереження API-сервера, а не збирати сторінки результатів безпосередньо з etcd. Повторно використовуючи ті самі механізми, що застосовуються для операцій watch, API-сервер може обслуговувати великі набори даних, зберігаючи при цьому стабільне використання памʼяті та уникаючи стрибків виділення памʼяті, які можуть вплинути на стабільність.

У цьому випуску kube-apiserver та kube-controller-manager обидва типово використовують новий механізм WatchList. Для kube-apiserver це означає, що запити list ефективніше передаються потоком, тоді як kube-controller-manager отримує ефективніший з точки зору памʼяті та передбачуваний спосіб роботи з інформерами. Разом ці покращення зменшують тиск на памʼять під час великих операцій list та покращують надійність під час тривалого навантаження, роблячи потокову передачу списків передбачуванішою та ефективнішою.

Ця робота була виконана в рамках KEP #3157 під керівництвом SIG API Machinery та SIG Scalability.

Обробка належного вимкнення для вузлів Windows

kubelet на вузлах Windows тепер може виявляти події вимкнення системи та починати належне завершення роботи запущених Podʼів. Це відтворює наявну поведінку в Linux і допомагає забезпечити коректне завершення робочих навантажень під час запланованих вимкнень або перезавантажень.
Коли система починає вимикатися, kubelet реагує, використовуючи стандартну логіку завершення. Він дотримується налаштованих хуків життєвого циклу та періодів належного завершення, надаючи Podʼам час на зупинку перед вимкненням вузла. Для координації цього процесу функція покладається на сповіщення Windows перед вимкненням (pre-shutdown). Це удосконалення покращує надійність робочих навантажень під час обслуговування, перезавантажень або оновлень системи. Тепер функція перебуває в бета-версії та є типово увімкненою.

Ця робота була виконана в рамках KEP #4802 під керівництвом SIG Windows.

Покращення зміни розміру Podʼа на місці

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

Ця функція залишається в бета-версії у v1.34. Детальні інструкції щодо використання та приклади наведено в документації: Зміна ресурсів CPU та памʼяті, призначених контейнерам.

Ця робота була виконана в рамках KEP #1287 під керівництвом SIG Node та SIG Autoscaling.

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

Це деякі з покращень, які тепер є альфа після випуску v1.34.

Сертифікати Podʼів для автентифікації mTLS

Автентифікація робочих навантажень всередині кластера, особливо для звʼязку з API-сервером, в основному покладалася на токени ServiceAccount. Хоча ці токени ефективні, вони не завжди ідеально підходять для встановлення сильної, перевірюваної ідентичності для взаємного TLS (mTLS) і можуть створювати проблеми при інтеграції з зовнішніми системами, які очікують автентифікації на основі сертифікатів.
Kubernetes v1.34 вводить вбудований механізм, за допомогою якого Podʼи можуть отримувати сертифікати X.509 через PodCertificateRequests. kubelet може запитувати та керувати сертифікатами для Podʼів, які потім можуть використовуватися для автентифікації на API-сервері Kubernetes та в інших службах за допомогою mTLS. Основна перевага полягає в більш надійному та гнучкому механізмі ідентифікації для Podʼів. Він надає вбудований спосіб реалізації надійної автентифікації mTLS без покладання виключно на токени на предʼявника (bearer tokens), узгоджуючи Kubernetes зі стандартними практиками безпеки та спрощуючи інтеграцію з інструментами спостереження та безпеки, що працюють із сертифікатами.

Ця робота була виконана в рамках KEP #4317 під керівництвом SIG Auth.

Стандарт безпеки Podʼів "Restricted" тепер забороняє віддалені перевірки

Поле host у перевірках (probes) та обробниках життєвого циклу дозволяє користувачам вказувати для перевірки kubelet іншу сутність, ніж podIP. Однак це відкриває шлях для зловживань та атак, які обходять засоби безпеки, оскільки в поле host можна встановити будь-яке значення, включаючи чутливі з погляду безпеки зовнішні хости або localhost на вузлі. У Kubernetes v1.34 Podʼи відповідають стандарту безпеки Podʼів Restricted лише в тому випадку, якщо вони або залишають поле host не встановленим, або взагалі не використовують цей тип перевірки. Ви можете використовувати допуск безпеки Podʼів (Pod security admission) або стороннє рішення, щоб забезпечити відповідність Podʼів цьому стандарту. Оскільки це засоби безпеки, ознайомтеся з документацією, щоб зрозуміти обмеження та поведінку механізму примусового застосування, який ви обираєте.

Ця робота була виконана в рамках KEP #4940 під керівництвом SIG Auth.

Використовуйте `.status.nominatedNodeName` для показу розміщення Podʼа

Коли kube-scheduler потребує часу, щоб привʼязати Podʼи до вузлів, кластерні автомасштабувальники можуть не розуміти, що Pod буде привʼязаний до певного вузла. Внаслідок цього вони можуть помилково вважати вузол недовикористаним і видалити його.
Щоб вирішити цю проблему, kube-scheduler може використовувати .status.nominatedNodeName не лише для вказівки на поточне витіснення, але й для показу намірів щодо розміщення Podʼа. Якщо увімкнути функціональну можливість NominatedNodeNameForExpectation, планувальник використовує це поле, щоб вказати, до якого вузла буде привʼязано Pod. Це робить видимими внутрішні резервування, щоб допомогти зовнішнім компонентам приймати обґрунтовані рішення.

Ця робота була виконана в рамках KEP #5278 під керівництвом SIG Scheduling.

Функції DRA в альфа-версії

Стан справності ресурсів для DRA

Буває важко дізнатися, коли Pod використовує пристрій, який вийшов з ладу або тимчасово несправний, що робить усунення несправностей, повʼязаних зі збоями Podʼів, складним або неможливим.
Стан справності ресурсів для DRA покращує спостережуваність, показуючи стан справності пристроїв, виділених Podʼу, у статусі Podʼа. Це полегшує виявлення причин проблем Podʼа, повʼязаних з несправними пристроями, та належне реагування на них.
Щоб увімкнути цю функціональність, потрібно увімкнути функціональну можливість ResourceHealthStatus, а драйвер DRA повинен реалізувати сервіс gRPC DRAResourceHealth.

Ця робота була виконана в рамках KEP #4680 під керівництвом WG Device Management.

Зіставлення розширених ресурсів

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

Ця робота була виконана в рамках KEP #5004 під керівництвом WG Device Management.

Споживча ємність DRA

У Kubernetes v1.33 додано підтримку оголошення драйверами ресурсів доступних частин пристрою замість того, щоб надавати весь пристрій як ресурс за принципом «все або нічого». Однак цей підхід не міг впоратися зі сценаріями, де драйвери пристроїв керують дрібними, динамічними частинами ресурсу пристрою на основі попиту користувачів або спільно використовують ці ресурси незалежно від ResourceClaims, які обмежені своєю специфікацією та простором імен.
Увімкнення функціональної можливості DRAConsumableCapacity (представленої як альфа у v1.34) дозволяє драйверам ресурсів спільно використовувати один і той самий пристрій або навіть частину пристрою в кількох ResourceClaims або в кількох DeviceRequests. Функція також розширює планувальник для підтримки виділення частин ресурсів пристрою, як визначено в полі capacity. Ця функція DRA покращує спільне використання пристроїв між просторами імен та заявками, адаптуючи його до потреб Podʼів. Вона дозволяє драйверам забезпечувати обмеження ємності, покращує планування та підтримує нові випадки використання, такі як мережева взаємодія з урахуванням пропускної здатності та спільне використання кількома орендарями.

Ця робота була виконана в рамках KEP #5075 під керівництвом WG Device Management.

Умови привʼязки пристроїв

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

Ця робота була виконана в рамках KEP #5007 під керівництвом WG Device Management.

Правила перезапуску контейнерів

Наразі всі контейнери в межах Podʼа дотримуються однієї й тієї ж .spec.restartPolicy під час виходу або аварійного завершення. Однак Podʼи, які виконують кілька контейнерів, можуть мати різні вимоги до перезапуску для кожного контейнера. Наприклад, для контейнерів ініціалізації, які використовуються для виконання ініціалізації, ви, можливо, не захочете повторювати ініціалізацію, якщо вона завершиться невдачею. Аналогічно, в дослідницьких середовищах ML з тривалими навчальними навантаженнями контейнери, які завершуються з кодами виходу, що допускають повторну спробу, повинні швидко перезапускатися на місці, а не спричиняти повторне створення Podʼа та втрату прогресу.
Kubernetes v1.34 вводить функціональну можливість ContainerRestartRules. Коли її увімкнено, restartPolicy можна вказати для кожного контейнера в межах Podʼа. Також можна визначити список restartPolicyRules, щоб перевизначати restartPolicy на основі останнього коду виходу. Це надає детальний контроль, необхідний для обробки складних сценаріїв, та краще використання обчислювальних ресурсів.

Ця робота була виконана в рамках KEP #5307 під керівництвом SIG Node.

Завантаження змінних середовища з файлів, створених під час виконання

Розробники застосунків давно просять про більшу гнучкість в оголошенні змінних середовища. Традиційно змінні середовища оголошуються на стороні API-сервера через статичні значення, ConfigMaps або Secrets.

З функціональною можливістю EnvFiles Kubernetes v1.34 впроваджує можливість оголошувати змінні середовища під час виконання. Один контейнер (зазвичай контейнер ініціалізації) може згенерувати змінну та зберегти її у файлі, а наступний контейнер може запуститися зі змінною середовища, завантаженою з цього файлу. Цей підхід усуває необхідність "обгортати" точку входу цільового контейнера, що дозволяє гнучкіше оркеструвати контейнери в межах Podʼа.

Ця функція особливо корисна для навчальних навантажень AI/ML, де кожен Pod у навчальному Job потребує ініціалізації значеннями, визначеними під час виконання.

Ця робота була виконана в рамках KEP #5307 під керівництвом SIG Node.

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

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

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

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

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

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

Ручне налаштування драйвера cgroup застаріло

Історично налаштування правильного драйвера cgroup було болючою точкою для користувачів, які використовують кластери Kubernetes. Kubernetes v1.28 додав для kubelet спосіб запитувати реалізацію CRI та дізнаватися, який драйвер cgroup використовувати. Це автоматичне виявлення тепер наполегливо рекомендується, і його підтримка стала стабільною у v1.34. Якщо ваше середовище виконання контейнерів CRI не підтримує можливість повідомляти потрібний йому драйвер cgroup, вам слід оновити або змінити середовище виконання контейнерів. Налаштування cgroupDriver у файлі конфігурації kubelet тепер застаріле. Відповідний параметр командного рядка --cgroup-driver був визнаний застарілим раніше, оскільки Kubernetes рекомендує натомість використовувати файл конфігурації. Як налаштування конфігурації, так і параметр командного рядка буде вилучено в майбутньому випуску; це вилучення відбудеться не раніше мінорного випуску v1.36.

Ця робота була виконана в рамках KEP #4033 під керівництвом SIG Node.

Kubernetes припинить підтримку containerd 1.x у v1.36

Хоча Kubernetes v1.34 все ще підтримує containerd 1.7 та інші LTS-випуски containerd, внаслідок автоматичного виявлення драйвера cgroup спільнота Kubernetes SIG Node офіційно погодила остаточний графік підтримки для containerd v1.X. Останнім випуском Kubernetes, який надаватиме цю підтримку, буде v1.35 (узгоджено із завершенням підтримки (EOL) containerd 1.7). Це раннє попередження: якщо ви використовуєте containerd 1.X, розгляньте можливість найближчим часом перейти на 2.0+. Ви можете відстежувати метрику kubelet_cri_losing_support, щоб визначити, чи використовують якісь вузли у вашому кластері версію containerd, яка незабаром стане застарілою.

Ця робота була виконана в рамках KEP #4033 під керівництвом SIG Node.

Розподіл трафіку `PreferClose` є застарілим

Поле spec.trafficDistribution у Kubernetes Service дозволяє користувачам висловлювати переваги щодо того, як трафік повинен маршрутизуватися до точок доступу Service.

KEP-3015 визнає застарілим PreferClose і вводить два додаткових значення: PreferSameZone та PreferSameNode. PreferSameZone є псевдонімом для наявного PreferClose, щоб прояснити його семантику. PreferSameNode дозволяє доставляти зʼєднання до локальної точки доступу, коли це можливо, з переходом на віддалену точку доступу, коли це неможливо.

Ця функція була представлена у v1.33 за функціональною можливістю PreferSameTrafficDistribution. Вона стала бета у v1.34 і є типово увімкненою.

Ця робота була виконана в рамках KEP #3015 під керівництвом SIG Network.

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

Перегляньте всі деталі випуску Kubernetes v1.34 у наших примітках до випуску.

Доступність

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

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

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

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

Ми вшановуємо памʼять Родольфо "Родо" Мартінеса Веги, відданого учасника, чия пристрасть до технологій та розбудови спільноти залишила слід у спільноті Kubernetes. Родо був учасником команди випуску Kubernetes протягом кількох випусків, включаючи v1.22-v1.23 та v1.25-v1.30, демонструючи непохитну відданість успіху та стабільності проєкту.
Окрім участі в команді випуску, Родо активно сприяв розвитку спільноти Cloud Native LATAM, допомагаючи долати мовні та культурні барʼєри в цій сфері. Його робота над іспанською версією документації Kubernetes та глосарієм CNCF є прикладом його відданості справі зробити знання доступними для іспаномовних розробників у всьому світі. Спадщина Родо живе в численних членах спільноти, яких він наставляв, у випусках, які він допоміг підготувати, та в яскравій спільноті Kubernetes LATAM, яку він допоміг виростити.

Ми хотіли б подякувати всій команді випуску за години наполегливої праці, витрачені на підготовку випуску Kubernetes v1.34 для нашої спільноти. Склад команди випуску варіюється від новачків-стажерів (shadows) до досвідчених лідерів команд, що повертаються, з досвідом, набутим протягом кількох циклів випуску. Особлива подяка нашому лідеру випуску, Вйому Ядаву, за те, що провів нас через успішний цикл випуску, за його практичний підхід до розвʼязання проблем та за енергію й турботу, які рухають нашу спільноту вперед.

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

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

Під час циклу випуску v1.34, який тривав 15 тижнів з 19 травня 2025 року по 27 серпня 2025 року, Kubernetes отримав внески від 106 різних компаній та 491 особи. У ширшій хмарній екосистемі ця цифра зростає до 370 компаній, враховуючи загалом 2235 учасників.

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

Джерело цих даних:

Майбутні події

Ознайомтеся з майбутніми подіями Kubernetes та cloud native, включаючи KubeCon + CloudNativeCon, KCD та інші помітні конференції по всьому світу. Залишайтеся в курсі та беріть участь у житті спільноти Kubernetes!

Серпень 2025

KCD — Дні спільноти Kubernetes: Колумбія: 28 серпня 2025 року | Богота, Колумбія

Вересень 2025

CloudCon Sydney: 9–10 вересня 2025 року | Сідней, Австралія.
KCD — Дні спільноти Kubernetes: Район затоки Сан-Франциско: 9 вересня 2025 року | Сан-Франциско, США
KCD — Дні спільноти Kubernetes: Вашингтон: 16 вересня 2025 року | Вашингтон, округ Колумбія, США
KCD — Дні спільноти Kubernetes: Софія: 18 вересня 2025 року | Софія, Болгарія
KCD — Дні спільноти Kubernetes: Ель-Сальвадор: 20 вересня 2025 року | Сан-Сальвадор, Ель-Сальвадор

Жовтень 2025

KCD — Дні спільноти Kubernetes: Варшава: 9 жовтня 2025 року | Варшава, Польща
KCD — Дні спільноти Kubernetes: Единбург: 21 жовтня 2025 року | Единбург, Сполучене Королівство
KCD — Дні спільноти Kubernetes: Шрі-Ланка: 26 жовтня 2025 року | Коломбо, Шрі-Ланка

Листопад 2025

KCD — Дні спільноти Kubernetes: Порту: 3 листопада 2025 року | Порту, Португалія
KubeCon + CloudNativeCon North America 2025: 10-13 листопада 2025 року | Атланта, США
KCD — Дні спільноти Kubernetes: Ханчжоу: 15 листопада 2025 року | Ханчжоу, Китай

Грудень 2025

KCD — Дні спільноти Kubernetes: Швейцарська Романдія: 4 грудня 2025 року | Женева, Швейцарія

Останні відомості про події можна знайти тут.

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

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

Долучайтесь

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

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

Попередній огляд Kubernetes v1.34

Mon, 28 Jul 2025 00:00:00 +0000

Kubernetes v1.34 очікукється наприкінці серпня 2025 року. Хоча він не міститиме видалень чи застарівань, у ньому буде велика кількість покращень. Ось деякі з функцій, які нас найбільше зацікавили в цьому циклі!

Зверніть увагу, що ця інформація відображає поточний стан розробки v1.34 і може змінитися до випуску нової версії.

Основні покращення Kubernetes v1.34

Нижче наведено деякі з помітних покращень, які, ймовірно, будуть включені до випуску v1.34, але це не вичерпний перелік усіх запланованих змін, і вміст релізу може змінюватися.

Ядро DRA переходить у стабільний стан

Динамічне виділення ресурсів (DRA) забезпечує гнучкий спосіб категоризації, подання заявок та використання пристроїв, таких як GPU або спеціалізоване обладнання, у вашому кластері Kubernetes.

З моменту випуску v1.30 DRA базується на заявках на пристрої із структурованими параметрами, які є непрозорими для ядра Kubernetes. Відповідна пропозиція (KEP-4381) щодо покращення, була створена під впливом концепцій динамічного виділення сховищ. DRA зі структурованими параметрами використовує набір допоміжних API-типів: ResourceClaim, DeviceClass, ResourceClaimTemplate та ResourceSlice у групі resource.k8s.io, а також розширює .spec для Pod новим полем resourceClaims. Ядро DRA планує перейти у стабільний стан у Kubernetes v1.34.

З DRA драйвери пристроїв та адміністратори кластерів визначають класи пристроїв, доступні для використання. Робочі навантаження можуть подавати заявки на пристрої із зазначенням класу пристроїв у запитах. Kubernetes виділяє відповідні пристрої для конкретних заявок і розміщує відповідні Podʼи на вузлах, які мають доступ до виділених пристроїв. Ця система забезпечує гнучку фільтрацію пристроїв за допомогою CEL, централізовану категоризацію пристроїв та спрощені запити Podʼів.

Після переходу цієї функції у стабільний стан API resource.k8s.io/v1 буде стандартно доступний.

Токени ServiceAccount для автентифікації для завантаження образів

Інтеграція токенів ServiceAccount для провайдерів облікових даних kubelet ймовірно досягне бета-стадії та буде стандартно увімкнена у Kubernetes v1.34. Це дозволяє kubelet використовувати ці токени для завантаження контейнерних образів з реєстрів, які потребують автентифікації.

Підтримка вже існує як alpha і відстежується у KEP-4412.

Alpha-інтеграція дозволяє kubelet використовувати короткострокові, токени ServiceAccount (з OIDC-сумісною семантикою) з автоматичною ротацією для автентифікації у реєстрі контейнерних образів. Кожен токен привʼязаний до відповідного Podʼа; механізм замінює потребу у довгострокових секретах для завантаження образів.

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

Політика заміни Pod в Deployment

Після змін в Deployment завершення Podʼів може тривати певний час і споживати додаткові ресурси. У рамках KEP-3973 буде додано поле .spec.podReplacementPolicy (як alpha) для Deployment.

Якщо функція увімкнена у вашому кластері, ви зможете обрати одну з двох політик:

TerminationStarted: Створює нові Podʼи, як тільки старі починають процес завершення роботи, що прискорює оновлення, але може збільшити споживання ресурсів.
TerminationComplete: Чекає повного завершення роботи старих Podʼів перед створенням нових, що забезпечує контрольоване споживання ресурсів.

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

Очікується, що функція буде доступна як alpha і може бути увімкнена через функціональні можливості DeploymentPodReplacementPolicy та DeploymentReplicaSetTerminatingReplicas в API-сервері та kube-controller-manager.

Готовий до промислового використання трейсинг для `kubelet` та API Server

Для вирішення проблеми налагодження на рівні вузла шляхом зіставлення розрізнених логів, KEP-2831 забезпечує глибоке, контекстне розуміння роботи kubelet.

Функція інструментує критичні операції kubelet, особливо gRPC-виклики до Container Runtime Interface (CRI), використовуючи стандарт OpenTelemetry. Це дозволяє операторам візуалізувати весь життєвий цикл подій (наприклад, запуск Podʼів) для визначення джерел затримок та помилок. Найпотужніша частина — передача trace ID у запитах до контейнерного рушія, що дозволяє їм звʼязувати свої власні відрізки.

Це доповнюється паралельним покращенням, KEP-647, яке приносить такі ж можливості трейсингу до API-сервера Kubernetes. Разом ці покращення забезпечують більш цілісний, наскрізний огляд подій, спрощуючи пошук затримок та помилок від панелі управління до вузла. Обидві функції пройшли офіційний процес релізу Kubernetes. KEP-2831 був представлений як alpha у v1.25, а KEP-647 — як alpha у v1.22. Обидва були підвищені до beta у v1.27. Надалі Kubelet Tracing (KEP-2831) і API Server Tracing (KEP-647) планують перевести у стабільний стан у наступному випуску v1.34.

`PreferSameZone` та `PreferSameNode` для розподілу трафіку у Service

Поле spec.trafficDistribution у Service дозволяє вказати переваги щодо маршрутизації трафіку до точок доступу Service.

KEP-3015 визнає застарілим PreferClose та додає два нових значення: PreferSameZone та PreferSameNode. PreferSameZone еквівалентний поточному PreferClose. PreferSameNode надає перевагу надсиланню трафіку до точок доступу на тому ж вузлі, що й клієнт.

Функція була представлена у v1.33 функціональною можливістю PreferSameTrafficDistribution. У v1.34 вона планує перейти у beta зі стандартним її увімкненням.

Підтримка KYAML: діалекту YAML для Kubernetes

KYAML — це безпечніша та менш неоднозначна підмножина YAML, спеціально розроблена для Kubernetes. Незалежно від версії Kubernetes, ви зможете використовувати KYAML для написання маніфестів чи Helm-чартів. Ви можете писати KYAML і передавати його як вхідні дані у будь-яку версію kubectl, оскільки всі KYAML-файли також є валідними YAML. З kubectl v1.34 очікується можливість запитувати вивід у форматі KYAML (kubectl get -o kyaml …). За бажанням, ви можете й надалі отримувати вихід у форматі JSON або YAML.

KYAML вирішує специфічні проблеми YAML та JSON. У YAML значущі пробіли вимагають уважності до відступів та вкладеності, а необовʼязкове взяття рядків в лапки може призвести до неочікуваного приведення типів (наприклад, "The Norway Bug"). JSON не підтримує коментарі та має суворі вимоги до ком та ключів в лапках.

KEP-5295 представляє KYAML, який вирішує основні проблеми:

Обовʼязкове використання подвійних лапок для рядкових (string) значень
Не вказувати ключі в лапках, якщо вони не є потенційно неоднозначними
Завжди використовує {} для відображень (асоціативних масивів)
Завжди використовує [] для списків

Це схоже на JSON, але на відміну від JSON, KYAML підтримує коментарі, дозволяє коми у кінці та не вимагає лапок для ключів.

Очікуємо, що KYAML буде представлений як новий формат виводу для kubectl v1.34. Як і для всіх цих функцій, жодна з них не гарантована; слідкуйте за оновленнями!

KYAML є і залишатиметься строгою підмножиною YAML, що гарантує можливість парсингу KYAML-документів будь-яким YAML-парсером. Kubernetes не вимагає спеціального формату KYAML для вхідних даних, і змінювати це не планується.

Точне регулювання автоматичного масштабування з налаштовуваною толерантністю HPA

KEP-4951 додає можливість налаштовувати толерантність автомасштабування для кожного HPA окремо, замість стандартного кластерного значення 10%, яке часто є занадто грубим для різних навантажень. Покращення додає необовʼязкове поле tolerance до секцій spec.behavior.scaleUp та spec.behavior.scaleDown HPA, дозволяючи різні значення толерантності для масштабування вгору та вниз, що особливо корисно, оскільки чутливість до масштабування вгору зазвичай важливіша для обробки піків трафіку.

Функція була випущена як alpha у Kubernetes v1.33 з функціональною можливістю HPAConfigurableTolerance, а у v1.34 планує перейти у beta. Це покращення допомагає вирішити проблеми масштабування для великих розгортань, де толерантність для масштабування вниз на 10% може означати те, що в роботі залишаться сотні зайвих Podʼів. Новий підхід дозволяє оптимізувати поведінку для кожного навантаження окремо.

Хочете дізнатися більше?

Нові функції та застарівання також оголошуються у нотатках до релізу Kubernetes. Офіційний анонс новинок у Kubernetes v1.34 буде частиною CHANGELOG для цього випуску.

Випуск Kubernetes v1.34 заплановано на середу, 27 серпня 2025 року. Слідкуйте за оновленнями!

Долучайтеся

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

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

Оголошення про випуск etcd v3.6.0

Thu, 15 May 2025 16:00:00 -0800

Це оголошення спочатку було опубліковане в блозі etcd.

Сьогодні ми випускаємо etcd v3.6.0, перший мінорний реліз з моменту випуску etcd v3.5.0 15 червня 2021 року. Цей реліз вводить кілька нових можливостей, робить значний прогрес у тривалих зусиллях, таких як підтримка зниження версії та міграція на v3store, і вирішує численні критичні та основні проблеми. Він також включає великі оптимізації в використанні памʼяті, покращуючи ефективність і продуктивність.

На додачу до можливостей v3.6.0, etcd приєднався до Kubernetes як SIG (sig-etcd), що дозволяє нам покращити стійкість проєкту. Ми впровадили систематичне тестування на надійність, щоб забезпечити правильність і надійність. За допомоги робочої групи etcd-operator ми плануємо також покращити зручність використання.

Далі наведені найзначніші зміни в etcd v3.6.0, а також обговорення планів майбутнього розвитку. Для детального списку змін, будь ласка, зверніться до CHANGELOG-3.6.

Щира подяка всім учасникам, які зробили цей реліз можливим!

Безпека

etcd ставиться до безпеки серйозно. Щоб підвищити безпеку програмного забезпечення в v3.6.0, ми покращили наші перевірки робочого процесу, інтегрувавши govulncheck для сканування вихідного коду та trivy для сканування контейнерних образів. Ці покращення також були перенесені на підтримувані стабільні релізи.

etcd продовжує дотримуватися процесу безпеки випуску для забезпечення належного керування та вирішення вразливостей.

Можливості

Міграція на v3store

v2store був визнаний застарілим з моменту випуску etcd v3.4, але його все ще можна було активувати за допомогою --enable-v2. Він залишався джерелом істини для даних про членство. У etcd v3.6.0 v2store більше не може бути активований, оскільки прапорець --enable-v2 був видалений, а v3store став єдиним джерелом істини для даних про членство.

Хоча v2store все ще існує в v3.6.0, etcd не зможе запуститися, якщо він міститиме будь-які дані, крім інформації про членство. Щоб допомогти з міграцією, etcd v3.5.18+ надає команду etcdutl check v2store, яка перевіряє, чи містить v2store лише дані про членство (див. PR 19113).

У порівнянні з v2store, v3store пропонує кращу продуктивність і транзакційну підтримку. Крім того, саме цей рушій зберігання активно підтримуватиметься надалі.

Видалення v2store все ще триває і відстежується в issues/12913.

Зниження версії

etcd v3.6.0 — це перша версія, яка повністю підтримує зниження версії. Зусилля для цього завдання зниження версії охоплюють обидві версії 3.5 і 3.6, а вся повʼязана робота відстежується в issues/11716.

На високому рівні процес охоплює міграцію схеми даних до цільової версії (наприклад, v3.5), а потім — поетапне зниження версії.

Переконайтеся, що кластер справний, і зробіть резервну копію знімка. Перевірте, чи можливе зниження версії:

$ etcdctl downgrade validate 3.5
Downgrade validate success, cluster version 3.6

Якщо зниження версії можливе, увімкніть режим зниження версії:

$ etcdctl downgrade enable 3.5
Downgrade enable success, cluster version 3.6

etcd перенесе схему даних у фоновому режимі. Після завершення перейдіть до поетапного зниження версії.

За деталями звертайтесь до керівництва Downgrade-3.6.

Функціональні можливості

У etcd v3.6.0 ми впровадили функціональні можливості (feature gates) в стилі Kubernetes для керування новими можливостями. Раніше ми позначали нестабільні можливості префіксом --experimental у назвах прапорців. Префікс видалявся, щойно можливість ставала стабільною, що спричиняло несумісну зміну. Тепер можливості починаються з Alpha, переходять до Beta, потім до GA або стають застарілими. Це забезпечує значно плавніше оновлення та зниження версії для користувачів.

Дивіться feature-gates для деталей.

Перевірки livez / readyz

etcd тепер підтримує точки доступу /livez і /readyz, що відповідає пробам життєздатності та готовності в Kubernetes. /livez вказує, чи є екземпляр etcd життєздатним, тоді як /readyz вказує, коли він готовий обслуговувати запити. Ця можливість також була перенесена на release-3.5 (починаючи з v3.5.11) і release-3.4 (починаючи з v3.4.29). Дивіться livez/readyz для деталей.

Наявна точка доступу /health залишається функціональною. /livez подібна до /health?serializable=true, тоді як /readyz подібна до /health або /health?serializable=false. Очевидно, що точки доступу /livez і /readyz надають чіткішу семантику і легші для розуміння.

v3discovery

В etcd v3.6.0 був представлений новий протокол виявлення v3discovery, заснований на clientv3. Він полегшує виявлення всіх членів кластера під час фази початкового завантаження.

Попередній протокол v2discovery, заснований на clientv2, був визнаний застарілим. Крім того, публічний сервіс виявлення за адресою https://discovery.etcd.io/, який покладався на v2discovery, більше не підтримується.

Продуктивність

Памʼять

У цьому випуску ми зменшили середнє споживання памʼяті щонайменше на 50% (див. Зображення 1). Це покращення в основному зумовлено двома змінами:

Типове значення для --snapshot-count було зменшено з 100 000 у v3.5 до 10 000 у v3.6. В результаті etcd v3.6 тепер зберігає лише близько 10% історичних записів у порівнянні з v3.5.
Історія Raft стискається частіше, про що йдеться в PR/18825.

Зображення 1: Порівняння використання памʼяті між etcd v3.5.20 і v3.6.0-rc.2 за різними співвідношеннями читання/запису. Кожен графік показує використання памʼяті з часом з певним співвідношенням читання/запису. Червона лінія представляє etcd v3.5.20, тоді як бірюзова лінія представляє v3.6.0-rc.2. У всіх протестованих співвідношеннях v3.6.0-rc.2 демонструє нижче і більш стабільне використання памʼяті.

Пропускна здатність

У порівнянні з v3.5, etcd v3.6 забезпечує середнє поліпшення продуктивності приблизно на 10% як у читанні, так і в запису (див. Зображення 2, 3, 4 і 5). Це поліпшення не повʼязане з жодною окремою великою зміною, а є кумулятивним ефектом кількох незначних вдосконалень. Одним з таких прикладів є оптимізація запитів до вільних сторінок, введена в PR/419.

Зображення 2: Порівняння пропускної здатності читання між etcd v3.5.20 і v3.6.0-rc.2 за високого коефіцієнта запису. Коефіцієнт читання/запису становить 0.0078, що означає 1 читання на 128 записів. Права смуга показує відсоткове поліпшення пропускної здатності читання v3.6.0-rc.2 в порівнянні з v3.5.20, яке коливається від 3.21% до 25.59%.

Зображення 3: Порівняння пропускної здатності читання між etcd v3.5.20 і v3.6.0-rc.2 за високого коефіцієнта читання. Коефіцієнт читання/запису становить 8, що означає 8 читань на 1 запис. Права смуга показує відсоткове поліпшення пропускної здатності читання v3.6.0-rc.2 в порівнянні з v3.5.20, яке коливається від 4.38% до 27.20%.

Зображення 4: Порівняння пропускної здатності запису між etcd v3.5.20 і v3.6.0-rc.2 за високого коефіцієнта запису. Коефіцієнт читання/запису становить 0.0078, що означає 1 читання на 128 записів. Права смуга показує відсоткове поліпшення пропускної здатності запису v3.6.0-rc.2 в порівнянні з v3.5.20, яке коливається від 2.95% до 24.24%.

Зображення 5: Порівняння пропускної здатності запису між etcd v3.5.20 і v3.6.0-rc.2 за високого коефіцієнта читання. Коефіцієнт читання/запису становить 8, що означає 8 читань на 1 запис. Права смуга показує відсоткове поліпшення пропускної здатності запису v3.6.0-rc.2 в порівнянні з v3.5.20, яке коливається від 3.86% до 28.37%.

Кардинальні зміни

У цьому розділі висвітлено кілька помітних несумісних змін. Повний список можна знайти в Оновлення etcd з v3.5 до v3.6 та CHANGELOG-3.6.

Старі бінарні файли несумісні з новими версіями схем

Старі бінарні файли etcd несумісні з новими версіями схем даних. Наприклад, etcd 3.5 не може бути запущений з даними, створеними etcd 3.6, а etcd 3.4 не може бути запущений з даними, створеними як 3.5, так і 3.6.

При зниженні версії etcd важливо дотримуватися задокументованої процедури зниження версії. Проста заміна бінарного файлу або образу призведе до проблеми несумісності.

Точки доступу учасників більше не обслуговують запити клієнтів

Точки доступу клієнтів (--advertise-client-urls) призначені лише для обслуговування запитів клієнтів, тоді як точки доступу учасників (--initial-advertise-peer-urls) призначені виключно для звʼязку між учасниками. Однак через недогляд у реалізації точки доступу учасників також могли обробляти запити клієнтів в etcd 3.4 і 3.5. Ця поведінка була оманливою і сприяла неправильним шаблонам використання. У etcd 3.6 ця оманлива поведінка була виправлена за допомогою PR/13565; точки доступу учасників більше не обслуговують запити клієнтів.

Чітка межа між etcdctl і etcdutl

Обидва etcdctl і etcdutl є інструментами командного рядка. etcdutl є офлайн-утилітою, призначеною для роботи безпосередньо з файлами даних etcd, тоді як etcdctl є онлайн-інструментом, який взаємодіє з etcd через мережу. Раніше між ними існували деякі перекриття функціональності, але ці перекриття були усунені в 3.6.0.

Вилучено etcdctl defrag --data-dir

Команда etcdctl defrag підтримує лише онлайн-дефрагментацію і більше не підтримує офлайн-дефрагментацію. Щоб виконати офлайн-дефрагментацію, використовуйте команду etcdutl defrag --data-dir.
Вилучено etcdctl snapshot status

etcdctl більше не підтримує отримання статусу знімка. Використовуйте команду etcdutl snapshot status замість цього.
Вилучено etcdctl snapshot restore

etcdctl більше не підтримує відновлення з знімка. Використовуйте команду etcdutl snapshot restore замість цього.

Виправлення критичних помилок

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

Неузгодженість даних при аварійному завершенні під навантаженням

Раніше, коли etcd застосовував дані, він спочатку оновлював consistent-index, а потім фіксував дані. Однак ці операції не були атомарними. Якщо etcd зазнавав аварії між цими операціями, це могло призвести до неузгодженості даних (див. issue/13766). Проблема зʼявилася в v3.5.0, її виправлено в v3.5.3 за допомогою PR/13854.
Порушення гарантії Durability API в кластері з одного вузла

Коли клієнт записує дані та отримує успішну відповідь, очікується, що дані будуть збережені. Однак дані можуть бути втрачені, якщо etcd зазнає аварії одразу після надсилання успішної відповіді клієнту. Це була стара проблема (див. issue/14370), яка впливала на всі попередні випуски. Вона була вирішена в v3.4.21 і v3.5.5 за допомогою PR/14400, і виправлена на стороні raft в основній гілці (тепер release-3.6) з PR/14413.
Неузгодженість ревізій при аварійному завершенні під час дефрагментації

Якщо etcd зазнавав аварії під час операції дефрагментації, після перезапуску він міг повторно застосувати деякі записи, які вже були застосовані, що призводило до проблеми з неузгодженістю ревізій (див. обговорення в PR/14685). Ця проблема зʼявилась в v3.5.0 і її було виправлено в v3.5.6 за допомогою PR/14730.

Проблема з оновленням

Цей розділ висвітлює поширену проблему issues/19557 в оновленні etcd з v3.5 до v3.6, яка може призвести до збою процесу оновлення. Для отримання докладних інструкцій з оновлення зверніться до Оновлення etcd з v3.5 до v3.6.

Ця проблема зʼявилась в etcd v3.5.1 і її було вирішено в v3.5.20.

Головне: користувачі повинні спочатку оновитися до etcd v3.5.20 (або новішої патч-версії) перед оновленням до etcd v3.6.0; інакше оновлення може зазнати невдачі.

Для отримання додаткової інформації та технічного контексту див. upgrade_from_3.5_to_3.6_issue.

Тестування

Ми впровадили тестування надійності, щоб перевірити коректність, яка завжди була нашим основним пріоритетом. Тест відтворює трафік різних типів і обсягів на кластері etcd, одночасно впроваджуючи випадкову точку відмови, записує всі операції (включаючи запити та відповіді) і, нарешті, виконує перевірку лінійної узгодженості. Він також перевіряє, що гарантії Watch APIs не були порушені. Тестування надійності підвищує нашу впевненість у забезпеченні якості кожного випуску etcd.

Ми мігрували більшість тестів робочого процесу etcd до інфраструктури тестування Prow Kubernetes, щоб використати її переваги, такі як зручні інформаційні панелі для перегляду результатів тестування та можливість для учасників повторно запускати невдалі тести самостійно.

Платформи

Зберігаючи всі наявні підтримувані платформи, ми підвищили Linux/ARM64 до рівня підтримки Tier 1. Для отримання додаткової інформації зверніться до issues/15951. Для отримання повного списку підтримуваних платформ, див. supported-platform.

Залежності

Посібник з оновлення залежностей

Ми опублікували офіційний посібник з оновлення залежностей для основної гілки та стабільних випусків etcd. У ньому також описано, як оновити версію Go. Для отримання більш детальної інформації, будь ласка, зверніться до dependency_management. Тепер, коли цей посібник доступний, будь-хто з учасників може допомогти з оновленням залежностей.

Оновлення основних залежностей

bbolt та raft є двома основними залежностями etcd.

Обидва etcd v3.4 і v3.5 залежать від bbolt v1.3, тоді як etcd v3.6 залежить від bbolt v1.4.

Для гілок release-3.4 і release-3.5 raft включено безпосередньо в репозиторій etcd, тому etcd v3.4 і v3.5 не залежать від зовнішнього модуля raft. Починаючи з etcd v3.6, raft було переміщено до окремого репозиторію (raft), а перший самостійний реліз raft — це v3.6.0. Як наслідок, etcd v3.6.0 залежить від raft v3.6.0.

Будь ласка, дивіться таблицю нижче:

версії etcd	версії bbolt	версії raft
3.4.x	v1.3.x	N/A
3.5.x	v1.3.x	N/A
3.6.x	v1.4.x	v3.6.x

grpc-gateway@v2

Ми оновили grpc-gateway з v1 до v2 через PR/16595 в etcd v3.6.0. Це є важливим кроком до міграції на protobuf-go, другу основну версію реалізації API protocol buffers для Go.

grpc-gateway@v2 призначений для роботи з protobuf-go. Однак etcd v3.6 все ще залежить від застарілого gogo/protobuf, який насправді є реалізацією protocol buffers v1. Щоб вирішити цю несумісність, ми застосували патч до згенерованих *.pb.gw.go файлів, щоб перетворити повідомлення v1 на повідомлення v2.

grpc-ecosystem/go-grpc-middleware/providers/prometheus

Ми перейшли з застарілого (і архівованого) grpc-ecosystem/go-grpc-prometheus на grpc-ecosystem/go-grpc-middleware/providers/prometheus у PR/19195. Ця зміна забезпечує подальшу підтримку та доступ до останніх можливостей і вдосконалень в інтеграції gRPC Prometheus.

Спільнота

В спільноті etcd відбуваються захопливі події, які відображають нашу постійну прихильність до зміцнення співпраці, покращення підтримки та розвитку врядування проєктом.

etcd стає Kubernetes SIG

etcd офіційно став Kubernetes Special Interest Group: SIG-etcd. Ця зміна відображає критичну роль etcd як основного сховища даних для Kubernetes і встановлює більш структуровану та прозору основу для довгострокового керування та співпраці між проєктами. Нова SIG допоможе спростити процес прийняття рішень, узгодити плани з потребами Kubernetes, і залучити більше учасників.

Нові учасники, супровідники та рецензенти

Ми спостерігали активність, що постійно зростає, з боку учасників, що призвело до додавання трьох нових супровідників:

Їхній постійний внесок був вирішальним для просування проєкту вперед.

Ми також вітаємо двох нових рецензентів у проєкті:

Ми цінуємо їхню відданість якості коду та готовність взяти на себе ширші обовʼязки з рецензування в межах спільноти.

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

Ми сформували нову команду випуску, очолювану ivanvc та jmhbnz, спростивши процес випуску шляхом автоматизації багатьох раніше ручних етапів. Надихнувшись Kubernetes SIG Release, ми прийняли кілька найкращих практик, включаючи чітко визначені ролі команди випуску та впровадження «тіней випуску» (release shadows) для підтримки обміну знаннями та стійкості команди. Ці зміни зробили наші випуски більш плавними та надійними, дозволяючи нам підходити до кожного випуску з більшою впевненістю та послідовністю.

Представляємо etcd Operator Working Group

Щоб ще більше покращити операційну досконалість etcd, ми сформували нову робочу групу: WG-etcd-operator. Робоча група присвячена питанням забезпечення автоматичної та ефективної роботи кластерів etcd, які працюють у середовищі Kubernetes за допомогою etcd-operator.

Майбутній розвиток

v2store був визнаний застарілим з моменту виходу etcd v3.4, а прапорець --enable-v2 був повністю видалений у v3.6. Це означає, що починаючи з v3.6, більше немає способу увімкнути або використовувати v2store. Однак всередині etcd все ще ініціалізується зі спадкових знімків v2. Щоб усунути цю неузгодженість, ми плануємо змінити etcd так, щоб він ініціалізувався з v3store і відтворити записи WAL на основі consistent-index. Ця робота відстежується в issues/12913.

Однією з найпостійніших проблем залишаються великі запити діапазону з kube-apiserver, які можуть призвести до аварійних зупинок процесів через їх непередбачувану природу. Можливість потокового діапазону, спочатку описана в v3.5 release blog/Future roadmaps, залишається ідеєю, яку варто переглянути, щоб розвʼязати проблеми з великими запитами діапазону.

Для отримання додаткової інформації та майбутніх планів, будь ласка, зверніться до планів розвитку etcd.

Kubernetes v1.33: Оновлення життєвого циклу контейнерів

Wed, 14 May 2025 10:30:00 -0800

У Kubernetes v1.33 представлено декілька оновлень життєвого циклу контейнерів. Дія Sleep для хуків життєвого циклу контейнера тепер підтримує нульову тривалість сну (можливість типово увімкнена). Також зʼявилася альфа-підтримка для налаштування сигналу зупинки, що надсилається контейнерам при завершенні їхньої роботи.

У цій статті ви дізнаєтеся більше про ці нові аспекти життєвого циклу контейнера і про те, як ними користуватися.

Нульове значення для дії Sleep

У Kubernetes v1.29 введено дію Sleep для хуків життєвого циклу контейнерів PreStop і PostStart. Дія Sleep дозволяє вашим контейнерам призупиняти роботу на певний час після запуску контейнера або перед його завершенням. Це було необхідно для забезпечення простого способу керування належним завершенням роботи. До появи дії Sleep люди використовували команду sleep за допомогою дії exec у своїх хуках життєвого циклу контейнера. Якщо ви хотіли це зробити, вам потрібно було мати двійковий файл для команди sleep в образі вашого контейнера. Це важко зробити, якщо ви використовуєте сторонні образи.

Дія sleep, коли її було додано, спочатку не підтримувала тривалість сну у нуль секунд. Функція time.Sleep, яку приховано використовується дією Sleep, підтримує тривалість сну у нуль секунд. Використання відʼємного або нульового значення для часу сну призводить до негайного повернення, що призводить до невиконання дії. Ми хотіли отримати таку саму поведінку для дії sleep. Цю підтримку нульової тривалості було додано у версії 1.32 за допомогою функціональної можливості PodLifecycleSleepActionAllowZero.

Функціональна можливість PodLifecycleSleepActionAllowZero перейшла до бета-версії у версії 1.33 і тепер типово увімкнена. Оригінальна дія Sleep для хуків preStop і postStart типово увімкнена, починаючи з Kubernetes v1.30. У кластері під керуванням Kubernetes v1.33 ви можете встановити нульову тривалість для хуків життєвого циклу сну. Для кластера з типовою конфігурацією вам не потрібно вмикати жодних функціональних можливостей, щоб зробити це можливим.

Сигнали зупинки контейнерів

Такі середовища виконання контейнерів, як containerd та CRI-O, враховують інструкцію StopSignal у визначенні образу контейнера. За допомогою цієї інструкції можна вказати власний сигнал зупинки, який середовище виконання використовуватиме для завершення роботи контейнерів на основі цього образу. Налаштування сигналу зупинки спочатку не було частиною Pod API у Kubernetes. До версії Kubernetes v1.33 єдиним способом перевизначити сигнал зупинки для контейнерів було перебудувати образ контейнера з новим власним сигналом зупинки (наприклад, вказавши STOPSIGNAL у Containerfile або Dockerfile).

Функціональна можливість ContainerStopSignals, яка була додана у Kubernetes v1.33, додає сигнали зупинки до API Kubernetes. Це дозволяє користувачам вказати власний сигнал зупинки в специфікації контейнера. Сигнали зупинки додаються до API як новий життєвий цикл разом з наявними обробниками життєвого циклу PreStop та PostStart. Для того, щоб використовувати цю можливість, ми очікуємо, що в Pod буде вказана операційна система за допомогою spec.os.name. Це необхідно для того, щоб ми могли перехресно перевірити сигнал зупинки на відповідність операційній системі і переконатися, що контейнери в Pod створюються з правильним сигналом зупинки для операційної системи, для якої планується створення Pod. Для Podʼів, запланованих на вузлах Windows, допустимими сигналами зупинки є лише SIGTERM і SIGKILL. Повний список сигналів, що підтримуються на вузлах Linux, можна знайти тут.

Типова поведінка

Якщо у життєвому циклі контейнера визначено власний сигнал зупинки, то для завершення роботи контейнера буде використано сигнал, визначений у життєвому циклі, враховуючи, що середовище виконання контейнера також підтримує власні сигнали зупинки. Якщо у життєвому циклі контейнера не визначено спеціального сигналу зупинки, середовище виконання повернеться до сигналу зупинки, визначеного в образі контейнера. Якщо в образі контейнера не визначено жодного сигналу зупинки, буде використано типовий сигнал зупинки середовища виконання. Типовим сигналом є SIGTERM як для containerd, так і для CRI-O.

Розбіжність версій

Щоб ця можливість працювала належним чином, версії Kubernetes та середовища виконання контейнера повинні підтримувати сигнали зупинки контейнера. Зміни до API Kubernetes та kubelet доступні в альфа-версії, починаючи з v1.33, які можна увімкнути за допомогою функціональної можливості ContainerStopSignals. Реалізації середовища виконання контейнерів для containerd та CRI-O все ще перебувають у процесі розробки та будуть випущені найближчим часом.

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

Щоб увімкнути цю можливість, вам потрібно увімкнути функціональну можливість ContainerStopSignals в kube-apiserver та kubelet. Після того, як у вас є вузли з увімкненою функціональною можливістю, ви можете створювати Podʼи з життєвим циклом StopSignal і правильною назвою ОС, наприклад, таким чином:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  os:
    name: linux
  containers:
    - name: nginx
      image: nginx:latest
      lifecycle:
        stopSignal: SIGUSR1

Зверніть увагу, що сигнал SIGUSR1 у цьому прикладі може бути використаний лише у тому випадку, якщо Pod контейнера заплановано на вузол Linux. Отже, нам потрібно вказати spec.os.name як linux, щоб мати змогу використовувати цей сигнал. Якщо Pod планується на вузол Windows, ви зможете налаштувати лише сигнали SIGTERM і SIGKILL. Ви також не зможете вказати containers[*].lifecycle.stopSignal, якщо поле spec.os.name дорівнює nil або не встановлено.

Як долучитися?

Розвиток цієї можливості веде SIG Node. Якщо ви зацікавлені в тому, щоб допомогти розвивати цю можливість, поділитися відгуками або взяти участь у будь-яких інших поточних проєктах SIG Node, будь ласка, звʼяжіться з нами!

Ви можете звʼязатися з SIG Node кількома способами:

Ви також можете звʼязатися зі мною напряму:

GitHub: @sreeram-venkitesh
Slack: @sreeram.venkitesh

Kubernetes v1.33: Продовження переходу від Endpoints до EndpointSlices

Thu, 24 Apr 2025 10:30:00 -0800

Відтоді як EndpointSlices (KEP-752) зʼявились у версії v1.15 як alpha, а згодом стали стабільними (GA) у v1.21, API Endpoints у Kubernetes поступово втрачало актуальність. Нові можливості Service, як-от двостекова мережа та розподіл трафіку, підтримуються лише через API EndpointSlice, тож усі проксі-сервери сервісів, реалізації Gateway API та подібні контролери мусили перейти від використання Endpoints до EndpointSlices. Наразі API Endpoints існує фактично лише для того, щоб не ламати робочі навантаження та скрипти кінцевих користувачів, які досі його використовують.

Починаючи з Kubernetes 1.33, API Endpoints офіційно оголошено застарілим, і API-сервер повертатиме попередження користувачам, які читають або записують ресурси Endpoints замість використання EndpointSlices.

Зрештою, план (як описано в KEP-4974) полягає в тому, щоб змінити критерії відповідності Kubernetes так, щоб вони більше не вимагали від кластерів запускати контролер Endpoints (який генерує обʼєкти Endpoints на основі Service і Podʼів), аби уникнути роботи, яка не потрібна в більшості сучасних кластерів.

Отже, хоча згідно з політикою застарівання Kubernetes тип Endpoints, ймовірно, ніколи не буде повністю вилучено, користувачам, які досі мають робочі навантаження або скрипти, що використовують API Endpoints, слід починати їх перенесення на EndpointSlices.

Примітки щодо міграції з Endpoints до EndpointSlices

Використання EndpointSlices замість Endpoints

Для кінцевих користувачів найбільшою відмінністю між API Endpoints та API EndpointSlice є те, що кожен Service із selector має рівно один обʼєкт Endpoints (з такою ж назвою, як і сам Service), тоді як у нього може бути будь-яка кількість повʼязаних EndpointSlice:

$ kubectl get endpoints myservice
Warning: v1 Endpoints is deprecated in v1.33+; use discovery.k8s.io/v1 EndpointSlice
NAME        ENDPOINTS          AGE
myservice   10.180.3.17:443    1h

$ kubectl get endpointslice -l kubernetes.io/service-name=myservice
NAME              ADDRESSTYPE   PORTS   ENDPOINTS          AGE
myservice-7vzhx   IPv4          443     10.180.3.17        21s
myservice-jcv8s   IPv6          443     2001:db8:0123::5   21s

У цьому прикладі сервіс є двостековим (dual-stack), тому має два EndpointSlice: один для IPv4-адрес, інший — для IPv6. (API Endpoints не підтримує подвійний стек, тому обʼєкт Endpoints показує лише адреси з основного сімейства адрес кластера.) Хоча будь-який Service з кількома точками доступу може мати кілька EndpointSlice, є три основні випадки, коли ви це побачите:

EndpointSlice може представляти лише точки доступу одного сімейства IP, тож двостекові Service матимуть окремі EndpointSlice для IPv4 та IPv6.
Усі точки доступу в EndpointSlice мають бути спрямовані на однакові порти. Тож, наприклад, якщо у вас є набір Podʼів точок доступу, які слухають порт 80, і ви розгортаєте оновлення, щоб натомість вони слухали порт 8080, то поки розгортання триває, Service потребуватиме двох EndpointSlice: одного для точок доступу, що слухають порт 80, і одного для точок доступу, що слухають порт 8080.
Коли Service має понад 100 точок доступу, контролер EndpointSlice розділить їх на кілька EndpointSlice, замість того щоб обʼєднувати їх в один надмірно великий обʼєкт, як це робить контролер Endpoints.

Оскільки між Service і EndpointSlice немає передбачуваного відображення 1:1, неможливо заздалегідь дізнатися, якою буде фактична назва ресурсу (ресурсів) EndpointSlice для Service; тож замість того, щоб отримувати EndpointSlice за назвою, ви запитуєте всі EndpointSlice з міткою "kubernetes.io/service-name", що вказує на Service:

$ kubectl get endpointslice -l kubernetes.io/service-name=myservice

Подібні зміни потрібні й у Go-коді. Для Endpoints це виглядало б приблизно так:

// Отримати Endpoints з назвою `name` у просторі імен `namespace`.
endpoint, err := client.CoreV1().Endpoints(namespace).Get(ctx, name, metav1.GetOptions{})
if err != nil {
	if apierrors.IsNotFound(err) {
		// Для Service (ще?) не існує Endpoints
		...
	}
        // обробка інших помилок
	...
}

// обробка `endpoint`
...

Для EndpointSlice це буде:

// Отримати всі EndpointSlice для Service `name` у просторі імен `namespace`.
slices, err := client.DiscoveryV1().EndpointSlices(namespace).List(ctx,
	metav1.ListOptions{LabelSelector: discoveryv1.LabelServiceName + "=" + name})
if err != nil {
        // обробка помилок
	...
} else if len(slices.Items) == 0 {
	// Для Service (ще?) не існує EndpointSlice
	...
}

// обробка `slices.Items`
...

Генерація EndpointSlices замість Endpoints

Для користувачів або контролерів, які створюють обʼєкти Endpoints, перехід на EndpointSlices дещо простіший, оскільки в більшості випадків не потрібно опрацьовувати кілька sliceʼів. Достатньо оновити YAML або Go-код, щоб використовувати новий тип (який організовує інформацію дещо інакше, ніж Endpoints).

Наприклад, цей обʼєкт Endpoints:

apiVersion: v1
kind: Endpoints
metadata:
  name: myservice
subsets:
  - addresses:
      - ip: 10.180.3.17
        nodeName: node-4
      - ip: 10.180.5.22
        nodeName: node-9
      - ip: 10.180.18.2
        nodeName: node-7
    notReadyAddresses:
      - ip: 10.180.6.6
        nodeName: node-8
    ports:
      - name: https
        protocol: TCP
        port: 443

виглядатиме приблизно так:

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: myservice
  labels:
    kubernetes.io/service-name: myservice
addressType: IPv4
endpoints:
  - addresses:
      - 10.180.3.17
    nodeName: node-4
  - addresses:
      - 10.180.5.22
    nodeName: node-9
  - addresses:
      - 10.180.18.12
    nodeName: node-7
  - addresses:
      - 10.180.6.6
    nodeName: node-8
    conditions:
      ready: false
ports:
  - name: https
    protocol: TCP
    port: 443

Деякі моменти, на які слід звернути увагу:

У цьому прикладі явно вказано name, але можна використати generateName, і API-сервер сам додасть унікальний суфікс. Назва обʼєкта не має значення — важлива мітка "kubernetes.io/service-name", що вказує на Service.
Необхідно явно вказати addressType: IPv4 (або IPv6).
EndpointSlice подібний до одного елемента масиву "subsets" в Endpoints. Обʼєкт Endpoints з кількома підмножинами (subsets) зазвичай потрібно буде виразити як кілька EndpointSlice, кожен з іншими "ports".
Поля endpoints і addresses — масиви, але за домовленістю кожен масив addresses містить лише один елемент. Якщо ваш Service має кілька точок доступу, вам потрібно мати кілька елементів у масиві endpoints, кожен з одним елементом у своєму масиві addresses.
API Endpoints перелічує «готові» та «неготові» точки доступу окремо, тоді як API EndpointSlice дозволяє кожній точці доступу мати повʼязані з нею стани (як-от "ready: false").

І, звісно, після переходу на EndpointSlice можна використовувати специфічні для нього можливості, як-от підказки топології та точки доступу, що завершують роботу. Докладніше в документації до API EndpointSlice.

Kubernetes v1.33: Octarine

Wed, 23 Apr 2025 10:30:00 -0800

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

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

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

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

Тема та логотип випуску

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

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

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

Kubernetes v1.33 — це свідчення незмінної сили інновацій з відкритим кодом, де сотні учасників⁴ з усього світу працюють разом, щоб створити щось справді надзвичайне. За кожною новою функцією стоїть робота спільноти 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

KCD - Дні спільноти Kubernetes: Коста-Ріка: 3 травня 2025 року | Ередіа, Коста-Ріка
KCD - Дні спільноти Kubernetes: Гельсінкі: 6 травня 2025 року | Гельсінкі, Фінляндія
KCD - Дні спільноти Kubernetes: Техас, Остін: 15 травня 2025 року | Остін, США
KCD - Дні спільноти Kubernetes: Сеул: 22 травня 2025 року | Сеул, Південна Корея
KCD - Дні спільноти Kubernetes: Стамбул, Туреччина: 23 травня 2025 року | Стамбул, Туреччина
KCD - Дні спільноти Kubernetes: Район затоки Сан-Франциско: 28 травня 2025 року | Сан-Франциско, США

Червень 2025

KCD - Дні спільноти Kubernetes: Нью-Йорк: 4 червня 2025 року | Нью-Йорк, США
KCD - Дні спільноти Kubernetes: Чехія та Словаччина: 5 червня 2025 року | Братислава, Словаччина
KCD - Дні спільноти Kubernetes: Бенгалуру: 6 червня 2025 року | Бенгалуру, Індія
KubeCon + CloudNativeCon China 2025: 10–11 червня 2025 року | Гонконг
KCD - Дні спільноти Kubernetes: Антигуа-Гватемала: 14 червня 2025 року | Антигуа-Гватемала, Гватемала
KubeCon + CloudNativeCon Japan 2025: 16–17 червня 2025 року | Токіо, Японія
KCD - Дні спільноти Kubernetes: Нігерія, Африка: 19 червня 2025 року | Нігерія, Африка

Липень 2025

KCD - Дні спільноти Kubernetes: Утрехт: 4 липня 2025 року | Утрехт, Нідерланди
KCD - Дні спільноти Kubernetes: Тайбей: 5 липня 2025 року | Тайбей, Тайвань
KCD - Дні спільноти Kubernetes: Ліма, Перу: 19 липня 2025 року | Ліма, Перу

Серпень 2025

KubeCon + CloudNativeCon India 2025: 6–7 серпня 2025 року | Гайдарабад, Індія
KCD - Дні спільноти Kubernetes: Колумбія: 29 серпня 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

Попередній огляд Kubernetes v1.33

Wed, 26 Mar 2025 10:30:00 -0800

З наближенням випуску 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

Kubernetes v1.32: Penelope

Wed, 11 Dec 2024 00:00:00 +0000

Редактори: Matteo Bianchi, Edith Puclla, William Rizzo, Ryota Sawada, Rashan Smith

Анонсуємо випуск Kubernetes v1.32: Penelope!

Як і попередні випуски, Kubernetes v1.32 представляє нові стабільні, бета- та альфа-функції. Послідовне постачання високоякісних випусків підкреслює силу нашого циклу розробки та активну підтримку нашої спільноти. Загалом цей випуск містить 44 удосконалення. З них 13 перейшли до стабільної версії, 12 — до бета-версії, а 19 зʼявилися в альфа-версії.

Тема та логотип випуску

Темою випуску Kubernetes v1.32 є «Penelope».

Якщо Kubernetes з давньогрецької означає «лоцман», то в цьому випуску ми відштовхуємося від цього походження і розмірковуємо про останні 10 років Kubernetes і наші досягнення: кожен цикл випуску — це подорож, і так само як Пенелопа в «Одіссеї» ткала 10 років, щоночі розпускаючи частину того, що зробила за день, кожен випуск додає нові функції та вилучає інші, хоча в нашому випадку з набагато чіткішою метою — постійно покращувати Kubernetes. Оскільки v1.32 є останнім випуском у році, коли Kubernetes відзначає своє перше десятиріччя, ми хотіли вшанувати всіх тих, хто був частиною глобального екіпажу Kubernetes, що мандрує хмарними (cloud-native) морями, долаючи небезпеки та виклики: тож продовжуймо разом ткати майбутнє Kubernetes.

Оновлення останніх ключових функцій

Примітка щодо удосконалень DRA

У цьому випуску, як і в попередньому, проєкт Kubernetes продовжує пропонувати низку удосконалень динамічного виділення ресурсів (Dynamic Resource Allocation, DRA), ключового компонента системи керування ресурсами Kubernetes. Ці удосконалення спрямовані на підвищення гнучкості та ефективності виділення ресурсів для робочих навантажень, які потребують спеціалізованого обладнання, такого як графічні процесори (GPU), FPGA та мережеві адаптери. Ці функції особливо корисні для таких сценаріїв використання, як машинне навчання або застосунки високопродуктивних обчислень. Основна частина, що забезпечує підтримку структурованих параметрів DRA, перейшла до бета-версії.

Покращення якості життя на вузлах та оновлення sidecar-контейнерів

SIG Node має такі основні новини, що виходять за межі KEP:

Можливість сторожового таймера (watchdog) systemd тепер використовується для перезапуску kubelet, коли його перевірка стану не вдається, одночасно обмежуючи максимальну кількість перезапусків протягом певного періоду часу. Це підвищує надійність роботи kubelet. Докладніше дивіться pull request #127566.
У випадках, коли виникає помилка відстрочки витягування образу (image pull back-off), повідомлення, що відображається у статусі Podʼа, покращено, щоб зробити його зрозумілішим для людини і вказати подробиці про те, чому Pod перебуває у такому стані. Коли виникає відстрочка витягування образу, помилка додається до поля status.containerStatuses[*].state.waiting.message у специфікації Podʼа зі значенням ImagePullBackOff у полі reason. Ця зміна надає вам більше контексту і допомагає визначити першопричину проблеми. Докладніше дивіться pull request #127918.
Функція sidecar-контейнерів має перейти до стабільної версії у v1.33. Щоб переглянути решту робочих завдань та відгуки користувачів, дивіться коментарі в тікеті #753.

Ключові функції, що переходять до стабільної версії

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

Селектори полів для Custom Resource

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

Ця робота була виконана в рамках KEP #4358, силами SIG API Machinery.

Підтримка визначення розміру томів у памʼяті

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

Ця робота була виконана в рамках KEP #1967, силами SIG Node.

Покращення токена привʼязаного службового облікового запису

Включення імені вузла до тверджень (claims) токенів службових облікових записів дозволяє користувачам використовувати цю інформацію під час авторизації та допуску (ValidatingAdmissionPolicy). Крім того, це покращення не дає обліковим даним службових облікових записів стати шляхом для підвищення привілеїв для вузлів.

Ця робота була виконана в рамках KEP #4193 силами SIG Auth.

Структурована конфігурація авторизації

В API-сервері можна налаштувати декілька авторизаторів, щоб забезпечити структуровані рішення щодо авторизації, з підтримкою умов відповідності CEL у вебхуках. Ця робота була виконана в рамках KEP #3221 силами SIG Auth.

Автоматичне видалення PVC, створених StatefulSet

PersistentVolumeClaims (PVC), створені StatefulSet, автоматично видаляються, коли вони більше не потрібні, забезпечуючи при цьому збереження даних під час оновлень StatefulSet і обслуговування вузлів. Ця функція спрощує керування сховищем для StatefulSet і зменшує ризик появи «осиротілих» PVC.

Ця робота була виконана в рамках KEP #1847 силами SIG Apps.

Ключові функції, що переходять до бета-версії

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

Механізм managed-by в Job API

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

Ця робота була виконана в рамках KEP #4368, силами SIG Apps.

Дозвіл анонімної автентифікації лише для налаштованих точок доступу

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

Ця робота була виконана в рамках KEP #4633, силами SIG Auth.

Функції зворотного виклику для кожного втулка для точного повторного додавання в чергу в удосконаленнях kube-scheduler

Ця функція підвищує пропускну здатність планування завдяки ефективнішим рішенням щодо повторних спроб планування за допомогою функцій зворотного виклику для кожного втулка (QueueingHint). Тепер усі втулки мають QueueingHints.

Ця робота була виконана в рамках KEP #4247, силами SIG Scheduling.

Відновлення після збою розширення тому

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

Ця робота була виконана в рамках KEP #1790, силами SIG Storage.

Знімок групи томів

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

Ця робота була виконана в рамках KEP #3476, силами SIG Storage.

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

Основна частина динамічного виділення ресурсів (Dynamic Resource Allocation, DRA), підтримка структурованих параметрів, перейшла до бета-версії. Це дозволяє kube-scheduler та Cluster Autoscaler моделювати виділення заявок безпосередньо, без потреби у сторонньому драйвері. Тепер ці компоненти можуть передбачати, чи можуть запити на ресурси бути виконані на основі поточного стану кластера, без фактичної фіксації виділення. Усуваючи потребу в сторонньому драйвері для перевірки або тестування виділень, ця функція покращує планування і прийняття рішень щодо розподілу ресурсів, роблячи процеси планування і масштабування ефективнішими.

Ця робота була виконана в рамках KEP #4381, силами WG Device Management (міжфункціональної команди, що складається з SIG Node, SIG Scheduling та SIG Autoscaling).

Авторизація за селекторами міток і полів

Селектори міток і полів можна використовувати у рішеннях щодо авторизації. Авторизатор вузлів автоматично використовує це, щоб дозволити вузлам отримувати перелік (list) або відстежувати (watch) лише їхні Podʼи. Авторизатори вебхуків можна оновити, щоб обмежувати запити на основі використаного селектора міток або полів.

Ця робота була виконана в рамках KEP #4601 силами SIG Auth.

Ключові нові функції в альфа-версії

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

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

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

Ця робота була виконана в рамках KEP #4832 силами SIG Scheduling.

Мутаційні політики допуску з використанням виразів CEL

Ця функція використовує створення обʼєктів у CEL та стратегії JSON Patch у поєднанні з алгоритмами злиття Server Side Apply. Це спрощує визначення політик, зменшує конфлікти мутацій і підвищує продуктивність контролю допуску, закладаючи основу для більш надійних, розширюваних фреймворків політик у Kubernetes.

API-сервер Kubernetes тепер підтримує мутаційні політики допуску (Mutating Admission Policies) на основі Common Expression Language (CEL), що забезпечує легку та ефективну альтернативу мутаційним вебхукам допуску. Завдяки цьому удосконаленню адміністратори можуть використовувати CEL для оголошення мутацій, таких як встановлення міток, встановлення типових значень полів або додавання sidecar-контейнерів, за допомогою простих декларативних виразів. Такий підхід зменшує операційну складність, усуває потребу у вебхуках та інтегрується безпосередньо з kube-apiserver, пропонуючи швидшу та надійнішу обробку мутацій в межах процесу.

Ця робота була виконана в рамках KEP #3962 силами SIG API Machinery.

Специфікації ресурсів на рівні Podʼа

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

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

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

Ця робота була виконана в рамках KEP #2837 силами SIG Node.

Дозвіл нульового значення для дії sleep хука PreStop

Це удосконалення надає можливість встановити нульову тривалість sleep для хука життєвого циклу PreStop у Kubernetes, пропонуючи гнучкіший варіант без операцій (no-op) для перевірки та налаштування ресурсів. Раніше спроба визначити нульове значення для дії sleep призводила до помилок валідації, що обмежувало її використання. З цим оновленням користувачі можуть налаштувати нульову тривалість як допустиме значення sleep, що дозволяє негайне виконання та завершення там, де це потрібно.

Це удосконалення є зворотно сумісним, його впроваджено як функцію, яку вмикають за бажанням (opt-in) і якою керує функціональна можливість PodLifecycleSleepActionAllowZero. Ця зміна особливо корисна для сценаріїв, що вимагають використання хуків PreStop для перевірки або обробки вебхуків допуску, не вимагаючи фактичної тривалості sleep. Завдяки узгодженню з можливостями функції Go time.After це оновлення спрощує конфігурацію і розширює можливості використання для робочих навантажень Kubernetes.

Ця робота була виконана в рамках KEP #4818 силами SIG Node.

DRA: Стандартизовані дані мережевого інтерфейсу для статусу заявки на ресурс

Це удосконалення додає нове поле, яке дозволяє драйверам повідомляти конкретні дані про стан пристрою для кожного виділеного обʼєкта в ResourceClaim. Воно також встановлює стандартизований спосіб представлення інформації про мережеві пристрої.

Ця робота була виконана в рамках KEP #4817, силами SIG Network.

Нові точки доступу statusz та flagz для основних компонентів

Ви можете ввімкнути дві нові HTTP-точки доступу, /statusz і /flagz, для основних компонентів. Вони покращують можливості налагодження кластера, надаючи інформацію про те, з якою версією (наприклад, версією Golang) працює компонент, а також про час його роботи і з якими прапорцями командного рядка його було запущено; це полегшує діагностику як проблем виконання, так і проблем конфігурації.

Ця робота була виконана в рамках KEP #4827 та KEP #4828 силами SIG Instrumentation.

Windows дає відсіч!

Додано підтримку належного завершення роботи Windows-вузлів у кластерах Kubernetes. До цього випуску Kubernetes надавав функціональність належного завершення роботи для вузлів Linux, але не мав еквівалентної підтримки для Windows. Це удосконалення дозволяє kubelet на Windows-вузлах правильно обробляти події вимкнення системи. Завдяки цьому Podʼи, запущені на Windows-вузлах, належно завершуються, що дозволяє перепланувати робочі навантаження без порушень. Це покращення підвищує надійність і стабільність кластерів, що включають вузли Windows, особливо під час планового обслуговування або будь-яких оновлень системи.

Крім того, додано підтримку спорідненості процесорів і памʼяті для вузлів Windows з вузлами, з поліпшеннями в диспетчері процесорів, диспетчері памʼяті і диспетчері топології.

Ця робота була виконана відповідно в рамках KEP #4802 та KEP #4885 силами SIG Windows.

Переходи, застарівання та вилучення у 1.32

Переходи до стабільної версії

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

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

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

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

Відмова від старої реалізації DRA

Удосконалення #3063 запровадило динамічне виділення ресурсів (DRA) у Kubernetes 1.26.

Однак у Kubernetes v1.32 цей підхід до DRA буде суттєво змінено. Код, повʼязаний з оригінальною реалізацією, буде вилучено, залишивши KEP #4381 як «нову» базову функціональність.

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

Це вилучення дозволить Kubernetes більш передбачувано обробляти нові вимоги до апаратного забезпечення та заявки на ресурси, оминаючи складнощі численних викликів API до kube-apiserver і назад.

Щоб дізнатися більше, дивіться тікет удосконалення #3063.

Вилучення API

У Kubernetes v1.32 вилучено один API:

Вилучено версію API flowcontrol.apiserver.k8s.io/v1beta3 для FlowSchema та PriorityLevelConfiguration. Щоб підготуватися до цього, ви можете відредагувати наявні маніфести та переписати клієнтське програмне забезпечення для використання версії flowcontrol.apiserver.k8s.io/v1 API, доступної починаючи з v1.29. Усі наявні збережені обʼєкти доступні через новий API. Серед помітних змін у flowcontrol.apiserver.k8s.io/v1beta3 — поле PriorityLevelConfiguration spec.limited.nominalConcurrencyShares типово отримує значення 30 лише тоді, коли його не вказано, а явне значення 0 не змінюється на 30.

Для отримання додаткової інформації зверніться до посібника із застарівання API.

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

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

Доступність

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

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

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

Ми хотіли б подякувати всій команді випуску за години напруженої роботи над тим, щоб випуск Kubernetes v1.32 дійшов до нашої спільноти. Склад команди випуску варіюється від тих, хто вперше став помічником (shadow), до керівників команд, які повертаються з досвідом, здобутим протягом кількох циклів випуску. Особлива подяка нашому керівнику випуску, Frederico Muñoz, за те, що він так витончено керував командою випуску і вирішував будь-які питання з максимальною ретельністю, забезпечуючи гладке та ефективне проведення цього випуску. І останнє, але не менш важливе: велика подяка всім учасникам випуску — як керівникам, так і помічникам — а також наступним SIG за приголомшливу роботу і результати, досягнуті за ці 14 тижнів роботи над випуском:

SIG Docs — за фундаментальну підтримку в рецензуванні документації та блогів, а також за постійну співпрацю з командами комунікацій (Comms) і документації (Docs) випуску;
SIG k8s Infra та SIG Testing — за видатну роботу з підтримки фреймворку тестування в належному стані, а також усіх необхідних компонентів інфраструктури;
SIG Release та всім менеджерам випуску — за неймовірну підтримку, надану протягом усього процесу оркестрування випуску, та вирішення навіть найскладніших питань витончено і своєчасно.

Швидкість реалізації проєкту

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

У циклі випуску v1.32, який тривав 14 тижнів (з 9 вересня по 11 грудня), ми бачили внески в Kubernetes від 125 різних компаній і 559 окремих осіб на момент написання цієї статті.

У всій екосистемі Cloud Native ця цифра зростає до 433 компаній із загальною кількістю учасників 2441. Це на 7% більше загального внеску порівняно з циклом попереднього випуску, а кількість залучених компаній зросла на 14%, що свідчить про значний інтерес до проєктів Cloud Native і сильну спільноту, яка стоїть за ними.

Джерело цих даних:

Під внеском ми маємо на увазі, коли хтось робить коміт, рецензує код, коментує, створює тікет або PR, рецензує PR (включно з блогами і документацією) або коментує тікети і PR.

Якщо ви зацікавлені у внеску, відвідайте сторінку Початок роботи на нашому сайті для учасників.

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

Новини про події

Ознайомтеся з майбутніми подіями Kubernetes та cloud-native з березня по червень 2025 року, зокрема з KubeCon та KCD. Залишайтеся в курсі подій та долучайтеся до спільноти Kubernetes.

Березень 2025

KCD - Kubernetes Community Days: Beijing, China: У березні | Пекін, Китай
KCD - Kubernetes Community Days: Guadalajara, Mexico: 16 березня 2025 року | Гвадалахара, Мексика
KCD - Kubernetes Community Days: Rio de Janeiro, Brazil: 22 березня 2025 року | Ріо-де-Жанейро, Бразилія

Квітень 2025

KubeCon + CloudNativeCon Europe 2025: 1-4 квітня 2025 року | Лондон, Велика Британія
KCD - Kubernetes Community Days: Budapest, Hungary: 23 квітня 2025 року | Будапешт, Угорщина
KCD - Kubernetes Community Days: Chennai, India: 26 квітня 2025 року | Ченнаї, Індія
KCD - Kubernetes Community Days: Auckland, New Zealand: 28 квітня 2025 року | Окленд, Нова Зеландія

Травень 2025

KCD - Kubernetes Community Days: Helsinki, Finland: 6 травня 2025 року | Гельсінкі, Фінляндія
KCD - Kubernetes Community Days: San Francisco, USA: 8 травня 2025 року | Сан-Франциско, США
KCD - Kubernetes Community Days: Austin, USA: 15 травня 2025 року | Остін, США
KCD - Kubernetes Community Days: Seoul, South Korea: 22 травня 2025 року | Сеул, Південна Корея
KCD - Kubernetes Community Days: Istanbul, Turkey: 23 травня 2025 року | Стамбул, Туреччина
KCD - Kubernetes Community Days: Heredia, Costa Rica: 31 травня 2025 року | Ередія, Коста-Ріка
KCD - Kubernetes Community Days: New York, USA: У травні | Нью-Йорк, США

Червень 2025

KCD - Kubernetes Community Days: Bratislava, Slovakia: 5 червня 2025 року | Братислава, Словаччина
KCD - Kubernetes Community Days: Bangalore, India: 6 червня 2025 року | Бангалор, Індія
KubeCon + CloudNativeCon China 2025: 10-11 червня 2025 року | Гонконг
KCD - Kubernetes Community Days: Antigua Guatemala, Guatemala: 14 червня 2025 року | Антигуа-Гватемала, Гватемала
KubeCon + CloudNativeCon Japan 2025: 16-17 червня 2025 року | Токіо, Японія
KCD - Kubernetes Community Days: Nigeria, Africa: 19 червня 2025 року | Нігерія, Африка

Найближчий вебінар про випуск

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

Долучайтеся

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

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

Попередній огляд Kubernetes v1.32

Fri, 08 Nov 2024 00:00:00 +0000

З наближенням дати випуску Kubernetes v1.32 проєкт розвивається та вдосконалюється. Функції можуть бути визнані застарілими, вилучені або замінені на кращі для загального покращення проєкту.

Тут описані деякі заплановані зміни для випуску Kubernetes v1.32, які, на думку команди випуску, вам слід знати для продовження обслуговування вашого середовища Kubernetes та підтримки в актуальному стані з останніми змінами. Інформація, наведена нижче, базується на поточному стані випуску v1.32 і може змінитися до фактичної дати випуску.

Процес вилучення та застарівання API Kubernetes

Проєкт Kubernetes має добре задокументовану політику застарівання для функцій. Ця політика зазначає, що стабільні API можуть бути визнані застарілими лише тоді, коли доступна новіша, стабільна версія цього API, і що API мають мінімальний термін служби для кожного рівня стабільності. Застарілий API, який був позначений для вилучення в майбутньому випуску Kubernetes, продовжуватиме функціонувати до вилучення (щонайменше один рік з моменту застарівання). Його використання призведе до показу попередження. Вилучені API більше недоступні в поточній версії, тому вам потрібно перейти на використання заміни.

Загальнодоступні (GA) або стабільні версії API можуть бути позначені як застарілі, але не повинні бути вилучені в межах основної версії Kubernetes.
Бета або попередні версії API повинні підтримуватися протягом 3 випусків після застарівання.
Альфа або експериментальні версії API можуть бути вилучені в будь-якому випуску без попереднього повідомлення про застарівання; цей процес може стати відкликанням у випадках, коли вже існує інша реалізація для тієї ж функції.

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

Примітка щодо відкликання старої реалізації DRA

Удосконалення #3063 запровадило динамічне виділення ресурсів (DRA — Dynamic Resource Allocation) в Kubernetes 1.26.

Однак у Kubernetes v1.32 цей підхід до DRA буде значно змінено. Код, повʼязаний з початковою реалізацією, буде вилучено, залишаючи KEP #4381 як "нову" базову функціональність.

Рішення змінити поточний підхід виникло через його несумісність з автоматичним масштабуванням кластера, оскільки доступність ресурсів була непрозорою, ускладнюючи прийняття рішень як для Cluster Autoscaler, так і для контролерів. Нещодавно додана модель структурованих параметрів (Structured Parameters) замінює цю функціональність.

Це вилучення дозволить Kubernetes обробляти нові апаратні вимоги та заявки на ресурси більш передбачувано, оминаючи складнощі постійного обміну викликами API з kube-apiserver.

Будь ласка, також перегляньте тікет удосконалення #3063, щоб дізнатися більше.

Вилучення API

Заплановано лише одне вилучення API для Kubernetes v1.32:

Версія API flowcontrol.apiserver.k8s.io/v1beta3 для FlowSchema та PriorityLevelConfiguration була вилучена. Щоб підготуватися до цього, ви можете відредагувати свої поточні маніфести та переписати клієнтське програмне забезпечення для використання версії flowcontrol.apiserver.k8s.io/v1 API, доступної з v1.29. Всі поточні збережені обʼєкти доступні через новий API. Помітні зміни в flowcontrol.apiserver.k8s.io/v1beta3 включають те, що поле spec.limited.nominalConcurrencyShares у PriorityLevelConfiguration типово встановлюється на 30 лише тоді, коли його не вказано, а явно вказане значення 0 не змінюється на 30.

Для отримання додаткової інформації, будь ласка, зверніться до керівництва із застарівання API.

Попередній огляд Kubernetes v1.32

Наступний список удосконалень, ймовірно, буде включений у випуск v1.32. Це не є зобовʼязанням, і вміст випуску може змінитися.

Ще більше удосконалень DRA!

У цьому випуску, як і в попередньому, проєкт Kubernetes продовжує пропонувати низку удосконалень для динамічного виділення ресурсів (DRA), ключового компонента системи управління ресурсами Kubernetes. Ці удосконалення спрямовані на підвищення гнучкості та ефективності виділення ресурсів для робочих навантажень, які потребують спеціалізованого обладнання, такого як GPU, FPGA та мережеві адаптери. Цей випуск вводить покращення, включаючи додавання статусу справності ресурсів до статусу Podʼа, як описано в KEP #4680.

Додавання статусу справності ресурсів до статусу Podʼа

Важко дізнатися, коли Pod використовує пристрій, який вийшов з ладу або тимчасово несправний. KEP #4680 пропонує показувати справність пристрою через status Podʼа, що полегшує усунення несправностей у разі аварійного завершення Podʼів.

Windows повертається!

KEP #4802 додає підтримку для належного завершення роботи вузлів Windows у кластерах Kubernetes. До цього випуску Kubernetes надавав функціональність належного завершення роботи вузлів для вузлів Linux, але не мав еквівалентної підтримки для Windows. Це удосконалення дозволяє kubelet на вузлах Windows правильно обробляти події завершення роботи системи. Таким чином, забезпечується належне завершення роботи Podʼів на вузлах Windows, що дозволяє повторно запланувати робочі навантаження без порушень. Це покращення підвищує надійність та стабільність кластерів, які включають вузли Windows, особливо під час планового обслуговування або будь-яких оновлень системи.

Дозвіл на використання спеціальних символів у змінних середовища

З переходом цього удосконалення у стан бета-версії, Kubernetes тепер дозволяє використовувати майже всі друковані символи ASCII (за винятком "=") в іменах змінних середовища. Ця зміна усуває обмеження, які раніше накладалися на імена змінних, сприяючи ширшому прийняттю Kubernetes, задовольняючи різні потреби застосунків. Послаблена перевірка буде типово увімкнена через функціональну можливість RelaxedEnvironmentVariableValidation, що дозволить користувачам легко використовувати змінні середовища без суворих обмежень і підвищить гнучкість для розробників, які працюють із застосунками на кшталт .NET Core, що потребують спеціальних символів у своїх конфігураціях.

Kubernetes буде обізнаним про поведінку LoadBalancer

KEP #1860 переходить до GA, вводячи поле ipMode для Service з type: LoadBalancer, яке може бути встановлено на "VIP" або "Proxy". Це удосконалення спрямоване на покращення взаємодії балансувальників навантаження хмарних провайдерів з kube-proxy і є зміною, прозорою для кінцевого користувача. Поточна поведінка kube-proxy зберігається при використанні "VIP", де kube-proxy обробляє балансування навантаження. Використання "Proxy" призводить до того, що трафік надсилається безпосередньо до балансувальника навантаження, надаючи хмарним провайдерам більший контроль над залежністю від kube-proxy; це означає, що ви можете побачити покращення продуктивності вашого балансувальника навантаження для деяких хмарних провайдерів.

Повторна генерація імен для ресурсів

Це удосконалення покращує обробку конфліктів імен для ресурсів Kubernetes, створених з полем generateName. Раніше, якщо виникав конфлікт імен, API-сервер повертав помилку 409 HTTP Conflict, і клієнти мали вручну повторювати запит. З цим оновленням API-сервер автоматично повторює генерацію нового імені до семи разів у разі конфлікту. Це значно знижує ймовірність зіткнення, забезпечуючи безперебійну генерацію до 1 мільйона імен з ймовірністю конфлікту менше 0,1%, що забезпечує більшу стійкість для великих робочих навантажень.

Хочете дізнатися більше?

Нові функції та застарівання також оголошуються в примітках до випуску Kubernetes. Ми офіційно оголосимо, що нового в Kubernetes v1.32 як частину CHANGELOG для цього випуску.

Ви можете побачити оголошення про зміни в примітках до випуску для:

DIY: Створіть власну хмару з Kubernetes (Частина 2)

Fri, 05 Apr 2024 07:35:00 +0000

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

Ми будемо говорити про такі технології, як KubeVirt, LINSTOR і Kube-OVN.

Але спочатку пояснімо, навіщо потрібні віртуальні машини та чому не можна просто використовувати docker-контейнери для побудови хмари? Причина в тому, що контейнери не забезпечують достатнього рівня ізоляції. Хоча ситуація з кожним роком покращується, ми часто стикаємося з вразливостями, які дозволяють вийти з пісочниці контейнера і підвищити привілеї в системі.

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

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

Технології віртуалізації в Kubernetes

Існує кілька різних технологій, які приносять віртуалізацію у світ Kubernetes: KubeVirt та Kata Containers є найпопулярнішими з них. Але варто знати, що вони працюють по-різному.

Kata Containers реалізує CRI (Container Runtime Interface) та забезпечує додатковий рівень ізоляції для стандартних контейнерів, запускаючи їх у віртуальних машинах. Але вони працюють в одному кластері Kubernetes.

Схема, що показує, як забезпечується ізоляція контейнерів шляхом запуску контейнерів у віртуальних машинах за допомогою Kata Containers

KubeVirt дозволяє запускати традиційні віртуальні машини за допомогою API Kubernetes. Віртуальні машини KubeVirt запускаються як звичайні процеси Linux у контейнерах. Іншими словами, у KubeVirt контейнер використовується як пісочниця для запуску процесів віртуальної машини (QEMU). Це чітко видно на малюнку нижче, якщо подивитися, як реалізовано живу міграцію віртуальних машин у KubeVirt. Коли міграція потрібна, віртуальна машина переміщується з одного контейнера до іншого.

Схема, що показує живу міграцію віртуальної машини з одного контейнера до іншого у KubeVirt

Існує також альтернативний проєкт — Virtink, який реалізує легку віртуалізацію за допомогою Cloud-Hypervisor і спочатку орієнтований на запуск віртуальних кластерів Kubernetes за допомогою Cluster API.

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

KubeVirt легко встановлюється і дозволяє запускати віртуальні машини безпосередньо з коробки, використовуючи containerDisk — ця можливість дозволяє зберігати та розповсюджувати образи VM безпосередньо як образи OCI з реєстру образів контейнерів. Віртуальні машини з containerDisk добре підходять для створення робочих вузлів Kubernetes та інших віртуальних машин, які не потребують збереження стану.

Для керування постійними даними KubeVirt пропонує окремий інструмент, Containerized Data Importer (CDI). Він дозволяє клонувати PVC і наповнювати їх даними з базових образів. CDI необхідний, якщо ви хочете автоматично виділяти постійні томи для ваших віртуальних машин, і він також потрібен для драйвера KubeVirt CSI, який використовується для обробки запитів на постійні томи з кластерів Kubernetes орендарів.

Але спочатку вам потрібно вирішити, де і як ви будете зберігати ці дані.

Сховище для VM в Kubernetes

З впровадженням CSI (Container Storage Interface) став доступний широкий спектр технологій, які інтегруються з Kubernetes. Насправді KubeVirt повністю використовує інтерфейс CSI, узгоджуючи вибір сховища для віртуалізації з вибором сховища для самого Kubernetes. Однак є нюанси, які вам потрібно врахувати. На відміну від контейнерів, які зазвичай використовують стандартну файлову систему, блокові пристрої є більш ефективними для віртуальних машин.

Хоча інтерфейс CSI в Kubernetes дозволяє запитувати обидва типи томів: файлові системи та блокові пристрої, важливо перевірити, чи підтримує це ваш бекенд сховища.

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

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

Схема, що показує взаємодію зовнішнього сховища даних з обчислювальними вузлами

Зовнішні рішення для зберігання даних часто є популярними в корпоративних системах, оскільки таке сховище часто надається зовнішнім постачальником, який займається його експлуатацією. Інтеграція з Kubernetes включає лише невеликий компонент, встановлений у кластері — драйвер CSI. Цей драйвер відповідає за виділення томів у цьому сховищі та підключення їх до Podʼів, які запускає Kubernetes. Втім, подібні рішення для зберігання даних можуть бути реалізовані й з використанням технологій з відкритим вихідним кодом. Одним з популярних рішень є TrueNAS на основі драйвера democratic-csi.

Діаграма, що показує локальне зберігання даних на обчислювальних вузлах

З іншого боку, гіперконвергентні системи часто реалізуються з використанням локального сховища (коли не потрібна реплікація) та програмно визначених сховищ, які часто встановлюються безпосередньо в Kubernetes, таких як Rook/Ceph, OpenEBS, Longhorn, LINSTOR та інші.

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

Гіперконвергентна система має свої переваги. Наприклад, локальність даних: коли ваші дані зберігаються локально, доступ до таких даних є швидшим. Але є і недоліки, оскільки така система зазвичай складніша в керуванні та обслуговуванні.

В Ænix ми прагнули надати готове до використання рішення, яке можна було б використовувати без необхідності купувати та налаштовувати додаткове зовнішнє сховище, і яке було б оптимальним з погляду швидкості та використання ресурсів. LINSTOR став цим рішенням. Перевірені часом та популярні в промисловості технології, такі як LVM і ZFS, як бекенд, дають упевненість у тому, що дані надійно зберігаються. Реплікація на основі DRBD неймовірно швидка і споживає невелику кількість обчислювальних ресурсів.

Для встановлення LINSTOR в Kubernetes існує проєкт Piraeus, який вже надає готове блокове сховище для використання з KubeVirt.

Примітка:

У випадку, якщо ви використовуєте Talos Linux, як ми описали в попередній статті, вам потрібно буде заздалегідь активувати необхідні модулі ядра і налаштувати piraeus, як описано в інструкції.

Мережа для віртуальних машин Kubernetes

Попри схожий інтерфейс — CNI, мережева архітектура в Kubernetes насправді є набагато складнішою та зазвичай складається з багатьох незалежних компонентів, які не повʼязані безпосередньо один з одним. Насправді ви можете розділити мережу Kubernetes на чотири рівні, які описані нижче.

Мережева інфраструктура вузлів (мережа дата-центру)

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

Діаграма, що показує роль мережі вузлів (мережі дата-центру) у схемі мережі Kubernetes

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

Мережа Podʼів

Це мережа, яку забезпечує ваш CNI-втулок. Завдання CNI-втулка полягає в забезпеченні прозорого зʼєднання між усіма контейнерами та вузлами в кластері. Більшість CNI-втулків реалізують пласку мережу, з якої окремі блоки IP-адрес виділяються для використання на кожному вузлі.

Діаграма, що показує роль мережі Podʼів (CNI-втулок) у схемі мережі Kubernetes

На практиці ваш кластер може мати кілька CNI-втулків, керованих Multus. Цей підхід часто використовується у рішеннях віртуалізації на основі KubeVirt — Rancher та OpenShift. Основний CNI-втулок використовується для інтеграції з сервісами Kubernetes, тоді як додаткові CNI-втулки використовуються для реалізації приватних мереж (VPC) та інтеграції з фізичними мережами вашого дата-центру.

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

Ще одним аспектом, який слід враховувати при запуску віртуальних машин у Kubernetes, є потреба в керуванні IP-адресами (IPAM), особливо для вторинних інтерфейсів, які надає Multus. Це зазвичай керується DHCP-сервером, що працює у вашій інфраструктурі. Додатково, призначення MAC-адрес для віртуальних машин може керуватись за допомогою Kubemacpool.

Проте на нашій платформі ми вирішили піти іншим шляхом і повністю покладаємося на Kube-OVN. Цей CNI-втулок базується на OVN (Open Virtual Network), який спочатку був розроблений для OpenStack і надає повне мережеве рішення для віртуальних машин у Kubernetes, з можливістю керування IP-адресами та MAC-адресами через Custom Resources, підтримує живу міграцію зі збереженням IP-адрес між вузлами, і дозволяє створювати VPC для фізичного розділення мереж між орендарями.

У Kube-OVN ви можете призначати окремі підмережі всьому простору імен або підключати їх як додаткові мережеві інтерфейси за допомогою Multus.

Мережа сервісів (Services Network)

Окрім CNI-втулка, Kubernetes також має мережу сервісів, яка в основному потрібна для виявлення сервісів. На відміну від традиційних віртуальних машин, Kubernetes спочатку розроблений для запуску Podʼів із випадковою адресою. І мережа сервісів забезпечує зручну абстракцію (стабільні IP-адреси та DNS-імена), яка завжди буде спрямовувати трафік до правильного Podʼа. Такий підхід також часто використовується з віртуальними машинами в хмарах, хоча їх IP-адреси зазвичай є статичними.

Діаграма, що показує роль мережі сервісів (втулок мережі сервісів) у схемі мережі Kubernetes

Реалізацію мережі сервісів у Kubernetes здійснює втулок мережі сервісів. Стандартною реалізацією є kube-proxy, який використовується в більшості кластерів. Але наразі ця функціональність може бути забезпечена як частина CNI-втулка. Найбільш передову реалізацію пропонує проєкт Cilium, який може працювати в режимі заміни kube-proxy.

Cilium базується на технології eBPF, яка дозволяє ефективно розвантажувати мережевий стек Linux, що підвищує продуктивність і безпеку в порівнянні з традиційними методами на основі iptables.

На практиці Cilium і Kube-OVN можуть бути легко інтегровані для забезпечення єдиного рішення, що пропонує безшовну багатокористувацьку мережу для віртуальних машин, а також досконалі мережеві політики та обʼєднану функціональність мережі сервісів.

Зовнішній балансувальник навантаження

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

Для bare-metal кластерів Kubernetes доступні кілька балансувальників навантаження: MetalLB, kube-vip, LoxiLB, також Cilium та Kube-OVN забезпечують вбудовану реалізацію.

Роль зовнішнього балансувальника навантаження полягає в наданні стабільної адреси, доступної зовні, і спрямуванні зовнішнього трафіку до мережі сервісів. Втулок мережі сервісів направить його до ваших Podʼів та віртуальних машин, як зазвичай.

Діаграма, що показує роль зовнішнього балансувальника навантаження у схемі мережі Kubernetes

У більшості випадків налаштування балансувальника навантаження на bare-metal досягається шляхом створення плаваючої IP-адреси на вузлах у кластері та її оголошення назовні за допомогою протоколів ARP/NDP або BGP.

Вивчивши різні варіанти, ми вирішили, що MetalLB є найпростішим і найнадійнішим рішенням, хоча ми не вимагаємо суворого використання лише його.

Ще однією перевагою є те, що в режимі L2 speaker-и MetalLB постійно перевіряють стан сусідів, виконуючи перевірки життєздатності за допомогою протоколу memberlist. Це дозволяє реалізувати автоматичне перемикання у разі відмови, яке працює незалежно від панелі управління Kubernetes.

Висновок

Цим завершується наш огляд віртуалізації, зберігання та мереж в Kubernetes. Усі згадані технології доступні та вже налаштовані на платформі Cozystack, де ви можете їх спробувати без обмежень.

У наступній статті я розповім, як на основі цього ви можете реалізувати створення повнофункціональних кластерів Kubernetes одним натисканням кнопки.

DIY: Створіть власну хмару з Kubernetes (Частина 1)

Fri, 05 Apr 2024 07:30:00 +0000

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

Чи думали ви коли-небудь про створення власної хмари? Я впевнений, що так. Але чи можливо це зробити, використовуючи лише сучасні технології та підходи, не виходячи за межі затишної екосистеми Kubernetes? Наш досвід у розробці Cozystack змусив нас глибоко заглибитись у це питання.

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

Навіщо ускладнювати речі? — адже Kubernetes вже має все необхідне для запуску кластерів Kubernetes для орендарів на цьому етапі.

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

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

Цією статтею я починаю серію, яка складатиметься з кількох частин:

Частина 1: Підготовка основи для вашої хмари. Виклики, з якими стикаються під час підготовки та експлуатації Kubernetes на "голому" залізі, та готовий рецепт для забезпечення інфраструктури.
Частина 2: Мережі, сховища та віртуалізація. Як перетворити Kubernetes на інструмент для запуску віртуальних машин і що для цього потрібно.
Частина 3: Cluster API і як почати розгортання кластерів Kubernetes натисканням однієї кнопки. Як працює автомасштабування, динамічне надання томів і балансувальники навантаження.

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

Почнемо з розуміння основної переваги Kubernetes та того, як він змінив підхід до використання хмарних ресурсів.

Важливо розуміти, що використання Kubernetes у хмарі та на "голому" залізі відрізняється.

Kubernetes у хмарі

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

Діаграма, що показує Kubernetes у хмарі, де балансування навантаження та зберігання виконуються поза кластером

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

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

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

Такий підхід є базовим при використанні Kubernetes у хмарах. Причина цього досить очевидна: чим простіша система, тим вона стабільніша, і саме за цю простоту ви купуєте Kubernetes у хмарі.

Kubernetes на "голому" залізі

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

Діаграма, що показує Kubernetes на "голому" залізі, де балансування навантаження та зберігання виконуються всередині кластера

Судіть самі: у хмарі, щоб оновити вузол, ви зазвичай видаляєте віртуальну машину (або навіть використовуєте команду kubectl delete node) і дозволяєте вашому інструменту керування вузлами створити новий на основі незмінного образу. Новий вузол приєднається до кластера і "просто працюватиме" як вузол; дотримуючись дуже простого та поширеного шаблону у світі Kubernetes. Багато кластерів замовляють нові віртуальні машини кожні кілька хвилин, просто тому, що вони можуть використовувати дешевші spot-екземпляри. Однак коли у вас є фізичний сервер, ви не можете просто видалити та відтворити його, по-перше, тому що він часто запускає деякі кластерні служби, зберігає дані, і процес його оновлення значно складніший.

Існують різні підходи до розвʼязання цієї проблеми, починаючи від оновлень на місці, як це роблять kubeadm, kubespray та k3s, до повної автоматизації забезпечення фізичних вузлів за допомогою Cluster API та Metal3.

Мені подобається гібридний підхід, який пропонує Talos Linux, де вся ваша система описується в одному конфігураційному файлі. Більшість параметрів цього файлу можна застосувати без перезавантаження або перестворення вузла, включаючи версію компонентів панелі управління Kubernetes. При цьому зберігається максимальна декларативність Kubernetes. Такий підхід мінімізує непотрібний вплив на кластерні сервіси при оновленні «голих» вузлів. У більшості випадків вам не потрібно буде мігрувати віртуальні машини та перебудовувати файлову систему кластера при незначних оновленнях.

Підготовка бази для майбутньої хмари

Отже, ви вирішили створити власну хмару. Щоб почати, потрібно створити базовий шар. Вам слід подумати не лише про те, як ви встановите Kubernetes на свої сервери, а й про те, як ви будете його оновлювати та підтримувати. Врахуйте, що вам доведеться думати про такі речі, як оновлення ядра, встановлення необхідних модулів, а також пакунків і оновлень безпеки. Тепер вам потрібно подумати про набагато більше, ніж зазвичай при використанні готового Kubernetes у хмарі.

Звісно, ви можете використовувати стандартні дистрибутиви, такі як Ubuntu або Debian, або ж розглянути спеціалізовані, як Flatcar Container Linux, Fedora Core і Talos Linux. Кожен з них має свої переваги та недоліки.

Що стосується нас, в Ænix, ми використовуємо досить специфічні модулі ядра, такі як ZFS, DRBD і OpenvSwitch, тому вирішили піти шляхом створення системного образу з усіма необхідними модулями заздалегідь. У цьому випадку Talos Linux виявився найбільш зручним для нас. Наприклад, достатньо такої конфігурації, щоб створити системний образ з усіма необхідними модулями ядра:

arch: amd64
platform: metal
secureboot: false
version: v1.6.4
input:
  kernel:
    path: /usr/install/amd64/vmlinuz
  initramfs:
    path: /usr/install/amd64/initramfs.xz
  baseInstaller:
    imageRef: ghcr.io/siderolabs/installer:v1.6.4
  systemExtensions:
    - imageRef: ghcr.io/siderolabs/amd-ucode:20240115
    - imageRef: ghcr.io/siderolabs/amdgpu-firmware:20240115
    - imageRef: ghcr.io/siderolabs/bnx2-bnx2x:20240115
    - imageRef: ghcr.io/siderolabs/i915-ucode:20240115
    - imageRef: ghcr.io/siderolabs/intel-ice-firmware:20240115
    - imageRef: ghcr.io/siderolabs/intel-ucode:20231114
    - imageRef: ghcr.io/siderolabs/qlogic-firmware:20240115
    - imageRef: ghcr.io/siderolabs/drbd:9.2.6-v1.6.4
    - imageRef: ghcr.io/siderolabs/zfs:2.1.14-v1.6.4
output:
  kind: installer
  outFormat: raw

Потім ми використовуємо інструмент командного рядка docker для створення образу ОС:

cat config.yaml | docker run --rm -i -v /dev:/dev --privileged "ghcr.io/siderolabs/imager:v1.6.4" -

І в результаті ми отримуємо контейнерний образ Docker з усім необхідним, який можна використовувати для встановлення Talos Linux на наші сервери. Ви можете зробити те саме; цей образ міститиме всі необхідні прошивки та модулі ядра.

Але виникає питання: як доставити свіжостворений образ на ваші вузли?

Я давно розмірковував над ідеєю завантаження через PXE. Наприклад, проєкт Kubefarm, про який я писав в статті два роки тому, був повністю побудований на цьому підході. Але, на жаль, він не допомагає розгорнути ваш перший батьківський кластер, який міститиме інші. Тож зараз у вас є рішення, яке допоможе зробити це саме за допомогою підходу PXE.

По суті, все, що вам потрібно зробити, це запустити тимчасово DHCP і PXE сервери всередині контейнерів. Тоді ваші вузли завантажаться з вашого образу, і ви можете використовувати простий скрипт у стилі Debian, щоб допомогти вам ініціалізувати вузли.

Вихідний код для цього сценарію talos-bootstrap доступний на GitHub.

Цей сценарій дозволяє розгорнути Kubernetes на "голому" залізі за пʼять хвилин і отримати kubeconfig для доступу до нього. Однак попереду ще багато невирішених питань.

Доставка системних компонентів

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

Традиційно це вирішується шляхом встановлення чартів Helm у ваш кластер. Ви можете зробити це, виконуючи команди helm install локально, але цей підхід стає незручним, коли ви хочете відстежувати оновлення, і якщо у вас кілька кластерів і ви хочете, щоб вони залишалися однорідними. Насправді існує багато способів зробити це декларативно. Для подолання цієї задачі я рекомендую використовувати найкращі практики GitOps. Я маю на увазі інструменти, такі як ArgoCD та FluxCD.

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

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

Здійснивши одноразову інсталяцію FluxCD у вашому новому кластері та налаштувавши його відповідним чином, ви дозволяєте йому автоматично розгорнути всі необхідні компоненти. Це дозволить вашому кластеру оновити себе до потрібного стану. Наприклад, після встановлення нашої платформи ви побачите такі попередньо налаштовані Helm чарти з системними компонентами:

NAMESPACE                        NAME                        AGE    READY   STATUS
cozy-cert-manager                cert-manager                4m1s   True    Release reconciliation succeeded
cozy-cert-manager                cert-manager-issuers        4m1s   True    Release reconciliation succeeded
cozy-cilium                      cilium                      4m1s   True    Release reconciliation succeeded
cozy-cluster-api                 capi-operator               4m1s   True    Release reconciliation succeeded
cozy-cluster-api                 capi-providers              4m1s   True    Release reconciliation succeeded
cozy-dashboard                   dashboard                   4m1s   True    Release reconciliation succeeded
cozy-fluxcd                      cozy-fluxcd                 4m1s   True    Release reconciliation succeeded
cozy-grafana-operator            grafana-operator            4m1s   True    Release reconciliation succeeded
cozy-kamaji                      kamaji                      4m1s   True    Release reconciliation succeeded
cozy-kubeovn                     kubeovn                     4m1s   True    Release reconciliation succeeded
cozy-kubevirt-cdi                kubevirt-cdi                4m1s   True    Release reconciliation succeeded
cozy-kubevirt-cdi                kubevirt-cdi-operator       4m1s   True    Release reconciliation succeeded
cozy-kubevirt                    kubevirt                    4m1s   True    Release reconciliation succeeded
cozy-kubevirt                    kubevirt-operator           4m1s   True    Release reconciliation succeeded
cozy-linstor                     linstor                     4m1s   True    Release reconciliation succeeded
cozy-linstor                     piraeus-operator            4m1s   True    Release reconciliation succeeded
cozy-mariadb-operator            mariadb-operator            4m1s   True    Release reconciliation succeeded
cozy-metallb                     metallb                     4m1s   True    Release reconciliation succeeded
cozy-monitoring                  monitoring                  4m1s   True    Release reconciliation succeeded
cozy-postgres-operator           postgres-operator           4m1s   True    Release reconciliation succeeded
cozy-rabbitmq-operator           rabbitmq-operator           4m1s   True    Release reconciliation succeeded
cozy-redis-operator              redis-operator              4m1s   True    Release reconciliation succeeded
cozy-telepresence                telepresence                4m1s   True    Release reconciliation succeeded
cozy-victoria-metrics-operator   victoria-metrics-operator   4m1s   True    Release reconciliation succeeded

Висновок

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

У наступних статтях я розповім про те як підготувати Kubernetes для запуску віртуальних машин та як запускати кластери Kubernetes натисканням кнопки. Залишайтеся з нами, буде цікаво!

Огляд Kubernetes v1.30

Tue, 12 Mar 2024 00:00:00 +0000

Швидкий огляд: зміни у Kubernetes v1.30

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

Щоб підготувати вас до офіційного випуску, ось короткий огляд удосконалень, про які ми найбільше хочемо розповісти!

Основні зміни для Kubernetes v1.30

Структуровані параметри для динамічного виділення ресурсів (KEP-4381)

Динамічне виділення ресурсів було додано до Kubernetes у версії v1.26 у режимі альфа. Воно визначає альтернативу традиційному API пристроїв для запиту доступу до ресурсів сторонніх постачальників. За концепцією, динамічне виділення ресурсів використовує параметри для ресурсів, що є абсолютно непрозорими для ядра Kubernetes. Цей підхід створює проблему для Cluster Autoscaler (CA) чи будь-якого контролера вищого рівня, який повинен приймати рішення для групи Podʼів (наприклад, планувальник завдань). Він не може симулювати ефект виділення чи звільнення заявок з плином часу. Інформацію для цього можуть надавати лише драйвери DRA сторонніх постачальників.

Структуровані параметри для динамічного виділення ресурсів — це розширення оригінальної реалізації, яке розвʼязує цю проблему, створюючи фреймворк для підтримки параметрів заявок, що є більш прозорими. Замість обробки семантики всіх параметрів заявок самостійно, драйвери можуть керувати ресурсами та описувати їх, використовуючи конкретну "структуровану модель", заздалегідь визначену Kubernetes. Це дозволить компонентам, які обізнані з цією "структурованою моделлю", приймати рішення щодо цих ресурсів без залучення зовнішнього контролера. Наприклад, планувальник може швидко обробляти заявки без зайвої комунікації з драйверами динамічного виділення ресурсів. Робота, виконана для цього релізу, зосереджена на визначенні необхідного фреймворку для активації різних "структурованих моделей" та реалізації моделі "пойменованих ресурсів". Ця модель дозволяє перераховувати окремі екземпляри ресурсів та, на відміну від традиційного API пристроїв, додає можливість вибору цих екземплярів індивідуально за атрибутами.

Підтримка своп-памʼяті на вузлах (KEP-2400)

У Kubernetes v1.30 підтримка своп-памʼяті на вузлах Linux отримує значущі зміни в способі її функціонування, з основним акцентом на покращенні стабільності системи. В попередніх версіях Kubernetes функція NodeSwap була типово вимкненою, а при увімкненні використовувала поведінку UnlimitedSwap. З метою досягнення кращої стабільності, поведінка UnlimitedSwap (яка може компрометувати стабільність вузла) буде видалена у версії v1.30.

Оновлена, все ще бета-версія підтримки своп на вузлах Linux буде типово доступною. Однак типовою поведінкою буде запуск вузла в режимі NoSwap (а не UnlimitedSwap). У режимі NoSwap kubelet підтримує роботу на вузлі, де активний простір своп, але Podʼи не використовують жодного page-файлу. Для того, щоб kubelet працював на цьому вузлі, вам все ще потрібно встановити --fail-swap-on=false. Однак велика зміна стосується іншого режиму: LimitedSwap. У цьому режимі kubelet фактично використовує page-файл на вузлі та дозволяє Podʼам виділяти деяку частину їхньої віртуальної памʼяті. Контейнери (і їхні батьківські Podʼи) не мають доступу до своп поза їхнім обмеженням памʼяті, але система все ще може використовувати простір своп, якщо він доступний.

Група Kubernetes Node (SIG Node) також оновить документацію, щоб допомогти вам зрозуміти, як використовувати оновлену реалізацію, на основі відгуків від кінцевих користувачів, учасників та широкої спільноти Kubernetes.

Для отримання додаткових відомостей про підтримку своп на вузлах Linux в Kubernetes, прочитайте попередній пост блогу чи документацію про своп на вузлах.

Підтримка просторів імен користувачів в Pod (KEP-127)

Простори імен користувачів — це функція лише для Linux, яка краще ізолює Podʼи для запобігання або помʼякшення кількох важливих CVEs із високим/критичним рейтингом, включаючи CVE-2024-21626, опубліковану у січні 2024 року. У Kubernetes 1.30 підтримка просторів імен користувачів переходить у бета-версію і тепер підтримує Podʼи з томами та без них, власні діапазони UID/GID та багато іншого!

Конфігурація структурованої авторизації (KEP-3221)

Підтримка конфігурації структурованої авторизації переходить у бета-версію та буде типово увімкненою. Ця функція дозволяє створювати ланцюги авторизації з кількома вебхуками із чітко визначеними параметрами, які перевіряють запити в певному порядку та надають деталізований контроль — такий, як явна відмова у випадку невдач. Використання конфігураційного файлу навіть дозволяє вказати правила CEL для попередньої фільтрації запитів, перш ніж вони будуть відправлені до вебхуків, допомагаючи вам запобігти непотрібним викликам. API-сервер також автоматично перезавантажує ланцюг авторизатора при зміні конфігураційного файлу.

Вам необхідно вказати шлях до конфігурації авторизації, використовуючи аргумент командного рядка --authorization-config. Якщо ви хочете продовжувати використовувати аргументи командного рядка замість конфігураційного файлу, вони продовжать працювати як є. Щоб отримати доступ до нових можливостей вебхуків авторизації, таких як кілька вебхуків, політика невдачі та правила попередньої фільтрації, перейдіть до використання параметрів у файлі --authorization-config. З версії Kubernetes 1.30 формат конфігураційного файлу є бета-рівнем, і потрібно вказувати лише --authorization-config, оскільки feature gate вже увімкнено. Приклад конфігурації із всіма можливими значеннями наведено в документації з авторизації. Докладніше читайте в документації з авторизації.

Автомасштабування Podʼів на основі ресурсів контейнера (KEP-1610)

Горизонтальне автомасштабування Podʼів на основі метрик ContainerResource перейде у стабільний стан у версії v1.30. Це нова функціональність для HorizontalPodAutoscaler дозволяє налаштовувати автоматичне масштабування на основі використання ресурсів для окремих контейнерів, а не загального використання ресурсів для всіх контейнерів у Podʼі. Докладні відомості можна знайти у нашій попередній статті або в метриках ресурсів контейнера.

CEL для керування допуском (KEP-3488)

Інтеграція Common Expression Language (CEL) для керування допуском у Kubernetes вводить більш динамічний та виразний спосіб оцінки запитів на допуск. Ця функція дозволяє визначати та застосовувати складні, деталізовані політики безпосередньо через API Kubernetes, підвищуючи безпеку та здатність до управління без втрати продуктивності чи гнучкості.

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

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

pkgs.k8s.io: Представляємо репозиторії пакунків від спільноти Kubernetes

Tue, 15 Aug 2023 20:00:00 +0000

Від імені Kubernetes SIG Release, я дуже радий представити репозиторії програмного забезпечення від спільноти Kubernetes для пакунків Debian та RPM: pkgs.k8s.io! Нові репозиторії пакунків є заміною для репозиторіїв, що надаються Google (apt.kubernetes.io та yum.kubernetes.io), які ми використовували з Kubernetes v1.5.

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

ℹ️ Оновлення (26 березня 2024): застарілі репозиторії, що надаються Google, були прибрані 4 березня 2024. Більше неможливо встановлювати пакунки Kubernetes із застарілих репозиторіїв, що надаються Google. Перегляньте оголошення про припинення підтримки для отримання додаткової інформації про цю зміну.

Що вам потрібно знати про нові репозиторії пакунків?

(оновлено 12 січня 2024 та 26 березня 2024)

Це не автоматична зміна; вам потрібно вручну перейти з використання репозиторію, що надається Google, на репозиторії, що належать спільноті Kubernetes. Дивіться як перейти далі в цьому оголошенні для інформації про міграцію та інструкцій.
Застарілі репозиторії, що надаються Google, було прибрано 4 березня 2024. Більше неможливо встановлювати пакунки Kubernetes із застарілих репозиторіїв, що надаються Google. Ці репозиторії були визнані застарілими з 31 серпня 2023, та заморожені з 13 вересня 2023. Перегляньте оголошення про припинення підтримки для отримання додаткової інформації про цю зміну.
Застарілі репозиторії, що надаються Google, будуть прибрані у січні 2024. Ці репозиторії були визнані застарілими з 31 серпня 2023, та заморожені з 13 вересня 2023. Перегляньте оголошення про припинення підтримки для отримання додаткової інформації про цю зміну.
Наявні пакунки в застарілих репозиторіях будуть доступні на невизначений час. Однак, проєкт Kubernetes не може гарантувати, як довго це буде. Застарілі репозиторії та їх вміст можуть бути видалені в будь-який час у майбутньому без додаткового попередження. Застарілі репозиторії пакунків зникнуть у січні 2024. Застарілі репозиторії, що надаються Google, були прибрані 4 березня 2024.
Оскільки нові релізи не будуть публікуватися в застарілих репозиторіях після 13 вересня 2023, ви не зможете оновитися до будь-якого патча або мінорного релізу, зробленого з тієї дати і далі, якщо ви не перейдете на нові репозиторії пакунків Kubernetes. ~~Тим не менш, ми рекомендуємо переходити на нові репозиторії пакунків Kubernetes якнайшвидше.~~ Перехід на нові репозиторії пакунків Kubernetes необхідний для отримання офіційних пакунків Kubernetes.
Нові репозиторії пакунків Kubernetes містять пакунки, починаючи з тих версій Kubernetes, які все ще підтримувалися, коли спільнота взяла на себе збірку пакунків. Це означає, що нові репозиторії пакунків мають пакунки Linux для всіх релізів Kubernetes, починаючи з v1.24.0.
Kubernetes не має офіційних пакунків Linux, доступних для попередніх релізів Kubernetes; однак, ваш дистрибутив Linux може надавати власні пакунки.
Існує окремий репозиторій пакунків для кожної мінорної версії Kubernetes. При оновленні до іншої мінорної версії, ви повинні памʼятати, що деталі репозиторію пакунків також змінюються. Перегляньте посібник Зміна репозиторію пакунків Kubernetes для отримання інформації про кроки, які вам потрібно виконати під час оновлення мінорної версії Kubernetes.

Чому ми представляємо нові репозиторії пакунків?

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

Публікація пакунків у репозиторій, що надається Google, є ручним процесом, який може виконуватися лише командою співробітників Google, Google Build Admins. Команда менеджерів релізів Kubernetes є дуже різноманітною, особливо щодо часових поясів, у яких ми працюємо. З огляду на це обмеження, нам доводиться дуже ретельно планувати кожен реліз, щоб забезпечити наявність як менеджера релізів, так і Google Build Admin для виконання релізу.

Інша проблема полягає в тому, що у нас є лише один репозиторій пакунків. Через це, ми не могли публікувати пакунки для передрелізних версій (alpha, beta та rc). Це ускладнювало тестування передрелізних версій Kubernetes для всіх, хто зацікавлений був це робити. Зворотний звʼязок, який ми отримуємо від людей, що тестують ці релізи, є критичним для забезпечення найкращої якості релізів, тому ми хочемо зробити тестування цих релізів якомога простішим. Крім того, наявність лише одного репозиторію обмежувала нас щодо публікації залежностей, таких як cri-tools та kubernetes-cni.

Незважаючи на всі ці проблеми, ми дуже вдячні Google та Google Build Admins за їх участь, підтримку та допомогу всі ці роки!

Як працюють нові репозиторії пакунків?

Нові репозиторії пакунків надаються за адресою pkgs.k8s.io для пакунків Debian та RPM. На цей час цей домен вказує на CloudFront CDN, що працює на основі кошика S3, у якому містяться репозиторії та пакунки. Однак, ми плануємо розгорнути додаткові дзеркала в майбутньому, даючи можливість іншим компаніям допомогти нам з обслуговуванням пакунків.

Пакунки збираються та публікуються платформою OpenBuildService (OBS). Після тривалого періоду оцінки різних рішень, ми прийняли рішення використовувати OpenBuildService як платформу для управління нашими репозиторіями та пакунками. По-перше, OpenBuildService є відкритою платформою, що використовується великою кількістю проєктів з відкритим кодом та компаній, таких як openSUSE, VideoLAN, Dell, Intel та інші. OpenBuildService має багато можливостей, що роблять його дуже гнучким та легким для інтеграції з нашими поточними інструментами випусків релізів. Він також дозволяє нам збирати пакунки подібним чином, як для репозиторію, що надається Google, щоб процес міграції був якомога плавнішим.

SUSE спонсорує проєкт Kubernetes надаючи доступ до свого еталонного розгортання OpenBuildService (build.opensuse.org) та технічну підтримку для інтеграції OBS з нашими процесами випусків релізів.

Ми використовуємо екземпляр OBS від SUSE для збірки та публікації пакунків. При збірці нового релізу, наші інструменти автоматично надсилають необхідні артефакти та специфікації пакунків до build.opensuse.org. Це запускає процес збірки, який збиратиме пакунки для всіх підтримуваних архітектур (AMD64, ARM64, PPC64LE, S390X). Наприкінці, згенеровані пакунки будуть автоматично надіслані до кошика S3, що належить спільноті, роблячи їх доступними для всіх користувачів.

Ми хочемо скористатися цією можливістю, щоб подякувати SUSE за дозвіл використовувати build.opensuse.org та їх щедру підтримку для здійснення цієї інтеграції!

Які значні відмінності між репозиторіями, що надаються Google, та репозиторіями пакунків Kubernetes?

Існує три значні відмінності, про які ви повинні знати:

Існує окремий репозиторій для кожної мінорної версії Kubernetes. Наприклад, репозиторій з назвою core:/stable:/v1.28 містить лише пакунки для стабільних релізів Kubernetes v1.28. Це означає, що ви можете встановити v1.28.0 з цього репозиторію, але не можете встановити v1.27.0 або будь-яку іншу мінорну версію крім v1.28. При оновленні до іншої мінорної версії, вам потрібно додати новий репозиторій та опціонально видалити старий
Існує різниця в тому, які версії пакунків cri-tools та kubernetes-cni доступні в кожному репозиторії Kubernetes
- Ці два пакунки є залежностями для kubelet та kubeadm
- Репозиторії Kubernetes для v1.24 до v1.27 мають ті самі версії цих пакунків, що й репозиторій, що надається Google
- Репозиторії Kubernetes для v1.28 та далі будуть публікувати лише версії, що використовуються цією мінорною версією Kubernetes
  - Говорячи про v1.28, лише kubernetes-cni 1.2.0 та cri-tools v1.28 будуть доступні в репозиторії для Kubernetes v1.28
  - Подібно для v1.29, ми плануємо публікувати лише cri-tools v1.29 та ту версію kubernetes-cni, що буде використовуватися Kubernetes v1.29
Частина ревізії версії пакунка (частина -00 у 1.28.0-00) тепер автоматично генерується платформою OpenBuildService та має інший формат. Ревізія тепер у форматі -x.y, наприклад 1.28.0-1.1

Чи впливає це якимось чином на наявні репозиторії, що надаються Google?

(оновлено 26 березня 2024)

Застарілі репозиторії, що надаються Google, були прибрані 4 березня 2024. Більше неможливо встановлювати пакунки Kubernetes із застарілих репозиторіїв, що надаються Google. Перегляньте оголошення про припинення підтримки для отримання додаткової інформації про цю зміну.

Репозиторій, що надається Google, та всі пакунки, опубліковані в ньому, будуть продовжувати працювати так само, як і раніше. Немає змін у тому, як ми збираємо та публікуємо пакунки в репозиторій, що надається Google, всі нововведені зміни впливають лише на пакунки, опубліковані в репозиторіях, що належать спільноті.

Однак, як згадувалося на початку цього допису в блозі, ми плануємо припинити публікацію пакунків у репозиторій, що надається Google, у майбутньому.

Як перейти на репозиторії пакунків від спільноти Kubernetes?

Debian, Ubuntu та операційні системи, що використовують `apt`/`apt-get`

Замініть визначення репозиторію apt, щоб apt вказував на новий репозиторій замість репозиторію, що надається Google. Переконайтеся, що замінили мінорну версію Kubernetes у команді нижче на мінорну версію, яку ви зараз використовуєте:
```
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /" | sudo tee /etc/apt/sources.list.d/kubernetes.list
```
Завантажте публічний ключ підпису для репозиторіїв пакунків Kubernetes. Той самий ключ підпису використовується для всіх репозиторіїв, тому ви можете ігнорувати версію в URL:
```
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
```
Оновлення: У релізах старіших за Debian 12 та Ubuntu 22.04, теки /etc/apt/keyrings типово немає, її слід створити перед виконанням команди curl.
Оновіть індекс пакунків apt:
```
sudo apt-get update
```

CentOS, Fedora, RHEL та операційні системи, що використовують `rpm`/`dnf`

Замініть визначення репозиторію yum, щоб yum вказував на новий репозиторій замість репозиторію, що надається Google. Переконайтеся, що замінили мінорну версію Kubernetes у команді нижче на мінорну версію, яку ви зараз використовуєте:
```
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.28/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
EOF
```

Де я можу отримати пакунки для версій Kubernetes до v1.24.0?

(оновлено 26 березня 2024 року)

Для Kubernetes v1.24 і новіших версій пакунки Linux для компонентів Kubernetes доступні для завантаження через офіційні репозиторії пакунків Kubernetes. Kubernetes не публікує жодних пакунків програмного забезпечення для релізів Kubernetes старіших за v1.24.0; однак, ваш дистрибутив Linux може надавати власні пакунки. Крім того, ви можете безпосередньо завантажити бінарні файли замість використання пакунків. Наприклад, дивіться інструкції Without a package manager у документі "Встановлення kubeadm".

Чи можу я повернутися до репозиторію, що надається Google, після міграції до репозиторіїв Kubernetes?

(оновлено 26 березня 2024 року)

Застарілі репозиторії, що надаються Google, припинили роботу 4 березня 2024 року, тому більше неможливо повернутися до застарілих репозиторіїв, що надаються Google.

Загалом, так. Просто виконайте ті самі кроки, що й під час міграції, але використовуйте параметри для репозиторію, що надається Google. Ви можете знайти ці параметри в документі, такому як "Встановлення kubeadm".

Чому немає стабільного списку доменів/IP? Чому я не можу обмежити завантаження пакунків?

Наш план для pkgs.k8s.io полягає в тому, щоб зробити його перенаправлювачем до набору бекендів (дзеркал пакунків) на основі розташування користувача. Характер цієї зміни означає, що користувач, який завантажує пакунок, може бути перенаправлений до будь-якого дзеркала в будь-який час. З огляду на архітектуру та наші плани щодо підключення додаткових дзеркал у найближчому майбутньому, ми не можемо надати список IP-адрес або доменів, які ви можете додати до списку дозволених.

Обмежувальні механізми контролю, такі як проксі man-in-the-middle або мережеві політики, що обмежують доступ до конкретного списку IP/доменів, перестануть працювати після цієї зміни. Для цих сценаріїв ми рекомендуємо віддзеркалювати пакунки релізу до локального репозиторію пакунків, над яким ви маєте повний контроль.

Що робити, якщо я виявив якусь аномалію з новими репозиторіями?

Якщо ви зіткнулися з будь-якою проблемою з новими репозиторіями пакунків Kubernetes, будь ласка, створіть тікет в репозиторії kubernetes/release.

Kubernetes Blog

Від робочої групи до SIG Architecture: у центрі уваги AI Conformance

Знайомство

Програма, робоча група, підпроєкт: яких форм набуває AI Conformance

Від робочої групи до підпроєкту SIG Architecture

AI Conformance і Kubernetes

Завершальні зауваження

Оголошуємо робочу групу Workload Conformance

Навіщо потрібен спільний стандарт для робочих навантажень

Що розробить робоча група

Як організовано роботу

Долучайтеся

Чому мій Kubernetes Job досі в черзі? Відстеження допуску Kueue в Headlamp

Підготовка

Спершу відокремте допуск від планування Podʼів

Шлях усунення несправностей із Headlamp на першому місці

Крок 1. Відкрийте режим перегляду Workloads

Крок 2. Прочитайте статус, стани та події

Крок 3. Порівняйте запит Workload із його призначенням

Крок 4. Перейдіть за посиланням на LocalQueue

Крок 5. Перевірте ємність і використання ClusterQueue

Крок 6. За потреби перевірте ResourceFlavor і Cohort

Чого ми навчилися, не залишаючи Headlamp

Якщо Workload допущено — перемикайтеся на інші режими

Повторюваний чекліст Headlamp

Що Headlamp замінює під час цього розслідування

Необовʼязково: відтворіть сценарій очікування

Поточні обмеження альфа-версії

Розроблено в межах наставництва LFX

Спробуйте та поділіться відгуками

Перехід на cgroup v2 у Kubernetes: що вам потрібно знати

Застарівання cgroup v1

Обмеження cgroup v1 та покращення з cgroup v2

Памʼять active_file не вважається доступною памʼяттю

Оновлення Memory QoS у Kubernetes v1.36

Обробка OOM з урахуванням контейнера

Підтримка rootless

Що ще?

Перетворення ваги CPU у новіших OCI-середовищах виконання

Оновлення ресурсів на місці

Впровадження cgroup версії 2

Вимоги

Оновлення ядра, що стосуються cgroup v2

Конфігурація cgroup-драйвера

Інструменти та команди для усунення несправностей

Як перевірити, чи ліміт CPU або памʼяті Podʼа успішно застосовано до файлу cgroup?

Подальше читання

Kubernetes v1.37: Захист зберігання контейнерів через параметри bind mount та режими EmptyDir

Основи Linux: зберігання та дозволи

Прапорці bind mount

Дозволи теки та sticky-біт

Причини для вдосконалень

Приклади використання в реальних умовах

Приклад 1: Впровадження параметрів bind mount

Приклад 2: Режим дозволів тому emptyDir зі sticky-бітом

Перевірка можливостей у Linux

Перевірка noexec

Перевірка sticky-біту

Важливі деталі

Як долучитись?

Kubernetes v1.37: Менеджери ресурсів на рівні Pod переходять у бета

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

Що нового у бета-версії

Початок роботи та надання відгуків

Kubernetes v1.37: Витіснення планувальником для зміни розміру Podʼів на місці (Alpha)

Проблема відкладеної («deferred») зміни розміру

Чому це важливо

Архітектурна механіка: Як це працює

Централізоване відстеження планувальником

Межа витіснення на одному вузлі

Безпека резервування ресурсів

Розділення зон відповідальності та критичний допуск

Керування конкурентними оновленнями та станами гонитви

Конфігурація витіснення на рівні вузла

Спробуйте це!

Міні-посібник: Спостереження за витісненням планувальника для зміни розміру на місці в дії

1. Створіть kind-кластер з увімкненим витісненням планувальника для зміни розміру на місці

Примітка:

2. Створіть PriorityClasses та розгорніть Podʼи

3. Запит на in-place scale-up

Памʼять `active_file` не вважається доступною памʼяттю

Приклад 2: Режим дозволів тому `emptyDir` зі sticky-бітом

`SELinuxMount` та `SELinuxChangePolicy`

Нова стратегія `Recreate` для розгортання StatefulSet

Проксі користувацького простору (userspace) для `localhost` NodePort для `nftables`

`maxUnavailable` для StatefulSets знову стандартно увімкнено