Як запобігти поширеному збою під час оновлення etcd v3.5 до v3.6
Ми виявили та виправили дві додаткові проблеми оновлення. Будь ласка, перегляньте наші нові дописи в блозі Продовження — Запобігання збоям оновлення з etcd v3.5 до v3.6 та Уникнення зомбі-членів кластера під час оновлення для деталей.
Існує поширена проблема #19557 в оновленні etcd з v3.5 до v3.6, яка може спричинити збій процесу оновлення. Ви можете знайти детальну інформацію та повʼязані обговорення в цій проблемі.
TL; DR
Користувачі повинні спочатку оновитися до etcd v3.5.20 (або вищої patch-версії) перед оновленням до etcd v3.6.0. Недотримання цього може призвести до невдалого оновлення.
Який симптом?
Під час оновлення кластера etcd, що складається з багатьох членів, з версії між v3.5.1 та v3.5.19 до v3.6.0 оновлення може завершитися невдачею через помилку «membership: too many learner member in cluster».
Яка першопричина?
Стандартно etcd дозволяє не більше одного learner-члена; процес початкового завантаження завершиться невдачею, якщо є два або більше learner-членів. Через проблему #19557 деякі голосуючі члени можуть повернутися до статусу learner під час оновлення до v3.6.0, що може спричинити збій оновлення.
Першопричина полягає в тому, що під час підвищення learner-члена повʼязана зміна постійно зберігається лише у v2store, а не у v3store. Як результат, дані про членство стають неузгодженими між v2store та v3store.
У etcd v3.5 джерелом достовірних даних про членство є v2store, тоді як у etcd v3.6 — v3store. Саме це є причиною того, що проблема виникає лише під час оновлення з версії v3.5 до v3.6.
Які версії зазнають впливу?
Про проблему було повідомлено у etcd v3.5.1 в #13348. Усі patch-версії etcd від v3.5.1 до v3.5.19 зазнають впливу.
Які версії містять виправлення цієї проблеми?
Проблему було виправлено в etcd v3.5.20 у #19563. Тому користувачі повинні спочатку оновитися до etcd v3.5.20 (або вищої patch-версії) перед оновленням до etcd v3.6.0; інакше оновлення може завершитися невдачею.
Що якщо користувачі не дотримуються посібника?
Що станеться, якщо користувачі все одно оновлюються безпосередньо з etcd v3.5.1-v3.5.19 до v3.6.0?
Якщо кластер etcd не зазнає впливу проблеми, жоден член не повернеться до статусу learner під час оновлення. У цьому випадку оновлення завершиться успішно без жодних проблем.
Якщо кластер etcd вже зазнав впливу проблеми, можливі два результати:
- Якщо два або більше членів повертаються до статусу learner під час оновлення, оновлення завершиться невдачею. У такому випадку користувачам доведеться відкотити зміни та спочатку оновитися до etcd v3.5.20 (або вищої версії) перед повторною спробою оновлення до v3.6.0.
- Якщо лише один член повертається до статусу learner під час оновлення, оновлення все одно завершиться успішно. Однак проблема полягає в тому, що голосуючий член повертається до статусу learner, що може заплутати користувачів, а також вплинути на кворум кластера. Ми вирішили цю проблему в etcd v3.6.0-rc.3 в #19636 шляхом автоматичного підвищення learner-члена до голосуючого члена під час початкового завантаження.
Як нам вдалося запобігти повторенню такої ситуації?
etcd має деякі наскрізні (e2e) тестові випадки оновлення, але вони не виявили цю проблему. Натомість її було виявлено в тесті робочого процесу Kubernetes. Щоб усунути цю прогалину, ми додали подібний e2e-тест у #19634, який також було перенесено до release-3.6 у #19662.