Я настраиваю etcd для загрузки с помощью обнаружения DNS, но он говорит, что сервер неправильно настроен и, похоже, запрашивает неправильный порт, а записи SRV кажутся неправильными.
Пожалуйста, не могли бы вы просмотреть ниже и увидеть мои вопросы в нижней части этого поста?
Характеристики
корневой домен: etcd.ksone
SRV-запись сервера:
_etcd-server-ssl._tcp.etcd.ksone SRV Простой —
0 0 2380 etcd2.ksone
0 0 2380 etcd1.ksone
клиентская SRV-запись:
_etcd-client-ssl._tcp.etcd.ksone SRV Простой —
0 0 2379 etcd2.ksone
0 0 2379 etcd1.ksone
используя TLS: Истинный
Операционные системы:
[fedora@ip-10-0-0-245 ~]$ uname
линукс
[fedora@ip-10-0-0-245 ~]$ кот /etc/os-релиз
ИМЯ=Федора
ВЕРСИЯ="24 (двадцать четыре)"
ID=федора
VERSION_ID=24
PRETTY_NAME="Fedora 24 (двадцать четыре)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:24"
HOME_URL="https://fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Федора"
REDHAT_BUGZILLA_PRODUCT_VERSION=24
REDHAT_SUPPORT_PRODUCT="Федора"
REDHAT_SUPPORT_PRODUCT_VERSION=24
PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy
версия etcdctl
[fedora@ip-10-0-0-245 ~]$ etcdctl --version
etcdctl версии 2.2.5
Список участников
Я пытаюсь перечислить участников, используя приведенную ниже команду, и получаю следующую ошибку:
bash-4.3# etcdctl --ca-file /etc/etcd/ca.pem --key-file /etc/etcd/kubernetes-key.pem --cert-file /etc/etcd/kubernetes.pem --discovery- srv etcd.ksone --список участников отладки
начать синхронизацию кластера с использованием конечных точек (https://etcd1.ksone.:2380, https://etcd2.ksone.:2380)
Команда cURL: curl -X ПОЛУЧИТЬ https://etcd1.ksone.:2380/v2/members
получил конечные точки () после синхронизации
Конечные точки кластера:
Команда cURL: curl -X GET /v2/members
клиент: кластер etcd недоступен или неправильно настроен
Состояние кластера
Точно так же я могу запросить состояние кластера с помощью следующей команды и вывода:
bash-4.3# etcdctl --ca-file /etc/etcd/ca.pem --key-file /etc/etcd/kubernetes-key.pem --cert-file /etc/etcd/kubernetes.pem --discovery- srv etcd.ksone --debug состояние кластера
Конечные точки кластера: https://etcd1.ksone.:2380, https://etcd2.ksone.:2380
===> ПРИМЕЧАНИЕ: ПЫТАЕТСЯ (НЕПРАВИЛЬНО?) НА ПОРТУ 2380 (СЕРВЕР) Команда cURL: curl -X GET https://etcd1.ksone.:2380/v2/members
кластер может быть неработоспособным: не удалось перечислить участников
Ошибка: неожиданный код состояния 404
SRV записи
Я настроил записи SRV следующим образом
- список SRV для корневого домена, т.е. «etcd.ksone» (ожидаемый результат --> должен показывать полные записи SRV, но ничего не возвращает?):
копать +noall +ответ SRV etcd.ksone
==> <в консоли нет вывода - пусто!>
- перечислить SRV явно для сервера:
# копать +noall +ответ SRV _etcd-server-ssl._tcp.etcd.ksone
_etcd-сервер-ssl._tcp.etcd.ksone. 33 IN SRV 0 0 2380 etcd2.ksone.
_etcd-сервер-ssl._tcp.etcd.ksone. 33 IN SRV 0 0 2380 etcd1.ksone.
- перечислить SRV явно для клиента:
/ # dig +noall +answer SRV _etcd-client-ssl._tcp.etcd.ksone
_etcd-client-ssl._tcp.etcd.ksone. 300 IN SRV 0 0 2379 etcd1.ksone.
_etcd-client-ssl._tcp.etcd.ksone. 300 IN SRV 0 0 2379 etcd2.ksone.
Явно попробуйте конечную точку клиента (УСПЕХ, но на самом деле не используя обнаружение DNS!)
bash-4.3# etcdctl --ca-file /etc/etcd/ca.pem --key-file /etc/etcd/kubernetes-key.pem --cert-file /etc/etcd/kubernetes.pem --debug - -конечная точка https://etcd1.ksone:2379 здоровье кластера
Конечные точки кластера: https://etcd1.ksone:2379
Команда cURL: curl -X ПОЛУЧИТЬ https://etcd1.ksone:2379/v2/members
участник 499073e22ac73562 здоров: получил здоровый результат от https://etcd1.ksone:2379
член b98d4fc780a787fe здоров: получил здоровый результат от https://etcd2.ksone:2379
кластер здоров
Настройка службы etcd
статус systemctl и т. д.
_ etcd.service - etcd
Загружено: загружено (/etc/systemd/system/etcd.service; включено; настройка поставщика: отключена)
Активно: активно (работает) с 01 августа 2021 г., 07:17:39 UTC; 1ч 23мин назад
Документы: https://github.com/coreos
Основной PID: 2363 (и т. д.)
Заданий: 7 (лимит: 512)
Группа CG: /system.slice/etcd.service
__2363 /usr/bin/etcd --name etcd1.ksone --discovery-srv=etcd.ksone --initial-advertise-peer-urls https://etcd1.ksone:2380 --initial-cluster-token etcd-cluster -0 --initial-cluster-state new --advertise-client-urls https://etcd1.ksone:2379 --listen-client-urls https://etcd1.ksone:2379,http://127.0.0.1 :2379 --listen-peer-urls https://etcd1.ksone:2380 --data-dir=/var/lib/etcd/data --cert-file=/etc/etcd/kubernetes.pem --key- file=/etc/etcd/kubernetes-key.pem --peer-cert-file=/etc/etcd/kubernetes.pem --peer-key-file=/etc/etcd/kubernetes-key.pem --trusted- ca-file=/etc/etcd/ca.pem --peer-trusted-ca-file=/etc/etcd/ca.pem
01 августа, 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 стал кандидатом на 41 сроке
01 августа, 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 получил голос от 499073e22ac73562 на сроке 41
01 августа, 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 [logterm: 1, index: 2] отправил запрос на голосование на b98d4fc780a787fe на сроке 41
01 августа, 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 получил голос от b98d4fc780a787fe на сроке 41
01 августа, 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 [q:2] получил 2 голоса и 0 отклонений голосов
01 авг 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 стал лидером на сроке 41
01 августа, 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: raft.node: 499073e22ac73562 избранный лидер 499073e22ac73562 на сроке 41
01 августа, 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: опубликован {Name:etcd1.ksone ClientURLs:[https://etcd1.ksone:2379 ]} в кластер 1c370848b4697ef2
01 августа, 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: установка начальной версии кластера на 2.2
01 августа, 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: установите начальную версию кластера на 2.2
Резюме наблюдений
- Механизм обнаружения на клиенте etcd не работает, о чем свидетельствует приведенная выше ошибка, т.е.
кластер недоступен или неправильно настроен или ``Ошибка: неожиданный код состояния 404```.
- Журналы отладки, кажется, указывают, что он пытается подключиться к одноранговому порту, то есть 2380, вместо клиентского порта, то есть 2379.
- Я могу заставить его работать, только явно установив переключатель конечной точки на порт 2379.
- Запрос SRV в корневом домене работает неправильно, т. е. возвращает пустой результат (без вывода).
статус systemctl и т. д. кажется, указывает на то, что конечная точка была правильно настроена для команды запуска etcd.
Вопросы
- Как правильно запрашивать записи и какие могут быть проблемы (если есть) с конфигурацией dns SRV?
- Почему etcdctl
--discovery-srv коммутатор не работает - я ожидаю, что он обнаружит правильный порт, то есть 2379, и не сообщит об ошибках.
- Должен ли etcd быть сбалансированным? Есть ли одна конечная точка, которую я могу запросить? [Почему] клиент сам выбирает конечную точку? Должен ли я настраивать балансировщик нагрузки поверх моей установки etcd?
Огромное спасибо!
