Нужно ли члену CoreOS иметь публичный ip для присоединения к кластеру etcd2?

Я запускаю 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, так и в альфа-канале

Источник

2 ответа

Я ускорил кластер с теми же настройками, за исключением того, что я включил "Автоматическое назначение публичного IP-адреса" при создании экземпляров, и все просто работало ™

я еще не уверен, почему каждому члену нужен публичный ip, так как он только рекламирует свой $private_ipv4 в сети.

------ редактировать ------

Я обнаружил, что проблема, которая была "исправлена" автоматическим назначением публичного IP-адреса, заключалась в том, что теперь он фактически имел доступ к Интернету (https 443).

Теперь, когда я это знаю, я просто поместил все члены своего кластера в частную подсеть, подключенную к NAT на 80 443, и теперь это работает.

Источник

Я недавно столкнулся с той же проблемой. Кажется, что общедоступный адрес - это не столько требование для etcd2, сколько для интернет-шлюзов в VPC. В документации говорится:

Убедитесь, что экземпляры в вашей подсети имеют общедоступные IP-адреса или эластичные IP-адреса.

Источник
Другие вопросы по тегам