Это потому, что у kops есть концепция групп экземпляров . На AWS они напрямую сопоставляются с AutoScalingGroup, что является аналогичной концепцией. Вы можете проверить свои группы экземпляров, запустив kops get ig, а также отредактировать и удалить накипи свой мастер и узлы до 0, а затем повторно запустить их с помощью kops edit ig nodes/nameofthemaster. Вторая часть - kops State Store . Который является местом, где находится конфигурация кластера. Это соответствует большей части конфигурации Kubernetes, за исключением некоторых ресурсов и, например, развертываний (например, внутреннего состояния), которые хранятся в etcd .
Таким образом, в вашем случае, когда вы удаляете главный узел, AWS увидит, что состояние вашей AutoScalingGroup равно 0 вместо 1, поэтому он воссоздает компьютер EC2.
Description:DescriptionLaunching a new EC2 instance: i-0e06f8fbb78aca2e6
Cause:CauseAt 2019-04-10T12:54:31Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 0 to 1.
После этого Kubernetes получит свою конфигурацию из корзины S3 и внутреннее состояние из etcd. Следующим вопросом будет, как etcd выживет после удаления мастера. Вы можете проверить это в своих томах, так как etcd имеет два отдельных тома (так же, как и пакеты etcd, один для событий и один основной). После удаления главного тома переходят в состояние avalivable, а после этого новый том EC2 порождает эти тома. будет подключен к новому мастеру, и вы восстановите внутреннее состояние (не уверен, но я думаю, что protokube также находится где-то на рисунке).
Это также причина, по которой вы можете восстановить кластер kops только из корзины s3, поскольку есть все настройки, которые необходимы для запуска kops. За исключением внутреннего состояния, которое находится в etcd, для которого вам потребуется отдельное резервное копирование.