GCloud虚拟机部署Rancher后创建第二个集群时Etcd Plane启动失败问题排查

看起来你遇到的这个问题确实挺棘手的——第一个集群能正常跑，第二个就卡Etcd健康检查，而且只有全清数据或者换VM才能解决，太影响效率了。结合你描述的操作和尝试过的方案，我整理几个针对性的排查方向和解决方案，你可以试试：

一、先纠正本地kubeconfig的使用逻辑 #

你提到创建第一个集群后会手动编辑~/.kube/config指向Rancher的local集群，其实这个操作可能是核心诱因之一。Rancher本身是用来管理多集群的，它的local集群是Rancher自身运行的集群，你手动把本地上下文固定到这个集群后，后续创建新集群时，Rancher可能会因为本地配置的干扰，出现集群上下文混淆的问题。

建议你这么调整：

1. 先备份当前的~/.kube/config文件（比如复制到~/.kube/config.backup），避免误操作丢配置。
2. 重置本地kubeconfig：可以直接删除原文件，或者用kubectl config unset current-context取消当前上下文，之后不要手动修改指向local集群。
3. 当需要操作某个具体集群时，从Rancher UI的集群详情页下载对应集群的kubeconfig，然后通过kubectl --kubeconfig=<下载的配置文件> ...来操作，或者用kubectl config use-context <集群名称>切换上下文，保持各集群配置的独立性。

二、排查GCloud VM的资源与网络限制 #

第一个集群正常运行后，第二个集群的Etcd节点可能因为资源不足或网络不通导致健康检查失败：

• 资源方面：检查你的GCloud VM配置，比如如果是n1-standard-1这类低配置机型，第一个集群的Etcd、控制平面已经占用了大部分CPU/内存，第二个集群的Etcd节点根本无法正常启动。建议你升级VM的资源规格（比如至少n1-standard-2，2核4G以上），或者在创建第二个集群时，调低控制平面节点的资源请求（在Rancher的集群创建页面，找到Etcd/Control Plane的资源限制设置）。
• 网络方面：GCloud的防火墙默认会拦截很多端口，你需要确保Rancher管理的集群之间能正常通信：
  1. 检查VM的防火墙规则，开放Etcd的核心端口：2379（客户端通信）、2380（节点间同步）。
  2. 确认VM的内部IP能被集群节点访问，没有被VPC网络的隔离规则限制。
• 日志排查：直接看失败集群的Etcd节点日志，定位具体的健康问题。你可以在Rancher UI进入失败集群的节点详情，找到Etcd容器查看日志；或者登录到GCloud VM上，用docker ps找到Etcd相关的容器ID，再用docker logs <容器ID>查看具体的错误信息，比如是不是节点无法加入集群、证书错误还是磁盘IO问题。

三、针对性清理异常集群的残留数据（替代全量清理） #

你提到的全量清理脚本会删掉所有集群，其实我们可以只清理失败集群的残留数据，保留正常的第一个集群：

1. 先在Rancher UI中删除失败的第二个集群，等待Rancher完成自动清理（可能需要几分钟）。
2. 登录到GCloud VM上，检查Rancher的存储：
   • 如果是用Docker挂载本地目录部署的Rancher（比如-v /opt/rancher:/var/lib/rancher），进入/opt/rancher目录，找到对应失败集群的Etcd数据目录（通常以集群ID命名），手动删除。
   • 如果是用Docker卷存储，先执行docker volume ls找到Rancher相关的卷，然后用docker volume rm <卷名>删除对应失败集群的残留卷。
3. 清理完成后，再尝试创建新集群，应该不会影响现有第一个集群的运行。

四、调整Rancher的部署参数（针对Docker单容器部署） #

如果你的Rancher是用单Docker容器部署的，默认配置可能不足以支持多集群管理：

• 确保Rancher使用持久化存储：部署时一定要加上-v /opt/rancher:/var/lib/rancher的挂载参数，避免Rancher的元数据存在临时存储中，导致集群状态异常。
• 给Rancher容器分配足够的资源：启动容器时加上--cpus=2 --memory=4g这类参数，让Rancher Server有足够的CPU和内存来管理多个集群。

按照这个顺序排查，应该能解决你的问题，不用再频繁删除所有数据或新建VM了。

备注：内容来源于stack exchange，提问作者Augusto Occhiuzzi