Kubernetes (K8s) s’est imposé comme le standard mondial pour automatiser le déploiement, la mise à l’échelle et la gestion des applications conteneurisées. Il excelle dans la planification de l’exécution des pods, la répartition de la charge réseau et le maintien de l’état déclaratif de votre infrastructure.
Cependant, Kubernetes natif s’arrête strictement aux frontières du cœur de l’orchestration. Il ne fournit par défaut ni registre d’images sécurisé, ni chaîne de livraison continue, ni supervision avancée.
Bâtir une plateforme de production avec Kubernetes Vanilla (Kubernetes Vanilla désigne la version la plus standard et basique) implique donc de concevoir une architecture sur mesure.
Vos équipes doivent évaluer, intégrer et maintenir une multitude de briques issues de la Cloud Native Computing Foundation (CNCF) pour le réseau, le stockage et la sécurité.
Cette approche offre une flexibilité totale : vous assemblez la plateforme qui répond précisément à vos exigences techniques, sans subir la moindre contrainte commerciale ou technologique liée à un éditeur tiers.
A lire dans la même thématique : Kubernetes DevOps : structurez vos conteneurs et processus
Éditée par Red Hat, OpenShift Container Platform (OCP) repose directement sur le code source de Kubernetes upstream. La valeur ajoutée d’OpenShift réside dans l’intégration native d’une couche logicielle complète et validée pour l’entreprise.
Dès l’installation, la plateforme embarque l’ensemble des composants indispensables à une équipe de production :
Cette standardisation logicielle s’accompagne d’un modèle de support commercial et de correctifs de sécurité.
OpenShift simplifie drastiquement la gestion du cycle de vie de la plateforme grâce à des opérateurs dédiés qui automatisent les montées de version de toute la stack.
En contrepartie, l’organisation s’acquitte de licences commerciales et adopte des abstractions techniques propres à l’écosystème Red Hat.
La comparaison entre les deux plateformes s’articule autour de plusieurs axes fondamentaux. Ce sont ces dimensions, et non les listes de fonctionnalités, qui doivent guider votre décision.
La première différence structurelle tient à ce que chaque plateforme fournit, ou ne fournit pas, dès l’installation.
OpenShift livre un environnement complet et cohérent : système d’exploitation durci (RHCOS), pipeline CI/CD (Tekton), registre d’images intégré et routage applicatif. L’équipe dispose d’un socle opérationnel immédiatement exploitable, sans phase d’assemblage.
Kubernetes, à l’inverse, se limite volontairement au moteur d’orchestration. Tout le reste (CI/CD, ingress, observabilité, gestion des secrets) est à choisir, intégrer et maintenir par l’équipe. C’est une liberté totale qui exige une expertise solide dès le départ.
Le rapport à la sécurité reflète deux philosophies opposées la sécurité par défaut d’OpenShift contre la sécurité à construire de Kubernetes.
OpenShift impose dès l’installation des politiques strictes (Security Context Constraints – SCC) qui interdisent par défaut l’exécution des pods en mode root. Cette posture durcit immédiatement la sécurité et accélère la conformité face aux référentiels exigeants (ISO 27001, HDS, PCI-DSS, DORA), bien qu’elle puisse nécessiter l’adaptation de certaines images Docker publiques.
Kubernetes se veut permissif par défaut pour offrir une liberté totale de configuration. La sécurisation repose alors sur la responsabilité de l’équipe, qui peut choisir et intégrer les outils CNCF les plus adaptés du marché (Kyverno, Cilium, Falco, OPA/Gatekeeper) pour un contrôle granulaire sur mesure.
Maintenir une plateforme conteneurs dans le temps représente un effort d’ingénierie souvent sous-estimé. OpenShift réduit cette charge en fournissant l’ensemble des composants sous forme de bundle validé et supporté directement par Red Hat, ce qui simplifie les montées de version globales via un opérateur dédié.
Kubernetes offre quant à lui un contrôle absolu sur chaque brique (CNI, Ingress Controller, observabilité, gestion des secrets), mais l’effort réside dans la maintenance continue de la matrice de compatibilité à chaque cycle de mise à jour des composants indépendants.
La question du lock-in est souvent décisive dans les choix d’infrastructure à long terme.
OpenShift introduit des abstractions propriétaires (Routes, DeploymentConfig, SCC) : bien que la compatibilité avec les objets Kubernetes standard reste entière, une migration vers un Kubernetes pur nécessite une phase d’adaptation et de conversion de ces primitives.
Kubernetes offre à l’inverse une portabilité maximale et une absence totale de verrouillage. Un workload s’exécute de façon quasi identique sur n’importe quel cloud (EKS, AKS, GKE) ou infrastructure sur site.
OpenShift repose sur un modèle commercial (généralement au cœur CPU ou au nœud) intégrant un support éditeur 24/7 et des correctifs de sécurité réactifs, ce qui permet de transférer une partie de ce risque vers Red Hat.
Kubernetes est gratuit et open source : l’investissement est principalement humain, concentré sur l’expertise d’une équipe technique interne capable de faire vivre la stack dans la durée.
OpenShift convient particulièrement aux DSI opérant dans des secteurs régulés (santé, finance, secteur public) avec des obligations de conformité fortes, ainsi qu’aux équipes DevOps de niveau intermédiaire qui ont besoin d’un socle fiable sans devoir maîtriser chaque couche de la stack et souhaitent s’appuyer sur un support contractuel en cas d’incident.
Kubernetes s’adresse aux équipes SRE seniors, composées d’au moins cinq ingénieurs avec une culture open source affirmée et la volonté de maîtriser intégralement leur infrastructure, des équipes qui tirent parti de la flexibilité totale de la plateforme pour construire un environnement optimisé pour leurs contraintes spécifiques.
Au-delà du duo OpenShift / Kubernetes, le marché des distributions conteneurs s’est considérablement diversifié. Voici un panorama des cinq axes à analyser pour choisir votre plateforme conteneurs entreprise : niveau de maturité DevOps requis, posture sécurité par défaut, modèle économique, portabilité et profil d’organisation cible.
C’est probablement la première question à poser, avant même d’ouvrir un comparatif technique.
Si votre organisation ne dispose pas d’une équipe dédiée aux opérations 24/7, ou si cette couverture repose sur une ou deux personnes clés difficiles à remplacer, l’adoption d’un Kubernetes managé ou d’une distribution avec support éditeur comme OpenShift sécurise l’exploitation de façon contractuelle.
À l’inverse, une équipe interne solide, habituée à opérer des systèmes distribués et à gérer des incidents de nuit, trouvera dans Kubernetes vanilla l’opportunité de maîtriser de bout en bout sa plateforme, sans dépendance tierce sur le chemin critique.
La nuance est importante : il y a une différence significative entre avoir déployé Kubernetes sur un environnement de test et avoir géré un cluster en production sous contrainte réelle.
La courbe d’apprentissage en conditions réelles (upgrades de version sans interruption de service, debugging de problèmes réseau au niveau CNI, tuning fin des ressources pour éviter les OOMKill en charge) est substantielle et ne se raccourcit pas à coups de formations.
Une équipe qui découvre ces problématiques simultanément à un projet critique prend un risque mesuré, mais réel, qu’il vaut mieux anticiper par un accompagnement externe ou un choix de plateforme plus encadrant.
C’est un paramètre que les équipes sous-estiment systématiquement au moment du choix initial.
Les migrations de plateforme conteneurs coûtent cher, en temps ingénieur, en re-test des workloads, en adaptation des pipelines CI/CD et parfois en refonte des architectures réseau.
Une organisation qui anticipe un horizon d’exploitation de 5 à 7 ans a tout intérêt à choisir dès le départ une distribution stable, supportée et dont le cycle de vie est garanti par un éditeur.
Changer de plateforme en cours de route n’est pas impossible, mais c’est rarement gratuit.
L’erreur classique est de construire une comparaison en opposant le coût de licence OpenShift à la gratuité théorique de Kubernetes open source.
C’est une comparaison tronquée. L’analyse budgétaire rigoureuse doit mesurer l’effort global sur la durée : d’un côté, les coûts de souscription Red Hat (prévisibles, contractuels, avec SLA) ; de l’autre, le coût réel des 3 à 5 ingénieurs qui conçoivent, maintiennent, documentent et font évoluer une stack maison, sans oublier le coût des incidents non couverts par un support éditeur, et celui des mises à jour majeures qui mobilisent l’équipe pendant plusieurs jours.
Sur trois ans, l’écart entre les deux modèles est souvent bien moins large qu’il n’y paraît au premier regard.
Plutôt qu’une liste de critères abstraits, voici une méthode opérationnelle pour arriver à une décision ancrée dans la réalité de votre organisation. Ces cinq étapes s’appliquent quel que soit votre secteur d’activité ou la taille de votre DSI.
A lire : Migration vers Kubernetes : les signaux qui indiquent qu’il est temps de migrer
Voici les erreurs les plus fréquentes dans les projets OpenShift vs Kubernetes, observées sur le terrain. Chacune a en commun de sous-estimer soit la complexité opérationnelle, soit le coût humain réel d’une plateforme conteneurs.
C’est l’erreur de raisonnement la plus répandue, et la plus coûteuse à corriger. Le logiciel est effectivement gratuit. Le coût réel, lui, est celui de l’équipe qui l’opère.
Opérer un cluster Kubernetes en production de manière sérieuse mobilise au minimum deux profils dédiés de niveau ingénieur SRE senior, capables de couvrir :
Inverser cet ordre est une erreur structurelle qui génère des projets de re-platforming longs et coûteux. Les choix de plateforme conditionnent directement :
Décider d’OpenShift après avoir conteneurisé pour Kubernetes vanilla, ou l’inverse, oblige à revoir des dizaines de manifestes, d’abstractions réseau et de configurations de sécurité. La règle est simple : la décision de plateforme précède la conteneurisation, pas l’inverse.
Docker Compose et Kubernetes partagent le concept de conteneur. Ils ne partagent pas l’opérationnel. La transition entre les deux n’est pas une montée en version : c’est un changement de paradigme complet.
Les compétences à acquérir sont distinctes et s’apprennent sur le terrain sur plusieurs mois :
Une équipe qui maîtrise Docker Compose n’est pas opérationnellement prête pour un cluster de production Kubernetes. L’écart est systématiquement sous-estimé lors des phases de cadrage projet.
La décision est techniquement valide, si et seulement si l’équipe dispose des compétences et des effectifs pour l’assumer.
Prise pour des raisons budgétaires seules, sans audit préalable de maturité DevOps, elle conduit dans la majorité des cas à des projets qui s’enlisent durablement lors de la phase d’opérationnalisation.
Le schéma est récurrent : le cluster est livré dans les délais en environnement de développement et de staging, puis se révèle instable dès le passage en production. Les incidents s’accumulent, les équipes peinent à diagnostiquer des problèmes qui mêlent réseau, stockage et scheduling, et la dette technique grossit silencieusement sur les sujets de sécurité et de mise à jour, précisément parce que personne n’a eu le temps de les traiter correctement.
EKS, AKS et GKE apportent une valeur réelle et documentée sur un périmètre précis : ils gèrent le control plane, assurent sa disponibilité, et absorbent la complexité des mises à jour de l’API server et des composants système sous-jacents.
C’est un allègement significatif, mais il est souvent mal interprété. La confusion vient du mot « managé », qui laisse entendre une délégation plus large qu’elle ne l’est en réalité.
Ce que ces services ne font pas, c’est gérer ce qui s’exécute au-dessus du control plane, c’est-à-dire l’essentiel de ce qui détermine la fiabilité et la sécurité d’une plateforme en production.
La configuration et le patching des nodes workers restent à la charge du client, tout comme la définition des politiques réseau, la gestion du stockage persistant et des stratégies de backup, la sécurisation des pods et la conformité des workloads aux référentiels internes ou réglementaires.
La gestion fine des accès, RBAC, IRSA sur AWS, Workload Identity sur GCP, exige une expertise qui ne s’improvise pas et qui mobilise du temps d’ingénierie de manière continue.
Oui, OpenShift intègre Kubernetes en son cœur. Tous les objets Kubernetes standard (Deployments, Services, ConfigMaps) y fonctionnent nativement. Les extensions propres à OpenShift (comme les Routes) viennent enrichir l’expérience mais nécessitent une attention particulière si vous visez une réversibilité immédiate.
Techniquement oui, avec des adaptations. Les Routes OpenShift doivent être converties en Ingress standard, les SCC en PodSecurityAdmission ou OPA/Gatekeeper, les DeploymentConfig en Deployments standard. La migration est possible, mais reste complexe sur un parc applicatif important.
Cela dépend du niveau de séniorité. Cinq ingénieurs juniors à intermédiaires sur Kubernetes vanilla en production représentent un risque élevé. Cinq ingénieurs seniors avec expérience Kubernetes en production peuvent le faire. En dessous de ce seuil, une distribution managée (ROSA, ARO, EKS, AKS) est une alternative sérieuse.
OKD est la version community d’OpenShift, entièrement open source et sans support Red Hat. OpenShift Container Platform (OCP) est la version commerciale supportée avec abonnement Red Hat et SLA. OKD permet de tester l’expérience OpenShift sans coût de licence, mais n’est pas prévu pour un usage en production d’entreprise.
Pour les organisations sans contrainte de résidence des données ou de souveraineté, oui. Les services managés suppriment la charge du control plane et offrent une intégration native avec les services cloud. Ils ne fournissent pas le niveau de support et de certification sécurité de Red Hat OpenShift, ce qui peut être bloquant dans les secteurs réglementés.
A lire aussi : Conteneurs AWS : arbitrez entre ECS, EKS et Lambda
OpenShift propose un Cluster Version Operator qui orchestre l’upgrade de façon déclarative et rollback-friendly. Kubernetes vanilla requiert de gérer les upgrades composant par composant (control plane, nodes, addons), ce qui nécessite une procédure documentée et testée.