Google Cloud оголосила, що її сервіс GKE тепер пропонує загальнодоступні (GA) двоступеневі оновлення control-plane, що дозволяє клієнтам відокремити оновлення програмного бінарного файлу від міграції формату даних і зберігати вікно відкату під час зміни мінорних версій.

Чому GKE потрібен був безпечніший шлях

Оновлення Kubernetes control plane з однієї мінорної версії на наступну завжди було пов'язане з ризиком. Перехід з 1.33 на 1.34 не лише замінює бінарні файли, а й переписує базові структури даних. Якщо нова версія містить помилку, кластер неможливо просто відкотити; адміністратори мають відновлювати старі знімки (snapshots) бази даних або повністю перестворювати кластер, що є тривалим і схильним до помилок процесом.

Як працює двоступеневе оновлення

Новий процес розділяє оновлення на два окремі етапи:

  • Крок 1 – Оновлення бінарних файлів (режим емуляції). GKE замінює бінарні файли control-plane на цільову версію, зберігаючи при цьому старий формат даних. Оскільки нові структури даних не записуються, кластер залишається захищеним від ризиків під час відкату протягом усього цього етапу.
  • Крок 2 – Завершення. Після налаштовуваного періоду очікування GKE конвертує збережені дані в новий формат. Після завершення цієї конвертації відкат потребуватиме тих самих зусиль зі відновлення знімків, яких двоступеневий процес був покликаний уникнути.

Таке розділення створює «вікно витримки» (soak window), під час якого оператори можуть спостерігати за оновленими бінарними файлами у робочому середовищі (production), не вдаючись до незворотної міграції даних.

Вікно витримки на практиці

GKE автоматично відстежує ключові метрики стану під час періоду витримки: затримку API, рівень помилок і стан подів (pods). Якщо сервіс виявляє аномалії, він зупиняє розгортання, залишаючи кластер у стані «тільки бінарні файли», коли відкат все ще можливий. Google зазначає, що рівень успіху оновлень за такою схемою становить 99,999%.

Для кластерів, які використовують функцію автооновлення GKE, платформа координує всю двоступеневу послідовність без ручного втручання. Користувачі, які віддають перевагу повному контролю, можуть запустити цей процес через Cloud CLI або Terraform.

Виконання ручного двоступеневого оновлення

Типове ручне оновлення з 48-годинним вікном безпеки виглядає так:

gcloud beta container clusters upgrade my-cluster \
  --location=us-central1 \
  --cluster-version=1.34.1-gke.1829001 \
  --control-plane-soak-duration=48h \
  --master

Щоб перевірити поточний статус:

gcloud container clusters describe my-cluster \
  --location=us-central1 \
  --format="yaml(rollbackSafeUpgradeStatus)"

Якщо під час витримки виявиться дефект, адміністратор може надати команду на відкат і повернутися до попередньої версії без втрати даних. Коли кластер доведе свою стабільність, оновлення можна завершити достроково за допомогою команди complete-control-plane-upgrade.

Обмеження та вимоги

  • Ця функція застосовується до кластерів GKE версії 1.33 або новішої.
  • Можна оновлювати лише одну мінорну версію за раз; пропуск версій не підтримується.
  • Як Autopilot, так і регіональні кластери залишаються доступними протягом усього двоступеневого процесу.

Потенційні недоліки

Розділення оновлень бінарних файлів і даних додає додатковий крок до графіка оновлення, що може подовжити загальне вікно для організацій, яким потрібні швидкі зміни версій. Період витримки також залежить від автоматизованих перевірок стану; командам, які запускають високонавантажені специфічні робочі навантаження (customized workloads), може знадобитися доповнити моніторинг GKE власними інструментами спостережуваності (observability), щоб виявити регресії у граничних випадках.

За чим стежити далі

Google не розкрила дорожню карту щодо розширення двоступеневої моделі на оновлення мажорних версій, які в багатьох випадках все ще потребують повного перестворення кластера. Спостерігачі чекатимуть на анонси подібних засобів безпеки для оновлення пулів вузлів (node-pools), а також на будь-яку інтеграцію зі сторонніми CI/CD конвеєрами, яка могла б автоматизувати перевірки у вікні витримки.

Підсумок: Розділяючи оновлення бінарних файлів і міграцію даних, GKE надає інженерам платформ практичне вікно відкату для змін мінорних версій, знижуючи операційні витрати на обслуговування кластера та мінімізуючи час простою.