恢复被破坏的 kubeadm master答案

【问题标题】：restore destroyed kubeadm master恢复被破坏的 kubeadm master
【发布时间】：2021-04-06 12:09:25
【问题描述】：

我使用 kubeadm 1.20 创建了一个 1-master 2-workers kubernetes 集群并备份了 etcd。我故意销毁了master，看看如何让集群恢复运行状态。

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 pod 的日志，coredns pod 未经授权向 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

我猜它与服务帐户令牌有关，所以我缺少一个步骤来授权 pod 在替换 etcd 数据库后向 api-server 进行身份验证。

我错过了什么？

【问题讨论】：

这个问题和编程有什么关系？它可能更适合serverfault。
@Turing85 我同意这是一个灰色地带，但请考虑一下：1）在 kubernetes 中，大多数任务使用“声明式”编程； 2）如果您查看与我的标签相似的问题，我的问题似乎很合适； 3) stackoverflow 的 kubernetes 标签的观察者和问题的数量大约是 serverfault 中相同标签的 30 倍。
我相信 SO 有更多的观察者。我也不确定这个问题是否与服务器故障有关（因此可能）。我担心答案的质量。开发人员通常对操作任务没有深入的了解（最坏的情况：危险的半知识），尤其是当它们像灾难恢复一样复杂时。
与stackoverflow.com/questions/51370870/… 有什么区别？或stackoverflow.com/questions/34486213/…？或stackoverflow.com/questions/51631714/…?

标签： kubernetes kubeadm etcd etcdctl

【解决方案1】：

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

【讨论】：

成功了，谢谢！请注意，我必须重新启动 pod，因为即使从命名空间中删除了已安装的密钥，它也不会消失。好消息是，只有真正需要访问 k8s api 的 pod 才会受到影响。我还从elastisys.com/backup-kubernetes-how-and-why 发现您应该保存证书并在还原时使用它们，这将首先防止此问题发生。