Блог

• Kubernetes v1.32: Penelope
• Попередній огляд Kubernetes v1.32
• DIY: Створіть власну хмару з Kubernetes (Частина 3)
• DIY: Створіть власну хмару з Kubernetes (Частина 2)
• DIY: Створіть власну хмару з Kubernetes (Частина 1)
• Огляд Kubernetes v1.30

Kubernetes v1.32: Penelope

Редактори: 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, яка блукає хмарними морями, долаючи небезпеки та виклики: нехай ми продовжуємо творити майбутнє Kubernetes разом.

Оновлення останніх ключових функцій

Примітка про вдосконалення DRA

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

Покращення якості життя на вузлах та оновлення контейнерів sidecar

SIG Node має наступні основні моменти, які виходять за рамки KEPs:

1. Функція сторожового таймера systemd тепер використовується для перезапуску kubelet, коли перевірка стану не вдається, одночасно обмежуючи максимальну кількість перезапусків протягом певного періоду часу. Це підвищує надійність роботи kubelet. Більш детальну інформацію можна знайти в pull request #127566.

2. У випадках, коли виникає помилка витягування образу, повідомлення, що відображається у статусі podʼів, було покращено, щоб зробити його більш зручним для користувача і вказати деталі про те, чому pod перебуває у такому стані. Коли виникає помилка витягування образу, вона додається до поля status.containerStatuses[*].state.waiting.message у специфікації Pod зі значенням ImagePullBackOff у полі reason. Ця зміна надає вам більше контексту і допомагає визначити першопричину проблеми. Докладніші відомості наведено у pull request #127918.

3. Функція контейнерів sidecar планується до випуску у статусі Stable у версії 1.33. Щоб переглянути решту робочих елементів та відгуки користувачів, дивіться коментарі у тікеті #753.

Функції, що перейшли у стан Stable

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

Перемикачі полів Custom Resource

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

Ця робота була виконана в рамках KEP #4358, силами SIG API Machinery.

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

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

Ця робота була виконана в рамках KEP #1967, силами SIG Node.

Покращення токену привʼязаного службового облікового запису

Включення імені вузла до вимог токенів службових облікових записів дозволяє користувачам використовувати цю інформацію під час авторизації та допуску (ValidatingAdmissionPolicy). Крім того, це покращення унеможливлює використання облікових даних службових облікових записів для підвищення привілеїв для вузлів.

Ця робота була виконана в рамках KEP #4193 силами SIG Auth.

Структурована конфігурація авторизації

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

Ця робота була виконана в рамках KEP #3221 силами SIG Auth.

Автоматичне видалення PVC, створених StatefulSet

PersistentVolumeClaims (PVC), створені StatefulSet, автоматично видаляються, коли вони більше не потрібні, забезпечуючи при цьому збереження даних під час оновлень StatefulSet і обслуговування вузлів. Ця функція спрощує керування сховищем для StatefulSets і зменшує ризик появи «осиротілих» PVC.

Ця робота була виконана в рамках KEP #1847 силами SIG Apps.

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

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

Механізм керованого Job API

Поле managedBy для Jobs було підвищено до рівня бета-версії у випуску v1.32. Ця можливість дозволяє зовнішнім контролерам (наприклад, Kueue) керувати синхронізацією завдань, пропонуючи більшу гнучкість та інтеграцію з сучасними системами керування робочим навантаженням.

Ця робота була виконана в рамках 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 та кластерному автомасштабувальнику імітувати розподіл запитів безпосередньо, без використання сторонніх драйверів. Тепер ці компоненти можуть передбачати, чи можуть запити на ресурси бути виконані на основі поточного стану кластера, без фактичної фіксації розподілу. Усуваючи необхідність у сторонньому драйвері для перевірки або тестування розподілів, ця функція покращує планування і прийняття рішень щодо розподілу ресурсів, роблячи процеси планування і масштабування більш ефективними.

Ця робота була виконана в рамках KEP #4381, силами WG Device Management (командою, що складється з SIG Node, SIG Scheduling та SIG Autoscaling).

Авторизація міток і селекторів полів

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

Ця робота була виконана в рамках KEP #4601 силами SIG Auth.

Фцнкції, що перейшли в стан Alpha

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

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

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

Ця робота була виконана в рамках KEP #4832 силами SIG Scheduling.

Змінювані політики допуску за допомогою CEL-виразів

Ця функція використовує обʼєктну конкретизацію CEL та стратегії JSON Patch у поєднанні з алгоритмами злиття Server Side Apply. Це спрощує визначення політик, зменшує конфлікти мутацій і підвищує продуктивність контролю доступу, закладаючи основу для більш надійних, розширюваних фреймворків політик в Kubernetes.

Сервер Kubernetes API тепер підтримує мутацію політик допуску на основі Common Expression Language (CEL), що забезпечує легку та ефективну альтернативу мутації веб-хуків допуску. Завдяки цьому вдосконаленню адміністратори можуть використовувати CEL для оголошення змін, таких як встановлення міток, стандартних значень полів або додавання sidecars, за допомогою простих декларативних виразів. Такий підхід зменшує операційну складність, усуває потребу у веб-хуках та інтегрується безпосередньо з kube-apiserver, пропонуючи швидшу та надійнішу обробку мутацій у процесі роботи.

Ця робота була виконана в рамках KEP #3962 силами SIG API Machinery.

Специфікації ресурсів на рівні podʼів

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

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

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

Ця робота була виконана в рамках KEP #2837 силами SIG Node.

Дозвіл нульового значення для дії sleep хука PreStop

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

Це вдосконалення є сумісним з попередніми версіями, його впроваджено як додаткову функцію, керовану за допомогою функції PodLifecycleSleepActionAllowZero. Ця зміна особливо корисна для сценаріїв, що вимагають використання хуків PreStop для перевірки або обробки веб-хуків допуску, не вимагаючи фактичної тривалості сплячого режиму. Завдяки узгодженню з можливостями функції time.After Go, це оновлення спрощує конфігурацію і розширює зручність використання для робочих навантажень 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

Перехід у Stable

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

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

• Structured Authorization Configuration
• Bound service account token improvements
• Custom Resource Field Selectors
• Retry Generate Name
• Make Kubernetes aware of the LoadBalancer behaviour
• Field status.hostIPs added for Pod
• Custom profile in kubectl debug
• Memory Manager
• Support to size memory backed volumes
• Improved multi-numa alignment in Topology Manager
• Add job creation timestamp to job annotations
• Add Pod Index Label for StatefulSets and Indexed Jobs
• Auto remove PVCs created by StatefulSet

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

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

Відмова від старої імплементації DRA

Удосконалення #3063 запровадило динамічний розподіл ресурсів (DRA) у Kubernetes 1.26.

Однак, у Kubernetes v1.32 цей підхід до DRA буде суттєво змінено. Код, повʼязаний з оригінальною реалізацією, буде видалено, залишивши KEP #4381 як «нову» базову функціональність.

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

Це видалення дозволить Kubernetes більш передбачувано обробляти нові вимоги до апаратного забезпечення та запити на ресурси, оминаючи складнощі зворотних викликів API до kube-apiserver.

Щоб дізнатися більше, дивіться тікет #3063.

Вилічення API

У [Kubernetes v1.32] (/docs/reference/using-api/deprecation-guide/#v1-32) вилучено один API:

• Видалено версію flowcontrol.apiserver.k8s.io/v1beta3 API 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 за допомогою minikube. Ви також можете легко встановити v1.32 за допомогою kubeadm.

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

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

Ми хотіли б подякувати всій команді розробників за години, проведені за напруженою роботою над випуском Kubernetes v1.32 для нашої спільноти. Членство в команді варіюється від новачків до досвідчених лідерів команд, які повернулися з досвідом, отриманим протягом декількох циклів випуску. Особлива подяка нашому керівнику релізу, Фредеріко Муньосу, за те, що він керує командою розробників так витончено і вирішує будь-які питання з максимальною ретельністю, гарантуючи, що цей реліз буде виконано гладко і ефективно. І останнє, але не менш важливе: велика подяка всім учасникам релізу, як ведучим, так і помічникам, а також наступним SIG за приголомшливу роботу і результати, досягнуті за ці 14 тижнів роботи над релізом:

• SIG 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 та наявність спільноти.

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

• Компанії, що роблять внесок у Kubernetes
• Загальний внесок в екосистему

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

Якщо ви зацікавлені у внеску, відвідайте Початок роботи на нашому сайті для учасників.

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

Оновлені події

Ознайомтеся з майбутніми подіями з Kubernetes та хмарних технологій з березня по червень 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: June 5, 2025 | Bratislava, Slovakia
• KCD - Kubernetes Community Days: Bangalore, India: June 6, 2025 | Bangalore, India
• 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.

Долучайтеся

Найпростіший спосіб долучитися до Kubernetes - приєднатися до однієї з багатьох [ Special Interest Groups] (https://www.kubernetes.dev/community/community-groups/#special-interest-groups) (SIG), які відповідають вашим інтересам. Маєте щось, про що хотіли б розповісти спільноті Kubernetes? Поділіться своєю думкою на нашій щотижневій зустрічі спільноти, а також за допомогою каналів нижче. Дякуємо за ваші постійні відгуки та підтримку.

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

Попередній огляд Kubernetes v1.32

Чим ближче до дати випуску 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, так і для контролерів. Нова додана модель Структурованих Параметрів замінює функціональність.

Це видалення дозволить Kubernetes обробляти нові апаратні вимоги та запити на ресурси більш передбачувано, обходячи складнощі зворотних викликів API до kube-apiserver.

Будь ласка, також перегляньте #3063 для отримання додаткової інформації.

Видалення API

Заплановано лише одне видалення API для Kubernetes v1.32:

• Версія API flowcontrol.apiserver.k8s.io/v1beta3 для FlowSchema та PriorityLevelConfiguration була видалена. Щоб підготуватися до цього, ви можете відредагувати свої поточні маніфести та переписати клієнтське програмне забезпечення для використання версії API flowcontrol.apiserver.k8s.io/v1, доступної з v1.29. Всі поточні збережені обʼєкти доступні через новий API. Помітні зміни в flowcontrol.apiserver.k8s.io/v1beta3 включають те, що поле PriorityLevelConfiguration spec.limited.nominalConcurrencyShares стандартно встановлюється на 30, якщо не вказано явне значення 0, яке не змінюється на 30.

Для отримання додаткової інформації, будь ласка, зверніться до керівництва по застаріванню API.

Попередній огляд Kubernetes v1.32

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

Ще більше покращень DRA!

У цьому випуску, як і в попередньому, проєкт Kubernetes продовжує пропонувати ряд покращень для Динамічного виділення ресурсів (DRA), ключового компонента системи управління ресурсами Kubernetes. Ці покращення спрямовані на підвищення гнучкості та ефективності виділення ресурсів для робочих навантажень, які потребують спеціалізованого обладнання, такого як GPU, FPGA та мережеві адаптери. Цей випуск вводить покращення, включаючи додавання статусу справності ресурсів у статус Pod, як описано в KEP #4680.

Додавання статусу справності ресурсів до статусу Pod

Важко дізнатися, коли Pod використовує пристрій, який вийшов з ладу або тимчасово несправний. KEP #4680 пропонує показувати справність пристрою через статус 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 типу 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 для цього випуску.

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

• Kubernetes v1.31

• Kubernetes v1.30

• Kubernetes v1.29

• Kubernetes v1.28

DIY: Створіть власну хмару з Kubernetes (Частина 3)

Наближаючись до найцікавішої фази, ця стаття розглядає запуск Kubernetes всередині Kubernetes. Висвітлюються такі технології, як Kamaji та Cluster API, а також їх інтеграція з KubeVirt.

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

Почнемо з Cluster API.

Cluster API

Cluster API — це розширення для Kubernetes, яке дозволяє керувати кластерами Kubernetes як власними ресурсами користувача всередині іншого кластеру Kubernetes.

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

У контексті Cluster API є два терміни: кластер управління та кластери користувачів.

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

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

Для своєї роботи Cluster API використовує концепцію провайдерів, які є окремими контролерами, що відповідають за конкретні компоненти створюваного кластера. В межах Cluster API існує кілька типів провайдерів. Основні з них:

• Провайдер інфраструктури, який відповідає за надання обчислювальної інфраструктури, такої як віртуальні машини або фізичні сервери.
• Провайдер панелі управління, який надає панель управління Kubernetes, а саме компоненти kube-apiserver, kube-scheduler та kube-controller-manager.
• Провайдер Bootstrapping, який використовується для створення конфігурацій cloud-init для віртуальних машин та серверів, що створюються.

Щоб почати, вам потрібно буде встановити сам Cluster API та одного провайдера кожного типу. Повний список підтримуваних провайдерів можна знайти в документації проєкту Cluster API.

Для встановлення можна використовувати утиліту clusterctl або Cluster API Operator як більш декларативний метод.

Вибір провайдерів

Провайдер інфраструктури

Для запуску кластерів Kubernetes за допомогою KubeVirt, необхідно встановити Infrastructure Provider KubeVirt. Він дозволяє розгортання віртуальних машин для робочих вузлів у тому ж кластері управління, де працює Cluster API.

Провайдер панелі управління

Проєкт Kamaji пропонує готове рішення для запуску панелі управління Kubernetes для кластерів користувачів як контейнерів у кластері управління. Цей підхід має кілька суттєвих переваг:

• Економічність: Запуск панелі управління в контейнерах запобігає використанню окремих вузлів панелі управління для кожного кластеру, що суттєво знижує витрати на інфраструктуру.
• Стабільність: Спрощення архітектури шляхом усунення складних багатошарових схем розгортання. Замість послідовного запуску віртуальної машини, а потім встановлення компонентів etcd та Kubernetes всередині неї, є проста панель управління, яка розгортається і працює як звичайний застосунок всередині Kubernetes та управляється оператором.
• Безпека: Панель управління кластера прихована від кінцевого користувача, що знижує можливість компрометації її компонентів, а також усуває доступ користувачів до сховища сертифікатів кластера. Такий підхід до організації панелі управління, невидимої для користувача, часто використовують постачальники хмарних послуг.

Провайдер Bootstrapping

Kubeadm як Bootstrapping Provider — стандартний метод підготовки кластерів у Cluster API. Цей провайдер розроблений як частина самого Cluster API. Він вимагає лише підготовленого системного образу з встановленими kubelet і kubeadm і дозволяє генерувати конфігурації у форматах cloud-init та ignition.

Слід зазначити, що Talos Linux також підтримує виділення ресурсів через Cluster API та має провайдерів для цього. Хоча попередні статті обговорювали використання Talos Linux для налаштування кластера управління на вузлах bare-metal, для створення клієнтських кластерів підхід Kamaji+Kubeadm має більше переваг. Він полегшує розгортання панелей управління Kubernetes у контейнерах, усуваючи необхідність окремих віртуальних машин для екземплярів панелі управління. Це спрощує управління та знижує витрати.

Як це працює

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

На відміну від Cluster, ці два ресурси не є стандартизованими, і їх тип залежить від конкретного провайдера, якого ви використовуєте:

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

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

Для створення машин MachineDeployment посилається на шаблон для генерації самої машини та шаблон для генерації її конфігурації cloud-init:

Щоб розгорнути новий кластер Kubernetes за допомогою Cluster API, вам потрібно буде підготувати наступний набір ресурсів:

• Загальний ресурс Cluster
• Ресурс KamajiControlPlane, відповідальний за панель управління, що управляється Kamaji
• Ресурс KubevirtCluster, що описує конфігурацію кластера в KubeVirt
• Ресурс KubevirtMachineTemplate, відповідальний за шаблон віртуальної машини
• Ресурс KubeadmConfigTemplate, відповідальний за генерацію токенів і cloud-init
• Щонайменше один MachineDeployment для створення деяких робочих ресурсів (workers)

Шліфування кластера

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

На цьому етапі ви вже маєте готовий клієнтський кластер Kubernetes, але наразі він містить лише API-робітників і кілька основних втулків, що стандартно включені в установку будь-якого кластера Kubernetes: kube-proxy та CoreDNS. Для повної інтеграції вам потрібно буде встановити ще кілька компонентів:

Щоб встановити додаткові компоненти, ви можете використовувати окремий Cluster API Add-on Provider для Helm, або той же FluxCD, про який згадувалося в попередніх статтях.

При створенні ресурсів у FluxCD, можна вказати цільовий кластер, звертаючись до kubeconfig, згенерованого Cluster API. Тоді установка буде виконана безпосередньо в нього. Таким чином, FluxCD стає універсальним інструментом для управління ресурсами як у кластері управління, так і в клієнтських кластерах.

Які компоненти обговорюються тут? Загалом, набір включає наступні:

Втулок CNI

Щоб забезпечити комунікацію між podʼами в клієнтському кластері Kubernetes, необхідно розгорнути втулок CNI. Цей втулок створює віртуальну мережу, яка дозволяє podʼам взаємодіяти один з одним і традиційно розгортається як Daemonset на робочих вузлах кластера. Ви можете вибрати та встановити будь-який втулок CNI, який вважаєте відповідним.

Cloud Controller Manager

Основне завдання Cloud Controller Manager (CCM) — інтеграція Kubernetes з середовищем провайдера хмари (в вашому випадку це кластер управління Kubernetes, в якому створюються всі робітники клієнтського Kubernetes). Ось деякі з його завдань:

1. Коли створюється сервіс типу LoadBalancer, CCM ініціює процес створення хмарного балансувальника навантаження, який направляє трафік до вашого кластера Kubernetes.
2. Якщо вузол видаляється з хмарної інфраструктури, CCM забезпечує його видалення з вашого кластера також, підтримуючи поточний стан кластера.
3. При використанні CCM вузли додаються до кластера з особливим taint, node.cloudprovider.kubernetes.io/uninitialized, який дозволяє обробку додаткової бізнес-логіки, якщо це необхідно. Після успішної ініціалізації цей taint видаляється з вузла.

Залежно від постачальника хмари, CCM може працювати як всередині, так і зовні клієнтського кластера.

Провайдер хмари KubeVirt розроблений для установки у зовнішньому батьківському кластері управління. Таким чином, створення сервісів типу LoadBalancer в клієнтському кластері ініціює створення сервісів LoadBalancer у батьківському кластері, які направляють трафік в клієнтський кластер.

Драйвер CSI

Container Storage Interface (CSI) розділений на дві основні частини для взаємодії зі зберіганням у Kubernetes:

• csi-controller: Цей компонент відповідає за взаємодію з API постачальника хмари для створення, видалення, підключення, відключення та зміни розміру томів.
• csi-node: Цей компонент працює на кожному вузлі та полегшує монтування томів до podʼів на запит kubelet.

У контексті використання CSI драйвера KubeVirt виникає унікальна можливість. Оскільки віртуальні машини в KubeVirt працюють всередині кластеру управління Kubernetes, де доступне повноцінний API Kubernetes, це відкриває шлях для запуску csi-controller ззовні клієнтського кластера. Цей підхід є популярним у спільноті KubeVirt і має кілька ключових переваг:

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

Однак, csi-node обовʼязково повинен працювати всередині клієнтського кластера, оскільки він безпосередньо взаємодіє з kubelet на кожному вузлі. Цей компонент відповідає за монтування та демонтування томів у podʼах, вимагаючи тісної інтеграції з процесами, що відбуваються безпосередньо на вузлах кластера.

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

Автоматичний масштабувальник кластера

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

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

Konnectivity

Є ще один додатковий компонент, про який я хотів би згадати — Konnectivity. Ймовірно, він вам знадобиться пізніше, щоб налаштувати вебхуки та шар агрегації API в вашому клієнтському кластері Kubernetes. Це питання детально висвітлене в одній з моїх попередніх статей.

На відміну від наведених вище компонентів, Kamaji дозволяє легко увімкнути Konnectivity та управляти ним як одним з основних компонентів вашого клієнтського кластера, поряд з kube-proxy і CoreDNS.

Висновок

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

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

Звичайно, всі компоненти, необхідні для розгортання кластера Kubernetes, можна упакувати в один Helm chart і розгорнути як єдиний застосунок. Саме так ми організовуємо розгортання керованих кластерів Kubernetes одним натисканням кнопки на нашій відкритій платформі PaaS, Cozystack, де ви можете безкоштовно випробувати всі технології, описані в статті.

DIY: Створіть власну хмару з Kubernetes (Частина 2)

Продовжуємо нашу серію публікацій про те, як побудувати власну хмару, використовуючи лише екосистему 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.

KubeVirt дозволяє запускати традиційні віртуальні машини за допомогою API Kubernetes. Віртуальні машини KubeVirt запускаються як звичайні процеси Linux у контейнерах. Іншими словами, у KubeVirt контейнер використовується як середовище для запуску процесів віртуальної машини (QEMU). Це чітко видно на малюнку нижче, якщо подивитися, як реалізовано живу міграцію віртуальних машин у 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.

Мережа для віртуальних машин Kubernetes

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

Мережева інфраструктура вузлів (мережа дата-центру)

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

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

Мережа Podʼів

Це мережа, яку забезпечує ваш CNI-втулок. Завдання CNI-втулка полягає в забезпеченні прозорого зʼєднання між усіма контейнерами та вузлами в кластері. Більшість CNI-втулків реалізують пласку мережу, з якої окремі блоки IP-адрес виділяються для використання на кожному вузлі.

На практиці ваш кластер може мати кілька 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 ви можете призначати окремі підмережі всьому namespace або підключати їх як додаткові мережеві інтерфейси за допомогою Multus.

Мережа сервісів (Services Network)

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

Реалізацію мережі сервісів у 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 забезпечують вбудовану реалізацію.

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

У більшості випадків налаштування балансувальника навантаження на bare-metal досягається шляхом створення плаваючої IP-адреси на вузлах у кластері та її оголошення назовні за допомогою протоколів ARP/NDP або BGP.

Вивчивши різні варіанти, ми вирішили, що MetalLB є найпростішим і найнадійнішим рішенням, хоча ми не вимагаємо суворого використання лише його.

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

Висновок

Цим завершується наш огляд віртуалізації, зберігання та мереж в Kubernetes. Усі згадані технології доступні та вже налаштовані на платформі Cozystack, де ви можете їх спробувати без обмежень.

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

DIY: Створіть власну хмару з Kubernetes (Частина 1)

У Æ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, навпаки, стає нестерпно складним. По-перше, тому що вся мережа, сховище даних, балансувальники навантаження тощо зазвичай працюють не зовні, а всередині вашого кластера. У результаті така система набагато складніша для оновлення та підтримки.

Судіть самі: у хмарі, щоб оновити вузол, ви зазвичай видаляєте віртуальну машину (або навіть використовуєте команду 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

Автори: Amit Dsouza, Frederick Kautz, Kristin Martin, Abigail McCarthy, Natali Vlatko

Швидкий огляд: зміни у 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.

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