Bienvenue dans cette revue hebdomadaire du Cloud et de l’Infrastructure as Code (IaC) !
haque semaine, nous décryptons les actualités, tendances et innovations majeures qui façonnent l’univers du cloud computing. À travers une sélection de sources fiables et spécialisées : blogs techniques, forums d’experts, réseaux sociaux et publications officielles nous vous proposons un résumé clair et structuré pour rester informé.

Avertissement : Contenu généré par IA avec MistralIA
Cet article a été généré automatiquement à l'aide d'une intelligence artificielle. Bien que nous nous efforcions d'assurer l'exactitude des informations, des erreurs ou imprécisions peuvent subsister.

Si vous constatez une erreur ou souhaitez signaler un problème, n'hésitez pas à me contacter :
Email : pro@sarquentin.fr
LinkedIn : Quentin Sar

Le résumé de la semaine

Cette semaine, l'actualité DevOps et Cloud a été marquée par plusieurs développements significatifs. HashiCorp a publié des articles détaillant l'utilisation de Vault pour sécuriser les charges de travail modernes, ainsi que des études de cas sur l'utilisation de Terraform par la Banque mondiale et Duke Energy pour gérer la complexité des clouds hybrides et renforcer la sécurité. De plus, la communauté Cloud Native Computing Foundation (CNCF) a annoncé le retour du Security Slam pour 2026, un événement visant à améliorer la posture de sécurité des projets open source. KubeCon + CloudNativeCon Europe 2026 a également été évoqué, avec un focus sur le Cloud Native Telco Day, un événement co-localisé qui rassemble les communautés des télécommunications et du cloud native. Enfin, un article a mis en lumière les tendances de vitesse des projets CNCF en 2025, révélant des insights sur l'avenir du cloud native.

Securing modern workloads with HashiCorp Vault and WIF

Les entreprises modernes, de plus en plus cloud-native, font face à des défis croissants en matière de sécurité. Les crédentiels statiques et les périmètres de sécurité traditionnels ne suffisent plus. HashiCorp Vault, combiné avec la fédération d'identités de charge de travail (WIF), permet aux organisations d'appliquer les principes de zéro confiance tout en réduisant les risques, en améliorant l'auditabilité et en simplifiant les opérations.

Le risque des crédentiels statiques

Même avec la fédération d'identité pour les utilisateurs humains, les charges de travail reposent souvent sur des secrets statiques stockés dans le code, les fichiers de configuration ou les pipelines CI/CD. Cela expose les organisations à des fuites de crédentiels, à une prolifération de secrets et à des rôles surprivilegés qui augmentent le rayon d'action d'une violation. Ces risques sont exactement ceux que WIF avec Vault est conçu pour atténuer.

Le problème du secret zéro

Un défi de sécurité critique dans les infrastructures modernes est le "secret zéro" : le premier crédentiel dont une charge de travail a besoin pour accéder à Vault afin de récupérer d'autres secrets. Traditionnellement, ce crédentiel initial doit être stocké quelque part, ce qui peut servir de porte d'entrée à tous les secrets en aval. Les incidents récents, comme l'attaque GhostAction sur GitHub en 2025, soulignent les conséquences réelles des crédentiels de secret zéro exposés.

Comment la fédération d'identités de charge de travail résout le problème du secret zéro

Vault s'intègre avec les identités natives des charges de travail, éliminant ainsi le besoin de crédentiels secrets zéro statiques. Les charges de travail s'authentifient en utilisant leur identité native, et Vault vérifie cette identité avec le fournisseur externe. Vault émet ensuite des crédentiels éphémères pour les bases de données, les API cloud ou d'autres moteurs de secrets. Cette approche élimine le besoin de crédentiels initiaux codés en dur ou statiques, atténuant ainsi les risques associés au secret zéro.

Vault et zéro confiance pour les charges de travail

Vault transforme WIF en un point d'application des principes de zéro confiance. Les crédentiels éphémères réduisent le rayon d'action en cas de compromission d'une charge de travail. Les politiques Vault appliquent le principe du moindre privilège de manière cohérente dans tous les environnements. La vérification continue et la révocation automatique garantissent que seules les identités valides peuvent obtenir des secrets. En combinant WIF avec des politiques de zéro confiance, Vault permet aux charges de travail de fonctionner sans stocker de crédentiels statiques à long terme lorsque l'authentification basée sur l'identité est utilisée.

Architecture pour les charges de travail d'entreprise

Vault et WIF peuvent être appliqués à travers les charges de travail d'entreprise, notamment dans les environnements multi-cloud, les clusters Kubernetes et les pipelines CI/CD. Ces modèles fournissent un modèle de sécurité cohérent à travers les clouds, les clusters et les pipelines, tout en réduisant considérablement le risque de secret zéro.

Impact commercial

L'adoption de Vault avec WIF permet de réduire les risques opérationnels liés à la prolifération des crédentiels, d'éliminer les crédentiels secrets zéro statiques en les remplaçant par des assertions d'identité vérifiables et à durée de vie courte, d'appliquer de manière cohérente des politiques de moindre privilège, d'automatiser la rotation et la révocation des crédentiels, d'améliorer l'auditabilité et la conformité, et d'accélérer les opérations DevOps et cloud. Pour les CIO et les CISO, cela se traduit par une meilleure gestion des risques et une réduction de la surface d'attaque. Pour les équipes techniques, cela permet des charges de travail sécurisées et agiles sans friction opérationnelle.

How World Bank manages hybrid cloud complexity with Terraform

La Banque mondiale a transformé son infrastructure en adoptant HCP Terraform, passant de processus manuels à une plateforme self-service en 30 minutes. Cette transformation a permis de gérer 27 000 ressources cloud et de soutenir 1 700 applications à travers Azure, AWS et GCP. La stratégie de plateforme de la Banque mondiale repose sur quatre piliers : l'expérience développeur, la sécurité intégrée, la gestion des secrets et les normes unifiées.

Défis des clouds hybrides

La Banque mondiale a rencontré plusieurs défis dans la gestion de son infrastructure hybride, notamment des processus manuels, la dérive de configuration, la conformité, les applications sur mesure et la charge cognitive. Pour surmonter ces défis, la Banque mondiale a adopté une stratégie de plateforme axée sur l'expérience développeur, la sécurité intégrée, la gestion des secrets et les normes unifiées.

Stratégie de plateforme

La stratégie de plateforme de la Banque mondiale est construite sur quatre piliers : l'expérience développeur, la sécurité intégrée, la gestion des secrets et les normes unifiées. La Banque mondiale a adopté une approche pyramidale pour implémenter sa stratégie de plateforme, en construisant d'abord les composants d'infrastructure nécessaires, puis en créant des bundles de modules ou des "templates" qui fournissent des déploiements complets et utilisables pour les développeurs. Enfin, la Banque mondiale a créé un "storefront" pour les plateformes, un portail développeur interne.

Workflow self-service avec Terraform

La Banque mondiale a mis en place un workflow self-service pour les développeurs, leur permettant de demander un produit de "golden path" dans le portail développeur interne. Ce processus déclenche un pipeline de gestion de plateforme qui déploie des espaces de travail HCP Terraform, préremplit toutes les variables, connecte l'agent qui exécutera la configuration et configure le dépôt Git avec les définitions de golden path. HCP Terraform exécute ensuite les plans et les exécutions pour déployer les motifs de golden path.

Sécurité intégrée dans le flux

La Banque mondiale a intégré la sécurité dans son flux de travail self-service. Lorsque l'exécution du plan Terraform est terminée, le plan est envoyé aux outils de sécurité de la Banque mondiale à l'aide d'une intégration de tâche Terraform. Les scans de sécurité ont lieu à la porte d'entrée de la provisioning. L'infrastructure ne se déploie que si elle est conforme aux normes de sécurité. Les vérifications de politique en tant que code ont également lieu à ce stade et sont appliquées automatiquement.

Vue d'architecture

La vue d'architecture de la Banque mondiale montre que chaque déploiement a un plan de ressources, un plan de plateforme et un plan de développeur. Le plan de ressources comprend les services consommés à partir d'Azure, AWS, GCP et on-prem. Le plan de plateforme utilise Terraform, Ansible et ArgoCD pour les pipelines de livraison de plateforme. Le plan de développeur offre la plus grande flexibilité, avec des IDE, des serveurs MCP et des outils AI comme Copilot.

Produits de plateforme : Application et données

La Banque mondiale a deux principaux produits de plateforme : Application et Data. Le produit Application comprend une pile centrale avec un VNet, des capacités d'interface utilisateur, d'API et de base de données, standardisé sur NodeJS, Java et .NET. Le produit Data comprend des options de calcul, de stockage et de capacités AI.

Opérations Day 2 pour les ingénieurs de plateforme

Les équipes de plateforme de la Banque mondiale sont devenues beaucoup plus productives en développant ces produits de plateforme. Au lieu de maintenir des dizaines de processus sur mesure et de traiter les tickets pour chaque demande de modification, elles peuvent effectuer de nombreuses tâches de maintenance et d'exploitation en masse et à grande échelle.

Résultats clés

La Banque mondiale a réalisé plusieurs impacts métriques majeurs grâce à la mise en œuvre de sa stratégie de plateforme, notamment une plus grande vitesse de livraison, une infrastructure standardisée dans l'organisation, une augmentation organique de la standardisation, une échelle et une portée, et une infrastructure sécurisée, cohérente et conforme.

Leçons apprises

La Banque mondiale a tiré six leçons majeures de sa transition vers une infrastructure cloud standardisée et automatisée. Ces leçons incluent l'importance de commencer petit, de standardiser et d'automatiser sans relâche, d'adopter des architectures modulaires et flexibles, d'appliquer les topologies d'équipe et les méthodes de travail agile, d'avoir une clarté sur les motifs qui servent une majorité de cas d'utilisation, et d'intégrer efficacement l'IA dans les flux de travail d'ingénierie de plateforme.

How Duke Energy enforces cloud security at scale with Terraform & Vault, and 6 lessons

Duke Energy, une entreprise de services publics régulée de 100 ans, a dû relever des défis uniques en matière de sécurité et de conformité lors de sa transition vers le cloud. En adoptant Terraform Enterprise et Sentinel, Duke Energy a pu standardiser la gestion de l'infrastructure, automatiser la gouvernance et centraliser la gestion des secrets, tout en réduisant la charge cognitive des développeurs.

De datacenters au cloud

Duke Energy a commencé sa transition vers le cloud en réalisant que ses datacenters vieillissants limitaient l'agilité, tandis que le cloud offrait de nouvelles possibilités. Cependant, cette transition a également introduit de nouvelles responsabilités en matière de sécurité qui ne pouvaient être résolues que par l'automatisation, la gouvernance et une expérience développeur standardisée.

Standardisation sur Terraform Enterprise et Sentinel

Duke Energy a adopté la version communautaire de Terraform pour apporter de la cohérence à la provisioning cloud. Cependant, le processus de revue manuelle des demandes de pull par les équipes de plateforme est devenu intenable à mesure que les équipes se multipliaient. Pour résoudre ce problème, Duke Energy a introduit un outil de politique de sécurité open source, mais a rapidement dépassé ses capacités. C'est alors qu'ils ont implémenté Terraform Enterprise et Sentinel. Sentinel évalue les plans Terraform avant l'application de l'infrastructure, agissant comme une porte de sécurité qui empêche les ressources non sûres d'être déployées.

Des secrets partout à une gestion centralisée des secrets

Un défi majeur dans l'adoption précoce du cloud par Duke Energy était la prolifération des secrets : les secrets étaient siloés et décentralisés dans plusieurs systèmes, selon l'équipe ou le cas d'utilisation. Ils ont implémenté HashiCorp Vault pour apporter plus de structure à la gestion des secrets, ce qui a atténué la plupart de la prolifération. Cependant, certaines applications AWS ont toujours besoin de secrets dans AWS Secrets Manager. Vault a également la capacité de synchroniser les secrets et d'intégrer divers magasins de secrets natifs du cloud afin que les secrets puissent toujours être gérés de manière centralisée dans un dépôt cloud-agnostique.

L'essor de l'infrastructure no-code

À mesure que l'utilisation du cloud augmentait, l'entreprise a atteint un mur d'échelle : les développeurs passaient plus de temps à déboguer les politiques Sentinel et à écrire du code Terraform qu'à construire des applications. Pour réduire la charge cognitive tout en préservant la sécurité, l'entreprise a commencé à utiliser des modules no-code Terraform - des constructions d'infrastructure pré-construites et durcies exposées à travers une interface simplifiée. Cela a permis aux développeurs de déployer des services comme les API Gateways ou S3 sans toucher au code Terraform.

Construction d'une plateforme de cycle de vie complet : De Day 0 à Day 2+

Le parcours cloud de Duke Energy a commencé avec des équipes réinventant la roue dans toute l'organisation. Ils voulaient un modèle plus structuré pour gouverner l'infrastructure cloud. En standardisant plusieurs processus en un seul, ils économisent du temps pour les développeurs et les opérateurs dans toute l'organisation, tout en rendant tout plus facile à maintenir pour l'équipe centrale de la plateforme. C'est le flux de travail d'automatisation de l'infrastructure et de la sécurité standardisé qu'ils ont construit jusqu'à présent.

Une meilleure expérience développeur, sans sacrifier la sécurité

L'histoire de Duke Energy montre que les développeurs heureux et une sécurité solide peuvent coexister. Un thème central dans le parcours de l'entreprise est que la sécurité et la productivité des développeurs peuvent se renforcer mutuellement lorsque l'automatisation est appliquée de manière réfléchie. En déplaçant la gouvernance dans le code de politique et en abstraisant l'infrastructure derrière des modules no-code, Duke Energy a réduit la friction des développeurs tout en renforçant la sécurité.

Prochaines étapes de Duke Energy

À l'avenir, Duke Energy vise à industrialiser l'ensemble du cycle de vie de l'infrastructure : un marché complet de modules no-code pour les motifs courants, la migration de Terraform Enterprise (auto-géré) vers HCP Terraform (SaaS), l'automatisation des opérations Day 2, les crédentiels dynamiques sécurisés via l'identité de la charge de travail, la gouvernance multi-cloud avec des politiques cloud-agnostiques dans Sentinel, et l'intégration plus rapide des services émergents comme AWS Bedrock.

Leçons apprises

L'histoire de Duke Energy offre plusieurs leçons claires pour les organisations qui évoluent de manière sécurisée dans le cloud : standardiser tôt et sans pitié, automatiser la gouvernance et non seulement la provisioning, réduire la charge cognitive pour les développeurs, centraliser les secrets et éliminer les crédentiels statiques, investir profondément dans l'automatisation des opérations Day 2+, et construire pour une maintenabilité à long terme.

KubeCon + CloudNativeCon Europe 2026 Co-located Event Deep Dive: Telco Day

Le Cloud Native Telco Day revient à KubeCon + CloudNativeCon Europe 2026 en tant qu'événement co-localisé à part entière, réunissant les communautés des télécommunications et du cloud native pour un échange technique approfondi et une collaboration concrète. Lancé en 2022 à Valence, le Cloud Native Telco Day a été créé pour combler le fossé entre les écosystèmes des réseaux et du cloud native. Cette mission est encore plus pertinente aujourd'hui. Les fournisseurs de télécommunications sont à un point d'inflexion où les systèmes d'IA et d'agents réshapent la manière dont les réseaux sont construits et exploités. Alors que le 5G mûrit et que l'industrie regarde vers le 6G et au-delà, les frontières entre les infrastructures réseau et cloud s'estompent. Les opérateurs télécoms adoptent les technologies CNCF à travers toutes les couches de la pile télécom pour permettre des opérations autonomes, des systèmes auto-optimisants et des architectures distribuées hautement qui doivent répondre à des exigences strictes de performance, de fiabilité et de sécurité.

Qui tirera le plus profit de cet événement ?

Les praticiens exploitant des infrastructures télécoms en production bénéficieront le plus de cet événement. Cet événement rassemble des études de cas du monde réel d'opérateurs déployant des technologies CNCF dans des réseaux en direct. Les participants peuvent apprendre directement de leurs pairs ce qui a fonctionné, ce qui n'a pas fonctionné, et comment éviter de répéter des erreurs coûteuses dans leurs propres environnements. Les équipes de plateforme construisant des plateformes internes pour développeurs et des piles télécoms cloud native gagneront également des informations pratiques sur la mise en réseau, l'observabilité, la gestion du cycle de vie GitOps et la gestion des charges de travail réseau distribuées à grande échelle. Les fournisseurs de fonctions réseau et les éditeurs entendront directement des opérateurs les exigences et contraintes cloud native, les aidant à mieux aligner avec les meilleures pratiques et les normes de certification CNF. Les mainteneurs de projets CNCF bénéficient également. Les charges de travail des télécommunications comportent souvent des contraintes uniques telles qu'une latence ultra-faible, une haute disponibilité et des exigences réglementaires. Le dialogue direct avec les opérateurs aide à garantir que les technologies CNCF continuent d'évoluer de manière à soutenir ces besoins du monde réel.

Ce qui est nouveau et différent cette année

Cette année marque une évolution importante pour le Cloud Native Telco Day. Après une salle complètement remplie l'année dernière à Londres, l'événement passe d'un format de demi-journée à un programme d'une journée complète. L'agenda comprend plus de sessions de panel pour encourager le dialogue ouvert entre les communautés et les perspectives. L'événement comptera avec la participation des sponsors Red Hat et Sylva/LFN tout en maintenant un focus neutre et communautaire. En outre, certains des sujets explorés lors du Cloud Native Telco Day se poursuivront dans des discussions techniques plus approfondies plus tard dans la semaine lors du jour du développeur du projet Sylva de la Linux Foundation Europe, donnant aux participants l'opportunité de prolonger les conversations et de plonger plus profondément dans les détails de mise en œuvre.

À quoi ressemblera la journée ?

Le Cloud Native Telco Day 2026 sera un événement d'une journée complète comprenant une session d'ouverture, sept conférences, trois panels, une conférence éclair et une session de clôture. La structure est conçue pour équilibrer la profondeur technique avec la discussion interactive. Au-delà de l'agenda formel, la journée est connue pour le partage informel de connaissances et les conversations inter-écosystèmes. Les opérateurs de télécommunications, les fournisseurs de fonctions réseau, les intégrateurs de systèmes mondiaux, les fournisseurs de matériel et les mainteneurs de projets open source se réunissent dans une même salle pour discuter des défis de production, des compromis architecturaux et des modèles émergents dans la transformation cloud native des télécommunications.

Faut-il faire des devoirs avant ?

Aucune préparation formelle n'est requise. Cependant, les participants peuvent bénéficier d'une familiarité avec les technologies CNCF couramment utilisées dans les environnements de télécommunications, ainsi qu'une compréhension de base de la virtualisation des fonctions réseau, du calcul en périphérie et des flux de travail GitOps. Venir préparé avec des défis de production spécifiques ou des questions architecturales peut aider à maximiser la valeur des discussions tout au long de la journée.

Trouvez votre communauté !

Le Cloud Native Telco Day renforce l'écosystème plus large en brisant les silos entre les communautés des télécommunications et du cloud native. Il soutient la collaboration inter-communautés, le partage de connaissances du monde réel et l'éducation technique ancrée dans l'expérience de production. Les opérateurs peuvent articuler leurs exigences directement aux mainteneurs de projets. Les mainteneurs reçoivent des retours d'expériences de déploiements réels. Les vendeurs et les intégrateurs entendent directement où les normes, les outils et les meilleures pratiques doivent être affinés. Le résultat est un meilleur alignement de l'écosystème et une progression partagée vers une infrastructure télécom résiliente, sécurisée et activée par l'IA construite sur des fondations cloud native.

Security Slam Returns for 2026 — Now Open to All Open Source Projects

Le CNCF Technical Advisory Group for Security & Compliance est ravi d'annoncer le retour du Security Slam 2026 lors de KubeCon + CloudNativeCon Europe, en partenariat avec Sonatype et OpenSSF. L'événement se déroulera du vendredi 20 février au vendredi 20 mars. Le Security Slam est une activité communautaire CNCF qui a pris de nombreuses formes au fil des ans. Maintenant dans sa cinquième itération, le Slam est conçu pour aider les projets à comprendre et à améliorer leur posture de sécurité globale.

Préparatifs et reconnaissance

Les événements précédents ont inclus diverses incitations pour encourager les projets à apporter les améliorations recommandées, comme les dons de Google en 2022 en faveur des projets atteignant certains jalons ou les prix LEGO décernés aux meilleurs contributeurs pour chaque projet participant en 2025. De même, l'événement a eu plusieurs variantes en termes de durée. Dans le cas du Kubernetes Lightning Round, le slam était une journée d'intégration de nouveaux contributeurs à Kubernetes avec un accent sur les améliorations d'hygiène de sécurité de sept sous-projets différents. Allant plus loin, l'événement 2025 a présenté des semaines de travail préparatoire avec les mainteneurs et des sessions en direct de 45 minutes avec les mainteneurs et toute personne souhaitant rejoindre l'audience à KubeCon + CloudNativeCon Europe. Cette année, cependant, imite l'événement qui a eu les résultats les plus statistiquement significatifs. En 2023, les projets ont reçu leurs propres badges à repasser et une plaque encadrée pour mettre en avant les jalons qu'ils ont atteints pendant l'événement de 30 jours. Non seulement les plaques étaient visibles aux tables des projets longtemps après la fin de l'événement, mais nous avons reçu des rapports de victoires significatives de projet grâce aux efforts réalisés lors de cet événement.

Éléments clés à retenir

Le projet durera environ un mois, menant à KubeCon. Le CNCF TAG Security & Compliance publiera une bibliothèque de ressources de soutien pour accélérer l'exécution des objectifs plus complexes. Des conseillers seront disponibles via un canal Slack dédié du CNCF tout au long du mois, pour offrir des clarifications et répondre aux questions relatives à l'hygiène de sécurité. Les projets participants recevront des plaques personnalisées pour démontrer leurs succès. Les contributeurs individuels recevront des badges correspondant aux objectifs complétés par le projet. Les projets en dehors du CNCF et de la Linux Foundation sont invités à participer. Des conseillers et des matériaux seront disponibles sur le sujet de la Cyber Resilience Act (CRA). La bibliothèque de Slam de cet événement sera hébergée en ligne sur securityslam.com.

Dates clés à retenir

Vendredi 20 février : Les objectifs de l'événement sont annoncés ; la bibliothèque Slam ouvre. Vendredi 20 mars : La soumission des scores finaux se clôt ; le scoring commence. Jeudi 26 mars : Les prix sont décernés sur la scène du pavillon des projets de KubeCon. L'inscription préalable est maintenant ouverte : inscrivez-vous pour recevoir des rappels et des instructions relatifs à l'événement !

What CNCF Project Velocity in 2025 Reveals About Cloud Native’s Future

Dix ans après le début du parcours de la CNCF, une chose n'a pas changé : nous continuons à nous appuyer sur des signaux réels - contributions open source, déploiements dans le monde réel et énergie communautaire - pour comprendre où nous allons. Le cloud native est désormais une infrastructure invisible, qui alimente discrètement notre vie quotidienne. En observant le rythme de l'activité des projets, nous avons une place de choix pour voir comment les équipes construisent l'avenir. Nous examinons des signaux tels que la fréquence des commits, la croissance des contributeurs, l'expansion de la communauté et les schémas de déploiement pour cartographier où le momentum se construit et comprendre pourquoi cela compte. Ces signaux nous donnent un moyen transparent d'identifier les technologies et les approches qui gagnent une traction réelle. Il ne s'agit pas seulement de ce qui est populaire, mais de ce qui est durable, de ce qui résout les problèmes réels et de ce qui est susceptible de façonner la prochaine phase de l'infrastructure cloud native.

Projet Velocity : Principaux enseignements

Voici ce qui ressort des données de 2025 : Kubernetes continue de diriger l'écosystème avec la plus grande base de contributeurs. Cette vitesse soutenue renforce son rôle de fondation de l'infrastructure moderne dans l'entreprise. Kubernetes continue de construire sur son succès alors qu'il évolue pour devenir un système d'exploitation critique derrière l'IA. Backstage a plus que doublé ses contributions depuis 2024. Grâce à son accent sur l'expérience développeur, il est le principal IDP open source, jouant un rôle fondamental dans la montée en puissance de l'ingénierie de plateforme. À mesure que de plus en plus d'organisations priorisent les plateformes internes pour accélérer la productivité et la cohérence des développeurs, Backstage devient une solution de référence. OpenTelemetry prend un sérieux élan, avec une augmentation de 39 % des commits et une base de contributeurs qui est passée de 1 301 à 1 756 en seulement un an ; soit une augmentation de 35 %. Maintenant, en tant que deuxième plus grand projet CNCF, il est clair que l'observabilité en temps réel devient essentielle à la manière dont les équipes construisent, exécutent et mettent à l'échelle les systèmes. Ce qui est excitant, c'est combien de ces tendances intersectent avec la montée en puissance des charges de travail d'IA. Des projets comme Kubernetes, Kubeflow et Crossplane sont de plus en plus utilisés comme fondation pour les systèmes d'entraînement et d'inférence. Avec le lancement du programme de conformité AI de Kubernetes et la dynamique autour de l'allocation dynamique des ressources (DRA), la communauté cloud native pose les bases d'un avenir où l'IA évolutive et portable fonctionne sur une infrastructure open source.

Conclusion

Il est toujours inspirant de voir l'énergie communautaire derrière ces projets. Chaque contribution compte - qu'il s'agisse de code, de documentation, de l'organisation d'un meetup ou du mentorat de quelqu'un de nouveau. Continuons à construire cet avenir ensemble. Tous les rapports actuels et passés sont disponibles sur GitHub.

Cluster API v1.12: Introducing in-place updates and chained upgrades

Cluster API apporte une gestion déclarative au cycle de vie des clusters Kubernetes, permettant aux utilisateurs et aux équipes de plateforme de définir l'état souhaité des clusters et de compter sur les contrôleurs pour les concilier en continu. De même que vous pouvez utiliser des StatefulSets ou des Deployments dans Kubernetes pour gérer un groupe de Pods, dans Cluster API vous pouvez utiliser KubeadmControlPlane pour gérer un ensemble de Machines de contrôle de plan, ou vous pouvez utiliser des MachineDeployments pour gérer un groupe de Nœuds travailleurs.

Emphase sur la simplicité et l'utilisabilité

Avec la version v1.12.0, le projet Cluster API démontre une fois de plus que cette communauté est capable de livrer une grande quantité d'innovation, tout en minimisant l'impact pour les utilisateurs de Cluster API. Que signifie cela en pratique ? Les utilisateurs doivent simplement changer la spécification du Cluster ou de la Machine (comme avec les versions précédentes de Cluster API), et Cluster API déclenchera automatiquement des mises à jour in situ ou des mises à niveau en chaîne lorsque cela est possible et conseillé.

Mises à jour in situ

Comme Kubernetes le fait pour les Pods dans les Deployments, lorsque la spécification de la Machine change, Cluster API effectue également des rollouts en créant une nouvelle Machine et en supprimant l'ancienne. Cette approche, inspirée du principe de l'infrastructure immuable, présente un ensemble d'avantages considérables : elle est simple à expliquer, prévisible, cohérente et facile à raisonner avec les utilisateurs et les ingénieurs. Elle est simple à implémenter, car elle repose uniquement sur deux primitives de base, create et delete. L'implémentation ne dépend pas des choix spécifiques aux Machines, comme le système d'exploitation, le mécanisme de bootstrap, etc. En conséquence, les rollouts de Machines réduisent considérablement le nombre de variables à prendre en compte lors de la gestion du cycle de vie d'un serveur hôte qui héberge des Nœuds.

Mises à niveau en chaîne

ClusterClass et les topologies gérées dans Cluster API ont fourni conjointement un cadre puissant et efficace qui agit comme une brique de construction pour de nombreuses plateformes offrant Kubernetes-as-a-Service. Maintenant, avec la version v1.12.0, cette fonctionnalité fait un pas en avant important, en permettant aux utilisateurs de mettre à niveau de plus d'une version mineure de Kubernetes en une seule opération, communément appelée mise à niveau en chaîne. Cela permet aux utilisateurs de déclarer une version Kubernetes cible et de laisser Cluster API orchestrer les étapes intermédiaires nécessaires de manière sûre, plutôt que de gérer manuellement chaque mise à niveau mineure.

Équipe de publication

Je tiens à remercier tous les contributeurs, les mainteneurs et tous les ingénieurs qui se sont portés volontaires pour l'équipe de publication. La fiabilité et la prévisibilité des publications Cluster API, l'une des caractéristiques les plus appréciées par nos utilisateurs, ne sont possibles que grâce au soutien, à l'engagement et au travail acharné de sa communauté. Félicitations à toute la communauté Cluster API pour la version v1.12.0 et toutes les excellentes versions livrées en 2025 ! Si vous êtes intéressé à vous impliquer, consultez les directives de contribution de Cluster API.

Et ensuite ?

Si vous lisez le manifeste Cluster API, vous pouvez voir comment le sous-projet Cluster API revendique le droit de rester inachevé, reconnaissant la nécessité de continuer à évoluer, à s'améliorer et à s'adapter aux besoins changeants des utilisateurs de Cluster API et de l'écosystème Cloud Native plus large. À mesure que Kubernetes lui-même continue d'évoluer, le sous-projet Cluster API avancera à ses côtés, en se concentrant sur des mises à niveau plus sûres, une réduction des perturbations et des briques de construction plus solides pour les plateformes gérant Kubernetes à grande échelle. L'innovation reste au cœur de Cluster API, restez à l'écoute pour des développements passionnants tout au long de 2026 !

Spotlight on SIG Architecture: API Governance

Dans cette série de spots SIG Architecture, nous avons discuté avec Jordan Liggitt, chef du sous-projet API Governance. Jordan Liggitt est un chrétien, mari, père de quatre enfants, ingénieur logiciel chez Google le jour, et musicien amateur en secret. Il est né au Texas (et aime toujours se réclamer de ce point d'origine), mais a vécu en Caroline du Nord pendant la majeure partie de sa vie. Il travaille sur Kubernetes depuis 2014. À cette époque, il travaillait sur l'authentification et l'autorisation chez Red Hat, et sa toute première demande de pull vers Kubernetes a tenté d'ajouter un serveur OAuth au serveur API Kubernetes. Elle n'a jamais quitté le statut de travail en cours. Il a fini par adopter une approche différente qui s'est superposée au serveur API Kubernetes de base dans un projet différent (spoiler alert : ceci est un présage), et il l'a fermée sans fusion six mois plus tard.

Objectifs et portée de l'API Governance

La surface de travail comprend toutes les différentes API que Kubernetes possède, et il existe des API que les gens ne réalisent pas toujours être des API : les drapeaux de ligne de commande, les fichiers de configuration, la manière dont les binaires sont exécutés, la manière dont ils parlent aux composants backend comme le runtime de conteneurs, et la manière dont ils persistent les données. Les gens pensent souvent à "l'API" comme n'étant que l'API REST… c'est la plus grande et la plus évidente, et celle avec le plus large public, mais toutes ces autres surfaces sont aussi des API. Leurs publics sont plus restreints, donc il y a plus de flexibilité, mais elles nécessitent néanmoins une considération. Les objectifs sont d'être stables tout en permettant l'innovation. La stabilité est facile si vous ne changez jamais rien, mais cela contredit l'objectif d'évolution et de croissance. Nous équilibrons donc "soyez stable" avec "autorisez le changement".

Impact des Custom Resource Definitions

Le moment charnière a été les Custom Resources. Avant cela, chaque API était conçue à la main par nous et entièrement revue. Il y avait des incohérences, mais nous comprenions et contrôlions chaque type et champ. Lorsque les Custom Resources sont arrivées, n'importe qui pouvait définir n'importe quoi. La première version ne nécessitait même pas de schéma. Cela les a rendus extrêmement puissants - cela a permis un changement immédiat - mais nous a laissés jouer à rattraper la stabilité et la cohérence. Lorsque les Custom Resources ont atteint la disponibilité générale (GA), les schémas sont devenus obligatoires, mais des échappatoires existaient encore pour la compatibilité descendante. Depuis lors, nous travaillons à donner aux auteurs de CRD des capacités de validation comparables aux intégrées. Les règles de validation intégrées pour les CRD ont atteint la GA dans les dernières versions. Ainsi, les CRD ont ouvert l'ère "tout est possible". Les règles de validation intégrées sont le deuxième jalon majeur : ramener la cohérence.

API Governance dans le contexte

API Machinery fournit le code et les outils réels sur lesquels les gens construisent des API. Ils ne révise pas les API pour le stockage, le réseau, l'ordonnancement, etc. SIG Architecture définit la direction globale du système et travaille avec API Machinery pour s'assurer que le système supporte cette direction. API Governance travaille avec les autres SIG qui construisent sur cette base pour définir des conventions et des motifs, garantissant une utilisation cohérente de ce que fournit API Machinery. Nous obtenons impliqué en deux endroits : la conception et l'implémentation. L'implication dans la conception augmente avant le gel des améliorations ; l'implication dans l'implémentation augmente avant le gel du code. Cependant, de nombreux efforts s'étendent sur plusieurs versions, donc il y a toujours une certaine conception et implémentation en cours, même pour le travail ciblant les versions futures. Entre ces périodes intenses, nous avons souvent le temps de travailler sur des travaux de conception à long terme.

S'impliquer

Il est généralement préférable de suivre un changement spécifique plutôt que d'essayer d'apprendre tout d'un coup. Choisissez un petit changement d'API, peut-être un que quelqu'un d'autre fait ou un que vous voulez faire, et observez le processus complet : conception, implémentation, revue. Les revues à haut débit - discussion en direct via vidéo - sont souvent très efficaces. Si vous faites ou suivez un changement, demandez s'il y a un moment pour passer en revue la conception ou la PR ensemble. Observer ces discussions est extrêmement instructif. Commencez par un petit changement. Ensuite, passez à un plus gros. Ensuite, peut-être une nouvelle API. Cela construit la compréhension des conventions telles qu'elles sont appliquées en pratique.

Commentaires finaux

La raison pour laquelle nous nous soucions tant de la compatibilité et de la stabilité, c'est pour nos utilisateurs. Il est facile pour les contributeurs de voir ces exigences comme des obstacles douloureux empêchant le nettoyage ou nécessitant un travail fastidieux… mais les utilisateurs se sont intégrés à notre système, et nous leur avons fait une promesse : nous voulons qu'ils nous fassent confiance pour ne pas rompre ce contrat. Donc, même lorsque cela nécessite plus de travail, ralentit les choses ou implique des duplications, nous choisissons la stabilité. Nous ne cherchons pas à être obstructifs ; nous essayons de rendre la vie agréable pour les utilisateurs. Beaucoup de nos questions portent sur l'avenir : vous voulez faire quelque chose maintenant… comment allez-vous l'évoluer plus tard sans le casser ? Nous supposons que nous en saurons plus à l'avenir, et nous voulons que la conception laisse de la place pour cela. Nous supposons également que nous ferons des erreurs. La question est alors : comment nous laissons-nous des avenues pour nous améliorer tout en maintenant les promesses de compatibilité ?

Sources

• Securing modern workloads with HashiCorp Vault and WIF
• How World Bank manages hybrid cloud complexity with Terraform
• How Duke Energy enforces cloud security at scale with Terraform & Vault, and 6 lessons
• KubeCon + CloudNativeCon Europe 2026 Co-located Event Deep Dive: Telco Day
• Security Slam Returns for 2026 — Now Open to All Open Source Projects
• What CNCF Project Velocity in 2025 Reveals About Cloud Native’s Future
• Cluster API v1.12: Introducing in-place updates and chained upgrades
• Spotlight on SIG Architecture: API Governance
• Automating AWS S3 with Terraform