amazon-web-services - CoreOS AWS Cloudinit 问题

Question

我正在尝试使用 CoreOS 稳定 AMI 和一些自定义 cloud-init 配置来设置 EC2 实例，但遇到了一些问题。

#cloud-config
coreos:
  etcd:
    discovery: https://discovery.etcd.io/5996f1b49fd642c5d1bc2f62cbff2fba
    addr: $private_ipv4:4001
    peer-addr: $private_ipv4:7001
  units:
    - name: etcd.service
      command: start
    - name: fleet.service
      command: start
write_files:
  - path: /etc/fleet/fleet.conf
    content: |
      public_ip="$private_ipv4"
      metadata="elastic_ip=true,public_ip=$public_ipv4"

上面的 cloud-config 工作正常，但是一旦我使用下面的 cloud-config

#cloud-config
coreos:
  etcd:
    discovery: https://discovery.etcd.io/5996f1b49fd642c5d1bc2f62cbff2fba
    addr: $private_ipv4:4001
    peer-addr: $private_ipv4:7001
  units:
    - name: etcd.service
      command: start
    - name: fleet.service
      command: start
users:
  - name: core
    coreos-ssh-import-github: oba11
write_files:
  - path: /etc/fleet/fleet.conf
    content: |
      public_ip="$private_ipv4"
      metadata="elastic_ip=true,public_ip=$public_ipv4"

或者

#cloud-config
coreos:
  etcd:
    discovery: https://discovery.etcd.io/5996f1b49fd642c5d1bc2f62cbff2fba
    addr: $private_ipv4:4001
    peer-addr: $private_ipv4:7001
  units:
    - name: etcd.service
      command: start
    - name: fleet.service
      command: start
users:
  - name: oba11
    groups:
      - sudo
      - docker
    coreos-ssh-import-github: oba11
write_files:
  - path: /etc/fleet/fleet.conf
    content: |
      public_ip="$private_ipv4"
      metadata="elastic_ip=true,public_ip=$public_ipv4"

我无法使用我的 aws key 对或个人 key 作为“核心”用户再次通过 SSH 连接到 coreos 实例，也无法使用我的个人 key 创建用户“oba11”。
我也试过 alpha AMI 但同样的问题。
我不知道我是不是做错了什么。

非常感谢您的帮助。

Answer 1

您正在使用陈旧的 etcd 发现 token ID。

一旦你的集群节点使用了这个 id， token 就会被标记为已使用，如果由于某种原因没有 etcd 节点心跳到这个地址， token 就会变得无用。

如果您尝试使用相同的 etcd 发现 URI 启动新集群或单个节点，引导过程将失败。

在您的情况下，EC2 节点将提供 ssh 服务，但不会使用该云配置正确配置它们。

您遇到的行为(连接但拒绝您的 PK)是预料之中的，如果您没有阅读 https://coreos.com/docs/cluster-management/setup/cluster-discovery/ 上的文档，可能会导致头痛。哪里有说明；

Another common problem with cluster discovery is attempting to boot a new cluster with a stale discovery URL. As explained above, the initial leader election is recorded into the URL, which indicates that the new etcd instance should be joining an existing cluster.

If you provide a stale discovery URL, the new machines will attempt to connect to each of the old peer addresses, which will fail since they don't exist, and the bootstrapping process will fail.