Безопасное удаление мастера из кластера Kubernetes HA - PullRequest
Новая
       102

Безопасное удаление мастера из кластера Kubernetes HA

1 голос
/ 23 января 2020

У меня есть кластер K8S для разработки, развернутый с kops на экземплярах AWS EC2, которые я первоначально развернул как архитектура высокой доступности с 3 мастерами и 3 узлами.

Теперь для экономии средств я хотел бы отключить 2 из 3 мастеров и оставить только 1 работающим

Я пытался с kubectl drain, но это было неэффективно, и просто завершение работы узла приводило к нестабильной работе кластера.

Есть ли безопасный способ удалить мастера?

1 Ответ

1 голос
/ 23 января 2020

Эта проблема уже обсуждалась на вопросе Github - HA для миграции с одного мастера .

Для вас уже подготовлено решение .

С тех пор как etcd-manager был введен в kops 1.12, а main и events Кластеры etcd автоматически и регулярно выполняют резервное копирование в S3 (та же корзина для KOPS_STATE_STORE).

Поэтому, если у вас кластер k8s более новой, чем версия 1.12, возможно, вам понадобятся следующие шаги:

  1. Удалить зоны etcd в кластере 
$ kops edit cluster

В разделе etcdCluster удалить etcdMembers элементов, чтобы оставить только один instanceGroup для main и events. например, 

  etcdClusters:
  - etcdMembers:
    - instanceGroup: master-ap-southeast-1a
      name: a
    name: main
  - etcdMembers:
    - instanceGroup: master-ap-southeast-1a
      name: a
    name: events
Применить изменения 
$ kops update cluster --yes
$ kops rolling-update cluster --yes
Удалите 2 группы экземпляров мастера 
$ kops delete ig master-xxxxxx-1b
$ kops delete ig master-xxxxxx-1c

Это действие не может быть отменено, и оно немедленно удалит 2 мастер-узла.

Теперь 2 из 3 вашего мастера узлы удаляются, службы k8s и т. д. могут быть недоступны, а служба kube-api будет недоступна. Это нормально, что ваши команды kops и kubectl больше не работают после этого шага.

Перезапустите кластер ectd с одним главным узлом.
Это сложная часть. s sh в оставшийся мастер-узел, затем 
$ sudo systemctl stop protokube
$ sudo systemctl stop kubelet

Загрузите инструмент etcd-manager-ctl. Если используется другая версия etcd-manager, измените ссылку для загрузки соответственно 

$ wget https://github.com/kopeio/etcd-manager/releases/download/3.0.20190930/etcd-manager-ctl-linux-amd64
$ mv etcd-manager-ctl-linux-amd64 etcd-manager-ctl
$ chmod +x etcd-manager-ctl
$ mv etcd-manager-ctl /usr/local/bin/

Восстановите резервные копии с S3. См. официальные документы 

$ etcd-manager-ctl -backup-store=s3://<kops s3 bucket name>/<cluster name>/backups/etcd/main list-backups
$ etcd-manager-ctl -backup-store=s3://<kops s3 bucket name>/<cluster name>/backups/etcd/main restore-backup 2019-10-16T09:42:37Z-000001
# do the same for events
$ etcd-manager-ctl -backup-store=s3://<kops s3 bucket name>/<cluster name>/backups/etcd/events list-backups
$ etcd-manager-ctl -backup-store=s3://<kops s3 bucket name>/<cluster name>/backups/etcd/events restore-backup 2019-10-16T09:42:37Z-000001

Это не запускает восстановление немедленно; вам нужно перезапустить etcd: убить связанные контейнеры и запустить kubelet 

$ sudo systemctl start kubelet
$ sudo systemctl start protokube

Дождаться восстановления до конца sh, тогда kubectl get nodes и kops validate cluster должны работать. Если нет, вы можете просто прекратить работу экземпляра EC2 оставшегося главного узла в консоли AWS, новый главный узел будет создан группами автоматического масштабирования и кластер etcd будет восстановлен.

...