Kubeadm: L'exécution des vérifications avant vol se bloque

Avec le paramètre v10.

[ root@vm03 etcd]# kubeadm join vm10.andrefagundes. org: 6443 --token 07nh7g.v8p5fcs61fn3o2h4 --discovery-token-ca-cert-hachage SHA256: 039a5f9229dafe39d4a51af6899c20adff1de5dda23f780ac9b896e95f95623a --experimental-control-plan --certificate-clé -v10 de cf3c8ca4f74751bfe7fc9d3e00e03a37619d36a6d6fb79fb5ba3645d74dd7bf4
I0401 00: 34: 08.531961 16893 join.go: 367] [preflight] trouvé NodeName vide ; en utilisant le nom d'hôte du système d'exploitation comme NodeName
I0401 00: 34: 08.532014 16893 join.go: 371] [preflight] trouvé advertisingAddress vide ; en utilisant l'adresse IP de l'interface par défaut comme advertisingAddress
I0401 00:34:08.532048 16893 initconfiguration.go:105] détecté et utilisant le socket CRI : /var/run/dockershim.sock
I0401 00: 34: 08.532179 16893 interface.go: 384] Recherche de routes par défaut avec des adresses IPv4
I0401 00: 34: 08.532187 16893 interface.go: 389] Interface de transit de route par défaut "eth0"
I0401 00:34:08.532324 16893 interface.go:196] L'interface eth0 est active
I0401 00: 34: 08.532380 16893 interface.go: 244] L'interface "eth0" a 4 adresses : [192.168.122.103/24 fe80 :: a3c0: 2a34: 91f2: e0eb/64 fe80 :: 8439: c3eb: 5848: c1f2/ 64 fe80::4381:b4a5:5836:a0e1/64].
I0401 00:34:08.532399 16893 interface.go:211] Vérification de l'adresse 192.168.122.103/24.
I0401 00:34:08.532407 16893 interface.go:218] IP trouvée 192.168.122.103
I0401 00:34:08.532415 16893 interface.go:250] Adresse IPv4 valide 192.168.122.103 trouvée pour l'interface « eth0 ».
I0401 00: 34: 08.532421 16893 interface.go: 395] IP active trouvée 192.168.122.103
[preflight] Exécution des vérifications avant le vol
I0401 00:34:08.532495 16893 preflight.go:90] [preflight] Exécution des vérifications générales
I0401 00:34:08.532539 16893 checks.go:254] validant l'existence et la vacuité du répertoire /etc/kubernetes/manifests
I0401 00:34:08.532570 16893 checks.go:292] validant l'existence du fichier /etc/kubernetes/kubelet.conf
I0401 00:34:08.532579 16893 checks.go:292] validant l'existence du fichier /etc/kubernetes/bootstrap-kubelet.conf
I0401 00: 34: 08.532586 16893 checks.go: 105] validation de l'exécution du conteneur
I0401 00:34:08.580885 16893 checks.go:131] validant si le service est activé et actif
I0401 00:34:08.638659 16893 checks.go:341] validant le contenu du fichier /proc/sys/net/bridge/bridge-nf-call-iptables
I0401 00:34:08.638724 16893 checks.go:341] validant le contenu du fichier /proc/sys/net/ipv4/ip_forward
I0401 00: 34: 08.638755 16893 checks.go: 653] validant si l'échange est activé ou non
I0401 00: 34: 08.638788 16893 checks.go: 382] validant la présence d'une adresse IP exécutable
I0401 00:34:08.638809 16893 checks.go:382] validant la présence d'iptables exécutables
I0401 00:34:08.638824 16893 checks.go:382] validant la présence du montage exécutable
I0401 00: 34: 08.638837 16893 checks.go: 382] validant la présence de nsenter exécutable
I0401 00:34:08.638849 16893 checks.go:382] validant la présence d'ebtables exécutables
I0401 00: 34: 08.638860 16893 checks.go: 382] validant la présence de l'exécutable ethtool
I0401 00: 34: 08.638871 16893 checks.go: 382] validant la présence de socat exécutable
I0401 00:34:08.638883 16893 checks.go:382] validant la présence de l'exécutable tc
I0401 00: 34: 08.638894 16893 checks.go: 382] validant la présence du toucher exécutable
I0401 00: 34: 08.638914 16893 checks.go: 524] exécutant toutes les vérifications
I0401 00: 34: 08.664826 16893 checks.go: 412] vérifiant si le nom de nœud donné est accessible à l'aide de net.LookupHost
I0401 00:34:08.665583 16893 checks.go:622] validation de la version kubelet
I0401 00:34:08.709573 16893 checks.go:131] validant si le service est activé et actif
I0401 00:34:08.716270 16893 checks.go:209] validant la disponibilité du port 10250
I0401 00: 34: 08.716418 16893 checks.go: 439] validant si le type de connectivité est via proxy ou direct
I0401 00: 34: 08.716444 16893 join.go: 427] [preflight] Découverte des informations sur le cluster
I0401 00:34:08.716498 16893 token.go:200] [découverte] Tentative de connexion au serveur API "vm10.andrefagundes. org:6443 "
I0401 00: 34: 08.716961 16893 token.go: 75] [découverte] Création d'un client de découverte d'informations sur le cluster, demandant des informations à " https://vm10.andrefagundes.org : 6443 "
I0401 00:34:08.717031 16893 round_trippers.go:419] curl -k -v -XGET -H "Accepter : application/json, / " -H "User-Agent : kubeadm/v1.14.0 (linux/amd64) kubernetes/ 641856d" ' https://vm10.andrefagundes.org :6443/api/v1/namespaces/kube-public/configmaps/cluster-info'
I0401 00:34:08.722405 16893 round_trippers.go:438] GET https://vm10.andrefagundes.org :6443/api/v1/namespaces/kube-public/configmaps/cluster-info 403 Interdit en 5 millisecondes
I0401 00:34:08.722423 16893 round_trippers.go:444] En-têtes de réponse :
I0401 00: 34: 08.722432 16893 round_trippers.go: 447] Type de contenu : application/json
I0401 00: 34: 08.722441 16893 round_trippers.go: 447] Options de type de contenu X : nosniff
I0401 00: 34: 08.722450 16893 round_trippers.go: 447] Longueur du contenu : 321
I0401 00:34:08.722458 16893 round_trippers.go:447] Date : lundi 01 avril 2019 03:34:08 GMT
I0401 00:34:08.722497 16893 request.go:942] Corps de la réponse : {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Échec","message ":"configmaps \"cluster-info\" est interdit : l'utilisateur \" system:anonymous\ " ne peut pas obtenir la ressource \"configmaps\" dans le groupe d'API \"\" dans l'espace de noms \"kube-public\""," reason":"Interdit","details":{"name":"cluster-info","kind":"configmaps"},"code":403}
I0401 00: 34: 08.722937 16893 token.go: 83] [découverte] Échec de la demande d'informations sur le cluster, va réessayer : [configmaps "cluster-info" est interdit : l'utilisateur " system:anonymous " ne peut pas obtenir la ressource "configmaps" dans l'API groupe "" dans l'espace de noms "kube-public"]

Autre info... vm10.andrefagundes.org est un Haproxy devant mon control plane.

me semble être un problème de réseau.
êtes-vous sûr que ce nœud de jonction a une connectivité au port 6443 sur le LB et peut résoudre vm10.andrefagundes.org ?

Oui, j'ai aussi changé vm10 pour pointer vers le plan de contrôle. J'ai vu le trafic sur le plan de contrôle venir en surveillance avec TCDUMP.

voyez-vous des erreurs en suspens dans les journaux kubelet ?

Il y a plusieurs erreurs dans les journaux. J'ai également essayé de réinstaller le cluster plusieurs fois et à chaque fois j'obtiens des erreurs différentes. J'abandonne. On peut clore l'affaire. Merci!!

la création d'un seul nœud de plan de contrôle + certains nœuds de travail fonctionne-t-elle pour vous ou le problème ne se produit-il que lors de la jonction de nœuds de plan de contrôle supplémentaires ?

L'utilisateur " system:anonymous " ne peut pas obtenir la ressource "configmaps" dans le groupe d'API "" dans l'espace de noms "kube-public"","reason":"Forbidden","details":{"name":"cluster-info", "kind":"configmaps"},"code":403

On dirait que kubeadm init n'a pas créé/configuré correctement les informations de cluster
Pourriez-vous partager les journaux d'initialisation de kubeadm ?

J'ai la même erreur après avoir exécuté la commande 'kubeadm join ...' : L'exécution des vérifications avant le vol est bloquée. Je n'ai aucune idée pour le gérer.

J'ai eu le même problème. J'avais besoin de redémarrer le maître et après cela, exécuter à nouveau la commande 'kubeadm join ...' sur les nœuds a fonctionné pour moi.

j'ai eu les mêmes problèmes avec kubeadm v1.15 , le maître de redémarrage ne fonctionne pas pour moi

j'ai eu les mêmes problèmes avec kubeadm v1.15 , le maître de redémarrage ne fonctionne pas pour moi

revenir à kubelet & kubeadm v1.13.1 a corrigé ce problème

assurez-vous d'appeler kubeadm init/join avec par exemple --v=2 pour avoir plus de détails sur ce qui se passe.

Je suis tombé sur le même problème, mais le problème a été attribué à la connectivité réseau de mon côté avec mes démons keepalived et haproxy qui ont été configurés à tort, empêchant le nœud principal de blocage de rejoindre le cluster via le service API VIP

Il convient de souligner que l'exécution de kubeadm init/join avec --v=2 était la façon dont j'ai pu le résoudre

assurez-vous d'appeler kubeadm init/join avec par exemple --v=2 pour avoir plus de détails sur ce qui se passe.

kubeadm v1.15

jointure kubeadm .. --v=2

I0802 11:47:31.027812 359 token.go:202] [découverte] Échec de la connexion au serveur API "": l'ID de jeton "r5uyqk" n'est pas valide pour ce cluster ou il a expiré. Utilisez "kubeadm token create" sur le nœud du plan de contrôle pour créer un nouveau jeton valide

kubeadm init phase upload-certs --upload-certs
création de jeton kubeadm

puis kubeadm rejoint le succès

Dans mon cas, j'ai réussi à rejoindre le nœud en arrêtant le pare-feu sur le nœud maître.

systemctl stop firewall

Dans mon cas, j'ai réussi à rejoindre le nœud en arrêtant le pare-feu sur le nœud maître.

systemctl stop firewall

Celui-ci a fonctionné comme un charme.
[ root@localhost ~]# kubeadm join 192.168.8.128:6443 --token 38lhr8.kxi5uy8aoy71dj17 --discovery-token-ca-cert-hash sha256:a12c805b8d98f42a256486d27e87463e22aaba190ab8f5bdce89cabb84
[preflight] Exécution des vérifications avant le vol
[WARNING IsDockerSystemdCheck] : "cgroupfs" détecté comme pilote Docker cgroup. Le pilote recommandé est "systemd". Veuillez suivre le guide sur https://kubernetes.io/docs/setup/cri/
[ATTENTION SystemVerification] : cette version de Docker n'est pas dans la liste des versions validées : 19.03.1. Dernière version validée : 18.09
[preflight] Lecture de la configuration à partir du cluster...
[preflight] FYI : Vous pouvez consulter ce fichier de configuration avec 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[kubelet-start] Téléchargement de la configuration du kubelet à partir du ConfigMap "kubelet-config-1.14" dans l'espace de noms kube-system
[kubelet-start] Écriture de la configuration de kubelet dans le fichier "/var/lib/kubelet/config.yaml"
[kubelet-start] Écriture du fichier d'environnement kubelet avec des drapeaux dans le fichier "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Activation du service kubelet
[kubelet-start] En attente que le kubelet exécute le TLS Bootstrap...

Ce nœud a rejoint le cluster :

• La demande de signature de certificat a été envoyée à apiserver et une réponse a été reçue.
• Le Kubelet a été informé des nouveaux détails de la connexion sécurisée.

Exécutez « kubectl get nodes » sur le plan de contrôle pour voir ce nœud rejoindre le cluster.

en regardant à nouveau le journal dans l'OP, ce n'est pas un "blocage" dans le contrôle en amont, mais plutôt la carte de configuration cluster-info n'est pas accessible, la seule façon dont cela pourrait se produire si la phase "boostrap-token" de "init" est ignoré.

en regardant les rapports ultérieurs, je vois des problèmes de réseau et de jeton expiré qui relèvent des éléments de "support" et non des bogues.

/soutien au triage
pour toute question, essayez stackoverflow, reddit ou #kubeadm sur k8s slack.

si vous trouvez un vrai bogue, veuillez ouvrir un nouveau problème.

Dans mon cas, j'ai réussi à rejoindre le nœud en arrêtant le pare-feu sur le nœud maître.

systemctl stop firewall

systemctl arrêter le pare-feu

Je trouve que le trafic n'était pas autorisé à se connecter au nœud maître.

l'ajout de règles dans sg a résolu mon problème

J'ai la même erreur après avoir exécuté la commande 'kubeadm join ...' : L'exécution des vérifications avant le vol est bloquée. Je n'ai aucune idée pour le gérer.

Avez-vous trouvé une solution?

Je trouve que le trafic n'était pas autorisé à se connecter au nœud maître.

l'ajout de règles dans sg a résolu mon problème

quel port entrant avez-vous autorisé ?