восстановить разрушенный мастер кубеадм

Dec 30 2020

Я создал кластер Kubernetes с 1 мастером и 2 рабочими с помощью kubeadm 1.20 и сделал резервную копию файла etcd. Я уничтожил мастер специально, чтобы проверить, как вернуть кластер в рабочее состояние.

Kubernetes version: 1.20
Installation method: kubeadm
Host OS: windows 10 pro
Guest OS: ubuntu 18 on virtual box 6
CNI and version: weave-net
CRI and version: docker 19

Я частично добился успеха в том, что секрет, который я создал перед уничтожением мастера, виден после восстановления etcd, так что эта часть, похоже, работает.

ОДНАКО модули coredns не авторизованы для выполнения запросов к серверу api на основе журналов модулей coredns:

[INFO] plugin/ready: Still waiting on: "kubernetes"
E1229 21:42:25.892580       1 reflector.go:178] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:125: Failed to list *v1.Namespace: Unauthorized
E1229 21:42:29.680620       1 reflector.go:178] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:125: Failed to list *v1.Endpoints: Unauthorized
[INFO] plugin/ready: Still waiting on: "kubernetes"
E1229 21:42:39.492521       1 reflector.go:178] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:125: Failed to list *v1.Service: Unauthorized

Я предполагаю, что это как-то связано с токенами учетных записей служб, поэтому мне не хватает шага для авторизации модулей для аутентификации на api-сервере после замены etcd db.

Что мне не хватает?

Ответы

2 coderanger Dec 30 2020 at 13:38

Если бы вы сделали резервную копию только содержимого Etcd, то kubeadm сгенерировал бы новые сертификаты, используемые для подписи ServiceAccount JWT. Старые токены больше не будут проверяться. Поскольку это обычно не выполняется во время планового обслуживания, я не думаю, что контроллер SA знает, что нужно перевыпускать токены. Если вы удалите все лежащие в основе секреты, он должен будет переиздать.