Comments 4
Сразу приступаете к действиям, не описав план проводимых работ.
Это теория или уже проверенный процесс? В любом случае не хватает шагов по проверке кворума etcd. Так же не совсем ясно, что будет после того, как на всех мастерах выполнится
Правим манифест на перемещаемом хосте /etc/kubernetes/manifests/etcd.yaml:
в разделе --initial-cluster оставляем только адрес перемещённой ноды (можно взять за образец строку из манифеста в /etc/kubernetes.back), убираем раздел --initial-cluster-state=existing
Так же, настройки calico пропущены.
Ну и для случая, когда новый адрес из другой подсети, действий надо побольше, как минимум разобраться с маршрутизацией
Это жёсткая практика, проверенная на нескольких кластерах схожей конфигурации.
Кворум не ломается, т.к. кластер etcd отлично работает на двух нодах и не развалится до момента смерти второй из трёх нод. В случае беспокойства, кластер отлично восстанавливается даже на других ip адресах просто из дампа etcd. И да, это тоже опробовано не единожды. Возможно позже сделаю статью и на эту тему.
>>Так же не совсем ясно, что будет после того, как на всех мастерах выполнится...
Возможно вы невнимательно читали, или я недостаточно подробно описал. Данная процедура производится только на перемещаемой ноде. Состояние кластера etcd хранится в самом кластере. Настройка --initial-cluster, равно как и --initial-cluster-state используется только в момент инициализации ноды и присоединению к кластеру (согласно документации). На дальнейший рестарт ноды etcd это не влияет.
Настройки calico не влияют, т.к. cni система на ноде инициализируется заново. Т.е. нода прохдит через продедуру удаления из кластера и добавления в него. Штатная процедура для kubeadm.
Про маршрутизацию в статье указано: "Дальше тушим ноду, меняем адреса на гипервизоре или железке, поднимаем, проверяем наличие сетевой связности нод."
В реальности переносилось именно в другую подсеть, в другой vlan. И часть времени кластер был размазан между двумя подсетями.
Перенос кластера kubernetes на другие ip адреса