<p>succès de la réinitialisation de kubeadm mais l'adresse IP de ce nœud est toujours dans la configuration de kubeadm-config</p>

cc @fabriziopandini

Idéalement, il y aurait un moyen de "rafraîchir" le ClusterStatus. Nous exécutons des clusters avec des tests de chaos, il est tout à fait possible qu'un nœud de plan de contrôle se termine sans avertissement et sans possibilité d'exécuter kubeadm reset . Idéalement, il y aurait un moyen propre de mettre à jour le ClusterStatus explicitement pour supprimer les nœuds du plan de contrôle dont nous savons qu'ils ne sont plus dans le cluster. C'est quelque chose qui serait fait avant d'exécuter kubeadm join --control-plane ... ou peut-être est-il intégré?

Quelques commentaires ici:

kubeadm-config ConfigMap supprime cette adresse IP de nœud.

@pytimer Je sais que

J'ai encore une question, pourquoi kubeadm reset ne supprime pas ce nœud directement du cluster? Au lieu de cela, exécutez le nœud de suppression kubectlmanuellement.

@luxas pourrait être un peu de contexte historique peut aider ici.
Je suppose que le nœud n'avait pas le privilège de se supprimer (mais cela s'applique aux nœuds de travail, pas aux nœuds du plan de contrôle ...)

Idéalement, il y aurait un moyen de "rafraîchir" le ClusterStatus / il y aurait un moyen propre de mettre à jour le ClusterStatus explicitement

@danbeaulieu c'est un bon point. avoir une commande explicite pour synchroniser l'état du cluster et / ou appliquer la synchronisation automatique lorsque kubeadm est exécuté est une bonne idée.
Cependant, étant kubeadm sans aucune sorte de boucle de contrôle fonctionnant en continu, je pense qu'il y aura toujours la possibilité de désynchroniser ClusterStatus.
Cela ne devrait pas être un problème, ou plus précisément avoir une adresse IP de nœud pour les nœuds qui n'existent plus (manque de nettoyage) ne devrait pas être un problème.
Au lieu de cela, si un nœud existe et que l'IP du nœud correspondant est absent de ClusterStatus (initialisation incorrecte), cela pourrait créer des problèmes, par exemple pour les mises à jour.

Pourriez-vous nous signaler si l'hypothèse ci-dessus est confirmée par vos tests de chaos? toute rétroaction sera vraiment appréciée.

@fabriziopandini Je rejoins le même nœud de plan de contrôle, il a échoué.

Mes étapes de jointure:

Le deuxième nœud du plan de contrôle ip est 192.168.46.212 .

• supprimez le membre etcd du nœud 192.168.46.212 du cluster etcd.
• kubectl delete node k8s-212
• kubeadm reset -f sur ce nœud du plan de contrôle.
• exécutez à nouveau kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5 .

Journaux de jointure 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

Je vois le code kubeadm, et je pense que ce problème peut être causé par 192.168.46.212 laissé dans le kubeadm-config ConfigMap.

Kubeadm obtient les points de terminaison d'API à partir de kubeadm-config ConfigMap lors de la jointure du nœud du plan de contrôle, et les points de terminaison etcd sont les mêmes que les points de terminaison de l'API. Mais le nœud du plan 912.168.46.212 contrôle

Lorsque je supprime le point de terminaison 192.168.46.212 api de la kubeadm-config ConfigMap et que je rejoins à nouveau ce nœud de plan de contrôle, la jointure réussit.

@pytimer merci!
Cela devrait être étudié. Il existe déjà une logique qui tente de synchroniser la liste supposée des points de terminaison etcd avec le point de terminaison réel de la liste etcd, mais quelque chose ne semble pas fonctionner correctement

Oui, cela semble être un bug. Nous avons un plan de contrôle à 3 nœuds ASG. Si nous terminons une instance, une nouvelle sera créée selon les règles ASG. Pendant ce temps, le nœud terminé est répertorié comme défectueux dans la liste des membres de etcd. Lorsque la nouvelle instance apparaît, avant d'exécuter kubeadm join... , elle supprime le membre défectueux de etcd. Au moment où nous exécutons kubeadm join... le cluster etcd est sain avec 2 nœuds selon etcd. Cependant, kubeadm utilise le ClusterStatus comme source de vérité, qui a toujours l'ancienne instance répertoriée.

La solution de contournement pour nous est juste après avoir fait la gestion des membres etcd est de mettre à jour le ConfigMap kubeadm-config avec la vérité du cluster, puis d'exécuter kubeadm join... .

Idéalement, kubeadm join... utiliserait etcd comme source de vérité et mettrait à jour le ConfigMap kubeadm-config en conséquence.

@fabianofranz J'ai peut-être trouvé la cause de ce problème.

Lorsque la synchronisation des points de terminaison etcd avec la véritable liste de points de terminaison etcd, la synchronisation est réussie. Mais attribuez les vrais points de terminaison etcd au client etcd Endpoints , cette variable client n'est pas un pointeur, donc quand un autre code utilise le client, ce client finit toujours les anciens points de terminaison, pas les points de terminaison réels après la synchronisation.

J'ai corrigé ce problème dans mon dépôt de fourche, vous pouvez vérifier ce PR https://github.com/pytimer/kubernetes/commit/0cdf6cad87a317be5326f868bafe4faecc80f033. Et je teste le cas utilisateur join the same control-plane node , ça rejoint le succès.

@pytimer a l'air génial! Bien repéré!
Pourriez-vous gentiment envoyer un PR? IMO cela sera éligible pour la cueillette de cerises.

@ neolit123 @timothysc ^^^

@fabianofranz Le premier PR est faux, j'oublie de confirmer CLA.

Vous pouvez vérifier ce PR https://github.com/kubernetes/kubernetes/pull/71945 . Si quelque chose ne va pas, espérons que vous le faites remarquer.

@fabriziopandini Je rejoins le même nœud de plan de contrôle, il a échoué.

Mes étapes de jointure:

Le deuxième nœud du plan de contrôle ip est 192.168.46.212 .

• supprimez le membre etcd du nœud 192.168.46.212 du cluster etcd.
• kubectl delete node k8s-212
• kubeadm reset -f sur ce nœud du plan de contrôle.
• exécutez à nouveau kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5 .

Journaux de jointure 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

Je vois le code kubeadm, et je pense que ce problème peut être causé par 192.168.46.212 laissé dans le kubeadm-config ConfigMap.

Kubeadm obtient les points de terminaison d'API à partir de kubeadm-config ConfigMap lors de la jointure du nœud du plan de contrôle, et les points de terminaison etcd sont les mêmes que les points de terminaison de l'API. Mais le nœud du plan 912.168.46.212 contrôle

Lorsque je supprime le point de terminaison 192.168.46.212 api de la kubeadm-config ConfigMap et que je rejoins à nouveau ce nœud de plan de contrôle, la jointure réussit.

J'ai eu la même erreur dans kubeadm version 1.13.2, j'ai essayé de supprimer le nœud manuellement et de mettre à jour kubeadm-config, cela ne fonctionne pas, les autres nœuds etcd essaient toujours de connecter le nœud supprimé

Lorsque je supprime le point de terminaison 192.168.46.212 api de la kubeadm-config ConfigMap et que je rejoins à nouveau ce nœud de plan de contrôle, la jointure réussit.

@pytimer Pouvez-vous expliquer comment vous avez supprimé manuellement l'ancien serveur api?

J'utilise 1.13.3; suppression manuelle de l'ancien serveur via:

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 

Je ne parviens toujours pas à rejoindre le cluster en raison de l'erreur:

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

J'ai ensuite tué les pods api et les pods etcd (2 de chaque).

Ils sont recréés, mais j'ai toujours la même erreur en essayant de connecter le nœud supplémentaire.

Eu le même problème dans la version 1.13.3 (configuration du cluster HA: 3 nœuds maîtres + 3 nœuds de calcul). Le nœud maître a été remplacé avec succès uniquement après les étapes suivantes:

Supprimer le nœud du cluster

kubectl delete node master03

Téléchargez etcdctl (par exemple, sur 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

Supprimer le nœud maître de 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

Supprimer de 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 Maintenant, kubeadm reset ne peut pas supprimer le membre etcd, vous avez donc trouvé que le cluster etcd connecte toujours le nœud etcd supprimé. Vous devez supprimer manuellement le membre etcd en utilisant etcdctl maintenant.

J'envoie un PR pour implémenter la suppression du nœud etcd lors de la réinitialisation, vous pouvez le voir. https://github.com/kubernetes/kubernetes/pull/74112

@lvangool Vous pouvez suivre les étapes @Halytskyi . Le PR: https://github.com/kubernetes/kubernetes/pull/71945 corrige les points de terminaison de synchronisation etcd lorsque vous rejoignez le nœud du plan de contrôle, ne peut pas supprimer le membre etcd.

Supprimez le membre etcd du cluster etcd lors de la réinitialisation, vous pouvez voir kubernetes / kubernetes # 74112.

Cela semble être encore un bogue dans la version 1.13.4.

Nous devons encore mettre à jour manuellement la carte de configuration de kubeadm ala https://github.com/kubernetes/kubeadm/issues/1300#issuecomment -463374200

N'est-il pas vrai que le correctif
kubernetes / kubernetes # 71945 utiliserait l'appartenance au cluster etcd comme source de vérité pour les membres du cluster? Sinon, qu'est-ce que ce PR a résolu exactement?

Il est intéressant de noter que cela fonctionne de manière sporadique car dans la plage de golang sur des cartes, comme ClusterStatus , n'est pas déterministe . Donc, si le premier point de terminaison qu'il trouve provient d'un ancien point de terminaison qui n'existe plus, les choses échouent. S'il trouve un point de terminaison sain, il mettra à jour le ClusterStatus à partir de etcd Sync ...

Je crois que la cause première de ceci est un bogue dans le clientv3 etcd où le bogue empêche le client de réessayer les autres points de terminaison si le premier échoue https://github.com/etcd-io/etcd/issues/9949.

Veuillez utiliser le problème suivant pour suivre les améliorations de la réinitialisation

• https://github.com/kubernetes/kubeadm/issues/1312 Supprimez les nœuds du plan de contrôle de ClusterStatus ( @Klaven https://github.com/kubernetes/kubernetes/pull/72886)
• https://github.com/kubernetes/kubeadm/issues/1211 Supprimez les membres etcd du cluster etcd (

@fabriziopandini Il y a au moins un autre problème ici qui n'est pas lié à kubeadm reset .

Si un nœud échoue sans avoir la possibilité d'effectuer la réinitialisation de kubeadm (arrêt de l'instance, panne matérielle, etc.)
Le cluster est laissé dans un état où ClusterStatus.apiEndpoints répertorie toujours un nœud qui n'est plus dans le cluster. Cela nécessite la solution de contournement consistant à lire, modifier et mettre à jour la carte de configuration avant d'effectuer kubeadm join . Kubeadm a probablement 2 options:

1) Implémentez le client etcd, réessayez lui-même si la numérotation échoue
2) Attendez que le bogue go-grpc soit corrigé, puis que le correctif parvienne au client etcd

Ce problème peut être un bon problème à utiliser pour suivre l'une ou l'autre de ces options.

Si un nœud échoue sans avoir la possibilité d'effectuer la réinitialisation de kubeadm (arrêt de l'instance, panne matérielle, etc.)
Le cluster est laissé dans un état où ClusterStatus.apiEndpoints répertorie toujours un nœud qui n'est plus dans le cluster. Cela nécessite la solution de contournement de lecture, d'édition et de mise à jour de la carte de configuration avant d'effectuer kubeadm join .

c'est vrai, sans appeler reset, vous devrez mettre à jour manuellement le ClusterStatus.
nous n'avons pas de commande qui fait cela. si vous pensez que c'est une fonctionnalité que kubeadm devrait supporter, veuillez déposer un ticket séparé.

Je viens de faire l'expérience de cela aujourd'hui sur 1.14.1

L'instance exécutant l'un de mes nœuds maîtres a échoué, ce qui l'a empêchée d'être supprimée correctement. Lorsqu'un nouveau nœud a tenté d'entrer, il n'a pas réussi à se joindre en raison de l'erreur décrite dans ce ticket.

J'ai dû supprimer manuellement le membre etcd via etcdctl, puis je pourrais rejoindre un nouveau nœud. J'ai également supprimé manuellement le nœud de la ConfigMap kubeadm-config, mais je ne suis pas sûr si cela était nécessaire.

@Halytskyi Merci La section etcdctl a aidé pour moi .....

Expérimenté cela aujourd'hui en 1.15.5

Dans mon cas, j'ai rejoint le cluster mais avec la version 1.16. puis supprimé ce nœud kubectl delete node , rétrograder à 15.5.5 et essayer de rejoindre (même ip, même nom d'hôte, version différente) et obtenir l'erreur etcd malsaine.

Résolu par (basé sur la réponse @Halytskyi mais avec etcdctl mis à jour):

• Supprimez le nœud du configmap kubeadm-config

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

• kubeadm reset -f dans le nœud problématique && iptables -t -f -X et ainsi de suite.

• supprimer le membre etcd (c'est la clé):

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

`` `` coquille
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 liste des membres
289ed62da3c6e9e5, commencé, k8s-nebula-m-115-1, https://10.205.30.2 : 2380, https://10.205.30.2 : 2379, faux
917e16b9e790c427, commencé, k8s-nebula-m-115-0, https://10.205.30.1 : 2380, https://10.205.30.1 : 2379, faux
ad6b76d968b18085, commencé, k8s-nebula-m-115-2, https://10.205.30.0 : 2380, https://10.205.30.0 : 2379, faux

```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

Et puis rejoignez les œuvres.

cela peut arriver si kubeadm reset est interrompu et ne peut pas supprimer le nœud du CM kubeadm.
dans ce cas, vous devez le supprimer manuellement de kubeadm CM.

Donc, si je supprime le nœud avec kubectl delete node foobar il ne le fait pas
le supprimer du membre etcd? Mais si je fais kubeadm reset dans le nœud que je veux
supprimer, alors il le fait? 🙄

Le mercredi 30 octobre 2019, 13:27 Lubomir I. Ivanov, [email protected]
a écrit:

cela peut se produire si la réinitialisation de kubeadm est interrompue et ne peut pas supprimer le
noeud du CM kubeadm.
dans ce cas, vous devez le supprimer manuellement de kubeadm CM.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/kubernetes/kubeadm/issues/1300?email_source=notifications&email_token=AF7BZL3Q4E2FMPZYKYNOV53QRF4SXA5CNFSM4GIIZTPKYY3PNVWWWK3TUL52HS4DFVOM87NVWWK3TUL52HS4DFVOM47HWWWK3TUL52HS4DFVOM87NVWWK3TUL52HS4DFVOM87NVWWK3TUL52HS4DFVom
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AF7BZL4EOZV7GQYNQOM3773QRF4SXANCNFSM4GIIZTPA
.

"kubeadm reset" devrait le supprimer du CM de kubeadm, mais appeler "kubectl delete node" est également nécessaire, ce qui supprime l'objet API Node.

Dans mon cas, la suppression du nœud de configmap ne l'a pas supprimé du
etcd cluster j'avais besoin de manuellement etcdctl delete member .

Le jeu, 31 octobre 2019 à 16:28, Lubomir I. Ivanov [email protected]
a écrit:

"kubeadm reset" devrait le supprimer de kubeadm CM, mais en appelant "kubectl
delete node "est également nécessaire pour supprimer l'objet API Node.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/kubernetes/kubeadm/issues/1300?email_source=notifications&email_token=AF7BZLZVF7FFVA3LWINJZW3QRL2TLA5CNFSM4GIIZTPKYY3PNVWWK3Tul52HS4DFVom4H9WWWWK3TUL52HS4DFVomH5WWWWK3TUL52HS4DFVom
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AF7BZL2KB3GVLTFKQTJTYXLQRL2TLANCNFSM4GIIZTPA
.

kubeadm reset devrait également supprimer le membre etcd du cluster etcd.
essayez de l'exécuter avec par exemple --v = 5 et voyez ce qu'il fait.

Cependant, gardez à l'esprit que kubeadm reset est une commande au mieux, donc si elle échoue pour une raison quelconque, elle ne peut afficher qu'un avertissement.

donc kubectl delete node ne le supprime pas de etcd. Au lieu de cela, exécuter dans le nœud kubeadm reset fait.
me semble cassé, je pense que kubectl delete node devrait également le supprimer du formulaire etcd. Ou est-ce que je manque un cas d'utilisation évident?
peut-être demander s'il devrait également être supprimé de là?
Quoi qu'il en soit, merci pour la clarification @ neolit123 , je le supprime d'abord du plan de contrôle, puis j'ai fait une réinitialisation, je suppose qu'il était trop tard pour se supprimer de l'etcd.

il y a donc différentes responsabilités.
kubectl delete node, supprime l'objet API Node - vous devriez le faire lorsque vous êtes vraiment sûr que vous ne voulez plus le nœud autour,
avant cela, vous devez appeler kubeadm reset sur ce nœud. ce que je fais, c'est qu'il nettoie l'état sur le disque et supprime également le membre etcd (s'il s'agit d'un nœud de plan de contrôle et si vous utilisez l'option par défaut où les instances etcd sont exécutées par nœud de plan de contrôle)

kubeadm reset réinitialise le nœud, mais il ne supprime pas l'objet Node pour plusieurs raisons:

• reset réinitialise simplement le nœud et vous pouvez le rejoindre. le nom du nœud reste réservé.
• le nœud lui-même n'a pas assez de privilèges pour supprimer son objet Node. ceci est de la responsabilité du propriétaire du "admin.conf" (par exemple, administrateur).

kubeadm reset est une commande au mieux

À ce sujet: lorsque le kubeadm reset échoue pour une raison quelconque (y compris une panne matérielle du serveur sous-jacent afin que la réinitialisation de kubeadm ne soit jamais exécutée en premier lieu) existe-t-il des options pour réconcilier manuellement l'état à côté de l'édition manuelle l'objet kubeadm-config configmap et la suppression du nœud?

si le nœud est en panne et que vous ne pouvez pas appeler kubeadm reset dessus, cela nécessite des étapes manuelles. il faudrait:
1) Supprimez l'adresse IP du plan de contrôle du Kubeadm-config CM ClusterStatus
2) Supprimez le membre etcd en utilisant etcdctl
3) supprimez l'objet Node en utilisant kubectl (si vous ne voulez plus le Node autour)

1 et 2 s'appliquent uniquement aux nœuds du plan de contrôle.

Existe-t-il un moyen d'automatiser ce basculement si la réinitialisation de kubeadm ne peut pas être exécutée?

Mêmes problèmes sur 1.9. Merci pour les solutions.