Парк Coreos не работает после автоматического масштабирования

У меня есть кластер CoreOS с 3 экземплярами AWS ec2. Кластер был настроен с использованием облачного формирования стека CoreOS. После того, как кластер запущен и работает, мне нужно обновить политику автомасштабирования, чтобы получить профиль экземпляра ec2. Я скопировал существующий файл конфигурации автоматического масштабирования и обновил роль IAM для ec2s. Затем я отключил 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/‹cluster токен› показывает 6 машин, 3 из которых не работают , 3 новых. Итак, похоже, что 3 новых экземпляра присоединились к кластеру. В журналах журнала -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
person Xueshan Feng    schedule 24.09.2014    source источник

Ответы (2)


arrow_upward
1
arrow_downward

В этой схеме etcd не останется с кворумом машин и не сможет успешно работать. Лучшей схемой автомасштабирования будет создание двух групп машин:

  1. Фиксированное количество (1-9) машин etcd, которые всегда будут работать. Они настроены с токеном обнаружения или статической сетью, как обычно.
  2. Ваша группа автомасштабирования, которая не запускает 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!?), поэтому обязательно замените их.

person Rob    schedule 26.09.2014

arrow_upward
1
arrow_downward

У вас должна быть по крайней мере одна машина, всегда работающая с токеном обнаружения, как только все они выйдут из строя, сердцебиение перестанет работать, и ни один новый не сможет присоединиться, вам понадобится новый токен для присоединения к кластеру.

person ART GALLERY    schedule 29.01.2015