RKE on Zwindler's Reflection

RKE, Talos Linux, ... : MountVolume.NewMounter initialization failed for volume : path does not exist

Thu, 26 Sep 2024 20:00:00 +0200

Tout a commencé…

Sans trop dévoiler de mon nouveau travail, je bosse sur une plateforme Kubernetes que nous gérons nous-même avec du Talos Linux (un OS Kubernetes immutable pas piqué des hannetons !).

La plateforme est encore assez jeune, et sur mon environnement de développement, j’ai de quoi faire des buckets S3 mais pas de PVC avec du stockage de type “block”. J’aurais pu monter un rook à la méthode RACHE.

Mais que voulez-vous… Par acquit de conscience pro (aka la grosse flemme de l’espace), et pour m’économiser 4 secondes et demi de requête à Google/ChatGPT, je demande à un collègue s’il a pas un petit bout de YAML pour monter un petit PVC à l’aide d’un hostPath vitef.

cf kubernetes.io/docs/concepts/storage/storage-classes/#local

Ca commence mal

Bon déjà, si vous essayer de jouer ce manifest, ça ne va pas fonctionner. En effet, ce que la doc officielle ne dit pas (pas dans la page sur les storage classes en tout cas), c’est que le provisioner Local kubernetes.io/no-provisioner ne peut pas créer de PV si vous ne spécifiez pas d’affinité (nodeAffinity).

% kubectl apply -f toto.yaml
storageclass.storage.k8s.io/pour-la-science-sc created
The PersistentVolume "pour-la-science-pv" is invalid: spec.nodeAffinity: Required value: Local volume requires node affinity

Ça se corrige facilement :

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: pour-la-science-sc
provisioner: kubernetes.io/no-provisioner
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolume
metadata:
 name: pour-la-science-pv
spec:
 accessModes:
 - ReadWriteOnce
 capacity:
 storage: 10Gi
 local:
 path: /opt/tempDir
 storageClassName: pour-la-science-sc
 nodeAffinity:
 required:
 nodeSelectorTerms:
 - matchExpressions:
 - key: kubernetes.io/hostname
 operator: In
 values:
 - worker-1

À partir de là, ça fonctionne (sur le papier). Une fois les manifests créés, vous devriez avoir une storage class et un PV, prêt à être utilisé. On peut même aller un cran plus loin et créer le PVC et le bind au PV.

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pour-la-science-pvc
 namespace: default
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 10Gi
 storageClassName: pour-la-science-sc

Fin de l’article ?

kubectl apply -f toto.yaml
storageclass.storage.k8s.io/pour-la-science-sc unchanged
persistentvolume/pour-la-science-pv created
persistentvolumeclaim/pour-la-science-pvc created

Non, bien sûr…

Cours, pod ! Couuuuuurs !

Lançons donc un petit Pod de debug pour voir si on arrive à monter notre PVC dans un container :

---
apiVersion: v1
kind: Pod
metadata:
 name: ubuntu-pvc
spec:
 containers:
 - name: ubuntu
 image: ubuntu:latest
 command: ["/bin/bash", "-c", "sleep 3600"]
 volumeMounts:
 - name: storage
 mountPath: /toto
 volumes:
 - name: storage
 persistentVolumeClaim:
 claimName: pour-la-science-pvc
 restartPolicy: Never

Ici, pas besoin de spécifier l’affinity qu’il faut que le Pod se schedule sur le worker-1 (là où se trouve le PV). Le scheduler de Kubernetes est assez intelligent pour le retrouver tout seul.

% kubectl apply -f toto2.yaml
pod/ubuntu-pvc created

Et là, c’est le drame. Le Pod reste bloqué en ContainerCreating !!

% kubectl get pods
NAME READY STATUS RESTARTS AGE
ubuntu 0/1 ContainerCreating 0 52s

% kubectl get events
LAST SEEN TYPE REASON OBJECT MESSAGE
4m6s Warning ProvisioningFailed persistentvolumeclaim/pour-la-science-pvc storageclass.storage.k8s.io "pour-la-science-pv" not found
100s Normal WaitForFirstConsumer persistentvolumeclaim/pour-la-science-pvc waiting for first consumer to be created before binding
88s Normal Scheduled pod/ubuntu-pvc Successfully assigned default/ubuntu to worker-1
25s Warning FailedMount pod/ubuntu-pvc MountVolume.NewMounter initialization failed for volume "pour-la-science-pv" : path "/opt/tempDir" does not exist

Hum… ok, path "/opt/tempDir" does not exist, c’est relativement explicite comme erreur. J’ai oublié de créer le dossier sur le host en question.

Je vais créer un nouveau Pod qui lui va monter le /opt de l’hôte dans /mnt/opt, et créer le dossier à la main (souvenez-vous, méthode RACHE) :

---
apiVersion: v1
kind: Pod
metadata:
 name: ubuntu-hostpath
 namespace: somespecialnamespace
spec:
 containers:
 - name: ubuntu
 image: ubuntu:latest
 command: ["/bin/bash", "-c", "sleep 3600"]
 volumeMounts:
 - mountPath: /host/opt
 name: host
 securityContext:
 privileged: true
 volumes:
 - name: mnt
 hostPath:
 path: /host
 type: Directory
 restartPolicy: Never
 affinity:
 nodeAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 nodeSelectorTerms:
 - matchExpressions:
 - key: kubernetes.io/hostname
 operator: In
 values:
 - worker-1

Note : les PodSecurity de Talos m’empêchent de créer le Pod (hostPath & priviledge) si je ne le créé pas dans un namespace disposant d’exceptions.

% kubectl exec -it -n somespecialnamespace pods/ubuntu-hostpath -- /bin/bash
root@ubuntu-hostpath:/# mkdir /host/opt/tempDir/
[control] + d
exit
command terminated with exit code 1

C’est bon maintenant ?

Répertoire : créé. Mission accomplie, right ? Right ?

Et ben non !! Le Pod est toujours bloqué.

Pourquoi diantre je peux voir ce dossier dans mon Pod ubuntu-hostpath, mais pas dans ubuntu-pvc, qui monte le même dossier, mais via un PVC ???

La raison, c’est… Parce que c’est un PVC.

Bon ok, d’accord. Ce n’est pas JUSTE parce que d’un côté, je passe par un hostpath et de l’autre par un PVC.

Les plus astucieux/astucieuses d’entre vous se seront surement douté qu’il y a un rapport avec le titre de mon article. Le problème est le même sur RKE, Talos Linux et surement d’autres OS similaires.

Ces OS ont la particularité d’être des “Container OS”. Les composants de kubernetes ne sont pas “installés” à proprement parlé dans l’OS, mais lancé dans des containers. L’OS n’est en fait qu’une grosse coquille vide avec juste de quoi lancer des containers. Ça limite la surface d’attaque et ça les rend plutôt légers.

Et il y a une différence fondamentale entre la façon dont est géré “un Pod avec hostPath” et “un pod qui monte un PVC”. Dans le cas du PVC provisionné avec kubernetes.io/no-provisioner, le kubelet a besoin de pouvoir monter le dossier avant le Pod.

Vous voyez où je veux en venir ? Dans un container OS, le kubelet est un container. Il ne voit rien d’autre que sa propre arborescence de container (pas le / de l’hôte comme un binaire classique, juste le contenu du gros ZIP qu’on a téléchargé depuis dockerhub avec docker pull), et éventuellement les dossiers de l’hôte qu’on lui a explicitement monté.

Dans mon cas, pour le container du kubelet, ce dossier /opt/tempDir n’existe pas, simplement parce que dans son arborescence de container, il n’a pas été monté (ni créé).

La solution

En fait, il suffisait, comme souvent, de lire la documentation. Talos Linux donne 2 méthodes pour résoudre ce problème :

explicitement monter les dossiers dont on a besoin dans le container du kubelet
passer par un provider tiers qui va créer des PVCs à partir de dossier sur l’hôte, sans passer par le kubelet.
www.talos.dev/v1.8/kubernetes-guides/configuration/local-storage/

J’ai testé les deux, elles fonctionnent parfaitement. Mais au-delà de la solution, c’est plus le chemin que j’ai trouvé intéressant à vous partager :)

Quelques liens sur le sujet

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