Dépannage de kubeadm | Kubernetes

Les informations contenues dans ce document peuvent être obsolètes
Ce document a une date de mise à jour antérieure à celle de l'original, les informations qu'il contient peuvent donc être obsolètes. Si vous comprenez l'anglais, consultez la version anglaise pour obtenir les informations les plus récentes : Troubleshooting kubeadm
Comme avec n'importe quel programme, vous pourriez rencontrer une erreur lors de l'installation ou de l'exécution de kubeadm. Cette page répertorie certains scénarios d’échec courants et propose des étapes pouvant vous aider à comprendre et résoudre le problème.
Si votre problème ne figure pas dans la liste ci-dessous, procédez comme suit:
Si vous pensez que votre problème est un bug avec kubeadm:
Si vous ne savez pas comment fonctionne kubeadm, vous pouvez demander sur Slack dans le canal #kubeadm, ou posez une questions sur StackOverflow. Merci d'ajouter les tags pertinents comme #kubernetes et #kubeadm, ainsi on pourra vous aider.
Dans la version v1.18, kubeadm a ajouté une protection empêchant l’ajout d’un nœud au cluster si un nœud portant le même nom existe déjà. Cela a nécessité l’ajout de règles RBAC permettant à l’utilisateur bootstrap-token de faire une requête GET sur un objet Node.
Cependant, cela provoque un problème : une commande kubeadm join depuis la version v1.18 ne peut pas rejoindre un cluster créé avec kubeadm v1.17.
Pour contourner ce problème, vous avez deux options :
Exécutez kubeadm init phase bootstrap-token sur un nœud du plan de contrôle avec kubeadm v1.18. Notez que cela active également les autres permissions liées au bootstrap-token.
Appliquez manuellement le contrôle d'accès basé sur les rôles (RBAC) suivant à l'aide de la commande kubectl apply -f ... :
Si vous voyez les warnings suivants lors de l'exécution kubeadm init
Ensuite, il peut vous manquer ebtables, ethtool ou un exécutable similaire sur votre nœud. Vous pouvez l'installer avec les commandes suivantes:
Si vous remarquez que kubeadm init se bloque après la ligne suivante:
Cela peut être causé par un certain nombre de problèmes. Les plus courants sont :
Cela peut se produire si le runtime de conteneurs s’arrête et ne supprime aucun conteneur géré par Kubernetes :
Une solution possible consiste à redémarrer le runtime de conteneurs, puis à relancer kubeadm reset. Vous pouvez également utiliser crictl pour déboguer l’état du runtime de conteneurs. Voir Déboguer les nœuds Kubernetes avec crictl.
Juste après kubeadm init, il ne devrait pas y avoir de pods dans ces états.
Ceci est prévu et fait partie du design. kubeadm est indépendant du fournisseur de réseau, ainsi l'administrateur devrait installer la solution réseau pod de son choix. Vous devez installer un réseau de pods avant que CoreDNS ne soit complètement déployé. D'où l' état Pending avant la mise en place du réseau.
Les fonctionnalités HostPort et HostIP sont disponibles en fonction de votre fournisseur de réseau de pod. Veuillez contacter l’auteur de l’add-on réseau pour savoir si ces fonctionnalités sont prises en charge.
Les fournisseurs de CNI Calico, Canal, et Flannel sont validés pour supporter HostPort.
Pour plus d'informations, voir la documentation CNI portmap.
Si votre fournisseur de réseau ne prend pas en charge le plug-in portmap CNI, vous devrez peut-être utiliser la fonction NodePort des services ou utiliser HostNetwork=true.
De nombreux add-ons réseau ne permettent pas encore mode hairpin, qui permet aux pods d’accéder à eux-mêmes via leur IP de service. Ceci est un problème lié au CNI. S'il vous plaît contacter le fournisseur d'add-on réseau afin d'obtenir des informations en matière de prise en charge du mode hairpin.
Si vous utilisez VirtualBox (directement ou via Vagrant), vous devrez vous assurez que hostname -i renvoie une adresse IP routable. Par défaut la première interface est connectée à un réseau d’ hôte uniquement non routable. En contournement vous pouvez modifier /etc/hosts, jetez un œil à ce Vagrantfile par exemple.
L'erreur suivante indique une possible incompatibilité de certificat.
Vérifiez que le fichier $HOME/.kube/config contient un certificat valide, et re-générer un certificat si nécessaire. Les certificats dans un fichier kubeconfig sont encodés en base64. La commande base64 --decode permet de décoder le certificat et la commande openssl x509 -text -noout permet d'afficher les informations du certificat.
Désactivez la variable d’environnement KUBECONFIG en utilisant :
Ou définissez-la vers l’emplacement par défaut de KUBECONFIG :
Une autre solution consiste à écraser le kubeconfig existant pour l'utilisateur " admin ":
Par défaut, kubeadm configure le kubelet avec une rotation automatique des certificats clients en utilisant le lien symbolique /var/lib/kubelet/pki/kubelet-client-current.pem défini dans /etc/kubernetes/kubelet.conf.
Si ce processus de rotation échoue, vous pouvez voir des erreurs telles que x509: certificate has expired or is not yet valid dans les logs du kube-apiserver. Pour corriger ce problème, vous devez suivre les étapes suivantes :
Si votre cluster ne dispose pas de ca.key, vous devez signer les certificats intégrés dans kubelet.conf de manière externe.
Copiez ce fichier kubelet.conf généré vers /etc/kubernetes/kubelet.conf sur le nœud défaillant.
Redémarrez le kubelet (systemctl restart kubelet) sur le nœud défaillant et attendez que /var/lib/kubelet/pki/kubelet-client-current.pem soit recréé.
Modifiez manuellement kubelet.conf pour pointer vers les certificats client kubelet renouvelés, en remplaçant client-certificate-data et client-key-data par :
Redémarrez le kubelet.
Assurez-vous que le nœud passe à l’état Ready.
L'erreur suivante peut indiquer que quelque chose n'allait pas dans le réseau de pod:
Vagrant attribue généralement deux interfaces à tous les ordinateurs virtuels. La première, pour laquel tous les hôtes se voient attribuer l’adresse IP 10.0.2.15, est utilisée pour le trafic externe via NAT.