https://blogppr.alterway.fr/2025-07-17T10:00:00+02:002025-07-17T10:00:00+02:002025-07-17T10:00:00+02:00Asmaa Maakeltag:blogppr.alterway.fr,2025-07-17:/ameliorer-la-developer-experience-avec-backstage-le-pari-reussi-de-safran-et-aws.html

<p>Retour d’expérience d'AWS et Safran sur la Developer Experience avec Backstage à l'AWS Summit 2025</p>

<h1>Améliorer la Developer Experience avec Backstage : le pari réussi de Safran et AWS</h1> <p>Créer une <strong>plateforme de développement interne</strong> capable de <strong>booster la productivité</strong>, <strong>simplifier l'onboarding</strong> et <strong>unifier l'accès aux outils techniques</strong> est devenu un enjeu stratégique. Lors de l’AWS Summit, <strong>Safran</strong> et <strong>AWS</strong> ont partagé une mise en œuvre concrète autour de <strong>Backstage</strong>, la solution open source développée par <strong>Spotify</strong>.</p> <h2>Pourquoi miser sur le Platform Engineering ?</h2> <p>Dans les organisations tech modernes, les développeurs sont confrontés à :</p> <ul> <li>Des <strong>stacks techniques</strong> de plus en plus complexes</li> <li>Une <strong>multitude d’outils</strong> CI/CD, cloud, sécurité, monitoring, etc.</li> <li>Une <strong>courbe d’apprentissage</strong> souvent décourageante pour les nouveaux arrivants</li> </ul> <p>Le <strong>Platform Engineering</strong> vise à répondre à ces problématiques en créant une <strong>plateforme interne</strong> (<em>IDP – Internal Developer Platform</em>) centralisée, cohérente, et automatisée.</p> <blockquote> <p><strong>Objectif</strong> : offrir aux développeurs plus d'<strong>autonomie</strong>, tout en gardant un <strong>cadre sécurisé</strong>, <strong>standardisé</strong> et <strong>gouverné</strong>.</p> </blockquote> <p>Une bonne IDP réduit les <strong>frictions</strong>, <strong>accélère les mises en production</strong>, et favorise la <strong>satisfaction des équipes tech</strong>.</p> <h2>Backstage, la fondation open source signée Spotify</h2> <p><strong>Backstage</strong> est un <strong>portail de développement interne</strong>, extensible et modulaire. Il permet aux entreprises de créer une <strong>interface unifiée</strong> pour gérer leurs composants logiciels.</p> <h3>Ce que Backstage apporte :</h3> <ul> <li><strong>Software Catalog</strong> : visibilité sur tous les services, APIs, composants, microservices</li> <li><strong>Scaffolder</strong> : génération de projets via des <strong>templates prédéfinis</strong></li> <li><strong>TechDocs</strong> : <strong>documentation générée</strong> à partir du code (Markdown + CI)</li> <li><strong>Plugins</strong> : intégrations avec Jenkins, GitLab, ArgoCD, Prometheus, etc.</li> </ul> <p>Backstage agit comme un <strong>tableau de bord complet</strong> pour les développeurs, où tout est à portée de clic.</p> <h2>Harmonix : l'accélérateur AWS</h2> <p>Pour déployer Backstage rapidement et de manière sécurisée sur AWS, les équipes ont créé <strong>Harmonix</strong>, une <strong>surcouche d’intégration cloud-native</strong>.</p> <h3>Harmonix inclut :</h3> <ul> <li><strong>Infrastructure as Code</strong> avec <strong>AWS CDK</strong></li> <li><strong>Authentification intégrée</strong>, <strong>RBAC</strong>, et <strong>logs d’audit</strong></li> <li><strong>Plugins AWS</strong> (CodePipeline, ECS, IAM, CloudWatch)</li> <li><strong>Déploiement préconfiguré</strong>, prêt à l'emploi</li> </ul> <p><strong>En résumé</strong> : Harmonix fournit une <strong>base solide</strong> pour implémenter Backstage à grande échelle, sans repartir de zéro.</p> <h2>Le retour d’expérience de Safran</h2> <p><strong>Safran</strong>, acteur majeur de l’aéronautique, devait répondre à une problématique courante dans les grandes organisations : <strong>comment standardiser le delivery logiciel</strong> sur plusieurs entités tout en laissant de l'<strong>autonomie</strong> aux équipes locales.</p> <p>Ils ont déployé <strong>Backstage</strong>, enrichi d’<strong>Harmonix</strong>, avec des résultats concrets.</p> <p>L’objectif était de <strong>centraliser la création de services</strong>, <strong>réduire la dépendance</strong> aux équipes plateforme, <strong>uniformiser les pratiques DevOps</strong>, et <strong>accélérer l’onboarding</strong> des nouveaux développeurs.</p> <p>Cela s’est concrétisé par la <strong>création de templates standardisés</strong> pour les microservices, l’<strong>intégration fluide avec les outils existants</strong> (GitLab, Jenkins, SonarQube), un <strong>accès direct aux pipelines, logs et documentation</strong>, ainsi qu’un <strong>catalogue de composants</strong> pour mieux visualiser l’état de l’écosystème interne.</p> <h3>Résultats observés :</h3> <ul> <li>Un <strong>onboarding réduit de plusieurs jours à quelques heures</strong></li> <li>Une <strong>chute significative des tickets</strong> vers l’équipe plateforme</li> <li>Une <strong>visibilité complète</strong> sur les services en place</li> <li>Une <strong>adoption rapide</strong> dans plusieurs unités du groupe</li> </ul> <h2>Une plateforme pensée pour l’autonomie</h2> <p>Lors de la démonstration live, les intervenants ont illustré un cas d’usage typique :</p> <ol> <li>Création d’un service via un <strong>template</strong> dans Backstage </li> <li>Génération automatique de la <strong>CI/CD</strong> </li> <li>Documentation créée et <strong>accessible immédiatement</strong> </li> <li><strong>Monitoring intégré</strong> via Prometheus et Grafana</li> </ol> <p>Ce <strong>workflow fluide</strong> permet à un développeur de <strong>livrer un service complet en toute autonomie</strong>, dans un environnement <strong>sécurisé et standardisé</strong>.</p> <h2>Les défis rencontrés</h2> <p>Même si la mise en œuvre a été un succès, elle n’a pas été exempte de <strong>défis</strong> :</p> <ul> <li>Une certaine <strong>résistance au changement</strong> de la part des équipes</li> <li>Une <strong>dette technique</strong> rendant certains projets difficilement standardisables</li> <li>La nécessité de <strong>développer des connecteurs spécifiques</strong> pour certains outils internes</li> </ul> <p>Ces obstacles ont été levés grâce à une <strong>approche progressive</strong>, une <strong>gouvernance claire</strong>, et un <strong>soutien fort du management</strong>.</p> <h2>Ce qui attend Safran et AWS</h2> <p>Safran prévoit désormais de <strong>généraliser l’utilisation de Backstage</strong> à tout le groupe, en y ajoutant des modules de <strong>test automatisé</strong>, de <strong>sécurité</strong>, et en construisant des <strong>plugins internes</strong> pour répondre à des besoins métiers spécifiques.</p> <p>AWS, de son côté, continue d’améliorer Harmonix pour :</p> <ul> <li><strong>Supporter des déploiements hybrides</strong> (on-prem + cloud)</li> <li><strong>Renforcer la sécurité</strong> et l’<strong>observabilité</strong></li> <li><strong>Améliorer l'expérience développeur</strong> grâce à de nouveaux plugins</li> </ul> <h2>Conclusion : de l’expérience développeur à l’impact business</h2> <p>Ce retour d’expérience montre à quel point <strong>l’expérience développeur est devenue un facteur de performance</strong> pour les organisations tech. <strong>Backstage</strong>, avec <strong>Harmonix</strong>, permet de structurer un environnement de développement <strong>moderne</strong>, <strong>accessible</strong>, <strong>cohérent</strong> et <strong>sécurisé</strong>.</p> <p>En investissant dans une <strong>IDP bien conçue</strong>, les entreprises peuvent :</p> <ul> <li><strong>Accélérer leur cycle de livraison</strong></li> <li><strong>Standardiser les bonnes pratiques</strong></li> <li><strong>Mieux gérer leur patrimoine logiciel</strong></li> <li><strong>Attirer et fidéliser les talents tech</strong></li> </ul> <p>L’avenir du DevOps passe par des <strong>plateformes pensées pour les développeurs</strong>. <strong>Backstage est l’outil qui leur donne enfin les moyens d’agir.</strong></p>2025-07-01T18:00:00+02:002025-07-01T18:00:00+02:00Asmaa Maakeltag:blogppr.alterway.fr,2025-07-01:/industrialiser-le-rag-pour-booster-lia-generative-lapproche-pragmatique-en-2025.html

<p>Retour d’expérience de BUreau Veritas et focus sur le RAG à l'AWS Summit 2025</p>

<h1>Industrialiser le RAG pour booster l’IA générative : l’approche pragmatique en 2025</h1> <p><em>Explorée en profondeur lors du AWS Summit Paris 2025, cette approche basée sur le RAG (Retrieval-Augmented Generation) s’impose comme une réponse concrète aux limites actuelles de l’IA générative en entreprise.</em></p> <hr /> <h2>Un constat alarmant, une promesse ambitieuse</h2> <p>Le constat est clair : selon Gartner, 60 % des projets d’intelligence artificielle échouent, essentiellement par manque de données appropriées. Pour inverser cette tendance, de plus en plus d’organisations misent sur une architecture de RAG — Retrieval-Augmented Generation — industrialisée et sécurisée.</p> <p>À l’ère de l’IA générative, plusieurs enjeux freinent les entreprises : comment s’assurer de la fiabilité des réponses ? Quel modèle choisir ? Comment rester conforme aux exigences de sécurité et de confidentialité ? Quel budget prévoir ? Le RAG, dans ce contexte, s’impose comme un compromis stratégique.</p> <hr /> <h2>RAG : le bon compromis pour une IA efficace</h2> <p>Il existe plusieurs manières de personnaliser un modèle de langage. Le prompt engineering est rapide, mais souvent limité. À l’autre extrême, le fine-tuning est puissant mais complexe, long et coûteux.</p> <p>Le RAG repose sur un principe simple : plutôt que de modifier le modèle, on lui fournit le bon contexte au moment de la requête, en allant chercher l’information dans une base documentaire interne. Pas besoin de réentraînement. Pas besoin de déplacer les données sensibles. Et surtout, des résultats pertinents dès la première itération.</p> <hr /> <h2>Comment fonctionne un système RAG</h2> <p>Tout commence par la collecte des contenus internes : documents, bases de connaissances, FAQs, pages intranet, etc. Ces fichiers sont nettoyés, découpés et transformés en vecteurs numériques grâce à un modèle d’embedding. Ces vecteurs sont ensuite stockés dans une base dédiée, comme OpenSearch ou Pinecone.</p> <p>Quand un utilisateur pose une question, le système recherche les passages les plus proches sémantiquement dans cette base. Ces extraits sont alors transmis comme contexte au LLM, qui génère une réponse plus précise, ancrée dans la documentation de l’entreprise.</p> <p>Ce mécanisme garantit fraîcheur, pertinence et traçabilité des réponses. Il devient aussi possible d’adapter finement les résultats selon les métiers, les droits d’accès ou la langue.</p> <hr /> <h2>Réduire les hallucinations, sécuriser les échanges, limiter les coûts</h2> <p>Les hallucinations sont souvent dues à un manque de contexte. En apportant les bons documents au moment de la requête, le RAG réduit fortement ce risque. Chaque réponse peut être justifiée, sourcée, et auditée si besoin.</p> <p>Sur le plan de la sécurité, les données ne quittent jamais leur périmètre. Grâce à des services comme Bedrock ou SageMaker, tout reste cloisonné dans l’environnement AWS, sans exposition externe ni transfert inutile. Le respect du RGPD est ainsi facilité.</p> <p>Côté budget, l’absence de fine-tuning fait une grande différence. Le coût de calcul est optimisé, et le système peut évoluer progressivement sans repasser par des phases d’entraînement lourdes à chaque changement.</p> <hr /> <h2>Une architecture modulaire et réutilisable</h2> <p>L’implémentation repose sur des composants bien connus et robustes. S3 permet de stocker les documents bruts. Lambda gère les traitements automatisés. OpenSearch ou Kendra assurent l’indexation et la recherche. Bedrock ou SageMaker génèrent les réponses. Enfin, Cognito et API Gateway sécurisent les accès selon les rôles.</p> <p>Cette architecture est modulaire. Elle peut être adaptée à différents secteurs, tailles d’entreprise ou contraintes réglementaires, sans compromis sur la performance ni la sécurité.</p> <hr /> <h2>Exemple concret : un assistant IA métier chez Bureau Veritas</h2> <p>Chez Bureau Veritas, un assistant interne basé sur le RAG a été développé pour répondre aux questions techniques des collaborateurs. Avec plus de 90 000 documents à disposition, les experts étaient sursollicités. Il fallait automatiser sans perdre la qualité des réponses.</p> <p>Le chatbot <em>Jules</em> a permis de répondre à cette problématique. En s’appuyant sur les briques AWS, il traite des requêtes complexes, en toute autonomie. Plus de 3 000 collaborateurs l’utilisent régulièrement, avec un taux de satisfaction supérieur à 80 %. Le temps de réponse moyen a été divisé par 10.</p> <p>Ce type d’outil montre qu’une IA bien connectée à la donnée peut vraiment transformer l’expérience utilisateur interne.</p> <hr /> <h2>Mettre à l’échelle en gardant le contrôle</h2> <p>Dès que l’IA commence à être utilisée au quotidien, il devient essentiel de suivre sa performance. Quelques indicateurs clés sont à surveiller : la pertinence des documents retrouvés, la qualité perçue des réponses, les temps de latence, ou encore les retours utilisateurs.</p> <p>Mais il ne suffit pas de mesurer. Il faut aussi encadrer. La gestion des droits d’accès, la traçabilité des interactions, les mécanismes d’alerte en cas de comportement anormal font partie intégrante d’un RAG sérieux et responsable.</p> <hr /> <h2>Évaluer et améliorer en continu</h2> <p>Un bon système RAG n’est jamais figé. Il évolue avec les usages et les données. Plusieurs leviers permettent de l’optimiser :</p> <ul> <li>des mesures automatiques (BLEU, ROUGE, F1),</li> <li>des retours utilisateurs intégrés dans la boucle,</li> <li>des tests A/B pour comparer différents modèles ou prompts,</li> <li>et surtout, un enrichissement continu de la base documentaire.</li> </ul> <p>Ce dernier point est crucial : plus les documents sont clairs, bien découpés et structurés, meilleure sera la qualité des réponses générées.</p> <hr /> <h2>Passer du test à la production</h2> <p>Il est tentant de rester sur une preuve de concept. Mais les outils sont là, les retours d’expérience sont solides, et les gains sont réels. Le passage en production n’a jamais été aussi accessible.</p> <p>Le RAG offre un compromis unique entre rapidité de mise en œuvre, sécurité, précision et maîtrise des coûts. Il permet d’activer les gisements de connaissances internes avec une IA réellement utile.</p> <p>Les données internes sont souvent le levier le plus sous-estimé des entreprises. Avec le bon outillage, elles deviennent un avantage concurrentiel tangible.</p>2025-05-22T10:00:00+02:002025-05-22T10:00:00+02:00Hervé Leclerctag:blogppr.alterway.fr,2025-05-22:/vmware-open-source.html

<p>Migration de VMware vers les Solutions Open Source de Virtualisation et de Conteneurisation</p>

<h1>Migration de VMware vers les Solutions Open Source de Virtualisation et de Conteneurisation</h1> <p><strong>1. Introduction et Contexte</strong></p> <p>Le paysage de l'infrastructure informatique d'entreprise connaît une période de transformation accélérée, largement catalysée par des changements significatifs dans l'écosystème des solutions de virtualisation dominantes. Pendant des années, VMware s'est imposé comme le leader incontesté, définissant les standards de la virtualisation de serveurs. Cependant, une confluence de facteurs récents pousse un nombre croissant d'organisations à réévaluer leur dépendance à VMware et à explorer activement des alternatives, notamment celles issues du monde open source. Ce rapport vise à analyser en profondeur les enjeux, les stratégies et les implications d'une telle migration, qu'elle s'oriente vers des solutions de virtualisation open source traditionnelles ou vers des plateformes de conteneurisation modernes basées sur Kubernetes.</p> <p><strong>1.1. Le Point de Bascule : Pourquoi Quitter VMware?</strong></p> <p>Plusieurs facteurs convergents expliquent l'intérêt grandissant pour des alternatives à VMware, mais l'acquisition de l'entreprise par Broadcom fin 2023 a agi comme un catalyseur majeur, voire un véritable point de bascule pour de nombreuses organisations.</p> <ul> <li><strong>Impact de l'Acquisition par Broadcom</strong> : Les changements stratégiques et tarifaires imposés par Broadcom constituent la raison la plus fréquemment citée pour envisager une migration.<ul> <li><strong>Hausse Drastique des Coûts</strong> : Des augmentations de prix spectaculaires ont été rapportées par de grands comptes et des partenaires. Par exemple, AT&amp;T aurait fait face à une proposition d'augmentation de 1050% ¹, tandis que Veeam signalait une hausse de 300% sur les produits VMware utilisés.² D'autres clients ont constaté des augmentations allant de 140% à 600%.² Pour un serveur typique, l'impact peut représenter plus qu'un triplement des coûts sur trois ans.³ Ces hausses rendent la poursuite de l'utilisation de VMware économiquement difficile, voire insoutenable, pour de nombreuses entreprises, en particulier les PME et certaines entités commerciales.²</li> <li><strong>Refonte du Modèle de Licences</strong> : Broadcom a mis fin aux licences perpétuelles et à leurs renouvellements de support, imposant une transition vers un modèle d'abonnement basé sur le nombre de cœurs physiques.¹ Cette transition est obligatoire pour conserver le support et les mises à jour une fois les contrats existants expirés.² De plus, le minimum de cœurs requis par licence a été augmenté significativement (passant de 16 à 72 cœurs dans certains cas ¹), et l'édition gratuite populaire vSphere Hypervisor (ESXi) a été supprimée.⁵ Ce changement structurel affecte la prévisibilité budgétaire et augmente le coût global, même pour des infrastructures stables, forçant les entreprises à payer pour des capacités qu'elles n'utilisent pas forcément.</li> <li><strong>Incertitude Stratégique</strong> : Au-delà des coûts, l'acquisition a semé le doute quant à l'avenir de l'innovation au sein de la gamme VMware.¹ Certains craignent un appauvrissement technologique ⁶ et une potentielle dilution du focus sur VMware au sein du vaste portefeuille de Broadcom, qui pourrait voir la plateforme davantage comme une "vache à lait" que comme un axe d'investissement stratégique.⁴ Cette incertitude pèse sur la confiance des clients et leur volonté d'investir à long terme dans la plateforme.⁴</li> </ul> </li> </ul> <p>L'ampleur de ces changements post-acquisition agit comme un choc externe puissant. Il ne s'agit plus simplement d'optimiser les coûts existants, mais d'une remise en question fondamentale d'un choix d'infrastructure souvent profondément ancré. Cette situation contraint les DSI et les architectes à envisager des alternatives potentiellement transformatrices, allant au-delà d'un simple remplacement fonctionnel.¹</p> <ul> <li><strong>Verrouillage Fournisseur (Vendor Lock-in)</strong> : La dépendance historique à l'écosystème VMware est une préoccupation de longue date pour de nombreuses entreprises.⁷ Bien que riche, cet écosystème peut limiter la flexibilité, compliquer l'intégration avec des solutions tierces ou des environnements multi-cloud, et rendre les migrations coûteuses et complexes.¹ L'acquisition par Broadcom a ravivé ces craintes et renforcé le désir d'indépendance technologique.¹</li> <li><strong>Coût Total de Possession (TCO) Antérieur</strong> : Même avant les bouleversements liés à Broadcom, le TCO des solutions VMware, incluant licences, support et matériel certifié, était un facteur de coût important pour les entreprises.⁹ Les récents changements n'ont fait qu'exacerber cette réalité.</li> <li><strong>Recherche de Flexibilité et d'Agilité</strong> : Parallèlement aux pressions exercées par VMware, les entreprises cherchent de plus en plus à adopter des architectures informatiques plus modernes, flexibles et agiles, souvent associées aux paradigmes du cloud (public ou privé) et aux technologies open source.¹ La rigidité perçue de l'écosystème VMware peut freiner cette évolution.</li> </ul> <p><strong>1.2. L'Appel de l'Open Source : Une Opportunité Stratégique</strong></p> <p>Face à ce contexte, les solutions open source émergent non seulement comme des alternatives viables, mais aussi comme des opportunités stratégiques pour repenser et moderniser l'infrastructure IT.</p> <ul> <li><strong>Au-delà de l'Alternative Économique</strong> : Si la réduction des coûts est un attrait majeur ¹, l'open source représente bien plus qu'une simple réponse budgétaire. C'est une voie vers la modernisation de l'infrastructure, l'amélioration de l'agilité opérationnelle, l'accélération de l'innovation et une optimisation plus fine des ressources.¹</li> <li><strong>Indépendance Technologique et Souveraineté</strong> : L'adoption de l'open source permet aux entreprises de regagner le contrôle sur leur pile technologique, d'éviter le verrouillage fournisseur et de choisir librement les composants les mieux adaptés à leurs besoins spécifiques.¹ Cette indépendance est cruciale dans un environnement technologique en constante évolution.</li> <li><strong>Adaptation au Cloud-Native</strong> : L'écosystème open source est le berceau de nombreuses technologies fondamentales du cloud-native, telles que les conteneurs (Docker), l'orchestration (Kubernetes), et les outils d'automatisation (Ansible, Terraform).¹ Migrer vers des solutions open source facilite l'adoption de ces paradigmes et la transition vers des architectures distribuées et scalables.</li> <li><strong>Qualité et Innovation Communautaire</strong> : Contrairement aux idées reçues, les logiciels open source majeurs bénéficient souvent de processus de développement rigoureux impliquant des milliers de contributeurs, ce qui peut conduire à une haute qualité et sécurité.⁹ Le rythme d'innovation, alimenté par une communauté mondiale, peut dépasser celui des éditeurs propriétaires, permettant aux entreprises de rester à la pointe de la technologie.⁵ La collaboration via les forums, conférences et bases de connaissances est également un atout majeur.⁹</li> <li><strong>Modèle Économique Alternatif</strong> : L'open source propose souvent un modèle économique basé sur des souscriptions pour le support et la maintenance, plutôt que sur des licences logicielles coûteuses.¹ Ce modèle peut offrir un ROI rapide et des coûts récurrents plus prévisibles et souvent inférieurs.¹</li> </ul> <p>Il est important de noter que la motivation pour migrer n'est pas uniquement une réaction négative aux changements chez VMware (facteurs "push"), mais aussi une attraction positive vers les bénéfices stratégiques perçus de l'open source (facteurs "pull").¹ Même si la situation tarifaire de VMware venait à se stabiliser, la tendance de fond vers l'open source, portée par les objectifs de modernisation, d'agilité et d'alignement cloud-native, pourrait persister.⁶ La migration devient ainsi une opportunité de repositionnement stratégique pour l'infrastructure IT.</p> <p><strong>2. Panorama des Alternatives Open Source à VMware</strong></p> <p>Le marché offre une diversité de solutions open source pouvant remplacer tout ou partie de la pile VMware. Ces alternatives se répartissent principalement en deux catégories : les solutions de virtualisation "classiques" (centrées sur la VM) et les plateformes de conteneurisation basées sur Kubernetes (centrées sur le conteneur, mais pouvant aussi gérer des VMs). Le choix d'une alternative ne se résume donc pas à un simple remplacement fonctionnel de VMware par un équivalent open source. Il implique une réflexion sur l'architecture cible souhaitée, le niveau d'intégration désiré et les compétences disponibles au sein de l'organisation. Le spectre des options va des hyperviseurs purs, nécessitant une intégration manuelle des outils de gestion, aux plateformes entièrement intégrées, voire aux plateformes orientées conteneurs capables d'héberger également des machines virtuelles.</p> <p><strong>2.1. Solutions de Virtualisation Open Source ("VM-centric")</strong></p> <p>Ces solutions se concentrent sur la fourniture et la gestion d'hyperviseurs pour exécuter des machines virtuelles, de manière similaire à VMware vSphere/ESXi.</p> <ul> <li><strong>KVM (Kernel-based Virtual Machine)</strong> :<ul> <li><strong>Description</strong> : KVM n'est pas un hyperviseur autonome au sens traditionnel, mais une fonctionnalité du noyau Linux qui transforme ce dernier en un hyperviseur de type 1 (bare-metal).¹² Il tire parti des capacités intrinsèques de Linux pour la gestion de la mémoire, l'ordonnancement des processus et la sécurité (SELinux, sVirt).¹²</li> <li><strong>Fonctionnalités Clés</strong> : Performances souvent citées comme proches du natif ¹⁵, support de la migration à chaud (live migration) ¹³, compatibilité avec une large gamme de matériel certifié Linux ¹⁷, et support étendu du stockage (tout ce qui est supporté par Linux : disques locaux, NAS, SAN via iSCSI/FC, multipath I/O).¹⁴</li> <li><strong>Positionnement</strong> : KVM est la fondation technologique de nombreuses autres solutions de virtualisation et de cloud open source, incluant Proxmox VE, OpenStack, oVirt, et Red Hat OpenShift Virtualization.⁵</li> <li><strong>Avantages</strong> : Open source, gratuit, performances élevées, stabilité héritée du noyau Linux, intégration native dans l'écosystème Linux.</li> <li><strong>Inconvénients</strong> : En tant que composant de base, KVM seul nécessite l'ajout et la configuration d'outils de gestion, d'orchestration, de réseau et de stockage pour fournir une solution complète, ce qui peut être complexe.¹³</li> </ul> </li> <li><strong>Proxmox VE (Virtual Environment)</strong> :<ul> <li><strong>Description</strong> : Plateforme de virtualisation open source complète, basée sur Debian Linux, qui intègre l'hyperviseur KVM pour les machines virtuelles et LXC pour les conteneurs Linux légers.⁷</li> <li><strong>Fonctionnalités Clés</strong> : Gestion centralisée via une interface web conviviale ¹², clustering haute disponibilité (HA) sans nœud maître dédié ¹, migration à chaud des VMs et conteneurs ⁵, snapshots, sauvegarde intégrée (vzdump) et solution de sauvegarde dédiée (Proxmox Backup Server) avec restauration à chaud.¹⁹ Supporte une large gamme de stockages, y compris des solutions software-defined comme Ceph et ZFS pour l'hyperconvergence (HCI), ainsi que les stockages réseau traditionnels (NFS, iSCSI, CIFS) et locaux (LVM, ZFS).¹¹ Fonctionnalités réseau incluant pontage, VLANs et Open vSwitch ²⁷, ainsi qu'un pare-feu intégré au niveau du cluster.²⁷</li> <li><strong>Positionnement</strong> : Très populaire auprès des PME, des environnements de test/développement, des "homelabs", mais aussi utilisé en production dans des organisations de taille significative.⁵</li> <li><strong>Avantages</strong> : Solution tout-en-un facile à installer et à gérer via l'interface web, entièrement open source (licence AGPLv3) sans coût de licence ¹, performances solides (particulièrement en stockage par rapport à ESXi selon certaines études ¹⁹), communauté active.¹⁴</li> <li><strong>Inconvénients</strong> : Bien que l'interface soit conviviale, une bonne compréhension de Linux/KVM est utile pour le dépannage avancé.⁵ Le support entreprise (optionnel et payant) est disponible mais peut être perçu comme moins étendu que celui de VMware.⁵ Certaines fonctionnalités très avancées de VMware (ex: DRS très sophistiqué, snapshots sur tous types de stockage sans limitation ³⁰) peuvent avoir des équivalents moins matures ou nécessiter une configuration spécifique.¹⁹</li> </ul> </li> <li><strong>Xen Project</strong> :<ul> <li><strong>Description</strong> : Hyperviseur open source de type 1, mature et éprouvé, utilisé dans de nombreux environnements de production à grande échelle, notamment dans le cloud public (AWS historique) et comme base pour des produits commerciaux comme Citrix Hypervisor.⁵</li> <li><strong>Fonctionnalités Clés</strong> : Performances efficaces sur diverses architectures (x86, ARM) ⁵, support de la migration à chaud ¹³, fonctionnalités de sécurité robustes (isolation forte entre VMs, support du live patching).⁵</li> <li><strong>Positionnement</strong> : Solution fiable pour des déploiements à grande échelle nécessitant un contrôle fin sur la couche de virtualisation.</li> <li><strong>Avantages</strong> : Maturité, fiabilité prouvée, flexibilité architecturale, gratuit et open source.⁵</li> <li><strong>Inconvénients</strong> : Peut avoir une courbe d'apprentissage plus abrupte que d'autres solutions.⁵ L'hyperviseur Xen de base manque d'outils de gestion intégrés conviviaux par rapport à Proxmox ou vCenter, nécessitant souvent l'utilisation de solutions tierces (comme Xen Orchestra pour XCP-ng) ou une gestion en ligne de commande.⁵ Support limité pour certaines fonctionnalités dans la version gratuite (ex: USB ¹³).</li> </ul> </li> <li><strong>oVirt</strong> :<ul> <li><strong>Description</strong> : Plateforme de gestion de virtualisation open source de niveau entreprise, basée sur l'hyperviseur KVM. C'est le projet communautaire sur lequel est basé Red Hat Virtualization (RHV).¹</li> <li><strong>Fonctionnalités Clés</strong> : Interface de gestion centralisée pour les clusters, le stockage et les VMs. Supporte la haute disponibilité, la migration à chaud, des fonctionnalités réseau avancées et s'intègre avec des outils d'automatisation comme Ansible.⁵</li> <li><strong>Positionnement</strong> : Alternative robuste à VMware vSphere pour les organisations familières avec KVM et recherchant des fonctionnalités d'entreprise.</li> <li><strong>Avantages</strong> : Riche en fonctionnalités de niveau entreprise, soutenu par une forte communauté et le support potentiel de Red Hat (via RHV).⁵</li> <li><strong>Inconvénients</strong> : La configuration et le déploiement peuvent être complexes, surtout pour les nouveaux utilisateurs.⁵ L'expérience utilisateur peut être perçue comme moins fluide que celle de vSphere.⁵</li> </ul> </li> <li><strong>OpenStack</strong> :<ul> <li><strong>Description</strong> : Projet open source massif fournissant une plateforme complète d'Infrastructure as a Service (IaaS) pour construire et gérer des clouds privés (et publics).⁵ Il est composé de nombreux services modulaires (Nova pour le calcul, Neutron pour le réseau, Cinder pour le stockage bloc, Swift pour l'objet, Keystone pour l'identité, Horizon pour le tableau de bord, etc.).</li> <li><strong>Fonctionnalités Clés</strong> : Extrêmement flexible et scalable, permet une gestion fine des ressources à très grande échelle, supporte divers hyperviseurs (KVM étant le plus courant), technologies de stockage (Ceph ⁵) et de réseau (SDN). API robustes pour l'automatisation et l'orchestration.⁵</li> <li><strong>Positionnement</strong> : Solution de choix pour les grandes entreprises ou les fournisseurs de services souhaitant construire un cloud privé avec un contrôle total, mais souvent surdimensionnée pour de simples besoins de virtualisation de serveurs.</li> <li><strong>Avantages</strong> : Scalabilité massive, flexibilité architecturale extrême, évite le verrouillage fournisseur, forte communauté et écosystème.⁵</li> <li><strong>Inconvénients</strong> : Très complexe à déployer, gérer et maintenir.⁵ Nécessite une expertise pointue en cloud, réseau, stockage et automatisation.</li> </ul> </li> <li><strong>Autres Solutions Notables</strong> :<ul> <li><strong>OpenNebula</strong> : Alternative à OpenStack, souvent considérée comme plus légère et plus simple à déployer, particulièrement pour les PME ou les déploiements hybrides.⁵</li> <li><strong>XCP-ng</strong> : Fork communautaire de Citrix XenServer, offrant une alternative open source avec des fonctionnalités d'entreprise et une gestion via Xen Orchestra.¹²</li> <li><strong>Harvester</strong> : Solution d'hyperconvergence (HCI) open source de SUSE, basée sur KVM/KubeVirt, Longhorn pour le stockage et intégrée à Rancher pour une gestion unifiée des VMs et des conteneurs.³⁰</li> </ul> </li> </ul> <p><strong>Tableau 2.1 : Comparaison des Fonctionnalités Clés : Hyperviseurs Open Source vs. VMware vSphere</strong></p> <table> <tr> <td><strong>Fonctionnalité</strong> </td> <td><strong>VMware vSphere (avec vCenter)</strong> </td> <td><strong>KVM (base)</strong> </td> <td><strong>Proxmox VE</strong> </td> <td><strong>Xen Project</strong> </td> <td><strong>oVirt</strong> </td> <td><strong>OpenStack</strong> </td> </tr> <tr> <td><strong>Type Hyperviseur</strong> </td> <td>Type 1 (ESXi) </td> <td>Type 1 (via noyau Linux) </td> <td>Type 1 (KVM via Linux Debian) </td> <td>Type 1 </td> <td>Type 1 (KVM via Linux) </td> <td>Gère divers hyperviseurs (KVM, etc.) </td> </tr> <tr> <td><strong>Licence</strong> </td> <td>Propriétaire (Abonnement) </td> <td>Open Source (GPL/LGPL) </td> <td>Open Source (AGPLv3) </td> <td>Open Source (GPLv2) </td> <td>Open Source (Apache 2.0) </td> <td>Open Source (Apache 2.0) </td> </tr> <tr> <td><strong>Haute Disponibilité</strong> </td> <td>Oui (vSphere HA) </td> <td>Non (nécessite outils externes) </td> <td>Oui (intégré, >= 3 nœuds) </td> <td>Oui (via outils/distros tiers) </td> <td>Oui (intégré) </td> <td>Oui (au niveau des services & instances) </td> </tr> <tr> <td><strong>Migration à Chaud</strong> </td> <td>Oui (vMotion) </td> <td>Oui (natif) </td> <td>Oui (intégrée) </td> <td>Oui (natif) </td> <td>Oui (intégrée) </td> <td>Oui (instances Nova) </td> </tr> <tr> <td><strong>Gestion Centralisée</strong> </td> <td>Oui (vCenter) </td> <td>Non (nécessite libvirt + outils) </td> <td>Oui (Interface Web intégrée) </td> <td>Non (nécessite outils/distros tiers) </td> <td>Oui (Interface Web intégrée) </td> <td>Oui (Horizon Dashboard, APIs) </td> </tr> <tr> <td><strong>Stockage Supporté</strong> </td> <td>VMFS, NFS, iSCSI, FC, vSAN, vVols </td> <td>Tout stockage Linux (local, NAS, SAN) </td> <td>Large (LVM, ZFS, Ceph, NFS, iSCSI, GlusterFS...) </td> <td>Tout stockage supporté par l'hôte </td> <td>NFS, iSCSI, FC, GlusterFS, Ceph </td> <td>Cinder (Bloc: iSCSI, Ceph...), Swift (Objet) </td> </tr> <tr> <td><strong>Réseau Avancé (SDN)</strong> </td> <td>Oui (vDS, NSX) </td> <td>Non (OVS/bridges Linux, config manuelle) </td> <td>Limité (OVS/bridges, pare-feu, VLANs) </td> <td>Limité (OVS/bridges, config manuelle) </td> <td>Oui (OVS intégré) </td> <td>Oui (Neutron, très avancé) </td> </tr> <tr> <td><strong>Sauvegarde Intégrée</strong> </td> <td>Limitée (vSphere Replication) </td> <td>Non </td> <td>Oui (vzdump, Proxmox Backup Server) </td> <td>Non (dépend outils/distros tiers) </td> <td>Limitée </td> <td>Non (snapshots Cinder) </td> </tr> <tr> <td><strong>Support Conteneurs</strong> </td> <td>Oui (via Tanzu) </td> <td>Non (directement) </td> <td>Oui (LXC intégré) </td> <td>Non (directement) </td> <td>Non (directement) </td> <td>Oui (via Magnum pour K8s, etc.) </td> </tr> <tr> <td><strong>Support Entreprise</strong> </td> <td>Oui (Broadcom) </td> <td>Via distributions (Red Hat, SUSE, Ubuntu) </td> <td>Oui (Proxmox Server Solutions GmbH) </td> <td>Via distributions (Citrix, Oracle...) </td> <td>Oui (via Red Hat RHV) </td> <td>Oui (Red Hat, Mirantis, Canonical...) </td> </tr> </table> <p><strong>2.2. Plateformes de Conteneurisation Basées sur Kubernetes ("Container-centric" avec gestion VM)</strong></p> <p>Ces plateformes utilisent Kubernetes comme orchestrateur principal mais intègrent des capacités (souvent via KubeVirt) pour gérer également des machines virtuelles, offrant une approche unifiée.</p> <ul> <li><strong>Kubernetes Vanilla</strong> :<ul> <li><strong>Description</strong> : Le projet open source Kubernetes de base, maintenu par la Cloud Native Computing Foundation (CNCF).⁴¹ Il fournit les fonctionnalités fondamentales pour l'orchestration de conteneurs (déploiement, scaling, gestion du cycle de vie).⁴²</li> <li><strong>Gestion VM</strong> : Nécessite l'installation et la configuration manuelles de KubeVirt.³⁷</li> <li><strong>Avantages</strong> : Flexibilité maximale, pas de surcoût lié à une distribution spécifique, contrôle total sur les composants.</li> <li><strong>Inconvénients</strong> : Complexité opérationnelle très élevée. Nécessite d'intégrer et de gérer soi-même tous les composants additionnels essentiels en production : monitoring, logging, réseau (CNI), stockage (CSI), sécurité, ingress, gestion des identités, etc..⁴⁵</li> </ul> </li> <li><strong>Red Hat OpenShift</strong> :<ul> <li><strong>Description</strong> : Distribution Kubernetes orientée entreprise, construite sur Kubernetes (OKD est la version communautaire en amont ⁴⁴), enrichie avec des fonctionnalités pour la sécurité, les développeurs (outils CI/CD intégrés, build S2I), la gestion opérationnelle (mises à jour automatisées, monitoring intégré) et une interface web complète.¹</li> <li><strong>Gestion VM</strong> : Intègre <strong>OpenShift Virtualization</strong>, basé sur KubeVirt, permettant de créer, importer et gérer des VMs KVM comme des objets natifs Kubernetes aux côtés des conteneurs.¹⁵ Inclut le <strong>Migration Toolkit for Virtualization (MTV)</strong> pour faciliter la migration depuis VMware.¹⁶ Une édition <strong>OpenShift Virtualization Engine</strong> est dédiée uniquement à la gestion de VMs sur OpenShift.¹⁶</li> <li><strong>Positionnement</strong> : Plateforme applicative hybride pour les entreprises, visant à unifier le développement et l'exploitation des applications traditionnelles (VMs) et modernes (conteneurs, serverless). Particulièrement pertinent pour les organisations déjà investies dans l'écosystème Red Hat.⁴⁷</li> <li><strong>Avantages</strong> : Solution PaaS/CaaS intégrée et supportée par Red Hat, sécurité renforcée par défaut (SELinux, SCCs) ⁴¹, outils développeurs et opérateurs intégrés, gestion simplifiée du cycle de vie du cluster et des applications.⁴²</li> <li><strong>Inconvénients</strong> : Peut être perçu comme plus complexe et "opinionated" (imposant certaines façons de faire) que Kubernetes vanilla ⁴⁴, modèle de souscription payant ⁴², potentiellement plus gourmand en ressources que des solutions plus légères.</li> </ul> </li> <li><strong>SUSE Rancher</strong> :<ul> <li><strong>Description</strong> : Plateforme open source de gestion centralisée pour de multiples clusters Kubernetes, quelle que soit leur localisation (on-premise, cloud public, edge) ou leur distribution (RKE, K3s, EKS, AKS, GKE...).³⁸ Rancher lui-même n'est pas une distribution Kubernetes, mais un outil de management qui s'installe au-dessus.⁴¹</li> <li><strong>Gestion VM</strong> : Rancher s'intègre nativement avec <strong>Harvester</strong>, la solution HCI de SUSE.³⁰ Harvester utilise KubeVirt et Longhorn (stockage bloc distribué) pour permettre la gestion des VMs depuis la console Rancher, aux côtés des clusters Kubernetes.</li> <li><strong>Distributions Associées</strong> : RKE (Rancher Kubernetes Engine) est une distribution Kubernetes certifiée CNCF fonctionnant dans des conteneurs Docker.⁴⁷ K3s est une distribution Kubernetes légère, optimisée pour les environnements à ressources limitées (edge, IoT, CI).⁴⁷</li> <li><strong>Positionnement</strong> : Idéal pour les organisations gérant un parc hétérogène de clusters Kubernetes et recherchant une interface de gestion unifiée et conviviale.</li> <li><strong>Avantages</strong> : Extrême flexibilité (agnostique vis-à-vis de l'infrastructure et de la distribution K8s), interface utilisateur intuitive ⁴¹, gestion multi-cluster native, open source avec support entreprise optionnel (SUSE).⁴¹</li> <li><strong>Inconvénients</strong> : Moins une plateforme PaaS "tout-en-un" qu'OpenShift.⁴¹ Bien que l'interface soit simple, la configuration et la gestion avancées des clusters sous-jacents nécessitent toujours une expertise Kubernetes.⁴⁴</li> </ul> </li> <li><strong>K3s</strong> :<ul> <li><strong>Description</strong> : Distribution Kubernetes légère et certifiée CNCF, développée initialement par Rancher Labs (maintenant SUSE).⁴⁷ Conçue pour être simple, rapide à déployer (binaire unique) et avec une faible empreinte mémoire/CPU.⁴⁷ Remplace et simplifie certains composants K8s (etcd remplacé par SQLite par défaut, par exemple).</li> <li><strong>Gestion VM</strong> : Peut exécuter KubeVirt, bien que moins courant que sur des distributions K8s complètes.</li> <li><strong>Positionnement</strong> : Excellent choix pour l'edge computing, l'IoT, les environnements de développement/test, et les petits clusters.</li> <li><strong>Avantages</strong> : Léger, rapide, facile à installer et à mettre à jour.⁴⁴</li> <li><strong>Inconvénients</strong> : Peut manquer de certaines fonctionnalités ou options de configuration avancées présentes dans K8s complet, potentiellement moins adapté pour de très grands clusters centralisés.⁴⁴</li> </ul> </li> <li><strong>KubeVirt (en tant que projet)</strong> :<ul> <li><strong>Description</strong> : Projet open source clé qui étend Kubernetes pour permettre la gestion de machines virtuelles.⁸ Il introduit des Custom Resource Definitions (CRDs) comme VirtualMachine (VM) et VirtualMachineInstance (VMI) qui sont gérées via l'API Kubernetes standard.</li> <li><strong>Fonctionnement</strong> : Utilise KVM/QEMU via libvirt, encapsulé dans un pod spécifique (virt-launcher) sur les nœuds workers.⁴⁶ Les composants virt-controller (dans le control plane) et virt-handler (daemonset sur les nœuds) orchestrent le cycle de vie des VMs.⁴⁶ Les VMs utilisent le réseau (CNI) et le stockage (CSI via PVCs) de Kubernetes.³⁷</li> <li><strong>Positionnement</strong> : Technologie habilitante fondamentale pour faire converger la gestion des VMs et des conteneurs sur Kubernetes. Utilisée par OpenShift Virtualization, Harvester, et potentiellement dans des déploiements K8s vanilla.</li> <li><strong>Avantages</strong> : Permet une gestion unifiée avec les outils Kubernetes existants, facilite une migration progressive vers le cloud-native en hébergeant des VMs legacy sur une plateforme moderne, potentiel d'amélioration de la densité des workloads par rapport aux VMs traditionnelles.³⁷</li> <li><strong>Inconvénients</strong> : Technologie plus récente que les hyperviseurs dédiés, la performance peut être un sujet d'attention pour certains workloads très intensifs ⁵⁹, la maturité de certaines fonctionnalités (ex: live migration avec stockage non-RWX ⁴⁶) peut être en retrait par rapport à vMotion. L'utilisation en mode "DIY" (Do It Yourself) sur K8s vanilla dépend fortement du support communautaire.³⁷</li> </ul> </li> </ul> <p>L'émergence de KubeVirt et son intégration dans des plateformes majeures comme OpenShift et Harvester/Rancher est significative. Elle brouille la frontière historiquement nette entre le monde de la virtualisation et celui de la conteneurisation. Plutôt que de forcer un choix binaire "tout VM" ou "tout conteneur", KubeVirt ouvre une voie de "Re-platforming".⁵⁵ Les entreprises peuvent déplacer leurs VMs existantes sur une infrastructure Kubernetes, les gérant avec les mêmes outils que leurs conteneurs. Cela permet de bénéficier immédiatement de certains avantages de Kubernetes (orchestration déclarative, API unifiée) tout en planifiant une modernisation plus profonde (refactoring vers des conteneurs natifs) à leur propre rythme.⁵⁵ Cette approche hybride et progressive est un atout majeur pour les organisations avec un parc applicatif mixte.</p> <p><strong>Tableau 2.2 : Comparaison des Plateformes Kubernetes (OpenShift vs. Rancher vs. K8s Vanilla + KubeVirt)</strong></p> <table> <tr> <td><strong>Caractéristique</strong> </td> <td><strong>Kubernetes Vanilla (+ KubeVirt DIY)</strong> </td> <td><strong>Red Hat OpenShift (+ Virtualization)</strong> </td> <td><strong>SUSE Rancher (+ Harvester/K3s)</strong> </td> </tr> <tr> <td><strong>Facilité Déploiement</strong> </td> <td>Complexe </td> <td>Complexe (mais assisté) </td> <td>Variable (Rancher simple, cluster K8s dépend) </td> </tr> <tr> <td><strong>Gestion Cluster</strong> </td> <td>Manuelle / Outils tiers </td> <td>Intégrée (Single/Multi via ACM) </td> <td>Nativement Multi-Cluster </td> </tr> <tr> <td><strong>Fonctionnalités PaaS</strong> </td> <td>Minimales (à intégrer) </td> <td>Riches et Intégrées (CI/CD, Registry...) </td> <td>Limitées (focus sur gestion K8s) </td> </tr> <tr> <td><strong>Gestion VM (KubeVirt)</strong> </td> <td>Manuelle (installation/config) </td> <td>Intégrée (OpenShift Virtualization) </td> <td>Intégrée via Harvester </td> </tr> <tr> <td><strong>Outils Migration VM</strong> </td> <td>Outils OS (virt-v2v, etc.) </td> <td>Intégrés (MTV) </td> <td>Dépend Harvester / Outils OS </td> </tr> <tr> <td><strong>Sécurité Intégrée</strong> </td> <td>Basique (RBAC, NetworkPolicy...) </td> <td>Renforcée (SELinux, SCCs, Compliance) </td> <td>Variable (dépend cluster K8s sous-jacent) </td> </tr> <tr> <td><strong>Modèle Licence/Coût</strong> </td> <td>Open Source (Gratuit) </td> <td>Souscription (Payant) </td> <td>Open Source (Support payant optionnel) </td> </tr> <tr> <td><strong>Support</strong> </td> <td>Communautaire </td> <td>Entreprise (Red Hat) </td> <td>Entreprise (SUSE) / Communautaire </td> </tr> <tr> <td><strong>Cible Principale</strong> </td> <td>Experts K8s, Flexibilité Max </td> <td>Entreprises, Standardisation RH </td> <td>Gestion Hétérogène, Multi-Cloud </td> </tr> <tr> <td><strong>Complexité Opérationnelle</strong> </td> <td>Très Élevée </td> <td>Élevée (mais managée) </td> <td>Moyenne à Élevée (selon cluster) </td> </tr> </table> <p><strong>3. Analyse Approfondie des Enjeux Techniques de la Migration</strong></p> <p>La migration d'un environnement VMware établi vers une alternative open source, qu'elle soit basée sur la virtualisation traditionnelle ou sur Kubernetes, soulève d'importants défis techniques qu'il convient d'anticiper et de maîtriser. Ces enjeux couvrent la compatibilité des applications et des systèmes d'exploitation, la parité des fonctionnalités essentielles, la complexité intrinsèque du processus de migration des machines virtuelles elles-mêmes, ainsi que les performances et la capacité de montée en charge comparées des différentes solutions.</p> <p><strong>3.1. Compatibilité Applicative et Systèmes d'Exploitation</strong></p> <p>Assurer que les systèmes d'exploitation invités et les applications qu'ils hébergent fonctionneront correctement sur la nouvelle plateforme est une préoccupation majeure.</p> <ul> <li><strong>Support des OS Invités</strong> : La plupart des hyperviseurs open source basés sur KVM ou Xen offrent un large support pour les systèmes d'exploitation invités courants, notamment diverses distributions Linux et versions de Windows.¹³ Proxmox VE liste explicitement Linux, Windows, et d'autres OS.²¹ De même, OpenShift Virtualization, basé sur KVM/KubeVirt, supporte officiellement Windows et Linux, avec même une certification pour certaines versions de Windows Server.³⁷ En théorie, la compatibilité de base des OS est donc généralement assurée.</li> <li><strong>Problèmes Potentiels lors d'une Migration VM-à-VM</strong> : Les difficultés surviennent souvent au niveau de l'interaction entre l'OS invité et le nouvel hyperviseur :<ul> <li><strong>Pilotes (Drivers)</strong> : C'est l'un des points les plus critiques. Les performances optimales (disque, réseau) sur KVM/Proxmox/oVirt dépendent des pilotes paravirtualisés VirtIO.⁶⁴ Il est fortement recommandé d'installer ces pilotes dans la VM <em>avant</em> la migration, bien que cela puisse parfois être fait après.⁶⁴ La désinstallation préalable des VMware Tools est également une étape essentielle pour éviter les conflits.⁶⁴ L'oubli ou l'échec de cette étape peut entraîner des VMs qui ne démarrent pas ou des performances dégradées.</li> <li><strong>Configuration Matérielle Virtuelle</strong> : Le matériel virtuel émulé par l'hyperviseur cible peut différer de celui de VMware. Il faut s'assurer que le type de contrôleur de disque (IDE pour les très vieux OS ⁶⁴, SATA, ou idéalement VirtIO-SCSI pour la performance ⁶⁴), le type de carte réseau (par exemple, passer de E1000/VMXNET3 à VirtIO-net/netkvm ⁶⁴), et le firmware (BIOS hérité vs UEFI ⁶³) sont correctement configurés et supportés par l'OS invité.</li> <li><strong>Configuration Réseau</strong> : Bien que des outils tentent de préserver les configurations réseau ⁶⁶, le changement d'adaptateur réseau virtuel peut entraîner la perte de l'adresse IP statique ou des problèmes de "stuck IP" liés à l'ancienne carte réseau fantôme dans l'OS.³⁰ Il est crucial de vérifier et, si nécessaire, de reconfigurer les paramètres IP après la migration. La correspondance des VLANs entre l'environnement source et cible est également indispensable pour maintenir la connectivité.⁶⁶ La préservation de l'adresse MAC peut être importante pour certains OS ou applications.⁶⁶</li> <li><strong>Licences OS/Applicatives</strong> : Bien que moins fréquent aujourd'hui, certaines licences logicielles pourraient être liées à des identifiants matériels virtuels spécifiques à VMware. Il convient de vérifier ce point pour les applications critiques ou sous licence spécifique.</li> </ul> </li> <li><strong>Problèmes Potentiels lors d'une Migration VM-vers-Conteneur ou VM-vers-KubeVirt</strong> : La transition vers un environnement basé sur Kubernetes introduit des défis de compatibilité différents :<ul> <li><strong>Nature de l'Application</strong> : Les applications monolithiques, non conçues pour être distribuées ou sans état, sont intrinsèquement difficiles à conteneuriser directement. KubeVirt offre ici une solution de repli intéressante, permettant d'exécuter la VM monolithique au sein de Kubernetes en attendant un refactoring éventuel.³⁷</li> <li><strong>Dépendances Système Fortes</strong> : Les applications qui interagissent profondément avec le noyau de l'OS invité, nécessitent des pilotes spécifiques ou des privilèges élevés peuvent être complexes à faire fonctionner dans un conteneur standard, qui partage le noyau de l'hôte et a des capacités limitées par défaut. KubeVirt, exécutant un OS complet dans une VM, contourne ce problème.</li> <li><strong>Stockage Persistant</strong> : La gestion du stockage persistant dans Kubernetes (via Persistent Volumes - PV, Persistent Volume Claims - PVC et Storage Classes - SC) est fondamentalement différente de la gestion des datastores et des disques virtuels (VMDK) dans VMware.⁴⁹ La migration nécessite de mapper les volumes VMDK vers des PVCs et de s'assurer que le stockage sous-jacent (via un driver CSI) fournit les performances et les fonctionnalités requises (ex: mode d'accès ReadWriteMany pour la migration à chaud KubeVirt ⁴⁶).</li> </ul> </li> </ul> <p>Si les défis de compatibilité technique pure (pilotes, matériel virtuel) lors d'une migration VM-à-VM sont souvent surmontables avec une planification minutieuse et les bons outils (comme l'installation préalable des drivers VirtIO), le véritable enjeu se déplace souvent vers la <strong>parité fonctionnelle</strong> et la <strong>complexité opérationnelle</strong>. L'écosystème VMware, centré autour de vCenter, offre un ensemble très intégré de fonctionnalités avancées (vMotion, DRS, HA, NSX, vSAN) qui peuvent être plus difficiles à répliquer avec le même niveau de simplicité et d'intégration en assemblant différentes briques open source.⁵ Une migration réussie ne se mesure pas seulement à la capacité de démarrer la VM sur la nouvelle plateforme, mais aussi à la capacité de l'opérer efficacement avec un niveau de service équivalent.</p> <p><strong>3.2. Parité des Fonctionnalités (Haute Disponibilité, Migration à Chaud, Réseau/Stockage)</strong></p> <p>L'un des aspects les plus scrutés lors d'une migration est la capacité des solutions alternatives à offrir un niveau de fonctionnalités équivalent à celui de VMware, notamment pour les opérations critiques.</p> <ul> <li><strong>Haute Disponibilité (HA)</strong> :<ul> <li><em>VMware</em> : vSphere HA est une solution éprouvée et largement utilisée pour redémarrer automatiquement les VMs sur d'autres hôtes en cas de défaillance matérielle.¹⁷</li> <li><em>Alternatives Open Source</em> :<ul> <li>Proxmox VE intègre une fonctionnalité de HA ¹, nécessitant au moins trois nœuds et un stockage partagé ou répliqué (comme Ceph).¹⁹ Certains utilisateurs la jugent fonctionnelle mais potentiellement moins sophistiquée que celle de VMware.¹⁹</li> <li>oVirt propose également une HA de niveau entreprise.⁵</li> <li>Pour KVM pur ou Xen, la HA nécessite généralement des solutions de clustering externes comme Pacemaker/Corosync, ajoutant une couche de complexité.</li> <li>Kubernetes gère nativement la haute disponibilité des applications (pods) en les redémarrant sur des nœuds sains. KubeVirt étend ce principe aux VMs qu'il gère, en redémarrant le pod virt-launcher de la VM.³⁷ Des fonctionnalités spécifiques à la HA des VMs sont également développées dans KubeVirt.³⁷</li> </ul> </li> </ul> </li> <li><strong>Migration à Chaud (Live Migration)</strong> :<ul> <li><em>VMware</em> : vMotion est la technologie de référence pour déplacer une VM en cours d'exécution d'un hôte à un autre sans interruption de service.¹⁷</li> <li><em>Alternatives Open Source</em> :<ul> <li>KVM, Xen, Proxmox VE et oVirt supportent tous la migration à chaud nativement.⁵</li> <li>KubeVirt supporte également la migration à chaud des VMs entre les nœuds Kubernetes.³⁷ Cependant, elle impose des contraintes, notamment la nécessité d'utiliser un stockage partagé accessible en mode ReadWriteMany (RWX) pour les volumes persistants de la VM.⁴⁶ Le processus peut aussi avoir un impact temporaire sur les performances.⁴⁶ KubeVirt implémente des stratégies de migration pré-copie (standard) et post-copie (pour les VMs difficiles à faire converger).⁶⁰</li> </ul> </li> </ul> </li> <li><strong>Gestion du Réseau</strong> :<ul> <li><em>VMware</em> : Offre des commutateurs virtuels standards (vSS) et distribués (vDS). Pour le Software-Defined Networking (SDN) avancé, NSX fournit des fonctionnalités riches de micro-segmentation, de routage dynamique, de pare-feu distribué, etc..³</li> <li><em>Alternatives Open Source</em> :<ul> <li>Les solutions basées sur Linux (KVM, Proxmox, Xen) utilisent typiquement les mécanismes de pontage (bridging) Linux ou Open vSwitch (OVS) pour la connectivité des VMs.¹ La configuration des VLANs est couramment supportée.³¹</li> <li>Proxmox intègre un pare-feu basique et des fonctionnalités SDN limitées.⁵ oVirt a une intégration OVS plus poussée.⁵</li> <li>OpenStack Neutron offre des capacités SDN très complètes mais notoirement complexes à maîtriser.⁸</li> <li>Kubernetes utilise le Container Network Interface (CNI) comme standard pour les plugins réseau. Des solutions CNI populaires (Calico, Cilium, OVN-Kubernetes...) fournissent des fonctionnalités SDN avancées (Network Policies pour la micro-segmentation, etc.). OpenShift intègre sa propre solution SDN (OpenShift SDN ou OVN-Kubernetes). KubeVirt s'intègre naturellement dans ce modèle réseau Kubernetes.³⁷</li> </ul> </li> </ul> </li> <li><strong>Gestion du Stockage</strong> :<ul> <li><em>VMware</em> : Utilise principalement le système de fichiers cluster VMFS pour les LUNs partagés, vSAN pour l'hyperconvergence (HCI), et supporte NFS et iSCSI. vVols permet une gestion plus granulaire du stockage au niveau des VMs.¹</li> <li><em>Alternatives Open Source</em> :<ul> <li>Proxmox VE brille par sa flexibilité de stockage, supportant une multitude d'options : stockage local (LVM, LVM-Thin, ZFS), stockage réseau (NFS, iSCSI, CIFS), et stockage distribué/software-defined (Ceph/RBD, GlusterFS, ZFS over iSCSI).¹¹ L'intégration native de Ceph et ZFS facilite la mise en place de solutions HCI.¹¹ Des limitations peuvent exister pour certaines fonctionnalités (ex: snapshots de l'hyperviseur sur LUNs iSCSI classiques ³⁰). Le Thin Provisioning est supporté.³⁰</li> <li>KVM/Linux peuvent utiliser tout type de stockage accessible par le système hôte Linux (local, NFS, iSCSI, FC).¹⁴ Des solutions SDS comme Ceph ⁵ ou GlusterFS sont couramment utilisées.</li> <li>OpenStack propose Cinder pour la gestion des volumes bloc (avec divers backends possibles) et Swift pour le stockage objet.⁸</li> <li>Kubernetes standardise l'accès au stockage via l'interface CSI (Container Storage Interface). Les administrateurs définissent des Storage Classes qui pointent vers des provisionneurs de stockage (ex: Ceph via Rook, Longhorn, pilotes CSI pour SAN/NAS...). Les applications demandent du stockage via des PVCs. KubeVirt utilise ce mécanisme standard : les disques virtuels des VMs sont adossés à des PVCs.⁴⁶ Harvester intègre Longhorn pour le stockage distribué.³⁷</li> </ul> </li> </ul> </li> </ul> <p><strong>Tableau 3.1 : Synthèse de la Parité des Fonctionnalités : VMware vSphere vs. Alternatives Open Source Majeures</strong></p> <table> <tr> <td><strong>Fonctionnalité</strong> </td> <td><strong>VMware vSphere (Full Stack)</strong> </td> <td><strong>Proxmox VE (+ PBS/Ceph)</strong> </td> <td><strong>KVM + oVirt/OpenStack</strong> </td> <td><strong>Xen + XCP-ng/Orchestra</strong> </td> <td><strong>OpenShift Virtualization</strong> </td> </tr> <tr> <td><strong>HA (VM Restart)</strong> </td> <td>Natif Intégré (Mature) </td> <td>Natif Intégré </td> <td>Intégré (oVirt) / Complexe (OS) </td> <td>Via Outils Tiers (Mature) </td> <td>Natif Intégré (K8s + KubeVirt) </td> </tr> <tr> <td><strong>Live Migration</strong> </td> <td>Natif Intégré (vMotion) </td> <td>Natif Intégré </td> <td>Natif Intégré </td> <td>Natif Intégré </td> <td>Natif Intégré (Limitations) </td> </tr> <tr> <td><strong>Load Balancing (DRS)</strong> </td> <td>Natif Intégré (Avancé) </td> <td>Limité / Manuel </td> <td>Limité (oVirt) / Possible (OS) </td> <td>Limité / Manuel </td> <td>Via K8s Scheduler (Pods) </td> </tr> <tr> <td><strong>SDN (Micro-segment.)</strong> </td> <td>Natif Intégré (NSX) </td> <td>Limité / Outils Tiers </td> <td>Avancé (Neutron) / Limité (oVirt) </td> <td>Limité / Outils Tiers </td> <td>Natif Intégré (NetworkPolicy) </td> </tr> <tr> <td><strong>Stockage SDS/HCI</strong> </td> <td>Natif Intégré (vSAN) </td> <td>Natif Intégré (Ceph/ZFS) </td> <td>Via Outils Tiers (Ceph...) </td> <td>Via Outils Tiers </td> <td>Via CSI (Ceph, Longhorn...) </td> </tr> <tr> <td><strong>Gestion Centralisée</strong> </td> <td>Natif Intégré (vCenter) </td> <td>Natif Intégré (Web UI) </td> <td>Natif Intégré (oVirt/Horizon) </td> <td>Via Outils Tiers (Xen Orch.) </td> <td>Natif Intégré (OpenShift UI) </td> </tr> <tr> <td><strong>Sauvegarde/DR Intégrée</strong> </td> <td>Limitée (VDP/vSphere Rep.) </td> <td>Intégrée (PBS) </td> <td>Limitée </td> <td>Limitée </td> <td>Via Outils Tiers (Velero...) </td> </tr> <tr> <td><strong>Sécurité Avancée</strong> </td> <td>Intégrée (NSX, Encryption...) </td> <td>Basique / Outils Tiers </td> <td>Variable (Dépend config/OS) </td> <td>Variable (Dépend config/distro) </td> <td>Intégrée (Policies, Secrets...) </td> </tr> </table> <p><em>Légende : Natif Intégré = Fonctionnalité clé de la plateforme; Via Outils Tiers = Nécessite un composant externe/communautaire; Limité = Fonctionnalité basique ou moins mature; Complexe = Possible mais difficile à mettre en œuvre.</em></p> <p><strong>3.3. Complexité de la Migration des VMs</strong></p> <p>Le processus technique de déplacement des machines virtuelles de VMware vers une plateforme open source varie en complexité selon la cible et la méthode choisies.</p> <ul> <li><strong>Migration VM-à-VM (vers Hyperviseur Open Source)</strong> : C'est le scénario le plus direct, visant à remplacer ESXi par KVM, Proxmox, Xen, etc.<ul> <li><strong>Outils Disponibles</strong> : Plusieurs outils peuvent faciliter cette transition :<ul> <li>virt-v2v : Un outil en ligne de commande puissant pour convertir des VMs depuis VMware (ESXi/vCenter) ou Xen vers des environnements basés sur KVM (gérés par libvirt, oVirt, OpenStack, RHV).⁶³ Il gère la conversion des disques et des métadonnées.</li> <li>Importateur Proxmox VE : Depuis la version 8.2, Proxmox intègre un assistant graphique pour importer directement des VMs depuis des hôtes ESXi (versions 6.5 à 8.0, hors vSAN).⁶⁵</li> <li>Export/Import OVF : L'exportation de la VM VMware au format OVF (Open Virtualization Format) et son importation sur la plateforme cible (ex: qm importovf sur Proxmox) est une méthode standardisée mais souvent manuelle.⁶⁵</li> <li>Conversion Manuelle de Disques : Implique de copier les fichiers VMDK de VMware et de les convertir au format qcow2 ou raw en utilisant qemu-img, puis de créer manuellement une VM sur la cible en attachant ces disques.⁶⁷ C'est la méthode la plus flexible mais aussi la plus laborieuse et sujette aux erreurs.</li> <li>Outils de Sauvegarde/Restauration : Des solutions tierces comme Veeam (qui a annoncé le support de Proxmox pour le T3 2024 ¹⁹), Vinchin Backup &amp; Recovery ⁶⁸, ou d'autres supportant à la fois VMware et la cible open source ¹⁹, peuvent potentiellement être utilisées pour sauvegarder sur VMware et restaurer sur la nouvelle plateforme (V2V).</li> </ul> </li> <li><strong>Processus Typique</strong> : Souvent, cela implique une phase d'exportation/copie depuis VMware, une phase de conversion du format de disque et des métadonnées, et une phase d'importation/création sur la cible.⁷⁰ Les outils comme virt-v2v ou l'importateur Proxmox automatisent une partie de ce flux.⁶⁵ Des ajustements post-migration sont presque toujours nécessaires (installation/vérification des pilotes VirtIO, configuration réseau, vérification du boot).⁶⁴</li> <li><strong>Gestion du Downtime</strong> : La plupart des méthodes (export/import OVF, conversion manuelle, virt-v2v ⁶⁹) nécessitent que la VM source soit arrêtée (migration à froid ou "cold migration"). L'importateur Proxmox permet une migration "live" (à chaud), mais elle est plus longue et recommandée uniquement si l'arrêt n'est pas possible.⁶⁵ Les outils de sauvegarde/restauration peuvent offrir des options de restauration rapide minimisant le downtime.</li> </ul> </li> <li><strong>Migration VM-vers-Conteneur (Refactoring)</strong> : Il ne s'agit pas d'une migration d'infrastructure au sens strict, mais d'une réingénierie applicative. La complexité est très élevée et dépend entièrement de l'application. Cela sort du cadre de ce rapport centré sur les plateformes.</li> <li><strong>Migration VM-vers-KubeVirt (Re-platforming)</strong> : Déplacer une VM pour qu'elle s'exécute au sein d'un cluster Kubernetes géré par KubeVirt.<ul> <li><strong>Outils Disponibles</strong> :<ul> <li>Red Hat Migration Toolkit for Virtualization (MTV) : Intégré à OpenShift, il est spécifiquement conçu pour migrer des VMs (notamment VMware) vers OpenShift Virtualization.¹⁶ Il automatise le mapping réseau/stockage et la création des objets KubeVirt.⁵⁷</li> <li>Konveyor : Bien que la communauté Konveyor semble s'être recentrée sur le refactoring applicatif ⁷², ses outils comme Crane (migration inter-cluster K8s) ou Move2Kube (aide au re-platforming) peuvent être utiles dans un contexte plus large de modernisation.⁷³</li> <li>Approche Manuelle/Scriptée : Implique de convertir le disque VM (ex: VMDK vers qcow2/raw ou image de conteneur), de téléverser cette image vers un emplacement accessible par KubeVirt (ex: registry de conteneurs, PVC), et de créer les manifestes YAML pour les objets KubeVirt (VirtualMachine, VirtualMachineInstance, DataVolume, Service...).⁴⁸</li> </ul> </li> <li><strong>Processus Typique</strong> : La migration implique non seulement de déplacer les données du disque, mais aussi de traduire la configuration de la VM (CPU, RAM, réseau, stockage) en objets Kubernetes/KubeVirt. MTV simplifie grandement ce processus dans l'écosystème OpenShift.⁵⁷</li> <li><strong>Complexité</strong> : Nettement plus complexe qu'une migration VM-à-VM car elle nécessite une compréhension des concepts Kubernetes (Pods, Services, PVCs, CRDs) en plus de la virtualisation. Cependant, elle est moins disruptive qu'un refactoring complet de l'application.</li> </ul> </li> </ul> <p><strong>3.4. Performance et Scalabilité Comparées</strong></p> <p>La performance et la capacité à monter en charge sont des critères essentiels dans le choix d'une plateforme de virtualisation ou de conteneurisation.</p> <ul> <li><strong>Comparaison des Hyperviseurs (VMware vs KVM/Proxmox)</strong> :<ul> <li><em>Performance Brute</em> : KVM est souvent réputé pour ses performances proches du matériel natif, grâce à son intégration profonde dans le noyau Linux.¹⁵ Des benchmarks historiques (Phoronix 2011 ¹⁸) et plus récents (SPECvirt ¹⁹) le positionnent favorablement face à ESXi. Proxmox VE, basé sur KVM, hérite de ces bonnes performances. Une étude de Blockbridge en 2024 a même montré que Proxmox surpassait significativement ESXi 7.0u3 en termes d'IOPS (+50%), de latence (-30%) et de bande passante (+38%) dans des tests de stockage intensifs avec 32 VMs.¹⁹ L'écart semble se réduire sous charge normale.¹⁹ VMware ESXi reste cependant une plateforme très performante, optimisée pour les charges de travail d'entreprise.²⁸</li> <li><em>Gestion de la Performance</em> : VMware dispose d'outils avancés comme Distributed Resource Scheduler (DRS) pour l'équilibrage de charge automatique et l'optimisation des ressources au niveau du cluster ²⁴, un domaine où les alternatives open source peuvent être moins intégrées ou nécessiter une configuration manuelle plus poussée.</li> <li><em>Conclusion Partielle</em> : Pour la performance brute, notamment en stockage, KVM et Proxmox semblent très compétitifs, voire supérieurs dans certains scénarios. VMware conserve un avantage potentiel dans la gestion automatisée et sophistiquée de la performance à grande échelle grâce à son écosystème intégré.</li> </ul> </li> <li><strong>Comparaison VMware vs KubeVirt (VMs sur Kubernetes)</strong> :<ul> <li><em>Performance</em> : Il existe peu de benchmarks publics standardisés comparant directement la performance d'une VM sur ESXi versus la même VM sur KubeVirt. La performance sur KubeVirt dépendra fortement de KVM sous-jacent, mais aussi de la performance et de la configuration du cluster Kubernetes lui-même (performance du CNI pour le réseau, du CSI pour le stockage). L'objectif d'OpenShift Virtualization est d'offrir des performances de niveau entreprise.¹⁶</li> <li><em>Densité</em> : Un argument clé en faveur de KubeVirt est le potentiel d'une meilleure densité de workloads. En partageant le plan de contrôle Kubernetes et potentiellement des ressources système avec les conteneurs, KubeVirt pourrait permettre d'héberger plus de VMs sur le même matériel par rapport à une pile de virtualisation traditionnelle plus lourde.⁶¹ Des analyses TCO suggèrent des gains d'efficacité et une réduction de l'empreinte matérielle.⁶¹</li> </ul> </li> <li><strong>Scalabilité</strong> :<ul> <li><em>VMware</em> : Très éprouvé pour la scalabilité verticale et horizontale dans de très grands data centers.²⁸</li> <li><em>Proxmox VE</em> : Permet de créer des clusters de plusieurs nœuds ²⁷ et est utilisé dans des déploiements multi-sites.³³ La scalabilité est bonne, bien que peut-être moins testée aux extrêmes que VMware.</li> <li><em>KVM/OpenStack</em> : Conçus pour une scalabilité massive, formant la base de nombreux clouds publics et privés de grande taille.⁵</li> <li><em>Kubernetes</em> : L'un de ses points forts est la scalabilité horizontale des applications conteneurisées. KubeVirt, en s'intégrant à Kubernetes, hérite de cette capacité à gérer un grand nombre de VMs (pods virt-launcher) orchestrées par Kubernetes. La scalabilité réelle dépendra de la robustesse du control plane K8s et des capacités des nœuds workers.</li> </ul> </li> </ul> <p>La migration vers KubeVirt représente un changement de paradigme technique et opérationnel plus profond qu'une simple migration VM-à-VM. Elle ne consiste pas seulement à changer d'hyperviseur, mais à adopter une nouvelle plateforme d'orchestration (Kubernetes) pour gérer les VMs. Cela impose une <strong>convergence des compétences et des outils</strong> traditionnellement séparés entre les équipes d'infrastructure (gestion des VMs) et les équipes applicatives/DevOps (gestion des conteneurs et de Kubernetes). La gestion du cycle de vie des VMs, de leur réseau (via CNI et Services K8s) et de leur stockage (via CSI et PVCs) se fait désormais avec les mécanismes et les API de Kubernetes.³⁷ Cette approche intégrée promet une plateforme unifiée ⁴⁹, mais exige que les administrateurs de virtualisation acquièrent une compréhension de Kubernetes ⁵⁹ et que les processus opérationnels s'alignent sur les pratiques DevOps (Infrastructure as Code, GitOps, CI/CD).⁵⁴</p> <p><strong>4. Évaluation des Défis Opérationnels et Organisationnels</strong></p> <p>Au-delà des aspects purement techniques, la migration de VMware vers des solutions open source engendre des défis opérationnels et organisationnels significatifs. Le succès de la transition dépend largement de la capacité de l'entreprise à anticiper et à gérer ces changements, qui touchent aux compétences des équipes, aux outils utilisés au quotidien, aux modèles de support et à la structure globale des coûts.</p> <p><strong>4.1. Besoins en Nouvelles Compétences</strong></p> <p>Le passage à un écosystème open source, qu'il s'agisse de virtualisation classique ou de Kubernetes, exige une adaptation et souvent une montée en compétence significative des équipes IT.</p> <ul> <li><strong>Compétences pour la Virtualisation Open Source (Proxmox, KVM, Xen, oVirt)</strong> :<ul> <li>Une <strong>maîtrise solide de l'environnement Linux</strong> est quasi indispensable, car la plupart de ces solutions reposent sur ce système d'exploitation.⁵</li> <li>Une <strong>connaissance de l'hyperviseur sous-jacent (KVM ou Xen)</strong> est nécessaire pour le dépannage avancé et l'optimisation.⁵</li> <li>La familiarité avec les <strong>outils spécifiques à la plateforme choisie</strong> (interface web et ligne de commande Proxmox ²⁰, libvirt pour KVM, Xen Orchestra pour XCP-ng) et les <strong>technologies de stockage et réseau associées</strong> (Ceph, ZFS, GlusterFS, LVM, Open vSwitch) est cruciale.⁵</li> <li>Les équipes devront potentiellement être plus à l'aise avec la <strong>ligne de commande</strong> et le <strong>scripting</strong> pour l'automatisation et certaines tâches de gestion, car les interfaces graphiques, bien qu'existantes (surtout pour Proxmox et oVirt), peuvent être moins exhaustives que vCenter pour couvrir l'ensemble des fonctionnalités avancées.⁵</li> </ul> </li> <li><strong>Compétences pour Kubernetes et KubeVirt</strong> : La transition vers une plateforme basée sur Kubernetes représente un saut de complexité plus important.<ul> <li>Une <strong>compréhension approfondie de Kubernetes</strong> est fondamentale : architecture (control plane, nœuds workers), objets clés (Pods, Deployments, Services, Ingress, ConfigMaps, Secrets), API, ligne de commande (kubectl), concepts réseau (CNI, Services, Ingress) et stockage (CSI, PV, PVC, StorageClasses).⁷⁴</li> <li>La <strong>gestion des conteneurs</strong> (Docker, containerd, CRI-O) et la capacité à construire et gérer des images de conteneurs sont nécessaires.</li> <li>Des compétences spécifiques à <strong>KubeVirt</strong> pour la définition et la gestion des VMs via les CRDs sont requises.</li> <li>La maîtrise des <strong>outils de l'écosystème Kubernetes</strong> est essentielle pour une exploitation en production : monitoring (Prometheus, Grafana ³⁷), logging (EFK/Loki), automatisation et déploiement (Helm, Kustomize, GitOps avec ArgoCD/Flux), gestion de la sécurité (Network Policies, OPA/Gatekeeper, scanners de vulnérabilités), et potentiellement service mesh (Istio, Linkerd).</li> <li>Des compétences en <strong>automatisation d'infrastructure</strong> (Ansible ⁵, Terraform ¹) sont également très utiles.</li> <li>La <strong>courbe d'apprentissage</strong> pour maîtriser cet ensemble est reconnue comme étant raide.⁶</li> </ul> </li> <li><strong>Comparaison avec les Compétences VMware</strong> : Les administrateurs VMware, certifiés VCP par exemple ⁷⁴, possèdent une expertise spécifique sur l'écosystème vSphere/vCenter.⁷⁵ Bien que certaines compétences soient transférables (concepts de virtualisation, réseau, stockage), une part importante de nouvelles connaissances doit être acquise pour gérer efficacement les plateformes open source, et plus encore pour Kubernetes.¹ VMware positionne sa solution Tanzu comme un moyen de tirer parti des compétences vSphere existantes pour aborder Kubernetes ⁷⁵, mais une migration vers des solutions open source pures demandera un investissement conséquent en formation.¹</li> <li><strong>Impact Organisationnel</strong> : Pour combler ce fossé de compétences, les entreprises devront investir dans la <strong>formation</strong> de leurs équipes existantes ¹, potentiellement <strong>recruter</strong> de nouveaux profils avec une expertise Linux/KVM/Kubernetes, ou <strong>s'appuyer sur des partenaires externes</strong> (consultants, sociétés de services spécialisées en open source) pour la migration et/ou l'exploitation.¹ La migration vers Kubernetes, en particulier, peut favoriser une <strong>convergence des équipes</strong> infrastructure et développement/DevOps, nécessitant une adaptation des structures organisationnelles.⁵⁴</li> </ul> <p><strong>4.2. Maturité des Outils de Gestion, Supervision et Sécurité</strong></p> <p>L'écosystème VMware, avec vCenter et la suite vRealize (maintenant Aria), offre une plateforme de gestion, de supervision et de sécurité très intégrée et mature.²⁰ Les alternatives open source présentent un paysage plus hétérogène.</p> <ul> <li><strong>Gestion Centralisée</strong> :<ul> <li><em>Proxmox VE</em> offre une interface web intégrée et assez complète pour gérer le cluster, les VMs, les conteneurs, le stockage et le réseau.¹² Elle est souvent louée pour sa convivialité.²⁰ Cependant, pour l'automatisation avancée (provisioning type vRA/vRO), des outils externes (Ansible, Terraform) sont nécessaires.¹</li> <li><em>oVirt</em> fournit également une interface de gestion centralisée de niveau entreprise.⁵</li> <li><em>KVM/Xen purs</em> nécessitent des outils de gestion tiers (comme virt-manager pour une gestion locale/simple, ou des solutions plus complexes comme OpenStack Horizon ou Xen Orchestra).</li> <li><em>Kubernetes</em> : Le Dashboard Kubernetes officiel est limité. Des outils comme Lens ou Octant offrent de meilleures interfaces graphiques. Les distributions comme OpenShift ⁴¹ et Rancher ⁴¹ fournissent des consoles web beaucoup plus riches et intégrées. Pour la gestion multi-cluster et la gouvernance, des outils comme Red Hat Advanced Cluster Management (ACM) ¹⁶ ou Rancher lui-même sont des solutions dédiées.</li> </ul> </li> <li><strong>Supervision (Monitoring &amp; Logging)</strong> :<ul> <li><em>Proxmox VE</em> inclut des capacités de monitoring de base des ressources (CPU, RAM, disque, réseau) visibles dans l'interface web ²⁷, avec une intégration possible vers InfluxDB/Graphite.²⁷ Les logs sont gérés via les mécanismes standards de Linux (syslog, journald).³¹ Pour une supervision et une centralisation des logs avancées, des outils externes (Zabbix, Checkmk, ELK/EFK/Loki stack) sont généralement nécessaires.³¹</li> <li><em>KVM/Xen/Linux</em> : Reposent entièrement sur l'écosystème d'outils de monitoring et de logging Linux/open source (Nagios, Zabbix, Prometheus Node Exporter, Fluentd, etc.).</li> <li><em>Kubernetes</em> : Possède un écosystème de supervision très riche et devenu un standard de facto, basé principalement sur <strong>Prometheus</strong> pour les métriques, <strong>Grafana</strong> pour la visualisation ³⁷, et Alertmanager pour les alertes. Pour les logs, des agents comme Fluentd ou FluentBit sont utilisés pour collecter les logs des conteneurs et les envoyer vers des systèmes de centralisation comme Elasticsearch, OpenSearch ou Loki. Ces outils sont souvent pré-intégrés et configurés dans les distributions comme OpenShift (OpenShift Monitoring) et Rancher (Rancher Monitoring).</li> </ul> </li> <li><strong>Sécurité</strong> :<ul> <li><em>VMware</em> offre un ensemble robuste de fonctionnalités de sécurité : pare-feu distribué et micro-segmentation avec NSX ²⁴, chiffrement des VMs au repos et en mouvement (vMotion chiffré) ³¹, chiffrement vSAN ³¹, intégration avec des modules TPM matériels ou virtuels, Secure Boot, et des outils pour la conformité (ex: vSphere Trust Authority).²⁰ Cet ensemble facilite l'atteinte des exigences de conformité réglementaire (HIPAA, PCI-DSS...).⁷</li> <li><em>Proxmox VE</em> fournit des fonctionnalités de sécurité de base : pare-feu intégré au niveau de l'hôte et du cluster (basé sur iptables) ²⁷, gestion fine des permissions via RBAC ³¹, support de l'authentification à deux facteurs (2FA).²⁰ Le chiffrement des volumes est possible (ex: via LUKS ou ZFS) mais nécessite une configuration manuelle.³¹ Les fonctionnalités de sécurité réseau avancées (type micro-segmentation) ne sont pas natives.³¹ La sécurité repose beaucoup sur la sécurisation de l'OS Debian sous-jacent. Les fonctionnalités intégrées pour la conformité sont limitées.³¹</li> <li><em>KVM/Linux</em> bénéficient des mécanismes de sécurité éprouvés de Linux, notamment SELinux ou AppArmor pour le Mandatory Access Control (MAC).¹⁵ KVM utilise également sVirt pour renforcer l'isolation des VMs.¹⁷</li> <li><em>Kubernetes</em> intègre plusieurs mécanismes de sécurité : Network Policies pour la segmentation réseau au niveau des pods, gestion des secrets, contrôle d'accès basé sur les rôles (RBAC), Security Contexts pour définir les privilèges des conteneurs, Pod Security Admission/Policies pour renforcer la sécurité des pods. Les distributions comme OpenShift vont plus loin en activant SELinux par défaut et en utilisant des Security Context Constraints (SCCs) plus stricts.⁴¹ L'écosystème K8s propose de nombreux outils tiers pour le scan de vulnérabilités (images, configurations), la sécurité runtime (Falco, Sysdig Secure ⁴⁴), et la gestion centralisée des politiques de sécurité (OPA/Gatekeeper, Kyverno ³⁷).</li> </ul> </li> <li><strong>Maturité Globale de l'Outillage</strong> : L'écosystème d'outils VMware est reconnu pour sa maturité, son intégration et sa couverture fonctionnelle étendue, fruit de nombreuses années de développement.⁷⁶ Du côté open source, la situation est variable. Proxmox offre une solution bien intégrée mais avec un périmètre fonctionnel potentiellement moins large que la suite VMware complète. Utiliser KVM ou Xen purs nécessite d'assembler et d'intégrer soi-même les différentes briques d'outillage (gestion, monitoring, sauvegarde, sécurité), ce qui demande du temps et de l'expertise. L'écosystème Kubernetes est extrêmement dynamique et innovant, avec des outils très puissants, mais il peut aussi apparaître fragmenté et complexe à maîtriser et à intégrer de manière cohérente.⁴⁵ Les distributions Kubernetes comme OpenShift et Rancher visent précisément à simplifier cette intégration en proposant des ensembles d'outils pré-validés et supportés.</li> </ul> <p><strong>4.3. Modèles de Support : Communautaire vs. Entreprise</strong></p> <p>Le modèle de support est une considération critique, en particulier pour les environnements de production.</p> <ul> <li><strong>Support Communautaire</strong> (Typique pour KVM/Xen purs, K8s vanilla, Proxmox sans souscription) :<ul> <li><em>Avantages</em> : Il est <strong>gratuit</strong> et donne accès à une vaste base de connaissances collective via les forums, les listes de diffusion, la documentation en ligne, les blogs, etc..⁵ Pour des problèmes courants ou des questions générales, la communauté peut être très réactive et fournir des solutions efficaces.³¹</li> <li><em>Inconvénients</em> : Il n'offre <strong>aucune garantie de temps de réponse (SLA)</strong>.⁷⁷ La résolution de problèmes complexes ou spécifiques peut dépendre de la disponibilité et de la bonne volonté des membres de la communauté.⁶ Il n'y a pas d'interlocuteur unique responsable en cas d'incident majeur. Ce modèle est souvent jugé <strong>insuffisant pour les applications et infrastructures critiques</strong> en entreprise.⁷⁶</li> </ul> </li> <li><strong>Support Entreprise</strong> (Proposé par des éditeurs comme Red Hat, SUSE, Canonical, ou Proxmox Server Solutions GmbH pour leurs produits/distributions basés sur l'open source) :<ul> <li><em>Avantages</em> : Fournit des <strong>niveaux de service garantis (SLAs)</strong>, un accès à des <strong>équipes d'experts dédiées</strong>, un support technique potentiellement <strong>24/7</strong> pour les incidents critiques, la fourniture de <strong>correctifs de sécurité validés</strong> et une <strong>feuille de route produit claire</strong>.⁵ Il offre une <strong>responsabilité</strong> claire en cas de problème et est généralement considéré comme <strong>indispensable pour les environnements de production critiques</strong>.³⁰</li> <li><em>Inconvénients</em> : Représente un <strong>coût récurrent</strong> (modèle de souscription annuel).¹¹ Bien que souvent inférieur aux coûts de licence VMware ¹¹, il doit être budgété. Il peut également lier l'entreprise à l'écosystème et aux cycles de vie du fournisseur de support choisi.⁴⁷</li> </ul> </li> <li><strong>Le Choix du Modèle</strong> : La décision dépendra fortement de la <strong>criticité des charges de travail</strong> hébergées, du <strong>niveau d'expertise technique interne</strong>, du <strong>budget alloué au support</strong> et de l'<strong>appétence au risque</strong> de l'organisation.²⁰ De nombreuses entreprises choisissent de souscrire à un support entreprise pour sécuriser leurs déploiements open source en production, considérant que le coût est justifié par la réduction du risque opérationnel.⁸ Pour les environnements non critiques (développement, test, pré-production), le support communautaire peut être suffisant.</li> </ul> <p><strong>4.4. Analyse Comparative du Coût Total de Possession (TCO)</strong></p> <p>L'analyse du TCO est essentielle pour comparer équitablement VMware et ses alternatives open source, en allant au-delà du simple coût des licences logicielles.</p> <ul> <li><strong>Composantes du TCO à Considérer</strong> :<ul> <li><strong>Coûts Logiciels (Licences et Souscriptions)</strong> : C'est le point de divergence le plus évident. VMware impose désormais des abonnements par cœur coûteux.¹ Les solutions open source de base (KVM, Xen, K8s vanilla, Proxmox sans support) n'ont pas de coût de licence.¹ Les distributions et plateformes open source avec support entreprise (OpenShift, Rancher, Proxmox avec support) ont des coûts de souscription, mais souvent inférieurs aux licences VMware équivalentes.¹¹</li> <li><strong>Coûts de Support</strong> : Pour VMware, le support est généralement inclus dans l'abonnement. Pour l'open source, il faut choisir entre le support communautaire (gratuit mais risqué) et le support entreprise (coût additionnel).³²</li> <li><strong>Coûts Matériels</strong> : Les besoins matériels peuvent varier. Proxmox VE est réputé moins gourmand en ressources pour l'hyperviseur lui-même que ESXi.¹⁹ L'adoption de KubeVirt et des conteneurs peut potentiellement améliorer la densité des workloads et réduire l'empreinte matérielle globale par rapport à une infrastructure 100% VM.⁶¹ Cependant, certaines plateformes comme OpenShift peuvent avoir des prérequis matériels minimaux plus élevés.</li> <li><strong>Coûts Opérationnels (Personnel et Compétences)</strong> : C'est un facteur clé souvent sous-estimé. Si les compétences requises pour les solutions open source (Linux, KVM, K8s, Ceph...) manquent en interne, les coûts liés à la formation, au recrutement de nouveaux profils ou à l'externalisation (consultants, infogérance) peuvent être significatifs et potentiellement compenser les économies de licences.⁶ L'investissement dans l'automatisation (Ansible, Terraform) peut cependant aider à maîtriser ces coûts à terme.⁵</li> <li><strong>Coûts de Migration</strong> : Le projet de migration lui-même a un coût (temps des équipes internes, potentiels outils ou services externes, downtime éventuel).</li> <li><strong>Coûts de Formation</strong> : Nécessaires pour assurer la montée en compétence des équipes.¹</li> <li><strong>Coûts des Outils Tiers</strong> : Si la plateforme open source choisie nécessite des outils complémentaires pour le monitoring, la sécurité ou la sauvegarde avancée, leurs coûts doivent être inclus dans le TCO.</li> </ul> </li> <li><strong>Comparaisons Spécifiques du TCO</strong> :<ul> <li><em>VMware vs. Proxmox VE</em> : Grâce à l'absence de coût de licence, Proxmox présente souvent un TCO plus avantageux, même en incluant une souscription de support.¹⁹ Une discussion sur Reddit ³² montre des avis partagés, certains estimant que VMware Standard est compétitif face à Proxmox Premium, tandis que d'autres rapportent des économies substantielles avec Proxmox. Le choix du niveau de support Proxmox et les compétences internes sont déterminants.¹¹</li> <li><em>VMware vs. OpenShift Virtualization</em> : OpenShift, via son modèle de souscription, peut offrir un TCO inférieur, en particulier pour les entreprises déjà engagées avec Red Hat ou celles qui bénéficient des gains de densité et d'agilité apportés par la plateforme unifiée VM/conteneurs.⁵⁴ Une analyse TCO de Platform9 (fournissant KubeVirt managé) comparée à VMware a montré une réduction de 49% sur 5 ans, en incluant les coûts opérationnels et de licence.⁶¹</li> <li><em>VMware vs. KVM (DIY)</em> : Le coût de licence KVM est nul, mais le TCO global dépendra entièrement des coûts d'implémentation (assemblage des outils), de gestion (compétences internes requises) et de support (interne ou externe).¹⁵</li> </ul> </li> <li><strong>Facteurs Clés pour l'Analyse TCO</strong> : Il est crucial de ne pas se focaliser uniquement sur le coût des licences logicielles.¹¹ Une analyse TCO rigoureuse doit modéliser l'ensemble des coûts sur plusieurs années (typiquement 3 à 5 ans), en incluant les coûts opérationnels (personnel, formation), les coûts de support (interne vs externe, SLA requis), les coûts matériels (potentiels gains de densité), et les coûts de migration initiaux. Des outils de calcul TCO peuvent être utiles s'ils sont disponibles et adaptés (ex: Scale Computing ²⁶, Platform9 ⁶¹).</li> </ul> <p>L'analyse du TCO des solutions open source révèle une complexité souvent sous-estimée. Si l'économie sur les licences logicielles est un avantage indéniable et immédiat ¹, elle peut être contrebalancée par d'autres facteurs. Les coûts potentiellement plus élevés liés au <strong>besoin accru de compétences spécifiques</strong> (internes ou externes) ⁶, à l'<strong>intégration d'outils</strong> qui peuvent être perçus comme moins matures ou plus fragmentés que la suite VMware ⁵, et au <strong>risque opérationnel</strong> associé au support communautaire pour les environnements critiques ⁶ doivent impérativement être pris en compte. Une analyse TCO sérieuse ne peut se contenter de comparer les prix affichés des licences ou des souscriptions ; elle doit intégrer une évaluation réaliste de ces coûts opérationnels, de support et de risque sur le long terme.¹¹</p> <p><strong>Tableau 4.1 : Analyse Comparative des Facteurs TCO (VMware vs. Proxmox vs. OpenShift)</strong></p> <table> <tr> <td><strong>Catégorie de Coût</strong> </td> <td><strong>VMware vSphere (Abonnement)</strong> </td> <td><strong>Proxmox VE (+ Support Premium)</strong> </td> <td><strong>OpenShift Platform Plus (+ Virt.)</strong> </td> <td><strong>Facteurs Clés d'Influence</strong> </td> </tr> <tr> <td><strong>Licences/Souscriptions</strong> </td> <td>Très Élevé </td> <td>Faible (Support uniquement) </td> <td>Élevé </td> <td>Modèle par cœur VMware, Coût support Proxmox, Édition OpenShift </td> </tr> <tr> <td><strong>Support Annuel</strong> </td> <td>Inclus (Très Élevé) </td> <td>Faible à Moyen </td> <td>Inclus (Élevé) </td> <td>Niveau de SLA requis, Compétences internes </td> </tr> <tr> <td><strong>Matériel Initial/Rafraîch.</strong> </td> <td>Moyen à Élevé </td> <td>Moyen </td> <td>Moyen à Élevé </td> <td>Densité workloads, Prérequis plateforme (OShift > Proxmox) </td> </tr> <tr> <td><strong>Personnel Opérationnel</strong> </td> <td>Moyen </td> <td>Moyen à Élevé </td> <td>Élevé </td> <td>Compétences Linux/KVM/K8s internes, Niveau d'automatisation </td> </tr> <tr> <td><strong>Formation Initiale/Continue</strong> </td> <td>Faible (si déjà expert) </td> <td>Moyenne (Linux/Proxmox) </td> <td>Élevée (K8s/OpenShift) </td> <td>Écart de compétences initial, Complexité plateforme </td> </tr> <tr> <td><strong>Migration Initiale</strong> </td> <td>N/A </td> <td>Faible à Moyen </td> <td>Moyen à Élevé </td> <td>Complexité source, Outils utilisés, Recours à services tiers </td> </tr> <tr> <td><strong>Outils Tiers (Monitor/Secu...)</strong> </td> <td>Faible (suite intégrée) </td> <td>Moyen </td> <td>Faible à Moyen (suite intégrée) </td> <td>Niveau de fonctionnalités requis vs. intégré </td> </tr> <tr> <td><strong>TCO Global Estimé (3-5 ans)</strong> </td> <td>Très Élevé </td> <td><strong>Faible à Moyen</strong> </td> <td><strong>Moyen à Élevé</strong> </td> <td><strong>Fortement dépendant des coûts opérationnels et de support</strong> </td> </tr> </table> <p><em>Évaluation qualitative : Faible &lt; Moyen &lt; Élevé &lt; Très Élevé. Le TCO global est une estimation comparative.</em></p> <p>Le passage à l'open source, que ce soit vers la virtualisation ou Kubernetes, représente bien plus qu'un simple changement d'outil technologique. C'est une <strong>transformation opérationnelle profonde</strong> qui impacte les compétences requises ⁶, les outils de gestion et de supervision utilisés au quotidien ³¹, les processus de déploiement et de maintenance, et les modèles de support.³¹ Le succès d'une telle migration dépend donc autant de la robustesse de la technologie choisie que de la capacité de l'organisation à <strong>gérer ce changement organisationnel et culturel</strong>.</p> <p><strong>5. Stratégies de Migration Détaillées</strong></p> <p>Une fois la décision de migrer prise et la plateforme cible sélectionnée, il est essentiel de définir une stratégie de migration claire et une approche de déploiement adaptée au contexte de l'entreprise. Plusieurs méthodologies existent, chacune avec ses avantages, ses inconvénients et ses cas d'usage privilégiés.</p> <p><strong>5.1. Les "6 R" de la Migration Cloud (Adaptées au contexte VMware vers Open Source)</strong></p> <p>Bien qu'originellement définies pour les migrations vers le cloud public, les stratégies des "6 R" offrent un cadre utile pour penser la migration depuis VMware :</p> <ul> <li><strong>Rehost (Lift and Shift)</strong> : Cette stratégie consiste à déplacer les machines virtuelles (VMs) de l'environnement VMware vers la nouvelle plateforme (hyperviseur open source comme KVM/Proxmox, ou plateforme KubeVirt sur Kubernetes) avec un minimum de modifications.⁵⁵ L'objectif principal est la rapidité et la minimisation des changements applicatifs initiaux.<ul> <li><em>Avantages</em> : C'est généralement l'approche la <strong>plus rapide</strong> et la <strong>moins risquée à court terme</strong>, car elle ne touche pas au fonctionnement interne des applications.⁶² Elle permet de quitter rapidement l'infrastructure VMware source.</li> <li><em>Inconvénients</em> : Elle <strong>ne tire pas pleinement parti des capacités</strong> de la nouvelle plateforme (élasticité native de K8s, fonctionnalités de stockage avancées de Proxmox/Ceph, etc.).⁵⁵ Les VMs migrées peuvent conserver des inefficacités ou des configurations sous-optimales pour le nouvel environnement. C'est souvent une étape tactique plutôt qu'une optimisation finale.</li> </ul> </li> <li><strong>Replatform (Lift and Reshape)</strong> : Ici, on apporte des <strong>modifications ciblées</strong> aux VMs ou à leur environnement pour mieux exploiter les capacités de la plateforme cible, sans pour autant réécrire complètement les applications.⁶² Exemples :<ul> <li>Migrer une VM vers <strong>KubeVirt</strong> pour la gérer via l'API Kubernetes.³⁷</li> <li>Modifier une application pour utiliser un service de base de données managé si la cible est un cloud public.⁵⁵</li> <li>Adapter la configuration de stockage pour utiliser des fonctionnalités spécifiques comme ZFS ou Ceph sur Proxmox, ou des vVols sur un stockage compatible.⁶²</li> <li>Installer ou optimiser les pilotes VirtIO après une migration vers KVM/Proxmox.</li> <li><em>Avantages</em> : Permet de réaliser des <strong>gains d'efficacité ou de fonctionnalité</strong> par rapport au Lift and Shift, sans l'effort d'une refonte complète.⁶² Offre un bon <strong>équilibre entre l'effort et les bénéfices</strong>.</li> <li><em>Inconvénients</em> : Nécessite plus de planification, de tests et potentiellement d'expertise que le Lift and Shift.</li> </ul> </li> <li><strong>Refactor / Re-architect</strong> : Cette stratégie implique une <strong>modernisation profonde</strong> des applications, souvent en les redéveloppant ou en les ré-architecturant pour adopter une approche cloud-native.⁵⁵ Cela signifie typiquement décomposer des applications monolithiques en microservices, les conteneuriser (avec Docker par exemple), et les déployer nativement sur une plateforme d'orchestration comme Kubernetes.<ul> <li><em>Avantages</em> : Permet de <strong>tirer pleinement parti des avantages du cloud-native</strong> : scalabilité horizontale, résilience, agilité de déploiement (CI/CD), optimisation des coûts à long terme grâce à une meilleure utilisation des ressources.⁶² C'est la voie vers une transformation applicative complète.</li> <li><em>Inconvénients</em> : C'est de loin l'approche la <strong>plus complexe, la plus longue, la plus coûteuse et la plus risquée</strong>.⁶² Elle nécessite des compétences avancées en développement logiciel, en architecture microservices et en Kubernetes.</li> </ul> </li> <li><strong>Repurchase</strong> : Remplacer une application existante hébergée sur une VM par une solution logicielle en mode SaaS (Software as a Service).⁷⁸ Moins une stratégie de migration d'infrastructure qu'une décision applicative, mais elle peut réduire le nombre de VMs à migrer.</li> <li><strong>Retain</strong> : Décider de <strong>conserver certaines applications ou workloads sur l'infrastructure VMware existante</strong> (ou une version réduite/dédiée de celle-ci).⁷⁸ Cette approche hybride peut être pertinente pour des applications très critiques, très spécifiques, difficiles ou coûteuses à migrer, ou soumises à des contraintes réglementaires particulières.</li> <li><strong>Retire</strong> : Identifier et <strong>décommissionner les applications ou VMs qui ne sont plus utilisées</strong> ou dont la valeur métier est devenue nulle.⁷⁸ C'est une étape importante de nettoyage à réaliser avant ou pendant la migration pour ne pas déplacer des systèmes obsolètes.</li> </ul> <p><strong>Tableau 5.1 : Comparaison des Stratégies de Migration (Lift &amp; Shift vs. Replatform vs. Refactor)</strong></p> <table> <tr> <td><strong>Stratégie</strong> </td> <td><strong>Effort / Complexité</strong> </td> <td><strong>Risque Initial</strong> </td> <td><strong>Durée Estimée</strong> </td> <td><strong>Coût Initial</strong> </td> <td><strong>Bénéfices Cloud-Native</strong> </td> <td><strong>Compétences Requises (Focus)</strong> </td> </tr> <tr> <td><strong>Lift & Shift (Rehost)</strong> </td> <td>Faible </td> <td>Faible </td> <td>Courte </td> <td>Faible </td> <td>Très Limités </td> <td>Infrastructure, Outils Migration </td> </tr> <tr> <td><strong>Replatform</strong> </td> <td>Moyen </td> <td>Moyen </td> <td>Moyenne </td> <td>Moyen </td> <td>Modérés </td> <td>Infra, Plateforme Cible, App (léger) </td> </tr> <tr> <td><strong>Refactor</strong> </td> <td>Très Élevé </td> <td>Très Élevé </td> <td>Longue </td> <td>Très Élevé </td> <td>Maximaux </td> <td>Développement, Architecture, K8s </td> </tr> </table> <p><strong>5.2. Approches de Déploiement de la Migration</strong></p> <p>Une fois la stratégie choisie (comment migrer), il faut décider de l'approche de déploiement (quand et à quel rythme migrer).</p> <ul> <li><strong>Big Bang</strong> : Cette approche consiste à migrer <strong>l'ensemble de l'environnement</strong> concerné (ou un large périmètre fonctionnel) <strong>en une seule fois</strong>, généralement pendant une fenêtre de maintenance planifiée et étendue.⁷⁹ L'ancien système est arrêté, la migration est effectuée, le nouveau système est démarré et validé.<ul> <li><em>Avantages</em> : La <strong>durée totale du projet de migration est plus courte</strong>. Il n'y a <strong>pas de complexité liée à la gestion de deux systèmes en parallèle</strong> sur une longue période. La transition est nette et claire pour tous les utilisateurs. Les coûts peuvent être inférieurs à court terme car l'effort est concentré.⁷⁹ Cette approche peut convenir aux environnements de petite taille, peu complexes, ou lorsque l'organisation peut tolérer une interruption de service planifiée et souhaite une coupure franche.⁷⁹</li> <li><em>Inconvénients</em> : Le <strong>risque est maximal</strong> : si un problème majeur survient pendant la migration ou lors du redémarrage, l'ensemble du périmètre migré est impacté, et un retour arrière (rollback) peut être très complexe et coûteux.⁷⁹ Elle nécessite une <strong>planification extrêmement rigoureuse</strong> et des <strong>tests préalables exhaustifs</strong> pour minimiser les imprévus. Le <strong>downtime requis peut être long</strong>, ce qui est inacceptable pour de nombreuses activités critiques fonctionnant 24/7.⁷⁹ La <strong>pression sur les équipes</strong> de migration est immense pendant la fenêtre de bascule. Il y a <strong>peu de flexibilité</strong> pour ajuster la stratégie en cours de route.⁸⁰</li> </ul> </li> <li><strong>Phased / Trickle / Progressive (Par Lots)</strong> : L'environnement est divisé en <strong>unités logiques plus petites</strong> (par application, par service métier, par criticité, par localisation géographique...) qui sont migrées <strong>étape par étape</strong>, sur une période de temps plus étendue.⁷⁹<ul> <li><em>Avantages</em> : Le <strong>risque est considérablement réduit</strong> : un échec lors de la migration d'un lot n'affecte que ce périmètre limité et est plus facile à gérer ou à annuler.⁷⁹ Le <strong>downtime est limité</strong> à chaque lot (voire nul pour certaines migrations à chaud). L'approche permet aux équipes de <strong>gagner en expérience</strong> au fur et à mesure, d'<strong>identifier et de corriger les problèmes</strong> rencontrés sur les premiers lots, et d'<strong>ajuster la méthodologie</strong> pour les lots suivants.⁷⁹ L'<strong>adaptation des utilisateurs</strong> au nouveau système est également plus progressive.⁸¹ C'est généralement l'approche <strong>préférée pour les environnements complexes, critiques ou de grande taille</strong>.</li> <li><em>Inconvénients</em> : La <strong>durée totale du projet de migration est plus longue</strong>.⁷⁹ Elle nécessite de <strong>gérer la coexistence</strong> de l'ancien et du nouvel environnement pendant la période de transition, ce qui peut être complexe (synchronisation de données, gestion des identités, dépendances inter-lots, routage réseau).⁷⁹ Les <strong>coûts opérationnels peuvent être plus élevés</strong> pendant cette période car deux systèmes doivent être maintenus et potentiellement synchronisés.⁷⁹ La gestion du projet est plus complexe en raison des multiples phases.⁸¹</li> </ul> </li> <li><strong>Migration Parallèle</strong> : Une variante de l'approche progressive où l'ancien et le nouveau système fonctionnent <strong>simultanément pendant une période de validation</strong>, traitant potentiellement les mêmes transactions ou données.⁸¹<ul> <li><em>Avantages</em> : C'est l'approche la <strong>moins risquée</strong> car elle permet une validation complète du nouveau système avant de décommissionner l'ancien.</li> <li><em>Inconvénients</em> : C'est souvent la <strong>plus coûteuse et la plus complexe</strong> à mettre en œuvre, car elle peut nécessiter une double saisie de données ou des mécanismes de synchronisation complexes, et implique de maintenir deux infrastructures complètes en production.⁸¹</li> </ul> </li> </ul> <p><strong>Tableau 5.2 : Comparaison des Approches de Déploiement (Big Bang vs. Phased)</strong></p> <table> <tr> <td><strong>Approche</strong> </td> <td><strong>Risque Global</strong> </td> <td><strong>Durée Totale Projet</strong> </td> <td><strong>Coût Total Estimé</strong> </td> <td><strong>Impact Opérationnel (Downtime)</strong> </td> <td><strong>Complexité Gestion (Pendant Migration)</strong> </td> <td><strong>Flexibilité / Ajustement</strong> </td> </tr> <tr> <td><strong>Big Bang</strong> </td> <td>Très Élevé </td> <td>Courte </td> <td>Potent. Inférieur </td> <td>Élevé (Unique et Long) </td> <td>Faible (Transition Nette) </td> <td>Faible </td> </tr> <tr> <td><strong>Phased / Progressive</strong> </td> <td>Réduit </td> <td>Longue </td> <td>Potent. Supérieur </td> <td>Faible (Par Lot) </td> <td>Élevée (Coexistence) </td> <td>Élevée </td> </tr> </table> <p>Le choix de la stratégie de migration ("R") influence souvent l'approche de déploiement la plus réaliste. Par exemple, une stratégie de <strong>Refactoring</strong> ⁶², intrinsèquement longue et complexe, se prête mal à une approche <strong>Big Bang</strong> ⁷⁹ pour un environnement d'entreprise significatif. Elle sera presque toujours déployée de manière <strong>progressive</strong>.⁷⁹ À l'inverse, un <strong>Lift and Shift</strong> ⁶², étant plus simple, peut être envisagé soit en Big Bang (pour des petits périmètres) soit par lots. Le <strong>Replatforming</strong> ⁶², avec des modifications intermédiaires, offre plus de flexibilité quant à l'approche de déploiement. La nature de la transformation visée (simple déplacement vs optimisation vs refonte) dicte en partie le rythme et le séquencement possibles de la migration.</p> <p><strong>5.3. Planification et Exécution</strong></p> <p>Quelle que soit la stratégie ou l'approche choisie, une planification rigoureuse et une exécution méthodique sont indispensables à la réussite.</p> <ul> <li><strong>Évaluation Pré-migration</strong> : Réaliser un audit complet de l'environnement VMware existant (inventaire des VMs, configurations matérielles et logicielles, utilisation des ressources, dépendances applicatives et réseau).¹ Définir des objectifs clairs et mesurables pour la migration (réduction des coûts, amélioration des performances, gain d'agilité...).⁷⁰ Identifier les contraintes (budgétaires, temporelles, réglementaires).</li> <li><strong>Feuille de Route (Roadmap)</strong> : Élaborer un plan de migration détaillé, incluant les étapes clés, la priorisation des workloads (basée sur la criticité, la complexité, les dépendances), les outils à utiliser, les responsabilités de chaque équipe, et un calendrier réaliste.¹</li> <li><strong>Tests Pilotes (Proof of Concept - PoC)</strong> : Avant de lancer la migration à grande échelle, il est crucial de valider le processus, les outils et la plateforme cible sur un échantillon représentatif et non critique de VMs ou d'applications.⁶² Ces pilotes permettent d'identifier les problèmes potentiels (techniques, performance, compatibilité), d'affiner la méthodologie et de former les équipes.</li> <li><strong>Sauvegarde et Plan de Retour Arrière (Rollback)</strong> : Mettre en place une stratégie de sauvegarde robuste pour toutes les VMs et données avant de commencer la migration.⁶² Définir et tester un plan de retour arrière clair pour chaque phase de migration en cas d'échec majeur.</li> <li><strong>Exécution de la Migration</strong> : Suivre la feuille de route, utiliser les outils choisis, communiquer étroitement entre les équipes, et documenter le processus.</li> <li><strong>Suivi et Optimisation Post-migration</strong> : Une fois les VMs migrées, surveiller attentivement leurs performances et leur stabilité sur la nouvelle plateforme.¹ Procéder aux ajustements et optimisations nécessaires (tuning des ressources, configuration réseau/stockage).</li> </ul> <p>Il est essentiel de comprendre que la migration n'est souvent pas une fin en soi, mais plutôt une <strong>étape dans un parcours de modernisation plus large et potentiellement continu</strong>. Une approche initiale de type "Lift and Shift" ou "Replatform" peut être choisie pour sortir rapidement de l'environnement VMware et réaliser des économies de coûts, tout en planifiant des phases ultérieures de "Refactoring" ou d'optimisation une fois l'infrastructure stabilisée sur la nouvelle plateforme open source. Des technologies comme <strong>KubeVirt</strong> ⁴⁸ sont particulièrement intéressantes dans cette optique, car elles permettent d'adopter une plateforme moderne (Kubernetes) tout en continuant à exécuter les VMs existantes (Replatforming). Cela crée une base solide pour une modernisation progressive, où les VMs peuvent être graduellement refactorisées en conteneurs natifs sur la même plateforme, au rythme de l'entreprise.⁶¹</p> <p><strong>6. Analyse Comparative : Migration vers Virtualisation Open Source vs. Conteneurisation Kubernetes</strong></p> <p>Le choix de la plateforme cible est une décision stratégique majeure qui conditionne l'ensemble du projet de migration et l'évolution future de l'infrastructure. Deux grandes voies se dessinent : rester dans un paradigme centré sur la VM en adoptant une solution de virtualisation open source, ou basculer vers un paradigme centré sur les conteneurs avec Kubernetes, tout en utilisant KubeVirt pour héberger les VMs existantes.</p> <p><strong>6.1. Chemin "Virtualisation Open Source" (Ex: Proxmox, KVM/oVirt, Xen)</strong></p> <p>Cette voie consiste à remplacer VMware vSphere/ESXi par un hyperviseur ou une plateforme de virtualisation open source pour continuer à gérer principalement des machines virtuelles.</p> <ul> <li><strong>Avantages</strong> :<ul> <li><strong>Transition plus familière</strong> : Le modèle opérationnel reste centré sur la VM, ce qui représente un changement moins radical pour les équipes d'infrastructure habituées à VMware.⁵ La courbe d'apprentissage initiale peut être moins abrupte.</li> <li><strong>Performance VM éprouvée</strong> : Les hyperviseurs comme KVM et Xen sont matures et offrent d'excellentes performances pour les workloads virtualisés traditionnels.⁵</li> <li><strong>Coûts potentiellement très bas</strong> : L'absence de coût de licence pour les solutions de base (KVM, Xen, Proxmox sans support) est un avantage financier majeur.¹¹</li> <li><strong>Simplicité relative (pour certaines plateformes)</strong> : Des solutions intégrées comme Proxmox VE offrent une expérience de gestion relativement simple et unifiée.²⁰</li> </ul> </li> <li><strong>Inconvénients</strong> :<ul> <li><strong>Moins orienté modernisation applicative</strong> : Cette approche résout le problème du coût et du verrouillage VMware, mais ne facilite pas intrinsèquement la transition vers des architectures cloud-natives basées sur les microservices et les conteneurs.⁶ Elle peut perpétuer une gestion en silos de l'infrastructure.</li> <li><strong>Écosystème d'outils potentiellement fragmenté</strong> : Pour atteindre un niveau de fonctionnalité équivalent à la suite VMware complète (gestion avancée, SDN, sécurité, automatisation), il faut souvent assembler et intégrer différentes briques open source (ex: KVM + oVirt + Ceph + Ansible + ELK...), ce qui demande de l'expertise et de l'effort.⁵</li> <li><strong>Maturité variable des outils</strong> : Bien que les hyperviseurs soient matures, certains outils de gestion, de supervision ou de sécurité de l'écosystème open source peuvent être perçus comme moins aboutis ou moins intégrés que leurs équivalents VMware.⁵</li> <li><strong>Défis de support</strong> : Reposer sur le support communautaire pour une infrastructure critique peut être risqué.³¹ Le support entreprise est une option mais représente un coût additionnel.</li> </ul> </li> </ul> <p><strong>6.2. Chemin "Conteneurisation Kubernetes" (Ex: OpenShift, Rancher, K8s + KubeVirt)</strong></p> <p>Cette voie consiste à adopter Kubernetes comme plateforme d'infrastructure unifiée, capable d'orchestrer à la fois les nouvelles applications conteneurisées et les VMs existantes grâce à KubeVirt.</p> <ul> <li><strong>Avantages</strong> :<ul> <li><strong>Alignement stratégique cloud-native</strong> : Positionne l'infrastructure pour l'avenir, en adoptant les standards de l'industrie pour le déploiement et la gestion d'applications modernes (microservices, serverless) et en facilitant les pratiques DevOps.⁶</li> <li><strong>Plateforme unifiée VM/Conteneurs</strong> : KubeVirt permet de gérer les VMs et les conteneurs avec les mêmes outils, les mêmes API (Kubernetes) et sur la même infrastructure physique, réduisant la complexité et les silos.³⁷</li> <li><strong>Modernisation progressive</strong> : Facilite un parcours où les applications peuvent être migrées en tant que VMs sur KubeVirt (Replatforming), puis progressivement refactorisées en conteneurs natifs sur la même plateforme lorsque cela fait sens.⁵⁴</li> <li><strong>Richesse de l'écosystème Kubernetes</strong> : Bénéficie de l'immense écosystème d'outils open source pour l'observabilité (Prometheus/Grafana), la sécurité (Falco, OPA), le réseau (CNI), le stockage (CSI), le service mesh (Istio), etc.</li> <li><strong>Scalabilité et résilience natives</strong> : Kubernetes est conçu dès le départ pour l'auto-réparation, le scaling horizontal et la gestion déclarative de l'état désiré.⁵⁴</li> <li><strong>Potentiel d'optimisation des ressources</strong> : La gestion unifiée et la nature potentiellement plus légère des conteneurs (et de KubeVirt par rapport à une pile VM complète) peuvent conduire à une meilleure densité et utilisation du matériel.⁶¹</li> </ul> </li> <li><strong>Inconvénients</strong> :<ul> <li><strong>Complexité et courbe d'apprentissage</strong> : Kubernetes est une plateforme complexe avec de nombreux concepts à maîtriser. La courbe d'apprentissage pour les équipes (infrastructure et développement) est significativement plus raide que pour la virtualisation traditionnelle.⁶</li> <li><strong>Nouveauté relative de KubeVirt</strong> : Bien que basé sur KVM, KubeVirt est une technologie plus jeune que les hyperviseurs établis. Des défis de performance, de stabilité ou de manque de fonctionnalités spécifiques peuvent exister pour certains workloads VM très exigeants ou particuliers.⁵⁹</li> <li><strong>Coût des plateformes managées</strong> : Utiliser une distribution Kubernetes entreprise comme OpenShift pour simplifier la gestion et obtenir du support représente un coût de souscription potentiellement élevé.⁴² Gérer K8s vanilla + KubeVirt en mode DIY est moins cher en licence mais maximise la complexité opérationnelle.</li> <li><strong>Nécessité d'une transformation des processus</strong> : Adopter Kubernetes efficacement implique souvent une refonte des processus de déploiement (vers CI/CD), de gestion de la configuration (vers GitOps/IaC) et une collaboration plus étroite entre les équipes (DevOps).</li> </ul> </li> </ul> <p><strong>6.3. Facteurs de Décision</strong></p> <p>Le choix entre ces deux voies dépendra d'une analyse approfondie de plusieurs facteurs propres à chaque organisation :</p> <ul> <li><strong>Maturité et Nature des Applications</strong> : Un parc applicatif majoritairement composé d'applications legacy stables et peu évolutives pourrait pencher vers la virtualisation open source. À l'inverse, une entreprise avec de nombreux développements en cours ou prévus, visant des architectures microservices, sera naturellement attirée par Kubernetes.</li> <li><strong>Objectifs Stratégiques Prioritaires</strong> : Si l'objectif premier est une réduction rapide des coûts de licence VMware avec un minimum de perturbations, la virtualisation open source peut être la voie la plus directe. Si l'objectif est une transformation à plus long terme vers l'agilité, le cloud-native et une plateforme unifiée, Kubernetes/KubeVirt est une option plus stratégique.</li> <li><strong>Compétences Internes et Culture d'Entreprise</strong> : L'existence (ou la volonté d'acquérir) des compétences pointues en Linux, KVM, et surtout Kubernetes/conteneurs est déterminante. La capacité de l'organisation à adopter de nouveaux outils, de nouveaux processus (DevOps, IaC) et à favoriser la collaboration entre équipes jouera un rôle crucial.⁵⁴ Une culture réfractaire au changement pourrait rendre l'adoption de Kubernetes très difficile.</li> <li><strong>Horizon Temporel et Budget</strong> : La virtualisation open source peut offrir des gains plus rapides avec un investissement initial potentiellement moindre (surtout en DIY). Kubernetes/KubeVirt représente un investissement initial plus important (en formation, outils, potentiellement licences de distribution) mais promet des bénéfices stratégiques à plus long terme.</li> </ul> <p>En synthèse, le choix n'est pas purement technique mais profondément stratégique. La migration vers la <strong>virtualisation open source</strong> peut être vue comme une <strong>étape tactique</strong>, répondant au besoin immédiat de réduire les coûts et la dépendance à VMware, tout en conservant un paradigme opérationnel relativement familier. La migration vers <strong>Kubernetes/KubeVirt</strong> est une <strong>décision plus stratégique et transformatrice</strong>, visant une modernisation en profondeur de l'infrastructure et des applications, mais exigeant un investissement initial plus conséquent en termes de complexité, de coût et de changement organisationnel.⁶</p> <p><strong>7. Outils de Migration Spécifiques</strong></p> <p>La réussite technique d'une migration dépend en grande partie du choix et de la maîtrise des outils appropriés pour déplacer les machines virtuelles et leurs données de l'environnement source vers l'environnement cible. Il n'existe pas d'outil universel ; le choix dépendra fortement de la plateforme cible (KVM, Proxmox, OpenStack, Kubernetes/KubeVirt) et de la stratégie de migration adoptée (Lift &amp; Shift, Replatform).</p> <p><strong>7.1. Outils de Migration VM-vers-VM (vers KVM/Proxmox/oVirt/OpenStack)</strong></p> <p>Ces outils sont conçus pour migrer des VMs VMware vers d'autres plateformes de virtualisation classiques.</p> <ul> <li><strong>virt-v2v</strong> :<ul> <li><em>Description</em> : Outil open source en ligne de commande, généralement inclus dans les distributions Linux basées sur Red Hat (RHEL, CentOS, Fedora), mais installable sur d'autres. Il est conçu pour convertir des VMs depuis VMware ESXi (via connexion directe ou vCenter), Xen, ou Hyper-V vers un format compatible KVM (géré par libvirt), oVirt, OpenStack ou RHV.⁶³</li> <li><em>Fonctionnement</em> : virt-v2v se connecte à l'hyperviseur source, inspecte la VM, copie les disques en les convertissant au format désiré (qcow2, raw...), crée un fichier de définition XML pour libvirt, et tente d'installer les pilotes VirtIO nécessaires dans l'OS invité pendant le processus.⁶⁸</li> <li><em>Utilisation</em> : Nécessite que la VM source soit arrêtée.⁶⁹ La commande spécifie la source (ex: -ic vpx://... pour vCenter, -ic esx://... pour ESXi), le nom de la VM, et la destination (ex: -o libvirt pour une importation directe dans libvirt local, -o local -os /chemin pour exporter les fichiers, -o openstack pour OpenStack).⁶⁸ Des options permettent de gérer l'authentification et la vérification des certificats.⁶⁹</li> <li><em>Limitations</em> : Le support des OS invités est spécifique et documenté (principalement RHEL, Windows, SLES).⁶³ Des problèmes peuvent survenir avec certaines configurations UEFI ou des systèmes de fichiers spécifiques.⁶³ Des ajustements manuels post-migration (configuration réseau notamment) sont souvent nécessaires.⁶³</li> </ul> </li> <li><strong>Importateur Intégré Proxmox VE (&gt;= 8.2)</strong> :<ul> <li><em>Description</em> : Fonctionnalité intégrée à l'interface web de Proxmox VE (depuis la version 8.2) permettant d'importer directement des VMs depuis des hôtes VMware ESXi (versions 6.5 à 8.0) ou vCenter.⁶⁵</li> <li><em>Fonctionnement</em> : L'administrateur ajoute d'abord l'hôte ESXi ou vCenter comme une source de "stockage" dans Proxmox. Ensuite, un assistant d'importation permet de parcourir les VMs sur la source, de sélectionner celles à migrer, et de configurer les paramètres de la VM cible sur Proxmox (nœud, stockage de destination, format de disque - qcow2 ou raw recommandé, réseau, etc.). L'outil gère la copie et la conversion des disques.⁶⁵</li> <li><em>Utilisation</em> : Nécessite un accès SSH à l'hôte ESXi source. Il est recommandé d'arrêter la VM source, bien qu'une migration "live" soit possible (mais plus lente et potentiellement plus risquée). Les snapshots sur la VM source doivent être supprimés. L'import depuis des datastores vSAN n'est pas supporté.⁶⁵ Il est crucial d'avoir préalablement désinstallé les VMware Tools et installé les pilotes VirtIO sur la VM source (surtout pour Windows) pour assurer un démarrage et des performances correctes après migration.⁶⁵ Des ajustements post-migration (attacher le disque au contrôleur VirtIO SCSI, vérifier l'ordre de boot) sont souvent nécessaires.⁶⁵</li> </ul> </li> <li><strong>OVF (Open Virtualization Format)</strong> :<ul> <li><em>Description</em> : Standard industriel pour l'empaquetage et la distribution de machines virtuelles. Une VM exportée en OVF comprend un fichier descripteur (.ovf, en XML), les fichiers de disques virtuels (.vmdk dans le cas de VMware), et éventuellement un fichier manifeste (.mf).⁷⁰</li> <li><em>Utilisation</em> : Exporter la VM depuis VMware vSphere Client ou vCenter au format OVF.⁷⁰ Transférer les fichiers générés vers la plateforme cible. Utiliser l'outil d'importation OVF de la plateforme cible (ex: la commande qm importovf &lt;vmid&gt; &lt;fichier.ovf&gt; &lt;stockage_cible&gt; dans Proxmox ⁶⁵). L'outil VMware OVF Tool peut également être utilisé pour faciliter l'export, l'import et la conversion.⁷⁰</li> <li><em>Avantages/Inconvénients</em> : Méthode standardisée mais souvent très manuelle, nécessitant des transferts de fichiers volumineux et des ajustements post-importation.</li> </ul> </li> <li><strong>Conversion Manuelle de Disques + Recréation VM</strong> :<ul> <li><em>Description</em> : Approche la plus basique, impliquant de copier manuellement les fichiers de disque .vmdk (et *-flat.vmdk) depuis le datastore VMware vers un stockage accessible par la plateforme cible.⁶⁵</li> <li><em>Utilisation</em> : Utiliser des outils comme scp ou un client SFTP (WinSCP) pour copier les fichiers.⁶⁵ Utiliser l'outil qemu-img sur l'hôte cible pour convertir le format de disque (ex: qemu-img convert -f vmdk -O qcow2 vmware_disk.vmdk proxmox_disk.qcow2).⁶⁷ Créer une nouvelle VM sur la plateforme cible avec une configuration matérielle similaire (CPU, RAM), puis attacher le disque nouvellement converti.⁶⁵</li> <li><em>Avantages/Inconvénients</em> : Offre un contrôle total mais est très laborieux, lent, et sujet aux erreurs. Nécessite des étapes de configuration post-création importantes (installation des pilotes, configuration réseau, ajustement du bootloader/fstab).⁷¹</li> </ul> </li> <li><strong>Outils de Sauvegarde/Restauration Tiers</strong> :<ul> <li><em>Description</em> : Les solutions de sauvegarde d'entreprise qui supportent à la fois VMware comme source et la plateforme open source cible (Proxmox, KVM via RHV/oVirt, Nutanix AHV...) peuvent être utilisées pour effectuer une migration V2V (Virtual-to-Virtual).¹⁹</li> <li><em>Utilisation</em> : Sauvegarder la VM sur l'environnement VMware. Effectuer une restauration de cette sauvegarde en choisissant la plateforme open source comme destination. L'outil de sauvegarde gère la conversion et la création de la VM sur la cible.</li> <li><em>Exemples</em> : Veeam (support Proxmox annoncé ¹⁹), Vinchin Backup &amp; Recovery (supporte VMware, Proxmox, oVirt, OpenStack, XenServer...) ⁶⁸, Commvault ¹⁹, Rubrik ³⁰, Cohesity.³⁰</li> <li><em>Avantages/Inconvénients</em> : Peut potentiellement simplifier et accélérer le processus via une interface unifiée, et offrir des options de restauration rapide (Instant VM Recovery) minimisant le downtime. Dépend fortement des capacités et des licences de l'outil de sauvegarde.</li> </ul> </li> </ul> <p><strong>7.2. Outils de Migration vers Kubernetes/Conteneurs (incl. KubeVirt)</strong></p> <p>Ces outils visent à faciliter le déplacement de VMs ou d'applications vers un environnement Kubernetes, potentiellement en utilisant KubeVirt pour les VMs.</p> <ul> <li><strong>Red Hat Migration Toolkit for Virtualization (MTV)</strong> :<ul> <li><em>Description</em> : Composant intégré à la plateforme Red Hat OpenShift, conçu spécifiquement pour migrer des machines virtuelles depuis diverses sources (VMware vSphere étant une source majeure) vers OpenShift Virtualization (qui utilise KubeVirt).¹⁶</li> <li><em>Fonctionnement</em> : Fournit une interface utilisateur dans la console OpenShift pour définir des fournisseurs source (ex: vCenter), créer des plans de migration spécifiant les VMs à migrer, et mapper les réseaux et les stockages entre l'environnement source et la configuration cible OpenShift (NetworkAttachmentDefinitions, StorageClasses). L'outil orchestre ensuite la copie des données et la création des objets KubeVirt (VirtualMachine, VirtualMachineInstance) correspondants dans OpenShift.⁵⁷ Il supporte la migration à froid (cold migration).⁵⁷</li> <li><em>Avantages</em> : Solution intégrée et supportée dans l'écosystème OpenShift, simplifie un processus autrement complexe.</li> </ul> </li> <li><strong>Konveyor</strong> :<ul> <li><em>Description</em> : Communauté open source (soutenue notamment par Red Hat) dont l'objectif est de développer des outils et des bonnes pratiques pour aider à la modernisation et à la migration d'applications vers Kubernetes et le cloud hybride.⁷³</li> <li><em>Outils Pertinents</em> :<ul> <li><strong>Crane</strong> (anciennement Migration Toolkit for Containers - MTC) : Outil principal pour migrer des applications (stateful ou stateless) <strong>entre différents clusters Kubernetes</strong> (ex: d'un ancien cluster OpenShift 3 vers un nouveau cluster OpenShift 4/moderne).⁷³ Il peut utiliser différentes méthodes de copie, y compris rsync pour une migration directe si une connectivité réseau existe, ou passer par un stockage objet intermédiaire.⁷³ <em>Moins pertinent pour une migration VMware vers K8s initiale, mais utile pour les migrations K8s-vers-K8s ultérieures.</em></li> <li><strong>Move2Kube</strong> : Outil en ligne de commande qui vise à accélérer le <strong>re-platforming</strong> d'applications (depuis des VMs ou d'autres sources) vers Kubernetes en générant automatiquement des artefacts de déploiement K8s (manifestes YAML, Dockerfiles, etc.).⁷³</li> <li><strong>Pathfinder</strong> : Outil d'évaluation qui analyse un portefeuille d'applications pour déterminer leur <strong>aptitude à la conteneurisation</strong> et suggérer des stratégies de migration.⁷³</li> <li><strong>Tackle/Windup</strong> : Outil plus spécifique pour analyser des applications Java en vue de leur modernisation et migration.⁷³</li> </ul> </li> <li><em>Positionnement</em> : Konveyor semble s'être <strong>recentré sur les aspects applicatifs</strong> de la modernisation (Replatforming, Refactoring) plutôt que sur la migration d'infrastructure VM-vers-KubeVirt directe.⁷² Ses outils sont donc complémentaires aux outils de migration de VMs.</li> </ul> </li> <li><strong>Plateformes Managées/Commerciales avec support KubeVirt</strong> :<ul> <li><em>Platform9</em> : Propose une plateforme Kubernetes managée qui intègre KubeVirt et offre explicitement des services pour aider à la migration depuis VMware, en mettant en avant une réduction du TCO.⁶¹</li> <li><em>Spectro Cloud Palette</em> : Plateforme de gestion de clusters Kubernetes qui supporte le déploiement et la gestion de KubeVirt, potentiellement avec des fonctionnalités pour faciliter l'intégration de VMs.³⁷</li> </ul> </li> </ul> <p><strong>7.3. Outils d'Automatisation (Supportant la Migration)</strong></p> <p>Ces outils ne sont pas spécifiques à la migration mais peuvent grandement faciliter et sécuriser le processus en automatisant des tâches répétitives.</p> <ul> <li><strong>Ansible Automation Platform</strong> : Outil d'automatisation basé sur des playbooks YAML, très utilisé pour la configuration post-migration (installation de logiciels, configuration système), le déploiement d'infrastructure, et l'orchestration de tâches complexes sur les systèmes cibles (Linux, Windows).¹ Red Hat l'intègre fortement dans ses solutions de migration et de gestion.¹⁶</li> <li><strong>Terraform</strong> : Outil d'Infrastructure as Code (IaC) permettant de définir et de provisionner l'infrastructure cible (réseau, stockage, instances K8s, VMs sur certaines plateformes) de manière déclarative et reproductible.¹</li> </ul> <p>L'analyse des outils disponibles montre clairement qu'il n'y a pas de solution unique pour tous les scénarios de migration. Le choix de l'outil est intrinsèquement lié à la <strong>plateforme cible</strong> (on n'utilisera pas les mêmes outils pour migrer vers Proxmox ou vers OpenShift Virtualization) et à la <strong>stratégie de migration</strong> retenue (un Lift &amp; Shift VM-à-VM utilisera des outils différents d'un Replatforming vers KubeVirt).</p> <p>De plus, on observe que le domaine de la migration <strong>VM-vers-KubeVirt</strong> est un domaine où l'outillage est <strong>moins standardisé et potentiellement moins mature</strong> que pour les migrations VM-à-VM traditionnelles. Des solutions intégrées comme MTV de Red Hat ⁵¹ ou des offres managées comme Platform9 ⁶¹ existent pour simplifier ce processus dans des contextes spécifiques (OpenShift ou plateforme managée). Cependant, réaliser une migration "DIY" vers KubeVirt sur un cluster Kubernetes vanilla nécessitera probablement une combinaison d'outils de conversion de disque (comme qemu-img), de scripting pour générer les manifestes KubeVirt, et une expertise Kubernetes/KubeVirt plus approfondie que pour utiliser un outil comme virt-v2v ou l'importateur Proxmox.</p> <p><strong>8. Retours d'Expérience, Études de Cas et Bonnes Pratiques</strong></p> <p>L'analyse des retours d'expérience et des cas concrets de migration permet de mieux appréhender la réalité du terrain, les bénéfices obtenus et les écueils à éviter.</p> <p><strong>8.1. Exemples de Migration vers Proxmox VE</strong></p> <p>Plusieurs organisations de tailles et de secteurs variés ont documenté leur passage de VMware (ou d'autres solutions comme XenServer) à Proxmox VE.</p> <ul> <li><strong>Motivations Récurrentes</strong> : La <strong>réduction des coûts</strong> (liée au modèle open source sans licence) et la volonté de s'affranchir du verrouillage fournisseur sont des moteurs fréquents.³³ La recherche de <strong>flexibilité</strong> ³⁴, de <strong>simplicité d'utilisation</strong> ³³ et le <strong>support de l'open source</strong> ³³ sont également cités.</li> <li><strong>Profils d'Organisations</strong> : On trouve des exemples dans l'<strong>éducation</strong> (collèges techniques comme HTL Leonding, universités comme Sigmund Freud Univ. ou Univ. de Macau ³³), les <strong>PME</strong>, les <strong>fournisseurs de services Internet ou d'hébergement</strong> (IGNUM, EdgeUno ³³), le <strong>secteur public/santé</strong> (Assurance Maladie française pour Proxmox Mail Gateway, projet de base de données pour la santé publique au Brésil ³³), des <strong>entreprises technologiques</strong> (Textkernel - IA pour RH, ESTECO - logiciels d'ingénierie ³³), des <strong>fondations</strong> (Cyber-Complex ³³) et même des <strong>lieux culturels</strong> (Odéon-Théâtre de l'Europe ³³).</li> <li><strong>Bénéfices Observés</strong> :<ul> <li><strong>Économies substantielles</strong> sur les coûts de licence (un cas mentionne 60% de réduction ³⁴).</li> <li><strong>Amélioration des performances</strong>.³⁴</li> <li><strong>Flexibilité accrue</strong> pour adapter l'infrastructure et tester de nouvelles configurations.³³</li> <li><strong>Simplification de la gestion</strong> de l'infrastructure grâce à l'interface centralisée.³³</li> <li><strong>Gain de temps</strong> pour les équipes d'administration.³³</li> <li><strong>Scalabilité et fiabilité</strong> améliorées, notamment en utilisant les fonctionnalités de clustering HA et le stockage Ceph.³³</li> </ul> </li> <li><strong>Démarche de Migration</strong> : Une approche <strong>graduelle</strong> est souvent privilégiée ³⁴, précédée d'une phase d'<strong>évaluation des besoins</strong> et de <strong>planification</strong>.³⁴ L'utilisation des fonctionnalités natives de Proxmox (HA, Ceph) est fréquente pour construire une infrastructure résiliente.³³</li> <li><strong>Appréciations Qualitatives</strong> : Les témoignages sont généralement positifs, qualifiant Proxmox VE de "phénoménal" ³³, de "meilleur moyen de simplifier l'infrastructure IT" ³³, ou soulignant la réduction des heures de travail.³³</li> </ul> <p><strong>8.2. Exemples de Migration vers OpenShift Virtualization / KubeVirt</strong></p> <p>Les retours d'expérience sur la migration vers KubeVirt (souvent via OpenShift Virtualization) sont peut-être moins nombreux ou moins détaillés publiquement, mais certains points émergent.</p> <ul> <li><strong>Motivations Principales</strong> : Recherche d'une <strong>alternative aux hyperviseurs traditionnels</strong> dans un contexte de modernisation, volonté de <strong>consolider la gestion des VMs et des conteneurs</strong> sur une plateforme unique.¹⁶ Faciliter la migration de workloads legacy vers une plateforme cloud-native sans réécriture immédiate.⁵⁵</li> <li><strong>Profils d'Organisations</strong> : Principalement des <strong>entreprises</strong> cherchant à moderniser leur infrastructure et à adopter Kubernetes de manière plus large, tout en gérant leur parc de VMs existant.³⁷ Un cas cité est celui de Reist Telecom AG.¹⁶</li> <li><strong>Bénéfices Observés</strong> :<ul> <li><strong>Gestion unifiée</strong> des VMs et des conteneurs via les outils et API Kubernetes/OpenShift.⁴⁹</li> <li><strong>Processus de migration simplifié</strong> depuis VMware grâce à des outils dédiés comme le Migration Toolkit for Virtualization (MTV).⁵⁷</li> <li><strong>Potentiel de réduction du TCO</strong> et d'<strong>augmentation de la densité</strong> des workloads par rapport à des silos séparés VM et conteneurs.⁶¹</li> <li><strong>Flexibilité</strong> pour moderniser les applications au rythme de l'entreprise.¹⁶</li> <li><strong>Bonnes performances</strong> lors des migrations à chaud de VMs avec stockage performant, minimisant l'impact sur les IOs.⁵⁶</li> </ul> </li> <li><strong>Démarche de Migration</strong> : L'utilisation de MTV pour orchestrer la migration depuis VMware vers OpenShift est une approche documentée.⁵⁷ Le processus implique la création d'objets KubeVirt (VM/VMI) et le mapping des ressources réseau et stockage.⁵⁶</li> </ul> <p>L'analyse croisée de ces retours suggère que <strong>Proxmox VE</strong> s'est solidement établi comme une <strong>alternative crédible et performante à VMware</strong>, particulièrement appréciée pour sa <strong>simplicité, sa flexibilité et son modèle économique avantageux</strong> dans des contextes variés allant de la PME à certains déploiements d'entreprise ou sectoriels (éducation, public). <strong>OpenShift Virtualization / KubeVirt</strong> apparaît comme une <strong>solution plus stratégique</strong>, visant les entreprises qui s'engagent dans une <strong>modernisation profonde vers le cloud-native et Kubernetes</strong>, et qui cherchent une <strong>plateforme unifiée</strong> pour gérer un parc applicatif mixte (VMs et conteneurs). Le choix de l'une ou l'autre voie semble donc dépendre fortement des objectifs à long terme et du contexte spécifique de l'organisation.</p> <p><strong>8.3. Leçons Apprises et Bonnes Pratiques (Synthèse)</strong></p> <p>Des migrations réussies (et des échecs évités) se dégagent plusieurs bonnes pratiques transversales :</p> <ul> <li><strong>La Planification est Reine</strong> : Ne jamais sous-estimer la phase amont. Réaliser un audit détaillé de l'environnement source, comprendre les dépendances applicatives et réseau, définir des objectifs clairs et mesurables, et choisir la stratégie (Lift&amp;Shift, Replatform, Refactor) et l'approche (Big Bang, Phased) les plus adaptées.¹</li> <li><strong>Tester, Tester et Encore Tester</strong> : Les Proofs of Concept (PoC) et les migrations pilotes sur des workloads non critiques sont indispensables pour valider la plateforme cible, les outils de migration, les procédures, estimer les performances et identifier les problèmes potentiels avant de passer à l'échelle.⁶² Tester spécifiquement la compatibilité OS et applicative.⁶⁴</li> <li><strong>Préparer Méticuleusement les VMs Sources</strong> : Avant la migration, "nettoyer" les VMs sources : désinstaller les agents et outils spécifiques à VMware (VMware Tools) ⁶⁴, installer les pilotes paravirtualisés de la plateforme cible (VirtIO pour KVM/Proxmox) si possible ⁶⁴, et supprimer les snapshots de la VM qui peuvent compliquer ou ralentir la migration [⁶⁵</li> </ul> <h5>Sources des citations</h5> <ol> <li>Move From VMware : Libérez votre infrastructure de VMware - Alter Way, consulté le avril 22, 2025, <a href="https://www.alterway.fr/movefromvmware-liberez-votre-infrastructure-de-vmware/">https://www.alterway.fr/movefromvmware-liberez-votre-infrastructure-de-vmware/</a></li> <li>Broadcom's Acquisition of VMware: Impact on Businesses ..., consulté le avril 22, 2025, <a href="https://www.rutter-net.com/blog/broadcoms-acquisition-of-vmware">https://www.rutter-net.com/blog/broadcoms-acquisition-of-vmware</a></li> <li>Broadcom's VMware Acquisition: What It Means for Avi Networks Customers - Radware, consulté le avril 22, 2025, <a href="https://www.radware.com/blog/applicationdelivery/broadcom-s-vmware-acquisition/">https://www.radware.com/blog/applicationdelivery/broadcom-s-vmware-acquisition/</a></li> <li>A Broadcom VMware Alternative: Partners See 'Massive' Opportunity For HPE VM Essentials - CRN, consulté le avril 22, 2025, <a href="https://www.crn.com/news/virtualization/2025/a-broadcom-vmware-alternative-partners-see-massive-opportunity-for-hpe-vm-essentials">https://www.crn.com/news/virtualization/2025/a-broadcom-vmware-alternative-partners-see-massive-opportunity-for-hpe-vm-essentials</a></li> <li>Quelles alternatives open source à VMware? — abilian.com, consulté le avril 22, 2025, <a href="https://abilian.com/fr/news/alternatives-open-source-a-vmware/">https://abilian.com/fr/news/alternatives-open-source-a-vmware/</a></li> <li>Quelles stratégies et solutions alternatives à VMWare envisager - Inside Group, consulté le avril 22, 2025, <a href="https://insidegroup.fr/actualites/strategie-vmware/">https://insidegroup.fr/actualites/strategie-vmware/</a></li> <li>VMware Alternatives for Business: Exploring the Best Options - Otava, consulté le avril 22, 2025, <a href="https://www.otava.com/blog/vmware-alternatives-for-business-exploring-the-best-options/">https://www.otava.com/blog/vmware-alternatives-for-business-exploring-the-best-options/</a></li> <li>Top VMware Alternatives in 2025 &amp; How to Migrate Easily - Hystax, consulté le avril 22, 2025, <a href="https://hystax.com/vmware-alternatives-migration-2025/">https://hystax.com/vmware-alternatives-migration-2025/</a></li> <li>Migrating from VMware to Open Source - Ubuntu, consulté le avril 22, 2025, <a href="https://ubuntu.com/engage/vmware-migration-to-open-source">https://ubuntu.com/engage/vmware-migration-to-open-source</a></li> <li>How the Broadcom VMware Acquisition of VMware is Affecting Longtime Customers, consulté le avril 22, 2025, <a href="https://blog.clearscale.com/how-the-broadcom-vmware-acquisition-of-vmware-is-affecting-longtime-customers/">https://blog.clearscale.com/how-the-broadcom-vmware-acquisition-of-vmware-is-affecting-longtime-customers/</a></li> <li>Alternatives to VMware: The Benefits of Open Source - Enix.io, consulté le avril 22, 2025, <a href="https://enix.io/en/blog/vmware-alternatives/">https://enix.io/en/blog/vmware-alternatives/</a></li> <li>Top 5 Open Source Alternatives to VMware ESXi for SMBs | Pogo Tech Blog, consulté le avril 22, 2025, <a href="https://www.pogolinux.com/blog/top-5-open-source-alternatives-vmware-esxi-smb/">https://www.pogolinux.com/blog/top-5-open-source-alternatives-vmware-esxi-smb/</a></li> <li>Xen vs. KVM - Comparison of Hypervisors | Storware BLOG, consulté le avril 22, 2025, <a href="https://storware.eu/blog/xen-vs-kvm-comparison-of-hypervisors/">https://storware.eu/blog/xen-vs-kvm-comparison-of-hypervisors/</a></li> <li>Choisir la bonne plateforme de virtualisation : Proxmox vs. KVM expliqué - Bacula Systems, consulté le avril 22, 2025, <a href="https://www.baculasystems.com/fr/blog-fr/proxmox-vs-kvm/">https://www.baculasystems.com/fr/blog-fr/proxmox-vs-kvm/</a></li> <li>KVM vs. VMware: Choosing the Right Hypervisor for Your Needs - Lightbits Labs, consulté le avril 22, 2025, <a href="https://www.lightbitslabs.com/blog/kvmvsvmware/">https://www.lightbitslabs.com/blog/kvmvsvmware/</a></li> <li>KVM ou VMware : quel hyperviseur choisir ? - Red Hat, consulté le avril 22, 2025, <a href="https://www.redhat.com/fr/topics/virtualization/kvm-vs-vmware-comparison">https://www.redhat.com/fr/topics/virtualization/kvm-vs-vmware-comparison</a></li> <li>KVM vs Proxmox VE vs VMware vSphere comparison - PeerSpot, consulté le avril 22, 2025, <a href="https://www.peerspot.com/products/comparisons/kvm_vs_proxmox-ve_vs_vmware-vsphere">https://www.peerspot.com/products/comparisons/kvm_vs_proxmox-ve_vs_vmware-vsphere</a></li> <li>VMware Player 4.0 vs. KVM Linux Virtualization - OpenBenchmarking.org, consulté le avril 22, 2025, <a href="https://openbenchmarking.org/result/1112124-AR-KVMLINUX286&amp;grs&amp;export=pdf">https://openbenchmarking.org/result/1112124-AR-KVMLINUX286&amp;grs&amp;export=pdf</a></li> <li>Proxmox vs VMware: which virtualisation solution should you choose?, consulté le avril 22, 2025, <a href="https://www.1300nerdcore.com.au/post/proxmox-vs-vmware-which-virtualisation-solution-should-you-choose">https://www.1300nerdcore.com.au/post/proxmox-vs-vmware-which-virtualisation-solution-should-you-choose</a></li> <li>Proxmox vs VMware: comparing virtualisation solutions - Qim info, consulté le avril 22, 2025, <a href="https://www.qiminfo.ch/en/proxmox-vs-vmware-which-virtualisation-solution-should-you-choose/">https://www.qiminfo.ch/en/proxmox-vs-vmware-which-virtualisation-solution-should-you-choose/</a></li> <li>9 VMware Alternatives To Consider In 2025 - CloudZero, consulté le avril 22, 2025, <a href="https://www.cloudzero.com/blog/vmware-alternatives/">https://www.cloudzero.com/blog/vmware-alternatives/</a></li> <li>Explore the VMware Alternatives for Your Virtualization Needs, consulté le avril 22, 2025, <a href="https://globalcybersecuritynetwork.com/blog/explore-the-vmware-alternatives-for-your-virtualization-needs/">https://globalcybersecuritynetwork.com/blog/explore-the-vmware-alternatives-for-your-virtualization-needs/</a></li> <li>Top 9 VMware ESXi Alternatives for Server Virtualization 2024 | Vinchin Backup, consulté le avril 22, 2025, <a href="https://www.vinchin.com/vm-tips/vmware-esxi-alternatives.html">https://www.vinchin.com/vm-tips/vmware-esxi-alternatives.html</a></li> <li>Proxmox VMware: What's Right for You? - Cloudzy, consulté le avril 22, 2025, <a href="https://cloudzy.com/blog/proxmox-vs-vmware/">https://cloudzy.com/blog/proxmox-vs-vmware/</a></li> <li>Best VMware alternatives to explore in 2025 - GroWrk, consulté le avril 22, 2025, <a href="https://growrk.com/blog/vmware-alternatives">https://growrk.com/blog/vmware-alternatives</a></li> <li>Looking for Vmware Alternatives? Here Are 7 Alternatives To Consider! - Workwize, consulté le avril 22, 2025, <a href="https://www.goworkwize.com/blog/vmware-alternatives">https://www.goworkwize.com/blog/vmware-alternatives</a></li> <li>Comparison - Proxmox VE vs vSphere, Hyper-V, Xen..., consulté le avril 22, 2025, <a href="https://www.proxmox.com/en/products/proxmox-virtual-environment/comparison">https://www.proxmox.com/en/products/proxmox-virtual-environment/comparison</a></li> <li>Proxmox vs VMware vs Hyper-V: The Ultimate 2024 Showdown - Amaze, consulté le avril 22, 2025, <a href="https://www.amaze.au/proxmox-vs-vmware-vs-hyper-v-the-ultimate-2024-showdown/">https://www.amaze.au/proxmox-vs-vmware-vs-hyper-v-the-ultimate-2024-showdown/</a></li> <li>Proxmox vs VMware - Comparison | Storware BLOG, consulté le avril 22, 2025, <a href="https://storware.eu/blog/proxmox-vs-vmware-comparison/">https://storware.eu/blog/proxmox-vs-vmware-comparison/</a></li> <li>Broadcom\VMware alternative s? : r/sysadmin - Reddit, consulté le avril 22, 2025, <a href="https://www.reddit.com/r/sysadmin/comments/1k2kfjn/broadcomvmware_alternative_s/">https://www.reddit.com/r/sysadmin/comments/1k2kfjn/broadcomvmware_alternative_s/</a></li> <li>Proxmox vs VMware: What Are the Main Security Differences? | Siberoloji, consulté le avril 22, 2025, <a href="https://www.siberoloji.com/proxmox-vs-vmware-what-are-the-main-security-differences/">https://www.siberoloji.com/proxmox-vs-vmware-what-are-the-main-security-differences/</a></li> <li>Cost VMware standard vs Promox : r/Proxmox - Reddit, consulté le avril 22, 2025, <a href="https://www.reddit.com/r/Proxmox/comments/1b19539/cost_vmware_standard_vs_promox/">https://www.reddit.com/r/Proxmox/comments/1b19539/cost_vmware_standard_vs_promox/</a></li> <li>Success Stories from Proxmox customers &amp; users, consulté le avril 22, 2025, <a href="https://www.proxmox.com/en/about/about-us/stories">https://www.proxmox.com/en/about/about-us/stories</a></li> <li>Comparative Analysis Between Proxmox and VMware - X5 Servers, consulté le avril 22, 2025, <a href="https://x5servers.com/en/Comparative-analysis-between-Proxmox-and-VMware/">https://x5servers.com/en/Comparative-analysis-between-Proxmox-and-VMware/</a></li> <li>Did anyone regret a switch from VMWare to ProxMox? : r/sysadmin - Reddit, consulté le avril 22, 2025, <a href="https://www.reddit.com/r/sysadmin/comments/1jtxhx8/did_anyone_regret_a_switch_from_vmware_to_proxmox/">https://www.reddit.com/r/sysadmin/comments/1jtxhx8/did_anyone_regret_a_switch_from_vmware_to_proxmox/</a></li> <li>Navigating New Horizons: Thinfinity® Workspace as a Strategic VMware Alternative, consulté le avril 22, 2025, <a href="https://blog.cybelesoft.com/alternatives-to-vmware-post-broadcom/">https://blog.cybelesoft.com/alternatives-to-vmware-post-broadcom/</a></li> <li>Top 5 Kubernetes-Based Alternatives to VMware - Portworx, consulté le avril 22, 2025, <a href="https://portworx.com/blog/top-5-kubernetes-based-alternatives-to-vmware/">https://portworx.com/blog/top-5-kubernetes-based-alternatives-to-vmware/</a></li> <li>SUSE Harvester and Rancher Solutions on ThinkSystem V3 Servers - Lenovo Press, consulté le avril 22, 2025, <a href="https://lenovopress.lenovo.com/lp2110-suse-harvester-and-rancher-solutions-on-thinksystem-v3-servers">https://lenovopress.lenovo.com/lp2110-suse-harvester-and-rancher-solutions-on-thinksystem-v3-servers</a></li> <li>Harvester Overview, consulté le avril 22, 2025, <a href="https://docs.harvesterhci.io/v1.4/">https://docs.harvesterhci.io/v1.4/</a></li> <li>SUSE® Virtualization :: Rancher product documentation, consulté le avril 22, 2025, <a href="https://documentation.suse.com/cloudnative/rancher-manager/latest/en/integrations/harvester/harvester.html">https://documentation.suse.com/cloudnative/rancher-manager/latest/en/integrations/harvester/harvester.html</a></li> <li>Rancher Vs. OpenShift - Qovery, consulté le avril 22, 2025, <a href="https://www.qovery.com/blog/rancher-vs-openshift/">https://www.qovery.com/blog/rancher-vs-openshift/</a></li> <li>Top 13 Kubernetes Alternatives for Containers in 2025 - Spacelift, consulté le avril 22, 2025, <a href="https://spacelift.io/blog/kubernetes-alternatives">https://spacelift.io/blog/kubernetes-alternatives</a></li> <li>Kubernetes Alternatives for Container Orchestration - Wiz, consulté le avril 22, 2025, <a href="https://www.wiz.io/academy/kubernetes-alternatives">https://www.wiz.io/academy/kubernetes-alternatives</a></li> <li>13 alternatives to vanilla Kubernetes for container orchestration - Sysdig, consulté le avril 22, 2025, <a href="https://sysdig.com/learn-cloud-native/13-alternatives-to-vanilla-kubernetes-for-container-orchestration/">https://sysdig.com/learn-cloud-native/13-alternatives-to-vanilla-kubernetes-for-container-orchestration/</a></li> <li>Kubernetes vs. OpenShift vs. VMware Tanzu: An Expert Comparison by HumberSys, consulté le avril 22, 2025, <a href="https://www.humbersys.com/?p=1182">https://www.humbersys.com/?p=1182</a></li> <li>KubeVirt user guide, consulté le avril 22, 2025, <a href="https://kubevirt.io/user-guide/">https://kubevirt.io/user-guide/</a></li> <li>Rancher vs. Openshift: The Guide - Densify, consulté le avril 22, 2025, <a href="https://www.densify.com/openshift-tutorial/rancher-vs-openshift/">https://www.densify.com/openshift-tutorial/rancher-vs-openshift/</a></li> <li>Migrating VMs to Kubernetes with Kubevirt - CloudRaft, consulté le avril 22, 2025, <a href="https://www.cloudraft.io/blog/migrating-vms-to-kubernetes-with-kubevirt">https://www.cloudraft.io/blog/migrating-vms-to-kubernetes-with-kubevirt</a></li> <li>Simplifying VM Storage and Management With OpenShift and KubeVirt - Cloud Native Now, consulté le avril 22, 2025, <a href="https://cloudnativenow.com/social-facebook/simplifying-vm-storage-and-management-with-openshift-and-kubevirt/">https://cloudnativenow.com/social-facebook/simplifying-vm-storage-and-management-with-openshift-and-kubevirt/</a></li> <li>Red Hat Launches OpenShift Virtualization Engine to Streamline Virtual Machine Management -- ADTmag - Application Development Trends, consulté le avril 22, 2025, <a href="https://adtmag.com/Articles/2025/01/22/Red-Hat-Launches-OpenShift-Virtualization-Engine.aspx">https://adtmag.com/Articles/2025/01/22/Red-Hat-Launches-OpenShift-Virtualization-Engine.aspx</a></li> <li>Red Hat OpenShift Virtualization | Red Hat Developer, consulté le avril 22, 2025, <a href="https://developers.redhat.com/products/openshift/virtualization">https://developers.redhat.com/products/openshift/virtualization</a></li> <li>Red Hat OpenShift Virtualization Engine overview - YouTube, consulté le avril 22, 2025, <a href="https://www.youtube.com/watch?v=NvGBmk-T_Kc">https://www.youtube.com/watch?v=NvGBmk-T_Kc</a></li> <li>Choosing the Right Platform: OpenShift Virtualization vs. VMware - Trilio, consulté le avril 22, 2025, <a href="https://trilio.io/openshift-virtualization/openshift-virtualization-vs-vmware/">https://trilio.io/openshift-virtualization/openshift-virtualization-vs-vmware/</a></li> <li>VMware vs OpenShift Virtualization: Which Platform Wins in 2025? - SYONE, consulté le avril 22, 2025, <a href="https://blog.syone.com/vmware-vs-openshift-virtualizationwhich-platform-wins-in-2025">https://blog.syone.com/vmware-vs-openshift-virtualizationwhich-platform-wins-in-2025</a></li> <li>Transform your VMware workloads with ROSA on AWS: limitless… - Paradigma Digital, consulté le avril 22, 2025, <a href="https://en.paradigmadigital.com/techbiz/transform-vmware-workloads-rosa-aws-limitless-modernization/">https://en.paradigmadigital.com/techbiz/transform-vmware-workloads-rosa-aws-limitless-modernization/</a></li> <li>Clustered Realities: Migrating VMs to Red Hat OpenShift Virtualization - Lightbits Labs, consulté le avril 22, 2025, <a href="https://www.lightbitslabs.com/blog/migrating-vms-to-red-hat-openshift-virtualization/">https://www.lightbitslabs.com/blog/migrating-vms-to-red-hat-openshift-virtualization/</a></li> <li>VMware to OpenShift Virtualization Migration - YouTube, consulté le avril 22, 2025, <a href="https://www.youtube.com/watch?v=Rp8YcDgSrZo&amp;pp=0gcJCdgAo7VqN5tD">https://www.youtube.com/watch?v=Rp8YcDgSrZo&amp;pp=0gcJCdgAo7VqN5tD</a></li> <li>Red Hat OpenShift vs VMware ESXi comparison - PeerSpot, consulté le avril 22, 2025, <a href="https://www.peerspot.com/products/comparisons/red-hat-openshift_vs_vmware-esxi-40782">https://www.peerspot.com/products/comparisons/red-hat-openshift_vs_vmware-esxi-40782</a></li> <li>Kubernetes as a Virtual Machine Management System - kth .diva, consulté le avril 22, 2025, <a href="https://kth.diva-portal.org/smash/get/diva2:1909098/FULLTEXT01.pdf">https://kth.diva-portal.org/smash/get/diva2:1909098/FULLTEXT01.pdf</a></li> <li>Live Migration - KubeVirt user guide, consulté le avril 22, 2025, <a href="https://kubevirt.io/user-guide/compute/live_migration/">https://kubevirt.io/user-guide/compute/live_migration/</a></li> <li>VMware vs KubeVirt - Discover a Cost-Effective Alternative for Virtualization - Platform9, consulté le avril 22, 2025, <a href="https://platform9.com/blog/vmware-vs-kubevirt/">https://platform9.com/blog/vmware-vs-kubevirt/</a></li> <li>What Is VMware Migration? | Pure Storage, consulté le avril 22, 2025, <a href="https://www.purestorage.com/uk/knowledge/vmware-migration.html">https://www.purestorage.com/uk/knowledge/vmware-migration.html</a></li> <li>Converting virtual machines from other hypervisors to KVM with virt-v2v in RHEL 7, RHEL 8, and RHEL 9 - Red Hat Customer Portal, consulté le avril 22, 2025, <a href="https://access.redhat.com/articles/1351473">https://access.redhat.com/articles/1351473</a></li> <li>To those who successfully migrated VMWare to Proxmox or Hyper-V how did it go? - Reddit, consulté le avril 22, 2025, <a href="https://www.reddit.com/r/sysadmin/comments/1j3lbgj/to_those_who_successfully_migrated_vmware_to/">https://www.reddit.com/r/sysadmin/comments/1j3lbgj/to_those_who_successfully_migrated_vmware_to/</a></li> <li>A Step-by-Step Guide to Migrating VMs from VMware ESXi to Proxmox - Cheap Windows VPS, consulté le avril 22, 2025, <a href="https://cheapwindowsvps.com/blog/a-step-by-step-guide-to-migrating-vms-from-vmware-esxi-to-proxmox/">https://cheapwindowsvps.com/blog/a-step-by-step-guide-to-migrating-vms-from-vmware-esxi-to-proxmox/</a></li> <li>Open-Source Migration with Migratekit: VMware to OpenStack - VEXXHOST sponsor pr... - Mohammed Naser - YouTube, consulté le avril 22, 2025, <a href="https://www.youtube.com/watch?v=AmQelZT_4TQ">https://www.youtube.com/watch?v=AmQelZT_4TQ</a></li> <li>VMware Migration Issues - Proxmox Support Forum, consulté le avril 22, 2025, <a href="https://forum.proxmox.com/threads/vmware-migration-issues.163753/">https://forum.proxmox.com/threads/vmware-migration-issues.163753/</a></li> <li>What Is Virt-v2v and How to Convert VM for KVM? - Vinchin Backup &amp; Recovery, consulté le avril 22, 2025, <a href="https://www.vinchin.com/vm-migration/virt-v2v.html">https://www.vinchin.com/vm-migration/virt-v2v.html</a></li> <li>Converting a VMware vCenter Linux virtual machine to KVM - Red Hat Customer Portal, consulté le avril 22, 2025, <a href="https://access.redhat.com/articles/1353223">https://access.redhat.com/articles/1353223</a></li> <li>How to Migrate VMs from VMware to Proxmox VE? - Apps4Rent.com, consulté le avril 22, 2025, <a href="https://www.apps4rent.com/blog/vmware-to-proxmox-ve-migration/">https://www.apps4rent.com/blog/vmware-to-proxmox-ve-migration/</a></li> <li>Migrate VMs from KVM to VMware | Steps and Common Problems | Vinchin Backup, consulté le avril 22, 2025, <a href="https://www.vinchin.com/vm-migration/kvm-to-vmware.html">https://www.vinchin.com/vm-migration/kvm-to-vmware.html</a></li> <li>Most efficient way to move virtual machines from vmare to kubevirt on kubernetes? - Reddit, consulté le avril 22, 2025, <a href="https://www.reddit.com/r/kubernetes/comments/1jqbwh2/most_efficient_way_to_move_virtual_machines_from/">https://www.reddit.com/r/kubernetes/comments/1jqbwh2/most_efficient_way_to_move_virtual_machines_from/</a></li> <li>-Konveyor- Moving Workloads Across Clusters With Crane – And A Look At The Konveyor Community | PDF | Backup | Replication (Computing) - Scribd, consulté le avril 22, 2025, <a href="https://www.scribd.com/document/815067347/Konveyor-Moving-Workloads-Across-Clusters-With-Crane-And-A-Look-At-The-Konveyor-Community">https://www.scribd.com/document/815067347/Konveyor-Moving-Workloads-Across-Clusters-With-Crane-And-A-Look-At-The-Konveyor-Community</a></li> <li>How to Become a Cloud Administrator ? Key Certifications and Skills You Need, consulté le avril 22, 2025, <a href="https://www.webasha.com/blog/how-to-become-a-cloud-administrator-key-certifications-and-skills-you-need">https://www.webasha.com/blog/how-to-become-a-cloud-administrator-key-certifications-and-skills-you-need</a></li> <li>TOP 5 REASONS KUBERNETES RUNS BETTER ON VMWARE vSPHERE, consulté le avril 22, 2025, <a href="https://www.vmware.com/docs/solution-overview-top-5-reasons-kubernetes-runs-better-on-vmware-vsphere">https://www.vmware.com/docs/solution-overview-top-5-reasons-kubernetes-runs-better-on-vmware-vsphere</a></li> <li>What are the benefits of "enterprise-level" virtualization? - Server Fault, consulté le avril 22, 2025, <a href="https://serverfault.com/questions/513381/what-are-the-benefits-of-enterprise-level-virtualization">https://serverfault.com/questions/513381/what-are-the-benefits-of-enterprise-level-virtualization</a></li> <li>Product - Community vs Enterprise - CFEngine, consulté le avril 22, 2025, <a href="https://cfengine.com/community-vs-enterprise-comparison/">https://cfengine.com/community-vs-enterprise-comparison/</a></li> <li>Lift-and-Shift or Refactor: Which Migration Methodology is Right for You? - ClearScale Blog, consulté le avril 22, 2025, <a href="https://blog.clearscale.com/lift-and-shift-or-refactor-which-migration-methodology-is-right-for-you/">https://blog.clearscale.com/lift-and-shift-or-refactor-which-migration-methodology-is-right-for-you/</a></li> <li>Big Bang vs. Gradual Data Migration: Pros, Cons, and Best Practices - XB Software, consulté le avril 22, 2025, <a href="https://xbsoftware.com/blog/big-bang-or-gradual-data-migration/">https://xbsoftware.com/blog/big-bang-or-gradual-data-migration/</a></li> <li>Big Bang vs Trickle Migration [Key Differences &amp; Considerations] - Brainhub, consulté le avril 22, 2025, <a href="https://brainhub.eu/library/big-bang-migration-vs-trickle-migration">https://brainhub.eu/library/big-bang-migration-vs-trickle-migration</a></li> <li>Big Bang vs Phased Implementation - Impact on Time and Cost, consulté le avril 22, 2025, <a href="https://pm.stackexchange.com/questions/12038/big-bang-vs-phased-implementation-impact-on-time-and-cost">https://pm.stackexchange.com/questions/12038/big-bang-vs-phased-implementation-impact-on-time-and-cost</a></li> </ol>2025-04-29T18:00:00+02:002025-04-29T18:00:00+02:00Cédric Henriquestag:blogppr.alterway.fr,2025-04-29:/simplifier-et-optimiser-vos-clusters-kubernetes-le-combo-gagnant-eks-karpenter-auto-mode.html

<p>Retour d’expérience de Qonto et focus sur Karpenter &amp; EKS Auto Mode à l'AWS Summit 2025</p>

<h1>Simplifier et optimiser vos clusters Kubernetes : le combo gagnant EKS + Karpenter + Auto Mode</h1> <p><strong>Retour d’expérience de Qonto et focus sur Karpenter &amp; EKS Auto Mode</strong></p> <blockquote> <p>À l’occasion d’une session au Summit AWS 2025, les équipes de Qonto et d’AWS sont revenues sur les bonnes pratiques pour gérer efficacement des clusters Kubernetes à grande échelle. Voici les principaux enseignements à retenir.</p> </blockquote> <h2>Kubernetes : un standard… qui reste complexe à opérer</h2> <p>Kubernetes s’est imposé comme l’orchestrateur de conteneurs de référence. <strong>84 % des entreprises</strong> l’utilisent, selon la CNCF, que ce soit en production ou en expérimentation. Ses atouts sont connus :<br /> - <strong>Portabilité</strong> : du laptop à l’on-prem, en passant par le cloud.<br /> - <strong>Support des architectures microservices</strong> : agilité, découplage, scalabilité.</p> <p>Mais derrière ces bénéfices se cache une <strong>complexité opérationnelle réelle</strong> : scaler les ressources, gérer les mises à jour, sécuriser les déploiements… Tout cela demande du temps et de l’expertise.</p> <p>Depuis 2017, <strong>Amazon EKS (Elastic Kubernetes Service)</strong> propose de décharger les équipes de la gestion du <strong>control plane</strong>. Mais qu’en est-il du <strong>data plane</strong> et des ressources sous-jacentes ? Comment éviter de passer des heures sur l’optimisation des nœuds ou le patching du système ?</p> <p>C’est là qu’interviennent <strong>Karpenter</strong> et <strong>EKS Auto Mode</strong>.</p> <hr /> <h2>Karpenter : le scaling intelligent et granulaire</h2> <h3>De Cluster Autoscaler à Karpenter : changer de paradigme</h3> <p>Avant Karpenter, le scaling horizontal (HPA) et Cluster Autoscaler étaient les standards. Mais ils reposaient sur des <strong>Auto Scaling Groups (ASG)</strong>, avec plusieurs limites :<br /> - Taille des instances homogène dans un ASG (peu de flexibilité).<br /> - Latence liée à l’intermédiation entre Kubernetes, Cluster Autoscaler et ASG.<br /> - Complexité pour gérer le Spot et les architectures ARM.</p> <p><strong>Karpenter</strong>, projet open source intégré à l’écosystème Kubernetes (SIG Autoscaling), vient casser ces limitations.</p> <h3>Comment fonctionne Karpenter ?</h3> <ul> <li>Il observe les pods en attente de scheduling. </li> <li>Il choisit dynamiquement le meilleur type d’instance pour les exécuter. </li> <li>Il provisionne directement les instances via l’API EC2 (sans passer par un ASG). </li> <li>Il scale de manière fine : petites, moyennes, grandes instances, Spot, On-Demand, ARM, GPU, selon les contraintes de vos workloads.</li> </ul> <h3>Node Pools &amp; Node Classes : plus de contrôle, moins de friction</h3> <ul> <li><strong>NodePool</strong> : définit les types d’instances autorisées (par ex. : uniquement Graviton, Spot, GPU…). </li> <li><strong>NodeClass</strong> : configure les instances (subnets, AMI, IAM role, OS version…). </li> <li>Support de l’<strong>auto-consolidation</strong> : Karpenter détecte les nœuds sous-utilisés, déploie de nouveaux nœuds optimisés, et termine les anciens.</li> </ul> <h3>Bénéfices concrets pour Qonto :</h3> <ul> <li><strong>Scalabilité granulaire</strong> sans dépendance à des groupes statiques. </li> <li><strong>Adoption facilitée du Spot</strong> avec des économies sur le compute (jusqu’à 55 % combiné à Graviton et consolidation). </li> <li><strong>Simplification des mises à jour</strong> : changement de version d’OS simplement via la NodeClass. </li> <li><strong>Réduction des temps de mise à jour</strong> : de plusieurs jours à 1h pour certains clusters.</li> </ul> <hr /> <h2>Aller plus loin avec EKS Auto Mode : l’automatisation poussée de Kubernetes</h2> <h3>Le constat : EKS gère déjà le control plane, mais la gestion des nœuds restait à la charge des clients</h3> <p>Avec <strong>EKS Auto Mode</strong>, AWS va plus loin :<br /> - Gestion automatique <strong>du data plane</strong> (instances EC2, patching, dimensionnement).<br /> - Sélection dynamique des instances optimales.<br /> - Mises à jour automatiques des nœuds avec OS optimisé (Amazon Linux / Ubuntu).<br /> - Surveillance de l’état de santé des nœuds + correction automatique.<br /> - <strong>Compute éphémère</strong> : rotation régulière des instances, réduisant la surface d’attaque et les risques liés aux patchs manquants.</p> <h3>La promesse :</h3> <p><strong>Vous déclarez vos pods, AWS gère le reste.</strong></p> <p>Plus besoin de gérer :<br /> - Le cycle de vie des instances.<br /> - Le patching OS.<br /> - Le monitoring bas niveau.<br /> - La mise à l’échelle (scaling up &amp; scaling down).</p> <h3>Focus sécurité :</h3> <ul> <li>Intégration native avec <strong>IAM Pod Identity</strong> pour les permissions sur les services AWS. </li> <li>Rafraîchissement automatique des pods (patching tous les 14 jours). </li> <li>Compute éphémère = renouvellement continu des ressources sous-jacentes. </li> <li>Compatibilité avec les services de sécurité AWS (GuardDuty, Security Hub…).</li> </ul> <hr /> <h2>Karpenter + Auto Mode : complémentaires ou concurrents ?</h2> <p>Les deux solutions sont <strong>complémentaires</strong> :<br /> - <strong>Karpenter</strong> : idéal si vous avez besoin de <strong>contrôle fin</strong> sur les types d’instances, les stratégies Spot, les pools par workload (GPU, Graviton, etc.).<br /> - <strong>Auto Mode</strong> : pour les cas où vous voulez <strong>externaliser totalement la gestion du data plane</strong> et concentrer vos efforts sur les déploiements applicatifs, sans gérer d’infrastructure.</p> <p><strong>Chez Qonto</strong> :<br /> - Karpenter optimise les clusters actuels avec une gestion granulaire des instances.<br /> - Auto Mode est exploré pour continuer à <strong>réduire la maintenance</strong> et déléguer davantage d’opérations non différenciantes à AWS.</p> <hr /> <h2>Pourquoi ces choix technologiques comptent ?</h2> <p>Chez Qonto, ce sont <strong>15 clusters</strong>, <strong>15 000 pods</strong> et <strong>200 déploiements par jour</strong>.<br /> Avec ce niveau d’activité, maintenir un bon équilibre entre :<br /> - Disponibilité.<br /> - Sécurité.<br /> - Scalabilité.<br /> - Coût maîtrisé. </p> <p>…devient un défi majeur. L’automatisation via Karpenter et Auto Mode permet de libérer les équipes des tâches les plus répétitives et chronophages.</p> <hr /> <h2>Conclusion : Kubernetes à grande échelle, mais sans douleur</h2> <p>Scalabilité, coûts, sécurité, maintenance : les défis Kubernetes sont nombreux. Avec <strong>EKS, Karpenter et EKS Auto Mode</strong>, AWS propose un ensemble cohérent pour :<br /> - Accélérer les déploiements.<br /> - Simplifier la gestion opérationnelle.<br /> - Optimiser les coûts de calcul.<br /> - Sécuriser les clusters par défaut.</p> <p>L’expérience de Qonto montre que ces outils sont non seulement efficaces, mais surtout <strong>adaptés à une gestion Kubernetes à grande échelle</strong>.</p> <blockquote> <p>Et si vous pouviez, vous aussi, passer plus de temps à innover… et moins à patcher vos nœuds ?</p> </blockquote>2025-04-18T10:00:00+02:002025-04-18T10:00:00+02:00Hervé Leclerctag:blogppr.alterway.fr,2025-04-18:/deployer-talos-sur-numspot.html

<p>Déployer un cluster Kubernetes Talos sur NumSpot avec Terraform : quand minimalisme et souveraineté riment avec modernité</p>

<h1>Déployer un cluster Kubernetes Talos sur NumSpot avec Terraform : quand minimalisme et souveraineté riment avec modernité</h1> <h2>Motivation</h2> <p>Chez de nombreux Cloud Providers, la tentation est grande d’utiliser les services managés Kubernetes (KaaS) : maintenance simplifiée, upgrades automatisés, intégration avec la console cloud... NumSpot n’échappe pas à la règle et propose sa propre offre Kubernetes managée, très séduisante pour qui veut déployer vite et sans douleur.</p> <p>Mais que faire lorsqu'on souhaite garder un contrôle total sur son OS, sa couche Kubernetes, tout en s’appuyant sur l’infrastructure robuste d’un cloud souverain ? C’est là que Talos de SideroLabs entre en scène. Minimaliste, sécurisé et taillé pour le Cloud Native, Talos OS s’impose comme un choix sérieux pour déployer Kubernetes en toute maîtrise.</p> <p>Dans cet article, je vous guide sur la création d’un cluster Talos sur NumSpot, orchestré par Terraform. Une alternative sérieuse pour ceux qui veulent conjuguer automatisation, sobriété et souveraineté.</p> <h2>Pourquoi Talos et pas un service managé ?</h2> <p>Avant de plonger dans le code, posons le décor.</p> <p>Talos est un OS Linux immuable et minimaliste conçu exclusivement pour exécuter Kubernetes. <strong>Pas de package manager</strong>, <strong>pas de SSH</strong>, une <strong>surface d’attaque</strong> réduite au strict nécessaire, et une approche <strong>API-first</strong> pour l'administration.</p> <p>NumSpot, de son côté, est un cloud souverain basé sur OutScale (Xen), robuste et compatible avec les standards du cloud public. Il propose déjà un Kubernetes managé, mais dans notre cas :</p> <p>Contrainte de sécurité élevée : Talos réduit les vecteurs d'attaque.</p> <p>Volonté d’expérimenter : maîtriser les mises à jour, le bootstrap, la gestion du cycle de vie.</p> <p>Homogénéité multi-cloud / on-prem : même OS partout, même comportement.</p> <h2>Pré-requis</h2> <p>Avant de commencer :</p> <ul> <li> <p>Un projet actif sur NumSpot avec quota suffisant.</p> </li> <li> <p>Un compte de service numspot avec des droits suffisants pour créer tous les éléments de l'infrastructure Numspot.</p> </li> <li> <p>Sous la forme d'un ID (SA_idKey) et d'un Secret (SA_KeyPass)</p> </li> <li> <p>Une infrastructure réseau existante (Vpc, Subnet, Nat Gateway). Très facile à créer en utilisant terraform.</p> </li> <li> <p>Une vm de service avec :</p> <ul> <li>Terraform installé (&gt;=1.6.x).</li> <li>talosctl installé.</li> <li>curl pour accéder à l'API de numspot car tou n'est pas encore disponible dans le provider terraform pour Numspot.</li> <li><strong>Prévoyez sur cette VM un volume supplémentaire de 20G monté sur la VM (/dev/sda).</strong></li> </ul> </li> </ul> <h2>1. Création d'une Image dans le catalogue privé du compte Numspot</h2> <p>L'image Talos n'est pas disponible dans le catalogue public de Numspot. </p> <h3>1.1 Téléchargement du raw disk Talos Linux</h3> <p>Nous allons devoir télécharger une image sur <a href="https://factory.talos.dev/">Talos Linux Image Factory</a></p> <p>C'est un service proposé par Sidero Labs qui permet de générer des images machine personnalisées pour Talos Linux. </p> <ul> <li>Choisir la version de Talos Linux, ex: 1.9.5</li> <li>Cliquer sur "Next"</li> <li>Choisir "Nocloud" comme type de distribution</li> <li>Cliquer sur "Next"</li> <li>Choisir amd64 comme architecture de machine, ne pas cocher SecureBoot</li> <li>Cliquer sur "Next"</li> <li>Vous pouvez choisir des extensions système si besoin (moi j'en ai choisi aucune)</li> <li>Cliquer sur "Next"</li> <li>Laisser le champ Customization vide</li> <li>Cliquer sur "Next"</li> <li>Télécharger le Disk Image (ex: https://factory.talos.dev/image/<hash>/v1.9.5/nocloud-amd64.raw.xz) <strong>sur la VM de service</strong></li> </ul> <h3>1.1.2 Copie du raw disk sur /dev/sda</h3> <ul> <li>Décompresser le raw disk </li> </ul> <div class="codehilite"><pre><span></span><code>xz<span class="w"> </span>-d<span class="w"> </span>nocloud-amd64.raw.xz mv<span class="w"> </span>talos-1.9.5-nocloud-amd64.raw<span class="w"> </span> </code></pre></div> <ul> <li>Nettoyage du disk avant copie</li> </ul> <p>Vérifiez où est monté votre volume dans la vm (sudo fdisk -l). (Moi /dev/sda)</p> <div class="codehilite"><pre><span></span><code>Disk /dev/vda: 10 GiB, 10737418240 bytes, 20971520 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: C7AE58FB-33FF-47AD-B0B0-C5494AA4C12B Device Start End Sectors Size Type /dev/vda1 2099200 20971486 18872287 9G Linux filesystem /dev/vda14 2048 10239 8192 4M BIOS boot /dev/vda15 10240 227327 217088 106M EFI System /dev/vda16 227328 2097152 1869825 913M Linux extended boot Partition table entries are not in disk order. Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors Disk model: QEMU HARDDISK Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes </code></pre></div> <p>Commande à lancer </p> <div class="codehilite"><pre><span></span><code>sudo<span class="w"> </span>wipefs<span class="w"> </span>-a<span class="w"> </span>/dev/sda </code></pre></div> <ul> <li>Copie avec la commande dd du raw disk sur /dev/sda</li> </ul> <div class="codehilite"><pre><span></span><code>sudo<span class="w"> </span>dd<span class="w"> </span><span class="k">if</span><span class="o">=</span>talos-1.9.5-nocloud-amd64.raw<span class="w"> </span><span class="nv">of</span><span class="o">=</span>/dev/sda<span class="w"> </span><span class="nv">bs</span><span class="o">=</span>32M<span class="w"> </span><span class="nv">status</span><span class="o">=</span>progress <span class="m">1241513984</span><span class="w"> </span>bytes<span class="w"> </span><span class="o">(</span><span class="m">1</span>.2<span class="w"> </span>GB,<span class="w"> </span><span class="m">1</span>.2<span class="w"> </span>GiB<span class="o">)</span><span class="w"> </span>copied,<span class="w"> </span><span class="m">1</span><span class="w"> </span>s,<span class="w"> </span><span class="m">1</span>.1<span class="w"> </span>GB/s<span class="w"> </span>... <span class="m">38</span>+1<span class="w"> </span>records<span class="w"> </span><span class="k">in</span> <span class="m">38</span>+1<span class="w"> </span>records<span class="w"> </span>out <span class="m">1306525696</span><span class="w"> </span>bytes<span class="w"> </span><span class="o">(</span><span class="m">1</span>.3<span class="w"> </span>GB,<span class="w"> </span><span class="m">1</span>.2<span class="w"> </span>GiB<span class="o">)</span><span class="w"> </span>copied,<span class="w"> </span><span class="m">123</span>.819<span class="w"> </span>s,<span class="w"> </span><span class="m">10</span>.6<span class="w"> </span>MB/s </code></pre></div> <p><strong>Soyez patient !</strong></p> <p>Ça peut prendre un certain temps avant d'avoir la 🫲.</p> <p>Si on repasse un <code>fdisk -l</code></p> <p>on voit que le disk a maintenant une structure</p> <div class="codehilite"><pre><span></span><code>Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors Disk model: QEMU HARDDISK Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 1C07C588-7E7B-4245-BF46-C54B8BCBDEEE Device Start End Sectors Size Type /dev/sda1 2048 206847 204800 100M EFI System /dev/sda2 206848 208895 2048 1M BIOS boot /dev/sda3 208896 2256895 2048000 1000M Linux filesystem /dev/sda4 2256896 2258943 2048 1M Linux filesystem </code></pre></div> <h3>1.1.3 Snapshot du volume pour en faire un ... Snapshot 😏</h3> <p>Sur numspot on peut convertir un snapshot en une image numspot utilisable pour booter une vm.</p> <p>Je pense qu'on peut faire cette partie par l'api de numspot, mais je vais au plus simple et je vais le faire par le portail.</p> <ul> <li>Allez dans Stockage &gt;&gt; Volumes </li> <li>Identifiez le volume que vous avez ajouté à votre VM </li> <li>Dans <code>Actions</code> Choissisez "Créer un Snapshot depuis ce Volume"</li> <li>Donnez un nom à votre snapshot pour facilement l'identifier (ex: talos-nocloud-1.9.5)</li> </ul> <p><center> <image src="/images/numspot/s1.png"> </center></p> <ul> <li>Puis allez dans snapshot, Vérifiez que votre snapshot est généré et disponible</li> </ul> <p><center> <image src="/images/numspot/s2.png"> </center></p> <ul> <li>notez l'ID du snapshot dans notre exemple <code>snap-88153838</code></li> </ul> <h3>1.1.4 Transformation du Snapshot en Image privée Numspot</h3> <p>C'est à ce moment-là que les choses se compliquent car cette fonctionnalité n'existe pas <strong>encore</strong> dans le portail.</p> <p>On va donc utiliser l'API de numspot pour faire ça !</p> <ul> <li> <p>Il faut nous connecter à l'API pour récupérer un TOKEN d'authentification qui sera utilisé dans les commandes curl suivantes.</p> </li> <li> <p>Créer un script <code>auth.sh</code> avec le code suivant :</p> </li> </ul> <p>Adapter simplement <code>REGION</code>, <code>SA_idKey</code> et <code>SA_KeyPass</code></p> <div class="codehilite"><pre><span></span><code><span class="c1"># auth.sh</span> <span class="nb">export</span><span class="w"> </span><span class="nv">REGION</span><span class="o">=</span><span class="s2">&quot;cloudgouv-eu-west-1&quot;</span> <span class="nv">SA_idKey</span><span class="o">=</span><span class="s2">&quot;zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz&quot;</span> <span class="nv">SA_KeyPass</span><span class="o">=</span><span class="s2">&quot;omygodthisisasecretkey&quot;</span> <span class="nb">export</span><span class="w"> </span><span class="nv">ACCESS_TOKEN</span><span class="o">=</span><span class="k">$(</span>curl<span class="w"> </span>-s<span class="w"> </span>-X<span class="w"> </span>POST<span class="w"> </span>https://api.<span class="nv">$REGION</span>.numspot.com/iam/token<span class="w"> </span><span class="se">\</span> -H<span class="w"> </span><span class="s1">&#39;Accept: */*&#39;</span><span class="w"> </span><span class="se">\</span> -u<span class="w"> </span><span class="s2">&quot;</span><span class="si">${</span><span class="nv">SA_idKey</span><span class="si">}</span><span class="s2">&quot;</span>:<span class="s2">&quot;</span><span class="si">${</span><span class="nv">SA_KeyPass</span><span class="si">}</span><span class="s2">&quot;</span><span class="w"> </span><span class="se">\</span> -H<span class="w"> </span><span class="s1">&#39;Content-Type: application/x-www-form-urlencoded&#39;</span><span class="w"> </span><span class="se">\</span> -d<span class="w"> </span><span class="s1">&#39;grant_type=client_credentials&amp;scope=openid+offline_access&#39;</span><span class="w"> </span><span class="p">|</span><span class="w"> </span>jq<span class="w"> </span>-r<span class="w"> </span><span class="s1">&#39;.access_token&#39;</span><span class="k">)</span> <span class="c1"># pour Debug seulement</span> <span class="c1">#echo $ACCESS_TOKEN</span> </code></pre></div> <ul> <li>Nous avons notre <code>TOKEN</code>. Nous allons donc transformer notre snapshot en image privée.</li> </ul> <p>Créer le script suivant ou la commande :</p> <div class="codehilite"><pre><span></span><code><span class="ch">#!/bin/bash</span> <span class="nb">source</span><span class="w"> </span>auth.sh curl<span class="w"> </span><span class="s1">&#39;https://api.cloudgouv-eu-west-1.numspot.com/compute/spaces/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx/images&#39;</span><span class="w"> </span><span class="se">\</span> <span class="w"> </span>--request<span class="w"> </span>POST<span class="w"> </span><span class="se">\</span> <span class="w"> </span>--header<span class="w"> </span><span class="s1">&#39;Content-Type: application/json&#39;</span><span class="w"> </span><span class="se">\</span> <span class="w"> </span>--header<span class="w"> </span><span class="s2">&quot;Authorization: Bearer </span><span class="si">${</span><span class="nv">ACCESS_TOKEN</span><span class="si">}</span><span class="s2">&quot;</span><span class="w"> </span><span class="se">\</span> <span class="w"> </span>--data<span class="w"> </span><span class="s1">&#39;{</span> <span class="s1"> &quot;architecture&quot;: &quot;x86_64&quot;,</span> <span class="s1"> &quot;blockDeviceMappings&quot;: [</span> <span class="s1"> {</span> <span class="s1"> &quot;bsu&quot;: {</span> <span class="s1"> &quot;deleteOnVmDeletion&quot;: true,</span> <span class="s1"> &quot;snapshotId&quot;: &quot;snap-88153838&quot;,</span> <span class="s1"> &quot;volumeSize&quot;: 20,</span> <span class="s1"> &quot;volumeType&quot;: &quot;standard&quot;</span> <span class="s1"> },</span> <span class="s1"> &quot;deviceName&quot;: &quot;/dev/sda1&quot;</span> <span class="s1"> }</span> <span class="s1"> ],</span> <span class="s1"> &quot;productCodes&quot;: [</span> <span class="s1"> &quot;0001&quot;</span> <span class="s1"> ],</span> <span class="s1"> &quot;name&quot;: &quot;talos1.9.5-img&quot;,</span> <span class="s1"> &quot;rootDeviceName&quot;: &quot;/dev/sda1&quot;</span> <span class="s1">}&#39;</span> </code></pre></div> <ul> <li>Adaptez les champs :</li> <li>snapshotId</li> <li>name </li> <li> <p>volumeType (si besoin)</p> </li> <li> <p>Gardez les champs :</p> <ul> <li>/dev/sda1 de deviceName et rootDeviceName </li> <li>architecture </li> </ul> </li> </ul> <p>Je ne sais pas trop ce qu'est <code>productCodes</code></p> <p>Note : </p> <ul> <li>Comment trouver https://api.cloudgouv-eu-west-1.numspot.com/compute/spaces/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx ?</li> <li> <p>Allez dans IAM &gt;&gt; Espaces : Prenez l'ID de votre Espace</p> </li> <li> <p>Lancez le script </p> </li> </ul> <p>Si tout se passe bien, allez dans Compute &gt;&gt; Images et tapez Talos dans le champ de recherche. Vous devriez avoir quelque chose d'approchant à ça </p> <p><center> <image src="/images/numspot/s3.png"> </center></p> <p>Notez l'ID de votre image (chez moi <code>ami-4a8eaf5a</code>)</p> <p>Voilà nous avons une image disponible nous allons pouvoir créer des VM à partir de cette image.</p> <p><center> <image src="/images/numspot/s4.png"> </center></p> <p>Vous pouvez déjà créer une vm de test pour vous assurer qu'elle boot correctement</p> <p>Note : </p> <p>Le boot est, je ne sais pas trop pourquoi, la première fois très lent.</p> <p>Si vous ouvrez la console de la VM créée vous aurez quelque chose comme ça d'approchant :</p> <p><center> <image src="/images/numspot/s5.png"> </center></p> <hr /> <h2>2. Création des configurations terraform pour Talos sur Numspot</h2> <p>Structure du répertoire :</p> <div class="codehilite"><pre><span></span><code>. ├── files ├── numspot-talos └── templates </code></pre></div> <p>Répertoire :</p> <ul> <li><code>files</code> : contient 1 fichier <code>cp-scheduling.yaml</code> qui permet de configurer les nœuds Talos avec des données fixes.</li> <li><code>templates</code> : contient 1 fichier de configuration <code>node-configuration.yaml.tmpl</code> qui permet de configurer les différents nœuds en fonction de leurs rôles ou autres paramètres.</li> <li><code>numspot-talos</code> : répertoire généré avec le nom du cluster, contiendra les fichiers permettant d'administrer le cluster avec la CLI talosctl et le kubeconfig permettant l'accès à l'API kubernetes</li> </ul> <h3>2.1 fichiers Providers</h3> <ul> <li>Créez un fichier <code>providers.tf</code> avec le code suivant :</li> </ul> <div class="codehilite"><pre><span></span><code><span class="nb">terraform</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="nb">required_providers</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="nb">numspot</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">source</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;numspot/numspot&quot;</span> <span class="w"> </span><span class="na">version</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;&gt;= 1.0&quot;</span> <span class="w"> </span><span class="p">}</span> <span class="w"> </span><span class="nb">talos</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">source</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;siderolabs/talos&quot;</span> <span class="w"> </span><span class="na">version</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;&gt;= 0.6.0&quot;</span> <span class="w"> </span><span class="p">}</span> <span class="w"> </span><span class="p">}</span> <span class="p">}</span> <span class="kr">provider</span><span class="w"> </span><span class="nv">&quot;numspot&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">numspot_host</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;https://api.cloudgouv-eu-west-1.numspot.com&quot;</span> <span class="w"> </span><span class="na">client_id</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;ID du SA&quot;</span> <span class="w"> </span><span class="na">client_secret</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;Secret du SA&quot;</span> <span class="w"> </span><span class="na">space_id</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;Votre Space ID&quot;</span> <span class="w"> </span><span class="na">numspot_host_os</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;https://objectstorage.eu-west-2.numspot.com&quot;</span> <span class="p">}</span> </code></pre></div> <p>Adaptez les informations de numspot</p> <p>Le rôle principal du fichier <code>providers.tf</code> est de :</p> <ul> <li> <p>Déclarer les fournisseurs (Providers) requis : Indiquer à Terraform quels plugins (fournisseurs) sont nécessaires pour interagir avec les différentes API des services que vous souhaitez gérer (ici, NumSpot et Talos).</p> </li> <li> <p>Configurer les fournisseurs : Fournir les informations d'authentification et les paramètres spécifiques (comme les points de terminaison d'API ou les régions) pour que Terraform puisse communiquer correctement avec ces services.</p> </li> <li> <p>Bloc terraform {}</p> <ul> <li>C'est un bloc spécial pour les configurations globales de Terraform lui-même.</li> <li>required_providers {} : Ce sous-bloc est crucial. Il liste les fournisseurs externes dont dépend votre code Terraform.<ul> <li>numspot = { ... } :<ul> <li>Déclare que le fournisseur numspot est nécessaire.</li> <li>source = "numspot/numspot" : Indique à Terraform où trouver le code de ce fournisseur dans le Registre Terraform (ici, il s'agit du fournisseur officiel maintenu par ou pour NumSpot).</li> <li>version = "&gt;= 1.0" : Spécifie que n'importe quelle version du fournisseur numspot égale ou supérieure à 1.0 est acceptable. Terraform téléchargera la version la plus récente correspondante lors de l'exécution de terraform init.</li> </ul> </li> <li>talos = { ... } :<ul> <li>Déclare que le fournisseur talos est nécessaire.</li> <li>source = "siderolabs/talos" : Indique que ce fournisseur provient de l'organisation siderolabs (les créateurs de Talos OS).</li> <li>version = "&gt;= 0.6.0" : Spécifie que n'importe quelle version du fournisseur Talos égale ou supérieure à 0.6.0 est acceptable.</li> </ul> </li> </ul> </li> </ul> </li> <li>Bloc provider "numspot" {}<ul> <li>Ce bloc configure le fournisseur numspot qui a été déclaré dans required_providers. C'est ici que vous donnez à Terraform les "clés" pour accéder à votre compte NumSpot.</li> <li>numspot_host = "https://api.cloudgouv-eu-west-1.numspot.com" : Définit l'URL du point de terminaison (endpoint) de l'API principale de NumSpot pour la région eu-west-1. C'est l'adresse que Terraform utilisera pour envoyer ses requêtes de gestion d'infrastructure.</li> <li>client_id = "ID du SA" : C'est l'identifiant de votre Compte de Service (SA) NumSpot. Vous devez remplacer "ID du SA" par votre véritable identifiant. Ce compte doit avoir les permissions nécessaires pour créer/modifier/supprimer les ressources définies dans votre code Terraform.</li> <li>client_secret = "Secret du SA" : C'est le secret associé à votre client_id. Vous devez remplacer "Secret du SA" par votre véritable secret. ATTENTION : Il est fortement déconseillé de stocker des secrets en clair directement dans les fichiers .tf. Utilisez plutôt des variables d'environnement (ex: NUMSPOT_CLIENT_SECRET) ou un fichier terraform.tfvars (ajouté au .gitignore) pour plus de sécurité.</li> <li>space_id = "Votre Space ID" : C'est l'identifiant de votre "Espace" (Space) NumSpot, qui correspond souvent à un projet ou un périmètre d'isolation logique au sein de votre organisation. Vous devez remplacer "Votre Space ID" par votre ID d'espace réel.</li> <li>numspot_host_os = "https://objectstorage.eu-west-2.numspot.com" : Définit l'URL du point de terminaison spécifique pour le service de Stockage Objet (Object Storage) de NumSpot, ici dans la région eu-west-2. Le fournisseur peut avoir besoin de cette information pour certaines opérations liées au stockage (par exemple, si vous gérez des buckets S3 ou téléchargez des images via ce service).</li> </ul> </li> </ul> <h3>2.2 variables et fichiers de configuration statiques ou templates</h3> <p>Nous allons avoir besoin de quelques variables.</p> <p>Ce fichier (vars.tf ou variables.tf) regroupe les paramètres que j'ai rendus configurables pour ce projet de déploiement de Talos sur NumSpot. </p> <p>L'idée est que vous puissiez adapter facilement le déploiement à vos besoins (nom du cluster, IPs, configuration des nœuds) sans toucher au cœur logique du code Terraform.</p> <p>Il faudra adapter les adresses IP en fonction des subnets que vous avez définis.</p> <p>Un des gros avantages de Talos c'est de pouvoir définir une <code>vip</code> pour le control plane.</p> <ul> <li>Créez un fichier <code>vars.tf</code> avec le code suivant :</li> </ul> <div class="codehilite"><pre><span></span><code><span class="kr">variable</span><span class="w"> </span><span class="nv">&quot;cluster_name&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">description</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;A name to provide for the Talos cluster&quot;</span> <span class="w"> </span><span class="na">type</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="kt">string</span> <span class="w"> </span><span class="na">default</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;numspot-talos&quot;</span> <span class="p">}</span> <span class="kr">variable</span><span class="w"> </span><span class="nv">&quot;vip&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">description</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;vip of k8s Talos cluster&quot;</span> <span class="w"> </span><span class="na">type</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="kt">string</span> <span class="w"> </span><span class="na">default</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;10.0.1.230&quot;</span> <span class="p">}</span> <span class="kr">variable</span><span class="w"> </span><span class="nv">&quot;node_data&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">description</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;A map of node data&quot;</span> <span class="w"> </span><span class="na">type</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="kt">object</span><span class="p">({</span> <span class="w"> </span><span class="na">controlplanes</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nf">map</span><span class="p">(</span><span class="kt">object</span><span class="p">({</span> <span class="w"> </span><span class="na">install_disk</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="kt">string</span> <span class="w"> </span><span class="na">hostname</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="err">optional</span><span class="p">(</span><span class="kt">string</span><span class="p">)</span> <span class="w"> </span><span class="p">}))</span> <span class="w"> </span><span class="na">workers</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nf">map</span><span class="p">(</span><span class="kt">object</span><span class="p">({</span> <span class="w"> </span><span class="na">install_disk</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="kt">string</span> <span class="w"> </span><span class="na">hostname</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="err">optional</span><span class="p">(</span><span class="kt">string</span><span class="p">)</span> <span class="w"> </span><span class="p">}))</span> <span class="w"> </span><span class="p">})</span> <span class="w"> </span><span class="nb">default</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="nb">controlplanes</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="s2">&quot;10.0.1.234&quot;</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">install_disk</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;/dev/sda&quot;</span> <span class="w"> </span><span class="p">},</span> <span class="w"> </span><span class="s2">&quot;10.0.1.235&quot;</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">install_disk</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;/dev/sda&quot;</span> <span class="w"> </span><span class="p">},</span> <span class="w"> </span><span class="s2">&quot;10.0.1.236&quot;</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">install_disk</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;/dev/sda&quot;</span> <span class="w"> </span><span class="p">}</span> <span class="w"> </span><span class="p">}</span> <span class="w"> </span><span class="nb">workers</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="s2">&quot;10.0.1.240&quot;</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">install_disk</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;/dev/sda&quot;</span> <span class="w"> </span><span class="na">hostname</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;worker-1&quot;</span> <span class="w"> </span><span class="p">},</span> <span class="w"> </span><span class="s2">&quot;10.0.1.241&quot;</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">install_disk</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;/dev/sda&quot;</span> <span class="w"> </span><span class="na">hostname</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;worker-2&quot;</span> <span class="w"> </span><span class="p">}</span> <span class="w"> </span><span class="p">}</span> <span class="w"> </span><span class="p">}</span> <span class="p">}</span> </code></pre></div> <p>Voici le détail des variables que j'ai définies :</p> <ol> <li> <p><strong><code>variable "cluster_name"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> Ici, vous définissez le nom que portera le cluster Talos que nous allons créer. Ce nom sera utilisé pour taguer certaines ressources ou dans la configuration Talos elle-même.</li> <li><strong>Type attendu :</strong> Une simple chaîne de caractères (<code>string</code>).</li> <li><strong>Valeur par défaut :</strong> Si vous ne fournissez pas de nom spécifique, j'utiliserai <code>"numspot-Talos"</code> par défaut.</li> </ul> </li> <li> <p><strong><code>variable "vip"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> Cette variable sert à définir l'adresse IP virtuelle (VIP) que j'utiliserai comme point d'accès stable pour le control plane Kubernetes (l'API Server). C'est l'adresse que vous utiliserez généralement dans votre <code>kubeconfig</code>.</li> <li><strong>Type attendu :</strong> Une chaîne de caractères (<code>string</code>) représentant une adresse IP valide.</li> <li><strong>Valeur par défaut :</strong> J'ai mis <code>"10.0.1.230"</code> par défaut, ce qui correspond à mon réseau de test. Adaptez-la à votre plan d'adressage réseau.</li> </ul> </li> <li> <p><strong><code>variable "node_data"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> C'est la variable la plus structurée. Elle me permet de savoir exactement quels nœuds (control planes et workers) vous voulez dans votre cluster et quelques détails à leur sujet. Pour chaque nœud, je m'attends à trouver son adresse IP (qui sert de clé dans la map), le disque sur lequel je dois installer Talos (<code>install_disk</code>), et éventuellement un nom d'hôte (<code>hostname</code>) que vous souhaitez lui assigner.</li> <li><strong>Type attendu :</strong> Un objet complexe (<code>object</code>) contenant deux maps : <code>controlplanes</code> et <code>workers</code>. Chaque map associe une adresse IP (clé <code>string</code>) à un objet contenant au moins <code>install_disk</code> (<code>string</code>) et optionnellement <code>hostname</code> (<code>string</code>).</li> <li><strong>Valeur par défaut :</strong> J'ai fourni une configuration par défaut assez complète pour vous montrer la structure attendue et permettre un démarrage rapide. Elle configure :<ul> <li>Trois <strong>control planes</strong> aux IPs <code>10.0.1.234</code>, <code>10.0.1.235</code>, <code>10.0.1.236</code>.</li> <li>Deux <strong>workers</strong> aux IPs <code>10.0.1.240</code> (nommé <code>worker-1</code>) et <code>10.0.1.241</code> (nommé <code>worker-2</code>).</li> <li>Pour tous ces nœuds par défaut, j'installerai Talos sur le disque <code>/dev/sda</code> (assurez-vous que c'est bien le disque que vous avez préparé sur vos VM NumSpot comme indiqué dans les prérequis !).</li> </ul> </li> </ul> </li> <li> <p>fichier <code>files/cp-scheduling.yaml</code></p> </li> </ol> <p>Contenu :</p> <div class="codehilite"><pre><span></span><code><span class="nt">cluster</span><span class="p">:</span> <span class="w"> </span><span class="nt">allowSchedulingOnControlPlanes</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">true</span> </code></pre></div> <p>Permet de déployer des workloads utilisateur sur les control-plane (vous pouvez mettre <code>false</code>)</p> <ul> <li>fichier <code>templates/node-configuration.yaml.tmpl</code></li> </ul> <p>Contenu :</p> <div class="codehilite"><pre><span></span><code><span class="nt">machine</span><span class="p">:</span> <span class="w"> </span><span class="nt">certSANs</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">${ dns_name }</span> <span class="err">%</span><span class="p p-Indicator">{</span><span class="w"> </span><span class="nv">if vip != &quot;&quot;</span><span class="w"> </span><span class="p p-Indicator">}</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">${vip}</span> <span class="err">%</span><span class="p p-Indicator">{</span><span class="w"> </span><span class="nv">endif</span><span class="w"> </span><span class="p p-Indicator">}</span> <span class="w"> </span><span class="nt">install</span><span class="p">:</span> <span class="w"> </span><span class="nt">disk</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">${install_disk}</span> <span class="w"> </span><span class="nt">network</span><span class="p">:</span> <span class="w"> </span><span class="nt">hostname</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">${hostname}</span> <span class="w"> </span><span class="nt">interfaces</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">interface</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">eth0</span> <span class="w"> </span><span class="nt">dhcp</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">true</span> <span class="err">%</span><span class="p p-Indicator">{</span><span class="w"> </span><span class="nv">if vip != &quot;&quot;</span><span class="w"> </span><span class="p p-Indicator">}</span> <span class="w"> </span><span class="nt">vip</span><span class="p">:</span> <span class="w"> </span><span class="nt">ip</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">${vip}</span> <span class="err">%</span><span class="p p-Indicator">{</span><span class="w"> </span><span class="nv">endif</span><span class="w"> </span><span class="p p-Indicator">}</span> <span class="nt">cluster</span><span class="p">:</span> <span class="w"> </span><span class="nt">apiServer</span><span class="p">:</span> <span class="w"> </span><span class="nt">certSANs</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">${ dns_name }</span> </code></pre></div> <p>Permet de configurer des install disk différents, de mettre des hostname parlant et d'ajouter les SANs pour la vip et le fqdn du loadbalancer</p> <h3>2.3 les data (ressources externes numspot)</h3> <p>Mon infrastructure Numspot possède déjà des composants déployés (ex: VPC, Subnets, IPs ...).</p> <p>Plutôt que de recréer un réseau à chaque fois, je pars du principe que vous avez déjà un VPC, un sous-réseau (subnet), et un groupe de sécurité (security group) prêts à l'emploi. </p> <p>Ce fichier sert à les "retrouver" pour que Terraform puisse les utiliser.</p> <p>Créez un fichier <code>data.tf</code> avec le code suivant :</p> <div class="codehilite"><pre><span></span><code><span class="kr">data</span><span class="w"> </span><span class="nc">&quot;numspot_vpcs&quot;</span><span class="w"> </span><span class="nv">&quot;ds-vpc&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">ids</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="s2">&quot;vpc-xxxxxxx&quot;</span><span class="p">]</span> <span class="p">}</span> <span class="kr">data</span><span class="w"> </span><span class="nc">&quot;numspot_subnets&quot;</span><span class="w"> </span><span class="nv">&quot;ds-subnet&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">vpc_ids</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="nv">data.numspot_vpcs.ds-vpc.items.0.id</span><span class="p">]</span> <span class="p">}</span> <span class="kr">data</span><span class="w"> </span><span class="nc">&quot;numspot_security_groups&quot;</span><span class="w"> </span><span class="nv">&quot;ds-sg&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">security_group_ids</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="s2">&quot;sg-xxxxxxx&quot;</span><span class="p">]</span> <span class="p">}</span> <span class="kr">resource</span><span class="w"> </span><span class="nc">&quot;null_resource&quot;</span><span class="w"> </span><span class="nv">&quot;print-ds-vpc-id&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="kr">provisioner</span><span class="w"> </span><span class="nv">&quot;local-exec&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">command</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;echo data.numspot_vpcs.ds-vpc.items.0.id&quot;</span> <span class="w"> </span><span class="p">}</span> <span class="p">}</span> <span class="kr">resource</span><span class="w"> </span><span class="nc">&quot;null_resource&quot;</span><span class="w"> </span><span class="nv">&quot;print-ds-subnet-id&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="kr">provisioner</span><span class="w"> </span><span class="nv">&quot;local-exec&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">command</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;echo data.numspot_subnets.ds-subnet.items.0.id&quot;</span> <span class="w"> </span><span class="p">}</span> <span class="p">}</span> <span class="kr">resource</span><span class="w"> </span><span class="nc">&quot;null_resource&quot;</span><span class="w"> </span><span class="nv">&quot;print-ds-sg-id&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="kr">provisioner</span><span class="w"> </span><span class="nv">&quot;local-exec&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">command</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;echo data.numspot_security_groups.ds-sg.items.0.id&quot;</span> <span class="w"> </span><span class="p">}</span> <span class="p">}</span> </code></pre></div> <ol> <li> <p><strong><code>data "numspot_vpcs" "ds-vpc"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> Ce bloc utilise une source de données (<code>data</code>) Terraform pour rechercher des informations sur un VPC spécifique dans NumSpot.</li> <li><strong>Comment :</strong> Je lui demande de chercher le VPC dont l'identifiant est <code>vpc-xxxxxxxx</code>. Le nom que je lui donne dans Terraform est <code>ds-vpc</code> (pour "data source VPC").</li> <li><strong>Pourquoi :</strong> J'ai besoin de l'identifiant et potentiellement d'autres détails de ce VPC pour configurer le reste de l'infrastructure, notamment pour trouver le bon sous-réseau.</li> <li><strong>Important :</strong> Vous <strong>devez remplacer <code>vpc-xxxxxxxx</code></strong> par l'ID du VPC que vous souhaitez réellement utiliser dans votre environnement NumSpot.</li> </ul> </li> <li> <p><strong><code>data "numspot_subnets" "ds-subnet"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> De la même manière, je recherche ici un ou plusieurs sous-réseaux.</li> <li><strong>Comment :</strong> Au lieu de chercher par ID de sous-réseau, je filtre en demandant les sous-réseaux qui appartiennent au VPC que j'ai trouvé juste avant (<code>data.numspot_vpcs.ds-vpc.items.0.id</code>). J'utilise <code>.items.0.id</code> car la source de données <code>numspot_vpcs</code> renvoie une liste (même s'il n'y a qu'un seul VPC correspondant à l'ID), et je prends le premier élément (<code>0</code>) de cette liste.</li> <li><strong>Pourquoi :</strong> Les machines virtuelles de notre cluster Talos devront être placées dans un sous-réseau spécifique. Ce bloc me permet d'obtenir l'ID de ce sous-réseau.</li> <li><strong>Note :</strong> Ce code suppose qu'il y a au moins un sous-réseau dans le VPC spécifié. Si vous en avez plusieurs, le code Terraform qui utilise <code>data.numspot_subnets.ds-subnet.items.0.id</code> ciblera le premier sous-réseau retourné par l'API NumSpot. Assurez-vous que c'est bien celui que vous visez.</li> </ul> </li> <li> <p><strong><code>data "numspot_security_groups" "ds-sg"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> Je récupère ici les informations d'un groupe de sécurité existant.</li> <li><strong>Comment :</strong> Comme pour le VPC, je le cible directement par son ID : <code>sg-xxxxxxxx</code>.</li> <li><strong>Pourquoi :</strong> Les machines virtuelles auront besoin d'être associées à un groupe de sécurité pour contrôler le trafic entrant et sortant. Ce groupe doit déjà être configuré avec les règles nécessaires pour Talos et Kubernetes (par exemple, ouvrir les ports 6443, 50000, 50001, etc.).</li> <li><strong>Important :</strong> Vous <strong>devez remplacer <code>sg-xxxxxxxx</code></strong> par l'ID du groupe de sécurité que vous avez préparé pour ce cluster.</li> </ul> </li> <li> <p><strong><code>resource "null_resource" "print-..."</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> Ces trois blocs (<code>print-ds-vpc-id</code>, <code>print-ds-subnet-id</code>, <code>print-ds-sg-id</code>) sont un peu différents. Ils utilisent une ressource <code>null_resource</code>, qui ne crée rien dans NumSpot. Associée à <code>provisioner "local-exec"</code>, elle me permet simplement d'exécuter une commande sur la machine où vous lancez Terraform.</li> <li><strong>Comment :</strong> J'exécute une commande <code>echo</code> qui affiche littéralement la chaîne de caractères correspondant au chemin d'accès Terraform vers l'ID de la ressource (par exemple, <code>echo data.numspot_vpcs.ds-vpc.items.0.id</code>).</li> <li><strong>Pourquoi :</strong> Je les ai ajoutés principalement à des fins de <strong>débogage</strong> ou de <strong>vérification rapide</strong>. Lorsque vous lancez <code>terraform apply</code>, ces commandes s'exécuteront et afficheront les chemins d'accès dans la sortie. Cela ne montre pas la <em>valeur</em> de l'ID, mais confirme que Terraform tente d'utiliser ces références. C'est une petite aide pour s'assurer que les data sources sont bien lues, même si pour voir les <em>vraies</em> valeurs, il faudrait utiliser des <code>output</code> ou une interpolation <code>${...}</code> dans le <code>echo</code>.</li> <li><strong>Note :</strong> Ces ressources <code>null_resource</code> n'ont aucun impact sur l'infrastructure créée et peuvent être retirées si vous les trouvez inutiles.</li> </ul> </li> </ol> <h3>2.4 Les VMs et autres composants de l'infrastructure</h3> <p>Ce fichier contient les définitions des ressources principales que Terraform va créer et gérer sur NumSpot pour notre cluster Talos. On y trouve la création des VMs (Control Plane et Workers) et du Load Balancer nécessaire pour la haute disponibilité et l'accès externe à l'API Kubernetes.</p> <ul> <li>Créez un fichier infra.tf avec le code suivant :</li> </ul> <div class="codehilite"><pre><span></span><code><span class="c1"># Création des VMs Controlplane</span> <span class="kr">resource</span><span class="w"> </span><span class="nc">&quot;numspot_vm&quot;</span><span class="w"> </span><span class="nv">&quot;talos-cp&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">for_each</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">var.node_data.controlplanes</span> <span class="w"> </span><span class="na">image_id</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;ami-4a8eaf5a&quot;</span> <span class="w"> </span><span class="na">type</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;ns-eco6-2c8r&quot;</span> <span class="w"> </span><span class="na">keypair_name</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;talos-keypair&quot;</span> <span class="w"> </span><span class="na">subnet_id</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">data.numspot_subnets.ds-subnet.items.0.id</span> <span class="w"> </span><span class="na">security_group_ids</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="nv">data.numspot_security_groups.ds-sg.items.0.id</span><span class="p">]</span> <span class="w"> </span><span class="na">private_ips</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="nv">each.key</span><span class="p">]</span> <span class="w"> </span><span class="na">tags</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span> <span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">key</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;name&quot;</span> <span class="w"> </span><span class="na">value</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;talos-cp-${each.key}&quot;</span> <span class="w"> </span><span class="p">}</span> <span class="w"> </span><span class="p">]</span> <span class="p">}</span> <span class="c1"># Création des VMs Worker</span> <span class="kr">resource</span><span class="w"> </span><span class="nc">&quot;numspot_vm&quot;</span><span class="w"> </span><span class="nv">&quot;talos-worker&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">for_each</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">var.node_data.workers</span> <span class="w"> </span><span class="na">image_id</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;ami-4a8eaf5a&quot;</span> <span class="w"> </span><span class="na">type</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;ns-eco6-2c8r&quot;</span> <span class="w"> </span><span class="na">keypair_name</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;talos-keypair&quot;</span> <span class="w"> </span><span class="na">subnet_id</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">data.numspot_subnets.ds-subnet.items.0.id</span> <span class="w"> </span><span class="na">security_group_ids</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="nv">data.numspot_security_groups.ds-sg.items.0.id</span><span class="p">]</span> <span class="w"> </span><span class="na">private_ips</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="nv">each.key</span><span class="p">]</span> <span class="w"> </span><span class="na">tags</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span> <span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">key</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;name&quot;</span> <span class="w"> </span><span class="na">value</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;talos-worker-${each.value.hostname}&quot;</span> <span class="w"> </span><span class="p">}</span> <span class="w"> </span><span class="p">]</span> <span class="p">}</span> <span class="kr">resource</span><span class="w"> </span><span class="nc">&quot;numspot_load_balancer&quot;</span><span class="w"> </span><span class="nv">&quot;load-balancer&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">name</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;nlb001&quot;</span> <span class="w"> </span><span class="na">listeners</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[{</span> <span class="w"> </span><span class="na">load_balancer_port</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="m">6443</span> <span class="w"> </span><span class="na">backend_port</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="m">6443</span> <span class="w"> </span><span class="na">backend_protocol</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;TCP&quot;</span> <span class="w"> </span><span class="na">load_balancer_protocol</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;TCP&quot;</span> <span class="w"> </span><span class="p">}]</span> <span class="w"> </span><span class="na">subnets</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="nv">data.numspot_subnets.ds-subnet.items.0.id</span><span class="p">]</span> <span class="w"> </span><span class="na">security_groups</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="nv">data.numspot_security_groups.ds-sg.items.0.id</span><span class="p">]</span> <span class="w"> </span><span class="na">backend_vm_ids</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="err">for</span><span class="w"> </span><span class="err">ip</span><span class="p">,</span><span class="w"> </span><span class="err">data</span><span class="w"> </span><span class="err">in</span><span class="w"> </span><span class="nv">var.node_data.controlplanes</span><span class="w"> </span><span class="p">:</span><span class="w"> </span><span class="nv">numspot_vm.talos-cp[ip].id</span><span class="p">]</span> <span class="c1"> // invalide à l&#39;heure actuelle - public_ip = numspot_public_ip.lb-public-ip.public_ip</span> <span class="w"> </span><span class="na">type</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;internet-facing&quot;</span> <span class="w"> </span><span class="nb">health_check</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">healthy_threshold</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="m">3</span> <span class="w"> </span><span class="na">check_interval</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="m">10</span> <span class="w"> </span><span class="na">port</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="m">6443</span> <span class="w"> </span><span class="na">protocol</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;HTTPS&quot;</span> <span class="w"> </span><span class="na">path</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;/api/v1/namespaces/kube-public/configmaps/cluster-info&quot;</span> <span class="w"> </span><span class="na">timeout</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="m">5</span> <span class="w"> </span><span class="na">unhealthy_threshold</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="m">5</span> <span class="w"> </span><span class="p">}</span> <span class="p">}</span> <span class="kr">data</span><span class="w"> </span><span class="nc">&quot;numspot_load_balancers&quot;</span><span class="w"> </span><span class="nv">&quot;load-balancer&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">load_balancer_names</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="nv">numspot_load_balancer.load-balancer.name</span><span class="p">]</span> <span class="w"> </span><span class="na">depends_on</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="nv">numspot_load_balancer.load-balancer</span><span class="p">]</span> <span class="p">}</span> </code></pre></div> <hr /> <p><strong>Note :</strong></p> <p>Pour le Health check je mets ça mais en fait ça ne peut pas marcher car tous les accès à l'API sont authentifiés. même la partie publique.</p> <p>Le problème c'est que je ne peux pas utiliser actuellement (bug ? ) un check TCP sur le port 6443 avec le provider numspot.</p> <p>Je patcherai plus tard le healthcheck via un call API pour le mettre à jour.</p> <hr /> <p>Ce fichier contient les définitions des ressources principales que Terraform va créer et gérer sur NumSpot pour notre cluster Talos. On y trouve la création des VMs (Control Plane et Workers) et du Load Balancer nécessaire pour la haute disponibilité et l'accès externe à l'API Kubernetes.</p> <ol> <li> <p><strong><code>resource "numspot_vm" "talos-cp"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> Ici, je définis les machines virtuelles qui serviront de nœuds <strong>Control Plane</strong> pour notre cluster Kubernetes.</li> <li><strong>Comment :</strong> J'utilise une boucle <code>for_each</code> qui s'appuie sur la map <code>controlplanes</code> de notre variable <code>var.node_data</code> (définie dans <code>vars.tf</code>). Pour chaque entrée dans cette map (chaque IP de control plane), Terraform créera une VM.</li> <li><strong>Configuration clé :</strong><ul> <li><code>image_id = "ami-3b18dcca"</code> : J'utilise une image spécifique de NumSpot. <strong>Attention, cet ID (<code>ami-3b18dcca</code>) est l'ID de l'image Talos que nous avons créée manuellement dans la première étape du tuto.</strong> Vous devrez remplacer cet ID par celui de <em>votre</em> image Talos perso dans votre catalogue privé NumSpot.</li> <li><code>type = "ns-eco6-2c8r"</code> : Je choisis ce type d'instance (taille/puissance). Vous pouvez l'adapter selon vos besoins.</li> <li><code>keypair_name = "talos-keypair"</code> : J'associe une paire de clés SSH préexistante nommée <code>talos-keypair</code> à la VM. Même si Talos n'utilise pas SSH, NumSpot peut le requérir ou cela peut être utile pour certaines opérations de bas niveau (très rare avec Talos). Assurez-vous que cette keypair existe dans votre compte NumSpot.</li> <li><code>subnet_id</code> et <code>security_group_ids</code> : J'utilise les informations du VPC/Subnet/Groupe de Sécurité que nous avons récupérées dans <code>data.tf</code>.</li> <li><code>private_ips = [each.key]</code> : C'est ici que j'attribue l'adresse IP privée fixe à chaque VM control plane. L'adresse IP provient directement de la <em>clé</em> de la map <code>var.node_data.controlplanes</code>.</li> <li><code>tags</code>: Je mets un tag "name" sur chaque VM pour l'identifier facilement (ex: <code>talos-cp-10.0.1.234</code>).</li> </ul> </li> </ul> </li> <li> <p><strong><code>resource "numspot_vm" "talos-worker"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> Très similaire au bloc précédent, mais celui-ci crée les machines virtuelles pour les nœuds <strong>Worker</strong> de notre cluster.</li> <li><strong>Comment :</strong> Utilise aussi une boucle <code>for_each</code>, mais cette fois sur la map <code>workers</code> de <code>var.node_data</code>.</li> <li><strong>Configuration clé :</strong> Globalement identique aux control planes (même image, type, keypair, réseau), mais :<ul> <li><code>private_ips = [each.key]</code> : Attribue l'IP privée fixe venant de la clé de la map <code>var.node_data.workers</code>.</li> <li><code>tags</code>: Le tag "name" utilise ici le <code>hostname</code> défini dans la valeur de la map (ex: <code>talos-worker-worker-1</code>).</li> </ul> </li> </ul> </li> <li> <p><strong><code>resource "numspot_load_balancer" "load-balancer"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> Crée un <strong>Load Balancer</strong> réseau (NLB) sur NumSpot.</li> <li><strong>Pourquoi :</strong> Il va répartir le trafic entrant destiné à l'API Kubernetes (sur le port 6443) entre les différentes VMs Control Plane que nous avons créées. C'est essentiel pour la haute disponibilité et pour avoir un point d'entrée unique (<code>vip</code>) pour le cluster.</li> <li><strong>Configuration clé :</strong><ul> <li><code>name = "nlb001"</code> : Je donne un nom fixe au Load Balancer.</li> <li><code>listeners</code>: Je configure l'écouteur pour recevoir du trafic TCP sur le port 6443 et le transférer vers les backends (nos control planes) sur le port 6443 également.</li> <li><code>subnets</code> &amp; <code>security_groups</code>: Je place le LB dans notre sous-réseau et lui associe notre groupe de sécurité (il faut que ce groupe autorise le trafic sur le port 6443).</li> <li><code>backend_vm_ids</code>: C'est ici que je connecte le LB aux VMs control plane. J'utilise une expression <code>for</code> pour récupérer dynamiquement les IDs de toutes les VMs créées par le bloc <code>numspot_vm.talos-cp</code>.</li> <li><code>public_ip</code>: <strong>Note importante :</strong> J'ai commenté cette ligne (<code>// invalide à l'heure actuelle - public_ip = ...</code>). Cela suggère qu'au moment où j'ai écrit ce code, l'assignation directe d'une IP publique via cet attribut n'était pas fonctionnelle ou supportée par le provider NumSpot pour ce type de LB. Le LB sera donc probablement accessible via une IP publique assignée automatiquement ou nécessitera une étape manuelle/supplémentaire pour l'exposition sur Internet si <code>type = "internet-facing"</code> fonctionne comme attendu.</li> <li><code>type = "internet-facing"</code>: Indique que je veux que ce LB soit potentiellement accessible depuis Internet (même si l'IP publique n'est pas explicitement définie ici).</li> <li><code>health_check</code>: Je définis comment le LB vérifie si les control planes sont opérationnels. Il essaie de contacter un endpoint spécifique de l'API Kubernetes (<code>/api/v1/.../cluster-info</code>) sur le port 6443 en HTTPS.</li> </ul> </li> </ul> </li> <li> <p><strong><code>data "numspot_load_balancers" "load-balancer"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> Ce bloc ne <em>crée</em> rien, il <em>lit</em> des informations sur le Load Balancer que nous venons juste de définir dans le bloc <code>resource</code> précédent.</li> <li><strong>Comment :</strong> Il recherche un LB ayant le nom <code>nlb001</code>.</li> <li><strong>Pourquoi :</strong> Souvent, on utilise une source de données comme celle-ci juste après avoir créé une ressource pour récupérer des attributs qui ne sont connus qu'après la création (comme un DNS Name généré automatiquement par NumSpot pour le LB). Le <code>depends_on = [numspot_load_balancer.load-balancer]</code> est crucial : il garantit que Terraform essaiera de lire ces informations <em>seulement après</em> que la création du LB soit terminée. Cela évite les erreurs si on essayait de lire trop tôt. Dans ce code précis, les informations lues ne semblent pas être utilisées immédiatement, mais c'est une bonne pratique de l'avoir si on prévoit d'utiliser des attributs dynamiques du LB plus tard (par exemple dans un fichier d'output).</li> </ul> </li> </ol> <h3>2.5 La configuration du cluster Talos</h3> <ul> <li>Créez un fichier talos-cluster.tf avec le code suivant :</li> </ul> <div class="codehilite"><pre><span></span><code><span class="kr">resource</span><span class="w"> </span><span class="nc">&quot;talos_machine_secrets&quot;</span><span class="w"> </span><span class="nv">&quot;this&quot;</span><span class="w"> </span><span class="p">{}</span> <span class="kr">data</span><span class="w"> </span><span class="nc">&quot;talos_machine_configuration&quot;</span><span class="w"> </span><span class="nv">&quot;controlplane&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">depends_on</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="nv">numspot_load_balancer.load-balancer</span><span class="p">]</span> <span class="w"> </span><span class="na">cluster_name</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">var.cluster_name</span> <span class="w"> </span><span class="na">cluster_endpoint</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;https://10.0.1.230:6443&quot;</span> <span class="w"> </span><span class="na">machine_type</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;controlplane&quot;</span> <span class="w"> </span><span class="na">machine_secrets</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">talos_machine_secrets.this.machine_secrets</span> <span class="p">}</span> <span class="kr">data</span><span class="w"> </span><span class="nc">&quot;talos_machine_configuration&quot;</span><span class="w"> </span><span class="nv">&quot;worker&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">depends_on</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="nv">numspot_load_balancer.load-balancer</span><span class="p">]</span> <span class="w"> </span><span class="na">cluster_name</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">var.cluster_name</span> <span class="w"> </span><span class="na">cluster_endpoint</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;https://10.0.1.230:6443&quot;</span> <span class="w"> </span><span class="na">machine_type</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;worker&quot;</span> <span class="w"> </span><span class="na">machine_secrets</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">talos_machine_secrets.this.machine_secrets</span> <span class="p">}</span> <span class="kr">data</span><span class="w"> </span><span class="nc">&quot;talos_client_configuration&quot;</span><span class="w"> </span><span class="nv">&quot;this&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">cluster_name</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">var.cluster_name</span> <span class="w"> </span><span class="na">client_configuration</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">talos_machine_secrets.this.client_configuration</span> <span class="w"> </span><span class="na">endpoints</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="err">for</span><span class="w"> </span><span class="err">k</span><span class="p">,</span><span class="w"> </span><span class="err">v</span><span class="w"> </span><span class="err">in</span><span class="w"> </span><span class="nv">var.node_data.controlplanes</span><span class="w"> </span><span class="p">:</span><span class="w"> </span><span class="err">k</span><span class="p">]</span> <span class="p">}</span> <span class="kr">resource</span><span class="w"> </span><span class="nc">&quot;talos_machine_configuration_apply&quot;</span><span class="w"> </span><span class="nv">&quot;controlplane&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">client_configuration</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">talos_machine_secrets.this.client_configuration</span> <span class="w"> </span><span class="na">machine_configuration_input</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">data.talos_machine_configuration.controlplane.machine_configuration</span> <span class="w"> </span><span class="na">for_each</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">var.node_data.controlplanes</span> <span class="w"> </span><span class="na">node</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">each.key</span> <span class="w"> </span><span class="na">config_patches</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span> <span class="w"> </span><span class="nf">templatefile</span><span class="p">(</span><span class="s2">&quot;${path.module}/templates/node-configuration.yaml.tmpl&quot;</span><span class="p">,</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">hostname</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">each.value.hostname</span><span class="w"> </span><span class="p">==</span><span class="w"> </span><span class="kt">null</span><span class="w"> </span><span class="p">?</span><span class="w"> </span><span class="nf">format</span><span class="p">(</span><span class="s2">&quot;%s-cp-%s&quot;</span><span class="p">,</span><span class="w"> </span><span class="nv">var.cluster_name</span><span class="p">,</span><span class="w"> </span><span class="nf">index</span><span class="p">(</span><span class="nf">keys</span><span class="p">(</span><span class="nv">var.node_data.controlplanes</span><span class="p">),</span><span class="w"> </span><span class="nv">each.key</span><span class="p">))</span><span class="w"> </span><span class="p">:</span><span class="w"> </span><span class="nv">each.value.hostname</span> <span class="w"> </span><span class="na">install_disk</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">each.value.install_disk</span> <span class="w"> </span><span class="na">vip</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">var.vip</span> <span class="w"> </span><span class="na">public_ip</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">data.numspot_load_balancers.load-balancer.items.0.public_ip</span> <span class="w"> </span><span class="na">dns_name</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">data.numspot_load_balancers.load-balancer.items.0.dns_name</span> <span class="w"> </span><span class="p">}),</span> <span class="w"> </span><span class="nf">file</span><span class="p">(</span><span class="s2">&quot;${path.module}/files/cp-scheduling.yaml&quot;</span><span class="p">),</span> <span class="w"> </span><span class="p">]</span> <span class="p">}</span> <span class="kr">resource</span><span class="w"> </span><span class="nc">&quot;talos_machine_configuration_apply&quot;</span><span class="w"> </span><span class="nv">&quot;worker&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">client_configuration</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">talos_machine_secrets.this.client_configuration</span> <span class="w"> </span><span class="na">machine_configuration_input</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">data.talos_machine_configuration.worker.machine_configuration</span> <span class="w"> </span><span class="na">for_each</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">var.node_data.workers</span> <span class="w"> </span><span class="na">node</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">each.key</span> <span class="w"> </span><span class="na">config_patches</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span> <span class="w"> </span><span class="nf">templatefile</span><span class="p">(</span><span class="s2">&quot;${path.module}/templates/node-configuration.yaml.tmpl&quot;</span><span class="p">,</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">hostname</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">each.value.hostname</span><span class="w"> </span><span class="p">==</span><span class="w"> </span><span class="kt">null</span><span class="w"> </span><span class="p">?</span><span class="w"> </span><span class="nf">format</span><span class="p">(</span><span class="s2">&quot;%s-worker-%s&quot;</span><span class="p">,</span><span class="w"> </span><span class="nv">var.cluster_name</span><span class="p">,</span><span class="w"> </span><span class="nf">index</span><span class="p">(</span><span class="nf">keys</span><span class="p">(</span><span class="nv">var.node_data.workers</span><span class="p">),</span><span class="w"> </span><span class="nv">each.key</span><span class="p">))</span><span class="w"> </span><span class="p">:</span><span class="w"> </span><span class="nv">each.value.hostname</span> <span class="w"> </span><span class="na">install_disk</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">each.value.install_disk</span> <span class="w"> </span><span class="na">vip</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;&quot;</span> <span class="w"> </span><span class="na">public_ip</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">data.numspot_load_balancers.load-balancer.items.0.public_ip</span> <span class="w"> </span><span class="na">dns_name</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">data.numspot_load_balancers.load-balancer.items.0.dns_name</span> <span class="w"> </span><span class="p">})</span> <span class="w"> </span><span class="p">]</span> <span class="p">}</span> <span class="kr">resource</span><span class="w"> </span><span class="nc">&quot;talos_machine_bootstrap&quot;</span><span class="w"> </span><span class="nv">&quot;this&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">depends_on</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="nv">talos_machine_configuration_apply.controlplane</span><span class="p">]</span> <span class="w"> </span><span class="na">client_configuration</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">talos_machine_secrets.this.client_configuration</span> <span class="w"> </span><span class="na">node</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="err">for</span><span class="w"> </span><span class="err">k</span><span class="p">,</span><span class="w"> </span><span class="err">v</span><span class="w"> </span><span class="err">in</span><span class="w"> </span><span class="nv">var.node_data.controlplanes</span><span class="w"> </span><span class="p">:</span><span class="w"> </span><span class="err">k</span><span class="p">][</span><span class="m">0</span><span class="p">]</span> <span class="p">}</span> <span class="kr">resource</span><span class="w"> </span><span class="nc">&quot;talos_cluster_kubeconfig&quot;</span><span class="w"> </span><span class="nv">&quot;this&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">depends_on</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="nv">talos_machine_bootstrap.this</span><span class="p">]</span> <span class="w"> </span><span class="na">client_configuration</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">talos_machine_secrets.this.client_configuration</span> <span class="w"> </span><span class="na">node</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">[</span><span class="err">for</span><span class="w"> </span><span class="err">k</span><span class="p">,</span><span class="w"> </span><span class="err">v</span><span class="w"> </span><span class="err">in</span><span class="w"> </span><span class="nv">var.node_data.controlplanes</span><span class="w"> </span><span class="p">:</span><span class="w"> </span><span class="err">k</span><span class="p">][</span><span class="m">0</span><span class="p">]</span> <span class="p">}</span> <span class="kr">resource</span><span class="w"> </span><span class="nc">&quot;local_file&quot;</span><span class="w"> </span><span class="nv">&quot;talosconfig&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">content</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">data.talos_client_configuration.this.talos_config</span> <span class="w"> </span><span class="na">filename</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;${path.module}/${var.cluster_name}/talosconfig&quot;</span> <span class="p">}</span> <span class="kr">resource</span><span class="w"> </span><span class="nc">&quot;local_file&quot;</span><span class="w"> </span><span class="nv">&quot;kubeconfig&quot;</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="na">content</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nv">talos_cluster_kubeconfig.this.kubeconfig_raw</span> <span class="w"> </span><span class="na">filename</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">&quot;${path.module}/${var.cluster_name}/kubeconfig&quot;</span> <span class="p">}</span> </code></pre></div> <p>Ce fichier est entièrement dédié à l'interaction avec Talos lui-même, une fois que les VMs de base sont (ou sont en train d'être) créées par infra.tf. J'utilise ici le provider Terraform siderolabs/talos pour générer les configurations spécifiques à Talos, les appliquer aux nœuds, et finalement bootstrapper le cluster Kubernetes. C'est ici que la "magie" Talos opère.</p> <ol> <li> <p><strong><code>resource "talos_machine_secrets" "this"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> C'est la première étape essentielle pour Talos. Je demande au provider de générer tous les secrets cryptographiques nécessaires (certificats PKI, clés) pour sécuriser le cluster et les communications entre les nœuds et avec le client (<code>talosctl</code>).</li> <li><strong>Pourquoi :</strong> Talos est sécurisé par défaut et repose sur mTLS. Cette ressource gère toute la complexité de la génération de cette PKI.</li> </ul> </li> <li> <p><strong><code>data "talos_machine_configuration" "controlplane"</code></strong> et <strong><code>data "talos_machine_configuration" "worker"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> Ces blocs <em>ne créent rien</em> sur les machines, ils utilisent des <em>data sources</em> du provider Talos pour générer les <strong>fichiers de configuration de base</strong> pour les control planes et les workers, mais <em>en mémoire</em>. C'est l'équivalent de ce que <code>talosctl gen config</code> ferait, mais intégré à Terraform.</li> <li><strong>Pourquoi :</strong> J'ai besoin d'une configuration standard pour chaque type de nœud, basée sur le nom du cluster (<code>var.cluster_name</code>), l'endpoint (j'utilise ici directement la VIP <code>10.0.1.230</code> définie dans <code>vars.tf</code> – assurez-vous qu'elle correspond à votre <code>var.vip</code>!), le type de machine (<code>controlplane</code> ou <code>worker</code>) et les secrets générés juste avant.</li> <li><strong>Dépendance :</strong> J'ai mis <code>depends_on = [numspot_load_balancer.load-balancer]</code> pour m'assurer que la génération de cette config (même si elle n'utilise pas <em>directement</em> le LB <em>ici</em>) n'ait lieu qu'après la création du LB, car les étapes suivantes <em>vont</em> utiliser les informations du LB.</li> </ul> </li> <li> <p><strong><code>data "talos_client_configuration" "this"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> Génère, toujours en mémoire, la configuration client (<code>talosconfig</code>) nécessaire pour que <code>talosctl</code> (et le provider Terraform lui-même) puisse communiquer avec les nœuds Talos.</li> <li><strong>Pourquoi :</strong> Pour appliquer les configurations et lancer le bootstrap, le provider a besoin de savoir comment s'authentifier auprès des nœuds Talos.</li> <li><strong>Comment :</strong> J'utilise le nom du cluster, la partie "client" des secrets générés, et je lui fournis la liste des IPs des control planes comme points d'accès initiaux (<code>endpoints</code>).</li> </ul> </li> <li> <p><strong><code>resource "talos_machine_configuration_apply" "controlplane"</code></strong> et <strong><code>resource "talos_machine_configuration_apply" "worker"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> C'est l'étape où j'applique <strong>effectivement</strong> la configuration sur chaque nœud (VM). Le provider Terraform se connecte à l'API Talos de chaque machine (sur le port 50000) en utilisant la configuration client générée, et lui envoie sa configuration.</li> <li><strong>Comment :</strong> J'utilise <code>for_each</code> pour boucler sur les IPs définies dans <code>var.node_data</code> (comme pour la création des VMs). Pour chaque nœud (<code>node = each.key</code>), je prends la configuration de base générée (<code>machine_configuration_input</code>) et j'y ajoute des <strong>patchs</strong> (<code>config_patches</code>).</li> <li><strong>Les Patchs (<code>config_patches</code>) :</strong> C'est là que je personnalise la configuration pour chaque nœud spécifique :<ul> <li>J'utilise <code>templatefile</code> pour lire un fichier modèle (<code>templates/node-configuration.yaml.tmpl</code>) et y injecter des valeurs dynamiques :<ul> <li>Le <code>hostname</code> : soit celui défini dans <code>var.node_data</code>, soit un nom généré automatiquement (ex: <code>numspot-talos-cp-0</code>).</li> <li>Le disque d'installation (<code>install_disk</code>) pris depuis <code>var.node_data</code>.</li> <li>La VIP (<code>var.vip</code>) pour les control planes (vide pour les workers).</li> <li>L'IP publique (<code>public_ip</code>) et le nom DNS (<code>dns_name</code>) récupérés depuis le Load Balancer NumSpot (via la source de données <code>data.numspot_load_balancers.load-balancer</code> que j'avais définie dans <code>infra.tf</code> - c'est pour ça que la dépendance et la data source étaient importantes !).</li> </ul> </li> <li>Pour les control planes, j'ajoute aussi un patch statique (<code>files/cp-scheduling.yaml</code>), qui contient probablement des configurations spécifiques aux CPs (peut-être pour autoriser l'exécution de pods dessus, ou définir des taints/labels).</li> </ul> </li> <li><strong>Important :</strong> Ces blocs nécessitent que les fichiers <code>templates/node-configuration.yaml.tmpl</code> et <code>files/cp-scheduling.yaml</code> existent aux chemins indiqués.</li> </ul> </li> <li> <p><strong><code>resource "talos_machine_bootstrap" "this"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> Une fois que tous les control planes ont leur configuration appliquée, je déclenche le processus de bootstrap sur <strong>un seul</strong> des control planes. C'est l'équivalent de la commande <code>talosctl bootstrap</code>.</li> <li><strong>Pourquoi :</strong> Cette étape initialise le cluster etcd et démarre réellement le control plane Kubernetes.</li> <li><strong>Comment :</strong> Je cible le premier control plane de ma liste (<code>[for k, v in var.node_data.controlplanes : k][0]</code>).</li> <li><strong>Dépendance :</strong> <code>depends_on = [talos_machine_configuration_apply.controlplane]</code> garantit que je n'essaie pas de bootstrapper avant que les CPs soient configurés.</li> </ul> </li> <li> <p><strong><code>resource "talos_cluster_kubeconfig" "this"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> Une fois le cluster bootstrappé, je demande à Talos (via le provider et en me connectant au premier control plane) de générer le fichier <code>kubeconfig</code> pour pouvoir interagir avec le cluster Kubernetes via <code>kubectl</code>.</li> <li><strong>Pourquoi :</strong> C'est le sésame pour utiliser notre nouveau cluster !</li> <li><strong>Dépendance :</strong> <code>depends_on = [talos_machine_bootstrap.this]</code> assure que le bootstrap est terminé.</li> </ul> </li> <li> <p><strong><code>resource "local_file" "talosconfig"</code></strong> et <strong><code>resource "local_file" "kubeconfig"</code></strong></p> <ul> <li><strong>Ce que ça fait :</strong> Je prends les configurations client Talos (<code>talosconfig</code>) et Kubernetes (<code>kubeconfig</code>) qui ont été générées par les ressources précédentes, et je les écris dans des fichiers locaux sur la machine où Terraform est exécuté.</li> <li><strong>Pourquoi :</strong> Pour que vous puissiez facilement utiliser <code>talosctl --talosconfig=./numspot-talos/talosconfig ...</code> et <code>kubectl --kubeconfig=./numspot-talos/kubeconfig ...</code> après l'exécution de Terraform.</li> <li><strong>Comment :</strong> Je les sauvegarde dans un sous-dossier portant le nom du cluster (ex: <code>./numspot-talos/</code>).</li> </ul> </li> </ol> <hr /> <h2>3. Let's GO !</h2> <h3>3.1 Terraform init</h3> <p>Lancez la commande :</p> <div class="codehilite"><pre><span></span><code>terraform<span class="w"> </span>init </code></pre></div> <p>La commande <code>terraform init</code> est la <strong>première étape fondamentale</strong> que vous devez exécuter lorsque vous commencez à travailler avec une nouvelle configuration Terraform ou lorsque vous modifiez certains aspects fondamentaux d'une configuration existante (comme les fournisseurs, les modules ou le backend).</p> <p>Son rôle principal est de <strong>préparer ton répertoire de travail</strong> pour que Terraform puisse exécuter les autres commandes (<code>plan</code>, <code>apply</code>, <code>destroy</code>, etc.).</p> <p>Voici ce que <code>terraform init</code> fait exactement :</p> <ol> <li> <p><strong>Initialisation du Backend :</strong></p> <ul> <li>Terraform lit le bloc <code>backend</code> (s'il existe) dans ta configuration (généralement dans un fichier <code>terraform.tf</code> ou <code>providers.tf</code>).</li> <li>Il configure la manière dont Terraform va stocker et accéder au <strong>fichier d'état</strong> (<code>terraform.tfstate</code>). Ce fichier est crucial car il contient la correspondance entre tes ressources Terraform et l'infrastructure réelle.</li> <li>Si aucun backend n'est spécifié, il utilise le backend local par défaut (le fichier <code>terraform.tfstate</code> est stocké dans le même répertoire).</li> <li>Si un backend distant est configuré (comme S3, Azure Blob Storage, Terraform Cloud, etc.), <code>init</code> vérifie la configuration et établit la connexion.</li> </ul> </li> <li> <p><strong>Téléchargement des Fournisseurs (Providers) :</strong></p> <ul> <li>Terraform analyse tes fichiers de configuration (<code>.tf</code>) pour identifier tous les fournisseurs requis, déclarés dans les blocs <code>required_providers</code> (comme <code>numspot/numspot</code> ou <code>siderolabs/talos</code> dans tes exemples).</li> <li>Il se connecte au <strong>Registre Terraform</strong> (ou à une autre source spécifiée) pour trouver et télécharger le code exécutable (le plugin) de chaque fournisseur nécessaire, en respectant les contraintes de version que vous avez spécifiées (<code>version = "&gt;= 1.0"</code>).</li> <li>Ces plugins sont stockés localement dans un sous-répertoire caché nommé <code>.terraform/providers</code>. C'est ce code qui permet à Terraform de communiquer avec les API des différents services (NumSpot, Talos, AWS, etc.).</li> </ul> </li> <li> <p><strong>Installation des Modules :</strong></p> <ul> <li>Si ta configuration utilise des <strong>modules</strong> (référencés via des blocs <code>module</code>), <code>terraform init</code> va les télécharger ou les copier.</li> <li>Les modules peuvent provenir de différentes sources :<ul> <li>Registre Terraform</li> <li>Dépôts Git (comme GitHub)</li> <li>Chemins locaux sur ton disque dur</li> <li>Archives HTTP</li> <li>Buckets S3, GCS...</li> </ul> </li> <li>Les modules téléchargés sont également stockés dans le répertoire <code>.terraform/modules</code>.</li> </ul> </li> <li> <p><strong>Initialisation des Modules Enfants :</strong></p> <ul> <li>Si les modules que vous utilisez contiennent eux-mêmes des blocs <code>required_providers</code> ou référencent d'autres modules, <code>terraform init</code> s'occupe de ces dépendances de manière récursive.</li> </ul> </li> </ol> <p><strong>Quand faut-il exécuter <code>terraform init</code> ?</strong></p> <ul> <li>La <strong>première fois</strong> que vous clonez ou crées une configuration Terraform.</li> <li>Chaque fois que vous <strong>ajoutez ou supprimes un fournisseur</strong>.</li> <li>Chaque fois que vous <strong>ajoutez ou supprimes un module</strong>.</li> <li>Chaque fois que vous <strong>modifiez la configuration du backend</strong>.</li> <li>Il est souvent sûr et recommandé de l'exécuter si vous n'êtes pas sûr de l'état de ton répertoire de travail.</li> </ul> <p>C'est une commande <strong>idempotente</strong>, ce qui signifie que vous ouvez l'exécuter plusieurs fois sans effet négatif ; elle ne refera que ce qui est nécessaire.</p> <h3>3.2 Terraform apply</h3> <p>lancez la commande </p> <div class="codehilite"><pre><span></span><code>terraform<span class="w"> </span>apply </code></pre></div> <p>La commande <code>terraform apply</code> est l'étape où vous <strong>concrétisez les changements</strong> décrits dans ta configuration Terraform. Après avoir potentiellement vérifié ce qui allait se passer avec <code>terraform plan</code>, <code>terraform apply</code> est la commande qui <strong>applique réellement ces changements à ton infrastructure réelle</strong> (sur NumSpot, Talos, etc.).</p> <p>Voici ce que <code>terraform apply</code> fait en détail :</p> <ol> <li> <p><strong>Lecture de la Configuration :</strong> Comme <code>plan</code>, il lit tous tes fichiers <code>.tf</code> dans le répertoire courant pour comprendre l'état désiré de ton infrastructure.</p> </li> <li> <p><strong>Lecture de l'État Existant :</strong> Il lit le fichier d'état (<code>terraform.tfstate</code>, qu'il soit local ou distant via un backend) pour savoir quelles ressources Terraform gère déjà et comment elles sont configurées selon la <em>dernière</em> exécution réussie.</p> </li> <li> <p><strong>Génération d'un Plan d'Exécution :</strong> Il compare l'état désiré (issu de ta configuration) avec l'état actuel (issu du fichier d'état et potentiellement en interrogeant les fournisseurs pour vérifier l'état réel des ressources). Sur la base de cette comparaison, il détermine les actions nécessaires :</p> <ul> <li><strong>Créer</strong> de nouvelles ressources qui sont dans ta configuration mais pas dans l'état.</li> <li><strong>Mettre à jour</strong> des ressources existantes dont la configuration a changé.</li> <li><strong>Détruire</strong> des ressources qui sont dans l'état mais ne sont plus dans ta configuration.</li> </ul> </li> <li> <p><strong>Affichage du Plan et Demande de Confirmation :</strong></p> <ul> <li>Terraform te <strong>montre le plan d'exécution</strong> qu'il vient de générer (exactement comme le ferait <code>terraform plan</code>). Il liste toutes les ressources qui seront créées, modifiées ou détruites, avec les détails des changements.</li> <li>Ensuite, il te <strong>demande explicitement de confirmer</strong> que vous souhaitez appliquer ce plan en tapant <code>yes</code>. C'est une étape de sécurité cruciale pour éviter des modifications accidentelles.</li> </ul> </li> <li> <p><strong>Exécution des Actions (si confirmé) :</strong></p> <ul> <li>Si vous tapez <code>yes</code>, Terraform commence à exécuter les actions listées dans le plan, dans l'ordre correct en respectant les dépendances entre les ressources.</li> <li>Il communique avec les <strong>fournisseurs</strong> (NumSpot, Talos, etc.) via leurs API pour leur demander de créer, modifier ou supprimer les ressources réelles.</li> <li>Il affiche la progression de ces opérations en temps réel.</li> </ul> </li> <li> <p><strong>Mise à Jour du Fichier d'État :</strong></p> <ul> <li>Au fur et à mesure que les opérations réussissent, Terraform <strong>met à jour le fichier d'état (<code>terraform.tfstate</code>)</strong> pour refléter le nouvel état de l'infrastructure. Par exemple, si une nouvelle VM est créée, son ID unique fourni par NumSpot sera enregistré dans le fichier d'état. Cette mise à jour est <em>essentielle</em> pour que les prochaines exécutions de Terraform sachent ce qui existe réellement.</li> </ul> </li> <li> <p><strong>Affichage des Sorties (Outputs) :</strong></p> <ul> <li>Une fois toutes les actions terminées avec succès, Terraform affiche les valeurs des éventuelles <strong>sorties</strong> (<code>output</code>) que vous avez définies dans ta configuration (comme le chemin du <code>kubeconfig</code> ou l'IP du load balancer dans tes exemples).</li> </ul> </li> </ol> <p>C'est la commande principale pour <strong>gérer le cycle de vie de ton infrastructure</strong> avec Terraform.</p> <p><strong>Option importante :</strong> * <code>terraform apply -auto-approve</code> : Permet de sauter l'étape de confirmation manuelle (<code>yes</code>). <strong>À utiliser avec prudence</strong>, principalement dans des scripts d'automatisation (CI/CD) où un <code>terraform plan</code> a déjà été validé au préalable.</p> <h3>3.3 Utilisation du cluster</h3> <p>L'apply est très rapide, par contre, la configuration sous-jacente de Talos peut être assez longue.</p> <p>Donc comment contrôler que tout va bien !</p> <ul> <li>Dashboard Talos </li> </ul> <p>Dans le répertoire <code>numspot-talos</code> vous avez ces fichiers</p> <ul> <li>kubeconfig </li> <li>talosconfig</li> </ul> <p>Exécutez la commande :</p> <div class="codehilite"><pre><span></span><code>talosctl<span class="w"> </span>--talosconfig<span class="w"> </span>numspot-talos/talosconfig<span class="w"> </span>dashboard<span class="w"> </span>-n<span class="w"> </span><span class="m">10</span>.0.1.234<span class="w"> </span>-e<span class="w"> </span><span class="m">10</span>.0.1.234 </code></pre></div> <p>Vous pouvez faire cela sur l'ensemble des nœuds du cluster</p> <p><center> <image src="/images/numspot/t1.png"> </center></p> <ul> <li>Accès à kubernetes</li> </ul> <p>Rien de plus simple !</p> <p>Exécutez la commande :</p> <div class="codehilite"><pre><span></span><code><span class="nb">export</span><span class="w"> </span><span class="nv">KUBECONFIG</span><span class="o">=</span>numspot-talos/kubeconfig kubectl<span class="w"> </span>get<span class="w"> </span>nodes<span class="w"> </span> </code></pre></div> <div class="codehilite"><pre><span></span><code>kubectl get nodes NAME STATUS ROLES AGE VERSION numspot-talos-cp-0 Ready control-plane 3d1h v1.32.0 numspot-talos-cp-1 Ready control-plane 3d1h v1.32.0 numspot-talos-cp-2 Ready control-plane 3d1h v1.32.0 worker-1 Ready &lt;none&gt; 3d1h v1.32.0 worker-2 Ready &lt;none&gt; 3d1h v1.32.0 </code></pre></div> <p>Si vous souhaitez utiliser le cluster avec l'API publique de votre loadbalancer </p> <p>Modifiez dans le kubeconfig <code>server: https://10.0.1.230:6443</code> en server: https://nlb001-CXXXX.cloudgouv-eu-west-1.lbu.outscale.com:6443</p> <p>Retrouvez l'URL dans le portail Numspot </p> <p>Pour que ça fonctionne il faut patcher le healthcheck du loadbalancer pour faire un ping TCP sur le port 6443.</p> <p>Créez un script update-lb.sh avec le contenu suivant :</p> <div class="codehilite"><pre><span></span><code><span class="ch">#!/bin/bash</span> <span class="c1"># Il faudra adapter si vous avez plusieurs LB</span> <span class="nb">source</span><span class="w"> </span>auth.sh <span class="nv">LBID</span><span class="o">=</span><span class="k">$(</span>curl<span class="w"> </span>-s<span class="w"> </span><span class="s1">&#39;https://api.cloudgouv-eu-west-1.numspot.com/compute/spaces/A MODIFIER/loadBalancers&#39;</span><span class="w"> </span><span class="se">\</span> <span class="w"> </span>--request<span class="w"> </span>GET<span class="w"> </span><span class="se">\</span> <span class="w"> </span>--header<span class="w"> </span><span class="s1">&#39;Content-Type: application/json&#39;</span><span class="w"> </span><span class="se">\</span> <span class="w"> </span>--header<span class="w"> </span><span class="s2">&quot;Authorization: Bearer </span><span class="si">${</span><span class="nv">ACCESS_TOKEN</span><span class="si">}</span><span class="s2">&quot;</span><span class="w"> </span><span class="p">|</span><span class="w"> </span>jq<span class="w"> </span>-r<span class="w"> </span><span class="s1">&#39;.items[0].name&#39;</span><span class="k">)</span> curl<span class="w"> </span>-s<span class="w"> </span><span class="s2">&quot;https://api.cloudgouv-eu-west-1.numspot.com/compute/spaces/A MODIFIER/</span><span class="nv">$LBID</span><span class="s2">&quot;</span><span class="w"> </span><span class="se">\</span> <span class="w"> </span>--request<span class="w"> </span>PUT<span class="w"> </span><span class="se">\</span> <span class="w"> </span>--header<span class="w"> </span><span class="s1">&#39;Content-Type: application/json&#39;</span><span class="w"> </span><span class="se">\</span> <span class="w"> </span>--header<span class="w"> </span><span class="s2">&quot;Authorization: Bearer </span><span class="si">${</span><span class="nv">ACCESS_TOKEN</span><span class="si">}</span><span class="s2">&quot;</span><span class="w"> </span><span class="se">\</span> <span class="w"> </span>--data<span class="w"> </span><span class="s1">&#39;{</span> <span class="s1"> &quot;healthCheck&quot;: {</span> <span class="s1"> &quot;checkInterval&quot;: 10,</span> <span class="s1"> &quot;healthyThreshold&quot;: 3,</span> <span class="s1"> &quot;port&quot;: 6443,</span> <span class="s1"> &quot;protocol&quot;: &quot;TCP&quot;,</span> <span class="s1"> &quot;timeout&quot;: 5,</span> <span class="s1"> &quot;unhealthyThreshold&quot;: 5</span> <span class="s1"> }</span> <span class="s1">}&#39;</span> </code></pre></div> <hr /> <h2>4. Améliorations</h2> <p><strong>Plein de choses à prévoir !</strong></p> <p><strong>Ce POC est un quick and dirty pour montrer qu'il est tout à fait possible de créer son propre cluster Talos sur Numspot.</strong></p> <p><strong>Il faudrait retravailler les configurations Terraform pour variabiliser les différents ID passés "en dur" !</strong></p> <hr /> <h2>5. Conclusions</h2> <p>​NumSpot continue de gagner en maturité, offrant des solutions cloud souveraines de plus en plus robustes et adaptées aux besoins des entreprises. La plateforme propose une interface web intuitive, le portail, qui permet de gérer les ressources cloud de manière centralisée et sécurisée. </p> <p>Ce portail est conçu pour évoluer progressivement, intégrant de nouvelles fonctionnalités d'observabilité et de gestion des opérations afin de fournir une vue unifiée des services déployés.</p> <p>Par ailleurs, NumSpot adopte une approche « Infrastructure as Code » (IaC), offrant des interfaces standardisées compatibles avec des outils du marché tels que Terraform. </p> <p>Cette compatibilité permet aux ingénieurs de définir et de gérer l'infrastructure informatique à l'aide de fichiers de script ou de code, facilitant ainsi l'automatisation des actions sur le cloud</p> <p>Cependant, bien que ces avancées soient prometteuses, il est important de noter que le portail et le provider Terraform de NumSpot nécessitent encore des enrichissements pour exploiter pleinement toutes les fonctionnalités de l'API.</p>2025-04-02T10:00:00+02:002025-04-02T10:00:00+02:00Hervé Leclerctag:blogppr.alterway.fr,2025-04-02:/maitriser-laffinite-et-lanti-affinite-podnode.html

<p>Kubernetes : Maîtriser l'Affinité et l'Anti-Affinité Pod/Node</p>

<h1>Kubernetes : Maîtriser l'Affinité et l'Anti-Affinité Pod/Node</h1> <p>Kubernetes est un formidable orchestrateur, mais par défaut, son scheduler place les pods là où il y a des ressources disponibles, sans forcément prendre en compte des contraintes plus fines. </p> <p>C'est là qu'interviennent les mécanismes d'<strong>Affinité</strong> et d'<strong>Anti-Affinité</strong>, des outils puissants pour influencer la décision du scheduler et placer vos pods de manière plus intelligente.</p> <p>Dans cet article, nous allons démystifier ces concepts, en expliquant simplement comment ils fonctionnent au niveau des Nœuds (Nodes) et des Pods, avec des exemples concrets et des cas d'usage.</p> <h2>Pourquoi aller au-delà du Scheduling par Défaut ?</h2> <p>Le scheduler de Kubernetes fait un bon travail pour répartir la charge, mais parfois, vous avez besoin de plus :</p> <ul> <li> <p><strong>Performance :</strong> Placer un pod applicatif près de sa base de données ou de son cache pour réduire la latence réseau.</p> </li> <li> <p><strong>Haute Disponibilité (HA) :</strong> S'assurer que les réplikas d'une application critique ne tournent pas tous sur la même machine physique (ou dans la même zone de disponibilité) pour éviter un point unique de défaillance (SPOF).</p> </li> <li> <p><strong>Contraintes Matérielles/Logicielles :</strong> Forcer un pod à tourner sur un nœud disposant d'un matériel spécifique (GPU, SSD rapide) ou d'une licence particulière.</p> </li> <li> <p><strong>Isolation :</strong> Éviter que des pods très consommateurs en ressources ne se retrouvent sur le même nœud et ne s'impactent mutuellement.</p> </li> <li> <p><strong>Réglementation/Localisation :</strong> Contraindre des pods à s'exécuter dans une région géographique spécifique.</p> </li> </ul> <p>C'est pour répondre à ces besoins que l'Affinité et l'Anti-Affinité existent.</p> <h2>Comprendre les Concepts Clés</h2> <ul> <li> <p><strong>Affinité (Affinity) :</strong> Règle qui <em>attire</em> des pods vers certaines cibles (nœuds ou autres pods). "Je <em>veux</em> tourner ici, ou près de ce pod."</p> </li> <li> <p><strong>Anti-Affinité (Anti-Affinity) :</strong> Règle qui <em>repousse</em> des pods de certaines cibles. "Je <em>ne veux pas</em> tourner ici, ou près de ce pod."</p> </li> <li> <p><strong>Niveau Node :</strong> Les règles concernent les caractéristiques des nœuds (labels).</p> </li> <li> <p><strong>Niveau Pod :</strong> Les règles concernent la présence d'autres pods sur les nœuds.</p> </li> <li> <p><strong>Labels &amp; Selectors :</strong> Le cœur du système. Les nœuds et les pods sont identifiés par des labels (paires clé/valeur), et les règles d'affinité/anti-affinité utilisent des selectors pour cibler ces labels.</p> </li> <li> <p><strong><code>topologyKey</code> :</strong> Utilisé pour l'affinité/anti-affinité de pods. Définit le "domaine" de la règle : est-ce que les pods doivent être sur le <em>même nœud</em> (<code>kubernetes.io/hostname</code>), dans la <em>même zone</em> (<code>topology.kubernetes.io/zone</code>), ou dans la <em>même région</em> (<code>topology.kubernetes.io/region</code>) ?</p> </li> <li> <p><strong>Types de Règles :</strong></p> <ul> <li> <p><code>requiredDuringSchedulingIgnoredDuringExecution</code> : Règle <strong>stricte</strong>. Le pod ne sera <em>pas</em> schedulé si la règle ne peut être satisfaite. Si les conditions changent <em>après</em> le scheduling (ex: label de nœud modifié), le pod continue de tourner (IgnoredDuringExecution). C'est la plus courante.</p> </li> <li> <p><code>preferredDuringSchedulingIgnoredDuringExecution</code> : Règle <strong>préférentielle</strong> (soft). Le scheduler <em>essaiera</em> de satisfaire la règle, mais placera le pod ailleurs si ce n'est pas possible. Un poids (<code>weight</code>, entre 1 et 100) permet de prioriser plusieurs règles préférentielles.</p> </li> </ul> </li> </ul> <p><em>(Note : Il existe aussi <code>requiredDuringSchedulingRequiredDuringExecution</code>, mais il est moins courant et peut causer des évictions de pods si les conditions changent, ce qui peut être perturbateur).</em></p> <hr /> <h2>1. Affinité de Nœud (Node Affinity)</h2> <p><center> <image src="/images/affantiaff/node-affinity.png"> </center></p> <p><strong>Objectif :</strong> Attirer un pod vers des nœuds ayant des caractéristiques spécifiques (labels).</p> <p><strong>Syntaxe :</strong> Se configure dans le <code>spec.affinity.nodeAffinity</code> du Pod.</p> <div class="codehilite"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">v1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Pod</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">mon-pod-rapide</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">affinity</span><span class="p">:</span> <span class="w"> </span><span class="nt">nodeAffinity</span><span class="p">:</span> <span class="w"> </span><span class="c1"># Règle STRICTE</span> <span class="w"> </span><span class="nt">requiredDuringSchedulingIgnoredDuringExecution</span><span class="p">:</span> <span class="w"> </span><span class="nt">nodeSelectorTerms</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">matchExpressions</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">key</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">disktype</span><span class="w"> </span><span class="c1"># Le label du nœud</span> <span class="w"> </span><span class="nt">operator</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">In</span><span class="w"> </span><span class="c1"># L&#39;opérateur (In, NotIn, Exists, DoesNotExist, Gt, Lt)</span> <span class="w"> </span><span class="nt">values</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ssd</span><span class="w"> </span><span class="c1"># La valeur recherchée</span> <span class="w"> </span><span class="c1"># Règle PRÉFÉRENTIELLE</span> <span class="w"> </span><span class="nt">preferredDuringSchedulingIgnoredDuringExecution</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">weight</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">50</span><span class="w"> </span><span class="c1"># Poids de la préférence (1-100)</span> <span class="w"> </span><span class="nt">preference</span><span class="p">:</span> <span class="w"> </span><span class="nt">matchExpressions</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">key</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">topology.kubernetes.io/zone</span> <span class="w"> </span><span class="nt">operator</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">In</span> <span class="w"> </span><span class="nt">values</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">eu-west-1a</span><span class="w"> </span><span class="c1"># Préfère cette zone</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">weight</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">30</span> <span class="w"> </span><span class="nt">preference</span><span class="p">:</span> <span class="w"> </span><span class="nt">matchExpressions</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">key</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">topology.kubernetes.io/zone</span> <span class="w"> </span><span class="nt">operator</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">In</span> <span class="w"> </span><span class="nt">values</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">eu-west-1b</span><span class="w"> </span><span class="c1"># Sinon, préfère celle-ci</span> <span class="w"> </span><span class="nt">containers</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">mon-conteneur</span> <span class="w"> </span><span class="nt">image</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">nginx</span> </code></pre></div> <p><strong>Explication des Exemples :</strong></p> <ol> <li><strong><code>required...</code> :</strong> Ce pod <strong>doit</strong> être placé sur un nœud ayant le label <code>disktype=ssd</code>. Si aucun nœud ne correspond, le pod restera en attente (Pending).</li> <li><strong><code>preferred...</code> :</strong> Le scheduler <strong>préférera</strong> (avec un poids de 50) placer le pod sur un nœud dans la zone <code>eu-west-1a</code>. S'il ne peut pas, il essaiera (avec un poids de 30) la zone <code>eu-west-1b</code>. S'il ne peut toujours pas, il le placera sur n'importe quel autre nœud disponible répondant à la règle <code>required</code>.</li> </ol> <p><strong>Schéma Conceptuel :</strong></p> <div class="codehilite"><pre><span></span><code> Pod (veut disktype=ssd) ─────► Node 1 (disktype=ssd) [OK] │ └─X──► Node 2 (disktype=hdd) [Ignoré par &#39;required&#39;] Pod (préfère zone=a) ───(Poids 50)───► Node 3 (zone=a) [Choix préféré] │ ───(Poids 30)───► Node 4 (zone=b) [Second choix] │ ───(Poids 0)────► Node 5 (zone=c) [Dernier recours] </code></pre></div> <p><strong>Cas d'Usage :</strong></p> <ul> <li> <p>Placer des pods nécessitant des I/O rapides sur des nœuds avec SSD (<code>disktype=ssd</code>).</p> </li> <li> <p>Placer des pods nécessitant des GPU sur des nœuds équipés (<code>hardware=gpu-tesla-v100</code>).</p> </li> <li> <p>Contraindre des pods à une zone ou région spécifique pour des raisons de latence ou de conformité (<code>topology.kubernetes.io/zone=us-east-1</code>).</p> </li> <li> <p>Utiliser des nœuds avec des licences logicielles spécifiques.</p> </li> </ul> <hr /> <h2>2. Anti-Affinité de Nœud (Node Anti-Affinity)</h2> <p><center> <image src="/images/affantiaff/node-anti-affinity.png"> </center></p> <p><strong>Objectif :</strong> Empêcher un pod d'être schedulé sur des nœuds ayant certaines caractéristiques.</p> <p><strong>Note importante :</strong> Il n'existe pas de section <code>nodeAntiAffinity</code> dédiée. L'anti-affinité de nœud est réalisée en utilisant <code>nodeAffinity</code> avec les opérateurs <code>NotIn</code> ou <code>DoesNotExist</code>.</p> <p><strong>Syntaxe :</strong> Toujours dans <code>spec.affinity.nodeAffinity</code>.</p> <div class="codehilite"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">v1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Pod</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">pod-sans-gpu</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">affinity</span><span class="p">:</span> <span class="w"> </span><span class="nt">nodeAffinity</span><span class="p">:</span> <span class="w"> </span><span class="nt">requiredDuringSchedulingIgnoredDuringExecution</span><span class="p">:</span> <span class="w"> </span><span class="nt">nodeSelectorTerms</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">matchExpressions</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">key</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">hardware</span><span class="w"> </span><span class="c1"># Le label du nœud</span> <span class="w"> </span><span class="nt">operator</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">DoesNotExist</span><span class="w"> </span><span class="c1"># Ne doit PAS avoir ce label</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">matchExpressions</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">key</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">gpu-type</span><span class="w"> </span><span class="c1"># Ou, si le label existe...</span> <span class="w"> </span><span class="nt">operator</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">NotIn</span><span class="w"> </span><span class="c1"># Sa valeur ne doit PAS être celles-ci</span> <span class="w"> </span><span class="nt">values</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">nvidia-a100</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">nvidia-v100</span> <span class="w"> </span><span class="nt">preferredDuringSchedulingIgnoredDuringExecution</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">weight</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">80</span> <span class="w"> </span><span class="nt">preference</span><span class="p">:</span> <span class="w"> </span><span class="nt">matchExpressions</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">key</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">maintenance</span><span class="w"> </span><span class="c1"># Label indiquant une maintenance prévue</span> <span class="w"> </span><span class="nt">operator</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">DoesNotExist</span><span class="w"> </span><span class="c1"># Préfère éviter les nœuds en maintenance</span> <span class="w"> </span><span class="nt">containers</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">mon-conteneur</span> <span class="w"> </span><span class="nt">image</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">busybox</span> <span class="w"> </span><span class="nt">command</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">[</span><span class="s">&quot;sleep&quot;</span><span class="p p-Indicator">,</span><span class="w"> </span><span class="s">&quot;3600&quot;</span><span class="p p-Indicator">]</span> </code></pre></div> <p><strong>Explication des Exemples :</strong></p> <ol> <li><strong><code>required...</code> :</strong> Ce pod <strong>ne doit pas</strong> être placé sur un nœud ayant le label <code>hardware</code> (quelque soit sa valeur) OU sur un nœud dont le label <code>gpu-type</code> a la valeur <code>nvidia-a100</code> ou <code>nvidia-v100</code>. Utile si le pod n'a pas besoin de GPU et que vous voulez réserver ces nœuds coûteux.</li> <li><strong><code>preferred...</code> :</strong> Le scheduler <strong>évitera</strong> (avec un poids élevé de 80) de placer le pod sur des nœuds ayant le label <code>maintenance</code>. S'il ne trouve que des nœuds avec ce label (et qui satisfont la règle <code>required</code>), il le placera quand même là.</li> </ol> <p><strong>Schéma Conceptuel :</strong></p> <div class="codehilite"><pre><span></span><code> Pod (ne veut pas gpu=nvidia) ───X──► Node 1 (gpu-type=nvidia-a100) [Rejeté par &#39;required&#39;] │ └───► Node 2 (pas de label gpu) [OK] Pod (préfère éviter maintenance=true) ───(Poids 80 Éviter)───► Node 3 (maintenance=true) [Choix évité si possible] │ ───(Poids 0)──────────► Node 4 (pas de label maintenance) [Choix préféré] </code></pre></div> <p><strong>Cas d'Usage :</strong></p> <ul> <li> <p>Éviter de placer des pods "normaux" sur des nœuds coûteux (GPU, grosse mémoire) réservés à des tâches spécifiques.</p> </li> <li> <p>Éviter des nœuds marqués pour maintenance (<code>maintenance=true</code>).</p> </li> <li> <p>Éviter des nœuds avec une architecture CPU spécifique si l'application n'est pas compatible (<code>kubernetes.io/arch != arm64</code>).</p> </li> </ul> <hr /> <h2>3. Affinité de Pod (Pod Affinity)</h2> <p><center> <image src="/images/affantiaff/pod-affinity.png"> </center></p> <p><strong>Objectif :</strong> Attirer un pod vers des nœuds où <em>d'autres pods</em> (correspondant à certains labels) sont déjà en cours d'exécution. Idéal pour la co-localisation.</p> <p><strong>Syntaxe :</strong> Se configure dans le <code>spec.affinity.podAffinity</code> du Pod. Nécessite un <code>topologyKey</code>.</p> <div class="codehilite"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">v1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Pod</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">web-server</span> <span class="w"> </span><span class="nt">labels</span><span class="p">:</span> <span class="w"> </span><span class="nt">app</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">frontend</span><span class="w"> </span><span class="c1"># Label pour être ciblé par d&#39;autres</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">affinity</span><span class="p">:</span> <span class="w"> </span><span class="nt">podAffinity</span><span class="p">:</span> <span class="w"> </span><span class="c1"># Règle STRICTE</span> <span class="w"> </span><span class="nt">requiredDuringSchedulingIgnoredDuringExecution</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">labelSelector</span><span class="p">:</span> <span class="w"> </span><span class="nt">matchExpressions</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">key</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">app</span><span class="w"> </span><span class="c1"># Cherche des pods avec ce label...</span> <span class="w"> </span><span class="nt">operator</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">In</span> <span class="w"> </span><span class="nt">values</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">cache</span><span class="w"> </span><span class="c1"># ...et cette valeur (le pod cache)</span> <span class="w"> </span><span class="nt">topologyKey</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">kubernetes.io/hostname</span><span class="w"> </span><span class="c1"># Doit être sur le MÊME NŒUD</span> <span class="w"> </span><span class="c1"># Règle PRÉFÉRENTIELLE</span> <span class="w"> </span><span class="nt">preferredDuringSchedulingIgnoredDuringExecution</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">weight</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">70</span> <span class="w"> </span><span class="nt">podAffinityTerm</span><span class="p">:</span> <span class="w"> </span><span class="nt">labelSelector</span><span class="p">:</span> <span class="w"> </span><span class="nt">matchExpressions</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">key</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">app</span> <span class="w"> </span><span class="nt">operator</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">In</span> <span class="w"> </span><span class="nt">values</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">api-gateway</span> <span class="w"> </span><span class="nt">topologyKey</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">topology.kubernetes.io/zone</span><span class="w"> </span><span class="c1"># Préfère être dans la MÊME ZONE que l&#39;API Gateway</span> <span class="w"> </span><span class="nt">containers</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">web-container</span> <span class="w"> </span><span class="nt">image</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">nginx</span> </code></pre></div> <p><strong>Explication des Exemples :</strong></p> <ol> <li><strong><code>required...</code> :</strong> Ce pod <code>web-server</code> <strong>doit</strong> être schedulé sur un nœud (<code>topologyKey: kubernetes.io/hostname</code>) où au moins un pod ayant le label <code>app=cache</code> est déjà en cours d'exécution. Si aucun nœud ne remplit cette condition, le pod restera Pending.</li> <li><strong><code>preferred...</code> :</strong> Le scheduler <strong>préférera</strong> (poids 70) placer ce pod dans la même zone de disponibilité (<code>topologyKey: topology.kubernetes.io/zone</code>) qu'un pod ayant le label <code>app=api-gateway</code>.</li> </ol> <p><strong>Schéma Conceptuel :</strong></p> <div class="codehilite"><pre><span></span><code> Pod Web (veut app=cache, même nœud) ─────► Node 1 (contient Pod Cache (app=cache)) [OK] │ └─X──► Node 2 (pas de Pod Cache) [Ignoré par &#39;required&#39;] Pod Web (préfère app=api, même zone) ───(Poids 70)───► Node 3 (Zone A, contient Pod API (app=api)) [Choix préféré] │ ───(Poids 0)────► Node 4 (Zone B, pas de Pod API) [Moins préféré] </code></pre></div> <p><strong>Cas d'Usage :</strong></p> <ul> <li> <p><strong>Performance :</strong> Placer un serveur web (<code>app=frontend</code>) sur le même nœud (<code>topologyKey: kubernetes.io/hostname</code>) qu'un cache en mémoire (<code>app=cache</code>) pour une latence minimale.</p> </li> <li> <p><strong>Localité des données :</strong> Placer des pods de traitement analytique (<code>app=analytics</code>) dans la même zone (<code>topologyKey: topology.kubernetes.io/zone</code>) que les pods de base de données (<code>app=database</code>) qu'ils interrogent fréquemment.</p> </li> <li> <p>Regrouper des microservices très communicants.</p> </li> </ul> <hr /> <h2>4. Anti-Affinité de Pod (Pod Anti-Affinity)</h2> <p><center> <image src="/images/affantiaff/pod-anti-affinity.png"> </center></p> <p><strong>Objectif :</strong> Empêcher un pod d'être schedulé sur des nœuds où <em>d'autres pods</em> (correspondant à certains labels) sont déjà en cours d'exécution. Idéal pour la haute disponibilité et l'isolation.</p> <p><strong>Syntaxe :</strong> Se configure dans le <code>spec.affinity.podAntiAffinity</code> du Pod. Nécessite aussi un <code>topologyKey</code>.</p> <div class="codehilite"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">apps/v1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Deployment</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ma-db-ha</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">replicas</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">3</span> <span class="w"> </span><span class="nt">selector</span><span class="p">:</span> <span class="w"> </span><span class="nt">matchLabels</span><span class="p">:</span> <span class="w"> </span><span class="nt">app</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">database</span><span class="w"> </span><span class="c1"># Important pour que l&#39;anti-affinité se cible elle-même</span> <span class="w"> </span><span class="nt">template</span><span class="p">:</span><span class="w"> </span><span class="c1"># Le template du Pod</span> <span class="w"> </span><span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">labels</span><span class="p">:</span> <span class="w"> </span><span class="nt">app</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">database</span><span class="w"> </span><span class="c1"># Le label que l&#39;anti-affinité va rechercher</span> <span class="w"> </span><span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">affinity</span><span class="p">:</span> <span class="w"> </span><span class="nt">podAntiAffinity</span><span class="p">:</span> <span class="w"> </span><span class="c1"># Règle STRICTE pour la Haute Disponibilité</span> <span class="w"> </span><span class="nt">requiredDuringSchedulingIgnoredDuringExecution</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">labelSelector</span><span class="p">:</span> <span class="w"> </span><span class="nt">matchExpressions</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">key</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">app</span><span class="w"> </span><span class="c1"># Cherche des pods avec ce label...</span> <span class="w"> </span><span class="nt">operator</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">In</span> <span class="w"> </span><span class="nt">values</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">database</span><span class="w"> </span><span class="c1"># ...et cette valeur (les autres réplikas de moi-même)</span> <span class="w"> </span><span class="nt">topologyKey</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">kubernetes.io/hostname</span><span class="w"> </span><span class="c1"># NE PAS être sur le MÊME NŒUD</span> <span class="w"> </span><span class="c1"># Règle PRÉFÉRENTIELLE pour encore plus de résilience</span> <span class="w"> </span><span class="nt">preferredDuringSchedulingIgnoredDuringExecution</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">weight</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">100</span> <span class="w"> </span><span class="nt">podAffinityTerm</span><span class="p">:</span> <span class="w"> </span><span class="nt">labelSelector</span><span class="p">:</span> <span class="w"> </span><span class="nt">matchExpressions</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">key</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">app</span> <span class="w"> </span><span class="nt">operator</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">In</span> <span class="w"> </span><span class="nt">values</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">database</span> <span class="w"> </span><span class="nt">topologyKey</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">topology.kubernetes.io/zone</span><span class="w"> </span><span class="c1"># Préfère NE PAS être dans la MÊME ZONE</span> <span class="w"> </span><span class="nt">containers</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">db-container</span> <span class="w"> </span><span class="nt">image</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">postgres:15</span> </code></pre></div> <p><strong>Explication des Exemples :</strong></p> <ol> <li><strong><code>required...</code> :</strong> Chaque nouveau pod de ce Deployment (<code>app=database</code>) <strong>ne doit pas</strong> être placé sur un nœud (<code>topologyKey: kubernetes.io/hostname</code>) où un autre pod avec le label <code>app=database</code> est déjà présent. Cela garantit que les 3 réplikas seront sur 3 nœuds distincts (si possible).</li> <li><strong><code>preferred...</code> :</strong> De plus, le scheduler <strong>tentera fortement</strong> (poids 100) d'éviter de placer les réplikas dans la même zone de disponibilité (<code>topologyKey: topology.kubernetes.io/zone</code>). Si vous avez assez de nœuds répartis sur plusieurs zones, cela augmente encore la résilience. Si tous les nœuds disponibles sont dans la même zone, cette règle "soft" sera ignorée, mais la règle "hard" sur les nœuds sera toujours respectée.</li> </ol> <p><strong>Schéma Conceptuel :</strong></p> <div class="codehilite"><pre><span></span><code> Pod DB Replica 1 ────► Node 1 (Zone A) Pod DB Replica 2 ───X──► Node 1 (déjà un Pod DB) │ └───► Node 2 (Zone A) [OK pour &#39;required&#39;, mais pas idéal pour &#39;preferred&#39;] Pod DB Replica 3 ───X──► Node 1 (déjà un Pod DB) │ ───X──► Node 2 (déjà un Pod DB) │ └───► Node 3 (Zone B) [OK pour &#39;required&#39;, et OK pour &#39;preferred&#39;] </code></pre></div> <p><strong>Cas d'Usage :</strong></p> <ul> <li> <p><strong>Haute Disponibilité :</strong> Assurer que les réplikas d'une application stateful (ex: base de données, etcd) sont répartis sur différents nœuds physiques (<code>topologyKey: kubernetes.io/hostname</code>) ou même différentes zones/régions (<code>topologyKey: topology.kubernetes.io/zone</code>) pour survivre à une panne matérielle ou de zone. C'est le cas d'usage le plus fréquent.</p> </li> <li> <p><strong>Isolation des Ressources :</strong> Éviter que plusieurs instances d'un pod très gourmand en CPU ou mémoire ne tournent sur le même nœud et ne se concurrencent (`topologyKey: </p> </li> <li> <p><strong>Sécurité :</strong> Répartir les composants d'une application pour limiter l'impact d'une compromission d'un nœud.</p> </li> </ul> <hr /> <h2>Bonnes Pratiques et Points d'Attention</h2> <ul> <li> <p><strong>Simplicité :</strong> N'abusez pas des règles complexes. Trop de contraintes peuvent rendre le scheduling difficile, voire impossible.</p> </li> <li> <p><strong>Labels Cohérents :</strong> La puissance de ces mécanismes repose sur une stratégie de labeling claire et cohérente pour vos nœuds et vos pods.</p> </li> <li> <p><strong>Choix du <code>topologyKey</code> :</strong> Réfléchissez bien au domaine d'application de vos règles de Pod (Anti-)Affinity (<code>hostname</code>, <code>zone</code>, <code>region</code>, ou même des labels custom sur vos nœuds).</p> </li> <li> <p><strong><code>IgnoredDuringExecution</code> :</strong> Rappelez-vous que ces règles sont évaluées <em>au moment du scheduling</em>. Si les conditions changent après (un label de nœud est retiré, un pod co-localisé est supprimé), le pod ne sera pas automatiquement déplacé ou supprimé (sauf si vous utilisez les règles <code>RequiredDuringExecution</code>, moins courantes).</p> </li> <li> <p><strong>Performance du Scheduler :</strong> Des règles d'anti-affinité complexes sur un grand nombre de pods peuvent ralentir le scheduler. Utilisez-les judicieusement.</p> </li> <li> <p><strong>Combinaison :</strong> Vous pouvez combiner plusieurs types d'affinité (node, pod, anti-affinité) dans un même Pod spec pour des scénarios avancés.</p> </li> </ul> <hr /> <h2>Conclusion</h2> <p>L'Affinité et l'Anti-Affinité Node/Pod sont des outils essentiels dans la boîte à outils de tout administrateur ou développeur Kubernetes souhaitant optimiser le placement de ses charges de travail. </p> <p>En maîtrisant les règles <code>required</code> et <code>preferred</code>, les <code>labelSelectors</code> et les <code>topologyKeys</code>, vous pouvez aller bien au-delà du scheduling par défaut pour améliorer la performance, la résilience et l'efficacité de vos applications conteneurisées.</p>2025-03-31T10:00:00+02:002025-03-31T10:00:00+02:00Hervé Leclerctag:blogppr.alterway.fr,2025-03-31:/kubernetes-133.html

<p>Kubernetes 1.33 : Nouveautés Réseau, Sécurité et Expérience Admin</p>

<h1>Kubernetes 1.33 : Nouveautés Réseau, Sécurité et Expérience Admin</h1> <h2>Introduction</h2> <p><strong>Kubernetes 1.33 doit sortir le Mercredi 23 avril 2025</strong></p> <p>Kubernetes continue son évolution rapide avec la sortie de la version 1.33. </p> <p>Cette nouvelle itération apporte son lot de fonctionnalités graduées vers la stabilité (GA), de nouvelles capacités en bêta et alpha, ainsi que des améliorations de performance et de sécurité notables. </p> <p>Voici les points les plus importants:</p> <ul> <li> <p>Kubernetes 1.33 stabilise les Sidecars, le proxy nftables et l'API ServiceCIDR. </p> </li> <li> <p>L'API v1 Endpoints est dépréciée, les fournisseurs cloud intégrés sont retirés. </p> </li> <li> <p>Sécurité et performances renforcées incluses.</p> </li> </ul> <p>Explorons les autres points forts de cette version.</p> <h2>Kubernetes 1.33 : Points les plus structurants</h2> <ol> <li> <p><strong>Dépréciation Officielle de l'API v1 Endpoints</strong>:</p> <ul> <li><strong>Impact</strong>: Très élevé. Bien que l'API ne soit pas supprimée immédiatement, c'est un signal fort pour <strong>migrer impérativement vers l'API EndpointSlice</strong>. Toutes les nouvelles fonctionnalités et optimisations réseau se concentreront sur EndpointSlice. Les utilisateurs et les outils doivent planifier cette transition.</li> <li><em>(Introduit dans v1.33.0-alpha.3)</em></li> </ul> </li> <li> <p><strong>Suppression Finale des Flags Cloud Provider In-Tree (<code>--cloud-provider</code>, <code>--cloud-config</code>)</strong>:</p> <ul> <li><strong>Impact</strong>: Très élevé pour ceux qui n'ont pas encore migré. Cela marque la fin de l'intégration directe des fournisseurs de cloud dans les composants principaux comme <code>kube-apiserver</code>. Il est <strong>obligatoire</strong> d'utiliser les fournisseurs de cloud externes (out-of-tree).</li> <li><em>(Introduit dans v1.33.0-alpha.3)</em></li> </ul> </li> <li> <p><strong>Gestion des CIDR de Service via l'API (<code>MultiCIDRServiceAllocator</code> GA)</strong>:</p> <ul> <li><strong>Impact</strong>: Élevé pour les administrateurs et les distributions Kubernetes. La configuration des plages d'IP pour les services passe des flags de ligne de commande à un objet API (<code>ServiceCIDR</code>). Cela offre plus de flexibilité (multi-CIDR) mais <strong>nécessite une nouvelle façon de gérer et de valider</strong> ces plages (potentiellement via <code>ValidatingAdmissionPolicy</code>).</li> <li><em>(Introduit dans v1.33.0-alpha.1)</em></li> </ul> </li> <li> <p><strong>Conteneurs Sidecar (<code>SidecarContainers</code>) en GA</strong>:</p> <ul> <li><strong>Impact</strong>: Élevé pour les développeurs d'applications. Cette fonctionnalité <strong>change la sémantique</strong> des conteneurs <code>init</code> avec <code>restartPolicy: Always</code>. Elle stabilise la manière native de gérer les sidecars, simplifiant les déploiements qui en dépendent fortement.</li> <li><em>(Introduit dans v1.33.0-alpha.1)</em></li> </ul> </li> <li> <p><strong>Mode <code>nftables</code> pour Kube-proxy en GA</strong>:</p> <ul> <li><strong>Impact</strong>: Élevé pour les performances et l'administration réseau. Offre une <strong>alternative stable et potentiellement plus performante</strong> au mode <code>iptables</code> par défaut. Les administrateurs peuvent désormais l'adopter en production en toute confiance.</li> <li><em>(Introduit dans v1.33.0-alpha.2)</em></li> </ul> </li> <li> <p><strong>Liaison des Tokens de Service Account au Nœud (<code>ServiceAccountTokenNodeBinding</code>) en GA et Verrouillée</strong>:</p> <ul> <li><strong>Impact</strong>: Élevé (Sécurité). Cette fonctionnalité de sécurité, qui empêche l'utilisation abusive de tokens de service account volés sur d'autres nœuds, est <strong>désormais toujours activée et non désactivable</strong>. Cela renforce la sécurité par défaut.</li> <li><em>(Introduit dans v1.33.0-alpha.1)</em></li> </ul> </li> <li> <p><strong>Changement de Comportement du CPU Manager (Static Policy &amp; CFS Quota)</strong>:</p> <ul> <li><strong>Impact</strong>: Potentiellement élevé pour les workloads sensibles aux performances CPU. Le fait de ne plus appliquer de quota CFS aux conteneurs avec des CPUs exclusifs (policy <code>static</code>) <strong>change un comportement établi de longue date</strong>. Bien que probablement plus correct, cela pourrait causer des régressions pour certains. Une feature gate (<code>DisableCPUQuotaWithExclusiveCPUs</code>) permet de revenir à l'ancien comportement si nécessaire.</li> <li><em>(Introduit dans v1.33.0-alpha.2)</em></li> </ul> </li> <li> <p><strong>Validation et Avertissements pour les IP/CIDR Non Standards</strong>:</p> <ul> <li><strong>Impact</strong>: Moyen à élevé (Compatibilité future). L'API server émettra des avertissements pour les formats non canoniques (ex: <code>192.168.000.1</code>). C'est un <strong>précurseur d'une application plus stricte</strong> dans les futures versions, incitant les utilisateurs à nettoyer leurs configurations et manifests.</li> <li><em>(Introduit dans v1.33.0-beta.0)</em></li> </ul> </li> </ol> <p>Ces points représentent les changements les plus structurants, nécessitant une attention particulière lors de la planification de la mise à niveau vers Kubernetes 1.33, que ce soit en termes d'action requise, de changement de comportement fondamental ou de stabilisation majeure d'une fonctionnalité clé.</p> <h2>Kuberenetes 1.33 : Détail complet des changements</h2> <h3>Graduations vers la Stabilité (GA)</h3> <p>Plusieurs fonctionnalités importantes atteignent la disponibilité générale (GA) dans la v1.33, signifiant qu'elles sont considérées comme stables et prêtes pour la production :</p> <ol> <li><strong>Sidecar Containers (<code>SidecarContainers</code>)</strong>: La gestion native des conteneurs sidecar est désormais stable. Cette fonctionnalité simplifie la gestion du cycle de vie des conteneurs auxiliaires qui doivent démarrer avant les conteneurs principaux d'un pod et rester actifs pendant toute la durée de vie du pod. (<em>Initialement dans v1.33.0-alpha.1, confirmé GA</em>)</li> <li><strong>Montages Récursifs en Lecture Seule (<code>RecursiveReadOnlyMounts</code>)</strong>: La possibilité de monter des volumes en lecture seule de manière récursive est maintenant GA, améliorant la sécurité en empêchant les écritures accidentelles dans les sous-répertoires des volumes montés. (<em>v1.33.0-alpha.3</em>)</li> <li><strong>Politique de Récupération des PV (<code>HonorPVReclaimPolicy</code>)</strong>: Le respect de la politique de récupération ( <code>Retain</code>, <code>Delete</code>, <code>Recycle</code>) définie sur un PersistentVolume (PV) lors de la suppression de la PersistentVolumeClaim (PVC) associée est maintenant stable. (<em>v1.33.0-alpha.3</em>)</li> <li><strong>Source de Données pour Volumes (<code>AnyVolumeDataSource</code>)</strong>: La capacité d'utiliser n'importe quelle ressource API comme source de données pour provisionner un volume via une PVC est désormais GA, offrant plus de flexibilité pour la création de volumes pré-remplis. (<em>v1.33.0-alpha.3</em>)</li> <li><strong>Validation des CRD avec Ratcheting (<code>CRDValidationRatcheting</code>)</strong>: Cette fonctionnalité, qui permet des mises à jour d'objets personnalisés même si l'objet existant n'est pas valide selon les nouvelles règles de validation (tant que la mise à jour ne rend pas l'objet <em>plus</em> invalide), est désormais stable. (<em>v1.33.0-alpha.3</em>)</li> <li><strong>Limite de Backoff par Index pour les Jobs (<code>JobBackoffLimitPerIndex</code>)</strong>: La configuration fine du nombre de tentatives par index pour les Jobs indexés est maintenant stable. (<em>v1.33.0-alpha.3</em>)</li> <li><strong>Mode nftables pour Kube-proxy</strong>: Le backend <code>nftables</code> pour <code>kube-proxy</code> passe en GA. Bien que <code>iptables</code> reste le mode par défaut, <code>nftables</code> offre une alternative potentiellement plus performante et flexible. (<em>v1.33.0-alpha.2</em>)</li> <li><strong>Liaison des Tokens de Service Account au Nœud (<code>ServiceAccountTokenNodeBinding</code>)</strong>: Cette fonctionnalité de sécurité, qui lie les tokens de service account éphémères au nœud qui les demande, est désormais GA et activée par défaut. (<em>v1.33.0-alpha.1</em>)</li> <li><strong>Migration CSI pour Portworx (<code>CSIMigrationPortworx</code>)</strong>: La migration automatique des volumes in-tree Portworx vers le driver CSI correspondant est stable. Assurez-vous que le driver CSI Portworx est installé avant la mise à niveau. (<em>v1.33.0-alpha.1</em>)</li> <li><strong>Flag <code>--subresource</code> pour Kubectl</strong>: La possibilité de cibler des sous-ressources (comme <code>status</code> ou <code>scale</code>) via <code>kubectl patch</code>, <code>edit</code>, etc., est maintenant stable. (<em>v1.33.0-alpha.3</em>)</li> <li><strong>Cache de Watch basé sur B-tree (<code>BtreeWatchCache</code>)</strong>: Cette optimisation interne du cache de l'API server est désormais GA. (<em>v1.33.0-alpha.2</em>)</li> <li><strong>Allocation Multi-CIDR pour les Services (<code>MultiCIDRServiceAllocator</code>)</strong>: Permet de définir plusieurs plages CIDR pour les Services ClusterIP, améliorant la flexibilité de l'adressage IP. (<em>v1.33.0-alpha.1</em>)</li> </ol> <h3>Fonctionnalités Promues en Bêta</h3> <p>Des fonctionnalités prometteuses passent en bêta, se rapprochant de la stabilité :</p> <ol> <li><strong>Validation Assouplie des Domaines de Recherche DNS (<code>RelaxedDNSSearchValidation</code>)</strong>: Autorise désormais les domaines de recherche DNS contenant un simple point (<code>.</code>) ou un underscore (<code>_</code>), activé par défaut. (<em>v1.33.0-alpha.3</em>)</li> <li><strong>Autorisation Fine du Kubelet (<code>KubeletFineGrainedAuthz</code>)</strong>: Permet un contrôle d'accès plus granulaire pour les endpoints de l'API du Kubelet, activé par défaut. (<em>v1.33.0-alpha.1</em>)</li> <li><strong>Mode Local pour le Kubelet du Control Plane (kubeadm)</strong> (<code>ControlPlaneKubeletLocalMode</code>): Kubeadm configure désormais par défaut le kubelet des nœuds master pour communiquer directement avec l'API server local, améliorant la résilience. (<em>v1.33.0-alpha.2, v1.33.0-alpha.1</em>)</li> <li><strong>Attente de Tous les Composants du Control Plane (kubeadm)</strong> (<code>WaitForAllControlPlaneComponents</code>): Kubeadm vérifie la santé des composants du control plane en utilisant les adresses et ports configurés dans leurs manifestes statiques. (<em>v1.33.0-alpha.1</em>)</li> <li><strong>Désactivation de l'Écriture Double pour l'Allocateur de Service CIDR</strong> (<code>DisableAllocatorDualWrite</code>): Désactivé par défaut, ce flag prépare la suppression de l'ancienne méthode d'écriture du CIDR de service via les arguments de l'API server. (<em>v1.33.0-alpha.1</em>)</li> </ol> <h3>Nouvelles Fonctionnalités Alpha et Améliorations Clés</h3> <p>La version 1.33 introduit également de nouvelles capacités expérimentales et des améliorations significatives :</p> <ul> <li><strong>API Server &amp; Core</strong>:<ul> <li><strong>Suivi de Génération Observée pour les Pods (<code>PodObservedGenerationTracking</code>)</strong>: Le Kubelet remplit <code>status.observedGeneration</code> pour indiquer la dernière <code>metadata.generation</code> du Pod qu'il a prise en compte (Alpha). (<em>v1.33.0-beta.0</em>)</li> <li><strong>Validation et Canonicalisation des IP/CIDR</strong>: Des avertissements sont émis pour les formats IP/CIDR non standards (ex: zéros non significatifs), et les composants écrivent désormais ces valeurs sous forme canonique. (<em>v1.33.0-beta.0, v1.33.0-alpha.3, v1.33.0-alpha.1</em>)</li> <li><strong>Encodage JSON en Streaming pour les Listes (<code>StreamingJSONListEncoding</code>)</strong>: Réduit drastiquement l'utilisation mémoire de l'API server lors du renvoi de grandes listes en JSON (Alpha, activé par défaut). (<em>v1.33.0-alpha.3</em>)</li> <li><strong>Namespace Ordonné (<code>OrderedNamespaceDeletion</code>)</strong>: Nouvelle feature gate (Alpha, désactivée par défaut) qui supprime d'abord les pods lors de la suppression d'un namespace pour renforcer la sécurité. (<em>v1.33.0-beta.0, v1.33.0-alpha.3</em>)</li> <li><strong>Métriques et Observabilité</strong>: Introduction d'une métrique de "digest" pour comparer le contenu d'etcd et du cache (<code>apiserver_storage_digest</code>), ajout d'annotations de latence d'authentification/autorisation aux logs d'audit, et ajout d'endpoints <code>/statusz</code> pour <code>kube-scheduler</code> et <code>kube-controller-manager</code>. (<em>v1.33.0-beta.0, v1.33.0-alpha.3, v1.33.0-alpha.2</em>)</li> </ul> </li> <li><strong>Node &amp; Kubelet</strong>:<ul> <li><strong>Mise à l'échelle Verticale In-Place (<code>InPlacePodVerticalScaling</code>)</strong>: Améliorations continues, notamment la gestion des sidecars et des politiques de redimensionnement mémoire. (<em>v1.33.0-beta.0, v1.33.0-alpha.3, v1.33.0-alpha.2</em>)</li> <li><strong>CPU Manager Static Policy</strong>: Possibilité de désactiver le quota CFS pour les conteneurs avec des CPUs exclusifs via la feature gate <code>DisableCPUQuotaWithExclusiveCPUs</code> (Alpha, activé par défaut). (<em>v1.33.0-alpha.2</em>)</li> </ul> </li> <li><strong>Scheduling</strong>:<ul> <li><strong>Exposition de NodeInfo</strong>: Le <code>NodeInfo</code> complet est exposé aux plugins de Score pour des décisions plus fines. (<em>v1.33.0-beta.0</em>)</li> <li><strong>Améliorations de Performance</strong>: Calculs de ressources de pods mis en cache et amélioration pour les contraintes de topologie requises. (<em>v1.33.0-alpha.1</em>)</li> </ul> </li> <li><strong>Réseau (Kube-proxy)</strong>:<ul> <li><strong>Améliorations <code>nftables</code></strong>: Outre la GA, des améliorations de logging pour le débuggage. (<em>v1.33.0-alpha.1</em>)</li> <li><strong>Observabilité</strong>: Endpoints <code>/flagz</code>, <code>/statusz</code>, et métriques/health checks enrichis avec l'information de famille IP. Métriques pour le suivi de la réconciliation conntrack. (<em>v1.33.0-alpha.2, v1.33.0-alpha.1</em>)</li> <li><strong>Correction de Bugs</strong>: Résolution d'une fuite mémoire potentielle et d'une consommation CPU excessive avec les services UDP et IP externes/LB. (<em>v1.33.0-alpha.3, v1.33.0-alpha.2</em>)</li> </ul> </li> <li><strong>Stockage</strong>:<ul> <li><strong>Suivi de Progression</strong>: Le changement de permissions/propriétaire des volumes indique désormais sa progression. (<em>v1.33.0-alpha.3</em>)</li> <li><strong>Tests E2E</strong>: Ajout de tests pour les snapshots de groupes de volumes. (<em>v1.33.0-alpha.1</em>)</li> </ul> </li> <li><strong>Sécurité</strong>:<ul> <li><strong>Restriction d'Audience pour les Nœuds</strong>: Configuration dynamique de l'audience/nom de compte de service demandée par le kubelet (Alpha). (<em>v1.33.0-beta.0</em>)</li> <li><strong>UID Utilisateur depuis Certificat</strong>: Possibilité d'extraire l'UID utilisateur depuis un OID spécifique dans le sujet d'un certificat client (Bêta). (<em>v1.33.0-alpha.1</em>)</li> </ul> </li> <li><strong>Allocation Dynamique de Ressources (DRA)</strong>:<ul> <li><strong>Critères Priorisés</strong>: Support d'une liste ordonnée de critères de sélection pour satisfaire une demande de ressource. (<em>v1.33.0-beta.0</em>)</li> <li><strong>Limite de Pods Augmentée</strong>: Un <code>ResourceClaim</code> peut maintenant être réservé pour 256 pods (contre 32). (<em>v1.33.0-alpha.1</em>)</li> </ul> </li> <li><strong>CLI (kubectl)</strong>:<ul> <li><strong>Fichier <code>kuberc</code></strong>: Support alpha pour personnaliser le comportement de kubectl via un fichier <code>kuberc</code> distinct du <code>kubeconfig</code>. (<em>v1.33.0-alpha.2</em>)</li> <li><strong><code>kubectl autoscale</code></strong>: Utilise désormais l'API <code>autoscaling/v2</code> par défaut. (<em>v1.33.0-alpha.1</em>)</li> </ul> </li> <li><strong>Kubeadm</strong>: Nombreuses améliorations sur les pré-vérifications, la gestion des feature gates (ControlPlaneKubeletLocalMode, WaitForAllControlPlaneComponents), les messages d'erreur, et la gestion des mises à niveau. (<em>Multiples PRs</em>)</li> </ul> <h3>Dépréciations et Suppressions Notables</h3> <ul> <li>L'<strong>API v1 Endpoints</strong> est officiellement dépréciée. Il est fortement recommandé d'utiliser l'API EndpointSlice à la place. L'API Endpoints ne sera pas supprimée mais n'est plus la méthode privilégiée. (<em>v1.33.0-alpha.3</em>)</li> <li>Les feature gates <code>AppArmor</code>, <code>AppArmorFields</code>, <code>JobPodFailurePolicy</code>, <code>PDBUnhealthyPodEvictionPolicy</code>, <code>KubeProxyDrainingTerminatingNodes</code> et <code>ServiceAccountTokenNodeBinding</code> ont été supprimées car elles étaient déjà GA et activées par défaut.</li> <li>Les feature gates <code>StorageNamespaceIndex</code> et <code>SeparateCacheWatchRPC</code> sont dépréciées et désactivées/non activables. (<em>v1.33.0-alpha.2</em>)</li> <li>Les flags CLI <code>--cloud-provider</code> et <code>--cloud-config</code> de l'API Server sont supprimés, ainsi que les feature gates associées (<code>DisableCloudProviders</code>, <code>DisableKubeletCloudCredentialProviders</code>). (<em>v1.33.0-alpha.3</em>)</li> </ul> <h2>Conclusion</h2> <p>Kubernetes 1.33 continue de renforcer la plateforme en stabilisant des fonctionnalités clés (Sidecars, RRO Mounts, nftables proxy, Multi-CIDR Services) tout en introduisant des améliorations significatives en termes de performance, de sécurité et d'opérabilité. Les avancées dans le scheduling, l'allocation dynamique de ressources et la gestion in-place des pods ouvrent de nouvelles perspectives. Comme toujours, il est recommandé de consulter les notes de version complètes ([lien vers les notes officielles si disponible]) avant de mettre à niveau et de tester attentivement les nouvelles fonctionnalités, en particulier celles en Alpha et Bêta.</p>2025-03-27T10:00:00+01:002025-03-27T10:00:00+01:00Hervé Leclerctag:blogppr.alterway.fr,2025-03-27:/kubernetes-et-ses-ressources.html

<p>Kubernetes et ses Ressources : Confessions d'un Kubelet au bord de la crise de nerfs</p>

<h1>Kubernetes et ses Ressources : Confessions d'un Kubelet au bord de la crise de nerfs</h1> <p><strong>Introduction : Le grand malentendu cosmique des millicores</strong></p> <p>Ah, Kubernetes. Notre sauveur, notre plateforme rutilante, notre promesse d'un monde où les déploiements se font en musique et où les conteneurs gambadent joyeusement dans des prés de Nodes verdoyants. Et puis... il y a la gestion des ressources. Les fameux <code>requests</code> et <code>limits</code>. C'est là que le rêve DevOps rencontre la dure réalité, un peu comme quand on commande un plat magnifique sur Instagram et qu'on reçoit une bouillie triste dans une barquette en alu.</p> <p>Avouons-le, expliquer les <code>requests</code> et <code>limits</code> à un nouveau venu, c'est comme essayer d'expliquer la règle du hors-jeu avec des marionnettes : ça semble simple en théorie, mais ça finit toujours en chaos et en pleurs.</p> <p><center> <image src="/images/resources/drakeposting.png"> </center></p> <h2>Chapitre 1 : Les <code>Requests</code> - La liste au Père Noël (ou au kube-scheduler)</h2> <p>Imaginez votre conteneur comme un enfant un peu capricieux avant son anniversaire. Le <code>request</code>, c'est sa liste de souhaits :</p> <ul> <li>"Je VEUX <em>au moins</em> 100 millicores de CPU pour pouvoir... euh... afficher 'Hello World' de manière <em>très</em> optimisée."</li> <li>"Et il me FAUT <em>absolument</em> 128Mi de RAM, sinon mes variables vont se sentir à l'étroit et faire une dépression."</li> </ul> <p>Le <strong>kube-scheduler</strong>, ce grand organisateur bienveillant mais un peu débordé (pensez à un animateur de colo avec 300 gamins hyperactifs), regarde cette liste. Il parcourt ses Nodes disponibles, en marmonnant : "Voyons voir... Tatie Node-01 a encore de la place à côté du conteneur Nginx qui ronfle... Oui, ça devrait passer. Allez hop, casé !"</p> <div class="codehilite"><pre><span></span><code>Voix tremblante d&#39;un Kubelet Anonyme (Kubelet-7b3f sur Node-Stresstest-04) : &quot;L&#39;autre jour, le Scheduler m&#39;a refilé un Pod qui demandait &#39;10m&#39; de CPU. Dix ! Pour une application qui, je le jure, essayait de calculer Pi jusqu&#39;à la dernière décimale. Je l&#39;ai vu venir gros comme une maison que ça allait mal finir. Mais bon, le request était satisfait, alors j&#39;ai dû le prendre...&quot; </code></pre></div> <p>Le <code>request</code>, c'est la <strong>promesse minimum garantie</strong>. C'est le siège réservé dans le train Kube. Si le Node ne peut même pas <em>garantir</em> ce minimum vital, votre Pod restera sur le quai, regardant les autres partir vers la gloire (ou vers une boucle infinie, on sait jamais).</p> <p><strong>Le drame des <code>requests</code> mal calibrées :</strong></p> <ul> <li><strong>Trop basses :</strong> Votre Pod se retrouve sur un Node déjà bondé, partageant son CPU avec un voisin bruyant qui compile le noyau Linux en boucle. Résultat : votre application rame comme un galérien sous Prozac.</li> <li><strong>Trop hautes :</strong> Votre Pod devient une diva insupportable. "QUOI ? Pas de Node avec 8 coeurs dédiés juste pour mon script batch qui tourne 5 minutes par jour ? Scandaleux ! Je refuse de démarrer." Et il boude en état <code>Pending</code> pendant des heures.</li> </ul> <p><center> <image src="/images/resources/bill.png"> </center></p> <h2>Chapitre 2 : Les <code>Limits</code> - La Laisse Électronique (et parfois mortelle)</h2> <p>Ah, les <code>limits</code>. Si le <code>request</code> était la liste au Père Noël, le <code>limit</code> c'est le budget réel que Papa Maman Kubelet vous accorde. C'est la dure réalité après les rêves de grandeur.</p> <ul> <li>"Ok, tu as demandé 100m de CPU, mais écoute coco, tu n'auras <strong>JAMAIS PLUS</strong> que 500m. Si tu dépasses, on va commencer à te ralentir TRES fort." (C'est le <strong>CPU Throttling</strong>, l'équivalent de devoir courir un 100m dans de la mélasse).</li> </ul> <div class="codehilite"><pre><span></span><code>Confession d&#39;un Kubelet Blasé (Kubelet-c4f8 sur Node-Production-Critical-66) : &quot;Regarder un Pod taper son limit CPU et commencer à se faire throttler... C&#39;est mon petit plaisir coupable. Ça rame, ça supplie, ça envoie des signaux de détresse dans les logs... et moi je suis là, imperturbable : &#39;Désolé mon grand, la limite, c&#39;est la limite. Fallait pas être si gourmand.&#39;&quot; </code></pre></div> <p><center> <image src="/images/resources/brain.png"> </center></p> <ul> <li>"Et pour la RAM, tu voulais 128Mi ? Adorable. Mais si tu oses toucher à <strong>1 Mi de plus</strong> que tes 256Mi de <code>limit</code>, <em>pouf</em>, tu disparais." (Ça, mes amis, c'est le célèbre et redouté <strong>OOMKiller</strong>, l'ange exterminateur de Kubernetes, aussi subtil qu'un coup de bazooka pour écraser une mouche).</li> </ul> <div class="codehilite"><pre><span></span><code>Témoignage Anonyme d&#39;un Kubelet Traumatisé (Kubelet-9a1d sur Node-Dev-Chaos-01) : &quot;&#39;Limit Exceeded: 256Mi&#39;. Ah, cette ligne dans mes logs... c&#39;est le son de l&#39;inévitable. J&#39;ai même pas le temps de dire &#39;OOM...&#39; que l&#39;autre psychopathe (l&#39;OOMKiller, ndlr) est déjà passé et a tout nettoyé. Parfois, la nuit, j&#39;entends encore les cris des processus terminés...&quot; </code></pre></div> <p><center> <image src="/images/resources/cat.png"> </center></p> <p>Le Kubelet, maintenant transformé en videur de boîte de nuit fatigué, surveille tout le monde. Dès qu'un conteneur devient trop gourmand en CPU, il lui tire l'oreille numériquement (throttling). Si un autre se goinfre de RAM comme s'il n'y avait pas de lendemain, le Kubelet appelle son pote OOMKiller, qui arrive avec sa faux et... <em>Terminé bonsoir</em>. Votre Pod est <code>OOMKilled</code>, laissant derrière lui un message cryptique dans les logs et une équipe d'astreinte en sueur à 3h du matin.</p> <h2>Chapitre 3 : Les Classes de QoS - Le Club VIP, la Classe Éco et... les autres</h2> <p>Pour ajouter un peu de piment (comme s'il en manquait), Kubernetes classe vos Pods en fonction de comment vous avez défini (ou pas) ces <code>requests</code> et <code>limits</code>. C'est une sorte de hiérarchie sociale pour conteneurs :</p> <ol> <li><strong><code>Guaranteed</code> (Le VIP) :</strong> Vous avez défini des <code>requests</code> ET des <code>limits</code>, et (attention, subtilité) ils sont <strong>égaux</strong> pour le CPU et la RAM. Ce Pod est un membre du Gotha. Il a une place réservée et un traitement de faveur. L'OOMKiller ira voir ailleurs en premier. C'est le Pod qui sirote du champagne dans le carré VIP du Node.</li> <li><strong><code>Burstable</code> (La Classe Éco Confort) :</strong> Vous avez défini des <code>requests</code>, mais les <code>limits</code> sont plus hauts (ou absents pour une ressource mais pas l'autre). Ce Pod a sa place assise (<code>request</code>), mais il peut essayer de s'étaler un peu plus si personne ne regarde (<code>limit</code> &gt; <code>request</code>). Attention, il est moins protégé que le VIP. Si ça chauffe, il risque de se faire <code>throttler</code> ou même <code>OOMKiller</code> avant les <code>Guaranteed</code>. C'est le passager qui espère secrètement que le siège à côté reste vide.</li> <li><strong><code>BestEffort</code> (Le Stagiaire / Le Squatteur) :</strong> Vous n'avez défini <strong>AUCUN</strong> <code>request</code> ni <code>limit</code>. Ce Pod vit dangereusement. Il n'a aucune garantie, il prend ce qui reste. C'est le premier à se faire éjecter sans ménagement si les ressources viennent à manquer. L'OOMKiller le regarde avec un sourire carnassier dès son démarrage. C'est celui qui essaie de rentrer gratos à la soirée et qui se fait sortir par la sécurité à la première occasion.</li> </ol> <p><center> <image src="/images/resources/dog.jpg"> </center></p> <div class="codehilite"><pre><span></span><code>Soupir d&#39;un Kubelet Fataliste (Kubelet-f8g2 sur Node-Shared-08) : &quot;Quand je vois arriver un Pod BestEffort, je ne m&#39;attache pas. Vraiment. C&#39;est comme accueillir un poisson rouge dans un aquarium de piranhas. On sait tous comment ça va finir. Je prépare déjà le message &#39;Evicted&#39;...&quot; </code></pre></div> <h2>Chapitre 4 : Le Grand Bazar - Pourquoi on se plante tous (avec amour)</h2> <p>Personne n'est parfait. Voici le florilège des erreurs classiques qui transforment nos clusters en joyeux chaos :</p> <ul> <li><strong>Le " YOLO Driven Development " :</strong> Ne mettre aucun <code>request</code> ni <code>limit</code>. Vos Pods sont en mode <code>BestEffort</code>, le Node devient une jungle où seule la loi du plus fort (ou du plus rapide à consommer la RAM) s'applique. Les OOMKills pleuvent comme à Gravelotte.</li> <li><strong>Le " Copier-Coller Sans Réfléchir " :</strong> Prendre les <code>requests/limits</code> d'un exemple sur Stack Overflow pour votre application Java ultra-gourmande. Spoiler : ça finit mal.</li> <li><strong>Le " Optimiste Pathologique " :</strong> Mettre des <code>requests</code> ridicules ("Mon appli utilise à peine 10m de CPU !") et des <code>limits</code> stratosphériques ("Mais au cas où, donnons-lui 4 coeurs !"). Résultat : vos Nodes sont pleins à craquer (basé sur les <code>requests</code> faibles), mais en réalité, ils sont constamment au bord de l'implosion car tout le monde dépasse allègrement. C'est l'overbooking aérien appliqué aux serveurs.</li> <li><strong>Le " Pessimiste Anxieux " :</strong> Mettre <code>requests</code> = <code>limits</code> partout, très haut "pour être sûr". Félicitations, vos Pods sont <code>Guaranteed</code>, mais vous utilisez 3 Nodes là où un seul aurait suffi. Votre DSI vous regarde avec des yeux qui lancent des éclairs (de factures Cloud).</li> </ul> <p><center> <image src="/images/resources/dev.png"> </center></p> <div class="codehilite"><pre><span></span><code>Rire nerveux d&#39;un Kubelet Développeur-Sympathisant (Kubelet-a2b5 sur Node-CI-CD-02) : &quot;Parfois, je vois des requests et limits arriver... et je me dis &#39;Ok, ce dev a clairement utilisé un générateur de nombres aléatoires&#39;. J&#39;ai vu des requests plus grands que les limits ! J&#39;ai vu des demandes de &#39;0.0001m&#39; de CPU ! J&#39;essaie de rester pro, mais des fois, j&#39;aimerais pouvoir envoyer un &#39;LOL&#39; dans les events du Pod.&quot; </code></pre></div> <h2>Conclusion : Rire pour ne pas pleurer (et mettre des métriques)</h2> <p>La gestion des ressources dans Kubernetes, c'est un art subtil. Un mélange de science (monitoring, profiling), de doigt mouillé (estimations initiales) et parfois, de pure chance. C'est une source inépuisable de maux de tête, de crises de nerfs nocturnes, mais aussi, avouons-le, de bonnes tranches de rigolade (après coup, généralement).</p> <p>Alors la prochaine fois que votre Pod se fait OOMKiller pour la 5ème fois de la journée, respirez un grand coup. Rappelez-vous que vous n'êtes pas seul. Nous sommes tous dans cette galère magnifique qu'est Kubernetes. Et n'oubliez pas : mettez des métriques partout, observez vos applications comme un stalker professionnel, ajustez vos <code>requests</code> et <code>limits</code> avec la précision d'un horloger suisse (ou au moins, avec un peu moins de "YOLO"), et peut-être, juste peut-être, votre Kubelet arrêtera de pleurer la nuit.</p> <p>Et si ça ne marche toujours pas ? Blâmez le YAML. Ça marche toujours.</p> <div class="codehilite"><pre><span></span><code>Dernier mot d&#39;un Kubelet Philosophe (Kubelet-1c9e sur Node-Zen-Garden-00) : &quot;Au fond, nous les Kubelets, on est juste là pour essayer de maintenir un semblant d&#39;ordre dans le chaos créatif des développeurs. On jongle avec des millicores et des mébioctets comme on peut. Alors oui, parfois on râle, parfois on throttle, parfois on appelle le grand méchant OOMKiller... mais c&#39;est pour le bien du cluster. Enfin... on espère.&quot; </code></pre></div> <p><center> <image src="/images/resources/batman.png"> </center></p>2025-03-26T10:00:00+01:002025-03-26T10:00:00+01:00Hervé Leclerctag:blogppr.alterway.fr,2025-03-26:/nelm-le-futur-de-helm.html

<p>Nelm : Redécouvrez le Déploiement de Charts Helm sur Kubernetes</p>

<h1>Nelm : Redécouvrez le Déploiement de Charts Helm sur Kubernetes</h1> <p>Dans l'écosystème Kubernetes, Helm s'est imposé comme le gestionnaire de paquets de facto, simplifiant la définition, l'installation et la mise à niveau des applications. Cependant, malgré ses qualités, Helm 3 présente certaines limitations et complexités qui peuvent frustrer les équipes DevOps. C'est là qu'intervient <strong>Nelm</strong>, une alternative open-source construite sur les fondations de Helm 3, mais repensée pour offrir plus de contrôle, de prévisibilité et de robustesse dans vos déploiements.</p> <p>Utilisé comme moteur de déploiement principal par l'outil CI/CD <a href="https://github.com/werf/werf/">werf</a>, Nelm conserve une compatibilité de premier ordre avec les Charts Helm existants tout en introduisant des fonctionnalités puissantes inspirées d'autres outils éprouvés comme Terraform.</p> <p>Ce billet explore en profondeur ce qu'est Nelm, pourquoi vous pourriez l'envisager à la place de Helm, et comment ses fonctionnalités clés peuvent améliorer vos workflows de déploiement Kubernetes.</p> <h3>Qu'est-ce que Nelm ? Une Alternative Améliorée à Helm 3</h3> <p>Nelm n'est pas une réécriture complète de Helm, mais plutôt une évolution. Il reprend la base de code de Helm 3, assure la compatibilité avec ses concepts fondamentaux (Charts, Releases), mais réimplémente ou améliore des parties cruciales, notamment le moteur de déploiement.</p> <p>Les objectifs principaux de Nelm sont de résoudre des problèmes connus de Helm 3 et d'introduire des capacités plus avancées :</p> <ol> <li> <p><strong>Prévisualisation Fiable des Changements :</strong> Offrir une fonctionnalité similaire à <code>terraform plan</code> pour savoir <em>exactement</em> ce qui va changer dans le cluster avant d'appliquer.</p> </li> <li> <p><strong>Gestion des Mises à Jour Robuste :</strong> Remplacer le mécanisme de "Fusion à Trois Voies" (3-Way Merge) de Helm par l'<strong>Application Côté Serveur</strong> (Server-Side Apply) de Kubernetes, plus fiable.</p> </li> <li> <p><strong>Ordonnancement Avancé :</strong> Permettre un contrôle fin sur l'ordre de déploiement des ressources, y compris les dépendances externes.</p> </li> <li> <p><strong>Gestion Sécurisée des Secrets :</strong> Intégrer nativement le chiffrement des fichiers de valeurs ou de fichiers arbitraires.</p> </li> <li> <p><strong>Suivi Détaillé et Visibilité :</strong> Améliorer le suivi de l'état des ressources, afficher les logs et événements en continu pendant le déploiement.</p> </li> <li> <p><strong>Correction de Bugs Helm :</strong> Résoudre des problèmes récurrents de Helm, comme les erreurs liées aux versions d'API obsolètes.</p> </li> </ol> <p>Tout en offrant ces améliorations, Nelm maintient la compatibilité avec le format des Charts Helm et le stockage des informations de release (Secrets Kubernetes), permettant une transition potentielle depuis Helm.</p> <h3>Pourquoi Envisager Nelm ? Les Fonctionnalités Clés</h3> <p>Explorons les aspects qui différencient Nelm et peuvent apporter une valeur significative à vos processus de déploiement.</p> <h3>1. Planification Précise avec <code>nelm release plan install</code></h3> <p>L'un des défis avec Helm est de comprendre précisément l'impact d'une commande <code>helm upgrade</code>. Nelm s'attaque à ce problème avec <code>nelm release plan install</code>. Cette commande utilise un dry-run basé sur Server-Side Apply pour générer un diff fiable entre l'état actuel dans le cluster et l'état désiré après application du Chart.</p> <p><strong>Exemple : Planifier la mise à jour d'une application web</strong></p> <p>Imaginons un Chart simple pour une application web <code>my-webapp</code> avec un Déploiement et un Service.</p> <ul> <li><code>Chart.yaml</code>:</li> </ul> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">v2</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-webapp</span> <span class="w"> </span><span class="nt">version</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">0.1.0</span> <span class="w"> </span><span class="nt">appVersion</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;1.0&quot;</span> </code></pre></div> <ul> <li><code>values.yaml</code>:</li> </ul> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="nt">replicaCount</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">1</span> <span class="w"> </span><span class="nt">image</span><span class="p">:</span> <span class="w"> </span><span class="nt">repository</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-registry/my-webapp</span> <span class="w"> </span><span class="nt">tag</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;1.0&quot;</span> <span class="w"> </span><span class="nt">service</span><span class="p">:</span> <span class="w"> </span><span class="nt">type</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ClusterIP</span> <span class="w"> </span><span class="nt">port</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">80</span> </code></pre></div> <ul> <li><code>templates/deployment.yaml</code>:</li> </ul> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">apps/v1</span> <span class="w"> </span><span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Deployment</span> <span class="w"> </span><span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">{{</span><span class="w"> </span><span class="nv">.Release.Name</span><span class="w"> </span><span class="p p-Indicator">}}</span><span class="l l-Scalar l-Scalar-Plain">-app</span> <span class="w"> </span><span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">replicas</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">{{</span><span class="w"> </span><span class="nv">.Values.replicaCount</span><span class="w"> </span><span class="p p-Indicator">}}</span> <span class="w"> </span><span class="nt">selector</span><span class="p">:</span> <span class="w"> </span><span class="nt">matchLabels</span><span class="p">:</span> <span class="w"> </span><span class="nt">app</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">{{</span><span class="w"> </span><span class="nv">.Release.Name</span><span class="w"> </span><span class="p p-Indicator">}}</span> <span class="w"> </span><span class="nt">template</span><span class="p">:</span> <span class="w"> </span><span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">labels</span><span class="p">:</span> <span class="w"> </span><span class="nt">app</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">{{</span><span class="w"> </span><span class="nv">.Release.Name</span><span class="w"> </span><span class="p p-Indicator">}}</span> <span class="w"> </span><span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">containers</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">web</span> <span class="w"> </span><span class="nt">image</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;{{</span><span class="nv"> </span><span class="s">.Values.image.repository</span><span class="nv"> </span><span class="s">}}:{{</span><span class="nv"> </span><span class="s">.Values.image.tag</span><span class="nv"> </span><span class="s">}}&quot;</span> <span class="w"> </span><span class="nt">ports</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">containerPort</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">8080</span><span class="w"> </span><span class="c1"># Supposons que l&#39;app écoute sur 8080</span> </code></pre></div> <ul> <li><code>templates/service.yaml</code>:</li> </ul> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">v1</span> <span class="w"> </span><span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Service</span> <span class="w"> </span><span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">{{</span><span class="w"> </span><span class="nv">.Release.Name</span><span class="w"> </span><span class="p p-Indicator">}}</span><span class="l l-Scalar l-Scalar-Plain">-svc</span> <span class="w"> </span><span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">type</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">{{</span><span class="w"> </span><span class="nv">.Values.service.type</span><span class="w"> </span><span class="p p-Indicator">}}</span> <span class="w"> </span><span class="nt">ports</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">port</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">{{</span><span class="w"> </span><span class="nv">.Values.service.port</span><span class="w"> </span><span class="p p-Indicator">}}</span> <span class="w"> </span><span class="nt">targetPort</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">8080</span><span class="w"> </span><span class="c1"># Port du container</span> <span class="w"> </span><span class="nt">selector</span><span class="p">:</span> <span class="w"> </span><span class="nt">app</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">{{</span><span class="w"> </span><span class="nv">.Release.Name</span><span class="w"> </span><span class="p p-Indicator">}}</span> </code></pre></div> <p>Après un premier déploiement (<code>nelm release install -n web -r myapp ./my-webapp</code>), nous voulons mettre à jour l'image vers la version "1.1" et passer à 2 réplicas. Planifions ce changement :</p> <div class="codehilite"><pre><span></span><code>nelm<span class="w"> </span>release<span class="w"> </span>plan<span class="w"> </span>install<span class="w"> </span>-n<span class="w"> </span>web<span class="w"> </span>-r<span class="w"> </span>myapp<span class="w"> </span>./my-webapp<span class="w"> </span><span class="se">\</span> <span class="w"> </span>--set<span class="w"> </span>image.tag<span class="o">=</span><span class="s2">&quot;1.1&quot;</span><span class="w"> </span><span class="se">\</span> <span class="w"> </span>--set<span class="w"> </span><span class="nv">replicaCount</span><span class="o">=</span><span class="m">2</span> </code></pre></div> <p>Nelm affichera un résultat clair, indiquant <em>uniquement</em> les modifications prévues sur le Déploiement :</p> <div class="codehilite"><pre><span></span><code>Planning release install &quot;myapp&quot; (namespace: &quot;web&quot;) ┌ Update Deployment/myapp-app │ namespace: web │ spec: │ - replicas: 1 │ + replicas: 2 │ template: │ spec: │ containers: │ - name: web │ - image: &quot;my-registry/my-webapp:1.0&quot; │ + image: &quot;my-registry/my-webapp:1.1&quot; │ ports: └ Update Deployment/myapp-app Planned changes summary for release &quot;myapp&quot; (namespace: &quot;web&quot;): - update: 1 resource(s) </code></pre></div> <p>Cette clarté permet d'éviter les surprises et de valider les changements avant de les appliquer réellement avec <code>nelm release install</code>.</p> <h3>2. Server-Side Apply (SSA) au lieu de 3-Way Merge</h3> <p>Le mécanisme de "Fusion à Trois Voies" (3-Way Merge) utilisé par Helm pour calculer les patchs de mise à jour est basé sur l'état connu de la <em>dernière release Helm réussie</em>. Si des modifications manuelles ont eu lieu (<code>kubectl edit</code>), ou si une release précédente a échoué partiellement, Helm peut générer des patchs incorrects ou écraser des changements inattendus.</p> <p>Nelm utilise l'<strong>Application Côté Serveur</strong> (Server-Side Apply), une fonctionnalité native de Kubernetes. Avec SSA, c'est le serveur d'API Kubernetes lui-même qui calcule le patch en se basant sur l'état <em>réel</em> de la ressource dans le cluster et l'état désiré soumis par Nelm. Chaque champ est "possédé" par un gestionnaire (ici, Nelm). Cela résout les problèmes de désynchronisation et assure des mises à jour beaucoup plus robustes et prévisibles. C'est la méthode adoptée par des outils modernes comme FluxCD.</p> <h3>3. Ordonnancement Avancé des Ressources</h3> <p>Helm propose un ordonnancement basique via les Hooks et leurs poids (<code>helm.sh/hook-weight</code>). Nelm étend considérablement ces capacités :</p> <ul> <li> <p><strong>Annotation <code>werf.io/weight</code> :</strong> Similaire à <code>helm.sh/hook-weight</code>, mais applicable à <strong>toutes</strong> les ressources (pas seulement les hooks). Les ressources avec le même poids sont déployées en parallèle. Les groupes de poids sont déployés séquentiellement (du plus petit au plus grand).</p> <p><strong>Exemple :</strong> Déployer une ConfigMap avant un Déploiement.</p> </li> </ul> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="c1"># templates/configmap.yaml</span> <span class="w"> </span><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">v1</span> <span class="w"> </span><span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ConfigMap</span> <span class="w"> </span><span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">myapp-config</span> <span class="w"> </span><span class="nt">annotations</span><span class="p">:</span> <span class="w"> </span><span class="nt">werf.io/weight</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;-10&quot;</span><span class="w"> </span><span class="c1"># Déployé en premier</span> <span class="w"> </span><span class="nt">data</span><span class="p">:</span> <span class="w"> </span><span class="nt">config.json</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">|</span> <span class="w"> </span><span class="no">{&quot;setting&quot;: &quot;value&quot;}</span> <span class="w"> </span><span class="c1"># templates/deployment.yaml</span> <span class="w"> </span><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">apps/v1</span> <span class="w"> </span><span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Deployment</span> <span class="w"> </span><span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">myapp-deployment</span> <span class="w"> </span><span class="nt">annotations</span><span class="p">:</span> <span class="w"> </span><span class="nt">werf.io/weight</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;0&quot;</span><span class="w"> </span><span class="c1"># Déployé après la ConfigMap</span> <span class="w"> </span><span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="c1"># ... spec utilisant la ConfigMap</span> </code></pre></div> <ul> <li> <p><strong>Annotation <code>werf.io/deploy-dependency-&lt;id&gt;</code> :</strong> La méthode la plus puissante. Permet à une ressource d'attendre qu'une <em>autre ressource de la même release</em> atteigne un état spécifique (<code>present</code> ou <code>ready</code>) avant de se déployer.</p> <p><strong>Exemple :</strong> Un Job qui initialise une base de données (StatefulSet) avant le démarrage de l'application (Deployment).</p> </li> </ul> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="c1"># templates/database-sts.yaml</span> <span class="w"> </span><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">apps/v1</span> <span class="w"> </span><span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">StatefulSet</span> <span class="w"> </span><span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">myapp-db</span> <span class="w"> </span><span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="c1"># ... spec du StatefulSet</span> <span class="w"> </span><span class="c1"># templates/init-db-job.yaml</span> <span class="w"> </span><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">batch/v1</span> <span class="w"> </span><span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Job</span> <span class="w"> </span><span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">myapp-init-db</span> <span class="w"> </span><span class="nt">annotations</span><span class="p">:</span> <span class="w"> </span><span class="c1"># Attend que le StatefulSet soit prêt avant de lancer le Job</span> <span class="w"> </span><span class="nt">werf.io/deploy-dependency-db</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;state=ready,kind=StatefulSet,name=myapp-db&quot;</span> <span class="w"> </span><span class="c1"># Note: Le Job lui-même est souvent un hook Helm (pre-install/pre-upgrade)</span> <span class="w"> </span><span class="nt">helm.sh/hook</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">pre-install, pre-upgrade</span> <span class="w"> </span><span class="nt">helm.sh/hook-weight</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;5&quot;</span><span class="w"> </span><span class="c1"># Exécuté après le STS mais avant le déploiement applicatif</span> <span class="w"> </span><span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="c1"># ... spec du Job d&#39;initialisation</span> <span class="w"> </span><span class="c1"># templates/app-deployment.yaml</span> <span class="w"> </span><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">apps/v1</span> <span class="w"> </span><span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Deployment</span> <span class="w"> </span><span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">myapp-app</span> <span class="w"> </span><span class="nt">annotations</span><span class="p">:</span> <span class="w"> </span><span class="c1"># Attend que le Job d&#39;initialisation soit terminé (présent suffit souvent pour un Job)</span> <span class="w"> </span><span class="c1"># Ou si le Job doit absolument réussir, on pourrait pointer vers un état Ready hypothétique si le Job le supportait.</span> <span class="w"> </span><span class="c1"># Ici, on suppose que la présence du Job terminé est suffisante.</span> <span class="w"> </span><span class="c1"># Alternativement, si le Job crée une ressource signal (comme un Secret), on pourrait dépendre de cette ressource.</span> <span class="w"> </span><span class="c1"># Pour cet exemple, nous allons supposer que le hook Helm suffit à séquencer.</span> <span class="w"> </span><span class="c1"># Si le Job n&#39;était PAS un hook, cette dépendance serait cruciale :</span> <span class="w"> </span><span class="c1"># werf.io/deploy-dependency-init: &quot;state=present,kind=Job,name=myapp-init-db&quot;</span> <span class="w"> </span><span class="nt">werf.io/weight</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;10&quot;</span><span class="w"> </span><span class="c1"># Assure qu&#39;il se déploie après les hooks de poids inférieur</span> <span class="w"> </span><span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="c1"># ... spec de l&#39;application</span> </code></pre></div> <p>(Note : L'exemple combine hooks Helm et dépendances Nelm pour illustrer. Souvent, <code>deploy-dependency</code> remplace le besoin de certains hooks complexes.)*</p> <ul> <li> <p><strong>Annotations <code>*.external-dependency.werf.io/*</code> :</strong> Permet d'attendre la disponibilité de ressources <em>hors</em> de la release actuelle, typiquement gérées par des opérateurs (ex: un <code>ClusterIssuer</code> de cert-manager, une <code>Database</code> de KubeDB).</p> <p><strong>Exemple :</strong> Une Ingress qui nécessite un <code>ClusterIssuer</code> géré séparément.</p> </li> </ul> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="c1"># templates/ingress.yaml</span> <span class="w"> </span><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">networking.k8s.io/v1</span> <span class="w"> </span><span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Ingress</span> <span class="w"> </span><span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">myapp-ingress</span> <span class="w"> </span><span class="nt">annotations</span><span class="p">:</span> <span class="w"> </span><span class="c1"># ID unique pour cette dépendance externe</span> <span class="w"> </span><span class="nt">certissuer.external-dependency.werf.io/resource</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;ClusterIssuer.v1.cert-manager.io/letsencrypt-prod&quot;</span> <span class="w"> </span><span class="c1"># Si le ClusterIssuer était dans un namespace spécifique (non applicable ici car ClusterIssuer est cluster-scoped) :</span> <span class="w"> </span><span class="c1"># certissuer.external-dependency.werf.io/namespace: &quot;cert-manager&quot;</span> <span class="w"> </span><span class="c1"># Annotation standard pour utiliser le ClusterIssuer</span> <span class="w"> </span><span class="nt">cert-manager.io/cluster-issuer</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;letsencrypt-prod&quot;</span> <span class="w"> </span><span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="c1"># ... spec de l&#39;Ingress</span> </code></pre></div> <p>Nelm attendra que la ressource <code>ClusterIssuer</code> nommée <code>letsencrypt-prod</code> (avec le groupe d'API <code>cert-manager.io/v1</code>) soit prête avant de créer l'Ingress.</p> <h3>4. Suivi Amélioré des Ressources et Affichage des Logs</h3> <p>Pendant une commande <code>nelm release install</code>, Nelm fournit une sortie beaucoup plus riche que Helm :</p> <ul> <li><strong>Tableau de Suivi :</strong> Un tableau est affiché périodiquement, montrant l'état de chaque ressource gérée (Waiting, Progressing, Ready, Failed). Pour les ressources comme les Déploiements ou StatefulSets, il suit aussi l'état des Pods sous-jacents.</li> <li><strong>Détection Heuristique pour les CRDs :</strong> Nelm tente de déterminer l'état "Ready" de nombreuses Custom Resources en analysant leurs champs <code>status</code>, ce qui fonctionne pour environ la moitié des CRDs sans configuration supplémentaire.</li> <li><strong>Affichage des Logs en Continu :</strong> Nelm récupère et affiche les logs des conteneurs des Pods créés ou mis à jour pendant le déploiement. Très utile pour déboguer rapidement les problèmes de démarrage.</li> <li><strong>Affichage des Événements :</strong> En ajoutant l'annotation <code>werf.io/show-service-messages: "true"</code> à une ressource, Nelm affichera également les événements Kubernetes associés à cette ressource pendant le déploiement.</li> </ul> <p>Des annotations permettent de personnaliser ce comportement (filtrer les logs par regex, skipper les logs pour certains conteneurs, ignorer les échecs pour des ressources non critiques, etc.). Voir la section Documentation du README pour la liste complète (<code>werf.io/log-regex</code>, <code>werf.io/skip-logs</code>, <code>werf.io/fail-mode</code>, etc.).</p> <h3>5. Gestion Native des Secrets Chiffrés</h3> <p>Gérer les secrets (mots de passe, clés d'API) dans Git est toujours délicat. Nelm intègre une solution inspirée de <code>helm-secrets</code>, mais nativement :</p> <ul> <li> <p><strong>Fichiers de Valeurs Chiffrés :</strong> Vous pouvez créer des fichiers comme <code>secret-values.yaml</code> qui sont chiffrés sur disque mais déchiffrés en mémoire lors du <code>nelm install</code> ou <code>nelm render</code>. Leurs valeurs sont accessibles via <code>.Values</code> comme d'habitude.</p> </li> <li> <p><strong>Fichiers Arbitraires Chiffrés :</strong> Vous pouvez chiffrer n'importe quel fichier (ex: <code>config.json</code>, <code>cert.pem</code>) et le placer dans un répertoire <code>secret/</code> à la racine du Chart. Ces fichiers peuvent être injectés dans les templates via la fonction <code>{{ werf_secret_file "monfichier.txt" }}</code>.</p> </li> </ul> <p>Le chiffrement utilise une clé AES-256-GCM générée via <code>nelm chart secret key create</code> et fournie via la variable d'environnement <code>NELM_SECRET_KEY</code>.</p> <p><strong>Exemple : Utiliser des identifiants de base de données chiffrés</strong></p> <ol> <li>Générer une clé (à faire une seule fois et à stocker de manière sécurisée) :</li> </ol> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="nb">export</span><span class="w"> </span><span class="nv">NELM_SECRET_KEY</span><span class="o">=</span><span class="k">$(</span>nelm<span class="w"> </span>chart<span class="w"> </span>secret<span class="w"> </span>key<span class="w"> </span>create<span class="k">)</span> <span class="w"> </span><span class="c1"># Stocker cette clé quelque part (ex: variable CI/CD, gestionnaire de secrets)</span> <span class="w"> </span><span class="nb">echo</span><span class="w"> </span><span class="nv">$NELM_SECRET_KEY</span> </code></pre></div> <ol> <li>Créer/éditer un fichier de valeurs secret :</li> </ol> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="c1"># Ouvre $EDITOR pour créer/modifier le fichier, le chiffre à la sauvegarde</span> <span class="w"> </span>nelm<span class="w"> </span>chart<span class="w"> </span>secret<span class="w"> </span>values-file<span class="w"> </span>edit<span class="w"> </span>my-webapp/secret-values.yaml </code></pre></div> <ol> <li>Contenu de <code>secret-values.yaml</code> (dans l'éditeur) :</li> </ol> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="nt">database</span><span class="p">:</span> <span class="w"> </span><span class="nt">username</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">dbuser</span> <span class="w"> </span><span class="nt">password</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">SecurePassword123!</span> </code></pre></div> <p>Le fichier <code>my-webapp/secret-values.yaml</code> sur disque contiendra des données chiffrées.</p> <ol> <li>Utiliser les valeurs dans un template (ex: pour créer un Secret Kubernetes) :</li> </ol> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="c1"># templates/db-secret.yaml</span> <span class="w"> </span><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">v1</span> <span class="w"> </span><span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Secret</span> <span class="w"> </span><span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">{{</span><span class="w"> </span><span class="nv">.Release.Name</span><span class="w"> </span><span class="p p-Indicator">}}</span><span class="l l-Scalar l-Scalar-Plain">-db-credentials</span> <span class="w"> </span><span class="nt">type</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Opaque</span> <span class="w"> </span><span class="nt">stringData</span><span class="p">:</span> <span class="w"> </span><span class="nt">username</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">{{</span><span class="w"> </span><span class="nv">.Values.database.username</span><span class="w"> </span><span class="p p-Indicator">}}</span> <span class="w"> </span><span class="nt">password</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">{{</span><span class="w"> </span><span class="nv">.Values.database.password</span><span class="w"> </span><span class="p p-Indicator">}}</span> </code></pre></div> <ol> <li>Déployer (Nelm utilisera <code>secret-values.yaml</code> automatiquement si <code>NELM_SECRET_KEY</code> est définie) :</li> </ol> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="nb">export</span><span class="w"> </span><span class="nv">NELM_SECRET_KEY</span><span class="o">=</span>...<span class="w"> </span><span class="c1"># Fournir la clé</span> <span class="w"> </span>nelm<span class="w"> </span>release<span class="w"> </span>install<span class="w"> </span>-n<span class="w"> </span>web<span class="w"> </span>-r<span class="w"> </span>myapp<span class="w"> </span>./my-webapp </code></pre></div> <p><strong>Exemple : Utiliser un fichier de configuration API chiffré</strong></p> <ol> <li>Créer/éditer un fichier secret dans le répertoire <code>secret/</code> :</li> </ol> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="c1"># Assurez-vous que NELM_SECRET_KEY est définie</span> <span class="w"> </span>mkdir<span class="w"> </span>-p<span class="w"> </span>my-webapp/secret <span class="w"> </span>nelm<span class="w"> </span>chart<span class="w"> </span>secret<span class="w"> </span>file<span class="w"> </span>edit<span class="w"> </span>my-webapp/secret/api-config.json </code></pre></div> <ol> <li>Contenu de <code>api-config.json</code> (dans l'éditeur) :</li> </ol> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="nt">&quot;apiKey&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;abcdef123456&quot;</span><span class="p">,</span> <span class="w"> </span><span class="nt">&quot;endpoint&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;https://api.example.com/v1&quot;</span> <span class="w"> </span><span class="p">}</span> </code></pre></div> <p>Le fichier <code>my-webapp/secret/api-config.json</code> sur disque sera chiffré.</p> <ol> <li>Injecter le contenu dans une ConfigMap :</li> </ol> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="c1"># templates/api-configmap.yaml</span> <span class="w"> </span><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">v1</span> <span class="w"> </span><span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ConfigMap</span> <span class="w"> </span><span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">{{</span><span class="w"> </span><span class="nv">.Release.Name</span><span class="w"> </span><span class="p p-Indicator">}}</span><span class="l l-Scalar l-Scalar-Plain">-api-config</span> <span class="w"> </span><span class="nt">data</span><span class="p">:</span> <span class="w"> </span><span class="nt">config.json</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">|</span> <span class="w"> </span><span class="no">{{- werf_secret_file &quot;api-config.json&quot; | nindent 8 }}</span> </code></pre></div> <ol> <li>Déployer :</li> </ol> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="nb">export</span><span class="w"> </span><span class="nv">NELM_SECRET_KEY</span><span class="o">=</span>...<span class="w"> </span><span class="c1"># Fournir la clé</span> <span class="w"> </span>nelm<span class="w"> </span>release<span class="w"> </span>install<span class="w"> </span>-n<span class="w"> </span>web<span class="w"> </span>-r<span class="w"> </span>myapp<span class="w"> </span>./my-webapp </code></pre></div> <p>La ConfigMap dans Kubernetes contiendra le JSON déchiffré.</p> <h3>Compatibilité avec Helm</h3> <p>Nelm se veut un remplacement "drop-in" pour de nombreux cas d'usage de Helm :</p> <ul> <li><strong>Charts :</strong> Les Charts Helm 3 sont directement utilisables avec Nelm sans modification. Toutes les fonctionnalités de templating, y compris les fonctions <code>lookup</code>, sont supportées.</li> <li><strong>Releases :</strong> Nelm utilise le même format de stockage des releases (Secrets dans le namespace de la release) que Helm 3. Théoriquement, vous pouvez alterner entre <code>helm</code> et <code>nelm</code> pour gérer la même release (bien que ce ne soit généralement pas recommandé en production).</li> <li> <p><strong>Commandes CLI :</strong> La structure des commandes est différente, mais les fonctionnalités sont largement équivalentes. Voici une correspondance rapide :</p> <table> <thead> <tr> <th style="text-align: left;">Helm Command</th> <th style="text-align: left;">Nelm Command</th> </tr> </thead> <tbody> <tr> <td style="text-align: left;"><code>helm upgrade --install --atomic --wait -n ns rel ./c</code></td> <td style="text-align: left;"><code>nelm release install --auto-rollback -n ns -r rel ./c</code></td> </tr> <tr> <td style="text-align: left;"><code>helm uninstall -n ns release</code></td> <td style="text-align: left;"><code>nelm release uninstall -n ns -r release</code></td> </tr> <tr> <td style="text-align: left;"><code>helm template ./chart</code></td> <td style="text-align: left;"><code>nelm chart render ./chart</code></td> </tr> <tr> <td style="text-align: left;"><code>helm lint ./chart</code></td> <td style="text-align: left;"><code>nelm chart lint ./chart</code></td> </tr> <tr> <td style="text-align: left;"><code>helm dependency build ./chart</code></td> <td style="text-align: left;"><code>nelm chart dependency download ./chart</code></td> </tr> <tr> <td style="text-align: left;"><code>helm get values -n ns release</code></td> <td style="text-align: left;"><code>nelm release get values -n ns -r release</code></td> </tr> <tr> <td style="text-align: left;">(Plugin helm-diff) <code>helm diff upgrade ...</code></td> <td style="text-align: left;">(Natif) <code>nelm release plan install ...</code></td> </tr> <tr> <td style="text-align: left;">(Plugin helm-secrets) <code>helm secrets ...</code></td> <td style="text-align: left;">(Natif) <code>nelm chart secret ...</code></td> </tr> </tbody> </table> </li> <li> <p><strong>Plugins Helm :</strong> Non supportés directement. Nelm privilégie l'intégration native des fonctionnalités utiles (comme <code>plan</code> et <code>secret</code>).</p> </li> </ul> <p>La migration consiste principalement à adapter vos scripts CI/CD pour utiliser les commandes Nelm équivalentes.</p> <h3>Conclusion : Plus de Contrôle et de Fiabilité pour vos Déploiements</h3> <p>Nelm se présente comme une alternative sérieuse et réfléchie à Helm 3 pour les équipes qui recherchent plus de prévisibilité, de contrôle et de robustesse dans leurs déploiements Kubernetes. En remplaçant le 3-Way Merge par Server-Side Apply, en offrant une planification détaillée des changements, un ordonnancement avancé des ressources, un suivi amélioré et une gestion native des secrets, Nelm répond à plusieurs points de douleur courants rencontrés avec Helm.</p> <p>Sa compatibilité avec les Charts Helm existants facilite son adoption. Si vous utilisez déjà <code>werf</code>, vous bénéficiez déjà de Nelm. Sinon, et si les fonctionnalités décrites ici vous semblent pertinentes pour vos défis de déploiement, Nelm mérite assurément d'être exploré.</p> <p>Pour commencer, consultez les <a href="https://github.com/werf/nelm/releases">instructions d'installation</a> et essayez-le sur un projet de test !</p>2025-03-24T10:00:00+01:002025-03-24T10:00:00+01:00Flavio Pastoretag:blogppr.alterway.fr,2025-03-24:/accelerer-la-migration-et-la-modernisation-dans-le-cloud.html

<p>Accélérer la migration et la modernisation dans le cloud : approches techniques et outils avancés selon AWS</p>

<h1>Accélérer la migration et la modernisation dans le cloud : approches techniques et outils avancés selon AWS</h1> <p>Dans un contexte où un nombre significatif de workloads demeure sur site, AWS propose une méthodologie robuste pour migrer depuis des infrastructures on-premise (move to the cloud). Certains sujet abordé dans cet événement, comme EKS, sont valables aussi pour moderniser des infrastructures aws existants. Les sessions de l'AWS MAP Academy Technical Track qui se sont tenues à Paris le dernier 13 Mars (<a href="https://aws-experience.com/emea/smb/e/7954a/map-academy-technical-track--france">source</a>) ont présenté en détail des stratégies basées sur des processus rigoureux, des outils d'automatisation et des techniques d'optimisation avancées. Voici une synthèse technique des principaux points abordés.</p> <p><img alt="AWS MAP" src="/images/aws-map-2025/aws_map_presentation.jpg" /></p> <h2>Intervenants</h2> <p>Parmi les intervenants, on trouvait :</p> <ul> <li><strong>Sid Ahmed</strong>, Partner SA </li> <li><strong>Clément Lebra</strong>, Migration and Modernization SA</li> <li><strong>Gengis Birsen</strong>, Partner SA</li> <li><strong>Pragnesh Shah</strong>, Migration and Modernization Sr. Partner SA</li> </ul> <h2>Opportunités de migration et approches stratégiques</h2> <h3>Identification et évaluation des workloads</h3> <p>La migration vers AWS est perçue comme une opportunité majeure, car de nombreuses charges de travail restent non migrées. Les conférences ont insisté sur l'importance d'une analyse approfondie pour :</p> <ul> <li>Identifier les workloads non migrés et évaluer leur criticité.</li> <li>Appliquer des techniques de migration industrielle afin d'optimiser la rapidité et la robustesse du transfert.</li> </ul> <p>Le <strong>Migration Acceleration Program (MAP)</strong> s’articule notamment autour de trois étapes clés :</p> <ol> <li> <p><strong>Assess (Évaluation)</strong><br /> Cette phase consiste dans l'analyse des workloads existants et dans l'évaluation de leur préparation à la migration. Il y a notamment un étude du Total Cost of Ownership (TCO) pour estimer les économies potentielles. Des services comme Application Discovery Service sont mis à disposition pour recenser les serveurs, les applications et les métriques (CPU, mémoire, I/O disque) avec ou sans agent. Ces données permettent un right-sizing précis pour adapter les ressources AWS.</p> </li> <li> <p><strong>Mobilize (Mobilisation)</strong><br /> Élaboration d’un plan de migration détaillé intégrant allocation des ressources, gestion des risques et calendrier précis. Il y a l'élaboration d’un business case avec des outils comme OLA (Optimizing and Licensing Assessment) pour l’optimisation des licences et MPA (Migration Planning Assessment) pour la planification.</p> </li> <li> <p><strong>Migrate &amp; Modernize (Migration et Modernisation)</strong><br /> Réalisation de la migration avec des outils comme AWS Application Migration Service (MGN) pour la réplication continue des serveurs et AWS Migration Hub Orchestrator pour gérer les workflows complexes. La modernisation peut inclure la conteneurisation avec Amazon ECS/EKS, l’utilisation de bases de données gérées comme Amazon RDS, ou l’adoption d’architectures serverless avec AWS Lambda.</p> </li> </ol> <p><img alt="AWS MAP" src="/images/aws-map-2025/migration_and_modernization.png" /></p> <h2>Modernisation applicative : analyse et transformation technique</h2> <h3>Analyse du portefeuille applicatif</h3> <p>Des outils comme <strong>CAST Highlight</strong> et <strong>CAST Imaging</strong>, en partenariat avec AWS, facilitent l’analyse du portefeuille applicatif en fournissant :</p> <ul> <li>Une évaluation de la taille du code (lignes, complexité).</li> <li>Une cartographie des dépendances techniques (bibliothèques, API obsolètes) et des contraintes (ex. : compatibilité DLL).</li> <li>Des recommandations pour choisir entre lift &amp; shift, conteneurisation, refactoring ou réécriture complète.</li> </ul> <h3>Évaluation des risques et planification technique</h3> <p>L’analyse des niveaux de maturité technologique et des besoins métier permet d’évaluer les risques et de planifier la transformation. Cela aboutit à une feuille de route pour convertir les applications legacy en microservices ou architectures serverless, en intégrant les meilleures pratiques de sécurité et de conformité. Par exemple, le refactoring peut s’appuyer sur <strong>AWS Mainframe Modernization</strong> pour les workloads mainframe.</p> <p><img alt="AWS MAP" src="/images/aws-map-2025/cast.png" /></p> <h2>Planification de la transformation cloud</h2> <h3>Approche multi-dimensionnelle</h3> <p>Au-delà des aspects techniques, la planification doit intégrer des facteurs humains et des processus opérationnels. L'utilisation d'outils tel que <strong>Migration Readiness Assessment (MRA)</strong> permet de :</p> <ul> <li>Cartographier l’état actuel de l’infrastructure et des applications</li> <li>Impliquer les équipes opérationnelles et de gouvernance</li> <li>Prioriser les actions et générer des rapports d’alignement stratégique (notamment pour définir des business cases et des stratégies d'optimisation)</li> </ul> <h3>Feuille de route opérationnelle</h3> <p>Les workflows de migration sont conçus pour gérer des projets à grande échelle. Des outils tels que AWS <strong>Migration Hub</strong> et ses Journey templates offrent une visibilité centralisée sur l'ensemble du processus, depuis l'inventaire initial jusqu'au cut-over final, en automatisant la gestion destâches et en facilitant la collaboration entre les parties prenantes.</p> <h2>Optimisation de l’infrastructure et techniques de Right-Sizing</h2> <h3>Dimensionnement précis, automatisation et réduction des coûts</h3> <p>L'optimisation des ressources AWS repose sur des techniques de right-sizing et d'analyse fine des métriques de consommation. Des outils comme AWS <strong>Application Discovery Service</strong>, combinés à des exports de données manuels ou automatisés, permettent de :</p> <ul> <li>Analyser la charge réelle des serveurs on-premise,</li> <li>Simuler différents scénarios de provisionnement (on-demand, spot instances, savings plans),</li> <li>Générer des rapports détaillés sur TCO et identifier des opportunités de réduction de coûts, par exemple par le passage à des instances basées sur graviton (en architecture ARM) qui offrent un excellent rapport prix-performance.</li> </ul> <p>Pour les clusters Amazon EKS, des outils comme <strong>Karpenter</strong> optimisent les ressources Kubernetes en consolidant les pods pour maximiser l’utilisation des ressources, en remplaçant dynamiquement les instances EC2 sous-utilisées (nœuds en termes d’EKS) par des options plus efficaces, tout en gérant les transitions vers des spot instances avec une tolérance aux interruptions.</p> <blockquote> <p><em>Exemple d’automatisation pour EKS via l’outil <a href="https://k9scli.io/">K9S</a></em></p> </blockquote> <p><img alt="AWS MAP" src="/images/aws-map-2025/karpenter.jpg" /></p> <p>Et ensuite le mécanisme <strong>EKS Auto mode</strong>.</p> <p><img alt="AWS MAP" src="/images/aws-map-2025/eks_auto_mode.png" /></p> <h2>L’Impact de la GenAI dans la migration et la modernisation</h2> <h3>Augmentation de la productivité par l’automatisation</h3> <p>L’intégration de solutions de GenAI dans les projets de migration permet de réduire significativement les tâches répétitives. Des outils comme <strong>Amazon Bedrock</strong> et <strong>Amazon Q Developer</strong> génèrent automatiquement des drafts de documentation, des schémas architecturaux, et même du code. Ces outils offrent un premier niveau d’analyse pour :</p> <ul> <li>Valider les business cases</li> <li>Générer des tests unitaire</li> <li>Faciliter la code review</li> </ul> <p>Ils permettent aussi d’activer des agents intelligents qui complètent ou refactorisent le code en se basant sur une base de connaissances entraînéesur les meilleures pratiques AWS. La Next Generation Developer Experience and Productivity redéfinit ainsi le cycle de vie du développement logiciel en offrant une automatisation complète des phases de build, test et déploiement grâce à des intégrations avec des pipelines DevOps (GitLab, Jenkins, GitHub, etc.) et des mécanismes de feedback en temps réel pour l’audit de sécurité et l’optimisation des performances, améliorant ainsi la qualité du code et réduisant le time-to-market.</p> <h3>Accélération de la migration et de la modernisation par l’utilisation d’outils avancés</h3> <h4>Une palette d’outils pour tous les cas d’usage</h4> <p>Les projets de migration et de modernisation bénéficient donc d’un écosystème riche d’outils qui permettent de couvrir l’ensemble du processus :</p> <ul> <li><strong>OLA</strong> et <strong>MPA</strong> pour la construction rapide de business cases et l’analyse du TCO</li> <li><strong>Migration Hub</strong> et ses Journey Templates pour la gestion centralisée du projet</li> <li><strong>MGN</strong> pour la réplication en continu et le basculement minimaliste des serveurs</li> <li><strong>DMS (Database Migration Service)</strong> avec Schema Conversion intégrant la GenAI pour automatiser la conversion de schémas et le refactoring de code</li> <li><strong>Amazon QDeveloper</strong> pour moderniser et adapter le code aux nouvelles architectures (par exemple, migration de .NET vers .NET Core sur Linux)</li> </ul> <h4>Automatisation et orchestration des workflows</h4> <p>Les outils d'orchestration, tels que <strong>Migration Hub Orchestrator</strong>, permettent de créer des workflows personnalisés qui automatisent les étapes de migration (ex. containerisation via App2Container) tout en intégrant des interventions manuelles lorsque nécessaire. Cette automatisation assure une réduction des erreurs et une accélération des délais de migration.</p> <h4>Expérience développeur de nouvelle génération dans les projets de migration et modernisation</h4> <h5>Réinventer le cycle de vie du développement</h5> <p>Les solutions de nouvelle génération visent à optimiser l'expérience développeur en intégrant la GenAI à toutes les étapes du cycle de développement :</p> <ul> <li><strong>Planification et Requirements Analysis</strong> : L’IA assiste dans la création de drafts de documents techniques et l’élaboration de schémas d’architecture à partir d’un simple prompt</li> <li><strong>Génération et refactoring du code</strong> : Amazon QDeveloper permet de générer du code, d’effectuer des revues automatisées et de proposer des corrections basées sur une analyse contextuelle approfondie de la base de code</li> <li><strong>Intégration dans les pipelines CI/CD</strong> : Les agents intelligents interagissent avec les systèmes de versionning (ex. Gitlab Duo with AmazonQ) pour automatiser les commits, les tests unitaires et les déploiements ansi que les upgrades (Java), tout en assurant des audits de sécurité en continu</li> </ul> <h5>Collaboration et productivité optimisée</h5> <p>L'objectif est de permettre aux développeurs de se concentrer sur la création de valeur en réduisant le temps passé sur des tâches répétitives et administratives. Les outils de génération de documentation, de tests et de transformation de code fournissent une première couche d'analyse et d'optimisation, sur laquelle les experts peuvent ensuite itérer pour affiner les résultats.</p> <h2>Conclusion</h2> <p>L'approche AWS pour la migration et la modernisation se distingue par une méthodologie intégrée et des outils avancés qui couvrent l'ensemble du processus, depuis l'évaluation initiale et la planification jusqu'à l'exécution, l'optimisation et la modernisation applicative. En combinant des techniques de right-sizing, des workflows automatisés et l'intégration de la GenAI en continue évolution, AWS offre aux entreprises la possibilité de réduire significativement le TCO, d'améliorer la productivité et de transformer sa propre infrastructure en un levier stratégique de compétitivité.</p> <p>Cette vision technologique, soutenue par les nombreux outils préséntés dans cet articles et bien d'autres, permet de répondre aux défis complexes des projets de transformation numérique en garantissant une transition rapide, sécurisée et optimisée vers le cloud.</p> <hr /> <h2>Q &amp; A</h2> <p><strong>Q :</strong> Dans le cadre de notre partenariat avec AWS, nous disposons d’un outil officiel pour VMware qui facilite l’import/export vers des instances EC2. Toutefois, pour les migrations vers le Cloud depuis des hyperviseurs de type KVM (comme Proxmox ou oVirt) pour lesquels il n’existe pas d’outils de migration directe à ce jour, faut-il encore recourir exclusivement à trouver la bonne instance EC2 baremetal (avec les drivers compatibles pour KVM) et procéder manuellement à la migration, ou existe-t-il une solution plus simple ?</p> <p><strong>A :</strong> Même s’il n’y a toujours pas d’outils directs comme pour VMware, <strong>AWS Migration Evaluator</strong> permet de construire des templates personnalisés qui définissent les étapes du processus de migration depuis des environnements KVM. Grâce à ces templates, on peut définir des workflows de migration adaptés à vos besoins, simplifiant ainsi la transition et réduisant le temps et l’effort requis pour migrer vos workloads.</p>2025-02-25T16:00:00+01:002025-02-25T16:00:00+01:00Vincent Jacquettag:blogppr.alterway.fr,2025-02-25:/securisez-vos-cicd-avec-trivy.html

<p>Trivy permet de détecter des vulnérabilités dans vos projets. Nous allons voir comment l'utiliser avec des exemples concrets.</p>

<h1>Sécurisez vos CI/CD avec Trivy</h1> <blockquote> <p>Des études récentes révèlent que <strong>75 % des conteneurs contiennent des vulnérabilités critiques ou élevées</strong>, et 85 % des images en production présentent au moins une vulnérabilité non corrigée. <a href="https://www.lemondeinformatique.fr/actualites/lire-la-securite-des-conteneurs-sacrifiee-par-les-developpeurs-85630.html">Source</a></p> </blockquote> <p>Un <a href="https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/">pipeline CI/CD</a>, c'est un ensemble d'outils qui automatisent le développement, les tests et le déploiement des applications. Ça permet de rendre tout ce processus plus rapide et plus fiable. Cependant, pour que cela soit véritablement efficace, il est nécessaire de considérer la sécurité dès le début. C'est ce qu'on appelle le "<a href="https://www.redhat.com/fr/topics/devops/shift-left-vs-shift-right">Shift Left Security</a>".</p> <p>C'est à ce moment précis que <a href="https://trivy.dev/latest/">Trivy</a> prend le relais ! Trivy est un outil de détection des vulnérabilités open source qui inspecte les conteneurs, le code et même les dépendances. Il est rapide, intuitif, et s'adapte à beaucoup d'outils DevOps connus. Trivy vous offre la possibilité de détecter des vulnérabilités dès leur apparition, améliorant ainsi considérablement la sécurité de vos applications.</p> <h2>Pourquoi utiliser Trivy dans une CI/CD ?</h2> <p>Je vais essayer de vous convaincre : </p> <p>• <strong>Identification anticipée des vulnérabilités</strong> : Trivy repère les failles de sécurité basé sur les <a href="https://www.cvedetails.com/">CVE</a> et les mauvaises configurations, dès les premières étapes du développement (selon votre CI). <em>Les problèmes n'ont plus de retard, ils arrivent dès qu'on commence à respirer !</em></p> <p>• <strong>Prise en charge multi-cibles</strong> : Que vous utilisiez <a href="https://www.docker.com/">Docker</a>, <a href="https://kubernetes.io/">Kubernetes</a> ou que vous développiez du code applicatif, Trivy répond à toutes vos exigences. Trivy peut aussi bien scanner votre repo pour savoir si un mot de passe y est en clair, comme scanner une image docker et y trouver des éventuelles vulnérabilités, ou encore scanner votre cluster. Une solution unique pour tous vos projets… <em>et pas besoin de consulter 15 experts qui ne sont jamais d’accord !</em></p> <p>• <strong>Intégration transparente</strong> : Trivy se couple aisément avec vos outils de prédilection tels que <a href="https://github.com/features/actions">GitHub Actions</a>, <a href="https://docs.gitlab.com/ci/">GitLab CI</a>, <a href="https://www.jenkins.io/">Jenkins</a>, et bien d'autres. Pas besoin de changer vos habitudes, Trivy s'ajoute en douceur à votre workflow, <em>comme un ninja discret… mais efficace !</em></p> <p><em>Alors convaincu ? Aller on continue …</em></p> <h2>Tester rapidement Trivy avec Docker</h2> <h3>Étape 1 : Télécharger Trivy (Docker)</h3> <p>Pour commencer, vous pouvez utiliser Docker pour télécharger rapidement Trivy. Ouvrez votre terminal et exécutez la commande suivante :</p> <div class="codehilite"><pre><span></span><code>docker<span class="w"> </span>pull<span class="w"> </span>aquasec/trivy:0.18.3 </code></pre></div> <p>Cette commande télécharge l'image Docker de Trivy version 0.18.3. Une fois le téléchargement terminé, vous êtes prêt à scanner !</p> <h3>Étape 2 : Scanner une image Docker</h3> <p>Pour scanner une image Docker, utilisez la commande suivante. Remplacez <em><strong>\&lt;nom-image&gt;</strong></em> par le nom de l'image que vous souhaitez analyser. Par exemple, pour scanner une image nommée <code>nginx:latest</code> :</p> <div class="codehilite"><pre><span></span><code>docker<span class="w"> </span>run<span class="w"> </span>--rm<span class="w"> </span>-v<span class="w"> </span>/var/run/docker.sock:/var/run/docker.sock<span class="w"> </span>aquasec/trivy:0.18.3<span class="w"> </span>image<span class="w"> </span>nginx:latest </code></pre></div> <p>Cette commande lance Trivy dans un conteneur Docker et scanne l'image <code>nginx:latest</code> pour détecter les vulnérabilités.</p> <h2>Tester Trivy en local</h2> <h3>Installer Trivy</h3> <p>Il suffit de suivre la documentation officielle : https://trivy.dev/v0.18.3/installation/</p> <p>Mais en résumé, sous linux un simple <code>apt-get install trivy</code> devrait suffire.</p> <h3>Scanner une image docker</h3> <div class="codehilite"><pre><span></span><code>trivy<span class="w"> </span>image<span class="w"> </span>nginx:latest </code></pre></div> <p>Tout simplement :)</p> <h4>Résultat avec un template</h4> <div class="codehilite"><pre><span></span><code>trivy<span class="w"> </span>image<span class="w"> </span>--format<span class="w"> </span>template<span class="w"> </span>--template<span class="w"> </span><span class="s2">&quot;@contrib/html.tpl&quot;</span><span class="w"> </span>-o<span class="w"> </span>report.html<span class="w"> </span>nginx:latest </code></pre></div> <p>Ici la commande va sortir le résultat sous forme de fichier <code>html</code>. Pour cela, il faut au préalable avoir le template sur sa machine grâce à la commande <code>wget https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/html.tpl -P contrib/</code>. Et voici le résultat : </p> <p><img alt="Screenshot" src="images/trivy-screenshot.jpg" /></p> <h2>Intégrer Trivy dans une CI/CD</h2> <p>Dans cet exemple, nous allons utiliser GitLab CI pour illustrer l'intégration d'une étape de scan de sécurité avec Trivy : </p> <div class="codehilite"><pre><span></span><code><span class="nt">stages</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">test</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">build</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">deploy</span> <span class="nt">trivy-scan</span><span class="p">:</span> <span class="w"> </span><span class="nt">stage</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">test</span> <span class="w"> </span><span class="nt">image</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">docker.io/aquasec/trivy:latest</span> <span class="w"> </span><span class="nt">entrypoint</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">[</span><span class="s">&quot;&quot;</span><span class="p p-Indicator">]</span> <span class="w"> </span><span class="nt">script</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">trivy image --clear-cache</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">trivy image --download-db-only</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">trivy image --severity HIGH,CRITICAL nginx:latest</span> <span class="nt">build</span><span class="p">:</span> <span class="w"> </span><span class="nt">image</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">docker:latest</span> <span class="w"> </span><span class="nt">stage</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">build</span> <span class="w"> </span><span class="nt">script</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">echo &quot;Building the project...&quot;</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">docker build -t nginx:latest .</span> <span class="nt">deploy</span><span class="p">:</span> <span class="w"> </span><span class="nt">image</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">docker:latest</span> <span class="w"> </span><span class="nt">stage</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">deploy</span> <span class="w"> </span><span class="nt">script</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">echo &quot;Deploying the project...&quot;</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">docker run -d --name my-app nginx:latest</span> </code></pre></div> <p>Ce fichier <code>.gitlab-ci.yml</code> standard inclut un stage <code>test</code>, avec un job <code>trivy-scan</code>. Celui-ci utilise l'image Docker de Trivy pour analyser les vulnérabilités de l'image <code>nginx:latest</code>.</p> <ul> <li><code>trivy image --clear-cache</code> : <ul> <li>Efface le cache local de Trivy, ce qui garantit l'utilisation des dernières bases de données de vulnérabilités.</li> </ul> </li> <li><code>trivy image --download-db-only</code>:<ul> <li>Télécharge uniquement la base de données des vulnérabilités sans effectuer de scan, pour s'assurer qu'elle est bien à jour.</li> </ul> </li> <li><code>trivy image --severity HIGH,CRITICAL nginx:latest</code> :<ul> <li>Analyse l’image <code>nginx:latest</code>.</li> <li>Ne signale que les vulnérabilités de sévérité <code>HIGH</code> et <code>CRITICAL</code>, pour se concentrer sur les plus critiques.</li> </ul> </li> </ul> <h4>Note</h4> <p>Depuis la version <strong>15.0</strong> de GitLab CI, des composants officiels sont mis à disposition des développeurs. Parmi eux, on trouve le composant <a href="https://docs.gitlab.com/user/application_security/container_scanning/">Container Scanning</a>, qui permet d’analyser automatiquement les images Docker à la recherche de vulnérabilités.</p> <p>Avant la version <strong>15.0</strong>, cette fonctionnalité était exclusivement réservée aux utilisateurs de <em>GitLab Ultimate</em>. Désormais, elle est disponible gratuitement pour toutes les éditions de GitLab, offrant ainsi un accès élargi aux outils de sécurité des conteneurs.</p> <p>Ce composant s’intègre facilement dans un pipeline GitLab CI/CD et repose sur des outils de sécurité comme <strong>Trivy</strong> ou <strong>Clair</strong>. Il offre une solution native pour renforcer la sécurité des conteneurs avant leur déploiement.</p> <h3>Bonus</h3> <ul> <li><code>--severity</code> : Filtre les vulnérabilités par niveau de gravité. Par exemple, <code>--severity CRITICAL,HIGH</code> pour ne voir que les vulnérabilités critiques et élevées.</li> <li><code>--ignore-unfixed</code> : Ignore les vulnérabilités qui n'ont pas de correctif disponible. Utile pour se concentrer sur les problèmes que vous pouvez réellement résoudre.</li> <li><code>--exit-code</code> : Définit le code de sortie en fonction de la gravité des vulnérabilités trouvées. Par exemple, <code>--exit-code 1</code> pour faire échouer le pipeline CI/CD si des vulnérabilités critiques sont détectées.</li> <li><code>--format</code> : Spécifie le format de sortie du rapport. Options incluent table, json, sarif, etc. Par exemple, <code>--format json</code> pour obtenir un rapport au format JSON.</li> <li><code>--ignorefile</code> : Spécifie un fichier contenant des vulnérabilités à ignorer. Par exemple, <code>--ignorefile .trivyignore</code> pour utiliser un fichier .trivyignore à la racine de votre projet.</li> <li>Trivy a aussi sa propre <a href="https://github.com/aquasecurity/trivy-vscode-extension">extention Vscode</a>, ça peut-être super utile en local !</li> </ul> <h2>Les bonnes pratiques</h2> <p>La règle numéro 1 : Scannez tôt et souvent ! Ajoutez Trivy dans votre pipeline CI/CD et faites un scan à chaque commit. Comme ça, vous repérez les vulnérabilités avant qu’elles ne fassent trop de dégâts. Votre code reste sécurisé et vous évitez les mauvaises surprises.</p> <p>Ensuite, l’automatisation des corrections, c’est toujours une bonne idée. En automatisant les mises à jour et les corrections des dépendances vulnérables, vous réduisez la charge de travail manuelle et vous assurez que votre code est toujours au top sans devoir y penser à chaque instant.</p> <h2>Les pièges courants</h2> <p>Mais attention, il y a quelques pièges à éviter. Les faux positifs, par exemple, peuvent surgir comme des fantômes. Ne perdez pas de temps à les poursuivre ! Vérifiez chaque alerte pour ne pas partir dans une chasse aux chimères. Un bon processus pour trier les alertes est essentiel pour garder votre esprit clair.</p> <p>Les performances, ça peut aussi devenir un casse-tête. Les scans de sécurité peuvent être gourmands en ressources. Mais pas de panique ! Avec des techniques comme le cache et les scans incrémentaux, vous pouvez accélérer tout ça et éviter que votre machine n'implose sous la pression.</p> <p>Enfin, n’oubliez pas que Trivy, aussi puissant soit-il, ne doit pas être votre seul bouclier. Pour une sécurité à toute épreuve, n’hésitez pas à combiner plusieurs outils et pratiques. La défense multicouche, c’est la clé pour protéger vos applications des vilaines attaques !</p> <p>Voilà, vous êtes prêt à déployer <strong>Trivy</strong> sans crainte et à garder un oeil sur les pièges !</p>2025-02-20T10:00:00+01:002025-02-20T10:00:00+01:00Hervé Leclerctag:blogppr.alterway.fr,2025-02-20:/les-services-template-de-k0rdent.html

<p>Comprendre les Service Templates dans k0rdent : Une Approche Technique</p>

<h1>Comprendre les Service Templates dans k0rdent : Une Approche Technique</h1> <p>Dans l’univers de la gestion de clusters Kubernetes à grande échelle, k0rdent se distingue par sa capacité à orchestrer de multiples plans de contrôle via une approche déclarative et modulaire. </p> <p>Parmi ses outils avancés, les service templates jouent un rôle crucial en permettant de déployer et de gérer des services de manière standardisée et réutilisable. </p> <p>Cet article technique explore en profondeur ce que sont les service templates dans k0rdent, comment ils sont structurés et comment ils s’intègrent dans l’architecture globale de la plateforme.</p> <p>Dans k0rdent, l'utilisation de flux constitue la clé de voûte de l'automatisation et de l'orchestration des déploiements Kubernetes. </p> <p>La plateforme s'appuie sur un flux de travail déclaratif qui commence par la définition de la configuration du cluster via des fichiers YAML, garantissant une spécification précise de l'infrastructure souhaitée. </p> <p>Le k0rdent Cluster Manager (kcm) prend ensuite le relais pour déployer automatiquement le cluster, en intégrant des outils comme FluxCD et Helm afin d'installer les composants nécessaires. </p> <p>Par la suite, le k0rdent State Manager (ksm) configure les politiques de sécurité et déploie les services à travers des « ServiceTemplate », assurant ainsi une cohérence et une conformité optimales sur l'ensemble de l'environnement. </p> <p>Ce modèle de flux interconnecté permet non seulement une gestion centralisée et transparente, mais aussi une synchronisation continue avec les dépôts Git, facilitant l'adaptation dynamique aux évolutions des environnements multi-cloud et hybrides. </p> <p>Cette approche permet à k0rdent de simplifier la complexité inhérente à la gestion des clusters tout en offrant une solution robuste et scalable pour les équipes DevOps.</p> <h3>1. Contexte et Objectifs de k0rdent</h3> <p>k0rdent se présente comme un « super control plane » conçu pour centraliser la gestion de clusters Kubernetes, que ce soit sur le cloud, sur site ou dans des environnements hybrides. </p> <p>Grâce à une architecture reposant sur des Custom Resource Definitions (CRD) et sur les principes de Kubernetes Cluster API (CAPI), k0rdent offre un moyen déclaratif de décrire et de gérer à la fois l’infrastructure des clusters et les services qui y sont déployés.</p> <p>Dans ce cadre, les service templates apportent une abstraction qui permet de définir et de déployer des services de manière standardisée, tout en tirant parti de la puissance des Helm charts.</p> <h3>2. Qu’est-ce qu’un Service Template ?</h3> <p>Un service template dans k0rdent est un objet Kubernetes personnalisé qui encapsule la définition d’un service à déployer. Il s’appuie principalement sur un Helm chart afin d’automatiser l’installation, la configuration et la mise à jour des composants applicatifs ou de contrôle.</p> <p>2.1 Structure Technique d’un Service Template Le service template est une Custom Resource défini en YAML et se présente sous la forme d’un objet de type <strong>ServiceTemplate</strong> . </p> <p>Un exemple de definition de service template :</p> <div class="codehilite"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent.mirantis.com/v1alpha1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ServiceTemplate</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">prometheus-27.3.1</span> <span class="w"> </span><span class="nt">namespace</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent-prometheus</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">helm</span><span class="p">:</span> <span class="w"> </span><span class="nt">chartSpec</span><span class="p">:</span> <span class="w"> </span><span class="nt">chart</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">prometheus</span> <span class="w"> </span><span class="nt">version</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">27.3.1</span> <span class="w"> </span><span class="nt">interval</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">10m0s</span> <span class="w"> </span><span class="nt">sourceRef</span><span class="p">:</span> <span class="w"> </span><span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">HelmRepository</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent-prometheus</span> </code></pre></div> <p>Avec une custom resource HelmRepository de flux:</p> <div class="codehilite"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">source.toolkit.fluxcd.io/v1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">HelmRepository</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent-prometheus</span> <span class="w"> </span><span class="nt">namespace</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent-prometheus</span> <span class="w"> </span><span class="nt">labels</span><span class="p">:</span> <span class="w"> </span><span class="nt">k0rdent.mirantis.com/managed</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;true&quot;</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">interval</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">10m0s</span> <span class="w"> </span><span class="nt">url</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">https://prometheus-community.github.io/helm-charts</span> </code></pre></div> <p>Dans cet exemple, plusieurs points techniques sont à noter :</p> <ul> <li> <p><strong><em>Helm Integration</em></strong> : La section helm.chartSpec définit le chart à utiliser, sa version ainsi que la fréquence de réconciliation (ici toutes les 10 minutes).</p> </li> <li> <p><strong>Source de Chart</strong> : La clé sourceRef référence un objet de type HelmRepository, garantissant que le chart est récupéré depuis une source centralisée et validée.</p> </li> <li> <p><strong>Déploiement déclaratif</strong> : En définissant l’état souhaité via un CRD, k0rdent s’assure que la configuration du service reste conforme, même en cas de dérive (drift).</p> </li> </ul> <p>Au niveau de la custom resource : HelmRepository</p> <p>Ce manifeste YAML définit une ressource de type HelmRepository qui fait partie du toolkit FluxCD, utilisé ici pour intégrer et gérer un dépôt de charts Helm dans un environnement GitOps consommé par k0rdent.</p> <p>Voici une explication détaillée des différentes sections :</p> <ul> <li> <p><strong>kind</strong>: HelmRepository Le type de ressource est un HelmRepository, ce qui signifie que Flux va interroger ce dépôt pour récupérer les charts Helm disponibles. Cela permet d’automatiser la mise à jour et le déploiement des applications via ces charts.</p> </li> <li> <p><strong>labels</strong>: Le label k0rdent.mirantis.com/managed: "true" peut être utilisé pour identifier que ce HelmRepository est géré ou supervisé par le système k0rdent. Cela facilite le filtrage et la gestion des ressources dans un environnement multi-clusters ou multi-projets.</p> </li> <li> <p><strong>interval</strong>: 10m0s Cela spécifie que Flux va vérifier le dépôt toutes les 10 minutes pour détecter d’éventuelles mises à jour des charts. Ce mécanisme de polling permet d’assurer que les dernières versions ou modifications sont prises en compte de manière automatique.</p> </li> <li> <p><strong>url</strong>: https://prometheus-community.github.io/helm-charts C’est l’URL du dépôt Helm hébergeant les charts de la communauté Prometheus. Ce dépôt contient une collection de charts pour déployer Prometheus, Grafana, Alertmanager et d’autres outils liés à la surveillance.</p> </li> </ul> <h3>3. L’Extension avec le ServiceTemplateChain</h3> <p>Pour renforcer la gestion des versions et faciliter l’évolution des déploiements, k0rdent introduit le concept de <strong>ServiceTemplateChain</strong>. </p> <p>Cet objet est également défini via une CRD et permet de lister ou de valider les templates pris en charge dans une chaîne de déploiement.</p> <p>Un exemple simple de définition est le suivant</p> <div class="codehilite"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent.mirantis.com/v1alpha1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ServiceTemplateChain</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">prometheus-27.3.1</span> <span class="w"> </span><span class="nt">namespace</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent-prometheus</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">supportedTemplates</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">prometheus-27.3.1</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">prometheus-26.5.1</span> <span class="w"> </span><span class="nt">availableUpgrades</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">prometheus-27.3.1</span> </code></pre></div> <p>Le <strong>ServiceTemplateChain</strong> est une ressource personnalisée (CRD) utilisée par k0rdent pour définir quels templates de service sont autorisés dans un certain namespace et comment ils s’enchaînent pour gérer les mises à jour (upgrade paths) d’une application déployée. Autrement dit, il s’agit d’un mécanisme permettant de :</p> <ul> <li>Déclarer les templates supportés</li> </ul> <p>Dans le champ spec.supportedTemplates, on liste les noms des ServiceTemplates qui peuvent être utilisés pour déployer un service. Par exemple, dans l’exemple précédent, le template prometheus-27.3.1 est explicitement supporté.</p> <ul> <li>Gérer les chemins de mise à jour Pour certains templates, il est possible de spécifier des upgrades. Ainsi, dans l’exemple, le template prometheus-26.5.1 dispose d’un chemin de mise à jour vers prometheus-27.3.1. </li> </ul> <p>Cela permet à k0rdent de savoir qu’une version antérieure (ici la 26.5.1) peut être mise à jour vers la version 27.3.1.</p> <h3>4. Demo sur 2 clusters déployés sur azure</h3> <p>Nous allons réaliser une démonstration de la mise en œuvre des service templates en déployant deux clusters AKS à partir du template clustertemplate.k0rdent.mirantis.com/azure-aks-0-1-0. </p> <p>Ce template permet de provisionner des clusters Azure Kubernetes Service (AKS) de manière déclarative et conforme aux bonnes pratiques de k0rdent. </p> <p>Pour en savoir plus sur l’intégration de k0rdent avec Azure, vous pouvez consulter l’article dédié : <a href="https://blog.alterway.fr/k0rdent-on-azure.html">k0rdent on Azure</a></p> <p>Dans cette démonstration, nous allons :</p> <ul> <li>Déployer le chart helm cert-manager sur tous les cluster à partir du catalogue d'application de k0rdent (https://catalog.k0rdent.io/) via <code>MultiClusterService</code></li> <li>Déployer buildkit-service uniquement sur le cluster de développemnt (aks-dev-001)</li> </ul> <h3>4.1 Pré-requis</h3> <p>Pour réaliser cette démonstration de service templates en déployant deux clusters AKS à partir du template clustertemplate.k0rdent.mirantis.com/azure-aks-0-1-0, voici les principaux prérequis à prévoir :</p> <ul> <li><strong>Accès à Azure</strong></li> </ul> <p>Un compte Azure valide, avec un abonnement actif et suffisamment de quota pour créer deux clusters AKS. Des droits suffisants (Owner ou Contributor) pour provisionner des ressources dans l’abonnement cible.</p> <ul> <li><strong>Identifiants Azure</strong></li> </ul> <p>Une Azure Service Principal (SP) configurée avec les rôles adéquats pour déployer des clusters AKS. Les variables d’environnement généralement requises par le provider Azure (CAPI) : AZURE_SP_APP_ID (client ID de la SP) AZURE_SP_PASSWORD (secret de la SP) AZURE_SP_TENANT_ID (tenant ID Azure) AZURE_SUBSCRIPTION_ID (ID de l’abonnement) Ces identifiants seront ensuite stockés dans un objet Credential dans k0rdent, afin d’automatiser le déploiement.</p> <p>Voir le point 2. de l'article <a href="https://blog.alterway.fr/k0rdent-on-azure.html">k0rdent sur Azure</a></p> <ul> <li><strong>Management Cluster k0rdent</strong></li> </ul> <p>Un cluster de management Kubernetes (pouvant être un cluster local via kind, un cluster existant, etc.) sur lequel k0rdent est déjà installé et opérationnel. Le composant k0rdent Cluster Manager (KCM) doit y être déployé pour gérer la création et la mise à jour des clusters cibles.</p> <p>Voir le point 1. de l'article <a href="https://blog.alterway.fr/k0rdent-on-azure.html">k0rdent sur Azure</a></p> <h3>4.2 Création de 2 cluster AKS</h3> <ul> <li>Cluster n°1</li> </ul> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: k0rdent.mirantis.com/v1alpha1</span> <span class="s">kind: ClusterDeployment</span> <span class="s">metadata:</span> <span class="s"> name: aks-dev-001</span> <span class="s"> namespace: kcm-system</span> <span class="s">spec:</span> <span class="s"> template: azure-aks-0-1-0</span> <span class="s"> credential: azure-aks-credential</span> <span class="s"> propagateCredentials: false</span> <span class="s"> config:</span> <span class="s"> clusterLabels:</span> <span class="s"> cluster_id: &quot;dev001&quot;</span> <span class="s"> environment: &quot;dev&quot;</span> <span class="s"> csp: &quot;microsoft-azure&quot;</span> <span class="s"> location: &quot;northeurope&quot;</span> <span class="s"> machinePools:</span> <span class="s"> system:</span> <span class="s"> count: 1</span> <span class="s"> vmSize: Standard_B2s_v2</span> <span class="s"> user:</span> <span class="s"> count: 1</span> <span class="s"> vmSize: Standard_B2s_v2</span> <span class="s">EOF</span> </code></pre></div> <div class="codehilite"><pre><span></span><code>clusterdeployment.k0rdent.mirantis.com/aks-dev-001<span class="w"> </span>created </code></pre></div> <ul> <li>Cluster n°2</li> </ul> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: k0rdent.mirantis.com/v1alpha1</span> <span class="s">kind: ClusterDeployment</span> <span class="s">metadata:</span> <span class="s"> name: aks-stg-001</span> <span class="s"> namespace: kcm-system</span> <span class="s">spec:</span> <span class="s"> template: azure-aks-0-1-0</span> <span class="s"> credential: azure-aks-credential</span> <span class="s"> propagateCredentials: false</span> <span class="s"> config:</span> <span class="s"> clusterLabels:</span> <span class="s"> cluster_id: &quot;stg001&quot;</span> <span class="s"> environment: &quot;stg&quot;</span> <span class="s"> csp: &quot;microsoft-azure&quot;</span> <span class="s"> location: &quot;northeurope&quot;</span> <span class="s"> machinePools:</span> <span class="s"> system:</span> <span class="s"> count: 1</span> <span class="s"> vmSize: Standard_B2s_v2</span> <span class="s"> user:</span> <span class="s"> count: 1</span> <span class="s"> vmSize: Standard_B2s_v2</span> <span class="s">EOF</span> </code></pre></div> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>ClusterDeployment NAME<span class="w"> </span>READY<span class="w"> </span>STATUS aks-dev-001<span class="w"> </span>True<span class="w"> </span>ClusterDeployment<span class="w"> </span>is<span class="w"> </span>ready aks-stg-001<span class="w"> </span>True<span class="w"> </span>ClusterDeployment<span class="w"> </span>is<span class="w"> </span>ready </code></pre></div> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>managedclusters NAME<span class="w"> </span>READY<span class="w"> </span>SEVERITY<span class="w"> </span>REASON<span class="w"> </span>MESSAGE aks-dev-001<span class="w"> </span>True<span class="w"> </span>Succeeded aks-stg-001<span class="w"> </span>True<span class="w"> </span>Succeeded </code></pre></div> <p><center> <image src="/images/k0rdent/aks-2-by-k0rdent.png"> </center></p> <h3>4.3 Créer le HelmRepository pour buildkit-service</h3> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: source.toolkit.fluxcd.io/v1</span> <span class="s">kind: HelmRepository</span> <span class="s">metadata:</span> <span class="s"> name: buildkit-service</span> <span class="s"> namespace: kcm-system</span> <span class="s"> labels:</span> <span class="s"> k0rdent.mirantis.com/managed: &quot;true&quot;</span> <span class="s">spec:</span> <span class="s"> provider: generic</span> <span class="s"> type: default</span> <span class="s"> url: https://andrcuns.github.io/charts</span> <span class="s"> interval: 10m0s</span> <span class="s">EOF</span> </code></pre></div> <ul> <li>Vérification </li> </ul> <div class="codehilite"><pre><span></span><code>get<span class="w"> </span>helmrepositories NAME<span class="w"> </span>URL<span class="w"> </span>AGE<span class="w"> </span>READY<span class="w"> </span>STATUS buildkit-service<span class="w"> </span>https://andrcuns.github.io/charts<span class="w"> </span>28m<span class="w"> </span>True<span class="w"> </span>stored<span class="w"> </span>artifact:<span class="w"> </span>revision<span class="w"> </span><span class="s1">&#39;sha256:...95a9db4&#39;</span> catalog-core<span class="w"> </span>oci://ghcr.io/k0rdent/catalog/charts<span class="w"> </span>7d4h kcm-templates<span class="w"> </span>oci://ghcr.io/k0rdent/kcm/charts<span class="w"> </span>7d4h </code></pre></div> <h3>4.4 Déploiement buildkit-service</h3> <h4>4.4.1 Préparation du service template</h4> <p>L'objet ServiceTemplate qui référence le chart buildkit-service. Dans cet exemple, nous utilisons la version 0.9.0</p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span>&lt;&lt;EOF apiVersion:<span class="w"> </span>k0rdent.mirantis.com/v1alpha1 kind:<span class="w"> </span>ServiceTemplate metadata: <span class="w"> </span>name:<span class="w"> </span>buildkit-service-0-9-0 <span class="w"> </span>namespace:<span class="w"> </span>kcm-system spec: <span class="w"> </span>helm: <span class="w"> </span>chartSpec: <span class="w"> </span>chart:<span class="w"> </span>buildkit-service <span class="w"> </span>version:<span class="w"> </span><span class="m">0</span>.9.0 <span class="w"> </span>interval:<span class="w"> </span>10m0s <span class="w"> </span>sourceRef: <span class="w"> </span>kind:<span class="w"> </span>HelmRepository <span class="w"> </span>name:<span class="w"> </span>buildkit-service </code></pre></div> <h4>4.4.2 Préparation du service template chain</h4> <p>L’objet ServiceTemplateChain permet de définir la ou les versions disponibles et, éventuellement, les chemins de mise à niveau. Dans cet exemple, nous définissons une chaîne simple contenant uniquement le template de buildkit-service créé :</p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: k0rdent.mirantis.com/v1alpha1</span> <span class="s">kind: ServiceTemplateChain</span> <span class="s">metadata:</span> <span class="s"> name: buildkit-service-chain</span> <span class="s"> namespace: kcm-system</span> <span class="s">spec:</span> <span class="s"> supportedTemplates:</span> <span class="s"> - name: buildkit-service-0-9-0</span> <span class="s"> # Vous pouvez ajouter ici d&#39;autres templates et définir des availableUpgrades si vous prévoyez des mises à niveau</span> <span class="s">EOF</span> </code></pre></div> <ul> <li>Vérifications</li> </ul> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>ServiceTemplate<span class="w"> </span>buildkit-service-0-9-0<span class="w"> </span> NAME<span class="w"> </span>VALID buildkit-service-0-9-0<span class="w"> </span><span class="nb">true</span> </code></pre></div> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>ServiceTemplateChain<span class="w"> </span>buildkit-service-ServiceTemplateChain NAME<span class="w"> </span>AGE buildkit-service-chain<span class="w"> </span>7s </code></pre></div> <h4>4.4.3 Déploiement sur le cluster de dev</h4> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: k0rdent.mirantis.com/v1alpha1</span> <span class="s">kind: ClusterDeployment</span> <span class="s">metadata:</span> <span class="s"> name: aks-dev-001</span> <span class="s"> namespace: kcm-system</span> <span class="s">spec:</span> <span class="s"> template: azure-aks-0-1-0</span> <span class="s"> credential: azure-aks-credential</span> <span class="s"> propagateCredentials: false</span> <span class="s"> config:</span> <span class="s"> clusterLabels:</span> <span class="s"> cluster_id: &quot;dev001&quot;</span> <span class="s"> environment: &quot;dev&quot;</span> <span class="s"> csp: &quot;microsoft-azure&quot;</span> <span class="s"> location: &quot;northeurope&quot;</span> <span class="s"> machinePools:</span> <span class="s"> system:</span> <span class="s"> count: 1</span> <span class="s"> vmSize: Standard_B2s_v2</span> <span class="s"> user:</span> <span class="s"> count: 1</span> <span class="s"> vmSize: Standard_B2s_v2</span> <span class="s"> serviceSpec:</span> <span class="s"> services:</span> <span class="s"> - template: buildkit-service-0-9-0</span> <span class="s"> name: buildkit-service</span> <span class="s"> namespace: buildkit-service</span> <span class="s"> priority: 100</span> <span class="s">EOF</span> </code></pre></div> <ul> <li>Vérifications</li> </ul> <p>Namespace buildkit-service créé sur le cluster de dev</p> <p><center> <image src="/images/k0rdent/buildkit-service-chain-ns.png"> </center></p> <p>Application buildkit-service créé sur le cluster de dev <center> <image src="/images/k0rdent/buildkit-service-chain-po.png"> </center></p> <h3>4.5 Déploiement de cert-manager via MultiClusterService</h3> <h4>4.5.1 Rappel</h4> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>servicetemplate NAME<span class="w"> </span>VALID buildkit-service-0-9-0<span class="w"> </span><span class="nb">true</span> cert-manager-1-16-2<span class="w"> </span><span class="nb">true</span><span class="w"> </span>on<span class="w"> </span>va<span class="w"> </span>déployer<span class="w"> </span>ce<span class="w"> </span>chart dex-0-19-1<span class="w"> </span><span class="nb">true</span> external-secrets-0-11-0<span class="w"> </span><span class="nb">true</span> ingress-nginx-4-11-0<span class="w"> </span><span class="nb">true</span> ingress-nginx-4-11-3<span class="w"> </span><span class="nb">true</span> kyverno-3-2-6<span class="w"> </span><span class="nb">true</span> velero-8-1-0<span class="w"> </span><span class="nb">true</span> </code></pre></div> <h4>4.5.2 Déployement du MultiClusterService</h4> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: k0rdent.mirantis.com/v1alpha1</span> <span class="s">kind: MultiClusterService</span> <span class="s">metadata:</span> <span class="s"> name: global-cert-manager</span> <span class="s">spec:</span> <span class="s"> clusterSelector:</span> <span class="s"> matchLabels:</span> <span class="s"> csp: &quot;microsoft-azure&quot;</span> <span class="s"> serviceSpec:</span> <span class="s"> services:</span> <span class="s"> - name: cert-manager</span> <span class="s"> namespace: cert-manager</span> <span class="s"> template: cert-manager-1-16-2</span> <span class="s"> values: |</span> <span class="s"> installCRDs: true</span> <span class="s"> priority: 300 </span> <span class="s">EOF</span> </code></pre></div> <p>Dans cet exemple, le champ clusterSelector sélectionne les clusters qui possèdent le label csp: microsoft-azure. Le serviceSpec définit le service à déployer en se référant au ServiceTemplate nommé cert-manager-1-16-2 (préalablement créé dans le namespace approprié). La priorité (ici à 300) permet de gérer les éventuels conflits en cas de déploiement de plusieurs sources sur le même cluster.</p> <p>le bloc YAML défini dans values permet de configurer l'installation des CRD et l'image utilisée par cert-manager. Vous devez adapter ces valeurs à la structure attendue par le chart Helm que vous utilisez. Vous pouvez également utiliser le champ valuesFrom pour référencer un ConfigMap ou un Secret contenant vos valeurs.</p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>multiclusterservice<span class="w"> </span>global-cert-manager NAME<span class="w"> </span>AGE global-cert-manager<span class="w"> </span>19s </code></pre></div> <ul> <li>Vérifications</li> </ul> <p><center> <image src="/images/k0rdent/MultiClusterService-ns.png"> </center></p> <p><center> <image src="/images/k0rdent/MultiClusterService-po.png"> </center></p> <h3>4.6 Exemples d'utilisation avancées</h3> <h4>4.6.1 Utilisation de valeurs externes via aluesFrom</h4> <p>Dans cet exemple, au lieu d’inscrire directement les paramètres dans le manifeste, on utilise valuesFrom pour récupérer les valeurs depuis un ConfigMap externe :</p> <div class="codehilite"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent.mirantis.com/v1alpha1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">MultiClusterService</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">global-external-service</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">clusterSelector</span><span class="p">:</span> <span class="w"> </span><span class="nt">matchLabels</span><span class="p">:</span> <span class="w"> </span><span class="nt">environment</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">production</span> <span class="w"> </span><span class="nt">serviceSpec</span><span class="p">:</span> <span class="w"> </span><span class="nt">services</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-external-service</span> <span class="w"> </span><span class="nt">namespace</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">external-namespace</span> <span class="w"> </span><span class="nt">template</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">external-service-1-0-0</span> <span class="w"> </span><span class="nt">valuesFrom</span><span class="p">:</span> <span class="w"> </span><span class="nt">configMapKeyRef</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">external-service-values</span> <span class="w"> </span><span class="nt">key</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">values.yaml</span> <span class="w"> </span><span class="nt">priority</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">300</span> </code></pre></div> <p>Ce mécanisme est particulièrement utile lorsque la configuration varie selon l’environnement ou doit être centralisée dans un ConfigMap (ou Secret).</p> <h4>4.6.2 Gestion des mises à jour avec Service Template Chain</h4> <p>Cet exemple montre deux versions d’un service et leur chaîne d’upgrade. Le ServiceTemplateChain permet de définir un chemin de mise à niveau entre la version 1.0.0 et 1.1.0 du service :</p> <div class="codehilite"><pre><span></span><code><span class="c1"># ServiceTemplate pour la version 1.0.0</span> <span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent.mirantis.com/v1alpha1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ServiceTemplate</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-service-1-0-0</span> <span class="w"> </span><span class="nt">namespace</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-app-namespace</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">helm</span><span class="p">:</span> <span class="w"> </span><span class="nt">chartSpec</span><span class="p">:</span> <span class="w"> </span><span class="nt">chart</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-service</span> <span class="w"> </span><span class="nt">version</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">1.0.0</span> <span class="w"> </span><span class="nt">interval</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">10m0s</span> <span class="w"> </span><span class="nt">sourceRef</span><span class="p">:</span> <span class="w"> </span><span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">HelmRepository</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-charts</span> <span class="nn">---</span> <span class="c1"># ServiceTemplate pour la version 1.1.0</span> <span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent.mirantis.com/v1alpha1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ServiceTemplate</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-service-1-1-0</span> <span class="w"> </span><span class="nt">namespace</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-app-namespace</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">helm</span><span class="p">:</span> <span class="w"> </span><span class="nt">chartSpec</span><span class="p">:</span> <span class="w"> </span><span class="nt">chart</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-service</span> <span class="w"> </span><span class="nt">version</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">1.1.0</span> <span class="w"> </span><span class="nt">interval</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">10m0s</span> <span class="w"> </span><span class="nt">sourceRef</span><span class="p">:</span> <span class="w"> </span><span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">HelmRepository</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-charts</span> <span class="nn">---</span> <span class="c1"># Chaîne d&#39;upgrade entre les deux versions</span> <span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent.mirantis.com/v1alpha1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ServiceTemplateChain</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-service-chain</span> <span class="w"> </span><span class="nt">namespace</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-app-namespace</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">supportedTemplates</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-service-1-1-0</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-service-1-0-0</span> <span class="w"> </span><span class="nt">availableUpgrades</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-service-1-1-0</span> </code></pre></div> <p>Ainsi, k0rdent saura qu’une mise à niveau de la version 1.0.0 vers 1.1.0 est disponible et pourra gérer ce processus de manière automatisée.</p> <h4>4.6.3 Insertion dynamique de valeurs via templating</h4> <p>La section values d'un ClusterDeployment injecte dynamiquement des informations spécifiques du cluster (récupérées via Sveltos) dans les valeurs du chart :</p> <div class="codehilite"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent.mirantis.com/v1alpha1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ClusterDeployment</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">advanced-cluster</span> <span class="w"> </span><span class="nt">namespace</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">kcm-system</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">config</span><span class="p">:</span> <span class="w"> </span><span class="nt">clusterLabels</span><span class="p">:</span> <span class="w"> </span><span class="nt">environment</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">production</span> <span class="w"> </span><span class="nt">serviceSpec</span><span class="p">:</span> <span class="w"> </span><span class="nt">services</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-app</span> <span class="w"> </span><span class="nt">namespace</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-app-namespace</span> <span class="w"> </span><span class="nt">template</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">my-app-1-0-0</span> <span class="w"> </span><span class="nt">values</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">|</span> <span class="w"> </span><span class="no">app:</span> <span class="w"> </span><span class="no">controlPlaneHost: {{ .Cluster.spec.controlPlaneEndpoint.host }}</span> <span class="w"> </span><span class="no">controlPlanePort: &quot;{{ .Cluster.spec.controlPlaneEndpoint.port }}&quot;</span> <span class="w"> </span><span class="no">replicaCount: 3</span> </code></pre></div> <p>Ici, les variables <code>{{ .Cluster.spec.controlPlaneEndpoint.host }}</code> et <code>{{ .Cluster.spec.controlPlaneEndpoint.port }}</code> seront remplacées par les informations du point d’accès du cluster lors du déploiement du service.</p> <p>Dans cet exemple, nous déployons un service ingress-nginx sur des clusters ciblés par le label app: web. </p> <p>On utilise le templating pour injecter dynamiquement une valeur extraite d'une annotation du cluster (par exemple, une adresse IP externe) dans les valeurs du chart </p> <div class="codehilite"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent.mirantis.com/v1alpha1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">MultiClusterService</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">global-ingress-with-dynamic-values</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">clusterSelector</span><span class="p">:</span> <span class="w"> </span><span class="nt">matchLabels</span><span class="p">:</span> <span class="w"> </span><span class="nt">app</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">web</span> <span class="w"> </span><span class="nt">serviceSpec</span><span class="p">:</span> <span class="w"> </span><span class="nt">services</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ingress-nginx</span> <span class="w"> </span><span class="nt">namespace</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ingress-nginx</span> <span class="w"> </span><span class="nt">template</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ingress-nginx-4-11-3</span> <span class="w"> </span><span class="nt">values</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">|</span> <span class="w"> </span><span class="no">controller:</span> <span class="w"> </span><span class="no">replicaCount: 2</span> <span class="w"> </span><span class="no">service:</span> <span class="w"> </span><span class="no">externalTrafficPolicy: Local</span> <span class="w"> </span><span class="no">loadBalancerIP: {{ .Cluster.metadata.annotations.external-ip }}</span> <span class="w"> </span><span class="nt">priority</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">350</span> </code></pre></div> <p>Ici, la syntaxe {{ .Cluster.metadata.annotations.external-ip }} permet de récupérer dynamiquement l’IP définie dans les annotations du cluster pour la passer au chart d’ingress-nginx</p> <h3>5 Conclusion</h3> <p>L'approche proposée par k0rdent, via l'utilisation des Services Template, Service Template Chain et MultiClusterService, offre une solution puissante pour simplifier la gestion des applications dans des environnements multi-clusters. </p> <p>Ces outils permettent de définir des déploiements standardisés et versionnés à l'aide de charts Helm, tout en facilitant les mises à jour et l'extension des services sur l'ensemble des clusters ciblés. </p> <p>En centralisant le contrôle et en automatisant le déploiement des services critiques, cette approche réduit non seulement le risque d'erreurs manuelles, mais améliore également l'agilité et la résilience de l'infrastructure Kubernetes. </p> <p>Ainsi, en adoptant ces concepts, les équipes DevOps disposent d'un véritable levier pour optimiser la gestion et la scalabilité de leurs environnements complexes.</p>2025-02-13T10:00:00+01:002025-02-13T10:00:00+01:00Hervé Leclerctag:blogppr.alterway.fr,2025-02-13:/k0rdent-on-azure.html

<p>k0rdent : Tests sur Azure</p>

<h1>k0rdent sur Azure avec AKS : Premiers pas</h1> <p>Les organisations doivent aujourd’hui faire face à une complexité croissante dans la gestion de leurs infrastructures. La centralisation du contrôle et l’automatisation des tâches récurrentes deviennent des impératifs pour assurer la scalabilité, la sécurité et l’efficacité opérationnelle. </p> <p>C’est ici qu’intervient <strong>k0rdent</strong>, en offrant :</p> <ul> <li>Un contrôle centralisé sur plusieurs clusters Kubernetes</li> <li>Une approche déclarative qui permet de réutiliser des templates pour une cohérence inter-environnements</li> <li>Une extensibilité facilitée grâce à des modules complémentaires (comme kcm pour la gestion du cycle de vie des clusters, ou kof pour l’observabilité)</li> </ul> <p>Ce billet de blog détaille l’expérimentation de trois configurations de déploiement sur Azure en utilisant les templates préconçus par k0rdent.</p> <h3>1. Création d'un cluster d'administration</h3> <p>Pré-requis :</p> <ul> <li>Une VM sur Azure 22.04.5 LTS, Jammy Jellyfish</li> <li>Homebrew (<code>/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"</code>)</li> <li>k0s (<code>curl --proto '=https' --tlsv1.2 -sSf https://get.k0s.sh | sudo sh</code>)</li> <li>krew (<code>brew install krew</code>))</li> <li>kubectl (<code>brew install kubectl</code>)</li> <li>helm (<code>brew install helm</code>)</li> <li>azure CLI (az) (<code>brew install azure-cli</code>)</li> <li>jq (<code>brew install jq</code>)</li> </ul> <p><strong>1.1 Création du cluster d'administration</strong></p> <div class="codehilite"><pre><span></span><code><span class="c1"># Création du cluster d&#39;un seul noeud</span> sudo<span class="w"> </span>k0s<span class="w"> </span>install<span class="w"> </span>controller<span class="w"> </span>--single <span class="c1"># Démarrage du cluster</span> sudo<span class="w"> </span>k0s<span class="w"> </span>start <span class="c1"># Aliasing</span> <span class="nb">echo</span><span class="w"> </span><span class="s1">&#39;source &lt;(kubectl completion bash)&#39;</span><span class="w"> </span>&gt;&gt;~/.bashrc <span class="nb">echo</span><span class="w"> </span><span class="s1">&#39;alias k=kubectl&#39;</span><span class="w"> </span>&gt;&gt;~/.bashrc <span class="nb">echo</span><span class="w"> </span><span class="s1">&#39;complete -o default -F __start_kubectl k&#39;</span><span class="w"> </span>&gt;&gt;~/.bashrc <span class="nb">source</span><span class="w"> </span>~/.bashrc <span class="c1"># Copie du kubeconfig </span> mkdir<span class="w"> </span>~/.kube sudo<span class="w"> </span>cp<span class="w"> </span>/var/lib/k0s/pki/admin.conf<span class="w"> </span>~/.kube/config sudo<span class="w"> </span>chmod<span class="w"> </span>+r<span class="w"> </span>~/.kube/config sudo<span class="w"> </span>chown<span class="w"> </span>devops:<span class="w"> </span>/home/devops/.kube/config <span class="c1"># Installation des plugins krew</span> kubectl<span class="w"> </span>krew<span class="w"> </span>install<span class="w"> </span>ns<span class="w"> </span> kubectl<span class="w"> </span>krew<span class="w"> </span>install<span class="w"> </span>ctx<span class="w"> </span> kubectl<span class="w"> </span>krew<span class="w"> </span>install<span class="w"> </span>neat kubectl<span class="w"> </span>krew<span class="w"> </span>install<span class="w"> </span>view-secret kubectl<span class="w"> </span>krew<span class="w"> </span>install<span class="w"> </span>stern kubectl<span class="w"> </span>get<span class="w"> </span>nodes <span class="c1"># Résultat : </span> NAME<span class="w"> </span>STATUS<span class="w"> </span>ROLES<span class="w"> </span>AGE<span class="w"> </span>VERSION herlec-icdc<span class="w"> </span>Ready<span class="w"> </span>control-plane<span class="w"> </span>6m11s<span class="w"> </span>v1.32.1+k0s </code></pre></div> <p><strong>1.2 Installation de k0rdent</strong></p> <div class="codehilite"><pre><span></span><code><span class="c1"># Récupération des valeurs par défaut(au cas ou...)</span> helm<span class="w"> </span>inspect<span class="w"> </span>values<span class="w"> </span>oci://ghcr.io/k0rdent/kcm/charts/kcm<span class="w"> </span>&gt;<span class="w"> </span>kcm-values.yaml </code></pre></div> <p>Interroge le chart Helm disponible dans le registre OCI (ici sur ghcr.io) pour récupérer les valeurs de configuration par défaut. Le résultat est ensuite redirigé vers le fichier kcm-values.yaml, que vous pourrez modifier si nécessaire.</p> <div class="codehilite"><pre><span></span><code><span class="c1"># Installation du kcm</span> helm<span class="w"> </span>install<span class="w"> </span>kcm<span class="w"> </span>oci://ghcr.io/k0rdent/kcm/charts/kcm<span class="w"> </span>--version<span class="w"> </span><span class="m">0</span>.1.0<span class="w"> </span>-n<span class="w"> </span>kcm-system<span class="w"> </span>--create-namespace<span class="w"> </span>-f<span class="w"> </span>kcm-values.yaml <span class="c1"># Résultat : </span> Pulled:<span class="w"> </span>ghcr.io/k0rdent/kcm/charts/kcm:0.1.0 Digest:<span class="w"> </span>sha256:accb6d1f9035d3dd46abbd86e10a7cd2c8bf235f8a77d079edeab58dfa9d38e8 NAME:<span class="w"> </span>kcm LAST<span class="w"> </span>DEPLOYED:<span class="w"> </span>Thu<span class="w"> </span>Feb<span class="w"> </span><span class="m">13</span><span class="w"> </span><span class="m">08</span>:02:08<span class="w"> </span><span class="m">2025</span> NAMESPACE:<span class="w"> </span>kcm-system STATUS:<span class="w"> </span>deployed REVISION:<span class="w"> </span><span class="m">1</span> TEST<span class="w"> </span>SUITE:<span class="w"> </span>None </code></pre></div> <p>Installe le chart Helm nommé kcm dans le namespace kcm-system (en créant le namespace si celui-ci n'existe pas) en utilisant la version 0.1.0 du chart. Elle applique également les configurations définies dans le fichier kcm-values.yaml pour personnaliser l'installation.</p> <div class="codehilite"><pre><span></span><code><span class="c1"># Check du déploiement</span> kubectl<span class="w"> </span>get<span class="w"> </span>pods<span class="w"> </span>-n<span class="w"> </span>kcm-system<span class="w"> </span> <span class="c1"># Cela peut prendre du temps pour avoir tous les composants installés, </span> <span class="c1"># car c&#39;est le contrôleur qui les installe.</span> NAME<span class="w"> </span>READY<span class="w"> </span>STATUS<span class="w"> </span>RESTARTS<span class="w"> </span>AGE azureserviceoperator-controller-manager-6b4dd86894-gvz8c<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>109s capa-controller-manager-64bbcb9f8-gx5qz<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>94s capi-controller-manager-66f8998ff5-tt9xd<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>3m4s capo-controller-manager-588f45c7cf-57tr2<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>76s capv-controller-manager-69f7fc65d8-pbgmt<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>64s capz-controller-manager-544845f786-q24nd<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>109s helm-controller-7644c4d5c4-98ff7<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>6m k0smotron-controller-manager-bootstrap-9fc48d76f-558fw<span class="w"> </span><span class="m">2</span>/2<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>2m40s k0smotron-controller-manager-control-plane-7df9bc7bf-hzlfv<span class="w"> </span><span class="m">2</span>/2<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>2m37s k0smotron-controller-manager-infrastructure-f7f94dd76-vpv8t<span class="w"> </span><span class="m">2</span>/2<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>84s kcm-cert-manager-895954d88-pmwd4<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>5m59s kcm-cert-manager-cainjector-685ffdf549-kz2jn<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>6m kcm-cert-manager-webhook-59ddc6b56-4ld68<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>6m kcm-cluster-api-operator-8487958779-ln8qd<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>3m48s kcm-controller-manager-7998cdb69-l7ksk<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>3m48s kcm-velero-b68fd5957-xcnrs<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>6m source-controller-6cd7676f7f-25hnw<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>6m <span class="c1"># Verification que projectsveltos est déployé et fonctionnement</span> kubectl<span class="w"> </span>get<span class="w"> </span>ns <span class="c1"># Résultat : </span> NAME<span class="w"> </span>STATUS<span class="w"> </span>AGE default<span class="w"> </span>Active<span class="w"> </span>18m k0s-autopilot<span class="w"> </span>Active<span class="w"> </span>17m kcm-system<span class="w"> </span>Active<span class="w"> </span>8m37s kube-node-lease<span class="w"> </span>Active<span class="w"> </span>18m kube-public<span class="w"> </span>Active<span class="w"> </span>18m kube-system<span class="w"> </span>Active<span class="w"> </span>18m mgmt<span class="w"> </span>Active<span class="w"> </span>4m49s projectsveltos<span class="w"> </span>Active<span class="w"> </span>5m16s kubectl<span class="w"> </span>get<span class="w"> </span>po<span class="w"> </span>-n<span class="w"> </span>projectsveltos <span class="c1"># Résultat : </span> kubectl<span class="w"> </span>get<span class="w"> </span>pods<span class="w"> </span>-n<span class="w"> </span>projectsveltos<span class="w"> </span> NAME<span class="w"> </span>READY<span class="w"> </span>STATUS<span class="w"> </span>RESTARTS<span class="w"> </span>AGE access-manager-56696cc7f-plxns<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>6m36s addon-controller-7c98776c79-wqbjw<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>6m36s classifier-manager-7b85f96469-swwjk<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>6m36s event-manager-67f6db7f44-btvmj<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>6m36s hc-manager-6d579d675f-lnxvb<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>6m36s sc-manager-55c99d494b-7d5cx<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>6m36s shard-controller-5ff9cd796d-hsm48<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>6m36s sveltos-agent-manager-7467959f4f-vd2sb<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>5m43s </code></pre></div> <p>Si <strong>Projectsveltos</strong> vous intéresse, vous pouvez consulter le blog d'Alter Way pour lire les articles à ce sujet.</p> <ul> <li><a href="https://blog.alterway.fr/creer-une-usine-a-clusters-kubernetes-partie-1.html">Créer une usine à clusters kubernetes - partie 1</a></li> <li><a href="https://blog.alterway.fr/creer-une-usine-a-clusters-kubernetes-partie-2.html">Créer une usine à clusters kubernetes - partie 2</a></li> <li><a href="https://blog.alterway.fr/creer-une-usine-a-clusters-kubernetes-partie-3.html">Créer une usine à clusters kubernetes - partie 3</a></li> </ul> <p><strong>1.3 Check des différents composant de k0rdent</strong></p> <p>Il faut que tout soit à <code>true</code></p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>Management,providertemplate,clustertemplate<span class="w"> </span>-n<span class="w"> </span>kcm-system <span class="c1"># Résultats :</span> NAME<span class="w"> </span>READY<span class="w"> </span>RELEASE<span class="w"> </span>AGE management.k0rdent.mirantis.com/kcm<span class="w"> </span>True<span class="w"> </span>kcm-0-1-0<span class="w"> </span>21m NAME<span class="w"> </span>VALID providertemplate.k0rdent.mirantis.com/cluster-api-0-1-0<span class="w"> </span><span class="nb">true</span> providertemplate.k0rdent.mirantis.com/cluster-api-provider-aws-0-1-0<span class="w"> </span><span class="nb">true</span> providertemplate.k0rdent.mirantis.com/cluster-api-provider-azure-0-1-0<span class="w"> </span><span class="nb">true</span> providertemplate.k0rdent.mirantis.com/cluster-api-provider-openstack-0-1-0<span class="w"> </span><span class="nb">true</span> providertemplate.k0rdent.mirantis.com/cluster-api-provider-vsphere-0-1-0<span class="w"> </span><span class="nb">true</span> providertemplate.k0rdent.mirantis.com/k0smotron-0-1-0<span class="w"> </span><span class="nb">true</span> providertemplate.k0rdent.mirantis.com/kcm-0-1-0<span class="w"> </span><span class="nb">true</span> providertemplate.k0rdent.mirantis.com/projectsveltos-0-45-0<span class="w"> </span><span class="nb">true</span> NAME<span class="w"> </span>VALID clustertemplate.k0rdent.mirantis.com/adopted-cluster-0-1-0<span class="w"> </span><span class="nb">true</span> clustertemplate.k0rdent.mirantis.com/aws-eks-0-1-0<span class="w"> </span><span class="nb">true</span> clustertemplate.k0rdent.mirantis.com/aws-hosted-cp-0-1-0<span class="w"> </span><span class="nb">true</span> clustertemplate.k0rdent.mirantis.com/aws-standalone-cp-0-1-0<span class="w"> </span><span class="nb">true</span> clustertemplate.k0rdent.mirantis.com/azure-aks-0-1-0<span class="w"> </span><span class="nb">true</span> clustertemplate.k0rdent.mirantis.com/azure-hosted-cp-0-1-0<span class="w"> </span><span class="nb">true</span> clustertemplate.k0rdent.mirantis.com/azure-standalone-cp-0-1-0<span class="w"> </span><span class="nb">true</span> clustertemplate.k0rdent.mirantis.com/openstack-standalone-cp-0-1-0<span class="w"> </span><span class="nb">true</span> clustertemplate.k0rdent.mirantis.com/vsphere-hosted-cp-0-1-0<span class="w"> </span><span class="nb">true</span> clustertemplate.k0rdent.mirantis.com/vsphere-standalone-cp-0-1-0<span class="w"> </span><span class="nb">true</span> </code></pre></div> <h3>2. Usage sur Azure</h3> <p><strong>2.1 Connexion à votre compte Azure</strong></p> <div class="codehilite"><pre><span></span><code>az<span class="w"> </span>login<span class="w"> </span> To<span class="w"> </span>sign<span class="w"> </span><span class="k">in</span>,<span class="w"> </span>use<span class="w"> </span>a<span class="w"> </span>web<span class="w"> </span>browser<span class="w"> </span>to<span class="w"> </span>open<span class="w"> </span>the<span class="w"> </span>page<span class="w"> </span>https://microsoft.com/devicelogin<span class="w"> </span>and<span class="w"> </span>enter<span class="w"> </span>the<span class="w"> </span>code<span class="w"> </span>C9EQUM9SG<span class="w"> </span>to<span class="w"> </span>authenticate. Retrieving<span class="w"> </span>tenants<span class="w"> </span>and<span class="w"> </span>subscriptions<span class="w"> </span><span class="k">for</span><span class="w"> </span>the<span class="w"> </span>selection... <span class="c1"># Choisir le tenant sur lequel vous allez manager vos AKS</span> <span class="c1"># Verifier les providers disponibles</span> az<span class="w"> </span>provider<span class="w"> </span>list<span class="w"> </span>--query<span class="w"> </span><span class="s2">&quot;[?registrationState==&#39;Registered&#39;]&quot;</span><span class="w"> </span>--output<span class="w"> </span>table<span class="w"> </span><span class="p">|</span><span class="w"> </span><span class="se">\</span> grep<span class="w"> </span>-e<span class="w"> </span><span class="s2">&quot;Microsoft.Compute&quot;</span><span class="w"> </span><span class="se">\</span> -e<span class="w"> </span><span class="s2">&quot;Microsoft.Network&quot;</span><span class="w"> </span><span class="se">\</span> -e<span class="w"> </span><span class="s2">&quot;Microsoft.ContainerService&quot;</span><span class="w"> </span><span class="se">\</span> -e<span class="w"> </span><span class="s2">&quot;Microsoft.ManagedIdentity&quot;</span><span class="w"> </span><span class="se">\</span> -e<span class="w"> </span><span class="s2">&quot;Microsoft.Authorization&quot;</span> <span class="c1"># Résultats</span> Microsoft.Compute<span class="w"> </span>Registered<span class="w"> </span>RegistrationRequired Microsoft.Network<span class="w"> </span>Registered<span class="w"> </span>RegistrationRequired Microsoft.ContainerService<span class="w"> </span>Registered<span class="w"> </span>RegistrationRequired Microsoft.ManagedIdentity<span class="w"> </span>Registered<span class="w"> </span>RegistrationRequired Microsoft.Authorization<span class="w"> </span>Registered<span class="w"> </span>RegistrationFree </code></pre></div> <p>Si vous avez déjà créé un cluster AKS sur Azure tout devrait être déjà enregistré</p> <p>Si ce n'est pas le cas utiliser la commande <code>az provider register --namespace [nom du service]</code> </p> <p>Par exemple <code>az provider register --namespace Microsoft.ContainerService</code> </p> <p><strong>2.2 Récupérer les information de la souscription courante</strong></p> <div class="codehilite"><pre><span></span><code><span class="nb">export</span><span class="w"> </span><span class="nv">SUBSCRIPTION_ID</span><span class="o">=</span><span class="k">$(</span>az<span class="w"> </span>account<span class="w"> </span>show<span class="w"> </span>--query<span class="w"> </span>id<span class="w"> </span>-o<span class="w"> </span>tsv<span class="k">)</span> <span class="nb">export</span><span class="w"> </span><span class="nv">TENANT_ID</span><span class="o">=</span><span class="k">$(</span>az<span class="w"> </span>account<span class="w"> </span>show<span class="w"> </span>--query<span class="w"> </span>tenantId<span class="w"> </span>-o<span class="w"> </span>tsv<span class="k">)</span> </code></pre></div> <p><strong>2.3 Création d'un compte de service avec le role contributeur sur la souscription</strong></p> <div class="codehilite"><pre><span></span><code><span class="nv">SP_INFO</span><span class="o">=</span><span class="k">$(</span>az<span class="w"> </span>ad<span class="w"> </span>sp<span class="w"> </span>create-for-rbac<span class="w"> </span>--role<span class="w"> </span>contributor<span class="w"> </span>--scopes<span class="o">=</span><span class="s2">&quot;/subscriptions/</span><span class="nv">$SUBSCRIPTION_ID</span><span class="s2">&quot;</span><span class="w"> </span>--output<span class="w"> </span>json<span class="k">)</span> <span class="nb">export</span><span class="w"> </span><span class="nv">AZURE_CLIENT_ID</span><span class="o">=</span><span class="k">$(</span><span class="nb">echo</span><span class="w"> </span><span class="nv">$SP_INFO</span><span class="w"> </span><span class="p">|</span><span class="w"> </span>jq<span class="w"> </span>-r<span class="w"> </span><span class="s1">&#39;.appId&#39;</span><span class="k">)</span> <span class="nb">export</span><span class="w"> </span><span class="nv">AZURE_CLIENT_SECRET</span><span class="o">=</span><span class="k">$(</span><span class="nb">echo</span><span class="w"> </span><span class="nv">$SP_INFO</span><span class="w"> </span><span class="p">|</span><span class="w"> </span>jq<span class="w"> </span>-r<span class="w"> </span><span class="s1">&#39;.password&#39;</span><span class="k">)</span> <span class="nb">export</span><span class="w"> </span><span class="nv">AZURE_TENANT_ID</span><span class="o">=</span><span class="k">$(</span><span class="nb">echo</span><span class="w"> </span><span class="nv">$SP_INFO</span><span class="w"> </span><span class="p">|</span><span class="w"> </span>jq<span class="w"> </span>-r<span class="w"> </span><span class="s1">&#39;.tenant&#39;</span><span class="k">)</span> <span class="nb">echo</span><span class="w"> </span><span class="nv">$AZURE_CLIENT_ID</span> <span class="nb">echo</span><span class="w"> </span><span class="nv">$AZURE_CLIENT_SECRET</span> <span class="nb">echo</span><span class="w"> </span><span class="nv">$AZURE_TENANT_ID</span> </code></pre></div> <p><strong>2.4 Création du secret pour l'authentification de kcm</strong> </p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: v1</span> <span class="s">kind: Secret</span> <span class="s">metadata:</span> <span class="s"> name: azure-cluster-identity-secret</span> <span class="s"> namespace: kcm-system</span> <span class="s"> labels:</span> <span class="s"> k0rdent.mirantis.com/component: &quot;kcm&quot;</span> <span class="s">stringData:</span> <span class="s"> clientSecret: $AZURE_CLIENT_SECRET # Password retrieved from the Service Principal</span> <span class="s">type: Opaque</span> <span class="s">EOF</span> </code></pre></div> <p><strong>2.5 Création du secret azure-aks-credential (pour le template AKS)</strong></p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: v1</span> <span class="s">kind: Secret</span> <span class="s">metadata:</span> <span class="s"> name: azure-aks-credential</span> <span class="s"> namespace: kcm-system</span> <span class="s"> labels:</span> <span class="s"> k0rdent.mirantis.com/component: &quot;kcm&quot;</span> <span class="s">stringData:</span> <span class="s"> AZURE_CLIENT_ID: &quot;${AZURE_CLIENT_ID}&quot;</span> <span class="s"> AZURE_CLIENT_SECRET: &quot;${AZURE_CLIENT_SECRET}&quot;</span> <span class="s"> AZURE_SUBSCRIPTION_ID: &quot;${SUBSCRIPTION_ID}&quot;</span> <span class="s"> AZURE_TENANT_ID: &quot;${AZURE_TENANT_ID}&quot;</span> <span class="s">type: Opaque</span> <span class="s">EOF</span> <span class="c1"># Résultat :</span> secret/azure-cluster-identity-secret<span class="w"> </span>created <span class="c1"># Vérifier le contenu du secret avec </span> kubectl<span class="w"> </span>view-secret<span class="w"> </span>azure-cluster-identity-secret<span class="w"> </span>-n<span class="w"> </span>kcm-system <span class="c1"># Résultat :</span> Viewing<span class="w"> </span>only<span class="w"> </span>available<span class="w"> </span>key:<span class="w"> </span>clientSecret xxxxxxxxxx </code></pre></div> <p><strong>2.6 Création des authentifications pour k0rdent et capz.</strong></p> <p>Tout est fait par références ce qui permet de ne pas avoir de mot de passe dans les manifestes</p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: infrastructure.cluster.x-k8s.io/v1beta1</span> <span class="s">kind: AzureClusterIdentity</span> <span class="s">metadata:</span> <span class="s"> name: azure-cluster-identity</span> <span class="s"> namespace: kcm-system</span> <span class="s"> labels:</span> <span class="s"> clusterctl.cluster.x-k8s.io/move-hierarchy: &quot;true&quot;</span> <span class="s"> k0rdent.mirantis.com/component: &quot;kcm&quot;</span> <span class="s">spec:</span> <span class="s"> allowedNamespaces: {}</span> <span class="s"> clientID: $AZURE_CLIENT_ID</span> <span class="s"> clientSecret:</span> <span class="s"> name: azure-cluster-identity-secret</span> <span class="s"> namespace: kcm-system</span> <span class="s"> tenantID: $AZURE_TENANT_ID</span> <span class="s"> type: ServicePrincipal</span> <span class="s">EOF</span> <span class="c1"># Résultat :</span> azureclusteridentity.infrastructure.cluster.x-k8s.io/azure-cluster-identity<span class="w"> </span>created <span class="c1"># Vérifier les informations</span> kubectl<span class="w"> </span>describe<span class="w"> </span>azureclusteridentity.infrastructure.cluster.x-k8s.io/azure-cluster-identity </code></pre></div> <p><strong>2.7 Création des crédences pour kcm</strong></p> <p>Tout se fait par référence aussi</p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: k0rdent.mirantis.com/v1alpha1</span> <span class="s">kind: Credential</span> <span class="s">metadata:</span> <span class="s"> name: azure-cluster-identity-cred</span> <span class="s"> namespace: kcm-system</span> <span class="s">spec:</span> <span class="s"> identityRef:</span> <span class="s"> apiVersion: infrastructure.cluster.x-k8s.io/v1beta1</span> <span class="s"> kind: AzureClusterIdentity</span> <span class="s"> name: azure-cluster-identity</span> <span class="s"> namespace: kcm-system</span> <span class="s">EOF</span> </code></pre></div> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: k0rdent.mirantis.com/v1alpha1</span> <span class="s">kind: Credential</span> <span class="s">metadata:</span> <span class="s"> name: azure-aks-credential</span> <span class="s"> namespace: kcm-system</span> <span class="s">spec:</span> <span class="s"> description: Azure AKS credentials</span> <span class="s"> identityRef:</span> <span class="s"> apiVersion: v1</span> <span class="s"> kind: Secret</span> <span class="s"> name: azure-aks-credential</span> <span class="s"> namespace: kcm-system</span> <span class="s">EOF</span> <span class="c1"># Résultat :</span> credential.k0rdent.mirantis.com/azure-cluster-identity-cred<span class="w"> </span>created <span class="c1"># Check </span> kubectl<span class="w"> </span>describe<span class="w"> </span>credential.k0rdent.mirantis.com/azure-cluster-identity-cred<span class="w"> </span> <span class="c1"># Regardez les informations du status</span> Status: <span class="w"> </span>Conditions: <span class="w"> </span>Last<span class="w"> </span>Transition<span class="w"> </span>Time:<span class="w"> </span><span class="m">2025</span>-02-13T09:44:25Z <span class="w"> </span>Message:<span class="w"> </span>Credential<span class="w"> </span>is<span class="w"> </span>ready <span class="w"> </span>Reason:<span class="w"> </span>Succeeded <span class="w"> </span>Status:<span class="w"> </span>True <span class="w"> </span>Type:<span class="w"> </span>CredentialReady <span class="w"> </span>Ready:<span class="w"> </span><span class="nb">true</span> </code></pre></div> <p><strong>2.8 Choix de la localisation du cluster</strong></p> <p>Nous prendons par exemple <code>northeurope</code>. Prenez celle qui vous sied le mieux</p> <p><strong>2.9 Choix du template de cluster</strong></p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>clustertemplate<span class="w"> </span>-n<span class="w"> </span>kcm-system<span class="w"> </span><span class="p">|</span><span class="w"> </span>grep<span class="w"> </span>azure <span class="c1"># Résultat :</span> azure-aks-0-1-0<span class="w"> </span><span class="nb">true</span> azure-hosted-cp-0-1-0<span class="w"> </span><span class="nb">true</span> azure-standalone-cp-0-1-0<span class="w"> </span><span class="nb">true</span> </code></pre></div> <ul> <li><strong>azure-standalone-cp-0-1-0</strong> : Permet de déployer un cluster k0s sur Azure </li> <li><strong>azure-hosted-cp-0-1-0</strong> : Permet de déployer un cluster kubernetes dont le control plane est géré dans le cluster d'administration (k0smotron)</li> <li><strong>azure-aks-0-1-0</strong> : Déploiement d'un cluster AKS classique</li> </ul> <hr /> <h3>3. Test du template azure-aks-0-1-0</h3> <hr /> <p><strong>Objectif :</strong> Déployer un cluster Kubernetes managé via Azure Kubernetes Service (AKS). Cette approche tire parti de la robustesse d’AKS en termes de scalabilité, sécurité et intégration native avec les services Azure.</p> <p><strong>Points forts :</strong></p> <p>Simplicité de déploiement : Intégration directe avec le portail Azure et ses API. Gestion optimisée des ressources : Évolutivité automatique et surveillance native. Sécurité renforcée : Conformité aux standards Azure et mise à jour des correctifs gérée par Microsoft. <strong>Cas d’usage :</strong> Idéal pour des environnements de production nécessitant une haute disponibilité et une maintenance réduite, avec une prise en charge native par le cloud.</p> <p><center> <image src="/images/k0rdent/azure-aks.png"> </center></p> <p><strong>3.1 Création du déploiement du cluster</strong> </p> <p>Notes : Faites bien attention au type des machines les nom sont sensible à la casse.</p> <p>ex: standard_a4_v2 ne fonctionnera pas il faut avoir Standard_A4_v2</p> <p>Pour connaitre tout les paramètres possible au niveau de l'attribut config il faut regarder le fichier <code>values.yaml</code> situé dans le répertoire templates/cluster/azure-aks du repo <code>https://github.com/k0rdent/kcm.git</code></p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: k0rdent.mirantis.com/v1alpha1</span> <span class="s">kind: ClusterDeployment</span> <span class="s">metadata:</span> <span class="s"> name: aks-by-k0rdent</span> <span class="s"> namespace: kcm-system</span> <span class="s">spec:</span> <span class="s"> template: azure-aks-0-1-0</span> <span class="s"> credential: azure-aks-credential</span> <span class="s"> propagateCredentials: false</span> <span class="s"> config:</span> <span class="s"> clusterLabels: {}</span> <span class="s"> location: &quot;northeurope&quot;</span> <span class="s"> machinePools:</span> <span class="s"> system:</span> <span class="s"> count: 1</span> <span class="s"> vmSize: Standard_A4_v2</span> <span class="s"> user:</span> <span class="s"> count: 1</span> <span class="s"> vmSize: Standard_A4_v2</span> <span class="s">EOF</span> <span class="c1"># Résultats : </span> clusterdeployment.k0rdent.mirantis.com/aks-by-k0rdent<span class="w"> </span>created </code></pre></div> <p><strong>3.2 Suivi de la création du cluster</strong></p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>clusterdeployment <span class="c1"># Résultat</span> NAME<span class="w"> </span>READY<span class="w"> </span>STATUS aks-by-k0rdent<span class="w"> </span>False<span class="w"> </span>aks-by-k0rdent:<span class="w"> </span>Waiting<span class="w"> </span><span class="k">for</span><span class="w"> </span>control<span class="w"> </span>plane<span class="w"> </span>provider<span class="w"> </span>to<span class="w"> </span>indicate<span class="w"> </span>the<span class="w"> </span>control<span class="w"> </span>plane<span class="w"> </span>has<span class="w"> </span>been<span class="w"> </span>initialized.<span class="w"> </span>aks-by-k0rdent.<span class="w"> </span>aks-by-k0rdent. </code></pre></div> <p>La clusterAPI crée l'insfrastructure Azure pour déployer l'AKS managé</p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>resourcegroups.resources.azure.com <span class="c1"># Résultat</span> NAME<span class="w"> </span>READY<span class="w"> </span>SEVERITY<span class="w"> </span>REASON<span class="w"> </span>MESSAGE aks-by-k0rdent<span class="w"> </span>True<span class="w"> </span>Succeeded </code></pre></div> <p><center> <image src="/images/k0rdent/resourcegroup.png"> </center></p> <p>On voit que le cluster AKS <code>aks-by-k0rdent</code> a bien été créé </p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>managedclusters NAME<span class="w"> </span>READY<span class="w"> </span>SEVERITY<span class="w"> </span>REASON<span class="w"> </span>MESSAGE aks-by-k0rdent<span class="w"> </span>True<span class="w"> </span>Succeeded </code></pre></div> <p><center> <image src="/images/k0rdent/aks-by-k0rdent.png"> </center></p> <ul> <li>Node machinePools</li> </ul> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>azureasomanagedmachinepools <span class="c1"># Résultat : </span> NAME<span class="w"> </span>AGE aks-by-k0rdent-system<span class="w"> </span>18m aks-by-k0rdent-user<span class="w"> </span>18m </code></pre></div> <p><center> <image src="/images/k0rdent/aks-by-k0rdent-nodepools.png"> </center></p> <p>Au final on a :</p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>clusterdeployment <span class="c1"># Résultat :</span> NAME<span class="w"> </span>READY<span class="w"> </span>STATUS aks-by-k0rdent<span class="w"> </span>True<span class="w"> </span>ClusterDeployment<span class="w"> </span>is<span class="w"> </span>ready </code></pre></div> <p><strong>3.3 Récupération du kubeconfig</strong></p> <div class="codehilite"><pre><span></span><code>az<span class="w"> </span>aks<span class="w"> </span>get-credentials<span class="w"> </span>--resource-group<span class="w"> </span>aks-by-k0rdent<span class="w"> </span>--name<span class="w"> </span>aks-by-k0rdent<span class="w"> </span>--overwrite-existing<span class="w"> </span>-f<span class="w"> </span>aks-by-k0rdent.conf </code></pre></div> <p><strong>3.4 Test du cluster</strong></p> <div class="codehilite"><pre><span></span><code><span class="nv">KUBECONFIG</span><span class="o">=</span>aks-by-k0rdent.conf<span class="w"> </span>kubectl<span class="w"> </span>get<span class="w"> </span>nodes <span class="c1"># Résultat : </span> NAME<span class="w"> </span>STATUS<span class="w"> </span>ROLES<span class="w"> </span>AGE<span class="w"> </span>VERSION aks-systempool-34952453-vmss000000<span class="w"> </span>Ready<span class="w"> </span>&lt;none&gt;<span class="w"> </span>14m<span class="w"> </span>v1.31.1 aks-userpool-34952453-vmss000000<span class="w"> </span>Ready<span class="w"> </span>&lt;none&gt;<span class="w"> </span>14m<span class="w"> </span>v1.31.1 </code></pre></div> <p><strong>3.5 Nettoyage</strong></p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>delete<span class="w"> </span>clusterdeployments<span class="w"> </span>aks-by-k0rdent </code></pre></div> <p>Toutes les resources Azure créées sont supprimées</p> <hr /> <h3>4. Test du Template azure-standalone-cp-0-1-0</h3> <hr /> <p>Ce template permet de créer un cluster kubernetes standard le control plane et worker en VM.</p> <p><strong>Objectif :</strong> Déployer un cluster Kubernetes avec un control plane dédié, entièrement indépendant des services managés d’Azure. Cette configuration permet une personnalisation poussée et une isolation accrue des composants critiques.</p> <p><strong>Points forts :</strong></p> <p>Personnalisation avancée : Permet de définir des configurations spécifiques pour le control plane sans être limité par les contraintes d’un service managé. Isolation et sécurité : Un control plane autonome peut offrir une isolation renforcée, essentielle pour des environnements sensibles. Contrôle total sur la configuration : Les équipes peuvent affiner chaque aspect du déploiement pour répondre à des exigences précises. Cas d’usage : Particulièrement intéressant pour des scénarios où la personnalisation et l’optimisation fine du contrôle sont nécessaires, notamment dans des contextes de R&amp;D ou d’infrastructures hybrides.</p> <p><center> <image src="/images/k0rdent/azure-standalone-cp-0-1-0.png"> </center></p> <p><strong>4.1 Création du manifeste de déploiement du cluster</strong></p> <div class="codehilite"><pre><span></span><code><span class="nb">export</span><span class="w"> </span><span class="nv">CLUSTER_DEPLOYMENT_NAME</span><span class="o">=</span><span class="s2">&quot;standalone-cp-azure&quot;</span> kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: k0rdent.mirantis.com/v1alpha1</span> <span class="s">kind: ClusterDeployment</span> <span class="s">metadata:</span> <span class="s"> name: &quot;${CLUSTER_DEPLOYMENT_NAME}&quot;</span> <span class="s"> namespace: kcm-system</span> <span class="s">spec:</span> <span class="s"> template: azure-standalone-cp-0-1-0</span> <span class="s"> credential: azure-cluster-identity-cred</span> <span class="s"> propagateCredentials: true</span> <span class="s"> config:</span> <span class="s"> clusterLabels: {}</span> <span class="s"> controlPlaneNumber: 1</span> <span class="s"> workersNumber: 1</span> <span class="s"> location: &quot;northeurope&quot;</span> <span class="s"> subscriptionID: &quot;${SUBSCRIPTION_ID}&quot;</span> <span class="s"> clusterIdentity:</span> <span class="s"> name: &quot;azure-cluster-identity&quot;</span> <span class="s"> controlPlane:</span> <span class="s"> vmSize: Standard_A4_v2</span> <span class="s"> worker:</span> <span class="s"> vmSize: Standard_A4_v2</span> <span class="s"> #tenantID: &quot;${AZURE_TENANT_ID}&quot;</span> <span class="s"> #clientID: &quot;${AZURE_CLIENT_ID}&quot;</span> <span class="s"> #clientSecret: &quot;${AZURE_CLIENT_SECRET}&quot;</span> <span class="s">EOF</span> </code></pre></div> <p>Dans ce cas, nous allons avoir la création sur azure d'un esemble de resource permettant d'avoir une cluster kubernetes complet : noeuds de "control plane" et worker. Dans notre cas 1 noued de control plane et 1 noeud worker.</p> <p>Composants créés :</p> <table> <thead> <tr> <th>Ressource</th> <th>Type</th> </tr> </thead> <tbody> <tr> <td>pip-standalone-cp-azure-apiserver</td> <td>Public IP address</td> </tr> <tr> <td>pip-standalone-cp-azure-node-natgw</td> <td>Public IP address</td> </tr> <tr> <td>standalone-cp-azure-controlplane-nsg</td> <td>Network security group</td> </tr> <tr> <td>standalone-cp-azure-cp-0</td> <td>Virtual machine</td> </tr> <tr> <td>standalone-cp-azure-cp-0-nic</td> <td>Network Interface</td> </tr> <tr> <td>standalone-cp-azure-cp-0_OSDisk</td> <td>Disk</td> </tr> <tr> <td>standalone-cp-azure-md-n5rsj-2kqvm</td> <td>Virtual machine</td> </tr> <tr> <td>standalone-cp-azure-md-n5rsj-2kqvm-nic</td> <td>Network Interface</td> </tr> <tr> <td>standalone-cp-azure-md-n5rsj-2kqvm_OSDisk</td> <td>Disk</td> </tr> <tr> <td>standalone-cp-azure-node-natgw</td> <td>NAT gateway</td> </tr> <tr> <td>standalone-cp-azure-node-nsg</td> <td>Network security group</td> </tr> <tr> <td>standalone-cp-azure-node-routetable</td> <td>Route table</td> </tr> <tr> <td>standalone-cp-azure-public-lb</td> <td>Load balancer</td> </tr> <tr> <td>standalone-cp-azure-vnet</td> <td>Virtual network</td> </tr> </tbody> </table> <p><center> <image src="/images/k0rdent/standalone-cp-azure.png"> </center></p> <p><strong>4.2 Vérifications</strong></p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>resourcegroups,virtualnetworks,virtualnetworkssubnets,natgateways <span class="c1"># Résultat :</span> NAME<span class="w"> </span>READY<span class="w"> </span>SEVERITY<span class="w"> </span>REASON<span class="w"> </span>MESSAGE resourcegroup.resources.azure.com/standalone-cp-azure<span class="w"> </span>True<span class="w"> </span>Succeeded NAME<span class="w"> </span>READY<span class="w"> </span>SEVERITY<span class="w"> </span>REASON<span class="w"> </span>MESSAGE virtualnetwork.network.azure.com/standalone-cp-azure-vnet<span class="w"> </span>True<span class="w"> </span>Succeeded NAME<span class="w"> </span>READY<span class="w"> </span>SEVERITY<span class="w"> </span>REASON<span class="w"> </span>MESSAGE virtualnetworkssubnet.network.azure.com/standalone-cp-azure-vnet-standalone-cp-azure-controlplane-subnet<span class="w"> </span>True<span class="w"> </span>Succeeded virtualnetworkssubnet.network.azure.com/standalone-cp-azure-vnet-standalone-cp-azure-node-subnet<span class="w"> </span>True<span class="w"> </span>Succeeded NAME<span class="w"> </span>READY<span class="w"> </span>SEVERITY<span class="w"> </span>REASON<span class="w"> </span>MESSAGE natgateway.network.azure.com/standalone-cp-azure-node-natgw<span class="w"> </span>True<span class="w"> </span>Succeeded </code></pre></div> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>azuremachines <span class="c1"># Résultat :</span> NAME<span class="w"> </span>READY<span class="w"> </span>SEVERITY<span class="w"> </span>REASON<span class="w"> </span>STATE<span class="w"> </span>AGE standalone-cp-azure-cp-0<span class="w"> </span>False<span class="w"> </span>Info<span class="w"> </span>Creating<span class="w"> </span>Succeeded<span class="w"> </span>85s standalone-cp-azure-md-jmnmx-qrqxt<span class="w"> </span>False<span class="w"> </span>Info<span class="w"> </span>WaitingForBootstrapData<span class="w"> </span>67s devops@herlec-icdc:~$<span class="w"> </span>kubectl<span class="w"> </span>get<span class="w"> </span>azuremachines <span class="c1"># Résultat :</span> NAME<span class="w"> </span>READY<span class="w"> </span>SEVERITY<span class="w"> </span>REASON<span class="w"> </span>STATE<span class="w"> </span>AGE standalone-cp-azure-cp-0<span class="w"> </span>True<span class="w"> </span>Succeeded<span class="w"> </span>3m3s standalone-cp-azure-md-jmnmx-qrqxt<span class="w"> </span>False<span class="w"> </span>Info<span class="w"> </span>Creating<span class="w"> </span>Succeeded<span class="w"> </span>2m45s kubectl<span class="w"> </span>get<span class="w"> </span>azuremachines <span class="c1"># Résultat :</span> NAME<span class="w"> </span>READY<span class="w"> </span>SEVERITY<span class="w"> </span>REASON<span class="w"> </span>STATE<span class="w"> </span>AGE standalone-cp-azure-cp-0<span class="w"> </span>True<span class="w"> </span>Succeeded<span class="w"> </span>21m standalone-cp-azure-md-n5rsj-2kqvm<span class="w"> </span>True<span class="w"> </span>Succeeded<span class="w"> </span>20m </code></pre></div> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>clusterdeployments <span class="c1"># Résultat :</span> NAME<span class="w"> </span>READY<span class="w"> </span>STATUS standalone-cp-azure<span class="w"> </span>True<span class="w"> </span>ClusterDeployment<span class="w"> </span>is<span class="w"> </span>ready </code></pre></div> <p><strong>4.3 Récupération du kubeconfig</strong></p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>standalone-cp-azure-kubeconfig<span class="w"> </span>-n<span class="w"> </span>kcm-system <span class="c1"># Utilisation du plugin view-secret</span> kubectl<span class="w"> </span>view-secret<span class="w"> </span>standalone-cp-azure-kubeconfig<span class="w"> </span>-n<span class="w"> </span>kcm-system<span class="w"> </span>&gt;<span class="w"> </span>kubeconfig.yaml </code></pre></div> <p><strong>4.4 Test du cluster</strong></p> <div class="codehilite"><pre><span></span><code><span class="nv">KUBECONFIG</span><span class="o">=</span>kubeconfig.yaml<span class="w"> </span>kubectl<span class="w"> </span>get<span class="w"> </span>nodes <span class="c1"># Résultat :</span> NAME<span class="w"> </span>STATUS<span class="w"> </span>ROLES<span class="w"> </span>AGE<span class="w"> </span>VERSION standalone-cp-azure-cp-0<span class="w"> </span>Ready<span class="w"> </span>control-plane<span class="w"> </span>25m<span class="w"> </span>v1.31.5+k0s standalone-cp-azure-md-n5rsj-2kqvm<span class="w"> </span>Ready<span class="w"> </span>&lt;none&gt;<span class="w"> </span>25m<span class="w"> </span>v1.31.5+k0s </code></pre></div> <div class="codehilite"><pre><span></span><code><span class="nv">KUBECONFIG</span><span class="o">=</span>kubeconfig.yaml<span class="w"> </span>kubectl<span class="w"> </span>get<span class="w"> </span>po<span class="w"> </span>-A NAMESPACE<span class="w"> </span>NAME<span class="w"> </span>READY<span class="w"> </span>STATUS<span class="w"> </span>RESTARTS<span class="w"> </span>AGE kube-system<span class="w"> </span>calico-kube-controllers-6cd7d8cc9f-bpfzh<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>27m kube-system<span class="w"> </span>calico-node-4cpmm<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>27m kube-system<span class="w"> </span>calico-node-ktjxt<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>26m kube-system<span class="w"> </span>cloud-controller-manager-765494fb6f-b67bb<span class="w"> </span><span class="m">0</span>/1<span class="w"> </span>CrashLoopBackOff<span class="w"> </span><span class="m">9</span><span class="w"> </span><span class="o">(</span>58s<span class="w"> </span>ago<span class="o">)</span><span class="w"> </span>27m kube-system<span class="w"> </span>cloud-node-manager-8qpvz<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>27m kube-system<span class="w"> </span>cloud-node-manager-hvzc8<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>26m kube-system<span class="w"> </span>coredns-645c5d6f5b-m7jxq<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>26m kube-system<span class="w"> </span>coredns-645c5d6f5b-qnnzg<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>26m kube-system<span class="w"> </span>csi-azuredisk-controller-54ff6d4cb7-h4sg5<span class="w"> </span><span class="m">1</span>/6<span class="w"> </span>CrashLoopBackOff<span class="w"> </span><span class="m">21</span><span class="w"> </span><span class="o">(</span>76s<span class="w"> </span>ago<span class="o">)</span><span class="w"> </span>5m12s kube-system<span class="w"> </span>csi-azuredisk-controller-54ff6d4cb7-ppggp<span class="w"> </span><span class="m">1</span>/6<span class="w"> </span>CrashLoopBackOff<span class="w"> </span><span class="m">21</span><span class="w"> </span><span class="o">(</span>75s<span class="w"> </span>ago<span class="o">)</span><span class="w"> </span>5m12s kube-system<span class="w"> </span>csi-azuredisk-node-fz4x6<span class="w"> </span><span class="m">3</span>/3<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>5m12s kube-system<span class="w"> </span>csi-azuredisk-node-q5pj8<span class="w"> </span><span class="m">3</span>/3<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>5m12s kube-system<span class="w"> </span>kube-proxy-dbq2r<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>26m kube-system<span class="w"> </span>kube-proxy-hvtkv<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>27m kube-system<span class="w"> </span>metrics-server-78c4ccbc7f-6ng5r<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>27m projectsveltos<span class="w"> </span>sveltos-agent-manager-789964cb68-6vqtk<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>27m </code></pre></div> <p><strong>4.5 Gestion des erreurs</strong> </p> <p>pour le <strong>cloud-controller-manager</strong></p> <div class="codehilite"><pre><span></span><code>Run:<span class="w"> </span>Cloud<span class="w"> </span>provider<span class="w"> </span>azure<span class="w"> </span>could<span class="w"> </span>not<span class="w"> </span>be<span class="w"> </span>initialized<span class="w"> </span>dynamically<span class="w"> </span>from<span class="w"> </span>secret<span class="w"> </span>kube-system/azure-cloud- provider:<span class="w"> </span>NewCloudFromSecret:<span class="w"> </span>failed<span class="w"> </span>to<span class="w"> </span>get<span class="w"> </span>config<span class="w"> </span>from<span class="w"> </span>secret<span class="w"> </span>kube-system/azure-cloud-provider:<span class="w"> </span>secrets<span class="w"> </span><span class="s2">&quot;azure-cloud-provider&quot;</span><span class="w"> </span>not<span class="w"> </span>found </code></pre></div> <p>La doc n'est pas claire sur ce sujet : (https://docs.k0rdent.io/latest/admin-credentials/?h=cloud+controller+manager#cloud-provider-credentials-propagation)</p> <p><strong>4.6 Tentative de patching à la main</strong></p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>view-secret<span class="w"> </span>standalone-cp-azure-cp-mt-azure-json </code></pre></div> <p>J'ai créé sur le cluster le secret <code>azure-cloud-provider</code> dans le ns <code>kube-system</code> avec les information suivantes :</p> <div class="codehilite"><pre><span></span><code><span class="nv">KUBECONFIG</span><span class="o">=</span>kubeconfig.yaml<span class="w"> </span>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: v1</span> <span class="s">kind: Secret</span> <span class="s">metadata:</span> <span class="s"> name: azure-cloud-provider</span> <span class="s"> namespace: kube-system</span> <span class="s">type: Opaque</span> <span class="s">stringData:</span> <span class="s"> cloud-config: |-</span> <span class="s"> {</span> <span class="s"> &quot;cloud&quot;: &quot;AzurePublicCloud&quot;,</span> <span class="s"> &quot;tenantId&quot;: &quot;${AZURE_TENANT_ID}&quot;,</span> <span class="s"> &quot;subscriptionId&quot;: &quot;${AZURE_SUBSCRIPTION_ID}&quot;,</span> <span class="s"> &quot;aadClientId&quot;: &quot;${AZURE_CLIENT_ID}&quot;,</span> <span class="s"> &quot;aadClientSecret&quot;: &quot;${AZURE_CLIENT_SECRET}&quot;,</span> <span class="s"> &quot;resourceGroup&quot;: &quot;${CLUSTER_DEPLOYMENT_NAME}&quot;,</span> <span class="s"> &quot;securityGroupName&quot;: &quot;${CLUSTER_DEPLOYMENT_NAME}-node-nsg&quot;,</span> <span class="s"> &quot;securityGroupResourceGroup&quot;: &quot;${CLUSTER_DEPLOYMENT_NAME}&quot;,</span> <span class="s"> &quot;location&quot;: &quot;northeurope&quot;,</span> <span class="s"> &quot;vmType&quot;: &quot;vmss&quot;,</span> <span class="s"> &quot;vnetName&quot;: &quot;${CLUSTER_DEPLOYMENT_NAME}-vnet&quot;,</span> <span class="s"> &quot;vnetResourceGroup&quot;: &quot;${CLUSTER_DEPLOYMENT_NAME}&quot;,</span> <span class="s"> &quot;subnetName&quot;: &quot;${CLUSTER_DEPLOYMENT_NAME}-node-subnet&quot;,</span> <span class="s"> &quot;routeTableName&quot;: &quot;${CLUSTER_DEPLOYMENT_NAME}-node-routetable&quot;,</span> <span class="s"> &quot;loadBalancerSku&quot;: &quot;Standard&quot;,</span> <span class="s"> &quot;loadBalancerName&quot;: &quot;&quot;,</span> <span class="s"> &quot;maximumLoadBalancerRuleCount&quot;: 250,</span> <span class="s"> &quot;useManagedIdentityExtension&quot;: false,</span> <span class="s"> &quot;useInstanceMetadata&quot;: true</span> <span class="s"> }</span> <span class="s">EOF</span> </code></pre></div> <div class="codehilite"><pre><span></span><code><span class="nv">KUBECONFIG</span><span class="o">=</span>kubeconfig.yaml<span class="w"> </span>kubectl<span class="w"> </span>delete<span class="w"> </span>po<span class="w"> </span>-n<span class="w"> </span>kube-system<span class="w"> </span>-l<span class="w"> </span><span class="nv">component</span><span class="o">=</span>cloud-controller-manager <span class="nv">KUBECONFIG</span><span class="o">=</span>kubeconfig.yaml<span class="w"> </span>kubectl<span class="w"> </span>delete<span class="w"> </span>po<span class="w"> </span>-n<span class="w"> </span>kube-system<span class="w"> </span>-l<span class="w"> </span><span class="nv">app</span><span class="o">=</span>csi-azuredisk-node </code></pre></div> <div class="codehilite"><pre><span></span><code><span class="nv">KUBECONFIG</span><span class="o">=</span>kubeconfig.yaml<span class="w"> </span>kubectl<span class="w"> </span>get<span class="w"> </span>po<span class="w"> </span>-n<span class="w"> </span>kube-system <span class="c1"># Résultat </span> NAME<span class="w"> </span>READY<span class="w"> </span>STATUS<span class="w"> </span>RESTARTS<span class="w"> </span>AGE calico-kube-controllers-6cd7d8cc9f-ldl9q<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>82m calico-node-fwssw<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>82m calico-node-t5ppw<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>81m cloud-controller-manager-765494fb6f-5c5kk<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>14m cloud-node-manager-j4f4f<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>81m cloud-node-manager-kmkfn<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>82m coredns-645c5d6f5b-mnnfz<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>81m coredns-645c5d6f5b-wkfrb<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>81m csi-azuredisk-controller-54ff6d4cb7-6bfr5<span class="w"> </span><span class="m">6</span>/6<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>13m csi-azuredisk-controller-54ff6d4cb7-jm2rj<span class="w"> </span><span class="m">6</span>/6<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>13m csi-azuredisk-node-ckvd4<span class="w"> </span><span class="m">3</span>/3<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>30m csi-azuredisk-node-ps79t<span class="w"> </span><span class="m">3</span>/3<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>30m kube-proxy-fk7mt<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>81m kube-proxy-nqvcd<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>82m metrics-server-78c4ccbc7f-5hvpb<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>82m </code></pre></div> <p><strong>All Good !</strong></p> <p>Fin du test <strong>azure-standalone-cp-0-1-0</strong></p> <p><strong>4.7 Cleaning</strong></p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>delete<span class="w"> </span>clusterdeployment<span class="w"> </span>standalone-cp-azure <span class="c1"># Résultat :</span> clusterdeployment.k0rdent.mirantis.com<span class="w"> </span><span class="s2">&quot;standalone-cp-azure&quot;</span><span class="w"> </span>deleted <span class="c1"># CA PREND DU TEMPS ! (Nettoyage de toutes les ressources Azure)</span> </code></pre></div> <hr /> <h3>5. Test du template azure-hosted-cp-0-1-0</h3> <hr /> <p><center> <image src="/images/k0rdent/azure-hosted-cp-0-1-0.png"> </center></p> <p>En pré-requis il faut du stockage sur le cluster de management </p> <p>Je vais faire très simple et installer localpath-provisioner de rancher</p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f<span class="w"> </span>https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.31/deploy/local-path-storage.yaml kubectl<span class="w"> </span>patch<span class="w"> </span>storageclass<span class="w"> </span>local-path<span class="w"> </span>-p<span class="w"> </span><span class="s1">&#39;{&quot;metadata&quot;: {&quot;annotations&quot;:{&quot;storageclass.kubernetes.io/is-default-class&quot;:&quot;true&quot;}}}&#39;</span> </code></pre></div> <p>Ce template permet de créer un cluster kubernetes dont le control plane est managé par k0smotron dans le cluster de management. Les workers sont déployés sous forme de VMs Azure.</p> <p>Le cluster de management se trouve dans un resource group qui s'appelle <code>aaaaa-herlec-icdc</code></p> <p>J'ai :</p> <ul> <li>un vnet : herlec-icdc-vnet</li> <li>un subnet : default</li> <li>un nsg : herlec-icdc-nsg</li> <li>une route table herlec-icdc-routetable</li> </ul> <p><strong>5.1 Création du manifeste de déploiement du cluster</strong></p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: k0rdent.mirantis.com/v1alpha1</span> <span class="s">kind: ClusterDeployment</span> <span class="s">metadata:</span> <span class="s"> name: azure-hosted-cp</span> <span class="s">spec:</span> <span class="s"> template: azure-hosted-cp-0-1-0</span> <span class="s"> credential: azure-cluster-identity-cred</span> <span class="s"> config:</span> <span class="s"> clusterLabels: {}</span> <span class="s"> location: &quot;westeurope&quot;</span> <span class="s"> subscriptionID: &quot;${AZURE_SUBSCRIPTION_ID}&quot;</span> <span class="s"> vmSize: Standard_A4_v2</span> <span class="s"> workersNumber: 2</span> <span class="s"> resourceGroup: aaaaa-herlec-icdc</span> <span class="s"> network:</span> <span class="s"> vnetName: herlec-icdc-vnet</span> <span class="s"> nodeSubnetName: default</span> <span class="s"> routeTableName: herlec-icdc-routetable</span> <span class="s"> securityGroupName: herlec-icdc-nsg</span> <span class="s"> k0smotron:</span> <span class="s"> service:</span> <span class="s"> type: ClusterIP</span> <span class="s"> #apiPort: 30443</span> <span class="s"> #konnectivityPort: 30132</span> <span class="s">EOF</span> </code></pre></div> <p>J'ai une erreur concernant k0smotron qui n'a pas d'adresse IP sur son service <strong>loadbalancer</strong>. Il faudra que je regarde si au niveau du déploiement on peut gérer ce paramètre. Je vais la forcer avec l'adresse ip publique et privée de ma VM.</p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>svc<span class="w"> </span>mc-azure-hosted-cp-lb<span class="w"> </span>-n<span class="w"> </span>kcm-system <span class="c1"># Résultat :</span> mc-azure-hosted-cp-lb<span class="w"> </span>LoadBalancer<span class="w"> </span><span class="m">10</span>.104.136.148<span class="w"> </span>&lt;pending&gt;<span class="w"> </span><span class="m">6443</span>:30661/TCP,8132:30619/TCP<span class="w"> </span>58m </code></pre></div> <ul> <li>Patching</li> </ul> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>patch<span class="w"> </span>svc<span class="w"> </span>kmc-azure-hosted-cp-lb<span class="w"> </span>--type<span class="o">=</span><span class="s1">&#39;merge&#39;</span><span class="w"> </span>-p<span class="w"> </span><span class="s1">&#39;{&quot;spec&quot;:{&quot;externalIPs&quot;:[&quot;10.0.0.4&quot;, &quot;13.xx.xx.xx&quot;]}}&#39;</span> </code></pre></div> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>svc<span class="w"> </span>mc-azure-hosted-cp-lb<span class="w"> </span>-n<span class="w"> </span>kcm-system <span class="c1"># Résultat :</span> kmc-azure-hosted-cp-lb<span class="w"> </span>LoadBalancer<span class="w"> </span><span class="m">10</span>.104.136.148<span class="w"> </span><span class="m">10</span>.0.0.4,13.xxx.xx.xx<span class="w"> </span><span class="m">6443</span>:30661/TCP,8132:30619/TCP<span class="w"> </span>64m </code></pre></div> <p><strong>5.2 Méthode alternative</strong></p> <p>Même comme ca, en forçant l'adresse IP sur l'ip publique de la VM ca ne marche pas. </p> <p>Je vais donc redéployer kcml sur un cluster d'administration <strong>basé sur AKS</strong>. de cette manière l'intégration à l'eco-système Azure sera plus simple. Stockage, loadbalancers.</p> <p>Je vais créer un vnet, subnet, Route table et un nsg</p> <div class="codehilite"><pre><span></span><code>-<span class="w"> </span>resourcegroup<span class="w"> </span>:<span class="w"> </span><span class="m">001</span>-kcm-k8s-hosted-cp -<span class="w"> </span>un<span class="w"> </span>vnet<span class="w"> </span>:<span class="w"> </span><span class="m">001</span>-kcm-k8s-hosted-cp-vnet -<span class="w"> </span>un<span class="w"> </span>subnet<span class="w"> </span>:<span class="w"> </span><span class="m">001</span>-kcm-k8s-hosted-cp-subnet-001 -<span class="w"> </span>un<span class="w"> </span>nsg<span class="w"> </span>:<span class="w"> </span><span class="m">001</span>-kcm-k8s-hosted-cp-nsg-001 -<span class="w"> </span>une<span class="w"> </span>route<span class="w"> </span>table<span class="w"> </span>:<span class="w"> </span><span class="m">001</span>-kcm-k8s-hosted-cp-rt-001 </code></pre></div> <p><center> <image src="/images/k0rdent/001-kcm-k8s-hosted-cp-rg.png"> </center></p> <p><center> <image src="/images/k0rdent/001-kcm-k8s-hosted-cp-subnet.png"> </center></p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: k0rdent.mirantis.com/v1alpha1</span> <span class="s">kind: ClusterDeployment</span> <span class="s">metadata:</span> <span class="s"> name: 001-kcm-k8s-hosted-cp</span> <span class="s">spec:</span> <span class="s"> template: azure-hosted-cp-0-1-0</span> <span class="s"> credential: azure-cluster-identity-cred</span> <span class="s"> config:</span> <span class="s"> clusterLabels: {}</span> <span class="s"> location: &quot;northeurope&quot;</span> <span class="s"> subscriptionID: &quot;${AZURE_SUBSCRIPTION_ID}&quot;</span> <span class="s"> vmSize: Standard_A4_v2</span> <span class="s"> workersNumber: 2</span> <span class="s"> resourceGroup: 001-kcm-k8s-hosted-cp</span> <span class="s"> network:</span> <span class="s"> vnetName: 001-kcm-k8s-hosted-cp-vnet</span> <span class="s"> nodeSubnetName: 001-kcm-k8s-hosted-cp-subnet-001</span> <span class="s"> routeTableName: 001-kcm-k8s-hosted-cp-rt-001</span> <span class="s"> securityGroupName: 001-kcm-k8s-hosted-cp-nsg-001</span> <span class="s">EOF</span> </code></pre></div> <p>J'ai bien la création d'un loadbalancer pour le control plane géré par k0smotron</p> <div class="codehilite"><pre><span></span><code>kmc-001-kcm-k8s-hosted-cp-lb<span class="w"> </span>LoadBalancer<span class="w"> </span><span class="m">10</span>.0.228.50<span class="w"> </span><span class="m">135</span>.x.x.9<span class="w"> </span><span class="m">6443</span>:32191/TCP,8132:30190/TCP<span class="w"> </span> <span class="c1"># Test curl </span> curl<span class="w"> </span>-k<span class="w"> </span>https://135.x.x.9:6443 <span class="c1"># Résultat :</span> <span class="o">{</span> <span class="w"> </span><span class="s2">&quot;kind&quot;</span>:<span class="w"> </span><span class="s2">&quot;Status&quot;</span>, <span class="w"> </span><span class="s2">&quot;apiVersion&quot;</span>:<span class="w"> </span><span class="s2">&quot;v1&quot;</span>, <span class="w"> </span><span class="s2">&quot;metadata&quot;</span>:<span class="w"> </span><span class="o">{}</span>, <span class="w"> </span><span class="s2">&quot;status&quot;</span>:<span class="w"> </span><span class="s2">&quot;Failure&quot;</span>, <span class="w"> </span><span class="s2">&quot;message&quot;</span>:<span class="w"> </span><span class="s2">&quot;Unauthorized&quot;</span>, <span class="w"> </span><span class="s2">&quot;reason&quot;</span>:<span class="w"> </span><span class="s2">&quot;Unauthorized&quot;</span>, <span class="w"> </span><span class="s2">&quot;code&quot;</span>:<span class="w"> </span><span class="m">401</span> <span class="o">}</span> </code></pre></div> <p>C'est OK!</p> <p><strong>5.3 Récupération du kubeconfig</strong></p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>view-secret<span class="w"> </span><span class="m">001</span>-kcm-k8s-hosted-cp-kubeconfig<span class="w"> </span>-n<span class="w"> </span>kcm-system<span class="w"> </span>&gt;<span class="w"> </span><span class="m">001</span>-kcm-k8s-hosted-cp.conf <span class="c1"># Vérifications </span> <span class="nv">KUBECONFIG</span><span class="o">=</span><span class="m">001</span>-kcm-k8s-hosted-cp.conf<span class="w"> </span>kubectl<span class="w"> </span>get<span class="w"> </span>nodes<span class="w"> </span> No<span class="w"> </span>resources<span class="w"> </span>found <span class="nv">KUBECONFIG</span><span class="o">=</span><span class="m">001</span>-kcm-k8s-hosted-cp.conf<span class="w"> </span>kubectl<span class="w"> </span>get<span class="w"> </span>po<span class="w"> </span>-A <span class="c1"># Résultats</span> NAMESPACE<span class="w"> </span>NAME<span class="w"> </span>READY<span class="w"> </span>STATUS<span class="w"> </span>RESTARTS<span class="w"> </span>AGE kube-system<span class="w"> </span>calico-kube-controllers-6cd7d8cc9f-k8xd7<span class="w"> </span><span class="m">0</span>/1<span class="w"> </span>Pending<span class="w"> </span><span class="m">0</span><span class="w"> </span>48s kube-system<span class="w"> </span>cloud-controller-manager-668b5cf9b6-trzsv<span class="w"> </span><span class="m">0</span>/1<span class="w"> </span>Pending<span class="w"> </span><span class="m">0</span><span class="w"> </span>48s kube-system<span class="w"> </span>coredns-7b7b486b6c-vjh7v<span class="w"> </span><span class="m">0</span>/1<span class="w"> </span>Pending<span class="w"> </span><span class="m">0</span><span class="w"> </span>49s kube-system<span class="w"> </span>metrics-server-78c4ccbc7f-kcmqs<span class="w"> </span><span class="m">0</span>/1<span class="w"> </span>Pending<span class="w"> </span><span class="m">0</span><span class="w"> </span>48s projectsveltos<span class="w"> </span>sveltos-agent-manager-7c967bfdd5-7c4d9<span class="w"> </span><span class="m">0</span>/1<span class="w"> </span>Pending<span class="w"> </span><span class="m">0</span><span class="w"> </span>24s <span class="c1"># Aucun des pods n&#39;est prets !</span> </code></pre></div> <p>Quand on regarde la documentation il y a une note qui n'est pas clair, car on ne sait pas quand il faut patcher la resource <code>azurecluster</code></p> <p>Référence : https://docs.k0rdent.io/v0.1.0/template-azure/</p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>azurecluster <span class="c1"># Résultat :</span> NAME<span class="w"> </span>CLUSTER<span class="w"> </span>READY<span class="w"> </span>REASON<span class="w"> </span>AGE <span class="m">001</span>-kcm-k8s-hosted-cp<span class="w"> </span><span class="m">001</span>-kcm-k8s-hosted-cp<span class="w"> </span>3m21s </code></pre></div> <p>J'ai donc patché la resource pour voir si ca changeait quelque chose 😀</p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>patch<span class="w"> </span>azurecluster<span class="w"> </span><span class="m">001</span>-kcm-k8s-hosted-cp<span class="w"> </span>--type<span class="o">=</span>merge<span class="w"> </span>--subresource<span class="w"> </span>status<span class="w"> </span>--patch<span class="w"> </span><span class="s1">&#39;status: {ready: true}&#39;</span> <span class="c1"># Résultat :</span> azurecluster.infrastructure.cluster.x-k8s.io/001-kcm-k8s-hosted-cp<span class="w"> </span>patched </code></pre></div> <p><strong>Et ... ca fonctionne !!!</strong></p> <p><center> <image src="/images/k0rdent/001-kcm-k8s-hosted-cp-resources.png"> </center></p> <p>J'ai bien 2 vm qui sont provisionnées</p> <p>Maintenant on a : </p> <div class="codehilite"><pre><span></span><code><span class="nv">KUBECONFIG</span><span class="o">=</span><span class="m">001</span>-kcm-k8s-hosted-cp.conf<span class="w"> </span>kubectl<span class="w"> </span>get<span class="w"> </span>po<span class="w"> </span>-A NAMESPACE<span class="w"> </span>NAME<span class="w"> </span>READY<span class="w"> </span>STATUS<span class="w"> </span>RESTARTS<span class="w"> </span>AGE kube-system<span class="w"> </span>calico-kube-controllers-6cd7d8cc9f-pvvwh<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>86m kube-system<span class="w"> </span>calico-node-2wfrf<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>4m9s kube-system<span class="w"> </span>calico-node-tw7vs<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>4m10s kube-system<span class="w"> </span>cloud-controller-manager-668b5cf9b6-k9jx4<span class="w"> </span><span class="m">0</span>/1<span class="w"> </span>CrashLoopBackOff<span class="w"> </span><span class="m">3</span><span class="w"> </span><span class="o">(</span>41s<span class="w"> </span>ago<span class="o">)</span><span class="w"> </span>6m26s kube-system<span class="w"> </span>cloud-node-manager-nllzg<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>4m10s kube-system<span class="w"> </span>cloud-node-manager-vl2j8<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>4m9s kube-system<span class="w"> </span>coredns-645c5d6f5b-2tldj<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>3m59s kube-system<span class="w"> </span>coredns-645c5d6f5b-cv4nz<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>3m59s kube-system<span class="w"> </span>csi-azuredisk-controller-54ff6d4cb7-44q7b<span class="w"> </span><span class="m">4</span>/6<span class="w"> </span>CrashLoopBackOff<span class="w"> </span><span class="m">12</span><span class="w"> </span><span class="o">(</span>23s<span class="w"> </span>ago<span class="o">)</span><span class="w"> </span>2m41s kube-system<span class="w"> </span>csi-azuredisk-controller-54ff6d4cb7-k6zvx<span class="w"> </span><span class="m">3</span>/6<span class="w"> </span>CrashLoopBackOff<span class="w"> </span><span class="m">12</span><span class="w"> </span><span class="o">(</span>8s<span class="w"> </span>ago<span class="o">)</span><span class="w"> </span>2m41s kube-system<span class="w"> </span>csi-azuredisk-node-4p268<span class="w"> </span><span class="m">3</span>/3<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>2m41s kube-system<span class="w"> </span>csi-azuredisk-node-qjp8j<span class="w"> </span><span class="m">3</span>/3<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>2m41s kube-system<span class="w"> </span>konnectivity-agent-j4r4n<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>4m10s kube-system<span class="w"> </span>konnectivity-agent-j7lng<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>4m9s kube-system<span class="w"> </span>kube-proxy-nq7z6<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>4m9s kube-system<span class="w"> </span>kube-proxy-s6m2s<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>4m10s kube-system<span class="w"> </span>metrics-server-78c4ccbc7f-qdz88<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>86m projectsveltos<span class="w"> </span>sveltos-agent-manager-665b9479b8-8mmm4<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>86m </code></pre></div> <p>Il va falloir fixer encore le <strong>cloud-controller-manager</strong> comme à l'étape précédente</p> <div class="codehilite"><pre><span></span><code><span class="nb">export</span><span class="w"> </span><span class="nv">CLUSTER_DEPLOYMENT_NAME</span><span class="o">=</span><span class="s2">&quot;001-kcm-k8s-hosted-cp&quot;</span> <span class="nb">export</span><span class="w"> </span><span class="nv">LOCATION</span><span class="o">=</span><span class="s2">&quot;northeurope&quot;</span> <span class="nv">KUBECONFIG</span><span class="o">=</span><span class="m">001</span>-kcm-k8s-hosted-cp.conf<span class="w"> </span>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: v1</span> <span class="s">kind: Secret</span> <span class="s">metadata:</span> <span class="s"> name: azure-cloud-provider</span> <span class="s"> namespace: kube-system</span> <span class="s">type: Opaque</span> <span class="s">stringData:</span> <span class="s"> cloud-config: |-</span> <span class="s"> {</span> <span class="s"> &quot;cloud&quot;: &quot;AzurePublicCloud&quot;,</span> <span class="s"> &quot;tenantId&quot;: &quot;${AZURE_TENANT_ID}&quot;,</span> <span class="s"> &quot;subscriptionId&quot;: &quot;${AZURE_SUBSCRIPTION_ID}&quot;,</span> <span class="s"> &quot;aadClientId&quot;: &quot;${AZURE_CLIENT_ID}&quot;,</span> <span class="s"> &quot;aadClientSecret&quot;: &quot;${AZURE_CLIENT_SECRET}&quot;,</span> <span class="s"> &quot;resourceGroup&quot;: &quot;${CLUSTER_DEPLOYMENT_NAME}&quot;,</span> <span class="s"> &quot;securityGroupName&quot;: &quot;${CLUSTER_DEPLOYMENT_NAME}-nsg-001&quot;,</span> <span class="s"> &quot;securityGroupResourceGroup&quot;: &quot;${CLUSTER_DEPLOYMENT_NAME}&quot;,</span> <span class="s"> &quot;location&quot;: &quot;${LOCATION}&quot;,</span> <span class="s"> &quot;vmType&quot;: &quot;vmss&quot;,</span> <span class="s"> &quot;vnetName&quot;: &quot;${CLUSTER_DEPLOYMENT_NAME}-vnet&quot;,</span> <span class="s"> &quot;vnetResourceGroup&quot;: &quot;${CLUSTER_DEPLOYMENT_NAME}&quot;,</span> <span class="s"> &quot;subnetName&quot;: &quot;${CLUSTER_DEPLOYMENT_NAME}-subnet-001&quot;,</span> <span class="s"> &quot;routeTableName&quot;: &quot;${CLUSTER_DEPLOYMENT_NAME}-rt-001&quot;,</span> <span class="s"> &quot;loadBalancerSku&quot;: &quot;Standard&quot;,</span> <span class="s"> &quot;loadBalancerName&quot;: &quot;&quot;,</span> <span class="s"> &quot;maximumLoadBalancerRuleCount&quot;: 250,</span> <span class="s"> &quot;useManagedIdentityExtension&quot;: false,</span> <span class="s"> &quot;useInstanceMetadata&quot;: true</span> <span class="s"> }</span> <span class="s">EOF</span> </code></pre></div> <p>Je provoque un redémarrage des pods du namespace <code>kube-system</code></p> <div class="codehilite"><pre><span></span><code><span class="nv">KUBECONFIG</span><span class="o">=</span><span class="m">001</span>-kcm-k8s-hosted-cp.conf<span class="w"> </span>kubectl<span class="w"> </span>-n<span class="w"> </span>kube-system<span class="w"> </span>rollout<span class="w"> </span>restart<span class="w"> </span>deploy<span class="w"> </span>cloud-controller-manager<span class="w"> </span>csi-azuredisk-controller<span class="w"> </span>calico-kube-controllers<span class="w"> </span>metrics-server<span class="w"> </span>coredns deployment.apps/cloud-controller-manager<span class="w"> </span>restarted deployment.apps/csi-azuredisk-controller<span class="w"> </span>restarted deployment.apps/calico-kube-controllers<span class="w"> </span>restarted deployment.apps/metrics-server<span class="w"> </span>restarted deployment.apps/coredns<span class="w"> </span>restarted <span class="c1"># Vérifications :</span> <span class="nv">KUBECONFIG</span><span class="o">=</span><span class="m">001</span>-kcm-k8s-hosted-cp.conf<span class="w"> </span>kubectl<span class="w"> </span>get<span class="w"> </span>po<span class="w"> </span>-A NAMESPACE<span class="w"> </span>NAME<span class="w"> </span>READY<span class="w"> </span>STATUS<span class="w"> </span>RESTARTS<span class="w"> </span>AGE kube-system<span class="w"> </span>calico-kube-controllers-555f4ffcbc-ks7r5<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>10s kube-system<span class="w"> </span>calico-node-mvqms<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>18m kube-system<span class="w"> </span>calico-node-rcztl<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>19m kube-system<span class="w"> </span>cloud-controller-manager-8d7d987f8-jpx4n<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>13s kube-system<span class="w"> </span>cloud-node-manager-ltz8t<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>8m32s kube-system<span class="w"> </span>cloud-node-manager-msnw6<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>8m32s kube-system<span class="w"> </span>coredns-645c5d6f5b-cfkt2<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>9m36s kube-system<span class="w"> </span>coredns-6c4b58d497-685fl<span class="w"> </span><span class="m">0</span>/1<span class="w"> </span>Pending<span class="w"> </span><span class="m">0</span><span class="w"> </span>12s kube-system<span class="w"> </span>coredns-6c4b58d497-kw87j<span class="w"> </span><span class="m">0</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>12s kube-system<span class="w"> </span>csi-azuredisk-controller-54ff6d4cb7-rrm4n<span class="w"> </span><span class="m">6</span>/6<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>8m20s kube-system<span class="w"> </span>csi-azuredisk-controller-54ff6d4cb7-rs7mf<span class="w"> </span><span class="m">6</span>/6<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>8m20s kube-system<span class="w"> </span>csi-azuredisk-controller-7c45dc7f7f-twc89<span class="w"> </span><span class="m">0</span>/6<span class="w"> </span>Pending<span class="w"> </span><span class="m">0</span><span class="w"> </span>13s kube-system<span class="w"> </span>csi-azuredisk-node-vlc2b<span class="w"> </span><span class="m">3</span>/3<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>8m20s kube-system<span class="w"> </span>csi-azuredisk-node-zsfdj<span class="w"> </span><span class="m">3</span>/3<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>8m20s kube-system<span class="w"> </span>konnectivity-agent-pxrv2<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>9m34s kube-system<span class="w"> </span>konnectivity-agent-x5spn<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>9m34s kube-system<span class="w"> </span>kube-proxy-59rb9<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>18m kube-system<span class="w"> </span>kube-proxy-n5wp6<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>18m kube-system<span class="w"> </span>metrics-server-5b9b76db47-tqk67<span class="w"> </span><span class="m">0</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>12s kube-system<span class="w"> </span>metrics-server-78c4ccbc7f-w8phh<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>7m11s projectsveltos<span class="w"> </span>sveltos-agent-manager-7c967bfdd5-7c4d9<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span>Running<span class="w"> </span><span class="m">0</span><span class="w"> </span>28m </code></pre></div> <p>Maintenant tout est Okubectl !</p> <p><strong>5.4 Test du cluster créé</strong></p> <div class="codehilite"><pre><span></span><code><span class="nv">KUBECONFIG</span><span class="o">=</span><span class="m">001</span>-kcm-k8s-hosted-cp.conf<span class="w"> </span>kubectl<span class="w"> </span>create<span class="w"> </span>deploy<span class="w"> </span>web<span class="w"> </span>--image<span class="w"> </span>nginx<span class="w"> </span>-n<span class="w"> </span>default <span class="nv">KUBECONFIG</span><span class="o">=</span><span class="m">001</span>-kcm-k8s-hosted-cp.conf<span class="w"> </span>kubectl<span class="w"> </span>expose<span class="w"> </span>deploy<span class="w"> </span>web<span class="w"> </span>--type<span class="w"> </span>LoadBalancer<span class="w"> </span>-n<span class="w"> </span>default<span class="w"> </span>--port<span class="w"> </span><span class="m">80</span> <span class="nv">KUBECONFIG</span><span class="o">=</span><span class="m">001</span>-kcm-k8s-hosted-cp.conf<span class="w"> </span>kubectl<span class="w"> </span>get<span class="w"> </span>deploy,svc<span class="w"> </span>-n<span class="w"> </span>default <span class="c1"># Résultats :</span> NAME<span class="w"> </span>READY<span class="w"> </span>UP-TO-DATE<span class="w"> </span>AVAILABLE<span class="w"> </span>AGE deployment.apps/web<span class="w"> </span><span class="m">1</span>/1<span class="w"> </span><span class="m">1</span><span class="w"> </span><span class="m">1</span><span class="w"> </span>3m22s NAME<span class="w"> </span>TYPE<span class="w"> </span>CLUSTER-IP<span class="w"> </span>EXTERNAL-IP<span class="w"> </span>PORT<span class="o">(</span>S<span class="o">)</span><span class="w"> </span>AGE service/kubernetes<span class="w"> </span>ClusterIP<span class="w"> </span><span class="m">10</span>.96.0.1<span class="w"> </span>&lt;none&gt;<span class="w"> </span><span class="m">443</span>/TCP<span class="w"> </span>34m service/web<span class="w"> </span>LoadBalancer<span class="w"> </span><span class="m">10</span>.101.53.225<span class="w"> </span><span class="m">4</span>.208.216.226<span class="w"> </span><span class="m">80</span>:32732/TCP<span class="w"> </span>2m14s </code></pre></div> <p>Le cloud controller fonctionne bien il a créé un loadbalancer qui pointe sur les vm du cluster kubernetes</p> <p><center> <image src="/images/k0rdent/001-kcm-k8s-hosted-cp-lb.png"> </center></p> <p><strong>5.5 Test de l'accès au service web</strong></p> <div class="codehilite"><pre><span></span><code>curl<span class="w"> </span>-s<span class="w"> </span>-o<span class="w"> </span>/dev/null<span class="w"> </span>-I<span class="w"> </span>-w<span class="w"> </span><span class="s2">&quot;%{http_code}&quot;</span><span class="w"> </span><span class="m">4</span>.208.216.226<span class="w"> </span> <span class="m">200</span>% </code></pre></div> <p>Le déprovisionnement fonctionne aussi très bien le loadbalancer ainsi que l'adresse ip publique sont bien supprimés</p> <p><strong>5.6 Cleaning</strong></p> <div class="codehilite"><pre><span></span><code><span class="c1"># Très important ! </span> kubectl<span class="w"> </span>patch<span class="w"> </span>azurecluster<span class="w"> </span><span class="m">001</span>-kcm-k8s-hosted-cp<span class="w"> </span>--type<span class="o">=</span>merge<span class="w"> </span>--patch<span class="w"> </span><span class="s1">&#39;metadata: {finalizers: [manual]}&#39;</span> kubectl<span class="w"> </span>delete<span class="w"> </span>clusterdeployment<span class="w"> </span><span class="m">001</span>-kcm-k8s-hosted-cp <span class="c1"># CA PREND DU TEMPS ! (Nettoyage de toutes les ressources Azure)</span> <span class="c1"># Libérer la resource pour sa suppression </span> kubectl<span class="w"> </span>patch<span class="w"> </span>azurecluster<span class="w"> </span><span class="m">001</span>-kcm-k8s-hosted-cp<span class="w"> </span>--type<span class="o">=</span>json<span class="w"> </span>-p<span class="o">=</span><span class="s1">&#39;[{&quot;op&quot;: &quot;remove&quot;, &quot;path&quot;: &quot;/metadata/finalizers/0&quot;}]&#39;</span> </code></pre></div> <h3>6. Conclusions</h3> <p>k0rdent (kcm) démontre sa capacité à simplifier considérablement le déploiement et la gestion de clusters Kubernetes sur Azure. Que ce soit pour des clusters AKS entièrement managés, des clusters k0s autonomes, ou des clusters avec un plan de contrôle hébergé, k0rdent offre une abstraction puissante grâce à l'intégration de Cluster API. </p> <p>L'automatisation fournie par k0rdent réduit la complexité, accélère les déploiements, et permet aux équipes de se concentrer sur leurs applications plutôt que sur l'infrastructure sous-jacente. </p> <p>L'utilisation de templates préconfigurés et la gestion centralisée des identifiants facilitent grandement l'adoption de Kubernetes sur Azure.</p>2025-02-10T12:00:00+01:002025-02-10T12:00:00+01:00Hervé Leclerctag:blogppr.alterway.fr,2025-02-10:/context-aware-identity-management-avec-kyverno.html

<p>Context-Aware Identity Management (avec Kyverno)</p>

<h1>Beyond the Static Gates</h1> <p><strong>Salut les passionnés de Kubernetes !</strong></p> <p>Soyons réalistes, RBAC dans Kubernetes, bien qu'essentiel, peut donner l'impression d'avoir un videur qui ne vérifie que les cartes d'identité sans se soucier de savoir si vous êtes sur le point de causer des problèmes. </p> <p>Il vous fait passer la porte, mais il ne sait rien de vous ni pourquoi vous êtes là maintenant.</p> <p>Imaginez ceci : un développeur accède accidentellement à une base de données de production depuis son réseau domestique à 3 heures du matin. RBAC dit : "Oui, vous avez le rôle", mais il passe complètement à côté des signaux d'alerte criant "Violation de sécurité potentielle !"</p> <p>C'est là que la gestion des identités contextuelles (Context-Aware Identity Management - CAIM) entre en jeu. </p> <p>C'est comme donner à votre videur un badge de détective, la capacité de lire dans les pensées et peut-être une API de vérification des antécédents. </p> <p>CAIM vous permet de contrôler l'accès aux ressources Kubernetes en fonction du contexte de la requête - qui, quoi, quand, où, comment... tout.</p> <p>Il ne s'agit pas seulement de renforcer la sécurité, mais d'ajouter une couche de sécurité intelligente qui comprend les nuances de votre environnement et s'adapte dynamiquement aux menaces potentielles. </p> <p>Prêt à passer à la vitesse supérieure en matière de sécurité Kubernetes ? Plongeons-nous dedans !</p> <p><strong>Le Problème avec RBAC Seul : Des Rôles Statiques dans un Monde Dynamique</strong></p> <p>Le contrôle d'accès basé sur les rôles (RBAC) de Kubernetes est le fondement de l'autorisation. Nous définissons des Rôles (quelles actions peuvent être effectuées) et des RoleBindings (qui peut effectuer ces actions). Solide, n'est-ce pas ?</p> <p>Pas tout à fait. Considérez ces limitations :</p> <ul> <li> <p><strong>Manque de Contrôle Granulaire</strong> : RBAC a du mal à appliquer des politiques précises. Pouvez-vous facilement dire : "Les développeurs de l'équipe A peuvent seulement lire les logs de production pendant les sessions de débogage" ? C'est complexe.</p> </li> <li> <p><strong>Nature Statique</strong> : Les permissions sont fixes. Elles ne s'adaptent pas en fonction de l'heure, du lieu ou du périphérique. Un compte compromis a les mêmes permissions, peu importe où ou quand il est utilisé.</p> </li> <li> <p><strong>Cauchemar de la Gestion des Exceptions</strong> : Besoin d'accorder un accès temporaire à une ressource spécifique pour une durée limitée ? RBAC rend cela lourd et sujet aux erreurs.</p> </li> </ul> <p>RBAC fournit une base de sécurité de base, mais ce n'est tout simplement pas suffisant pour les environnements complexes et à enjeux élevés d'aujourd'hui. Nous avons besoin de quelque chose de plus intelligent.</p> <h3>L'Identité Contextuelle : L'Autorisation avec un Cerveau</h3> <p>La gestion des identités contextuelles fait passer l'autorisation au niveau supérieur. Au lieu de faire confiance aveuglément aux rôles, elle évalue une requête en fonction d'un ensemble riche d'attributs contextuels :</p> <ul> <li> <p><strong>Contexte de l'Utilisateur</strong> : Rôle, appartenances aux groupes, fonction, département, habilitation de sécurité.</p> </li> <li> <p><strong>Contexte de la Ressource</strong> : Type de ressource, étiquettes, espace de noms, niveau de sensibilité.</p> </li> <li> <p><strong>Contexte Temporel</strong> : Heure de la journée, jour de la semaine, fenêtres de maintenance.</p> </li> <li> <p><strong>Contexte Géographique</strong> : Localisation de l'utilisateur, adresse IP d'origine, segment de réseau.</p> </li> <li> <p><strong>Contexte du Périphérique</strong> : Type de périphérique, système d'exploitation, posture de sécurité (par exemple, statut de l'antivirus).</p> </li> <li> <p><strong>Contexte des Menaces</strong> : Flux d'informations sur les menaces en temps réel, scores de détection d'anomalies.</p> </li> </ul> <p>Avec CAIM, vous pouvez définir des politiques comme celles-ci :</p> <ul> <li> <p>"Autoriser l'accès à la base de données de production uniquement depuis le réseau d'entreprise, pendant les heures de bureau, et uniquement aux membres du groupe 'administrateurs-de-base-de-données'."</p> </li> <li> <p>"Refuser l'accès aux données sensibles des clients à partir de tout périphérique qui n'est pas conforme aux politiques de sécurité de l'entreprise (par exemple, absence d'antivirus ou OS obsolète)."</p> </li> <li> <p>"Escalader automatiquement les permissions lors d'un incident de sécurité en fonction du niveau de gravité."</p> </li> </ul> <h3>Techniquement comment faire ?</h3> <p>Prenons un exemple : <strong>Use case : Un utilisateur ne peux acceder aux resources d'un certain namespace seulement entre 8h et 19h</strong></p> <p>Voici une approche détaillée et plusieurs solutions pour implémenter une gestion d'identité contextuelle dans Kubernetes, en mettant l'accent sur notre exemple de restriction horaire :</p> <p><strong>Défis avec Kubernetes RBAC Standard</strong></p> <p>Le RBAC (Role-Based Access Control) natif de Kubernetes est puissant pour gérer l'autorisation basée sur les rôles. Cependant, il est <strong>limité pour la gestion contextuelle</strong>. Le RBAC standard ne permet pas nativement de :</p> <ul> <li>Définir des conditions temporelles dans les règles RBAC.</li> <li>Intégrer facilement des sources de contexte externes (localisation, appareil, etc.).</li> </ul> <p><strong>Solutions pour la CAIM dans Kubernetes</strong></p> <p>Pour implémenter la CAIM, vous devrez étendre les capacités de Kubernetes. Voici les approches principales :</p> <p><strong>1. Admission Webhooks (Authorization Webhooks) Personnalisés</strong></p> <ul> <li> <p><strong>Principe :</strong> Vous pouvez créer un webhook d'admission d'autorisation personnalisé. Kubernetes interrogera ce webhook <em>avant</em> d'autoriser une requête à l'API server. Votre webhook peut alors examiner le contexte (y compris l'heure) et décider d'autoriser ou non l'accès.</p> </li> <li> <p><strong>Avantages :</strong></p> <ul> <li><strong>Flexibilité totale :</strong> Vous contrôlez entièrement la logique de décision d'autorisation.</li> <li><strong>Intégration native :</strong> Utilise les mécanismes d'extension de Kubernetes.</li> </ul> </li> <li> <p><strong>Inconvénients :</strong></p> <ul> <li><strong>Complexité de développement :</strong> Vous devez développer et maintenir le webhook personnalisé.</li> <li><strong>Performance :</strong> Un webhook mal optimisé peut impacter la performance de l'API server.</li> </ul> </li> <li> <p><strong>Exemple Conceptuel (Webhook) pour la restriction horaire :</strong></p> </li> </ul> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="c1"># Logique du webhook (simplifiée, conceptuelle)</span> <span class="w"> </span><span class="kn">import</span><span class="w"> </span><span class="nn">datetime</span> <span class="w"> </span><span class="k">def</span><span class="w"> </span><span class="nf">authorize_request</span><span class="p">(</span><span class="n">request</span><span class="p">):</span> <span class="w"> </span><span class="n">current_hour</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">datetime</span><span class="o">.</span><span class="n">datetime</span><span class="o">.</span><span class="n">now</span><span class="p">()</span><span class="o">.</span><span class="n">hour</span> <span class="w"> </span><span class="n">namespace</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">request</span><span class="o">.</span><span class="n">namespace</span> <span class="w"> </span><span class="n">user</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="n">request</span><span class="o">.</span><span class="n">userInfo</span><span class="o">.</span><span class="n">username</span> <span class="w"> </span><span class="k">if</span><span class="w"> </span><span class="n">namespace</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="s2">&quot;mon-namespace&quot;</span><span class="w"> </span><span class="ow">and</span><span class="w"> </span><span class="p">(</span><span class="n">current_hour</span><span class="w"> </span><span class="o">&lt;</span><span class="w"> </span><span class="mi">8</span><span class="w"> </span><span class="ow">or</span><span class="w"> </span><span class="n">current_hour</span><span class="w"> </span><span class="o">&gt;=</span><span class="w"> </span><span class="mi">19</span><span class="p">):</span> <span class="w"> </span><span class="c1"># Refuser l&#39;accès en dehors des heures autorisées pour ce namespace</span> <span class="w"> </span><span class="k">return</span><span class="w"> </span><span class="p">{</span><span class="s2">&quot;allowed&quot;</span><span class="p">:</span><span class="w"> </span><span class="kc">False</span><span class="p">,</span><span class="w"> </span><span class="s2">&quot;reason&quot;</span><span class="p">:</span><span class="w"> </span><span class="s2">&quot;Accès refusé en dehors des heures de bureau (8h-19h)&quot;</span><span class="p">}</span> <span class="w"> </span><span class="k">else</span><span class="p">:</span> <span class="w"> </span><span class="c1"># Laisser Kubernetes RBAC standard gérer l&#39;autorisation ensuite</span> <span class="w"> </span><span class="k">return</span><span class="w"> </span><span class="p">{</span><span class="s2">&quot;allowed&quot;</span><span class="p">:</span><span class="w"> </span><span class="kc">True</span><span class="p">}</span> </code></pre></div> <p><strong>Mise en œuvre (points clés) :</strong></p> <ul> <li><strong>Développement du webhook :</strong> Écrire le service webhook (en Go, Python, etc.) qui contient la logique d'autorisation contextuelle.</li> <li><strong>Déploiement du webhook :</strong> Déployer le service webhook dans votre cluster Kubernetes.</li> <li><strong>Configuration de l'Admission Controller :</strong> Configurer un <code>ValidatingWebhookConfiguration</code> ou <code>MutatingWebhookConfiguration</code> dans Kubernetes pour intercepter les requêtes d'autorisation et les envoyer à votre webhook. Il faut spécifier quels types de requêtes (par exemple, <code>create</code>, <code>update</code>, <code>delete</code>) et quelles ressources (par exemple, <code>pods</code>, <code>deployments</code>) doivent être interceptées.</li> <li><strong>Sécurité :</strong> Sécuriser la communication entre l'API server et le webhook (TLS, authentification).</li> </ul> <p><strong>2. Utilisation d'un Policy Engine (OPA - Open Policy Agent ou Kyverno)</strong></p> <ul> <li> <p><strong>Principe :</strong> Utiliser un moteur de politiques externe comme OPA ou Kyverno. Ces outils sont conçus pour appliquer des politiques complexes et contextuelles. Ils s'intègrent bien avec Kubernetes via des admission controllers.</p> </li> <li> <p><strong>Avantages :</strong></p> <ul> <li><strong>Langage de politique dédié :</strong> OPA utilise Rego, Kyverno utilise YAML (plus simple). Ces langages sont conçus pour exprimer des politiques complexes de manière déclarative.</li> <li><strong>Gestion centralisée des politiques :</strong> OPA et Kyverno permettent de gérer les politiques de manière centralisée et versionnée.</li> <li><strong>Auditabilité :</strong> Facilitent l'audit des décisions d'autorisation.</li> <li><strong>Communauté et maturité :</strong> OPA et Kyverno sont des projets open source actifs et matures.</li> </ul> </li> <li> <p><strong>Inconvénients :</strong></p> <ul> <li><strong>Courbe d'apprentissage (OPA/Rego) :</strong> Rego peut être un peu complexe à apprendre au début. Kyverno est plus simple.</li> <li><strong>Déploiement et gestion supplémentaires :</strong> Il faut déployer et gérer le moteur de politiques (OPA ou Kyverno) dans le cluster.</li> </ul> </li> <li> <p><strong>Exemple OPA (Rego) pour la restriction horaire :</strong></p> </li> </ul> <div class="codehilite"><pre><span></span><code><span class="w"> </span><span class="n">package</span><span class="w"> </span><span class="n">kubernetes</span><span class="o">.</span><span class="n">admission</span> <span class="w"> </span><span class="kn">import</span><span class="w"> </span><span class="nn">time</span> <span class="w"> </span><span class="c1"># Politique de restriction horaire pour le namespace &quot;mon-namespace&quot;</span> <span class="w"> </span><span class="n">deny</span><span class="p">[</span><span class="n">msg</span><span class="p">]</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="nb">input</span><span class="o">.</span><span class="n">namespace</span><span class="o">.</span><span class="n">metadata</span><span class="o">.</span><span class="n">name</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="s2">&quot;mon-namespace&quot;</span> <span class="w"> </span><span class="ow">not</span><span class="w"> </span><span class="n">is_within_business_hours</span> <span class="w"> </span><span class="n">msg</span><span class="w"> </span><span class="o">:=</span><span class="w"> </span><span class="s2">&quot;Accès refusé en dehors des heures de bureau (8h-19h) pour le namespace &#39;mon-namespace&#39;&quot;</span> <span class="w"> </span><span class="p">}</span> <span class="w"> </span><span class="n">is_within_business_hours</span><span class="w"> </span><span class="p">{</span> <span class="w"> </span><span class="n">hour</span><span class="w"> </span><span class="o">:=</span><span class="w"> </span><span class="n">time</span><span class="o">.</span><span class="n">now_in_zone</span><span class="p">(</span><span class="s2">&quot;Europe/Paris&quot;</span><span class="p">)</span><span class="o">.</span><span class="n">hour</span><span class="w"> </span> <span class="w"> </span><span class="n">hour</span><span class="w"> </span><span class="o">&gt;=</span><span class="w"> </span><span class="mi">8</span> <span class="w"> </span><span class="n">hour</span><span class="w"> </span><span class="o">&lt;</span><span class="w"> </span><span class="mi">19</span> <span class="w"> </span><span class="p">}</span> </code></pre></div> <p><strong>Exemple Kyverno (YAML) pour la restriction horaire :</strong></p> <div class="codehilite"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">kyverno.io/v1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ClusterPolicy</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">deny-outside-business-hours</span> <span class="w"> </span><span class="nt">namespace</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">kyverno</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">background</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">false</span> <span class="w"> </span><span class="nt">validationFailureAction</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Enforce</span> <span class="w"> </span><span class="nt">rules</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">check-business-hours</span> <span class="w"> </span><span class="nt">match</span><span class="p">:</span> <span class="w"> </span><span class="nt">any</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">resources</span><span class="p">:</span> <span class="w"> </span><span class="nt">kinds</span><span class="p">:</span><span class="w"> </span><span class="p p-Indicator">[</span><span class="s">&quot;*&quot;</span><span class="p p-Indicator">]</span> <span class="w"> </span><span class="nt">namespaces</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">mon-namespace</span> <span class="w"> </span><span class="nt">validate</span><span class="p">:</span> <span class="w"> </span><span class="nt">message</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;Accès</span><span class="nv"> </span><span class="s">refusé</span><span class="nv"> </span><span class="s">en</span><span class="nv"> </span><span class="s">dehors</span><span class="nv"> </span><span class="s">des</span><span class="nv"> </span><span class="s">heures</span><span class="nv"> </span><span class="s">de</span><span class="nv"> </span><span class="s">bureau</span><span class="nv"> </span><span class="s">(8h-19h)&quot;</span> <span class="w"> </span><span class="nt">deny</span><span class="p">:</span> <span class="w"> </span><span class="nt">conditions</span><span class="p">:</span> <span class="w"> </span><span class="nt">any</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">key</span><span class="p">:</span><span class="w"> </span><span class="s">&#39;{{</span><span class="nv"> </span><span class="s">time_now_utc().time_to_cron(@).split(@,</span><span class="se">&#39;&#39;</span><span class="nv"> </span><span class="se">&#39;&#39;</span><span class="s">)</span><span class="nv"> </span><span class="s">|</span><span class="nv"> </span><span class="s">[1].to_number(@)</span><span class="nv"> </span><span class="s">}}&#39;</span> <span class="w"> </span><span class="nt">operator</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">LessThan</span> <span class="w"> </span><span class="nt">value</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">6</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">key</span><span class="p">:</span><span class="w"> </span><span class="s">&#39;{{</span><span class="nv"> </span><span class="s">time_now_utc().time_to_cron(@).split(@,</span><span class="se">&#39;&#39;</span><span class="nv"> </span><span class="se">&#39;&#39;</span><span class="s">)</span><span class="nv"> </span><span class="s">|</span><span class="nv"> </span><span class="s">[1].to_number(@)</span><span class="nv"> </span><span class="s">}}&#39;</span> <span class="w"> </span><span class="nt">operator</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">GreaterThan</span> <span class="w"> </span><span class="nt">value</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">17</span> </code></pre></div> <p>J'ai une préférence depuis tout le temps pour <strong>Kyverno</strong>, donc je vais illustrer cette implémentation avec cet outil.</p> <h3>Installation de Kyverno via Helm</h3> <div class="codehilite"><pre><span></span><code>helm<span class="w"> </span>repo<span class="w"> </span>add<span class="w"> </span>kyverno<span class="w"> </span>https://kyverno.github.io/kyverno/ helm<span class="w"> </span>repo<span class="w"> </span>update helm<span class="w"> </span>install<span class="w"> </span>kyverno<span class="w"> </span>kyverno/kyverno<span class="w"> </span>-n<span class="w"> </span>kyverno<span class="w"> </span>--create-namespace </code></pre></div> <h3>Création d'un namespace de test</h3> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>create<span class="w"> </span>namespace<span class="w"> </span>mon-namespace </code></pre></div> <h3>Création de la ClusterPolicy</h3> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f-<span class="w"> </span><span class="s">&lt;&lt;EOF</span> <span class="s">apiVersion: kyverno.io/v1</span> <span class="s">kind: ClusterPolicy</span> <span class="s">metadata:</span> <span class="s"> name: deny-outside-business-hours</span> <span class="s"> namespace: kyverno</span> <span class="s">spec:</span> <span class="s"> background: false</span> <span class="s"> validationFailureAction: Enforce</span> <span class="s"> rules:</span> <span class="s"> - name: check-business-hours</span> <span class="s"> match:</span> <span class="s"> any:</span> <span class="s"> - resources:</span> <span class="s"> kinds: [&quot;*&quot;] # Ciblage des resources de tous les types (pods, deployments, etc.)</span> <span class="s"> namespaces:</span> <span class="s"> - mon-namespace</span> <span class="s"> validate:</span> <span class="s"> message: &quot;Accès refusé en dehors des heures de bureau (8h-19h)&quot;</span> <span class="s"> deny:</span> <span class="s"> conditions:</span> <span class="s"> any:</span> <span class="s"> - key: &#39;{{ time_now_utc().time_to_cron(@).split(@,&#39;&#39; &#39;&#39;) | [1].to_number(@) }}&#39;</span> <span class="s"> operator: LessThan</span> <span class="s"> value: 6</span> <span class="s"> - key: &#39;{{ time_now_utc().time_to_cron(@).split(@,&#39;&#39; &#39;&#39;) | [1].to_number(@) }}&#39;</span> <span class="s"> operator: GreaterThan</span> <span class="s"> value: 17</span> <span class="s">EOF</span> </code></pre></div> <p><code>{{ time_now_utc().time_to_cron(@).split(@,'' '') | [1].to_number(@) }}</code></p> <p>Cette expression JMESPath dans Kyverno fait plusieurs opérations :</p> <ul> <li>time_now_utc() : récupère l'heure UTC actuelle</li> <li>time_to_cron(@) : convertit cette heure en format cron</li> <li>split(@,' ') : divise la chaîne cron en tableau en utilisant l'espace comme séparateur</li> <li>[1] : sélectionne le deuxième élément (index 1) qui représente l'heure</li> <li>to_number(@) : convertit cette heure en nombre</li> </ul> <p>Par exemple, si l'heure est 14:30 UTC :</p> <ul> <li>Format cron : "30 14 * * *"</li> <li>Après split : ["30", "14", "", "", "*"]</li> <li>Sélection : "14"</li> <li>Résultat final : 14 (nombre)</li> </ul> <p>Si vous essayez de créer par exemple un déploiement en dehors du créneau 8h-19h vous aurez :</p> <div class="codehilite"><pre><span></span><code>error:<span class="w"> </span>failed<span class="w"> </span>to<span class="w"> </span>create<span class="w"> </span>deployment:<span class="w"> </span>admission<span class="w"> </span>webhook<span class="w"> </span><span class="s2">&quot;validate.kyverno.svc-fail&quot;</span><span class="w"> </span>denied<span class="w"> </span>the<span class="w"> </span>request: resource<span class="w"> </span>Deployment/mon-namespace/nginx<span class="w"> </span>was<span class="w"> </span>blocked<span class="w"> </span>due<span class="w"> </span>to<span class="w"> </span>the<span class="w"> </span>following<span class="w"> </span>policies deny-outside-business-hours: <span class="w"> </span>check-business-hours:<span class="w"> </span>Accès<span class="w"> </span>refusé<span class="w"> </span>en<span class="w"> </span>dehors<span class="w"> </span>des<span class="w"> </span>heures<span class="w"> </span>de<span class="w"> </span>bureau<span class="w"> </span><span class="o">(</span>8h-19h<span class="o">)</span> </code></pre></div> <h3>Mot de la fin : La Sécurité Kubernetes pour l'Ère Moderne</h3> <p>La gestion des identités contextuelles est une technique puissante pour améliorer la sécurité de vos clusters Kubernetes. Elle va au-delà des limitations de RBAC en ajoutant une couche d'autorisation intelligente qui tient compte du contexte de chaque requête.</p> <p>Bien qu'elle introduise une complexité, les avantages – sécurité renforcée, conformité améliorée et plus grande flexibilité – en valent la peine.</p>2025-02-07T11:00:00+01:002025-02-07T11:00:00+01:00Hervé Leclerctag:blogppr.alterway.fr,2025-02-07:/kui.html

<p>Découvrez Kui, le Framework Open Source qui Donne des Superpouvoirs Graphiques à Votre Ligne de Commande</p>

<h1>Kui : Optimisez Votre Expérience Kubernetes avec une Interface Graphique Performante et Open Source</h1> <p>Kubernetes s'est imposé comme la plateforme d'orchestration de conteneurs de référence. Cependant, l'interface en ligne de commande (<code>kubectl</code>), bien que puissante, peut présenter des défis d'ergonomie, en particulier lors de la navigation et de l'analyse de données complexes. Le rendu ASCII standard peut rendre la lecture et l'interprétation des ressources laborieuses. Kui intervient ici comme une solution élégante, en enrichissant l'interaction avec Kubernetes grâce à une interface utilisateur graphique (GUI) intuitive et performante.</p> <p><strong>Pourquoi intégrer Kui à votre workflow Kubernetes ?</strong></p> <p>Kui est un <strong>projet open source</strong> initié au sein des SIGs Kubernetes, conçu pour transformer votre manière d'interagir avec vos clusters. En s'appuyant sur la robustesse de <code>kubectl</code>, Kui propose une interface visuelle avancée qui permet de :</p> <ul> <li><strong>Structurer l'information avec des tableaux interactifs et triables</strong> : Dépassez les limitations des listes ASCII statiques et gagnez en lisibilité.</li> <li><strong>Explorer les détails des ressources de manière contextuelle</strong> : Accédez rapidement aux informations essentielles via une navigation intuitive.</li> <li><strong>Visualiser en temps réel les logs et événements</strong> : Diagnostiquez et analysez les comportements de vos ressources de façon dynamique.</li> <li><strong>Organiser votre espace de travail avec une interface à onglets</strong> : Gérez efficacement plusieurs contextes et tâches simultanément.</li> <li><strong>Accélérer l'exécution des commandes <code>kubectl</code></strong> : Bénéficiez d'un gain de performance significatif, avec des commandes traitées 2 à 3 fois plus rapidement.</li> </ul> <p><strong>Architecture et Fonctionnement de Kui</strong></p> <p>Kui est architecturé autour du framework Electron, lui permettant de fonctionner comme une application de bureau native. Techniquement, lorsqu'une commande <code>kubectl</code> est saisie dans Kui, elle est transmise à l'exécutable <code>kubectl</code> sous-jacent. Les résultats sont ensuite interprétés et restitués visuellement via une API REST, assurant une communication fluide et performante entre l'interface graphique et le moteur CLI.</p> <p><strong>Déploiement et Configuration de Kui</strong></p> <p>L'installation de Kui a été conçue pour être simple et adaptable à différents environnements :</p> <ul> <li><strong>macOS</strong> : L'intégration avec Homebrew simplifie l'installation : <code>brew install kui kubectl kui get pods open /Applications/Kui.app</code>.</li> <li><strong>Windows et Linux</strong> : Un package téléchargeable et dézippable est disponible. Après décompression, l'ajout du répertoire au PATH système permet d'exécuter Kui via la commande <code>kubectl kui</code> ou directement via l'exécutable <code>Kui</code>.</li> <li><strong>Déploiement Avancé</strong> : Pour les environnements spécifiques, la compilation depuis le code source ou l'utilisation d'une image Docker sont également envisageables.</li> </ul> <p>Une fois déployé, Kui offre un environnement interactif combinant une interface graphique intuitive et un REPL (Read-Eval-Print Loop) pour une exploration et une gestion efficace de vos ressources Kubernetes.</p> <p><strong>Avantages Clés de Kui pour les Opérations Kubernetes</strong></p> <p>Kui apporte des bénéfices substantiels qui optimisent significativement la productivité et l'expérience utilisateur :</p> <ul> <li><strong>Ergonomie Optimisée</strong> : Prise en main rapide pour les utilisateurs novices et efficacité accrue pour les experts.</li> <li><strong>Gain de Productivité Mesurable</strong> : Visualisation claire des données et navigation contextuelle pour des workflows plus rapides.</li> <li><strong>Visibilité Améliorée sur les Infrastructures Complexes</strong> : Supervision et gestion simplifiées des environnements Kubernetes les plus denses.</li> <li><strong>Débogage Accéléré</strong> : Identification et résolution des incidents facilitées par une analyse visuelle des logs et événements.</li> <li><strong>Personnalisation et Extensibilité</strong> : Adaptation de Kui aux besoins spécifiques via la création d'extensions Kubernetes personnalisées, de thèmes, d'icônes et l'amélioration des commandes existantes.</li> </ul> <p><strong>Cas d'Usage Concrets : Optimisation des Workflows Kubernetes</strong></p> <p>Kui trouve sa place dans de nombreux scénarios opérationnels :</p> <ul> <li><strong>Monitoring Continu</strong> : Suivi en temps réel de l'état et des performances des clusters Kubernetes.</li> <li><strong>Diagnostic et Résolution d'Incidents</strong> : Analyse approfondie des logs et événements pour un débogage rapide et précis.</li> <li><strong>Gestion des Déploiements et Mises à Jour</strong> : Simplification des processus de déploiement et de mise à jour applicative.</li> <li><strong>Collaboration et Partage d'Informations</strong> : Facilitation du travail d'équipe et de la communication autour des ressources Kubernetes.</li> <li><strong>Automatisation et Personnalisation des Tâches</strong> : Création de commandes et thèmes sur mesure pour répondre à des besoins spécifiques.</li> </ul> <p><strong>Exemple Pratique : Visualisation Avancée des Pods</strong></p> <p>L'exécution de la commande <code>kubectl get all</code> avec Kui transforme l'affichage ASCII traditionnel en plusieurs tableaux interactifs et triables. Un simple clic sur un pod permet d'accéder instantanément à ses détails, logs et événements associés. Cette approche élimine la manipulation fastidieuse de longs identifiants et centralise l'information de manière accessible.</p> <p><center> <image src="/images/kui/kui-get.png"> </center></p> <p>Détail d'un pod : </p> <p><center> <image src="/images/kui/kui-get-po.png"> </center></p> <p>On peut lancer un terminal (si on a les droits) dans le pod :</p> <p><center> <image src="/images/kui/kui-exec-po.png"> </center></p> <p>On peut aussi voir :</p> <ul> <li>le status du pod</li> <li>Voir le noeud sur lequel le pod est exécuté</li> <li>les logs (kubectl logs)</li> <li>les labels (kubectl --show-labels)</li> <li>les containers composants le pod (kubectl describe)</li> <li>le yaml (kubectl get -o yaml)</li> <li>On peut faire un edit du fichier yaml (kubectl edit)</li> <li>Voir les événements concernant le pod (kubectl get events)</li> </ul> <p>Pour chacune des ressources kubernetes on aura des affichages dediés</p> <p>Exemple les nodes :</p> <p><center> <image src="/images/kui/kui-get-nodes.png"> </center></p> <p><strong>Kui Guidebooks : Automatisation et Guidage des Tâches Complexes</strong></p> <p>Kui introduit une fonctionnalité novatrice : les Guidebooks. Imaginez la possibilité de transformer des procédures complexes en assistants interactifs directement intégrés à votre environnement de travail. C'est précisément la vocation des Guidebooks de Kui.</p> <p><strong>La Simplicité du Markdown au Service de l'Automatisation</strong></p> <p>Un Guidebook est défini par un simple fichier Markdown. La structuration des instructions en Markdown, enrichie de directives spécifiques à Kui, permet de générer un assistant intelligent qui guide l'utilisateur pas à pas à travers une tâche définie.</p> <p><strong>Mécanismes Clés des Guidebooks</strong></p> <ul> <li><strong>Parcours Guidé et Séquencé</strong> : Le Guidebook définit un flux d'actions ordonné. Kui présente chaque étape à l'utilisateur de manière claire et progressive.</li> <li><strong>Gestion Interactive des Choix Utilisateur</strong> : L'assistant attend les décisions de l'utilisateur à chaque étape avant de progresser. Par exemple, une étape "Sélectionnez le cluster cible" attendra la sélection avant de continuer.</li> <li><strong>Validation Contextuelle Intelligente</strong> : Kui peut évaluer dynamiquement la pertinence d'une étape en fonction du contexte utilisateur. Par exemple, la vérification de dépendances sera conditionnée à l'environnement spécifique, évitant ainsi les étapes superflues.</li> <li><strong>Optimisation des Opérations Coûteuses</strong> : Pour les actions longues ou non-idempotentes, les Guidebooks permettent de valider leur nécessité, optimisant ainsi les ressources et le temps.</li> </ul> <p><strong>Potentiel des Guidebooks : Scénarios d'Application</strong></p> <ul> <li><strong>Onboarding Simplifié pour les Nouveaux Collaborateurs</strong> : Création de Guidebooks pour guider les nouveaux membres d'équipe dans la configuration de leur environnement de développement.</li> <li><strong>Déploiements Applicatifs Orchestrés</strong> : Transformation des procédures de déploiement complexes en assistants interactifs pour minimiser les erreurs et garantir la cohérence.</li> <li><strong>Résolution Guidée des Problèmes Techniques</strong> : Développement de Guidebooks de diagnostic pour autonomiser les utilisateurs dans la résolution d'incidents.</li> <li><strong>Automatisation des Tâches Répétitives</strong> : Rationalisation des tâches répétitives et réduction de la charge cognitive grâce à un guidage pas à pas.</li> </ul> <p>Exemples : </p> <ul> <li>Formations intéractives kubernetes</li> </ul> <p><center> <image src="/images/kui/kui-formation-001.png"> </center></p> <p>Les blocs de code sont activables, les résultats sont affichés de manière graphique </p> <p><center> <image src="/images/kui/kui-formation-002.png"> </center></p> <p><center> <image src="/images/kui/kui-formation-003.png"> </center></p> <p><center> <image src="/images/kui/kui-formation-004.png"> </center></p> <p>Kui se positionne comme une solution mature et performante, dépassant le simple rôle d'interface graphique pour Kubernetes. Il s'agit d'un outil puissant qui optimise significativement l'interaction avec vos clusters, permettant un gain de temps substantiel et une amélioration notable de l'efficacité opérationnelle. Pour tout professionnel travaillant avec Kubernetes, Kui représente une solution à envisager sérieusement pour optimiser son workflow.</p>2025-02-07T10:00:00+01:002025-02-07T10:00:00+01:00Hervé Leclerctag:blogppr.alterway.fr,2025-02-07:/k0rdent.html

<p>k0rdent : Un environnement de gestion de conteneurs distribués (DCME) open source</p>

<h1>k0rdent de Mirantis : Plongée au Cœur d'une Plateforme de Gestion de Conteneurs Distribuée (DCME) Open Source pour Kubernetes</h1> <p>Dans le paysage actuel de l'IT, la gestion de Kubernetes à grande échelle et dans des environnements distribués (multi-cloud, edge) représente un défi complexe. Mirantis, acteur majeur de l'écosystème Kubernetes, a répondu à ce besoin avec k0rdent, une plateforme open source de gestion de conteneurs distribuée (DCME - Distributed Container Management Environment). k0rdent se positionne comme un "super plan de contrôle" orchestrant et simplifiant la gestion d'infrastructures Kubernetes hétérogènes. Cet article explore en profondeur l'architecture, les composants, les fonctionnalités techniques et les avantages de k0rdent.</p> <p><strong>Architecture de k0rdent : Une Vision en Couches pour la Gestion Distribuée</strong></p> <p>L'architecture de k0rdent est conçue selon une approche modulaire et distribuée, permettant une gestion centralisée tout en respectant les principes de scalabilité et de résilience. Elle s'articule autour de trois composants clés, chacun jouant un rôle spécifique dans l'orchestration de l'environnement Kubernetes :</p> <ol> <li> <p><strong>k0rdent Cluster Manager (kcm) : Le Chef d'Orchestre des Clusters Kubernetes</strong></p> <p>Le kcm est le cœur de k0rdent, responsable de la gestion du cycle de vie complet des clusters Kubernetes. Il s'appuie sur l'API Cluster (CAPI - Cluster API), un projet open source de la CNCF (Cloud Native Computing Foundation), pour automatiser la création, la configuration, la mise à niveau et la suppression des clusters Kubernetes à travers diverses infrastructures. CAPI permet une approche déclarative de la gestion des clusters, où l'état désiré est défini, et le kcm se charge de le réaliser.</p> <ul> <li> <p><strong>Abstraction de l'Infrastructure :</strong> Le kcm abstrait la complexité des infrastructures sous-jacentes (AWS, Azure, vSphere, OpenStack, bare metal). Grâce à CAPI et à ses fournisseurs d'infrastructure (Infrastructure Providers), k0rdent peut déployer et gérer des clusters sur différentes plateformes de manière uniforme. L'utilisateur interagit avec une API standardisée, indépendamment du fournisseur cloud ou de l'infrastructure on-premise.</p> </li> <li> <p><strong>Gestion du Cycle de Vie Déclarative :</strong> Le kcm met en œuvre une gestion du cycle de vie déclarative. Les configurations de clusters sont définies dans des fichiers YAML, qui sont ensuite appliqués par le kcm. Les mises à jour, les mises à l'échelle et les autres opérations sont également gérées de manière déclarative, garantissant la cohérence et la reproductibilité. Cette approche s'inscrit dans les principes du GitOps, favorisant l'infrastructure as code.</p> </li> <li> <p><strong>Reprise Après Sinistre Intégrée :</strong> La robustesse est au cœur de la conception du kcm. Il intègre des mécanismes de sauvegarde et de restauration pour assurer la reprise après sinistre. Les données critiques du kcm, notamment les configurations et les métadonnées des clusters, peuvent être sauvegardées sur une infrastructure externe (par exemple, un stockage objet S3 compatible). En cas de défaillance, ces données peuvent être restaurées pour rétablir rapidement la plateforme de gestion.</p> </li> <li> <p><strong>Extensibilité via les Fournisseurs CAPI :</strong> L'architecture basée sur CAPI rend k0rdent hautement extensible. De nouveaux fournisseurs d'infrastructure CAPI peuvent être ajoutés pour supporter de nouvelles plateformes cloud ou on-premise. Cela permet à k0rdent de s'adapter aux environnements hybrides et multi-cloud complexes.</p> </li> </ul> </li> <li> <p><strong>k0rdent State Manager (ksm) : Le Gardien de la Configuration et des Politiques</strong></p> <p>Le ksm est responsable de la gestion de l'état et de la configuration des clusters Kubernetes gérés par k0rdent. Il va au-delà de la simple gestion de l'infrastructure et se concentre sur la configuration logicielle et les politiques applicables aux clusters.</p> <ul> <li> <p><strong>Gestion Centralisée des Configurations :</strong> Le ksm permet de définir et d'appliquer des configurations cohérentes à l'ensemble des clusters gérés. Cela inclut les configurations Kubernetes (RBAC, NetworkPolicies, etc.), mais aussi la configuration d'outils et de services externes déployés sur les clusters. Cette centralisation simplifie la gouvernance et assure la conformité.</p> </li> <li> <p><strong>Installation de Services "Beach-Head" :</strong> Le concept de "beach-head services" est central au ksm. Il permet de déployer de manière automatisée des services fondamentaux et partagés sur chaque cluster Kubernetes géré. Ces services peuvent inclure :</p> <ul> <li><strong>Outils d'Observabilité :</strong> Agents Prometheus, Grafana, outils de logging (Fluentd, Elasticsearch, Kibana).</li> <li><strong>Outils de Sécurité :</strong> Solutions de sécurité réseau, scanners de vulnérabilités.</li> <li><strong>Outils de Gestion des Politiques :</strong> OPA (Open Policy Agent), Kyverno pour l'application de politiques de sécurité et de conformité.</li> <li><strong>Outils de Mise en Réseau :</strong> Service meshes (Istio, Linkerd), Ingress controllers.</li> </ul> <p>Ces services "beach-head" sont déployés de manière uniforme sur tous les clusters, garantissant un environnement cohérent et sécurisé.</p> </li> <li> <p><strong>Gestion des Politiques et de la Conformité :</strong> Le ksm peut intégrer des moteurs de politiques comme OPA ou Kyverno pour appliquer des politiques de sécurité, de gouvernance et de conformité à l'échelle de la flotte de clusters. Ces politiques peuvent être définies de manière centralisée et appliquées automatiquement à tous les clusters, assurant la conformité aux exigences réglementaires et aux standards de sécurité de l'organisation.</p> </li> <li> <p><strong>Intégration GitOps :</strong> Le ksm s'intègre naturellement avec les flux de travail GitOps. Les configurations et les politiques sont versionnées dans un dépôt Git, et les modifications sont automatiquement synchronisées avec les clusters gérés par le ksm. Cela renforce la traçabilité, l'auditabilité et la reproductibilité des configurations.</p> </li> </ul> </li> <li> <p><strong>k0rdent Observability and FinOps (kof) : La Visibilité et l'Optimisation des Coûts</strong></p> <p>Le kof fournit une vue unifiée sur l'observabilité et les aspects FinOps (Financial Operations) des clusters Kubernetes gérés. Il agrège les données de monitoring, de logging et de coût provenant de l'ensemble de la flotte de clusters, offrant une visibilité centralisée et des outils d'optimisation.</p> <ul> <li> <p><strong>Observabilité Unifiée :</strong> Le kof collecte et agrège les métriques, les logs et les traces provenant de tous les clusters gérés. Il offre des tableaux de bord centralisés pour visualiser l'état de santé, les performances et les événements de l'ensemble de l'environnement Kubernetes. Cela facilite la détection et la résolution des problèmes, ainsi que l'analyse des performances globales.</p> </li> <li> <p><strong>Monitoring Approfondi :</strong> Le kof va au-delà du monitoring de base des clusters et des nœuds. Il permet de surveiller les applications, les services et les workloads déployés sur les clusters. Des métriques spécifiques aux applications peuvent être collectées et analysées, offrant une visibilité granulaire sur les performances et le comportement des applications distribuées.</p> </li> <li> <p><strong>Gestion des Logs Centralisée :</strong> Le kof centralise la gestion des logs provenant de tous les clusters. Il permet de rechercher, d'analyser et de corréler les logs pour diagnostiquer les problèmes et comprendre le comportement du système. L'intégration avec des outils de logging populaires (Elasticsearch, Loki, etc.) est généralement proposée.</p> </li> <li> <p><strong>Fonctionnalités FinOps :</strong> Le kof intègre des fonctionnalités FinOps pour aider les organisations à maîtriser les coûts de leur infrastructure Kubernetes. Cela peut inclure :</p> <ul> <li><strong>Visualisation des Coûts :</strong> Tableaux de bord affichant les coûts par cluster, par namespace, par application, etc.</li> <li><strong>Allocation des Coûts :</strong> Attribution des coûts aux différentes équipes ou départements.</li> <li><strong>Recommandations d'Optimisation :</strong> Suggestions pour optimiser l'utilisation des ressources et réduire les coûts (redimensionnement des pods, autoscaling, etc.).</li> <li><strong>Politiques de Gestion des Coûts :</strong> Définition de budgets et d'alertes pour contrôler les dépenses.</li> </ul> </li> <li> <p><strong>Alerting et Notifications :</strong> Le kof configure des alertes basées sur des seuils de performance, des erreurs ou des anomalies détectées dans les logs ou les métriques. Ces alertes peuvent être envoyées par email, Slack, PagerDuty ou d'autres canaux de notification, permettant une réponse rapide aux problèmes.</p> </li> </ul> </li> </ol> <p><strong>Fonctionnement et Flux de Travail de k0rdent</strong></p> <p>Le fonctionnement de k0rdent peut être résumé par le flux de travail suivant :</p> <ol> <li> <p><strong>Définition de la Configuration du Cluster :</strong> L'utilisateur définit la configuration du cluster Kubernetes souhaité (type d'infrastructure, version de Kubernetes, ressources, etc.) à l'aide de fichiers YAML compatibles avec CAPI.</p> </li> <li> <p><strong>Déploiement du Cluster via kcm :</strong> Le kcm, en utilisant CAPI et le fournisseur d'infrastructure approprié, provisionne et configure le cluster Kubernetes sur l'infrastructure cible.</p> </li> <li> <p><strong>Configuration et Politiques via ksm :</strong> Le ksm, en se basant sur les configurations définies (souvent versionnées dans Git), configure les services "beach-head", applique les politiques de sécurité et de conformité sur le cluster nouvellement créé.</p> </li> <li> <p><strong>Observabilité et FinOps via kof :</strong> Le kof collecte et agrège les données de monitoring, de logging et de coût du cluster. Les utilisateurs peuvent visualiser ces données via les tableaux de bord du kof pour surveiller l'état du cluster, analyser les performances et optimiser les coûts.</p> </li> <li> <p><strong>Gestion Continue du Cycle de Vie :</strong> Le kcm continue de surveiller le cluster et permet de réaliser des opérations de mise à niveau, de mise à l'échelle, de sauvegarde et de restauration de manière déclarative.</p> </li> </ol> <p><strong>Avantages Techniques Clés de k0rdent</strong></p> <ul> <li> <p><strong>Gestion Centralisée et Unifiée :</strong> k0rdent offre un point de contrôle unique pour gérer l'ensemble de l'infrastructure Kubernetes distribuée, simplifiant les opérations et réduisant la complexité.</p> </li> <li> <p><strong>Automatisation Déclarative et GitOps :</strong> L'approche déclarative et l'intégration GitOps facilitent l'infrastructure as code, la reproductibilité, la traçabilité et l'automatisation des opérations Kubernetes.</p> </li> <li> <p><strong>Abstraction de l'Infrastructure et Portabilité :</strong> Grâce à CAPI, k0rdent abstrait la complexité des infrastructures sous-jacentes, permettant de déployer et de gérer des clusters Kubernetes sur divers environnements de manière uniforme et portable.</p> </li> <li> <p><strong>Extensibilité et Adaptabilité :</strong> L'architecture modulaire et l'utilisation de standards open source (CAPI, OPA, Prometheus, etc.) rendent k0rdent extensible et adaptable à des environnements variés et à des besoins spécifiques.</p> </li> <li> <p><strong>Observabilité Intégrée et FinOps :</strong> Le kof fournit une visibilité centralisée sur l'état de santé, les performances et les coûts de l'infrastructure Kubernetes, permettant une gestion proactive et une optimisation des ressources.</p> </li> <li> <p><strong>Facilitation des Plateformes de Développement Internes (IDP) :</strong> k0rdent simplifie la création de plateformes de développement internes en fournissant une infrastructure Kubernetes gérée et cohérente, ainsi que des outils d'observabilité et de gestion des politiques. Les développeurs peuvent se concentrer sur le développement d'applications sans se soucier de la complexité de la gestion de Kubernetes.</p> </li> </ul> <p><strong>Cas d'Utilisation Techniques</strong></p> <ul> <li><strong>Environnements Multi-Cloud et Hybrides :</strong> Gestion centralisée de clusters Kubernetes déployés sur différents fournisseurs cloud (AWS, Azure, GCP) et environnements on-premise.</li> <li><strong>Edge Computing :</strong> Déploiement et gestion de clusters Kubernetes distribués en périphérie (edge) pour des applications nécessitant une faible latence et un traitement local des données.</li> <li><strong>Grandes Entreprises avec de Nombreuses Équipes et Clusters :</strong> Simplification de la gestion et de la gouvernance d'un grand nombre de clusters Kubernetes, réduisant la charge opérationnelle des équipes DevOps et assurant la cohérence et la conformité.</li> <li><strong>Fournisseurs de Services Gérés (MSP) :</strong> Offre de services Kubernetes managés à leurs clients en s'appuyant sur k0rdent pour la gestion centralisée et automatisée des clusters.</li> </ul> <p><center> <image src="/images/k0rdent/k0rdent.png"> </center></p> <p><strong>Les <code>ServiceTemplate</code> de k0rdent : Déployer des Services Facilement sur Kubernetes</strong></p> <p>k0rdent utilise des <code>ServiceTemplate</code> pour simplifier le déploiement d'applications et de services sur les clusters Kubernetes gérés. Ces templates sont basés sur des charts Helm et permettent de définir comment installer un service spécifique.</p> <p><strong>Points Clés :</strong></p> <ul> <li><strong>Définition des <code>ServiceTemplate</code> :</strong> Ils indiquent à k0rdent où trouver un chart Helm (souvent dans un dépôt privé) pour installer une application. L'exemple de Nginx Ingress montre comment définir le chart, la version et le dépôt Helm dans un <code>ServiceTemplate</code>.</li> <li><strong>Intégration dans <code>ClusterDeployment</code> :</strong> Pour déployer un service sur un cluster, on référence le <code>ServiceTemplate</code> dans la section <code>serviceSpec</code> d'un objet <code>ClusterDeployment</code>. Cela indique à k0rdent d'inclure ce service lors de la création ou de la modification du cluster.</li> <li><strong>Services de base ("Beach-head services") :</strong> Les <code>ServiceTemplate</code> sont idéaux pour déployer des services fondamentaux comme Kyverno ou Ingress Nginx sur tous les clusters gérés de manière cohérente.</li> <li><strong>Personnalisation via <code>values</code> :</strong> On peut personnaliser la configuration des services en passant des valeurs Helm spécifiques dans la section <code>values</code> du <code>ClusterDeployment</code>. Ces valeurs sont fusionnées avec la configuration par défaut du chart Helm. On peut aussi utiliser <code>valuesFrom</code> pour charger les valeurs depuis un ConfigMap ou Secret.</li> <li><strong>Templating des valeurs :</strong> k0rdent permet d'utiliser le templating (avec Sveltos) dans les <code>values</code> pour récupérer dynamiquement des informations du cluster Kubernetes cible (comme l'endpoint du control plane).</li> <li><strong>Suivi de l'état :</strong> L'état du déploiement des services (installé, erreurs, etc.) est visible dans la section <code>status.services</code> de l'objet <code>ClusterDeployment</code>.</li> <li> <p><strong>Suppression de services :</strong> Pour supprimer un service déployé via <code>ServiceTemplate</code>, il suffit de retirer sa définition de la section <code>serviceSpec</code> du <code>ClusterDeployment</code>.</p> </li> <li> <p>Un exemple simple</p> </li> </ul> <p><strong>Scénario :</strong> Nous voulons déployer une application web simple (Nginx) sur un cluster Kubernetes géré par k0rdent, en utilisant un <code>ServiceTemplate</code>.</p> <p><strong>1. Définition du <code>ServiceTemplate</code> pour Nginx :</strong></p> <p>Imaginons que nous ayons un chart Helm simple pour déployer Nginx, disponible dans un dépôt Helm public (ou privé). Nous allons créer un <code>ServiceTemplate</code> qui pointe vers ce chart.</p> <div class="codehilite"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent.mirantis.com/v1alpha1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ServiceTemplate</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">simple-nginx-template-1.0.0</span><span class="w"> </span><span class="c1"># Nom du ServiceTemplate (versionné)</span> <span class="w"> </span><span class="nt">namespace</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent-system</span><span class="w"> </span><span class="c1"># Namespace où le ServiceTemplate est défini (gestion)</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">displayName</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;Nginx</span><span class="nv"> </span><span class="s">Web</span><span class="nv"> </span><span class="s">Server</span><span class="nv"> </span><span class="s">Simple&quot;</span><span class="w"> </span><span class="c1"># Nom affiché dans l&#39;interface utilisateur</span> <span class="w"> </span><span class="nt">description</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;Déploie</span><span class="nv"> </span><span class="s">un</span><span class="nv"> </span><span class="s">serveur</span><span class="nv"> </span><span class="s">web</span><span class="nv"> </span><span class="s">Nginx</span><span class="nv"> </span><span class="s">basique.&quot;</span><span class="w"> </span><span class="c1"># Description du template</span> <span class="w"> </span><span class="nt">helm</span><span class="p">:</span><span class="w"> </span><span class="c1"># Spécification du chart Helm</span> <span class="w"> </span><span class="nt">chartSpec</span><span class="p">:</span> <span class="w"> </span><span class="nt">chart</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">simple-nginx</span><span class="w"> </span><span class="c1"># Nom du chart Helm (dans le dépôt)</span> <span class="w"> </span><span class="nt">version</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">1.0.0</span><span class="w"> </span><span class="c1"># Version du chart Helm</span> <span class="w"> </span><span class="nt">sourceRef</span><span class="p">:</span><span class="w"> </span><span class="c1"># Référence au dépôt Helm</span> <span class="w"> </span><span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">HelmRepository</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent-public-charts</span><span class="w"> </span><span class="c1"># Nom du HelmRepository (défini ailleurs dans k0rdent)</span> </code></pre></div> <p><strong>Explication du <code>ServiceTemplate</code> :</strong></p> <ul> <li><strong><code>apiVersion</code>, <code>kind</code>, <code>metadata</code> :</strong> Définition standard d'un objet Kubernetes <code>ServiceTemplate</code>.</li> <li><strong><code>metadata.name</code> :</strong> <code>simple-nginx-template-1.0.0</code> - Nom unique pour identifier ce template. La version <code>1.0.0</code> est incluse pour le versionnement.</li> <li><strong><code>metadata.namespace</code> :</strong> <code>k0rdent-system</code> - On place généralement les <code>ServiceTemplate</code> de gestion dans un namespace système.</li> <li><strong><code>spec.displayName</code>, <code>spec.description</code> :</strong> Informations pour l'affichage dans l'interface utilisateur de k0rdent, pour aider les utilisateurs à comprendre ce que fait ce template.</li> <li><strong><code>spec.helm</code> :</strong> Indique que ce <code>ServiceTemplate</code> utilise un chart Helm pour le déploiement.<ul> <li><strong><code>chartSpec.chart</code> :</strong> <code>simple-nginx</code> - Nom du chart Helm que nous voulons utiliser.</li> <li><strong><code>chartSpec.version</code> :</strong> <code>1.0.0</code> - Version spécifique du chart Helm à utiliser.</li> <li><strong><code>chartSpec.sourceRef</code> :</strong> Indique où trouver le dépôt Helm.<ul> <li><strong><code>kind: HelmRepository</code> :</strong> Type de référence (dépôt Helm).</li> <li><strong><code>name: k0rdent-public-charts</code> :</strong> Nom d'un objet <code>HelmRepository</code> qui aurait été préalablement défini dans k0rdent et qui pointe vers l'URL du dépôt Helm public contenant le chart <code>simple-nginx</code>. (La définition de <code>HelmRepository</code> n'est pas montrée ici pour simplifier).</li> </ul> </li> </ul> </li> </ul> <p><strong>2. Déploiement de Nginx sur un Cluster via <code>ClusterDeployment</code> :</strong></p> <p>Maintenant, pour déployer ce Nginx sur un cluster géré par k0rdent, nous allons créer ou modifier un <code>ClusterDeployment</code> et y référencer notre <code>ServiceTemplate</code>.</p> <div class="codehilite"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">k0rdent.mirantis.com/v1alpha1</span> <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ClusterDeployment</span> <span class="nt">metadata</span><span class="p">:</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">mon-cluster-web</span><span class="w"> </span><span class="c1"># Nom de notre ClusterDeployment</span> <span class="w"> </span><span class="nt">namespace</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">mon-organisation</span><span class="w"> </span><span class="c1"># Namespace pour notre organisation</span> <span class="nt">spec</span><span class="p">:</span> <span class="w"> </span><span class="nt">template</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">aws-standalone-cp-0-1-0</span><span class="w"> </span><span class="c1"># Template de cluster utilisé (défini ailleurs)</span> <span class="w"> </span><span class="nt">credential</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">aws-credential</span><span class="w"> </span><span class="c1"># Credential AWS pour ce cluster (défini ailleurs)</span> <span class="w"> </span><span class="nt">serviceSpec</span><span class="p">:</span><span class="w"> </span><span class="c1"># Spécification des services à déployer sur ce cluster</span> <span class="w"> </span><span class="nt">services</span><span class="p">:</span> <span class="w"> </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">template</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">simple-nginx-template-1.0.0</span><span class="w"> </span><span class="c1"># Référence au ServiceTemplate Nginx</span> <span class="w"> </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">nginx-web</span><span class="w"> </span><span class="c1"># Nom de l&#39;instance du service (release Helm)</span> <span class="w"> </span><span class="nt">namespace</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">applications-web</span><span class="w"> </span><span class="c1"># Namespace où Nginx sera déployé sur le cluster cible</span> <span class="w"> </span><span class="nt">priority</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">100</span><span class="w"> </span><span class="c1"># Priorité des services (peut être utilisé pour ordonnancer les déploiements)</span> </code></pre></div> <p><strong>Explication du <code>ClusterDeployment</code> :</strong></p> <ul> <li><strong><code>apiVersion</code>, <code>kind</code>, <code>metadata</code> :</strong> Définition standard d'un objet <code>ClusterDeployment</code>.</li> <li><strong><code>metadata.name</code> :</strong> <code>mon-cluster-web</code> - Nom de notre déploiement de cluster.</li> <li><strong><code>metadata.namespace</code> :</strong> <code>mon-organisation</code> - Namespace pour organiser nos déploiements.</li> <li><strong><code>spec.template</code>, <code>spec.credential</code> :</strong> Définissent le template de cluster et les informations d'identification pour l'infrastructure sous-jacente (AWS dans cet exemple). Ces parties ne sont pas directement liées aux <code>ServiceTemplate</code>, mais sont nécessaires pour un <code>ClusterDeployment</code> complet.</li> <li><strong><code>spec.serviceSpec.services</code> :</strong> La partie cruciale pour les <code>ServiceTemplate</code>.<ul> <li><strong><code>- template: simple-nginx-template-1.0.0</code> :</strong> Indique que nous voulons utiliser le <code>ServiceTemplate</code> que nous avons défini pour Nginx. On le référence par son nom.</li> <li><strong><code>name: nginx-web</code> :</strong> Donne un nom à cette instance de service. Ce nom sera utilisé comme nom de release Helm.</li> <li><strong><code>namespace: applications-web</code> :</strong> Spécifie le namespace <code>applications-web</code> sur le cluster cible où Nginx sera déployé. Si ce namespace n'existe pas, k0rdent peut le créer (selon la configuration).</li> <li><strong><code>priority: 100</code> :</strong> Définit une priorité pour ce service. Si vous avez plusieurs services, vous pouvez utiliser les priorités pour contrôler l'ordre de déploiement.</li> </ul> </li> </ul> <p><strong>Ce qui se passe lorsque vous appliquez le <code>ClusterDeployment</code> :</strong></p> <ol> <li>k0rdent lit le <code>ClusterDeployment</code> et détecte la section <code>serviceSpec.services</code>.</li> <li>Pour le service <code>nginx-web</code>, il recherche le <code>ServiceTemplate</code> nommé <code>simple-nginx-template-1.0.0</code> dans le namespace <code>k0rdent-system</code>.</li> <li>k0rdent récupère la définition du <code>ServiceTemplate</code>, notamment les informations sur le chart Helm (<code>simple-nginx</code> version <code>1.0.0</code> depuis le dépôt <code>k0rdent-public-charts</code>).</li> <li>k0rdent utilise Helm pour déployer le chart <code>simple-nginx</code> sur le cluster Kubernetes cible, dans le namespace <code>applications-web</code>, en utilisant le nom de release <code>nginx-web</code>.</li> </ol> <p><strong>Vérification :</strong></p> <p>Une fois le <code>ClusterDeployment</code> appliqué et k0rdent a terminé le déploiement, vous pouvez vérifier sur le cluster cible (via <code>kubectl</code>) que le service Nginx est bien déployé dans le namespace <code>applications-web</code>. Vous devriez voir des Pods Nginx en cours d'exécution et un Service Nginx créé.</p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>pods<span class="w"> </span>-n<span class="w"> </span>applications-web kubectl<span class="w"> </span>get<span class="w"> </span>service<span class="w"> </span>-n<span class="w"> </span>applications-web </code></pre></div> <p><strong>Conclusion</strong></p> <p>k0rdent de Mirantis représente une solution technique robuste et complète pour la gestion de conteneurs distribuée avec Kubernetes. Son architecture modulaire, son approche déclarative, son intégration avec CAPI et son focus sur l'observabilité et le FinOps en font une plateforme puissante pour les organisations qui cherchent à maîtriser la complexité de Kubernetes à grande échelle et dans des environnements distribués. En tant que projet open source, k0rdent bénéficie de la contribution de la communauté, assurant son évolution et son adaptation aux besoins du marché. Pour les architectes, les ingénieurs DevOps et les responsables de plateformes Kubernetes, k0rdent est une solution à considérer sérieusement pour simplifier et optimiser la gestion de leurs infrastructures conteneurisées.</p>2025-01-09T10:00:00+01:002025-01-09T10:00:00+01:00Hervé Leclerctag:blogppr.alterway.fr,2025-01-09:/evolution-des-applications-saas.html

<p>L'IA détrône les applications : Satya Nadella et la révolution des agents intelligents</p>

<h1>L'IA détrône les applications : Satya Nadella et la révolution des agents intelligents</h1> <p>Dans une interview récente, Satya Nadella, PDG de Microsoft, a partagé une vision audacieuse de l'avenir de la technologie, où l'intelligence artificielle (IA) et les <strong>agents intelligents</strong> jouent un rôle central. </p> <p>Loin d'être de simples assistants, ces agents sont appelés à remplacer les applications traditionnelles telles que nous les connaissons. </p> <p>Cette perspective, qui remet en question le modèle actuel du logiciel en tant que service (SaaS), mérite une analyse approfondie.</p> <p><center></p> <iframe width="560" height="315" src="https://www.youtube.com/embed/a_RjOhCkhvQ?si=z8lphNuY64fgqawV" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe> <p></center></p> <ul> <li><a href="https://www.youtube.com/embed/a_RjOhCkhvQ?si=z8lphNuY64fgqawV">lien vidéo</a></li> </ul> <h2>Les applications, simples façades de bases de données</h2> <p>Selon Nadella, les applications d'entreprise (Biz apps) comme Dynamics ne sont fondamentalement que des bases de données avec une logique métier. Cette logique, qui gère les interactions avec les données, est sur le point de migrer vers des <strong>agents d'IA</strong>. Ces agents deviendront les principaux acteurs de l'interaction avec les données, capables d'orchestrer les actions et les analyses. Ils ne se limiteront pas à une seule base de données, mais pourront interagir avec plusieurs sources d'informations.</p> <h2>L'agent d'IA : la nouvelle interface utilisateur</h2> <p>L'idée clé de cette vision est que les <strong>agents d'IA</strong> deviendront la principale interface d'interaction avec les données, remplaçant ainsi l'approche traditionnelle des applications avec des interfaces utilisateurs. Nadella envisage un avenir où les utilisateurs interagissent avec un <strong>Copilot</strong> qui appelle des agents spécialisés pour chaque tâche. Par exemple, un utilisateur pourrait faire appel à un agent pour Excel, un agent pour Word, et ainsi de suite.</p> <h2>Un exemple : Excel, du tableur à outil pour l'IA</h2> <p>L'exemple d'Excel est particulièrement révélateur. Nadella souligne qu'Excel, combiné avec Python et un interpréteur de code, devient un outil puissant pour l'analyse de données avec l'aide d'un agent. Il imagine un scénario où Copilot utilise Excel comme un outil pour générer des analyses, des visualisations, et même des plans, en s'appuyant sur les capacités de Python. <strong>Excel n'est plus un tableur isolé, mais une interface utilisée par les agents d'IA pour réaliser des analyses complexes.</strong></p> <h2>Copilot : l'orchestrateur de l'IA</h2> <p>L'approche de Microsoft est de construire <strong>Copilot</strong> comme une <strong>couche d'organisation pour l'IA</strong>, avec des agents spécialisés pour chaque application. Cela implique une nouvelle façon de penser le travail, où les agents d'IA prennent en charge des tâches qui étaient auparavant effectuées par les utilisateurs directement. Copilot devient l'interface principale qui permet d'interagir avec ces agents.</p> <h2>La fin du SaaS traditionnel ?</h2> <p>Selon Nadella, l'ère des logiciels en tant que service (SaaS) est en train de changer. Les applications SaaS sont considérées comme des interfaces superficielles au-dessus des bases de données, qui seront progressivement remplacées par des interactions directes avec des <strong>agents d'IA</strong>. L'accent sera mis sur l'efficacité des bases de données et la capacité des agents à interagir avec diverses sources de données.</p> <h2>Implications pour l'avenir</h2> <p>Cette vision a des implications profondes pour l'avenir de la technologie :</p> <ul> <li> <p><strong>Disruption du modèle SaaS :</strong> Le modèle SaaS traditionnel est remis en question. Les applications ne sont plus vues comme des outils autonomes, mais plutôt comme des canaux d'interaction avec des agents d'IA. Les entreprises devront s'adapter à ce changement ou disparaître</p> </li> <li> <p><strong>L'IA au cœur de la logique métier :</strong> La logique métier migre de l'application vers l'IA, ce qui signifie que les agents d'IA deviennent les acteurs principaux dans la manipulation et l'analyse des données.</p> </li> <li> <p><strong>Automatisation et efficacité :</strong> L'intégration d'agents d'IA vise à automatiser de nombreuses tâches et à rendre les workflows plus efficaces. L'IA permettra aux utilisateurs d'accomplir des tâches complexes sans avoir à manipuler directement des données ou utiliser des interfaces complexes.</p> </li> <li> <p><strong>Transformation des rôles :</strong> Les développeurs devront se concentrer sur la création d'agents d'IA intelligents et capables d'interagir avec des données et des outils divers. Le développement d'applications traditionnelles pourrait diminuer, remplacé par la création d'agents d'IA.</p> </li> </ul>2024-12-19T12:00:00+01:002024-12-19T12:00:00+01:00Hervé Leclerctag:blogppr.alterway.fr,2024-12-19:/openkruise-argoproj.html

<p>Optimisation des Déploiements Kubernetes : La Synergie entre OpenKruise et Argo</p>

<h1>Optimisation des Déploiements Kubernetes : La Synergie entre OpenKruise et Argo</h1> <p>Dans l'écosystème Kubernetes en constante évolution, la gestion efficace des applications est primordiale. OpenKruise et Argo, deux projets open source incubés par la CNCF (Cloud Native Computing Foundation), offrent des solutions puissantes pour relever ces défis. Bien qu'ils aient des objectifs distincts, ils se complètent de manière remarquable, créant une synergie qui améliore considérablement les processus de déploiement, de mise à jour et de gestion des applications Kubernetes. Cet article de blog technique explore cette complémentarité, en fournissant des exemples concrets pour illustrer comment ces outils peuvent être utilisés ensemble pour une gestion d'applications Kubernetes optimisée.</p> <h2>OpenKruise : L'automatisation avancée pour Kubernetes</h2> <p>OpenKruise est une suite d'outils d'extension pour Kubernetes, axée sur l'<strong>automatisation de la gestion des applications à grande échelle</strong>. Il se concentre sur les aspects suivants :</p> <ul> <li><strong>Workloads avancés</strong> : OpenKruise étend les workloads Kubernetes de base (comme Deployment, StatefulSet, DaemonSet) avec des fonctionnalités améliorées telles que les mises à jour in-place, des stratégies de mise à l'échelle et de mise à niveau configurables et des opérations parallèles. Cela permet des déploiements plus rapides et plus efficaces, avec moins d'impact sur les systèmes environnants.</li> <li><strong>Gestion "bypass"</strong> : OpenKruise permet de gérer les conteneurs sidecar et les déploiements multi-domaines sans modifier directement les workloads existants. Par exemple, SidecarSet injecte et met à jour les conteneurs sidecar de manière indépendante, et WorkloadSpread contrôle la répartition des pods sur différents types de nœuds.</li> <li><strong>Protection de la haute disponibilité</strong> : OpenKruise offre des mécanismes pour protéger les ressources Kubernetes contre les suppressions en cascade, et PodUnavailableBudget pour prévenir les disruptions d'applications.</li> <li><strong>Fonctionnalités opérationnelles de haut niveau</strong> : Il fournit des outils comme ImagePullJob pour pré-télécharger les images et ContainerRecreateRequest pour redémarrer des conteneurs spécifiques dans un Pod en cours d'exécution.</li> </ul> <h3>Exemple 1 : Mise à jour in-place avec CloneSet et SidecarSet</h3> <p>Supposons que vous ayez une application web déployée avec un CloneSet, avec un conteneur principal (nginx) et un conteneur sidecar (logtail) pour la collecte de logs. OpenKruise permet d'effectuer les actions suivantes :</p> <ol> <li><strong>Mise à jour de l'image du conteneur nginx</strong> : Au lieu de recréer les pods, vous pouvez effectuer une mise à jour in-place du conteneur nginx en utilisant les fonctionnalités de CloneSet. Cela réduit le temps de mise à jour et évite les perturbations inutiles.</li> <li><strong>Mise à jour indépendante du conteneur logtail</strong> : En utilisant SidecarSet, vous pouvez mettre à jour l'image du conteneur logtail sans affecter le conteneur nginx ni interrompre le service. SidecarSet peut même effectuer des mises à jour à chaud (hot upgrades) pour les conteneurs sidecar qui gèrent le trafic, tels que les proxies ou les mesh containers.</li> <li><strong>Gestion des logs</strong> : SidecarSet facilite la collecte des logs en partageant les volumes et les variables d'environnement entre les conteneurs principal et sidecar.</li> </ol> <h3>Exemple 2 : Déploiement multi-domaines avec WorkloadSpread</h3> <p>Imaginez que vous déployiez une application dans différents environnements (par exemple, zones de disponibilité ou types de nœuds). OpenKruise permet d'utiliser WorkloadSpread pour :</p> <ol> <li><strong>Définir des sous-ensembles (subsets)</strong> : Vous pouvez définir des subsets pour les nœuds normaux et élastiques, en spécifiant le nombre maximal de réplicas pour chacun.</li> <li><strong>Répartition des pods</strong> : WorkloadSpread distribue les pods sur les différents subsets en fonction des règles définies, assurant ainsi que votre application est déployée sur les différents domaines configurés.</li> <li><strong>Contrôle de la suppression des pods</strong> : En collaboration avec les annotations Kubernetes et OpenKruise, WorkloadSpread gère la priorité de suppression des pods afin d'éviter des perturbations inutiles pendant les opérations de scale-in.</li> </ol> <h2>Argo : La puissance du GitOps pour les déploiements Kubernetes</h2> <p>Argo est un ensemble d'outils open source axés sur les pratiques GitOps, offrant une <strong>approche déclarative et automatisée de la gestion des applications sur Kubernetes</strong>. Les principaux outils d'Argo sont :</p> <ul> <li><strong>Argo CD</strong> : Un outil de livraison continue (CD) basé sur GitOps pour Kubernetes. Il synchronise automatiquement l'état de l'application définie dans les dépôts Git avec les environnements cibles. Il prend en charge diverses méthodes de configuration, notamment Kustomize, Helm, et les fichiers YAML.</li> <li><strong>Argo Workflows</strong> : Un moteur de workflow natif pour Kubernetes, permettant d'orchestrer des tâches parallèles sous forme de DAG (Directed Acyclic Graph) ou de séquences de tâches. Il est idéal pour les pipelines de CI/CD, le traitement des données et l'automatisation de l'infrastructure.</li> <li><strong>Argo Rollouts</strong> : Un contrôleur Kubernetes qui fournit des stratégies de déploiement avancées telles que les déploiements bleu-vert et canari, avec analyse et rollback automatisés.</li> <li><strong>Argo Events</strong> : Un gestionnaire de dépendances basé sur les événements, permettant de définir des actions à déclencher en fonction de diverses sources d'événements.</li> </ul> <h3>Exemple 3 : Déploiement continu avec Argo CD</h3> <p>Argo CD est l'outil central de la suite Argo pour implémenter le GitOps. Il permet de :</p> <ol> <li><strong>Définir l'état souhaité</strong> : Vous définissez la configuration de votre application (manifestes Kubernetes, Helm charts, etc.) dans un dépôt Git.</li> <li><strong>Synchronisation automatique</strong> : Argo CD surveille en permanence le dépôt Git et synchronise automatiquement les modifications avec votre cluster Kubernetes cible.</li> <li><strong>Détection des dérives</strong> : Argo CD détecte et visualise les différences entre l'état actuel de l'application et l'état souhaité, offrant des options de synchronisation automatique ou manuelle.</li> <li><strong>Rollback</strong> : Vous pouvez facilement revenir à n'importe quelle version précédente de votre configuration en utilisant l'historique du dépôt Git.</li> </ol> <h3>Exemple 4 : Pipelines CI/CD avec Argo Workflows</h3> <p>Argo Workflows est un puissant outil pour créer des pipelines complexes sur Kubernetes. Il peut être utilisé pour :</p> <ol> <li><strong>Définir des workflows</strong> : Vous définissez chaque étape d'un workflow comme un conteneur et modélisez les dépendances entre ces étapes.</li> <li><strong>Orchestrer des tâches parallèles</strong> : Argo Workflows permet d'exécuter des tâches en parallèle, ce qui est idéal pour les pipelines de CI/CD ou de traitement de données.</li> <li><strong>Gérer les artefacts</strong> : Argo Workflows prend en charge les artefacts, ce qui permet de suivre et de gérer les entrées et les sorties de chaque étape du workflow.</li> <li><strong>Intégrer les notifications</strong> : Argo Workflows permet de configurer des notifications pour les événements importants, tels que la fin d'un workflow ou l'échec d'une étape.</li> <li><strong>Utilisation d'Argo Events</strong> : Argo Events peut être utilisé pour déclencher des workflows basés sur des événements spécifiques.</li> </ol> <h2>La complémentarité : OpenKruise et Argo, un duo gagnant</h2> <p>Bien qu'ils soient des outils distincts, OpenKruise et Argo peuvent être combinés pour créer une solution de gestion d'applications Kubernetes encore plus robuste. Voici comment :</p> <ul> <li><strong>OpenKruise améliore les fondations, Argo automatise le cycle de vie</strong> : OpenKruise fournit les outils pour une gestion plus fine des workloads, tandis qu'Argo automatise le déploiement et la synchronisation de ces workloads.</li> <li><strong>Mises à jour intelligentes avec OpenKruise, contrôlées par Argo</strong> : OpenKruise permet des mises à jour in-place et des mises à jour indépendantes des conteneurs sidecar, tandis qu'Argo CD garantit que ces mises à jour sont appliquées conformément à la configuration définie dans Git.</li> <li><strong>Workflows puissants avec Argo Workflows et déploiements sophistiqués avec OpenKruise</strong> : Argo Workflows peut être utilisé pour créer des pipelines CI/CD automatisés qui déclenchent des déploiements via Argo CD, en utilisant les fonctionnalités de déploiement avancées d'OpenKruise telles que les mises à jour in-place et la gestion multi-domaines.</li> <li><strong>Combinaison des capacités de Rollouts avec OpenKruise et Argo</strong> : OpenKruise Rollouts et Argo Rollouts peuvent être utilisé en fonction des use-case. Argo Rollouts permet un contrôle plus fin des stratégies de déploiement, tandis que Kruise Rollouts permet des mises à jour multi-batch ou des déploiements canari. Les deux peuvent s'intégrer avec Argo CD.</li> </ul> <h3>Exemple 5 : Un workflow CI/CD complet</h3> <p>Un pipeline CI/CD typique pourrait fonctionner comme suit :</p> <ol> <li><strong>Développement</strong> : Les développeurs modifient le code de l'application et le poussent vers un dépôt Git.</li> <li><strong>CI</strong> : Argo Workflows est déclenché par un commit vers le dépôt Git, effectue des tests unitaires, construit une image de conteneur, et la pousse vers un registre d'images.</li> <li><strong>CD</strong> :<ul> <li>Argo CD synchronise l'état de l'application déployée dans Kubernetes avec le dépôt Git, en utilisant les nouvelles images de conteneurs construites.</li> <li>OpenKruise, via SidecarSet, injecte et gère les sidecars (par exemple, logtail) en toute transparence. OpenKruise via WorkloadSpread assure la bonne répartition des pods sur les différents environnements.</li> <li>Si une mise à jour de l'application est nécessaire, Argo Rollouts peut être utilisé pour un déploiement canari ou bleu/vert, en s'appuyant sur la gestion avancée des workloads d'OpenKruise.</li> </ul> </li> <li><strong>Monitoring</strong> : Les métriques de l'application sont monitorées via Prometheus et Grafana.</li> </ol> <p>Dans ce scénario, Argo et OpenKruise travaillent en harmonie : Argo assure la cohérence du processus de déploiement tandis qu'OpenKruise fournit une meilleure fondation pour des mises à jour efficaces et une gestion plus fine des applications.</p> <h2>Conclusion</h2> <p>OpenKruise et Argo, bien qu'étant des projets distincts, offrent une <strong>complémentarité remarquable pour améliorer la gestion des applications Kubernetes</strong>. OpenKruise fournit des outils avancés pour optimiser les workloads et automatiser les opérations, tandis qu'Argo apporte la puissance du GitOps pour l'automatisation des déploiements. Utilisés ensemble, ils offrent un puissant écosystème pour des déploiements Kubernetes plus efficaces, plus robustes et plus fiables.</p> <p>L'intégration de ces deux outils dans votre infrastructure Kubernetes peut vous aider à <strong>réduire la complexité, à améliorer la vitesse de déploiement et à assurer une meilleure disponibilité de vos applications</strong>.</p> <p>En tirant parti des fonctionnalités avancées de gestion des applications d'OpenKruise et de la puissance du GitOps d'Argo, les entreprises peuvent optimiser leurs flux de travail de développement et de déploiement, et tirer le meilleur parti de leur infrastructure Kubernetes. L'avenir de la gestion des applications Kubernetes réside dans cette synergie, où chaque outil joue son rôle spécifique pour un résultat global optimisé.</p>2024-12-19T10:00:00+01:002024-12-19T10:00:00+01:00Hervé Leclerctag:blogppr.alterway.fr,2024-12-19:/kubevpn.html

<p>KubeVPN : Votre Environnement de Développement Cloud Natif Connecté à Kubernetes</p>

<h1>KubeVPN : Votre Environnement de Développement Cloud Natif Connecté à Kubernetes</h1> <p>KubeVPN est un outil puissant qui transforme la façon dont les développeurs interagissent avec les environnements Kubernetes. Il offre un <strong>environnement de développement cloud natif</strong> qui se connecte de manière transparente au réseau de votre cluster Kubernetes. Avec KubeVPN, vous pouvez accéder aux ressources de votre cluster Kubernetes directement depuis votre machine locale, simplifiant considérablement le développement et le débogage d'applications cloud natives.</p> <h2>Les Défis du Développement Cloud Natif</h2> <p>Le développement d'applications pour Kubernetes peut être complexe. Traditionnellement, les développeurs sont confrontés aux défis suivants :</p> <ul> <li><strong>Difficulté d'accès aux ressources du cluster</strong> : Accéder aux services et pods du cluster Kubernetes nécessite souvent des configurations complexes et des redirections de ports.</li> <li><strong>Environnement de développement non cohérent</strong> : Les environnements locaux peuvent différer significativement de ceux du cluster, ce qui peut entraîner des problèmes d'intégration et de déploiement.</li> <li><strong>Complexité du débogage</strong> : Le débogage d'applications exécutées dans le cluster Kubernetes peut être difficile, car il faut souvent se connecter aux pods et analyser les journaux à distance.</li> </ul> <p>KubeVPN répond à ces défis en fournissant une connexion directe et cohérente au réseau Kubernetes, permettant aux développeurs de travailler plus efficacement.</p> <h2>Comment KubeVPN Simplifie le Développement Kubernetes</h2> <p>KubeVPN offre une approche innovante pour le développement cloud natif, en établissant un tunnel sécurisé entre votre machine locale et votre cluster Kubernetes. Voici les fonctionnalités clés qui rendent KubeVPN si utile :</p> <h3>1. Connexion au Réseau Kubernetes</h3> <p>KubeVPN vous permet de vous connecter au réseau de votre cluster Kubernetes en utilisant la commande <code>kubevpn connect</code>. Cette commande crée un tunnel et ajoute une route vers une interface virtuelle, comme <code>tun0</code>, redirigeant le trafic vers un gestionnaire de trafic distant. Vous pouvez alors accéder aux ressources du cluster à l'aide des noms de service ou des adresses IP des pods/services. Un mot de passe administrateur est requis pour créer le tunnel.</p> <div class="codehilite"><pre><span></span><code>kubevpn<span class="w"> </span>connect </code></pre></div> <p>Résultat</p> <div class="codehilite"><pre><span></span><code><span class="nt">...</span> <span class="nb">+----------------------------------------------------------+</span> <span class="c">| Now you can access resources in the kubernetes cluster ! |</span> <span class="nb">+----------------------------------------------------------+</span> </code></pre></div> <p>Après la connexion, vous pouvez vérifier l'état de la connexion avec la commande <code>kubevpn status</code>:</p> <div class="codehilite"><pre><span></span><code>kubevpn<span class="w"> </span>status </code></pre></div> <p>Exemple de résultat :</p> <div class="codehilite"><pre><span></span><code>ID Mode Cluster Kubeconfig Namespace Status Netif 0 full k8s-train /Users/hleclerc/.kube/config default Connected utun7 </code></pre></div> <p>Deployons juste un nginx via helm </p> <div class="codehilite"><pre><span></span><code>helm install hello-world oci://ghcr.io/herveleclerc/hello-world --version 0.1.0 </code></pre></div> <p>Résultat </p> <div class="codehilite"><pre><span></span><code><span class="n">Pulled</span><span class="o">:</span><span class="w"> </span><span class="n">ghcr</span><span class="o">.</span><span class="na">io</span><span class="sr">/herveleclerc/</span><span class="n">hello</span><span class="o">-</span><span class="n">world</span><span class="o">:</span><span class="mf">0.1</span><span class="o">.</span><span class="mi">0</span> <span class="n">Digest</span><span class="o">:</span><span class="w"> </span><span class="n">sha256</span><span class="o">:</span><span class="mi">5</span><span class="n">eba2624abeeebb332c06c08e4ccb3015d6a449272bc937f877b7711b128ae68</span> <span class="n">NAME</span><span class="o">:</span><span class="w"> </span><span class="n">hello</span><span class="o">-</span><span class="n">world</span> <span class="n">LAST</span><span class="w"> </span><span class="n">DEPLOYED</span><span class="o">:</span><span class="w"> </span><span class="n">Thu</span><span class="w"> </span><span class="n">Dec</span><span class="w"> </span><span class="mi">19</span><span class="w"> </span><span class="mi">09</span><span class="o">:</span><span class="mi">54</span><span class="o">:</span><span class="mi">21</span><span class="w"> </span><span class="mi">2024</span> <span class="n">NAMESPACE</span><span class="o">:</span><span class="w"> </span><span class="k">default</span> <span class="n">STATUS</span><span class="o">:</span><span class="w"> </span><span class="n">deployed</span> <span class="n">REVISION</span><span class="o">:</span><span class="w"> </span><span class="mi">1</span> <span class="n">NOTES</span><span class="o">:</span> <span class="mi">1</span><span class="o">.</span><span class="w"> </span><span class="n">Get</span><span class="w"> </span><span class="n">the</span><span class="w"> </span><span class="n">application</span><span class="w"> </span><span class="n">URL</span><span class="w"> </span><span class="n">by</span><span class="w"> </span><span class="n">running</span><span class="w"> </span><span class="n">these</span><span class="w"> </span><span class="n">commands</span><span class="o">:</span> <span class="w"> </span><span class="n">export</span><span class="w"> </span><span class="n">POD_NAME</span><span class="o">=</span><span class="n">$</span><span class="o">(</span><span class="n">kubectl</span><span class="w"> </span><span class="kd">get</span><span class="w"> </span><span class="n">pods</span><span class="w"> </span><span class="o">--</span><span class="kd">namespace</span><span class="w"> </span><span class="k">default</span><span class="w"> </span><span class="o">-</span><span class="n">l</span><span class="w"> </span><span class="s2">&quot;app.kubernetes.io/name=hello-world,app.kubernetes.io/instance=hello-world&quot;</span><span class="w"> </span><span class="o">-</span><span class="n">o</span><span class="w"> </span><span class="n">jsonpath</span><span class="o">=</span><span class="s2">&quot;{.items[0].metadata.name}&quot;</span><span class="o">)</span> <span class="w"> </span><span class="n">export</span><span class="w"> </span><span class="n">CONTAINER_PORT</span><span class="o">=</span><span class="n">$</span><span class="o">(</span><span class="n">kubectl</span><span class="w"> </span><span class="kd">get</span><span class="w"> </span><span class="n">pod</span><span class="w"> </span><span class="o">--</span><span class="kd">namespace</span><span class="w"> </span><span class="k">default</span><span class="w"> </span><span class="n">$POD_NAME</span><span class="w"> </span><span class="o">-</span><span class="n">o</span><span class="w"> </span><span class="n">jsonpath</span><span class="o">=</span><span class="s2">&quot;{.spec.containers[0].ports[0].containerPort}&quot;</span><span class="o">)</span> <span class="w"> </span><span class="n">echo</span><span class="w"> </span><span class="s2">&quot;Visit http://127.0.0.1:8080 to use your application&quot;</span> <span class="w"> </span><span class="n">kubectl</span><span class="w"> </span><span class="o">--</span><span class="kd">namespace</span><span class="w"> </span><span class="k">default</span><span class="w"> </span><span class="n">port</span><span class="o">-</span><span class="n">forward</span><span class="w"> </span><span class="n">$POD_NAME</span><span class="w"> </span><span class="mi">8080</span><span class="o">:</span><span class="n">$CONTAINER_PORT</span> </code></pre></div> <p>Regardons le pod déployé par kubevpn et helm</p> <div class="codehilite"><pre><span></span><code>kubectl get svc,po -o wide NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR service/hello-world ClusterIP 10.0.145.54 &lt;none&gt; 80/TCP 3m48s app.kubernetes.io/instance=hello-world,app.kubernetes.io/name=hello-world service/kubernetes ClusterIP 10.0.0.1 &lt;none&gt; 443/TCP 241d &lt;none&gt; service/kubevpn-traffic-manager ClusterIP 10.0.123.176 &lt;none&gt; 8422/UDP,10800/TCP,9002/TCP,80/TCP,53/UDP 115s app=kubevpn-traffic-manager NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/hello-world-57f994fd7d-j8th6 1/1 Running 0 3m48s 10.224.0.102 aks-agentpool-35883522-vmss00001g &lt;none&gt; &lt;none&gt; pod/kubevpn-traffic-manager-8556f588c8-749bf 3/3 Running 0 114s 10.224.0.116 aks-agentpool-35883522-vmss00001g &lt;none&gt; &lt;none&gt; </code></pre></div> <p>Vous pouvez tester la connexion en utilisant <code>ping</code> avec l'adresse IP d'un pod :</p> <div class="codehilite"><pre><span></span><code>ping<span class="w"> </span><span class="m">10</span>.224.0.116 </code></pre></div> <p>Vous pouvez aussi tester la connexion en utilisant <code>curl</code> avec l'adresse IP d'un service:</p> <div class="codehilite"><pre><span></span><code>curl<span class="w"> </span><span class="m">10</span>.224.0.102 </code></pre></div> <p>KubeVPN prend en charge la résolution des noms DNS Kubernetes, vous pouvez donc accéder à un service nommé <code>hello-world</code> dans l'espace de noms <code>default</code> en utilisant les noms suivants: * <code>hello-world</code> * <code>hello-world.default</code> * <code>hello-world.default.svc.cluster.local</code> Vous pouvez même utiliser le nom court de domaine comme <code>productpage</code>.</p> <div class="codehilite"><pre><span></span><code>curl<span class="w"> </span>hello-world<span class="w"> </span><span class="m">1</span><span class="w"> </span><span class="c1"># Nom court</span> curl<span class="w"> </span>hello-world.default.svc.cluster.local </code></pre></div> <p><strong>Important :</strong> La résolution des noms courts ne fonctionne que dans l'espace de noms où <code>kubevpn-traffic-manager</code> est déployé.</p> <h3>2. Interception du Trafic Inbound</h3> <p>KubeVPN permet également d'intercepter le trafic entrant des services Kubernetes et de le rediriger vers votre machine locale. Cette fonctionnalité est particulièrement utile pour le débogage et le développement, car elle vous permet de tester localement vos modifications tout en les intégrant dans l'environnement Kubernetes.</p> <p>Vous pouvez utiliser la commande <code>kubevpn proxy</code> pour intercepter le trafic entrant d'un déploiement spécifique, par exemple <code>productpage</code>:</p> <div class="codehilite"><pre><span></span><code>kubevpn<span class="w"> </span>proxy<span class="w"> </span>deployment/hello-world </code></pre></div> <p>Vous pouvez même définir une règle pour que seul le trafic avec un header spécifique soit redirigé vers votre machine locale, par exemple, avec le header <code>app=monapp</code>.</p> <div class="codehilite"><pre><span></span><code>kubevpn<span class="w"> </span>proxy<span class="w"> </span>deployment/hello-world<span class="w"> </span>--headers<span class="w"> </span><span class="nv">app</span><span class="o">=</span>monapp </code></pre></div> <p>Pour annuler le proxy, vous pouvez utiliser la commande <code>kubevpn leave</code> :</p> <div class="codehilite"><pre><span></span><code>kubevpn<span class="w"> </span>leave<span class="w"> </span>deployment/hello-world </code></pre></div> <p>Plus d'informations ici : <a href="https://www.kubevpn.cn/docs/functions/reverse_proxy">reverse proxy</a></p> <h3>3. Modes de Connexion</h3> <p>KubeVPN propose différents modes de connexion pour s'adapter à vos besoins :</p> <ul> <li><strong>Mode Connect</strong> : Crée un tunnel simple pour connecter votre machine locale au cluster Kubernetes.</li> <li><strong>Mode Reverse</strong> : Injecte un conteneur sidecar dans le contrôleur, bloque le trafic entrant et le redirige vers votre machine locale via un tunnel.</li> <li><strong>Mode Mesh</strong> : Utilise Envoy comme proxy. Si les headers contiennent une clé-valeur spéciale, le trafic est routé vers la machine locale, sinon, il est routé vers le service d'origine.</li> <li><strong>Mode Lite</strong> : (<code>--lite=true</code>) Permet de se connecter à plusieurs clusters Kubernetes simultanément, conçu pour la connexion à plusieurs réseaux de clusters.</li> <li><strong>Mode Full</strong> : Par défaut, (<code>--lite=false</code>) Permet de se connecter à un réseau de clusters et prend également en charge le proxy du trafic entrant vers votre machine locale.</li> </ul> <p>Vous pouvez vous connecter à plusieurs clusters en utilisant les modes <code>lite</code> et <code>full</code> :</p> <div class="codehilite"><pre><span></span><code><span class="c1"># Se connecter à 2 clusters en mode lite</span> kubevpn<span class="w"> </span>connect kubevpn<span class="w"> </span>status kubevpn<span class="w"> </span>connect<span class="w"> </span>-n<span class="w"> </span>default<span class="w"> </span>--kubeconfig<span class="w"> </span>~/.kube/dev_config<span class="w"> </span>--lite </code></pre></div> <p>L'état des connexions sera alors mis à jour en conséquence:</p> <div class="codehilite"><pre><span></span><code>ID Mode Cluster Kubeconfig Namespace Status 0 full k8s-train /Users/hleclerc/.kube/config default Connected 1 lite k8s-dev /Users/hleclerc/.kube/dev_config default Connected </code></pre></div> <h3>4. Mode Développement Local avec Docker</h3> <p>KubeVPN va encore plus loin en permettant d'exécuter vos pods Kubernetes dans des conteneurs Docker locaux. Cela vous garantit un environnement de développement identique à celui du cluster, avec les mêmes variables d'environnement, volumes et configuration réseau.</p> <p>J'utilise limactl </p> <p>Voici un exemple de commande pour lancer le mode développement :</p> <div class="codehilite"><pre><span></span><code>kubevpn<span class="w"> </span>dev<span class="w"> </span>deployment/hello-world<span class="w"> </span>--entrypoint<span class="w"> </span>sh </code></pre></div> <p>Cette commande : * Connecte votre machine locale au réseau du cluster. * Injecte un sidecar pour intercepter le trafic entrant. * Lance un conteneur Docker avec l'image de votre pod.</p> <p>Vous pouvez utiliser <code>localhost:port</code> pour accéder à votre conteneur. L'environnement, le volume et le réseau sont les mêmes que dans le pod Kubernetes distant. Vous pouvez choisir de ne pas utiliser de proxy:</p> <div class="codehilite"><pre><span></span><code>kubevpn<span class="w"> </span>dev<span class="w"> </span>deployment/hello-world<span class="w"> </span>--no-proxy </code></pre></div> <p>Vous pouvez aussi utiliser un image docker spécifique et un point d'entrée particulier:</p> <div class="codehilite"><pre><span></span><code>kubevpn<span class="w"> </span>dev<span class="w"> </span>deployment/hello-world<span class="w"> </span>--dev-image<span class="w"> </span><span class="o">[</span>docker<span class="w"> </span>registry<span class="o">]</span>/<span class="o">[</span>namespace<span class="o">]</span>/<span class="o">[</span>repo<span class="o">]</span>:<span class="o">[</span>tag<span class="o">]</span><span class="w"> </span>--entrypoint<span class="w"> </span>/bin/bash </code></pre></div> <p>KubeVPN prend en charge le Docker in Docker (DinD).</p> <div class="codehilite"><pre><span></span><code>docker<span class="w"> </span>run<span class="w"> </span>-it<span class="w"> </span>--privileged<span class="w"> </span>--sysctl<span class="w"> </span>net.ipv6.conf.all.disable_ipv6<span class="o">=</span><span class="m">0</span><span class="w"> </span>-v<span class="w"> </span>/var/run/docker.sock:/var/run/docker.sock<span class="w"> </span>-v<span class="w"> </span>/tmp:/tmp<span class="w"> </span>-v<span class="w"> </span>~/.kube/config:/root/.kube/config<span class="w"> </span>--platform<span class="w"> </span>linux/amd64<span class="w"> </span>naison/kubevpn:latest </code></pre></div> <h3>5. Prise en Charge des Protocoles Multiples</h3> <p>KubeVPN supporte les couches 3 et supérieures du modèle OSI, comme ICMP, TCP, UDP, gRPC, WebSocket et HTTP.</p> <h3>6. Installation Facile</h3> <p>KubeVPN peut être installé de différentes manières : * Avec <code>brew</code> (macOS/Linux) : <code>brew install kubevpn</code>. * Avec <code>scoop</code> (Windows) : <code>scoop bucket add extras &amp;&amp; scoop install kubevpn</code>. * Avec <code>krew</code> (Windows/macOS/Linux) : <code>kubectl krew index add kubevpn https://github.com/kubenetworks/kubevpn.git &amp;&amp; kubectl krew install kubevpn/kubevpn &amp;&amp; kubectl kubevpn</code>. * Via une release GitHub. Vous pouvez également installer l'application de démo Bookinfo:</p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>apply<span class="w"> </span>-f<span class="w"> </span>https://raw.githubusercontent.com/kubenetworks/kubevpn/master/samples/bookinfo.yaml </code></pre></div> <p>Vous pouvez nettoyer après le test en utilisant la commande:</p> <div class="codehilite"><pre><span></span><code>kubectl<span class="w"> </span>delete<span class="w"> </span>-f<span class="w"> </span>https://raw.githubusercontent.com/kubenetworks/kubevpn/master/samples/bookinfo.yaml </code></pre></div> <h2>Exemples d'Utilisation Concrets</h2> <p>Voici quelques exemples d'utilisation qui illustrent la puissance de KubeVPN :</p> <ol> <li> <p><strong>Développement et débogage local</strong> : Vous pouvez exécuter votre application dans un conteneur Docker local, mais connecté au réseau Kubernetes grâce à KubeVPN. Cela vous permet de déboguer votre application dans un environnement identique à celui de production.</p> </li> <li> <p><strong>Test de modifications en temps réel</strong> : Vous pouvez intercepter le trafic entrant vers un service Kubernetes et le rediriger vers votre machine locale. Cela vous permet de tester rapidement les modifications de votre code sans avoir à redéployer l'application dans le cluster.</p> </li> <li> <p><strong>Accès facile aux API Kubernetes</strong> : Vous pouvez utiliser les outils en ligne de commande Kubernetes comme <code>kubectl</code> directement depuis votre machine locale, sans avoir à configurer des tunnels ou des redirections de ports complexes.</p> </li> <li> <p><strong>Collaboration simplifiée</strong> : Les membres de votre équipe peuvent utiliser KubeVPN pour accéder au même environnement de développement, réduisant ainsi les problèmes de compatibilité et de configuration.</p> </li> </ol> <h2>FAQ</h2> <p>Vos sources répondent également à certaines questions fréquentes : * Si l'image Docker ne peut pas être téléchargée ou si l'environnement interne ne peut pas accéder à <code>docker.io</code> :<br /> * Transférer l'image dans votre propre registre privé et utiliser l'option <code>--image</code>. * Utiliser l'option <code>--transfer-image</code> pour transférer automatiquement l'image vers l'adresse spécifiée par l'option <code>--image</code>. * Si vous obtenez l'erreur 137 lors de l'utilisation de <code>kubevpn dev</code>, il peut s'agir d'une insuffisance de ressources allouées par Docker Desktop. Augmentez la mémoire dans les paramètres de Docker Desktop. * Si vous utilisez Docker dans WSL (Windows Subsystem for Linux) et que la connexion au cluster ne fonctionne pas, vous pouvez installer Docker dans WSL, utiliser <code>kubevpn connect</code> sur Windows, ou utiliser l'option <code>--network container:$CONTAINER_ID</code> lors de l'utilisation de <code>kubevpn dev</code>. * Si vous obtenez l'erreur <code>172.17.0.1:443 connect refusued</code> lors de l'accès à l'api Kubernetes, cela peut être dû à un conflit entre le sous-réseau de Kubernetes et celui de Docker. Utilisez l'option <code>--connect-mode container</code> avec <code>kubevpn dev</code> ou modifiez le fichier <code>~/.docker/daemon.json</code> en ajoutant un sous-réseau qui ne sera pas en conflit, par exemple: <code>"bip": "172.15.0.1/24"</code>.</p> <h2>Conclusion</h2> <p>KubeVPN est un outil indispensable pour tout développeur travaillant avec Kubernetes. Il simplifie l'accès aux ressources du cluster, permet de tester facilement les modifications locales et offre un environnement de développement cohérent. Si vous développez des applications cloud natives, vous devriez absolument essayer KubeVPN !</p> <p>Ce billet de blog a exploré les principales fonctionnalités de KubeVPN, en s'appuyant sur les informations fournies dans vos sources. J'espère qu'il vous sera utile et vous encouragera à adopter cet outil pour améliorer votre productivité.</p>2024-12-13T10:00:00+01:002024-12-13T10:00:00+01:00Hervé Leclerctag:blogppr.alterway.fr,2024-12-13:/kubernetes-132.html

<p>Kubernetes 1.32 : Stabilité et la performance !</p>

<h1>Kubernetes 1.32 : Stabilité et la performance !</h1> <p>Salut les mordus de Kubernetes ! La version 1.32 est arrivée, et elle est pleine de nouveautés intéressantes qui vont améliorer votre expérience Kubernetes. </p> <p>Accrochez-vous, on vous embarque pour un tour d'horizon des nouvelles fonctionnalités les plus cool !</p> <h2>Performance et Stabilité : Kubelet s'améliore</h2> <p><strong>Le gestionnaire de mémoire de Kubelet est enfin en version stable !</strong> C'est une grande nouvelle car cela signifie que vous pouvez l'utiliser en toute confiance en production. </p> <p>Ce gestionnaire améliore la façon dont Kubelet gère la mémoire des pods, <strong>prévenant les interruptions de service</strong> dues à une saturation. </p> <p>En plus de cela, on a droit à une <strong>meilleure gestion des connexions UDP</strong> grâce à un correctif dans kube-proxy. </p> <p>Fini les problèmes DNS après un redémarrage des pods DNS ! De même, le <strong>contrôleur de point de terminaison a été corrigé</strong> pour gérer plus efficacement les objets Endpoint.</p> <p>Et devinez quoi ? <strong>Le gestionnaire d'expulsion (Eviction) a été corrigé pour supprimer les images et les conteneurs inutilisés</strong>. </p> <p>Cela vous permet de <strong>libérer de l'espace précieux</strong> sur vos nœuds !</p> <h2>Fonctionnalités en version stable : La cerise sur le gâteau</h2> <p>En plus des améliorations de performance et de stabilité, <strong>plusieurs fonctionnalités ont été promues en version stable</strong> dans Kubernetes 1.32. Parmi elles :</p> <ul> <li> <p><strong>StatefulSetAutoDeletePVC</strong> : Plus besoin de supprimer manuellement les PVC associés à un StatefulSet lorsqu'il est supprimé.</p> </li> <li> <p><strong>CustomResourceFieldSelectors</strong> : Cette fonctionnalité offre plus de flexibilité dans la gestion des CustomResourceDefinitions.</p> </li> <li> <p><strong>RetryGenerateName</strong> : La génération de noms pour les objets Kubernetes est désormais plus robuste et fiable.</p> </li> <li> <p><strong>SizeMemoryBackedVolumes</strong> : La gestion des volumes en mémoire est maintenant plus stable et performante.</p> </li> <li> <p><strong>PodLifecycleSleepAction</strong>: Cette fonctionnalité simplifie la gestion des actions de cycle de vie des pods. </p> </li> </ul> <h2>Encore plus de nouveautés</h2> <p>Kubernetes 1.32 ne s'arrête pas là ! Voici d'autres nouveautés à découvrir :</p> <ul> <li> <p>La fonctionnalité « Scheduler Queueing Hints » est passée en version bêta. Elle promet d'<strong>optimiser la planification des pods</strong>.</p> </li> <li> <p><strong>La prise en charge de Windows pour le gestionnaire de mémoire des nœuds</strong> a été ajoutée, améliorant ainsi les performances et la stabilité des nœuds Windows.</p> </li> <li> <p>Vous pouvez maintenant <strong>configurer des domaines de recherche de pod</strong> avec plus de liberté.</p> </li> <li> <p>L'intégration du chien de garde (watchdog) <strong>systemd</strong> au kubelet permet de <strong>redémarrer automatiquement les kubelets bloqués</strong>. </p> </li> </ul> <h2>Autres Changements importants</h2> <ul> <li> <p>Des modifications ont été apportées à l'API pour la gestion du redimensionnement des pods. Un nouveau sous-ressource <strong>/resize</strong> a été ajouté pour les opérations de redimensionnement.</p> </li> <li> <p>Une nouvelle fonctionnalité permet la suppression non sécurisée des ressources corrompues. Cette fonctionnalité est désactivée par défaut et peut être activée en définissant l'option <strong>--feature-gates=AllowUnsafeMalformedObjectDeletion=true</strong>. </p> </li> <li> <p>La structure <strong>NodeToStatusMap</strong> a été modifiée, passant d'une map à une structure. Des méthodes ont été ajoutées pour accéder aux entrées et absentNodesStatus informe de l'état des nœuds absents dans la map. </p> </li> <li> <p>Le support pour la suppression des requêtes et des limites lors du redimensionnement d'un pod a été supprimé.</p> </li> <li> <p>"<strong>ComponentSLIs</strong>" est maintenant en GA et verrouillée.</p> </li> </ul> <h2>En résumé</h2> <p>Kubernetes 1.32 apporte <strong>une multitude d'améliorations qui raviront les utilisateurs</strong> de la plateforme. </p> <p>N'hésitez pas à explorer toutes les nouveautés et à les mettre en pratique pour tirer le meilleur parti de votre environnement Kubernetes !</p> <p><strong>N'oubliez pas de consulter les notes de version officielles pour une liste complète des changements.</strong> </p> <p><a href="https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md">Change Log</a></p> <p><strong>Upgradez vous cluster fréquemment !!!</strong></p>