Kubernetes avec RancherOS et RKE – partie 1

Posted by

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 maitrise 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…

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 mergeant 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 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 connait 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 :)


Vous aimez ce blog ? Partagez-le avec vos amis !   Twitter Facebook Linkedin email

Vous pouvez également soutenir le blog financièrement :
Tipeee

9 comments

  1. Pour comprendre les produits de la société Rancher, il faut se rappeler qu’elle a réalisé deux pivots majeurs : au début un orchestrateur monolithique concurrent de ECS / Mesos / Nomad, Rancher est devenu une surcouche de management agnostique de l’orchestrateur (supportant toujours son orchestrateur historique Cattle). En 2017, Rancher 2.x est un reboot Kubernetes-only, abandonnant le support des autres orchestrateurs.

    RancherOS est un reliquat de cette époque 1.x, preuve en est la présence de amazon-ecs-agent dans l’installation de base. Il suffit de regarder la fréquence de commit sur le repo pour se rendre compte qu’il n’est plus vraiment activement développé: https://github.com/rancher/os/graphs/contributors ; car la société mise plutôt sur k3sos pour les déploiements « légers » : https://rancher.com/blog/2019/announcing-k3os-kubernetes-operating-system/ . Malheureusement, Rancher semble réticent à marquer ces vieux projets « en fin de vie », probablement car ils vendent probablement encore des contrats de support dessus.

    Bien que l’idée de base (services système dans docker) soit séduisante, elle a un coût significatif. En effet, un démon Docker c’est lourd, deux (system docker + user docker) c’est deux fois plus lourd ! De plus Docker fait trop de choses par rapport au besoin de k8s, c’est pourquoi la partie « utile » a été extraite dans containerd (sur lequel Docker est maintenant basé).

    Pour répondre à ta question « Pourquoi RancherOS ? », je dirais:
    – en intégration verticale kernel->orchestrateur dans le cadre d’un contrat de support Rancher
    – en image de base commune pour supporter plusieurs orchestrateurs (ECS + Cattle + k8s), pour les clients ayant ce besoin (couvert par Rancher 1.x)
    – certainement pas en image de base pour un k8s léger
    – certainement pas pour du hobbyiste : le setup est complexe, mais le support Rancher fera le plus gros du boulot pour le client

    Je prends de l’avance sur ton post RKE, car j’ai bien peur que ce ne soit pas la réponse à ton problème non plus : la cible principale de Rancher est le grand compte qui doit gérer plusieurs milliers de machines k8s, ce qui implique de les répartir sur plusieurs clusters k8s (et de s’appuyer sur Rancher pour ne pas gérer manuellement chaque cluster). RKE est positionné pour répondre au besoin « dans mon datacenter » de ces clients, et sera bien trop lourd pour gérer trois machines.

    Bonne nouvelle, pour les petits déploiements Rancher a un produit : c’est k3s. En effet, il supporte désormais le multi-master pour déployer un « vrai » cluster. k8s est très lourd, et honnêtement un gros gâchis de RAM pour de petits clusters ; k3s enlève une majorité du « gras », mais sacrifie la scalabilité au passage.

    Si tu veux expérimenter de nouvelles solutions, l’orchestrateur le plus « élastique » avec lequel j’ai travaillé est Nomad, qui fonctionne de 1 à 5000 noeuds, et est notamment utilisé par CircleCI et Cloudflare. Mais il vient avec ses propres limitations, et un périmètre fonctionnel plus petit que k8s.

    1. Merci pour ce long et intéressant avis.

      Sur le fait que RancherOS (et RKE) ne soit pas pour moi (ou un hobbyist), on est bien d’accord !

      En fait, même si je le déploie chez moi, tout ce que j’expérimente est fait dans l’idée de ce que ça m’apporterait dans un contexte pro. Et je n’avais pas vraiment trouvé l’usage, par rapport à précédents et actuels contextes pro.

      Et du coup, effectivement, la vision de l »historique amène pas mal d’explications.

  2. Merci pour cet article et l’astuce de l’accès terminal série, pile-poil quand je remets au propre mon installation serveur !
    Je m’étais arraché les cheveux justement sur ce que tu as étais confronté (noVNC/qwerty/cloud-config/pas de DHCP) puis au final abandonné tant c’était laborieux.

  3. Heu yep, merci pour l’astuce du terminal série; je sens que ce va me servir quand j’aurais enfin reçu ma X570D4I-2T.

    A part ça, Je sais pas si tu connais K3D, c’est d’après ce que j’ai compris, l’équivalent de RKE mais pour K3S : https://k3d.io/ J’ai voulu tester il y a pas longtemps sur un raspberrypi 3B+ mais ca part en erreur
     » Failed waiting for log message ‘start worker processes’ from node »
    Je vais re tester tiens et créer une issue si nécessaire.

    1. Ahah oui c’est bien k3d mais j’ai déjà vu plusieurs personnes faire des articles dessus alors je voulais sortir un peu des sentiers battus

  4. Bonjour,
    Simple question, est il possible d’utiliser le périphérique cloud-init embarqué dans proxmox pour enregistrer la configuration de la VM ?
    Si c’est le cas, le déploiement avec terraform est le plugin community proxmox pourrais se révéler très sympa.

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.