У меня возникли проблемы с настройкой кластера etcd без использования URL-адреса обнаружения, работающего в CoreOS.
Конфигурация через cloud-init. 3 сервера в кластере перечислены ниже под одноранговыми узлами. Каждый из них имеет свой IP-адрес и статически установленный адрес и одноранговый адрес.
Например, первый сервер содержит:
#cloud-config
coreos:
etcd:
addr: 192.168.0.50:4001
peer-addr: 192.168.0.50:7001
peers: 192.168.0.50:7001,192.168.0.51:7001,192.168.0.52:7001
Что я вижу в journalctl:
ВНИМАНИЕ | сбой синхронизации кластера ([http://192.168.0.50:7001 http://127.0.0.1:7001])
И такие ошибки:
locksmithd [12262]: etcd.service активен locksmithd [12262]: Ошибка инициализации клиента etcd: 402: Внутренняя ошибка режима ожидания (
Я предполагаю, потому что etcd работает неправильно.
К сожалению, на веб-сайте CoreOS нет подробностей о статической настройке CoreOS & etcd на практике.
Когда это сработает, как будет выглядеть моя облачная конфигурация для проксированного экземпляра etcd?
При использовании статического обнаружения etcd 0.4.x выбирает начального лидера кластера в качестве узла, который был запущен без --peer список. Вам нужно будет опустить peers: раздел одного из ваших облачных конфигов.
etcd 2.0.0 позволит вам запустить кластер так, как вы сейчас пытаетесь, который предоставляет статический список всем членам и таким образом запускает кластер. Ознакомьтесь с документацией по статической кластеризации: https://github.com/coreos/etcd/blob/master/Documentation/clustering.md#static
etcd 2.0.0 не поставляется в образе / канале CoreOS, но скоро его ждет!