Remplacer Kubernetes par systemd (2024)

• L’auteur explique comment, frustré par la complexité et la consommation de ressources de Kubernetes pour faire tourner ses serveurs personnels, il l’a remplacé par une combinaison de systemd et Podman
• Kubernetes séduit par GitOps et l’automatisation, mais reste un système excessivement lourd pour les petits environnements
• En utilisant la mise à jour automatique de Podman et la génération de services systemd, il est possible de reproduire simplement les fonctions essentielles de Kubernetes
• Il décrit aussi l’exécution automatique de services au niveau utilisateur en combinant systemctl et loginctl, en soulignant une forte baisse de la consommation de ressources sur son VPS
• Il précise toutefois que l’intégration systemd de Podman sera bientôt remplacée par une nouvelle approche appelée "Quadlet"

---

Introduction : première rencontre avec Kubernetes

• Il revient sur son expérience de 2018, lorsqu’il a expérimenté Kubernetes en tentant de déployer un cluster sur un NUC personnel
• Kubernetes est complexe, mais son fonctionnement repose fondamentalement sur la boucle répétitive suivante :
  • observation de l’état actuel → calcul de l’état souhaité → calcul de l’écart → application
• Les fonctions d’automatisation reposant sur divers composants comme cert-manager l’avaient fortement impressionné

Les exigences excessives de Kubernetes en ressources

• Sur un serveur personnel (NUC), Kubernetes entraînait une utilisation CPU continue, du bruit de ventilateur et de la chaleur
• Différentes distributions comme Azure, MicroK8s et K3S consommaient elles aussi des ressources importantes
  • MicroK8s : 12 % de CPU utilisé (VPS 2 vCPU)
  • K3S : 6 % de CPU utilisé (Ampere A1 2 vCPU)

La tentation de l’automatisation GitOps

• Des outils comme Flux rendaient l’automatisation des déploiements basée sur Git extrêmement pratique
• Il suffisait de pousser une image de conteneur sur GitHub pour que le serveur déploie automatiquement la dernière version de l’application
• Mais sans Kubernetes, mettre en place une telle automatisation était très difficile

L’arrivée de Podman et systemd

• Podman est une alternative à Docker et permet de transformer des conteneurs en services systemd
• podman generate systemd permet de générer automatiquement des fichiers de service
• Le tag io.containers.autoupdate permet une mise à jour automatique des images une fois par jour
• En s’appuyant sur cette méthode présentée dans Fedora Magazine, il a réussi à mettre en place un environnement remplaçant Kubernetes

Les trois éléments nécessaires

1. systemctl --user enable mycontainer.service

   • Configure le conteneur pour qu’il se lance automatiquement à la connexion

2. loginctl enable-linger

   • Configure l’activation de la session utilisateur au démarrage du serveur

3. La fonction d’auto-update de Podman

• Avec ces trois éléments, il a pu remplacer 99 % des fonctions fournies par Kubernetes de manière plus simple et plus légère

Résultat de la migration

• Il a migré l’ensemble de ses services d’un VPS existant vers un nouveau VPS
• Les ressources nécessaires ont été divisées par deux, tandis que les performances se sont au contraire améliorées, avec une densité de services plus élevée et des coûts réduits

Prochaine étape : Quadlet

• Malheureusement, l’intégration systemd de Podman devrait bientôt être abandonnée
• À la place, elle migrera vers un nouveau mode de définition reposant sur les fichiers Quadlet
• L’article se conclut en soulignant qu’il faudra se préparer à apprendre cette nouvelle technologie

[GN⁺]

Avis sur Hacker News

• Si l’on considère Kubernetes uniquement comme un moyen d’exécuter et de mettre à jour des images de conteneurs, cela peut être excessif

  • Kubernetes fournit les ressources nécessaires pour que les conteneurs puissent partager leur état, se connecter entre eux et accéder à leur configuration ou à leurs secrets
  • Le coût en CPU et en mémoire provient de la gestion des conteneurs et de la fourniture des ressources nécessaires
  • Dans les systèmes distribués, tous les systèmes ne fonctionnent pas comme on le souhaite, donc le gestionnaire essaie en permanence d’atteindre l’état désiré

• J’ai essayé d’exploiter quelques petits sites web avec Docker, mais il était difficile de mettre à jour les images et de les tester

  • J’ai tout remplacé par un script qui crée des unités systemd sur Debian et redémarre lors des changements de service
  • J’utilise une VM de test pour rsync les changements vers l’hôte de déploiement et exécuter le script de déploiement
  • L’ensemble du système tourne sur un VPS de 2 Go, et si Wordpress prenait officiellement en charge SQLite, il pourrait être réduit à 1 Go
  • J’utilise Mariadb afin de minimiser les exigences de support

• Je n’ai pas de problème à gérer un cluster Kubernetes, mais pour des projets perso, son utilisation est difficile à cause des besoins en ressources

  • Kubernetes est trop gourmand en ressources pour tourner sur un VPS à 10 $/mois
  • J’utilise manuellement les commandes docker compose et la fonction de découverte de conteneurs de Traefik au lieu d’Ingress
  • J’écris de petits scripts pour gérer crontab au lieu des CronJobs
  • J’essaie de résoudre, de manière moins efficace, des problèmes que Kubernetes a déjà résolus
  • Je voudrais une alternative légère offrant une API compatible Kubernetes qui fonctionne bien sur des instances VPS bon marché

• Systemd résout beaucoup de problèmes et ne doit pas être ignoré

  • Il offre diverses fonctionnalités comme machinectl, nspawn, vmspawn et importctl
  • homed/homectl étend la gestion des utilisateurs, mounts monte automatiquement les disques, boot contrôle le démarrage/l’arrêt des services, timers remplace cron
  • Les unités de service contrôlent les tâches, et systemctl edit permet de modifier les fichiers de configuration

• J’exploite mon homelab avec podman-systemd, et chaque fois que j’étudie une nouvelle variante de Kubernetes, cela n’ajoute pas de contrainte supplémentaire

  • J’utilise des playbooks Ansible pour pré-télécharger les images et placer les fichiers d’unité au bon endroit
  • Je fais tourner la stack de l’imprimante 3D Voron avec podman-systemd et j’envisage de passer à mkosi et systemd-sysupdate
  • Il y a l’inconvénient de devoir convertir les fichiers Docker-compose en unités systemd
  • Podman réduit la complexité liée aux réglages des utilisateurs et des permissions

• Utiliser Quadlet pour gérer les conteneurs dans systemd est l’étape suivante

  • Plus de détails sont disponibles sur le blog de Red Hat

• J’ai créé Skate pour construire un système prenant en charge le multi-hôte et les manifestes Kubernetes

  • En interne, il utilise podman et systemd

• Il est possible d’utiliser les commandes Docker compose et Caddy pour obtenir automatiquement des certificats

  • La configuration peut être simplifiée avec la commande docker compose up -d --pull always
  • La configuration CI repose sur scp et ssh
  • C’est simple et cela fonctionne aussi sur la machine de développement

• Systemd propose désormais ParticleOS, une distribution d’OS officiellement prise en charge pour les workflows immuables

• Je pense que déployer sur un seul serveur ne devrait pas être compliqué, et j’ai écrit un outil appelé Harbormaster

  • Il utilise des fichiers YAML pour découvrir les dépôts et exécute les fichiers Docker Compose
  • Il conserve tout l’état dans un seul répertoire, ce qui facilite les sauvegardes
  • C’est l’outil d’orchestration de conteneurs le plus simple nécessaire pour un seul serveur