Kubernetes 恢复被摧毁的kubeadm主机

我使用kubeadm 1.20创建了一个1-master 2-workers kubernetes集群，并备份了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

我的部分成功在于，我在销毁master之前创建的秘密在etcd恢复后可见，所以这部分似乎有效

但是，根据coredns吊舱的日志，coredns吊舱无权向api服务器发出请求：

[INFO] plugin/ready: Still waiting on: "kubernetes"
E1229 21:42:25.892580       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.3/tools/cache/reflector.go:125: Failed to list *v1.Namespace: Unauthorized
E1229 21:42:29.680620       1 reflector.go:178] pkg/mod/k8s.io/client-go@v0.18.3/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/client-go@v0.18.3/tools/cache/reflector.go:125: Failed to list *v1.Service: Unauthorized

我猜这与服务帐户令牌有关，所以在etcd db替换之后，我缺少一个步骤来授权POD向api服务器进行身份验证

---

我遗漏了什么？

如果您只备份了Etcd的内容，那么kubeadm将生成用于签名ServiceAccount JWTs的新证书。旧代币将不再验证。由于这通常不是在日常维护期间完成的，我认为SA控制器不知道如何重新颁发令牌。如果您删除了所有的基本机密，那么应该重新发布。

这个问题与编程有什么关系？它可能更适合.@ Turn85：我同意这是一个灰色区域，但请考虑如下：1）在KubNeNes中，大多数任务使用“声明式”编程；2） 如果你看看那些与我的问题有相似标签的问题，我的问题似乎是合适的；3） stackoverflow的kubernetes标签的观察者和问题数量大约是serverfault中相同标签的30倍。我相信更多的观察者也是如此。我也不确定这个问题是否是关于serverfault的主题（因此可能）。我担心答案的质量。开发人员通常不具备操作任务的深入知识（最坏情况：危险的一半知识），尤其是当操作任务与灾难恢复一样复杂时？或还是？那很有效，谢谢！注意，我必须重新启动pod，因为即使从名称空间中删除了挂载的秘密，它也不会消失。好消息是，只有真正需要访问K8SAPI的POD才会受到影响。我还从中发现，您应该保存证书并在恢复时使用它们，这将从一开始就防止此问题的发生。