Scaleway on Zwindler's Reflection

CIVO : du kubernetes managé à partir de 4$/mois, vraiment ?

Fri, 16 Jul 2021 07:00:00 +0000

Pendant la Kubecon EU 2021, un provider que je ne connaissais pas a mis le paquet pour s’assurer de la visibilité : CIVO. Et avec une promesse plus qu’alléchante : un Kubernetes managé basé sur k3s (que j’adore) et avec un tarif à partir de 4$/mois !

Chez les concurrents, on a rien sous les 15€ / mois (Scaleway), quand ce n’est pas 30 voire 80… De quoi piquer ma curiosité donc.

Un de plus ?

J’ai donc pris un compte d’essai proposé par l’entreprise aux participants de la Kubecon et j’ai créé un compte.

La première chose que j’ai testé, c’est l’interface (il y a aussi une CLI). Forcément, chez un pure player, c’est simple et efficace, on s’y retrouve et l’interface est léchée. On est loin du gloubiboulga visuel de chez Azure (cf mon test d’AKS). Après, c’est un minimum… c’est forcément plus simple quand on commence de zéro et qu’on a pas des centaines de produits ;-p.

On a un dashboard avec les opérations réalisées chronologiquement, un menu pour créer des clusters kube, un menu pour créer du compute et des LB « nus ». Rien de bien révolutionnaire, ça fait le job.

La partie « KubeQuest », c’est de la bête gamification (« Créez un cluster pour passer niveau 2!!! »), je ne m’y attarderai même pas.

Bon, on le créé ce cluster à 4$ ?

Bon, ne vous enflammez pas, l’offre « à partir de 4$/mois » ne sera pas utilisable en prod, pas de miracle. Mais c’est déjà un tour de force qu’ils arrivent à le proposer, notamment grâce à k3s.

Pas de surprise, le pricing des nodes est immédiatement affiché, et voilà à quoi ça ressemble :

Pour 4$ par mois, on vous propose un « cluster » d’un seul node, avec seulement 1 vCPU et 1 Go de RAM. Pas de quoi faire tourner grand chose d’autre que quelques containers nginx… Si ça jamais ça fonctionne ?! (on y reviendra)

Au delà, les prix sont similaires à ce que l’on trouve sur le marché « bon marché » (Scaleway notamment). Si on veut être un peu sérieux et comparer ce qui est comparable, on peut booter des machines avec 2vCPU et 4 Go de RAM à16$/mois l’unité (moins de ~13,5€ en ce moment).

Kubernetes easy to install

La plupart des offres managées de Kubernetes (si ce n’est toutes) viennent avec une certaine quantité de personnalisation préinstallée. Chez Azure, vous pouvez choisir parti 2 CNIs et le dashboard (ou pas). Chez Scaleway si c’est Calico qui est préinstallé ou pas.

Chez CIVO, ils ont poussé le concept beaucoup plus loin, en reprenant l’idée de Rancher ou d’Openshift du « marketplace ».

Avant de boostraper votre cluster, vous avez accès à tout un magasin d’applications (ni plus ni moins que des charts helm avec une icône pour cliquer dessus) et éventuellement une très petite personnalisation avec un dropdown menu (mais vraiment trivial, très peu de choix).

Et là, pour le coup en terme d’UX je trouve ça très très malin. En quelques clics, j’ai (dé)sélectionné les composants qui m’intéressent et ils ont été préinstallés pour moi avec mon cluster.

On peut même préinstaller des produits de sécurité, notamment Kyverno avec un ensemble de règles de sécurité préconfigurées.

Et c’est pas fini !

Pour ce qui est des composants d’infrastructure, je comprend l’incentive. Pour certains devs, l’infra c’est ch***t.

Mon cluster je le veux up and running sans perte de temps, sans pour autant que mes données soient à poil sur Internet

Mais comme tout ce qui « cache » la complexité du métier d’Ops (cf mon article « Au secours, le métier d’Ops va disparaître »), la difficulté n’est pas tant le déploiement que le « day 2 operations ». Et si vous voulez modifier un paramètre, vous êtes marrons.

Tout de même, préconfigurer cette partie dès le bootstrap du cluster est malin. Et ce qui est encore plus malin, c’est qu’ils ont open sourcé leur marketplace.

Qu’est ce qu’ils y gagnent, me direz vous ?

Et bien, s’il y a un nouveau « shiny composant » qui fait rêver tout le monde, vous pouvez aller faire une PR pour ajouter une tuile dans l’UI de CIVO. Comme ça vous bossez pour eux. Elle est pas belle la vie ? ;-p (je troll, mais je trouve ça cool, en vrai).

Et le cluster, il boote vite ?

C’est un peu la guéguerre entre Kubernetes managés à qui bootstrappera le control plane et les workers le plus vite. Azure met plus de 20 minutes. OVH bootstrappe le control plane en une minute mais met des plombes à sortir les VMs à cause de leur OpenStack. Exoscale fait le tout (control plane + workers) en moins de 2 minutes.

CIVO nous promet 90 secondes et c’était pas loin d’être vrai. Je ne dirai pas que c’est les plus rapides mais ils sont dans le top 3 de tous les kubes managés que j’ai pu tester, sans hésiter.

Une fois le cluster opérationnel, on vous propose évidemment de télécharger votre kubeconfig et roule ma poule

Mais qu’est ce qu’on peut faire tourner dans Kube avec 1 (ou 4) Go de RAM ?

Le souci avec ce genre de « petites machines », c’est que si vous n’avez pas OS et kubernetes optimisés, une part non négligeable de la VM ne sera pas utilisable pour vos workloads et vous n’aurez que (dans le pire des cas) 2 Go de libre.

Et c’est là toute la « malinerie » d’utiliser k3s plutôt qu’un k8s vanilla. k3s est spécialement pensé pour tourner sur des petites machines (en edge notamment). J’avais pu installer un master kubernetes sur un raspberry pi 1 (model B, 1 CPU ridicule et 512 Mo de RAM) tellement l’empreinte mémoire demandée est faible.

Associé à un magasin d’applications maison pré-tuné pour consommer peu (très petites requests pour fit les petites machines sans tout bloquer), on arrive avec des nodes quasiment sans overhead. Dans cet exemple, j’ai cliqué sur plusieurs composants (cert-manager, kyverno, ha-proxy, prometheus+alertmanager+grafana, metrics-server, falco). Je me retrouve avec des nodes (4vCPU 8Go) quasiment vides !

kubectl --kubeconfig civo-zwindler-kubeconfig top nodes
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
k3s-zwindler-deadbeef-node-pool-31af 230m 5% 945Mi 12%
k3s-zwindler-deadbeef-node-pool-6609 97m 2% 471Mi 6%
k3s-zwindler-deadbeef-node-pool-e07c 141m 3% 874Mi 11%

Du coup, pour du lab perso ou des workloads qui nécessitent très peu de puissance, l’offre de CIVO est plutôt bien positionnée. Je ne suis pas complètement convaincu de l’intérêt de l’offre extra small à 4$ qui est plus là pour la prouesse technique qu’une réelle utilisation. Mais dès small ou medium, on a un service qui fonctionne, moins cher que de nombreux concurrents et surtout bien plus optimisé en terme de ratio overhead/puissance totale.

Au delà de kubernetes, l’offre est quasiment inexistante. Des VMs (plus chères que les workers kubes !!! wtf) et des loadbalancer à 10$/mois (Scaleway le fait à 8€, on est dans les prix « pas cher ») et c’est tout…

Autant dire que c’est kubernetes ou rien. Du coup, est ce qu’il y a un marché pour ce besoin, je ne suis pas certain… mais pourquoi pas ? En tout cas, bonne surprise !

Le blog en IPv6 : ça aurait du être simple et pourtant…

Mon, 01 Mar 2021 07:15:00 +0000

C’est l’histoire d’un collègue de boulot

C’est l’histoire d’un collègue de boulot, qui me dit :

Dis donc zwindler, avec toute la veille que tu fais sur ton blog, comment se fait-il qu’il ne soit toujours pas accessible en IPv6 !?

Damned… Il a raison le bougre !

Mauvaise réponse : par flemme.

Encore plus mauvaise réponse : parce que ce n’est pas aussi trivial à implémenter que ça devrait l’être…

Allez, je vous embarque !

D’abord mon infra…

J’vais sauter tout de suite le topo comme quoi IPv6 c’est important et surtout là depuis quasiment 25 ans, que IPv4 est dead depuis un an ou deux, qu’IPv6 c’est pas compliqué en vrai (la partie théorique j’entends ; la pratique on va en parler). De toute façon, les tweets récents de @davlgd me laissent à penser qu’un article sur NextInpact devrait sortir à ce sujet dans peu de temps ;-).

J’ai changé une énième fois d’infra pour mes besoins persos et me retrouve maintenant avec un serveur hébergé à la maison pour le gros de mes besoins perso, ainsi que deux machines plus modestes (des Atom 2 cœurs, 4 Go) que je loue pour une bouchée de pain pour avoir un cluster Proxmox VE et des réplications ZFS.

(Oui je ferai un article pour en parler… promis… un jour… peut être).

On commence déjà pas super bien : mon opérateur Internet ne me propose pas d’IPv6. Impossible donc de proposer mon blog en IPv6 si je l’héberge depuis chez moi.

Ça tombe bien (sort of), j’ai préféré le laisser sur une des deux machines Atom que je loue, qui suffisent vu le peu de charge que représente le blog. Je pars du principe que les hébergeurs ont de meilleurs taux de dispos que ma maison bourrée de SPOF. L’histoire ne me donne pas forcément raison, mais passons.

OneProvider

Est-ce que ces machines peuvent être en IPv6 ?

Je me suis pris la tête avec le support de OneProvider à plusieurs reprises, mais punaise, ils sont tellement peu chers… J’avais dit « plus jamais ! », mais des Atom à 6€ / mois pour 4 Go de RAM et un stockage correct… C’est quasiment impossible de trouver mieux.

Si on se contente de regarder ce qu’on a pour ce prix là, « la question elle est vite répondue ». Il n’y a pas d’IPv6 dans l’interface et on ne peut pas en commander. On est cuit…

Plot twist

Bon ben voilà, pas de solution, fin de l’article.

…

… Mais non !

Car quand on connait un peu les machines à Paris et à Amsterdam de OneProvider, on sait que ce sont en fait des serveurs de chez Online (Scaleway), vendus en marque blanche.

Et là l’espoir renait car Online ne le met pas en avant sur son site directement, mais dans le wiki il est dit que

La totalité des réseaux Online/Dedibox est compatible IPv6, et les futurs déploiements auront également de l’IPv6 par défaut. https://documentation.online.net/fr/dedicated-server/network/ipv6/start

Un petit mail au support

Je prends mon courage à deux mains et j’écris au support, en espérant que ça ne finisse pas comme les fois précédentes à les engueuler comme du poisson pourri, car ils m’ont dit que « oui oui c’est possible » et finalement me la mette à l’envers avec des options payantes qui ne me servent à rien et qu’on ne peut pas annuler…

Bonne surprise, cette fois-ci :

OK. On peut donc avoir un bloc en IPv6 (un /64 alors que c’est un /56 chez Online, mais on ne va pas faire les fines bouches) tout en gardant l’IPv4 (j’ai préféré leur demander confirmation, connaissant les zozos).

Les seules difficultés sont donc que l’IP doit être assignée avec un client DHCP (mkay) et qu’on ne peut pas faire de rDNS. Dans mon cas, juste pour que le blog soit en IPv6, c’est suffisant.

Une fois que j’ai indiqué que c’était bon pour moi, le support m’a rapidement envoyé un /64 ainsi qu’un DUID pour le DHCP.

La configuration du DHCP

A partir de là, le « fun » a pu commencer.

D’abord, il a fallu trouver comment configurer dhclient pour chopper correctement mon IPv6. Heureusement on trouve assez vite de l’aide sur le net, notamment sur le wiki d’Online (et ça tombe bien vu que je suis chez eux).

documentation.online.net/en/dedicated-server/network/ipv6/prefix

Long story short; sur des distribs récentes (notamment Proxmox), le plus « simple » est de créer un service systemd qui se lancera au démarrage juste après le réseau

cat > /etc/systemd/system/dhclient.service << EOF
[Unit]
Description=dhclient for sending DUID IPv6
After=network-online.target
Wants=network-online.target
[Service]
Restart=always
RestartSec=10
Type=forking
ExecStart=/sbin/dhclient -cf /etc/dhcp/dhclient6.conf -6 -P -v vmbr0
ExecStop=/sbin/dhclient -x -pf /var/run/dhclient6.pid
[Install]
WantedBy=network.target
EOF
cat /etc/dhcp/dhclient6.conf
interface "vmbr0" {
send dhcp6.client-id VOTRE:DUID;
request;
}

Vous remarquerez peut-être que, contrairement à l’article du wiki d’Online, je n’utilise pas l’interface réseau physique (enp0s20 dans mon cas) mais un bridge (vmbr0). En fait, on a pas trop le choix (sauf si j’ai mal compris), car on va « brancher » nos VMs sur un bridge pour leur affecter des IPv6 et je n’ai pas réussi à faire marcher ça lorsque l’interface qui porte le /64 n’était pas aussi le bridge. Si vous avez mieux, je prend les suggestions.

La « blague » dans l’histoire, c’est que je n’utilise pas du tout cette configuration réseau dans laquelle l’IP de l’hyperviseur est portée par un bridge pour la partie IPv4 (moi j’utilise ça).

Deuxième blague, impossible de faire marcher ça avec un bridge open-vswich ce qui est pourtant vachement plus fun, notamment pour la possibilité d’ajouter des liens GRE entre nodes et ainsi avoir un LAN virtuel unifié dans tout le cluster.

J’ai donc dû REFAIRE tout mon fichier /etc/network/interfaces…

Le réseau, du coup

J’ai suivi sans succès plusieurs tutos (dont celui-ci, celui-là et celui-là). Le dernier était pourtant particulièrement prometteur puisque utilisant à la fois Online et Proxmox… mais rien n’y a fait. Je me suis coupé la patte un nombre incalculable de fois…

trolololololo lololo lololooooo<

cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto enp0s20
iface enp0s20 inet manual
auto vmbr0
iface vmbr0 inet static
address VOTRE.IP.V.4/24
gateway GATEWAY.IP.V.4
bridge-ports enp0s20
bridge-stp off
bridge-fd 0
iface vmbr0 inet6 static
address VOTRE:IP:V:6::1/64
#ONLINE.NET specific throttling
post-up ip6tables -A OUTPUT -p udp --dport 547 -m limit --limit 10/min --limit-burst 5 -j ACCEPT
post-up ip6tables -A OUTPUT -p udp --dport 547 -j DROP
allow-ovs vmbr1
iface vmbr1 inet static
... blablabla
#La partie masquerading sur un Open vSwitch comme indiquée dans https://pve.proxmox.com/wiki/Network_Configuration#_masquerading_nat_with_tt_span_class_monospaced_iptables_span_tt

On se retrouve avec un genre de monstre de Frankenstein avec une carte enp0s20 attaché à un bridge (vmbr0) qui sert aussi de bridge pour nos containers IPv6, et d’un bridge (vmbr1) open vswitch pour ce qui reste en v4 et les communications inter-nodes.

Gavé bien !

Notez les iptables v6 en « post-up » dans la partie v6 du vmbr0.

#ONLINE.NET specific throttling
post-up ip6tables -A OUTPUT -p udp --dport 547 -m limit --limit 10/min --limit-burst 5 -j ACCEPT
post-up ip6tables -A OUTPUT -p udp --dport 547 -j DROP

D’expérience, ça ne sert à rien. Mais c’est conseillé par Online dans son wiki sur IPv6. Personnellement je n’ai vu aucun impact positif en ajoutant ces lignes.

Et ça marche maintenant ?

Ben non, bien sûr. Il va falloir modifier quelques options dans sysctl (notamment le forwarding pour IPv6)

vi /etc/sysctl.conf
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.all.proxy_ndp = 1
net.ipv6.conf.default.proxy_ndp = 1

Sur les recommandations du wiki d’Online (IPv6 SLAAC), j’ai rajouté les paramètres suivants :

#Online specific (SLAAC)
net.ipv6.conf.vmbr0.autoconf = 0
net.ipv6.conf.vmbr0.accept_ra = 2

Pas sûr que ce soit très efficace, j’ai vu d’autres procédures mettre accept_ra à 1. Je vous laisse tester les deux.

Mais ça ne suffit pas, parce que quelqu’un (pas trop sûr de qui) a décidé de rajouter des paramètres par défaut qui bloquent l’IPv6 sur ces serveurs. Malin !

J’ai été sauvé par ce Gist de DonSYS91 (MERCI !) qui indique une partie des pièces manquantes à mon puzzle.

D’abord dans /etc/modprobe.d/local.conf, il y a une ligne ipv6 disable à 1, qu’il faut passer à 0… Si vous ne changez pas cette valeur, peu importe ce que vous mettrez dans votre sysctl.conf, IPv6 sera systématiquement désactivé au boot !

cat /etc/modprobe.d/local.conf
# Local module settings
# Created by the Debian installer
options ipv6 disable=0

Après reboot, tout fonctionne. Je ping bien (avec ping6) des serveurs IPv6 only et j’ai pu affecter des IPv6 à mes containers LXC.

CA M’A PAS DU TOUT DÉTENDU CETTE HISTOIRE D’IPV6 !

Et encore, j’ai même pas de DNS IPv6 car OVH ne sait pas le faire sur leurs DNS !

Ni du fait que dans certains cas, 90% des requêtes sont perdues, mais uniquement sur les DC2/DC3 d’Online à Paris, ce que confirment a priori plusieurs personnes qui font aussi de l’IPv6 sur des machines hostées chez Online…

And that’s what we call « flapping »

Mais je m’en fous, le blog est accessible en IPv6.

Ma plateforme de travail collaboratif Nextcloud en 5 minutes

Mon, 27 Apr 2020 06:45:00 +0000

C’est quoi Nextcloud ?

Par où commencer ? Nextcloud, c’est tellement de choses ;-)

Historiquement, Nextcloud est un fork du projet Owncloud, qui visait à fournir un service en ligne de stockage de fichier via une interface web. Un peu comme Dropbox, mais hébergé par vous, chez vous, et donc respectueux de votre vie privée !

Mais aujourd’hui, Nextcloud c’est bien plus que ça. C’est une véritable plateforme de travail collaboratif avec certes un service de gestion, de partage et de synchronisation de fichiers entre plusieurs devices/utilisateurs, mais aussi un serveur libreoffice/collabora de l’édition de fichiers collaboratifs (Office 365/Google Docs), un serveur Talk (visioconférence), calendrier, gestion de notes et bien plus encore.

La solution s’est même nettement étoffée depuis la version 18 qui vient de sortir, avec de très nombreuses extensions.

Pourquoi attendre si longtemps pour en parler ?

La première fois que j’ai testé Owncloud, c’était en 2014 lorsque j’ai créé (sans succès) une entreprise d’infogérence spécialisée dans les outils open source. Le but était de fournir, entre autre, un service autohébergé pour justement remplacer Dropbox. Cette annecdote fera peut être sourire certains de mes lecteurs, très impliqués dans Nextcloud :-p.

A l’époque, je n’avais pas du tout aimé Owncloud, que j’avais trouvé moyen en terme d’ergonomie, très lent, etc.

Récemment cependant, Nextcloud a gagné beaucoup de traction et c’est tant mieux, car ça m’a forcé à rester l’outil, qui a vraiment évolué pour le mieux.

Et comment on va faire pour le déployer si vite ?

Ahah ! En voilà une bonne question… Grosse surprise, on va déployer tout ça avec un playbook, bien sûr !

Pour ceux qui ne savent pas, à chaque fois que j’installe un soft, j’automatise ça avec ansible, car j’automatise TOUT avec ansible.

Je vous met à disposition sur Github cet ensemble de playbooks qui vous permettront d’installer un serveur Nextcloud de A à Z en partant d’un serveur Ubuntu 18.04 sur lequel vous avez un accès SSH.

Et pour ceux qui n’ont pas de serveur à disposition, je vous ai également mis un playbook permettant de déployer une machine sur le cloud provider français Scaleway.

Pourquoi Scaleway ? Pas parce que j’ai le moindre partenariat avec eux (pas pour l’instant en tout cas), mais parce :

ils sont français
ils ont une super API et des modules Ansible qui marchent très très bien (j’ai même fais un live coding avec) avec l’inventaire ansible dynamique (ce que d’autres n’ont pas forcément)
ils proposent des instances à moins de 4€ par mois, payable à l’heure, ce qui est parfait pour des petits tests

Mais n’importe quelle autre machine sous Ubuntu 18.04 fera l’affaire !

Créer une VM sur Scaleway

Je ne détaillerai pas l’instanciation de la VM sur Scaleway si vous choisissez cette option, car tout est expliqué en détail sur le README.md du dépôt Github. J’ai également abondamment parlé de ce sujet à l’occasion d’autres articles

Préparer l’installation de Nextcloud

Avant de pouvoir installer Nextcloud sur notre nouveau serveur Ubuntu 18.04 tout neuf, il est important de choisir un nom de domaine pour notre futur service Nextcloud. Ajoutez un CNAME permettant de mapper ce nom de domaine sur l’adresse IP de votre machine virtuelle Ubuntu.

Maintenant que le serveur Ubuntu 18.04 est disponible et que le futur service est résolvable, on dispose de 2 méthodes pour installer Nextcloud. Soit on lance le playbook ansible en local sur la machine Nextcloud, soit on l’installe à distance via ansible.

Si on le lance en local

Récupérer le repository zwindler/ansible-nextcloud directement sur le serveur via un git clone. Nous utiliserons le paramètre “-i hosts_local” quand on exécutera ansible-playbook.

Si on a généré une VM avec Scaleway

Dans ce cas, on profitera de la fonctionnalité d’inventaire dynamique fournie par Scaleway. Nous utiliserons le paramètre “-i dynamic_inventory.yml” quand on exécutera ansible-playbook.

Si vous voulez installer à distance

Il sera nécessaire de pouvoir se connecter en SSH à la machine distante mais aussi de générer un inventaire pour qu’ansible sache sur quel machine il doit se connecter. Pour le faire on créera un fichier texte avec l’IP du serveur distant, et nous utiliserons “-i hosts_distant” quand on exécutera ansible-playbook.

echo "IP_of_the_server" > hosts_distant

Installer Nextcloud

En partant du principe que vous avez utilisé la méthode Scaleway avec l’inventaire dynamique, voilà ce que vous devrez faire :

ansible-playbook -i dynamic_inventory.yml -u root nextcloud_install.yml

Le playbook vous promptera pour renseigner un certain nombre de variables qui correspondent à votre installation :

MariaDB root password: awesome_mariadb_password
Nextcloud MariaDB password: awesome_mariadb_user_password
Your domain: example.org
Nextcloud HTTPS port [8443]: 443
Nextcloud instance name (URL will be https://thisvalue.example.org) [nextcloud]: nextcloudscw

A l’issue du playbook, vous devriez pouvoir vous connecter sur votre instance pour finaliser l’installation. Lorsque vous vous connecterez pour la première fois, vous tomberez sur un écran qui vous demandera une partie des informations rentrées préalablement

Et la sécurité ?

Et oui, la sécurité pour un outil aussi sensible que vos documents, c’est important.

Heureusement, Nextcloud est un outil bien packagé et un projet pour lequel la sécurité est au cœur du développement.

Nextcloud met à disposition un scan de sécurité (scan.nextcloud.com) qui vous permettra de vous tester contre un certain nombre d’attaques connues.

Comme vous pouvez le voir, ça se passe plutôt bien ;-)

De même, la configuration nginx (le frontal de notre serveur) coté TLS est elle aussi sécurisée. Par défaut, je désactive TLS 1.0 et 1.1, ce qui peut poser des soucis pour les plus vieux appareil mais permet d’obtenir un joli A+ chez SSL Labs

Dans le cas où vous souhaiteriez les réactiver, c’est possible (il y a un flag dans le playbook) mais dans ce cas là la note sera rétrogradée à B.

Et c’est fini ! 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 !!!