Installer k3s et déployer cilium sous Debian 12

Une page simple et rapide pour vous permettre d'installer un cluster Kubernetes avec k3s et cilium.

Le but de la page n'est pas d'aller au plus loin dans les technologies, plutôt d'avoir un rapide guide de mise en place.

Environnement de test

Pour les besoins de cette opération, j'utiliserai deux machines sous Debian 12, disposant de 12 Go de mémoire vive, de 4 threads CPU et d'un disque SSD. Les machines disposent de deux cartes réseaux (1 x 2,5 GbE et 1 x 1 GbE), configurées en "bond" (backup).

Côté commutation, le matériel est un simple TP-Link disposant de ports 1 GbE. Tout est local, il n'y a donc pas de VPN, ni de pare-feu (pour le moment).

Le but de cet environnement est aussi (et surtout) de me (re)mettre à Kubernetes, avec un cluster au plus proche de ce qui peut être fait en production. Ayant eu quelques surprises lors de mes tests, je ne passe plus avec "sudo", mais directement en tant que "root".

J'abstrais complètement la partie IGC, les certificats. Pour l'instant, le but est d'avoir un cluster qui démarre et est prêt à lancer des pods.

Mon réseau pour le homelab :

serveur "master" : k3s-master1 / IP = 192.168.1.100/24
serveur "worker" : k3s-worker1 / IP = 192.168.1.101/24
sous-réseau pour les pods : 10.42.0.0/16 (celui par défaut utilisé par k3s)

Pré-requis

Avant d'initier l'installation de Kubernetes, assurez-vous d'avoir un système à l'heure avec une source de temps fiable, une adresse IP fixe et un fichier /etc/hosts à jour, et aucun outil ou configuration exotique qui pourrait empêcher l'installation des paquets (SELinux, AppArmor, hardening trop poussé...).

Installation de k3s sur le master

L'équipe derrière Rancher met à disposition un binaire en Go, accessible depuis leur site web. En une ligne de commande, vous pouvez installer et avoir un Kubernetes fonctionnel. Je vais aller plus loin, en spécifiant un fichier de configuration permettant de limiter les pré-installations d'outils, pour y ajouter cilium par la suite.

Créons le fichier de configuration, ajoutons le contenu, puis lançons l'installation de k3s.

$ apt update && apt install -y curl

$ mkdir -p /etc/rancher/k3s

$ cat << EOF > config.yaml
---

kube-controller-manager-arg: --allocate-node-cidrs
flannel-backend: none
disable-network-policy: true
disable: traefik
EOF

$ curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server" sh -s

Le fichier de configuration désactive Flannel (remplacé par cilium), empêche le déploiement pré-configuré de Traefik et bloque la configuration d'un network-policy par défaut. Les options et désactivations seront surchargées par cilium dans quelques instants.

Via un systemctl status k3s, contrôlez que le service est dans le statut "démarré".

Ensuite, je lance la kubectl pour spécifier l'adresse IP de mon master, plutôt que d'utiliser l'adresse de loopback (certains ont eu des pb avec 127.0.0.1, à cause d'un MTU notamment qui n'était pas 1500) : kubectl config set-cluster default --server=https://192.168.1.100:6443.

S'il y a un problème de connexion en lançant les commandes kubectl, exportez la variable "KUBECONFIG" suivante : export KUBECONFIG=/etc/rancher/k3s/k3s.yaml.

Kubernetes doit être lancé à cet instant, mais les pods sans doute dans un état "ContainerCreating" ou "CrashLoopbackOff". Ce comportement est normal, puisqu'il n'y a pas de composant réseau lancé, ça arrive...

Installer k3s sur un worker

Passons rapidement à l'installation d'un nœud de type "worker". C'est bien plus rapide que pour le master (logique et heureusement).

Depuis votre master, récupérez le jeton de votre cluster (node-token) via la commande suivante : cat /var/lib/rancher/k3s/server/node-token. Maintenant, installons k3s sur le worker, en spécifiant l'IP du master et le node-token :

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC='agent' K3S_URL=https://192.168.1.100:6443 K3S_TOKEN=aaaaa::server:3289azer sh -

Sur votre nœud master, en faisant un kubectl get nodes, vous devriez voir vos deux serveurs :

╰─# kubectl get nodes
NAME          STATUS   ROLES                  AGE   VERSION
k3s-worker1   Ready    <none>                 17h   v1.27.4+k3s1
k3s-master1   Ready    control-plane,master   17h   v1.27.4+k3s1

Si ce n'est pas le cas, regardez les journaux côté worker (soit c'est un problème de token, ou de connexion réseau (IP, DNS, hosts, route, pare-feu)).

Installer cilium

Enfin, nous arrivons. Depuis la version 1.14.0 de cilium, il est préférable d'utiliser leur ligne de commande (cilium-cli 0.15.5). Nous allons donc télécharger l'outil, l'installer et lancer le déploiement de cilium. Les opérations sont simples, la CLI fait tout.

Il y a un point à noter, que je n'ai pas encore pris le temps de comprendre, c'est le montage bpf. Une commande mount doit être lancée avant d'exploiter cilium-cli.

$ mount bpffs -t bpf /sys/fs/bpf

$ curl -L --remote-name-all https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz{,.sha256sum}
$ sha256sum --check cilium-linux-amd64.tar.gz.sha256sum
$ tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
$ rm cilium-linux-amd64.tar.gz{,.sha256sum}

Assurez-vous d'avoir les bonnes versions, via la commande cilium version. Mi-août, l'article se base sur ces versions :

╰─# cilium version
cilium-cli: v0.15.5 compiled with go1.20.4 on linux/amd64
cilium image (default): v1.14.0
cilium image (stable): v1.14.0
cilium image (running): 1.14.0

╰─# kubectl version --short
Client Version: v1.27.4+k3s1
Kustomize Version: v5.0.1
Server Version: v1.27.4+k3s1

Via la commande cilium install, l'outil va déployer tout le nécessaire pour votre cluster Kubernetes. Patientez quelques minutes que tout le déploiement s'exécute. Par la commande watch kubectl get pods -A -o wide, vous verrez gigoter les conteneurs...

Enfin, en faisant un cilium status, vous verrez l'état de la CNI. L'option --wait est l'équivalent d'un watch, s'arrêtant une fois les status "OK".

╭─root@k3s-master1─~
╰─# cilium status
    /¯¯\
 /¯¯\__/¯¯\    Cilium:             OK
 \__/¯¯\__/    Operator:           OK
 /¯¯\__/¯¯\    Envoy DaemonSet:    disabled (using embedded mode)
 \__/¯¯\__/    Hubble Relay:       OK
    \__/       ClusterMesh:        disabled

Deployment             hubble-relay       Desired: 1, Ready: 1/1, Available: 1/1
DaemonSet              cilium             Desired: 2, Ready: 2/2, Available: 2/2
Deployment             cilium-operator    Desired: 1, Ready: 1/1, Available: 1/1
Containers:            hubble-relay       Running: 1
                       cilium-operator    Running: 1
                       cilium             Running: 2
Cluster Pods:          4/4 managed by Cilium
Helm chart version:    1.14.0
Image versions         cilium             quay.io/cilium/cilium:v1.14.0@sha256:5a94b561f4651fcfd85970a50bc78b201cfbd6e2ab1a03848eab25a82832653a: 2
                       hubble-relay       quay.io/cilium/hubble-relay:v1.14.0@sha256:bfe6ef86a1c0f1c3e8b105735aa31db64bcea97dd4732db6d0448c55a3c8e70c: 1
                       cilium-operator    quay.io/cilium/operator-generic:v1.14.0@sha256:3014d4bcb8352f0ddef90fa3b5eb1bbf179b91024813a90a0066eb4517ba93c9: 1

Dans ce statut, relevez les états de "Cilium" et "Operator". Tant qu'ils ne sont pas OK, la CNI n'est pas fonctionnelle.

Étape cruciale, tester le bon fonctionnement de cilium. Pour vous rassurer et afficher pleins de "OK" dans votre terminal, lancez la commande cilium connectivity test. Pendant plusieurs minutes, une batterie de tests et quelques pods seront lancés, pour tester l'ingress, l'egress, le filtrage interne et externe...

Facultatif, mais conseillé : Hubble

Pour aller plus loin, j'ai installé Hubble, intégré à cilium. Cet outil supervise et inspecte en profondeur les flux réseaux de votre cluster. Rapidement, vous pouvez initier le déploiement en saisissant cilium hubble enable.

Maintenant, il est nécessaire de déployer quelques services dans ce Kube...

Effectuer les tâches manuellement, c'est mignon, automatiser c'est mieux ! Retrouvez l'ensemble des tâches ci-dessus avec Ansible, dans ce dépôt GitHub :