Red Hat SummitIntroduction à ROSA
Aperçu de Red Hat OpenShift Service sur l’architecture AWS
Résumé
Chapitre 1. Comprendre la ROSA
Apprenez-en plus sur Red Hat OpenShift Service sur AWS (ROSA), en interagissant avec ROSA en utilisant les outils Red Hat OpenShift Cluster Manager et l’interface de ligne de commande (CLI), l’expérience de consommation et l’intégration avec les services Amazon Web Services (AWS).
1.1. À propos de ROSA
La ROSA est une plateforme d’applications clé en main entièrement gérée qui vous permet de vous concentrer sur la fourniture de valeur à vos clients en créant et en déployant des applications. Les experts en ingénierie de fiabilité du site Red Hat (SRE) gèrent la plate-forme sous-jacente afin que vous n’ayez pas à vous soucier de la complexité de la gestion de l’infrastructure. La ROSA assure une intégration transparente avec Amazon CloudWatch, AWS Identity and Access Management (IAM), Amazon Virtual Private Cloud (VPC) et une large gamme de services AWS supplémentaires afin d’accélérer la création et la fourniture d’expériences différenciées à vos clients.
Abonnez-vous au service directement depuis votre compte AWS. Après avoir créé des clusters, vous pouvez utiliser vos clusters avec la console Web OpenShift, le ROSA CLI, ou via Red Hat OpenShift Cluster Manager.
Les mises à jour OpenShift avec de nouvelles versions de fonctionnalités et une source commune partagée pour l’alignement sur OpenShift Container Platform. La ROSA prend en charge les mêmes versions d’OpenShift que Red Hat OpenShift Dedicated et OpenShift Container Platform pour atteindre la cohérence de la version.
En savoir plus sur l’installation de ROSA, consultez Installing Red Hat OpenShift Service sur AWS (ROSA) interactif.
1.2. Facturation et tarification
Le service Red Hat OpenShift sur AWS est facturé directement sur votre compte Amazon Web Services (AWS). La tarification ROSA est basée sur la consommation, avec des engagements annuels ou des engagements de trois ans pour une plus grande réduction. Le coût total de ROSA se compose de deux composantes:
- Frais de service ROSA
- Frais d’infrastructure AWS
Consultez le Service OpenShift Red Hat sur AWS Pricing page sur le site AWS pour plus de détails.
1.3. Débuter
Afin de commencer le déploiement de votre cluster, assurez-vous que votre compte AWS répond aux conditions préalables, vous disposez d’un compte Red Hat prêt et suivez les procédures décrites dans Démarrer avec Red Hat OpenShift Service sur AWS.
Ressources supplémentaires
Chapitre 2. Définition des politiques et des services
2.1. À propos de la disponibilité pour Red Hat OpenShift Service sur AWS
La disponibilité et l’évitement des catastrophes sont des aspects extrêmement importants de toute plate-forme d’application. Bien que Red Hat OpenShift Service sur AWS (ROSA) offre de nombreuses protections contre les défaillances à plusieurs niveaux, les applications déployées par le client doivent être configurées de manière appropriée pour une haute disponibilité. Afin de tenir compte des pannes qui pourraient survenir chez les fournisseurs de cloud, d’autres options sont disponibles, telles que le déploiement d’un cluster sur plusieurs zones de disponibilité et la maintenance de plusieurs clusters avec des mécanismes de basculement.
2.1.1. Les points d’échec potentiels
Le service OpenShift Red Hat sur AWS (ROSA) offre de nombreuses fonctionnalités et options pour protéger vos charges de travail contre les temps d’arrêt, mais les applications doivent être conçues de manière appropriée pour tirer parti de ces fonctionnalités.
La ROSA peut vous aider à vous protéger contre de nombreux problèmes communs de Kubernetes en ajoutant le support de l’ingénierie de fiabilité du site Red Hat (SRE) et la possibilité de déployer un cluster de zones de disponibilité multiple, mais il existe plusieurs façons dont un conteneur ou une infrastructure peut encore échouer. En comprenant les points d’échec potentiels, vous pouvez comprendre les risques et concevoir de manière appropriée vos applications et vos clusters pour être aussi résilients que nécessaire à chaque niveau spécifique.
La panne peut se produire à plusieurs niveaux d’infrastructures et de composants de clusters.
2.1.1.1. Défaillance du conteneur ou de la gousse
D’après la conception, les gousses sont censées exister pendant une courte période. La mise à l’échelle appropriée des services de sorte que plusieurs instances de vos pods d’application sont en cours d’exécution peut protéger contre les problèmes avec n’importe quel pod ou conteneur individuel. Le programmeur de nœud OpenShift peut également s’assurer que ces charges de travail sont réparties entre différents nœuds de travail afin d’améliorer encore la résilience.
Lors de la prise en compte des éventuelles défaillances de pod, il est également important de comprendre comment le stockage est attaché à vos applications. Les volumes persistants uniques attachés à des pods uniques ne peuvent pas tirer parti de tous les avantages de la mise à l’échelle des pod, tandis que les bases de données reproduites, les services de base de données ou le stockage partagé peuvent.
Afin d’éviter les perturbations de vos applications lors de la maintenance planifiée, comme les mises à niveau, il est important de définir un budget de perturbation de Pod. Ceux-ci font partie de l’API Kubernetes et peuvent être gérés avec des commandes oc telles que d’autres types d’objets. Ils permettent de spécifier les contraintes de sécurité sur les gousses pendant les opérations, telles que l’évacuation d’un nœud pour l’entretien.
2.1.1.2. Défaillance du nœud ouvrier
Les nœuds ouvriers sont les machines virtuelles qui contiennent vos pods d’application. Par défaut, un cluster ROSA dispose d’un minimum de deux nœuds de travail pour un cluster de zone de disponibilité unique. En cas de défaillance d’un nœud ouvrier, les gousses sont transférées vers des nœuds de travail fonctionnels, tant qu’il y a suffisamment de capacité, jusqu’à ce que tout problème avec un nœud existant soit résolu ou que le nœud soit remplacé. Le plus grand nombre de nœuds de travail signifie une plus grande protection contre les pannes d’un seul nœud et assure une capacité de cluster appropriée pour les gousses reprogrammées en cas de défaillance du nœud.
Lors de la prise en compte des défaillances possibles des nœuds, il est également important de comprendre comment le stockage est affecté. Les volumes EFS ne sont pas affectés par la défaillance des nœuds. Cependant, les volumes EBS ne sont pas accessibles s’ils sont connectés à un nœud qui échoue.
2.1.1.3. Défaillance du cluster
Les clusters ROSA monoAZ ont au moins trois avions de contrôle et deux nœuds d’infrastructure dans la même zone de disponibilité (AZ) dans le sous-réseau privé.
Les clusters ROSA multi-AZ ont au moins trois nœuds de plan de contrôle et trois nœuds d’infrastructure qui sont préconfigurés pour une haute disponibilité, soit dans une seule zone, soit sur plusieurs zones, selon le type de cluster que vous avez sélectionné. Le plan de contrôle et les nœuds d’infrastructure ont la même résilience que les nœuds ouvriers, avec l’avantage supplémentaire d’être entièrement géré par Red Hat.
Dans le cas d’une panne complète du plan de contrôle, les API OpenShift ne fonctionneront pas, et les pods de nœuds existants ne sont pas affectés. Cependant, s’il y a aussi une panne de pod ou de nœud en même temps, les plans de contrôle doivent récupérer avant que de nouveaux gousses ou nœuds puissent être ajoutés ou programmés.
L’ensemble des services fonctionnant sur les nœuds d’infrastructure sont configurés par Red Hat pour être hautement disponibles et distribués à travers les nœuds d’infrastructure. En cas de panne complète de l’infrastructure, ces services ne sont pas disponibles jusqu’à ce que ces nœuds aient été récupérés.
2.1.1.4. Défaillance de la zone
La défaillance de la zone AWS affecte tous les composants virtuels, tels que les nœuds de travail, le blocage ou le stockage partagé, et les équilibreurs de charge spécifiques à une seule zone de disponibilité. Afin de se protéger contre une défaillance de zone, ROSA offre l’option pour les clusters qui sont répartis sur trois zones de disponibilité, connues sous le nom de clusters de zones de disponibilité multiples. Les charges de travail apatrides existantes sont redistribuées dans des zones non affectées en cas de panne, tant qu’il y a suffisamment de capacité.
2.1.1.5. Défaillance de stockage
Lorsque vous avez déployé une application étatique, le stockage est un composant essentiel et doit être pris en compte lors de la réflexion sur la haute disponibilité. Le PV de stockage d’un seul bloc est incapable de résister aux pannes même au niveau de la pod. Les meilleurs moyens de maintenir la disponibilité du stockage sont d’utiliser des solutions de stockage répliquées, un stockage partagé qui n’est pas affecté par des pannes, ou un service de base de données indépendant du cluster.
2.2. Aperçu des responsabilités pour Red Hat OpenShift Service sur AWS
Cette documentation décrit Red Hat, Amazon Web Services (AWS) et les responsabilités des clients pour le service géré Red Hat OpenShift sur AWS (ROSA).
2.2.1. Des responsabilités partagées pour Red Hat OpenShift Service sur AWS
Alors que Red Hat et Amazon Web Services (AWS) gèrent le service Red Hat OpenShift sur les services AWS, le client partage certaines responsabilités. Le service OpenShift Red Hat sur les services AWS sont accessibles à distance, hébergés sur des ressources cloud publiques, créés dans des comptes AWS appartenant à des clients, et ont une plate-forme sous-jacente et une sécurité des données qui appartient à Red Hat.
Lorsque le rôle de cluster-admin est ajouté à un utilisateur, consultez les responsabilités et les notes d’exclusion dans l’annexe 4 de l’accord d’entreprise Red Hat (Services d’abonnement en ligne).
| A) Ressources | Gestion des incidents et des opérations | Gestion du changement | Accès et autorisation d’identité | Conformité à la sécurité et à la réglementation | La reprise après sinistre |
|---|---|---|---|---|---|
| Données du client | Client | Client | Client | Client | Client |
| Applications client | Client | Client | Client | Client | Client |
| Les services des développeurs | Client | Client | Client | Client | Client |
| La surveillance de la plate-forme | Chapeau rouge | Chapeau rouge | Chapeau rouge | Chapeau rouge | Chapeau rouge |
| L’exploitation forestière | Chapeau rouge | Chapeau rouge et client | Chapeau rouge et client | Chapeau rouge et client | Chapeau rouge |
| La mise en réseau des applications | Chapeau rouge et client | Chapeau rouge et client | Chapeau rouge et client | Chapeau rouge | Chapeau rouge |
| La mise en réseau de clusters | Chapeau rouge [1] | Chapeau rouge et client [2] | Chapeau rouge et client | Chapeau rouge [1] | Chapeau rouge [1] |
| Gestion des réseaux virtuels | Chapeau rouge et client | Chapeau rouge et client | Chapeau rouge et client | Chapeau rouge et client | Chapeau rouge et client |
| Gestion virtuelle du calcul (plan de contrôle, infrastructure et nœuds ouvriers) | Chapeau rouge | Chapeau rouge | Chapeau rouge | Chapeau rouge | Chapeau rouge |
| La version du cluster | Chapeau rouge | Chapeau rouge et client | Chapeau rouge | Chapeau rouge | Chapeau rouge |
| Gestion des capacités | Chapeau rouge | Chapeau rouge et client | Chapeau rouge | Chapeau rouge | Chapeau rouge |
| Gestion du stockage virtuel | Chapeau rouge | Chapeau rouge | Chapeau rouge | Chapeau rouge | Chapeau rouge |
| Logiciel AWS (services AWS publics) | AWS | AWS | AWS | AWS | AWS |
| Infrastructure mondiale hardware/AWS | AWS | AWS | AWS | AWS | AWS |
- Lorsque le client choisit d’utiliser son propre plugin CNI, la responsabilité revient au client.
- Le client doit configurer son pare-feu pour permettre l’accès aux domaines et ports OpenShift et AWS requis avant que le cluster ne soit mis en place. En savoir plus, voir « Prérequis du pare-feu AWS ».
2.2.3. Examen et notifications des groupes d’action
Les notifications de cluster sont des messages sur l’état, la santé ou les performances de votre cluster.
Les notifications de cluster sont la principale façon dont Red Hat Site Reliability Engineering (SRE) communique avec vous sur la santé de votre cluster géré. Le SRE peut également utiliser des notifications de cluster pour vous inviter à effectuer une action afin de résoudre ou d’empêcher un problème avec votre cluster.
Les propriétaires de clusters et les administrateurs doivent régulièrement examiner et agir les notifications de clusters pour s’assurer que les clusters restent en bonne santé et pris en charge.
Dans l’onglet Historique des clusters de votre cluster, vous pouvez afficher les notifications de cluster dans la console de cloud hybride Red Hat. Par défaut, seul le propriétaire du cluster reçoit des notifications de cluster sous forme d’e-mails. Lorsque d’autres utilisateurs doivent recevoir des e-mails de notification en cluster, ajoutez chaque utilisateur comme contact de notification pour votre cluster.
2.2.3.1. La politique de notification par groupe
Les notifications de cluster sont conçues pour vous tenir informé de la santé de votre cluster et des événements à fort impact qui l’affectent.
La plupart des notifications de cluster sont générées et envoyées automatiquement pour vous assurer que vous êtes immédiatement informé des problèmes ou des changements importants à l’état de votre cluster.
Dans certaines situations, Red Hat Site Reliability Engineering (SRE) crée et envoie des notifications de cluster pour fournir un contexte supplémentaire et des conseils pour un problème complexe.
Les notifications de cluster ne sont pas envoyées pour les événements à faible impact, les mises à jour de sécurité à faible risque, les opérations et la maintenance de routine, ou les problèmes transitoires mineurs qui sont rapidement résolus par SRE.
Les services Red Hat envoient automatiquement des notifications lorsque:
- Les contrôles de surveillance de la santé ou de vérification de l’environnement à distance détectent un problème dans votre cluster, par exemple lorsqu’un nœud de travail a peu d’espace disque.
- Des événements importants du cycle de vie des clusters se produisent, par exemple, lorsque la maintenance ou les mises à niveau programmées commencent, ou que les opérations de cluster sont touchées par un événement, mais ne nécessitent pas d’intervention du client.
- D’importants changements de gestion des clusters se produisent, par exemple, lorsque la propriété de clusters ou le contrôle administratif est transféré d’un utilisateur à un autre.
- L’abonnement à votre cluster est modifié ou mis à jour, par exemple lorsque Red Hat met à jour les conditions d’abonnement ou les fonctionnalités disponibles pour votre cluster.
La SRE crée et envoie des notifications lorsque:
- L’incident entraîne une dégradation ou une panne qui affecte la disponibilité ou les performances de votre cluster, par exemple, votre fournisseur de cloud a une panne régionale. La SRE envoie des notifications ultérieures pour vous informer de l’état d’avancement de la résolution des incidents et lorsque l’incident est résolu.
- Des failles de sécurité, des failles de sécurité ou des activités inhabituelles sont détectées sur votre cluster.
- Le Red Hat détecte que les changements que vous avez apportés sont en train de créer ou peuvent entraîner une instabilité des clusters.
- Le Red Hat détecte que vos charges de travail causent une dégradation des performances ou une instabilité dans votre cluster.
2.2.4. Gestion des incidents et des opérations
Le Red Hat est responsable de la supervision des composants de service requis pour le réseau de plate-forme par défaut. AWS est responsable de la protection de l’infrastructure matérielle qui exécute tous les services offerts dans AWS Cloud. Le client est responsable de la gestion des incidents et des opérations des données d’application client et de tout réseau personnalisé que le client a configuré pour le réseau cluster ou le réseau virtuel.
| A) Ressources | Les responsabilités en matière de service | Les responsabilités du client |
|---|---|---|
| La mise en réseau des applications | Chapeau rouge
|
|
| La mise en réseau de clusters | Chapeau rouge
|
|
| Gestion des réseaux virtuels | Chapeau rouge
|
|
| Gestion du stockage virtuel | Chapeau rouge
|
|
| La surveillance de la plate-forme | Chapeau rouge
| |
| Gestion des incidents | Chapeau rouge
|
|
| Infrastructure et résilience des données | Chapeau rouge
|
|
| Capacité des clusters | Chapeau rouge
| |
| Logiciel AWS (services AWS publics) | AWS
|
|
| Infrastructure mondiale hardware/AWS | AWS
|
|
2.2.4.1. La surveillance de la plate-forme
Les journaux d’audit de plate-forme sont transmis en toute sécurité à un système centralisé d’informations de sécurité et de surveillance des événements (SIEM), où ils peuvent déclencher des alertes configurées à l’équipe SRE et sont également soumis à un examen manuel. Les journaux d’audit sont conservés dans le système SIEM pendant un an. Les journaux d’audit d’un cluster donné ne sont pas supprimés au moment où le cluster est supprimé.
2.2.4.2. Gestion des incidents
L’incident est un événement qui entraîne une dégradation ou une panne d’un ou de plusieurs services Red Hat. L’incident peut être soulevé par un client ou un membre de l’expérience client et de l’engagement (CEE) par le biais d’un dossier d’assistance, directement par le système centralisé de surveillance et d’alerte, ou directement par un membre de l’équipe SRE.
En fonction de l’impact sur le service et le client, l’incident est classé en termes de gravité.
Lors de la gestion d’un nouvel incident, Red Hat utilise le flux de travail général suivant:
- Le premier intervenant de SRE est alerté d’un nouvel incident et commence une enquête initiale.
- Après l’enquête initiale, l’incident est assigné à un responsable de l’incident, qui coordonne les efforts de rétablissement.
- Le responsable de l’incident gère toute communication et coordination autour de la récupération, y compris les notifications pertinentes et les mises à jour des cas d’assistance.
- L’incident est récupéré.
- L’incident est documenté et une analyse des causes profondes (RCA) est effectuée dans les 5 jours ouvrables suivant l’incident.
- L’ébauche du document RCA sera communiquée au client dans les 7 jours ouvrables suivant l’incident.
Le Red Hat aide également les incidents de clients soulevés par des cas d’assistance. Le chapeau rouge peut aider aux activités, y compris, mais sans s’y limiter:
- Collecte médico-légale, y compris l’isolement du calcul virtuel
- Guide de la collection d’images de calcul
- Fournir des journaux d’audit recueillis
2.2.4.3. Capacité des clusters
L’impact d’une mise à niveau du cluster sur la capacité est évalué dans le cadre du processus d’essai de mise à niveau afin de s’assurer que la capacité n’est pas affectée négativement par de nouveaux ajouts au cluster. Lors d’une mise à niveau de cluster, des nœuds de travail supplémentaires sont ajoutés pour s’assurer que la capacité totale du cluster est maintenue pendant le processus de mise à niveau.
Les évaluations des capacités du personnel de Red Hat SRE se produisent également en réponse aux alertes du cluster, après que les seuils d’utilisation soient dépassés pendant une certaine période. De telles alertes peuvent également entraîner une notification au client.
2.2.5. Gestion du changement
Cette section décrit les stratégies sur la façon dont les changements de cluster et de configuration, les correctifs et les versions sont gérés.
Il incombe à Red Hat de modifier l’infrastructure et les services de cluster que le client contrôlera, ainsi que de maintenir les versions des nœuds d’avion de contrôle, des nœuds et des services d’infrastructure et des nœuds de travail. AWS est responsable de la protection de l’infrastructure matérielle qui exécute tous les services offerts dans AWS Cloud. Le client est responsable d’initier des demandes de changement d’infrastructure et d’installer et de maintenir des services et des configurations de réseau optionnels sur le cluster, ainsi que toutes les modifications apportées aux données client et aux applications client.
2.2.5.1. Changements initiés par le client
Il est possible d’initier des modifications en utilisant des fonctionnalités en libre-service telles que le déploiement de clusters, la mise à l’échelle des nœuds de travail ou la suppression de clusters.
L’historique des changements est capturé dans la section Historique des clusters dans l’onglet Aperçu OpenShift Cluster Manager, et est disponible pour vous. L’historique des changements comprend, sans s’y limiter, les journaux des changements suivants:
- Ajout ou suppression de fournisseurs d’identité
- Ajout ou suppression d’utilisateurs vers ou à partir du groupe admins dédiés
- Dimensionnement des nœuds de calcul du cluster
- Dimensionnement de l’équilibreur de charge du cluster
- Dimensionnement du stockage persistant du cluster
- Amélioration du cluster
Il est possible d’implémenter une exclusion de maintenance en évitant les changements dans OpenShift Cluster Manager pour les composants suivants:
- La suppression d’un cluster
- Ajout, modification ou suppression de fournisseurs d’identité
- Ajout, modification ou suppression d’un utilisateur d’un groupe élevé
- Installation ou suppression des add-ons
- La modification des configurations de réseau de clusters
- Ajout, modification ou suppression de pools de machines
- Activer ou désactiver la surveillance de la charge de travail des utilisateurs
- Lancement d’une mise à niveau
Afin de faire respecter l’exclusion de la maintenance, assurez-vous que les politiques d’autoscaling ou de mise à niveau automatique du pool de machines ont été désactivées. Après que l’exclusion de maintenance a été levée, procéder à l’activation automatique de la mise à l’échelle de la machine ou des politiques de mise à niveau automatique comme souhaité.
2.2.5.2. Changements initiés par Red Hat
L’ingénierie de fiabilité du site Red Hat (SRE) gère l’infrastructure, le code et la configuration de Red Hat OpenShift Service sur AWS à l’aide d’un flux de travail GitOps et de pipelines CI/CD entièrement automatisés. Ce processus permet à Red Hat d’introduire en toute sécurité des améliorations de service sur une base continue sans impact négatif sur les clients.
Chaque changement proposé fait l’objet d’une série de vérifications automatisées dès l’enregistrement. Les changements sont ensuite déployés dans un environnement de mise en scène où ils subissent des tests d’intégration automatisés. Enfin, des changements sont déployés dans l’environnement de production. Chaque étape est entièrement automatisée.
L’examinateur autorisé doit approuver l’avancement à chaque étape. L’examinateur ne peut pas être la même personne qui a proposé le changement. Les modifications et approbations sont entièrement vérifiables dans le cadre du flux de travail GitOps.
Certaines modifications sont publiées à la production progressivement, en utilisant des drapeaux de fonctionnalités pour contrôler la disponibilité de nouvelles fonctionnalités pour des clusters ou des clients spécifiés.
2.2.5.3. Gestion des patchs
Le logiciel OpenShift Container Platform et l’image du système d’exploitation immuable Red Hat CoreOS (RHCOS) sous-jacente sont corrigés pour les bogues et les vulnérabilités dans les mises à niveau régulières du flux z. En savoir plus sur l’architecture RHCOS dans la documentation OpenShift Container Platform.
2.2.5.4. Gestion des libérations
Le Red Hat ne met pas automatiquement à niveau vos clusters. Il est possible de programmer la mise à niveau des clusters à intervalles réguliers (mise à niveau récurrente) ou une seule fois (mise à niveau individuelle) à l’aide de la console Web OpenShift Cluster Manager. Le Red Hat pourrait mettre à niveau avec force un cluster vers une nouvelle version z-stream seulement si le cluster est affecté par un CVE d’impact critique.
Étant donné que les autorisations requises peuvent changer entre les versions y-stream, les politiques peuvent devoir être mises à jour avant qu’une mise à jour puisse être effectuée. Donc, vous ne pouvez pas planifier une mise à niveau récurrente sur les clusters ROSA avec STS.
Consultez l’historique de tous les événements de mise à niveau de cluster dans la console Web OpenShift Cluster Manager. Consultez la politique sur le cycle de vie pour plus d’informations sur les communiqués.
| A) Ressources | Les responsabilités en matière de service | Les responsabilités du client |
|---|---|---|
| L’exploitation forestière | Chapeau rouge
|
|
| La mise en réseau des applications | Chapeau rouge
|
|
| La mise en réseau de clusters | Chapeau rouge
|
|
| Gestion des réseaux virtuels | Chapeau rouge
|
|
| Gestion de calcul virtuel | Chapeau rouge
|
|
| La version du cluster | Chapeau rouge
|
|
| Gestion des capacités | Chapeau rouge
|
|
| Gestion du stockage virtuel | Chapeau rouge
|
|
| Logiciel AWS (services AWS publics) | AWS Calcul : Fournir le service Amazon EC2, utilisé pour l’avion de contrôle ROSA, l’infrastructure et les nœuds de travail. Le stockage: Fournir Amazon EBS, utilisé par ROSA pour fournir le stockage de nœuds locaux et le stockage en volume persistant pour le cluster. Stockage: Fournissez Amazon S3, utilisé pour le registre d’images intégré du service ROSA. Fournir les services AWS Cloud suivants, utilisés par ROSA pour répondre aux besoins d’infrastructure de réseau virtuel:
Fournir les services AWS suivants, que les clients peuvent éventuellement intégrer avec ROSA:
|
|
| Infrastructure mondiale hardware/AWS | AWS
|
|
2.2.6. Conformité à la sécurité et à la réglementation
Le tableau suivant présente les responsabilités en matière de conformité en matière de sécurité et de réglementation:
| A) Ressources | Les responsabilités en matière de service | Les responsabilités du client |
|---|---|---|
| L’exploitation forestière | Chapeau rouge
|
|
| Gestion des réseaux virtuels | Chapeau rouge
|
|
| Gestion du stockage virtuel | Chapeau rouge
|
|
| Gestion de calcul virtuel | Chapeau rouge
|
|
| Logiciel AWS (services AWS publics) | AWS Calcul: Secure Amazon EC2, utilisé pour le plan de contrôle ROSA, l’infrastructure et les nœuds de travail. Consultez la sécurité de l’infrastructure dans Amazon EC2 dans le Guide de l’utilisateur Amazon EC2. Amazon Elastic Block Store (EBS), utilisé pour le plan de contrôle ROSA, l’infrastructure et les volumes de nœuds de travail, ainsi que les volumes persistants de Kubernetes. Cliquez ici pour plus d’informations sur la protection des données dans Amazon EC2 dans le Guide de l’utilisateur Amazon EC2. Le stockage: Fournissez AWS KMS, que ROSA utilise pour chiffrer les volumes de plan de contrôle, d’infrastructure et de nœuds de travail et les volumes persistants. Consultez le chiffrement Amazon EBS dans le Guide de l’utilisateur Amazon EC2. Amazon S3, utilisé pour le registre intégré d’images de conteneurs du service ROSA. Consultez la sécurité Amazon S3 dans le guide de l’utilisateur S3. Fournir des capacités et des services de sécurité pour augmenter la confidentialité et contrôler l’accès au réseau sur l’infrastructure mondiale AWS, y compris les pare-feu réseau intégrés dans Amazon VPC, les connexions réseau privées ou dédiées, et le cryptage automatique de tout le trafic sur les réseaux mondiaux et régionaux AWS entre les installations sécurisées AWS. Consultez le modèle de responsabilité partagée AWS et la sécurité de l’infrastructure dans l’introduction au livre blanc AWS Security. |
|
| Infrastructure mondiale hardware/AWS | AWS
|
|
2.2.7. La reprise après sinistre
La reprise après sinistre comprend la sauvegarde des données et de la configuration, la reproduction des données et la configuration dans l’environnement de reprise après sinistre, et le basculement sur les événements de catastrophe.
Le service OpenShift Red Hat sur AWS (ROSA) fournit une reprise après sinistre pour les défaillances qui se produisent au niveau de la zone de pod, du nœud de travail, du nœud d’infrastructure, du nœud d’avion de contrôle et de la zone de disponibilité.
La récupération après sinistre exige que le client utilise les meilleures pratiques pour déployer des applications, du stockage et des clusters hautement disponibles, tels que le déploiement d’une zone unique ou le déploiement multizone, pour tenir compte du niveau de disponibilité souhaité.
En cas de panne d’une zone ou d’une zone de disponibilité, un groupe unique n’assurera pas d’évitement ou de reprise en cas de catastrophe. De multiples clusters à zone unique avec basculement entretenu par le client peuvent tenir compte des pannes à la zone ou au niveau régional.
En cas de panne totale de la région, un groupe multizones ne permettra pas d’éviter les catastrophes ou de se remettre en état. De multiples clusters multizones avec basculement entretenu par le client peuvent tenir compte des pannes au niveau régional.
| A) Ressources | Les responsabilités en matière de service | Les responsabilités du client |
|---|---|---|
| Gestion des réseaux virtuels | Chapeau rouge
|
|
| Gestion du stockage virtuel | Chapeau rouge
|
|
| Gestion de calcul virtuel | Chapeau rouge
|
|
| Logiciel AWS (services AWS publics) | AWS Calcul : Fournir des fonctionnalités Amazon EC2 qui prennent en charge la résilience des données telles que les instantanés Amazon EBS et Amazon EC2 Auto Scaling. Consultez Résilience dans Amazon EC2 dans le Guide de l’utilisateur EC2. Fournir la possibilité pour le service ROSA et les clients de sauvegarder le volume Amazon EBS sur le cluster via des instantanés de volume Amazon EBS. Stockage: Pour des informations sur les fonctionnalités Amazon S3 qui prennent en charge la résilience des données, voir Resilience dans Amazon S3. La mise en réseau : Pour obtenir des informations sur les fonctionnalités Amazon VPC qui prennent en charge la résilience des données, consultez Resilience dans Amazon Virtual Private Cloud dans le Guide de l’utilisateur Amazon VPC. |
|
| Infrastructure mondiale hardware/AWS | AWS
|
|
2.2.8. Les ressources gérées par Red Hat
2.2.8.1. Aperçu général
Ce qui suit couvre tous les services Red Hat OpenShift sur les ressources AWS qui sont gérées ou protégées par l’équipe de la plate-forme d’ingénierie de fiabilité des services (SRE-P). Les clients ne devraient pas essayer de changer ces ressources, car cela peut conduire à une instabilité des clusters.
2.2.8.2. Des ressources gérées
La liste suivante affiche le service Red Hat OpenShift sur les ressources AWS gérées par OpenShift Hive, le système centralisé de gestion de la configuration de la flotte. Ces ressources s’ajoutent aux ressources OpenShift Container Platform créées lors de l’installation. « OpenShift Hive tente continuellement de maintenir la cohérence dans tous les services OpenShift Red Hat sur les clusters AWS. Les modifications apportées au service OpenShift de Red Hat sur les ressources AWS doivent être effectuées via OpenShift Cluster Manager afin que OpenShift Cluster Manager et Hive soient synchronisés. Contactez ocm-feedback@redhat.com si OpenShift Cluster Manager ne prend pas en charge la modification des ressources en question.
Exemple 2.1. Liste des ressources gérées par Red Hat
2.2.8.3. Le Red Hat OpenShift Service sur AWS core namespaces
Le service Red Hat OpenShift sur AWS core namespaces est installé par défaut lors de l’installation du cluster.
Exemple 2.2. Liste des espaces de noms principaux
2.2.8.4. Le Red Hat OpenShift Service sur AWS add-on namespaces
Le Red Hat OpenShift Service sur les add-ons AWS sont des services disponibles pour l’installation après l’installation du cluster. Ces services supplémentaires incluent Red Hat OpenShift Dev Spaces, Red Hat OpenShift API Management et Cluster Logging Operator. Les modifications apportées aux ressources dans les espaces de noms suivants peuvent être remplacées par l’add-on lors des mises à niveau, ce qui peut conduire à des configurations non prises en charge pour la fonctionnalité add-on.
Exemple 2.3. Liste des espaces de noms gérés par add-on
2.2.8.5. Le Red Hat OpenShift Service sur AWS valide les webhooks
Le service Red Hat OpenShift sur AWS validant les webhooks est un ensemble de contrôles d’admission dynamiques maintenus par l’équipe OpenShift SRE. Ces rappels HTTP, également connus sous le nom de webhooks, sont appelés à divers types de requêtes pour assurer la stabilité des clusters. La liste suivante décrit les différents webhooks avec des règles contenant les opérations enregistrées et les ressources qui sont contrôlées. La tentative de contourner ces webhooks valides pourrait affecter la stabilité et la supportabilité du cluster.
Exemple 2.4. Liste des webhooks de validation
2.2.9. Autres responsabilités client pour les données et les applications
Le client est responsable des applications, des charges de travail et des données qu’ils déploient dans Red Hat OpenShift Service sur AWS. Cependant, Red Hat et AWS fournissent divers outils pour aider le client à gérer les données et les applications sur la plateforme.
| A) Ressources | Chapeau rouge et AWS | Les responsabilités du client |
|---|---|---|
| Données du client | Chapeau rouge
AWS
|
|
| Applications client | Chapeau rouge
AWS
|
|
2.3. Le Red Hat OpenShift Service sur la définition de service AWS
Cette documentation décrit la définition du service du service Red Hat OpenShift Service sur AWS (ROSA) géré.
2.3.1. Gestion des comptes
Cette section fournit des informations sur la définition du service pour Red Hat OpenShift Service sur la gestion de compte AWS.
2.3.1.1. Facturation et tarification
Le service Red Hat OpenShift sur AWS est facturé directement sur votre compte Amazon Web Services (AWS). La tarification ROSA est basée sur la consommation, avec des engagements annuels ou des engagements de trois ans pour une plus grande réduction. Le coût total de ROSA se compose de deux composantes:
- Frais de service ROSA
- Frais d’infrastructure AWS
Consultez le Service OpenShift Red Hat sur AWS Pricing page sur le site AWS pour plus de détails.
2.3.1.2. Cluster en libre-service
Les clients peuvent en libre-service leurs clusters, y compris, mais sans s’y limiter:
- Créer un cluster
- Effacer un cluster
- Ajouter ou supprimer un fournisseur d’identité
- Ajouter ou supprimer un utilisateur d’un groupe élevé
- Configurer la confidentialité du cluster
- Ajouter ou supprimer des pools de machines et configurer l’autoscaling
- Définir les politiques de mise à niveau
Ces tâches en libre-service peuvent être exécutées à l’aide du service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.
2.3.1.3. Les types d’instances
Les clusters de zone de disponibilité unique nécessitent un minimum de 3 nœuds d’avion de contrôle, 2 nœuds d’infrastructure et 2 nœuds ouvriers déployés dans une seule zone de disponibilité.
Les clusters de zones de disponibilité multiples nécessitent un minimum de 3 nœuds de plan de contrôle, 3 nœuds d’infrastructure et 3 nœuds ouvriers.
Considérez les limites suivantes lors du déploiement et de la gestion des charges de travail:
- Il faut déployer des charges de travail sur les nœuds de travail qui existent dans le cluster en utilisant Red Hat OpenShift Service sur les pools de machines AWS.
- Exécutez des charges de travail que vous considérez essentielles sur le plan de contrôle et les nœuds d’infrastructure comme des démons.
- Assurez-vous que toutes les charges de travail exécutées sur ces nœuds sont sécurisées, évolutives et compatibles avec une version de Red Hat OpenShift Service sur AWS, de sorte que l’accord de niveau de service (SLA) pour la disponibilité du serveur API n’est pas affecté.
Il est possible que Red Hat vous avise et redimensionne le plan de contrôle ou les nœuds d’infrastructure si le service OpenShift Red Hat sur les composants AWS est affecté.
Les nœuds d’avion de contrôle et d’infrastructure sont déployés et gérés par Red Hat. Ces nœuds sont automatiquement redimensionnés en fonction de l’utilisation des ressources. Lorsque vous avez besoin de redimensionner ces nœuds pour répondre aux demandes des clusters, ouvrez un cas de support.
La fermeture de l’infrastructure sous-jacente via la console fournisseur de cloud n’est pas prise en charge et peut entraîner une perte de données.
Consultez la section de support de Red Hat Operator suivante pour plus d’informations sur les charges de travail de Red Hat qui doivent être déployées sur les nœuds des travailleurs.
Environ un noyau vCPU et 1 GiB de mémoire sont réservés sur chaque nœud de travail et retirés des ressources allocatables. Cette réserve de ressources est nécessaire pour exécuter les processus requis par la plate-forme sous-jacente. Ces processus incluent des démons système tels que udev, kubelet et l’exécution des conteneurs, entre autres. Les ressources réservées tiennent également compte des réservations du noyau.
Les systèmes de base OpenShift Container Platform tels que l’agrégation des journaux d’audit, la collecte des métriques, le DNS, le registre d’images, le SDN et d’autres pourraient consommer des ressources allocatables supplémentaires pour maintenir la stabilité et la maintenabilité du cluster. Les ressources supplémentaires consommées peuvent varier en fonction de l’utilisation.
Consultez la documentation Kubernetes pour plus d’informations.
2.3.1.4. Les régions et les zones de disponibilité
Les régions AWS suivantes sont actuellement disponibles pour Red Hat OpenShift 4 et sont prises en charge pour Red Hat OpenShift Service sur AWS.
Les régions chinoises ne sont pas soutenues, quel que soit leur soutien sur OpenShift 4.
Dans le cas des régions de GovCloud (États-Unis), vous devez soumettre une demande d’accès pour Red Hat OpenShift Service sur AWS (ROSA) FedRAMP.
Les régions de GovCloud (États-Unis) ne sont prises en charge que sur les clusters ROSA Classic.
Exemple 2.5. Les régions AWS
- États-Unis-Est-1 (N. Virginie)
- C’est nous-Est-2 (Ohio)
- États-Unis-Ouest-1 (N.-Californie)
- l’ouest-2 (Oregon)
- AF-south-1 (Cape Town, AWS opt-in requis)
- AP-east-1 (Hong Kong, AWS opt-in requis)
- AP-south-2 (Hyderabad, AWS opt-in requis)
- AP-sud-est-3 (Jakarta, AWS opt-in requis)
- AP-sud-est-4 (Melbourne, AWS opt-in requis)
- AP-sud-1 (Mumbai)
- AP-northeast-3 (Osaka)
- AP-northeast-2 (Seoul)
- AP-sud-est-1 (Singapour)
- AP-sud-est-2 (Sydney)
- AP-northeast-1 (Tokyo)
- ca-central-1 (Centre du Canada)
- EU-central-1 (Francfort)
- EU-north-1 (Stockholm)
- UE-Ouest-1 (Irlande)
- EU-west-2 (Londres)
- EU-Sud-1 (Milan, AWS opt-in requis)
- EU-west-3 (Paris)
- UE-Sud-2 (Espagne)
- EU-central-2 (Zurich, AWS opt-in requis)
- le me-sud-1 (Bahrain, AWS opt-in requis)
- le me-central-1 (UAE, AWS opt-in requis)
- hôtels proches de la SA-east-1 (São Paulo)
- us-gov-east-1 (AWS GovCloud - États-Unis-Est)
- us-gov-west-1 (AWS GovCloud - États-Unis-Ouest)
Les clusters de zones de disponibilité multiples ne peuvent être déployés que dans les régions avec au moins 3 zones de disponibilité. Consultez la section Régions et Zones de Disponibilité dans la documentation AWS.
Chaque nouveau Red Hat OpenShift Service sur AWS cluster est installé dans un cloud privé virtuel (VPC) créé par un installateur ou préexistant dans une seule région, avec la possibilité de se déployer dans une seule zone de disponibilité (Single-AZ) ou sur plusieurs zones de disponibilité (Multi-AZ). Cela permet d’isoler le réseau et les ressources au niveau du cluster, et permet les paramètres VPC fournisseurs de cloud, tels que les connexions VPN et VPC Peering. Les volumes persistants (PV) sont soutenus par Amazon Elastic Block Storage (Amazon EBS), et sont spécifiques à la zone de disponibilité dans laquelle ils sont fournis. Les revendications de volume persistants (PVC) ne se lient pas à un volume tant que la ressource de la gousse associée n’est pas affectée dans une zone de disponibilité spécifique afin d’éviter les pods imprévus. Les ressources spécifiques à la zone de disponibilité ne sont utilisables que par des ressources dans la même zone de disponibilité.
La région et le choix d’une zone de disponibilité unique ou multiple ne peuvent pas être modifiés après le déploiement d’un cluster.
2.3.1.5. Les zones locales
Le service OpenShift Red Hat sur AWS prend en charge l’utilisation des zones locales AWS, qui sont des zones de disponibilité centralisées de métropole où les clients peuvent placer des charges de travail d’application sensibles à la latence. Les zones locales sont des extensions de régions AWS qui ont leur propre connexion Internet. Consultez la documentation AWS Comment fonctionnent les Zones Locales AWS.
2.3.1.6. Accord de niveau de service (SLA)
Les SLA du service lui-même sont définies à l’annexe 4 de l’Annexe 4 de l’Accord d’entreprise Red Hat (Services d’abonnement en ligne).
2.3.1.7. Le statut de soutien limité
Lorsqu’un cluster passe à un statut de support limité, Red Hat ne surveille plus de manière proactive le cluster, le SLA n’est plus applicable et les crédits demandés contre l’ALS sont refusés. Cela ne signifie pas que vous n’avez plus de support produit. Dans certains cas, le cluster peut revenir à un statut entièrement pris en charge si vous corrigez les facteurs de violation. Cependant, dans d’autres cas, vous devrez peut-être supprimer et recréer le cluster.
Il est possible qu’un cluster passe à un statut de support limité pour de nombreuses raisons, y compris les scénarios suivants:
- Lorsque vous ne mettez pas à niveau un cluster vers une version prise en charge avant la date de fin de vie
Le Red Hat ne fait aucune garantie d’exécution ou de SLA pour les versions après leur date de fin de vie. Afin de recevoir un soutien continu, mettre à niveau le cluster vers une version prise en charge avant la date de fin de vie. Lorsque vous ne mettez pas à niveau le cluster avant la date de fin de vie, le cluster passe à un statut de support limité jusqu’à ce qu’il soit mis à niveau vers une version prise en charge.
Le Red Hat fournit un support commercialement raisonnable pour passer d’une version non prise en charge à une version prise en charge. Cependant, si un chemin de mise à niveau pris en charge n’est plus disponible, vous devrez peut-être créer un nouveau cluster et migrer vos charges de travail.
- Lorsque vous supprimez ou remplacez un service native Red Hat OpenShift sur les composants AWS ou tout autre composant installé et géré par Red Hat
- En cas d’utilisation des autorisations d’administrateur de clusters, Red Hat n’est pas responsable des actions de vos utilisateurs autorisés ou de vos utilisateurs autorisés, y compris celles qui affectent les services d’infrastructure, la disponibilité des services ou la perte de données. Dans le cas où Red Hat détecte de telles actions, le cluster pourrait passer à un statut de support limité. Le Red Hat vous informe du changement d’état et vous devriez soit inverser l’action, soit créer un cas de support pour explorer les étapes d’assainissement qui pourraient vous obliger à supprimer et à recréer le cluster.
Lorsque vous avez des questions sur une action spécifique qui pourrait amener un cluster à passer à un statut de support limité ou à avoir besoin d’aide supplémentaire, ouvrez un ticket d’assistance.
2.3.1.8. Le soutien
Le service OpenShift Red Hat sur AWS inclut le support Red Hat Premium, auquel on peut accéder en utilisant le portail client Red Hat.
Consultez les Conditions d’utilisation de Red Hat Production Support pour connaître les délais de réponse du support.
Le support AWS est soumis au contrat de support existant d’un client avec AWS.
2.3.2. L’exploitation forestière
Le service OpenShift Red Hat sur AWS fournit un transfert de journal intégré optionnel vers Amazon (AWS) CloudWatch.
2.3.2.1. Enregistrement de l’audit en grappes
Les journaux d’audit en cluster sont disponibles via AWS CloudWatch, si l’intégration est activée. Lorsque l’intégration n’est pas activée, vous pouvez demander les journaux d’audit en ouvrant un dossier d’assistance.
2.3.2.2. Enregistrement des applications
Les journaux d’application envoyés à STDOUT sont collectés par Fluentd et transmis à AWS CloudWatch via la pile de journalisation du cluster, s’il est installé.
2.3.3. Le suivi
Cette section fournit des informations sur la définition du service pour Red Hat OpenShift Service sur la surveillance AWS.
2.3.3.1. Les métriques des clusters
Le Red Hat OpenShift Service sur les clusters AWS est livré avec une pile Prometheus intégrée pour la surveillance des clusters, y compris les métriques CPU, mémoire et réseau. Ceci est accessible via la console web. Ces métriques permettent également une mise à l’échelle horizontale de pod basée sur des métriques CPU ou mémoire fournies par un service OpenShift Red Hat sur l’utilisateur AWS.
2.3.3.2. Les notifications de cluster
Les notifications de cluster sont des messages sur l’état, la santé ou les performances de votre cluster.
Les notifications de cluster sont la principale façon dont Red Hat Site Reliability Engineering (SRE) communique avec vous sur la santé de votre cluster géré. Le SRE peut également utiliser des notifications de cluster pour vous inviter à effectuer une action afin de résoudre ou d’empêcher un problème avec votre cluster.
Les propriétaires de clusters et les administrateurs doivent régulièrement examiner et agir les notifications de clusters pour s’assurer que les clusters restent en bonne santé et pris en charge.
Dans l’onglet Historique des clusters de votre cluster, vous pouvez afficher les notifications de cluster dans la console de cloud hybride Red Hat. Par défaut, seul le propriétaire du cluster reçoit des notifications de cluster sous forme d’e-mails. Lorsque d’autres utilisateurs doivent recevoir des e-mails de notification en cluster, ajoutez chaque utilisateur comme contact de notification pour votre cluster.
2.3.4. Le réseautage
Cette section fournit des informations sur la définition du service pour Red Hat OpenShift Service sur le réseau AWS.
2.3.4.1. Domaines personnalisés pour les applications
À partir de Red Hat OpenShift Service sur AWS 4.14, l’opérateur de domaine personnalisé est obsolète. Afin de gérer Ingress dans Red Hat OpenShift Service sur AWS 4.14 ou version ultérieure, utilisez l’opérateur Ingress. La fonctionnalité est inchangée pour Red Hat OpenShift Service sur AWS 4.13 et versions antérieures.
Afin d’utiliser un nom d’hôte personnalisé pour un itinéraire, vous devez mettre à jour votre fournisseur DNS en créant un enregistrement de nom canonique (CNAME). L’enregistrement CNAME doit cartographier le nom d’hôte du routeur canonique OpenShift à votre domaine personnalisé. Le nom d’hôte du routeur canonique OpenShift est affiché sur la page Détails de l’itinéraire après la création d’une route. Alternativement, un enregistrement générique CNAME peut être créé une fois pour acheminer tous les sous-domaines d’un nom d’hôte donné vers le routeur du cluster.
2.3.4.2. Certificats validés par domaine
Le service OpenShift Red Hat sur AWS inclut les certificats de sécurité TLS nécessaires pour les services internes et externes sur le cluster. Dans le cas des routes externes, il existe deux certificats TLS Wildcard distincts qui sont fournis et installés sur chaque cluster: l’un est pour la console Web et les noms d’hôte par défaut d’itinéraire, et l’autre pour le point de terminaison API. Let's Encrypt est l’autorité de certification utilisée pour les certificats. Les itinéraires à l’intérieur du cluster, tels que le point de terminaison interne de l’API, utilisent les certificats TLS signés par l’autorité de certification intégrée du cluster et exigent le paquet CA disponible dans chaque pod pour faire confiance au certificat TLS.
2.3.4.3. Autorités de certification personnalisées pour les constructions
Le service OpenShift Red Hat sur AWS prend en charge l’utilisation d’autorités de certification personnalisées pour être fiable par les builds lors de l’extraction d’images à partir d’un registre d’images.
2.3.4.4. Balanceurs de charge
Le service OpenShift Red Hat sur AWS utilise jusqu’à cinq balanceurs de charge différents:
- Balanceur de charge de plan de contrôle interne qui est interne au cluster et utilisé pour équilibrer le trafic pour les communications internes de cluster.
- Balanceur de charge de plan de contrôle externe utilisé pour accéder aux API OpenShift et Kubernetes. Cet équilibreur de charge peut être désactivé dans OpenShift Cluster Manager. Lorsque cet équilibreur de charge est désactivé, Red Hat reconfigure le DNS API pour pointer vers l’équilibreur de charge du plan de contrôle interne.
- Balanceur de charge de plan de commande externe pour Red Hat qui est réservé à la gestion des clusters par Red Hat. L’accès est strictement contrôlé, et la communication n’est possible que par les hôtes de bastion sur liste blanche.
- Il s’agit d’un balanceur de charge externe par défaut qui est l’équilibreur de charge par défaut de l’application, indiqué par les applications dans l’URL. L’équilibreur de charge par défaut peut être configuré dans OpenShift Cluster Manager pour être accessible au public sur Internet ou uniquement accessible en privé via une connexion privée préexistante. L’ensemble des itinéraires d’application du cluster sont exposés sur cet équilibreur de charge de routeur par défaut, y compris les services de cluster tels que l’interface utilisateur de journalisation, l’API métrique et le registre.
- Facultatif: Un balanceur de charge secondaire de routeur / ingère qui est un équilibreur de charge d’application secondaire, indiqué par apps2 dans l’URL. L’équilibreur de charge secondaire peut être configuré dans OpenShift Cluster Manager pour être accessible au public sur Internet ou uniquement accessible en privé via une connexion privée préexistante. Lorsqu’une correspondance Label est configurée pour cet équilibreur de charge de routeur, seuls les itinéraires d’application correspondant à cette étiquette sont exposés sur cet équilibreur de charge du routeur; sinon, tous les itinéraires d’application sont également exposés sur cet équilibreur de charge du routeur.
- Facultatif: Balanceurs de charge pour les services. Activer le trafic non-HTTP/SNI et les ports non standard pour les services. Ces équilibreurs de charge peuvent être cartographiés à un service fonctionnant sur Red Hat OpenShift Service sur AWS pour activer des fonctionnalités d’entrée avancées, telles que le trafic non-HTTP/SNI ou l’utilisation de ports non standard. Chaque compte AWS dispose d’un quota qui limite le nombre d’équilibreurs de charge classiques pouvant être utilisés dans chaque cluster.
2.3.4.5. Entrée de cluster
Les administrateurs de projet peuvent ajouter des annotations d’itinéraire à de nombreuses fins différentes, y compris le contrôle d’entrée grâce à la liste d’autorisations IP.
Les stratégies d’entrée peuvent également être modifiées en utilisant les objets NetworkPolicy, qui exploitent le plugin ovs-networkpolicy. Cela permet un contrôle total de la stratégie réseau d’entrée jusqu’au niveau pod, y compris entre les pods sur le même cluster et même dans le même espace de noms.
L’ensemble du trafic d’entrée de cluster passera par les équilibreurs de charge définis. L’accès direct à tous les nœuds est bloqué par la configuration du cloud.
2.3.4.6. Egress de cluster
Le contrôle du trafic par le biais d’objets EgressNetworkPolicy peut être utilisé pour prévenir ou limiter le trafic sortant dans Red Hat OpenShift Service sur AWS.
Le trafic public sortant du plan de contrôle et des nœuds d’infrastructure est nécessaire pour maintenir la sécurité de l’image de cluster et la surveillance des clusters. Cela nécessite que l’itinéraire 0.0.0.0/0 appartient uniquement à la passerelle Internet; il n’est pas possible d’acheminer cette plage sur des connexions privées.
Les clusters OpenShift 4 utilisent les passerelles NAT pour présenter une IP publique statique pour tout trafic public sortant du cluster. Chaque zone de disponibilité dans laquelle un cluster est déployé reçoit une passerelle NAT distincte, de sorte que jusqu’à 3 adresses IP statiques uniques peuvent exister pour le trafic egress de cluster. Le trafic qui reste à l’intérieur du cluster, ou qui ne va pas vers l’Internet public, ne passera pas par la passerelle NAT et aura une adresse IP source appartenant au nœud d’origine du trafic. Les adresses IP des nœuds sont dynamiques; par conséquent, un client ne doit pas compter sur la liste blanche des adresses IP individuelles lors de l’accès aux ressources privées.
Les clients peuvent déterminer leurs adresses IP statiques publiques en exécutant un pod sur le cluster, puis en interrogeant un service externe. À titre d’exemple:
oc run ip-lookup --image=busybox -i -t --restart=Never --rm -- /bin/sh -c "/bin/nslookup -type=a myip.opendns.com resolver1.opendns.com | grep -E 'Address: [0-9.]+'"
$ oc run ip-lookup --image=busybox -i -t --restart=Never --rm -- /bin/sh -c "/bin/nslookup -type=a myip.opendns.com resolver1.opendns.com | grep -E 'Address: [0-9.]+'"2.3.4.7. Configuration du réseau cloud
Le service Red Hat OpenShift sur AWS permet la configuration d’une connexion réseau privée via des technologies gérées par AWS, telles que:
- Connexions VPN
- Peering VPC
- Passerelle de transit
- Connexion directe
Les ingénieurs de fiabilité du site Red Hat (SRE) ne surveillent pas les connexions de réseau privé. La surveillance de ces connexions relève de la responsabilité du client.
2.3.4.8. Envoi DNS
Dans le cas de Red Hat OpenShift Service sur les clusters AWS qui ont une configuration de réseau cloud privé, un client peut spécifier des serveurs DNS internes disponibles sur cette connexion privée, qui devraient être interrogés pour les domaines explicitement fournis.
2.3.4.9. La vérification du réseau
Les vérifications réseau s’exécutent automatiquement lorsque vous déployez un service Red Hat OpenShift sur le cluster AWS dans un cloud privé virtuel (VPC) existant ou créez un pool de machines supplémentaire avec un sous-réseau qui est nouveau dans votre cluster. Les vérifications valident votre configuration réseau et mettent en évidence les erreurs, vous permettant de résoudre les problèmes de configuration avant le déploiement.
Il est également possible d’exécuter manuellement les vérifications réseau pour valider la configuration d’un cluster existant.
2.3.5. Le stockage
Cette section fournit des informations sur la définition du service pour Red Hat OpenShift Service sur le stockage AWS.
2.3.5.1. Stockage crypté des systèmes d’exploitation et des nœuds
Le plan de contrôle, l’infrastructure et les nœuds de travail utilisent le stockage Amazon Elastic Block Store (Amazon EBS) chiffré.
2.3.5.2. Crypté au repos PV
Les volumes EBS utilisés pour les PV sont cryptés au repos par défaut.
2.3.5.3. Bloc de stockage (RWO)
Les volumes persistants (PV) sont soutenus par Amazon Elastic Block Store (Amazon EBS), qui est Read-Write-Once.
Les PVS ne peuvent être attachés qu’à un seul nœud à la fois et sont spécifiques à la zone de disponibilité dans laquelle ils ont été approvisionnés. Cependant, les PV peuvent être attachés à n’importe quel nœud dans la zone de disponibilité.
Chaque fournisseur de cloud a ses propres limites pour combien de PV peuvent être attachés à un seul nœud. Consultez les limites de type d’instance AWS pour plus de détails.
2.3.6. La plate-forme
Cette section fournit des informations sur la définition du service pour la plateforme Red Hat OpenShift Service sur AWS (ROSA).
2.3.6.1. Autoscaling
La mise à l’échelle automatique des nœuds est disponible sur le service Red Hat OpenShift sur AWS. Il est possible de configurer l’option autoscaler pour mettre automatiquement à l’échelle le nombre de machines d’un cluster.
2.3.6.2. Daemonsets
Les clients peuvent créer et exécuter des démons sur Red Hat OpenShift Service sur AWS. Afin de limiter les daemonsets à ne fonctionner que sur les nœuds ouvriers, utilisez le nodeSelector suivant:
spec:
nodeSelector:
role: worker
spec:
nodeSelector:
role: worker2.3.6.3. La zone de disponibilité multiple
Dans un cluster de zones de disponibilité multiple, les nœuds de plan de contrôle sont répartis entre les zones de disponibilité et au moins un nœud de travail est requis dans chaque zone de disponibilité.
2.3.6.4. Étiquettes des nœuds
Les étiquettes de nœuds personnalisés sont créées par Red Hat lors de la création de nœuds et ne peuvent pas être modifiées sur Red Hat OpenShift Service sur les clusters AWS pour le moment. Cependant, les étiquettes personnalisées sont prises en charge lors de la création de nouveaux pools de machines.
2.3.6.5. La stratégie de sauvegarde des clusters
Le Red Hat ne fournit pas de méthode de sauvegarde pour les clusters ROSA qui utilisent STS. Il est essentiel que les clients disposent d’un plan de sauvegarde pour leurs applications et leurs données d’application.
Les sauvegardes de données d’applications et d’applications ne font pas partie du service Red Hat OpenShift sur AWS.
Le tableau ci-dessous ne s’applique qu’aux clusters non STS. Les composants suivants sont utilisés par Red Hat dans des circonstances atténuantes.
| Composante | Fréquence de prise de vue | La rétention | Les notes |
|---|---|---|---|
| Sauvegarde complète du magasin d’objets | Au quotidien | 7 jours | Il s’agit d’une sauvegarde complète de tous les objets Kubernetes comme etcd. Aucun volume persistant (PV) n’est sauvegardé dans ce calendrier de sauvegarde. |
| Chaque semaine | 30 jours | ||
| Sauvegarde complète du magasin d’objets | Horaire | 24 heures | Il s’agit d’une sauvegarde complète de tous les objets Kubernetes comme etcd. Aucun PV n’est sauvegardé dans ce calendrier de sauvegarde. |
| Le volume de racine des nœuds | Jamais jamais | C) N/A | Les nœuds sont considérés comme à court terme. Aucune critique ne doit être stockée sur le volume racine d’un nœud. |
2.3.6.6. La version OpenShift
Le service Red Hat OpenShift sur AWS est exécuté en tant que service et est tenu à jour avec la dernière version OpenShift Container Platform. La planification des mises à niveau vers la dernière version est disponible.
2.3.6.7. Des mises à niveau
Les mises à niveau peuvent être programmées à l’aide du ROSA CLI, rosa ou via OpenShift Cluster Manager.
Consultez le service Red Hat OpenShift sur AWS Life Cycle pour plus d’informations sur la politique et les procédures de mise à niveau.
2.3.6.8. Conteneurs Windows
La prise en charge de Red Hat OpenShift pour les conteneurs Windows n’est pas disponible sur Red Hat OpenShift Service sur AWS pour le moment.
2.3.6.9. Conteneur moteur
Le Red Hat OpenShift Service sur AWS fonctionne sur OpenShift 4 et utilise CRI-O comme seul moteur de conteneur disponible.
2.3.6.10. Le système d’exploitation
Le Red Hat OpenShift Service sur AWS fonctionne sur OpenShift 4 et utilise Red Hat CoreOS comme système d’exploitation pour tous les avions de contrôle et les nœuds de travail.
2.3.6.11. Assistance de Red Hat Operator
Les charges de travail Red Hat se réfèrent généralement aux opérateurs fournis par Red Hat mis à disposition par l’intermédiaire de l’opérateur Hub. Les charges de travail Red Hat ne sont pas gérées par l’équipe Red Hat SRE et doivent être déployées sur les nœuds des travailleurs. Ces opérateurs peuvent nécessiter des abonnements supplémentaires à Red Hat et peuvent entraîner des coûts d’infrastructure cloud supplémentaires. Des exemples de ces opérateurs fournis par Red Hat sont:
- Chapeau rouge Quay
- Gestion avancée des clusters Red Hat
- Ajouter au panier Red Hat Advanced Cluster Security
- Chapeau rouge OpenShift Service Mesh
- Informations sur OpenShift Serverless
- Coupe rouge OpenShift Logging
- Chapeau rouge OpenShift Pipelines
2.3.6.12. Assistance de l’opérateur Kubernetes
Les opérateurs inscrits sur le marché OperatorHub devraient être disponibles pour l’installation. Ces opérateurs sont considérés comme des charges de travail des clients et ne sont pas surveillés par Red Hat SRE.
2.3.7. La sécurité
Cette section fournit des informations sur la définition du service pour Red Hat OpenShift Service sur la sécurité AWS.
2.3.7.1. Fournisseur d’authentification
L’authentification pour le cluster peut être configurée en utilisant OpenShift Cluster Manager ou le processus de création de cluster ou en utilisant le ROSA CLI, rosa. La ROSA n’est pas un fournisseur d’identité, et tout accès au cluster doit être géré par le client dans le cadre de sa solution intégrée. L’utilisation de plusieurs fournisseurs d’identité fournis en même temps est prise en charge. Les fournisseurs d’identité suivants sont pris en charge:
- GitHub ou GitHub Enterprise
- GitLab
- LDAP
- Connexion d’OpenID
- htpasswd
2.3.7.2. Conteneurs privilégiés
Des conteneurs privilégiés sont disponibles pour les utilisateurs ayant le rôle de cluster-admin. L’utilisation de conteneurs privilégiés en tant que cluster-admin est assujettie aux responsabilités et aux notes d’exclusion figurant à l’annexe 4 de l’Accord d’entreprise Red Hat (Services d’abonnement en ligne).
2.3.7.3. Administrateur client utilisateur
En plus des utilisateurs normaux, Red Hat OpenShift Service sur AWS donne accès à un groupe spécifique ROSA appelé admin dédié. Les utilisateurs du cluster qui sont membres du groupe admin dédié:
- Avoir un accès administrateur à tous les projets créés par le client sur le cluster.
- Gérer les quotas de ressources et les limites du cluster.
- Il peut ajouter et gérer des objets NetworkPolicy.
- Ils sont capables d’afficher des informations sur des nœuds spécifiques et des PV dans le cluster, y compris les informations sur les planificateurs.
- Accéder au projet admin réservé sur le cluster, ce qui permet la création de comptes de service avec des privilèges élevés et permet également de mettre à jour les limites et les quotas par défaut pour les projets sur le cluster.
- Il peut installer des Opérateurs depuis OperatorHub et exécuter tous les verbes dans tous les groupes d’API *.operators.coreos.com.
2.3.7.4. Le rôle de l’administration des clusters
L’administrateur de Red Hat OpenShift Service sur AWS a un accès par défaut au rôle d’administration du cluster de votre organisation. Alors qu’ils sont connectés à un compte avec le rôle de cluster-admin, les utilisateurs ont augmenté les autorisations d’exécuter des contextes de sécurité privilégiés.
2.3.7.5. Libre-service de projet
Par défaut, tous les utilisateurs ont la possibilité de créer, de mettre à jour et de supprimer leurs projets. Cela peut être restreint si un membre du groupe admin dédié supprime le rôle d’auto-fournisseur des utilisateurs authentifiés:
oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth
$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauthLes restrictions peuvent être annulées en appliquant:
oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth
$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth2.3.7.6. Conformité réglementaire
Consultez le tableau de conformité dans Comprendre le processus et la sécurité de ROSA pour obtenir les dernières informations sur la conformité.
2.3.7.7. La sécurité du réseau
Avec Red Hat OpenShift Service sur AWS, AWS fournit une protection DDoS standard sur tous les équilibreurs de charge, appelé AWS Shield. Cela offre une protection de 95 % contre les attaques de niveau 3 et 4 les plus couramment utilisées sur l’ensemble des balanceurs de charge publics utilisés pour Red Hat OpenShift Service sur AWS. Le délai de 10 secondes est ajouté pour les requêtes HTTP arrivant sur le routeur haproxy pour recevoir une réponse ou la connexion est fermée pour fournir une protection supplémentaire.
2.3.7.8. chiffrement etcd
Dans Red Hat OpenShift Service sur AWS, le stockage du plan de contrôle est crypté au repos par défaut et cela inclut le cryptage des volumes etcd. Ce chiffrement de niveau de stockage est fourni via la couche de stockage du fournisseur de cloud.
Il est également possible d’activer le chiffrement etcd, qui chiffre les valeurs clés dans etcd, mais pas les clés. Lorsque vous activez le cryptage etcd, les ressources suivantes du serveur API Kubernetes et OpenShift API sont cryptées:
- Les secrets
- Configuration des cartes
- Itinéraires
- Jetons d’accès OAuth
- Autoriser les jetons OAuth
La fonction de chiffrement etcd n’est pas activée par défaut et ne peut être activée qu’au moment de l’installation du cluster. Bien que le chiffrement etcd soit activé, les valeurs clés etcd sont accessibles à toute personne ayant accès aux nœuds de plan de contrôle ou aux privilèges cluster-admin.
En activant le chiffrement etcd pour les valeurs clés dans etcd, vous subirez un surcharge de performance d’environ 20%. Les frais généraux sont le résultat de l’introduction de cette deuxième couche de chiffrement, en plus du chiffrement de stockage de plan de contrôle par défaut qui crypte les volumes etcd. Le Red Hat vous recommande d’activer le chiffrement etc. uniquement si vous en avez spécifiquement besoin pour votre cas d’utilisation.
2.4. Le Red Hat OpenShift Service sur les types d’instance AWS
Le Red Hat OpenShift Service sur AWS offre les types et tailles d’instance de nœuds de travail suivants:
2.4.1. Les types d’instances AWS x86
Exemple 2.6. But général
- format M5.xlarge (4 vCPU, 16 GiB)
- format M5.2xlarge (8 vCPU, 32 GiB)
- format M5.4xlarge (16 vCPU, 64 GiB)
- format M5.8xlarge (32 vCPU, 128 GiB)
- format M5.12xlarge (48 vCPU, 192 GiB)
- format M5.16xlarge (64 vCPU, 256 GiB)
- format M5.24xlarge (96 vCPU, 384 GiB)
- ajouter au panier M5.metal (96† vCPU, 384 GiB)
- ajouter au panier M5a.xlarge (4 vCPU, 16 GiB)
- format M5a.2xlarge (8 vCPU, 32 GiB)
- format M5a.4xlarge (16 vCPU, 64 GiB)
- format M5a.8xlarge (32 vCPU, 128 GiB)
- format M5a.12xlarge (48 vCPU, 192 GiB)
- format M5a.16xlarge (64 vCPU, 256 GiB)
- format M5a.24xlarge (96 vCPU, 384 GiB)
- ajouter au panier M5dn.metal (96 vCPU, 384 GiB)
- ajouter au panier M5zn.metal (48 vCPU, 192 GiB)
- ajouter au panier M5d.metal (96† vCPU, 384 GiB)
- ajouter au panier M5n.metal (96 vCPU, 384 GiB)
- ajouter au panier M6a.xlarge (4 vCPU, 16 GiB)
- format M6a.2xlarge (8 vCPU, 32 GiB)
- format M6a.4xlarge (16 vCPU, 64 GiB)
- format M6a.8xlarge (32 vCPU, 128 GiB)
- format M6a.12xlarge (48 vCPU, 192 GiB)
- format M6a.16xlarge (64 vCPU, 256 GiB)
- format M6a.24xlarge (96 vCPU, 384 GiB)
- format M6a.32xlarge (128 vCPU, 512 GiB)
- format M6a.48xlarge (192 vCPU, 768 GiB)
- ajouter au panier M6a.metal (192 vCPU, 768 GiB)
- ajouter au panier M6i.xlarge (4 vCPU, 16 GiB)
- ajouter au panier M6i.2xlarge (8 vCPU, 32 GiB)
- format M6i.4xlarge (16 vCPU, 64 GiB)
- format M6i.8xlarge (32 vCPU, 128 GiB)
- format M6i.12xlarge (48 vCPU, 192 GiB)
- format M6i.16xlarge (64 vCPU, 256 GiB)
- format M6i.24xlarge (96 vCPU, 384 GiB)
- format M6i.32xlarge (128 vCPU, 512 GiB)
- ajouter au panier M6i.metal (128 vCPU, 512 GiB)
- ajouter au panier M6id.xlarge (4 vCPU, 16 GiB)
- ajouter au panier M6id.2xlarge (8 vCPU, 32 GiB)
- format M6id.4xlarge (16 vCPU, 64 GiB)
- format M6id.8xlarge (32 vCPU, 128 GiB)
- format M6id.12xlarge (48 vCPU, 192 GiB)
- format M6id.16xlarge (64 vCPU, 256 GiB)
- format M6id.24xlarge (96 vCPU, 384 GiB)
- format M6id.32xlarge (128 vCPU, 512 GiB)
- ajouter au panier M6id.metal (128 vCPU, 512 GiB)
- ajouter au panier M6idn.xlarge (4 vCPU, 16 GiB)
- ajouter au panier M6idn.2xlarge (8 vCPU, 32 GiB)
- format M6idn.4xlarge (16 vCPU, 64 GiB)
- format M6idn.8xlarge (32 vCPU, 128 GiB)
- format M6idn.12xlarge (48 vCPU, 192 GiB)
- format M6idn.16xlarge (64 vCPU, 256 GiB)
- format M6idn.24xlarge (96 vCPU, 384 GiB)
- format M6idn.32xlarge (128 vCPU, 512 GiB)
- ajouter au panier M6in.xlarge (4 vCPU, 16 GiB)
- format M6in.2xlarge (8 vCPU, 32 GiB)
- format M6in.4xlarge (16 vCPU, 64 GiB)
- format M6in.8xlarge (32 vCPU, 128 GiB)
- format M6in.12xlarge (48 vCPU, 192 GiB)
- format M6in.16xlarge (64 vCPU, 256 GiB)
- format M6in.24xlarge (96 vCPU, 384 GiB)
- format M6in.32xlarge (128 vCPU, 512 GiB)
- ajouter au panier M7a.xlarge (4 vCPU, 16 GiB)
- format M7a.2xlarge (8 vCPU, 32 GiB)
- format M7a.4xlarge (16 vCPU, 64 GiB)
- format M7a.8xlarge (32 vCPU, 128 GiB)
- format M7a.12xlarge (48 vCPU, 192 GiB)
- format M7a.16xlarge (64 vCPU, 256 GiB)
- format M7a.24xlarge (96 vCPU, 384 GiB)
- format M7a.32xlarge (128 vCPU, 512 GiB)
- format M7a.48xlarge (192 vCPU, 768 GiB)
- ajouter au panier M7a.metal-48xl (192 vCPU, 768 GiB)
- ajouter au panier M7i-flex.2xlarge (8 vCPU, 32 GiB)
- format M7i-flex.4xlarge (16 vCPU, 64 GiB)
- format M7i-flex.8xlarge (32 vCPU, 128 GiB)
- ajouter au panier M7i-flex.xlarge (4 vCPU, 16 GiB)
- ajouter au panier M7i.xlarge (4 vCPU, 16 GiB)
- format M7i.2xlarge (8 vCPU, 32 GiB)
- format M7i.4xlarge (16 vCPU, 64 GiB)
- format M7i.8xlarge (32 vCPU, 128 GiB)
- format M7i.12xlarge (48 vCPU, 192 GiB)
- format M7i.16xlarge (64 vCPU, 256 GiB)
- format M7i.24xlarge (96 vCPU, 384 GiB)
- format M7i.48xlarge (192 vCPU, 768 GiB)
- ajouter au panier M7i.metal-24xl (96 vCPU, 384 GiB)
- ajouter au panier M7i.metal-48xl (192 vCPU, 768 GiB)
† Ces types d’instances offrent 96 processeurs logiques sur 48 cœurs physiques. Ils fonctionnent sur des serveurs uniques avec deux sockets Intel physiques.
Exemple 2.7. Rafale à usage général
- ajouter au panier T3.xlarge (4 vCPU, 16 GiB)
- format T3.2xlarge (8 vCPU, 32 GiB)
- ajouter au panier T3a.xlarge (4 vCPU, 16 GiB)
- ajouter au panier T3a.2xlarge (8 vCPU, 32 GiB)
Exemple 2.8. Intensité de mémoire
- format x1.16xlarge (64 vCPU, 976 GiB)
- format x1.32xlarge (128 vCPU, 1,952 GiB)
- ajouter au panier x1e.xlarge (4 vCPU, 122 GiB)
- ajouter au panier x1e.2xlarge (8 vCPU, 244 GiB)
- ajouter au panier x1e.4xlarge (16 vCPU, 488 GiB)
- format x1e.8xlarge (32 vCPU, 976 GiB)
- format x1e.16xlarge (64 vCPU, 1,952 GiB)
- format x1e.32xlarge (128 vCPU, 3 904 GiB)
- ajouter au panier x2idn.16xlarge (64 vCPU, 1 024 GiB)
- format x2idn.24xlarge (96 vCPU, 1 536 GiB)
- format x2idn.32xlarge (128 vCPU, 2,048 GiB)
- ajouter au panier x2iedn.xlarge (4 vCPU, 128 GiB)
- ajouter au panier x2iedn.2xlarge (8 vCPU, 256 GiB)
- ajouter au panier x2iedn.4xlarge (16 vCPU, 512 GiB)
- format x2iedn.8xlarge (32 vCPU, 1 024 GiB)
- format x2iedn.16xlarge (64 vCPU, 2,048 GiB)
- format x2iedn.24xlarge (96 vCPU, 3,072 GiB)
- format x2iedn.32xlarge (128 vCPU, 4,096 GiB)
- ajouter au panier x2iezn.2xlarge (8 vCPU, 256 GiB)
- ajouter au panier x2iezn.4xlarge (16vCPU, 512 GiB)
- ajouter au panier x2iezn.6xlarge (24vCPU, 768 GiB)
- ajouter au panier x2iezn.8xlarge (32vCPU, 1 024 GiB)
- ajouter au panier x2iezn.12xlarge (48vCPU, 1.536 GiB)
- ajouter au panier x2iezn.metal (48 vCPU, 1 536 GiB)
- ajouter au panier x2idn.metal (128vCPU, 2,048 GiB)
- ajouter au panier x2iedn.metal (128vCPU, 4,096 GiB)
Exemple 2.9. La mémoire optimisée
- ajouter au panier R4.xlarge (4 vCPU, 30.5 GiB)
- ajouter au panier R4.2xlarge (8 vCPU, 61 GiB)
- ajouter au panier R4.4xlarge (16 vCPU, 122 GiB)
- largeur de r4.8xlarge (32 vCPU, 244 GiB)
- largeur (64 vCPU, 488 GiB)
- ajouter au panier R5.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R5.2xlarge (8 vCPU, 64 GiB)
- longueur d’écran (16 vCPU, 128 GiB)
- largeur de r5.8xlarge (32 vCPU, 256 GiB)
- largeur de r5.12xlarge (48 vCPU, 384 GiB)
- largeur de r5.16xlarge (64 vCPU, 512 GiB)
- 5,54xlarge (96 vCPU, 768 GiB)
- (96† vCPU, 768 GiB)
- ajouter au panier R5a.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R5a.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R5a.4xlarge (16 vCPU, 128 GiB)
- largeur (32 vCPU, 256 GiB)
- ajouter au panier R5a.12xlarge (48 vCPU, 384 GiB)
- 5a.16xlarge (64 vCPU, 512 GiB)
- largeur de r5a.24xlarge (96 vCPU, 768 GiB)
- ajouter au panier R5ad.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R5ad.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R5ad.4xlarge (16 vCPU, 128 GiB)
- ajouter au panier R5ad.8xlarge (32 vCPU, 256 GiB)
- ajouter au panier R5ad.12xlarge (48 vCPU, 384 GiB)
- ajouter au panier R5ad.16xlarge (64 vCPU, 512 GiB)
- ajouter au panier R5ad.24xlarge (96 vCPU, 768 GiB)
- ajouter au panier R5b.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R5b.2xlarge (8 vCPU, 364 GiB)
- ajouter au panier R5b.4xlarge (16 vCPU, 3,128 GiB)
- largeur de r5b.8xlarge (32 vCPU, 3 256 GiB)
- largeur de r5b.12xlarge (48 vCPU, 3,384 GiB)
- largeur de r5b.16xlarge (64 vCPU, 3,512 GiB)
- largeur de r5b.24xlarge (96 vCPU, 3 768 GiB)
- a) R5b.metal (96 768 GiB)
- ajouter au panier R5d.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R5d.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R5d.4xlarge (16 vCPU, 128 GiB)
- largeur de r5d.8xlarge (32 vCPU, 256 GiB)
- largeur de r5d.12xlarge (48 vCPU, 384 GiB)
- 5d.16xlarge (64 vCPU, 512 GiB)
- largeur de r5d.24xlarge (96 vCPU, 768 GiB)
- le r5d.metal (96† vCPU, 768 GiB)
- ajouter au panier R5n.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R5n.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R5n.4xlarge (16 vCPU, 128 GiB)
- largeur (32 vCPU, 256 GiB)
- ajouter au panier R5n.12xlarge (48 vCPU, 384 GiB)
- 5n.16xlarge (64 vCPU, 512 GiB)
- largeur de r5n.24xlarge (96 vCPU, 768 GiB)
- C5n.metal (96 vCPU, 768 GiB)
- ajouter au panier R5dn.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R5dn.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R5dn.4xlarge (16 vCPU, 128 GiB)
- largeur de r5dn.8xlarge (32 vCPU, 256 GiB)
- ajouter au panier R5dn.12xlarge (48 vCPU, 384 GiB)
- 5dn.16xlarge (64 vCPU, 512 GiB)
- largeur de r5dn.24xlarge (96 vCPU, 768 GiB)
- a) R5dn.metal (96 vCPU, 768 GiB)
- ajouter au panier R6a.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R6a.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R6a.4xlarge (16 vCPU, 128 GiB)
- largeur (32 vCPU, 256 GiB)
- ajouter au panier R6a.12xlarge (48 vCPU, 384 GiB)
- 6a.16xlarge (64 vCPU, 512 GiB)
- 6a.24xlarge (96 vCPU, 768 GiB)
- largeur de r6a.32xlarge (128 vCPU, 1 024 GiB)
- ajouter au panier R6a.48xlarge (192 vCPU, 1 536 GiB)
- ajouter au panier R6i.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R6i.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R6i.4xlarge (16 vCPU, 128 GiB)
- largeur (32 vCPU, 256 GiB)
- ajouter au panier R6i.12xlarge (48 vCPU, 384 GiB)
- 6i.16xlarge (64 vCPU, 512 GiB)
- 6i.24xlarge (96 vCPU, 768 GiB)
- largeur de r6i.32xlarge (128 vCPU, 1 024 GiB)
- (128 vCPU, 1 024 GiB)
- ajouter au panier R6id.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R6id.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R6id.4xlarge (16 vCPU, 128 GiB)
- largeur (32 vCPU, 256 GiB)
- ajouter au panier R6id.12xlarge (48 vCPU, 384 GiB)
- 6id.16xlarge (64 vCPU, 512 GiB)
- largeur de r6id.24xlarge (96 vCPU, 768 GiB)
- largeur de r6id.32xlarge (128 vCPU, 1 024 GiB)
- le R6id.metal (128 vCPU, 1 024 GiB)
- ajouter au panier R6idn.12xlarge (48 vCPU, 384 GiB)
- 6idn.16xlarge (64 vCPU, 512 GiB)
- 24xlarge (96 vCPU, 768 GiB)
- ajouter au panier R6idn.2xlarge (8 vCPU, 64 GiB)
- largeur de r6idn.32xlarge (128 vCPU, 1 024 GiB)
- ajouter au panier R6idn.4xlarge (16 vCPU, 128 GiB)
- largeur (32 vCPU, 256 GiB)
- ajouter au panier R6idn.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R6in.12xlarge (48 vCPU, 384 GiB)
- 6in.16xlarge (64 vCPU, 512 GiB)
- largeur de r6in.24xlarge (96 vCPU, 768 GiB)
- ajouter au panier R6in.2xlarge (8 vCPU, 64 GiB)
- largeur de r6in.32xlarge (128 vCPU, 1 024 GiB)
- 4xlarge (16 vCPU, 128 GiB)
- largeur de r6in.8xlarge (32 vCPU, 256 GiB)
- ajouter au panier R6in.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R7a.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R7a.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R7a.4xlarge (16 vCPU, 128 GiB)
- largeur de r7a.8xlarge (32 vCPU, 256 GiB)
- ajouter au panier R7a.12xlarge (48 vCPU, 384 GiB)
- largeur de r7a.16xlarge (64 vCPU, 512 GiB)
- largeur de r7a.24xlarge (96 vCPU, 768 GiB)
- largeur de r7a.32xlarge (128 vCPU, 1024 GiB)
- ajouter au panier R7a.48xlarge (192 vCPU, 1536 GiB)
- ajouter au panier R7a.metal-48xl (192 vCPU, 1536 GiB)
- ajouter au panier R7i.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R7i.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R7i.4xlarge (16 vCPU, 128 GiB)
- largeur de r7i.8xlarge (32 vCPU, 256 GiB)
- ajouter au panier R7i.12xlarge (48 vCPU, 384 GiB)
- largeur de r7i.16xlarge (64 vCPU, 512 GiB)
- largeur de r7i.24xlarge (96 vCPU, 768 GiB)
- a) R7i.metal-24xl (96 vCPU, 768 GiB)
- ajouter au panier R7iz.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R7iz.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R7iz.4xlarge (16 vCPU, 128 GiB)
- largeur de r7iz.8xlarge (32 vCPU, 256 GiB)
- ajouter au panier R7iz.12xlarge (48 vCPU, 384 GiB)
- largeur de r7iz.16xlarge (64 vCPU, 512 GiB)
- largeur de r7iz.32xlarge (128 vCPU, 1024 GiB)
- ajouter au panier R7iz.metal-16xl (64 vCPU, 512 GiB)
- a) R7iz.metal-32xl (128 vCPU, 1 024 GiB)
- ajouter au panier z1d.xlarge (4 vCPU, 32 GiB)
- ajouter au panier z1d.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier z1d.3xlarge (12 vCPU, 96 GiB)
- ajouter au panier z1d.6xlarge (24 vCPU, 192 GiB)
- format z1d.12xlarge (48 vCPU, 384 GiB)
- ajouter au panier z1d.metal (48^ vCPU, 384 GiB)
† Ces types d’instances offrent 96 processeurs logiques sur 48 cœurs physiques. Ils fonctionnent sur des serveurs uniques avec deux sockets Intel physiques.
Ce type d’instance offre 48 processeurs logiques sur 24 cœurs physiques.
Exemple 2.10. Calcul accéléré
- ajouter au panier P3.2xlarge (8 vCPU, 61 GiB)
- largeur de p3.8xlarge (32 vCPU, 244 GiB)
- largeur de p3.16xlarge (64 vCPU, 488 GiB)
- format p3dn.24xlarge (96 vCPU, 768 GiB)
- format p4d.24xlarge (96 vCPU, 152 GiB)
- ajouter au panier P4de.24xlarge (96 vCPU, 152 GiB)
- format P5.48xlarge (192 vCPU, 2,048 GiB)
- g4ad.xlarge (4 vCPU, 16 GiB)
- g4ad.2xlarge (8 vCPU, 32 GiB)
- g4ad.4xlarge (16 vCPU, 64 GiB)
- g4ad.8xlarge (32 vCPU, 128 GiB)
- g4ad.16xlarge (64 vCPU, 256 GiB)
- g4dn.xlarge (4 vCPU, 16 GiB)
- g4dn.2xlarge (8 vCPU, 32 GiB)
- g4dn.4xlarge (16 vCPU, 64 GiB)
- g4dn.8xlarge (32 vCPU, 128 GiB)
- g4dn.12xlarge (48 vCPU, 192 GiB)
- g4dn.16xlarge (64 vCPU, 256 GiB)
- g4dn.metal (96 vCPU, 384 GiB)
- g5.xlarge (4 vCPU, 16 GiB)
- G5.2xlarge (8 vCPU, 32 GiB)
- g5.4xlarge (16 vCPU, 64 GiB)
- G5.8xlarge (32 vCPU, 128 GiB)
- G5.16xlarge (64 vCPU, 256 GiB)
- g5.12xlarge (48 vCPU, 192 GiB)
- G5.24xlarge (96 vCPU, 384 GiB)
- g5.48xlarge (192 vCPU, 768 GiB)
- dl1.24xlarge (96 vCPU, 768 GiB)†
- g6.xlarge (4 vCPU, 16 GiB)
- G6.2xlarge (8 vCPU, 32 GiB)
- g6.4xlarge (16 vCPU, 64 GiB)
- G6.8xlarge (32 vCPU, 128 GiB)
- g6.12xlarge (48 vCPU, 192 GiB)
- G6.16xlarge (64 vCPU, 256 GiB)
- G6.24xlarge (96 vCPU, 384 GiB)
- g6.48xlarge (192 vCPU, 768 GiB)
- g6e.xlarge (4 vCPU, 32 GiB)
- g6e.2xlarge (8 vCPU, 64 GiB)
- g6e.4xlarge (16 vCPU, 128 GiB)
- g6e.8xlarge (32 vCPU, 256 GiB)
- g6e.12xlarge (48 vCPU, 384 GiB)
- g6e.16xlarge (64 vCPU, 512 GiB)
- g6e.24xlarge (96 vCPU, 768 GiB)
- g6e.48xlarge (192 vCPU, 1 536 GiB)
- gr6.4xlarge (16 vCPU, 128 GiB)
- gr6.8xlarge (32 vCPU, 256 GiB)
† Intel spécifique; non couvert par Nvidia
La prise en charge de la pile logicielle de type d’instance GPU est fournie par AWS. Assurez-vous que vos quotas de service AWS peuvent accueillir les types d’instances GPU souhaités.
Exemple 2.11. Calcul optimisé
- c5.xlarge (4 vCPU, 8 GiB)
- c5.2xlarge (8 vCPU, 16 GiB)
- c5.4xlarge (16 vCPU, 32 GiB)
- c5.9xlarge (36 vCPU, 72 GiB)
- c5.12xlarge (48 vCPU, 96 GiB)
- c5.18xlarge (72 vCPU, 144 GiB)
- c5.24xlarge (96 vCPU, 192 GiB)
- c5.métal (96 vCPU, 192 GiB)
- c5d.xlarge (4 vCPU, 8 GiB)
- c5d.2xlarge (8 vCPU, 16 GiB)
- c5d.4xlarge (16 vCPU, 32 GiB)
- c5d.9xlarge (36 vCPU, 72 GiB)
- c5d.12xlarge (48 vCPU, 96 GiB)
- c5d.18xlarge (72 vCPU, 144 GiB)
- c5d.24xlarge (96 vCPU, 192 GiB)
- c5d.metal (96 vCPU, 192 GiB)
- c5a.xlarge (4 vCPU, 8 GiB)
- c5a.2xlarge (8 vCPU, 16 GiB)
- c5a.4xlarge (16 vCPU, 32 GiB)
- c5a.8xlarge (32 vCPU, 64 GiB)
- c5a.12xlarge (48 vCPU, 96 GiB)
- c5a.16xlarge (64 vCPU, 128 GiB)
- c5a.24xlarge (96 vCPU, 192 GiB)
- c5ad.xlarge (4 vCPU, 8 GiB)
- c5ad.2xlarge (8 vCPU, 16 GiB)
- c5ad.4xlarge (16 vCPU, 32 GiB)
- c5ad.8xlarge (32 vCPU, 64 GiB)
- c5ad.12xlarge (48 vCPU, 96 GiB)
- c5ad.16xlarge (64 vCPU, 128 GiB)
- c5ad.24xlarge (96 vCPU, 192 GiB)
- c5n.xlarge (4 vCPU, 10.5 GiB)
- c5n.2xlarge (8 vCPU, 21 GiB)
- c5n.4xlarge (16 vCPU, 42 GiB)
- c5n.9xlarge (36 vCPU, 96 GiB)
- c5n.18xlarge (72 vCPU, 192 GiB)
- c5n.metal (72 vCPU, 192 GiB)
- c6a.xlarge (4 vCPU, 8 GiB)
- c6a.2xlarge (8 vCPU, 16 GiB)
- c6a.4xlarge (16 vCPU, 32 GiB)
- c6a.8xlarge (32 vCPU, 64 GiB)
- c6a.12xlarge (48 vCPU, 96 GiB)
- c6a.16xlarge (64 vCPU, 128 GiB)
- c6a.24xlarge (96 vCPU, 192 GiB)
- c6a.32xlarge (128 vCPU, 256 GiB)
- c6a.48xlarge (192 vCPU, 384 GiB)
- c6i.xlarge (4 vCPU, 8 GiB)
- c6i.2xlarge (8 vCPU, 16 GiB)
- c6i.4xlarge (16 vCPU, 32 GiB)
- c6i.8xlarge (32 vCPU, 64 GiB)
- c6i.12xlarge (48 vCPU, 96 GiB)
- c6i.16xlarge (64 vCPU, 128 GiB)
- c6i.24xlarge (96 vCPU, 192 GiB)
- c6i.32xlarge (128 vCPU, 256 GiB)
- c6i.metal (128 vCPU, 256 GiB)
- c6id.xlarge (4 vCPU, 8 GiB)
- c6id.2xlarge (8 vCPU, 16 GiB)
- c6id.4xlarge (16 vCPU, 32 GiB)
- c6id.8xlarge (32 vCPU, 64 GiB)
- c6id.12xlarge (48 vCPU, 96 GiB)
- c6id.16xlarge (64 vCPU, 128 GiB)
- c6id.24xlarge (96 vCPU, 192 GiB)
- c6id.32xlarge (128 vCPU, 256 GiB)
- c6id.metal (128 vCPU, 256 GiB)
- c6in.12xlarge (48 vCPU, 96 GiB)
- c6in.16xlarge (64 vCPU, 128 GiB)
- c6in.24xlarge (96 vCPU, 192 GiB)
- c6in.2xlarge (8 vCPU, 16 GiB)
- c6in.32xlarge (128 vCPU, 256 GiB)
- c6in.4xlarge (16 vCPU, 32 GiB)
- c6in.8xlarge (32 vCPU, 64 GiB)
- c6in.xlarge (4 vCPU, 8 GiB)
- c7a.xlarge (4 vCPU, 8 GiB)
- c7a.2xlarge (8 vCPU, 16 GiB)
- c7a.4xlarge (16 vCPU, 32 GiB)
- c7a.8xlarge (32 vCPU, 64 GiB)
- c7a.12xlarge (48 vCPU, 96 GiB)
- c7a.16xlarge (64 vCPU, 128 GiB)
- c7a.24xlarge (96 vCPU, 192 GiB)
- c7a.32xlarge (128 vCPU, 256 GiB)
- c7a.48xlarge (192 vCPU, 384 GiB)
- c7a.metal-48xl (192 vCPU, 384 GiB)
- c7i.xlarge (4 vCPU, 8 GiB)
- c7i.2xlarge (8 vCPU, 16 GiB)
- c7i.4xlarge (16 vCPU, 32 GiB)
- c7i.8xlarge (32 vCPU, 64 GiB)
- c7i.12xlarge (48 vCPU, 96 GiB)
- c7i.16xlarge (64 vCPU, 128 GiB)
- c7i.24xlarge (96 vCPU, 192 GiB)
- c7i.48xlarge (192 vCPU, 384 GiB)
- c7i.metal-24xl (96 vCPU, 192 GiB)
- c7i.metal-48xl (192 vCPU, 384 GiB)
- hpc6a.48xlarge (96 vCPU, 384 GiB)
- hpc6id.32xlarge (64 vCPU, 1024 GiB)
- hpc7a.12xlarge (24 vCPU, 768 GiB)
- hpc7a.24xlarge (48 vCPU, 768 GiB)
- hpc7a.48xlarge (96 vCPU, 768 GiB)
- hpc7a.96xlarge (192 vCPU, 768 GiB)
- format M5zn.12xlarge (48 vCPU, 192 GiB)
- ajouter au panier M5zn.2xlarge (8 vCPU, 32 GiB)
- format M5zn.3xlarge (16 vCPU, 48 GiB)
- format M5zn.6xlarge (32 vCPU, 96 GiB)
- ajouter au panier M5zn.xlarge (4 vCPU, 16 GiB)
Exemple 2.12. Le stockage optimisé
- c5ad.12xlarge (48 vCPU, 96 GiB)
- c5ad.16xlarge (64 vCPU, 128 GiB)
- c5ad.24xlarge (96 vCPU, 192 GiB)
- c5ad.2xlarge (8 vCPU, 16 GiB)
- c5ad.4xlarge (16 vCPU, 32 GiB)
- c5ad.8xlarge (32 vCPU, 64 GiB)
- c5ad.xlarge (4 vCPU, 8 GiB)
- i3.xlarge (4 vCPU, 30.5 GiB)
- i3.2xlarge (8 vCPU, 61 GiB)
- i3.4xlarge (16 vCPU, 122 GiB)
- i3.8xlarge (32 vCPU, 244 GiB)
- i3.16xlarge (64 vCPU, 488 GiB)
- i3.metal (72† vCPU, 512 GiB)
- i3en.xlarge (4 vCPU, 32 GiB)
- i3en.2xlarge (8 vCPU, 64 GiB)
- i3en.3xlarge (12 vCPU, 96 GiB)
- i3en.6xlarge (24 vCPU, 192 GiB)
- i3en.12xlarge (48 vCPU, 384 GiB)
- i3en.24xlarge (96 vCPU, 768 GiB)
- i3en.metal (96 vCPU, 768 GiB)
- i4i.xlarge (4 vCPU, 32 GiB)
- i4i.2xlarge (8 vCPU, 64 GiB)
- i4i.4xlarge (16 vCPU, 128 GiB)
- i4i.8xlarge (32 vCPU, 256 GiB)
- i4i.12xlarge (48 vCPU, 384 GiB)
- i4i.16xlarge (64 vCPU, 512 GiB)
- i4i.24xlarge (96 vCPU, 768 GiB)
- i4i.32xlarge (128 vCPU, 1 024 GiB)
- i4i.metal (128 vCPU, 1 024 GiB)
- ajouter au panier M5ad.xlarge (4 vCPU, 16 GiB)
- ajouter au panier M5ad.2xlarge (8 vCPU, 32 GiB)
- ajouter au panier M5ad.4xlarge (16 vCPU, 64 GiB)
- format M5ad.8xlarge (32 vCPU, 128 GiB)
- ajouter au panier M5ad.12xlarge (48 vCPU, 192 GiB)
- format M5ad.16xlarge (64 vCPU, 256 GiB)
- ajouter au panier M5ad.24xlarge (96 vCPU, 384 GiB)
- ajouter au panier M5d.xlarge (4 vCPU, 16 GiB)
- format M5d.2xlarge (8 vCPU, 32 GiB)
- format M5d.4xlarge (16 vCPU, 64 GiB)
- format M5d.8xlarge (32 vCPU, 28 GiB)
- format M5d.12xlarge (48 vCPU, 192 GiB)
- format M5d.16xlarge (64 vCPU, 256 GiB)
- format M5d.24xlarge (96 vCPU, 384 GiB)
† Ce type d’instance offre 72 processeurs logiques sur 36 cœurs physiques.
Les types d’instances virtuelles initialisent plus rapidement que les types d’instances ".metal".
Exemple 2.13. Haute mémoire
- agrandir U-3tb1.56xlarge (224 vCPU, 3 072 GiB)
- format U-6tb1.56xlarge (224 vCPU, 6,144 GiB)
- ajouter au panier U-6tb1.112xlarge (448 vCPU, 6,144 GiB)
- ajouter au panier U-6tb1.metal (448 vCPU, 6,144 GiB)
- ajouter au panier U-9tb1.112xlarge (448 vCPU, 9,216 GiB)
- ajouter au panier U-9tb1.metal (448 vCPU, 9,216 GiB)
- ajouter au panier U-12tb1.112xlarge (448 vCPU, 12,288 GiB)
- ajouter au panier U-12tb1.metal (448 vCPU, 12 288 GiB)
- ajouter au panier U-18tb1.metal (448 vCPU, 18,432 GiB)
- ajouter au panier U-24tb1.metal (448 vCPU, 24 576 GiB)
- ajouter au panier U-24tb1.112xlarge (448 vCPU, 24 576 GiB)
Exemple 2.14. Le réseau optimisé
- c5n.xlarge (4 vCPU, 10.5 GiB)
- c5n.2xlarge (8 vCPU, 21 GiB)
- c5n.4xlarge (16 vCPU, 42 GiB)
- c5n.9xlarge (36 vCPU, 96 GiB)
- c5n.18xlarge (72 vCPU, 192 GiB)
- ajouter au panier M5dn.xlarge (4 vCPU, 16 GiB)
- ajouter au panier M5dn.2xlarge (8 vCPU, 32 GiB)
- format M5dn.4xlarge (16 vCPU, 64 GiB)
- format M5dn.8xlarge (32 vCPU, 128 GiB)
- format M5dn.12xlarge (48 vCPU, 192 GiB)
- format M5dn.16xlarge (64 vCPU, 256 GiB)
- format M5dn.24xlarge (96 vCPU, 384 GiB)
- format M5n.12xlarge (48 vCPU, 192 GiB)
- format M5n.16xlarge (64 vCPU, 256 GiB)
- format M5n.24xlarge (96 vCPU, 384 GiB)
- ajouter au panier M5n.xlarge (4 vCPU, 16 GiB)
- format M5n.2xlarge (8 vCPU, 32 GiB)
- format M5n.4xlarge (16 vCPU, 64 GiB)
- format M5n.8xlarge (32 vCPU, 128 GiB)
2.5. Le Red Hat OpenShift Service sur AWS met à jour le cycle de vie
2.5.1. Aperçu général
Le Red Hat fournit un cycle de vie des produits publié pour Red Hat OpenShift Service sur AWS afin que les clients et les partenaires puissent planifier, déployer et soutenir efficacement leurs applications en cours d’exécution sur la plateforme. Le Red Hat publie ce cycle de vie pour offrir autant de transparence que possible et pourrait faire des exceptions à ces politiques lorsque des conflits surgissent.
Le Red Hat OpenShift Service sur AWS est une instance gérée de Red Hat OpenShift et maintient un calendrier de sortie indépendant. De plus amples détails sur l’offre gérée peuvent être trouvés dans le service Red Hat OpenShift sur la définition de service AWS. La disponibilité des avis de sécurité et des avis de correction de bogues pour une version spécifique dépend de la politique de cycle de vie de Red Hat OpenShift Container Platform et est soumise au service Red Hat OpenShift sur le calendrier de maintenance AWS.
2.5.2. Définitions
| Format de version | A) Majeur | Le mineur | Le patch | Le major.minor.patch |
|---|---|---|---|---|
| a) x | C) Y | à Z | à propos de x.y.z | |
| Exemple : | 4 | 5 | 21 | 4.5.21 |
- Les versions majeures ou X- Releases
Désignés uniquement comme des versions majeures ou X- Releases (X.y.z).
Exemples
- « Grande version 5 » → 5.y.z
- « Grande version 4 » → 4.y.z
- « Version majeure 3 » → 3.y.z
- Libérations mineures ou sorties Y
Désignés uniquement comme des libérations mineures ou des versions Y (x.Y.z).
Exemples
- "Liminor release 4" → 4.4.z
- "La libération mineure 5" → 4.5.z
- "Liminor release 6" → 4.6.z
- Lancements de patchs ou Z- Releases
Désigne uniquement les versions de patch ou Z- Releases (x.y.Z).
Exemples
- « Patch release 14 de la libération mineure 5 » → 4.5.14
- « Patch release 25 of minor release 5 » → 4.5.25
- « Patch release 26 of minor release 6 » → 4.6.26
2.5.3. Les versions majeures (X.y.z)
Les principales versions de Red Hat OpenShift Service sur AWS, par exemple la version 4, sont prises en charge pendant un an après la sortie d’une version majeure ultérieure ou la retraite du produit.
Exemple :
- « si la version 5 était disponible sur Red Hat OpenShift Service sur AWS le 1er janvier, la version 4 serait autorisée à continuer à fonctionner sur les clusters gérés pendant 12 mois, jusqu’au 31 décembre. Après cette période, les clusters devront être mis à niveau ou migrés vers la version 5.
2.5.4. Les versions mineures (x.Y.z)
À partir de la version mineure de 4.8 OpenShift Container Platform, Red Hat prend en charge toutes les versions mineures pendant au moins 16 mois après la disponibilité générale de la version mineure donnée. Les versions de patch ne sont pas affectées par la période de support.
Les clients sont informés 60, 30 et 15 jours avant la fin de la période d’assistance. Les clusters doivent être mis à niveau vers la dernière version de patch de la version mineure la plus ancienne prise en charge avant la fin de la période de support, ou le cluster entrera un statut « Support limité ».
Exemple :
- Le cluster d’un client est actuellement en cours d’exécution sur 4.13.8. La version 4.13 mineure est devenue généralement disponible le 17 mai 2023.
- Le 19 juillet, le 16 août et le 2 septembre 2024, le client est informé que son cluster entrera dans le statut « Support limité » le 17 septembre 2024 si le cluster n’a pas déjà été mis à niveau vers une version mineure prise en charge.
- Le cluster doit être mis à niveau à 4.14 ou plus tard d’ici le 17 septembre 2024.
- Dans le cas où la mise à jour n’a pas été effectuée, le cluster sera marqué comme étant dans un état de « Support limité ».
2.5.5. Correction des versions (x.y.Z)
Au cours de la période pendant laquelle une version mineure est prise en charge, Red Hat prend en charge toutes les versions de patch OpenShift Container Platform sauf indication contraire.
En raison de la sécurité et de la stabilité de la plate-forme, une version de correctif peut être dépréciée, ce qui empêcherait les installations de cette version et déclencherait des mises à niveau obligatoires de cette version.
Exemple :
- 4.7.6 contient un CVE critique.
- Les versions affectées par le CVE seront supprimées de la liste de diffusion des correctifs pris en charge. De plus, tous les clusters fonctionnant en 4.7.6 seront programmés pour des mises à niveau automatiques dans les 48 heures.
2.5.6. Le statut de soutien limité
Lorsqu’un cluster passe à un statut de support limité, Red Hat ne surveille plus de manière proactive le cluster, le SLA n’est plus applicable et les crédits demandés contre l’ALS sont refusés. Cela ne signifie pas que vous n’avez plus de support produit. Dans certains cas, le cluster peut revenir à un statut entièrement pris en charge si vous corrigez les facteurs de violation. Cependant, dans d’autres cas, vous devrez peut-être supprimer et recréer le cluster.
Il est possible qu’un cluster passe à un statut de support limité pour de nombreuses raisons, y compris les scénarios suivants:
- Lorsque vous ne mettez pas à niveau un cluster vers une version prise en charge avant la date de fin de vie
Le Red Hat ne fait aucune garantie d’exécution ou de SLA pour les versions après leur date de fin de vie. Afin de recevoir un soutien continu, mettez le cluster à une version prise en charge avant la date de fin de vie. Lorsque vous ne mettez pas à niveau le cluster avant la date de fin de vie, le cluster passe à un statut de support limité jusqu’à ce qu’il soit mis à niveau vers une version prise en charge.
Le Red Hat fournit un support commercialement raisonnable pour passer d’une version non prise en charge à une version prise en charge. Cependant, si un chemin de mise à niveau pris en charge n’est plus disponible, vous devrez peut-être créer un nouveau cluster et migrer vos charges de travail.
- Lorsque vous supprimez ou remplacez un service native Red Hat OpenShift sur les composants AWS ou tout autre composant installé et géré par Red Hat
- En cas d’utilisation des autorisations d’administrateur de clusters, Red Hat n’est pas responsable des actions de vos utilisateurs autorisés ou de vos utilisateurs autorisés, y compris celles qui affectent les services d’infrastructure, la disponibilité des services ou la perte de données. Dans le cas où Red Hat détecte de telles actions, le cluster pourrait passer à un statut de support limité. Le Red Hat vous informe du changement d’état et vous devriez soit inverser l’action, soit créer un cas de support pour explorer les étapes d’assainissement qui pourraient vous obliger à supprimer et à recréer le cluster.
Lorsque vous avez des questions sur une action spécifique qui pourrait faire passer un cluster à un statut de support limité ou avoir besoin d’une assistance supplémentaire, ouvrez un ticket de support.
2.5.7. La politique d’exception des versions prises en charge
Le Red Hat se réserve le droit d’ajouter ou de supprimer des versions nouvelles ou existantes, ou de retarder les versions mineures à venir, qui ont été identifiées comme ayant un ou plusieurs problèmes de production critiques ayant un impact sur les bogues ou les problèmes de sécurité sans préavis.
2.5.8. La politique d’installation
Alors que Red Hat recommande l’installation de la dernière version de support, Red Hat OpenShift Service sur AWS prend en charge l’installation de toute version prise en charge comme couvert par la politique précédente.
2.5.9. Des mises à niveau obligatoires
Lorsqu’un CVE critique ou important, ou un autre bug identifié par Red Hat, a un impact significatif sur la sécurité ou la stabilité du cluster, le client doit passer à la prochaine version du correctif pris en charge dans les deux jours ouvrables.
Dans des circonstances extrêmes et sur la base de l’évaluation par Red Hat de la criticité CVE pour l’environnement, Red Hat informera les clients qu’ils disposent de deux jours ouvrables pour planifier ou mettre à jour manuellement leur cluster vers la dernière version sécurisée du patch. Dans le cas où une mise à jour n’est pas effectuée après deux jours ouvrables, Red Hat mettra automatiquement à jour le cluster vers la dernière version de correctif sécurisé afin d’atténuer les failles de sécurité potentielles ou l’instabilité. À sa propre discrétion, Red Hat peut retarder temporairement une mise à jour automatisée si un client le demande par le biais d’un dossier d’assistance.
2.5.10. Dates du cycle de vie
| La version | Disponibilité générale | Fin de vie |
|---|---|---|
| 4.17 | 14 octobre 2024 | 14 février 2026 |
| 4.16 | Juil 2, 2024 | 2 novembre 2025 |
| 4.15 | Fév 27, 2024 | 30 juin 2025 |
| 4.14 | 31 octobre 2023 | 1er mai 2025 |
| 4.13 | 17 mai 2023 | 17 septembre 2024 |
| 4.12 | 17 janv. 2023 | 17 juil. 2024 |
| 4.11 | Août 10, 2022 | Déc 10, 2023 |
| 4.10 | 10 mars 2022 | 10 septembre, 2023 |
| 4.9 | 18 oct 2021 | Décembre 18, 2022 |
| 4.8 | 27 juil. 2021 | 27 septembre 2022 |
2.6. Le Red Hat OpenShift Service sur AWS (ROSA) avec la définition de service des avions de contrôle hébergés (HCP)
Cette documentation décrit la définition du service du service Red Hat OpenShift Service sur AWS (ROSA) avec un service géré par des avions de contrôle hébergés (HCP).
2.6.1. Gestion des comptes
Cette section fournit des informations sur la définition du service pour Red Hat OpenShift Service sur la gestion de compte AWS.
2.6.1.1. Facturation et tarification
Le service Red Hat OpenShift sur AWS est facturé directement sur votre compte Amazon Web Services (AWS). La tarification ROSA est basée sur la consommation, avec des engagements annuels ou des engagements de trois ans pour une plus grande réduction. Le coût total de ROSA se compose de deux composantes:
- Frais de service ROSA
- Frais d’infrastructure AWS
Consultez le Service OpenShift Red Hat sur AWS Pricing page sur le site AWS pour plus de détails.
2.6.1.2. Cluster en libre-service
Les clients peuvent en libre-service leurs clusters, y compris, mais sans s’y limiter:
- Créer un cluster
- Effacer un cluster
- Ajouter ou supprimer un fournisseur d’identité
- Ajouter ou supprimer un utilisateur d’un groupe élevé
- Configurer la confidentialité du cluster
- Ajouter ou supprimer des pools de machines et configurer l’autoscaling
- Définir les politiques de mise à niveau
Ces tâches en libre-service peuvent être exécutées à l’aide du service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.
2.6.1.3. Les types d’instances
L’ensemble des ROSA dotés de clusters HCP nécessitent un minimum de 2 nœuds ouvriers. La fermeture de l’infrastructure sous-jacente via la console fournisseur de cloud n’est pas prise en charge et peut entraîner une perte de données.
Environ un noyau vCPU et 1 GiB de mémoire sont réservés sur chaque nœud de travail et retirés des ressources allocatables. Cette réserve de ressources est nécessaire pour exécuter les processus requis par la plate-forme sous-jacente. Ces processus incluent des démons système tels que udev, kubelet et l’exécution des conteneurs, entre autres. Les ressources réservées tiennent également compte des réservations du noyau.
Les systèmes de base OpenShift Container Platform tels que l’agrégation des journaux d’audit, la collecte des métriques, le DNS, le registre d’images, le SDN et d’autres pourraient consommer des ressources allocatables supplémentaires pour maintenir la stabilité et la maintenabilité du cluster. Les ressources supplémentaires consommées peuvent varier en fonction de l’utilisation.
Consultez la documentation Kubernetes pour plus d’informations.
2.6.1.4. Les régions et les zones de disponibilité
Les régions AWS suivantes sont actuellement disponibles pour ROSA avec HCP.
Les régions chinoises ne sont pas soutenues, quel que soit leur soutien sur OpenShift 4.
Dans le cas des régions de GovCloud (États-Unis), vous devez soumettre une demande d’accès pour Red Hat OpenShift Service sur AWS (ROSA) FedRAMP.
Les régions de GovCloud (États-Unis) ne sont prises en charge que sur les clusters ROSA Classic.
Exemple 2.15. Les régions AWS
- États-Unis-Est-1 (N. Virginie)
- C’est nous-Est-2 (Ohio)
- l’ouest-2 (Oregon)
- AF-south-1 (Cape Town, AWS opt-in requis)
- AP-east-1 (Hong Kong, AWS opt-in requis)
- AP-south-2 (Hyderabad, AWS opt-in requis)
- AP-sud-est-3 (Jakarta, AWS opt-in requis)
- AP-sud-est-4 (Melbourne, AWS opt-in requis)
- AP-sud-1 (Mumbai)
- AP-northeast-3 (Osaka)
- AP-northeast-2 (Seoul)
- AP-sud-est-1 (Singapour)
- AP-sud-est-2 (Sydney)
- AP-northeast-1 (Tokyo)
- ca-central-1 (Centre du Canada)
- EU-central-1 (Francfort)
- EU-north-1 (Stockholm)
- UE-Ouest-1 (Irlande)
- EU-west-2 (Londres)
- EU-Sud-1 (Milan, AWS opt-in requis)
- EU-west-3 (Paris)
- UE-Sud-2 (Espagne)
- EU-central-2 (Zurich, AWS opt-in requis)
- le me-sud-1 (Bahrain, AWS opt-in requis)
- le me-central-1 (UAE, AWS opt-in requis)
- hôtels proches de la SA-east-1 (São Paulo)
Les clusters de zones de disponibilité multiples ne peuvent être déployés que dans les régions avec au moins 3 zones de disponibilité. Consultez la section Régions et Zones de Disponibilité dans la documentation AWS.
Chaque nouvelle ROSA avec le cluster HCP est installée dans un cloud privé virtuel préexistant (VPC) dans une seule région, avec la possibilité de déployer jusqu’au nombre total de zones de disponibilité pour la région donnée. Cela permet d’isoler le réseau et les ressources au niveau du cluster, et permet les paramètres VPC fournisseurs de cloud, tels que les connexions VPN et VPC Peering. Les volumes persistants (PV) sont soutenus par Amazon Elastic Block Storage (Amazon EBS), et sont spécifiques à la zone de disponibilité dans laquelle ils sont fournis. Les revendications de volume persistants (PVC) ne se lient pas à un volume tant que la ressource de la gousse associée n’est pas affectée dans une zone de disponibilité spécifique afin d’éviter les pods imprévus. Les ressources spécifiques à la zone de disponibilité ne sont utilisables que par des ressources dans la même zone de disponibilité.
La région ne peut pas être modifiée après le déploiement d’un cluster.
2.6.1.5. Les zones locales
Le service OpenShift Red Hat sur AWS (ROSA) avec des avions de contrôle hébergés (HCP) ne prend pas en charge l’utilisation des zones locales AWS.
2.6.1.6. Accord de niveau de service (SLA)
Les SLA du service lui-même sont définies à l’annexe 4 de l’Annexe 4 de l’Accord d’entreprise Red Hat (Services d’abonnement en ligne).
2.6.1.7. Le statut de soutien limité
Lorsqu’un cluster passe à un statut de support limité, Red Hat ne surveille plus de manière proactive le cluster, le SLA n’est plus applicable et les crédits demandés contre l’ALS sont refusés. Cela ne signifie pas que vous n’avez plus de support produit. Dans certains cas, le cluster peut revenir à un statut entièrement pris en charge si vous corrigez les facteurs de violation. Cependant, dans d’autres cas, vous devrez peut-être supprimer et recréer le cluster.
Il est possible qu’un cluster passe à un statut de support limité pour de nombreuses raisons, y compris les scénarios suivants:
- Lorsque vous supprimez ou remplacez un service native Red Hat OpenShift sur les composants AWS ou tout autre composant installé et géré par Red Hat
- En cas d’utilisation des autorisations d’administrateur de clusters, Red Hat n’est pas responsable des actions de vos utilisateurs autorisés ou de vos utilisateurs autorisés, y compris celles qui affectent les services d’infrastructure, la disponibilité des services ou la perte de données. Dans le cas où Red Hat détecte de telles actions, le cluster pourrait passer à un statut de support limité. Le Red Hat vous informe du changement d’état et vous devriez soit inverser l’action, soit créer un cas de support pour explorer les étapes d’assainissement qui pourraient vous obliger à supprimer et à recréer le cluster.
Lorsque vous avez des questions sur une action spécifique qui pourrait amener un cluster à passer à un statut de support limité ou à avoir besoin d’aide supplémentaire, ouvrez un ticket d’assistance.
2.6.1.8. Le soutien
Le service OpenShift Red Hat sur AWS inclut le support Red Hat Premium, auquel on peut accéder en utilisant le portail client Red Hat.
Consultez les Conditions d’utilisation de Red Hat Production Support pour connaître les délais de réponse du support.
Le support AWS est soumis au contrat de support existant d’un client avec AWS.
2.6.2. L’exploitation forestière
Le service OpenShift Red Hat sur AWS fournit un transfert de journal intégré optionnel vers Amazon (AWS) CloudWatch.
2.6.2.1. Enregistrement de l’audit en grappes
Les journaux d’audit en cluster sont disponibles via AWS CloudWatch, si l’intégration est activée. Lorsque l’intégration n’est pas activée, vous pouvez demander les journaux d’audit en ouvrant un dossier d’assistance.
2.6.2.2. Enregistrement des applications
Les journaux d’application envoyés à STDOUT sont collectés par Fluentd et transmis à AWS CloudWatch via la pile de journalisation du cluster, s’il est installé.
2.6.3. Le suivi
Cette section fournit des informations sur la définition du service pour Red Hat OpenShift Service sur la surveillance AWS.
2.6.3.1. Les métriques des clusters
Le Red Hat OpenShift Service sur les clusters AWS est livré avec une pile Prometheus intégrée pour la surveillance des clusters, y compris les métriques CPU, mémoire et réseau. Ceci est accessible via la console web. Ces métriques permettent également une mise à l’échelle horizontale de pod basée sur des métriques CPU ou mémoire fournies par un service OpenShift Red Hat sur l’utilisateur AWS.
2.6.3.2. Les notifications de cluster
Les notifications de cluster sont des messages sur l’état, la santé ou les performances de votre cluster.
Les notifications de cluster sont la principale façon dont Red Hat Site Reliability Engineering (SRE) communique avec vous sur la santé de votre cluster géré. Le SRE peut également utiliser des notifications de cluster pour vous inviter à effectuer une action afin de résoudre ou d’empêcher un problème avec votre cluster.
Les propriétaires de clusters et les administrateurs doivent régulièrement examiner et agir les notifications de clusters pour s’assurer que les clusters restent en bonne santé et pris en charge.
Dans l’onglet Historique des clusters de votre cluster, vous pouvez afficher les notifications de cluster dans la console de cloud hybride Red Hat. Par défaut, seul le propriétaire du cluster reçoit des notifications de cluster sous forme d’e-mails. Lorsque d’autres utilisateurs doivent recevoir des e-mails de notification en cluster, ajoutez chaque utilisateur comme contact de notification pour votre cluster.
2.6.4. Le réseautage
Cette section fournit des informations sur la définition du service pour Red Hat OpenShift Service sur le réseau AWS.
2.6.4.1. Domaines personnalisés pour les applications
À partir de Red Hat OpenShift Service sur AWS 4.14, l’opérateur de domaine personnalisé est obsolète. Afin de gérer Ingress dans Red Hat OpenShift Service sur AWS 4.14 ou version ultérieure, utilisez l’opérateur Ingress. La fonctionnalité est inchangée pour Red Hat OpenShift Service sur AWS 4.13 et versions antérieures.
Afin d’utiliser un nom d’hôte personnalisé pour un itinéraire, vous devez mettre à jour votre fournisseur DNS en créant un enregistrement de nom canonique (CNAME). L’enregistrement CNAME doit cartographier le nom d’hôte du routeur canonique OpenShift à votre domaine personnalisé. Le nom d’hôte du routeur canonique OpenShift est affiché sur la page Détails de l’itinéraire après la création d’une route. Alternativement, un enregistrement générique CNAME peut être créé une fois pour acheminer tous les sous-domaines d’un nom d’hôte donné vers le routeur du cluster.
2.6.4.2. Certificats validés par domaine
Le service OpenShift Red Hat sur AWS inclut les certificats de sécurité TLS nécessaires pour les services internes et externes sur le cluster. Dans le cas des routes externes, il existe deux certificats TLS Wildcard distincts qui sont fournis et installés sur chaque cluster: l’un est pour la console Web et les noms d’hôte par défaut d’itinéraire, et l’autre pour le point de terminaison API. Let's Encrypt est l’autorité de certification utilisée pour les certificats. Les itinéraires à l’intérieur du cluster, tels que le point de terminaison interne de l’API, utilisent les certificats TLS signés par l’autorité de certification intégrée du cluster et exigent le paquet CA disponible dans chaque pod pour faire confiance au certificat TLS.
2.6.4.3. Autorités de certification personnalisées pour les constructions
Le service OpenShift Red Hat sur AWS prend en charge l’utilisation d’autorités de certification personnalisées pour être fiable par les builds lors de l’extraction d’images à partir d’un registre d’images.
2.6.4.4. Balanceurs de charge
Le service OpenShift Red Hat sur AWS (ROSA) avec des plans de contrôle hébergés (HCP) déploie uniquement des équilibreurs de charge à partir du contrôleur d’entrée par défaut. Les autres balanceurs de charge peuvent être déployés en option par un client pour les contrôleurs d’entrée secondaires ou les balanceurs de charge Service.
2.6.4.5. Entrée de cluster
Les administrateurs de projet peuvent ajouter des annotations d’itinéraire à de nombreuses fins différentes, y compris le contrôle d’entrée grâce à la liste d’autorisations IP.
Les stratégies d’entrée peuvent également être modifiées en utilisant les objets NetworkPolicy, qui exploitent le plugin ovs-networkpolicy. Cela permet un contrôle total de la stratégie réseau d’entrée jusqu’au niveau pod, y compris entre les pods sur le même cluster et même dans le même espace de noms.
L’ensemble du trafic d’entrée de cluster passera par les équilibreurs de charge définis. L’accès direct à tous les nœuds est bloqué par la configuration du cloud.
2.6.4.6. Egress de cluster
Le contrôle du trafic par le biais des objets EgressNetworkPolicy peut être utilisé pour prévenir ou limiter le trafic sortant dans Red Hat OpenShift Service sur AWS (ROSA) avec des avions de contrôle hébergés (HCP).
2.6.4.7. Configuration du réseau cloud
Le service Red Hat OpenShift sur AWS permet la configuration d’une connexion réseau privée via des technologies gérées par AWS, telles que:
- Connexions VPN
- Peering VPC
- Passerelle de transit
- Connexion directe
Les ingénieurs de fiabilité du site Red Hat (SRE) ne surveillent pas les connexions de réseau privé. La surveillance de ces connexions relève de la responsabilité du client.
2.6.4.8. Envoi DNS
Dans le cas de Red Hat OpenShift Service sur les clusters AWS qui ont une configuration de réseau cloud privé, un client peut spécifier des serveurs DNS internes disponibles sur cette connexion privée, qui devraient être interrogés pour les domaines explicitement fournis.
2.6.4.9. La vérification du réseau
Les vérifications réseau s’exécutent automatiquement lorsque vous déployez un service Red Hat OpenShift sur le cluster AWS dans un cloud privé virtuel (VPC) existant ou créez un pool de machines supplémentaire avec un sous-réseau qui est nouveau dans votre cluster. Les vérifications valident votre configuration réseau et mettent en évidence les erreurs, vous permettant de résoudre les problèmes de configuration avant le déploiement.
Il est également possible d’exécuter manuellement les vérifications réseau pour valider la configuration d’un cluster existant.
2.6.5. Le stockage
Cette section fournit des informations sur la définition de service pour Red Hat OpenShift Service sur AWS (ROSA) avec stockage de plans de contrôle hébergés (HCP).
2.6.5.1. Stockage crypté des systèmes d’exploitation et des nœuds
Les nœuds de travail utilisent le stockage Amazon Elastic Block Store (Amazon EBS) crypté au repos.
2.6.5.2. Crypté au repos PV
Les volumes EBS utilisés pour les PV sont cryptés au repos par défaut.
2.6.5.3. Bloc de stockage (RWO)
Les volumes persistants (PV) sont soutenus par Amazon Elastic Block Store (Amazon EBS), qui est Read-Write-Once.
Les PVS ne peuvent être attachés qu’à un seul nœud à la fois et sont spécifiques à la zone de disponibilité dans laquelle ils ont été approvisionnés. Cependant, les PV peuvent être attachés à n’importe quel nœud dans la zone de disponibilité.
Chaque fournisseur de cloud a ses propres limites pour combien de PV peuvent être attachés à un seul nœud. Consultez les limites de type d’instance AWS pour plus de détails.
2.6.6. La plate-forme
Cette section fournit des informations sur la définition du service pour la plateforme Red Hat OpenShift Service sur AWS (ROSA).
2.6.6.1. Autoscaling
La mise à l’échelle automatique des nœuds est disponible sur le service Red Hat OpenShift sur AWS. Il est possible de configurer l’option autoscaler pour mettre automatiquement à l’échelle le nombre de machines d’un cluster.
2.6.6.2. Daemonsets
Les clients peuvent créer et exécuter des démons sur Red Hat OpenShift Service sur AWS. Afin de limiter les daemonsets à ne fonctionner que sur les nœuds ouvriers, utilisez le nodeSelector suivant:
spec:
nodeSelector:
role: worker
spec:
nodeSelector:
role: worker2.6.6.3. La zone de disponibilité multiple
Dans un cluster de zones de disponibilité multiple, les nœuds de plan de contrôle sont répartis entre les zones de disponibilité et au moins un nœud de travail est requis dans chaque zone de disponibilité.
2.6.6.4. Étiquettes des nœuds
Les étiquettes de nœuds personnalisés sont créées par Red Hat lors de la création de nœuds et ne peuvent pas être modifiées sur Red Hat OpenShift Service sur les clusters AWS pour le moment. Cependant, les étiquettes personnalisées sont prises en charge lors de la création de nouveaux pools de machines.
2.6.6.5. La stratégie de sauvegarde des clusters
Le Red Hat ne fournit pas de méthode de sauvegarde pour les clusters ROSA qui utilisent STS. Il est essentiel que les clients disposent d’un plan de sauvegarde pour leurs applications et leurs données d’application.
Les sauvegardes de données d’applications et d’applications ne font pas partie du service Red Hat OpenShift sur AWS.
Le tableau ci-dessous ne s’applique qu’aux clusters non STS. Les composants suivants sont utilisés par Red Hat dans des circonstances atténuantes.
| Composante | Fréquence de prise de vue | La rétention | Les notes |
|---|---|---|---|
| Sauvegarde complète du magasin d’objets | Au quotidien | 7 jours | Il s’agit d’une sauvegarde complète de tous les objets Kubernetes comme etcd. Aucun volume persistant (PV) n’est sauvegardé dans ce calendrier de sauvegarde. |
| Chaque semaine | 30 jours | ||
| Sauvegarde complète du magasin d’objets | Horaire | 24 heures | Il s’agit d’une sauvegarde complète de tous les objets Kubernetes comme etcd. Aucun PV n’est sauvegardé dans ce calendrier de sauvegarde. |
| Le volume de racine des nœuds | Jamais jamais | C) N/A | Les nœuds sont considérés comme à court terme. Aucune critique ne doit être stockée sur le volume racine d’un nœud. |
2.6.6.6. La version OpenShift
Le service Red Hat OpenShift sur AWS est exécuté en tant que service et est tenu à jour avec la dernière version OpenShift Container Platform. La planification des mises à niveau vers la dernière version est disponible.
2.6.6.7. Des mises à niveau
Les mises à niveau peuvent être programmées à l’aide du ROSA CLI, rosa ou via OpenShift Cluster Manager.
Consultez le service Red Hat OpenShift sur AWS Life Cycle pour plus d’informations sur la politique et les procédures de mise à niveau.
2.6.6.8. Conteneurs Windows
La prise en charge de Red Hat OpenShift pour les conteneurs Windows n’est pas disponible sur Red Hat OpenShift Service sur AWS pour le moment.
2.6.6.9. Conteneur moteur
Le Red Hat OpenShift Service sur AWS fonctionne sur OpenShift 4 et utilise CRI-O comme seul moteur de conteneur disponible.
2.6.6.10. Le système d’exploitation
Le Red Hat OpenShift Service sur AWS fonctionne sur OpenShift 4 et utilise Red Hat CoreOS comme système d’exploitation pour tous les avions de contrôle et les nœuds de travail.
2.6.6.11. Assistance de Red Hat Operator
Les charges de travail Red Hat se réfèrent généralement aux opérateurs fournis par Red Hat mis à disposition par l’intermédiaire de l’opérateur Hub. Les charges de travail Red Hat ne sont pas gérées par l’équipe Red Hat SRE et doivent être déployées sur les nœuds des travailleurs. Ces opérateurs peuvent nécessiter des abonnements supplémentaires à Red Hat et peuvent entraîner des coûts d’infrastructure cloud supplémentaires. Des exemples de ces opérateurs fournis par Red Hat sont:
- Chapeau rouge Quay
- Gestion avancée des clusters Red Hat
- Ajouter au panier Red Hat Advanced Cluster Security
- Chapeau rouge OpenShift Service Mesh
- Informations sur OpenShift Serverless
- Coupe rouge OpenShift Logging
- Chapeau rouge OpenShift Pipelines
2.6.6.12. Assistance de l’opérateur Kubernetes
Les opérateurs inscrits sur le marché OperatorHub devraient être disponibles pour l’installation. Ces opérateurs sont considérés comme des charges de travail des clients et ne sont pas surveillés par Red Hat SRE.
2.6.7. La sécurité
Cette section fournit des informations sur la définition de service pour Red Hat OpenShift Service sur AWS (ROSA) avec la sécurité des avions de contrôle hébergés (HCP).
2.6.7.1. Fournisseur d’authentification
L’authentification pour le cluster peut être configurée en utilisant OpenShift Cluster Manager ou le processus de création de cluster ou en utilisant le ROSA CLI, rosa. La ROSA n’est pas un fournisseur d’identité, et tout accès au cluster doit être géré par le client dans le cadre de sa solution intégrée. L’utilisation de plusieurs fournisseurs d’identité fournis en même temps est prise en charge. Les fournisseurs d’identité suivants sont pris en charge:
- GitHub ou GitHub Enterprise
- GitLab
- LDAP
- Connexion d’OpenID
- htpasswd
2.6.7.2. Conteneurs privilégiés
Des conteneurs privilégiés sont disponibles pour les utilisateurs ayant le rôle de cluster-admin. L’utilisation de conteneurs privilégiés en tant que cluster-admin est assujettie aux responsabilités et aux notes d’exclusion figurant à l’annexe 4 de l’Accord d’entreprise Red Hat (Services d’abonnement en ligne).
2.6.7.3. Administrateur client utilisateur
En plus des utilisateurs normaux, Red Hat OpenShift Service sur AWS (ROSA) avec des avions de contrôle hébergés (HCP) donne accès à un ROSA avec un groupe spécifique HCP appelé admin dédié. Les utilisateurs du cluster qui sont membres du groupe admin dédié:
- Avoir un accès administrateur à tous les projets créés par le client sur le cluster.
- Gérer les quotas de ressources et les limites du cluster.
- Il peut ajouter et gérer des objets NetworkPolicy.
- Ils sont capables d’afficher des informations sur des nœuds spécifiques et des PV dans le cluster, y compris les informations sur les planificateurs.
- Accéder au projet admin réservé sur le cluster, ce qui permet la création de comptes de service avec des privilèges élevés et permet également de mettre à jour les limites et les quotas par défaut pour les projets sur le cluster.
- Il peut installer des Opérateurs depuis OperatorHub et exécuter tous les verbes dans tous les groupes d’API *.operators.coreos.com.
2.6.7.4. Le rôle de l’administration des clusters
L’administrateur de Red Hat OpenShift Service sur AWS (ROSA) avec des plans de contrôle hébergés (HCP) a un accès par défaut au rôle d’administration cluster pour le cluster de votre organisation. Alors qu’ils sont connectés à un compte avec le rôle de cluster-admin, les utilisateurs ont augmenté les autorisations d’exécuter des contextes de sécurité privilégiés.
2.6.7.5. Libre-service de projet
Par défaut, tous les utilisateurs ont la possibilité de créer, de mettre à jour et de supprimer leurs projets. Cela peut être restreint si un membre du groupe admin dédié supprime le rôle d’auto-fournisseur des utilisateurs authentifiés:
oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauth
$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated:oauthLes restrictions peuvent être annulées en appliquant:
oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth
$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated:oauth2.6.7.6. Conformité réglementaire
Consultez le tableau de conformité dans Comprendre le processus et la sécurité de ROSA pour obtenir les dernières informations sur la conformité.
2.6.7.7. La sécurité du réseau
Avec Red Hat OpenShift Service sur AWS, AWS fournit une protection DDoS standard sur tous les équilibreurs de charge, appelé AWS Shield. Cela offre une protection de 95 % contre les attaques de niveau 3 et 4 les plus couramment utilisées sur l’ensemble des balanceurs de charge publics utilisés pour Red Hat OpenShift Service sur AWS. Le délai de 10 secondes est ajouté pour les requêtes HTTP arrivant sur le routeur haproxy pour recevoir une réponse ou la connexion est fermée pour fournir une protection supplémentaire.
2.6.7.8. chiffrement etcd
Dans Red Hat OpenShift Service sur AWS (ROSA) avec des plans de contrôle hébergés (HCP), le stockage du plan de contrôle est crypté au repos par défaut et cela inclut le chiffrement des volumes etcd. Ce chiffrement de niveau de stockage est fourni via la couche de stockage du fournisseur de cloud.
La base de données etcd est toujours cryptée par défaut. Les clients peuvent choisir de fournir leurs propres clés AWS KMS personnalisées dans le but de chiffrer la base de données etcd.
Le chiffrement etcd chiffrera les ressources suivantes du serveur API Kubernetes et du serveur OpenShift API:
- Les secrets
- Configuration des cartes
- Itinéraires
- Jetons d’accès OAuth
- Autoriser les jetons OAuth
2.7. Le service OpenShift Red Hat sur AWS (ROSA) avec des types d’instances de plans de contrôle hébergés (HCP)
La ROSA avec HCP offre les types et tailles d’instances de nœuds de travail suivants:
Actuellement, ROSA avec HCP prend en charge un maximum de 500 nœuds ouvriers.
2.7.1. Les types d’instances AWS x86
Exemple 2.16. But général
- format M5.xlarge (4 vCPU, 16 GiB)
- format M5.2xlarge (8 vCPU, 32 GiB)
- format M5.4xlarge (16 vCPU, 64 GiB)
- format M5.8xlarge (32 vCPU, 128 GiB)
- format M5.12xlarge (48 vCPU, 192 GiB)
- format M5.16xlarge (64 vCPU, 256 GiB)
- format M5.24xlarge (96 vCPU, 384 GiB)
- ajouter au panier M5.metal (96† vCPU, 384 GiB)
- ajouter au panier M5a.xlarge (4 vCPU, 16 GiB)
- format M5a.2xlarge (8 vCPU, 32 GiB)
- format M5a.4xlarge (16 vCPU, 64 GiB)
- format M5a.8xlarge (32 vCPU, 128 GiB)
- format M5a.12xlarge (48 vCPU, 192 GiB)
- format M5a.16xlarge (64 vCPU, 256 GiB)
- format M5a.24xlarge (96 vCPU, 384 GiB)
- ajouter au panier M5dn.metal (96 vCPU, 384 GiB)
- ajouter au panier M5zn.metal (48 vCPU, 192 GiB)
- ajouter au panier M5d.metal (96† vCPU, 384 GiB)
- ajouter au panier M5n.metal (96 vCPU, 384 GiB)
- ajouter au panier M6a.xlarge (4 vCPU, 16 GiB)
- format M6a.2xlarge (8 vCPU, 32 GiB)
- format M6a.4xlarge (16 vCPU, 64 GiB)
- format M6a.8xlarge (32 vCPU, 128 GiB)
- format M6a.12xlarge (48 vCPU, 192 GiB)
- format M6a.16xlarge (64 vCPU, 256 GiB)
- format M6a.24xlarge (96 vCPU, 384 GiB)
- format M6a.32xlarge (128 vCPU, 512 GiB)
- format M6a.48xlarge (192 vCPU, 768 GiB)
- ajouter au panier M6a.metal (192 vCPU, 768 GiB)
- ajouter au panier M6i.xlarge (4 vCPU, 16 GiB)
- ajouter au panier M6i.2xlarge (8 vCPU, 32 GiB)
- format M6i.4xlarge (16 vCPU, 64 GiB)
- format M6i.8xlarge (32 vCPU, 128 GiB)
- format M6i.12xlarge (48 vCPU, 192 GiB)
- format M6i.16xlarge (64 vCPU, 256 GiB)
- format M6i.24xlarge (96 vCPU, 384 GiB)
- format M6i.32xlarge (128 vCPU, 512 GiB)
- ajouter au panier M6i.metal (128 vCPU, 512 GiB)
- ajouter au panier M6id.xlarge (4 vCPU, 16 GiB)
- ajouter au panier M6id.2xlarge (8 vCPU, 32 GiB)
- format M6id.4xlarge (16 vCPU, 64 GiB)
- format M6id.8xlarge (32 vCPU, 128 GiB)
- format M6id.12xlarge (48 vCPU, 192 GiB)
- format M6id.16xlarge (64 vCPU, 256 GiB)
- format M6id.24xlarge (96 vCPU, 384 GiB)
- format M6id.32xlarge (128 vCPU, 512 GiB)
- ajouter au panier M6id.metal (128 vCPU, 512 GiB)
- ajouter au panier M6idn.xlarge (4 vCPU, 16 GiB)
- ajouter au panier M6idn.2xlarge (8 vCPU, 32 GiB)
- format M6idn.4xlarge (16 vCPU, 64 GiB)
- format M6idn.8xlarge (32 vCPU, 128 GiB)
- format M6idn.12xlarge (48 vCPU, 192 GiB)
- format M6idn.16xlarge (64 vCPU, 256 GiB)
- format M6idn.24xlarge (96 vCPU, 384 GiB)
- format M6idn.32xlarge (128 vCPU, 512 GiB)
- ajouter au panier M6in.xlarge (4 vCPU, 16 GiB)
- format M6in.2xlarge (8 vCPU, 32 GiB)
- format M6in.4xlarge (16 vCPU, 64 GiB)
- format M6in.8xlarge (32 vCPU, 128 GiB)
- format M6in.12xlarge (48 vCPU, 192 GiB)
- format M6in.16xlarge (64 vCPU, 256 GiB)
- format M6in.24xlarge (96 vCPU, 384 GiB)
- format M6in.32xlarge (128 vCPU, 512 GiB)
- ajouter au panier M7a.xlarge (4 vCPU, 16 GiB)
- format M7a.2xlarge (8 vCPU, 32 GiB)
- format M7a.4xlarge (16 vCPU, 64 GiB)
- format M7a.8xlarge (32 vCPU, 128 GiB)
- format M7a.12xlarge (48 vCPU, 192 GiB)
- format M7a.16xlarge (64 vCPU, 256 GiB)
- format M7a.24xlarge (96 vCPU, 384 GiB)
- format M7a.32xlarge (128 vCPU, 512 GiB)
- format M7a.48xlarge (192 vCPU, 768 GiB)
- ajouter au panier M7a.metal-48xl (192 vCPU, 768 GiB)
- ajouter au panier M7i-flex.2xlarge (8 vCPU, 32 GiB)
- format M7i-flex.4xlarge (16 vCPU, 64 GiB)
- format M7i-flex.8xlarge (32 vCPU, 128 GiB)
- ajouter au panier M7i-flex.xlarge (4 vCPU, 16 GiB)
- ajouter au panier M7i.xlarge (4 vCPU, 16 GiB)
- format M7i.2xlarge (8 vCPU, 32 GiB)
- format M7i.4xlarge (16 vCPU, 64 GiB)
- format M7i.8xlarge (32 vCPU, 128 GiB)
- format M7i.12xlarge (48 vCPU, 192 GiB)
- format M7i.16xlarge (64 vCPU, 256 GiB)
- format M7i.24xlarge (96 vCPU, 384 GiB)
- format M7i.48xlarge (192 vCPU, 768 GiB)
- ajouter au panier M7i.metal-24xl (96 vCPU, 384 GiB)
- ajouter au panier M7i.metal-48xl (192 vCPU, 768 GiB)
† Ces types d’instances offrent 96 processeurs logiques sur 48 cœurs physiques. Ils fonctionnent sur des serveurs uniques avec deux sockets Intel physiques.
Exemple 2.17. Rafale à usage général
- ajouter au panier T3.xlarge (4 vCPU, 16 GiB)
- format T3.2xlarge (8 vCPU, 32 GiB)
- ajouter au panier T3a.xlarge (4 vCPU, 16 GiB)
- ajouter au panier T3a.2xlarge (8 vCPU, 32 GiB)
Exemple 2.18. Intensité de mémoire
- format x1.16xlarge (64 vCPU, 976 GiB)
- format x1.32xlarge (128 vCPU, 1,952 GiB)
- ajouter au panier x1e.xlarge (4 vCPU, 122 GiB)
- ajouter au panier x1e.2xlarge (8 vCPU, 244 GiB)
- ajouter au panier x1e.4xlarge (16 vCPU, 488 GiB)
- format x1e.8xlarge (32 vCPU, 976 GiB)
- format x1e.16xlarge (64 vCPU, 1,952 GiB)
- format x1e.32xlarge (128 vCPU, 3 904 GiB)
- ajouter au panier x2idn.16xlarge (64 vCPU, 1 024 GiB)
- format x2idn.24xlarge (96 vCPU, 1 536 GiB)
- format x2idn.32xlarge (128 vCPU, 2,048 GiB)
- ajouter au panier x2iedn.xlarge (4 vCPU, 128 GiB)
- ajouter au panier x2iedn.2xlarge (8 vCPU, 256 GiB)
- ajouter au panier x2iedn.4xlarge (16 vCPU, 512 GiB)
- format x2iedn.8xlarge (32 vCPU, 1 024 GiB)
- format x2iedn.16xlarge (64 vCPU, 2,048 GiB)
- format x2iedn.24xlarge (96 vCPU, 3,072 GiB)
- format x2iedn.32xlarge (128 vCPU, 4,096 GiB)
- ajouter au panier x2iezn.2xlarge (8 vCPU, 256 GiB)
- ajouter au panier x2iezn.4xlarge (16vCPU, 512 GiB)
- ajouter au panier x2iezn.6xlarge (24vCPU, 768 GiB)
- ajouter au panier x2iezn.8xlarge (32vCPU, 1 024 GiB)
- ajouter au panier x2iezn.12xlarge (48vCPU, 1.536 GiB)
- ajouter au panier x2iezn.metal (48 vCPU, 1 536 GiB)
- ajouter au panier x2idn.metal (128vCPU, 2,048 GiB)
- ajouter au panier x2iedn.metal (128vCPU, 4,096 GiB)
Exemple 2.19. La mémoire optimisée
- ajouter au panier R4.xlarge (4 vCPU, 30.5 GiB)
- ajouter au panier R4.2xlarge (8 vCPU, 61 GiB)
- ajouter au panier R4.4xlarge (16 vCPU, 122 GiB)
- largeur de r4.8xlarge (32 vCPU, 244 GiB)
- largeur (64 vCPU, 488 GiB)
- ajouter au panier R5.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R5.2xlarge (8 vCPU, 64 GiB)
- longueur d’écran (16 vCPU, 128 GiB)
- largeur de r5.8xlarge (32 vCPU, 256 GiB)
- largeur de r5.12xlarge (48 vCPU, 384 GiB)
- largeur de r5.16xlarge (64 vCPU, 512 GiB)
- 5,54xlarge (96 vCPU, 768 GiB)
- (96† vCPU, 768 GiB)
- ajouter au panier R5a.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R5a.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R5a.4xlarge (16 vCPU, 128 GiB)
- largeur (32 vCPU, 256 GiB)
- ajouter au panier R5a.12xlarge (48 vCPU, 384 GiB)
- 5a.16xlarge (64 vCPU, 512 GiB)
- largeur de r5a.24xlarge (96 vCPU, 768 GiB)
- ajouter au panier R5ad.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R5ad.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R5ad.4xlarge (16 vCPU, 128 GiB)
- ajouter au panier R5ad.8xlarge (32 vCPU, 256 GiB)
- ajouter au panier R5ad.12xlarge (48 vCPU, 384 GiB)
- ajouter au panier R5ad.16xlarge (64 vCPU, 512 GiB)
- ajouter au panier R5ad.24xlarge (96 vCPU, 768 GiB)
- ajouter au panier R5b.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R5b.2xlarge (8 vCPU, 364 GiB)
- ajouter au panier R5b.4xlarge (16 vCPU, 3,128 GiB)
- largeur de r5b.8xlarge (32 vCPU, 3 256 GiB)
- largeur de r5b.12xlarge (48 vCPU, 3,384 GiB)
- largeur de r5b.16xlarge (64 vCPU, 3,512 GiB)
- largeur de r5b.24xlarge (96 vCPU, 3 768 GiB)
- a) R5b.metal (96 768 GiB)
- ajouter au panier R5d.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R5d.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R5d.4xlarge (16 vCPU, 128 GiB)
- largeur de r5d.8xlarge (32 vCPU, 256 GiB)
- largeur de r5d.12xlarge (48 vCPU, 384 GiB)
- 5d.16xlarge (64 vCPU, 512 GiB)
- largeur de r5d.24xlarge (96 vCPU, 768 GiB)
- le r5d.metal (96† vCPU, 768 GiB)
- ajouter au panier R5n.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R5n.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R5n.4xlarge (16 vCPU, 128 GiB)
- largeur (32 vCPU, 256 GiB)
- ajouter au panier R5n.12xlarge (48 vCPU, 384 GiB)
- 5n.16xlarge (64 vCPU, 512 GiB)
- largeur de r5n.24xlarge (96 vCPU, 768 GiB)
- C5n.metal (96 vCPU, 768 GiB)
- ajouter au panier R5dn.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R5dn.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R5dn.4xlarge (16 vCPU, 128 GiB)
- largeur de r5dn.8xlarge (32 vCPU, 256 GiB)
- ajouter au panier R5dn.12xlarge (48 vCPU, 384 GiB)
- 5dn.16xlarge (64 vCPU, 512 GiB)
- largeur de r5dn.24xlarge (96 vCPU, 768 GiB)
- a) R5dn.metal (96 vCPU, 768 GiB)
- ajouter au panier R6a.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R6a.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R6a.4xlarge (16 vCPU, 128 GiB)
- largeur (32 vCPU, 256 GiB)
- ajouter au panier R6a.12xlarge (48 vCPU, 384 GiB)
- 6a.16xlarge (64 vCPU, 512 GiB)
- 6a.24xlarge (96 vCPU, 768 GiB)
- largeur de r6a.32xlarge (128 vCPU, 1 024 GiB)
- ajouter au panier R6a.48xlarge (192 vCPU, 1 536 GiB)
- ajouter au panier R6i.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R6i.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R6i.4xlarge (16 vCPU, 128 GiB)
- largeur (32 vCPU, 256 GiB)
- ajouter au panier R6i.12xlarge (48 vCPU, 384 GiB)
- 6i.16xlarge (64 vCPU, 512 GiB)
- 6i.24xlarge (96 vCPU, 768 GiB)
- largeur de r6i.32xlarge (128 vCPU, 1 024 GiB)
- (128 vCPU, 1 024 GiB)
- ajouter au panier R6id.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R6id.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R6id.4xlarge (16 vCPU, 128 GiB)
- largeur (32 vCPU, 256 GiB)
- ajouter au panier R6id.12xlarge (48 vCPU, 384 GiB)
- 6id.16xlarge (64 vCPU, 512 GiB)
- largeur de r6id.24xlarge (96 vCPU, 768 GiB)
- largeur de r6id.32xlarge (128 vCPU, 1 024 GiB)
- le R6id.metal (128 vCPU, 1 024 GiB)
- ajouter au panier R6idn.12xlarge (48 vCPU, 384 GiB)
- 6idn.16xlarge (64 vCPU, 512 GiB)
- 24xlarge (96 vCPU, 768 GiB)
- ajouter au panier R6idn.2xlarge (8 vCPU, 64 GiB)
- largeur de r6idn.32xlarge (128 vCPU, 1 024 GiB)
- ajouter au panier R6idn.4xlarge (16 vCPU, 128 GiB)
- largeur (32 vCPU, 256 GiB)
- ajouter au panier R6idn.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R6in.12xlarge (48 vCPU, 384 GiB)
- 6in.16xlarge (64 vCPU, 512 GiB)
- largeur de r6in.24xlarge (96 vCPU, 768 GiB)
- ajouter au panier R6in.2xlarge (8 vCPU, 64 GiB)
- largeur de r6in.32xlarge (128 vCPU, 1 024 GiB)
- 4xlarge (16 vCPU, 128 GiB)
- largeur de r6in.8xlarge (32 vCPU, 256 GiB)
- ajouter au panier R6in.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R7a.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R7a.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R7a.4xlarge (16 vCPU, 128 GiB)
- largeur de r7a.8xlarge (32 vCPU, 256 GiB)
- ajouter au panier R7a.12xlarge (48 vCPU, 384 GiB)
- largeur de r7a.16xlarge (64 vCPU, 512 GiB)
- largeur de r7a.24xlarge (96 vCPU, 768 GiB)
- largeur de r7a.32xlarge (128 vCPU, 1024 GiB)
- ajouter au panier R7a.48xlarge (192 vCPU, 1536 GiB)
- ajouter au panier R7a.metal-48xl (192 vCPU, 1536 GiB)
- ajouter au panier R7i.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R7i.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R7i.4xlarge (16 vCPU, 128 GiB)
- largeur de r7i.8xlarge (32 vCPU, 256 GiB)
- ajouter au panier R7i.12xlarge (48 vCPU, 384 GiB)
- largeur de r7i.16xlarge (64 vCPU, 512 GiB)
- largeur de r7i.24xlarge (96 vCPU, 768 GiB)
- a) R7i.metal-24xl (96 vCPU, 768 GiB)
- ajouter au panier R7iz.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R7iz.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R7iz.4xlarge (16 vCPU, 128 GiB)
- largeur de r7iz.8xlarge (32 vCPU, 256 GiB)
- ajouter au panier R7iz.12xlarge (48 vCPU, 384 GiB)
- largeur de r7iz.16xlarge (64 vCPU, 512 GiB)
- largeur de r7iz.32xlarge (128 vCPU, 1024 GiB)
- ajouter au panier R7iz.metal-16xl (64 vCPU, 512 GiB)
- a) R7iz.metal-32xl (128 vCPU, 1 024 GiB)
- ajouter au panier z1d.xlarge (4 vCPU, 32 GiB)
- ajouter au panier z1d.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier z1d.3xlarge (12 vCPU, 96 GiB)
- ajouter au panier z1d.6xlarge (24 vCPU, 192 GiB)
- format z1d.12xlarge (48 vCPU, 384 GiB)
- ajouter au panier z1d.metal (48^ vCPU, 384 GiB)
† Ces types d’instances offrent 96 processeurs logiques sur 48 cœurs physiques. Ils fonctionnent sur des serveurs uniques avec deux sockets Intel physiques.
Ce type d’instance offre 48 processeurs logiques sur 24 cœurs physiques.
Exemple 2.20. Calcul accéléré
- ajouter au panier P3.2xlarge (8 vCPU, 61 GiB)
- largeur de p3.8xlarge (32 vCPU, 244 GiB)
- largeur de p3.16xlarge (64 vCPU, 488 GiB)
- format p3dn.24xlarge (96 vCPU, 768 GiB)
- format p4d.24xlarge (96 vCPU, 152 GiB)
- ajouter au panier P4de.24xlarge (96 vCPU, 152 GiB)
- format P5.48xlarge (192 vCPU, 2,048 GiB)
- g4ad.xlarge (4 vCPU, 16 GiB)
- g4ad.2xlarge (8 vCPU, 32 GiB)
- g4ad.4xlarge (16 vCPU, 64 GiB)
- g4ad.8xlarge (32 vCPU, 128 GiB)
- g4ad.16xlarge (64 vCPU, 256 GiB)
- g4dn.xlarge (4 vCPU, 16 GiB)
- g4dn.2xlarge (8 vCPU, 32 GiB)
- g4dn.4xlarge (16 vCPU, 64 GiB)
- g4dn.8xlarge (32 vCPU, 128 GiB)
- g4dn.12xlarge (48 vCPU, 192 GiB)
- g4dn.16xlarge (64 vCPU, 256 GiB)
- g4dn.metal (96 vCPU, 384 GiB)
- g5.xlarge (4 vCPU, 16 GiB)
- G5.2xlarge (8 vCPU, 32 GiB)
- g5.4xlarge (16 vCPU, 64 GiB)
- G5.8xlarge (32 vCPU, 128 GiB)
- G5.16xlarge (64 vCPU, 256 GiB)
- g5.12xlarge (48 vCPU, 192 GiB)
- G5.24xlarge (96 vCPU, 384 GiB)
- g5.48xlarge (192 vCPU, 768 GiB)
- dl1.24xlarge (96 vCPU, 768 GiB)†
- g6.xlarge (4 vCPU, 16 GiB)
- G6.2xlarge (8 vCPU, 32 GiB)
- g6.4xlarge (16 vCPU, 64 GiB)
- G6.8xlarge (32 vCPU, 128 GiB)
- g6.12xlarge (48 vCPU, 192 GiB)
- G6.16xlarge (64 vCPU, 256 GiB)
- G6.24xlarge (96 vCPU, 384 GiB)
- g6.48xlarge (192 vCPU, 768 GiB)
- g6e.xlarge (4 vCPU, 32 GiB)
- g6e.2xlarge (8 vCPU, 64 GiB)
- g6e.4xlarge (16 vCPU, 128 GiB)
- g6e.8xlarge (32 vCPU, 256 GiB)
- g6e.12xlarge (48 vCPU, 384 GiB)
- g6e.16xlarge (64 vCPU, 512 GiB)
- g6e.24xlarge (96 vCPU, 768 GiB)
- g6e.48xlarge (192 vCPU, 1 536 GiB)
- gr6.4xlarge (16 vCPU, 128 GiB)
- gr6.8xlarge (32 vCPU, 256 GiB)
† Intel spécifique; non couvert par Nvidia
La prise en charge de la pile logicielle de type d’instance GPU est fournie par AWS. Assurez-vous que vos quotas de service AWS peuvent accueillir les types d’instances GPU souhaités.
Exemple 2.21. Calcul optimisé
- c5.xlarge (4 vCPU, 8 GiB)
- c5.2xlarge (8 vCPU, 16 GiB)
- c5.4xlarge (16 vCPU, 32 GiB)
- c5.9xlarge (36 vCPU, 72 GiB)
- c5.12xlarge (48 vCPU, 96 GiB)
- c5.18xlarge (72 vCPU, 144 GiB)
- c5.24xlarge (96 vCPU, 192 GiB)
- c5.métal (96 vCPU, 192 GiB)
- c5d.xlarge (4 vCPU, 8 GiB)
- c5d.2xlarge (8 vCPU, 16 GiB)
- c5d.4xlarge (16 vCPU, 32 GiB)
- c5d.9xlarge (36 vCPU, 72 GiB)
- c5d.12xlarge (48 vCPU, 96 GiB)
- c5d.18xlarge (72 vCPU, 144 GiB)
- c5d.24xlarge (96 vCPU, 192 GiB)
- c5d.metal (96 vCPU, 192 GiB)
- c5a.xlarge (4 vCPU, 8 GiB)
- c5a.2xlarge (8 vCPU, 16 GiB)
- c5a.4xlarge (16 vCPU, 32 GiB)
- c5a.8xlarge (32 vCPU, 64 GiB)
- c5a.12xlarge (48 vCPU, 96 GiB)
- c5a.16xlarge (64 vCPU, 128 GiB)
- c5a.24xlarge (96 vCPU, 192 GiB)
- c5ad.xlarge (4 vCPU, 8 GiB)
- c5ad.2xlarge (8 vCPU, 16 GiB)
- c5ad.4xlarge (16 vCPU, 32 GiB)
- c5ad.8xlarge (32 vCPU, 64 GiB)
- c5ad.12xlarge (48 vCPU, 96 GiB)
- c5ad.16xlarge (64 vCPU, 128 GiB)
- c5ad.24xlarge (96 vCPU, 192 GiB)
- c5n.xlarge (4 vCPU, 10.5 GiB)
- c5n.2xlarge (8 vCPU, 21 GiB)
- c5n.4xlarge (16 vCPU, 42 GiB)
- c5n.9xlarge (36 vCPU, 96 GiB)
- c5n.18xlarge (72 vCPU, 192 GiB)
- c5n.metal (72 vCPU, 192 GiB)
- c6a.xlarge (4 vCPU, 8 GiB)
- c6a.2xlarge (8 vCPU, 16 GiB)
- c6a.4xlarge (16 vCPU, 32 GiB)
- c6a.8xlarge (32 vCPU, 64 GiB)
- c6a.12xlarge (48 vCPU, 96 GiB)
- c6a.16xlarge (64 vCPU, 128 GiB)
- c6a.24xlarge (96 vCPU, 192 GiB)
- c6a.32xlarge (128 vCPU, 256 GiB)
- c6a.48xlarge (192 vCPU, 384 GiB)
- c6i.xlarge (4 vCPU, 8 GiB)
- c6i.2xlarge (8 vCPU, 16 GiB)
- c6i.4xlarge (16 vCPU, 32 GiB)
- c6i.8xlarge (32 vCPU, 64 GiB)
- c6i.12xlarge (48 vCPU, 96 GiB)
- c6i.16xlarge (64 vCPU, 128 GiB)
- c6i.24xlarge (96 vCPU, 192 GiB)
- c6i.32xlarge (128 vCPU, 256 GiB)
- c6i.metal (128 vCPU, 256 GiB)
- c6id.xlarge (4 vCPU, 8 GiB)
- c6id.2xlarge (8 vCPU, 16 GiB)
- c6id.4xlarge (16 vCPU, 32 GiB)
- c6id.8xlarge (32 vCPU, 64 GiB)
- c6id.12xlarge (48 vCPU, 96 GiB)
- c6id.16xlarge (64 vCPU, 128 GiB)
- c6id.24xlarge (96 vCPU, 192 GiB)
- c6id.32xlarge (128 vCPU, 256 GiB)
- c6id.metal (128 vCPU, 256 GiB)
- c6in.12xlarge (48 vCPU, 96 GiB)
- c6in.16xlarge (64 vCPU, 128 GiB)
- c6in.24xlarge (96 vCPU, 192 GiB)
- c6in.2xlarge (8 vCPU, 16 GiB)
- c6in.32xlarge (128 vCPU, 256 GiB)
- c6in.4xlarge (16 vCPU, 32 GiB)
- c6in.8xlarge (32 vCPU, 64 GiB)
- c6in.xlarge (4 vCPU, 8 GiB)
- c7a.xlarge (4 vCPU, 8 GiB)
- c7a.2xlarge (8 vCPU, 16 GiB)
- c7a.4xlarge (16 vCPU, 32 GiB)
- c7a.8xlarge (32 vCPU, 64 GiB)
- c7a.12xlarge (48 vCPU, 96 GiB)
- c7a.16xlarge (64 vCPU, 128 GiB)
- c7a.24xlarge (96 vCPU, 192 GiB)
- c7a.32xlarge (128 vCPU, 256 GiB)
- c7a.48xlarge (192 vCPU, 384 GiB)
- c7a.metal-48xl (192 vCPU, 384 GiB)
- c7i.xlarge (4 vCPU, 8 GiB)
- c7i.2xlarge (8 vCPU, 16 GiB)
- c7i.4xlarge (16 vCPU, 32 GiB)
- c7i.8xlarge (32 vCPU, 64 GiB)
- c7i.12xlarge (48 vCPU, 96 GiB)
- c7i.16xlarge (64 vCPU, 128 GiB)
- c7i.24xlarge (96 vCPU, 192 GiB)
- c7i.48xlarge (192 vCPU, 384 GiB)
- c7i.metal-24xl (96 vCPU, 192 GiB)
- c7i.metal-48xl (192 vCPU, 384 GiB)
- hpc6a.48xlarge (96 vCPU, 384 GiB)
- hpc6id.32xlarge (64 vCPU, 1024 GiB)
- hpc7a.12xlarge (24 vCPU, 768 GiB)
- hpc7a.24xlarge (48 vCPU, 768 GiB)
- hpc7a.48xlarge (96 vCPU, 768 GiB)
- hpc7a.96xlarge (192 vCPU, 768 GiB)
- format M5zn.12xlarge (48 vCPU, 192 GiB)
- ajouter au panier M5zn.2xlarge (8 vCPU, 32 GiB)
- format M5zn.3xlarge (16 vCPU, 48 GiB)
- format M5zn.6xlarge (32 vCPU, 96 GiB)
- ajouter au panier M5zn.xlarge (4 vCPU, 16 GiB)
Exemple 2.22. Le stockage optimisé
- c5ad.12xlarge (48 vCPU, 96 GiB)
- c5ad.16xlarge (64 vCPU, 128 GiB)
- c5ad.24xlarge (96 vCPU, 192 GiB)
- c5ad.2xlarge (8 vCPU, 16 GiB)
- c5ad.4xlarge (16 vCPU, 32 GiB)
- c5ad.8xlarge (32 vCPU, 64 GiB)
- c5ad.xlarge (4 vCPU, 8 GiB)
- i3.xlarge (4 vCPU, 30.5 GiB)
- i3.2xlarge (8 vCPU, 61 GiB)
- i3.4xlarge (16 vCPU, 122 GiB)
- i3.8xlarge (32 vCPU, 244 GiB)
- i3.16xlarge (64 vCPU, 488 GiB)
- i3.metal (72† vCPU, 512 GiB)
- i3en.xlarge (4 vCPU, 32 GiB)
- i3en.2xlarge (8 vCPU, 64 GiB)
- i3en.3xlarge (12 vCPU, 96 GiB)
- i3en.6xlarge (24 vCPU, 192 GiB)
- i3en.12xlarge (48 vCPU, 384 GiB)
- i3en.24xlarge (96 vCPU, 768 GiB)
- i3en.metal (96 vCPU, 768 GiB)
- i4i.xlarge (4 vCPU, 32 GiB)
- i4i.2xlarge (8 vCPU, 64 GiB)
- i4i.4xlarge (16 vCPU, 128 GiB)
- i4i.8xlarge (32 vCPU, 256 GiB)
- i4i.12xlarge (48 vCPU, 384 GiB)
- i4i.16xlarge (64 vCPU, 512 GiB)
- i4i.24xlarge (96 vCPU, 768 GiB)
- i4i.32xlarge (128 vCPU, 1 024 GiB)
- i4i.metal (128 vCPU, 1 024 GiB)
- ajouter au panier M5ad.xlarge (4 vCPU, 16 GiB)
- ajouter au panier M5ad.2xlarge (8 vCPU, 32 GiB)
- ajouter au panier M5ad.4xlarge (16 vCPU, 64 GiB)
- format M5ad.8xlarge (32 vCPU, 128 GiB)
- ajouter au panier M5ad.12xlarge (48 vCPU, 192 GiB)
- format M5ad.16xlarge (64 vCPU, 256 GiB)
- ajouter au panier M5ad.24xlarge (96 vCPU, 384 GiB)
- ajouter au panier M5d.xlarge (4 vCPU, 16 GiB)
- format M5d.2xlarge (8 vCPU, 32 GiB)
- format M5d.4xlarge (16 vCPU, 64 GiB)
- format M5d.8xlarge (32 vCPU, 28 GiB)
- format M5d.12xlarge (48 vCPU, 192 GiB)
- format M5d.16xlarge (64 vCPU, 256 GiB)
- format M5d.24xlarge (96 vCPU, 384 GiB)
† Ce type d’instance offre 72 processeurs logiques sur 36 cœurs physiques.
Les types d’instances virtuelles initialisent plus rapidement que les types d’instances ".metal".
Exemple 2.23. Haute mémoire
- agrandir U-3tb1.56xlarge (224 vCPU, 3 072 GiB)
- format U-6tb1.56xlarge (224 vCPU, 6,144 GiB)
- ajouter au panier U-6tb1.112xlarge (448 vCPU, 6,144 GiB)
- ajouter au panier U-6tb1.metal (448 vCPU, 6,144 GiB)
- ajouter au panier U-9tb1.112xlarge (448 vCPU, 9,216 GiB)
- ajouter au panier U-9tb1.metal (448 vCPU, 9,216 GiB)
- ajouter au panier U-12tb1.112xlarge (448 vCPU, 12,288 GiB)
- ajouter au panier U-12tb1.metal (448 vCPU, 12 288 GiB)
- ajouter au panier U-18tb1.metal (448 vCPU, 18,432 GiB)
- ajouter au panier U-24tb1.metal (448 vCPU, 24 576 GiB)
- ajouter au panier U-24tb1.112xlarge (448 vCPU, 24 576 GiB)
Exemple 2.24. Le réseau optimisé
- c5n.xlarge (4 vCPU, 10.5 GiB)
- c5n.2xlarge (8 vCPU, 21 GiB)
- c5n.4xlarge (16 vCPU, 42 GiB)
- c5n.9xlarge (36 vCPU, 96 GiB)
- c5n.18xlarge (72 vCPU, 192 GiB)
- ajouter au panier M5dn.xlarge (4 vCPU, 16 GiB)
- ajouter au panier M5dn.2xlarge (8 vCPU, 32 GiB)
- format M5dn.4xlarge (16 vCPU, 64 GiB)
- format M5dn.8xlarge (32 vCPU, 128 GiB)
- format M5dn.12xlarge (48 vCPU, 192 GiB)
- format M5dn.16xlarge (64 vCPU, 256 GiB)
- format M5dn.24xlarge (96 vCPU, 384 GiB)
- format M5n.12xlarge (48 vCPU, 192 GiB)
- format M5n.16xlarge (64 vCPU, 256 GiB)
- format M5n.24xlarge (96 vCPU, 384 GiB)
- ajouter au panier M5n.xlarge (4 vCPU, 16 GiB)
- format M5n.2xlarge (8 vCPU, 32 GiB)
- format M5n.4xlarge (16 vCPU, 64 GiB)
- format M5n.8xlarge (32 vCPU, 128 GiB)
2.7.2. AWS Arm-based Graviton types d’instances
En plus de l’architecture x86, ROSA avec HCP offre les types et tailles suivants d’instances de nœuds Graviton basés sur le bras:
Les types d’instances graviton ne sont disponibles que pour les nouveaux clusters créés après le 24 juillet 2024.
Exemple 2.25. But général
- a1.xlarge (2 vCPU, 4 GiB)
- a1.2xlarge (4 vCPU, 8 GiB)
- a1.4xlarge (8 vCPU, 16 GiB)
- a1.Métal (16 vCPU, 32 GiB)
- ajouter au panier M6G.xlarge (2 vCPU, 8 GiB)
- format M6G.2xlarge (4 vCPU, 16 GiB)
- format M6G.4xlarge (8 vCPU, 32 GiB)
- format M6G.8xlarge (32 vCPU, 128 GiB)
- format M6g.12xlarge (48 vCPU, 192 GiB)
- format M6G.16xlarge (64 vCPU, 256 GiB)
- ajouter au panier M6G.metal (64 vCPU, 256 GiB)
- ajouter au panier M6gd.xlarge (2 vCPU, 8 GiB)
- ajouter au panier M6gd.2xlarge (4 vCPU, 16 GiB)
- ajouter au panier M6gd.4xlarge (8 vCPU, 32 GiB)
- format M6gd.8xlarge (32 vCPU, 128 GiB)
- format M6gd.12xlarge (48 vCPU, 192 GiB)
- format M6gd.16xlarge (64 vCPU, 256 GiB)
- ajouter au panier M6gd.metal (64 vCPU, 256 GiB)
- ajouter au panier M7G.xlarge (2 vCPU, 8 GiB)
- format M7g.2xlarge (4 vCPU, 16 GiB)
- format M7g.4xlarge (8 vCPU, 32 GiB)
- format M7g.8xlarge (32 vCPU, 128 GiB)
- format M7g.12xlarge (48 vCPU, 192 GiB)
- format M7g.16xlarge (64 vCPU, 256 GiB)
- ajouter au panier M7G.metal (64 vCPU, 256 GiB)
- format M7gd.2xlarge (4 vCPU, 16 GiB)
- format M7gd.4xlarge (8 vCPU, 32 GiB)
- format M7gd.8xlarge (32 vCPU, 128 GiB)
- format M7gd.12xlarge (48 vCPU, 192 GiB)
- format M7gd.16xlarge (64 vCPU, 256 GiB)
- ajouter au panier M7gd.xlarge (2 vCPU, 8 GiB)
- ajouter au panier M7gd.metal (64 vCPU, 256 GiB)
Exemple 2.26. Rafale à usage général
- ajouter au panier T4G.xlarge (4 vCPU, 16 GiB)
- ajouter au panier T4g.2xlarge (8 vCPU, 32 GiB)
Exemple 2.27. Intensité de mémoire
- ajouter au panier x2Gd.xlarge (2 vCPU, 64 GiB)
- format x2gd.2xlarge (4 vCPU, 128 GiB)
- format x2gd.4xlarge (8 vCPU, 256 GiB)
- ajouter au panier x2gd.8xlarge (16 vCPU, 512 GiB)
- format x2gd.12xlarge (32 vCPU, 768 GiB)
- format x2gd.16xlarge (64 vCPU, 1 024 GiB)
- ajouter au panier x2gd.metal (64 vCPU, 1 024 GiB)
- ajouter au panier x8G.xlarge (4 vCPU, 64 GiB)
- ajouter au panier x8G.2xlarge (8 vCPU, 128 GiB)
- format x8G.4xlarge (16 vCPU, 256 GiB)
- format x8G.8xlarge (32 vCPU, 512 GiB)
- format x8G.12xlarge (48 vCPU, 768 GiB)
- format x8G.16xlarge (64 vCPU, 1 024 GiB)
- format x8G.24xlarge (96 vCPU, 1 536 GiB)
- ajouter au panier x8G.48xlarge (192 vCPU, 3,072 GiB)
- ajouter au panier x8G.metal-24xl (96 vCPU, 1 536 GiB)
- ajouter au panier x8G.metal-48xl (192 vCPU, 3,072 GiB)
Exemple 2.28. La mémoire optimisée
- ajouter au panier R6G.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R6G.2xlarge (8 vCPU, 64 GiB)
- 4xlarge (16 vCPU, 128 GiB)
- largeur de r6g.8xlarge (32 vCPU, 256 GiB)
- largeur (48 vCPU, 384 GiB)
- 6g.16xlarge (64 vCPU, 512 GiB)
- 6G.metal (64 vCPU, 512 GiB)
- ajouter au panier R6Gd.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R6gd.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R6gd.4xlarge (16 vCPU, 128 GiB)
- largeur (32 vCPU, 256 GiB)
- ajouter au panier R6gd.12xlarge (48 vCPU, 384 GiB)
- 6gd.16xlarge (64 vCPU, 512 GiB)
- 6gd.metal (64 vCPU, 512 GiB)
- ajouter au panier R7G.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R7G.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R7G.4xlarge (16 vCPU, 128 GiB)
- largeur de r7g.8xlarge (32 vCPU, 256 GiB)
- largeur de r7g.12xlarge (48 vCPU, 384 GiB)
- largeur de r7g.16xlarge (64 vCPU, 512 GiB)
- le r7g.metal (64 vCPU, 512 GiB)
- ajouter au panier R7Gd.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R7gd.2xlarge (8 vCPU, 64 GiB)
- ajouter au panier R7gd.4xlarge (16 vCPU, 128 GiB)
- largeur de r7gd.8xlarge (32 vCPU, 256 GiB)
- ajouter au panier R7gd.12xlarge (48 vCPU, 384 GiB)
- largeur de r7gd.16xlarge (64 vCPU, 512 GiB)
- le r7gd.metal (64 vCPU, 512 GiB)
- ajouter au panier R8G.xlarge (4 vCPU, 32 GiB)
- ajouter au panier R8G.2xlarge (8 vCPU, 64 GiB)
- G8G.4xlarge (16 vCPU, 128 GiB)
- largeur (32 vCPU, 256 GiB)
- ajouter au panier R8G.12xlarge (48 vCPU, 384 GiB)
- largeur de r8g.16xlarge (64 vCPU, 512 GiB)
- largeur de r8g.24xlarge (96 vCPU, 768 GiB)
- ajouter au panier R8G.48xlarge (192 vCPU, 1 536 GiB)
- ajouter au panier R8G.metal-24xl (96 vCPU, 768 GiB)
- ajouter au panier R8G.metal-48xl (192 vCPU, 1 536 GiB)
Exemple 2.29. Calcul accéléré
- g5G.xlarge (4 vCPU, 8 GiB)
- g5G.2xlarge (8 vCPU, 16 GiB)
- G5G.4xlarge (16 vCPU, 32 GiB)
- G5G.8xlarge (32 vCPU, 64 GiB)
- g5G.16xlarge (64 vCPU, 128 GiB)
- G5G.metal (64 vCPU, 128 GiB)
Exemple 2.30. Calcul optimisé
- c6G.xlarge (4 vCPU, 8 GiB)
- c6G.2xlarge (8 vCPU, 16 GiB)
- c6g.4xlarge (16 vCPU, 32 GiB)
- c6g.8xlarge (32 vCPU, 64 GiB)
- c6g.12xlarge (48 vCPU, 96 GiB)
- c6G.16xlarge (64 vCPU, 128 GiB)
- c6G.metal (64 vCPU, 128 GiB)
- c6gd.xlarge (4 vCPU, 8 GiB)
- c6gd.2xlarge (8 vCPU, 16 GiB)
- c6gd.4xlarge (16 vCPU, 32 GiB)
- c6gd.8xlarge (32 vCPU, 64 GiB)
- c6gd.12xlarge (48 vCPU, 96 GiB)
- c6gd.16xlarge (64 vCPU, 128 GiB)
- c6gd.metal (64 vCPU, 128 GiB)
- c6gn.xlarge (4 vCPU, 8 GiB)
- c6gn.2xlarge (8 vCPU, 16 GiB)
- c6gn.4xlarge (16 vCPU, 32 GiB)
- c6gn.8xlarge (32 vCPU, 64 GiB)
- c6gn.12xlarge (48 vCPU, 96 GiB)
- c6gn.16xlarge (64 vCPU, 128 GiB)
- c7G.xlarge (4 vCPU, 8 GiB)
- c7G.2xlarge (4 vCPU, 8 GiB)
- c7g.4xlarge (16 vCPU, 32 GiB)
- c7g.8xlarge (32 vCPU, 64 GiB)
- c7g.12xlarge (48 vCPU, 96 GiB)
- c7G.16xlarge (64 vCPU, 128 GiB)
- c7G.metal (64 vCPU, 128 GiB)
- c7gd.xlarge (4 vCPU, 8 GiB)
- c7gd.2xlarge (4 vCPU, 8 GiB)
- c7gd.4xlarge (16 vCPU, 32 GiB)
- c7gd.8xlarge (32 vCPU, 64 GiB)
- c7gd.12xlarge (48 vCPU, 96 GiB)
- c7gd.16xlarge (64 vCPU, 128 GiB)
- c7gd.metal (64 vCPU, 128 GiB)
- c7gn.xlarge (4 vCPU, 8 GiB)
- c7gn.2xlarge (8 vCPU, 16 GiB)
- c7gn.4xlarge (16 vCPU, 32 GiB)
- c7gn.8xlarge (32 vCPU, 64 GiB)
- c7gn.12xlarge (48 vCPU, 96 GiB)
- c7gn.16xlarge (64 vCPU, 128 GiB)
- c7gn.metal (64 vCPU, 128 GiB)
Exemple 2.31. Le stockage optimisé
- i4G.xlarge (4 vCPU, 32 GiB)
- i4G.2xlarge (8 vCPU, 64 GiB)
- i4G.4xlarge (16 vCPU, 128 GiB)
- i4G.8xlarge (32 vCPU, 256 GiB)
- i4G.16xlarge (64 vCPU, 512 GiB)
- is4gen.xlarge (4 vCPU, 16 GiB)
- is4gen.2xlarge (8 vCPU, 32 GiB)
- is4gen.4xlarge (16 vCPU, 64 GiB)
- is4gen.8xlarge (32 vCPU, 128 GiB)
- im4gn.xlarge (4 vCPU, 16 GiB)
- im4gn.2xlarge (8 vCPU, 32 GiB)
- im4gn.4xlarge (16 vCPU, 64 GiB)
- im4gn.8xlarge (32 vCPU, 128 GiB)
- im4gn.16xlarge (64 vCPU, 256 GiB)
Exemple 2.32. Calcul haute performance (HPC)
- hpc7g.4xlarge (16 vCPU, 128 GiB)
- hpc7g.8xlarge (32 vCPU, 128 GiB)
- hpc7g.16xlarge (64 vCPU, 128 GiB)
2.8. Cycle de vie de la mise à jour de la ROSA avec HCP
2.8.1. Aperçu général
Le Red Hat fournit un cycle de vie des produits publié pour Red Hat OpenShift Service sur AWS afin que les clients et les partenaires puissent planifier, déployer et soutenir efficacement leurs applications en cours d’exécution sur la plateforme. Le Red Hat publie ce cycle de vie pour offrir autant de transparence que possible et pourrait faire des exceptions à ces politiques lorsque des conflits surgissent.
Le Red Hat OpenShift Service sur AWS est une instance gérée de Red Hat OpenShift et maintient un calendrier de sortie indépendant. De plus amples détails sur l’offre gérée peuvent être trouvés dans le service Red Hat OpenShift sur la définition de service AWS. La disponibilité des avis de sécurité et des avis de correction de bogues pour une version spécifique dépend de la politique de cycle de vie de Red Hat OpenShift Container Platform et est soumise au service Red Hat OpenShift sur le calendrier de maintenance AWS.
2.8.2. Définitions
| Format de version | A) Majeur | Le mineur | Le patch | Le major.minor.patch |
|---|---|---|---|---|
| a) x | C) Y | à Z | à propos de x.y.z | |
| Exemple : | 4 | 5 | 21 | 4.5.21 |
- Les versions majeures ou X- Releases
Désignés uniquement comme des versions majeures ou X- Releases (X.y.z).
Exemples
- « Grande version 5 » → 5.y.z
- « Grande version 4 » → 4.y.z
- « Version majeure 3 » → 3.y.z
- Libérations mineures ou sorties Y
Désignés uniquement comme des libérations mineures ou des versions Y (x.Y.z).
Exemples
- "Liminor release 4" → 4.4.z
- "La libération mineure 5" → 4.5.z
- "Liminor release 6" → 4.6.z
- Lancements de patchs ou Z- Releases
Désigne uniquement les versions de patch ou Z- Releases (x.y.Z).
Exemples
- « Patch release 14 de la libération mineure 5 » → 4.5.14
- « Patch release 25 of minor release 5 » → 4.5.25
- « Patch release 26 of minor release 6 » → 4.6.26
2.8.3. Les versions majeures (X.y.z)
Les principales versions de Red Hat OpenShift Service sur AWS, par exemple la version 4, sont prises en charge pendant un an après la sortie d’une version majeure ultérieure ou la retraite du produit.
Exemple :
- « si la version 5 était disponible sur Red Hat OpenShift Service sur AWS le 1er janvier, la version 4 serait autorisée à continuer à fonctionner sur les clusters gérés pendant 12 mois, jusqu’au 31 décembre. Après cette période, les clusters devront être mis à niveau ou migrés vers la version 5.
2.8.4. Les versions mineures (x.Y.z)
À partir de la version mineure de 4.8 OpenShift Container Platform, Red Hat prend en charge toutes les versions mineures pendant au moins 16 mois après la disponibilité générale de la version mineure donnée. Les versions de patch ne sont pas affectées par la période de support.
Les clients sont informés 60, 30 et 15 jours avant la fin de la période d’assistance. Les clusters doivent être mis à niveau vers la dernière version de patch de la version mineure la plus ancienne prise en charge avant la fin de la période de support, ou Red Hat mettra automatiquement à niveau le plan de contrôle vers la prochaine version mineure prise en charge.
Exemple :
- Le cluster d’un client est actuellement en cours d’exécution sur 4.13.8. La version 4.13 mineure est devenue généralement disponible le 17 mai 2023.
- Le 19 juillet, le 16 août et le 2 septembre 2024, le client est informé que son cluster entrera dans le statut « Support limité » le 17 septembre 2024 si le cluster n’a pas déjà été mis à niveau vers une version mineure prise en charge.
- Le cluster doit être mis à niveau à 4.14 ou plus tard d’ici le 17 septembre 2024.
- Dans le cas où la mise à niveau n’a pas été effectuée, le plan de contrôle du cluster sera automatiquement mis à niveau au 4.14.26, et il n’y aura pas de mises à niveau automatiques vers les nœuds de travail du cluster.
2.8.5. Correction des versions (x.y.Z)
Au cours de la période pendant laquelle une version mineure est prise en charge, Red Hat prend en charge toutes les versions de patch OpenShift Container Platform sauf indication contraire.
En raison de la sécurité et de la stabilité de la plate-forme, une version de correctif peut être dépréciée, ce qui empêcherait les installations de cette version et déclencherait des mises à niveau obligatoires de cette version.
Exemple :
- 4.7.6 contient un CVE critique.
- Les versions affectées par le CVE seront supprimées de la liste de diffusion des correctifs pris en charge. De plus, tous les clusters fonctionnant en 4.7.6 seront programmés pour des mises à niveau automatiques dans les 48 heures.
2.8.6. Le statut de soutien limité
Lorsqu’un cluster passe à un statut de support limité, Red Hat ne surveille plus de manière proactive le cluster, le SLA n’est plus applicable et les crédits demandés contre l’ALS sont refusés. Cela ne signifie pas que vous n’avez plus de support produit. Dans certains cas, le cluster peut revenir à un statut entièrement pris en charge si vous corrigez les facteurs de violation. Cependant, dans d’autres cas, vous devrez peut-être supprimer et recréer le cluster.
Il est possible qu’un cluster passe à un statut de support limité pour de nombreuses raisons, y compris les scénarios suivants:
- Lorsque vous supprimez ou remplacez un service native Red Hat OpenShift sur les composants AWS ou tout autre composant installé et géré par Red Hat
- En cas d’utilisation des autorisations d’administrateur de clusters, Red Hat n’est pas responsable des actions de vos utilisateurs autorisés ou de vos utilisateurs autorisés, y compris celles qui affectent les services d’infrastructure, la disponibilité des services ou la perte de données. Dans le cas où Red Hat détecte de telles actions, le cluster pourrait passer à un statut de support limité. Le Red Hat vous informe du changement d’état et vous devriez soit inverser l’action, soit créer un cas de support pour explorer les étapes d’assainissement qui pourraient vous obliger à supprimer et à recréer le cluster.
Lorsque vous avez des questions sur une action spécifique qui pourrait faire passer un cluster à un statut de support limité ou avoir besoin d’une assistance supplémentaire, ouvrez un ticket de support.
2.8.7. La politique d’exception des versions prises en charge
Le Red Hat se réserve le droit d’ajouter ou de supprimer des versions nouvelles ou existantes, ou de retarder les versions mineures à venir, qui ont été identifiées comme ayant un ou plusieurs problèmes de production critiques ayant un impact sur les bogues ou les problèmes de sécurité sans préavis.
2.8.8. La politique d’installation
Alors que Red Hat recommande l’installation de la dernière version de support, Red Hat OpenShift Service sur AWS prend en charge l’installation de toute version prise en charge comme couvert par la politique précédente.
2.8.9. Des mises à niveau obligatoires
Lorsqu’un CVE critique ou important, ou un autre bug identifié par Red Hat, a un impact significatif sur la sécurité ou la stabilité du cluster, le client doit passer à la prochaine version du correctif pris en charge dans les deux jours ouvrables.
Dans des circonstances extrêmes et sur la base de l’évaluation par Red Hat de la criticité CVE pour l’environnement, Red Hat informera les clients qu’ils disposent de deux jours ouvrables pour planifier ou mettre à jour manuellement leur cluster vers la dernière version sécurisée du patch. Dans le cas où une mise à jour n’est pas effectuée après deux jours ouvrables, Red Hat mettra automatiquement à jour le plan de contrôle du cluster vers la dernière version de patch sécurisé afin d’atténuer les failles de sécurité potentielles ou l’instabilité. À sa propre discrétion, Red Hat peut retarder temporairement une mise à jour automatisée si un client le demande par le biais d’un dossier d’assistance.
2.8.10. Dates du cycle de vie
| La version | Disponibilité générale | Fin de vie |
|---|---|---|
| 4.17 | 14 octobre 2024 | 14 février 2026 |
| 4.16 | Juil 2, 2024 | 2 novembre 2025 |
| 4.15 | Fév 27, 2024 | 30 juin 2025 |
| 4.14 | Décembre 4, 2023 | 1er mai 2025 |
2.9. Comprendre la sécurité pour Red Hat OpenShift Service sur AWS
Ce document détaille le Red Hat, Amazon Web Services (AWS) et les responsabilités de sécurité des clients pour le service Red Hat OpenShift géré sur AWS (ROSA).
Acronymes et termes
- AWS - Amazon Web Services
- CEE - Expérience client et engagement (assistance au chapeau rouge)
- CI/CD - Intégration continue / Livraison continue
- CVE - Vulnérabilités et expositions communes
- Les PVS - Volumes persistants
- Accueil > ROSA - Red Hat OpenShift Service sur AWS
- Ingénierie de fiabilité du site de Red Hat
- Le VPC - Cloud privé virtuel
2.9.1. Conformité à la sécurité et à la réglementation
La conformité à la sécurité et à la réglementation comprend des tâches telles que la mise en œuvre de contrôles de sécurité et la certification de conformité.
2.9.1.1. Classification des données
Red Hat définit et suit une norme de classification des données pour déterminer la sensibilité des données et mettre en évidence le risque inhérent à la confidentialité et à l’intégrité de ces données lors de leur collecte, de leur utilisation, de leur transmission, de leur stockage et de leur traitement. Les données appartenant au client sont classées au plus haut niveau de sensibilité et d’exigences de manipulation.
2.9.1.2. Gestion des données
Le service OpenShift Red Hat sur AWS (ROSA) utilise AWS Key Management Service (KMS) pour aider à gérer en toute sécurité les clés pour les données chiffrées. Ces clés sont utilisées pour le plan de contrôle, l’infrastructure et les volumes de données de travail qui sont cryptés par défaut. Les volumes persistants (PV) pour les applications client utilisent également AWS KMS pour la gestion des clés.
Lorsqu’un client supprime son cluster ROSA, toutes les données de cluster sont définitivement supprimées, y compris les volumes de données de plan de contrôle et les volumes de données d’application client, tels que les volumes persistants (PV).
2.9.1.3. Gestion de la vulnérabilité
Le Red Hat effectue une analyse périodique de vulnérabilité de ROSA à l’aide d’outils standard de l’industrie. Les vulnérabilités identifiées sont suivies de leur assainissement en fonction des échéanciers en fonction de la gravité. Les activités d’analyse et d’assainissement des vulnérabilités sont documentées aux fins de vérification par des tiers évaluateurs dans le cadre d’audits de certification de conformité.
2.9.1.4. La sécurité du réseau
2.9.1.4.1. Coupe-feu et protection DDoS
Chaque cluster ROSA est protégé par une configuration réseau sécurisée en utilisant les règles de pare-feu pour AWS Security Groups. Les clients ROSA sont également protégés contre les attaques DDoS avec AWS Shield Standard.
2.9.1.4.2. Clusters privés et connectivité réseau
Les clients peuvent éventuellement configurer leurs points de terminaison de cluster ROSA, tels que la console Web, l’API et le routeur d’applications, pour être rendus privés afin que le plan de contrôle du cluster et les applications ne soient pas accessibles à partir d’Internet. Le Red Hat SRE nécessite toujours des points de terminaison accessibles à Internet qui sont protégés par des listes d’autorisations IP.
Les clients AWS peuvent configurer une connexion réseau privée à leur cluster ROSA grâce à des technologies telles que AWS VPC peering, AWS VPN ou AWS Direct Connect.
2.9.1.4.3. Contrôles d’accès au réseau cluster
Les règles de contrôle d’accès réseau fines peuvent être configurées par les clients, sur une base par projet, à l’aide des objets NetworkPolicy et du SDN OpenShift.
2.9.1.5. Essais de pénétration
Le Red Hat effectue des tests de pénétration périodiques contre ROSA. Les tests sont effectués par une équipe interne indépendante en utilisant des outils standard de l’industrie et des meilleures pratiques.
Les problèmes qui peuvent être découverts sont prioritaires en fonction de la gravité. Les problèmes constatés dans le cadre de projets open source sont partagés avec la communauté aux fins de résolution.
2.9.1.6. Conformité
Le service OpenShift Red Hat sur AWS suit les meilleures pratiques de l’industrie en matière de sécurité et de contrôle. Les certifications sont décrites dans le tableau suivant.
| Conformité | Le service OpenShift Red Hat sur AWS (ROSA) | Le service OpenShift Red Hat sur AWS (ROSA) avec des avions de contrôle hébergés (HCP) |
|---|---|---|
| HIPAA Qualifié[1] | ♪ oui ♪ | ♪ oui ♪ |
| ISO 27001 | ♪ oui ♪ | ♪ oui ♪ |
| ISO 27017 | ♪ oui ♪ | ♪ oui ♪ |
| ISO 27018 | ♪ oui ♪ | ♪ oui ♪ |
| DSS 4.0 PCI | ♪ oui ♪ | ♪ oui ♪ |
| COS 1 Type 2 | ♪ oui ♪ | ♪ oui ♪ |
| Le SOC 2 de type 2 | ♪ oui ♪ | ♪ oui ♪ |
| LE SOC 3 | ♪ oui ♪ | ♪ oui ♪ |
| FedRAMP High[2] | (GovCloud requis) | C) Non |
- En savoir plus sur les offres ROSA qualifiées HIPAA de Red Hat, consultez l’aperçu HIPAA.
- En savoir plus sur ROSA sur GovCloud, consultez les annonces FedRAMP Marketplace ROSA et ROSA JAB.
2.10. Accès au compte SRE et service
L’accès à Red Hat OpenShift Service sur les clusters AWS (ROSA) est décrit par la gestion de l’identité et de l’accès.
2.10.1. Gestion de l’identité et des accès
La plupart des accès par les équipes de Red Hat SRE se font en utilisant des opérateurs de clusters grâce à une gestion automatisée de la configuration.
Les sous-traitants
Dans la liste des sous-traitants disponibles, consultez la liste des sous-processeurs Red Hat sur le portail client Red Hat.
2.10.2. Accès au cluster SRE
L’accès SRE à Red Hat OpenShift Service sur les clusters AWS (ROSA) est contrôlé par plusieurs couches d’authentification requise, qui sont toutes gérées par une politique d’entreprise stricte. Les tentatives d’authentification pour accéder à un cluster et les modifications apportées au sein d’un cluster sont enregistrées dans les journaux d’audit, ainsi que l’identité spécifique du compte du SRE responsable de ces actions. Ces journaux d’audit permettent de s’assurer que toutes les modifications apportées par les SRE au cluster d’un client respectent les politiques et procédures strictes qui composent les lignes directrices sur les services gérés de Red Hat.
L’information présentée ci-dessous est un aperçu du processus qu’une SRE doit effectuer pour accéder au cluster d’un client.
- Le SRE demande un jeton d’identification actualisé de la Red Hat SSO (Cloud Services). Cette demande est authentifiée. Le jeton est valable quinze minutes. Après l’expiration du jeton, vous pouvez rafraîchir le jeton à nouveau et recevoir un nouveau jeton. La capacité de se rafraîchir à un nouveau jeton est indéfinie; cependant, la capacité de se rafraîchir à un nouveau jeton est révoquée après 30 jours d’inactivité.
- Le SRE se connecte au VPN Red Hat. L’authentification au VPN est complétée par le système Red Hat Corporate Identity and Access Management (RH IAM). Avec RH IAM, les SRE sont multifactorielles et peuvent être gérées en interne par les groupes et les processus existants d’intégration et de hors-bord. Après qu’un SRE soit authentifié et connecté, le SRE peut accéder à l’avion de gestion de flotte de services cloud. Les modifications apportées au plan de gestion de la flotte de services cloud nécessitent de nombreuses couches d’approbation et sont maintenues par une politique stricte de l’entreprise.
- Après la fin de l’autorisation, le SRE se connecte à l’avion de gestion de flotte et reçoit un compte de service que l’avion de gestion de flotte a créé. Le jeton est valable pendant 15 minutes. Après que le jeton n’est plus valide, il est supprimé.
Avec l’accès accordé au plan de gestion de flotte, SRE utilise diverses méthodes pour accéder aux clusters, en fonction de la configuration du réseau.
- Accès à un cluster privé ou public : Demande est envoyée via un balanceur de charge réseau spécifique (NLB) à l’aide d’une connexion HTTP chiffrée sur le port 6443.
- Accès à un cluster PrivateLink : Demande est envoyée à la passerelle Red Hat Transit, qui se connecte ensuite à un PCV Red Hat par région. Le VPC qui reçoit la demande dépendra de la région du cluster privé cible. Dans le VPC, il y a un sous-réseau privé qui contient le point de terminaison PrivateLink au cluster PrivateLink du client.
Accédez aux clusters ROSA via la console Web ou les outils d’interface de ligne de commande (CLI). L’authentification nécessite une authentification multi-facteurs (MFA) avec des exigences standard de l’industrie pour la complexité des mots de passe et les verrouillages de compte. Le SRES doit s’authentifier en tant qu’individu afin d’assurer l’auditabilité. Les tentatives d’authentification sont enregistrées sur un système de gestion des informations de sécurité et des événements (SIEM).
Les SRES accèdent à des clusters privés à l’aide d’une connexion HTTP cryptée. Les connexions ne sont autorisées qu’à partir d’un réseau Red Hat sécurisé à l’aide d’une liste d’autorisations IP ou d’un lien fournisseur de cloud privé.
Figure 2.1. Accès SRE aux clusters ROSA
2.10.2.1. Contrôles d’accès privilégiés dans ROSA
La SRE adhère au principe du moindre privilège lors de l’accès aux composants ROSA et AWS. Il existe quatre catégories de base d’accès SRE manuels:
- Accès administrateur SRE via le portail Red Hat avec une authentification normale à deux facteurs et aucune élévation privilégiée.
- L’administrateur SRE accède par l’intermédiaire du SSO d’entreprise Red Hat avec une authentification normale à deux facteurs et aucune élévation privilégiée.
- Élévation OpenShift, qui est une élévation manuelle utilisant Red Hat SSO. L’accès est limité à 2 heures, est entièrement audité et nécessite l’approbation de la direction.
- Accès AWS ou élévation, qui est une élévation manuelle pour l’accès à la console AWS ou CLI. L’accès est limité à 60 minutes et est entièrement audité.
Chacun de ces types d’accès a différents niveaux d’accès aux composants:
| Composante | Accès administrateur SRE typique (Portail rouge) | Accès administrateur SRE typique (Red Hat SSO) | Élévation de OpenShift | Accès ou élévation des fournisseurs de cloud |
|---|---|---|---|---|
| Gestionnaire de cluster OpenShift | DE R/W | Aucun accès | Aucun accès | Aucun accès |
| Console OpenShift | Aucun accès | DE R/W | DE R/W | Aucun accès |
| Le système d’exploitation des nœuds | Aucun accès | Liste spécifique des autorisations élevées du système d’exploitation et du réseau. | Liste spécifique des autorisations élevées du système d’exploitation et du réseau. | Aucun accès |
| Console AWS | Aucun accès | Aucun accès, mais il s’agit du compte utilisé pour demander l’accès aux fournisseurs de cloud. | Aucun accès | L’ensemble des autorisations des fournisseurs de cloud utilisant l’identité SRE. |
2.10.2.2. Accès SRE aux comptes AWS
Le personnel de Red Hat n’a pas accès aux comptes AWS dans le cadre de la routine Red Hat OpenShift Service sur les opérations AWS. À des fins de dépannage d’urgence, les SRE disposent de procédures bien définies et vérifiables pour accéder aux comptes d’infrastructure cloud.
Dans le flux de backplan isolé, les SRE demandent l’accès au rôle de support d’un client. Cette demande est juste à temps (JIT) traitée par l’API de backplane qui met à jour dynamiquement les autorisations du rôle de l’organisation vers un compte du personnel SRE spécifique. Le compte de ce SRE bénéficie d’un accès à l’environnement spécifique du client Red Hat. L’accès SRE à l’environnement d’un client Red Hat est un accès temporaire et de courte durée qui n’est établi qu’au moment de la demande d’accès.
L’accès au jeton STS est bloqué par l’audit et traçable pour les utilisateurs individuels. Les clusters STS et non STS utilisent le service AWS STS pour l’accès SRE. Le contrôle d’accès utilise le flux de backplan unifié lorsque la stratégie ManagedOpenShift-Technical-Support-Role a la stratégie ManagedOpenShift-Support-Access, et ce rôle est utilisé pour l’administration. Le contrôle d’accès utilise le flux de backplan isolé lorsque la stratégie ManagedOpenShift-Support-Role est jointe à la stratégie ManagedOpenShift-Technical-<org_id>. Consultez l’article de KCS Mise à jour des politiques de confiance pour les clusters ROSA pour plus d’informations.
2.10.2.3. La vue SRE STS des comptes AWS
Lorsque les SRE sont sur un VPN via une authentification à deux facteurs, ils et Red Hat Support peuvent assumer le rôle ManagedOpenShift-Support-Support dans votre compte AWS. Le ManagedOpenShift-Support-Role dispose de toutes les autorisations nécessaires aux SRE pour résoudre et gérer directement les ressources AWS. En supposant le rôle ManagedOpenShift-Support-Role, les SRE utilisent un AWS Security Token Service (STS) pour générer une URL unique et expirant le temps vers l’interface Web AWS du client pour leur compte. Le SRES peut ensuite effectuer plusieurs actions de dépannage, qui comprennent:
- Affichage des journaux CloudTrail
- Arrêt d’une instance EC2 défectueuse
L’ensemble des activités effectuées par les SRE arrivent des adresses IP Red Hat et sont connectés à CloudTrail pour vous permettre d’auditer et de passer en revue toutes les activités. Ce rôle n’est utilisé que dans les cas où l’accès aux services AWS est nécessaire pour vous aider. La majorité des autorisations sont en lecture seule. Cependant, quelques autorisations sélectionnées ont plus d’accès, y compris la possibilité de redémarrer une instance ou de faire tourner une nouvelle instance. L’accès SRE est limité aux autorisations de stratégie attachées à ManagedOpenShift-Support-Role.
Consultez la liste complète des autorisations, voir sts_support_permission_policy.json dans le guide de l’utilisateur des ressources A propos de l’IAM.
2.10.2.4. Accès SRE via le service de point de terminaison PrivateLink VPC
Le service PrivateLink VPC endpoint est créé dans le cadre de la création de cluster ROSA.
Lorsque vous disposez d’un cluster ROSA PrivateLink, son serveur API Kubernetes est exposé à l’aide d’un équilibreur de charge auquel on ne peut accéder qu’à partir du VPC par défaut. L’ingénierie de fiabilité du site Red Hat (SRE) peut se connecter à cet équilibreur de charge via un service de point d’extrémité VPC qui dispose d’un point de terminaison VPC associé dans un compte AWS appartenant à Red Hat. Ce service de point de terminaison contient le nom du cluster, qui est également dans l’ARN.
Dans l’onglet Autoriser les principaux, un compte AWS appartenant à Red Hat est listé. Cet utilisateur spécifique s’assure que d’autres entités ne peuvent pas créer de connexions VPC Endpoint au serveur API Kubernetes du cluster PrivateLink.
Lorsque les Red Hat SRE accèdent à l’API, ce plan de gestion de flotte peut se connecter à l’API interne via le service de point de terminaison VPC.
2.10.3. Accès au support Red Hat
Les membres de l’équipe de Red Hat Customer Experience and Engagement (CEE) ont généralement accès en lecture seule à certaines parties du cluster. En particulier, CEE a un accès limité aux espaces de noms de cœur et de produits et n’a pas accès aux espaces de noms des clients.
| Le rôle | Espace de noms de base | Espace de noms de produit en couches | Espace de noms du client | Compte AWS* |
|---|---|---|---|---|
| Fonctionnement normal de OpenShift SRE [1] | Lire: Tout Écrire: Très limité | Lire: Tout Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun |
| Accès amélioré à OpenShift SRE [2] (Gated by Approved Access) | Lire: Tout Ecrire: Tous | Lire: Tout Ecrire: Tous | Lire: Tout Ecrire: Tous | Lire: Tout Ecrire: Tous |
| CEE | Lire: Tout Écrire: Aucun | Lire: Tout Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun |
| Administrateur client | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Tout Ecrire: Tous | Lire: Tout Ecrire: Tous |
| Client utilisateur | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Limitée [3] Ecrire: Limited [3] | Lire: Aucun Écrire: Aucun |
| Les autres | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun | Lire: Aucun Écrire: Aucun |
- Limité à traiter les cas d’utilisation courante tels que les déploiements défaillants, la mise à niveau d’un cluster et le remplacement des nœuds de mauvais travailleurs.
- L’accès élevé donne à SRE les niveaux d’accès d’un rôle d’administration de cluster et est fermé par l’Accès Approuvé. En savoir plus, voir « Rôles de clusters par défaut » et « Accès approuvé ».
- Limité à ce qui est accordé par RBAC par l’administrateur client et les espaces de noms créés par l’utilisateur.
2.10.4. Accès client
L’accès du client est limité aux espaces de noms créés par le client et aux autorisations accordées par RBAC par le rôle d’administrateur client. L’accès à l’infrastructure sous-jacente ou aux espaces de noms de produits n’est généralement pas autorisé sans accès cluster-admin. En savoir plus sur l’accès et l’authentification des clients, consultez la section « Comprendre l’authentification » de la documentation.
2.10.5. Approbation et examen de l’accès
L’accès aux nouveaux utilisateurs SRE nécessite l’approbation de la direction. Les comptes SRE séparés ou transférés sont supprimés en tant qu’utilisateurs autorisés par le biais d’un processus automatisé. En outre, le SRE effectue un examen périodique de l’accès, y compris la signature de la gestion des listes d’utilisateurs autorisés.
Le tableau d’autorisation d’accès et d’identité comprend les responsabilités de gestion de l’accès autorisé aux grappes, aux applications et aux ressources d’infrastructure. Cela inclut des tâches telles que la fourniture de mécanismes de contrôle d’accès, l’authentification, l’autorisation et la gestion de l’accès aux ressources.
| A) Ressources | Les responsabilités en matière de service | Les responsabilités du client |
|---|---|---|
| L’exploitation forestière | Chapeau rouge
|
|
| La mise en réseau des applications | Chapeau rouge
|
|
| La mise en réseau de clusters | Chapeau rouge
|
|
| Gestion des réseaux virtuels | Chapeau rouge
|
|
| Gestion du stockage virtuel | Chapeau rouge
|
|
| Gestion de calcul virtuel | Chapeau rouge
|
|
| Logiciel AWS (services AWS publics) | AWS Calcul : Fournir le service Amazon EC2, utilisé pour l’avion de contrôle ROSA, l’infrastructure et les nœuds de travail. Le stockage : Fournir Amazon EBS, utilisé pour permettre à ROSA de fournir un stockage de nœud local et un stockage en volume persistant pour le cluster. Stockage: Fournissez Amazon S3, utilisé pour le registre d’images intégré du service. Le réseau : Fournir AWS Identity and Access Management (IAM), utilisé par les clients pour contrôler l’accès aux ressources ROSA fonctionnant sur les comptes clients. |
|
| Hardware et infrastructure globale AWS | AWS
|
|
2.10.6. Comment les comptes de services assument les rôles AWS IAM dans les projets appartenant à SRE
Lorsque vous installez un service Red Hat OpenShift sur le cluster AWS qui utilise le service de jetons de sécurité AWS (STS), des rôles AWS Identity and Access Management (IAM) spécifiques au cluster sont créés. Ces rôles IAM permettent au service Red Hat OpenShift sur AWS cluster Operators d’exécuter la fonctionnalité principale d’OpenShift.
Les opérateurs de cluster utilisent les comptes de service pour assumer des rôles IAM. Lorsqu’un compte de service assume un rôle IAM, des informations d’identification STS temporaires sont fournies pour que le compte de service puisse être utilisé dans la pod de l’opérateur du cluster. Lorsque le rôle assumé dispose des privilèges AWS nécessaires, le compte de service peut exécuter les opérations SDK AWS dans la pod.
Flux de travail pour assumer les rôles AWS IAM dans les projets appartenant à SRE
Le diagramme suivant illustre le flux de travail pour assumer les rôles AWS IAM dans les projets appartenant à SRE:
Figure 2.2. Flux de travail pour assumer les rôles AWS IAM dans les projets appartenant à SRE
Le flux de travail comporte les étapes suivantes:
Dans chaque projet qu’un opérateur de cluster exécute, la spécification de déploiement de l’opérateur dispose d’une monture de volume pour le jeton de compte de service projeté, et d’un secret contenant une configuration d’identification AWS pour le pod. Le jeton est lié à l’audience et au temps. Chaque heure, Red Hat OpenShift Service sur AWS génère un nouveau jeton, et le SDK AWS lit le secret monté contenant la configuration d’identification AWS. Cette configuration a un chemin vers le jeton monté et le rôle AWS IAM ARN. La configuration d’identification du secret comprend les éléments suivants:
- La variable $AWS_ARN_ROLE possède l’ARN pour le rôle IAM qui possède les autorisations requises pour exécuter les opérations SDK AWS.
- * une variable $AWS_WEB_IDENTITY_TOKEN_FILE qui a le chemin complet dans le pod vers le jeton OpenID Connect (OIDC) pour le compte de service. Le chemin complet est /var/run/secrets/openshift/serviceaccount/token.
- Lorsqu’un opérateur de cluster doit assumer un rôle AWS IAM pour accéder à un service AWS (tel qu’EC2), le code client AWS SDK s’exécutant sur l’opérateur invoque l’appel de l’API AssumeRoleWithWebIdentity.
Le jeton OIDC est transmis du pod au fournisseur OIDC. Le fournisseur authentifie l’identité du compte de service si les exigences suivantes sont remplies:
- La signature d’identité est valide et signée par la clé privée.
L’audience sts.amazonaws.com est listée dans le jeton OIDC et correspond à l’audience configurée dans le fournisseur OIDC.
NoteDans Red Hat OpenShift Service sur AWS avec des clusters STS, le fournisseur OIDC est créé lors de l’installation et défini comme émetteur de compte de service par défaut. L’audience sts.amazonaws.com est définie par défaut dans le fournisseur OIDC.
- Le jeton OIDC n’a pas expiré.
- La valeur de l’émetteur dans le jeton a l’URL pour le fournisseur OIDC.
- Lorsque le compte de projet et de service est dans le champ d’application de la politique de confiance pour le rôle de l’IAM qui est assumé, l’autorisation réussit.
- Après une authentification et une autorisation réussies, les informations d’identification AWS STS temporaires sous la forme d’un jeton d’accès AWS, d’une clé secrète et d’un jeton de session sont transmises à la pod pour utilisation par le compte de service. En utilisant les informations d’identification, le compte de service reçoit temporairement les autorisations AWS activées dans le rôle IAM.
- Lorsque l’opérateur de cluster s’exécute, l’opérateur qui utilise le SDK AWS dans la pod consomme le secret qui a le chemin vers le compte de service projeté et le rôle AWS IAM ARN pour s’authentifier contre le fournisseur OIDC. Le fournisseur OIDC retourne des informations d’identification STS temporaires pour l’authentification par rapport à l’API AWS.
Chapitre 3. Les ressources IAM requises pour les clusters STS
Afin de déployer un Red Hat OpenShift Service sur AWS (ROSA) cluster qui utilise AWS Security Token Service (STS), vous devez créer les ressources AWS Identity Access Management (IAM) suivantes:
- Des rôles et des politiques IAM spécifiques à l’échelle du compte qui fournissent les autorisations STS requises pour le support ROSA, l’installation, le plan de contrôle et la fonctionnalité de calcul. Cela inclut les politiques de l’opérateur à l’échelle du compte.
- Des rôles IAM d’opérateur spécifiques à un cluster qui permettent aux opérateurs de cluster ROSA d’exécuter la fonctionnalité principale d’OpenShift.
- Fournisseur OpenID Connect (OIDC) que les opérateurs de cluster utilisent pour s’authentifier.
Lorsque vous déployez et gérez votre cluster à l’aide d’OpenShift Cluster Manager, vous devez créer les ressources supplémentaires suivantes:
- A OpenShift Cluster Manager rôle IAM pour compléter l’installation sur votre cluster.
- Le rôle d’utilisateur sans aucune autorisation pour vérifier l’identité de votre compte AWS.
Ce document fournit des informations de référence sur les ressources IAM que vous devez déployer lorsque vous créez un cluster ROSA qui utilise STS. Il inclut également les commandes aws CLI qui sont générées lorsque vous utilisez le mode manuel avec la commande rosa create.
3.1. Les rôles et autorisations de gestionnaire de cluster OpenShift
Lorsque vous créez des clusters ROSA en utilisant OpenShift Cluster Manager, vous devez avoir les rôles AWS IAM suivants liés à votre compte AWS pour créer et gérer les clusters. En savoir plus sur le lien entre vos rôles IAM et votre compte AWS, consultez Associer votre compte AWS.
Ces rôles AWS IAM sont les suivants:
- Le rôle utilisateur ROSA (le rôle utilisateur) est un rôle AWS utilisé par Red Hat pour vérifier l’identité AWS du client. Ce rôle n’a pas d’autorisations supplémentaires, et le rôle a une relation de confiance avec le compte d’installation Red Hat.
La ressource ocm-rôle accorde les autorisations requises pour l’installation de clusters ROSA dans OpenShift Cluster Manager. Il est possible d’appliquer des autorisations de base ou administratives à la ressource ocm-role. En créant une ressource administrative ocm-rôle, OpenShift Cluster Manager peut créer les rôles AWS Operator et OpenID Connect (OIDC) nécessaires. Ce rôle d’IAM crée également une relation de confiance avec le compte d’installation Red Hat.
NoteLa ressource ocm-rôle IAM fait référence à la combinaison du rôle de l’IAM et des politiques nécessaires créées avec elle.
Il faut créer ce rôle d’utilisateur ainsi qu’une ressource administrative ocm-rôle, si vous souhaitez utiliser le mode automatique dans OpenShift Cluster Manager pour créer vos stratégies de rôles Opérateur et fournisseur OIDC.
3.1.1. Comprendre le rôle de gestionnaire de cluster OpenShift
La création de clusters ROSA dans OpenShift Cluster Manager nécessite un rôle IAM ocm-role. Les autorisations de rôle Ocm-role de base vous permettent d’effectuer la maintenance des clusters dans OpenShift Cluster Manager. Afin de créer automatiquement les rôles d’opérateur et le fournisseur OpenID Connect (OIDC), vous devez ajouter l’option --admin à la commande rosa create. Cette commande crée une ressource ocm-rôle avec des autorisations supplémentaires nécessaires pour les tâches administratives.
Ce rôle IAM élevé permet à OpenShift Cluster Manager de créer automatiquement les rôles d’opérateur spécifiques au cluster et le fournisseur OIDC lors de la création de clusters. Consultez le lien « Méthodes de création de rôles à l’échelle du compte » dans Ressources supplémentaires pour plus d’informations sur ce rôle automatique et la création de politiques.
3.1.1.1. Comprendre le rôle de l’utilisateur
En plus d’un rôle IAM ocm-rôle, vous devez créer un rôle utilisateur afin que Red Hat OpenShift Service sur AWS puisse vérifier votre identité AWS. Ce rôle n’a pas d’autorisations, et il n’est utilisé que pour créer une relation de confiance entre le compte d’installateur et vos ressources ocm-rôle.
Les tableaux suivants montrent les autorisations de base et administratives associées pour la ressource ocm-role.
| A) Ressources | Description |
|---|---|
|
| Cette autorisation permet au rôle de base de récupérer des informations sur le fournisseur OpenID Connect (OIDC) spécifié. |
|
| Cette autorisation permet au rôle de base de récupérer toute information pour un rôle spécifié. Certaines des données retournées incluent le chemin du rôle, GUID, ARN, et la politique de confiance du rôle qui accorde la permission d’assumer le rôle. |
|
| Cette autorisation permet au rôle de base de répertorier les rôles dans un préfixe de chemin. |
|
| Cette autorisation permet au rôle de base de répertorier les balises sur un rôle spécifié. |
|
| Cette autorisation permet au rôle de base de retourner des informations sur toutes les régions activées sur votre compte. |
|
| Cette autorisation permet au rôle de base de retourner des informations sur toutes vos tables d’itinéraires. |
|
| Cette autorisation permet au rôle de base de retourner des informations sur tous vos sous-réseaux. |
|
| Cette autorisation permet au rôle de base de retourner des informations sur tous vos clouds privés virtuels (VPC). |
|
| Cette autorisation permet au rôle de base de récupérer des informations de sécurité temporaires pour accéder aux ressources AWS qui sont au-delà de ses autorisations normales. |
|
| Cette autorisation permet au rôle de base de récupérer des informations de sécurité temporaires pour les utilisateurs authentifiés de leur compte auprès d’un fournisseur d’identité Web. |
| A) Ressources | Description |
|---|---|
|
| Cette autorisation permet au rôle d’administrateur d’attacher une stratégie spécifiée au rôle IAM souhaité. |
|
| Cette autorisation crée une ressource qui décrit un fournisseur d’identité, qui prend en charge OpenID Connect (OIDC). Lorsque vous créez un fournisseur OIDC avec cette autorisation, ce fournisseur établit une relation de confiance entre le fournisseur et AWS. |
|
| Cette autorisation permet au rôle d’administrateur de créer un rôle pour votre compte AWS. |
|
| Cette autorisation permet au rôle d’administrateur de répertorier toutes les stratégies associées à votre compte AWS. |
|
| Cette autorisation permet au rôle d’administrateur de répertorier les balises d’une stratégie désignée. |
|
| Cette autorisation permet au rôle d’administrateur de modifier la limite des autorisations pour un utilisateur en fonction d’une stratégie spécifiée. |
|
| Cette autorisation permet au rôle d’administrateur d’ajouter des tags à un rôle IAM. |
Création d’un rôle Ocm-role IAM
Créez vos rôles Ocm-role IAM à l’aide de l’interface de ligne de commande (CLI).
Conditions préalables
- Il y a un compte AWS.
- Dans l’organisation OpenShift Cluster Manager, vous avez les privilèges d’administrateur d’organisation Red Hat.
- Les autorisations requises pour installer les rôles AWS à l’échelle du compte sont requises.
- Dans votre installation, vous avez installé et configuré le dernier service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.
Procédure
Afin de créer un rôle Ocm-role IAM avec des privilèges de base, exécutez la commande suivante:
rosa create ocm-role
$ rosa create ocm-roleCopy to Clipboard Copied! Toggle word wrap Toggle overflow Afin de créer un rôle Ocm-role IAM avec les privilèges d’administrateur, exécutez la commande suivante:
rosa create ocm-role --admin
$ rosa create ocm-role --adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow Cette commande vous permet de créer le rôle en spécifiant des attributs spécifiques. L’exemple suivant montre le "mode automatique" sélectionné, ce qui permet au ROSA CLI (rosa) de créer vos rôles et stratégies d’opérateur. Consultez « Méthodes de création de rôles à l’échelle du compte » pour plus d’informations.
Exemple de sortie
- 1
- Il s’agit d’une valeur préfixée pour toutes les ressources AWS créées. Dans cet exemple, ManagedOpenShift prépend toutes les ressources AWS.
- 2
- Choisissez si vous voulez que ce rôle ait les autorisations d’administration supplémentaires.Note
L’option --admin n’a pas été consultée.
- 3
- Le nom de ressource Amazon (ARN) de la politique pour définir les limites d’autorisation.
- 4
- Indiquez un chemin IAM pour le nom d’utilisateur.
- 5
- Choisissez la méthode pour créer vos rôles AWS. En utilisant l’auto, le ROSA CLI génère et relie les rôles et les politiques. En mode automatique, vous recevez des invitations différentes pour créer les rôles AWS.
- 6
- La méthode automatique vous demande si vous souhaitez créer un rôle ocm spécifique en utilisant votre préfixe.
- 7
- Confirmez que vous souhaitez associer votre rôle IAM à votre OpenShift Cluster Manager.
- 8
- Relie le rôle créé à votre organisation AWS.
Les rôles AWS IAM sont liés à votre compte AWS pour créer et gérer les clusters. En savoir plus sur le lien entre vos rôles IAM et votre compte AWS, consultez Associer votre compte AWS.
3.2. Le rôle et la référence des politiques de l’IAM à l’échelle du compte
Cette section fournit des détails sur les rôles et les politiques de l’IAM à l’échelle du compte qui sont nécessaires pour les déploiements de ROSA qui utilisent STS, y compris les politiques de l’opérateur. Il inclut également les fichiers JSON qui définissent les politiques.
Les rôles et les politiques à l’échelle du compte sont spécifiques à un service Red Hat OpenShift sur AWS version mineure, par exemple Red Hat OpenShift Service sur AWS 4, et sont compatibles avec les versions précédentes. Il est possible de minimiser les ressources STS requises en réutilisant les rôles et les stratégies à l’échelle du compte pour plusieurs clusters de la même version mineure, quelle que soit leur version de patch.
3.2.1. Les méthodes de création de rôles à l’échelle du compte
Il est possible de créer des rôles à l’échelle du compte en utilisant le service OpenShift Red Hat sur AWS (ROSA) CLI, rosa ou l’installation guidée OpenShift Cluster Manager. Il est possible de créer les rôles manuellement ou en utilisant un processus automatique qui utilise des noms prédéfinis pour ces rôles et stratégies.
Création manuelle de ressources ocm-role
La méthode de création manuelle peut être utilisée si vous disposez de l’accès CLI nécessaire pour créer ces rôles sur votre système. Cette option peut être exécutée dans l’outil CLI souhaité ou depuis OpenShift Cluster Manager. Après avoir commencé le processus de création manuelle, le CLI présente une série de commandes pour vous d’exécuter qui créent les rôles et de les lier aux politiques nécessaires.
Création automatique de ressources ocm-role
En créant une ressource ocm-role avec des autorisations administratives, vous pouvez utiliser la méthode de création automatique d’OpenShift Cluster Manager. Le ROSA CLI n’exige pas que vous ayez cette ressource IAM admin ocm-role pour créer automatiquement ces rôles et politiques. La sélection de cette méthode crée les rôles et les stratégies qui utilisent les noms par défaut.
Lorsque vous utilisez l’installation guidée ROSA sur OpenShift Cluster Manager, vous devez avoir créé une ressource ocm-rôle avec des autorisations administratives dans la première étape de l’installation du cluster guidé. En l’absence de ce rôle, vous ne pouvez pas utiliser l’option de création automatique de rôle et de stratégie de l’opérateur, mais vous pouvez toujours créer le cluster et ses rôles et politiques avec le processus manuel.
Le numéro de compte présent dans les échantillons sts_installer_trust_policy.json et sts_support_trust_policy.json représente le compte Red Hat qui est autorisé à assumer les rôles requis.
| A) Ressources | Description |
|---|---|
|
| Le rôle IAM utilisé par l’installateur ROSA. |
|
| Il s’agit d’une politique IAM qui fournit à l’installateur ROSA les autorisations requises pour effectuer les tâches d’installation du cluster. |
Exemple 3.1. accueil > Sts_installer_trust_policy.json
Exemple 3.2. accueil > Sts_installer_permission_policy.json
| A) Ressources | Description |
|---|---|
|
| Le rôle IAM utilisé par le plan de contrôle ROSA. |
|
| La politique IAM qui fournit au plan de contrôle ROSA les autorisations requises pour gérer ses composants. |
Exemple 3.3. accueil > Sts_instance_controlplane_trust_policy.json
Exemple 3.4. accueil > Sts_instance_controlplane_permission_policy.json
| A) Ressources | Description |
|---|---|
|
| Le rôle IAM utilisé par les instances de calcul ROSA. |
|
| La politique IAM qui fournit aux instances de calcul ROSA les autorisations requises pour gérer leurs composants. |
Exemple 3.5. accueil > Sts_instance_worker_trust_policy.json
Exemple 3.6. accueil > Sts_instance_worker_permission_policy.json
| A) Ressources | Description |
|---|---|
|
| Le rôle de l’IAM utilisé par l’équipe de soutien de Red Hat Site Reliability Engineering (SRE). |
|
| La politique IAM qui fournit à l’équipe de soutien Red Hat SRE les autorisations requises pour soutenir les clusters ROSA. |
Exemple 3.7. accueil > Sts_support_trust_policy.json
Exemple 3.8. accueil > Sts_support_permission_policy.json
| A) Ressources | Description |
|---|---|
|
| Ce rôle vous permet de créer et de maintenir des clusters ROSA dans OpenShift Cluster Manager. |
Exemple 3.9. ajouter au panier Sts_ocm_role_trust_policy.json
| A) Ressources | Description |
|---|---|
|
| Le rôle IAM utilisé par Red Hat pour vérifier l’identité AWS du client. |
Exemple 3.10. sts_user_role_trust_policy.json
Exemple de sortie de CLI pour les politiques attachées à un rôle
Lorsqu’une politique est attachée à un rôle, la ROSA CLI affiche une sortie de confirmation. La production dépend du type de politique.
Dans le cas où la politique est une politique de confiance, l’ILC ROSA produit le nom du rôle et le contenu de la politique.
En ce qui concerne le rôle cible avec la stratégie jointe, ROSA CLI affiche le nom du rôle et l’URL de la console du rôle cible.
Le rôle cible avec le résultat de l’exemple joint à la politique
I: Attached trust policy to role 'testrole-Worker-Role(https://console.aws.amazon.com/iam/home?#/roles/testrole-Worker-Role)': ******************
I: Attached trust policy to role 'testrole-Worker-Role(https://console.aws.amazon.com/iam/home?#/roles/testrole-Worker-Role)': ******************Copy to Clipboard Copied! Toggle word wrap Toggle overflow Dans le cas où la politique ci-jointe est une politique de fiducie, la ROSA CLI produit le contenu de cette politique.
Exemple d’exemple de confiance
I: Attached trust policy to role 'test-Support-Role': {"Version": "2012-10-17", "Statement": [{"Action": ["sts:AssumeRole"], "Effect": "Allow", "Principal": {"AWS": ["arn:aws:iam::000000000000:role/RH-Technical-Support-00000000"]}}]}I: Attached trust policy to role 'test-Support-Role': {"Version": "2012-10-17", "Statement": [{"Action": ["sts:AssumeRole"], "Effect": "Allow", "Principal": {"AWS": ["arn:aws:iam::000000000000:role/RH-Technical-Support-00000000"]}}]}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Lorsque la politique est une politique d’autorisation, la ROSA CLI affiche le nom et le lien public de cette politique ou de l’ARN selon que la politique est ou non une politique gérée par AWS ou une politique gérée par le client.
Dans le cas où la politique jointe est une politique gérée par AWS, la ROSA CLI produit le nom et le lien public de cette politique et le rôle auquel elle est attachée.
La sortie d’exemple de stratégie gérée AWS
I: Attached policy 'ROSASRESupportPolicy(https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSASRESupportPolicy)' to role 'test-HCP-ROSA-Support-Role(https://console.aws.amazon.com/iam/home?#/roles/test-HCP-ROSA-Support-Role)'
I: Attached policy 'ROSASRESupportPolicy(https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSASRESupportPolicy)' to role 'test-HCP-ROSA-Support-Role(https://console.aws.amazon.com/iam/home?#/roles/test-HCP-ROSA-Support-Role)'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Dans le cas où la politique jointe est une politique gérée par AWS, la ROSA CLI produit le nom et le lien public de cette politique et le rôle auquel elle est attachée.
Exemple d’exemple de stratégie géré par le client
I: Attached policy 'arn:aws:iam::000000000000:policy/testrole-Worker-Role-Policy' to role 'testrole-Worker-Role(https://console.aws.amazon.com/iam/home?#/roles/testrole-Worker-Role)'
I: Attached policy 'arn:aws:iam::000000000000:policy/testrole-Worker-Role-Policy' to role 'testrole-Worker-Role(https://console.aws.amazon.com/iam/home?#/roles/testrole-Worker-Role)'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
| A) Ressources | Description |
|---|---|
|
| La politique IAM qui fournit à l’opérateur d’ingénieur ROSA les autorisations requises pour gérer l’accès externe à un cluster. |
Exemple 3.11. accueil > Openshift_ingress_operator_cloud_credentials_policy.json
| A) Ressources | Description |
|---|---|
|
| La politique IAM requise par ROSA pour gérer le stockage back-end via l’interface de stockage de conteneurs (CSI). |
Exemple 3.12. accueil > Openshift_cluster_csi_drivers_ebs_cloud_credentials_policy.json
| A) Ressources | Description |
|---|---|
|
| Il s’agit d’une politique IAM qui fournit à l’opérateur de configuration de machine ROSA les autorisations requises pour exécuter les fonctionnalités de cluster de base. |
Exemple 3.13. accueil > Openshift_machine_api_aws_cloud_credentials_policy.json
| A) Ressources | Description |
|---|---|
|
| La politique IAM qui fournit à l’opérateur d’identification en nuage ROSA les autorisations requises pour gérer les informations d’identification des fournisseurs de cloud. |
Exemple 3.14. accueil > Openshift_cloud_credential_operator_cloud_credential_operator_iam_ro_creds_policy.json
| A) Ressources | Description |
|---|---|
|
| La politique IAM fournit à l’opérateur de registre d’images ROSA les autorisations requises pour gérer le stockage du registre d’images OpenShift dans AWS S3 pour un cluster. |
Exemple 3.15. accueil > Openshift_image_registry_installer_cloud_credentials_policy.json
3.2.2. Le rôle et la politique de l’IAM à l’échelle du compte
Cette section répertorie les commandes aws CLI que la commande rosa génère dans le terminal. La commande peut être exécutée en mode manuel ou automatique.
En utilisant le mode manuel pour la création de rôles de compte
Le mode de création de rôles manuel génère les commandes aws pour que vous puissiez examiner et exécuter. La commande suivante démarre ce processus, où <openshift_version> fait référence à votre version de Red Hat OpenShift Service sur AWS (ROSA), comme 4.
rosa create account-roles --mode manual
$ rosa create account-roles --mode manualLes exemples de commandes fournis incluent le préfixe ManagedOpenShift. Le préfixe ManagedOpenShift est la valeur par défaut, si vous ne spécifiez pas un préfixe personnalisé en utilisant l’option --prefix.
Commande de sortie
En utilisant le mode automatique pour la création de rôles
Lorsque vous ajoutez l’argument --mode automatique, le Red Hat OpenShift Service sur AWS (ROSA) CLI, rosa, crée vos rôles et vos politiques. La commande suivante démarre ce processus:
rosa create account-roles --mode auto
$ rosa create account-roles --mode autoLes exemples de commandes fournis incluent le préfixe ManagedOpenShift. Le préfixe ManagedOpenShift est la valeur par défaut, si vous ne spécifiez pas un préfixe personnalisé en utilisant l’option --prefix.
Commande de sortie
3.3. Limites d’autorisation pour le rôle d’installateur
Il est possible d’appliquer une stratégie en tant que limite d’autorisations sur un rôle d’installateur. Il est possible d’utiliser une politique gérée par AWS ou une politique gérée par le client pour définir la limite d’une entité de gestion de l’identité et des accès (IAM) d’Amazon Web Services (AWS) (utilisateur ou rôle). La combinaison de la stratégie et de la stratégie limite limite les autorisations maximales pour l’utilisateur ou le rôle. La ROSA comprend un ensemble de trois fichiers de stratégie de limites d’autorisation préparés, avec lesquels vous pouvez restreindre les autorisations pour le rôle d’installateur puisque la modification de la stratégie d’installation elle-même n’est pas prise en charge.
Cette fonctionnalité n’est prise en charge que sur Red Hat OpenShift Service sur les clusters AWS (architecture classique).
Les fichiers de stratégie de limites d’autorisation sont les suivants:
- Le fichier de stratégie de limites de base contient les autorisations minimales nécessaires à l’installateur ROSA (architecture classique) pour installer un Red Hat OpenShift Service sur le cluster AWS. L’installateur n’a pas d’autorisation pour créer un cloud privé virtuel (VPC) ou PrivateLink (PL). Il faut fournir un VPC.
- Le fichier de stratégie de limite VPC contient les autorisations minimales nécessaires à l’installateur ROSA (architecture classique) pour créer/gérer le VPC. Il n’inclut pas les autorisations pour l’installation PL ou core. Lorsque vous avez besoin d’installer un cluster avec suffisamment d’autorisations pour l’installateur pour installer le cluster et créer / gérer le VPC, mais vous n’avez pas besoin de configurer PL, alors utilisez les fichiers limites core et VPC avec le rôle d’installateur.
- Le fichier de stratégie de limite PrivateLink (PL) contient les autorisations minimales requises pour l’installateur ROSA (architecture classique) pour créer l’AWS PL avec un cluster. Il n’inclut pas les autorisations pour VPC ou l’installation de base. Fournir un VPC pré-créé pour tous les clusters PL pendant l’installation.
Lors de l’utilisation des fichiers de stratégie de limites d’autorisation, les combinaisons suivantes s’appliquent:
- Aucune politique de limite d’autorisation ne signifie que les autorisations complètes de stratégie d’installation s’appliquent à votre cluster.
Core définit uniquement les autorisations les plus restreintes pour le rôle d’installateur. Les autorisations VPC et PL ne sont pas incluses dans la stratégie de limites de base seulement.
- L’installateur ne peut pas créer ou gérer le VPC ou PL.
- Il faut avoir un VPC fourni par le client, et PrivateLink (PL) n’est pas disponible.
Core + VPC définit les autorisations core et VPC pour le rôle d’installateur.
- L’installateur ne peut pas créer ou gérer le PL.
- Suppose que vous n’utilisez pas custom/BYO-VPC.
- Suppose que l’installateur créera et gérera le VPC.
Core + PrivateLink (PL) signifie que l’installateur peut fournir l’infrastructure PL.
- Il faut avoir un VPC fourni par le client.
- Ceci est pour un cluster privé avec PL.
Cette procédure d’exemple est applicable pour un rôle et une politique d’installation avec la plus grande restriction des autorisations, en utilisant uniquement la stratégie de limite d’autorisation de l’installateur de base pour ROSA. Il est possible de compléter cela avec la console AWS ou le CLI AWS. Cet exemple utilise l’AWS CLI et la politique suivante:
Exemple 3.16. accueil > Sts_installer_core_permission_border_policy.json
Afin d’utiliser les limites d’autorisation, vous devrez préparer la politique de limite d’autorisation et l’ajouter à votre rôle d’installateur pertinent dans AWS IAM. Bien que le ROSA (rosa) CLI offre une fonction de limite d’autorisation, il s’applique à tous les rôles et pas seulement au rôle d’installateur, ce qui signifie qu’il ne fonctionne pas avec les politiques de limite d’autorisation fournies (qui ne sont que pour le rôle d’installateur).
Conditions préalables
- Il y a un compte AWS.
- Les autorisations requises pour administrer les rôles et les politiques AWS sont requises.
- Dans votre poste de travail, vous avez installé et configuré les derniers CLI AWS (aws) et ROSA (rosa).
- Les rôles de votre compte ROSA ont déjà été préparés, y compris le rôle d’installateur et les politiques correspondantes. Dans le cas où ceux-ci n’existent pas dans votre compte AWS, consultez « Créer les rôles et les politiques STS à l’échelle du compte » dans les ressources supplémentaires.
Procédure
Créez le fichier de la politique en saisissant la commande suivante dans la rosa CLI:
curl -o ./rosa-installer-core.json https://raw.githubusercontent.com/openshift/managed-cluster-config/master/resources/sts/4.18/sts_installer_core_permission_boundary_policy.json
$ curl -o ./rosa-installer-core.json https://raw.githubusercontent.com/openshift/managed-cluster-config/master/resources/sts/4.18/sts_installer_core_permission_boundary_policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow Créez la stratégie dans AWS et rassemblez son nom de ressource Amazon (ARN) en entrant la commande suivante:
aws iam create-policy \ --policy-name rosa-core-permissions-boundary-policy \ --policy-document file://./rosa-installer-core.json \ --description "ROSA installer core permission boundary policy, the minimum permission set, allows BYO-VPC, disallows PrivateLink"
$ aws iam create-policy \ --policy-name rosa-core-permissions-boundary-policy \ --policy-document file://./rosa-installer-core.json \ --description "ROSA installer core permission boundary policy, the minimum permission set, allows BYO-VPC, disallows PrivateLink"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ajoutez la stratégie de limite d’autorisation au rôle d’installateur que vous souhaitez restreindre en entrant la commande suivante:
aws iam put-role-permissions-boundary \ --role-name ManagedOpenShift-Installer-Role \ --permissions-boundary arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy
$ aws iam put-role-permissions-boundary \ --role-name ManagedOpenShift-Installer-Role \ --permissions-boundary arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Afficher le rôle d’installateur pour valider les stratégies jointes (y compris les limites des autorisations) en entrant la commande suivante dans la rosa CLI:
aws iam get-role --role-name ManagedOpenShift-Installer-Role \ --output text | grep PERMISSIONSBOUNDARY
$ aws iam get-role --role-name ManagedOpenShift-Installer-Role \ --output text | grep PERMISSIONSBOUNDARYCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
PERMISSIONSBOUNDARY arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy Policy
PERMISSIONSBOUNDARY arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy PolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow D’autres exemples de politiques de limites d’autorisation PL et VPC voir:
Exemple 3.17.
sts_installer_ privatelink_permission_border_policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple 3.18.
accueil > Sts_installer_vpc_permission_border_policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. Groupe de référence du rôle de l’opérateur IAM
Cette section fournit des détails sur les rôles IAM d’opérateur requis pour les déploiements de Red Hat OpenShift Service sur AWS (ROSA) qui utilisent STS. Les opérateurs de cluster utilisent les rôles d’opérateur pour obtenir les autorisations temporaires requises pour effectuer des opérations de cluster, telles que la gestion du stockage back-end, les informations d’identification des fournisseurs de cloud et l’accès externe à un cluster.
Lorsque vous créez les rôles d’opérateur, les stratégies d’opérateur à l’échelle du compte pour la version du cluster de correspondance sont attachées aux rôles. Les politiques de l’opérateur sont marquées avec l’opérateur et la version avec laquelle elles sont compatibles. La stratégie correcte pour un rôle d’opérateur est déterminée à l’aide des balises.
Lorsque plus d’une stratégie de correspondance est disponible dans votre compte pour un rôle d’opérateur, une liste interactive d’options est fournie lorsque vous créez l’opérateur.
| A) Ressources | Description |
|---|---|
|
| Le rôle IAM requis par ROSA pour gérer le stockage back-end via l’interface de stockage de conteneurs (CSI). |
|
| Le rôle IAM requis par l’opérateur de configuration de machine ROSA pour exécuter les fonctionnalités de cluster de base. |
|
| Le rôle IAM requis par l’opérateur d’identification en nuage ROSA pour gérer les informations d’identification des fournisseurs de cloud. |
|
| Le rôle IAM requis par le contrôleur de configuration du réseau cloud pour gérer la configuration du réseau cloud pour un cluster. |
|
| Le rôle IAM requis par l’opérateur de registre d’images ROSA pour gérer le stockage du registre d’images OpenShift dans AWS S3 pour un cluster. |
|
| Le rôle d’IAM requis par l’opérateur ROSA Ingress pour gérer l’accès externe à un cluster. |
|
| Le rôle IAM requis par le contrôleur de configuration du réseau cloud pour gérer les informations d’identification réseau cloud pour un cluster. |
3.4.1. Le rôle de l’opérateur IAM référence AWS CLI
Cette section répertorie les commandes aws CLI qui sont affichées dans le terminal lorsque vous exécutez la commande rosa suivante en mode manuel:
rosa create operator-roles --mode manual --cluster <cluster_name>
$ rosa create operator-roles --mode manual --cluster <cluster_name>Lorsque vous utilisez le mode manuel, les commandes aws sont imprimées sur le terminal pour votre examen. Après avoir examiné les commandes aws, vous devez les exécuter manuellement. Alternativement, vous pouvez spécifier --mode auto avec la commande rosa créer pour exécuter les commandes aws immédiatement.
Commande de sortie
Les exemples de commandes fournis dans le tableau incluent les rôles d’opérateur qui utilisent le préfixe ManagedOpenShift. Lorsque vous avez défini un préfixe personnalisé lorsque vous avez créé les rôles et stratégies à l’échelle du compte, y compris les stratégies d’opérateur, vous devez y faire référence en utilisant l’option --prefix <prefix_name> lorsque vous créez les rôles Opérateur.
3.4.2. À propos des préfixes de rôle IAM de l’opérateur personnalisé
Chaque cluster Red Hat OpenShift Service sur AWS (ROSA) qui utilise le service de jetons de sécurité AWS (STS) nécessite des rôles IAM d’opérateur spécifiques à un cluster.
Les noms de rôles de l’opérateur sont préfixés par défaut avec le nom du cluster et un hachage aléatoire à 4 chiffres. À titre d’exemple, le rôle IAM de Cloud Credential Operator pour un cluster nommé mycluster a le nom par défaut mycluster-<hash>-openshift-cloud-credential-operator-cloud-credentials, où <hash> est une chaîne aléatoire à 4 chiffres.
Cette convention de nommage par défaut vous permet d’identifier facilement les rôles d’opérateur IAM pour un cluster dans votre compte AWS.
Lorsque vous créez les rôles Opérateur pour un cluster, vous pouvez éventuellement spécifier un préfixe personnalisé à utiliser au lieu de <cluster_name>-<hash>. En utilisant un préfixe personnalisé, vous pouvez prédépender des identifiants logiques à vos noms de rôle Opérateur pour répondre aux exigences de votre environnement. À titre d’exemple, vous pouvez préfixer le nom du cluster et le type d’environnement, comme mycluster-dev. Dans cet exemple, le nom de rôle de Cloud Credential Operator avec le préfixe personnalisé est mycluster-dev-openshift-cloud-credential-operator-cloud-credenti.
Les noms des rôles sont tronqués à 64 caractères.
3.5. Exigences d’Open ID Connect (OIDC) pour l’authentification de l’opérateur
Dans le cas des installations ROSA qui utilisent STS, vous devez créer un fournisseur OIDC spécifique à un cluster utilisé par les opérateurs de clusters pour authentifier ou créer votre propre configuration OIDC pour votre propre fournisseur OIDC.
3.5.1. Création d’un fournisseur OIDC à l’aide du CLI
Il est possible de créer un fournisseur OIDC hébergé sur votre compte AWS avec Red Hat OpenShift Service sur AWS (ROSA) CLI, rosa.
Conditions préalables
- La dernière version de la ROSA CLI a été installée.
Procédure
Créer un fournisseur OIDC, en utilisant une configuration OIDC non enregistrée ou enregistrée.
Les configurations OIDC non enregistrées nécessitent de créer le fournisseur OIDC via le cluster. Exécutez ce qui suit pour créer le fournisseur OIDC:
rosa create oidc-provider --mode manual --cluster <cluster_name>
$ rosa create oidc-provider --mode manual --cluster <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteLorsque vous utilisez le mode manuel, la commande aws est imprimée sur le terminal pour votre examen. Après avoir examiné la commande aws, vous devez l’exécuter manuellement. Alternativement, vous pouvez spécifier --mode auto avec la commande rosa créer pour exécuter la commande aws immédiatement.
Commande de sortie
aws iam create-open-id-connect-provider \ --url https://oidc.op1.openshiftapps.com/<oidc_config_id> \ --client-id-list openshift sts.<aws_region>.amazonaws.com \ --thumbprint-list <thumbprint>
aws iam create-open-id-connect-provider \ --url https://oidc.op1.openshiftapps.com/<oidc_config_id> \1 --client-id-list openshift sts.<aws_region>.amazonaws.com \ --thumbprint-list <thumbprint>2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- L’URL utilisée pour atteindre le fournisseur d’identité OpenID Connect (OIDC) après la création du cluster.
- 2
- L’empreinte de pouce est générée automatiquement lorsque vous exécutez la commande rosa créer oidc-fourr. Consultez la documentation AWS pour plus d’informations sur l’utilisation des empreintes digitales avec AWS Identity and Access Management (IAM) des fournisseurs d’identité OIDC.
Les configurations OIDC enregistrées utilisent un identifiant de configuration OIDC. Exécutez la commande suivante avec votre identifiant de configuration OIDC:
rosa create oidc-provider --oidc-config-id <oidc_config_id> --mode auto -y
$ rosa create oidc-provider --oidc-config-id <oidc_config_id> --mode auto -yCopy to Clipboard Copied! Toggle word wrap Toggle overflow Commande de sortie
I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName' I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/241rh9ql5gpu99d7leokhvkp8icnalpf'
I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName' I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/241rh9ql5gpu99d7leokhvkp8icnalpf'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5.2. Création d’une configuration OpenID Connect
Lorsque vous utilisez un cluster hébergé par Red Hat, vous pouvez créer une configuration OpenID Connect (OIDC) gérée ou non en utilisant le service Red Hat OpenShift sur AWS (ROSA) CLI, rosa. La configuration OIDC gérée est stockée dans le compte AWS de Red Hat, tandis qu’une configuration OIDC non gérée générée est stockée dans votre compte AWS. La configuration OIDC est enregistrée pour être utilisée avec OpenShift Cluster Manager. Lors de la création d’une configuration OIDC non gérée, le CLI vous fournit la clé privée.
Création d’une configuration OpenID Connect
Lorsque vous utilisez un Red Hat OpenShift Service sur AWS cluster, vous pouvez créer la configuration OpenID Connect (OIDC) avant de créer votre cluster. Cette configuration est enregistrée pour être utilisée avec OpenShift Cluster Manager.
Conditions préalables
- Les prérequis AWS pour le service OpenShift Red Hat sont complétés sur AWS.
- Dans votre installation, vous avez installé et configuré le dernier service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.
Procédure
Afin de créer votre configuration OIDC à côté des ressources AWS, exécutez la commande suivante:
rosa create oidc-config --mode=auto --yes
$ rosa create oidc-config --mode=auto --yesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Cette commande renvoie les informations suivantes.
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Lors de la création de votre cluster, vous devez fournir l’identifiant de configuration OIDC. La sortie CLI fournit cette valeur pour --mode auto, sinon vous devez déterminer ces valeurs en fonction de la sortie CLI aws pour --mode manuel.
Facultatif : vous pouvez enregistrer l’identifiant de configuration OIDC en tant que variable à utiliser ultérieurement. Exécutez la commande suivante pour enregistrer la variable:
export OIDC_ID=<oidc_config_id>
$ export OIDC_ID=<oidc_config_id>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Dans l’exemple de sortie ci-dessus, l’IDC de configuration ID est 13cdr6b.
Afficher la valeur de la variable en exécutant la commande suivante:
echo $OIDC_ID
$ echo $OIDC_IDCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
13cdr6b
13cdr6bCopy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Il est possible de répertorier les configurations OIDC possibles pour vos clusters associés à votre organisation utilisateur. Exécutez la commande suivante:
rosa list oidc-config
$ rosa list oidc-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDN
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDNCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Des options de paramètres pour créer votre propre configuration OpenID Connect
Les options suivantes peuvent être ajoutées à la commande rosa create oidc-config. Ces paramètres sont tous facultatifs. L’exécution de la commande rosa créer oidc-config sans paramètres crée une configuration OIDC non gérée.
Il vous est demandé d’enregistrer la configuration OIDC non gérée en affichant une demande à /oidc_configs via OpenShift Cluster Manager. Dans la réponse, vous recevez une pièce d’identité. Cet ID permet de créer un cluster.
fichiers bruts
Il vous permet de fournir des fichiers bruts pour la clé RSA privée. Cette clé s’appelle rosa-private-key-oidc-<random_label_of_length_4>.key. De plus, vous recevez un document de découverte, nommé Discovery-document-oidc-<random_label_of_length_4>.json, et un jeu de clés Web JSON, nommé jwks-oidc-<random_label_of_length_4>.json.
Ces fichiers sont utilisés pour configurer le point de terminaison. Ce point de terminaison répond à /.well-known/openid-configuration avec le document de découverte et sur keys.json avec le JSON Web Key Set. La clé privée est stockée dans Amazon Web Services (AWS) Secrets Manager Service (SMS) sous forme de texte clair.
Exemple :
rosa create oidc-config --raw-files
$ rosa create oidc-config --raw-filesle mode
Il vous permet de spécifier le mode pour créer votre configuration OIDC. Avec l’option manuelle, vous recevez des commandes AWS qui configurent la configuration OIDC dans un seau S3. Cette option stocke la clé privée dans le Gestionnaire des secrets. Avec l’option manuelle, l’URL OIDC Endpoint est l’URL du seau S3. Il faut récupérer l’ARN du Gestionnaire Secrets pour enregistrer la configuration OIDC avec OpenShift Cluster Manager.
Lors de l’utilisation de l’option automatique, vous recevez la même configuration OIDC et les mêmes ressources AWS que le mode manuel. La différence significative entre les deux options est que lors de l’utilisation de l’option automatique, ROSA appelle AWS, de sorte que vous n’avez pas besoin de prendre d’autres actions. L’URL OIDC Endpoint est l’URL du seau S3. Le CLI récupère l’ARN Secrets Manager, enregistre la configuration OIDC avec OpenShift Cluster Manager, et rapporte la deuxième commande rosa que l’utilisateur peut exécuter pour continuer avec la création du cluster STS.
Exemple :
rosa create oidc-config --mode=<auto|manual>
$ rosa create oidc-config --mode=<auto|manual>géré
Crée une configuration OIDC hébergée sous le compte AWS de Red Hat. Cette commande crée une clé privée qui répond directement avec un identifiant de configuration OIDC que vous pouvez utiliser lors de la création du cluster STS.
Exemple :
rosa create oidc-config --managed
$ rosa create oidc-config --managedExemple de sortie
3.6. Ensemble minimum d’autorisations efficaces pour les politiques de contrôle du service (SCP)
Les stratégies de contrôle des services (SCP) sont un type de stratégie d’organisation qui gère les autorisations au sein de votre organisation. Les SCP s’assurent que les comptes au sein de votre organisation restent dans le respect de vos directives de contrôle d’accès définies. Ces politiques sont maintenues dans AWS Organizations et contrôlent les services disponibles dans les comptes AWS ci-joints. La gestion de SCP relève de la responsabilité du client.
Lorsque vous utilisez AWS Security Token Service (STS), vous devez vous assurer que la stratégie de contrôle du service ne bloque pas les ressources suivantes:
-
ec2: {} -
IAM: {} -
étiquette :*
Assurez-vous que votre politique de contrôle de service (SCP) ne limite aucune de ces autorisations requises.
| Le service | Actions | Effet | |
|---|---|---|---|
| A) requis | Amazon EC2 | Le tout | Autoriser |
| Amazon EC2 Auto Scaling | Le tout | Autoriser | |
| Amazon S3 | Le tout | Autoriser | |
| Gestion de l’identité et de l’accès | Le tout | Autoriser | |
| Équilibrage de charge élastique | Le tout | Autoriser | |
| Équilibrage de charge élastique V2 | Le tout | Autoriser | |
| Amazon CloudWatch | Le tout | Autoriser | |
| Événements Amazon CloudWatch | Le tout | Autoriser | |
| Journaux Amazon CloudWatch | Le tout | Autoriser | |
| AWS EC2 Instance Connect | SendSerialConsoleSSHPublicKey | Autoriser | |
| Le support AWS | Le tout | Autoriser | |
| AWS Key Management Service | Le tout | Autoriser | |
| AWS Security Token Service | Le tout | Autoriser | |
| AWS Tiro | CréerQuery GetQueryAnswer GetQueryExplanation | Autoriser | |
| AWS Marketplace | Abonnez-vous Désabonnement Afficher les abonnements | Autoriser | |
| Étiquettes des ressources AWS | Le tout | Autoriser | |
| AWS Route53 DNS | Le tout | Autoriser | |
| Quotas de service AWS | Liste des services GetRequestedServiceQuotaChange GetServiceQuota DemandeServiceQuotaaugmentation ListeServiceQuotas | Autoriser | |
| Facultatif | Facturation AWS | AfficherAccount Affichage de la facturation AffichageUsage | Autoriser |
| AWS Rapport sur les coûts et l’utilisation | Le tout | Autoriser | |
| AWS Cost Explorer Services | Le tout | Autoriser |
3.7. Des politiques gérées par le client
Les utilisateurs de Red Hat OpenShift Service sur AWS (ROSA) sont en mesure d’attacher des stratégies gérées par le client aux rôles IAM nécessaires pour exécuter et maintenir des clusters ROSA. Cette capacité n’est pas rare avec les rôles AWS IAM. La capacité d’attacher ces politiques à des rôles IAM spécifiques à ROSA étend les capacités d’autorisation d’un cluster ROSA; par exemple, pour permettre aux composants de cluster d’accéder à des ressources AWS supplémentaires qui ne font pas partie des politiques IAM spécifiques au ROSA.
Afin de s’assurer que toute application client critique qui s’appuie sur des politiques gérées par le client ne soit pas modifiée de quelque manière que ce soit lors des mises à niveau de cluster ou de rôle, ROSA utilise l’autorisation ListAttachedRolesPolicies pour récupérer la liste des politiques d’autorisation des rôles et l’autorisation ListRolePolicies pour récupérer la liste des politiques à partir de rôles spécifiques à ROSA. Cette information garantit que les politiques gérées par les clients ne sont pas impactées lors des événements de cluster, et permet aux SRE Red Hat de surveiller les politiques ROSA et gérées par les clients attachées aux rôles IAM spécifiques à ROSA, améliorant ainsi leur capacité à résoudre les problèmes de clusters plus efficacement.
L’attachement de stratégies de limites d’autorisation aux rôles IAM qui restreignent les stratégies spécifiques à la ROSA n’est pas prise en charge, car ces politiques pourraient interrompre la fonctionnalité des autorisations de base nécessaires pour exécuter et maintenir avec succès votre cluster ROSA. Il existe des politiques de limites d’autorisations préparées pour le rôle d’installateur ROSA (architecture classique). Consultez la section Ressources supplémentaires pour plus d’informations.
Chapitre 4. Aperçu d’OpenID Connect
L’OpenID Connect (OIDC) utilise Security Token Service (STS) pour permettre aux clients de fournir un jeton d’identité Web pour accéder à plusieurs services. Lorsqu’un client se connecte à un service en utilisant STS, le jeton est validé par rapport au fournisseur d’identité OIDC.
Le protocole OIDC utilise une URL de configuration qui contient les informations nécessaires pour authentifier l’identité d’un client. Le protocole répond au fournisseur avec les informations d’identification nécessaires au fournisseur pour valider le client et les connecter.
Le service OpenShift Red Hat sur les clusters AWS utilise STS et OIDC pour accorder aux opérateurs inclus l’accès aux ressources AWS nécessaires.
4.1. Comprendre les options de vérification OIDC
Les types de vérification OIDC suivants peuvent être configurés:
Configuration OIDC non enregistrée et gérée
Lors du processus d’installation du cluster, une configuration OIDC non enregistrée et gérée est créée pour vous. La configuration est hébergée sous le compte AWS de Red Hat. Cette option ne vous donne pas l’identifiant qui relie la configuration OIDC, de sorte que vous ne pouvez utiliser ce type de configuration OIDC que sur un seul cluster.
Configuration OIDC enregistrée et gérée
Créez une configuration OIDC enregistrée et gérée avant de commencer à créer vos clusters. Cette configuration est hébergée sous le compte AWS de Red Hat comme la configuration OIDC gérée non enregistrée. Lorsque vous utilisez cette option pour votre configuration OIDC, vous recevez un ID qui se connecte à la configuration OIDC. Le Red Hat utilise cet identifiant pour identifier l’URL de l’émetteur et la clé privée. Ensuite, vous pouvez utiliser cette URL et cette clé privée pour créer un fournisseur d’identité et des rôles d’opérateur. Ces ressources sont créées sous votre compte AWS en utilisant les services AWS de gestion des identités et des accès (IAM). Il est également possible d’utiliser l’identifiant de configuration OIDC pendant le processus de création du cluster.
Configuration OIDC enregistrée et non gérée
Il est possible de créer une configuration OIDC enregistrée et non gérée avant de commencer à créer vos clusters. Cette configuration est hébergée sous votre compte AWS. Lorsque vous utilisez cette option, vous êtes responsable de la gestion de la clé privée. Enregistrez la configuration avec Red Hat OpenShift Cluster Manager en stockant la clé privée dans un fichier secret AWS à l’aide du service AWS Secrets Manager (SM) et de l’URL de l’émetteur qui héberge la configuration. Le Red Hat OpenShift Service sur AWS (ROSA) CLI, rosa, vous permet de créer une configuration OIDC enregistrée et non gérée avec la commande rosa créer oidc-config --managed=false. Cette commande crée et héberge la configuration sous votre compte et crée les fichiers nécessaires et la clé secrète privée. Cette commande enregistre également la configuration avec OpenShift Cluster Manager.
Les options enregistrées peuvent être utilisées pour créer les ressources IAM requises avant de commencer à créer un cluster. Cette option se traduit par des temps d’installation plus rapides puisqu’il y a une période d’attente pendant la création de cluster où l’installation s’arrête jusqu’à ce que vous créez un fournisseur OIDC et des rôles d’opérateur.
Dans le cas de ROSA Classic, vous pouvez utiliser l’une des options de configuration OIDC. Lorsque vous utilisez ROSA avec HCP, vous devez créer une configuration OIDC enregistrée, qu’elle soit gérée ou non gérée. Les configurations OIDC enregistrées peuvent être partagées avec d’autres clusters. Cette possibilité de partager la configuration vous permet également de partager les rôles de fournisseur et d’opérateur.
La réutilisation des configurations OIDC, du fournisseur OIDC et des rôles d’opérateur entre les clusters n’est pas recommandée pour les clusters de production puisque la vérification d’authentification est utilisée dans tous ces clusters. Le Red Hat recommande de réutiliser uniquement les ressources entre les environnements de test de non-production.
4.2. Création d’une configuration OpenID Connect
Lorsque vous utilisez un cluster hébergé par Red Hat, vous pouvez créer une configuration OpenID Connect (OIDC) gérée ou non en utilisant le service Red Hat OpenShift sur AWS (ROSA) CLI, rosa. La configuration OIDC gérée est stockée dans le compte AWS de Red Hat, tandis qu’une configuration OIDC non gérée générée est stockée dans votre compte AWS. La configuration OIDC est enregistrée pour être utilisée avec OpenShift Cluster Manager. Lors de la création d’une configuration OIDC non gérée, le CLI vous fournit la clé privée.
Création d’une configuration OpenID Connect
Lorsque vous utilisez un Red Hat OpenShift Service sur AWS cluster, vous pouvez créer la configuration OpenID Connect (OIDC) avant de créer votre cluster. Cette configuration est enregistrée pour être utilisée avec OpenShift Cluster Manager.
Conditions préalables
- Les prérequis AWS pour le service OpenShift Red Hat sont complétés sur AWS.
- Dans votre installation, vous avez installé et configuré le dernier service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.
Procédure
Afin de créer votre configuration OIDC à côté des ressources AWS, exécutez la commande suivante:
rosa create oidc-config --mode=auto --yes
$ rosa create oidc-config --mode=auto --yesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Cette commande renvoie les informations suivantes.
Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Lors de la création de votre cluster, vous devez fournir l’identifiant de configuration OIDC. La sortie CLI fournit cette valeur pour --mode auto, sinon vous devez déterminer ces valeurs en fonction de la sortie CLI aws pour --mode manuel.
Facultatif : vous pouvez enregistrer l’identifiant de configuration OIDC en tant que variable à utiliser ultérieurement. Exécutez la commande suivante pour enregistrer la variable:
export OIDC_ID=<oidc_config_id>
$ export OIDC_ID=<oidc_config_id>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Dans l’exemple de sortie ci-dessus, l’IDC de configuration ID est 13cdr6b.
Afficher la valeur de la variable en exécutant la commande suivante:
echo $OIDC_ID
$ echo $OIDC_IDCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
13cdr6b
13cdr6bCopy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Il est possible de répertorier les configurations OIDC possibles pour vos clusters associés à votre organisation utilisateur. Exécutez la commande suivante:
rosa list oidc-config
$ rosa list oidc-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDN
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDNCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Des options de paramètres pour créer votre propre configuration OpenID Connect
Les options suivantes peuvent être ajoutées à la commande rosa create oidc-config. Ces paramètres sont tous facultatifs. L’exécution de la commande rosa créer oidc-config sans paramètres crée une configuration OIDC non gérée.
Il vous est demandé d’enregistrer la configuration OIDC non gérée en affichant une demande à /oidc_configs via OpenShift Cluster Manager. Dans la réponse, vous recevez une pièce d’identité. Cet ID permet de créer un cluster.
fichiers bruts
Il vous permet de fournir des fichiers bruts pour la clé RSA privée. Cette clé s’appelle rosa-private-key-oidc-<random_label_of_length_4>.key. De plus, vous recevez un document de découverte, nommé Discovery-document-oidc-<random_label_of_length_4>.json, et un jeu de clés Web JSON, nommé jwks-oidc-<random_label_of_length_4>.json.
Ces fichiers sont utilisés pour configurer le point de terminaison. Ce point de terminaison répond à /.well-known/openid-configuration avec le document de découverte et sur keys.json avec le JSON Web Key Set. La clé privée est stockée dans Amazon Web Services (AWS) Secrets Manager Service (SMS) sous forme de texte clair.
Exemple :
rosa create oidc-config --raw-files
$ rosa create oidc-config --raw-filesle mode
Il vous permet de spécifier le mode pour créer votre configuration OIDC. Avec l’option manuelle, vous recevez des commandes AWS qui configurent la configuration OIDC dans un seau S3. Cette option stocke la clé privée dans le Gestionnaire des secrets. Avec l’option manuelle, l’URL OIDC Endpoint est l’URL du seau S3. Il faut récupérer l’ARN du Gestionnaire Secrets pour enregistrer la configuration OIDC avec OpenShift Cluster Manager.
Lors de l’utilisation de l’option automatique, vous recevez la même configuration OIDC et les mêmes ressources AWS que le mode manuel. La différence significative entre les deux options est que lors de l’utilisation de l’option automatique, ROSA appelle AWS, de sorte que vous n’avez pas besoin de prendre d’autres actions. L’URL OIDC Endpoint est l’URL du seau S3. Le CLI récupère l’ARN Secrets Manager, enregistre la configuration OIDC avec OpenShift Cluster Manager, et rapporte la deuxième commande rosa que l’utilisateur peut exécuter pour continuer avec la création du cluster STS.
Exemple :
rosa create oidc-config --mode=<auto|manual>
$ rosa create oidc-config --mode=<auto|manual>géré
Crée une configuration OIDC hébergée sous le compte AWS de Red Hat. Cette commande crée une clé privée qui répond directement avec un identifiant de configuration OIDC que vous pouvez utiliser lors de la création du cluster STS.
Exemple :
rosa create oidc-config --managed
$ rosa create oidc-config --managedExemple de sortie
4.3. Création d’un fournisseur OIDC à l’aide du CLI
Il est possible de créer un fournisseur OIDC hébergé sur votre compte AWS avec Red Hat OpenShift Service sur AWS (ROSA) CLI, rosa.
Conditions préalables
- La dernière version de la ROSA CLI a été installée.
Procédure
Créer un fournisseur OIDC, en utilisant une configuration OIDC non enregistrée ou enregistrée.
Les configurations OIDC non enregistrées nécessitent de créer le fournisseur OIDC via le cluster. Exécutez ce qui suit pour créer le fournisseur OIDC:
rosa create oidc-provider --mode manual --cluster <cluster_name>
$ rosa create oidc-provider --mode manual --cluster <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteLorsque vous utilisez le mode manuel, la commande aws est imprimée sur le terminal pour votre examen. Après avoir examiné la commande aws, vous devez l’exécuter manuellement. Alternativement, vous pouvez spécifier --mode auto avec la commande rosa créer pour exécuter la commande aws immédiatement.
Commande de sortie
aws iam create-open-id-connect-provider \ --url https://oidc.op1.openshiftapps.com/<oidc_config_id> \ --client-id-list openshift sts.<aws_region>.amazonaws.com \ --thumbprint-list <thumbprint>
aws iam create-open-id-connect-provider \ --url https://oidc.op1.openshiftapps.com/<oidc_config_id> \1 --client-id-list openshift sts.<aws_region>.amazonaws.com \ --thumbprint-list <thumbprint>2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- L’URL utilisée pour atteindre le fournisseur d’identité OpenID Connect (OIDC) après la création du cluster.
- 2
- L’empreinte de pouce est générée automatiquement lorsque vous exécutez la commande rosa créer oidc-fourr. Consultez la documentation AWS pour plus d’informations sur l’utilisation des empreintes digitales avec AWS Identity and Access Management (IAM) des fournisseurs d’identité OIDC.
Les configurations OIDC enregistrées utilisent un identifiant de configuration OIDC. Exécutez la commande suivante avec votre identifiant de configuration OIDC:
rosa create oidc-provider --oidc-config-id <oidc_config_id> --mode auto -y
$ rosa create oidc-provider --oidc-config-id <oidc_config_id> --mode auto -yCopy to Clipboard Copied! Toggle word wrap Toggle overflow Commande de sortie
I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName' I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/241rh9ql5gpu99d7leokhvkp8icnalpf'
I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName' I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/241rh9ql5gpu99d7leokhvkp8icnalpf'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Legal Notice
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}