Оновлення etcd з 2.3 до 3.0

У загальному випадку, оновлення з etcd 2.3 до 3.0 може бути безперервним, поступовим оновленням:

• по черзі зупиняйте процеси etcd v2.3 і замінюйте їх процесами etcd v3.0
• після запуску всіх процесів v3.0 нові функції v3.0 будуть доступні кластеру

Перед початком оновлення, прочитайте решту цього посібника, щоб підготуватися.

Контрольні списки оновлення

ПРИМІТКА: При міграції з v2 без даних v3, сервер etcd v3.2+ панікує, коли etcd відновлюється з наявних знімків, але немає файлу v3 ETCD_DATA_DIR/member/snap/db. Це відбувається, коли сервер мігрував з v2 без попередніх даних v3. Це також запобігає випадковій втраті даних v3 (наприклад, файл db міг бути переміщений). etcd вимагає, щоб після міграції v3 можна було продовжувати лише з даними v3. Не оновлюйте до новіших версій v3, поки сервер v3.0 не містить даних v3.

Вимоги до оновлення

Щоб оновити поточне розгортання etcd до 3.0, кластер, що працює, повинен бути версії 2.3 або вище. Якщо це версія до 2.3, будь ласка, оновіть до 2.3 перед оновленням до 3.0.

Також, щоб забезпечити плавне поступове оновлення, кластер, що працює, повинен бути справним. Перевірте стан кластера за допомогою команди etcdctl cluster-health перед продовженням.

Підготовка

Перед оновленням etcd завжди тестуйте сервіси, що залежать від etcd, у тестовому середовищі перед розгортанням оновлення у промисловому середовищі.

Перед початком зробіть резервну копію теки даних etcd. Якщо щось піде не так з оновленням, можна використовувати цю резервну копію для пониження версії до поточної версії etcd.

Змішані версії

Під час оновлення кластер etcd підтримує змішані версії членів etcd і працює з протоколом найнижчої загальної версії. Кластер вважається оновленим лише після того, як усі його члени будуть оновлені до версії 3.0. Внутрішньо члени etcd домовляються між собою, щоб визначити загальну версію кластера, яка контролює версію, про яку повідомляється, та підтримувані функції.

Обмеження

Може знадобитися до 2 хвилин, щоб новий оновлений член наздогнав поточний кластер, коли загальний розмір даних перевищує 50 МБ. Перевірте розмір останнього знімка, щоб оцінити загальний розмір даних. Іншими словами, найкраще зачекати 2 хвилини між оновленням кожного члена.

Для набагато більшого загального розміру даних, 100 МБ або більше, цей одноразовий процес може зайняти ще більше часу. Адміністратори дуже великих кластерів etcd такого масштабу можуть звернутися до команди etcd перед оновленням, і ми будемо раді надати поради щодо процедури.

Пониження версії

Якщо всі члени були оновлені до v3.0, кластер буде оновлений до v3.0, і пониження з цього завершеного стану неможливе. Однак, якщо будь-який окремий член все ще є v2.3, кластер і його операції залишаються “v2.3”, і з цього змішаного стану кластера можна повернутися до використання двійкового файлу v2.3 на всіх членах.

Будь ласка, зробіть резервну копію теки даних всіх членів etcd, щоб зробити можливим пониження версії кластера навіть після його повного оновлення.

Процедура оновлення

Цей приклад детально описує оновлення кластера v2.3 etcd з трьох членів, що працює на локальній машині.

1. Перевірте вимоги до оновлення.

Чи кластер справний і працює на версії v.2.3.x?

$ etcdctl cluster-health
member 6e3bd23ae5f1eae0 is healthy: got healthy result from http://localhost:22379
member 924e2e83e93f2560 is healthy: got healthy result from http://localhost:32379
member 8211f1d0f64f3269 is healthy: got healthy result from http://localhost:12379
cluster is healthy

$ curl http://localhost:2379/version
{"etcdserver":"2.3.x","etcdcluster":"2.3.8"}

2. Зупиніть поточний процес etcd

Коли кожен процес etcd зупиняється, очікувані помилки будуть зареєстровані іншими членами кластера. Це нормально, оскільки зʼєднання члена кластера було (тимчасово) розірвано:

2016-06-27 15:21:48.624124 E | rafthttp: failed to dial 8211f1d0f64f3269 on stream Message (dial tcp 127.0.0.1:12380: getsockopt: connection refused)
2016-06-27 15:21:48.624175 I | rafthttp: the connection with 8211f1d0f64f3269 became inactive

На цьому етапі добре зробити резервну копію теки даних etcd, щоб забезпечити шлях для пониження версії у разі виникнення будь-яких проблем:

$ etcdctl backup \
      --data-dir /var/lib/etcd \
      --backup-dir /tmp/etcd_backup

3. Встановіть двійковий файл etcd v3.0 і запустіть новий процес etcd

Новий etcd v3.0 опублікує свою інформацію в кластер:

09:58:25.938673 I | etcdserver: published {Name:infra1 ClientURLs:[http://localhost:12379]} to cluster 524400597fb1d5f6

Переконайтеся, що кожен член, а потім і весь кластер, стає справним з новим двійковим файлом etcd v3.0:

$ etcdctl cluster-health
member 6e3bd23ae5f1eae0 is healthy: got healthy result from http://localhost:22379
member 924e2e83e93f2560 is healthy: got healthy result from http://localhost:32379
member 8211f1d0f64f3269 is healthy: got healthy result from http://localhost:12379
cluster is healthy

Оновлені члени будуть реєструвати попередження, подібні до наступних, поки весь кластер не буде оновлений. Це очікувано і припиниться після оновлення всіх членів кластера etcd до v3.0:

2016-06-27 15:22:05.679644 W | etcdserver: the local etcd version 2.3.7 is not up-to-date
2016-06-27 15:22:05.679660 W | etcdserver: member 8211f1d0f64f3269 has a higher version 3.0.0

4. Повторіть крок 2 до кроку 3 для всіх інших членів

5. Завершення

Коли всі члени будуть оновлені, кластер повідомить про успішне оновлення до 3.0:

2016-06-27 15:22:19.873751 N | membership: updated the cluster version from 2.3 to 3.0
2016-06-27 15:22:19.914574 I | api: enabled capabilities for version 3.0.0

$ ETCDCTL_API=3 etcdctl endpoint health
127.0.0.1:12379 is healthy: successfully committed proposal: took = 18.440155ms
127.0.0.1:32379 is healthy: successfully committed proposal: took = 13.651368ms
127.0.0.1:22379 is healthy: successfully committed proposal: took = 18.513301ms

Подальші міркування

• Змінено змінні середовища etcdctl. Якщо ETCDCTL_API=2 etcdctl cluster-health працює належним чином, але ETCDCTL_API=3 etcdctl endpoints health відповідає Error: grpc: timed out when dialing, обовʼязково використовуйте нові імена змінних.

Відомі проблеми

• etcd < v3.1 не працює належним чином, якщо зібраний з Go > v1.7. Див. Issue 6951 для додаткової інформації.
• Якщо в журналах сервера etcd зʼявляється помилка, така як transport: http2Client.notifyError got notified that the client transport was broken unexpected EOF., переконайтеся, що etcd є попередньо зібраним релізом або зібраний з (etcd v3.1+ & go v1.7+) або (etcd <v3.1 & go v1.6.x).
• Додавання вузла v3 до кластера v2.3 під час оновлень не підтримується і може викликати паніку. Див. Issue 7249 для додаткової інформації. Змішані версії членів etcd дозволені лише під час міграції v3. Завершіть оновлення перед внесенням будь-яких змін у членство.