Kubernetes vs OpenShift : quelle différence choisir en 2026 ?

Vous hésitez entre Kubernetes et OpenShift pour orchestrer vos conteneurs en 2026 ? La question revient sur la table dans presque chaque projet d’industrialisation que j’accompagne. La réponse courte : les deux reposent sur le même moteur, mais répondent à des contextes très différents. Ce guide compare en détail Kubernetes et OpenShift — architecture, sécurité, expérience développeur, coûts, cas d’usage — pour vous aider à choisir la plateforme adaptée à votre organisation.

Temps de lecture estimé : 12 minutes.

Sommaire

• Kubernetes, c’est quoi ?
• OpenShift, c’est quoi ?
• Tableau comparatif Kubernetes vs OpenShift
• Différences techniques détaillées
• Quel produit pour quel cas d’usage ?
• CLI : kubectl vs oc
• Coûts réels en 2026
• Et les alternatives (OKD, Rancher, EKS) ?
• FAQ

Kubernetes, c’est quoi ?

Kubernetes (souvent abrégé K8s) est le standard de facto de l’orchestration de conteneurs. Il s’agit d’un projet open source initié par Google en 2014, donné à la CNCF et maintenu aujourd’hui par une vaste communauté. Kubernetes fournit les briques fondamentales pour :

• déployer et orchestrer des conteneurs sur un cluster de machines ;
• gérer le cycle de vie des applications (rolling updates, rollback, scaling) ;
• exposer ces applications via des services et des ingress ;
• fournir un modèle déclaratif (manifests YAML) pour décrire l’état désiré.

Kubernetes est un moteur. Il ne fournit pas de console graphique aboutie, pas de gestion des utilisateurs intégrée, pas de pipeline CI/CD, pas de registre d’images, pas d’observabilité prête à l’emploi. Vous devez assembler ces briques vous-même via des projets tiers (Prometheus, Grafana, Argo CD, Harbor, Keycloak…).

OpenShift, c’est quoi ?

Red Hat OpenShift Container Platform (OCP) est une distribution Kubernetes opinionated commercialisée par Red Hat. OpenShift n’est pas un fork de Kubernetes : c’est Kubernetes upstream + un ensemble cohérent de composants intégrés, certifiés et supportés.

OpenShift apporte par défaut :

• une console web complète (Developer + Administrator) ;
• un système d’authentification intégré (LDAP, OIDC, htpasswd…) ;
• un registre d’images interne ;
• des pipelines CI/CD natifs (Tekton via OpenShift Pipelines) ;
• du GitOps natif (Argo CD via OpenShift GitOps) ;
• une stack monitoring complète (Prometheus, Alertmanager, Grafana) ;
• des opérateurs certifiés via OperatorHub ;
• des politiques de sécurité strictes par défaut (SCC, RBAC, NetworkPolicy) ;
• un OS dédié pour les nœuds : Red Hat CoreOS (RHCOS).

Concrètement, là où Kubernetes vous donne un moteur de voiture, OpenShift vous livre la voiture entière, avec sa carrosserie, son tableau de bord et le service après-vente.

Tableau comparatif Kubernetes vs OpenShift

Critère	Kubernetes (vanilla)	OpenShift Container Platform
Éditeur	CNCF (open source)	Red Hat (commercial, basé sur K8s)
Licence	Apache 2.0	Souscription Red Hat
Version équivalente	Kubernetes 1.30 / 1.31	OCP 4.16 / 4.17
OS des nœuds	Au choix (Ubuntu, Debian, RHEL, Flatcar…)	Red Hat CoreOS (immuable, imposé)
Console web	Dashboard minimaliste à installer	Console complète (Dev + Admin)
Authentification	À assembler (Keycloak, Dex…)	OAuth intégré (LDAP, OIDC, htpasswd)
CI/CD	Composants tiers (Argo CD, Tekton…)	OpenShift Pipelines + GitOps inclus
Registre d’images	Externe (Harbor, Quay, ECR…)	Internal Image Registry inclus
Sécurité par défaut	Permissive — SecurityContext optionnel	Stricte — SCC restricted-v2 par défaut
Mise à jour	Manuelle ou via opérateur	Update orchestré, OTA, rollback
Support	Communauté (ou éditeur cloud)	Red Hat 24/7 inclus dans la souscription
Coût (50 cores)	Gratuit (sauf cloud managé)	~30 000 €/an environ
Public visé	Équipes maîtrisant l’écosystème	Entreprises voulant une plateforme intégrée

Différences techniques détaillées

1. Sécurité par défaut

C’est la différence la plus structurante. OpenShift applique par défaut la SCC restricted-v2 : aucun pod ne peut tourner en root, l’UID est imposé aléatoirement par namespace, les capabilities Linux sont retirées. Conséquence : beaucoup d’images Docker publiques (NGINX, MySQL, Redis officielles) refusent de démarrer telles quelles.

Sur Kubernetes vanilla, ces images démarrent — souvent en root — sans rien dire. C’est plus pratique en POC, c’est aussi une dette de sécurité massive en production. Sur Kubernetes, vous pouvez (et devez) appliquer les Pod Security Standards, mais c’est à vous d’en assumer la configuration.

# Rejet typique côté OpenShift quand une image tourne en root :
$ oc apply -f deploy.yaml
Error from server (Forbidden): error when creating "deploy.yaml": pods is forbidden:
unable to validate against any security context constraint:
[provider "restricted-v2": Forbidden: not usable by user or serviceaccount,
spec.containers[0].securityContext.runAsUser: Invalid value: 0: must be in the ranges: [1000700000, 1000709999]]

2. Routes vs Ingress

Kubernetes utilise les ressources Ingress (puis Gateway API). OpenShift propose en plus la ressource Route, antérieure à Ingress et toujours active. Une Route OpenShift s’écrit ainsi :

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: app-front
  namespace: prod
spec:
  host: app.example.com
  to:
    kind: Service
    name: app-front
  port:
    targetPort: 8080
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

OpenShift sait évidemment lire des Ingress standards (ils sont convertis en Routes en arrière-plan). Vos manifests Kubernetes restent donc portables.

3. Image Stream et Source-to-Image (S2I)

OpenShift introduit le concept d’ImageStream, une abstraction au-dessus du registre d’images permettant de découpler la référence de l’image de son tag. Couplé à Source-to-Image (S2I), OpenShift peut construire une image directement depuis le code source d’un dépôt Git, sans Dockerfile.

C’est un confort indéniable pour les développeurs Java, Python ou Node, qui n’existe pas nativement sur Kubernetes (où il faut passer par Buildah, Kaniko ou Tekton).

4. Opérateurs et OperatorHub

Le Operator Lifecycle Manager (OLM) et l’OperatorHub sont natifs dans OpenShift. En quelques clics dans la console, vous installez une stack monitoring, un certificat manager, un opérateur Vault, un opérateur Postgres : ils sont installés, surveillés et mis à jour automatiquement.

Sur Kubernetes vanilla, OLM existe mais doit être installé manuellement. La plupart des équipes n’utilisent pas OLM : elles installent les opérateurs via Helm chart ou kustomize, en prenant en charge elles-mêmes le suivi des versions.

5. Mises à jour orchestrées

OpenShift applique les mises à jour over-the-air via le Cluster Version Operator : vous choisissez une version cible dans la console, le cluster met à jour les nœuds RHCOS, l’API server et tous les opérateurs en suivant un graphe de versions validé. C’est l’une des grandes forces d’OCP en production.

Sur Kubernetes vanilla, la mise à jour dépend de votre installation : kubeadm upgrade, opérateur de cluster (Cluster API, kOps, kubespray), ou tâche cloud-managed (EKS, GKE, AKS). Il faut maîtriser l’ensemble de la chaîne.

Quel produit pour quel cas d’usage ?

Choisissez Kubernetes (managé ou vanilla) si :

• Vous avez une équipe DevOps senior à l’aise avec l’écosystème CNCF.
• Votre infra tourne déjà sur AWS, GCP ou Azure et vous voulez utiliser EKS / GKE / AKS.
• Vous voulez maîtriser intégralement vos coûts (pas de souscription).
• Votre architecture est très standardisée et bien outillée (GitOps, Terraform, Crossplane).
• Vous tolérez de construire vous-même la plateforme développeur.

Choisissez OpenShift si :

• Vous travaillez dans un secteur régulé (banque, santé, énergie, gouvernement).
• Vous avez besoin d’un support 24/7 contractuel.
• Votre cible est on-premise (bare metal, VMware vSphere) ou hybride.
• Vos équipes développeurs ne sont pas (encore) des experts Kubernetes.
• Vous voulez une plateforme intégrée prête à l’emploi : console, CI/CD, monitoring, sécurité.
• Vous capitalisez déjà sur l’écosystème Red Hat (RHEL, Ansible, RHACM, RHACS).

D’expérience, sur les missions que j’ai conduites — notamment la migration de plus de 50 applications de la Banque Nationale du Canada d’OpenShift 3.11 vers OCP 4.x — OpenShift apporte un retour sur investissement très net dans les grandes organisations on-premise. Dans une petite équipe agile sur AWS, EKS sera plus pertinent.

CLI : kubectl vs oc

Le client OpenShift oc est un superset de kubectl : toutes les commandes kubectl existent dans oc, plus quelques ajouts spécifiques OCP.

# Kubernetes
kubectl get nodes
kubectl get pods -n monitoring
kubectl apply -f deploy.yaml
kubectl logs -f pod/app-xyz
kubectl exec -it pod/app-xyz -- /bin/sh

# OpenShift — équivalent + spécificités
oc get nodes
oc get pods -n monitoring
oc apply -f deploy.yaml
oc logs -f pod/app-xyz
oc rsh pod/app-xyz                  # alias pratique pour exec -it
oc new-project demo                 # crée projet (= namespace + métadonnées)
oc new-app python:3.12~https://github.com/me/app   # build S2I depuis Git
oc adm top nodes
oc whoami --show-server
oc adm policy add-scc-to-user anyuid -z default    # ajuster une SCC

Bonne nouvelle : vos manifests Kubernetes (Deployment, Service, ConfigMap…) sont 100% compatibles OpenShift, à condition de respecter les SCC. Vos compétences kubectl sont donc immédiatement réutilisables.

Coûts réels en 2026

Le coût brut de la souscription OpenShift est souvent cité comme un repoussoir. Il faut pourtant comparer ce qui est comparable.

• OpenShift Container Platform on-premise : souscription Red Hat à la core. À titre indicatif, comptez environ 600 € par cœur et par an pour la Premium subscription (à négocier).
• EKS / GKE / AKS : ~70 USD/mois pour le control plane par cluster, plus le coût des nœuds.
• Kubernetes vanilla on-premise : 0 € de licence, mais comptez le temps homme pour assembler et maintenir la plateforme.

En pratique, j’ai mesuré chez plusieurs clients que le coût total OpenShift est compétitif dès lors que l’on intègre : les ETP nécessaires pour bâtir et maintenir la plateforme sur Kubernetes vanilla, le coût d’incidents évités grâce au support, et la productivité accrue des équipes développement grâce à la console et aux pipelines intégrés.

Et les alternatives ?

• OKD : la version 100% open source d’OpenShift, sans souscription Red Hat. Très bon choix pour valider OCP en POC, mais sans support officiel.
• Rancher (SUSE) : une plateforme de gestion multi-clusters Kubernetes. Excellent pour gérer beaucoup de petits clusters, plus léger qu’OpenShift.
• Tanzu (VMware) : l’offre Kubernetes intégrée à vSphere, intéressante pour les organisations VMware historiques.
• EKS / GKE / AKS : les Kubernetes managés des grands clouds. Légers, opérationnels rapidement, mais ne fournissent pas la même intégration verticale qu’OpenShift.

FAQ

OpenShift est-il un fork de Kubernetes ?

Non. OpenShift utilise Kubernetes upstream (sans patch propriétaire) et ajoute autour des composants intégrés. Quand Kubernetes 1.31 sort, il finit dans une version d’OpenShift quelques mois plus tard.

Mon code Helm fonctionne-t-il sur OpenShift ?

Oui, Helm 3 fonctionne nativement. Les seuls écueils sont les Security Context Constraints : certaines charts publiques ne respectent pas la SCC restricted-v2. Soit vous adaptez les valeurs, soit vous utilisez une SCC moins stricte sur le ServiceAccount du chart.

Peut-on installer OpenShift en local pour apprendre ?

Oui : OpenShift Local (anciennement CRC) tourne sur un poste de développeur (16 Go de RAM minimum). Pour une cible plus production-like, OKD ou un cluster SNO (Single Node OpenShift) font très bien l’affaire.

Faut-il être certifié Red Hat pour exploiter OpenShift ?

Non, mais c’est fortement conseillé. Les certifications Red Hat Certified Specialist in OpenShift Administration (EX280) et Containers and Kubernetes (EX180) sont d’excellents repères pour valider les compétences d’une équipe.

Quelle plateforme choisir pour une migration depuis Kubernetes vanilla ?

Tout dépend de votre cible. Si vos équipes maîtrisent déjà Kubernetes et que votre cible est cloud public, restez sur Kubernetes managé. Si vous êtes en multi-cloud ou on-premise et que vous voulez homogénéiser la plateforme avec un support contractuel, OpenShift est un excellent candidat — c’est typiquement la situation qui m’a été confiée à la Banque Nationale du Canada (50+ applications migrées avec 80% d’erreurs manuelles en moins).

---

Articles liés à découvrir prochainement : « HashiCorp Vault sur Kubernetes », « OpenBao, l’alternative open source à Vault », « Terraform best practices pour structurer ses modules ».