Cluster API v1.12: Впровадження оновлень на місці та ланцюгових оновлень
Cluster API забезпечує декларативне управління життєвим циклом кластерів Kubernetes, дозволяючи користувачам і командам роботи з платформами визначати бажаний стан кластерів і покладатися на контролери, які постійно узгоджують його.
Подібно до того, як ви можете використовувати StatefulSets або Deployments в Kubernetes для управління групою Pods, в Cluster API ви можете використовувати KubeadmControlPlane для управління набором машин панелі упрвління або MachineDeployments для управління групою робочих вузлів.
Випуск Cluster API v1.12.0 розширює можливості Cluster API, зменшуючи складності у звичайних операціях життєвого циклу завдяки впровадженню оновлень на місці та ланцюгових оновлень.
Акцент на простоті та зручності використання
Cluster API завжди прагнув забезпечити простий і передбачуваний процес управління життєвим циклом кластерів Kubernetes.
З версією v1.12.0 проєкт Cluster API ще раз демонструє, що ця спільнота здатна запроваджувати велику кількість інновацій, одночасно мінімізуючи вплив на користувачів Cluster API.
Що це означає на практиці?
Користувачам просто потрібно змінити специфікацію [Cluster](https://cluster-api.sigs.k8s.io/user/concepts# cluster) або Machine spec (так само, як і в попередніх версіях Cluster API), і Cluster API автоматично запустить оновлення на місці або послідовні оновлення, коли це можливо і доцільно.
Оновлення на місці
Як і Kubernetes для Pods у Deployments, коли змінюється специфікація Machine, Cluster API також виконує розгортання, створюючи нову машину та видаляючи стару.
Цей підхід, навіяний принципом незмінної інфраструктури, має низку значних переваг:
- Він простий для пояснення, передбачуваний, послідовний і легкий для розуміння користувачами та інженерами.
- Він простий у реалізації, оскільки базується лише на двох основних операціях: створенні та видаленні.
- Реалізація не залежить від конкретних параметрів машини, таких як ОС, механізм завантаження тощо.
В результаті розгортання машин значно зменшують кількість змінних, які потрібно враховувати під час управління життєвим циклом хост-сервера, що є хостом для Nodes.
Однак, хоча переваги незмінності не підлягають обговоренню, як Kubernetes, так і Cluster API проходять подібний шлях, впроваджуючи зміни, що дозволяють користувачам мінімізувати перебої в роботі, коли це можливо.
Згодом Cluster API також запровадив кілька вдосконалень до незмінних розгортань, зокрема:
- Підтримка поширення змін, що впливають тільки на ресурси Kubernetes, що дозволяє уникнути непотрібних розгортань
- Спосіб позначення застарілих вузлів за допомогою PreferNoSchedule, що дозволяє зменшити кількість втрат Podʼів шляхом оптимізації перепланування Podʼів під час розгортань.
- Підтримка стратегії «спочатку видалити, потім розгорнути», що спрощує розгортання незмінних версій на фізичних серверах/у середовищах з обмеженими ресурсами.
Нова функція оновлення на місці в Cluster API є наступним кроком на цьому шляху.
З випуском версії 1.12.0 Cluster API впроваджує підтримку розширень оновлення, що дозволяє користувачам вносити зміни в діючі машини на місці, без видалення та повторного створення машин.
Як KubeadmControlPlane, так і MachineDeployments підтримують оновлення на місці на основі нового розширення оновлення, а це означає, що межі можливостей Cluster API тепер значно змінилися.
Як працюють оновлення на місці?
Найпростіше пояснити це так: коли користувач запускає оновлення, змінюючи бажаний стан машин, Cluster API вибирає найкращий інструмент для досягнення бажаного стану.
Новина полягає в тому, що тепер Cluster API може вибирати між незмінними розгортаннями та розширеннями оновлень на місці для виконання необхідних змін.
Важливо, що це не незмінні розгортання проти оновлень на місці; Cluster API розглядає обидва варіанти як дійсні та вибирає найбільш відповідний механізм для даної зміни.
З точки зору розробників Cluster API, оновлення на місці найбільш корисні для внесення змін, які не вимагають спорожнення вузла або перезапуску подів; наприклад: зміна облікових даних користувача для машини. З іншого боку, коли робоче навантаження все одно буде порушено, просто виконайте розгортання.
Тим не менш, 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.
Також у цьому випадку розширюваність є основою цієї функції, і розширення виконання плану оновлення можуть бути використані для впливу на те, як обчислюється план оновлення; аналогічно, хуки життєвого циклу можуть використовуватися для автоматизації інших завдань, які необхідно виконати під час оновлення, наприклад, оновлення надбудови після завершення оновлення панелі управління.
На наш погляд, ланцюгові оновлення найбільш корисні для користувачів, яким важко встигати за мінорними релізами 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 рік!
Корисні посилання: