Guide Complet pour l’Administration d’un Cluster Red Hat OpenShift : Architecture et Concepts Clés

1. Introduction à Red Hat OpenShift

Red Hat OpenShift se positionne comme une plateforme de conteneurs d’entreprise de premier plan, conçue pour permettre aux organisations de créer, moderniser et déployer des applications à une échelle significative.[1] Fondamentalement, OpenShift s’appuie sur Kubernetes, le standard de facto pour l’orchestration de conteneurs, mais l’enrichit considérablement avec un ensemble de fonctionnalités intégrées qui couvrent le développement, les opérations et la sécurité.[1] L’objectif principal d’OpenShift est de simplifier l’ensemble du cycle de vie des applications, depuis leur conception jusqu’à leur mise en production et leur maintenance, en particulier dans des environnements de cloud hybride. Pour ce faire, la plateforme s’efforce d’assurer une cohérence opérationnelle à travers divers environnements d’exécution, en s’appuyant sur une infrastructure ouverte et flexible, elle-même basée sur Linux.[1] Pour tout administrateur, saisir la définition et la portée d’OpenShift est une étape initiale indispensable, car elle établit le contexte de ce qu’est la plateforme et les problèmes qu’elle vise à résoudre.

1.1 Relation avec Kubernetes et Valeur Ajoutée d’OpenShift

La relation entre OpenShift et Kubernetes est symbiotique : OpenShift utilise Kubernetes comme son moteur principal d’orchestration de conteneurs.[1] Cependant, Kubernetes, dans sa forme “vanilla” (c’est-à-dire non modifiée ou pure), bien que puissant, est essentiellement un ensemble de briques de base. Pour construire une plateforme d’entreprise complète et prête à la production, de nombreuses capacités supplémentaires doivent être intégrées manuellement. Celles-ci incluent, entre autres, la surveillance, la journalisation centralisée, un service mesh, une infrastructure serverless, des outils de productivité pour les développeurs, et des mécanismes de sécurité avancés.[1] C’est précisément là qu’OpenShift apporte sa valeur ajoutée majeure.

OpenShift se présente comme une solution complète qui intègre nativement un moteur Kubernetes stable et sécurisé, enrichi de ces capacités indispensables, toutes testées, empaquetées et supportées par Red Hat.[1] Alors que Kubernetes offre une flexibilité et une modularité qui permettent de construire une plateforme sur mesure (“do-it-yourself”), OpenShift propose une pile technologique plus intégrée et “opinionated”.[3] Cette approche intégrée vise à simplifier les flux de travail des équipes de développement et d’exploitation (DevOps) et à améliorer la productivité globale en réduisant la complexité inhérente à l’assemblage et à la maintenance de multiples composants disparates.[3]

Il est donc crucial de comprendre qu’OpenShift est bien plus qu’une simple distribution de Kubernetes. Sa valeur réside dans cette intégration poussée, la simplification des opérations, une posture de sécurité renforcée dès l’installation, et un support d’entreprise complet. Ces éléments justifient souvent son adoption par les entreprises qui cherchent à accélérer leur transition vers les conteneurs et les microservices tout en maîtrisant les risques et la complexité. L’administration d’OpenShift, bien que reposant sur les fondations de Kubernetes, s’étend ainsi à la gestion d’un écosystème plus vaste et plus cohésif. Cette intégration peut simplifier de nombreuses tâches, mais elle introduit également une certaine complexité propre à OpenShift, avec ses propres outils et concepts (comme les Routes, ImageStreams, BuildConfigs) que les administrateurs doivent maîtriser en plus des concepts Kubernetes.

1.2 Aperçu des Cas d’Utilisation et des Avantages

OpenShift est conçu pour répondre à un large éventail de cas d’utilisation dans le paysage applicatif moderne. Parmi les plus courants, on trouve le développement de nouvelles applications cloud-natives, la modernisation d’applications existantes (parfois appelées “legacy”), le déploiement et la gestion d’applications à grande échelle, la mise en œuvre de l’automatisation à l’échelle de l’entreprise, la consolidation de charges de travail virtualisées et conteneurisées sur une plateforme unique, le renforcement de la sécurité applicative et le déploiement de charges de travail en périphérie du réseau (edge computing).[1]

Les avantages découlant de l’utilisation d’OpenShift sont multiples et alignés sur les besoins des entreprises cherchant à innover plus rapidement tout en maintenant la stabilité et la sécurité. La standardisation des environnements de développement, de test et de production, basée sur Linux et les conteneurs, est un atout majeur.[1] La plateforme simplifie considérablement le cycle de vie des applications, depuis le build jusqu’au déploiement et à la mise à l’échelle. L’automatisation est un autre avantage clé, OpenShift fournissant une base solide pour unifier diverses technologies, équipes et environnements.[1] Enfin, le support d’entreprise offert par Red Hat, disponible 24h/24 et 7j/7, ainsi qu’un cycle de vie de support étendu (pouvant aller jusqu’à 9 ans pour certaines versions), sont des facteurs déterminants pour les organisations qui exigent fiabilité et assistance professionnelle.[1]

Le choix d’OpenShift par rapport à une solution Kubernetes “vanilla” est souvent motivé par un besoin impérieux de standardisation, d’un support d’entreprise robuste et d’une pile technologique cohérente et sécurisée dès le départ. En fournissant une plateforme où de nombreux composants essentiels sont déjà intégrés, testés ensemble et supportés par un unique fournisseur, OpenShift permet de réduire significativement le fardeau d’intégration, de test et de maintenance qui incomberait autrement aux équipes internes. Cela se traduit par un gain de temps et une réduction de la complexité, permettant aux entreprises de se concentrer sur la création de valeur applicative plutôt que sur la construction et la maintenance de leur infrastructure de conteneurs.[3]

2. Architecture Fondamentale d’OpenShift

L’architecture de Red Hat OpenShift est conçue en couches superposées, chacune jouant un rôle spécifique dans la fourniture d’une plateforme de conteneurs robuste et complète. Comprendre cette structure est essentiel pour administrer efficacement un cluster OpenShift.

2.1 Couches d’Architecture

L’architecture d’OpenShift peut être globalement divisée en plusieurs couches logiques :

1. Couche d’Infrastructure (Infrastructure Layer) : C’est la fondation sur laquelle repose l’ensemble du cluster OpenShift. Elle peut être constituée de serveurs physiques (bare metal), de machines virtuelles (VMs) hébergées dans un datacenter privé, ou de ressources provisionnées sur un cloud public (comme AWS, Azure, GCP) ou privé.4 Cette couche fournit les ressources de calcul, de stockage et de réseau de base nécessaires au fonctionnement du cluster.
2. Couche de Service (Service Layer) : Située au-dessus de la couche d’infrastructure, la couche de service est responsable de la définition et de la gestion des unités de travail fondamentales, les pods. Elle gère également leurs politiques d’accès, leur fournit des adresses IP persistantes et des noms d’hôte uniques au sein du cluster, et offre des capacités d’équilibrage de charge interne simples pour distribuer le travail entre les différents composants applicatifs.[4]

Ces couches interagissent pour créer un environnement où les applications conteneurisées peuvent être déployées, gérées et mises à l’échelle de manière efficace et cohérente.

2.2 Nœuds du Control Plane (Master Nodes / Control Plane Nodes)

Les nœuds du Control Plane, souvent appelés “master nodes”, constituent le cerveau du cluster OpenShift. Ils sont responsables de la gestion globale du cluster, y compris la coordination de toutes les activités, la maintenance de l’état désiré du cluster et la gestion des nœuds worker.[2] Pour assurer la haute disponibilité, un cluster OpenShift en production requiert un minimum de trois nœuds de control plane.[2] Si l’un de ces nœuds tombe en panne, les autres peuvent continuer à assurer la gestion du cluster.

• API Server (kube-apiserver) : C’est le point d’entrée central pour toutes les interactions avec le cluster. Il expose l’API Kubernetes (et l’API OpenShift via l’OpenShift API Server) et est responsable de la validation et de la configuration de toutes les données pour les objets API tels que les pods, les services, les routes, etc. Toutes les commandes oc ou kubectl, ainsi que les interactions depuis la console web, passent par l’API Server.[2]
• etcd : Une banque de données clé-valeur distribuée, cohérente et hautement disponible. etcd stocke de manière persistante l’intégralité de l’état de configuration du cluster, y compris la définition de tous les objets *Kubernetes et OpenShift, l’état des applications, les politiques de sécurité, etc..[2] La fiabilité et la performance d’etcd sont critiques pour la santé globale du cluster. Dans OpenShift, la gestion d’etcd est souvent simplifiée par l’utilisation d’un etcd Operator.[5]
• Scheduler (kube-scheduler) : Ce composant surveille en permanence les pods nouvellement créés qui n’ont pas encore été assignés à un nœud. Sa tâche est de sélectionner le nœud worker le plus approprié pour héberger chaque pod, en tenant compte des demandes de ressources du pod (CPU, mémoire), des contraintes de placement (affinités, anti-affinités, taints, tolerations), et de la capacité disponible sur les nœuds workers.[2]
• Controller Manager (kube-controller-manager) : Il exécute un ensemble de boucles de contrôle (contrôleurs) qui surveillent l’état du cluster via l’API Server. Chaque contrôleur est responsable d’un type de ressource spécifique (par exemple, Replication Controller, Endpoints, Namespace, ServiceAccount). Leur rôle est de s’assurer que l’état actuel du cluster correspond à l’état désiré défini par les utilisateurs ou les administrateurs. Si un écart est détecté, le contrôleur prend des mesures pour corriger la situation.[2]
• OpenShift API Server : Spécifique à OpenShift, ce serveur API est géré par l’OpenShift API Operator. Il étend l’API Kubernetes en fournissant des points d’entrée pour les objets et fonctionnalités propres à OpenShift, tels que les Routes, les Projects, les ImageStreams, les BuildConfigs et les DeploymentConfigs.[2]
• OpenShift Controller Manager : Similaire au kube-controller-manager, mais pour les objets spécifiques à OpenShift. Géré par l’OpenShift Controller Manager Operator, il surveille etcd pour les changements relatifs aux objets OpenShift (comme les projets, les routes, les templates) et utilise l’API OpenShift pour appliquer l’état désiré.[2]
• OpenShift OAuth API Server & OAuth Server : Ces composants, gérés par le Cluster Authentication Operator, sont responsables de la gestion de l’authentification des utilisateurs et des systèmes au sein du cluster. Ils valident les informations d’identification, configurent les données d’authentification (utilisateurs, groupes) et émettent des tokens OAuth qui sont ensuite utilisés pour authentifier les requêtes API.[2]

La compréhension approfondie de ces composants du control plane est fondamentale pour l’administrateur, car ils sont au cœur du fonctionnement du cluster. Leur surveillance, leur dépannage et la gestion de leur capacité sont des tâches administratives critiques.

2.3 Nœuds de Calcul (Worker Nodes / Compute Nodes)

Les nœuds de calcul, ou “worker nodes” (parfois aussi appelés “compute nodes”), sont les machines (physiques ou virtuelles) du cluster OpenShift où les applications des utilisateurs sont effectivement exécutées.[2] Ils sont responsables de la gestion de la création et du cycle de vie global des pods qui leur sont assignés par le scheduler.[2] Un cluster peut comporter de quelques à plusieurs centaines de nœuds worker, en fonction des besoins de la charge de travail.

Les composants clés s’exécutant sur chaque nœud worker incluent :

• Kubelet : C’est l’agent principal de Kubernetes qui s’exécute sur chaque nœud du cluster (y compris les nœuds worker et, dans certaines configurations, les nœuds du control plane). Il reçoit les spécifications des pods (PodSpecs) de l’API Server et s’assure que les conteneurs décrits dans ces PodSpecs sont en cours d’exécution et en bonne santé sur son nœud. Le Kubelet gère également les volumes de stockage attachés aux pods et communique l’état de son nœud et de ses pods au control plane.[2]
• CRI-O : C’est le moteur d’exécution de conteneurs (container runtime) utilisé par défaut dans OpenShift pour gérer le cycle de vie des conteneurs sur les nœuds. CRI-O est une implémentation de l’interface CRI (Container Runtime Interface) de Kubernetes, conçue pour être légère, sécurisée et optimisée pour Kubernetes.[2] Il interagit avec le Kubelet pour démarrer, arrêter et gérer les conteneurs.
• Service Proxy (kube-proxy) : Ce composant s’exécute sur chaque nœud et est responsable du maintien des règles réseau sur le nœud. Ces règles permettent la communication réseau vers les Pods depuis des sessions réseau à l’intérieur ou à l’extérieur du cluster. kube-proxy gère la découverte de services (en observant les objets Service et Endpoint) et effectue un équilibrage de charge simple pour le trafic destiné aux services.[6]
• Pods : Comme mentionné précédemment, un pod est la plus petite unité déployable dans Kubernetes et OpenShift. Il encapsule un ou plusieurs conteneurs (par exemple, des conteneurs Docker), ainsi que leurs ressources partagées comme le stockage et le réseau (une adresse IP unique par pod).[2] Les applications des utilisateurs s’exécutent à l’intérieur de ces pods sur les nœuds worker.

La bonne gestion des nœuds worker, notamment en termes de ressources (CPU, mémoire, stockage, réseau) et de leur état de santé, est directement liée à la performance, à la disponibilité et à la stabilité des applications hébergées sur le cluster.

2.4 Nœuds d’Infrastructure (Infrastructure Nodes)

Dans les déploiements OpenShift de production, il est courant et recommandé de dédier certains nœuds à l’hébergement des composants d’infrastructure du cluster. Ces “nœuds d’infrastructure” exécutent des services essentiels au fonctionnement du cluster mais qui ne sont pas directement des applications utilisateur. Typiquement, cela inclut [2] :

• Le routeur OpenShift par défaut (basé sur HAProxy) qui gère le trafic entrant.
• Le registre d’images de conteneurs intégré à OpenShift.
• Les composants pour la collecte des métriques et la surveillance du cluster (par exemple, Prometheus, Alertmanager, Grafana).
• Parfois, les composants de journalisation centralisée (par exemple, la pile EFK/ELK ou son équivalent moderne).

L’objectif principal de l’utilisation de nœuds d’infrastructure est de séparer les charges de travail d’infrastructure des charges de travail applicatives des utilisateurs. Cette séparation améliore la stabilité globale du cluster, car les services d’infrastructure critiques ne sont pas en compétition pour les ressources avec les applications utilisateur et sont moins susceptibles d’être affectés par des problèmes liés à ces applications. Elle facilite également la gestion des ressources et la planification de la capacité.

La création de nœuds d’infrastructure se fait généralement en utilisant des MachineSets (si le cluster est provisionné par l’installateur et gère les machines via l’API Machine) ou en étiquetant manuellement des nœuds worker existants avec une étiquette spécifique, par exemple node-role.kubernetes.io/infra="".[10] Ensuite, des sélecteurs de nœuds (nodeSelector) ou des affinités de nœuds sont utilisés dans les configurations des pods d’infrastructure pour s’assurer qu’ils sont planifiés sur ces nœuds dédiés.

Isoler les services d’infrastructure est une bonne pratique qui contribue significativement à la robustesse et à la performance d’un cluster OpenShift, en évitant que les applications utilisateurs ne consomment des ressources vitales pour le bon fonctionnement de la plateforme elle-même.

2.5 Système d’Exploitation : Red Hat Enterprise Linux CoreOS (RHCOS)

Chaque nœud au sein d’un cluster OpenShift Container Platform (à partir de la version 4) exécute Red Hat Enterprise Linux CoreOS (RHCOS) comme système d’exploitation de base.[2] RHCOS est une version de Red Hat Enterprise Linux (RHEL) spécifiquement conçue et optimisée pour exécuter des charges de travail conteneurisées avec OpenShift. Il partage le même noyau que RHEL et bénéficie donc des mêmes mises à jour de sécurité et corrections de bugs.[2]

Une caractéristique distinctive de RHCOS est sa nature largement immuable et sa gestion centralisée par le cluster lui-même. Les mises à jour des nœuds RHCOS sont gérées par le MachineConfig Operator (MCO). Le MCO délivre les mises à jour du système d’exploitation et les changements de configuration sous forme d’images de conteneur qui sont ensuite écrites sur le disque du nœud. Lorsqu’un nœud redémarre, il démarre sur cette nouvelle image mise à jour.[2]

Ce modèle de gestion représente un changement de paradigme par rapport à la gestion traditionnelle des systèmes d’exploitation où les administrateurs se connectent aux serveurs pour appliquer des configurations ou des mises à jour manuellement. Avec RHCOS et le MCO, l’administration des nœuds se fait de manière déclarative : les administrateurs définissent l’état désiré des nœuds via des objets MachineConfig, et le MCO se charge d’appliquer ces configurations de manière cohérente à travers le cluster. Cette approche simplifie la maintenance, améliore la sécurité en réduisant la surface d’attaque (car les nœuds sont minimaux et gérés de manière centralisée), et garantit une plus grande cohérence entre les nœuds du cluster. Il est crucial pour les administrateurs OpenShift de comprendre ce modèle de gestion “immuable” et basé sur les opérateurs pour configurer et mettre à jour les nœuds efficacement.

Le tableau suivant résume les rôles et composants clés des différents types de nœuds dans une architecture OpenShift :

Cette distinction et la spécialisation des types de nœuds sont fondamentales pour la stabilité, la performance et la sécurité d’un cluster OpenShift. Une mauvaise répartition des rôles ou un sous-dimensionnement de l’un de ces types de nœuds peut avoir des impacts significatifs sur l’ensemble de la plateforme et les applications qu’elle héberge.

3.Concepts Clés de Kubernetes pour l’Administration d’OpenShift

Red Hat OpenShift étant construit sur Kubernetes, une compréhension solide des objets et concepts fondamentaux de Kubernetes est un prérequis indispensable pour tout administrateur OpenShift. Ces concepts forment la base sur laquelle OpenShift ajoute ses propres fonctionnalités et abstractions.

3.1 Pods : Unité de déploiement de base

Le Pod est la plus petite et la plus simple unité de calcul qui peut être créée et gérée dans un environnement Kubernetes, et par extension, dans OpenShift.4 Un pod représente une instance unique d’un processus en cours d’exécution dans le cluster. De manière cruciale, un pod peut encapsuler un ou plusieurs conteneurs (par exemple, des conteneurs Docker ou conformes à la spécification OCI).[8]

Lorsque plusieurs conteneurs s’exécutent au sein d’un même pod, ils sont considérés comme étant étroitement couplés. Ils partagent des ressources communes, notamment :

• Le réseau : Tous les conteneurs d’un pod partagent le même namespace réseau, ce qui signifie qu’ils partagent la même adresse IP et le même espace de ports. Ils peuvent communiquer entre eux en utilisant localhost.[8]
• Le stockage : Les conteneurs d’un pod peuvent partager des volumes de stockage, ce qui permet un partage de données efficace entre eux.[8]
• Le contexte d’exécution : Ils s’exécutent dans un contexte partagé, incluant les mêmes namespaces Linux (IPC, UTS, etc.) et potentiellement les mêmes cgroups, bien que des isolations supplémentaires puissent être appliquées au niveau des conteneurs individuels.[8]

Les conteneurs au sein d’un même pod sont toujours co-localisés (s’exécutent sur le même nœud worker) et co-planifiés (le scheduler prend des décisions pour le pod dans son ensemble).[8]

Une caractéristique essentielle des pods est leur nature éphémère.[8] Les pods sont créés, se voient attribuer un identifiant unique (UID), et sont planifiés pour s’exécuter sur un nœud worker. Ils y restent jusqu’à ce qu’ils terminent leur exécution (selon leur politique de redémarrage) ou qu’ils soient explicitement supprimés. En cas de défaillance du nœud sur lequel un pod s’exécute, ce pod spécifique (identifié par son UID) n’est pas “replanifié” ou déplacé vers un autre nœud. Au lieu de cela, il est généralement supprimé (après un délai), et s’il est géré par un contrôleur de plus haut niveau (comme un Deployment ou un StatefulSet), ce contrôleur créera un nouveau pod de remplacement, potentiellement avec le même nom mais un nouvel UID.[8]

La compréhension du cycle de vie des pods, de la manière dont ils consomment les ressources (CPU, mémoire), de leurs interactions réseau et de leur nature éphémère est fondamentale pour l’administration d’OpenShift, car toutes les applications et de nombreux services système s’exécutent en tant que pods.

3.2 Services : Abstraction réseau pour les Pods

Étant donné la nature éphémère des pods et le fait que leurs adresses IP peuvent changer (par exemple, lors d’un redémarrage ou d’une replanification), il est nécessaire de disposer d’un mécanisme pour y accéder de manière stable et fiable. C’est le rôle du Service Kubernetes.[14]

Un Service est une abstraction qui définit un ensemble logique de pods (généralement déterminés par un sélecteur de labels) et une politique permettant d’y accéder.[16]Il fournit un point d’accès unique et stable – une adresse IP virtuelle (appelée ClusterIP) et un nom DNS – pour un groupe de pods qui fournissent la même fonctionnalité. Lorsqu’un client (un autre pod ou un système externe, selon la configuration) se connecte à l’adresse IP du Service, le trafic est automatiquement routé et équilibré vers l’un des pods sains faisant partie de cet ensemble logique.[15]

Les Services permettent un couplage lâche entre les composants applicatifs. Par exemple, un pod frontend n’a pas besoin de connaître les adresses IP individuelles des pods backend ; il se connecte simplement au Service backend. Cela facilite la mise à l’échelle, les mises à jour et la gestion des pannes des pods backend sans impacter le frontend.

Kubernetes propose plusieurs types de Services pour différents cas d’usage [16] :

• ClusterIP : (Type par défaut) Expose le Service sur une adresse IP interne au cluster. Ce type de Service n’est accessible que depuis l’intérieur du cluster. C’est le type le plus courant pour la communication inter-services au sein du cluster.
• NodePort : Expose le Service sur un port statique (le NodePort) sur l’adresse IP de chaque nœud du cluster. Un client externe peut alors accéder au Service en contactant <NodeIP>:<NodePort>. Kubernetes route ce trafic vers le ClusterIP du Service, qui à son tour le route vers les pods. Ce type est souvent utilisé pour exposer des services pendant le développement ou pour des services qui ne nécessitent pas un équilibreur de charge dédié.
• LoadBalancer : Expose le Service de manière externe en utilisant l’équilibreur de charge du fournisseur de cloud (si le cluster s’exécute sur une plateforme cloud qui le supporte, comme AWS, Azure, ou GCP). Le fournisseur de cloud provisionne un équilibreur de charge qui dirige le trafic externe vers le Service (via son NodePort ou directement vers les pods). C’est la méthode standard pour exposer des applications à Internet en production sur le cloud.
• ExternalName : Mappe le Service à un nom DNS externe (par exemple, my.database.example.com) en retournant un enregistrement CNAME. Aucun proxy n’est mis en place. Ce type est utile pour permettre aux applications du cluster d’accéder à des services externes en utilisant un nom interne au cluster.

Les administrateurs doivent maîtriser la configuration des Services pour assurer la connectivité et l’accessibilité des applications déployées sur OpenShift, que ce soit pour des communications internes au cluster ou pour une exposition au monde extérieur.

3.3 Deployments : Gestion déclarative des applications

Un Deployment Kubernetes est un objet de plus haut niveau qui permet de gérer de manière déclarative le cycle de vie des applications stateless.[14] Au lieu de créer et de gérer manuellement des pods individuels, les administrateurs et les développeurs décrivent l’état désiré de leur application dans un objet Deployment. Le contrôleur de Deployment se charge ensuite de faire converger l’état actuel du système vers cet état désiré, et ce, de manière contrôlée[18].

Les principales responsabilités et fonctionnalités d’un Deployment incluent :

• Gestion des ReplicaSets : Un Deployment gère un (ou plusieurs, lors des mises à jour) ReplicaSet. Le ReplicaSet, à son tour, s’assure qu’un nombre spécifié de répliques (copies identiques) d’un pod sont en cours d’exécution à tout moment.[18]
• Mises à jour déclaratives : Pour mettre à jour une application, il suffit de modifier la spécification du pod (par exemple, changer la version de l’image du conteneur) dans le template du Deployment. Le contrôleur de Deployment gérera alors la transition de l’ancienne version vers la nouvelle.
• Stratégies de mise à jour : Les Deployments supportent différentes stratégies pour le déploiement de nouvelles versions, la plus courante étant :
  • RollingUpdate (Mise à jour progressive) : (Stratégie par défaut) Met à jour les pods de manière progressive, en remplaçant les anciens pods par de nouveaux un par un ou par lots, tout en s’assurant qu’un certain nombre de pods restent disponibles pour servir le trafic. Cela permet des mises à jour sans interruption de service.[18]
  • Recreate (Recréer) : Supprime tous les anciens pods avant de créer les nouveaux. Cela entraîne une interruption de service pendant la mise à jour.
• Rollbacks (Retours en arrière) : Les Deployments conservent un historique des révisions, ce qui permet de revenir facilement à une version précédente de l’application en cas de problème avec une nouvelle version.[18]
• Mise à l’échelle (Scaling) : Il est facile d’augmenter ou de diminuer le nombre de répliques d’une application en modifiant simplement le champ replicas dans la spécification du Deployment.

Les Deployments sont la méthode standard et recommandée pour déployer et gérer la plupart des applications stateless dans Kubernetes et OpenShift. Les administrateurs les utilisent constamment pour les déploiements initiaux, les mises à jour de version, les mises à l’échelle et les retours en arrière.

3.4 ReplicaSets : Assurer la disponibilité des Pods

Un ReplicaSet a pour objectif principal de maintenir un ensemble stable de répliques de pods en cours d’exécution à un instant T.[14] Il garantit qu’un nombre spécifié (défini par le champ replicas) de pods identiques, basés sur un template de pod fourni, sont toujours disponibles. Si un pod géré par un ReplicaSet vient à échouer, à être supprimé ou à s’arrêter pour une raison quelconque, le ReplicaSet détecte cet écart par rapport à l’état désiré et crée automatiquement un nouveau pod pour le remplacer, restaurant ainsi le nombre de répliques attendu.[20]

Les ReplicaSets utilisent un sélecteur de labels pour identifier les pods qu’ils sont censés gérer. Tout pod dont les labels correspondent au sélecteur du ReplicaSet est considéré comme étant sous sa gestion.

Bien qu’il soit possible de créer et de gérer des ReplicaSets directement, ce n’est généralement pas la pratique recommandée. Les Deployments (vus précédemment) sont des contrôleurs de plus haut niveau qui gèrent eux-mêmes les ReplicaSets.[19] Lorsqu’on crée ou met à jour un Deployment, celui-ci crée et orchestre les ReplicaSets nécessaires pour atteindre l’état désiré. Cette abstraction offerte par les Deployments simplifie grandement la gestion des mises à jour et des rollbacks.

Par conséquent, les administrateurs interagissent rarement directement avec les ReplicaSets. Cependant, comprendre leur rôle est essentiel pour saisir comment Kubernetes et OpenShift assurent la haute disponibilité et la mise à l’échelle des pods pour les applications stateless. Ils sont le mécanisme sous-jacent qui garantit que le nombre souhaité d’instances d’une application est toujours en cours d’exécution.

3.5 Namespaces : Isolation des ressources

Les Namespaces (espaces de noms) sont un mécanisme fondamental de Kubernetes qui permet de partitionner les ressources d’un unique cluster physique en plusieurs clusters virtuels isolés les uns des autres.[14] Ils fournissent une portée (scope) pour les noms des ressources : le nom d’une ressource doit être unique au sein d’un namespace, mais le même nom peut être réutilisé dans différents namespaces.[21]

Les Namespaces sont particulièrement utiles dans les environnements où de nombreux utilisateurs, équipes ou projets partagent le même cluster Kubernetes/OpenShift.[21] Ils offrent plusieurs avantages :

• Organisation : Permettent de regrouper logiquement les ressources liées à un projet, une application ou une équipe spécifique.
• Isolation : Bien que l’isolation ne soit pas absolue par défaut (des NetworkPolicies sont nécessaires pour une isolation réseau stricte), les namespaces fournissent une première barrière. Les opérations effectuées dans un amespace n’affectent généralement pas les autres.
• Gestion des accès et des quotas : Les permissions (via RBAC) et les quotas de ressources (quantité de CPU, mémoire, nombre d’objets, etc.) peuvent être définis par namespace, permettant de contrôler et de limiter ce que les utilisateurs peuvent faire et consommer dans leur espace respectif.[21]
• Prévention des conflits de noms : Comme mentionné, ils évitent les collisions de noms entre différentes équipes ou applications.

Kubernetes démarre avec quelques namespaces initiaux [21] :

• default : Le namespace par défaut pour les objets qui ne spécifient pas explicitement de namespace. Il est recommandé de ne pas l’utiliser pour les applications en production et de créer des namespaces dédiés.
• kube-system : Utilisé pour les objets créés par le système Kubernetes lui-même (control plane, addons, etc.).
• kube-public : Ce namespace est lisible par tous les utilisateurs (y compris non authentifiés) et est généralement utilisé pour exposer des informations publiques sur le cluster.
• kube-node-lease : Contient des objets Lease associés à chaque nœud, utilisés pour les signaux de présence des nœuds.

Dans OpenShift, le concept de Project est une extension des Namespaces Kubernetes. La création d’un Projet entraîne automatiquement la création d’un Namespace correspondant, mais le Projet ajoute des fonctionnalités de gestion et des contrôles administratifs supplémentaires spécifiques à OpenShift, comme la gestion des membres du projet et des quotas de manière plus intégrée.[23]Il est donc crucial pour un administrateur OpenShift de comprendre cette relation étroite et les spécificités des Projets.

3.6 ConfigMaps : Gestion de la configuration non sensible

Les ConfigMaps sont des objets API Kubernetes utilisés pour stocker des données de configuration non confidentielles sous forme de paires clé-valeur.[14] L’objectif principal des ConfigMaps est de découpler la configuration des applications du code applicatif lui-même ou du contenu des images de conteneurs.[26] Cela rend les applications plus portables et facilite la gestion des configurations dans différents environnements (développement, test, production) sans avoir à reconstruire les images.

Les données stockées dans un ConfigMap peuvent être consommées par les pods de plusieurs manières [25] :

• Variables d’environnement : Les clés du ConfigMap peuvent être injectées comme variables d’environnement dans les conteneurs d’un pod.
• Arguments de ligne de commande : Les valeurs du ConfigMap peuvent être utilisées pour construire les arguments de la commande de démarrage d’un conteneur.
• Fichiers dans un volume : Le ConfigMap peut être monté comme un volume dans un pod, où chaque clé devient un fichier dans le répertoire de montage, et la valeur de la clé devient le contenu de ce fichier. C’est une méthode très courante pour fournir des fichiers de configuration aux applications.

Les ConfigMaps sont idéaux pour gérer des paramètres tels que les URL de points de terminaison, les niveaux de journalisation, les configurations de fonctionnalités, ou tout autre paramètre de configuration qui n’est pas sensible. Pour les données confidentielles comme les mots de passe ou les clés API, il faut utiliser les Secrets.

3.7 Secrets : Gestion des données sensibles

Les Secrets Kubernetes sont des objets API conçus spécifiquement pour stocker et gérer des informations sensibles.[14]Cela inclut typiquement :

• Mots de passe
• Tokens OAuth
• Clés SSH
• Clés API
• Certificats TLS

L’utilisation de Secrets permet de ne pas inclure ces données confidentielles directement dans les définitions de pods, dans le code source des applications, ou dans les images de conteneurs, ce qui réduit considérablement le risque d’exposition accidentelle.[28]

Les données stockées dans un Secret sont encodées en Base64.[27] Il est important de noter que l’encodage Base64 n’est pas une forme de chiffrement ; c’est simplement un moyen de représenter des données binaires sous forme de texte. Par défaut, les Secrets sont stockés dans etcd (la base de données du cluster) sans chiffrement supplémentaire au niveau de la valeur elle-même.[28] Cela signifie que toute personne ayant un accès API suffisant pour lire les Secrets, ou un accès direct à etcd, pourrait potentiellement récupérer les données sensibles.

echo -n 'maCleSecretePourEtcd123!' | base64
bWFDbGVTZWNyZXRlUG91ckV0Y2QxMjMh

Et pour la décoder:

echo 'bWFDbGVTZWNyZXRlUG91ckV0Y2QxMjMh' | base64 --decode
# ou sur certains systèmes (comme macOS) :
# echo 'bWFDbGVTZWNyZXRlUG91ckV0Y2QxMjMh' | base64 -d
maCleSecretePourEtcd123!

Pour cette raison, il est crucial de prendre des mesures de sécurité supplémentaires lors de l’utilisation des Secrets :

• Activer le chiffrement au repos (Encryption at Rest) pour les Secrets : OpenShift et Kubernetes permettent de configurer le chiffrement des données des Secrets avant qu’elles ne soient écrites dans etcd.
• Mettre en place un contrôle d’accès basé sur les rôles (RBAC) strict : Limiter rigoureusement qui (utilisateurs, groupes, comptes de service) a la permission de lire ou de créer des Secrets, en appliquant le principe du moindre privilège.

Comme les ConfigMaps, les Secrets peuvent être injectés dans les pods de différentes manières [27] :

• En tant que variables d’environnement.
• En tant que fichiers dans un volume monté.

Il existe plusieurs types de Secrets prédéfinis pour des cas d’usage courants, tels que kubernetes.io/service-account-token (pour les tokens de comptes de service), kubernetes.io/dockercfg ou kubernetes.io/dockerconfig.json (pour les identifiants de registres Docker), kubernetes.io/basic-auth (pour l’authentification basique), kubernetes.io/ssh-auth (pour les clés SSH), et kubernetes.io/tls (pour les certificats et clés TLS).[27] On peut également créer des Secrets de type Opaque pour des données arbitraires.

La maîtrise de ces objets Kubernetes fondamentaux est un prérequis indispensable pour administrer OpenShift. La plateforme s’appuie sur ces concepts et les étend, mais sans une compréhension solide de la base Kubernetes, il est difficile d’exploiter pleinement le potentiel d’OpenShift ou de dépanner efficacement les problèmes. La nature éphémère des Pods, par exemple, explique directement la nécessité et l’importance cruciale des Services (pour fournir un point d’accès stable et découvrable) et des contrôleurs comme les Deployments et ReplicaSets (pour maintenir l’état désiré et la disponibilité des applications).

De même, la gestion de la configuration et des informations sensibles via ConfigMaps et Secrets, bien que fondamentale, introduit une complexité administrative liée à la sécurité. Le stockage par défaut non chiffré des Secrets dans etcd [28] souligne la nécessité pour les administrateurs de mettre en œuvre des mesures de sécurité supplémentaires, telles que le chiffrement au repos et une gestion RBAC rigoureuse, pour prévenir les fuites d’informations. Ce ne sont pas de simples mécanismes de stockage de données, mais des points critiques de la posture de sécurité du cluster.

4. Fonctionnalités Spécifiques à OpenShift pour l’Administration

Au-delà des concepts fondamentaux de Kubernetes, Red Hat OpenShift introduit un ensemble de fonctionnalités et d’objets spécifiques qui enrichissent la plateforme, simplifient certaines tâches administratives et fournissent des capacités orientées entreprise. Ces fonctionnalités sont conçues pour améliorer le cycle de vie des applications, l’automatisation et la gestion globale du cluster.

4.1 Projects : Extension des Namespaces Kubernetes

Dans OpenShift, un Project est une extension du concept de Namespace de Kubernetes.[23]Lorsqu’un Projet est créé, un Namespace Kubernetes du même nom est automatiquement créé en arrière-plan. Cependant, les Projets OpenShift ajoutent une surcouche de fonctionnalités et de contrôles administratifs qui ne sont pas présents nativement avec les Namespaces seuls.[23]

Les Projets constituent l’unité fondamentale d’isolation et de collaboration au sein d’un cluster OpenShift. Chaque Projet encapsule ses propres ressources (pods, services, routes, etc.), ses membres (utilisateurs et groupes avec des rôles spécifiques), des quotas de ressources pour limiter la consommation, et des politiques de sécurité.23

Quelques caractéristiques clés des Projets OpenShift :

• Gestion des accès : Les Projets permettent une gestion plus fine des permissions. Les administrateurs de projet peuvent gérer les membres et leurs rôles (par exemple, admin, edit, view) au sein de leur projet.
• Quotas de ressources : Des quotas peuvent être appliqués au niveau du Projet pour limiter la quantité de CPU, de mémoire, le nombre de pods, de services, de PVCs, etc., qu’un projet peut consommer.
• Création contrôlée : Typiquement, dans un environnement OpenShift d’entreprise, la création directe de Projets par des utilisateurs standards est restreinte. Les utilisateurs demandent la création d’un projet via une ressource ProjectRequest, qui peut ensuite être approuvée par un administrateur de cluster.[23]Les projets dont le nom commence par OpenShift- ou kube- sont réservés au système et ne peuvent pas être créés par les commandes utilisateur habituelles (oc new-project) ; leur création nécessite des commandes d’administration (oc adm new-project).[24]

Les Projets sont donc le principal mécanisme dans OpenShift pour organiser les ressources, gérer l’accès multi-utilisateurs et multi-équipes, et appliquer des politiques de gouvernance, offrant une structure plus riche que les Namespaces Kubernetes de base.

4.2 Routes : Exposition des services à l’extérieur du cluster

Alors que Kubernetes utilise les objets Ingress pour gérer l’accès externe aux services HTTP/HTTPS, OpenShift propose son propre mécanisme appelé Route.4 Une Route OpenShift expose un service à un nom d’hôte accessible de l’extérieur du cluster, permettant ainsi aux utilisateurs et aux applications externes d’atteindre les services hébergés dans OpenShift.[29]

Les Routes sont gérées par un routeur OpenShift intégré, qui est généralement une instance de HAProxy déployée et configurée automatiquement par la plateforme.4 Chaque Route définit une correspondance entre un nom d’hôte (par exemple, app.example.com), un chemin optionnel, et un service OpenShift backend. Elle inclut également une configuration de sécurité optionnelle, notamment pour la terminaison TLS.[29]

OpenShift supporte plusieurs types de Routes et de stratégies de terminaison TLS [29] :

• Routes HTTP (non sécurisées) : Le trafic transite en clair (HTTP) jusqu’au pod.
• Routes HTTPS (sécurisées) :
  • Edge Termination : Le routeur OpenShift termine la connexion TLS. Le trafic entre le client et le routeur est chiffré, mais le trafic entre le routeur et le pod backend est en clair (HTTP). Le certificat TLS est configuré au niveau de la Route.
  • Passthrough Termination : Le routeur ne termine pas la connexion TLS. Le trafic chiffré est transmis directement au pod backend, qui est alors responsable de la terminaison TLS et doit posséder le certificat approprié.
  • Re-encryption Termination : Le routeur termine la connexion TLS initiale du client, puis ré-enchiffre le trafic avec un autre certificat (souvent un certificat interne au cluster) avant de l’envoyer au pod backend. Cela garantit que le trafic est chiffré de bout en bout, y compris à l’intérieur du cluster.

Les Routes peuvent également effectuer du routage basé sur le chemin (Path-Based Routing) pour le trafic HTTP, permettant à différentes URL sous le même nom d’hôte d’être dirigées vers des services différents.[29]

Les Routes sont le mécanisme privilégié et simplifié dans OpenShift pour l’exposition des services. Elles offrent une intégration native avec la plateforme, notamment pour la gestion des certificats et la terminaison TLS, ce qui les rend souvent plus simples à utiliser que les objets Ingress Kubernetes standards dans un contexte OpenShift.

4.4 ImageStreams : Abstraction et gestion du cycle de vie des images conteneur

Les ImageStreams sont un concept puissant et central dans OpenShift, conçu pour gérer et réagir aux changements des images de conteneurs.[31] Un ImageStream ne contient pas les données binaires de l’image elle-même (celles-ci résident dans un registre de conteneurs), mais il agit comme une abstraction ou une vue virtuelle de plusieurs images liées, pointant vers elles via des tags.[31]

Fonctionnalités clés des ImageStreams :

• Référencement abstrait : Au lieu de référencer directement une image par son nom complet dans un registre (par exemple, docker.io/library/nginx:latest), les déploiements et les builds dans OpenShift peuvent référencer un tag d’ImageStream (par exemple, my-project/nginx:latest). Cela découple la configuration de déploiement de l’emplacement physique de l’image.
• Tags et historique : Les tags au sein d’un ImageStream (comme latest, v1.0, stable, dev) pointent vers des versions spécifiques d’une image dans un registre. L’ImageStream conserve un historique des images associées à chaque tag, ce qui permet de revenir facilement à une version précédente (rollback).[31]
• Déclencheurs automatiques (Triggers) : C’est l’une des fonctionnalités les plus importantes. Les ImageStreams peuvent être configurés pour surveiller les changements dans les registres d’images externes ou internes. Lorsqu’une nouvelle version d’une image est poussée dans un registre et qu’un tag d’ImageStream est mis à jour pour pointer vers cette nouvelle version, cela peut automatiquement déclencher :
  • Un nouveau build (via un BuildConfig) pour reconstruire une application qui dépend de cette image de base.
  • Un nouveau déploiement (via un DeploymentConfig ou un Deployment) pour mettre à jour une application en cours d’exécution avec la nouvelle image.[31]
• Importation d’images : Les ImageStreams peuvent être configurés pour importer périodiquement les métadonnées d’images depuis des registres externes, maintenant ainsi la vue d’OpenShift à jour avec les dernières versions disponibles.
• Contrôle d’accès : Les permissions sur les objets ImageStream permettent un contrôle d’accès fin sur qui peut voir et utiliser les images au sein d’un projet ou à travers le cluster.[31]

Les ImageStreams sont un pilier de l’intégration continue et du déploiement continu (CI/CD) dans OpenShift, en automatisant les réactions aux mises à jour d’images et en simplifiant la gestion des versions d’images.

4.5 BuildConfigs : Définition des processus de construction d’images

OpenShift intègre un système de build puissant qui permet de construire des images de conteneurs directement au sein du cluster. L’objet central de ce système est le BuildConfig.[34]Un BuildConfig décrit une définition de build unique, incluant la source du code applicatif, la stratégie de build à utiliser, et les déclencheurs qui peuvent initier un nouveau build.[34]

Les éléments clés d’un BuildConfig sont :

• Source : Spécifie l’origine du code source de l’application. Les types de sources courants sont [34] :
  • Git : Pointe vers un dépôt Git.
  • Dockerfile : Utilise un Dockerfile fourni (en ligne ou depuis un dépôt Git).
  • Binary : Accepte une charge binaire (par exemple, un fichier WAR/JAR) poussée directement par le client.
• Stratégie de Build : Détermine le processus utilisé pour transformer le code source en une image de conteneur exécutable. OpenShift supporte plusieurs stratégies [34] :
  • Source-to-Image (S2I) : C’est une stratégie puissante et souvent privilégiée dans OpenShift. Elle utilise une image de builder (une image de conteneur préconfigurée avec les outils et les runtimes nécessaires pour un langage ou un framework spécifique, par exemple Node.js, Python, Java). Le processus S2I injecte le code source de l’application dans cette image de builder, qui exécute ensuite des scripts d’assemblage pour compiler le code, installer les dépendances et configurer l’application. Le résultat est une nouvelle image de conteneur prête à l’exécution. S2I supporte les builds incrémentaux, ce qui peut accélérer considérablement les builds successifs.
  • Docker : Cette stratégie utilise un Dockerfile fourni par l’utilisateur pour construire l’image. OpenShift utilise en interne Buildah (un outil de construction d’images compatible OCI) pour exécuter les instructions du Dockerfile. C’est une option flexible pour ceux qui sont déjà familiers avec la syntaxe Dockerfile.
  • Custom : Permet aux développeurs de définir leur propre image de builder qui encapsule une logique de build entièrement personnalisée. Cette image de builder est responsable de l’ensemble du processus. Cette stratégie offre une flexibilité maximale mais requiert des privilèges élevés et est généralement réservée aux cas d’usage avancés.
  • Pipeline (obsolète) : Anciennement utilisée pour définir des pipelines Jenkins. Cette stratégie est maintenant dépréciée au profit d’OpenShift Pipelines, qui est basé sur Tekton.[37]
• Output : Spécifie où l’image construite doit être poussée, généralement un ImageStream dans le registre interne d’OpenShift.
• Déclencheurs (Triggers) : Un BuildConfig peut être déclenché par divers événements [35] :
  • Webhooks (depuis GitHub, GitLab, Bitbucket, ou un webhook générique).
  • Changement d’une image de base (ImageChangeTrigger), souvent lié à un ImageStream.
  • Changement dans la configuration du BuildConfig lui-même (ConfigChangeTrigger).
  • Manuellement via la CLI ou la console web.

Les builds s’exécutent en tant que pods sur le cluster OpenShift. Les BuildConfigs, en conjonction avec les ImageStreams, fournissent un flux de travail CI/CD intégré et automatisé directement sur la plateforme.

4.6 DeploymentConfigs : Fonctionnalités de déploiement avancées

OpenShift propose un objet appelé DeploymentConfig qui offre des fonctionnalités de déploiement plus avancées et spécifiques à la plateforme, par rapport à l’objet Deployment standard de Kubernetes.[30]Alors que les Deployments Kubernetes utilisent des ReplicaSets pour gérer les répliques de pods, les DeploymentConfigs OpenShift s’appuient sur des ReplicationControllers (un concept plus ancien mais toujours supporté dans ce contexte).[39]

Les caractéristiques distinctives des DeploymentConfigs incluent [30] :

• Déclencheurs (Triggers) : C’est une différence majeure. Les DeploymentConfigs peuvent être automatiquement déclenchés par :
  • ImageChangeTrigger : Un nouveau déploiement est lancé lorsque l’image référencée dans un ImageStream (spécifié dans le DeploymentConfig) est mise à jour. C’est une intégration clé avec les ImageStreams et les BuildConfigs pour un CI/CD automatisé.
  • ConfigChangeTrigger : Un nouveau déploiement est lancé lorsque la configuration du template de pod au sein du DeploymentConfig est modifiée.
• Stratégies de déploiement : En plus des stratégies Rolling (par défaut, similaire au RollingUpdate des Deployments) et Recreate, les DeploymentConfigs supportent une stratégie Custom. Cette dernière permet aux utilisateurs de fournir leur propre logique de déploiement en spécifiant une image de conteneur qui exécutera le processus de déploiement.
• Hooks de cycle de vie : Les DeploymentConfigs permettent de définir des actions (hooks) à exécuter à différentes étapes du processus de déploiement. Par exemple, un hook Pre peut être utilisé pour préparer une base de données avant le déploiement, un hook Mid (pour la stratégie Rolling) peut s’exécuter une fois que les nouveaux pods sont prêts mais avant que les anciens ne soient réduits, et un hook Post peut être utilisé pour des tâches de nettoyage ou de vérification après le déploiement.
• Rollbacks automatiques : En cas d’échec d’un déploiement, un DeploymentConfig peut être configuré pour revenir automatiquement à la dernière version déployée avec succès.

Bien que les Deployments Kubernetes soient de plus en plus la norme et soient recommandés par OpenShift pour la plupart des cas d’usage (surtout pour les applications stateless simples), les DeploymentConfigs restent pertinents et utiles lorsque leurs fonctionnalités spécifiques, notamment les triggers basés sur les ImageStreams et les hooks de cycle de vie avancés, sont nécessaires.[39] Les administrateurs doivent comprendre les cas d’usage de chacun pour choisir l’outil le plus approprié.

Le tableau suivant compare les Deployments Kubernetes et les DeploymentConfigs OpenShift :

Et voici un tableau résumant les stratégies de build dans OpenShift :

4.7 Templates : Déploiement paramétré d’applications

Les Templates OpenShift sont des mécanismes qui permettent de définir un ensemble d’objets Kubernetes et OpenShift (comme des Services, Deployments/DeploymentConfigs, Routes, ImageStreams, PVCs, etc.) sous une forme paramétrée.[42]L’idée est de fournir un plan ou un modèle réutilisable pour déployer une application ou un ensemble de services interconnectés.

Lorsqu’un Template est “traité” ou “instancié”, les utilisateurs peuvent fournir des valeurs pour les paramètres définis dans le Template (par exemple, le nom de l’application, la version de l’image à utiliser, la taille de la mémoire, des variables d’environnement spécifiques, etc.). OpenShift substitue alors ces valeurs dans les définitions d’objets du Template avant de les créer dans le projet cible.[42]

Les Templates peuvent inclure :

• Une liste d’objets à créer.
• Une liste de paramètres avec des descriptions, des valeurs par défaut, et parfois des expressions pour générer des valeurs (par exemple, pour des mots de passe aléatoires).
• Des labels à appliquer à tous les objets créés à partir du Template.
• Un message à afficher à l’utilisateur après l’instanciation.

Les Templates peuvent être stockés au niveau d’un projet ou dans une bibliothèque globale accessible à plusieurs projets. Ils peuvent être instanciés via la console web d’OpenShift (qui présente souvent un formulaire convivial pour remplir les paramètres) ou via la commande oc process suivie de oc apply ou oc create en ligne de commande.[43]

Les Templates sont particulièrement utiles pour :

• Standardiser le déploiement d’applications communes (par exemple, une base de données, un serveur web).
• Déployer des applications multi-composants de manière cohérente.
• Permettre aux développeurs de déployer des applications sans avoir à écrire des fichiers YAML complexes, en se contentant de remplir des paramètres prédéfinis.

Ils simplifient le déploiement d’applications complexes et favorisent la réutilisabilité et la cohérence.

4.8 Operators : Automatisation de la gestion des applications

Les Operators représentent une méthode avancée pour empaqueter, déployer et gérer des applications Kubernetes-natives, en particulier des applications stateful ou complexes.[45] Un Operator est essentiellement un logiciel, s’exécutant dans un pod sur le cluster, qui utilise l’API Kubernetes (et les Custom Resource Definitions) pour automatiser des tâches opérationnelles qui nécessiteraient autrement une intervention humaine.[45] Ils encodent la connaissance et l’expertise d’un administrateur humain pour une application spécifique.

Fonctionnement et composants clés de l’écosystème des Operators dans OpenShift :

• Custom Resource Definitions (CRDs) : Les Operators étendent l’API Kubernetes en définissant de nouveaux types d’objets personnalisés via des CRDs.[4] Par exemple, un Operator de base de données pourrait définir un CRD MongoDBCluster. Les utilisateurs interagissent alors avec ces Custom Resources (CRs) de la même manière qu’avec les objets Kubernetes natifs (via oc apply, oc get, etc.).
• Contrôleur de l’Operator : Le cœur de l’Operator est une boucle de contrôle qui surveille l’état des CRs qui lui sont associés. Lorsqu’un CR est créé ou modifié, l’Operator réagit pour s’assurer que l’état réel de l’application correspond à l’état désiré spécifié dans le CR.
• Automatisation des opérations “Day 2” : Au-delà du déploiement initial, les Operators peuvent automatiser des tâches complexes telles que les mises à jour, les sauvegardes, la restauration, la gestion des pannes, la mise à l’échelle, le rebalancement, etc..[45]
• Operator Lifecycle Manager (OLM) : OLM est un composant d’OpenShift qui gère le cycle de vie des Operators eux-mêmes. Il s’occupe de leur installation, de leurs mises à niveau, et de la gestion de leurs dépendances et des permissions RBAC nécessaires.[45]
• OperatorHub : Intégré à la console web d’OpenShift, l’OperatorHub est un catalogue où les administrateurs de cluster peuvent découvrir, sélectionner et installer des Operators certifiés par Red Hat, des partenaires, ou la communauté.[45]

OpenShift utilise lui-même de nombreux Operators pour gérer ses propres composants système, tels que le MachineConfig Operator (MCO) pour la configuration des nœuds, le DNS Operator, l’Ingress Operator, etc..[2]

Les Operators sont un pilier de l’écosystème OpenShift et Kubernetes pour la gestion d’applications complexes. Ils réduisent considérablement la charge opérationnelle et permettent d’atteindre des niveaux d’automatisation élevés. L’adoption massive des Operators, y compris pour la gestion des composants internes d’OpenShift, transforme radicalement l’administration du cluster. Elle évolue d’une gestion souvent impérative vers une gestion déclarative et automatisée, où l’administrateur définit l’état désiré et l’Operator se charge de l’atteindre et de le maintenir. Cela requiert une nouvelle compréhension des mécanismes de contrôle et des méthodes de dépannage, qui impliquent souvent d’inspecter l’état et les logs de l’Operator lui-même ainsi que les CRs qu’il gère.

En résumé, OpenShift enrichit Kubernetes avec des objets et des mécanismes qui ciblent spécifiquement le cycle de vie de l’application (build, déploiement, exposition) et l’automatisation opérationnelle. Des fonctionnalités comme les ImageStreams, BuildConfigs, DeploymentConfigs, Routes, et surtout les Operators, rendent la plateforme plus “prête à l’emploi” pour les entreprises, en simplifiant et en automatisant des tâches que les administrateurs devraient autrement gérer avec des outils externes ou des développements personnalisés.

5. Gestion du Réseau dans OpenShift

La gestion du réseau est un aspect fondamental de l’administration d’un cluster OpenShift. Elle englobe la manière dont les pods communiquent entre eux, comment les services sont découverts et exposés, et comment le trafic entrant et sortant du cluster est contrôlé et sécurisé. OpenShift s’appuie sur les concepts réseau de Kubernetes tout en y ajoutant ses propres abstractions et outils.

5.1 Software Defined Networking (SDN)

Au cœur de la communication des pods dans OpenShift se trouve une solution de Software Defined Networking (SDN). Le SDN fournit un réseau de cluster unifié et plat, permettant à chaque pod d’avoir sa propre adresse IP unique et de communiquer avec d’autres pods à travers tous les nœuds du cluster.[2]

Historiquement, OpenShift utilisait principalement **OpenShift SDN, un plugin réseau basé sur Open vSwitch (OVS) qui configure un réseau en overlay (superposition), souvent en utilisant le protocole VXLAN.[48]OpenShift SDN proposait plusieurs modes de fonctionnement pour gérer l’isolation du trafic entre les projets (namespaces) [48] :

• NetworkPolicy (mode par défaut dans les versions plus récentes comme OCP 4.12 et 4.16) : Dans ce mode, l’isolation du réseau est entièrement contrôlée par les objets NetworkPolicy de Kubernetes. Les administrateurs de projet peuvent définir des politiques granulaires pour spécifier quelles communications entrantes et sortantes sont autorisées pour leurs pods.
• Multitenant : Ce mode fournit une isolation stricte au niveau du projet. Par défaut, les pods d’un projet ne peuvent pas communiquer avec les pods et services d’un autre projet. Des exceptions peuvent être configurées pour permettre des communications inter-projets spécifiques.
• Subnet : Ce mode offre un réseau de pods complètement plat où chaque pod peut communiquer avec n’importe quel autre pod ou service dans le cluster, quel que soit son projet. Le mode NetworkPolicy offre une fonctionnalité similaire mais avec la possibilité d’ajouter des restrictions.

Cependant, une évolution majeure dans la gestion du réseau OpenShift est la transition vers OVN-Kubernetes (Open Virtual Network - Kubernetes) comme plugin CNI (Container Network Interface) par défaut et recommandé pour les nouvelles installations.[50]OVN-Kubernetes utilise OVN, une solution de virtualisation de réseau open source, pour gérer les flux de trafic. Il implémente également le support des NetworkPolicy Kubernetes et utilise le protocole Geneve pour son réseau en overlay, qui peut offrir des avantages par rapport à VXLAN dans certains scénarios.[50]

Il est important de noter que OpenShift SDN CNI est déprécié à partir d’OpenShift Container Platform (OCP) 4.14 et n’est plus une option pour les nouvelles installations à partir d’OCP 4.15.[49] La migration des clusters existants utilisant OpenShift SDN vers OVN-Kubernetes est fortement recommandée.[50] OVN-Kubernetes offre un ensemble de fonctionnalités plus riche, incluant un meilleur support pour IPv6, la possibilité de chiffrement IPsec pour les communications intra-cluster, et des logs pour les NetworkPolicies, entre autres.[49] Il v aut donc mieux se familiariser avec OVN-Kubernetes, car il représente l’avenir du SDN dans OpenShift.

5.2 Gestion du trafic interne : Services Kubernetes et DNS interne

Pour la communication à l’intérieur du cluster, deux concepts Kubernetes sont fondamentaux : les Services et le DNS.

• Services Kubernetes : Comme détaillé précédemment Section 3.2, un Service Kubernetes fournit une abstraction stable (une adresse IP virtuelle appelée ClusterIP et un nom DNS) pour accéder à un ensemble de pods fournissant une fonctionnalité commune.[15] Cela permet aux applications de se découvrir et de communiquer entre elles de manière fiable, même si les pods sous-jacents sont créés, détruits ou mis à l’échelle.
• DNS interne (CoreDNS) : OpenShift intègre un service DNS interne, généralement basé sur CoreDNS, qui est essentiel pour la découverte de services.[52] L’DNS Operator déploie et gère CoreDNS au sein du cluster. Ce service DNS est configuré pour que tous les pods du cluster l’utilisent par défaut pour la résolution de noms. Lorsqu’un Service Kubernetes est créé, une entrée DNS correspondante est automatiquement générée. Le format typique de ce nom DNS est <nom-service>.<nom-namespace>.svc.cluster.local (où cluster.local est le domaine par défaut du cluster, configurable).[21] Les pods peuvent alors utiliser ces noms DNS pour se connecter aux services, plutôt que de dépendre d’adresses IP qui peuvent changer. Le Kubelet sur chaque nœud configure le fichier /etc/resolv.conf de chaque pod pour qu’il utilise l’adresse IP du service CoreDNS du cluster.[52]

Le bon fonctionnement du DNS interne est vital pour la communication inter-applicative au sein du cluster. Les administrateurs doivent s’assurer de sa disponibilité et comprendre comment la résolution de noms s’opère.

5.3 Gestion du trafic externe : Ingress Controllers, Routes, Egress IPs, Egress Firewall

Pour gérer les communications entre le cluster OpenShift et le monde extérieur, plusieurs mécanismes sont disponibles :

• Ingress Controllers et Routes :
  • L’Ingress Operator dans OpenShift déploie et gère un ou plusieurs Ingress Controllers. Ces contrôleurs, typiquement basés sur HAProxy dans OpenShift, sont responsables de la gestion du trafic entrant (ingress) vers les services du cluster.[4]
  • Les Routes (concept spécifique à OpenShift, voir Section 4.2) sont le moyen privilégié pour exposer des services HTTP/HTTPS à l’extérieur. Elles définissent comment le trafic externe arrivant sur un nom d’hôte spécifique (et éventuellement un chemin) doit être dirigé vers un service interne. Les Routes offrent des fonctionnalités intégrées pour la terminaison TLS (Edge, Passthrough, Re-encryption) et l’équilibrage de charge.[4]
• Egress IPs : Cette fonctionnalité permet d’assigner une ou plusieurs adresses IP sources statiques et prévisibles pour le trafic sortant (egress) d’un ou plusieurs pods (généralement au niveau d’un projet/namespace) vers des destinations externes au cluster.[54] C’est particulièrement utile lorsque des systèmes externes (par exemple, des bases de données, des API tierces) ont des listes de contrôle d’accès (ACL) basées sur les adresses IP sources. La configuration se fait via l’objet NetNamespace (pour l’ancien OpenShift SDN) ou, de manière plus moderne avec OVN-Kubernetes, via un Custom Resource (CR) EgressIP. L’adresse IP d’egress doit appartenir au même sous-réseau que l’interface réseau primaire du nœud qui l’héberge.[59]Pour la haute disponibilité, plusieurs adresses IP d’egress peuvent être configurées et assignées à différents nœuds éligibles.
• Egress Firewall : L’Egress Firewall permet aux administrateurs de cluster de restreindre les destinations externes que les pods sont autorisés à contacter.[54]Cela ajoute une couche de sécurité en empêchant les communications sortantes non désirées ou malveillantes. La configuration se fait via un objet EgressNetworkPolicy (pour OpenShift SDN) ou un CR EgressFirewall (pour OVN-Kubernetes) au niveau du projet. Les règles peuvent autoriser (Allow) ou refuser (Deny) le trafic vers des destinations spécifiées par des plages CIDR d’adresses IP ou des noms DNS. Des règles de port et de protocole peuvent également être appliquées.[64] Il existe des limitations, comme le fait qu’un projet ne peut avoir qu’une seule politique d’Egress Firewall, et des considérations importantes concernant la résolution DNS (les mises à jour DNS peuvent ne pas être instantanément reflétées dans les règles appliquées).[64]

Ces mécanismes de gestion du trafic externe sont cruciaux pour contrôler comment les applications au sein du cluster interagissent avec le monde extérieur et comment elles sont accessibles, ce qui est essentiel pour la sécurité et l’intégration avec d’autres systèmes.

5.4 NetworkPolicies : Sécurisation des communications pod-à-pod

Les NetworkPolicies sont des objets Kubernetes standard qui permettent de définir des règles de communication réseau au niveau des pods.[24] Elles offrent un moyen de segmenter le réseau à l’intérieur d’un projet (namespace) et de contrôler finement quel pod peut communiquer avec quel autre pod, et sur quels ports/protocoles.

Par défaut, dans de nombreuses configurations Kubernetes/OpenShift, tous les pods au sein d’un même projet peuvent communiquer librement entre eux. Les NetworkPolicies permettent de restreindre ce comportement.

• Lorsqu’un pod est ciblé par une ou plusieurs NetworkPolicies (via des sélecteurs de labels), il n’acceptera que les connexions entrantes (ingress) et/ou n’autorisera que les connexions sortantes (egress) qui sont explicitement permises par au moins une de ces politiques.[70]
• Si un pod est ciblé par une politique mais qu’aucune règle n’autorise explicitement un certain trafic, ce trafic sera refusé (principe du “deny by default” une fois qu’une politique s’applique).
• Un pod qui n’est sélectionné par aucune NetworkPolicy reste généralement accessible selon la politique par défaut du namespace (souvent, tout autoriser au sein du namespace).

Les NetworkPolicies sont additives : si plusieurs politiques s’appliquent à un pod, le trafic est autorisé s’il correspond aux règles d’au moins une de ces politiques.[70] Des exemples courants de NetworkPolicies incluent :

• Isoler complètement un pod (déni de tout trafic entrant et sortant).
• Autoriser le trafic entrant uniquement depuis certains pods (par exemple, unbackend autorisant uniquement le frontend).
• Autoriser le trafic sortant uniquement vers des services spécifiques (par exemple, une base de données).
• Autoriser le trafic entrant uniquement depuis l’Ingress Controller d’OpenShift.[70]

Les NetworkPolicies sont un outil de sécurité réseau essentiel pour implémenter le principe du moindre privilège au niveau des communications des pods et pour créer des micro-segmentations au sein du cluster. Avec OpenShift SDN, des optimisations existent, comme l’utilisation de namespaceSelector dans les politiques pour cibler des projets entiers, ce qui peut être plus efficace en termes de nombre de règles OpenFlow générées.[70]

5.5 OpenShift Service Mesh

Pour les architectures basées sur les microservices, OpenShift propose OpenShift Service Mesh, qui est basé sur le projet open source Istio.[4] Un service mesh fournit une couche d’infrastructure dédiée pour rendre la communication service-à-service sécurisée, rapide et fiable.

OpenShift Service Mesh offre des fonctionnalités avancées pour [4] :

• Gestion du trafic : Routage avancé (par exemple, canary deployments, A/B testing, routage basé sur les en-têtes), équilibrage de charge sophistiqué, gestion des timeouts et des nouvelles tentatives.
• Sécurité : Authentification mutuelle TLS (mTLS) entre les services, politiques d’autorisation fines, gestion des identités de service.
• Observabilité : Collecte de métriques détaillées sur le trafic (latence, taux d’erreur, débit), traçage distribué, visualisation de la topologie des services.

Ces fonctionnalités sont injectées de manière transparente dans les pods applicatifs via des proxys sidecar (généralement Envoy) qui interceptent tout le trafic réseau entrant et sortant des pods. La configuration du service mesh se fait via des Custom Resources spécifiques à Istio/Service Mesh, comme les Gateways (pour gérer le trafic entrant et sortant du maillage) et les VirtualServices (pour définir les règles de routage).[73]

L’utilisation d’un Service Mesh comme celui proposé par OpenShift est particulièrement pertinente pour les applications complexes composées de nombreux microservices, où la gestion manuelle des communications, de la sécurité et de l’observabilité deviendrait prohibitive.

La gestion du réseau dans OpenShift est donc une combinaison de concepts Kubernetes standard et de fonctionnalités spécifiques à OpenShift, toutes visant à simplifier et sécuriser les communications. La transition d’OpenShift SDN vers OVN-Kubernetes est une évolution notable que les administrateurs doivent intégrer dans leur planification et leur expertise, car OVN-Kubernetes offre des capacités plus étendues mais peut introduire des nuances dans la configuration et le dépannage. La sécurité réseau est une préoccupation transversale, adressée à plusieurs niveaux : isolation au niveau du projet, contrôle fin du trafic pod-à-pod avec les NetworkPolicies, gestion du trafic externe avec les Routes et les Egress Firewalls/IPs, et capacités avancées via le Service Mesh. Une stratégie de sécurité réseau robuste doit considérer l’articulation de tous ces éléments pour une défense en profondeur.

Le tableau suivant compare les plugins CNI OpenShift SDN et OVN-Kubernetes :

6. Gestion du Stockage Persistant

Pour les applications qui nécessitent de conserver des données au-delà du cycle de vie d’un pod individuel (applications “stateful”), OpenShift fournit des mécanismes robustes de gestion du stockage persistant. Ces mécanismes s’appuient largement sur les concepts de PersistentVolumes (PV), PersistentVolumeClaims (PVC) et StorageClasses de Kubernetes, tout en s’intégrant avec une variété de solutions de stockage backend.

6.1 PersistentVolumes (PVs) et PersistentVolumeClaims (PVCs) : Concepts et cycle de vie

Au cœur de la gestion du stockage persistant dans Kubernetes et OpenShift se trouvent deux objets API principaux :

• PersistentVolume (PV) : Un PV représente un “morceau” de stockage physique ou réseau qui a été mis à disposition du cluster.[74] Il s’agit d’une ressource du cluster, au même titre qu’un nœud. Un PV est une abstraction de l’implémentation réelle du stockage, qui peut être du NFS, de l’iSCSI, un volume EBS d’AWS, un disque Azure, etc..[74] Les PVs sont provisionnés soit manuellement par un administrateur (provisionnement statique), soit automatiquement par le système en réponse à une demande (provisionnement dynamique via les StorageClasses). Un PV a un cycle de vie indépendant de tout pod qui l’utilise.
• PersistentVolumeClaim (PVC) : Un PVC est une demande de stockage formulée par un utilisateur ou une application au sein d’un projet (namespace).[74]De la même manière qu’un pod consomme des ressources de nœud (CPU, mémoire), un PVC consomme des ressources PV. Un PVC spécifie la quantité de stockage requise et les modes d’accès souhaités (par exemple, ReadWriteOnce, ReadOnlyMany, ReadWriteMany).

Le cycle de vie d’un volume et d’une demande de volume se déroule typiquement comme suit [74] :

1. Provisionnement :
   • Statique : L’administrateur crée manuellement un certain nombre de PVs qui représentent le stockage existant. Ces PVs sont disponibles pour être réclamés.
   • Dynamique : Si aucun PV statique ne correspond à un PVC, et si le PVC spécifie une StorageClass configurée pour le provisionnement dynamique, le cluster peut tenter de provisionner automatiquement un PV adapté.
2. Liaison (Binding) : Lorsqu’un PVC est créé, le control plane de Kubernetes/OpenShift recherche un PV disponible qui satisfait les exigences du PVC (taille, modes d’accès, StorageClass). Si un PV correspondant est trouvé (ou dynamiquement provisionné), il est lié (bound) au PVC. Cette liaison est généralement exclusive.
3. Utilisation : Une fois qu’un PVC est lié à un PV, il peut être monté comme un volume à l’intérieur d’un ou plusieurs pods (selon les modes d’accès). L’application dans le pod peut alors lire et écrire des données sur ce volume persistant.
4. Protection de l’objet de stockage en cours d’utilisation : Des mécanismes de protection empêchent la suppression accidentelle d’un PVC activement utilisé par un pod, ou d’un PV lié à un PVC.
5. Libération (Releasing) : Lorsque l’utilisateur n’a plus besoin du volume, il supprime l’objet PVC. Cette action libère le PV, qui n’est plus lié à ce PVC.
6. Récupération (Reclaiming) : Ce qui advient du PV (et des données qu’il contient) après sa libération dépend de sa politique de récupération (reclaim policy). Les politiques courantes sont :
   • Retain : Le PV et ses données sont conservés. L’administrateur doit manuellement nettoyer les données et supprimer le PV s’il n’est plus nécessaire. C’est souvent la politique par défaut pour les PVs provisionnés manuellement.
   • Delete : Le PV et le stockage sous-jacent (par exemple, le volume EBS sur AWS) sont supprimés. C’est souvent la politique par défaut pour les PVs provisionnés dynamiquement.
   • Recycle : (Obsolète et non recommandé) Tente d’effacer les données du volume pour le rendre réutilisable.

Comprendre ce cycle de vie est fondamental pour les administrateurs afin de gérer correctement les ressources de stockage, d’assurer la persistance des données pour les applications stateful, et de mettre en œuvre des stratégies de nettoyage et de récupération des ressources.

6.2 StorageClasses et Provisionnement Dynamique

Le provisionnement dynamique des volumes persistants est une fonctionnalité clé qui simplifie considérablement la gestion du stockage dans OpenShift. Au lieu que les administrateurs aient à pré-provisionner manuellement chaque PV, le système peut créer des PVs à la demande lorsqu’un PVC est soumis.[74]Ce mécanisme repose sur l’objet StorageClass.[78]

Une StorageClass permet aux administrateurs de définir différentes “classes” ou “profils” de stockage qu’ils offrent. Chaque StorageClass est associée à un provisionneur (provisioner) spécifique qui sait comment interagir avec un type de stockage backend particulier (par exemple, AWS EBS, Azure Disk, NFS, ODF). La StorageClass peut également contenir des paramètres spécifiques au provisionneur (par exemple, le type de disque, la zone de disponibilité, les options de chiffrement).[80]

Lorsqu’un utilisateur crée un PVC, il peut spécifier le nom d’une StorageClass. Si cette StorageClass est configurée pour le provisionnement dynamique, le provisionneur associé créera automatiquement un nouveau PV qui correspond aux exigences du PVC (taille, modes d’accès) et le liera au PVC. Si un PVC ne spécifie pas de StorageClass, il utilisera la StorageClass marquée comme par défaut pour le cluster, si une telle classe existe.[80]

OpenShift supporte une large gamme de provisionneurs pour différents types de stockage, y compris ceux des principaux fournisseurs de cloud public (AWS EBS, Azure Disk, GCE Persistent Disk), des solutions sur site (vSphere, OpenStack Cinder), et des solutions software-defined comme OpenShift Data Foundation.[80] La tendance est à l’utilisation de pilotes CSI (Container Storage Interface), qui permettent aux fournisseurs de stockage de développer et de maintenir leurs propres pilotes de manière indépendante du cycle de vie de Kubernetes/OpenShift.[79]

Le provisionnement dynamique, grâce aux StorageClasses, réduit la charge de travail des administrateurs, accélère la mise à disposition du stockage pour les développeurs, et permet une gestion plus flexible et automatisée des ressources de stockage.

6.3 Options de stockage

OpenShift offre une flexibilité considérable en matière de solutions de stockage backend pouvant être utilisées pour fournir des volumes persistants. Le choix dépendra des besoins de l’application (performance, modes d’accès, capacité), de l’infrastructure sous-jacente (cloud, sur site), et des préférences opérationnelles.

• OpenShift Data Foundation (ODF) (anciennement OpenShift Container Storage) : ODF est la solution de stockage software-defined, hyperconvergée et profondément intégrée de Red Hat pour OpenShift.[79] Basée sur la technologie Ceph, ODF est déployée et gérée via un Operator directement sur le cluster OpenShift.[79] Elle est capable de fournir les trois types de stockage :
  • Bloc (Block Storage) : via Ceph RBD, typiquement pour des bases de données ou des applications nécessitant un accès RWO (ReadWriteOnce) performant.
  • Fichier (File Storage) : via CephFS, pour des besoins de stockage partagé RWX (ReadWriteMany).
  • Objet (Object Storage) : via Ceph RGW (RADOS Gateway) ou NooBaa (pour la gestion de données multi-cloud), compatible S3, pour le stockage de données non structurées.[79] ODF offre des fonctionnalités d’entreprise telles que le provisionnement dynamique, la réplication des données pour la haute disponibilité, le chiffrement, les snapshots, et la scalabilité.[[86 Son intégration étroite avec OpenShift simplifie la gestion du stockage pour les administrateurs de la plateforme. Cependant, ODF est lui-même un système de stockage distribué complexe qui nécessite une compréhension de son architecture et de son fonctionnement pour une administration efficace.
• NFS (Network File System) : NFS est une solution de stockage de fichiers en réseau largement répandue et souvent utilisée avec OpenShift pour fournir un accès RWX (ReadWriteMany) aux volumes persistants.[88] Cela signifie que plusieurs pods, potentiellement sur différents nœuds, peuvent lire et écrire simultanément sur le même volume NFS. La configuration de PVs NFS est généralement statique (l’administrateur crée le PV qui pointe vers un export NFS existant), bien que des provisionneurs dynamiques CSI pour NFS existent et puissent être déployés séparément.[91] Bien que simple à mettre en œuvre, NFS peut présenter des limitations en termes de performance et de scalabilité par rapport à des solutions de stockage bloc dédiées ou à ODF, en particulier pour des charges de travail intensives en I/O.[88]
• iSCSI : iSCSI est un protocole de stockage en réseau qui fournit un accès en mode bloc aux volumes. Dans OpenShift, les volumes iSCSI sont typiquement utilisés avec un mode d’accès RWO (ReadWriteOnce), ce qui signifie qu’ils ne peuvent être montés en lecture-écriture que par un seul nœud à la fois.[88] L’utilisation d’iSCSI nécessite que l’initiateur iSCSI (logiciel client) soit installé et configuré sur tous les nœuds OpenShift susceptibles d’accéder aux volumes iSCSI.[92] iSCSI peut offrir de bonnes performances pour des applications comme les bases de données qui bénéficient d’un accès bloc dédié.
• Intégration avec les stockages Cloud (AWS EBS, Azure Disk, Google Persistent Disk, etc.) : Lorsqu’OpenShift est déployé sur une plateforme de cloud public, il peut s’intégrer nativement avec les services de stockage de blocs et de fichiers de ce fournisseur. Cette intégration se fait de plus en plus via des pilotes CSI (Container Storage Interface) spécifiques au fournisseur, qui permettent le provisionnement dynamique et la gestion des volumes cloud directement depuis OpenShift.[80]
  • AWS Elastic Block Store (EBS) : Permet de provisionner dynamiquement des volumes EBS. Des StorageClasses peuvent être définies pour différents types de volumes EBS (gp2, io1, etc.) et des options comme le chiffrement.[84]
  • Azure Disk : Permet de provisionner dynamiquement des disques managés Azure. Des StorageClasses peuvent spécifier le type de compte de stockage (Standard_LRS, Premium_LRS, etc.).[95]
  • Azure File : Permet d’utiliser Azure Files (stockage de fichiers SMB/NFS) pour un accès RWX.[100]
  • Google Cloud Persistent Disk (GCP PD) : Permet de provisionner dynamiquement des disques persistants GCP. Des StorageClasses peuvent définir le type de disque (standard, ssd, regional).[96]Cette intégration est essentielle pour tirer parti des capacités de stockage managées, performantes et souvent résilientes des fournisseurs de cloud.

6.4 Cas d’usage du stockage : Fichier, Bloc, Objet pour applications stateful

Le choix du type de stockage persistant dépend fortement des besoins de l’application stateful :

• Stockage Fichier (File Storage) :
  • Cas d’usage : Partage de contenu entre plusieurs pods (par exemple, un site web servi par plusieurs serveurs web), systèmes de gestion de contenu (CMS), outils de développement collaboratif, répertoires partagés pour des logs ou des configurations. Souvent utilisé lorsque le mode d’accès ReadWriteMany (RWX) est requis.
  • Exemples de technologies : NFS, OpenShift Data Foundation (via CephFS), Azure Files, AWS EFS, Google Cloud Filestore.[79]
• Stockage Bloc (Block Storage) :
  • Cas d’usage : Bases de données relationnelles (MySQL, PostgreSQL, SQL Server) et NoSQL (MongoDB, Cassandra, si configurées pour un accès RWO par instance), files d’attente de messages (Kafka, RabbitMQ), applications nécessitant des I/O disques rapides, à faible latence, et un accès exclusif au volume (mode ReadWriteOnce - RWO).
  • Exemples de technologies : iSCSI, Fibre Channel, AWS EBS, Azure Disk, Google Persistent Disk, OpenShift Data Foundation (via Ceph RBD).[79]
• Stockage Objet (Object Storage) :
  • Cas d’usage : Stockage de grandes quantités de données non structurées comme des images, des vidéos, des sauvegardes, des archives, des jeux de données pour le big data ou l’IA/ML. Souvent accédé via une API HTTP (compatible S3 ou Swift). Idéal pour les applications cloud-natives conçues pour interagir avec ce type de stockage.
  • Exemples de technologies : OpenShift Data Foundation (via Ceph RGW ou NooBaa), AWS S3, Azure Blob Storage, Google Cloud Storage, MinIO.[79]

OpenShift, grâce à son architecture de stockage flexible basée sur les PVs, PVCs et StorageClasses, offre une abstraction robuste par-dessus une multitude de technologies de stockage. Cela permet aux développeurs de consommer du stockage de manière standardisée, tout en donnant aux administrateurs la latitude de choisir les backends les plus adaptés. La transition vers les pilotes CSI (Container Storage Interface) est une tendance de fond, déportant la logique de provisionnement vers des pilotes maintenus par les fournisseurs de stockage eux-mêmes, ce qui favorise l’innovation et la maintenabilité.[79]Néanmoins, malgré la simplification apportée par OpenShift, la complexité inhérente à la gestion du stockage sous-jacent (performance, capacité, sauvegarde, reprise après sinistre, sécurité des données) demeure une responsabilité majeure de l’administrateur. Des solutions intégrées comme ODF peuvent aider à centraliser cette gestion au sein d’OpenShift, mais ODF est lui-même un système distribué qui requiert sa propre expertise d’administration.[86]Le choix judicieux des modes d’accès (RWO, RWX) et des politiques de récupération des volumes a des implications directes et critiques sur la manière dont les applications peuvent utiliser le stockage et sur la pérennité des données.

Le tableau suivant résume les options de stockage persistant courantes dans OpenShift :

7. Gestion des Identités et des Accès (IAM)

La gestion des identités et des accès (Identity and Access Management - IAM) est un pilier de la sécurité et de la gouvernance d’un cluster OpenShift. Elle détermine qui peut accéder au cluster, quelles actions ils sont autorisés à effectuer, et sur quelles ressources. OpenShift offre un système IAM robuste qui combine l’intégration avec des fournisseurs d’identité d’entreprise et un modèle de contrôle d’accès basé sur les rôles (RBAC) hérité de Kubernetes.

7.1 Fournisseurs d’identité (Identity Providers - IdP)

OpenShift ne gère pas directement les mots de passe des utilisateurs. Au lieu de cela, il s’appuie sur des fournisseurs d’identité (IdP) configurés pour authentifier les utilisateurs.[111] Lorsqu’un utilisateur tente de se connecter à OpenShift (via la console web ou la CLI oc), il est généralement redirigé vers l’IdP configuré pour vérifier ses informations d’identification.

Le serveur OAuth interne d’OpenShift joue un rôle central dans ce processus.[111] Une fois que l’IdP a authentifié l’utilisateur avec succès, il renvoie une information d’identité au serveur OAuth d’OpenShift. Ce dernier mappe alors cette identité externe à un utilisateur OpenShift, crée un token d’accès OAuth, et le retourne à l’utilisateur. Ce token sera ensuite utilisé pour authentifier toutes les requêtes ultérieures de l’utilisateur à l’API OpenShift.

OpenShift supporte une variété de fournisseurs d’identité, permettant une intégration aisée avec les systèmes d’authentification existants d’une entreprise. Parmi les plus courants :

• LDAP / Active Directory : OpenShift peut être configuré pour valider les informations d’identification des utilisateurs directement auprès d’un serveur LDAPv3 ou d’un annuaire Active Directory.[115] La configuration implique généralement la création d’un objet Secret dans OpenShift pour stocker de manière sécurisée le mot de passe du compte de liaison (bind DN/password) utilisé pour interroger l’annuaire LDAP, ainsi que la configuration d’un Custom Resource (CR) OAuth qui décrit les détails de la connexion LDAP (URL du serveur, base DN pour la recherche des utilisateurs, attributs à mapper pour le nom d’utilisateur, l’email, etc.).[115]
• OpenID Connect (OIDC) : C’est un protocole d’authentification standard basé sur OAuth 2.0. De nombreux fournisseurs d’identité modernes (comme *Keycloak, Okta, Auth0, Azure AD, Google) supportent OIDC, ce qui en fait une option d’intégration populaire et flexible.
• Autres : D’autres IdPs comme GitHub, GitLab, ou des solutions basées sur des fichiers htpasswd (principalement pour des environnements de test ou de petite taille) peuvent également être configurés.

L’intégration avec un IdP d’entreprise est cruciale car elle permet une gestion centralisée des identités, l’application des politiques de mot de passe de l’entreprise, et une expérience utilisateur simplifiée (single sign-on).

7.2 Gestion des utilisateurs et des groupes (CLI et console web)

Une fois authentifiés via un IdP, les acteurs interagissant avec OpenShift sont représentés par des objets User et Group.

• Utilisateurs (Users) : Un objet User dans OpenShift représente une entité (généralement une personne, mais aussi un système) qui peut effectuer des requêtes à l’API OpenShift.[111] Il existe plusieurs types d’utilisateurs :
  • Utilisateurs réguliers : Ce sont typiquement les développeurs, les administrateurs, ou d’autres utilisateurs humains. Ils sont souvent créés automatiquement dans OpenShift lors de leur première connexion réussie via un IdP configuré, ou peuvent être créés manuellement via l’API.
  • Utilisateurs système : Ce sont des utilisateurs spéciaux créés automatiquement par OpenShift pour permettre aux composants d’infrastructure d’interagir de manière sécurisée avec l’API. Des exemples incluent system:admin (le super-utilisateur initial, dont l’usage doit être limité après la configuration initiale), system:openshift-registry (pour le registre interne), ou system:node:<nom_du_noeud> (pour les kubelets). L’utilisateur système anonymous est utilisé pour les requêtes non authentifiées.[111]
  • Comptes de service (ServiceAccounts) : Ce sont un type spécial d’utilisateur système non humain, associés à un projet (namespace). Ils sont utilisés par les pods et les applications s’exécutant dans le cluster pour interagir avec l’API Server. Chaque projet a des comptes de service par défaut (par exemple, default, builder, deployer), et des comptes de service personnalisés peuvent être créés pour accorder des permissions spécifiques aux applications.[111] La gestion sécurisée des comptes de service est aussi critique que celle des utilisateurs humains, car des permissions excessives accordées à un compte de service peuvent être exploitées si une application utilisant ce compte est compromise.
• Groupes (Groups) : Un objet Group représente un ensemble d’utilisateurs.[111] L’utilisation de groupes simplifie considérablement la gestion des autorisations, car les permissions (via RBAC) peuvent être accordées à un groupe entier plutôt qu’à chaque utilisateur individuellement. Les groupes peuvent être synchronisés depuis un IdP externe (comme des groupes LDAP) ou gérés directement dans OpenShift. OpenShift définit également des groupes virtuels système qui sont automatiquement provisionnés et auxquels les utilisateurs sont ajoutés en fonction de leur statut d’authentification [111] :
  • system:authenticated : Inclut tous les utilisateurs authentifiés.
  • system:authenticated:oauth : Inclut tous les utilisateurs authentifiés via un token OAuth.
  • system:unauthenticated : Inclut tous les utilisateurs non authentifiés.

La gestion des utilisateurs et des groupes (par exemple, l’ajout d’un utilisateur à un groupe) peut s’effectuer via la console web d’OpenShift ou en utilisant la CLI oc (par exemple,oc adm groups add-users <nom_groupe> <utilisateur1> <utilisateur2>).[118] Une gestion rigoureuse des comptes utilisateurs et de leur appartenance aux groupes est essentielle pour maintenir la sécurité et l’organisation du cluster.

7.3 Contrôle d’accès basé sur les rôles (RBAC) : ClusterRoles, Roles, RoleBindings, ClusterRoleBindings

Une fois qu’un utilisateur est authentifié, le système de contrôle d’accès basé sur les rôles (RBAC) détermine ce que cet utilisateur est autorisé à faire.[111] RBAC est le mécanisme standard de Kubernetes, et donc d’OpenShift, pour gérer les autorisations. Il repose sur quatre types d’objets principaux :

• Role (Rôle local) : Un Role est un ensemble de permissions définies au sein d’un projet (namespace) spécifique. Une permission est une combinaison d’un verbe (une action comme get, list, watch, create, update, patch, delete) et d’une ressource (un type d’objet API comme pods, services, routes). Par exemple, un Role pourrait accorder la permission de get et list les pods dans un projet donné.[124]
• ClusterRole (Rôle de cluster) : Un ClusterRole est similaire à un Role, mais ses permissions s’appliquent à l’échelle de l’ensemble du cluster. Les ClusterRoles peuvent définir des permissions sur des ressources de cluster (comme les nodes, les persistentvolumes, ou les clusterroles eux-mêmes) ou sur des ressources namespacées à travers tous les namespaces (par exemple, la permission de get les pods dans n’importe quel projet). OpenShift fournit un ensemble de ClusterRoles par défaut, tels que cluster-admin (super-utilisateur), admin (administrateur d’un projet), edit (peut modifier la plupart des objets dans un projet), view (peut voir la plupart des objets dans un projet).[125]
• RoleBinding (Liaison de rôle locale) : Un RoleBinding accorde les permissions définies dans un Role (ou un ClusterRole utilisé localement) à un ensemble de sujets (utilisateurs, groupes, ou comptes de service) au sein d’un projet spécifique.[124]
• ClusterRoleBinding (Liaison de rôle de cluster) : Un ClusterRoleBinding accorde les permissions définies dans un ClusterRole à un ensemble de sujets à l’échelle de tout le cluster.[123]

Les permissions dans RBAC sont additives. Un utilisateur reçoit l’union de toutes les permissions qui lui sont accordées par tous les rôles (locaux ou de cluster) auxquels il est lié directement ou via son appartenance à des groupes.

La commande oc adm policy (par exemple, oc adm policy add-role-to-user <role> <user> -n <project>) ou la manipulation directe des objets YAML RoleBinding et ClusterRoleBinding sont utilisées pour gérer ces liaisons.[124]

Une configuration RBAC correcte, appliquant rigoureusement le principe du moindre privilège (accorder uniquement les permissions strictement nécessaires pour accomplir une tâche), est absolument cruciale pour la sécurité d’un cluster OpenShift. Une mauvaise configuration RBAC, notamment l’attribution excessive de privilèges (comme l’utilisation généralisée du rôle cluster-admin), est l’une des plus grandes menaces pour la sécurité, car la compromission d’un compte avec des privilèges étendus peut compromettre l’ensemble du cluster.[126]

7.4 Configuration avancée du serveur OAuth interne

Le serveur OAuth interne d’OpenShift offre plusieurs options de configuration pour affiner son comportement en fonction des politiques de sécurité et des besoins de l’expérience utilisateur de l’entreprise [112] :

• Durée des tokens d’accès : Le paramètre accessTokenMaxAgeSeconds dans la configuration OAuth du cluster permet de contrôler la durée de validité des tokens d’accès. La valeur par défaut est généralement de 24 heures (86400 secondes). Cette durée peut être augmentée ou diminuée.
• Timeout d’inactivité des tokens : Le paramètre accessTokenInactivityTimeout peut être configuré pour que les tokens d’accès expirent après une certaine période d’inactivité. La valeur minimale autorisée est de 300 secondes. Si un client OAuth a également une configuration de timeout d’inactivité, celle du client peut prévaloir.
• Méthodes d’octroi (Grant Methods) : Lorsqu’un client OAuth demande un token pour un utilisateur qui n’a pas encore accordé de permission à ce client, la stratégie d’octroi du client OAuth détermine l’action. OpenShift permet de configurer des méthodes par défaut comme auto (approuver automatiquement la demande) ou prompt (demander à l’utilisateur d’approuver ou de refuser).
• Personnalisation de l’URL du serveur OAuth : L’URL externe du serveur OAuth interne peut être personnalisée en modifiant la configuration Ingress du cluster, spécifiquement pour le composant oauth-openshift. Cela peut impliquer la fourniture d’un certificat TLS personnalisé si le nom d’hôte personnalisé ne correspond pas au suffixe de domaine du cluster.

Ces options de configuration avancées permettent aux administrateurs d’aligner le comportement du serveur OAuth sur les exigences spécifiques de leur organisation.

8. Surveillance (Monitoring) et Journalisation (Logging)

La surveillance et la journalisation sont des fonctions critiques pour l’administration, l’exploitation et le dépannage d’un cluster Red Hat OpenShift. La plateforme intègre des solutions robustes pour collecter des métriques, déclencher des alertes et agréger les logs de tous les composants du cluster et des applications qui y sont hébergées.

8.1 Architecture de surveillance : Prometheus, Grafana, Alertmanager

OpenShift Container Platform est livré avec une pile de surveillance complète, préconfigurée, préinstallée et auto-actualisée, qui est basée sur Prometheus, un projet open source de premier plan dans l’écosystème cloud-natif, et ses composants associés.[128]

Les principaux composants de cette architecture de surveillance sont :

• Cluster Monitoring Operator (CMO) : C’est l’opérateur central qui déploie, configure, gère et met à jour automatiquement tous les autres composants de la pile de surveillance principale, y compris les instances Prometheus, Alertmanager, Thanos Querier, et Telemeter Client.[130]
• Prometheus Operator (PO) : Déployé par le CMO dans le namespace openshift-monitoring (pour la surveillance de la plateforme) et potentiellement dans openshift-user-workload-monitoring (si la surveillance des projets utilisateur est activée). Le Prometheus Operator est responsable de la création, de la configuration et de la gestion des instances de Prometheus et d’Alertmanager. Il génère automatiquement les configurations de cibles de scraping pour Prometheus en se basant sur des sélecteurs de labels Kubernetes.[130]
• Prometheus : Le cœur du système de surveillance. Prometheus est une base de données de séries temporelles (TSDB) qui collecte (scrape) activement les métriques exposées par divers points de terminaison (/metrics) des composants du cluster et des applications. Il stocke ces métriques et dispose d’un puissant langage de requête (PromQL) pour les analyser. Prometheus évalue également des règles d’alerte définies et, si des conditions d’alerte sont remplies, envoie ces alertes à Alertmanager.[128]
• Alertmanager : Reçoit les alertes de Prometheus. Il est responsable de la déduplication, du regroupement, du silençage et du routage de ces alertes vers divers mécanismes de notification externes (email, PagerDuty, Slack, webhooks, etc.).[130]
• Grafana : Bien que le document 130 ne le liste pas explicitement comme un composant central déployé par défaut dans les versions les plus récentes (car la console OpenShift intègre de plus en plus de fonctionnalités de visualisation), Grafana est traditionnellement l’outil de visualisation privilégié pour créer des tableaux de bord dynamiques et interactifs à partir des métriques stockées dans Prometheus.[128] OpenShift fournit souvent des tableaux de bord Grafana préconfigurés pour la surveillance du cluster.
• Thanos Querier : Ce composant permet d’agréger les métriques provenant de multiples instances Prometheus (par exemple, celle de la plateforme et celle des projets utilisateur) et, optionnellement, de dédupliquer les métriques si des configurations Prometheus redondantes sont en place. Il fournit une interface de requête unique et multi-tenant sur l’ensemble des métriques.[130]

Par défaut, cette pile de surveillance collecte les métriques des composants essentiels de la plateforme OpenShift (CoreDNS, etcd, API servers, kubelets, etc.). Il est également possible d’activer la surveillance pour les projets définis par l’utilisateur, ce qui déploie une instance séparée de Prometheus et de Thanos Ruler dans le namespace openshift-user-workload-monitoring pour collecter les métriques des applications des utilisateurs.[130]

Une surveillance complète et bien configurée est essentielle pour comprendre l’état de santé du cluster, diagnostiquer proactivement les problèmes, planifier la capacité future et assurer des performances optimales.

8.2 Collecte et consultation des métriques

La collecte des métriques dans OpenShift est principalement effectuée par Prometheus, qui “scrape” (récupère périodiquement) les données depuis des points de terminaison HTTP (/metrics) exposés par les différents composants du cluster et les applications.[130] Ces points de terminaison fournissent des métriques au format textuel de Prometheus.

Les métriques collectées peuvent être consultées et interrogées de plusieurs manières :

• Console Web d’OpenShift :
  • La perspective Administrator offre un accès à de nombreux tableaux de bord préconfigurés qui visualisent l’état et les performances des composants principaux du cluster, tels que les performances de l’API, l’état d’etcd, l’utilisation des ressources de calcul (CPU, mémoire) et du réseau, les performances de Prometheus lui-même, des tableaux de bord basés sur la méthodologie USE (Utilization, Saturation, Errors), et les performances des nœuds.[130]
  • La perspective Developer permet aux développeurs d’accéder à des tableaux de bord visualisant l’utilisation des ressources Kubernetes pour les projets auxquels ils ont accès.[130]
  • La console web inclut également une interface utilisateur pour les Alertes (Alerting UI) qui permet de visualiser les alertes actives, de gérer les silences (pour supprimer temporairement des notifications d’alerte) et de consulter les règles d’alerte configurées.[130]
  • L’onglet Metrics dans la section Observe de la console permet d’exécuter directement des requêtes en utilisant le langage PromQL (Prometheus Query Language). Les administrateurs peuvent interroger les métriques de tous les projets, tandis que les développeurs peuvent interroger les métriques des projets utilisateur. L’interface propose souvent des requêtes prédéfinies et la possibilité de construire des requêtes personnalisées pour une analyse approfondie.[130]
• Interface en Ligne de Commande (CLI) :
  • Il est possible d’accéder aux API web des différents composants de la pile de surveillance (Prometheus, Alertmanager, Thanos Ruler, Thanos Querier) en utilisant des outils CLI comme curl, après s’être authentifié avec un token porteur (bearer token).[130]
  • Les métriques peuvent être interrogées directement depuis le point de terminaison de fédération de Prometheus en utilisant la CLI.

Savoir où et comment accéder aux métriques, et comment les interpréter à l’aide de PromQL, sont des compétences cruciales pour tout administrateur OpenShift souhaitant effectuer des tâches de surveillance proactive, de dépannage et d’optimisation des performances.

8.3 Journalisation centralisée : Architecture et Composants

La journalisation centralisée (centralized logging) dans OpenShift permet d’agréger les logs provenant de diverses sources à travers le cluster – y compris les logs système des nœuds, les logs d’audit, les logs des conteneurs d’application, et les logs des composants d’infrastructure – et de les stocker dans un emplacement centralisé pour analyse et conservation.[135]

L’architecture de la solution de journalisation d’OpenShift a évolué. Historiquement, elle était souvent basée sur la pile EFK (Elasticsearch, Fluentd, Kibana).[135] Cependant, les documentations plus récentes, notamment pour OCP 4.[18] 138, indiquent une transition vers une architecture s’appuyant sur Loki pour le stockage des logs et Vector (ou Fluentd dans les versions antérieures) pour la collecte, avec une visualisation via l’OpenShift Observability UI.

Les composants principaux de la solution de journalisation actuelle ou récente sont :

• Collector (Collecteur de logs) : Ce composant est déployé sur chaque nœud du cluster (généralement sous forme de DaemonSet). Sa tâche est de collecter les logs des conteneurs s’exécutant sur le nœud, ainsi que les logs système du nœud lui-même. Il formate ensuite ces logs et les transfère vers le magasin de logs centralisé.
  • Vector : Mentionné dans la documentation pour OCP 6.1+ comme capable de transférer les logs OVN et Auditd, suggérant son rôle croissant comme collecteur principal.[138]
  • Fluentd : Était le collecteur traditionnellement utilisé dans la pile EFK d’OpenShift.[135] Il est possible qu’il soit encore utilisé ou supporté dans certaines configurations.
• Log Store (Magasin de logs) : C’est le système backend où les logs agrégés sont stockés et indexés pour permettre des recherches et des analyses.
  • Loki : C’est le système de stockage de logs principal dans les architectures de journalisation plus récentes d’OpenShift.[138] Loki est un système d’agrégation de logs multi-tenant, horizontalement scalable et hautement disponible, inspiré par Prometheus. Une différence clé avec des systèmes comme Elasticsearch est que Loki indexe principalement les métadonnées (labels) associées aux flux de logs, plutôt que le contenu textuel complet des logs, ce qui peut le rendre plus efficace en termes de coûts de stockage et d’indexation pour certains cas d’usage. La configuration Loki fournie par OpenShift Logging est optimisée pour un stockage à court terme, facilitant les requêtes récentes et le dépannage rapide. Pour une conservation à long terme, il est conseillé d’utiliser des magasins de logs externes.[138]
  • Elasticsearch (ES) : Était le magasin de logs par défaut dans l’ancienne pile EFK.[135] C’est un moteur de recherche et d’analyse distribué très puissant, mais qui peut être plus gourmand en ressources.
• Visualization (Interface de visualisation) : C’est l’interface utilisateur qui permet aux administrateurs et aux développeurs de rechercher, de visualiser et d’analyser les logs stockés.
  • OpenShift Observability UI : Avec l’utilisation de Loki, c’est l’outil principal pour la visualisation et l’interrogation des logs. Le plugin Logging UI du Cluster Observability Operator active la section “Log” dans l’onglet “Observe” de la console OpenShift.[138]
  • Kibana : Était l’outil de visualisation utilisé avec Elasticsearch dans la pile EFK.[135]

La gestion de la journalisation dans OpenShift est orchestrée par le Red Hat OpenShift Logging Operator et, si Loki est utilisé, par le Loki Operator.[138] La configuration de la collecte et du transfert des logs se fait principalement via deux Custom Resources (CRs) : ClusterLogging (pour définir l’instance de la pile de journalisation) et ClusterLogForwarder (pour spécifier comment et où les logs doivent être collectés et transférés).[135]

La journalisation centralisée est indispensable pour le débogage des applications, l’audit de sécurité, la surveillance de la conformité et la compréhension du comportement global du cluster et de ses charges de travail.

8.4 Gestion et interrogation des logs

La configuration de la collecte des logs est définie via le CR ClusterLogForwarder (CLF).[138] Ce CR utilise des inputs pour spécifier les différentes sources de logs à collecter. OpenShift Logging fournit des types d’input intégrés 138 :

• application : Sélectionne les logs de tous les conteneurs d’application, en excluant par défaut les namespaces d’infrastructure. Des filtres peuvent être appliqués pour inclure/exclure des namespaces spécifiques, des noms de conteneurs, ou se baser sur des labels.
• infrastructure : Sélectionne les logs des nœuds et des composants d’infrastructure s’exécutant dans des namespaces spécifiques (comme default, kube-*, openshift-*). Peut être filtré par source (nœud ou conteneur).
• audit : Sélectionne les logs d’audit provenant de l’API server OpenShift, de l’API server Kubernetes, les logs d’audit OVN, et les logs d’audit des nœuds (provenant d’auditd). Peut être filtré par source d’audit. Un filtre d’audit API permet un contrôle plus fin des événements d’audit collectés.

Pour que le CLF puisse collecter ces logs, des permissions RBAC appropriées doivent être accordées au compte de service qu’il utilise, via des liaisons à des ClusterRoles comme collect-application-logs, collect-infrastructure-logs, et collect-audit-logs.[138]

Lorsque Loki est utilisé comme magasin de logs, l’interrogation des logs se fait à l’aide du langage LogQL.[138] LogQL est un langage de requête inspiré de PromQL, conçu pour interroger les logs en se basant sur leurs labels et pour effectuer des recherches textuelles dans les messages de log. L’OpenShift Observability UI fournit une interface pour construire et exécuter ces requêtes LogQL.

L’évolution de la pile de journalisation d’OpenShift, passant d’une solution EFK traditionnelle à une architecture potentiellement basée sur Loki et Vector, reflète une tendance plus large dans l’industrie. Les solutions comme Loki sont souvent perçues comme plus légères, plus rentables et mieux adaptées aux environnements Kubernetes à haute cardinalité de labels, en comparaison avec Elasticsearch qui, bien que très puissant, peut être plus complexe et coûteux à opérer à grande échelle pour la journalisation. Néanmoins, la configuration et la maintenance efficaces de ces systèmes, incluant la gestion de la rétention des données, la configuration d’alertes pertinentes basées sur les logs, et la sécurisation de l’accès à ces données sensibles, restent des tâches administratives continues et critiques. Elles vont bien au-delà du simple déploiement des opérateurs et exigent une planification et une gestion actives pour éviter la perte de données, la surcharge du système ou le “bruit” d’alertes non pertinentes.

9. Gestion du Cycle de Vie du Cluster

L’administration d’un cluster OpenShift ne se limite pas à son déploiement initial et à la gestion des applications. Elle englobe également la gestion continue de son cycle de vie, ce qui inclut les mises à jour régulières, la maintenance planifiée des nœuds, et la mise en place de stratégies robustes de sauvegarde et de restauration pour assurer la résilience et la continuité d’activité.

9.1 Mises à jour du cluster (versions mineures et patchs)

Maintenir un cluster OpenShift à jour est vital pour bénéficier des dernières fonctionnalités, des améliorations de performance, des corrections de bugs et, surtout, des correctifs de sécurité. OpenShift a un processus de mise à jour bien défini, largement automatisé par le Cluster Version Operator (CVO).[142]

Le processus de mise à jour se déroule généralement en deux phases principales 142 :

1. Déploiement de la charge utile par le CVO : Le CVO est responsable de la gestion de la version globale du cluster. Il vérifie régulièrement auprès d’un service de mise à jour (par exemple, le Red Hat OpenShift Update Service - OSUS) les mises à jour valides disponibles pour la version actuelle du cluster et le canal de mise à jour configuré. Lorsqu’une mise à jour est initiée, le CVO récupère l’image de la version cible et commence à appliquer les changements aux composants du control plane qui s’exécutent en tant que pods (comme l’API server, le controller manager, etcd, etc.).
2. Mises à jour des nœuds par le Machine Config Operator (MCO) : Une fois que les composants du control plane sont mis à jour, le MCO prend le relais pour mettre à jour les composants au niveau de l’hôte sur chaque nœud du cluster (control plane et worker). Pour chaque nœud, le MCO effectue séquentiellement les actions suivantes :
   • Cordon : Le nœud est marqué comme non planifiable pour empêcher que de nouveaux pods y soient affectés.
   • Drain : Les pods existants sur le nœud sont évacués de manière contrôlée (en respectant les PodDisruptionBudgets) et replanifiés sur d’autres nœuds disponibles.
   • Mise à jour de l’OS : Le système d’exploitation du nœud (RHCOS) est mis à jour vers la nouvelle version.
   • Redémarrage : Le nœud est redémarré pour appliquer la mise à jour de l’OS et du kernel.
   • Uncordon : Une fois le nœud redémarré et jugé sain, il est marqué comme planifiable à nouveau, et de nouveaux pods peuvent y être affectés.

Plusieurs facteurs peuvent affecter la durée d’une mise à jour de cluster 142 :

• Le temps nécessaire au MCO pour redémarrer chaque nœud.
• La valeur du paramètre MaxUnavailable configurée dans les MachineConfigPools (MCPs), qui détermine combien de nœuds dans un pool peuvent être indisponibles simultanément pendant la mise à jour (par défaut, c’est 1 pour tous les MCPs).
• La configuration des PodDisruptionBudgets (PDBs) des applications, qui peut ralentir le processus de drain si les PDBs sont stricts.
• Le nombre total de nœuds dans le cluster.
• L’état de santé général du cluster et de ses nœuds.

Les mises à jour peuvent être initiées soit via la console web d’OpenShift (dans la section Administration > Cluster Settings), soit en utilisant la CLI oc avec la commande oc adm upgrade --to=<version> ou oc adm upgrade --to-latest=true.[145]

Avant d’entreprendre une mise à jour, plusieurs prérequis doivent être remplis 145 :

• Avoir un accès administrateur au cluster.
• Disposer d’une sauvegarde etcd récente et vérifiée.
• S’assurer que tous les Opérateurs installés via l’Operator Lifecycle Manager (OLM) sont à jour dans leur canal respectif.
• Vérifier que tous les MachineConfigPools sont actifs (non en pause), sauf si une stratégie de déploiement canary est intentionnellement utilisée.
• Résoudre toutes les conditions qui rendent le cluster non actualisable (Upgradeable=False).
• Prendre connaissance des API Kubernetes dépréciées ou supprimées dans la version cible et migrer les composants affectés si nécessaire.

Comprendre le processus de mise à jour, ses implications et ses prérequis est essentiel pour minimiser les risques et assurer une transition en douceur vers les nouvelles versions d’OpenShift.

9.2 Maintenance des nœuds (cordon, drain)

Des opérations de maintenance régulières sur les nœuds du cluster (par exemple, pour des mises à jour matérielles, des remplacements de composants, ou des investigations de problèmes) sont parfois nécessaires. Pour effectuer ces opérations en minimisant l’impact sur les applications en cours d’exécution, OpenShift fournit des mécanismes pour isoler et vider les nœuds.

• Cordon (oc adm cordon <node_name>) : Cette commande marque un nœud comme non planifiable (unschedulable).[146] Une fois qu’un nœud est “cordonné”, le scheduler Kubernetes/OpenShift n’y placera plus de nouveaux pods. Cependant, les pods qui s’exécutent déjà sur ce nœud ne sont pas affectés et continuent de fonctionner. C’est généralement la première étape avant une opération de maintenance. Pour rendre un nœud à nouveau planifiable, on utilise la commande oc adm uncordon <node_name>.
• Drain (oc adm drain <node_name>) : Cette commande va plus loin que le cordon. Elle évicte de manière sécurisée tous les pods (ou un sous-ensemble spécifié par des sélecteurs) du nœud cible.[146] “De manière sécurisée” signifie que le processus de drain tente de respecter les PodDisruptionBudgets (PDBs) configurés pour les applications, et envoie des signaux de terminaison aux pods pour leur permettre de s’arrêter proprement. Les pods gérés par des contrôleurs (Deployments, StatefulSets, etc.) seront replanifiés sur d’autres nœuds disponibles du cluster. La commande oc adm drain possède plusieurs options utiles :
  • --ignore-daemonsets : Par défaut, les pods gérés par des DaemonSets ne sont pas évincés. Cette option force leur éviction.
  • --delete-local-data (ou --delete-emptydir-data selon la version) : Si les pods utilisent des volumes emptyDir qui stockent des données sur le disque local du nœud, cette option supprime ces données lors de l’éviction. À utiliser avec prudence.
  • --force : Force la suppression des pods qui ne sont pas gérés par un ReplicationController, ReplicaSet, Job, DaemonSet ou StatefulSet. Cela peut aussi forcer la suppression si le pod ne respecte pas son PDB. À utiliser avec une extrême prudence car cela peut entraîner des interruptions de service.
  • --grace-period=-1 : Peut être utilisé en conjonction avec --force pour supprimer immédiatement les pods sans attendre leur terminaison gracieuse.

Dans les versions plus récentes d’OpenShift, notamment avec OpenShift Virtualization, la maintenance des nœuds peut également être gérée via des Custom Resources NodeMaintenance. L’opérateur Node Maintenance Operator (NMO) surveille ces CRs. Lorsqu’un CR NodeMaintenance est créé pour un nœud, l’opérateur se charge de cordonner le nœud et d’évincer les pods.[150] Pour les machines virtuelles (VMs) gérées par OpenShift Virtualization, des stratégies d’éviction spécifiques peuvent être configurées (par exemple, LiveMigrate pour tenter une migration à chaud de la VM vers un autre nœud, LiveMigrateIfPossible, ou None pour simplement arrêter la VM).[150]

Des procédures de maintenance de nœuds bien planifiées et correctement exécutées sont cruciales pour minimiser l’impact sur la disponibilité des applications.

9.3 Sauvegarde et restauration

La mise en place d’une stratégie de sauvegarde et de restauration robuste est indispensable pour se prémunir contre les pertes de données, les corruptions, les erreurs humaines, ou les sinistres majeurs. Dans OpenShift, cela concerne deux domaines principaux : la configuration du cluster lui-même (stockée dans etcd) et les données des applications persistantes.

• Sauvegarde et restauration d’etcd : etcd est la base de données clé-valeur qui stocke l’état complet de tous les objets de ressources du cluster OpenShift (définitions de pods, services, secrets, configurations, etc.). Une corruption ou une perte de données etcd peut rendre le cluster inopérable. Il est donc critique de sauvegarder régulièrement etcd.[152]
  • Quand sauvegarder : Régulièrement, et impérativement avant toute opération majeure comme une mise à jour du cluster. Il est recommandé d’attendre au moins 24 heures après l’installation initiale du cluster avant la première sauvegarde, pour s’assurer que la rotation initiale des certificats est terminée et que la sauvegarde contient des certificats valides.[152] Les sauvegardes devraient être effectuées pendant les heures de faible utilisation en raison du coût en I/O de l’opération de snapshot etcd.
  • Méthodes de sauvegarde :
    • Manuelle : OpenShift fournit un script cluster-backup.sh (généralement situé dans /usr/local/bin/ sur les nœuds du control plane) qui peut être exécuté depuis un nœud du control plane. Ce script crée un snapshot de la base de données etcd (un fichier .db) et une archive (.tar.gz) contenant les ressources des pods statiques et, si le chiffrement etcd est activé, les clés de chiffrement du snapshot.[152] Ces fichiers de sauvegarde doivent être stockés dans un emplacement sécurisé, idéalement en dehors de l’environnement OpenShift.
    • Automatisée (en Technology Preview dans certaines versions) : OpenShift explore des mécanismes pour des sauvegardes etcd automatisées, potentiellement récurrentes (via un cron job), en utilisant des CRs comme EtcdBackup et Backup. Cela peut impliquer l’utilisation de PersistentVolumeClaims (PVCs) pour stocker les sauvegardes.[152]
  • Restauration d’etcd : La restauration d’etcd est une opération destructive et complexe, à n’utiliser qu’en dernier recours en cas de défaillance majeure du cluster (par exemple, perte de quorum etcd). Elle implique généralement l’arrêt des composants du control plane, la restauration du snapshot etcd sur un ou plusieurs nœuds du control plane, et le redémarrage contrôlé du cluster. Des scripts comme cluster-restore.sh sont fournis pour faciliter ce processus.[152] Il est crucial d’utiliser une sauvegarde provenant de la même version z-stream (patch) d’OpenShift que celle du cluster que l’on tente de restaurer. La restauration d’etcd ne restaure pas les données des volumes persistants des applications, ce qui peut entraîner des incohérences nécessitant une intervention manuelle. Il est fortement recommandé de tester les procédures de restauration dans un environnement de non-production.
• Sauvegarde et restauration des applications (Velero/OADP) : Pour la sauvegarde et la restauration des applications elles-mêmes (leurs définitions de ressources Kubernetes/OpenShift et, de manière cruciale, leurs données persistantes stockées dans des PVs), OpenShift s’appuie sur l’OpenShift API for Data Protection (OADP) Operator. Cet opérateur est basé sur le projet open source Velero (anciennement Heptio Ark).[155]
  • Fonctionnement : OADP/Velero permet de sauvegarder les objets API d’un projet (ou de plusieurs projets, ou de l’ensemble du cluster) ainsi que les données des volumes persistants. Les sauvegardes des objets API sont généralement stockées sous forme d’archives tar compressées, et les sauvegardes des données des PVs peuvent être réalisées soit par des snapshots au niveau du fournisseur de stockage (si le pilote CSI ou le provisionneur cloud le supporte), soit par une copie de fichiers au niveau du système de fichiers (par exemple, en utilisant Restic, un outil intégré à Velero).
  • Stockage des sauvegardes : OADP/Velero nécessite un emplacement de stockage objet compatible S3 (comme AWS S3, MinIO, Ceph RGW, Azure Blob Storage, Google Cloud Storage, ou OpenShift Data Foundation) pour stocker les archives de sauvegarde et les métadonnées.[157]
  • Configuration : L’OADP Operator doit être installé et configuré. Cela inclut la création d’un CR DataProtectionApplication (DPA) qui spécifie l’emplacement de stockage des sauvegardes (via un CR BackupStorageLocation) et, si des snapshots de volumes sont utilisés, la configuration des VolumeSnapshotLocations.
  • Création de sauvegardes : Les sauvegardes sont initiées en créant un CR Backup. Ce CR peut spécifier les namespaces à inclure ou exclure, les types de ressources, ou utiliser des sélecteurs de labels pour cibler les ressources à sauvegarder. Des sauvegardes planifiées peuvent être configurées avec un CR Schedule.
  • Restauration : Les restaurations sont effectuées en créant un CR Restore, qui référence un CR Backup existant. On peut choisir de restaurer toutes les ressources de la sauvegarde ou seulement un sous-ensemble. La restauration des PVs peut être activée ou désactivée.[155]
  • Hooks : Velero supporte des hooks de sauvegarde et de restauration, qui sont des commandes ou des scripts pouvant être exécutés à l’intérieur des conteneurs des pods avant ou après certaines phases de la sauvegarde ou de la restauration. Cela permet d’effectuer des actions spécifiques à l’application, comme vider des tampons de base de données avant un snapshot, ou réinitialiser des connexions après une restauration.[155]

La gestion du cycle de vie d’un cluster OpenShift est une responsabilité administrative continue. Elle exige une planification proactive pour les mises à jour, une exécution méthodique et prudente de la maintenance des nœuds, et la mise en œuvre de stratégies de sauvegarde et de restauration complètes et régulièrement testées. Il existe une forte interdépendance entre ces opérations : par exemple, une sauvegarde etcd est un prérequis à une mise à jour majeure 145, et la configuration des PodDisruptionBudgets impacte directement la capacité à drainer les nœuds pour la maintenance ou les mises à jour.[142] L’automatisation apportée par les Opérateurs (CVO, MCO, OADP Operator) simplifie grandement l’exécution de ces tâches complexes, mais elle ne dispense pas l’administrateur d’une compréhension approfondie des processus sous-jacents, des prérequis et des implications. En cas d’échec d’une opération automatisée, cette compréhension est indispensable pour un dépannage efficace.

10. Bonnes Pratiques d’Administration

L’administration efficace d’un cluster Red Hat OpenShift repose sur un ensemble de bonnes pratiques couvrant la sécurité, la haute disponibilité, la performance et la gestion des ressources. L’application rigoureuse de ces pratiques est essentielle pour garantir un environnement stable, sécurisé, performant et optimisé en termes de coûts.

10.1 Sécurité : Renforcement du cluster, gestion des Security Context Constraints (SCCs)

La sécurité dans OpenShift est une responsabilité partagée et doit être abordée de manière holistique, en considérant toutes les couches de la plateforme.

• Isolation et Moindre Privilège :
  • Utiliser les Projets (Namespaces) pour isoler logiquement les charges de travail, les équipes et les environnements.[127]
  • Appliquer rigoureusement le principe du moindre privilège avec le Contrôle d’Accès Basé sur les Rôles (RBAC). Cela signifie définir des Roles et ClusterRoles avec des permissions granulaires, accordant uniquement les droits nécessaires pour accomplir des tâches spécifiques. Éviter l’utilisation généralisée de rôles à privilèges élevés comme cluster-admin, sauf lorsque c’est absolument indispensable et pour des comptes dédiés à des tâches d’administration spécifiques.[126]
  • Isoler les charges de travail en utilisant des Comptes de Service (ServiceAccounts) distincts pour chaque application ou composant, chacun étant lié à des Roles contenant uniquement les permissions minimales requises.[126]
• Security Context Constraints (SCCs) : Les SCCs sont une fonctionnalité de sécurité spécifique à OpenShift qui contrôle les actions que les pods sont autorisés à effectuer et les fonctionnalités auxquelles ils peuvent accéder.[126] Ils définissent un ensemble de conditions qu’un pod doit respecter pour être admis dans le système, comme la possibilité de s’exécuter en tant qu’utilisateur root, d’accéder à des répertoires de l’hôte, d’utiliser des namespaces de l’hôte (PID, IPC, réseau), ou les capacités Linux autorisées.
  • OpenShift est livré avec un ensemble de SCCs par défaut (par exemple, restricted, nonroot, anyuid, privileged).
  • Il est crucial d’éviter d’assigner le SCC privileged par défaut aux pods, car il désactive la plupart des mécanismes de sécurité. Il ne doit être utilisé qu’en cas de nécessité absolue pour des charges de travail spécifiques qui le requièrent et après une analyse de risque approfondie.[126]
  • Attribuer le SCC le plus restrictif possible qui permet encore à l’application de fonctionner correctement.
• Sécurisation du Control Plane : Le control plane (API server, etcd, etc.) est le cœur du cluster et doit être particulièrement protégé.[126]
  • Utiliser des fournisseurs d’identité (IdP) forts (comme OpenID Connect avec authentification multi-facteurs, LDAP sécurisé) pour l’authentification des utilisateurs.
  • Configurer des pare-feu pour limiter l’accès réseau à l’API server uniquement depuis des sources fiables.
  • Assurer le chiffrement de toutes les communications du control plane en utilisant TLS, et envisager le mTLS (mutual TLS) pour une validation d’identité renforcée des nœuds.
  • Activer et surveiller régulièrement les logs d’audit de l’API server pour détecter toute activité suspecte ou non autorisée.
  • Sécuriser etcd en chiffrant ses données au repos et en limitant strictement l’accès à ses ports.
• Sécurité des Images Conteneur : La sécurité des images est fondamentale pour prévenir l’introduction de vulnérabilités dans le cluster.[126]
  • Utiliser des registres d’images de confiance et scanner les images pour identifier les vulnérabilités connues (CVEs) en utilisant des outils intégrés ou tiers (comme Red Hat Quay Security Scanning, OpenShift Compliance Operator).
  • Mettre en place des politiques d’admission des images (par exemple, via des Admission Controllers ou des outils comme OPA/Gatekeeper) pour empêcher le déploiement d’images provenant de sources non approuvées ou contenant des vulnérabilités critiques non corrigées.
  • Construire des images minimales, contenant uniquement les dépendances nécessaires à l’application, pour réduire la surface d’attaque.
• Sécurité des Nœuds et des Charges de Travail :
  • Minimiser la surface d’attaque des nœuds worker en limitant les logiciels installés sur RHCOS uniquement à ce qui est absolument requis.[126] RHCOS est conçu pour être minimal et géré par le cluster, ce qui aide dans ce sens.
  • Utiliser les NetworkPolicies pour segmenter le réseau au sein du cluster et restreindre les communications entre les pods au strict nécessaire (voir Section 5.4).[127]
  • Les AdminNetworkPolicy (ANP) et BaselineAdminNetworkPolicy (BANP), disponibles avec OVN-Kubernetes, offrent un contrôle administratif de plus haut niveau sur les politiques réseau. Les ANP permettent de définir des règles prioritaires (par exemple, pour bloquer certains trafics à l’échelle du cluster ou pour des groupes de namespaces) qui sont évaluées avant les NetworkPolicies définies par les développeurs. Les BANP permettent d’établir des politiques de base (par exemple, un “deny-all” par défaut pour le trafic inter-namespace) qui s’appliquent si aucune ANP ou NetworkPolicy plus spécifique ne correspond.[161] Ces outils sont puissants pour établir une gouvernance centralisée de la sécurité réseau.
  • Configurer le SecurityContext des pods et des conteneurs pour limiter leurs privilèges (par exemple, runAsNonRoot, readOnlyRootFilesystem, capabilities drop).
  • Activer et surveiller les logs d’audit système sur les nœuds.
• Mises à jour et Patchs : Maintenir le cluster OpenShift et RHCOS à jour avec les derniers patchs de sécurité est une mesure de défense fondamentale.

Une posture de sécurité robuste nécessite une vigilance constante, des audits réguliers et une adaptation aux nouvelles menaces et vulnérabilités.

10.2 Haute Disponibilité (HA) : Conception et stratégies de déploiement

Assurer la haute disponibilité des applications et du cluster OpenShift lui-même est une priorité majeure en production. Cela implique une conception architecturale réfléchie et la mise en œuvre de stratégies de déploiement résilientes.

• Redondance du Control Plane : Déployer au moins trois nœuds master (control plane), chacun hébergeant une instance etcd, répartis de préférence sur des domaines de défaillance distincts (par exemple, différentes zones de disponibilité dans un cloud public).[96] Cela permet au control plane de tolérer la perte d’un nœud.
• Répartition des Nœuds Worker : Déployer les nœuds worker sur plusieurs domaines de défaillance (zones de disponibilité, racks physiques différents) pour éviter qu’une défaillance unique n’impacte une grande partie de la capacité de calcul.[96] Utiliser des politiques de placement des VMs si possible.
• Réplication des Applications :
  • Exécuter plusieurs répliques (instances de pods) pour chaque composant applicatif stateless (par exemple, frontends web, API stateless). Le nombre de répliques doit être suffisant pour gérer la charge et tolérer la perte d’une ou plusieurs instances.[96] Utiliser des Deployments avec un spec.replicas supérieur à 1.
  • Les Services Kubernetes équilibreront la charge entre ces répliques.
• Stratégies de Déploiement Résilientes : Utiliser des stratégies de déploiement comme RollingUpdate (pour les Deployments et DeploymentConfigs) qui mettent à jour les applications progressivement, en s’assurant qu’un nombre suffisant d’instances reste disponible pour servir le trafic, minimisant ainsi les interruptions de service.[163]
• Gestion de la Terminaison Gracieuse : Les applications doivent être conçues pour gérer correctement le signal SIGTERM envoyé par Kubernetes avant l’arrêt d’un pod. Cela leur permet de terminer proprement les requêtes en cours, de fermer les connexions, et de sauvegarder leur état si nécessaire, avant d’être forcées de s’arrêter. La période de grâce (terminationGracePeriodSeconds) peut être ajustée.[163]
• Sondes de Santé (Health Probes) : Configurer des sondes de vivacité (livenessProbe), de préparation (readinessProbe), et de démarrage (startupProbe) pour chaque conteneur applicatif.[163]
  • livenessProbe : Indique si le conteneur est en cours d’exécution et en bonne santé. S’il échoue, Kubernetes redémarre le conteneur.
  • readinessProbe : Indique si le conteneur est prêt à accepter du trafic. S’il échoue, le pod est retiré des points de terminaison du Service et ne reçoit plus de nouvelles requêtes jusqu’à ce qu’il redevienne prêt.
  • startupProbe : Indique si l’application dans le conteneur a démarré avec succès. Utile pour les applications à démarrage lent, pour éviter que les liveness/readiness probes ne les tuent prématurément.
• Gestion des Dépendances Externes : Les applications doivent être résilientes aux défaillances temporaires de leurs dépendances externes (bases de données, API tierces). Utiliser des initContainers ou des startupProbes pour vérifier la disponibilité des dépendances avant que le conteneur principal ne démarre ou ne soit marqué comme prêt.[163]
• PodDisruptionBudgets (PDBs) : Un PDB est un objet Kubernetes qui limite le nombre de pods d’une application (définie par un sélecteur de labels) qui peuvent être volontairement interrompus en même temps (par exemple, lors d’une opération de drain de nœud pour maintenance ou mise à jour). Configurer des PDBs est crucial pour garantir qu’un nombre minimum d’instances de l’application reste toujours disponible.[96]
• Stockage Persistant Hautement Disponible : Pour les applications stateful, utiliser des solutions de stockage persistant qui offrent elles-mêmes de la redondance et de la haute disponibilité (par exemple, OpenShift Data Foundation configuré en mode HA, des volumes cloud régionaux comme AWS Regional EBS, ou des systèmes de fichiers partagés répliqués).[96]
• Externalisation de l’État : Pour les applications qui le permettent, externaliser l’état (comme les sessions utilisateur ou les caches) vers des magasins de données persistants ou des caches en mémoire partagés qui sont eux-mêmes configurés en mode haute disponibilité (par exemple, Redis, Memcached, ou une base de données externe répliquée).[96]
• Équilibrage de Charge Externe : Utiliser des équilibreurs de charge externes (fournis par le cloud ou sur site) qui peuvent distribuer le trafic sur plusieurs nœuds ou même sur plusieurs clusters OpenShift dans des configurations multi-régions ou de reprise après sinistre.[96]

La haute disponibilité est le résultat d’une conception architecturale soignée à plusieurs niveaux, depuis l’infrastructure sous-jacente jusqu’à la configuration des applications elles-mêmes.

10.3 Performance et Optimisation : Dimensionnement, réglages

Optimiser les performances d’un cluster OpenShift et des applications qu’il héberge est un processus continu qui implique un dimensionnement correct, des réglages fins et une surveillance constante.

• Dimensionnement des Nœuds et du Cluster :
  • Nœuds Control Plane : Leur taille (CPU, mémoire) doit être suffisante pour gérer le nombre de nœuds worker, le nombre total de pods et d’objets API dans le cluster. Surveiller leur utilisation et viser un maximum de 60% d’utilisation en temps normal pour absorber les pics lors de défaillances ou de mises à jour.[164]
  • Nœuds Worker et Infrastructure : Dimensionner en fonction des besoins des charges de travail applicatives et des services d’infrastructure. Tenir compte des demandes (requests) et des limites (limits) de ressources des pods.
  • etcd : Exécuter etcd sur des machines avec des disques SSD ou NVMe à faible latence et haut débit. Surveiller les métriques de performance d’etcd (durée fsync WAL, latence RTT entre pairs).[164] Défragmenter etcd périodiquement.
• Optimisation des Ressources (Requests et Limits) :
  • Toujours définir des demandes (requests) de CPU et de mémoire pour les conteneurs. Cela garantit que le pod se verra allouer ces ressources minimales sur le nœud où il est planifié.[165]
  • Définir des limites (limits) de mémoire pour éviter qu’un conteneur en fuite ne consomme toute la mémoire du nœud et n’entraîne des OOM (Out Of Memory) kills pour lui-même ou d’autres pods. Une pratique courante est de fixer la limite de mémoire à un multiple de la demande (par exemple, 2x).[165]
  • Éviter de définir des limites (limits) de CPU strictes sauf si absolument nécessaire, car cela peut entraîner un étranglement (throttling) inutile du CPU même si des cycles CPU sont disponibles sur le nœud. Kubernetes gère bien le partage du CPU basé sur les demandes.[165]
  • Surveiller l’utilisation réelle des charges de travail et ajuster les demandes en fonction de l’utilisation moyenne observée sur une période significative.[165]
  • Utiliser le Vertical Pod Autoscaler (VPA) en mode Recommendation pour obtenir des suggestions sur les valeurs optimales de demandes de ressources basées sur l’utilisation historique. Appliquer ces recommandations manuellement après validation.[165]
• Optimisation du Stockage :
  • Choisir le type de stockage persistant (bloc, fichier, objet) et la StorageClass appropriés en fonction des besoins de performance (IOPS, débit) et des modes d’accès de l’application.[164]
  • Pour les charges de travail intensives en écriture comme etcd, éviter les configurations RAID qui peuvent introduire de la latence.
• Optimisation du Réseau :
  • La performance du routeur OpenShift (Ingress Controller) dépend de facteurs comme le mode keep-alive HTTP, le type de route (sécurisée/non sécurisée), la reprise de session TLS, et la taille des pages des serveurs backend.[164]
  • L’utilisation de tunnels overlay (VXLAN avec OpenShift SDN, Geneve avec OVN-Kubernetes) peut introduire une surcharge CPU. Envisager des cartes réseau avec déchargement VXLAN/Geneve (offload) pour réduire cette charge.[164]
  • Optimiser la MTU (Maximum Transmission Unit) du réseau. Une MTU plus grande peut améliorer le débit, tandis qu’une MTU plus petite peut réduire la latence. La MTU de l’overlay SDN doit être inférieure à la MTU de l’interface réseau physique du nœud.[164]
• Node Tuning Operator : Utiliser le Node Tuning Operator pour appliquer des réglages fins au niveau du noyau (sysctls) et d’autres paramètres système sur des groupes de nœuds. Cela peut être utilisé pour optimiser les performances pour des charges de travail spécifiques (par exemple, faible latence, haut débit réseau).[164]
• CPU Manager et Topology Manager : Pour les applications très sensibles à la latence, le CPU Manager permet de contraindre les charges de travail à des cœurs CPU spécifiques (CPU pinning). Le Topology Manager, en conjonction avec le CPU Manager et le Device Manager, aide à aligner les ressources (CPU, périphériques PCIe comme les GPU ou les NICs rapides) sur le même nœud NUMA, améliorant ainsi les performances.[164]
• Huge Pages : L’utilisation de Huge Pages (pages mémoire de grande taille, par exemple 2MB ou 1GB au lieu des 4KB standards) peut améliorer les performances des applications qui manipulent de grandes quantités de mémoire en réduisant les défauts de TLB (Translation Lookaside Buffer). OpenShift permet de configurer et d’allouer des Huge Pages aux pods qui en ont besoin.[164]
• Performance Addon Operator : Pour les charges de travail à faible latence (souvent dans le domaine des télécommunications/NFV), cet opérateur peut automatiser de nombreux

Lexique des Abréviations

• ACL : Access Control List (Liste de Contrôle d’Accès)
• ANP : AdminNetworkPolicy (Politique Réseau d’Administration)
• API : Application Programming Interface (Interface de Programmation d’Application)
• AWS : Amazon Web Services
• BANP : BaselineAdminNetworkPolicy (Politique Réseau d’Administration de Base)
• CI/CD : Continuous Integration/Continuous Deployment (Intégration Continue/Déploiement Continu)
• CLF : ClusterLogForwarder (Transitaire de Logs de Cluster)
• CLI : Command Line Interface (Interface en Ligne de Commande)
• CMO : Cluster Monitoring Operator (Opérateur de Surveillance de Cluster)
• CNI : Container Network Interface (Interface Réseau de Conteneur)
• CPU : Central Processing Unit (Unité Centrale de Traitement)
• CR : Custom Resource (Ressource Personnalisée)
• CRD : Custom Resource Definition (Définition de Ressource Personnalisée)
• CRI : Container Runtime Interface (Interface d’Exécution de Conteneur)
• CSI : Container Storage Interface (Interface de Stockage de Conteneur)
• CVO : Cluster Version Operator (Opérateur de Version de Cluster)
• DNS : Domain Name System (Système de Noms de Domaine)
• DPA : DataProtectionApplication (Application de Protection des Données)
• EBS : Elastic Block Store (Service de stockage en mode bloc d’AWS)
• EFK : Elasticsearch, Fluentd, Kibana (Pile de journalisation)
• GCP : Google Cloud Platform
• HA : High Availability (Haute Disponibilité)
• IAM : Identity and Access Management (Gestion des Identités et des Accès)
• IdP : Identity Provider (Fournisseur d’Identité)
• IOPS : Input/Output Operations Per Second (Opérations d’Entrée/Sortie par Seconde)
• IP : Internet Protocol
• iSCSI : Internet Small Computer System Interface
• LDAP : Lightweight Directory Access Protocol (Protocole d’Accès Annuaire Léger)
• MCO : MachineConfig Operator (Opérateur de Configuration de Machine)
• MCP : MachineConfigPool (Pool de Configuration de Machine)
• mTLS : Mutual Transport Layer Security (Sécurité de la Couche de Transport Mutuelle)
• MTU : Maximum Transmission Unit (Unité de Transmission Maximale)
• NFS : Network File System (Système de Fichiers en Réseau)
• NMO : Node Maintenance Operator (Opérateur de Maintenance de Nœud)
• NUMA : Non-Uniform Memory Access (Accès Mémoire Non Uniforme)
• OADP : OpenShift API for Data Protection (API OpenShift pour la Protection des Données)
• OCI : Open Container Initiative
• OCP : OpenShift Container Platform
• ODF : OpenShift Data Foundation
• OIDC : OpenID Connect
• OLM : Operator Lifecycle Manager (Gestionnaire de Cycle de Vie des Opérateurs)
• OOM : Out Of Memory (Hors Mémoire)
• OS : Operating System (Système d’Exploitation)
• OVN : Open Virtual Network
• OVS : Open vSwitch
• PDB : PodDisruptionBudget (Budget de Perturbation de Pod)
• PO : Prometheus Operator (Opérateur Prometheus)
• PromQL : Prometheus Query Language (Langage de Requête Prometheus)
• PV : PersistentVolume (Volume Persistant)
• PVC : PersistentVolumeClaim (Demande de Volume Persistant)
• RBAC : Role-Based Access Control (Contrôle d’Accès Basé sur les Rôles)
• RBD : RADOS Block Device (Périphérique Bloc RADOS - Ceph)
• RGW : RADOS Gateway (Passerelle RADOS - Ceph)
• RHCOS : Red Hat Enterprise Linux CoreOS
• RHEL : Red Hat Enterprise Linux
• RWO : ReadWriteOnce (Lecture-Écriture une seule fois - mode d’accès PV)
• RWX : ReadWriteMany (Lecture-Écriture multiple - mode d’accès PV)
• S2I : Source-to-Image
• S3 : Simple Storage Service (Service de stockage simple d’AWS)
• SCC : Security Context Constraint (Contrainte de Contexte de Sécurité)
• SDN : Software Defined Networking (Réseau Défini par Logiciel)
• TLS : Transport Layer Security (Sécurité de la Couche de Transport)
• TSDB : Time Series Database (Base de Données de Séries Temporelles)
• UID : Unique Identifier (Identifiant Unique)
• VM : Virtual Machine (Machine Virtuelle)
• VPA : Vertical Pod Autoscaler (Auto-ajusteur Vertical de Pod)
• VXLAN : Virtual Extensible LAN (Réseau Local Virtuel Extensible)
• YAML : YAML Ain’t Markup Language