<p>kubeadm reset успешно, но этот IP-адрес узла все еще находится в configmap kubeadm-config</p>

cc @fabriziopandini

В идеале должен быть способ «обновить» ClusterStatus. Мы запускаем кластеры с хаотическим тестированием, вполне возможно, что узел уровня управления будет завершен без предупреждения и без возможности запустить kubeadm reset . В идеале был бы чистый способ явно обновить ClusterStatus, чтобы удалить узлы плоскости управления, которые, как мы знаем, больше не находятся в кластере. Это то, что нужно сделать перед запуском kubeadm join --control-plane ... или, возможно, оно встроено?

Некоторые комментарии здесь:

kubeadm-config ConfigMap удалить этот ip узла.

@pytimer Я знаю, что наличие адреса api узла, оставленного в статусе кластера, не идеально, но мне интересно понять, вызывает ли это «отсутствие очистки» проблемы или нет. Вы пытались снова присоединиться к той же плоскости управления? вы пробовали присоединиться к другому самолету управления? Я не ожидаю проблем, но я буду благодарен за подтверждение по этому поводу.

У меня все еще вопрос, почему kubeadm reset не удаляет этот узел напрямую из кластера? Вместо этого запустите kubectl delete nodeвручную.

@luxas может быть здесь немного исторического контекста.
Я предполагаю, что у узла не было права удалять себя (но это относится к рабочим узлам, а не к узлам уровня управления ...)

В идеале был бы способ «обновить» ClusterStatus / был бы чистый способ явно обновить ClusterStatus

@danbeaulieu , это хороший
Однако, будучи kubeadm без какого-либо непрерывно работающего цикла управления, я думаю, что всегда будет возможность рассинхронизировать ClusterStatus.
Это не должно быть проблемой, или, точнее говоря, наличие IP-адреса узла для узлов, которые больше не существуют (отсутствие очистки), не должно быть проблемой.
Вместо этого, если узел существует и соответствующий IP-адрес узла отсутствует в ClusterStatus (неправильная инициализация), это может создать проблемы, например, для обновлений.

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

@fabriziopandini Я присоединяюсь к тому же узлу уровня управления, это не удалось.

Мои шаги присоединения:

IP второго узла плоскости управления - 192.168.46.212 .

• удалите узел 192.168.46.212 узел etcd из кластера etcd.
• kubectl delete node k8s-212
• kubeadm reset -f на этом узле плоскости управления.
• снова запустите kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5 .

журналы присоединения kubeadm:

...
[etcd] Checking Etcd cluster health
I1207 17:57:18.109993    8541 local.go:66] creating etcd client that connects to etcd pods
I1207 17:57:18.110000    8541 etcd.go:134] checking etcd manifest
I1207 17:57:18.119797    8541 etcd.go:181] etcd endpoints read from pods: https://192.168.46.211:2379,https://192.168.46.212:2379
I1207 17:57:18.131111    8541 etcd.go:221] etcd endpoints read from etcd: https://192.168.46.211:2379
etcd cluster is not healthy: context deadline exceeded

Я вижу код kubeadm и думаю, что эта проблема может быть вызвана 192.168.46.212, оставленным в kubeadm-config ConfigMap.

Kubeadm получает конечные точки api из kubeadm-config ConfigMap при присоединении к узлу уровня управления, а конечные точки etcd аналогичны конечным точкам api. Но узел 912.168.46.212 управления был удален и еще не присоединен, поэтому проверьте состояние кластера etcd неправильно.

Когда я удаляю конечную точку 192.168.46.212 api из kubeadm-config ConfigMap и снова присоединяюсь к этому узлу плоскости управления, он присоединяется к успеху.

@pytimer спасибо!
Это должно быть исследовано. Уже существует логика, которая пытается синхронизировать предполагаемый список конечных точек etcd с реальной конечной точкой списка etcd, но что-то работает неправильно

Да, это действительно похоже на ошибку. У нас есть 3-узловая контрольная группа ASG. Если мы завершим работу экземпляра, будет создан новый в соответствии с правилами ASG. В это время завершенный узел отображается как неисправный в списке участников etcd. Когда появляется новый экземпляр, перед запуском kubeadm join... он удаляет нездоровый член из etcd. К тому времени, когда мы запустим kubeadm join... кластер etcd будет исправен с двумя узлами согласно etcd. Однако kubeadm использует ClusterStatus в качестве источника истины, в котором все еще указан старый экземпляр.

Обходной путь для нас - сразу после выполнения управления членством в etcd - обновить kubeadm-config ConfigMap, указав истинность кластера, а затем запустить kubeadm join... .

В идеале kubeadm join... будет использовать etcd как источник истины и соответственно обновить kubeadm-config ConfigMap.

@fabianofranz Возможно, я нашел причину этой проблемы.

При синхронизации конечных точек etcd с реальным списком конечных точек etcd синхронизация проходит успешно. Но назначьте реальные конечные точки etcd клиенту etcd Endpoints , эта клиентская переменная не является указателем, поэтому, когда другой код использует клиента, эти конечные точки клиента остаются старыми конечными точками, а не настоящими конечными точками после синхронизации.

Я исправил эту проблему в своем репозитории форков, вы можете проверить этот PR https://github.com/pytimer/kubernetes/commit/0cdf6cad87a317be5326f868bafe4faecc80f033. И я тестирую пользовательский случай join the same control-plane node , он успешно присоединяется.

@pytimer Выглядит отлично! Хорошо подмечено!
Не могли бы вы прислать PR? ИМО, это будет иметь право на сбор вишни.

@ neolit123 @timothysc ^^^

@fabianofranz Первый PR неправильный, я забыл подтвердить CLA.

Этот PR https://github.com/kubernetes/kubernetes/pull/71945 вы можете проверить. Если что-то не так, надеюсь, вы укажете.

@fabriziopandini Я присоединяюсь к тому же узлу уровня управления, это не удалось.

Мои шаги присоединения:

IP второго узла плоскости управления - 192.168.46.212 .

• удалите узел 192.168.46.212 узел etcd из кластера etcd.
• kubectl delete node k8s-212
• kubeadm reset -f на этом узле плоскости управления.
• снова запустите kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5 .

журналы присоединения kubeadm:

...
[etcd] Checking Etcd cluster health
I1207 17:57:18.109993    8541 local.go:66] creating etcd client that connects to etcd pods
I1207 17:57:18.110000    8541 etcd.go:134] checking etcd manifest
I1207 17:57:18.119797    8541 etcd.go:181] etcd endpoints read from pods: https://192.168.46.211:2379,https://192.168.46.212:2379
I1207 17:57:18.131111    8541 etcd.go:221] etcd endpoints read from etcd: https://192.168.46.211:2379
etcd cluster is not healthy: context deadline exceeded

Я вижу код kubeadm и думаю, что эта проблема может быть вызвана 192.168.46.212, оставленным в kubeadm-config ConfigMap.

Kubeadm получает конечные точки api из kubeadm-config ConfigMap при присоединении к узлу уровня управления, а конечные точки etcd аналогичны конечным точкам api. Но узел 912.168.46.212 управления был удален и еще не присоединен, поэтому проверьте состояние кластера etcd неправильно.

Когда я удаляю конечную точку 192.168.46.212 api из kubeadm-config ConfigMap и снова присоединяюсь к этому узлу плоскости управления, он присоединяется к успеху.

Получил ту же ошибку в kubeadm версии 1.13.2, я попытался удалить узел вручную и обновить kubeadm-config, он не работает, остальные узлы etcd все еще пытаются подключить удаленный узел

Когда я удаляю конечную точку 192.168.46.212 api из kubeadm-config ConfigMap и снова присоединяюсь к этому узлу уровня управления, он присоединяется к успеху.

@pytimer Не могли бы вы

Я использую 1.13.3; удаление старого сервера вручную с помощью:

1. kubectl -n kube-system get cm kubeadm-config -o yaml > /tmp/conf.yml
2. manually edit /tmp/conf.yml to remove the old server
3. kubectl -n kube-system apply -f /tmp/conf.yml 

Я все еще не могу присоединиться к кластеру из-за ошибки:

[etcd] Checking etcd cluster health
etcd cluster is not healthy: context deadline exceeded

Затем я убил модули api и модули etcd (по 2 каждого).

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

Была такая же проблема в 1.13.3 (настройка кластера высокой доступности: 3 главных узла + 3 рабочих). Успешно заменен главный узел только после следующих шагов:

Удалить узел из кластера

kubectl delete node master03

Скачиваем etcdctl (например на master01)

mkdir /opt/tools && cd /opt/tools
wget https://github.com/etcd-io/etcd/releases/download/v3.3.12/etcd-v3.3.12-linux-arm64.tar.gz
tar xfz etcd-v3.3.12-linux-arm64.tar.gz

Удалить главный узел из etcd

cd /opt/tools/etcd-v3.3.12-linux-arm64
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member list
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member remove 28a9dabfcfbca673

Удалить из kubeadm-config

kubectl -n kube-system get cm kubeadm-config -o yaml > /tmp/conf.yml
manually edit /tmp/conf.yml to remove the old server
kubectl -n kube-system apply -f /tmp/conf.yml

@zhangyelong Теперь kubeadm reset не может удалить член etcd, поэтому вы обнаружили, что кластер etcd все еще подключает удаленный узел etcd. Вы должны вручную удалить член etcd, используя etcdctl.

Я отправляю PR для реализации удаления узла etcd при сбросе, вы можете видеть. https://github.com/kubernetes/kubernetes/pull/74112

@lvangool Вы можете следовать шагам @Halytskyi . PR: https://github.com/kubernetes/kubernetes/pull/71945 исправляет синхронизацию конечных точек etcd при присоединении к узлу плоскости управления, не может удалить член etcd.

Удалите член etcd из кластера etcd при сбросе, вы увидите kubernetes / kubernetes # 74112.

Кажется, это все еще ошибка в 1.13.4.

Нам все еще нужно вручную обновить карту конфигурации kubeadm ala https://github.com/kubernetes/kubeadm/issues/1300#issuecomment -463374200

Разве это не тот случай, когда исправление в
kubernetes / kubernetes # 71945 будет использовать членство в кластере etcd как источник истины для членов кластера? Если нет, то что именно исправил этот PR?

Интересно, что это время от времени работает, потому что диапазон golang на картах, таких как ClusterStatus , не является детерминированным . Поэтому, если первая конечная точка, которую он находит, относится к старой конечной точке, которая больше не существует, что-то не получается. Если он найдет работоспособную конечную точку, он обновит ClusterStatus из etcd Sync ...

Я считаю, что основной причиной этого является ошибка в etcd clientv3, из-за которой клиент не пытается повторить попытку других конечных точек, если первая выходит из строя https://github.com/etcd-io/etcd/issues/9949.

Пожалуйста, используйте следующую проблему для отслеживания улучшений сброса

• https://github.com/kubernetes/kubeadm/issues/1312 Удалите узлы уровня управления из ClusterStatus ( @Klaven https://github.com/kubernetes/kubernetes/pull/72886)
• https://github.com/kubernetes/kubeadm/issues/1211 Удалите участников etcd из кластера etcd ( @pytimer https://github.com/kubernetes/kubernetes/pull/74112)

@fabriziopandini Здесь есть по крайней мере еще одна проблема, не kubeadm reset .

Если узел выходит из строя без возможности выполнить сброс kubeadm (завершение работы экземпляра, отказ оборудования и т. Д.)
Кластер остается в состоянии, в котором ClusterStatus.apiEndpoints по-прежнему перечисляет узел, которого больше нет в кластере. Для этого требуется обходной путь чтения, редактирования и обновления карты конфигурации перед выполнением kubeadm join . У Kubeadm, вероятно, есть 2 варианта:

1) Реализуйте повторную попытку клиента etcd в случае сбоя набора номера.
2) Подождите, пока ошибка go-grpc будет исправлена, а затем исправление перенесется в клиент etcd.

Эта проблема может быть хорошей проблемой для отслеживания любого из этих вариантов.

Если узел выходит из строя без возможности выполнить сброс kubeadm (завершение работы экземпляра, отказ оборудования и т. Д.)
Кластер остается в состоянии, в котором ClusterStatus.apiEndpoints по-прежнему перечисляет узел, которого больше нет в кластере. Для этого требуется обходной путь чтения, редактирования и обновления карты конфигурации перед выполнением kubeadm join .

это правда, без вызова сброса вам придется вручную обновить ClusterStatus.
у нас нет команды, которая это делает. Если вы считаете, что kubeadm должен поддерживать эту функцию, отправьте отдельный запрос.

Только что испытал это сегодня на 1.14.1

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

Мне пришлось вручную удалить член etcd через etcdctl, после чего я мог присоединиться к новому узлу. Я также вручную удалил узел из kubeadm-config ConfigMap, но я не уверен, требовалось ли это.

@Halytskyi Спасибо раздел etcdctl мне помог .....

Испытал это сегодня в 1.15.5

В моем случае я присоединился к кластеру, но с версией 1.16. затем удалил этот узел kubectl delete node , понизил до 15.5.5 и попытался присоединиться (тот же IP, то же имя хоста, другая версия) и получил ошибку etcd unhealthy.

Решено (на основе ответа

• Удалите узел из карты конфигурации kubeadm-config

>: kubectl edit configmap  kubeadm-config -n kube-system
configmap/kubeadm-config edited

• kubeadm reset -f в проблемном узле && iptables -t -f -X и так далее.

• удалить член etcd (это ключ):

root@k8s-nebula-m-115-2:wget https://github.com/etcd-io/etcd/releases/download/v3.4.3/etcd-v3.4.3-linux-amd64.tar.gz
root@k8s-nebula-m-115-2:tar xfz etcd-v3.4.3-linux-amd64.tar.gz

оболочка
корень @ k8s-nebula-m-115-2 : ~ / etcdctl / etcd-v3.4.3-linux-amd64 # ./etcdctl --endpoints https://127.0.0.1 : 2379 --cacert / etc / kubernetes / pki /etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key список участников
289ed62da3c6e9e5, запущено, k8s-nebula-m-115-1, https://10.205.30.2 : 2380, https://10.205.30.2 : 2379, ложь
917e16b9e790c427, запущено, k8s-nebula-m-115-0, https://10.205.30.1 : 2380, https://10.205.30.1 : 2379, ложь
ad6b76d968b18085, запущен, k8s-nebula-m-115-2, https://10.205.30.0 : 2380, https://10.205.30.0 : 2379, ложь

```shell
root@k8s-nebula-m-115-2:~/etcdctl/etcd-v3.4.3-linux-amd64# ./etcdctl --endpoints https://127.0.0.1:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key member remove 289ed62da3c6e9e5
Member 289ed62da3c6e9e5 removed from cluster d4913a539ea2384e

А потом снова работать.

это может произойти, если kubeadm reset прерывается и не может удалить узел из CM kubeadm.
в таком случае вам нужно вручную удалить его из CM kubeadm.

Поэтому, если я удалю узел с помощью kubectl delete node foobar он не будет
удалить его от члена etcd? Но если я сделаю kubeadm reset в узле, который хочу
чтобы удалить, то он это делает? 🙄

Ср, 30.10.2019, 13:27 Любомир Иванович Иванов, [email protected]
написал:

это может произойти, если сброс kubeadm прерван и не удалось удалить
узел из kubeadm CM.
в таком случае вам нужно вручную удалить его из CM kubeadm.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubeadm/issues/1300?email_source=notifications&email_token=AF7BZL3Q4E2FMPZYKYNOV53QRF4SXA5CNFSM4GIIZTPKYY3PNVWWK3TULXG43JVMWWK3TULXG4DVMQWWK3TREXW04DVMWWWK3TULXG4DVMWWK3TREXWWC07B04DVMW08
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AF7BZL4EOZV7GQYNQOM3773QRF4SXANCNFSM4GIIZTPA
.

Команда «kubeadm reset» должна удалить его из CM kubeadm, но также необходим вызов «узла удаления kubectl», который удаляет объект API узла.

В моем случае удаление узла из de configmap не привело к его удалению из
etcd, мне нужно было вручную etcdctl delete member .

Вт, 31.10.2019 в 16:28, Любомир Иванович [email protected]
написал:

"kubeadm reset" должен удалить его из CM kubeadm, но вызов "kubectl"
удалить узел ", который удаляет объект API узла.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubeadm/issues/1300?email_source=notifications&email_token=AF7BZLZVF7FFVA3LWINJZW3QRL2TLA5CNFSM4GIIZTPKYY3PNVWWK3TUL52X63JVMWWK3TUL52X63JNVWWK3TUL52X4DVMWWK3TUL52X4DVMVWWK3TUL52X4DVMWW9CBWWM6DWWW8
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AF7BZL2KB3GVLTFKQTJTYXLQRL2TLANCNFSM4GIIZTPA
.

kubeadm reset также должен удалить член etcd из кластера etcd.
попробуйте выполнить его, например, --v = 5, и посмотрите, что он делает.

однако имейте в виду, что kubeadm reset - это лучшая команда, поэтому в случае сбоя по какой-либо причине она может вывести только предупреждение.

поэтому kubectl delete node не удаляет его из etcd. Вместо этого выполняется запуск в узле kubeadm reset .
Мне кажется, что kubectl delete node должен удалить его из etcd. Или мне не хватает очевидного варианта использования?
может спросить, нельзя ли его оттуда тоже удалить?
В любом случае спасибо за разъяснение @ neolit123 , я сначала удалил его из плоскости управления, а затем сделал сброс, думаю, было слишком поздно удалять себя из etcd.

так что есть разные обязанности.
kubectl delete node, удаляет объект Node API - вы должны сделать это, когда действительно уверены, что вам больше не нужен узел,
перед этим вы должны вызвать kubeadm reset на этом узле. что я делаю, так это очищает состояние на диске, а также удаляет член etcd (если это узел уровня управления и если вы используете параметр по умолчанию, когда экземпляры etcd выполняются для каждого узла плоскости управления)

kubeadm reset сбрасывает узел, но не удаляет объект узла по нескольким причинам:

• reset просто сбрасывает узел, и вы можете снова присоединиться к нему. имя узла остается зарезервированным.
• сам узел не имеет достаточно прав для удаления своего объекта узла. это ответственность владельца "admin.conf" (например, администратора).

kubeadm reset - лучшая команда

Относительно этого: когда kubeadm reset не удается завершить по какой-либо причине (включая жесткий сбой базового сервера, так что сброс kubeadm никогда не выполняется в первую очередь), есть ли какие-либо варианты для ручного согласования состояния помимо ручного редактирования объект configmap kubeadm-config и удаление узла?

если узел неисправен и вы не можете вызвать на нем сброс kubeadm, это требует ручных действий. вам нужно будет:
1) удалите IP-адрес плоскости управления из CM ClusterStatus kubeadm-config
2) удалите член etcd с помощью etcdctl
3) удалите объект Node с помощью kubectl (если вы больше не хотите, чтобы Node был рядом)

1 и 2 применяются только к узлам уровня управления.

Есть ли способ автоматизировать эту отработку отказа, если kubeadm reset не может быть запущен?

Те же проблемы на 1.9. Спасибо за решения.