J'ai configuré mon nœud maître et j'essaie de rejoindre un nœud de travail comme suit:
Mar 29 15:03:15 ubuntu-xenial kubelet[9626]: F0329 15:03:15.353432 9626 server.go:193] failed to load Kubelet config file /var/lib/kubelet/config.yaml, error failed to read kubelet config file "/var/lib/kubelet/config.yaml", error: open /var/lib/kubelet/config.yaml: no such file or directory Mar 29 15:03:15 ubuntu-xenial systemd[1]: kubelet.service: Main process exited, code=exited, status=255/n/a Mar 29 15:03:15 ubuntu-xenial systemd[1]: kubelet.service: Unit entered failed state.
Cependant, la commande se bloque pour toujours dans l'état suivant:
[preflight] Running pre-flight checks [WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". Please follow the guide at https://kubernetes.io/docs/setup/cri/
Puisqu'il ne s'agit que d'un avertissement, pourquoi échoue-t-il réellement?
edit : j'ai remarqué ce qui suit dans mon / var / log / syslog
kubeadm join 192.168.30.1:6443 --token 3czfua.os565d6l3ggpagw7 --discovery-token-ca-cert-hash sha256:3a94ce61080c71d319dbfe3ce69b555027bfe20f4dbe21a9779fd902421b1a63
5 Réponses :
J'ai eu la même erreur sur CentOS 7 mais dans mon cas, la commande join a fonctionné sans problème, donc ce n'était en fait qu'un avertissement.
> [WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker > cgroup driver. The recommended driver is "systemd". Please follow the > guide at https://kubernetes.io/docs/setup/cri/ [preflight] Reading > configuration from the cluster... [preflight] FYI: You can look at > this config file with 'kubectl -n kube-system get cm kubeadm-config > -oyaml' [kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.14" ConfigMap in the kube-system namespace
Comme le mentionne la documentation officielle, il existe deux problèmes courants qui font que l'initialisation se bloque (je suppose que cela s'applique également à la commande join):
la configuration par défaut du pilote de groupe de contrôle pour le kubelet diffère de celui utilisé par Docker. Vérifiez le fichier journal du système (par exemple / var / log / message) ou examinez la sortie de journalctl -u kubelet. Si tu vois quelque chose comme le suivant:
Commencez par essayer les étapes de documentation officielle et si cela ne fonctionne pas, veuillez fournir plus d'informations afin que nous puissions résoudre le problème si nécessaire.
Il semble que ce problème soit lié à la configuration CRI sur le maître; Je n'ai aucun problème à créer le cluster; la commande join
est celle qui échoue; cependant, j'ai installé docker
en utilisant exactement la même manière dans master et nodes.
J'ai publié les résultats de la commande join, donc cela fonctionne dans mon cas même avec cet avertissement. Est-ce un cluster clair, je veux dire, pouvez-vous simplement le réinitialiser? Si oui, essayez de faire kubeadm reset
et de réinstaller docker à partir du site de documentation officiel (avez-vous également essayé ceci )?
Le problème était lié au fait que kubeadm
n'installe pas une solution réseau compatible CNI prête à l'emploi;
Par conséquent, sans cette étape, les nœuds / master kubernetes
ne peuvent établir aucune forme de communication;
La tâche suivante a résolu le problème:
- name: kubernetes.yml --> Install Flannel shell: kubectl -n kube-system apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml become: yes environment: KUBECONFIG: "/etc/kubernetes/admin.conf" when: inventory_hostname in (groups['masters'] | last)
quand: avec run_once mieux que la dernière
J'ai eu un tas de scripts de déploiement de k8 qui ont récemment cassé avec ce même message d'erreur ... il semble que docker ait changé son installation. Essayez ceci -
installation précédente: apt-get n'est pas tout docker-ce
installation mise à jour: apt-get install docker-ce docker-ce-cli containerd.io
Premièrement, si vous voulez voir plus de détails lorsque votre worker rejoint le master, utilisez:
systemctl stop firewalld
En utilisant la commande ci-dessus, j'ai pu voir que mon worker n'a pas pu établir de connexion avec le master, donc je viens d'arrêter le pare-feu:
kubeadm join 192.168.1.100:6443 --token m3jfbb.wq5m3pt0qo5g3bt9 --discovery-token-ca-cert-hash sha256:d075e5cc111ffd1b97510df9c517c122f1c7edf86b62909446042cc348ef1e0b --v=2
Concernant l'erreur /var/lib/kubelet/config.yaml: aucun fichier ou répertoire
.
Voici les étapes à suivre sur le nœud worker pour que le fichier mentionné soit créé.
1) La création du / var / lib / kubelet /
dossier.
Il est créé lorsque le service kubelet est installé comme indiqué ici :
. . [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml" [kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env" [kubelet-start] Starting the kubelet . .
2) La création de config.yaml
.
Le flux de jointure kubeadm doit avoir lieu, donc lorsque vous exécutez kubeadm join
, kubeadm utilise les informations d'identification du jeton d'amorçage pour effectuer un bootstrap TLS, qui récupère les informations d'identification nécessaires pour télécharger le kubelet-config -1.X
ConfigMap et l'écrit dans /var/lib/kubelet/config.yaml
.
Après une exécution réussie, vous devriez voir les journaux ci-dessous:
sudo apt-get update && sudo apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list deb https://apt.kubernetes.io/ kubernetes-xenial main EOF sudo apt-get update sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl
Donc, après ces 2 étapes, vous devriez avoir /var/lib/kubelet/config.yaml
en place.
Dans votre cas, il semble que le kubeadm join flow a échoué, ce qui peut se produire en raison de plusieurs raisons telles que la mauvaise configuration d'iptables, les ports déjà utilisés, le runtime du conteneur mal installé, etc. '- comme décrit ici et ici a>.
Pour autant que je sache, le fait qu'aucune solution réseau compatible CNI n'ait été en place ne devrait pas affecter la création de /var/lib/kubelet/config.yaml
:
A) Nous pouvons voir le sous le kubeadm vérifie en amont quels problèmes entraîneront l'échec de la phase de jointure.
B) J'ai également testé ce problème en supprimant la solution actuelle que j'ai utilisée (Calico) et j'ai exécuté kubeadm reset et kubeadm join
à nouveau et aucune erreur n'est apparue dans les journaux kubeadm
(j'ai les journaux d'exécution réussis que j'ai mentionnés ci-dessus) et /var/lib/kubelet/config.yaml
a été créé correctement.
(*) Bien sûr que le cluster ne peut pas fonctionner dans cet état - je voulais juste pour souligner que je pense que le problème était l'une des options mentionnées en A.