Formation Plateforme Kubernetes avec OpenShift
Exploiter et gérer une plateforme Red Hat OpenShift pour industrialiser les déploiements Kubernetes : architecture, projets, builds, pipelines, sécurité et scalabilité
- Durée
- 3 jours
- Niveau
- Intermédiaire
- Modalités
- Distanciel
Description de la formation OpenShift
Qu'est-ce qu'OpenShift ?
Red Hat OpenShift est une plateforme d'applications conteneurisées construite sur Kubernetes. Elle y ajoute ce qu'une entreprise attend pour la production : une console web et une ligne de commande unifiées, un registre d'images intégré, des mécanismes de build depuis le code source, des pipelines CI/CD natifs, une sécurité renforcée par défaut et une gestion du cycle de vie du cluster par des opérateurs. Elle est disponible en version commerciale, OpenShift Container Platform, et en version communautaire, OKD.
Pourquoi suivre une formation Plateforme Kubernetes avec OpenShift ?
Industrialiser les déploiements Kubernetes en entreprise suppose de maîtriser à la fois l'exploitation de la plateforme et les outils mis à disposition des équipes de développement. Cette formation donne en trois jours une vision opérationnelle complète d'OpenShift : comprendre son architecture, organiser les projets, construire les images et automatiser les livraisons avec les pipelines intégrés, puis sécuriser la plateforme et en maîtriser les ressources et la scalabilité. Conçue par PLB, elle ne prépare pas à une certification. Les cours officiels Red Hat DO180, DO280 et DO288 permettent ensuite d'approfondir chaque domaine.
Objectifs pédagogiques
À l'issue de cette formation Plateforme Kubernetes avec OpenShift, vous aurez acquis les connaissances nécessaires pour :
- Découvrir l'architecture d'OpenShift et ses apports par rapport à Kubernetes.
- Gérer les projets et déployer des applications sur OpenShift.
- Gérer les images, les builds et la construction Source-to-Image.
- Mettre en œuvre des pipelines CI/CD intégrés avec OpenShift Pipelines.
- Superviser la sécurité de la plateforme et des applications.
- Maîtriser les quotas de ressources, la scalabilité et la supervision.
Objectifs opérationnels
Savoir exploiter et gérer une plateforme OpenShift pour industrialiser les déploiements Kubernetes en entreprise.
Programme
Contenu du cours, module par module
12 modules
- Les apports d'OpenShift par rapport à Kubernetes
- Les éditions : OpenShift Container Platform, OKD, OpenShift Local, offres managées dans le cloud
- Architecture : plan de contrôle, nœuds, Red Hat CoreOS, runtime CRI-O
- Les opérateurs de cluster et OperatorHub
Travaux pratiques
Objectif :Découvrir l'architecture d'un cluster OpenShift.
Description :Les participants se connectent au cluster de formation et identifient ses nœuds et leurs rôles. Ils listent les opérateurs de cluster et observent leur état. Ils parcourent ensuite le catalogue OperatorHub. Qu'apporte la gestion du cluster par des opérateurs par rapport à un Kubernetes standard ? Un QCM rapide valide les acquis.
Description :Les participants se connectent au cluster de formation et identifient ses nœuds et leurs rôles. Ils listent les opérateurs de cluster et observent leur état. Ils parcourent ensuite le catalogue OperatorHub. Qu'apporte la gestion du cluster par des opérateurs par rapport à un Kubernetes standard ? Un QCM rapide valide les acquis.
- La console web : perspectives administrateur et développeur
- Le client oc et sa correspondance avec kubectl
- Vérifier l'intégrité du cluster : nœuds, opérateurs, événements
- Processus et canaux de mise à jour du cluster
Travaux pratiques
Objectif :Vérifier l'état de santé d'un cluster OpenShift.
Description :Les participants effectuent un contrôle d'intégrité complet du cluster, d'abord avec le client oc puis avec la console web. Ils analysent les événements et identifient un composant volontairement dégradé. Ils consultent ensuite les mises à jour disponibles et le canal configuré. Quels indicateurs consulter en premier lorsqu'un cluster semble dégradé ? Le diagnostic correct du composant défaillant valide l'exercice.
Description :Les participants effectuent un contrôle d'intégrité complet du cluster, d'abord avec le client oc puis avec la console web. Ils analysent les événements et identifient un composant volontairement dégradé. Ils consultent ensuite les mises à jour disponibles et le canal configuré. Quels indicateurs consulter en premier lorsqu'un cluster semble dégradé ? Le diagnostic correct du composant défaillant valide l'exercice.
- Projets OpenShift et namespaces Kubernetes
- Déployer une application avec oc new-app et depuis la console
- Deployments, Services et Routes
- Catalogue de développement : templates et charts Helm
- Configuration avec ConfigMaps et Secrets
Travaux pratiques
Objectif :Déployer et exposer une application dans un projet OpenShift.
Description :Les participants créent un projet et y déploient une application web et sa base de données à partir d'images existantes. Ils exposent l'application par une route et externalisent sa configuration. Ils déploient ensuite une seconde application depuis le catalogue de la console. Quelle différence existe-t-il entre une route OpenShift et un Ingress Kubernetes ? L'accès à l'application par son URL valide l'exercice.
Description :Les participants créent un projet et y déploient une application web et sa base de données à partir d'images existantes. Ils exposent l'application par une route et externalisent sa configuration. Ils déploient ensuite une seconde application depuis le catalogue de la console. Quelle différence existe-t-il entre une route OpenShift et un Ingress Kubernetes ? L'accès à l'application par son URL valide l'exercice.
- Sondes de santé et fiabilité des applications
- Stratégies de déploiement : rolling, recreate
- Répartition du trafic entre versions avec les routes
- Stockage persistant : PersistentVolumeClaims et classes de stockage
Travaux pratiques
Objectif :Fiabiliser et faire évoluer une application déployée.
Description :Les participants ajoutent des sondes de santé et un volume persistant à leur application. Ils déploient une nouvelle version selon une stratégie progressive. Ils répartissent ensuite le trafic entre deux versions à l'aide d'une route. Comment basculer sans risque une partie des utilisateurs vers une nouvelle version ? La bascule maîtrisée du trafic valide l'exercice.
Description :Les participants ajoutent des sondes de santé et un volume persistant à leur application. Ils déploient une nouvelle version selon une stratégie progressive. Ils répartissent ensuite le trafic entre deux versions à l'aide d'une route. Comment basculer sans risque une partie des utilisateurs vers une nouvelle version ? La bascule maîtrisée du trafic valide l'exercice.
- Le registre d'images interne d'OpenShift
- ImageStreams et tags
- Importer et publier des images vers un registre d'entreprise
- Déclencheurs de déploiement sur changement d'image
Travaux pratiques
Objectif :Gérer les images de l'application avec les ImageStreams.
Description :Les participants importent une image externe dans un ImageStream du projet. Ils configurent un déploiement qui se met à jour automatiquement lorsqu'un nouveau tag est publié. Ils publient ensuite une image vers un registre d'entreprise. Quel avantage apporte un ImageStream par rapport à une référence directe à une image ? Le redéploiement automatique observé valide l'exercice.
Description :Les participants importent une image externe dans un ImageStream du projet. Ils configurent un déploiement qui se met à jour automatiquement lorsqu'un nouveau tag est publié. Ils publient ensuite une image vers un registre d'entreprise. Quel avantage apporte un ImageStream par rapport à une référence directe à une image ? Le redéploiement automatique observé valide l'exercice.
- Le processus de build et la ressource BuildConfig
- Stratégies de build : Source-to-Image et Dockerfile
- Déclencheurs : webhooks Git, changement de configuration, changement d'image
- Suivi, logs et dépannage des builds
Travaux pratiques
Objectif :Construire une application directement depuis son code source.
Description :Les participants créent un build Source-to-Image à partir d'un dépôt Git. Ils créent ensuite un second build à partir d'un Dockerfile. Ils configurent un webhook pour déclencher le build à chaque commit et diagnostiquent un build en échec. Dans quel cas privilégier un build Dockerfile plutôt que Source-to-Image ? L'application reconstruite et redéployée après un commit valide l'exercice.
Description :Les participants créent un build Source-to-Image à partir d'un dépôt Git. Ils créent ensuite un second build à partir d'un Dockerfile. Ils configurent un webhook pour déclencher le build à chaque commit et diagnostiquent un build en échec. Dans quel cas privilégier un build Dockerfile plutôt que Source-to-Image ? L'application reconstruite et redéployée après un commit valide l'exercice.
- Images builder et fonctionnement de S2I
- Scripts assemble et run : personnaliser la construction
- Créer sa propre image builder S2I
- Builds chaînés pour produire des images légères
Travaux pratiques
Objectif :Adapter le processus Source-to-Image aux besoins d'une application.
Description :Les participants surchargent les scripts S2I pour ajouter une étape de construction spécifique. Ils créent ensuite leur propre image builder et l'utilisent pour construire une application. Ils mettent en place un build chaîné pour réduire la taille de l'image finale. Quel intérêt présente une image builder commune à toutes les équipes ? L'image finale allégée et fonctionnelle valide l'exercice.
Description :Les participants surchargent les scripts S2I pour ajouter une étape de construction spécifique. Ils créent ensuite leur propre image builder et l'utilisent pour construire une application. Ils mettent en place un build chaîné pour réduire la taille de l'image finale. Quel intérêt présente une image builder commune à toutes les équipes ? L'image finale allégée et fonctionnelle valide l'exercice.
- Tekton et OpenShift Pipelines : principes et architecture
- Tasks, Pipelines, PipelineRuns et workspaces
- Déclencher un pipeline depuis Git avec les Triggers
- Réutiliser des tâches du catalogue
- Panorama du déploiement GitOps avec OpenShift GitOps
Travaux pratiques
Objectif :Automatiser la chaîne de livraison avec un pipeline intégré.
Description :Les participants construisent un pipeline qui clone le code, exécute les tests, construit l'image et déploie l'application. Ils le déclenchent automatiquement à chaque commit grâce aux Triggers. Ils suivent son exécution dans la console et corrigent une étape en échec. Quelles étapes doivent bloquer le pipeline avant tout déploiement ? Le pipeline exécuté de bout en bout valide l'exercice.
Description :Les participants construisent un pipeline qui clone le code, exécute les tests, construit l'image et déploie l'application. Ils le déclenchent automatiquement à chaque commit grâce aux Triggers. Ils suivent son exécution dans la console et corrigent une étape en échec. Quelles étapes doivent bloquer le pipeline avant tout déploiement ? Le pipeline exécuté de bout en bout valide l'exercice.
- Le serveur OAuth et les fournisseurs d'identité : HTPasswd, LDAP
- Utilisateurs, groupes et rôles
- RBAC : rôles de cluster et rôles de projet
- ServiceAccounts et accès des applications à l'API
Travaux pratiques
Objectif :Contrôler l'accès des utilisateurs et des équipes à la plateforme.
Description :Les participants configurent un fournisseur d'identité HTPasswd et créent des utilisateurs et des groupes. Ils attribuent des rôles différents par projet, puis vérifient les actions autorisées et refusées. Ils retirent aux utilisateurs standard le droit de créer des projets. Pourquoi attribuer les rôles à des groupes plutôt qu'à des utilisateurs ? Le respect des droits définis pour chaque profil valide l'exercice.
Description :Les participants configurent un fournisseur d'identité HTPasswd et créent des utilisateurs et des groupes. Ils attribuent des rôles différents par projet, puis vérifient les actions autorisées et refusées. Ils retirent aux utilisateurs standard le droit de créer des projets. Pourquoi attribuer les rôles à des groupes plutôt qu'à des utilisateurs ? Le respect des droits définis pour chaque profil valide l'exercice.
- Security Context Constraints (SCC) et exécution sans privilèges
- Gestion des Secrets et des identifiants d'accès
- NetworkPolicies et isolation entre projets
- Routes sécurisées en TLS : edge, passthrough, re-encrypt
Travaux pratiques
Objectif :Sécuriser l'exécution et les communications des applications.
Description :Les participants déploient une image qui exige des privilèges et analysent son refus par les SCC. Ils corrigent le déploiement sans affaiblir la sécurité du cluster. Ils isolent ensuite les projets avec des NetworkPolicies et exposent l'application par une route TLS. Pourquoi OpenShift refuse-t-il par défaut les conteneurs exécutés en root ? L'application sécurisée et accessible en HTTPS valide l'exercice.
Description :Les participants déploient une image qui exige des privilèges et analysent son refus par les SCC. Ils corrigent le déploiement sans affaiblir la sécurité du cluster. Ils isolent ensuite les projets avec des NetworkPolicies et exposent l'application par une route TLS. Pourquoi OpenShift refuse-t-il par défaut les conteneurs exécutés en root ? L'application sécurisée et accessible en HTTPS valide l'exercice.
- Requêtes et limites de ressources des conteneurs
- LimitRanges et valeurs par défaut par projet
- ResourceQuotas et ClusterResourceQuotas
- Modèle de projet par défaut pour industrialiser la création des projets
Travaux pratiques
Objectif :Encadrer la consommation des ressources par projet et par équipe.
Description :Les participants définissent un LimitRange et un quota sur un projet, puis tentent de les dépasser. Ils créent un quota partagé entre plusieurs projets d'une même équipe. Ils personnalisent ensuite le modèle de projet pour appliquer automatiquement ces règles. Comment garantir que chaque nouveau projet respecte les règles de l'entreprise ? Le projet créé avec ses limites appliquées automatiquement valide l'exercice.
Description :Les participants définissent un LimitRange et un quota sur un projet, puis tentent de les dépasser. Ils créent un quota partagé entre plusieurs projets d'une même équipe. Ils personnalisent ensuite le modèle de projet pour appliquer automatiquement ces règles. Comment garantir que chaque nouveau projet respecte les règles de l'entreprise ? Le projet créé avec ses limites appliquées automatiquement valide l'exercice.
- Mise à l'échelle manuelle et auto-dimensionnement horizontal
- Contrôle du placement des pods : labels, sélecteurs de nœuds, taints
- Pile de supervision intégrée : Prometheus, Alertmanager, tableaux de bord de la console
- Supervision des applications et alertes
Travaux pratiques
Objectif :Adapter automatiquement l'application à la charge et superviser la plateforme.
Description :Les participants configurent un auto-dimensionnement horizontal sur leur application puis génèrent de la charge. Ils observent l'évolution du nombre de pods dans les tableaux de bord de la console. Ils définissent une alerte sur le comportement de l'application et la déclenchent. Quels indicateurs faut-il suivre pour anticiper un manque de capacité du cluster ? L'adaptation automatique à la charge et l'alerte reçue clôturent la formation.
Description :Les participants configurent un auto-dimensionnement horizontal sur leur application puis génèrent de la charge. Ils observent l'évolution du nombre de pods dans les tableaux de bord de la console. Ils définissent une alerte sur le comportement de l'application et la déclenchent. Quels indicateurs faut-il suivre pour anticiper un manque de capacité du cluster ? L'adaptation automatique à la charge et l'alerte reçue clôturent la formation.
Travaux pratiques
Travaux réalisés sur un cluster OpenShift (version d'évaluation d'OpenShift Container Platform ou OKD), avec la console web, le client oc, le registre intégré et OpenShift Pipelines. Environ 60 % du temps est consacré aux travaux pratiques.
Programme mis à jour le 09/11/2026
Public concerné
Administrateurs et développeurs travaillant dans un environnement Red Hat souhaitant exploiter, gérer et utiliser une plateforme OpenShift.
Prérequis
La maîtrise de Docker ou d'un outil d'orchestration de conteneurs est nécessaire. Elle permet de se concentrer sur les apports propres à OpenShift plutôt que sur les notions de base des conteneurs. Une pratique de la ligne de commande Linux est recommandée, car une grande partie des travaux pratiques se fait avec le client oc.
J’évalue mes connaissances pour vérifier que je dispose des prérequis nécessaires pour profiter pleinement de cette formation en faisant le test de prérequis.
Faire le testFinancement
Cette formation peut être prise en charge par votre entreprise, seule ou avec l’appui de son opérateur de compétences. Nous fournissons le devis et les pièces attendues par l’OPCO.