【发布时间】：2015-12-22 08:28:44
【问题描述】：
我正在尝试在 VPC 内的 AWS EC2 实例上设置一个小型 CoreOS 集群。 在本练习中，我使用了两个 Auto Scaling 组，其中 3 台机器中的一台将形成核心 etcd 和 consul 集群，然后是第二个 Auto Scaling 组，目前只有一个节点，该节点实际上会随着应用程序的增长而扩展。它们都在一个共同的 etcd 集群中。
本周 coreos.com 将 build 681 发布到 stable 分支，其中一个节点立即更新为 681.0，但 48 小时后，主集群中的 3 个节点仍保持在 647.2 版本。当我查看期刊时，我看到以下内容：
Jun 11 14:25:17 ip-10-0-68-116.ec2.internal update_engine[477]: [0611/142517:INFO:libcurl_http_fetcher.cc(48)] Starting/Resuming transfer
Jun 11 14:25:17 ip-10-0-68-116.ec2.internal update_engine[477]: [0611/142517:INFO:libcurl_http_fetcher.cc(164)] Setting up curl options for HTTPS
Jun 11 14:25:17 ip-10-0-68-116.ec2.internal update_engine[477]: [0611/142517:INFO:libcurl_http_fetcher.cc(427)] Setting up timeout source: 1 seconds.
Jun 11 14:25:17 ip-10-0-68-116.ec2.internal update_engine[477]: [0611/142517:INFO:libcurl_http_fetcher.cc(240)] HTTP response code: 200
Jun 11 14:25:17 ip-10-0-68-116.ec2.internal update_engine[477]: [0611/142517:INFO:libcurl_http_fetcher.cc(297)] Transfer completed (200), 267 bytes downloaded
Jun 11 14:25:17 ip-10-0-68-116.ec2.internal update_engine[477]: [0611/142517:INFO:omaha_request_action.cc(574)] Omaha request response: <?xml version="1.0" encoding="UTF-8"?>
Jun 11 14:25:17 ip-10-0-68-116.ec2.internal update_engine[477]: <response protocol="3.0" server="update.core-os.net">
Jun 11 14:25:17 ip-10-0-68-116.ec2.internal update_engine[477]: <daystart elapsed_seconds="0"></daystart>
Jun 11 14:25:17 ip-10-0-68-116.ec2.internal update_engine[477]: <app appid="e96281a6-xxxx-xxxx-xxxx-xxxxxxxxxxxx" status="ok">
Jun 11 14:25:17 ip-10-0-68-116.ec2.internal update_engine[477]: <updatecheck status="noupdate"></updatecheck>
Jun 11 14:25:17 ip-10-0-68-116.ec2.internal update_engine[477]: </app>
Jun 11 14:25:17 ip-10-0-68-116.ec2.internal update_engine[477]: </response>
所以节点得到没有更新的响应。
这是 coreos 团队尝试负载平衡他们的文件服务器的方式，还是有一些额外的配置？这是 coreos 试图将我推向付费服务的方式吗？我对更新过程的理解是节点会像多米诺骨牌一样一个接一个地更新。
这是我当前的集群状态：
for m in $(fleetctl list-machines -fields="machine" -full -no-legend); do fleetctl ssh $m cat /etc/lsb-release; done
DISTRIB_ID=CoreOS
DISTRIB_RELEASE=647.2.0
DISTRIB_CODENAME="Red Dog"
DISTRIB_DESCRIPTION="CoreOS 647.2.0"
DISTRIB_ID=CoreOS
DISTRIB_RELEASE=681.0.0
DISTRIB_CODENAME="Red Dog"
DISTRIB_DESCRIPTION="CoreOS 681.0.0"
DISTRIB_ID=CoreOS
DISTRIB_RELEASE=647.2.0
DISTRIB_CODENAME="Red Dog"
DISTRIB_DESCRIPTION="CoreOS 647.2.0"
DISTRIB_ID=CoreOS
DISTRIB_RELEASE=647.2.0
DISTRIB_CODENAME="Red Dog"
DISTRIB_DESCRIPTION="CoreOS 647.2.0"
一周后更新：集群仍卡在半升级状态。如果有人有任何经验，我很想知道如何调试此类问题。
【问题讨论】：
-
CoreOS 因 bug 取消了 681 版本。 ref: github.com/coreos/bugs/issues/383 "稳定版频道目前已暂停（我们收到了太多错误报告）。更新引擎正确报告没有可用的升级。如果您真的想尝试新的稳定版，您可以使用最新映像配置新实例。”当稳定频道有新的升级版本时再试一次，因为从技术上讲，647 是目前最新的稳定版本。您可以使用
update_engine_client -check_for_update强制进行更新检查。 -
非常感谢您的澄清。
-
CoreOS 681.2.0 已发布，修复了许多问题。您现在应该能够成功更新，但需要将您的 681 系统更新到 681.2 才能同步。
-
我看到了 681.2 版本。今天早上有两台机器在新的 681.2 上（一台最初在 681.0 上，第一台在 647.2 上）现在很多小时后最后两台机器仍在 647.2 上……我想知道 681.2 是否也停止了？但是在运行
update_engine_client -check_for_update之后，我看到在 #3 机器上开始下载。
标签： amazon-web-services coreos