Представьте себе следующий сценарий:
Сегодня вы открываете электронную почту и получаете уведомление, что центр обработки данных переедет в новое место. Физические серверы будут выключены, перемещены в новое место и снова включены.
Как правильно завершить работу кластера Kubernetes (без нарушения данных etcd)?
Вот что я сделал:
После миграции:
После этого у меня был один из двух сценариев:
Как это можно было предотвратить? Я не думаю, что запуск etcd в режиме высокой доступности здесь поможет, так как все узлы etcd также должны быть отключены одновременно, поэтому вы получите ситуацию, аналогичную сценарию с одним узлом. У меня сложилось впечатление, что Etcd довольно ... хрупкий по сравнению с другими магазинами K / V, такими как Consul.
Вам нужно будет остановиться на мастере
Если у вас есть федерация, также остановите federation-apiserver
Запустите резервную копию (снимок) etcd и остановите etcd, когда закончите
Для каждой остановки узла
Etcd такой же надежный, как консул, что вы имеете в виду под instable ?!
При восстановлении, хотя у вас есть данные etcd, это не действует сразу ... вы должны прочитать резервные копии на кубернетах
На самом деле, etcd является довольно устойчивым благодаря подходу, основанному на журналах, но, как всегда, вы должны сделать резервную копию непосредственно перед миграцией / завершением работы, на всякий случай. Если есть проблема с etcd, просто восстановите резервную копию, и все готово.
Поскольку вы перезапустите весь кластер, порядок, в котором вы это делаете, на самом деле не так важен, все контейнеры все равно придется запускать заново, а это значит, что kubelet придется подключаться к работающему API.
Откуда у вас такое нестабильное впечатление от etcd, понятия не имею.