Troubleshooting on Zwindler's Reflection

Minikube sur Hyper-V part 2 : troubleshooting de l’installation

Tue, 02 Oct 2018 11:45:54 +0000

Minikube, le retour

Il y a deux semaines, j’ai fais un article sur l’installation de Minikube sur un poste Windows 10. Petite subtilité, l’article en question explique comment installer Minikube sur Hyper-V, nativement présent avec Windows 10, plutôt qu’avec Virtual Box, le choix par défaut mais qui nécessite un téléchargement et une installation complémentaire. Si vous l’avez loupé, c’est par ici.

Option 2 : Expectations meet life

On s’était arrêté dans l’article précédent à un monde merveilleux ou tout marche du premier coup.
Mais, vous vous en doutez, dans la vie (et particulièrement dans l’IT), rien ne se passe jamais comme prévu.

Voilà donc un petit florilège des problèmes que vous pourriez (ou avez) rencontrer (et leur résolution !)

VBoxManage not found

Si vous en venez à vous demander comment l’installer sur Hyper-V, c’est probablement que vous avez commencé par lancer la commande « minikube start » sans arguments… L’installeur a donc bêtement assumé que vous utilisiez Virtual Box (pourquoi ?) et vous vous retrouvez avec l’erreur suivante :

Error getting state for host: VBoxManage not found. Make sure VirtualBox is installed and VBoxManage is in the path.

Pourtant, vous avez beau forcer le start avec le flag suivant, rien y fait, ce n’est pas pris en compte.

--vm-driver hyperv

Pour trouver comment résoudre ce problème, vous pouvez jeter à œil à cette issue sur github

En réalité, une fois le premier « start » lancé, les fichiers de configuration sont générés dans C:\users[votrelogin].minikube (et en particulier dans profiles\minikube\config.json).

Impossible d’expliquer à l’installeur que vous avez changé d’avis (oui oui…), il faut donc de supprimer tout le dossier .minikube et recommencer avec les bons paramètres la prochaine fois (enfin c’est le plus simple, on va dire).

minikube-v0.xx.x.iso: Le chemin d’accès spécifié est introuvable…

minikube-v0.28.1.iso: Le chemin d’accès spécifié est introuvable...

Ok, ça ne marche toujours pas. On passe en mode verbose pour avoir l’erreur exacte :

PS C:\windows\system32> minikube start --vm-driver hyperv --hyperv-virtual-switch "Primary Virtual Switch" -v=7
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
[...]
[stderr =====>] :
Downloading D:\Users\zwindler\.minikub\cache\boot2docker.iso from file://D:/Users/zwindler/.minikub/cache/iso/minikube-v0.28.1.iso...
E0906 15:10:27.568262 14484 start.go:174] Error starting host: Error creating host: Error executing step: Creating VM.: open /Users/zwindler/.minikub/cache/iso/minikub-v0.28.1.iso: Le chemin d’accès spécifié est introuvable..
Retrying.
E0906 15:10:27.873612 14484 start.go:180] Error starting host: Error creating host: Error executing step: Creating VM.
: open /Users/zwindler/.minikube/cache/iso/minikube-v0.28.1.iso: Le chemin d’accès spécifié est introuvable.

Pourtant le fichier existe. Et c’est reparti pour un tour sur Github pour avoir plus de détails !

Ici, c’est donc tout simplement le script Minikube qui ne sait pas que vous avez un disque **D:**… Alors qu’il vient de le déposer lui même dans *D:* une ligne plus haut !!! La solution donc :

you can specify the path for the .minikub directory by setting the MINIKUBE_HOME env variable

Bon en vrai la bonne syntaxe sous Windows (dans Powershell en tout cas) c’est :

$MINIKUBE_HOME="D:\Users\[votrelogin]\"

On oublie pas de nettoyer la tentative précédente avec un :

minikube delete

FLMNH : « Error deleting machine profile config »

Si jamais en essayant de nettoyer votre environnement (pour recommencez, vous essayez un « minikube delete » et que vous vous prenez une erreur).

minikube delete
Deleting local Kubernetes cluster...
Machine deleted.
Error deleting machine profile config

Rebelotte, on supprime le dossier D:\Users[votrelogin].minikube à la main.

Error starting host: Error starting stopped host: exit status 1

Tout à l’air de fonctionner. Vous croyez que vous vous en êtes sortis ? Pauvres fous ;)

Au moment où tout se termine, le script vérifie que le cluster est opérationnel. Et après avoir boucler un moment : PAF !

Error starting host: Error starting stopped host: exit status 1

L’erreur n’est pas très explicite. En gros, vous êtes dans le cas où tout est bien installé, mais le curl pour vérifier que le cluster est UP échoue, pour un souci réseau. La plupart du temps, il s’agit de l’erreur suivante :

After some troubleshooting and head banging, it became apparent that the external network adapter had an ethernet adapter selected that was not connected to a network. (ethernet selected, instead of the wireless adapter). Of course an IP wont be allocated on an external network if none is connected.

Vérifiez donc dans les paramètres d’Hyper-V que vous ne vous êtes pas trompé d’adaptateur réseau lors de la configuration du réseau virtuel (cf l’article précédent) !

unable to authenticate, attempted methods [publickey none]

Ok, cette fois ci tout est censé être bon. Pourtant, à la fin, ça plante encore (désespoir).

Error dialing TCP: ssh: handshake failed: ssh: unable to authenticate, attempted methods [publickey none], no supported methods remain

Là je ne suis pas sûr à 100% ni de la cause, ni du fix, mais a priori, c’était un problème lié au client/serveur OpenSSH fourni par Microsoft, qui serait pourri. L’installation d’une autre version via Chocolatey semble avoir résolu le problème.

github.com/kubernetes/minikube/issues/2329

PS D:\> minikube ip
172.16.25.217

choco install openssh
Chocolatey v0.10.11
Installing the following packages:
openssh

Kubernetes avec Kubespray part 2 – Astuces & troubleshooting

Tue, 30 Jan 2018 12:45:54 +0000

Kubespray ?

Pour ceux qui ne savent pas ce qu’est Kubernetes, je vous invite à lire les articles que j’ai écris à ce sujet. Kubernetes est un produit permettant de gérer des clusters de machines exécutant des containers en production. Et pour ceux qui ne connaissent pas Kubespray, il s’agit d’un outil principalement basé sur Ansible permettant de simplifier l’installation (relativement complexe) de Kubernetes.

En théorie, si vous partez avec des machines vierges et qui peuvent discuter entre elles, vous devriez avoir un cluster Kubernetes opérationnel en une vingtaine de minutes et en deux lignes de commande, en suivant ce tutoriel pas à pas.

ansible-playbook -i inventaire_kubernetes/inventory.cfg cluster.yml -b -v --private-key=~/.ssh/id_rsa
[...]
Monday 29 January 2018 15:57:07 +0100 (0:00:00.050) 0:17:56.289 ********
===============================================================================

Bon… j’ai quand même eu quelques erreurs et j’ai décidé de les consigner « à part » de l’article d’installation. Je le mettrais à jour dès que j’en rencontre de nouvelles.

Erreur kubespray-defaults : Configure defaults

Si l’installation plante à cette étape avec une très loooongue erreur bien rouge, vérifier qu’il n’y a pas écrit en fin de ligne

The ipaddr filter requires python-netaddr be installed on the ansible controller

Si c’est le cas, vous avez probablement oublié d’installer le paquet python-netaddr comme indiqué au début du tutoriel d’installation.

Erreur « kubernetes/preinstall : Stop if swap enabled »

Cette erreur est assez explicite : vous avez oublié de désactiver la swap sur un des nœuds.

TASK [kubernetes/preinstall : Stop if swap enabled] *********************************************************************************************************
Monday 29 January 2018 15:06:44 +0100 (0:00:00.092) 0:00:23.562 ********
fatal: [kube01.zwindler.fr]: FAILED! => {
"assertion": "ansible_swaptotal_mb == 0",
"changed": false,
"evaluated_to": false
}

On peut facilement la désactiver avec la boucle Ansible suivante :

ansible kube*.zwindler.fr -m shell -a "swapon -s"
kube01.zwindler.fr | SUCCESS | rc=0 >>
Nom de fichier Type Taille Utilisé Priorité
/dev/sda3 partition 1048572 25812 -1
[...]
ansible kube*.zwindler.fr -m shell -a "swapoff -a"
kube01.zwindler.fr | SUCCESS | rc=0 >>

Mais il ne faudra pas oublier de passer aussi dans la fstab pour que le changement soit permanent (attention le sed est un peu brut, je vous invite à vérifier ce qu’il fait) !

ansible kube*.zwindler.fr -m shell -a "grep swap /etc/fstab"
kube01.zwindler.fr | SUCCESS | rc=0 >>
UUID=18eaabbe-aaaa-aaaa-aaaa-205cdaa94fe6 swap swap defaults 0 0
ansible kube*.zwindler.fr -m shell -a "sed -i.bak '/swap/d' /etc/fstab"
[WARNING]: Consider using template or lineinfile module rather than running sed
kube01.zwindler.fr | SUCCESS | rc=0 >>

Too many nameservers

Typiquement c’est vraiment une erreur « à la c** ». Pas de bol pour moi, ça a planté directement avec l’erreur « Too many nameservers ». O-kay…

Effectivement, j’ai plusieurs serveurs DNS renseignés sur mon OS et Kubespray ne supporte pas plus de 2 out of the box.

Bon pas de drame, l’utilitaire nous indique qu’on peut contourner cette « erreur » simplement en modifiant une variable :

You can relax this check by set docker_dns_servers_strict=no and we will only use the first 3.

Dans le fichier cluster.yml, recherchez le block suivant et ajouter les lignes -vars puis - docker_dns_servers_strict: no

vi cluster.yml
[...]
- hosts: k8s-cluster:etcd:calico-rr
any_errors_fatal: "{{ any_errors_fatal | default(true) }}"
vars:
- docker_dns_servers_strict: no
roles:
- { role: kubespray-defaults}
- { role: kernel-upgrade, tags: kernel-upgrade, when: kernel_upgrade is defined and kernel_upgrade }
- { role: kubernetes/preinstall, tags: preinstall }
- { role: docker, tags: docker }
- role: rkt
tags: rkt
when: "'rkt' in [etcd_deployment_type, kubelet_deployment_type, vault_deployment_type]"
[...]

Proxy pour pull les images Docker

J’ai été pas mal embêté par le proxy lors de l’installation de mon cluster avec kubeadm. Même si je n’ai pas été bloqué avec Kubespray, j’ai quand même été un peu embêté ;-).

Le contournement est simple, ici il suffit de configurer le proxy sur les démons docker de toutes les machines du cluster. Avec Ansible :

ansible -m shell master* worker* -a 'cat > /etc/systemd/system/docker.service.d/http-proxy.conf << EOF
[Service] Environment="HTTP_PROXY=http://@IP-mon-super-proxy:8080/"'
ansible -m shell master* worker* -a "systemctl daemon-reload"
ansible -m shell master* worker* -a "systemctl restart docker"

Attention au restart si vous avez des containers qui tournent… mais je vais partir du principe que nous puisque vous êtes en train d’installer un cluster Kubernetes (depuis zéro).

The error was: no test named ‘equalto’

Vous avez probablement oublié un des prérequis du tutoriel : la version de jinja n’est pas pas à jour…

pip install --upgrade Jinja2

Messages d’information à chaque exécution de kubectl

J’ai aussi eu un petit bug (non bloquant) une fois l’installation terminée. A chaque exécution de kubectl, j’avais les messages suivants qui s’affichaient dans le terminal.

kubectl describe service kubernetes-dashboard --namespace=kube-system
2017-08-24 10:20:09.035979 I | proto: duplicate proto type registered: google.protobuf.Any
2017-08-24 10:20:09.036050 I | proto: duplicate proto type registered: google.protobuf.Duration
2017-08-24 10:20:09.036066 I | proto: duplicate proto type registered: google.protobuf.Timestamp
[…]

Une « issue » a été remontée sur le github de la version de Kubernetes déployée par Azure, à savoir acs-engine, mais est applicable dans notre cas aussi. A priori c’est une version de kubectl qui a le problème.

Le problème devrait être résolu avec la version qu’on trouve sur les repository.

mv /usr/local/bin/kubectl /usr/local/bin/kubectl.old
yum install -y kubectl
ln -s /usr/bin/kubectl /usr/local/bin/kubectl