Architecture

Bien que les images de conteneurs et les conteneurs qui s’en sortent soient les principaux éléments de base du développement d’applications modernes, les exécuter à 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 pour automatiser le déploiement, l’échelle et la gestion des applications conteneurisées. Le concept général de Kubernetes est assez simple:

En seulement quelques années, Kubernetes a connu une adoption massive de 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 offre de nombreux avantages par rapport aux méthodes de déploiement traditionnelles. Lorsque les applications devaient autrefois ê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 eux. La création d’applications conteneurisées offre de nombreux avantages.

La société OpenShift Dedicated fournit des améliorations prêtes à l’entreprise à Kubernetes, y compris les améliorations 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 plate-forme ou les processus de déploiement. Les outils et processus de gestion de plate-forme puissants et flexibles sont des avantages importants qu’offre OpenShift Dedicated 4. Les sections suivantes décrivent certaines caractéristiques et avantages uniques d’OpenShift Dedicated.

L’architecture de la CFP comprend les services aux producteurs et les services aux consommateurs. En utilisant la CFP, les consommateurs peuvent accéder aux services aux producteurs en privé à partir de l’intérieur de leur réseau VPC. De même, il permet aux producteurs d’héberger des services dans leurs propres réseaux VPC séparés et d’offrir une connexion privée à leurs consommateurs.

L’image suivante illustre la façon dont les SRE Red HAT et d’autres grappes internes d’accès aux ressources et de soutien ont été créées à l’aide de la CFP.

Figure 3.1. Aperçu de l’architecture de la CFP

View larger image

Dans un cluster Kubernetes, les nœuds de travail exécutent et gèrent les charges de travail réelles demandées par les utilisateurs de Kubernetes. Les nœuds de travail annoncent leur capacité et le planificateur, qui est un service d’avion de contrôle, détermine sur quels nœuds commencer les pods et les conteneurs. Les services importants suivants s’appliquent à chaque nœud de travail:

Dans OpenShift Dedicated, les ensembles de machines de calcul contrôlent les machines de calcul, qui sont assignées au rôle de la machine de travail. Les machines avec le rôle du travailleur propulsent les charges de travail qui sont régies par un pool de machines spécifique qui les met à l’échelle automatique. Étant donné qu’OpenShift Dedicated a la capacité de prendre en charge plusieurs types de machines, les machines ayant le rôle de travailleur sont classées comme machines de calcul. Dans cette version, les termes machine de travail et machine de calcul sont utilisés de manière interchangeable parce que le seul type par défaut de machine de calcul est la machine ouvrier. Dans les versions futures d’OpenShift Dedicated, différents types de machines de calcul, telles que les machines d’infrastructure, pourraient être utilisés par défaut.

Dans un cluster Kubernetes, les nœuds maîtres exécutent des services qui sont nécessaires pour contrôler le cluster Kubernetes. Dans OpenShift Dedicated, le plan de contrôle est composé de machines de plan de contrôle qui ont un rôle maître de machine. Ils contiennent plus que les services Kubernetes pour la gestion du cluster OpenShift dédié.

Dans la plupart des clusters dédiés à OpenShift, les machines de plan de contrôle sont définies par une série de ressources d’API automatiques autonomes. Les plans de contrôle sont 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 du contrôleur Kubernetes et le planificateur Kubernetes.

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

Certains de ces services sur les machines de plan de contrôle fonctionnent comme des services système, tandis que d’autres fonctionnent comme des gousses statiques.

Les services système sont appropriés pour les services dont vous avez besoin pour toujours proposer ce système en particulier peu de temps après son démarrage. Dans le cas des machines de contrôle, celles-ci incluent sshd, ce qui permet la connexion à distance. Il comprend également des services tels que:

CRI-O et Kubelet doivent fonctionner directement sur l’hôte en tant que services système, car ils doivent être exécutés avant de pouvoir exécuter d’autres conteneurs.

Les pods de plan de contrôle installateur* et révision-pruner-* doivent s’exécuter avec des autorisations root car ils écrivent dans le répertoire /etc/kubernetes, qui appartient à l’utilisateur root. Ces pods se trouvent dans les espaces de noms suivants:

Le gestionnaire de cycle de vie de l’opérateur (OLM) et OperatorHub sont des composants par défaut dans OpenShift Dedicated qui aident à gérer les applications natives 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édiée OpenShift, les administrateurs ayant le rôle d’administrateur dédié et les utilisateurs autorisés peuvent sélectionner Opérateurs à installer à partir des catalogues d’opérateurs. Après avoir installé un opérateur depuis OperatorHub, il peut être mis à disposition dans le monde entier ou dans des espaces de noms spécifiques pour s’exécuter dans des applications utilisateur.

Des sources de catalogue par défaut sont disponibles qui incluent les opérateurs Red Hat, les opérateurs certifiés et les opérateurs communautaires. Les administrateurs dotés du rôle d’administrateur dédié 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 aider les opérateurs personnalisés qui profitent également des fonctionnalités OLM. Leur opérateur peut ensuite être groupé et ajouté à une source de catalogue personnalisée, qui peut être ajoutée à un cluster et mise à la disposition des utilisateurs.

En utilisant etcd, vous pouvez bénéficier de plusieurs façons:

Afin d’assurer une approche fiable de la configuration et de la gestion des clusters, etcd utilise l’opérateur etcd. L’opérateur simplifie l’utilisation de etcd sur une plate-forme de conteneurs Kubernetes comme OpenShift Dedicated. Avec l’opérateur etcd, vous pouvez créer ou supprimer des membres etcd, redimensionner des clusters, effectuer des sauvegardes et mettre à niveau etcd.

L’opérateur etcd observe, analyse et agit:

etcd détient l’état du cluster, qui est constamment mis à jour. Cet état est constamment persisté, ce qui conduit à un nombre élevé de petits changements à haute fréquence. En conséquence, Red Hat Site Reliability Engineering (SRE) soutient le membre du cluster etcd avec des E/S rapides et à faible latence.

Compute Unified Device Architecture (CUDA) est une plate-forme informatique parallèle et un modèle de programmation développé par NVIDIA pour l’informatique générale sur les GPU.

Le flux est une séquence d’opérations qui s’exécute en ordre de problème sur le GPU. Les commandes CUDA sont généralement exécutées de manière séquentielle dans un flux par défaut et une tâche ne démarre pas tant qu’une tâche précédente n’est pas terminée.

Le traitement asynchrone des opérations sur différents flux permet l’exécution parallèle des tâches. La tâche émise dans un flux s’exécute avant, pendant ou après qu’une autre tâche soit émise dans un autre flux. Cela permet au GPU d’exécuter plusieurs tâches simultanément dans aucun ordre prescrit, ce qui permet d’améliorer les performances.

GPU time-slicing interleva les charges de travail programmées sur les GPU surchargés lorsque vous exécutez plusieurs applications CUDA.

Il est possible de définir un ensemble de répliques pour un GPU, chacun pouvant être distribué indépendamment à un pod pour exécuter des charges de travail. Contrairement au GPU multiinstance (MIG), il n’y a pas d’isolement de mémoire ou de défaut entre les répliques, mais pour certaines charges de travail, c’est mieux que de ne pas partager du tout. En interne, le chronométrage GPU est utilisé pour multiplexer les charges de travail à partir de répliques du même GPU sous-jacent.

Il est possible d’appliquer une configuration par défaut à l’échelle du cluster. Il est également possible d’appliquer des configurations spécifiques aux nœuds. À titre d’exemple, vous pouvez appliquer une configuration de découpage de temps uniquement aux nœuds dotés de GPU Tesla T4 et ne pas modifier les nœuds avec d’autres modèles GPU.

Il est possible de combiner ces deux approches en appliquant une configuration par défaut à l’échelle du cluster, puis d’étiqueter les nœuds pour donner à ces nœuds une configuration spécifique à chaque nœud.

CUDA Multi-Process Service (MPS) permet à un seul GPU d’utiliser plusieurs processus CUDA. Les processus s’exécutent en parallèle sur le GPU, éliminant ainsi la saturation des ressources de calcul GPU. Le MPS permet également l’exécution simultanée, ou le chevauchement, des opérations du noyau et de la copie de mémoire à partir de différents processus pour améliorer l’utilisation.

En utilisant le GPU Multi-instance (MIG), vous pouvez diviser les unités de calcul GPU et la mémoire en plusieurs instances MIG. Chacune de ces instances représente un périphérique GPU autonome du point de vue du système et peut être connectée à n’importe quelle application, conteneur ou machine virtuelle fonctionnant sur le nœud. Le logiciel qui utilise le GPU traite chacune de ces instances MIG comme un GPU individuel.

Le MIG est utile lorsque vous avez une application qui ne nécessite pas la pleine puissance d’un GPU entier. La fonctionnalité MIG de la nouvelle architecture NVIDIA Ampere vous permet de diviser vos ressources matérielles en plusieurs instances GPU, dont chacune est disponible pour le système d’exploitation en tant que GPU indépendant compatible CUDA.

La version 1.7.0 et supérieure de NVIDIA GPU Operator fournit une prise en charge MIG pour les cartes A100 et A30 Ampere. Ces instances GPU sont conçues pour prendre en charge jusqu’à sept applications CUDA indépendantes afin qu’elles fonctionnent complètement isolées avec des ressources matérielles dédiées.

Les machines virtuelles (VM) peuvent accéder directement à un seul GPU physique à l’aide de NVIDIA vGPU. Il est possible de créer des GPU virtuels qui peuvent être partagés par des machines virtuelles à travers l’entreprise et accessibles par d’autres appareils.

Cette capacité combine la puissance des performances GPU avec les avantages de gestion et de sécurité fournis par vGPU. Les avantages supplémentaires fournis par vGPU comprennent la gestion proactive et la surveillance de votre environnement de VM, l’équilibrage de la charge de travail pour les charges de travail mixtes VDI et calcul, et le partage des ressources sur plusieurs machines virtuelles.

La construction et la gestion de conteneurs avec buildah, podman et skopeo se traduit par des images de conteneurs standard de l’industrie qui incluent des fonctionnalités spécifiquement réglées pour le déploiement de conteneurs dans les environnements OpenShift Dedicated ou autres Kubernetes. Ces outils sont sans démon et peuvent fonctionner sans privilèges root, nécessitant moins de frais généraux pour les exécuter.

Lorsque vous exécutez finalement vos conteneurs dans OpenShift Dedicated, vous utilisez le moteur de conteneur CRI-O. CRI-O fonctionne sur chaque machine d’avion de travail et de contrôle dans un cluster dédié OpenShift, mais CRI-O n’est pas encore pris en charge en tant que temps d’exécution autonome en dehors d’OpenShift Dedicated.

L’image de base sur laquelle vous choisissez de construire votre application contient un ensemble de logiciels qui ressemble à un système Linux à votre application. Lorsque vous construisez 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 la mise à niveau de votre conteneur à l’avenir.

Le Red Hat fournit 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 offertes par Red Hat dans le passé, avec une différence majeure : elles sont librement redistribuables sans abonnement Red Hat. En conséquence, vous pouvez construire votre application sur des images UBI sans avoir à vous soucier de la façon dont elles sont partagées ou de la nécessité de créer différentes images pour différents environnements.

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

Les images S2I sont disponibles pour vous à utiliser directement à partir de l’interface Web dédiée OpenShift. Dans la perspective Développeur, accédez à la vue +Ajouter et dans la tuile du catalogue des développeurs, visualisez tous les services disponibles dans le catalogue des développeurs.

Figure 6.2. Choisissez des images de base S2I pour les applications qui ont besoin d’exécutions spécifiques

View larger image

Les registres de conteneurs sont l’endroit où vous stockez des images de conteneurs afin que vous puissiez les partager avec d’autres et les mettre à la disposition de la plate-forme où ils finissent par fonctionner. Il est possible de sélectionner de grands registres de conteneurs publics qui offrent des comptes gratuits ou une version premium offrant plus de stockage et de fonctionnalités spéciales. En outre, vous pouvez installer votre propre registre qui peut être exclusif à votre organisation ou partagé de manière sélective avec d’autres personnes.

Afin d’obtenir des images Red Hat et des images de partenaires certifiés, vous pouvez tirer du Registre Red Hat. Le Registre Red Hat est représenté par deux emplacements: Registry.access.redhat.com, qui n’est pas authentifié et déprécié, et Registry.redhat.io, qui nécessite une authentification. En savoir plus sur les images Red Hat et les images partenaires dans le Registre Red Hat à partir de la section Images Container du catalogue de l’écosystème Red Hat. En plus de la liste des images de conteneurs Red Hat, il montre également des informations détaillées sur le contenu et la qualité de ces images, y compris les 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 Dedicated sont stockés dans Quay.io, y compris les images de conteneurs et les opérateurs qui sont utilisés pour déployer OpenShift Dedicated lui-même. Le Quay.io offre également les moyens de stocker d’autres types de contenu, y compris les graphiques Helm.

Dans le cas où vous voulez votre propre registre de conteneurs privé, OpenShift Dedicated comprend un registre de conteneurs privé qui est installé avec OpenShift Dedicated et fonctionne sur son cluster. Le Red Hat propose également une version privée du registre Quay.io appelé Red Hat Quay. Le Red Hat Quay inclut la réplication géographique, les déclencheurs Git build, le balayage d’image clair et de nombreuses autres fonctionnalités.

L’ensemble des registres mentionnés ici peut nécessiter des informations d’identification pour télécharger des images à partir de ces registres. Certaines de ces informations d’identification sont présentées à l’échelle du cluster à partir d’OpenShift Dedicated, tandis que d’autres informations d’identification peuvent être attribuées à des individus.

Alors que l’image du conteneur est l’unité de base avec docker, les unités de base avec lesquelles Kubernetes fonctionne sont appelées pods. Les pods représentent la prochaine étape dans la création d’une application. La gousse peut contenir un ou plusieurs contenants. La clé est que le pod est 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 à considérer lors de la détermination de ce qui se passe dans un pod. Afin de faciliter votre déploiement, vous voudrez peut-être déployer un conteneur dans un pod et inclure son propre conteneur d’enregistrement et de surveillance dans le pod. Ensuite, lorsque vous exécutez la pod et que vous devez mettre à l’échelle une instance supplémentaire, ces autres conteneurs sont mis à l’échelle avec elle. Dans le cas des espaces de noms, les conteneurs d’un pod partagent les mêmes interfaces réseau, volumes de stockage partagés et limitations de ressources, tels que la mémoire et le CPU, ce qui facilite la gestion du contenu du pod en tant qu’unité unique. Les conteneurs dans un pod peuvent également communiquer les uns avec les autres en utilisant des communications inter-processus standard, telles que les sémaphores du système V ou la mémoire partagée POSIX.

Alors que les gousses individuelles représentent une unité évolutive dans Kubernetes, un service fournit un moyen de regrouper un ensemble de gousses pour créer une application complète et stable qui peut accomplir des tâches telles que l’équilibrage de charge. Le service est également plus permanent qu’un pod car le service reste disponible à partir de la même adresse IP jusqu’à ce que vous le supprimiez. Lorsque le service est utilisé, il est demandé par nom et le cluster OpenShift Dedicated résout ce nom dans les adresses IP et les ports où vous pouvez atteindre les pods qui composent le service.

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

Lorsque votre conteneur nécessite un stockage sur disque au lieu d’un stockage de base de données, qui peut être fourni via un service, vous pouvez ajouter des volumes à vos manifestes pour que ce stockage soit disponible à vos pods. Configurez 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 les objets Déploiement et DéploiementConfig.

Ensuite, considérez comment votre type d’application influence comment l’exécuter.

Kubernetes définit différents types de charges de travail qui conviennent à différents types d’applications. Afin de déterminer la charge de travail appropriée pour votre demande, considérez si la demande est:

L’application que vous écrivez peut avoir besoin de composants de support, comme une base de données ou un composant de journalisation. Afin de 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édiée OpenShift:

Les opérateurs et les modèles supportés peuvent être configurés selon les besoins spécifiques de votre équipe de développement, puis les rendre disponibles dans les espaces de noms dans lesquels vos développeurs travaillent. Beaucoup de gens ajoutent des modèles partagés à l’espace de noms openshift car il est accessible depuis tous les autres espaces de noms.

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

À 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 le développement de vos conteneurs aux dépôts Git que vous utilisez pour stocker le logiciel nécessaire à la construction de vos applications.

Le flux de travail à ce stade pourrait ressembler à:

Le plugin d’admission mutant est invoqué pendant la phase de mutation du processus d’admission, ce qui permet de modifier le contenu de la ressource avant qu’il ne soit persisté. La fonction Pod Node Selector, qui utilise une annotation sur un espace de noms pour trouver un sélecteur d’étiquettes et l’ajouter à la spécification du pod, est un exemple de webhook qui peut être appelé via le plugin d’admission mutant.

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration 
metadata:
  name: <webhook_name> 
webhooks:
- name: <webhook_name> 
  clientConfig: 
    service:
      namespace: default 
      name: kubernetes 
      path: <webhook_url> 
    caBundle: <ca_signing_certificate> 
  rules: 
  - operations: 
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 
  sideEffects: None

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration 

metadata:
  name: <webhook_name> 

webhooks:
- name: <webhook_name> 

  clientConfig: 

    service:
      namespace: default 

      name: kubernetes 

      path: <webhook_url> 

    caBundle: <ca_signing_certificate> 

  rules: 

  - operations: 

    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 

  sideEffects: None

La validation d’un plugin d’admission est invoquée pendant la phase de validation du processus d’admission. Cette phase permet l’application des invariants sur des ressources API particulières pour s’assurer que la ressource ne change plus. Le Pod Node Selector est également un exemple de webhook qui est appelé par le plugin d’admission de validation, pour s’assurer que tous les champs nodeSelector sont limités par les restrictions du sélecteur de nœuds sur l’espace de noms.

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration 
metadata:
  name: <webhook_name> 
webhooks:
- name: <webhook_name> 
  clientConfig: 
    service:
      namespace: default  
      name: kubernetes 
      path: <webhook_url> 
    caBundle: <ca_signing_certificate> 
  rules: 
  - operations: 
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 
  sideEffects: Unknown

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration 

metadata:
  name: <webhook_name> 

webhooks:
- name: <webhook_name> 

  clientConfig: 

    service:
      namespace: default  

      name: kubernetes 

      path: <webhook_url> 

    caBundle: <ca_signing_certificate> 

  rules: 

  - operations: 

    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 

  sideEffects: Unknown