Certains liens de cette page sont des liens d'affiliation : si vous vous inscrivez via ces liens, ce site touche une commission, sans surcoût pour vous. Les prix et les recommandations ne changent pas.

Quatre sujets ont retenu l’attention cette semaine, avec notre avis sur chacun. Les originaux sont liés ; lisez-les. Cette page explique seulement pourquoi ils comptent pour une petite installation auto-hébergée.

1. Un resources: {} vide déclasse silencieusement vos pods sur Kubernetes 1.34 à 1.36

Original : An Empty resources: {} Makes Kubernetes 1.34 to 1.36 Pods BestEffort sur devops-daily.com (aussi sur dev.to).

L’affirmation : si un pod définit spec.resources: {} au niveau du pod, le kubelet le classe en BestEffort, même lorsque chaque conteneur a des requests et des limits. Les auteurs l’ont mesuré sur k3s 1.34, 1.35 et 1.36 : oom_score_adj est passé à 1000 et, à côté d’un voisin très sollicité, un pod qui avait demandé une demi-CPU n’obtenait que 0.06 à 0.08 cœur au lieu d’environ 0.57. Un quota de namespace qui bloque les pods BestEffort l’a rejeté. Sur 1.37.1, les classes étaient correctes. L’executor Kubernetes de GitLab Runner génère ce bloc vide dans les versions 18.10.0 à 19.4.3.

Notre avis : une correction utile à une idée reçue. L’article montre que l’affirmation populaire « ces pods sont évincés en premier » est fausse ; l’ordre d’éviction du kubelet n’a pas changé. Vérifiez votre cluster en dix secondes :

kubectl get pods -A -o custom-columns=NS:.metadata.namespace,POD:.metadata.name,QOS:.status.qosClass | grep BestEffort

Si une charge de travail disposant de limits apparaît ici, vous avez trouvé le problème. Si vous préférez voir la classe QoS dans une interface, notre comparatif des interfaces graphiques Kubernetes présente les outils qui l’affichent d’un coup d’œil.

2. Un OpenStick à 10 USD comme serveur domestique

Original : What I run on my $10 USD OpenStick homelab (825 points et 137 commentaires sur Hacker News).

Le matériel : quatre cœurs Cortex-A53 à 1 GHz, 512 Mo de RAM (environ 450 Mo utilisables), 4 Go d’eMMC, Debian avec systemd et Podman, refroidissement passif. L’auteur y fait tourner AdGuard Home (environ 40 Mo) et quelques petits utilitaires.

Notre avis : ce qui est intéressant n’est pas le gadget, mais la discipline budgétaire. Les services qui se mesurent en dizaines de mégaoctets sont le bon choix par défaut pour un bloqueur DNS, une surveillance de disponibilité ou un outil de notification. Quand un service dépasse 512 Mo, l’étape honnête suivante est un petit VPS plutôt qu’une machine plus grosse sous le bureau ; notre comparatif des VPS montre ce que 4 à 6 EUR par mois permettent aujourd’hui.

3. HolyArrs : une pile média auto-hébergée de 15 Mo

Original : HolyArrs sur GitHub, publié sous le titre « Show HN: A 15 MB self-hosted Netflix and Spotify for your media server » (environ 160 points et 125 commentaires sur Hacker News).

Le projet remplace six applications média distinctes par un seul binaire : environ 15 Mo à télécharger, environ 140 Mo de RAM au repos avec 10 000 titres, builds pour amd64, arm64 et armv7, licence AGPL-3.0.

Notre avis : après l’exploitation de Plex plus tôt cette saison, une surface d’attaque réduite est l’argument qui fait réagir. Un seul petit binaire est plus facile à auditer qu’une pile de six applications, mais un projet jeune n’a pas encore d’historique de sécurité. Notez que 15 Mo est la taille du téléchargement, pas l’empreinte mémoire : à 140 Mo au repos, cela tiendrait tout juste sur l’OpenStick ci-dessus. Quel que soit votre choix, placez-le derrière un reverse proxy, sans port publié directement ; Docker contourne ufw pour les ports publiés, ce que nous avons mesuré dans nos pièges de Docker en production.

4. NVIDIA publie NVKE, un plan de gestion pour Kubernetes GPU

Original : dsx-ai-factory/nvke (124 points et 30 commentaires sur Hacker News).

NVKE est un plan de gestion dans lequel chaque cluster de charge de travail reçoit son propre plan de contrôle, son etcd et ses pools de nœuds. Le README le présente comme une préversion et déconseille son usage en production. Un quickstart local lance un plan de gestion et un cluster de charge de travail sur des machines simulées, ce qui permet de l’essayer sans matériel GPU.

Notre avis : sans intérêt pour un serveur unique, mais signal important : le modèle « un cluster par client » devient un produit packagé. Si vous faites tourner un ou deux clusters, restez sur k3s et revenez sur NVKE quand l’étiquette de préversion aura disparu.

Ce que nous ferions cette semaine

  • Lancez la vérification BestEffort ci-dessus sur tout cluster en 1.34 à 1.36.
  • Si vous utilisez l’executor Kubernetes de GitLab Runner, passez à 19.5.0 ou plus récent, comme le recommande le rapport d’origine.
  • Ne déplacez rien de critique en production sur un logiciel en préversion.