OpenShift : ce que la plateforme change réellement par rapport à Kubernetes

Quand on découvre OpenShift après Kubernetes, la première erreur est de chercher une liste de commandes différentes. La différence la plus importante est ailleurs : OpenShift transforme un ensemble de briques Kubernetes en une plateforme davantage intégrée et gouvernée.

Les objets fondamentaux restent familiers : pods, services, deployments, namespaces, RBAC, manifests YAML et API Kubernetes. Les compétences Kubernetes restent donc directement utiles. Ce qui change surtout, c’est le contrat d’exploitation autour de ces objets.

Kubernetes reste le socle

OpenShift Container Platform est une plateforme Kubernetes. Il ne faut donc pas opposer les deux comme s’il s’agissait de technologies indépendantes. Une application correctement conçue pour Kubernetes conserve une grande partie de ses concepts, de ses manifests et de ses pratiques.

En revanche, OpenShift ajoute des composants et des conventions destinés à réduire la quantité d’assemblage manuel nécessaire pour exploiter une plateforme d’entreprise.

Le cycle de vie devient une responsabilité de plateforme

Dans un cluster Kubernetes construit à partir de composants choisis séparément, l’équipe plateforme doit décider comment installer, mettre à jour et maintenir une partie importante de ces composants. OpenShift structure davantage ce cycle de vie.

Les Cluster Operators gèrent des fonctions de plateforme et cherchent à maintenir leurs composants dans l’état attendu. Pour les composants additionnels, l’Operator Lifecycle Manager fournit un mécanisme d’installation et de gestion du cycle de vie des Operators.

Routes, Ingress et exposition des applications

Kubernetes fournit l’objet Ingress. OpenShift conserve cette possibilité mais ajoute aussi l’objet Route. L’Ingress Operator gère les contrôleurs responsables de l’accès externe et peut traiter aussi bien les ressources Route que les ressources Ingress.

Pour une équipe applicative, cela signifie que l’exposition HTTP d’un service s’inscrit dans un mécanisme déjà intégré à la plateforme, plutôt que d’exiger systématiquement l’assemblage d’un contrôleur externe et de sa gouvernance.

La sécurité modifie parfois les hypothèses d’une application

OpenShift utilise notamment les Security Context Constraints (SCC) pour encadrer les permissions accordées aux pods : exécution privilégiée, capacités Linux, UID, accès à certains volumes ou namespaces hôte, contexte SELinux, entre autres.

C’est un point important lors d’une migration. Un conteneur qui suppose inutilement qu’il peut s’exécuter en root ou demander des privilèges élevés peut nécessiter une adaptation. Le bon réflexe n’est pas de désactiver les garde-fous, mais de comprendre exactement le privilège réellement nécessaire.

Identité, RBAC et exploitation restent liés

OpenShift ajoute une couche intégrée d’authentification autour de l’API et s’appuie ensuite sur les mécanismes d’autorisation pour déterminer les actions permises. Les utilisateurs, groupes, rôles, service accounts et politiques deviennent ainsi une partie visible du design de la plateforme.

L’outil oc complète cet environnement tout en restant compatible avec une grande partie des usages Kubernetes. L’objectif n’est pas d’oublier kubectl, mais de disposer d’une CLI qui expose aussi les ressources propres à OpenShift.

Quand OpenShift apporte le plus de valeur

Le gain devient particulièrement visible lorsque l’organisation cherche à standardiser plusieurs dimensions en même temps : cycle de vie du cluster, sécurité, installation d’Operators, exposition des applications, authentification, observabilité et expérience développeur.

À l’inverse, la plateforme ne dispense pas de comprendre Kubernetes. Plus l’environnement est automatisé, plus il devient important de savoir distinguer ce qui appartient à Kubernetes, ce qui appartient à OpenShift et ce qui appartient à l’application.

Le modèle mental à retenir

1. Kubernetes fournit les primitives d’orchestration ;
2. OpenShift conserve ces primitives ;
3. la plateforme ajoute des conventions et des composants intégrés ;
4. les Operators gèrent une partie du cycle de vie ;
5. les politiques de sécurité réduisent certaines hypothèses permissives ;
6. l’exploitation devient un problème de plateforme autant qu’un problème de cluster.