Отказоустойчивость CoreOS, Fleet и Etcd2
У меня есть 23-узловый кластер, работающий на CoreOS Stable 681.2.0 в AWS в 4 зонах доступности. Все узлы работают под управлением etcd2 и фланели. Из 23 узлов 8 являются выделенными узлами etcd2, остальные специально обозначены как прокси etcd2.
В кластере запланировано 3 контейнера nginx плюс, личный реестр Docker, SkyDNS и 4 контейнера наших приложений. Контейнеры приложения регистрируются в etcd2, а контейнеры nginx фиксируют любые изменения, отображают необходимые файлы и, наконец, перезагружаются.
Это все работает отлично, пока отдельный узел etcd2 не будет недоступен по любой причине.
Если кластер голосующих участников etcd2 теряет связь даже с одним другим голосующим членом etcd2, все службы, запланированные для парка, становятся нестабильными. Запланированные услуги начинают останавливаться и запускаться без моего вмешательства.
В качестве теста я начал останавливать экземпляры EC2, на которых размещаются голосующие узлы etcd2, до потери кворума. После остановки первого узла etcd2 начались вышеуказанные симптомы. После второго узла службы стали нестабильными, без видимых изменений. Затем, после того, как третий был остановлен, кворум был потерян, и все подразделения были незапланированными. Затем я снова запустил все три узла etcd2, и в течение 60 секунд кластер вернулся в стабильное состояние.
Последующие тесты дают идентичные результаты.
Я сталкиваюсь с известной ошибкой в etcd2, fleet или CoreOS?
Есть ли параметр, который я могу изменить, чтобы сохранить запланированные единицы на узле, даже если etcd недоступен по какой-либо причине?
1 ответ
Я испытал то же самое. В моем случае, когда я запускал 1 конкретную единицу, это вызывало взрыв. Запланированные и отлично работающие единицы были внезапно потеряны без какого-либо уведомления, даже машины выпадали из кластера.
Я все еще не уверен, в чем именно заключалась проблема, но я думаю, что это могло иметь какое-то отношение к etcd vs etcd2. У меня была зависимость от etcd.service в файле модуля, что (я думаю, не уверен) заставило CoreOS попытаться запустить etcd.service, пока etcd2.service уже работал. Это могло вызвать конфликт в моем случае и испортить реестр устройств и машин etcd.
Нечто подобное может произойти с вами, поэтому я предлагаю вам проверить каждый хост, используете ли вы etcd или etcd2, и проверить файлы вашего модуля, чтобы узнать, от какого они зависят.