Я запускаю 5 членов coreos EC2 в частной подсети. Затем назначьте один эластичный IP-адрес одному из элементов. Кажется, что только тот, у кого назначен IP-адрес, может присоединиться к кластеру etcd2 и постоянно ожидает другого 4.
вот моя облачная конфигурация
#cloud-config
coreos:
update:
reboot-strategy: "etcd-lock"
etcd2:
discovery: "https://discovery.etcd.io/_____hash_____"
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"
fleet:
public-ip: "$private_ipv4"
metadata: "region=us-west"
units:
- name: "etcd2.service"
command: "start"
- name: "fleet.service"
command: "start"
вот ошибки от участника с публичным ip
error #0: client: etcd member https://discovery.etcd.io returns server error [Gateway Timeout]
waiting for other nodes: error connecting to https://discovery.etcd.io, retrying in 4m16s
found self ae44c4332ec3c211 in the cluster
found 1 peer(s), waiting for 4 more
остальные 4 члена не заходят так далеко
listening for peers on http://10.0.0.50:2380
listening for peers on http://10.0.0.50:7001
listening for client requests on http://0.0.0.0:2379
listening for client requests on http://0.0.0.0:4001
etcd2.service: Main process exited, code=exited, status=1/FAILURE
Failed to start etcd2.
etcd2.service: Unit entered failed state.
etcd2.service: Failed with result 'exit-code'.
Правила для входящих подключений группы безопасности
Custom TCP 7001 VPC subnet
SSH TCP 22 0.0.0.0/0
Custom TCP 4001 VPC subnet
Custom TCP 2379 VPC subnet
Custom TCP 2380 VPC subnet
Я тестировал это как в стабильном канале CoreOS, так и в альфа-канале
Я развернул кластер с теми же настройками, за исключением того, что я включил «Автоматически назначать общедоступный IP-адрес» при создании экземпляров, и все просто работал ™
Я еще не уверен, зачем каждому участнику нужен общедоступный IP-адрес, поскольку они только рекламируют свой $ private_ipv4 в сети.
------ редактировать ------
Я обнаружил, что проблема, которая была «исправлена» путем автоматического назначения общедоступного IP-адреса, заключалась в том, что теперь у него был доступ к Интернету (https 443)
Теперь, когда я это знаю, я просто поместил всех членов своего кластера в частную подсеть, подключенную к NAT для 80 443, и теперь это работает.
Недавно я столкнулся с той же проблемой. Похоже, что публичный адрес - это не столько требование etcd2, сколько это требуется для интернет-шлюзов в VPC. Документация документация говорит:
Убедитесь, что экземпляры в вашей подсети имеют общедоступные IP-адреса или эластичные IP-адреса.