Cluster API v1.12: Впровадження оновлень на місці та ланцюгових оновлень
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 рік!
Корисні посилання: