Kubernetes kubeadm init échoue à cause de dial tcp 127.0.0.1:10248 : connect : connexion refusée

Question

J'essaie de mettre en place un cluster très simple de 2 nœuds k8s 1.13.3 dans un nuage privé vSphere. Les machines virtuelles fonctionnent sous Ubuntu 18.04. Les pare-feu sont désactivés à des fins de test. Pourtant, l'initialisation échoue en raison d'une connexion refusée. Y a-t-il une autre cause que le blocage des ports ? Je suis nouveau sur K8s et j'essaie de me faire une idée de tout cela.

J'ai placé un vsphere.conf dans /etc/kubernetes/ comme indiqué dans ce gist. https://gist.github.com/spstratis/0395073ac3ba6dc24349582b43894a77

J'ai également créé un fichier de configuration vers lequel pointer lorsque je lance le programme kubeadm init . En voici l'exemple' \s contenu. https://gist.github.com/spstratis/086f08a1a4033138a0c42f80aef5ab40

Quand je cours sudo kubeadm init --config /etc/kubernetes/kubeadminitmaster.yaml il s'arrête avec l'erreur suivante.

[kubelet-check] Initial timeout of 40s passed.
[kubelet-check] It seems like the kubelet isn't running or healthy.
[kubelet-check] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get http://localhost:10248/healthz: dial tcp 127.0.0.1:10248: connect: connection refused.

Vérification de sudo systemctl status kubelet me montre que le kubelet fonctionne. Pour l'instant, j'ai désactivé le pare-feu sur ma machine virtuelle principale à des fins de test, afin de vérifier que le cluster s'amorce de lui-même.

   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           10-kubeadm.conf
   Active: active (running) since Sat 2019-02-16 18:09:58 UTC; 24s ago
     Docs: https://kubernetes.io/docs/home/
 Main PID: 16471 (kubelet)
    Tasks: 18 (limit: 4704)
   CGroup: /system.slice/kubelet.service
           16471 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cloud-config=/etc/kubernetes/vsphere.conf --cloud-provider=vsphere --cgroup-driver=systemd --network-plugin=cni --pod-i

Voici quelques journaux supplémentaires ci-dessous montrant que la connexion à https://192.168.0.12:6443/ est refusée. Tout cela semble faire échouer kubelet et empêcher le processus init de se terminer.

    Feb 16 18:10:22 k8s-master-1 kubelet[16471]: E0216 18:10:22.633721   16471 kubelet.go:2266] node "k8s-master-1" not found
    Feb 16 18:10:22 k8s-master-1 kubelet[16471]: E0216 18:10:22.668213   16471 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/kubelet.go:453: Failed to list *v1.Node: Get https://192.168.0.12:6443/api/v1/nodes?fieldSelector=metadata.name%3Dk8s-master-1&limit=500&resourceVersion=0: dial tcp 192.168.0.1
Feb 16 18:10:22 k8s-master-1 kubelet[16471]: E0216 18:10:22.669283   16471 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/kubelet.go:444: Failed to list *v1.Service: Get https://192.168.0.12:6443/api/v1/services?limit=500&resourceVersion=0: dial tcp 192.168.0.12:6443: connect: connection refused
    Feb 16 18:10:22 k8s-master-1 kubelet[16471]: E0216 18:10:22.670479   16471 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:47: Failed to list *v1.Pod: Get https://192.168.0.12:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dk8s-master-1&limit=500&resourceVersion=0: dial tcp 192.1
    Feb 16 18:10:22 k8s-master-1 kubelet[16471]: E0216 18:10:22.734005   16471 kubelet.go:2266] node "k8s-master-1" not found

Answer 1

Vous ne pouvez pas utiliser bootstrap-kubeconfig pour initialiser le kubelet du maître puisque -- comme vous le constatez -- il n'a pas de serveur api à contacter pour générer sa clé privée et son certificat. Catch-22. Je suis sûr à 80 % que la suppression de la --bootstrap-kubeconfig des args du kubelet aidera cette situation. Je voudrais s'attendre à que le kubelet dispose déjà de sa clé et de son certificat en /var/lib/kubelet/pki Il faut donc aussi vérifier.

En outre, en supposant que vous utilisez le /etc/kubernetes/manifests pour exécuter l'apiserver et le controllermanager, assurez-vous que staticPodPath: en /var/lib/kubelet/config.yaml pointe vers le bon répertoire. Il est peu probable que ce soit le problème, mais c'est très bon marché de le vérifier.