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, nous avons exploré une variété de sujets passionnants dans le domaine du DevOps et du cloud computing. Nous avons commencé par examiner les meilleures pratiques pour la conception et la mise à l'échelle des modules Terraform, en nous concentrant sur des aspects tels que la portée, la stratégie de code, la sécurité et les tests. Nous avons également découvert le processus de Fannie Mae pour le développement de politiques en tant que code avec Terraform Enterprise et Sentinel, en mettant en lumière l'importance de l'automatisation et de la conformité dans les environnements réglementés. De plus, nous avons analysé les stratégies de Trust Bank pour coder rapidement et en toute sécurité, en mettant en avant leur approche "paved road" et l'intégration de l'IA dans leurs flux de travail. Nous avons également exploré des outils et techniques pour prévenir l'exposition des secrets dans les environnements IT, en soulignant l'importance de la sécurité proactive. Enfin, nous avons discuté de l'autoscaling efficace avec des projets open source comme KEDA et Karpenter, ainsi que de l'intégration de Kyverno avec les politiques Kubernetes pour une gestion plus complète des politiques. Ces articles offrent des perspectives précieuses pour les professionnels du DevOps, allant des juniors aux experts, et mettent en lumière les tendances et les meilleures pratiques actuelles dans le domaine.

Comment concevoir et dimensionner correctement les modules Terraform

La conception de modules Terraform efficaces nécessite une attention particulière à plusieurs aspects clés. Rene Schach, un consultant senior en cloud, a partagé ses insights lors de HashiDays 2025, en se concentrant sur le "rightsizing" des modules Terraform. Ce processus va au-delà du simple choix de la bonne quantité de ressources et se divise en quatre piliers principaux : la portée, la stratégie de code, la sécurité et les tests.

Définir la portée des modules

Chaque module Terraform doit servir un but spécifique et cibler un public bien défini. Avant de commencer à coder, il est crucial de comprendre qui utilisera le module et quel problème il est destiné à résoudre. Cela implique de parler aux utilisateurs cibles, d'identifier leurs flux de travail actuels et leurs défis, et de clarifier quels inputs ils ont besoin de contrôler. Les modules doivent représenter des cas d'utilisation réels de l'entreprise et des abstractions, plutôt que des meilleures pratiques théoriques tirées d'Internet.

Stratégie de code pour les modules

Les modules Terraform sont des artefacts logiciels qui doivent être versionnés, testés et structurés comme toute autre base de code. Une bonne structure améliore la maintenabilité et la lisibilité pour les nouveaux contributeurs. Il est recommandé de séparer les ressources Terraform en plusieurs fichiers en fonction de leur objectif, plutôt que de tout garder dans un seul fichier. Par exemple, un module Google Cloud Compute Engine (GCE) peut avoir des fichiers séparés pour les comptes de service et les machines virtuelles. Cela aide les équipes à identifier rapidement où se trouve une logique spécifique et facilite l'extension des modules sans confusion.

Sécurité des modules

Les modules définissent les garde-fous pour la provision de l'infrastructure. Il est essentiel de valider les entrées tôt et de limiter la configurabilité pour éviter les déploiements non sécurisés ou incohérents. Terraform permet la validation en ligne des variables d'entrée directement dans les définitions de variables. Par exemple, une validation peut garantir que les ressources ne sont déployées que dans des régions approuvées. Il est également important d'appliquer des politiques de sécurité à l'aide de frameworks comme Sentinel (HashiCorp) ou Open Policy Agent (OPA) pour une application centralisée des règles de conformité.

Tests des modules

Les tests des modules Terraform étaient autrefois fastidieux, mais le cadre de test natif de Terraform rend cette tâche pratique et intégrée. Il est recommandé d'utiliser la commande terraform test pour écrire et exécuter des tests en utilisant la syntaxe standard de configuration Terraform. Les tests doivent se concentrer sur des cas d'utilisation réels et des exigences organisationnelles, plutôt que de tenter de tester chaque combinaison d'entrées. Il est également important de tester les exemples fournis avec le module pour s'assurer que la documentation reste valide et que les exemples ne deviennent pas obsolètes.

Le processus de Fannie Mae pour le développement de politiques en tant que code avec Terraform Enterprise et Sentinel

Fannie Mae, l'une des plus grandes entreprises au monde, a adopté Terraform Enterprise et Sentinel pour automatiser le provisionnement de l'infrastructure cloud à grande échelle tout en atténuant les risques de sécurité et de conformité. Leur processus de développement de politiques en tant que code se compose de cinq étapes : les exigences, le développement, les tests, la revue et la publication.

Collecte des exigences

La première étape consiste à désigner un groupe transversal de parties prenantes, y compris des représentants de la plateforme, de la sécurité, de la conformité, du développement d'applications et d'autres départements pertinents. Une fois le groupe de parties prenantes en place, ils peuvent commencer à examiner les spécifications des exigences pour de nouvelles politiques Sentinel. Lorsqu'une personne souhaite proposer une politique, la première chose à faire est généralement de consulter la documentation spécifique du fournisseur Terraform pour le composant d'infrastructure concerné. Cette documentation est utilisée pour créer une spécification de politique Sentinel granulée. Fannie Mae inclut cinq sections dans chaque spécification : le type de ressource, les attributs, les valeurs autorisées et le niveau de mise en œuvre.

Développement des politiques

Fannie Mae utilise une méthodologie de branche de fonctionnalité standard pour construire leurs politiques Sentinel. Ils commencent par une branche de fonctionnalité pour chaque politique ou modification d'un ensemble de politiques. Une fois les modifications terminées, la branche de fonctionnalité est fusionnée dans la branche de publication où Sentinel obtient les politiques. Cette section de la présentation de Fannie Mae vous guide à travers la syntaxe des politiques dans quatre domaines : les imports, les ressources, les fonctions et les règles.

Tests des politiques

Après avoir construit une politique, il est nécessaire de s'assurer qu'elle fonctionne effectivement. Fannie Mae définit des cas de test qu'ils souhaitent couvrir avec une politique donnée. Dans quelles situations la politique réussit-elle ? Dans quelles situations la politique échoue-t-elle ? La section suivante de la présentation de Fannie Mae montre comment générer des tests de politique Sentinel pour valider ces cas de test. Il existe deux utilitaires dans Sentinel qui aident à la génération de tests : les mocks Sentinel et l'interface de ligne de commande Sentinel.

Revue des politiques

Fannie Mae a deux niveaux de revue de code de politique : la revue par les pairs et la revue de sécurité de l'information. La phase de revue met également en action les tests construits dans la phase précédente. Cette section de la présentation de Fannie Mae vous guide à travers leur pipeline de revue et de test : Une clé pour réduire les risques dans cette phase est de tester chaque cas de test pour chaque politique à chaque fois. La raison en est que si un fichier ou une fonction partagée par plusieurs politiques est modifié, cela peut affecter plus de politiques que celle actuellement traitée.

Publication des politiques

La dernière étape consiste à fusionner la branche de fonctionnalité pour la politique dans la branche de publication de l'ensemble de politiques. Cette section finale de la présentation de Fannie Mae vous guide à travers leur processus de publication et montre à quoi ressemblent les garde-fous Sentinel pour les développeurs utilisant Terraform dans leur travail quotidien.

Les 4 clés de Trust Bank pour coder rapidement et en toute sécurité

Trust Bank, avec une équipe d'environ 100 ingénieurs, a réussi à capturer 20 % de la population singapourienne en seulement deux ans. Leur succès repose sur leur capacité à avancer rapidement sans rien casser. Comme l'a souligné Rajay Rai, CIO de Trust Bank, la vitesse et la sécurité ne sont pas mutuellement exclusives ; elles sont essentielles lorsqu'on construit une banque, en particulier dans les services financiers.

Philosophie d'infrastructure : l'approche "paved road"

Trust Bank a bâti sa fondation sur l'infrastructure en tant que code, adoptant le concept "paved road" de Netflix. Cette architecture opinionnée fournit aux développeurs des modules préconstruits, sécurisés et des motifs standardisés. Leur cadre repose sur quatre principes : la sécurité et la conformité intégrées, une architecture opinionnée, une conformité continue et l'autonomie dans des limites responsables. Cette dernière est peut-être le principe le plus crucial. Les développeurs ont la liberté de bouger rapidement, mais dans des limites qui empêchent les mauvais résultats.

Acheter plutôt que construire pour les choses non différenciantes

Lors de la construction de leur plateforme, Trust Bank a opté pour les éditions commerciales de HashiCorp Terraform et Vault plutôt que de commencer par les éditions communautaires gratuites. Pour une startup mince et agile, payer pour des logiciels d'entreprise peut sembler contre-intuitif. Mais la raison de Raj est convaincante : "Quand vous êtes mince et agile, et que vous allez vraiment vite, vous voulez vous assurer que vous implémentez les meilleures pratiques du marché."

Se concentrer sur les opérations de jour 2

Là où la stratégie de Trust Bank diverge fortement de la plupart des entreprises, c'est dans leur concentration sur l'optimisation des déploiements initiaux (Jour 0 et Jour 1). Rajay souligne une réalité cruciale : "20-30 % est en amont lorsque vous le construisez. 70-80 % vient plus tard, n'est-ce pas ? Alors que vous avancez, vous devez constamment l'hydrater et vous assurer que vous réduisez le coût de maintenance au fil du temps."

Intégration de l'IA et des LLM

Trust Bank utilise déjà des flux de travail d'IA agentique tout au long de son processus de développement. Leurs intégrations d'IA comprennent : des résumés automatisés de révision de code qui déclenchent via des webhooks lorsque les développeurs soumettent des demandes de tirage, rendant les approbations plus rapides et plus faciles, la génération de code de migration qui réduit certaines de leurs tâches de migration de trois à quatre mois à moins d'un mois, la génération de politiques en tant que code utilisant des LLM pour générer des politiques plus efficacement, la sommation automatisée des notes de version et des modifications pour les outils utilisés dans leur environnement, comme Spring Boot.

Prévenir l'exposition des secrets dans l'IT : 4 outils et techniques

L'exposition des secrets tels que les mots de passe de bases de données, les jetons API et les clés de chiffrement peut entraîner des violations coûteuses. En 2025, le coût moyen d'une violation de données est de 4,4 millions de dollars, selon le rapport sur le coût des violations de données. Il est essentiel de prévenir l'exposition des secrets pour les équipes de sécurité. Le rapport 2025 de Verizon sur les enquêtes sur les violations de données le confirme, en constatant que 88 % des attaques ciblant les applications web impliquaient l'utilisation de identifiants compromis.

Injection de credentials et accès juste-à-temps (JIT)

Les méthodes traditionnelles d'octroi d'accès au système impliquent généralement le partage et le stockage de identifiants statiques. Cette mauvaise pratique augmente le risque de compromission des identifiants car ils sont généralement stockés en texte brut dans de multiples emplacements, partagés entre les opérateurs, tout en étant difficiles à révoquer en raison de leur usage élevé et de leur importance dans les opérations quotidiennes. HashiCorp Boundary résout ce problème en exigeant que l'utilisateur ne garde trace que de ses propres identifiants personnels, non privilégiés. Ce flux de travail de protection des secrets utilise les identifiants dynamiques de HashiCorp Vault pour l'authentification de session une fois que l'utilisateur est authentifié à Boundary.

Scanners de secrets préventifs

Vous ne pouvez pas sécuriser vos secrets (identifiants, jetons, clés, etc.) si vous ne savez pas où ils se trouvent. Il incombe aux équipes de sécurité et de plateforme de trouver des outils capables de découvrir et de remédier à la prolifération de secrets en scannant les identifiants non gérés et divulgués dans un large éventail de sources de données. Ces outils doivent trouver les secrets en texte brut non seulement dans les dépôts GitHub, mais aussi dans des endroits comme Slack, Jira et Confluence. Les meilleurs outils ne se contentent pas d'aider les équipes à prendre la voie de remédiation appropriée, ils empêchent également les développeurs de divulguer accidentellement des secrets dans l'historique Git.

Modules d'infrastructure en tant que code sécurisés par conception

L'un des principaux avantages de l'adoption des pratiques d'infrastructure en tant que code (IaC) est la réduction du risque d'erreur humaine en automatisant la provision et la gestion de l'infrastructure. En templatisant et en versionnant votre configuration d'automatisation d'infrastructure, vous pouvez prévenir l'exposition des secrets à chaque fois que vous provisionnez des ressources informatiques. Dans des outils IaC tels que HashiCorp Terraform, ce processus de durcissement de la sécurité est réalisé à l'aide de modules. Les équipes de plateforme, les opérations et les parties prenantes de la sécurité peuvent travailler ensemble pour intégrer des paramètres sécurisés dans les modules afin que les erreurs comme l'exposition des secrets ne se produisent jamais.

Jetons d'identité de charge de travail

Une autre tactique de sécurité qui devient courante est l'identité de charge de travail, également appelée fédération d'identité de charge de travail (WIF) pour certains fournisseurs de cloud. Cette technique utilise des jetons d'identité de charge de travail pour connecter les systèmes de provision d'infrastructure aux fournisseurs de cloud sans stocker de identifiants dans le processus. La durée de vie du jeton est très courte et il n'est utilisé que pour un déploiement. Pour chaque déploiement, le système génère automatiquement un tout nouveau jeton. Cela rend beaucoup plus difficile la découverte ou l'exposition de l'identifiant pendant sa courte durée de vie.

Autoscaling efficace : performance, fiabilité et coût avec des projets open source

Lors de ContainerDays à Hambourg, Kelsey Hightower a posé une question simple mais puissante : « Pourquoi parlons-nous encore des conteneurs ? » Sa remarque a résonné profondément — même à l'ère de l'IA, la communauté cloud-native affine toujours les fondamentaux de l'orchestration des conteneurs, de l'évolutivité et de l'efficacité. Dans cet article, nous explorerons comment des projets open source comme KEDA et Karpenter peuvent vous aider à équilibrer performance, fiabilité et coût dans l'autoscaling Kubernetes.

L'autoscaling Kubernetes implique des compromis

Lorsque nous parlons d'autoscaling Kubernetes, il ne s'agit pas simplement d'ajouter des réplicas ou des nœuds lorsque la demande augmente et de les supprimer lorsqu'elle diminue. Il faut équilibrer performance, fiabilité et coût — trois forces qui s'opposent constamment. La façon dont j'aime penser à ces trois piliers est comme un triangle, comme dans la figure suivante.

Performance

Avant de commencer à mettre à l'échelle, vous devez comprendre ce qui impacte réellement les performances de votre application — ce qui compte pour vos utilisateurs et parties prenantes. La plupart du temps, ils ne se soucient pas directement de l'utilisation du CPU ou de la mémoire. Ceux-ci peuvent être des indicateurs, mais ils ne racontent pas toujours toute l'histoire. Les équipes qui réussissent avec l'autoscaling suivent souvent des métriques telles que les requêtes par seconde, la latence, la profondeur de la file d'attente, le temps jusqu'au premier jeton, les jetons par seconde, ou même des métriques déclenchées par des événements provenant de sources externes comme les fournisseurs de cloud. Il n'y a pas de métrique "dorée" unique pour chaque charge de travail. Souvent, une combinaison fonctionne le mieux. C'est là que KEDA excelle. Même si vous mettez actuellement à l'échelle en fonction du CPU ou de la mémoire, KEDA prend en charge ces métriques — mais ouvre également la porte à des déclencheurs personnalisés et à des règles de mise à l'échelle composite pour des charges de travail plus complexes.

Coût

L'un des principaux moteurs de l'autoscaling est l'efficacité — utiliser uniquement les ressources nécessaires, quand vous en avez besoin. KEDA aide à dimensionner correctement les charges de travail en mettant à l'échelle les pods de manière intelligente, tandis que Karpenter le complète en provisionnant des nœuds juste-à-temps de manière optimisée en coût. Voici comment ils fonctionnent ensemble : Lorsque la demande augmente, KEDA ajoute plus de pods pour gérer la charge accrue. Lorsque les pods deviennent non planifiables en raison d'un manque de capacité, Karpenter provisionne de nouveaux nœuds pour répondre à cette demande.

Fiabilité

Le troisième pilier — la fiabilité — est là où les choses deviennent souvent délicates. L'autoscaling ajoute et supprime des Pods et des Nœuds dynamiquement, ce qui peut impacter la stabilité si vos applications ne sont pas conçues pour gérer les terminations gracieuses ou les changements soudains. Avant de traiter la fiabilité, définissez clairement vos SLAs et SLOs. Vous ne voulez pas sur-ingénier ou sur-dépenser si vos attentes de niveau de service ne le justifient pas. Par exemple, si votre SLA est une latence de 500 ms à 3 500 requêtes par seconde, concevez en conséquence — comprenez votre budget d'erreur et utilisez-le pour guider les compromis.

Kyverno vs politiques Kubernetes : comment Kyverno complète et achève les types de politiques Kubernetes

Avec l'ajout de ValidatingAdmissionPolicy et MutatingAdmissionPolicy dans Kubernetes, avez-vous encore besoin de Kyverno ? Cet article répond à la question en fournissant dix raisons pour lesquelles Kyverno est essentiel même lorsque vous utilisez les types de politiques Kubernetes. Avant Kyverno, la gestion des politiques dans Kubernetes était complexe et fastidieuse. Bien que le besoin de Policy as Code soit clair, les premières implémentations nécessitaient d'apprendre des langages complexes et n'implémentaient pas le cycle de vie complet de Policy as Code.

Application des politiques sur les ressources existantes

Lorsque de nouvelles politiques sont créées, elles doivent être appliquées aux ressources existantes. Les politiques Kubernetes ne s'appliquent qu'aux changements de ressources, et donc les violations de politique sur les ressources existantes ne sont pas signalées. Kyverno applique les politiques, y compris les types de politiques Kubernetes, sur toutes les ressources. Les politiques changent au fil du temps. Cela peut être pour s'adapter à de nouvelles fonctionnalités ou à de nouvelles fonctionnalités, ou pour corriger des problèmes dans la politique. Lorsque une politique change, elle doit être réappliquée à toutes les ressources. Les politiques Kubernetes sont intégrées dans le serveur API et ne sont pas réappliquées lorsque la politique change.

Réapplication des politiques en cas de modifications

Comme le code, les politiques évoluent avec le temps. Cela peut être pour s'adapter à de nouvelles fonctionnalités ou à de nouvelles fonctionnalités, ou pour corriger des problèmes dans la politique. Lorsque une politique change, elle doit être réappliquée à toutes les ressources. Les politiques Kubernetes sont intégrées dans le serveur API et ne sont pas réappliquées lorsque la politique change. Fournir des retours aux développeurs dès que possible dans un pipeline de déploiement est hautement souhaitable et a des avantages tangibles en termes de temps et de coûts. Le CLI Kyverno peut appliquer les types de politiques Kyverno et Kubernetes dans les pipelines CI/CD et IaC.

Test des politiques en tant que code

Comme tout logiciel, les politiques doivent être testées de manière approfondie avant le déploiement. Kyverno fournit des outils pour tester les types de politiques Kyverno et Kubernetes. Vous pouvez utiliser le CLI Kyverno pour les tests unitaires, et Kyverno Chainsaw pour les tests de comportement e2e. Kyverno permet de configurer des exceptions de politique pour exclure certaines ressources des politiques. Les exceptions Kyverno sont des ressources Kubernetes, ce qui permet de les visualiser et de les gérer via l'API Kubernetes en utilisant des outils standard.

Logique de politique complexe

Les politiques Kubernetes sont conçues pour des vérifications simples et ne peuvent s'appliquer qu'à la charge utile d'admission. Cela est souvent insuffisant, car les politiques peuvent avoir besoin de consulter d'autres ressources ou même de faire référence à des données externes. Ces types de vérifications ne sont pas possibles avec les politiques Kubernetes. De plus, les politiques MutatingAdmissionPolicy de Kubernetes ne peuvent pas correspondre aux sous-ressources et s'appliquer à une ressource. Kyverno prend en charge des fonctionnalités pour les politiques complexes, notamment des recherches API et une gestion des données externes. Kyverno offre également une bibliothèque CEL étendue avec des fonctions utiles nécessaires aux politiques complexes.

Vérification des images

Kyverno offre une vérification intégrée des signatures et attestations d'images OCI (Open Container Initiative) en utilisant les projets Sigstore’s Cosign ou CNCF’s Notary. Cela permet d'implémenter des cas d'usage de sécurité de la chaîne d'approvisionnement logicielle et d'atteindre des niveaux élevés de SLSA (Supply-chain Levels for Software Artifacts). En plus de la validation et de la mutation des ressources, les politiques sont un outil essentiel pour automatiser plusieurs tâches complexes d'ingénierie de plateforme. Par exemple, les politiques peuvent être utilisées pour générer automatiquement des valeurs par défaut sécurisées ou des ressources comme les politiques réseau, sur des déclencheurs flexibles tels que la création d'un namespace ou lorsque qu'une étiquette est ajoutée.

Kyverno partout

Alors que les types de politiques Kubernetes ne peuvent être appliqués qu'aux ressources Kubernetes, les politiques Kyverno peuvent être appliquées à toute charge utile JSON ou YAML, y compris les manifestes Terraform ou OpenTofu, d'autres manifestes IaC tels que CDK, et des artefacts de build tels que les Dockerfiles. Kyverno permet une approche unifiée de Policy as Code, ce qui est essentiel pour les équipes d'ingénierie de plateforme qui gèrent à la fois les clusters Kubernetes et les pipelines pour le CI/CD et l'IaC.

Automatiser les applications stateful avec les Operators Kubernetes

Si vous avez déjà eu des problèmes avec la mise à l'échelle des bases de données ou l'automatisation des mises à niveau dans Kubernetes, les Operators peuvent vous aider en vous faisant gagner du temps et des efforts. La gestion des applications Kubernetes complexes comme les bases de données, les files d'attente de messages et les systèmes distribués peut être vraiment difficile. Kubernetes gère bien les charges de travail simples, tandis que les grandes applications souffrent de problèmes de basculement, de mise à l'échelle, de sauvegarde et de mises à jour automatisées. Ces activités nécessitent souvent une expertise opérationnelle.

Qu'est-ce que les Operators Kubernetes ?

Les Operators sont des outils supplémentaires qui vous aident à gérer les applications complexes ou stateful dans Kubernetes. Il s'agit d'une combinaison de Controllers et de Définitions de Ressources Personnalisées (CRDs). Les Controllers sont les règles pour déployer, configurer, mettre à l'échelle, réparer et mettre à jour des ressources. Les CRDs vous permettent d'ajouter un nouveau type d'objet à Kubernetes. Les CRDs vous permettent également de décrire le type d'objet que vous souhaitez gérer, après quoi vous procédez à la création d'une Ressource Personnalisée (CR), qui est une instance du type d'objet que vous avez créé.

Différence entre les Controllers traditionnels Kubernetes et les Operators

Voici un aperçu de la différence entre le Controller Kubernetes et les Operators : Les Controllers Kubernetes sont principalement applicables pour la gestion des applications simples. Mais lorsqu'il s'agit de gérer des applications complexes ou stateful, ils ont des limitations. Ces contrôleurs natifs ne peuvent pas automatiser les opérations et les flux de travail spécifiques à l'application, rendant difficile la gestion de tâches comme le provisionnement de bases de données, les mises à niveau et la gestion de basculement de manière fiable.

Comment fonctionnent les Operators Kubernetes

Supposons que votre application soit prête, que vous ayez une configuration de base Kubernetes et un déploiement fonctionnel. Sans Operators, vous devrez installer et gérer l'application vous-même manuellement. Mais avec les Operators, vous pouvez exécuter ces processus automatiquement. Voici comment cela fonctionne : Une Ressource Personnalisée (CR) est un objet que vous créez pour contrôler un aspect particulier de votre application. Vous devez déclarer une CRD avant de pouvoir créer une CR. La CRD informe Kubernetes du nouveau type d'objet que vous créez.

Cas d'utilisation des Operators Kubernetes

Les Operators sont particulièrement utiles lorsqu'il s'agit de travailler avec des applications stateful ou complexes. Voici quelques scénarios pratiques où les Operators apportent une grande valeur et comment Middleware aide les équipes à obtenir plus de visibilité : La gestion des applications stateful, telles que les bases de données, peut être difficile car la récupération des données est cruciale. Les Operators aident à gérer ces charges de travail même lorsqu'un conteneur ou un pod s'arrête. Ils effectuent automatiquement des sauvegardes, des restaurations, des mises à l'échelle et des mises à niveau. Un bon exemple est l'Operator Postgres et MySQL.

Pourquoi avons-nous besoin des Operators ?

Les contrôleurs Kubernetes sont principalement applicables lorsqu'il s'agit de gérer des applications simples. Mais lorsqu'il s'agit de gérer des applications complexes ou stateful, ils ont des limitations. Ces contrôleurs natifs ne peuvent pas automatiser les opérations et les flux de travail spécifiques à l'application, rendant difficile la gestion de tâches comme le provisionnement de bases de données, les mises à niveau et la gestion de basculement de manière fiable. Sans Operators, la récupération manuelle des bases de données peut entraîner des heures de temps d'arrêt. Les Operators Kubernetes automatisent ces tâches, et les alertes en temps réel de Middleware vous permettent de détecter les problèmes tôt.

Les outils pour surmonter les 10 principaux défis DevOps

DevOps est une manière de travailler qui réduit les gaspillages. Il utilise des outils et des pratiques intelligents pour construire, tester et livrer des logiciels plus rapidement. Il rend les équipes plus rapides, les systèmes plus solides et les problèmes plus petits lorsqu'il est bien fait. Ce n'est pas juste une chose — il s'agit de faire fonctionner toute la machine mieux. Mais cela signifie que DevOps n'est pas seulement un ensemble d'outils ou de processus. C'est une manière de penser et une culture née du besoin de réparer quelque chose de cassé : le mur entre les développeurs et les opérations.

Le cycle infini du DevOps

DevOps n'est pas une ligne droite. Il se déplace en boucle — constant, connecté, jamais terminé. Les étapes sont simples : Planifier. Développer. Tester. Publier. Déployer. Exploiter. Surveiller. Feedback. Puis cela recommence. Chaque étape alimente la suivante, et chacune dépend de la dernière. Comme des engrenages dans une montre, tout s'arrête si un engrenage saute. Ce cycle n'est pas seulement une question de vitesse. Il s'agit de rythme, de équipes travaillant comme une seule. Si elles cessent de parler — si la planification ne correspond pas à la construction, si les opérations n'entendent pas les développeurs — les choses se cassent. Les bugs se cachent. Les releases échouent. Les clients partent. Le cycle n'est fort que lorsque les gens parlent, écoutent et réparent ce qui doit être réparé. Les outils aident, mais la communication fait tourner la boucle.

Les défis majeurs en DevOps

Même les meilleurs outils ne peuvent pas réparer une culture brisée. DevOps vit et meurt par la communication. Sans elle, même les meilleurs outils échouent. Avec elle, les équipes peuvent repérer les problèmes plus tôt, les résoudre plus vite et livrer des logiciels qui fonctionnent. Lisez la suite pour découvrir comment la communication fait avancer le DevOps et aide les équipes à surmonter les défis. Il existe un certain nombre d'outils CNCF pour améliorer la boucle : Kubernetes (Gradué) pour l'orchestration, Argo et Flux (Incubateur/Gradué) pour le CI/CD piloté par GitOps, Prometheus (Gradué) et OpenTelemetry (Incubateur) pour la surveillance et l'observabilité, Jaeger (Gradué) pour le traçage, et Linkerd (Gradué) pour la communication sécurisée du service mesh.

Inconsistances des environnements

Lorsque les environnements de développement, de test et de production ne correspondent pas, rien ne se comporte comme prévu. Les bugs apparaissent dans un endroit mais pas dans l'autre, et du temps est gaspillé à poursuivre des fantômes. Le problème n'est pas toujours le code — c'est là où le code s'exécute. Utilisez des outils CNCF comme Kubernetes et Helm (Gradué) pour standardiser les environnements. Silos d'équipe et lacunes de compétences : Les développeurs et les équipes d'exploitation parlent souvent des langues différentes. L'un bouge vite ; l'autre maintient les choses stables. Sans connaissances partagées ou formations croisées, ils tirent dans des directions opposées, ralentissent la progression et créent des tensions. Adopter le GitOps avec Argo ou Flux aligne les deux équipes sur un flux de travail partagé.

Pratiques obsolètes

Certaines équipes utilisent encore de vieilles méthodes — processus manuels, cycles de publication longs et approbations lentes. C'est comme essayer de gagner une course en voiture rouillée. Cela étouffe l'innovation et empêche les équipes de bouger à la vitesse DevOps. Les outils CI/CD CNCF comme Argo Workflows peuvent aider à moderniser les publications. Points aveugles de surveillance : Si vous ne voyez pas le problème, vous ne pouvez pas le résoudre. Les équipes sans surveillance appropriée réagissent trop tard — ou pas du tout. Les temps d'arrêt s'étirent, et les clients les ressentent avant que l'équipe ne le fasse. Prometheus, Grafana, OpenTelemetry et Jaeger fournissent une observabilité de la pile complète.

Goulots d'étranglement des performances CI/CD

Les builds échouent, les tests traînent, les déploiements s'étouffent dans des bugs de pipeline et des configurations CI/CD mal réglées transforment les publications rapides en embouteillages. Le système ralentit, et l'équipe aussi. Utilisez Argo CD ou Flux pour des pipelines cloud-native qui évoluent. Problèmes de compatibilité de l'automatisation : Tous les outils ne jouent pas bien ensemble — une version entre en conflit avec une autre, les mises à jour plantent le système et l'automatisation casse le flux au lieu de faire gagner du temps. Crossplane (Incubateur) permet une automatisation multi-cloud cohérente grâce à la gestion des infrastructures native Kubernetes.

Vulnérabilités de sécurité

Lorsque la sécurité est une après-pensée, des fissures apparaissent. Une seule violation peut défaire tout le reste. Ce n'est pas seulement un risque technique — c'est un risque de confiance. Falco (Incubateur) fournit une détection de menaces en temps d'exécution, et cert-manager (Gradué) automatise la gestion des certificats. Scalabilité de l'infrastructure de test : À mesure que les utilisateurs augmentent, les tests doivent aussi augmenter. Mais de nombreuses équipes atteignent le plafond. L'infrastructure de test ne peut pas suivre et les bugs passent à travers les mailles du filet. Exécuter des tests sur Kubernetes et utiliser KubeVirt (Incubateur) pour les charges de travail basées sur des machines virtuelles permet de faire évoluer les environnements de test.

Rapports de débogage peu clairs

Longs logs. Erreurs cryptiques. Personne ne sait ce qui s'est cassé ou pourquoi. Lorsque les rapports confondent plus qu'ils ne clarifient, les bugs persistent — et les tempêtes montent. Jaeger et OpenTelemetry améliorent le débogage et la visibilité des traces. Goulots d'étranglement dans la prise de décision : Il n'y a pas de propriétaire clair, pas de oui ou non rapide, et les équipes stagnent en attendant la permission. Le travail s'arrête et les publications prennent du retard. À la fin, personne n'est vraiment en charge. Les tableaux de bord Prometheus et Grafana fournissent des métriques claires pour des décisions plus rapides.

Comment surmonter les défis DevOps (et pourquoi la communication est clé)

Aucun outil magique ne résout le DevOps. Mais il y a quelque chose qui fonctionne : les gens qui parlent les uns aux autres. Des objectifs clairs. Moins de silos. Un travail partagé. Voici une liste de contrôle de ce qui aide et pourquoi c'est important. Créer un langage et des objectifs partagés : Les équipes ne peuvent pas construire la même chose si elles ne parlent pas la même langue. Utilisez des métriques communes — MTTR, temps de lead, taux d'erreur — pour ancrer le travail. Ces chiffres gardent tout le monde honnête. Ces objectifs entrent en conflit lorsque l'une des équipes pousse les fonctionnalités et l'autre corrige les incendies. Ne laissez pas les équipes optimiser en isolation. Faites-les partager la ligne d'arrivée.

Construire des pods cross-fonctionnels

Les équipes travaillent mieux lorsqu'elles sont assises ensemble et résolvent les problèmes côte à côte. Formez des pods — groupes stables de développeurs, d'opérations, de QA et de membres de l'équipe produit. Il est difficile de rester en silo lorsque vous partagez un stand-up. La proximité construit la confiance. Et la confiance fait avancer le code. Favoriser la sécurité psychologique : Les gens font des erreurs. C'est ainsi que les systèmes s'améliorent. Mais si les gens ont peur de parler, les problèmes restent enterrés. Lorsque les équipes se sentent en sécurité pour soulever les préoccupations ou admettre l'échec, elles se rétablissent plus vite et apprennent davantage. Les rapports d'incident réels ne cachent pas le blâme. Ils montrent la vérité, afin que la prochaine fois soit meilleure.

Standardiser les environnements

"Ça marchait sur ma machine" ne signifie rien si ça se casse en production. Utilisez l'infrastructure en tant que code et les outils cloud pour garder les environnements dev, test et prod cohérents. Lorsque l'environnement est le même partout, les surprises sont moins nombreuses. Kubernetes et Helm (Gradué) simplifient cela. Accélérer le CI/CD et les tests pour les performances : Un pipeline lent ralentit tout le monde. Accélérez-le avec des outils qui testent sur des appareils réels, mesurent les performances du navigateur et automatisent les chemins les plus critiques. Il ne s'agit pas de tester plus — il s'agit de tester intelligemment. Argo CD et Flux améliorent les performances.

Assurer la surveillance et la sécurité continues

Vous ne pouvez pas réparer ce que vous ne voyez pas. Utilisez des outils comme Nagios ou Prometheus pour surveiller le système. Intégrez la sécurité à chaque étape — utilisez des scanners, des audits et des analyses de code statique. La sécurité n'est pas la dernière étape — c'est chaque étape. Falco et cert-manager assurent la sécurité en temps d'exécution et lors du transport. Améliorer la lisibilité des rapports : Les longs logs et les tableaux de bord encombrés n'aident pas. Utilisez des graphiques clairs, des tableaux de bord visuels et des outils comme BrowserStack Test Insights pour rendre les résultats évidents — même pour les équipes non techniques. Lorsque tout le monde peut lire les données, tout le monde peut agir. Les tableaux de bord Jaeger et Grafana aident ici aussi.

Ce à quoi ressemble une culture DevOps réussie

Vous voulez voir le DevOps fait correctement ? Regardez Netflix. Ils avaient un problème simple : évoluer rapidement, ne pas casser. Alors, ils ont changé la façon dont leurs équipes travaillaient. Plus de silos. Ils ont construit des équipes croisées — développeurs, opérations, QA tous dans la même équipe. Ils ne travaillaient pas juste à côté les uns des autres. Ils travaillaient ensemble. Ils parlaient tous les jours. Ils faisaient des rétrospectives. Lorsque quelque chose se cassait, ils ne le cachaient pas — ils l'écrivaient, l'étudiaient et s'assuraient que cela ne se reproduirait pas. Ils utilisaient des outils comme Slack pour parler, Jira pour suivre et GitHub pour livrer. Ces outils comptent. Mais le changement fondamental est venu de la confiance, du feedback et du but partagé.

La ligne de fond : la communication est la plus grande force du DevOps

DevOps n'est pas seulement construit en code. C'est une routine intégrée. Les meilleures équipes ne s'attendent pas aux problèmes — elles se réunissent tous les jours pour en parler. Ils regardent en arrière après chaque sprint. Ils écrivent ce qui s'est cassé, pourquoi et comment s'assurer que cela ne se reproduira pas. DevOps vit et meurt par la façon dont les équipes se parlent les unes aux autres — pas seulement quand quelque chose se casse. Les meilleures équipes ne bougent pas seulement vite — elles bougent ensemble. Ils partagent le même objectif, parlent la même langue et réparent les choses avant qu'elles ne tombent en panne. Les pipelines aident. Les outils aident. Mais quand DevOps échoue, il échoue au niveau de l'alignement, pas de l'automatisation.

Cloud Native & Kubernetes AI Day

Cloud Native & Kubernetes AI Day accueille les communautés de l'IA/ML et du High Performance Computing (HPC). Depuis 2022, il y a eu plusieurs événements dédiés (Batch / HPC et Cloud Native AI days), mais étant donné le chevauchement des exigences, des projets et des intérêts des utilisateurs finaux, il est devenu clair que nous nous intégrons mieux ensemble. Cloud Native & Kubernetes AI Day rassemble une diversité de passionnés techniques, de contributeurs open source, de praticiens, de chercheurs et d'utilisateurs finaux. Tous unis par un objectif commun : améliorer Kubernetes comme l'outil ultime de gestion d'infrastructure pour les charges de travail de recherche et d'IA/ML.

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

L'événement Cloud Native & Kubernetes AI Day s'adresse aux praticiens expérimentés ainsi qu'à ceux qui débutent dans les mondes du calcul par lots et des MLOps. Toute personne cherchant des solutions et des bonnes pratiques pour fournir une infrastructure rentable et efficace afin de mettre à l'échelle les charges de travail de calcul par lots, d'entraînement et d'inférence, de faire le meilleur usage des accélérateurs matériels rares et coûteux et de gérer efficacement les LLM et l'infrastructure agentique. Cet événement aidera également les praticiens des MLOps à interagir avec les mainteneurs des projets Cloud Native AI et à favoriser la collaboration entre les deux mondes.

Qu'y a-t-il de nouveau et de différent cette année ?

Le thème de cette année est « agent », avec de multiples références et rapports sur l'IA agentique et l'infrastructure cloud native qui la soutient. Cet événement sera une opportunité unique de se connecter et de réseauter avec les personnes qui pilotent cette nouvelle génération d'infrastructure. Nous aurons une journée complète avec 10 sessions complètes et 4 présentations éclair, et suffisamment de temps pour poser des questions pendant les sessions et discuter lors des pauses. Nous entendrons des chercheurs, des mainteneurs de projets et de nombreux utilisateurs finaux rapportant des succès et des défis de l'exécution de charges de travail d'IA/ML sur une infrastructure cloud native.

Devrais-je faire des devoirs en premier ?

Aucune préparation formelle n'est requise, mais envisagez de consulter le programme à l'avance afin de pouvoir préparer à poser ou à soulever des sujets particuliers qui vous intéressent ou qui intéressent votre organisation. C'est une opportunité unique de rencontrer et d'apprendre des meilleurs praticiens de l'industrie et une bonne chance de soulever également vos exigences particulières et d'aider à tracer la voie pour notre communauté.

Un mot spécial des présidents du programme

Les nouveaux outils supportant l'infrastructure Agentic AI : Les derniers mois ont été uniques en nombre et en qualité des outils supportant les LLM et l'infrastructure Agentic AI. Ce sera une grande opportunité d'en savoir plus sur l'état actuel et la direction que prend la communauté. Histoires de réussite et cas d'utilisation réels : Dans le domaine en rapide évolution de l'IA/ML, écouter les histoires d'utilisateurs finaux (à la fois les défis et les succès) est extrêmement important pour comprendre ce qui fonctionne et pour quels cas d'utilisation. Les politiques jouent un rôle crucial dans la gestion et la sécurisation des clusters Kubernetes. Mais saviez-vous comment ces politiques sont développées, implémentées et standardisées dans l'écosystème Kubernetes ? Pour répondre à cela, jetons un coup d'œil rétrospectif au travail du groupe de travail sur les politiques.

Le groupe de travail sur les politiques

Le groupe de travail sur les politiques était dédié à une mission critique : fournir une architecture globale qui englobe à la fois les implémentations actuelles liées aux politiques et les propositions futures de politiques dans Kubernetes. Leur objectif était à la fois ambitieux et essentiel : développer une architecture de politique universelle qui bénéficie aux développeurs et aux utilisateurs finaux. Grâce à des méthodes collaboratives, ce groupe de travail a cherché à apporter clarté et cohérence au monde souvent complexe des politiques Kubernetes. En se concentrant à la fois sur les implémentations existantes et les propositions futures, ils ont garanti que le paysage des politiques dans Kubernetes reste cohérent et accessible à mesure que la technologie évolue.

Introduction

Bonjour, merci pour le temps ! Commençons par quelques présentations, pourriez-vous nous dire un peu sur vous, votre rôle et comment vous vous êtes impliqué dans Kubernetes ? Jim Bugwadia : Mon nom est Jim Bugwadia, et je suis co-fondateur et PDG de Nirmata, qui fournit des solutions pour automatiser la sécurité et la conformité des charges de travail cloud-native. Chez Nirmata, nous travaillons avec Kubernetes depuis son début en 2014. Nous avons initialement construit un moteur de politique Kubernetes dans notre plateforme commerciale et l'avons ensuite donné à la CNCF en tant que projet Kyverno. J'ai rejoint le groupe de travail Kubernetes Policy de la CNCF pour aider à construire et à standardiser divers aspects de la gestion des politiques pour Kubernetes et suis ensuite devenu co-président.

À propos des groupes de travail

Une chose que je ne connais même pas est la différence entre un groupe de travail et un SIG. Pouvez-vous nous aider à comprendre ce qu'est un groupe de travail et comment il diffère d'un SIG ? Contrairement aux SIG, les groupes de travail sont temporaires et axés sur la résolution de problèmes spécifiques ou de projets transversaux qui peuvent impliquer plusieurs SIG. Leur durée de vie est définie, et ils se dissolvent une fois qu'ils ont atteint leur objectif. En règle générale, les groupes de travail ne possèdent pas de code ni n'ont de responsabilité à long terme pour la gestion d'une partie particulière du projet Kubernetes.

Vous avez mentionné que les groupes de travail impliquent plusieurs SIG. Avec quels SIG le groupe de travail sur les politiques était-il étroitement impliqué, et comment avez-vous coordonné avec eux ?

Le groupe a collaboré étroitement avec Kubernetes SIG Auth tout au long de notre existence, et plus récemment, le groupe a également travaillé avec SIG Security depuis sa formation. Notre collaboration s'est déroulée de plusieurs manières. Nous avons fourni des mises à jour périodiques lors des réunions du SIG pour les tenir informés de nos progrès et activités. De plus, nous utilisons d'autres forums communautaires pour maintenir des lignes de communication ouvertes et nous assurer que notre travail s'alignait avec l'écosystème Kubernetes plus large. Cette approche collaborative a aidé le groupe à rester coordonné avec les efforts connexes dans la communauté Kubernetes.

Groupe de travail sur les politiques

Pourquoi le groupe de travail sur les politiques a-t-il été créé ? Pour permettre une large gamme de cas d'utilisation, nous reconnaissons que Kubernetes est alimenté par un système de gestion de configuration hautement déclaratif, granulaire et extensible. Nous avons observé qu'un manifeste de configuration Kubernetes peut avoir différentes parties importantes pour divers parties prenantes. Par exemple, certaines parties peuvent être cruciales pour les développeurs, tandis que d'autres peuvent être d'un intérêt particulier pour les équipes de sécurité ou aborder des préoccupations opérationnelles. Compte tenu de cette complexité, nous croyons que les politiques régissant l'utilisation de ces configurations complexes sont essentielles pour réussir avec Kubernetes.

Pouvez-vous me donner une idée du travail que vous avez fait dans le groupe ?

Nous avons travaillé sur plusieurs projets liés aux politiques Kubernetes. Nos initiatives comprenaient : Nous avons travaillé sur une Proposition d'Amélioration Kubernetes (KEP) pour l'API des Rapports de Politiques Kubernetes. Cela vise à standardiser la manière dont les rapports de politiques sont générés et consommés dans l'écosystème Kubernetes. Nous avons mené une enquête CNCF pour mieux comprendre l'utilisation des politiques dans l'espace Kubernetes. Cela a permis de jauger les pratiques et les besoins à travers la communauté à l'époque.

Pouvez-vous nous dire quels étaient les principaux objectifs du groupe de travail sur les politiques et certaines de vos réalisations clés ?

La charte du groupe de travail sur les politiques était de contribuer à la standardisation de la gestion des politiques pour Kubernetes et d'éduquer la communauté sur les meilleures pratiques. Pour accomplir cela, nous avons mis à jour la documentation Kubernetes (Politiques | Kubernetes), produit plusieurs livres blancs (Gestion des politiques Kubernetes, GRC Kubernetes), et créé l'API des rapports de politiques (Référence de l'API) qui standardise les rapports à travers divers outils. Plusieurs outils populaires tels que Falco, Trivy, Kyverno, kube-bench, et autres prennent en charge l'API des rapports de politiques. Une étape majeure pour le groupe de travail sur les politiques a été de promouvoir l'API des rapports de politiques au niveau d'API SIG ou de lui trouver un logement stable.

Quels étaient certains des principaux défis auxquels le groupe de travail sur les politiques a été confronté ?

Lors de notre travail dans le groupe de travail sur les politiques, nous avons rencontré plusieurs défis : L'un des principaux problèmes que nous avons rencontrés était de trouver du temps pour contribuer de manière cohérente. Étant donné que beaucoup d'entre nous avons d'autres engagements professionnels, il peut être difficile de consacrer du temps régulier aux initiatives du groupe de travail. Un autre défi que nous avons rencontré était lié à notre modèle de consensus. Bien que cette approche garantisse que toutes les voix soient entendues, elle peut parfois conduire à des processus de prise de décision plus lents. Nous valorisions les discussions approfondies et l'accord, mais cela peut parfois retarder la progression de nos projets.

Pouvez-vous m'en dire plus sur ces défis ? Comment les avez-vous découverts ? Quel a été l'impact ? Quelles étaient certaines des stratégies que vous avez utilisées pour les résoudre ?

Il n'y a pas de réponses faciles, mais avoir plus de contributeurs et de mainteneurs aide grandement ! Globalement, la communauté CNCF est formidable pour travailler avec et est très accueillante pour les débutants. Alors, si les gens hésitent à s'impliquer, je les encourage vivement à assister à une réunion de WG ou de SIG et à simplement écouter. Il faut souvent quelques réunions pour comprendre pleinement les discussions, alors ne vous découragez pas si vous ne comprenez pas tout tout de suite. Nous avons fait un point d'insister sur cela et encouragé les nouveaux membres à consulter la documentation comme point de départ pour s'impliquer.

Conclusion

Le groupe de travail, et en particulier les personnes qui ont participé à cet article, espèrent que cela vous a donné quelques informations sur les objectifs et le fonctionnement du groupe. Vous pouvez obtenir plus d'informations sur les groupes de travail ici. Aucune source disponible pour cette semaine.