[k8s] The connection to the server [ip-address]:6443 was refused – did you specify the right host or port?

J’ai rencontré une série d’erreurs pendant, et après une mise-à-jour sur Ubuntu, entrainant le redéploiement de mon cluster kubernetes.

I. Problèmes de Mise-à-jour du serveur Ubuntu

1.1 URL non valide pendant X temps

Tout commence par un échec de mise en cache avec la commande « apt update » de la dernière version des paquets installés sur ma machine.

E: Release file for http://[URL] is not valid yet (invalid for another XXh YYmin ZZs). Updates for this repository will not be applied.

Ce message nous indique que l’horloge du serveur n’est pas en synchronisation avec l’horloge géographique.

Pour y remédier, redémarrer le service NTP.

$ sudo service ntp restart

Ou,

$ sudo systemctl restart ntp.service

Je vais essayer d’écrire un autre article pour vous aider à dépanner votre serveur si le redémarrage du service NTP ne vous a pas aidé. Sinon, à la fin de cette article, je vous ai partargé mes sources afin que vous puisser progresser et résoudre le problème par vous même.

1.2 Cache vérouillé

Vient ensuite le moment de la mise-à-jour avec « apt upgrade » qui ne se déroule pas comme prévue, et nous renvoie un message:

Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend

De mon côté, je n’ai rien fait de particulier à part patienter. La mise-à-jour s’est terminée sans encombre après un certain temps d’attente.

Je tiens à préciser que j’ai essayé de tuer le processus apt qui a bloqué la màj, mais rien n’y fait. J’étais retombé sur le même message d’erreur.

II. Cluster Kubernetes inaccessible

2.1 Problème d’accès au cluster

Vient ensuite un problème d’accès au cluster kubernetes, la liste des Pods et des Nodes dans ne peut pas s’afficher.

$ kubectl get node
The connection to the server [URL]:6443 was refused - did you specify the right host or port?

Je tiens à précisé que mon clusteur fonctionnait sans problème avec cette màj. De ce fait, la méthode ci-dessous risque de ne pas fonctionner si vous n’êtes pas dans les mêmes conditions.

Vérifier avant tout, que tous les services nécessaires au bon fonctionnement de kubernetes ont bien démarrés.

$ service docker status

$ systemctl status kubelet 

Détruisez le cluster kubernetes, en lançant la commande  kubeadm reset sur chacun des nodes et, du/des Master(s).

 

$ kubeadm reset

Cette commande ne supprime pas le fichier $HOME/.kube.bak, qu’il va falloir supprimer manuellement au niveau du Master, afin d’éviter d’avoir des problèmes de certificats.

$ mv $HOME/.kube $HOME/.kube.bak

Lancer ensuite la commande kubeadm init, puis suivez les instructions proposées.

Je ne vais pas ré-expliquer tout le processus, mais si vous avez des doutes, revoyez le chapitre sur le déploiement de kubernetes avec kubeadmin.

$ sudo kubeadm init --pod-network-cidr [CIDR]/[SUBNET]

$ mkdir -p $HOME/.kube

$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

$ sudo su

# export KUBECONFIG=/etc/kubernetes/admin.conf

# exit

Vous pouvez maintenant joindre chacun des Nodes au Master.

$ sudo kubeadm join [ip-address]:6443 --token xxxxxxxxxxxxxxxxx \
--discovery-token-ca-cert-hash sha256:84496fa085b4bd4b15e39b6d368ea690467d0eyyyyyyyyyyyyyyyyyyyyyy

Finalement, redéployer le plugin Canal, pour les communications réseaux.

$ curl https://docs.projectcalico.org/manifests/canal.yaml -O

$ kubectl apply -f canal.yaml

Vérifier maintenant que tout est bon.

$ kubectl get pod -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system calico-kube-controllers-85b5b5888d-g6ttn 1/1 Running 0 2m14s
kube-system canal-55ln8 2/2 Running 0 2m15s
kube-system canal-ml6qf 2/2 Running 0 2m15s
kube-system canal-nhp8s 2/2 Running 0 2m15s
kube-system coredns-64897985d-7lll2 1/1 Running 0 24m
kube-system coredns-64897985d-x8bm9 1/1 Running 0 24m
kube-system etcd-k8sn01 1/1 Running 3 24m
kube-system kube-apiserver-k8sn01 1/1 Running 3 24m
kube-system kube-controller-manager-k8sn01 1/1 Running 4 (9m6s ago) 24m
kube-system kube-proxy-8b48j 1/1 Running 0 24m
kube-system kube-proxy-9qdjf 1/1 Running 0 22m
kube-system kube-proxy-v4579 1/1 Running 0 16m
kube-system kube-scheduler-k8sn01 1/1 Running 4 (9m6s ago) 24m

2.2 Quelques problèmes

Après avoir détruit et reconstruit le cluster de kubernetes, si vous avez un problème de certificat, c’est parce que vous n’avez pas supprimé le fichier $HOME/.kube/config.

$ kubectl get node
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")

Une autre erreur que vous pouvez rencontrer,

$ sudo kubeadm join [ip-address]:6443 --token xxxxxxxxxxxxxxxxx \
--discovery-token-ca-cert-hash sha256:84496fa085b4bd4b15e39b6d368ea690467d0eyyyyyyyyyyyyyyyyyyyyyy

[preflight] Running pre-flight checks
error execution phase preflight: [preflight] Some fatal errors occurred:
[ERROR FileAvailable--etc-kubernetes-kubelet.conf]: /etc/kubernetes/kubelet.conf already exists
[ERROR Port-10250]: Port 10250 is in use
[ERROR FileAvailable--etc-kubernetes-pki-ca.crt]: /etc/kubernetes/pki/ca.crt already exists
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
To see the stack trace of this error execute with --v=5 or higher

Ceci est du au fait que vous n’avez pas réinitialiser l’un des nodes avec kubeadm reset.

Sources

sudo apt update error: « Release file is not yet valid »
The connection to the server <host>:6443 was refused – did you specify the right host or port?