Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Chapitre 11. Déploiement de ROSA sans AWS STS

11.1. AWS prérequis pour ROSA
Copier lien

Le Red Hat OpenShift Service sur AWS (ROSA) fournit un modèle qui permet à Red Hat de déployer des clusters dans le compte Amazon Web Service (AWS) existant d’un client.

Avant d’installer ROSA, vous devez vous assurer que les conditions préalables sont remplies. Ce document d’exigences ne s’applique pas à AWS Security Token Service (STS). Lorsque vous utilisez STS, consultez les exigences spécifiques au STS.

Astuce

AWS Security Token Service (STS) est le mode d’identification recommandé pour l’installation et l’interaction avec les clusters sur Red Hat OpenShift Service sur AWS car il offre une sécurité accrue.

11.1.1. Exigences du client
Copier lien

Les clusters Red Hat OpenShift Service sur AWS (ROSA) doivent répondre à plusieurs prérequis avant de pouvoir être déployés.

Note

Afin de créer le cluster, l’utilisateur doit être connecté en tant qu’utilisateur IAM et non pas un rôle assumé ou un utilisateur STS.

11.1.1.1. Compte
Copier lien

  • Le client veille à ce que les limites AWS soient suffisantes pour prendre en charge le service Red Hat OpenShift sur AWS fourni dans le compte AWS du client.

  • Le compte AWS du client doit être dans les organisations AWS du client avec la politique de contrôle du service (SCP) applicable.

    Note

    Il n’est pas nécessaire que le compte du client soit dans les organisations AWS ou que le SCP soit appliqué, mais Red Hat doit être en mesure d’effectuer toutes les actions énumérées dans le SCP sans restriction.

  • Le compte AWS du client ne devrait pas être transférable à Red Hat.
  • Le client ne peut pas imposer de restrictions d’utilisation AWS aux activités Red Hat. Imposer des restrictions entravera gravement la capacité de Red Hat à réagir aux incidents.

  • Le client peut déployer des services AWS natifs au sein du même compte AWS.

    Note

    Les clients sont encouragés, mais non mandatés, à déployer des ressources dans un Cloud privé virtuel (VPC) distinct du VPC hébergeant Red Hat OpenShift Service sur AWS et d’autres services pris en charge par Red Hat.

11.1.1.2. Exigences d’accès
Copier lien

  • Afin de gérer correctement le service Red Hat OpenShift sur le service AWS, Red Hat doit faire appliquer la politique AdministratorAccess au rôle d’administrateur en tout temps. Cette exigence ne s’applique pas si vous utilisez AWS Security Token Service (STS).

    Note

    Cette politique fournit uniquement à Red Hat des autorisations et des capacités pour modifier les ressources du compte AWS fourni par le client.

  • Le Red Hat doit avoir accès à la console AWS au compte AWS fourni par le client. Cet accès est protégé et géré par Red Hat.
  • Le client ne doit pas utiliser le compte AWS pour augmenter ses autorisations au sein du service Red Hat OpenShift sur le cluster AWS.
  • Les actions disponibles dans le service OpenShift Red Hat sur AWS (ROSA) CLI, rosa ou OpenShift Cluster Manager ne doivent pas être effectuées directement sur le compte AWS du client.

11.1.1.3. Besoins de soutien
Copier lien

  • Le Red Hat recommande que le client dispose au moins d’un support professionnel d’AWS.
  • Le client a l’autorité de Red Hat pour demander un support AWS en son nom.
  • Le Red Hat a le pouvoir du client de demander des augmentations de limite de ressources AWS sur le compte du client.
  • Le Red Hat gère les restrictions, limitations, attentes et défaut pour tous les services OpenShift Red Hat sur les clusters AWS de la même manière, sauf indication contraire dans cette section d’exigences.

11.1.1.4. Exigences de sécurité
Copier lien

  • Les instantanés de volume resteront dans le compte AWS du client et dans la région spécifiée par le client.
  • Le Red Hat doit avoir accès aux hôtes EC2 et au serveur API à partir d’adresses IP autorisées.
  • Le Red Hat doit avoir le droit d’envoyer le système et les journaux d’audit vers une pile de journalisation centrale gérée par Red Hat.

11.1.2. La procédure client requise
Copier lien

Complétez ces étapes avant de déployer Red Hat OpenShift Service sur AWS (ROSA).

Procédure

  1. En tant que client, si vous utilisez AWS Organizations, vous devez utiliser un compte AWS au sein de votre organisation ou en créer un nouveau.
  2. Afin de vous assurer que Red Hat peut effectuer les actions nécessaires, vous devez soit créer une stratégie de contrôle du service (SCP) soit s’assurer qu’aucune n’est appliquée au compte AWS.
  3. Attachez le SCP au compte AWS.
  4. Suivre les procédures ROSA pour la mise en place de l’environnement.

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.

Note

L’exigence minimale de SCP ne s’applique pas lorsque vous utilisez AWS Security Token Service (STS). Consultez les prérequis AWS pour ROSA avec STS pour plus d’informations sur STS.

Assurez-vous que votre politique de contrôle de service (SCP) ne limite aucune de ces autorisations requises.

Expand
 Le serviceActionsEffet

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

11.1.3. Les références de Red Hat gérées par IAM pour AWS
Copier lien

Il est responsable de la création et de la gestion des ressources Amazon Web Services (AWS) suivantes : les politiques IAM, les utilisateurs de l’IAM et les rôles de l’IAM.

11.1.3.1. IAM Politiques
Copier lien

Note

Les politiques IAM sont sujettes à modification à mesure que les capacités de Red Hat OpenShift Service sur AWS changent.

  • La politique AdministratorAccess est utilisée par le rôle d’administration. Cette politique fournit à Red Hat l’accès nécessaire pour administrer le cluster Red Hat OpenShift Service sur AWS (ROSA) dans le compte AWS du client. 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "*",
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}
    Copy to Clipboard Toggle word wrap

11.1.3.2. Les utilisateurs de l’IAM
Copier lien

L’utilisateur osdManagedAdmin est créé immédiatement après l’installation de ROSA dans le compte AWS du client.

11.1.4. Infrastructure AWS provisionnée
Copier lien

Il s’agit d’un aperçu des composants Amazon Web Services (AWS) fournis sur un cluster Red Hat OpenShift Service sur AWS (ROSA) déployé.

11.1.4.1. Instances EC2
Copier lien

Les instances AWS EC2 sont nécessaires pour déployer les fonctions de plan de contrôle et de plan de données pour Red Hat OpenShift Service sur AWS.

Les types d’instances peuvent varier pour les nœuds de plan de contrôle et d’infrastructure, en fonction du nombre de nœuds de travail.

Au minimum, les instances EC2 suivantes sont déployées:

  • 3 m5.2x grands nœuds de plan de commande
  • Deux nœuds d’infrastructure r5.xlarge
  • Deux nœuds de travail m5.xlarge

Le type d’instance affiché pour les nœuds de travail est la valeur par défaut, mais vous pouvez personnaliser le type d’instance pour les nœuds de travail en fonction des besoins de votre charge de travail.

Afin d’obtenir de plus amples conseils sur le comptage des nœuds des travailleurs, consultez les informations sur les considérations de planification initiales dans le sujet « Limites et évolutivité » figurant dans la section « Ressources supplémentaires » de cette page.

11.1.4.2. Amazon Elastic Block Store stockage
Copier lien

Le stockage de blocs Amazon Elastic Block Store (Amazon EBS) est utilisé à la fois pour le stockage des nœuds locaux et le stockage en volume persistant. Les valeurs suivantes sont la taille par défaut du stockage éphémère local prévu pour chaque instance EC2.

Exigences en volume pour chaque instance EC2:

  • Contrôle du volume du plan

    • Format: 350 Go
    • Catégorie: gp3
    • Entrée/sortie Opérations par seconde: 1000

  • Le volume de l’infrastructure

    • Dimensions: 300 Go
    • Catégorie: gp3
    • Entrées/sorties par seconde : 900

  • Le volume des travailleurs

    • Taille par défaut: 300 Go
    • Format minimum: 128 Go
    • Format minimum: 75 Go
    • Catégorie: gp3
    • Entrées/sorties par seconde : 900
Note

Les clusters déployés avant la sortie d’OpenShift Container Platform 4.11 utilisent le stockage de type gp2 par défaut.

11.1.4.3. Équilibrage de charge élastique
Copier lien

Chaque cluster peut utiliser jusqu’à deux balanceurs de charge classiques pour le routeur d’application et jusqu’à deux balanceurs de charge réseau pour API.

Consultez la documentation ELB pour AWS.

11.1.4.4. Le stockage S3
Copier lien

Le registre des images est soutenu par le stockage AWS S3. La valorisation des ressources est effectuée régulièrement afin d’optimiser l’utilisation de S3 et la performance des clusters.

Note

Deux seaux sont nécessaires avec une taille typique de 2 To chacun.

11.1.4.5. LE VPC
Copier lien

Configurez votre VPC selon les exigences suivantes:

  • Deux sous-réseaux pour un cluster avec une seule zone de disponibilité, ou six sous-réseaux pour un cluster avec plusieurs zones de disponibilité.

    Le Red Hat recommande fortement d’utiliser des sous-réseaux uniques pour chaque cluster. Le partage de sous-réseaux entre plusieurs clusters n’est pas recommandé.

    Note

    Le sous-réseau public se connecte directement à Internet via une passerelle Internet. Le sous-réseau privé se connecte à Internet via une passerelle de traduction d’adresse réseau (NAT).

  • Les tables d’itinéraire: une table de route par sous-réseau privé, et une table supplémentaire par cluster.
  • Passerelles Internet: une passerelle Internet par cluster.
  • Passerelles NAT: Une passerelle NAT par sous-réseau public.

Figure 11.1. Exemple d’architecture VPC

Architecture de référence VPC
View larger image
Architecture de référence VPC

11.1.4.6. Groupes de sécurité
Copier lien

Les groupes de sécurité AWS assurent la sécurité au niveau du protocole et de l’accès au port; ils sont associés aux instances EC2 et aux balanceurs de charge Elastic Load Balancing (ELB). Chaque groupe de sécurité contient un ensemble de règles qui filtrent le trafic entrant et sortant d’une ou de plusieurs instances EC2.

Assurez-vous que les ports requis pour l’installation et le fonctionnement du cluster sont ouverts sur votre réseau et configurés pour permettre l’accès entre les hôtes. Les exigences pour les groupes de sécurité par défaut sont listées dans les ports requis pour les groupes de sécurité par défaut.

Expand
Tableau 11.1. Les ports requis pour les groupes de sécurité par défaut
Groupe de travailLe typeLe protocole de propriété intellectuelleGamme de ports

Groupe MasterSecurity

AWS :: EC2 ::SecurityGroup

ICMP

0

le TCP

22

le TCP

6443

le TCP

22623

Groupe WorkerSecurity

AWS :: EC2 ::SecurityGroup

ICMP

0

le TCP

22

BootstrapSecurityGroup

AWS :: EC2 ::SecurityGroup

le TCP

22

le TCP

19531

Lorsque vous créez un cluster à l’aide d’un VPC existant non géré, vous pouvez ajouter des groupes de sécurité personnalisés supplémentaires lors de la création de clusters. Les groupes de sécurité personnalisés sont soumis aux limitations suivantes:

  • Il faut créer les groupes de sécurité personnalisés dans AWS avant de créer le cluster. Consultez les groupes de sécurité Amazon EC2 pour les instances Linux.
  • Il faut associer les groupes de sécurité personnalisés au VPC dans lequel le cluster sera installé. Les groupes de sécurité personnalisés ne peuvent pas être associés à un autre VPC.
  • Il vous faudra peut-être demander un quota supplémentaire pour votre VPC si vous ajoutez des groupes de sécurité personnalisés supplémentaires. Afin d’obtenir des informations sur les exigences de quotas AWS pour ROSA, consultez les quotas de service AWS requis dans Préparez votre environnement. Afin d’obtenir des informations sur la demande d’augmentation du quota AWS, consultez Demander une augmentation de quota.

11.1.5. Conditions préalables à la mise en réseau
Copier lien

11.1.5.1. Bande passante minimale
Copier lien

Lors du déploiement de clusters, Red Hat OpenShift Service sur AWS nécessite une bande passante minimale de 120 Mbps entre les ressources de cluster et les ressources Internet publiques. Lorsque la connectivité réseau est plus lente que 120 Mbps (par exemple, lors de la connexion via un proxy), le processus d’installation du cluster est terminé et le déploiement échoue.

Après le déploiement, les besoins du réseau sont déterminés par votre charge de travail. Cependant, une bande passante minimale de 120 Mbps permet d’assurer des mises à niveau opportunes des clusters et des opérateurs.

11.1.6. Les prochaines étapes
Copier lien

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat