想象一下以下场景：
- 您在数据中心运行一个使用 kubeadm 部署的 kubernetes 集群。
- 它由一个主节点（以静态 pod 形式运行 etcd，由 kubeadm 部署）和 3 个工作节点组成
- 节点作为在 vmware 上运行的虚拟机
今天，你打开电子邮件，收到通知说数据中心将搬迁到新位置。物理服务器将关闭，搬迁到新位置并再次开机。
您的 kubernetes 集群的正确关闭程序是什么（不会弄乱您的 etcd 数据）？
这是我做的：
- 首先停止主服务器（包括 etcd ofc），以防止当我关闭工作节点时，pod 被重新安排到其他节点。
- 停止每个工作节点
迁移后：
- 首先启动工作节点
- 接下来启动主节点
完成此操作后，我最终遇到了以下两种情况之一：
- etcd 数据损坏，etcd pod 因错误退出
- 收到如下错误：“无法在节点“worker-002”上完成操作：对象已被修改；请将更改应用到最新版本并重试”。我的日志中充斥着这些信息。
如何防止这种情况发生？我认为在 HA 模式下运行 etcd 不会有帮助，因为所有 etcd 节点也必须同时关闭，因此最终会遇到与单节点场景类似的情况。我感觉 Etcd 与其他 K/V 存储（如 Consul）相比相当……脆弱。
答案1
你需要在 master 上停止
- kupe-api 服务器
- kube-调度程序
- kube-控制器
- kubelet（如果适用）
- kube-proxy（如果适用）
如果你有联邦，也请停止 federation-apiserver
运行 etcd 的备份（快照）并在完成后停止 etcd
对于每个节点停止
- 库贝莱特
- kube-proxy
Etcd 与 consul 一样健壮，什么意思instable？！
虽然您有 etcd 数据，但恢复时它不会立即生效...您应该继续阅读kubernetes 上的备份
答案2
事实上，etcd 的基于日志的方法相当有弹性，但为了安全起见，您还是应该在迁移/关闭之前进行备份。如果 etcd 出现问题，只需恢复备份即可。
由于您将重新启动整个集群，因此执行的顺序并不那么重要，所有容器都必须重新启动，这意味着 kubelet 必须连接到一个有效的 API。
你从哪里得到这种对 etcd 不稳定的印象呢，我不知道。