Coreos 队列在自动缩放后不工作答案

【问题标题】：Coreos fleet not working after auto-scalingCoreos 队列在自动缩放后不工作
【发布时间】：2014-11-19 09:19:57
【问题描述】：

我有带有 3 个 AWS ec2 实例的 CoreOS 集群。集群是使用 CoreOS 堆栈 cloudformation 设置的。集群启动并运行后，我需要更新自动缩放策略以获取 ec2 实例配置文件。我复制了现有的自动扩展配置文件并更新了 ec2s 的 IAM 角色。然后我终止了队列中的 EC2，让自动扩展启动新实例。新实例确实承担了它们的新角色，但是，集群似乎丢失了集群机器信息：

ip-10-214-156-29 ~ # systemctl -l status etcd.service
● etcd.service - etcd
   Loaded: loaded (/usr/lib64/systemd/system/etcd.service; disabled)
  Drop-In: /run/systemd/system/etcd.service.d
       └─10-oem.conf, 20-cloudinit.conf
   Active: activating (auto-restart) (Result: exit-code) since Wed 2014-09-24 18:28:58 UTC; 9s ago
  Process: 14124 ExecStart=/usr/bin/etcd (code=exited, status=1/FAILURE)
 Main PID: 14124 (code=exited, status=1/FAILURE)

Sep 24 18:28:58 ip-10-214-156-29.us-west-2.compute.internal systemd[1]: etcd.service: main process  exited, code=exited, status=1/FAILURE
Sep 24 18:28:58 ip-10-214-156-29.us-west-2.compute.internal systemd[1]: Unit etcd.service entered failed state.
Sep 24 18:28:58 ip-10-214-156-29.us-west-2.compute.internal etcd[14124]: [etcd] Sep 24 18:28:58.206 INFO      | d9a7cb8df4a049689de452b6858399e9 attempted to join via 10.252.78.43:7001 failed: fail checking join version: Client Internal Error (Get http://10.252.78.43:7001/version: dial tcp 10.252.78.43:7001: connection refused)
Sep 24 18:28:58 ip-10-214-156-29.us-west-2.compute.internal etcd[14124]: [etcd] Sep 24 18:28:58.206 WARNING   | d9a7cb8df4a049689de452b6858399e9 cannot connect to existing peers [10.214.135.35:7001 10.16.142.108:7001 10.248.7.66:7001 10.35.142.159:7001 10.252.78.43:7001]: fail joining the cluster via given peers after 3 retries
Sep 24 18:28:58 ip-10-214-156-29.us-west-2.compute.internal etcd[14124]: [etcd] Sep 24 18:28:58.206 CRITICAL  | fail joining the cluster via given peers after 3 retries

在 cloud-init 中使用了相同的令牌。 https://discovery.etcd.io/<clustertoken> 显示 6 台机器，3 台死机，3 台新机。所以看起来有 3 个新实例加入了集群。 journal -u etcd.service 日志显示 etcd 在死实例上超时，并且新实例的连接被拒绝。

journal -u etcd.service shows: 
...

Sep 24 06:01:11 ip-10-35-142-159.us-west-2.compute.internal etcd[574]: [etcd] Sep 24 06:01:11.198 INFO      | 5c4531d885df4d06ae2d369c94f4de11 attempted to join via 10.214.156.29:7001 failed: fail checking join version: Client Internal Error (Get http://10.214.156.29:7001/version: dial tcp 10.214.156.29:7001: connection refused)

etcdctl --debug  ls
Cluster-Peers: http://127.0.0.1:4001 http://10.35.142.159:4001
Curl-Example: curl -X GET http://127.0.0.1:4001/v2/keys/?     consistent=true&recursive=false&sorted=false
Curl-Example: curl -X GET http://10.35.142.159:4001/v2/keys/?consistent=true&recursive=false&sorted=false
Curl-Example: curl -X GET http://127.0.0.1:4001/v2/keys/?consistent=true&recursive=false&sorted=false
Curl-Example: curl -X GET http://10.35.142.159:4001/v2/keys/?consistent=true&recursive=false&sorted=false
Error:  501: All the given peers are not reachable (Tried to connect to each peer twice and failed) [0]

也许这不是更新集群配置的正确过程，但如果集群确实需要自动扩展无论出于何种原因（例如负载触发），队列仍然能够在死实例和新实例混合的情况下运行游泳池？

如何在不拆除和重建的情况下从这种情况中恢复？

雪山

【问题讨论】：

标签： amazon-ec2 autoscaling coreos

【解决方案1】：

您必须至少有一台机器始终使用发现令牌运行，一旦它们全部关闭，心跳将失败并且没有新的能够加入，您将需要一个新的令牌才能加入集群.

【讨论】：

【解决方案2】：

在此方案中，etcd 不会保留在法定人数中，并且无法成功运行。进行自动缩放的最佳方案是设置两组机器：

固定数量 (1-9) 的 etcd 机器将始终运行。这些设置与正常的发现令牌或静态网络一样。
您的自动扩展组，它不会启动 etcd，而是将队列（和任何其他工具）配置为使用固定的 etcd 集群。您可以在 cloud-config 中执行此操作。下面是一个示例，它还设置了一些队列元数据，以便您可以根据需要将作业专门安排到自动缩放的机器上：

#cloud-config
coreos:
  fleet:
    metadata: "role=autoscale"
    etcd_servers: "http://:4001,http://:4001,http://:4001,http://:4001,http://:4001,http://:4001"
  units:
    - name: fleet.service
      command: start

验证器不允许我在我的答案中输入任何10.x IP 地址（wtf！？）所以一定要替换那些。

【讨论】：