基于Vagrant的CoreOS集群etcd启动配置异常，寻求Kubernetes部署方案

首先得说，完全懂你觉得CoreOS（准确说现在是Container Linux，已经停止更新维护了）浪费时间的感受——这玩意儿现在确实有点过时了，折腾起来性价比太低。给你推荐几个更省心的部署方案：

更优部署方案推荐 #

• 用kubeadm配合Ubuntu Server/Fedora Server：这是目前社区最主流的轻量部署方式，文档齐全，问题排查资源多，3节点集群搭起来步骤清晰，不需要跟旧的CoreOS配置死磕。
• Fedora CoreOS（FCOS）：这是CoreOS的官方继任者，专门为容器化 workload 设计，支持自动更新，配合Ignition配置（替代原来的cloud-config），用Vagrant或者云实例部署都比旧CoreOS顺畅，而且跟Kubernetes兼容性更好。
• K3s：如果是测试/边缘场景，K3s是轻量版Kubernetes，单二进制文件，资源占用极低，3节点集群几分钟就能搭好，完全不用折腾复杂的etcd配置，自带嵌入式数据库或者可以外接etcd。

如果你还想救一下CoreOS Vagrant集群 #

既然你已经按官方指南改了user-data和config.rb，拿到了新的发现令牌，那可以从这几个方向排查：

1. 检查user-data里的etcd2配置格式是否正确，比如：

   #cloud-config
   coreos:
     etcd2:
       discovery: https://discovery.etcd.io/7bxxxxxx
       advertise-client-urls: http://$private_ipv4:2379
       initial-advertise-peer-urls: http://$private_ipv4:2380
       listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
       listen-peer-urls: http://$private_ipv4:2380,http://$private_ipv4:7001
   

   要确保变量$private_ipv4能被CoreOS正确解析，Vagrant环境里这个变量应该是有效的，但可以手动替换成节点的私有IP试试。
2. 检查Vagrant的config.rb里的私有IP段是否和你的本地网络不冲突，比如默认的172.17.8.101这种，有没有被其他设备占用。
3. 登录到CoreOS节点，查看etcd2的日志：journalctl -u etcd2 -f，看有没有连接不到发现服务器、IP冲突或者令牌过期的报错——发现令牌是有有效期的，要是隔了太久才启动集群，得重新生成一个。
4. 确认Vagrant的CoreOS镜像是不是最新的可用版本（毕竟Container Linux已经停更，找最后发布的稳定镜像），老镜像可能有etcd2的兼容性bug。

总的来说，还是建议直接换更现代的方案，省得在停更的系统上浪费时间。

内容的提问来源于stack exchange，提问作者Marco Massenzio