L’article présente talosctl-oidc, un outil conçu pour simplifier l’authentification sur Talos Linux, un système d’exploitation minimaliste pour Kubernetes. L’auteur souligne les limites du système actuel basé sur des certificats mTLS (mutual TLS), qui impose une gestion manuelle fastidieuse des accès, notamment dans un contexte d’équipe. Plutôt que de régénérer manuellement des certificats pour chaque utilisateur, l’outil propose une solution intégrant l’OIDC (OpenID Connect) via un serveur d’échange de certificats, permettant une authentification centralisée via un fournisseur d’identité comme Authentik ou Keycloak.
Le fonctionnement repose sur un serveur intermédiaire qui génère des certificats Talos temporaires à partir des identités validées par l’OIDC. L’article détaille les étapes techniques, de l’installation à la configuration, en passant par la création d’un client OIDC dans l’IdP et la gestion des rôles via RBAC. L’outil automatise également le renouvellement des certificats et simplifie la révocation des accès, évitant ainsi la régénération complète de la CA en cas de départ d’un collaborateur. Cette approche s’inscrit dans une logique de cloud-native, alignée sur les bonnes pratiques modernes d’infrastructure.
Enfin, l’auteur évoque l’absence de solution native pour intégrer l’OIDC directement dans Talos, justifiant ainsi le développement de cet outil open source. Bien que conçu pour des environnements minimalistes ou air-gapped, talosctl-oidc offre une alternative pragmatique aux solutions centralisées comme Omni, tout en restant compatible avec les clusters existants. Le projet illustre une réflexion sur l’automatisation et la sécurité des accès dans les infrastructures Kubernetes.
Tetragon est un outil de sécurité conçu pour surveiller et détecter les comportements malveillants dans les clusters Kubernetes en temps réel. Développé par Isovalent, il s’appuie sur la technologie eBPF pour analyser les événements au niveau du noyau Linux, comme les lancements de processus, les accès aux fichiers ou les connexions réseau, offrant ainsi une visibilité complète sur l’activité des pods. Contrairement à un EDR classique, Tetragon se concentre sur le runtime, permettant une détection précoce des intrusions avant qu’elles ne causent des dommages.
L’article explique que Tetragon fonctionne en traduisant des politiques de traçage (définies en YAML) en programmes eBPF exécutés directement dans le noyau, générant des logs détaillés à chaque événement correspondant. Bien que l’utilisation de Tetragon ne nécessite pas de maîtriser eBPF, une compréhension approfondie du noyau Linux et de cette technologie est essentielle pour en exploiter pleinement les capacités, notamment pour créer des politiques avancées.
Enfin, l’auteur annonce une série d’articles pratiques, commençant par une démonstration d’installation hors Kubernetes, avant d’aborder son déploiement dans des environnements plus complexes. L’objectif est d’aider les utilisateurs à évaluer l’outil, à l’installer et à l’étendre selon leurs besoins, tout en répondant aux questions sur son adéquation avec leurs infrastructures.
L’article explique comment créer des boucles dans les templates Helm en utilisant l’instruction range, qui permet d’itérer sur des listes ou des maps définies dans le fichier values.yaml afin de générer dynamiquement des blocs YAML répétés, évitant ainsi la duplication manuelle et rendant les charts plus flexibles. Il insiste notamment sur la gestion du contexte dans les templates (avec . et $ pour accéder aux données globales) et montre que ces boucles sont essentielles pour produire des configurations adaptables selon les valeurs fournies, par exemple pour créer plusieurs entrées à partir d’une liste de paramètres.
Cet article compare deux méthodes pour étendre l'API Kubernetes : les CRD (Custom Resource Definitions) et les APIService. Les CRD permettent de définir des ressources personnalisées directement gérées par Kubernetes (stockage, validation via OpenAPI), tandis que les APIService délèguent la gestion à un serveur HTTP externe via le kube-aggregator. L'auteur explique que dans 90% des cas, les CRD sont la solution la plus simple et recommandée, illustrant la différence avec un exemple concret de création d'une ressource Cafe. Un bon guide pour choisir la bonne approche selon ses besoins ! ☕️
Fault est un outil de chaos engineering conçu pour tester la résilience des microservices en injectant volontairement des perturbations (latence, erreurs, coupures) dans les communications HTTP afin d’observer leur comportement face aux défaillances et d’identifier leurs faiblesses. Il agit comme un proxy intermédiaire qui rend les échanges volontairement instables, permettant par exemple de reproduire des retards ou des pannes de dépendances et de détecter des problèmes concrets comme des fuites de ressources ou une mauvaise gestion des erreurs, dans l’objectif d’améliorer la tolérance aux pannes et la robustesse globale du système.
L'auteur partage son expérience avec un outil Kubernetes simplifié, kubectl-debug-pvc, développé en deux sessions de 30 minutes grâce à l'IA (Claude Opus). Face à un besoin réel en production (accéder à un volume PVC en ReadWriteOnce sans shell), il contourne les limites de kubectl debug avec une solution automatisée via un plugin Krew. Le projet, plus léger que son prédécesseur PodSweeper, illustre l'efficacité de l'IA pour des tâches ciblées, tout en soulignant l'importance de la supervision humaine. Une démonstration de la puissance des outils GenAI pour le DevOps ! 🚀
L'auteur partage son expérience avec Kyverno, un outil puissant pour Kubernetes, lors d'une mise à jour de cluster vers la version 1.34. L'upgrade a provoqué un deadlock entre les nouvelles fonctionnalités réseau de Kubernetes et Kyverno, rendant l'API Server injoignable. L'incident, initialement perçu comme un problème réseau, était en réalité causé par une collision entre la création automatique d'un objet ServiceCIDR par Kubernetes et l'interception par le webhook Kyverno. L'auteur détaille le mécanisme du deadlock et propose des solutions pour éviter de tels incidents à l'avenir.
Cet article détaille trois retours d’expérience marquants. Sellsy a partagé sa migration réussie de 50 000 bases de données d’un monolithe MariaDB vers une architecture distribuée PostgreSQL/Kubernetes, sans interruption de service, en utilisant CloudNativePG et ZFS pour optimiser les performances et réduire les coûts. Ubisoft a expliqué comment rationaliser l’usage de Kubernetes à grande échelle avec Capsule et une Internal Developer Platform, permettant une gestion multi-tenant efficace et scalable. Enfin, l’INSEE a présenté son approche MLOps pour industrialiser l’entraînement et le déploiement de modèles d’IA, en brisant les silos entre data scientists et développeurs, et en automatisant les pipelines avec Argo Workflows. Une journée riche en enseignements techniques et organisationnels !
Le 3 février 2026, Ippon Technologies a participé aux Cloud Native Days France (ex-Kubernetes Community Days), un événement dédié au Cloud Native, au DevOps et à la souveraineté numérique. La journée a débuté par une keynote sur la souveraineté et l’open source, soulignant l’importance de contribuer activement à ces écosystèmes pour réduire la dépendance aux acteurs américains. Plusieurs interventions ont illustré ces enjeux, comme celle du CERN, qui gère des pétaoctets de données grâce à une infrastructure cloud native optimisée, ou celles de la DINUM et de Scaleway, mettant en avant des solutions souveraines basées sur OpenStack et Kubernetes. Une table ronde a également abordé la formation à Kubernetes et les défis du platform engineering. Enfin, la présentation de Kubo, une distribution Kubernetes open source française, a détaillé son architecture multi-tenant sécurisée, utilisant Capsule et Keycloak pour une gestion fine des droits et une authentification moderne. L’événement a marqué un tournant avec son nouveau nom, symbolisant une plus grande liberté éditoriale et une ouverture accrue.
Le premier jour de la conférence Touraine Tech 2026 a été riche en découvertes et en échanges. L’événement, désormais organisé sur deux jours à l’Université de Sciences de Tours, a débuté par une keynote marquante de Clément Hammel-Cazenave (Agoratlas) sur la guerre informationnelle et les ingérences numériques, illustrée par l’analyse de 500k tweets autour de la crise agricole. L’outil open source D3lta (Viginum) a été présenté pour détecter les contenus dupliqués et lutter contre ces manipulations. Les participants ont aussi pu découvrir des projets techniques variés : la modernisation de trains Jouef avec des Raspberry Pi et TinyGo, un talk sur Kubernetes (avec ses démos improvisées), et une présentation inspirante sur Metal-As-A-Service (MAAS) pour gérer le bare-metal comme des machines virtuelles, avec des économies d’énergie significatives. Enfin, une session sur les agents IA a permis d’explorer les workflows et frameworks pour organiser le chaos des intelligences artificielles. Une journée intense, entre innovation, partage et réflexion collective ! 🚀
L'article explique comment obtenir un ASN (Autonomous System Number) personnel pour annoncer ses plages d'IP sur Internet via le protocole BGP (Border Gateway Protocol). Il commence par définir ce qu'est un ASN et son rôle dans la communication entre réseaux autonomes. L'auteur partage son expérience personnelle, détaillant les étapes pour obtenir un ASN sans se ruiner, comment annoncer ses routes, et comment configurer BGP dans un environnement Kubernetes avec MetalLB. L'article met en lumière l'importance des protocoles de routage dynamique comme BGP pour optimiser les chemins de réseau, surtout dans des infrastructures complexes.
Découverte de Talos Linux, une distribution innovante dédiée à Kubernetes, axée sur l'immuabilité et la sécurité. Sans SSH ni CLI traditionnelle, elle est entièrement gérée via une API similaire à celle de Kubernetes, utilisant des certificats pour l'authentification. Le blog détaille le déploiement d'un cluster Kubernetes avec 3 nœuds masters et un nœud worker, en utilisant Talosctl. La documentation officielle est saluée pour sa clarté, et les prérequis infrastructurels sont classiques. Un tutoriel pratique avec commandes et captures d'écran est fourni.
L'auteur partage son expérience d'obtention des cinq certifications officielles Kubernetes de la CNCF, un parcours initié en 2025 et aboutissant au titre de Kubestronaut. Il détaille les certifications (KCNA, KCSA, CKA, CKAD, CKS), les coûts initiaux élevés (plus de 1500€) et les stratégies pour les réduire (promotions, bundles), ainsi que les défis rencontrés. Il conclut par une réflexion sur la valeur de ces certifications et partage des ressources supplémentaires. Un retour d'expérience utile pour ceux intéressés par la certification Kubernetes.
Cet article remet en question l'idée reçue que Kubernetes est uniquement utile pour les grandes entreprises comme Netflix ou Google. Il rappelle que les problématiques d'infrastructure (tolérance aux pannes, déploiements fréquents, flexibilité, etc.) existent dès qu'une équipe gère plusieurs applications en production, indépendamment de la taille de l'entreprise. L'auteur décrit les solutions utilisées avant Kubernetes, comme le load balancing avec HAProxy et Keepalived, et les défis liés au service discovery et aux rollouts, soulignant la complexité de ces tâches sans un outil comme Kubernetes.
Ce billet de blog décrit la mise en place d'un cluster Kubernetes full IPv6 avec Talos OS, un système d'exploitation minimaliste et sécurisé. L'auteur, ayant un /60 IPv6 fourni par son FAI, explique comment configurer Talos pour utiliser uniquement des adresses IPv6, en planifiant des plages IPv6 pour les nodes, les pods et les services. Il détaille les étapes de configuration initiale avec talhelper, un outil facilitant la création de fichiers de configuration Talos, et aborde les problèmes potentiels de DHCPv6 et de résolution de noms. L'article se conclut par des pistes pour améliorer la configuration et des liens vers des ressources supplémentaires.
Kairos est un système d'exploitation immutable open-source conçu pour déployer des clusters Kubernetes de manière simple et efficace. Contrairement à Talos, qui est minimaliste et sans SSH ni Systemd, Kairos adopte une approche plus classique en permettant de bâtir un système immuable à partir de distributions existantes comme openSUSE, Ubuntu, Debian ou Rocky Linux. Kairos offre des mises à jour atomiques A/B via des images signées, un OS en lecture seule pour éviter les dérives de configuration, et des workflows d'automatisation basés sur Cloud-Init (via Yip) et les pipelines OCI. Cela en fait une option intéressante pour les équipes souhaitant bénéficier de l'immutabilité sans renoncer à l'usage d'une distribution Linux déjà maîtrisée.
L'article de Julia Evans explique comment Kubernetes peut causer des problèmes à etcd, un système de stockage de clés-valeurs utilisé pour la coordination des clusters.
Kubernetes 1.34 introduit les Pod-level resources, une fonctionnalité en béta qui simplifie la gestion des ressources pour les pods contenant plusieurs conteneurs. Contrairement à la croyance initiale de l'auteur, la QoS Guaranteed ne nécessite pas que tous les conteneurs aient les mêmes limites et demandes de ressources, mais seulement que chaque conteneur respecte cpu.limit = cpu.request et memory.limit = memory.request. Les Pod-level resources sont utiles pour les conteneurs peu gourmands ou injectés dynamiquement, évitant ainsi de spécifier des limites et demandes pour chaque conteneur individuellement. Cela simplifie la gestion des ressources, surtout lorsque des conteneurs annexes comme des sidecars sont ajoutés ou modifiés.
Ce billet de blog explique comment transformer un serveur Proxmox VE en nœud Kubernetes en utilisant LXC et lxcri, un runtime de conteneurs compatible CRI pour LXC. L'auteur, bien conscient du côté inutile du projet, décrit les étapes pour installer et configurer cri-o et lxcri sur Proxmox VE, malgré les défis techniques et les bugs rencontrés. Le but est de réutiliser au maximum les technologies existantes de Proxmox, notamment LXC, pour intégrer le serveur dans un cluster Kubernetes. Un projet audacieux et instructif pour les amateurs de virtualisation et de conteneurs.
Dans cet article, Rémi Verchère partage son expérience de création et de gestion de plusieurs clusters Kubernetes Talos sur Docker pour une démo ArgoCD multi-clusters. Il détaille les étapes de configuration réseau, la création des clusters avec des CIDR dédiés, et les défis rencontrés pour assurer la communication inter-clusters. Des scripts d'automatisation et des commandes talosctl sont fournis pour faciliter le processus. Un guide pratique pour ceux qui souhaitent expérimenter des architectures multi-clusters en local.