Bien que les images de conteneurs et les conteneurs qui s'exécutent à partir d'elles soient les principaux éléments constitutifs du développement d'applications modernes, leur exécution à grande échelle nécessite un système de distribution fiable et flexible. Kubernetes est la norme de facto pour l'orchestration des conteneurs.

Kubernetes est un moteur d'orchestration de conteneurs open source permettant d'automatiser le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Le concept général de Kubernetes est assez simple :

En quelques années seulement, Kubernetes a connu une adoption massive dans le cloud et sur site. Le modèle de développement open source permet à de nombreuses personnes d'étendre Kubernetes en mettant en œuvre différentes technologies pour des composants tels que le réseau, le stockage et l'authentification.

L'utilisation d'applications conteneurisées présente de nombreux avantages par rapport aux méthodes de déploiement traditionnelles. Alors que les applications étaient autrefois censées être installées sur des systèmes d'exploitation comprenant toutes leurs dépendances, les conteneurs permettent à une application de transporter ses dépendances avec elle. La création d'applications conteneurisées offre de nombreux avantages.

OpenShift Container Platform apporte à Kubernetes des améliorations prêtes pour l'entreprise, notamment les suivantes :

Bien que Kubernetes excelle dans la gestion de vos applications, il ne spécifie ni ne gère les exigences au niveau de la plateforme ou les processus de déploiement. Des outils et des processus de gestion de plateforme puissants et flexibles sont des avantages importants qu'offre OpenShift Container Platform 4.12. Les sections suivantes décrivent certaines caractéristiques et avantages uniques d'OpenShift Container Platform.

2.1.3.4. Cycle de vie d'OpenShift Container Platform

La figure suivante illustre le cycle de vie de base d'OpenShift Container Platform :

• Créer un cluster OpenShift Container Platform
• Gestion de la grappe
• Développement et déploiement d'applications
• Extension des applications

Figure 2.1. Vue d'ensemble de la plateforme OpenShift Container Platform

Dans OpenShift Container Platform 4.12, vous devez avoir accès à Internet pour installer votre cluster.

Vous devez disposer d'un accès à l'internet pour :

Vous pouvez utiliser le programme d'installation pour déployer chaque type de cluster. Le programme d'installation génère des ressources principales telles que les fichiers de configuration Ignition pour le bootstrap, le plan de contrôle (maître) et les machines de travail. Vous pouvez démarrer un cluster OpenShift Container Platform avec ces trois configurations et une infrastructure correctement configurée.

Le programme d'installation d'OpenShift Container Platform utilise un ensemble de cibles et de dépendances pour gérer les installations de clusters. Le programme d'installation a un ensemble de cibles qu'il doit atteindre, et chaque cible a un ensemble de dépendances. Comme chaque objectif ne concerne que ses propres dépendances, le programme d'installation peut agir pour atteindre plusieurs objectifs en parallèle, l'objectif final étant un cluster en cours d'exécution. Le programme d'installation reconnaît et utilise les composants existants au lieu d'exécuter des commandes pour les créer à nouveau, car le programme respecte les dépendances.

Figure 3.1. Cibles et dépendances pour l'installation d'OpenShift Container Platform

Après l'installation, chaque machine du cluster utilise Red Hat Enterprise Linux CoreOS (RHCOS) comme système d'exploitation. RHCOS est la version d'hôte de conteneur immuable de Red Hat Enterprise Linux (RHEL) et comporte un noyau RHEL avec SELinux activé par défaut. Il inclut kubelet, qui est l'agent de nœud Kubernetes, et le runtime de conteneur CRI-O, qui est optimisé pour Kubernetes.

Chaque machine du plan de contrôle dans un cluster OpenShift Container Platform 4.12 doit utiliser RHCOS, qui comprend un outil critique de provisionnement au premier démarrage appelé Ignition. Cet outil permet au cluster de configurer les machines. Les mises à jour du système d'exploitation sont fournies sous la forme d'une image de conteneur amorçable, utilisant OSTree comme backend, qui est déployée dans le cluster par le Machine Config Operator. Les modifications réelles du système d'exploitation sont effectuées sur place sur chaque machine en tant qu'opération atomique à l'aide de rpm-ostree. Ensemble, ces technologies permettent à OpenShift Container Platform de gérer le système d'exploitation comme n'importe quelle autre application sur le cluster, en effectuant des mises à jour sur place qui maintiennent l'ensemble de la plateforme à jour. Ces mises à jour sur place peuvent réduire la charge des équipes d'exploitation.

Si vous utilisez RHCOS comme système d'exploitation pour toutes les machines de la grappe, celle-ci gère tous les aspects de ses composants et de ses machines, y compris le système d'exploitation. Pour cette raison, seuls le programme d'installation et l'opérateur de configuration des machines peuvent modifier les machines. Le programme d'installation utilise les fichiers de configuration Ignition pour définir l'état exact de chaque machine, et le Machine Config Operator effectue d'autres modifications sur les machines, telles que l'application de nouveaux certificats ou de nouvelles clés, après l'installation.

Dans OpenShift Container Platform 4.12, vous pouvez installer un cluster qui utilise une infrastructure fournie par l'installateur sur les plateformes suivantes :

Pour ces clusters, toutes les machines, y compris l'ordinateur sur lequel vous exécutez le processus d'installation, doivent avoir un accès direct à Internet afin d'extraire des images pour les conteneurs de la plate-forme et de fournir des données télémétriques à Red Hat.

Dans OpenShift Container Platform 4.12, vous pouvez installer un cluster qui utilise l'infrastructure fournie par l'utilisateur sur les plateformes suivantes :

Selon les cas pris en charge pour la plateforme, les installations sur une infrastructure fournie par l'utilisateur vous permettent d'exécuter des machines avec un accès complet à Internet, de placer votre cluster derrière un proxy ou d'effectuer une installation sur restricted network installation. Dans une installation en réseau restreint, vous pouvez télécharger les images nécessaires à l'installation d'un cluster, les placer dans un registre miroir et utiliser ces données pour installer votre cluster. Alors que vous avez besoin d'un accès à Internet pour extraire les images des conteneurs de plateforme, avec une installation en réseau restreint sur vSphere ou une infrastructure bare metal, vos machines de cluster n'ont pas besoin d'un accès direct à Internet.

La page OpenShift Container Platform 4.x Tested Integrations contient des détails sur les tests d'intégration pour différentes plateformes.

À l'exception de l'installateur assisté, lorsque vous installez un cluster OpenShift Container Platform, vous téléchargez le programme d'installation à partir de la page du fournisseur d'infrastructure approprié sur le site OpenShift Cluster Manager. Ce site gère :

Dans OpenShift Container Platform 4.12, le programme d'installation est un fichier binaire Go qui effectue une série de transformations de fichiers sur un ensemble de ressources. La façon dont vous interagissez avec le programme d'installation diffère en fonction de votre type d'installation.

Le programme d'installation utilise trois ensembles de fichiers lors de l'installation : un fichier de configuration d'installation nommé install-config.yaml, des manifestes Kubernetes et des fichiers de configuration Ignition pour vos types de machines.

Le fichier de configuration de l'installation est transformé en manifestes Kubernetes, puis les manifestes sont enveloppés dans des fichiers de configuration Ignition. Le programme d'installation utilise ces fichiers de configuration Ignition pour créer le cluster.

Les fichiers de configuration de l'installation sont tous élagués lorsque vous exécutez le programme d'installation. Veillez donc à sauvegarder tous les fichiers de configuration que vous souhaitez réutiliser.

Le processus d'installation avec le programme d'installation assistée

L'installation à l'aide du programme d'installation assistée implique la création d'une configuration de cluster de manière interactive à l'aide de l'interface utilisateur Web ou de l'API RESTful. L'interface utilisateur du programme d'installation assistée vous invite à saisir les valeurs requises et fournit des valeurs par défaut raisonnables pour les autres paramètres, sauf si vous les modifiez dans l'interface utilisateur ou à l'aide de l'API. Le programme d'installation assistée génère une image de découverte que vous téléchargez et utilisez pour démarrer les machines du cluster. L'image installe RHCOS et un agent, et l'agent gère le provisionnement pour vous. Vous pouvez installer OpenShift Container Platform avec l'installateur assisté et l'intégration complète sur Nutanix, vSphere et bare metal, et sur d'autres plateformes sans intégration.

OpenShift Container Platform gère tous les aspects du cluster, y compris le système d'exploitation lui-même. Chaque machine démarre avec une configuration qui référence les ressources hébergées dans le cluster qu'elle rejoint. Cette configuration permet au cluster de se gérer lui-même au fur et à mesure que les mises à jour sont appliquées.

Si possible, utilisez cette fonction pour éviter d'avoir à télécharger et à configurer le programme d'installation basé sur un agent.

Le processus d'installation d'une infrastructure basée sur des agents

L'installation à l'aide d'un agent est similaire à l'utilisation du programme d'installation assistée, à ceci près que vous devez d'abord télécharger et installer le programme d'installation à l'aide d'un agent. L'installation à l'aide d'un agent est recommandée lorsque vous souhaitez bénéficier de tous les avantages de l'installateur assisté, mais que vous devez effectuer l'installation sur un réseau isolé ou déconnecté.

Si possible, utilisez cette fonctionnalité pour éviter d'avoir à créer une machine de provisionnement avec une VM de démarrage et de provisionner et maintenir l'infrastructure du cluster.

Le processus d'installation avec l'infrastructure fournie par l'installateur

Le type d'installation par défaut utilise une infrastructure fournie par l'installateur. Par défaut, le programme d'installation agit comme un assistant d'installation, vous demandant les valeurs qu'il ne peut pas déterminer lui-même et fournissant des valeurs par défaut raisonnables pour les paramètres restants. Vous pouvez également personnaliser le processus d'installation pour prendre en charge des scénarios d'infrastructure avancés. Le programme d'installation fournit l'infrastructure sous-jacente pour le cluster.

Vous pouvez installer soit un cluster standard, soit un cluster personnalisé. Dans le cas d'un cluster standard, vous fournissez les informations minimales nécessaires à l'installation du cluster. Avec un cluster personnalisé, vous pouvez spécifier plus de détails sur la plateforme, tels que le nombre de machines que le plan de contrôle utilise, le type de machine virtuelle que le cluster déploie, ou la plage CIDR pour le réseau de service Kubernetes.

Si possible, utilisez cette fonction pour éviter d'avoir à approvisionner et à maintenir l'infrastructure du cluster. Dans tous les autres environnements, vous utilisez le programme d'installation pour générer les ressources nécessaires à l'approvisionnement de votre infrastructure de cluster.

Avec les clusters d'infrastructure provisionnés par l'installateur, OpenShift Container Platform gère tous les aspects du cluster, y compris le système d'exploitation lui-même. Chaque machine démarre avec une configuration qui référence les ressources hébergées dans le cluster qu'elle rejoint. Cette configuration permet au cluster de se gérer lui-même au fur et à mesure que les mises à jour sont appliquées.

Le processus d'installation avec l'infrastructure fournie par l'utilisateur

Vous pouvez également installer OpenShift Container Platform sur une infrastructure que vous fournissez. Vous utilisez le programme d'installation pour générer les ressources nécessaires au provisionnement de l'infrastructure du cluster, créer l'infrastructure du cluster, puis déployer le cluster sur l'infrastructure que vous avez fournie.

Si vous n'utilisez pas l'infrastructure fournie par le programme d'installation, vous devez gérer et maintenir les ressources du cluster vous-même, y compris :

Si votre cluster utilise une infrastructure fournie par l'utilisateur, vous avez la possibilité d'ajouter des machines de calcul RHEL à votre cluster.

Détails de la procédure d'installation

Parce que chaque machine du cluster nécessite des informations sur le cluster lorsqu'elle est provisionnée, OpenShift Container Platform utilise une machine temporaire bootstrap lors de la configuration initiale pour fournir les informations nécessaires au plan de contrôle permanent. Elle démarre en utilisant un fichier de configuration Ignition qui décrit comment créer le cluster. La machine d'amorçage crée les machines du plan de contrôle qui constituent le plan de contrôle. Les machines du plan de contrôle créent ensuite les machines de calcul, également appelées machines de travail. La figure suivante illustre ce processus :

Figure 3.2. Création du bootstrap, du plan de contrôle et des machines de calcul

Après l'initialisation des machines de la grappe, la machine bootstrap est détruite. Tous les clusters utilisent le processus d'amorçage pour initialiser le cluster, mais si vous fournissez l'infrastructure pour votre cluster, vous devez effectuer de nombreuses étapes manuellement.

L'amorçage d'une grappe comprend les étapes suivantes :

Le résultat de ce processus de démarrage est un cluster OpenShift Container Platform en cours d'exécution. Le cluster télécharge et configure ensuite les autres composants nécessaires au fonctionnement quotidien, y compris la création de machines de calcul dans les environnements pris en charge.

Champ d'application de l'installation

Le programme d'installation d'OpenShift Container Platform est volontairement restreint. Il est conçu pour être simple et garantir le succès de l'installation. Vous pouvez effectuer de nombreuses autres tâches de configuration une fois l'installation terminée.

L'onglet Overview fournit des informations sur la façon dont votre cluster a été configuré :

L'onglet Access control permet au propriétaire du cluster de configurer un fournisseur d'identité, d'accorder des autorisations élevées et d'attribuer des rôles à d'autres utilisateurs.

L'onglet Add-ons affiche tous les modules optionnels qui peuvent être ajoutés au cluster. Sélectionnez l'extension souhaitée, puis Install sous la description de l'extension qui s'affiche.

L'onglet Insights Advisor utilise la fonctionnalité Remote Health de OpenShift Container Platform pour identifier et atténuer les risques en matière de sécurité, de performance, de disponibilité et de stabilité. Voir Utiliser Insights pour identifier les problèmes de votre cluster dans la documentation d'OpenShift Container Platform.

L'onglet Machine pools permet au propriétaire du cluster de créer de nouveaux pools de machines, si le quota disponible est suffisant, ou de modifier un pool de machines existant.

La sélection de More options > Scale ouvre la boîte de dialogue "Edit node count" (Modifier le nombre de nœuds). Dans cette boîte de dialogue, vous pouvez modifier le nombre de nœuds par zone de disponibilité. Si la mise à l'échelle automatique est activée, vous pouvez également définir la plage de mise à l'échelle automatique.

Dans l'onglet Support, vous pouvez ajouter des contacts de notification pour les personnes qui doivent recevoir les notifications du cluster. Le nom d'utilisateur ou l'adresse électronique que vous fournissez doit se rapporter à un compte d'utilisateur dans l'organisation Red Hat où le cluster est déployé.

Toujours à partir de cet onglet, vous pouvez ouvrir un dossier de support pour demander une assistance technique pour votre cluster.

L'onglet Settings offre quelques options au propriétaire du cluster :

La version d'OpenShift Container Platform doit correspondre entre l'hôte du plan de contrôle et l'hôte du nœud. Par exemple, dans un cluster 4.12, tous les hôtes du plan de contrôle doivent être 4.12 et tous les nœuds doivent être 4.12.

Les décalages temporaires lors des mises à niveau de clusters sont acceptables. Par exemple, lors de la mise à niveau d'OpenShift Container Platform 4.11 à 4.12, certains nœuds passeront à la version 4.12 avant d'autres. Un décalage prolongé des hôtes du plan de contrôle et des hôtes des nœuds peut exposer les machines de calcul plus anciennes à des bogues et à des fonctionnalités manquantes. Les utilisateurs doivent résoudre les hôtes de plan de contrôle et les hôtes de nœuds asymétriques dès que possible.

Le service kubelet ne doit pas être plus récent que kube-apiserver, et peut être jusqu'à deux versions mineures plus anciennes selon que la version de votre OpenShift Container Platform est paire ou impaire. Le tableau ci-dessous indique la compatibilité de version appropriée :

Dans un cluster Kubernetes, les nœuds de travail sont l'endroit où les charges de travail réelles demandées par les utilisateurs de Kubernetes s'exécutent et sont gérées. Les nœuds de travail annoncent leur capacité et le planificateur, qui est un service de plan de contrôle, détermine sur quels nœuds démarrer les pods et les conteneurs. D'importants services sont exécutés sur chaque nœud de travail, notamment CRI-O, le moteur de conteneurs ; Kubelet, le service qui accepte et exécute les demandes d'exécution et d'arrêt des charges de travail des conteneurs ; un proxy de service, qui gère la communication entre les pods et les travailleurs ; et le runtime de conteneur de bas niveau runC ou crun (Technology Preview), qui crée et exécute les conteneurs.

Dans OpenShift Container Platform, les ensembles de machines de calcul contrôlent les machines de calcul, auxquelles est attribué le rôle de machine worker. Les machines dotées du rôle worker pilotent des charges de travail de calcul qui sont régies par un pool de machines spécifique qui les met à l'échelle automatiquement. Comme OpenShift Container Platform a la capacité de prendre en charge plusieurs types de machines, les machines ayant le rôle worker sont classées comme des machines compute. Dans cette version, les termes worker machine et compute machine sont utilisés de manière interchangeable car le seul type de machine de calcul par défaut est la machine de travail. Dans les versions futures d'OpenShift Container Platform, d'autres types de machines de calcul, telles que les machines d'infrastructure, pourraient être utilisées par défaut.

Dans un cluster Kubernetes, les nœuds master exécutent les services nécessaires au contrôle du cluster Kubernetes. Dans OpenShift Container Platform, le plan de contrôle est composé de machines de plan de contrôle qui ont un rôle de machine master. Elles contiennent plus que les services Kubernetes pour gérer le cluster OpenShift Container Platform.

Pour la plupart des clusters OpenShift Container Platform, les machines du plan de contrôle sont définies par une série de ressources API de machines autonomes. Pour les combinaisons de fournisseurs de cloud et de versions d'OpenShift Container Platform prises en charge, les plans de contrôle peuvent être gérés avec des ensembles de machines de plan de contrôle. Des contrôles supplémentaires s'appliquent aux machines de plan de contrôle pour vous empêcher de supprimer toutes les machines de plan de contrôle et de casser votre cluster.

Les services qui relèvent de la catégorie Kubernetes sur le plan de contrôle comprennent le serveur API Kubernetes, etcd, le gestionnaire de contrôleur Kubernetes et le planificateur Kubernetes.

Il existe également des services OpenShift qui s'exécutent sur le plan de contrôle, notamment le serveur API OpenShift, le gestionnaire de contrôleur OpenShift, le serveur API OpenShift OAuth et le serveur OpenShift OAuth.

Certains de ces services sur les machines du plan de contrôle s'exécutent en tant que services systemd, tandis que d'autres s'exécutent en tant que pods statiques.

Les services Systemd sont appropriés pour les services qui doivent toujours apparaître sur un système particulier peu de temps après son démarrage. Pour les machines du plan de contrôle, il s'agit notamment de sshd, qui permet de se connecter à distance. Ils comprennent également des services tels que :

CRI-O et Kubelet doivent être exécutés directement sur l'hôte en tant que services systemd, car ils doivent fonctionner avant que vous puissiez exécuter d'autres conteneurs.

Les pods de plan de contrôle installer-* et revision-pruner-* doivent être exécutés avec les permissions de l'utilisateur root car ils écrivent dans le répertoire /etc/kubernetes, qui appartient à l'utilisateur root. Ces modules se trouvent dans les espaces de noms suivants :

Dans OpenShift Container Platform, toutes les fonctions de cluster sont divisées en une série de cluster Operators par défaut. Les opérateurs de cluster gèrent un domaine particulier des fonctionnalités du cluster, comme la journalisation des applications à l'échelle du cluster, la gestion du plan de contrôle Kubernetes ou le système de provisionnement des machines.

Les opérateurs de cluster sont représentés par un objet ClusterOperator, que les administrateurs de cluster peuvent consulter dans la console web d'OpenShift Container Platform à partir de la page Administration → Cluster Settings. Chaque opérateur de cluster fournit une API simple pour déterminer les fonctionnalités du cluster. L'Opérateur cache les détails de la gestion du cycle de vie de ce composant. Les opérateurs peuvent gérer un seul composant ou des dizaines de composants, mais l'objectif final est toujours de réduire la charge opérationnelle en automatisant les actions courantes.

Operator Lifecycle Manager (OLM) et OperatorHub sont des composants par défaut dans OpenShift Container Platform qui aident à gérer les applications natives de Kubernetes en tant qu'opérateurs. Ensemble, ils fournissent le système de découverte, d'installation et de gestion des opérateurs complémentaires optionnels disponibles sur le cluster.

En utilisant OperatorHub dans la console web d'OpenShift Container Platform, les administrateurs de clusters et les utilisateurs autorisés peuvent sélectionner des opérateurs à installer à partir de catalogues d'opérateurs. Après avoir installé un opérateur à partir d'OperatorHub, il peut être mis à disposition globalement ou dans des espaces de noms spécifiques pour être exécuté dans les applications des utilisateurs.

Des sources de catalogue par défaut sont disponibles et incluent les opérateurs Red Hat, les opérateurs certifiés et les opérateurs communautaires. Les administrateurs de clusters peuvent également ajouter leurs propres sources de catalogue personnalisées, qui peuvent contenir un ensemble personnalisé d'opérateurs.

Les développeurs peuvent utiliser le SDK de l'opérateur pour créer des opérateurs personnalisés qui tirent parti des fonctionnalités d'OLM. Leur opérateur peut ensuite être regroupé et ajouté à un catalogue source personnalisé, qui peut être ajouté à un cluster et mis à la disposition des utilisateurs.

Operator Lifecycle Manager (OLM) introduit un nouveau type d'opérateur appelé platform Operators. Un opérateur de plateforme est un opérateur basé sur OLM qui peut être installé pendant ou après les opérations du jour 0 d'un cluster OpenShift Container Platform et qui participe au cycle de vie du cluster. En tant qu'administrateur de cluster, vous pouvez utiliser les opérateurs de plateforme pour personnaliser davantage votre installation OpenShift Container Platform afin de répondre à vos exigences et à vos cas d'utilisation.

En utilisant la fonction existante de capacités de cluster dans OpenShift Container Platform, les administrateurs de cluster peuvent déjà désactiver un sous-ensemble de composants basés sur l'opérateur de version de cluster (CVO) considérés comme non essentiels à la charge utile initiale avant l'installation du cluster. Les opérateurs de plateforme s'inspirent de ce modèle en offrant des options de personnalisation supplémentaires. Grâce au mécanisme de l'opérateur de plateforme, qui s'appuie sur les ressources du composant RukPak, les opérateurs basés sur OLM peuvent désormais être installés au moment de l'installation du cluster et peuvent bloquer le déploiement du cluster si l'opérateur ne parvient pas à s'installer correctement.

Dans OpenShift Container Platform 4.12, cette version Technology Preview se concentre sur le mécanisme de base de la plateforme Operator et construit une base pour étendre le concept dans les prochaines versions. Vous pouvez utiliser l'API PlatformOperator à l'échelle du cluster pour configurer les opérateurs avant ou après la création du cluster sur les clusters qui ont activé l'ensemble de fonctionnalités TechPreviewNoUpgrades.

OpenShift Container Platform est souvent déployé dans un modèle couplé, ou autonome, où un cluster se compose d'un plan de contrôle et d'un plan de données. Le plan de contrôle comprend un point d'extrémité d'API, un point d'extrémité de stockage, un planificateur de charge de travail et un actionneur qui assure l'état. Le plan de données comprend le calcul, le stockage et le réseau où s'exécutent les charges de travail et les applications.

Le plan de contrôle autonome est hébergé par un groupe dédié de nœuds, qui peuvent être physiques ou virtuels, avec un nombre minimum pour assurer le quorum. La pile réseau est partagée. L'accès de l'administrateur à une grappe offre une visibilité sur le plan de contrôle de la grappe, les API de gestion des machines et d'autres composants qui contribuent à l'état d'une grappe.

Bien que le modèle autonome fonctionne bien, certaines situations exigent une architecture où le plan de contrôle et le plan de données sont découplés. Dans ce cas, le plan de données se trouve sur un domaine de réseau séparé avec un environnement d'hébergement physique dédié. Le plan de contrôle est hébergé en utilisant des primitives de haut niveau telles que les déploiements et les ensembles avec état qui sont natifs de Kubernetes. Le plan de contrôle est traité comme n'importe quelle autre charge de travail.

Avec les plans de contrôle hébergés pour OpenShift Container Platform, vous pouvez ouvrir la voie à une véritable approche de cloud hybride et profiter de plusieurs autres avantages.

À chaque version majeure, mineure ou corrective d'OpenShift Container Platform, deux composants des plans de contrôle hébergés sont publiés :

L'opérateur HyperShift gère le cycle de vie des clusters hébergés qui sont représentés par les ressources de l'API HostedCluster. L'opérateur HyperShift est publié avec chaque version d'OpenShift Container Platform.

Le CLI est un utilitaire d'aide au développement. Le CLI fait partie de toute version d'HyperShift Operator. Aucune politique de compatibilité n'est garantie.

L'API, hypershift.openshift.io, permet de créer et de gérer des clusters OpenShift Container Platform légers, flexibles et hétérogènes à l'échelle. L'API expose deux ressources orientées utilisateur : HostedCluster et NodePool. Une ressource HostedCluster encapsule le plan de contrôle et la configuration commune du plan de données. Lorsque vous créez une ressource HostedCluster, vous disposez d'un plan de contrôle entièrement fonctionnel sans nœuds attachés. Une ressource NodePool est un ensemble évolutif de nœuds de travail attaché à une ressource HostedCluster.

La politique de version de l'API s'aligne généralement sur la politique de version de l'API Kubernetes.

La construction et la gestion de conteneurs avec buildah, podman et skopeo permettent d'obtenir des images de conteneurs standard qui incluent des fonctionnalités spécifiquement adaptées au déploiement de conteneurs dans OpenShift Container Platform ou d'autres environnements Kubernetes. Ces outils sont sans démon et peuvent s'exécuter sans privilèges root, ce qui nécessite moins de frais généraux pour les faire fonctionner.

Lorsque vous exécutez vos conteneurs dans OpenShift Container Platform, vous utilisez le moteur de conteneur CRI-O. CRI-O s'exécute sur chaque machine worker et control plane dans un cluster OpenShift Container Platform, mais CRI-O n'est pas encore supporté en tant que runtime autonome en dehors d'OpenShift Container Platform.

L'image de base sur laquelle vous choisissez de construire votre application contient un ensemble de logiciels qui ressemble à un système Linux pour votre application. Lorsque vous créez votre propre image, votre logiciel est placé dans ce système de fichiers et voit ce système de fichiers comme s'il regardait son système d'exploitation. Le choix de cette image de base a un impact majeur sur la sécurité, l'efficacité et l'évolutivité de votre conteneur à l'avenir.

Red Hat propose un nouvel ensemble d'images de base appelées Red Hat Universal Base Images (UBI). Ces images sont basées sur Red Hat Enterprise Linux et sont similaires aux images de base que Red Hat a proposées par le passé, avec une différence majeure : elles sont librement redistribuables sans abonnement à Red Hat. Par conséquent, vous pouvez développer votre application sur des images UBI sans avoir à vous soucier de la manière dont elles sont partagées ou de la nécessité de créer des images différentes pour des environnements différents.

Ces images UBI ont des versions standard, init et minimale. Vous pouvez également utiliser les images de Red Hat Software Collections comme base pour les applications qui reposent sur des environnements d'exécution spécifiques tels que Node.js, Perl ou Python. Des versions spéciales de certaines de ces images de base d'exécution sont appelées images Source-to-Image (S2I). Avec les images S2I, vous pouvez insérer votre code dans un environnement d'image de base prêt à l'exécuter.

Les images S2I sont disponibles pour être utilisées directement depuis l'interface web d'OpenShift Container Platform en sélectionnant Catalog → Developer Catalog, comme le montre la figure suivante :

Figure 7.2. Choisir des images de base S2I pour les applications nécessitant des runtimes spécifiques

Les registres de conteneurs sont l'endroit où vous stockez les images de conteneurs afin de les partager avec d'autres et de les mettre à la disposition de la plateforme sur laquelle elles sont exécutées. Vous pouvez sélectionner de grands registres de conteneurs publics qui proposent des comptes gratuits ou une version premium offrant davantage de stockage et de fonctionnalités spéciales. Vous pouvez également installer votre propre registre qui peut être exclusif à votre organisation ou partagé sélectivement avec d'autres.

Pour obtenir des images Red Hat et des images de partenaires certifiés, vous pouvez puiser dans le Red Hat Registry. Le Red Hat Registry est représenté par deux emplacements : registry.access.redhat.com red Hat Registry, qui n'est pas authentifié et qui est obsolète, et registry.redhat.io, qui nécessite une authentification. Vous pouvez en savoir plus sur les images Red Hat et les images des partenaires dans le Red Hat Registry à partir de la section Images de conteneurs du catalogue de l'écosystème Red Hat. En plus de répertorier les images de conteneurs Red Hat, le catalogue présente également des informations détaillées sur le contenu et la qualité de ces images, y compris des scores de santé basés sur les mises à jour de sécurité appliquées.

Les grands registres publics comprennent Docker Hub et Quay.io. Le registre Quay.io est détenu et géré par Red Hat. De nombreux composants utilisés dans OpenShift Container Platform sont stockés dans Quay.io, notamment les images de conteneurs et les opérateurs utilisés pour déployer OpenShift Container Platform elle-même. Quay.io permet également de stocker d'autres types de contenu, notamment les graphiques Helm.

Si vous souhaitez disposer de votre propre registre de conteneurs, OpenShift Container Platform inclut un registre de conteneurs privé qui est installé avec OpenShift Container Platform et fonctionne sur son cluster. Red Hat propose également une version privée du registre Quay.io appelée Red Hat Quay. Red Hat Quay comprend la réplication géographique, les déclencheurs de construction Git, l'analyse d'images Clair et de nombreuses autres fonctionnalités.

Tous les registres mentionnés ici peuvent exiger des informations d'identification pour télécharger des images à partir de ces registres. Certains de ces identifiants sont présentés à l'échelle du cluster par OpenShift Container Platform, tandis que d'autres peuvent être attribués à des individus.

Alors que l'image du conteneur est l'unité de base de Docker, les unités de base avec lesquelles Kubernetes travaille sont appelées pods. Les pods représentent l'étape suivante dans la construction d'une application. Un pod peut contenir un ou plusieurs conteneurs. L'essentiel est que le pod soit l'unité unique que vous déployez, mettez à l'échelle et gérez.

L'évolutivité et les espaces de noms sont probablement les principaux éléments à prendre en compte pour déterminer ce qu'il faut mettre dans un pod. Pour faciliter le déploiement, vous pouvez vouloir déployer un conteneur dans un pod et y inclure son propre conteneur de journalisation et de surveillance. Plus tard, lorsque vous ferez fonctionner le pod et que vous aurez besoin de mettre à l'échelle une instance supplémentaire, ces autres conteneurs seront mis à l'échelle en même temps que lui. Pour les espaces de noms, les conteneurs d'un module partagent les mêmes interfaces réseau, les mêmes volumes de stockage partagés et les mêmes limites de ressources, telles que la mémoire et l'unité centrale, ce qui facilite la gestion du contenu du module en tant qu'unité unique. Les conteneurs d'un pod peuvent également communiquer entre eux en utilisant des communications inter-processus standard, telles que les sémaphores System V ou la mémoire partagée POSIX.

Alors que les pods individuels représentent une unité évolutive dans Kubernetes, un service permet de regrouper un ensemble de pods pour créer une application complète et stable capable d'effectuer des tâches telles que l'équilibrage de charge. Un service est également plus permanent qu'un pod, car il reste disponible à partir de la même adresse IP jusqu'à ce que vous le supprimiez. Lorsque le service est utilisé, il est demandé par son nom et le cluster OpenShift Container Platform résout ce nom en adresses IP et ports permettant d'atteindre les pods qui composent le service.

Par nature, les applications conteneurisées sont séparées des systèmes d'exploitation sur lesquels elles s'exécutent et, par extension, de leurs utilisateurs. Une partie de votre manifeste Kubernetes décrit comment exposer l'application aux réseaux internes et externes en définissant des stratégies réseau qui permettent un contrôle fin de la communication avec vos applications conteneurisées. Pour connecter des requêtes entrantes pour HTTP, HTTPS et d'autres services provenant de l'extérieur de votre cluster à des services à l'intérieur de votre cluster, vous pouvez utiliser une ressource Ingress ressource.

Si votre conteneur nécessite un stockage sur disque au lieu d'un stockage de base de données, qui peut être fourni par un service, vous pouvez ajouter des volumes à vos manifestes pour mettre ce stockage à la disposition de vos pods. Vous pouvez configurer les manifestes pour créer des volumes persistants (PV) ou créer dynamiquement des volumes qui sont ajoutés à vos définitions Pod.

Après avoir défini un groupe de pods qui composent votre application, vous pouvez définir ces pods dans Deployment et DeploymentConfig objets.

Ensuite, réfléchissez à la manière dont votre type d'application influe sur la façon de l'exécuter.

Kubernetes définit différents types de charges de travail qui conviennent à différents types d'applications. Pour déterminer la charge de travail appropriée à votre application, déterminez si l'application est.. :

L'application que vous écrivez peut avoir besoin de composants de support, comme une base de données ou un composant de journalisation. Pour répondre à ce besoin, vous pourriez être en mesure d'obtenir le composant requis à partir des catalogues suivants qui sont disponibles dans la console web d'OpenShift Container Platform :

Vous pouvez configurer les opérateurs et les modèles de support en fonction des besoins spécifiques de votre équipe de développement, puis les rendre disponibles dans les espaces de noms dans lesquels vos développeurs travaillent. De nombreuses personnes ajoutent des modèles partagés à l'espace de noms openshift car il est accessible depuis tous les autres espaces de noms.

Les manifestes Kubernetes vous permettent de créer une image plus complète des composants qui constituent vos applications Kubernetes. Vous écrivez ces manifestes sous forme de fichiers YAML et vous les déployez en les appliquant au cluster, par exemple en exécutant la commande oc apply.

À ce stade, envisagez des moyens d'automatiser votre processus de développement de conteneurs. Idéalement, vous avez une sorte de pipeline CI qui construit les images et les pousse vers un registre. En particulier, un pipeline GitOps intègre votre développement de conteneurs avec les dépôts Git que vous utilisez pour stocker les logiciels nécessaires à la création de vos applications.

Le flux de travail jusqu'à ce point peut ressembler à ce qui suit :

La liste suivante décrit les principales caractéristiques du système d'exploitation RHCOS :

Pour les systèmes RHCOS, la disposition du système de fichiers rpm-ostree présente les caractéristiques suivantes :

RHCOS est conçu pour se déployer sur un cluster OpenShift Container Platform avec un minimum de configuration de la part de l'utilisateur. Dans sa forme la plus basique, cela consiste à :

Parce que les systèmes RHCOS dans OpenShift Container Platform sont conçus pour être entièrement gérés à partir du cluster OpenShift Container Platform par la suite, il est déconseillé de modifier directement une machine RHCOS. Bien qu'un accès direct limité au cluster de machines RHCOS puisse être réalisé à des fins de débogage, vous ne devriez pas configurer directement les systèmes RHCOS. Au lieu de cela, si vous avez besoin d'ajouter ou de modifier des fonctionnalités sur vos nœuds OpenShift Container Platform, envisagez d'apporter des modifications de la manière suivante :

Voici des exemples de personnalisations que vous pouvez effectuer dès le premier jour :

Pour accomplir ces tâches, vous pouvez augmenter le processus openshift-install pour inclure des objets supplémentaires tels que les objets MachineConfig. Les procédures qui aboutissent à la création de configurations de machines peuvent être transmises à l'opérateur de configuration de machines une fois que la grappe est en place.

Les différences entre les installations RHCOS pour OpenShift Container Platform sont basées sur le fait que vous déployez sur une infrastructure provisionnée par le programme d'installation ou par l'utilisateur :

La fonction Ignition ne fonctionne que lorsque le système RHCOS est configuré pour la première fois. Ensuite, les configurations d'allumage peuvent être fournies ultérieurement en utilisant la configuration de la machine.

Ignition est l'utilitaire utilisé par RHCOS pour manipuler les disques lors de la configuration initiale. Il effectue des tâches courantes sur les disques, notamment le partitionnement des disques, le formatage des partitions, l'écriture de fichiers et la configuration des utilisateurs. Au premier démarrage, Ignition lit sa configuration à partir du média d'installation ou de l'emplacement que vous avez spécifié et applique la configuration aux machines.

Que vous installiez votre cluster ou que vous y ajoutiez des machines, Ignition effectue toujours la configuration initiale des machines du cluster OpenShift Container Platform. La majeure partie de la configuration réelle du système se produit sur chaque machine elle-même. Pour chaque machine, Ignition prend l'image RHCOS et démarre le noyau RHCOS. Les options de la ligne de commande du noyau identifient le type de déploiement et l'emplacement du disque RAM initial activé par Ignition (initramfs).

Le plugin d'admission à la mutation est invoqué pendant la phase de mutation du processus d'admission, ce qui permet de modifier le contenu de la ressource avant qu'elle ne soit conservée. Un exemple de webhook qui peut être appelé par le plugin d'admission à la mutation est la fonctionnalité Pod Node Selector, qui utilise une annotation sur un espace de noms pour trouver un sélecteur d'étiquette et l'ajouter à la spécification du pod.

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration 1
metadata:
  name: <webhook_name> 2
webhooks:
- name: <webhook_name> 3
  clientConfig: 4
    service:
      namespace: default 5
      name: kubernetes 6
      path: <webhook_url> 7
    caBundle: <ca_signing_certificate> 8
  rules: 9
  - operations: 10
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 11
  sideEffects: None

Un plugin d'admission validant est invoqué pendant la phase de validation du processus d'admission. Cette phase permet d'appliquer des invariants à des ressources API particulières afin de s'assurer que la ressource ne sera pas modifiée à nouveau. Le Pod Node Selector est également un exemple de webhook appelé par le plugin de validation d'admission, pour s'assurer que tous les champs nodeSelector sont contraints par les restrictions du sélecteur de nœuds sur l'espace de noms.

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration 1
metadata:
  name: <webhook_name> 2
webhooks:
- name: <webhook_name> 3
  clientConfig: 4
    service:
      namespace: default  5
      name: kubernetes 6
      path: <webhook_url> 7
    caBundle: <ca_signing_certificate> 8
  rules: 9
  - operations: 10
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 11
  sideEffects: Unknown