Rancher on Zwindler's Reflection

Test (incomplet) de Rancher Labs Harvester, plateforme de virtualisation hyperconvergée

Tue, 24 Jan 2023 06:30:00 +0200

Je ne dirais pas que c’est un échec. Je dirais que ça n’a pas marché !

Disclaimer !

Je vous préviens tout de suite, même si j’ai réussi à installer Harvester et avoir un cluster fonctionnel, j’ai eu beaucoup de mal à l’utiliser, car mes machines étaient trop peu puissantes pour le faire fonctionner.

En effet, en lisant la doc (lol, qui fait ça ?) je me suis rendu compte que les prérequis sont relativement élevés :

Harvester : great for “edge HCI” !

Also Harvester : 16-core/64 GB RAM or above preferred for production

Je ne vais donc pas totalement au bout du test, ne soyez pas déçu / vous êtes prévenus.

Lab maison

Il y a quelques mois, j’ai décidé d’acheter des petites machines pour me faire un “lab” à la maison.

L’idée était de pouvoir tester des technos telles que des hyperviseurs, sans galérer avec des VMs (et avoir des perfs pourries en “nested virt”) ou galérer avec les interfaces types ILO pas toujours très bien supportées par les différents hébergeurs “pas chers”.

Pour éviter de me ruiner, j’ai décidé d’acheter d’occasion 3 Dell micro (pour avoir un nombre impair de machines) de la gamme 3050 ou équivalent et avec les caractéristiques suivantes :

i5-6500T à 4 cores
entre 4 et 16 Go de RAM DDR3(L) ou DDR4
un emplacement 2"5 SATA et éventuellement un emplacement NVMe

D’abord, ces machines sont assez peu couteuses (entre 100 et 150€ sur LeBonCoin ou les reconditionneurs en cherchant bien). Ensuite, elles consomment très peu grâce au i5-T (autour de 10w en idle) ce qui me permet de les laisser allumées quelques heures sans me sentir mal pour ma facture d’électricité ou la planète. Enfin, elles sont super compactes, presque silencieuses et jolies. On est loin du rack qui fait tâche dans le salon.

Une fois que je les ai reçues, je vous ai demandé sur Twitter/Masto ce que vous vouliez que je mette dessus. Parmis vos réponses, c’est Harvester qui a attiré ma curiosité parmis vos réponses.

Mais c’est quoi Harvester ?

Harvester est un produit de chez Rancher Labs (compagnie achetée par Suse en 2020).

Harvester is the next generation of hyperconverged infrastructure designed for the modern cloud-native environment.

C’est donc un produit de virtualisation, dans la gamme des solutions “hyperconvergées”, où le stockage de chaque noeud est mis dans un pool commun de stockage distribué.

Vous avez sûrement entendu parler de Nutanix ou de VMware vSAN, ou peut être de Proxmox VE qui propose un cluster Ceph natif, pour faire la même chose en open source.

Ce que met en avant en premier Rancher, c’est que Harvester est un outil simple à utiliser.

Hyperconverged infrastructure doesn’t need to be complex or expensive. With Harvester and Rancher, IT operators now have access to an enterprise-ready, simple-to-use infrastructure platform that cohesively manages their virtual machines and Kubernetes clusters alongside one another.

Ok, why not. Mais là où ça se complique, c’est quand on creuse un peu sur comment c’est fait :

Built by the Rancher engineering team, Harvester is powered by 100% open source cloud native technology including Kubernetes, Longhorn and Kubevirt.

Mkay. Utiliser Kubernetes pour faire des VMs, ça “marche” (Kubevirt), mais c’est clairement pas l’idée que j’aurais en premier.

Techniquement c’est quoi ?

Pour aller voir de plus près comment ça marche, le plus simple est d’aller voir le repository officiel de harvester (c’est open source, tout est disponible sur Github.com).

Le plus intéressant est ce fichier harvester/deploy/charts/harvester/Chart.yaml dans lequel on peut voir tout ce qui est déployé par défaut sur nos machines Harvester :

kubevirt-operator
harvester-network-controller
harvester-node-disk-manager
csi-snapshotter
longhorn
kube-vip
harvester-load-balancer
whereabouts
harvester-node-manager

Ca fait pas mal de composants et ça explique certainement les requirements élevés en nombre de CPUs minimum (on a tendance à réserver plus de CPU qu’on en consomme sur les composants techniques d’un cluster Kubernetes, par sécurité).

Voyons voir comment ça s’installe.

Bon là, c’est relativement classique, on peut booter Harvester via un serveur PXE ou l’installer via un ISO avec une clé USB.

J’avais la flemme de monter un serveur PXE (mais il va falloir que je m’y mette, on en reparlera dans un autre article, cela dit) donc je suis resté simple et efficace.

Un petit coup de balena Etcher et on en parle plus.

wget https://releases.rancher.com/harvester/v1.1.1/harvester-v1.1.1-amd64.iso

chmod +x balenaEtcher-1.13.1-x64.AppImage
./balenaEtcher-1.13.1-x64.AppImage

On a ensuite une interface d’install assez basique et plutôt simple dans laquelle on renseigne hostname, IP, token pour créer ou joindre un cluster existant. Dans un contexte plus pro/industrialisé, le boot PXE et une config automatisée prendront évidemment tout leur sens.

non, ce n’est pas de la neige sur l’écran, il est juste affreusement sale…

Effectivement, je n’ai eu aucun souci à ce niveau et c’était très simple. Une fois l’installation de nos 3 noeuds terminée, on se retrouve avec une interface comme celle ci :

On se connecte

Maintenant qu’on a un cluster fonctionnel, on peut aller faire un tour sur l’interface de management.

On nous avait promis quelque chose de simple et c’est pas des blagues ! C’est simple, pour ne pas dire simpliste.

Un menu pour les VMs, un pour les volumes, un pour le réseau, un pour les backups (et quelques autres).

La première VM

On ne perd pas de temps, je suis tout de suite allé créer un VM (on est quand même là pour ça).

Préalablement, c’est mieux si on a créé un Namespace (oui, vous vous souvenez c’est du Kubernetes !) et uploadé une clé SSH. Le menu reste simple, on est proche de ce qu’on va trouver chez les grands cloud providers, par exemple.

Il y a juste une petite subtilité pour ce qui est de la création de volumes, je trouve le wizard pas hyper clair la première fois. Pour créer la VM, il va vous falloir probablement soit un ISO, soit un volume que vous aurez préalablement créé contenant l’OS sur lequel booter.

Sauf que l’interface ne parle que de “disques” sans plus de détails. Il faut comprendre qu’on va ajouter un CDROM (ISO) et un disque (HDD).

Et il faut changer de menu pour uploader l’ISO, car on ne peut pas le faire directement dans le menu de création de VM.

On a vu plus simple comme UX d’un hyperviseur. Heureusement l’interface des ISOs a quand même l’avantage de proposer de rentrer une URL et de DL le fichier pour nous (comme Proxmox VE), ce qui gagne du temps.

On peut ensuite ajouter à notre VM des volumes (en cliquant sur Volumes dans le menu au milieu à gauche) et ajouter l’ISO et un volume vide.

Ce qui est intéressant ici, c’est que mon volume est provisionné dans le stockage longhorn, à savoir, le fameux pool de stockage distribué aggrégeant les disques de tous mes serveurs, géré “automagiquement”.

Si j’ajoute des noeuds, le stockage s’étend. Si j’en retire, toutes les données sont redistribuées.

Ca me fait toujours un peu flipper ce genre de solutions. Quand “ça se passe mal”, c’est quand même bien d’avoir la main et j’aurais probablement plus confiance dans un Ceph (sur Proxmox VE) sur lequel j’ai plus facilement la main pour réparer/rebalance, que sur un longhorn prépackagé pour moi.

Mais peut-être que c’est juste une histoire d’habitude et que ça se gère tout aussi bien.

On la boote, cette VM ?

Une fois configurée, on peut donc commencer à booter notre VM et voir si elle fonctionne comme attendue.

Et c’est là où les choses ont commencé à sérieusement se gâter pour moi. En effet, je l’ai dit tout au début de l’article, mes machines ne sont tout simplement pas assez puissantes pour héberger une solution hyperconvergée de ce type.

Les SSDs étaient trop lents (je n’ai pas encore investi dans des NVMe pour avoir les données séparées du disque SATA de l’OS) et surtout, les CPUs étaient au max.

Sans aucune VM, à vide, Harvester réserve déjà quasiment les 4 CPUs de mes 3 machines. Pire, sur la machine harvester01, l’interface me disait réserver plus de cores que ce que la machine disposait (4.5 cores). Niveau RAM, ça allait même si à l’usage 10-12 Go par machine aurait probablement été juste.

Le résultat était que la plupart des fonctionnalités étaient extrêmement lentes. Ma VM a mis une 20aines de secondes à se créer puis booter.

Même la navigation dans l’interface était parfois pénible. J’ai mis plusieurs minutes avant de pouvoir afficher la console VNC de ma VM. Le stockage avait du mal à se synchroniser entre les nodes.

Je ne parle même pas de tester des fonctionnalités plus avancées comme les live-migrations, les snapshots, les backups/restaurations. J’ai donc décidé de finir d’explorer les menus puis de couper court à l’essai.

Les autres menus

Au-delà de la partie purement HCI (hyperconverged infrastructure), Rancher Labs met en avant le fait qu’il existe de belles synergies entre Harvester et Rancher. Typiquement, il est possible de gérer ses clusters Harvester depuis Rancher (si j’ai bien compris) et inversement de créer plus facilement des clusters Kubernetes/Rancher grâce à Harvester.

N’ayant pas du tout l’infra pour tester, je ne peux pas trop juger de la pertinence de cette fonctionnalité.

J’ai aussi trouvé intéressant l’ajout d’extension directement dans l’interface d’Harvester. On est proche de l’expérience Kubernetes packagée par certains cloud providers qui fournissent presque plus un PaaS propulsé par Kubernetes qu’un KaaS.

On peut très facilement déployer une stack de monitoring Prometheus ou de logging avec fluentbit

Je n’ai pas testé non plus, mais il existe des providers terraform officiels assez complets qui permettent d’automatiser pas mal d’actions. Je ferai peut être un test avec un update de l’article.

registry.terraform.io/providers/harvester

Conclusion && pour aller plus loin

J’imagine que comme moi, vous restez sur votre faim. Je n’ai vraiment pas pu aller loin à cause de mes problématiques de matériel. Si vous voulez en savoir plus, je vous invite donc à regarder la vidéo Harvester deep dive avec Saiyam Pathak (Kubesimplify) et Guangbo Chen (Rancher Labs).

Personnellement, comme pour mon précédent test de RancherOS (un autre produit Rancher Labs), j’ai du mal à bien comprendre à qui s’adresse ce genre d’outils.

Harvester est présenté comme une solution HCI basée sur Kubernetes mais avec une interface simplifiée à l’extrême pour permettre à des opérateurs IT (vos équipes IT traditionnelles, disons) qui ne maîtrisent pas ces technos, de le gérer. La simplicité est vraiment l’argument principal mis en avant et l’interface reflète cette promesse.

Mais… au-delà des éventuelles synergies avec l’écosystème Rancher Labs… pourquoi est ce qu’une équipe IT aurait envie d’installer un hyperviseur basé sur Kubernetes (+ Kubevirt + longhorn) ???

Des solutions de virtualisation vraiment simples existent sur le marché (qu’elles soient open source ou pas, on-prem ou managées). Kubernetes n’est pas pensé pour faire du Pet (vs Cattle) et ce n’est clairement pas dans un usecase d’hyperviseur simple que je le mettrais en avant.

Dernier point, dans un monde où l’électricité coûte un bras et où tout le monde se targue d’être plus green que green (c’est pour la planète), peut-on vraiment accepter qu’une solution de virtualisation demande des prérequis en ressources aussi importants ?

Peut-être que j’ai tout faux, mais tout ça me parait assez peu efficient…

k3os, le reboot de RancherOS à la sauce k3s

Tue, 08 Dec 2020 07:45:00 +0000

k3os, encore un produit Rancher ?

Oui, k3os. Je vais donc ENCORE parler d’un produit de Rancher aujourd’hui, et la raison principale est que cet article est plus ou moins la suite logique des deux précédents sur RancherOS et RKE

Dans Kubernetes avec RancherOS et RKE partie 1, je vous expliquais que j’avais ENCORE changé d’infra et que pour le fun, j’avais souhaité essayer d’installer RancherOS puis RKE, respectivement comme distrib pour mes nodes Kubernetes et comme méthode d’installation de Kubernetes lui même.

Bon, alors d’abord j’ai pas été super convaincu par RancherOS (pas seulement pour mon usage perso, mais aussi plus globalement) et en plus, j’ai découvert grâce aux commentaires que RancherOS était en fait abandonné.

Bummer…

k3s pour mon usecase c’est quand même mieux

Bon en vrai ce n’était pas bien grave, car le but était de tester ces produits dont j’entendais parler depuis un moment. Mais du coup, je n’ai toujours pas de Kubernetes viable pour mes geekeries…

Un des outils qui correspond le mieux à mon usecase, là encore chez Rancher, c’est k3s. Un Kubernetes minimaliste qui prend très peu de ressources et qui est simple à installer.

J’avais d’ailleurs fait quelques articles dessus, notamment pour parler d’un playbook Ansible qui permettait de déployer k3s sur des instances ARM dans le cloud de Scaleway (la bonne époque où ils en proposaient, en tout cas…).

Le code est toujours dispo et n’était pas spécifique à ARM ni à Scaleway, si ça vous intéresse.

Et k3os dans tout ça ?

La méthode d’installation de Kubernetes est donc choisie. Mais ça ne répond pas à la seconde question, à savoir, sur quelle distribution je l’installe.

Je peux l’installer sur n’importe quel OS Linux généraliste (Debian, Ubuntu, CentOS, … you name it), mais le but, c’est quand même d’installer un Kubernetes le plus léger possible (car je suis radin sur les serveurs que je loue et ils sont peu puissants).

Qu’à cela ne tienne, me dis-je ! Pourquoi ne pas retenter l’expérience CoreOS et RancherOS avec k3os ?

Et c’est vraiment une bonne question…

k3OS donc

k3OS is a Linux distribution designed to remove as much OS maintenance as possible in a Kubernetes cluster. It is specifically designed to only have what is needed to run k3s. Additionally the OS is designed to be managed by kubectl once a cluster is bootstrapped. Nodes only need to join a cluster and then all aspects of the OS can be managed from Kubernetes. Both k3OS and k3s upgrades are handled by the k3OS operator. github.com/rancher/k3os

k3os est donc une distribution optimisée par Rancher pour fonctionner avec k3s et consommer le moins de ressources possibles.

Les avantages mis en avant sont que dès que l’OS est installé, on a un Kubernetes fonctionnel puisque k3s est préinstallé et configuré à l’install de l’OS.

L’autre avantage mis en avant est que tout la gestion du cycle de vie de l’OS est piloté à l’aide d’un operateur dans Kubernetes (k3OS operator) qui va nous permettre de gérer l’OS depuis Kubernetes directement.

Mkay, pourquoi pas.

Et c’est reparti pour un tour

Même procédure que pour l’article sur RancherOS, les principes sont très similaires. On va télécharger une image iso, créer une VM et se connecter dessus en liveCD pour installer l’OS sur le disque.

La page des releases est ici : github.com/rancher/k3os/releases

cd /var/lib/vz/template/iso
wget https://github.com/rancher/k3os/releases/download/v0.11.1/k3os-amd64.iso

To copy k3OS to local disk, after logging in as rancher run sudo k3os install. Then remove the ISO from the virtual machine and reboot.

STOOOOOP

Exactement comme dans l’install de RancherOS, si vous partez bille en tête vous risquez de tomber sur un OS (ahah).

Dans l’article précédent, j’avais fait l’andouille et lancé la commande, pour me rendre compte qu’une fois installé, je n’avais ni réseau, ni clé SSH pour me connecter sur l’utilisateur rancher post install.

En vrai, tout doit se faire via cloud-config…

Bon, pour être honnête, cette fois-ci, ils ont quand même un peu plus prévu le coup. Si vous ne fournissez pas de cloud-config, cette fois-ci k3os vous propose de rentrer un mot de passe pour votre rancher.

Mais vous n’aurez pas plus de réseau si comme moi vous n’avez pas mis de DHCP sur votre LAN (cf aparté pour les bolosses qui n’ont pas de DHCP plus tard dans l’article).

cloud-config

Partons donc pour l’instant du principe que vous avez un DHCP et que vous aurez donc, une fois k3OS installé, accès réseau à votre machine.

Proxmox a la bonne idée de permettre la création de volume cloud-init directement depuis l’UI.

Cependant, j’ai bien l’impression que le format du cloud-init de Proxmox ne correspond pas au format attendu par k3OS…

OK, je suis pas fâché.

On va donc devoir le faire à la mimine et ça tombe bien, car on a ENCORE le souci du clavier Qwerty/Azerty… (cf Bonus Qwerty), ce qui est parfait pour copier à la main une clé SSH, c’est bien connu.

Vous l’aurez compris, on va s’en sortir une fois de plus avec un port série et la console de type xterm.js…

Grosso modo, mon cloud config s’est limité à ça.

cat > config.yml << EOF
k3os:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQAaaaaaaaaaaaaaaaaaaaaaaaaaaaOF0lZiHOjIZ/27aaHmNTq27Vws2dhzJ9 rancher
EOF

Tout ça pour ça me direz-vous ? Oui…

Mais bon, une fois qu’on a ça, on peut passer à l’install elle-même, qui est en fait un mini installeur qui vous pose quelques questions un peu triviales comme « rôle du node », « token », « chemin de la clé SSH ».

k3os-15121 [~]$ sudo k3os install
Running k3OS configuration
Choose operation
1. Install to disk
2. Configure server or agent
Select Number [1]:
Config system with cloud-init file? [y/N]: y
cloud-init file location (file path or http URL): config.yml
[...]

Ces valeurs peuvent d’ailleurs être ajoutées au cloud-config pour vous permettre d’automatiser la totalité de l’opération.

A l’issue de l’opération… magie ! vous aurez un Kubernetes tout neuf et tout léger :)

Aparté pour les bolosses qui n’ont pas de DHCP (aka. moi)

Ça aurait été plus simple de monter un petit serveur DHCP vite fait mais je suis têtu comme pas deux.

La blague avec k3OS est que, contrairement à RancherOS, il n’est tout simplement pas possible d’installer l’OS en lui spécifiant l’adresse réseau physique qu’il devra avoir post install.

En fait au début, j’avais copié ce que j’avais fait pour RancherOS. L’installeur de k3OS ne râle pas, mais il ignore simplement le code en trop.

Et vous ne pourrez plus vous connecter…

Mais comme je suis têtu (je me répète), j’ai cherché à tout prix la solution.

L’idée ici est de feinter l’installeur en ne lui donnant PAS de cloud config. On garde ainsi la possibilité de se loguer à l’utilisateur rancher avec un mot de passe (pas bien ça…).

Une fois k3OS installé, on se connecte une nouvelle fois en console (oui, on risque pas de le faire en SSH…) et on configure la carte réseau.

k3OS est un dérivé d’Alpine (pour les binaires userspace) avec le kernel d’Ubuntu 20.04 (oh…kay ?).

Pour setter le réseau, vous pouvez donc faire :

sudo connmanctl services
*AR Wired ethernet_c6eb50d8c655_cable

Cette commande vous renvoie le nom de la carte réseau virtuelle. Vous pouvez maintenant regarder la configuration par défaut

sudo connmanctl services ethernet_c6eb50d8c655_cable
/net/connman/service/ethernet_c6eb50d8c655_cable
Type = ethernet
Security = [ ]
State = ready
Favorite = True
Immutable = False
AutoConnect = True
Name = Wired
Ethernet = [ Method=auto, Interface=eth0, Address=C6:EB:50:D8:C6:55, MTU=1500 ]
IPv4 = [ Method=auto, Address=169.254.126.16, Netmask=255.255.0.0 ]
IPv4.Configuration = [ Method=auto ]
IPv6 = [ ]
IPv6.Configuration = [ Method=auto, Privacy=disabled ]
Nameservers = [ 8.8.8.8 ]
Nameservers.Configuration = [ ]
Timeservers = [ ]
Timeservers.Configuration = [ ]
Domains = [ ]
Domains.Configuration = [ ]
Proxy = [ Method=direct ]
Proxy.Configuration = [ ]
mDNS = False
mDNS.Configuration = False
Provider = [ ]

Grande classe. 8.8.8.8 en DNS… No comment.

Et setter votre carte réseau post installation avec cette dernière commande (à remplacer par vos valeurs à vous, hein) :

sudo connmanctl config ethernet_d2416991aa5b_cable --ipv4 manual 192.168.1.15 255.255.255.0 192.168.1.1 --nameservers 192.168.1.1

Conclusion

Bon je crois qu’il est temps d’arrêter de se faire du mal…

Oui clairement, je me suis mis dans un exemple un peu foireux. Tout le monde de normalement constitué dispose d’un DHCP de nos jours. Surtout que k3OS cible les usages de k3s, à savoir le edge et l’IoT.

Mais du coup, j’ai l’impression qu’on est vraiment dans le marché de niche de la niche : un OS optimisé pour l’IoT ou l’edge uniquement. Je ne suis clairement pas ciblé par k3OS.

Ça ne m’a pas vraiment donné envie de regarder plus en détails la partie k3OS operator, qui permet de gérer les mises à jours de l’OS depuis Kube.

La documentation sur le sujet est disponible ici et ça a l’air d’avoir beaucoup bougé entre la v0.9, la v0.10 et la v0.11, puisqu’il y a des exceptions dans tous les sens…

github.com/rancher/k3os#upgrade-and-maintenance

Bref… il est temps que je m’installe un bête OS généraliste…

Kubernetes avec RancherOS et RKE – partie 2

Mon, 30 Nov 2020 07:45:00 +0000

Déployer Kubernetes avec RKE

Il y a quelques semaines, je vous ai présenté un petit projet que j’avais commencé pour le fun: déployer Kubernetes à l’aide de deux composants de Rancher : RancherOS et RKE.

Kubernetes avec RancherOS et RKE - partie 1

Mais c’est quoi RKE ?

Rancher est une boite pléthorique de solutions pour le monde des containers. Parmi toutes les solutions qu’ils proposent, on a Rancher, k3s, k3os, k3d, Longhorn (pour le stockage), et donc : RancherOS et RKE.

RKE is a CNCF-certified Kubernetes distribution that runs entirely within Docker containers.

RKE est donc une manière d’installer mais surtout de gérer de manière simple Kubernetes.

It solves the common frustration of installation complexity with Kubernetes by removing most host dependencies and presenting a stable path for deployment, upgrades, and rollbacks.

Car si déployer Kubernetes commence à devenir relativement trivial (on peut installer Kubernetes avec microk8s ou minikube sur son portable en quasiment une ligne de commande, Kubeadm est GA,…), ce n’est pas toujours le cas des mises à jour de vos clusters en prod, que ce soit pour l’OS lui-même, ou bien les composants de Kube. C’est le fameux day2 operation dont je vous ai déjà parlé.

RKE pour nous sauver

RKE a donc vocation à nous simplifier la vie, en nous proposant une méthode (plus) simple pour gérer le cycle de vie de nos clusters : un binaire qui manipulera tous les composants de notre Kubernetes dans des containers.

L’idée est intéressante (même si pas nouvelle, de nombreuses distributions de Kubernetes containerisent les composants internes), du coup j’ai voulu voir ce que Rancher proposait.

Et comme je ne veux rien faire comme les autres, je me suis rajouté une difficulté supplémentaire en partant du principe que si Rancher proposait une distrib Linux, j’allais utiliser leur distrib comme base pour les nodes.

Ainsi, l’OS (et Docker) est géré par RancherOS, et la gestion du cycle de vie de mon cluster Kubernetes est gérée par RKE.

Disclaimer

Qu’on se mette d’accord tout de suite. Je ne vous conseille pas du tout de faire la même chose. J’étais simplement curieux de voir si ces 2 solutions proposées par Rancher se mariaient bien ensemble.

Et en fait, j’ai d’ailleurs été assez critique envers RancherOS dans le post précédent… J’ai même découvert grâce à un des lecteurs que RancherOS allait tout simplement être abandonné dans les mois qui viennent…

A priori ce n’est pas le cas de RKE, mais on peut tout de même rester prudent ;-).

RKE, c’est quand même pas mal

Heureusement, cette partie s’est globalement mieux passée.

De base, j’ai tout de suite remarqué qu’il n’y avait pas de documentation officielle pour installer RKE sur des machines RancherOS. J’ai trouvé ça un peu étonnant (et même carrément inquiétant) mais vous allez voir au final que ça fonctionne.

Le code source de RKE est disponible sur Github à l’adresse suivante : github.com/rancher/rke

Comme je le disais plus haut, RKE est simplement un binaire (à l’instar de kubeadm), écrit en go.

On va donc, dans la majorité des cas, simplement le télécharger avec un bête cURL ou wget sur un de nos serveurs RancherOS (ou autre, du coup), à partir de la page des releases dans Github.

wget https://github.com/rancher/rke/releases/download/v1.2.3/rke_linux-amd64
mv rke_linux-amd64 rke
chmod +x rke
./rke --version

La dernière commande devrait vous renvoyer « rke version v1.2.3 » (ou celle que vous aurez installé).

Pour pouvoir s’installer sur tous les nœuds de votre cluster, vous vous doutez bien qu’il va falloir avoir un moyen de vous identifier sur ces nœuds en devenir.

J’ai donc généré une clé SSH via OpenSSL sur ma machine locale, et j’ai ajouté cette clé dans celles autorisées pour l’utilisateur rancher sur tous les membres du futur cluster.

openssl genrsa -out rancher.private.pem 2048
openssl rsa -in rancher.private.pem -outform PEM -pubout -out rancher.public.pem
ls -l
total 8
-rw------- 1 toto toto 1679 Aug 12 14:56 rancher.private.pem
-rw-r--r-- 1 toto toto 451 Aug 12 15:00 rancher.public.pem

Configuration du cluster

A partir de là, vous allez pouvoir commencer à décrire à RKE ce que vous souhaitez qu’il fasse.

Dans mon cas, j’avais juste sous la main qu’une seule machine RancherOS. J’ai donc déployé le « cluster » le plus trivial qui soit, un cluster à une seule machine avec tout dessus.

Rancher donne plusieurs exemples de configuration et dans mon cas j’ai utilisé celui-ci : rancher.com/docs/rke/latest/en/example-yamls/#minimal-cluster-yml-example

cat > cluster.yml << EOF
nodes:
- address: 192.168.1.14
user: rancher
role:
- controlplane
- etcd
- worker
ssh_key_path: /home/toto/rancher.private.pem
EOF

On voit donc que la configuration est assez simple et claire à comprendre. On liste nos nodes ainsi que leurs rôles dans ce cluster (ici controlplane, etcd, ET worker) et c’est tout.

Vous pouvez également générer un fichier de configuration via la ligne de commande suivante, qui vous posera plein de questions en lignes de commandes (TUI)

./rke config --name cluster-new.yml
[+] Cluster Level SSH Private Key Path [~/.ssh/id_rsa]: /home/toto/rancher.private.pem
[+] Number of Hosts [1]:
[+] SSH Address of host (1) [none]: 192.168.1.14
[+] SSH Port of host (1) [22]:
[+] SSH Private Key Path of host (192.168.1.14) [none]: /home/toto/rancher.private.pem
[+] SSH User of host (192.168.10.214) [ubuntu]: rancher
[...]

Maintenant qu’on a configuré notre cluster.yml (notre fichier de description du cluster) on le « bootstrape » avec un simple rke up :

./rke up
INFO[0000] Running RKE version: v1.2.3
INFO[0000] Initiating Kubernetes cluster
INFO[0000] [dialer] Setup tunnel for host [192.168.1.14]
INFO[0000] Checking if container [cluster-state-deployer] is running on host [192.168.1.14], try #1
[...]
NFO[0068] [ingress] Setting up nginx ingress controller
INFO[0068] [addons] Saving ConfigMap for addon rke-ingress-controller to Kubernetes
INFO[0068] [addons] Successfully saved ConfigMap for addon rke-ingress-controller to Kubernetes
INFO[0068] [addons] Executing deploy job rke-ingress-controller
INFO[0094] [ingress] ingress controller nginx deployed successfully
INFO[0094] [addons] Setting up user addons
INFO[0094] [addons] no user addons defined
INFO[0094] Finished building Kubernetes cluster successfully

A la fin du processus, vous devriez avoir un cluster Kubernetes « up and running » ainsi qu’un fichier cluster.rkestate ainsi qu’un fichier kube_config_cluster.yml dans le répertoire courant.

C’est ce dernier fichier qu’il faut utiliser pour se connecter à votre cluster en kubectl

kubectl --kubeconfig kube_config_cluster.yml get nodes
NAME STATUS ROLES AGE VERSION
192.168.1.14 Ready controlplane,etcd,worker 108d v1.19.4

Final thoughts

Si mon avis était très très mitigé sur RancherOS, je suis beaucoup plus satisfait par l’expérience (courte) que j’ai eue avec RKE.

L’outil ne révolutionne pas vraiment le déploiement de cluster Kubernetes et je ne pense pas que je vais rester sur cette stack RancherOS/RKE (c’était vraiment par curiosité pour le portfolio de Rancher).

Mais de ce que j’ai pu voir, c’est simple à utiliser, ça fonctionne plutôt bien (même sur RancherOS et c’est dire…).

La configuration par fichier YAML est agréable et très complète à la fois, et permet de planifier à l’avance ce qu’on veut faire avec les machines qu’on a. J’ai également testé une mise à jour de Kubernetes 1.18.5 vers 1.19.4 qui est très bien passée.

De ce que j’ai cru comprendre, il existe des synergies avec d’autres produits de Rancher (notamment Rancher lui-même), donc je pense qu’on peut dire que si vous êtes dans un écosystème Rancher, RKE est probablement un tool plutôt safe pour déployer vos clusters.

Dans le cas contraire, même si RKE semble une option totalement viable, je pense qu’il vaut tout de même mieux étudier d’autres solutions en parallèle. Elles seront potentiellement plus adaptées à votre contexte (AKS engine si vous louez du IaaS sur Azure, kubeadm ou kubespray pour du « on-prem », …).

Have fun :)

Kubernetes avec RancherOS et RKE – partie 1

Mon, 26 Oct 2020 07:45:00 +0000

RancherOS pour commencer

Pendant l’été, j’ai encore changé d’infra, avec un passage à un cluster Proxmox VE à 3 nœuds. Je reviendrais la dessus, mais la finalité c’est que j’ai eu (encore) l’envie de m’installer un petit cluster Kubernetes dans mes hyperviseurs.

Ceux qui me suivent depuis un moment savent que j’en ai déjà déployé des tonnes depuis le temps (k3s qui vient également de chez Rancher, mais aussi kubespray, kubeadm, aks, OVH, the hard way de kelsey hightower, …).

Du coup, plutôt que de gagner du temps et refaire quelque chose que je maîtrise déjà, je suis parti dans l’idée de tester quelque chose d’encore nouveau, deux produits de Rancher dont j’ai entendu parler : RancherOS + RKE !

L’idée dans cette première partie est de découvrir RancherOS, une des nombreuses solutions pour vos workload containerisés proposées par Rancher.

Mais c’est quoi RancherOS ?

RancherOS A lightweight, secure Linux distribution, built from containers to run containers well. RancherOS est donc un OS minimaliste contenant juste ce qu’il faut pour faire du Docker, configuré à l’aide de cloud-init et dans lequel la plupart des opérations de maintenances sont simplifiées. Quand je lis ça, je ne peux pas m’empêcher de repenser à CoreOS, qui faisait (fait) les mêmes promesses. N’ayant qu’installé et utilisé pendant peu de temps CoreOS, je ne serai pas capable de faire une comparaison des deux produits entre eux, mais la finalité est vraiment la même. Un point intéressant (je trouve) dans RancherOS est le fait que tous les services “techniques” nécessaires pour faire fonctionner correctement vos applications containerisés sont également des containers. RancherOS is the smallest, easiest way to run Docker in production. Every process in RancherOS is a container managed by Docker. This includes system services such as udev and syslog.

L’idée ici, c’est que tous ces services systèmes tournent dans un démon Docker séparé (pour plus de sécurité et éviter la suppression accidentelle).

Comment le déployer ?

Ça dépend. Et évidemment, ça dépend, ça dépasse.

Rancher a fait le choix (malin) de mettre le paquet pour faciliter le déploiement de leur RancherOS sur le plus de plateformes possibles.

Ainsi, vous retrouverez des processus de déploiement facilités pour la plupart des clouds providers public, mais aussi des images pour VMware, une image pour Rasberry Pi, Virtual Box ou Docker Machine. Il y a même de quoi booter en PXE pour ceux qui ont encore l’envie de faire ce genre de choses.

Dans mon cas, la seule solution à ma disposition pour KVM c’est d’utiliser l’ISO.

Première bonne nouvelle et première déconvenue

LA première bonne nouvelle, c’est qu’il existe un ISO tuné pour Proxmox VE, et ça c’est très cool.

Donc je DL l’ISO, créé une bête machine virtuelle sur mon cluster, dans lequel l’ISO est monté et roule ma poule ?

Ouais… presque !

You must boot with enough memory which you can refer to here.

Un point agaçant avec RancherOS est le minimum requirement en termes de mémoire. 1.25 Go pour un OS Linux soi-disant minimaliste (passé à 1 Go depuis la 1.5), la pilule a du mal à passer. Ok, je pinaille peut-être un peu, mais 1 Go c’est énorme quand on a prévu de lancer juste quelques petits containers comme des petits nginx ou des petits bouts de code python.

Il faut dire que Rancher nous a mal habitué avec k3s, leur Kubernetes modifié qui tourne avec quasiment pas de RAM au point de permettre de Kubernetes sur des RPi 1 ou en edge computing. Et là, avec 2 fois plus de RAM en requirement, j’ai que le démon Docker, même pas le kube qui va avec…

Du coup, le “RancherOS is the smallest, easiest way to run Docker in production”, bof…

Déployer en 5 minutes un cluster Kubernetes sur ARM avec k3s et Ansible

Rancher essaye de se raccrocher aux branches en vous linkant une doc permettant de construire soi-même une image custom nécessitant moins de RAM, mais bon… Le mal est fait, ils m’ont pas motivé à tester…

Déployer RancherOS sur Proxmox VE

Ok, assez discuté, maintenant on peut rentrer dans le vif du sujet. Sur notre hyperviseur préféré, on récupère l’ISO.

cd /var/lib/vz/template/iso
wget https://releases.rancher.com/os/latest/proxmoxve/rancheros.iso
--2020-08-10 15:00:26-- https://releases.rancher.com/os/latest/proxmoxve/rancheros.iso
Resolving releases.rancher.com (releases.rancher.com)... 104.26.12.240, 172.67.69.133, 104.26.13.240, ...
Connecting to releases.rancher.com (releases.rancher.com)|104.26.12.240|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 160432128 (153M) [application/x-iso9660-image]
Saving to: ‘rancheros.iso’
rancheros.iso 100%[===================>] 153.00M 42.3MB/s in 3.7s
2020-08-10 15:00:36 (40.9 MB/s) - ‘rancheros.iso’ saved [160432128/160432128]

La procédure d’installation officielle est disponible ici.

Grosso modo, on boot la VM, qui va configurer le serveur au minimum et permettre de se connecter avec l’utilisateur rancher sans mot de passe. L’idée est d’utiliser cet utilisateur pour finaliser l’installation avec ros install une fois la VM configurée.

The ros install` command orchestrates the installation from the rancher/os container. You will need to have already created a cloud-config file and found the target disk.

STOOOOOP

Si vous partez bille en tête comme moi et faites un ros install` sans lire la phrase en entier, vous vous retrouverez avec une VM sur laquelle vous ne pourrez pas vous loguer (voire sans réseau si vous n’avez pas de DHCP). C’est con.

The easiest way to log in is to pass a cloud-config.yml file containing your public SSH keys.

Cloud config

Ok, on va éviter de tous faire la même erreur. Voici maintenant le fameux prérequis, la documentation officielle qui parle de configuration/#cloud-config.

Si vous avez un doute sur certains paramètres, vous pouvez toujours utiliser la commande ros config` qui permet de récupérer les valeurs par défaut puis les setter.

On finalisera le tout en fusionnant la config actuelle avec un fichier YAML, ou alors on exportera la conf actuelle dans un autre fichier YAML.

Dans le cas d’un PoC, la plupart des valeurs qui vont nous intéresser sont simplement ce qui permet de setter l’IP et de configurer notre clé SSH pour pouvoir se connecter.

sudo ros config get rancher.network
dhcp_timeout: 0
dns:
nameservers: []
search: []
http_proxy: ""
https_proxy: ""
interfaces: {}
modem_networks: {}
no_proxy: ""
post_cmds: []
pre_cmds: []
wifi_networks: {}

Donc là, de base, bah ya rien.

Pourtant, si vous allez voir le fichier /var/lib/rancher/conf/cloud-config.yml, vous remarquerez qu’il y a pleeeeein de choses, plus ou moins utiles.

La page de doc qui nous intéressera donc dans ce cas est networking. Voici un exemple de commandes pour configurer une IP fixe (à remplacer par des valeurs qui ont du sens dans votre réseau, of course).

sudo ros config set rancher.network.interfaces.eth0.address 192.168.1.10/24
sudo ros config set rancher.network.interfaces.eth0.gateway 192.168.1.1
sudo ros config set rancher.network.interfaces.eth0.mtu 1500
sudo ros config set rancher.network.interfaces.eth0.dhcp false

A partir de ce moment là, vous avez accès au réseau depuis votre machine RancherOS, mais les modifications ne seront pas permanentes. On va donc exporter tout ça.

sudo ros config export
rancher:
environment:
EXTRA_CMDLINE: /init
network:
interfaces:
eth0:
address: 192.168.1.10/24
dhcp: false
gateway: 192.168.1.10
mtu: 1500
ssh_authorized_keys: []

Bon, et là vous voyez qu’il nous manque toujours la clé SSH.

Bonus clavier qwerty

Vous connaissez la différence entre un admin systèmes français débutant et un admin système français senior ?

If you call yourself a sysadmin and don’t know by heart the qwerty layout on an azerty keyboard, I just assume you are a junior.

(Pour ceux qui n’ont pas la blague, allez voir ce tweet de _oshell qui a bien backfired (lien mort) dans sa face)

Le senior, a force de bouffer des consoles à la con qui gèrent mal les différents layouts de claviers (parce que “hé, on s’en fout des gens qui ont pas de qwerty, on vient de la Silicon valley”), il connaît le qwerty par cœur.

Et ben là encore, ça n’a pas loupé. La console NoVNC de mon PVE, qui en plus n’avait le partage de presse-papier qui ne marchait pas.

Je veux bien être à l’aise en “blind qwerty sur azerty”, mais faut pas déconner, je suis pas senior au point d’être capable de copier une clé publique dans un YAML #trollface.

Donc pour ceux qui ne connaissent pas l’astuce, il est possible d’affecter temporairement un terminal série à votre VM de la façon suivante (voir doc Proxmox VE)

# qm set 100 -serial0 socket
update VM 100: -serial0 socket

A partir de là, vous devriez pouvoir accéder à un nouveau type de console dans Proxmox, qui devrait à la fois résoudre le problème de clavier qwerty ET le problème de presse-papier.

Cloud-config, suite

On récupère ce qu’on vient d’exporter et on ajoute notre clé comme nous le demande Rancher dans sa doc. Et avant de lancer l’install, on vérifie que notre cloud-config est valide

sudo ros config validate -i cloud-config.yml

Si la commande ne renvoie rien, c’est que c’est OK (pas super explicite mais bon why not). On passe donc à l’install :

sudo ros install -c cloud-config.yml -d /dev/sda
INFO[0000] No install type specified...defaulting to generic
Installing from rancher/os:v0.5.0
Continue [y/N]:
[...]
Continue with reboot [y/N]: y
INFO[0013] Rebooting

A partir de là, on peut (et on doit) se connecter en SSH sur la machine RancherOS (l’accès console n’est plus possible)

ssh -J proxmoxve rancher@192.168.1.10

Et si tout s’est bien passé, vous devriez pouvoir vous connecter !

Et maintenant, que vais-je fai-reuh ?

Ben déjà on peut regarder ce que RancherOS a activé comme “services” sur notre install Proxmox VE.

sudo ros service list
disabled amazon-ecs-agent
disabled container-cron
disabled open-iscsi
disabled zfs
disabled kernel-extras
disabled kernel-headers
disabled kernel-headers-system-docker
disabled open-vm-tools
disabled hyperv-vm-tools
enabled qemu-guest-agent
disabled rancher-server
disabled rancher-server-stable
disabled amazon-metadata
disabled volume-cifs
disabled volume-efs
disabled volume-nfs
disabled modem-manager
disabled waagent
disabled virtualbox-tools
disabled pingan-amc

Globalement, pas grand chose. La seule chose activée est le qemu-guest-agent, ce qui est utile puisque nous avons une effectivement une VM QEMU dans ce cas précis. Quant à vos containers Docker, vous pouvez vérifier qu’ils sont bien séparés des containers docker servant au fonctionnement de RancherOS avec les commandes suivantes :

Les containers “systèmes”

[rancher@rancher ~]$ sudo system-docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1e059e78c17e rancher/os-docker:19.03.11 "ros user-docker" 12 minutes ago Up 12 minutes docker
ba43a0648227 rancher/os-qemuguestagent:v2.8.1-2 "/usr/bin/ros entr..." 12 minutes ago Restarting (1) 34 seconds ago qemu-guest-agent
d9ad607221fa rancher/os-console:v1.5.6 "/usr/bin/ros entr..." 12 minutes ago Up 12 minutes console
ad0197c79ff2 rancher/os-base:v1.5.6 "/usr/bin/ros entr..." 12 minutes ago Up 12 minutes ntp
538ccf5eb624 rancher/os-base:v1.5.6 "/usr/bin/ros entr..." 12 minutes ago Up 12 minutes network
f389c6b0b40e rancher/os-base:v1.5.6 "/usr/bin/ros entr..." 12 minutes ago Up 12 minutes udev
b51deb379bf2 rancher/container-crontab:v0.4.0 "container-crontab" 12 minutes ago Up 12 minutes system-cron
59441adcc016 rancher/os-syslog:v1.5.6 "/usr/bin/entrypoi..." 13 minutes ago Up 12 minutes syslog
120df7cc2492 rancher/os-acpid:v1.5.6 "/usr/bin/ros entr..." 13 minutes ago Up 12 minutes acpid

Vos containers :

[rancher@rancher ~]$ docker container ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Les containers “systèmes” sont bien distincts des containers docker “utilisateurs”. La promesse d’isolation Docker infra vs Docker appli est bien tenue.

Mon avis

A voir à l’usage, mais je ne suis pas hyper convaincu.

D’abord, en termes d’OS minimalistes, on a quand même vu mieux. Et d’ailleurs, les gens chez Rancher le savent puisqu’ils se sentent obligés de s’en justifier…

Plus grave, l’UX est quand même super bof. J’ai l’habitude d’installer des softs mais je me suis quand même pris la tête avec le cloud-config assez moyennement documenté, et en plus, à faire DANS une console (et la galère QWERTY/AZERTY associée).

“Et c’est pas fini”, comme dis la pub.

Je vous l’ai dis, mon objectif est d’avoir un cluster Kubernetes installé par RKE. Or, il n’est pas trivial d’utiliser RancherOS comme OS pour hoster un Kubernetes déployé avec RKE. Vous verrez dans la partie 2 que ça n’a pas été une partie de plaisir…

Un comble pour 2 produits de la même boite censé vous simplifier l’administration de Docker/Kube…

Et plus grave encore, c’est que j’ai du mal à voir pour qui ce genre de distribs apporte de la valeur. C’est d’ailleurs pour cette même raison pour laquelle je n’avais pas poussé l’expérimentation très loin avec CoreOS. En tant qu’admin, je suis forcément frustré par un OS où je n’ai pas/peu la main.

J’aime bien ce qu’ils font chez Rancher. Mais je ne sais pas répondre à la question Pourquoi RancherOS ? On pourrait se dire que pour une équipe de développeurs en mode startup qui doit sortir son MVP en peu de temps, ça peut être cool.

Mais même là, j’ai des doutes.

Si ces gens là veulent VRAIMENT s’abstraire d’Ops (voir mon avis sur la question dans Au secours, le métier d’Ops va disparaître !), ils partiront sur d’autres types de technos (Kubernetes managé, Serverless, No code ?).

Si vous voyez une raison que j’aurais loupé, n’hésitez pas à venir en parler en commentaire ou via les RS, car là je vois pas…

En attendant la partie sur RKE, have fun :)

Déployer en 5 minutes un cluster Kubernetes sur ARM avec k3s et Ansible

Thu, 21 Mar 2019 13:00:14 +0000

C’est quoi k3s ?

Il y a quelques jours, vous avez peut être vu passer dans vos fil d’actus k3s, ce nouveau projet open sourcé par Rancher.

Lightweight Kubernetes. 5 less than k8s.

Il s’agit d’une version réduite de Kubernetes, sans pour autant être minimaliste, qui nous vante la possibilité de monter des clusters Kubernetes avec très peu de ressources nécessaires. On parle de moins de 512 Mo de RAM pour un master, encore moins pour un worker, tout dans un binaire de 40 Mo, support de armhf, et arm64, …

Great for Edge, IoT, CI, ARM, and situations where a PhD in k8s clusterology is infeasible

Cerise sur le gâteau, comme tout est regroupé dans un seul et même binaire, l’installation est ultra simple et se résume en :

Récupérer un binaire
Lancer le binaire sur le master
Lancer le binaire sur le worker avec l’URL du master et un token

Mais c’est génial !

Nécessairement, pour arriver à ça, il a fallut faire quelques concessions mais pour l’instant je ne les trouves pas très gênantes. Parmi les modifications notables, on retrouve :

Suppression des features alpha, legacy et non standard
Suppression de tous les add-on des cloud providers
Remplacement de etcd3 par sqlite3 (même si etcd3 peut être toujours être utilisé)

J’en veux un !

Autant dire que pas mal de bidouilleurs du dimanche se sont jetés dessus.

Le premier exemple qui vient à l’esprit est de monter un cluster Kubernetes sur Raspberry pi. Nombre de personnes ont déjà installé Docker sur un raspberry qui traînait dans un tiroir (moi compris), et le nombre d’articles avec Docker Swarm sur plusieurs Raspberry pullule sur le web.

Geekerie du week end : installer Docker sur un Raspberry Pi

Tout ça c’est très bien mais jusqu’à présent, il était difficile d’installer Kubernetes sur ce genre de machines, assez limités en CPU/RAM. Du coup, vous vous en doutez, je ne suis pas le premier à parler de ça.

Vincent RABAT aka itwars (que vous connaissez sûrement si vous écumez les meetups sur Bordeaux) m’a coiffé au poteau en releasant un playbook Ansible pour installer k3s, et notamment sur un Raspberry Pi (mais pas que).

A charge de revanche, Vincent ;-).

Un peu différent

Du coup, pour me démarquer, je vous propose aujourd’hui quelque chose d’un peu différent. N’ayant pas suffisament de raspberry sous la main, j’ai voulu faire un PoC de k3s en me basant sur des machines ARM créées chez un cloud provider.

L’idée étant que si ça marche sur des machines de faible puissance en ARM, ça marchera partout (x64, raspberry, etc).

Ça fait plusieurs fois que j’utilise Scaleway comme hébergeur pour des petits projets, et en particulier pour déployer rapidement des machines car leur API est pas trop mal fichues et surtout ils disposent de modules Ansible très bien fait, notamment avec la feature « inventaire dynamique », ce que beaucoup ne font pas.

Pour ceux que ça intéresse, mon talk sur BDX.IO était basé sur le même principe :

https://www.youtube.com/watch?v=WPRE1_f0pyg

Dans ce tuto, je vais donc vous montrer comment en quelque commande, monter un cluster k3s sur des machines ARM créées à la volée chez Scaleway, le tout avec Ansible (vous l’aurez compris).

Quelques prérequis

La première chose à faire est de cloner sur votre machine les playbooks Ansible que j’ai mis à disposition sur Github à l’adresse suivante : github.com/zwindler/ansible-scaleway-k3s

Pour réaliser ce tuto, je pars du principe que vous avec déjà un compte sur Scaleway, que vous avez un clé SSH qu’on déposera à la racine du projet, appelée admin.pub (c’est original).

Il faudra également installer les package pipy suivant sur la machine locale :

pip install jinja2 PyYAML paramiko cryptography packaging

Ensuite, vous devrez installer Ansible depuis les sources (>= 2.8devel) et éventuellement le binaire jq pour requêter dans les output JSON (ça c’est juste pour se faciliter la vie)

Dans la console Scaleway, vous devrez créer un token sur le site de Scaleway pour les accès distants et le stocker dans un fichier scaleway_token

export SCW_API_KEY='aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'

Et enfin sourcer le fichier pour avoir la variable dans votre environnement

source scaleway_token

OK, on est prêt

La première étape de cette procédure va être de générer des instances ARM pour héberger le master et le worker Kubernetes. Pour ça, le playbook Ansible create_arm_vms.yaml va :

récupérer l’ID d’organisation du compte Scaleway
récupérer un ID d’image compatible debian Stretch
ajouter si nécessaire la clé SSH de l’admin
créer autant de machines que nécessaire

On lance la commande suivante :

ansible-playbook create_arm_vms_scaleway.yml

ET C’EST TOUT !

Normalement en 2 minutes, vous devriez avoir 2 instances ARM sur le datacenter de Paris (par1).

A noter, il se peut qu’elles ne soient pas accessibles tout de suite en SSH. J’adapterai peut être le playbook pour qu’il ne rende pas la main tant que les machines ne sont pas accessibles, et qu’on enchaîne automatiquement sur l’étape suivante (TODO).

Inventaire automatique

Je le disais plus haut, la grande force de Scaleway avec Ansible est le fait qu’ils ont fait l’effort de coder l’inventaire dynamique. Vous n’avez pas besoin de renseigner à la main les IPs des instances que vous venez de créer dans un fichier ansible/hosts. Grâce à l’API, la découverte se fait automatiquement. On va dont pouvoir enchaîner sur la suite directement.

De base, voici le contenu de mon fichier d’inventaire (inventory.yml) :

plugin: scaleway
regions:
- par1
tags:
- k3smaster
- k3sworker

Maintenant que les machines sont UP, on peut vérifier ce que nous renvoie Scaleway avec la commande ansible-inventory. Ça devrait ressembler à ça :

ansible-inventory --list -i inventory.yml
{
"_meta": {
"hostvars": {
"x.x.x.x": {
"arch": "arm64",
"commercial_type": "ARM64-2GB",
"hostname": "k3smaster1",
[...]
"k3sworker": {
"hosts": [
"x.x.x.x",
"y.y.y.y",
"z.z.z.z"
]
}

SSH fingerprints

Une étape qui est souvent fastidieuse, surtout quand on ajoute beaucoup de serveur, est l’étape de vérification de l’empreinte SSH des nouveaux serveurs lors de la première connexion. Cette authentification est très importante et il n’est pas du tout conseillé (comme je le vois parfois) d’ajouter l’option ANSIBLE_HOST_KEY_CHECKING=False.

Ici, je vous propose de scanner automatiquement la première fois l’empreinte, et l’ajouter dans votre known_hosts. Ainsi, si l’empreinte change en cours de route, vous serez prévenus. Cependant, ce n’est à utiliser que dans le cas de notre bidouille, pas en production.

ansible-inventory --list -i inventory.yml | jq -r '.k3smaster.hosts | .[]' | xargs ssh-keyscan >> ~/.ssh/known_hosts
ansible-inventory --list -i inventory.yml | jq -r '.k3sworker.hosts | .[]' | xargs ssh-keyscan >> ~/.ssh/known_hosts

Vous pouvez maintenant ajouter votre clé SSH dans le ssh-agent, et vérifier qu’on vous pouvez vous connecter à tous les serveurs via Ansible :

eval `ssh-agent`
ssh-add myprivate.key

Préparation du serveur

C’était facile, non ?

Et bien la suite l’est encore plus, à l’exception de cette petite subtilité/piège => Il se trouve que l’image ARM par défaut proposée par Scaleway ne dispose ni de python ni de sudo. Pour faire du Ansible, c’est très très handicapant.

J’ai donc écris un petit playbook, à n’exécuter la première fois, qui installe les prérequis non présents sur l’image de base (python et sudo)

ansible-playbook -i inventory.yml -u root install_prerequisites_scaleway.yml

Si vous n’êtes pas sur ce genre de machines, vous n’aurez pas à faire cette étapes.

Maintenant qu’on a des machines avec python et sudo, on peut installer k3s normalement avec Ansible :

ansible-playbook -i inventory.yml -u root install_k3s_scaleway.yml

Une fois de plus : ET C’EST TOUT !

Le cluster est maintenant opérationnel. Les serveurs ont Kubernetes installé et fonctionnel. Le ou les workers ont rejoint le master et font parti d’un même cluster. Un Ingress controller Treafik est créé, on peut jouer dessus directement :-)

Bonus : accéder au cluster

Bon je vous ai un peu feinté.

Certes, on peut se connecter en SSH sur le master et le piloter avec les commandes kubectl classique (mais il faut rajouter k3s devant car le binaire kubectl est intégré à k3s). Mais c’est quand même plus simple si on peut y accéder à distance, depuis votre machine locale.

Là encore, j’ai donc fais un petit playbook qui va aspirer la configuration kubectl et la coller dans le fichier ~/.kube/config.k3smaster

ansible-playbook -i inventory.yml -u root configure_kubeconfig.yml

A partir de là, vous devriez pouvoir tester votre nouveau cluster depuis votre PC :-)

cd
kubectl --kubeconfig=.kube/config.k3smaster get nodes
NAME STATUS ROLES AGE VERSION
k3smaster1 Ready <none> 2d v1.13.3-k3s.6
k3sworker1 Ready <none> 2d v1.13.3-k3s.6

Enjoy !!!