Продовження — Запобігання збоям оновлення з etcd v3.5 до v3.6
Ми виявили та виправили додатковий сценарій, який може спричинити збої оновлення під час переходу з etcd v3.5 до v3.6. Цей допис містить деталі, виправлення та додаткові обхідні шляхи. Будь ласка, зверніться до тікета #20793, щоб отримати детальну технічну інформацію.
Проблема
У попередньому дописі — Як запобігти поширеному збою під час оновлення etcd v3.5 до v3.6 — ми описали проблему оновлення, що впливає на версії etcd у діапазоні v3.5.1-v3.5.19. Цю проблему було вирішено у v3.5.20. Однак подальше розслідування виявило, що початкове виправлення не охоплювало всі сценарії.
Зокрема, під час оновлень із поступовою заміною (таких, як ті, що виконуються Cluster API під час оновлення панелей управління Kubernetes), новий learner може отримати знімок від старішого учасника (≤ v3.5.19), що містить невірні дані про членство. Ця невідповідність не впливає на кластери, що все ще працюють на версії v3.5, де v2store залишається авторитетним джерелом, але може спричинити збій оновлення під час переходу на v3.6, оскільки новий learner може знову отримати знімок із неправильними даними про членство, і v3store стане авторитетним джерелом.
Рішення
Цей додатковий сценарій було виправлено в etcd v3.5.24 у #20797. Усі користувачі, які можуть, повинні спочатку оновитися до etcd v3.5.24 (або вищої patch-версії) перед оновленням до etcd v3.6; інакше оновлення може завершитися невдачею.
Однак, якщо ви вже використовуєте версію v3.5.20–v3.5.23 і ваш кластер було нещодавно встановлено (а не оновлено з попередньої версії), ви можете безпечно оновити систему безпосередньо до версії v3.6, не переходячи попередньо на версію v3.5.24 (або версію з вищим номером патча).
Обхідні шляхи
Оновлення безпосередньо до v3.5.24 або новішої версії є найнадійнішим і найпростішим способом уникнути збою оновлення. Однак, якщо ви не можете оновитися до v3.5.24 (або вищої patch-версії) з якоїсь причини, будь ласка, застосуйте один із наведених нижче обхідних шляхів перед оновленням до v3.6:
Користувачі, які працювали на v3.5.19 або нижчій версії та оновилися до версії між v3.5.20 та v3.5.23, можуть зробити одну з двох речей:
- Перезапустіть усі члени etcd перед оновленням до v3.6. Повний перезапуск запускає повторну реєстрацію та виправляє неправильну інформацію про членство.
- Виконайте додаткове оновлення до будь-якої patch-версії в діапазоні v3.5.20 – v3.5.23. Кожен член повторно зареєструє свою інформацію про сервер, автоматично виправляючи неправильні дані про членство під час додаткового оновлення.
Користувачам, які все ще працюють на v3.5.19 або ранішій версії, потрібно спочатку оновитися до будь-якої версії між v3.5.20 та v3.5.23, а потім застосувати один із двох обхідних шляхів вище.
Користувачам на свіжій установці v3.5.20 до v3.5.23 не потрібно вживати жодних додаткових дій.
Подяки
Ми хотіли б подякувати Avinash Batukbhai з Broadcom за повідомлення про проблему оновлення. Його звіт допоміг привернути нашу увагу до цієї проблеми, щоб ми могли розслідувати та вирішити її.