8
votes

Rejoindre un cluster prend une éternité

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


0 commentaires

5 Réponses :


0
votes

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.


2 commentaires

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 )?



1
votes

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)


1 commentaires

quand: avec run_once mieux que la dernière



0
votes

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


0 commentaires

3
votes

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


0 commentaires

0
votes

Comment /var/lib/kubelet/config.yaml est créé?

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.

Échec du flux de jointure kubeadm

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.


0 commentaires