Kubernetes 1.37 автоматизував міграцію версій даних у etcd

У Kubernetes 1.37 механізм Storage Version Migration отримав статус stable і ввімкнений за замовчуванням. Вбудований API storagemigration.k8s.io/v1 та контролер control plane дають адміністраторам декларативний спосіб переписати об’єкти в etcd у поточну storage-версію. Це закриває давню операційну прогалину під час видалення старих версій CRD, оновлення API та ротації ключів шифрування даних at rest.

Чому старі дані не оновлюються самі

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

Це особливо помітно з CustomResourceDefinition. Коли команда хоче прибрати застарілу версію з CRD, спочатку потрібно переконатися, що в сховищі не залишилося об’єктів у цьому форматі. Поле .status.storedVersions допомагає відстежувати стан, але раніше сам процес переписування часто виконували вручну.

Що змінює вбудована міграція

Адміністратор створює ресурс StorageVersionMigration для потрібного GroupVersionResource. Контролер знаходить відповідні об’єкти та ініціює їх повторний запис через API server, тож актуальна storage-версія і всі чинні admission, conversion та encryption правила застосовуються централізовано. Хід операції відображається у статусі ресурсу, а успішне завершення позначається умовою Succeeded=True.

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

Де це потрібне на практиці

• Прибирання версії CRD. Перед видаленням старої served/storage версії всі наявні custom resources треба переписати в актуальний формат.
• Зміна storage version вбудованого API. Міграція не залишає «довгий хвіст» об’єктів, які роками зберігаються у старій схемі.
• Ротація encryption key. Нова конфігурація захищає наступні записи, а міграція примушує вже наявні секрети та інші ресурси пройти повторний запис із новим ключем.
• Підготовка до оновлення. Команда отримує спостережуваний, повторюваний процес замість одноразового скрипта з kubectl get і replace.

Що перевіряти під час запуску

До міграції потрібно зробити актуальний backup etcd, перевірити conversion webhooks і оцінити кількість об’єктів. Якщо webhook нестабільний або схема не приймає старі дані, масовий повторний запис лише швидше проявить проблему. У великих кластерах слід спостерігати latency API server, черги, помилки admission, навантаження на etcd і стан контролера.

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

Практичний висновок: StorageVersionMigration варто включити до runbook для оновлення API, CRD та encryption config. Запускайте її як контрольовану операцію з backup, моніторингом і перевіркою storedVersions, а не як фонову формальність.

Обмеження і сумісність

Функція stable і ввімкнена за замовчуванням саме в Kubernetes 1.37. Старі кластери можуть потребувати попереднього зовнішнього migrator або ручного процесу. Механізм також не виправляє помилки у conversion webhook, не проєктує нову схему CRD і не визначає, яку версію бізнес-даних слід вважати правильною — ці рішення залишаються за власником API.

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

Джерело та ліцензія

Матеріал підготовлено за дописом Michael Aspinwall Storage Version Migration is Now Generally Available in Kubernetes v1.37. Вміст Kubernetes Website поширюється за Creative Commons Attribution 4.0. Український текст перекладено й адаптовано редакцією з атрибуцією на умовах CC BY 4.0.