【问题标题】:Recovering Kubernetes cluster without certs在没有证书的情况下恢复 Kubernetes 集群
【发布时间】:2020-11-11 09:43:43
【问题描述】:

我在实验室中有以下情况,想看看是否可以恢复。集群已损坏,但非常符合预期,因为我正在测试我可以通过破坏集群走多远并且仍然能够恢复。

环境: Kubernetes 1.16.3 Kubespray

我做了一些试验,在这个集群上没有任何数据,但我仍然很好奇是否有可能恢复。我有一个健康的 3 节点 etcd 集群,具有原始配置(所有命名空间、工作负载、配置映射等)。我没有用于控制平面的原始 SSL 证书。

我从集群中删除了所有节点(kubeadm 重置)。我有原始清单和 kubelet 配置,并尝试重新初始化主节点。它比我想象的要成功,但不是我想要的。 kubeadm init 成功后,kubelet 和 control plane 容器启动成功,但没有创建相应的 Pod。我可以将 kube API 与 kubectl 一起使用,并查看节点、命名空间、部署等。

在 kube-system 命名空间中,所有守护程序集仍然存在,但 pod 不会以以下消息开始:

49m         Warning   FailedCreate        daemonset/kube-proxy                                Error creating: Timeout: request did not complete within requested timeout

kubelet 记录以下 re control plane pods

Jul 21 22:30:02 k8s-master-4 kubelet[13791]: E0721 22:30:02.088787   13791 kubelet.go:1664] Failed creating a mirror pod for "kube-scheduler-k8s-master-4_kube-system(3e128801ef687b022f6c8ae175c9c56d)": Timeout: request did not complete within requested timeout
Jul 21 22:30:53 k8s-master-4 kubelet[13791]: E0721 22:30:53.089517   13791 kubelet.go:1664] Failed creating a mirror pod for "kube-controller-manager-k8s-master-4_kube-system(da5cfae13814fa171a320ce0605de98f)": Timeout: request did not complete within requested timeout

在 kubeadm 重置/初始化过程中,我已经完成了一些步骤,因此我可以到达现在的位置(删除服务帐户以重置令牌,删除一些配置映射(kuebadm 等))

我的问题是 - 是否可以在没有证书的情况下恢复控制平面。如果它复杂但仍然可能的过程,我仍然想知道。

感谢所有帮助

亨利

【问题讨论】:

    标签: kubernetes kubeadm


    【解决方案1】:

    是否可以在没有证书的情况下恢复控制平面。

    是的,应该可以。证书 ? 是必需的,但它们不必与您最初创建集群时使用的证书完全相同。所有certificates 包括CA 都可以全盘旋转。 kubelet 甚至支持certificate auto-rotation。不过,配置需要在任何地方匹配。这意味着 CA 需要与创建 CSR 的 CA 相同,并且证书密钥/证书需要从相同的 CSR 创建。 ?

    此外,所有组件都需要使用相同的 CA 并能够通过 API 服务器进行身份验证(kube-controller-manager、kube-scheduler 等)?。我不完全确定您看到的日志,但看起来 kube-controller-manager 和 kube-scheduler 无法进行身份验证并加入集群。所以我会看看他们的证书配置:

    • /etc/kubernetes/kube-controller-manager.conf
    • /etc/kubernetes/kube-scheduler.conf

    此外,您还可以在 /etc/kubernetes/pki 下找到需要验证的每个 PKI 组件

    ✌️

    【讨论】:

    • 谢谢里科!我忘记提到的一个有趣的事实是,我在 apiserver pod 上遇到了同样的错误,但几天后,pod 最终被创建了。我正在查看调度程序和控制器管理器的证书配置,但我认为这些已经是新的,并且由 kube adm 在初始化阶段之一创建。我认为集群内必须有更多的证书配置用于 pod 和控制器。
    • 我有一些好消息。集群仍部分损坏,但控制平面 pod(包括 kube-proxy、calico、dns pod)现在已启动并运行。我找到了这个success.docker.com/article/…,但不确定它与我的情况有何关系。我有三个变异的 webhook 并将它们全部删除。一旦我删除了它们,就会创建 Pod 并开始安排它们。
    • 此时它只是几个应用程序,如 prometheus 或 cert-manager,主要是因为身份验证。我相信这很容易解决。我还能够添加一堆新的主节点和工作节点。我将不得不阅读 webhook 以更好地了解它们如何防止创建控制平面 pod。
    • 现在全部修复。控制平面重新部署,所有应用程序正常工作。
    • 太棒了,很高兴听到!
    猜你喜欢
    • 2016-10-10
    • 2019-03-18
    • 2017-09-04
    • 2019-12-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-02-10
    • 2012-08-16
    相关资源
    最近更新 更多