L’article explore l’intégration de Karpenter avec Cluster API (CAPI) pour automatiser l’autoscaling des nœuds Kubernetes, notamment sur OVH. L’auteur compare deux solutions : Cluster Autoscaler, qui gère des groupes de machines prédéfinis, et Karpenter, qui provisionne dynamiquement des nœuds en fonction des besoins des pods, sans nécessiter de configuration manuelle de groupes. Karpenter, initialement conçu pour AWS, est désormais agnostique grâce à sa donation à la CNCF, avec des providers tiers comme karpenter-provider-cluster-api pour CAPI, permettant une intégration avec des clouds comme OVH.

L’auteur détaille le fonctionnement de Karpenter, notamment ses ressources clés comme les NodePools, qui définissent les règles de provisionnement, et son approche par pods en attente (Pending). Contrairement à son mode natif (standalone), l’utilisation avec CAPI impose un cluster de management supplémentaire, ce qui complexifie légèrement l’architecture. Le texte souligne aussi les différences philosophiques entre les deux outils : Karpenter optimise les coûts en choisissant des instances adaptées (y compris Spot), tandis que Cluster Autoscaler se base sur des groupes de nœuds préconfigurés.

Enfin, l’article présente un retour d’expérience pratique avec des tests de scale-up et scale-down, mettant en lumière les défis rencontrés, comme la gestion des taints ou les limites du scale-to-zero. L’auteur conclut en comparant Karpenter et Cluster Autoscaler, soulignant les avantages de Karpenter pour les charges irrégulières, tout en notant les contraintes liées à son intégration avec CAPI.

Ce tutoriel explique comment concevoir un load balancer ICMP (ping) en utilisant XDP (eXpress Data Path) avec le framework Rust Aya. L’objectif est de rediriger les requêtes ICMP vers différents serveurs backends en modifiant l’adresse IP de destination, illustrant ainsi les principes de base des load balancers réseau. L’auteur justifie le choix de l’ICMP par sa simplicité pédagogique, bien que moins courant que TCP/UDP, tout en soulignant que les concepts abordés s’appliquent aussi à ces protocoles.

L’article détaille la création d’un environnement de développement via des namespaces réseau, la génération d’un programme XDP minimal avec Aya, et l’intégration de dépendances comme network-types pour manipuler les en-têtes réseau. Il montre ensuite comment tester le load balancer en pingant une IP virtuelle (10.0.0.10) qui redirige le trafic vers un backend (10.0.0.2 ou 10.0.0.3), avec une approche progressive pour résoudre les problèmes de checksum et de répartition de charge.

Enfin, le billet s’inscrit dans une série dédiée à XDP, après des articles sur les firewalls et la mitigation de DDoS, et annonce une suite pour améliorer ce load balancer. L’auteur invite les lecteurs à approfondir avec des ressources externes et à explorer des cas plus complexes comme TCP/UDP.

L’auteur présente son dépôt de dotfiles, un ensemble de configurations et d’outils pour personnaliser son terminal et optimiser son workflow. Ces fichiers, stockés dans un dépôt Git, permettent de recréer rapidement un environnement de travail sur une nouvelle machine en quelques minutes. L’idée centrale est de centraliser et versionner ces configurations pour une gestion efficace et reproductible.

Parmi les outils modernes utilisés, on trouve des alternatives performantes aux commandes Unix classiques : eza pour un affichage enrichi de ls, bat pour la coloration syntaxique de cat, ripgrep pour des recherches rapides, fd pour simplifier find, zoxide pour naviguer entre dossiers avec des fragments de noms, et delta pour améliorer la lisibilité des différences Git. Ces outils, souvent écrits en Rust, offrent des performances supérieures et une expérience utilisateur plus intuitive.

L’auteur souligne particulièrement zoxide, qui remplace avantageusement cd en mémorisant les chemins visités et en permettant des déplacements rapides via des mots-clés. Cette solution s’intègre parfaitement à son flux de travail, notamment en déclenchant automatiquement des actions comme le changement de version Node.js via fnm lors de la navigation.