Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

De préparer votre environnement

Red Hat OpenShift Service on AWS 4

La planification, les limites et l’évolutivité pour Red Hat OpenShift Service sur AWS

Red Hat OpenShift Documentation Team

Résumé

Ce document fournit des considérations de planification pour Red Hat OpenShift Service sur les déploiements de clusters AWS (ROSA), y compris des informations sur les limites et l’évolutivité des clusters.

Il s’agit d’une liste de contrôle de haut niveau des prérequis nécessaires pour créer un cluster Red Hat OpenShift Service sur AWS (ROSA) (architecture classique) avec STS.

La machine à partir de laquelle vous exécutez le processus d’installation doit avoir accès aux éléments suivants:

  • API Amazon Web Services et points de terminaison des services d’authentification
  • API Red Hat OpenShift et points de terminaison de service d’authentification (api.openshift.com et sso.redhat.com)
  • Connectivité Internet pour obtenir des artefacts d’installation
Important

À partir de la version 1.2.7 du ROSA CLI, toutes les URL de point de terminaison du fournisseur OIDC sur les nouveaux clusters utilisent Amazon CloudFront et le domaine oidc.op1.openshiftapps.com. Ce changement améliore la vitesse d’accès, réduit la latence et améliore la résilience des nouveaux clusters créés avec la ROSA CLI 1.2.7 ou ultérieure. Il n’y a pas de chemins de migration pris en charge pour les configurations de fournisseurs OIDC existantes.

1.1. Comptes et autorisations
Copier lien

Assurez-vous que vous avez les comptes, les informations d’identification et les autorisations suivantes.

1.1.1. Compte AWS
Copier lien

  • Créez un compte AWS si vous n’en avez pas déjà un.
  • Collectez les informations d’identification nécessaires pour vous connecter à votre compte AWS.
  • Assurez-vous que votre compte AWS dispose d’autorisations suffisantes pour utiliser le ROSA CLI: moins d’autorisations de privilège pour les commandes courantes ROSA CLI

  • Activez ROSA pour votre compte AWS sur la console AWS.

    • Dans le cas où votre compte est le compte de gestion de votre organisation (utilisé à des fins de facturation AWS), vous devez disposer des autorisations aws-marketplace:S’abonner sur votre compte. Consultez les prérequis de la stratégie de contrôle du service (SCP) pour plus d’informations, ou consultez la documentation AWS pour le dépannage : la stratégie de contrôle du service AWS Organizations nie les autorisations requises pour AWS Marketplace.

1.1.2. Compte Red Hat
Copier lien

  • Créez un compte Red Hat pour la console de cloud hybride Red Hat si vous n’en avez pas déjà un.
  • Collectez les informations d’identification nécessaires pour vous connecter à votre compte Red Hat.

1.2. Exigences du CLI
Copier lien

Il faut télécharger et installer plusieurs outils CLI (interface de ligne de commande) pour pouvoir déployer un cluster.

1.2.1. AWS CLI (aws)
Copier lien

  1. Installez l’interface de ligne de commande AWS.
  2. Connectez-vous à votre compte AWS à l’aide de l’AWS CLI: Connectez-vous via AWS CLI

  3. Contrôlez l’identité de votre compte: 

     $ aws sts get-caller-identity
    Copy to Clipboard Toggle word wrap

  4. Vérifiez si le rôle de service pour ELB (Elastic Load Balancing) existe: 

    $ aws iam get-role --role-name "AWSServiceRoleForElasticLoadBalancing"
    Copy to Clipboard Toggle word wrap

    Lorsque le rôle n’existe pas, créez-le en exécutant la commande suivante: 

    $ aws iam create-service-linked-role --aws-service-name "elasticloadbalancing.amazonaws.com"
    Copy to Clipboard Toggle word wrap

1.2.2. CLI ROSA (rosa)
Copier lien

  1. Installez le ROSA CLI à partir de la console Web. Consultez l’installation du Red Hat OpenShift Service sur AWS (ROSA) CLI, rosa pour des instructions détaillées.

  2. Connectez-vous à votre compte Red Hat en exécutant la connexion rosa et en suivant les instructions de la sortie de commande: 

    $ rosa login
To login to your Red Hat account, get an offline access token at https://console.redhat.com/openshift/token/rosa
? Copy the token and paste it here:
    Copy to Clipboard Toggle word wrap

    Alternativement, vous pouvez copier l’ensemble $ rosa login --token=abc…​ commande et coller cela dans le terminal: 

    $ rosa login --token=<abc..>
    Copy to Clipboard Toggle word wrap

  3. Confirmez que vous êtes connecté en utilisant le compte et les informations d’identification corrects: 

    $ rosa whoami
    Copy to Clipboard Toggle word wrap

1.2.3. CLI OpenShift (oc)
Copier lien

Le CLI OpenShift (oc) n’est pas nécessaire pour déployer un service Red Hat OpenShift sur le cluster AWS, mais est un outil utile pour interagir avec votre cluster après son déploiement.

  1. Cliquez ici pour télécharger et installer 'oc' à partir de la page d’outils OpenShift Cluster Manager (CLI), ou suivez les instructions de démarrage avec OpenShift CLI.

  2. Assurez-vous que le CLI OpenShift a été installé correctement en exécutant la commande suivante: 

    $ rosa verify openshift-client
    Copy to Clipboard Toggle word wrap

1.3. Conditions préalables à l’infrastructure AWS
Copier lien

  • En option, assurez-vous que votre compte AWS dispose d’un quota suffisant pour déployer un cluster. 

    $ rosa verify quota
    Copy to Clipboard Toggle word wrap

    Cette commande ne vérifie que le quota total alloué à votre compte; elle ne reflète pas le montant de quota déjà consommé à partir de ce quota. L’exécution de cette commande est facultative car votre quota est vérifié lors du déploiement de clusters. Cependant, Red Hat recommande d’exécuter cette commande pour confirmer votre quota à l’avance afin que le déploiement ne soit pas interrompu par des problèmes de disponibilité des quotas.

  • Afin d’obtenir de plus amples informations sur les ressources mises à disposition lors du déploiement de clusters ROSA, voir Infrastructure AWS provisoire.
  • Afin d’obtenir plus d’informations sur les quotas de service AWS requis, consultez les quotas de service AWS requis.

Les clusters ROSA sont hébergés dans un compte AWS au sein d’une unité organisationnelle AWS. La stratégie de contrôle des services (SCP) est créée et appliquée à l’unité organisationnelle AWS qui gère les services auxquels les sous-comptes AWS sont autorisés à accéder.

  • Assurez-vous que les SCP de votre organisation ne sont pas plus restrictifs que les rôles et les politiques requis par le cluster. Consultez l’ensemble minimum d’autorisations efficaces pour les SCP.
  • Lorsque vous créez un cluster ROSA, un fournisseur d’identité AWS OpenID Connect (OIDC) associé est créé.

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

Conditions préalables nécessaires du point de vue de la mise en réseau.

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.

1.5.2. Le pare-feu
Copier lien

  • Configurez votre pare-feu pour permettre l’accès aux domaines et ports listés dans les prérequis du pare-feu AWS.

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.

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.

Assurez-vous que les conditions préalables suivantes sont remplies avant d’installer votre cluster.

Les conditions préalables suivantes doivent être remplies avant de déployer un Red Hat OpenShift Service sur AWS (ROSA) cluster qui utilise AWS Security Token Service (STS).

2.1.1. Compte AWS
Copier lien

  • Le compte AWS doit permettre un quota suffisant pour déployer votre cluster.
  • Lorsque votre organisation applique et applique des politiques SCP, ces politiques ne doivent pas être plus restrictives que les rôles et les politiques requis par le cluster.
  • Il est possible de déployer des services AWS natifs dans le même compte AWS.
  • Il doit avoir un rôle lié au service pour permettre au programme d’installation de configurer Elastic Load Balancing (ELB). Consultez « Créer le rôle d’équilibrage de charge élastique (ELB) » pour plus d’informations.

2.1.2. Besoins de soutien
Copier lien

  • Le Red Hat recommande que le client dispose au moins d’un support professionnel d’AWS.
  • Il se peut que Red Hat ait l’autorisation du client de demander un support AWS en son nom.
  • Il se peut que Red Hat ait la permission 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.

2.1.3. Exigences de sécurité
Copier lien

  • 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 une sortie autorisée dans les domaines documentés dans la section "Firewall prérequis".

Les détails de configuration suivants ne sont requis que si vous utilisez OpenShift Cluster Manager pour gérer vos clusters. En utilisant exclusivement les outils CLI, vous pouvez ignorer ces exigences.

2.2.1. Association de compte AWS
Copier lien

Lorsque vous fournissez Red Hat OpenShift Service sur AWS (ROSA) à l’aide d’OpenShift Cluster Manager, vous devez associer les rôles ocm-rôle et utilisateur IAM à votre compte AWS à l’aide de votre nom de ressource Amazon (ARN). Ce processus d’association est également connu sous le nom de lien de compte.

L’ARN ocm-role est stocké sous forme d’étiquette dans votre organisation Red Hat tandis que l’ARN du rôle utilisateur est stocké sous forme d’étiquette à l’intérieur de votre compte utilisateur Red Hat. Le Red Hat utilise ces étiquettes ARN pour confirmer que l’utilisateur est un titulaire de compte valide et que les autorisations correctes sont disponibles pour effectuer des tâches de provisionnement dans le compte AWS.

2.2.2. Associer votre compte AWS aux rôles IAM
Copier lien

Il est possible d’associer ou de lier votre compte AWS aux rôles IAM existants en utilisant le service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.

Conditions préalables

  • Il y a un compte AWS.
  • Les autorisations requises pour installer les rôles AWS à l’échelle du compte sont requises. Consultez les « Ressources supplémentaires » de cette section pour plus d’informations.
  • L’installation et la configuration des derniers CLI AWS (aws) et ROSA (rosa) sur votre hôte d’installation.

  • « vous avez créé les rôles ocm-role et user-role IAM, mais vous ne les avez pas encore liés à votre compte AWS. Il est possible de vérifier si vos rôles IAM sont déjà liés en exécutant les commandes suivantes: 

    $ rosa list ocm-role
    Copy to Clipboard Toggle word wrap 
    $ rosa list user-role
    Copy to Clipboard Toggle word wrap

    Lorsque Oui est affiché dans la colonne Linked pour les deux rôles, vous avez déjà lié les rôles à un compte AWS.

Procédure

  1. À partir du CLI, liez votre ressource ocm-role à votre organisation Red Hat en utilisant votre nom de ressource Amazon (ARN):

    Note

    Il faut avoir les privilèges d’administrateur de l’organisation Red Hat pour exécuter la commande rosa link. Après avoir lié la ressource ocm-role à votre compte AWS, elle est visible pour tous les utilisateurs de l’organisation. 

    $ rosa link ocm-role --role-arn <arn>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    I: Linking OCM role
? Link the '<AWS ACCOUNT ID>` role with organization '<ORG ID>'? Yes
I: Successfully linked role-arn '<AWS ACCOUNT ID>' with organization account '<ORG ID>'
    Copy to Clipboard Toggle word wrap

  2. À partir du CLI, liez votre ressource de rôle utilisateur à votre compte d’utilisateur Red Hat en utilisant votre nom de ressource Amazon (ARN): 

    $ rosa link user-role --role-arn <arn>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    I: Linking User role
? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' role with organization '<AWS ID>'? Yes
I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' with organization account '<AWS ID>'
    Copy to Clipboard Toggle word wrap

Ressources supplémentaires

  • Consultez le rôle de l’IAM à l’échelle du compte et la référence des politiques pour une liste des rôles IAM nécessaires à la création de clusters.

Il est possible d’associer plusieurs comptes AWS à votre organisation Red Hat. L’association de plusieurs comptes vous permet de créer des clusters Red Hat OpenShift Service sur AWS (ROSA) sur l’un des comptes AWS associés de votre organisation Red Hat.

Avec cette fonctionnalité, vous pouvez créer des clusters dans différentes régions AWS en utilisant plusieurs profils AWS en tant qu’environnements liés à la région.

Conditions préalables

  • Il y a un compte AWS.
  • Il est possible d’utiliser OpenShift Cluster Manager pour créer des clusters.
  • Les autorisations requises pour installer les rôles AWS à l’échelle du compte sont requises.
  • L’installation et la configuration des derniers CLI AWS (aws) et ROSA (rosa) sur votre hôte d’installation.
  • C’est vous qui avez créé vos rôles Ocm-role et user-role IAM.

Procédure

Afin d’associer un compte AWS supplémentaire, créez d’abord un profil dans votre configuration AWS locale. Ensuite, associez le compte à votre organisation Red Hat en créant les rôles ocm-rôle, utilisateur et compte dans le compte AWS supplémentaire.

Afin de créer les rôles dans une région supplémentaire, spécifiez le paramètre --profile &lt;aws-profile&gt; lors de l’exécution de la rosa créer des commandes et remplacer &lt;aws_profile&gt; par le nom de profil de compte supplémentaire:

  • De spécifier un profil de compte AWS lors de la création d’un rôle OpenShift Cluster Manager: 

    $ rosa create --profile <aws_profile> ocm-role
    Copy to Clipboard Toggle word wrap

  • De spécifier un profil de compte AWS lors de la création d’un rôle utilisateur: 

    $ rosa create --profile <aws_profile> user-role
    Copy to Clipboard Toggle word wrap

  • De spécifier un profil de compte AWS lors de la création des rôles de compte: 

    $ rosa create --profile <aws_profile> account-roles
    Copy to Clipboard Toggle word wrap
Note

Dans le cas où vous ne spécifiez pas un profil, le profil AWS par défaut est utilisé.

La région d’opt-in AWS est une région qui n’est pas activée par défaut. Dans le cas où vous souhaitez déployer un Red Hat OpenShift Service sur AWS (ROSA) qui utilise AWS Security Token Service (STS) dans une région d’opt-in, vous devez répondre aux exigences suivantes:

  • La région doit être activée dans votre compte AWS. Consultez Gérer les régions AWS dans la documentation AWS pour plus d’informations sur l’activation des régions opt-in.

  • La version jeton de sécurité de votre compte AWS doit être définie sur la version 2. Il est impossible d’utiliser des jetons de sécurité version 1 pour les régions opt-in.

    Important

    La mise à jour du jeton de sécurité version 2 peut avoir un impact sur les systèmes qui stockent les jetons, en raison de la longueur accrue du jeton. Consultez la documentation AWS pour plus d’informations sur la définition des préférences STS.

2.3.1. Configuration de la version de jeton de sécurité AWS
Copier lien

Lorsque vous souhaitez créer un cluster Red Hat OpenShift Service sur AWS (ROSA) avec AWS Security Token Service (STS) dans une région d’opt-in AWS, vous devez définir la version jeton de sécurité sur la version 2 de votre compte AWS.

Conditions préalables

  • L’installation et la configuration du dernier CLI AWS sur votre hôte d’installation.

Procédure

  1. Énumérez l’ID du compte AWS qui est défini dans votre configuration AWS CLI: 

    $ aws sts get-caller-identity --query Account --output json
    Copy to Clipboard Toggle word wrap

    Assurez-vous que la sortie correspond à l’ID du compte AWS pertinent.

  2. Énumérez la version de jeton de sécurité qui est définie dans votre compte AWS: 

    $ aws iam get-account-summary --query SummaryMap.GlobalEndpointTokenVersion --output json
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    1
    Copy to Clipboard Toggle word wrap

  3. Afin de mettre à jour la version jeton de sécurité vers la version 2 pour toutes les régions de votre compte AWS, exécutez la commande suivante: 

    $ aws iam set-security-token-service-preferences --global-endpoint-token-version v2Token
    Copy to Clipboard Toggle word wrap
    Important

    La mise à jour du jeton de sécurité version 2 peut avoir un impact sur les systèmes qui stockent les jetons, en raison de la longueur accrue du jeton. Consultez la documentation AWS pour plus d’informations sur la définition des préférences STS.

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

Lorsque vous utilisez STS comme méthode d’identification de cluster, Red Hat n’est pas responsable de la création et de la gestion des politiques IAM d’Amazon Web Services (AWS), des utilisateurs IAM ou des rôles IAM. Afin d’obtenir de l’information sur la création de ces rôles et politiques, voir les sections suivantes sur les rôles de l’IAM.

  • Afin d’utiliser le CLI ocm, vous devez disposer d’une ressource ocm-role et user-role. Consultez les ressources du rôle de gestionnaire de cluster OpenShift.
  • Dans le cas où vous disposez d’un seul cluster, consultez le rôle et la référence des politiques dans l’ensemble du compte.
  • Chaque cluster doit avoir les rôles d’opérateur nécessaires. Consultez la référence du rôle de l’opérateur IAM.

2.5. 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é.

2.5.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.

2.5.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.

2.5.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.

2.5.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.

2.5.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 2.1. Exemple d’architecture VPC

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

2.5.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 2.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

2.5.6.1. Groupes de sécurité personnalisés supplémentaires
Copier lien

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.

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

2.6.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.

2.7. Les prochaines étapes
Copier lien

Chapitre 3. Les ressources du rôle de ROSA IAM
Copier lien

Il faut créer plusieurs ressources de rôles sur votre compte AWS afin de créer et de gérer un cluster Red Hat OpenShift Service sur AWS (ROSA).

3.1. Aperçu des rôles requis
Copier lien

Afin de créer et de gérer votre service Red Hat OpenShift sur le cluster AWS, vous devez créer plusieurs rôles à l’échelle du compte et à l’échelle du cluster. Lorsque vous avez l’intention d’utiliser OpenShift Cluster Manager pour créer ou gérer votre cluster, vous avez besoin de rôles supplémentaires.

Créer et gérer des clusters

Il faut plusieurs rôles à l’échelle du compte pour créer et gérer des clusters ROSA. Ces rôles ne doivent être créés qu’une fois par compte AWS et n’ont pas besoin d’être créés frais pour chaque cluster. Il est possible de spécifier votre propre préfixe ou d’utiliser le préfixe par défaut (ManagedOpenShift).

Les rôles suivants à l’échelle du compte sont requis:

  • &lt;prefix&gt;-Role du travailleur
  • &lt;préfixe&gt;-Soutien-Role
  • &lt;prefix&gt;-Installer-Role
  • &lt;prefix&gt;-ControlPlane-Role
Note

La création de rôles ne demande pas votre accès AWS ou vos clés secrètes. AWS Security Token Service (STS) est utilisé comme base de ce flux de travail. AWS STS utilise des informations d’identification temporaires et à privilèges limités pour fournir l’authentification.

Gérer les fonctionnalités de cluster fournies par les opérateurs

Les rôles d’opérateur spécifiques au cluster (rôles d’opérateur dans l’ILC ROSA), obtenir les autorisations temporaires requises pour effectuer des opérations de cluster pour les fonctionnalités fournies par les opérateurs, telles que la gestion du stockage back-end, l’entrée et le registre. Cela nécessite la configuration d’un fournisseur OpenID Connect (OIDC), qui se connecte à AWS Security Token Service (STS) pour authentifier l’accès de l’opérateur aux ressources AWS.

Les rôles d’opérateur sont requis pour chaque cluster, car plusieurs opérateurs sont utilisés pour fournir des fonctionnalités de cluster par défaut.

Les rôles d’opérateur suivants sont requis:

  • &lt;cluster_name&gt;-&lt;hash&gt;-openshift-cluster-csi-drivers-ebs-cloud-credentials
  • &lt;cluster_name&gt;-&lt;hash&gt;-openshift-cloud-network-config-controller-credentials
  • &lt;cluster_name&gt;-&lt;hash&gt;-openshift-machine-api-aws-cloud-credentials
  • &lt;cluster_name&gt;-&lt;hash&gt;-openshift-cloud-credential-operator-cloud-credentials
  • &lt;cluster_name&gt;-&lt;hash&gt;-openshift-image-registry-installer-cloud-credentials
  • &lt;cluster_name&gt;-&lt;hash&gt;-openshift-ingress-operator-cloud-credentials
À utiliser OpenShift Cluster Manager

L’interface utilisateur Web, OpenShift Cluster Manager, vous oblige à créer des rôles supplémentaires dans votre compte AWS pour créer une relation de confiance entre ce compte AWS et le gestionnaire de cluster OpenShift.

Cette relation de confiance est obtenue grâce à la création et à l’association du rôle d’Ocm-role AWS IAM. Ce rôle a une politique de confiance avec l’installateur AWS qui relie votre compte Red Hat à votre compte AWS. En outre, vous avez également besoin d’un rôle AWS IAM d’utilisateur pour chaque utilisateur d’interface utilisateur Web, qui sert à identifier ces utilisateurs. Ce rôle AWS IAM de rôle utilisateur n’a pas d’autorisations.

Les rôles AWS IAM suivants sont nécessaires pour utiliser OpenShift Cluster Manager:

  • le rôle de l’OCM
  • le rôle de l’utilisateur

Ressources supplémentaires

3.2. À propos de la ressource ocm-role IAM
Copier lien

Il faut créer la ressource Ocm-role IAM pour permettre à une organisation Red Hat d’utilisateurs de créer des clusters Red Hat OpenShift Service sur AWS (ROSA). Dans le cadre de la connexion à AWS, une organisation Red Hat est un utilisateur unique au sein d’OpenShift Cluster Manager.

Certaines considérations pour votre ressource Ocm-role IAM sont:

  • Il n’y a qu’un seul rôle IAM ocm-role par organisation Red Hat; cependant, vous pouvez avoir n’importe quel nombre de rôles IAM ocm-role par compte AWS. L’interface utilisateur Web exige qu’un seul de ces rôles puisse être lié à la fois.
  • Chaque utilisateur d’une organisation Red Hat peut créer et lier une ressource Ocm-role IAM.

  • Il n’y a que l’administrateur de l’organisation Red Hat qui peut déconnecter une ressource IAM ocm-role. Cette limitation vise à protéger les autres membres de l’organisation Red Hat contre la perturbation des capacités d’interface des autres utilisateurs.

    Note

    Lorsque vous venez de créer un compte Red Hat qui ne fait pas partie d’une organisation existante, ce compte est également l’administrateur de l’organisation Red Hat.

  • Consultez « Comprendre le rôle de gestionnaire de cluster OpenShift » dans les ressources supplémentaires de cette section pour une liste des politiques d’autorisation AWS pour les ressources de base et admin ocm-rôle IAM.

En utilisant le ROSA CLI (rosa), vous pouvez lier votre ressource IAM lorsque vous la créez.

Note

« Lier » ou « associer » vos ressources IAM à votre compte AWS signifie créer une politique de confiance avec votre rôle IAM ocm et le rôle AWS Red Hat OpenShift Cluster Manager. Après avoir créé et lié votre ressource IAM, vous voyez une relation de confiance à partir de votre ressource Ocm-role IAM dans AWS avec la ressource arn:aws:iam::7333:role/RH-Managed-OpenShift-Installer.

Après qu’un administrateur d’organisation Red Hat ait créé et lié une ressource Ocm-role IAM, tous les membres de l’organisation peuvent vouloir créer et relier leur propre rôle IAM à rôle utilisateur. Cette ressource IAM n’a besoin d’être créée et liée qu’une seule fois par utilisateur. « si un autre utilisateur de votre organisation Red Hat a déjà créé et lié une ressource IAM ocm-role, vous devez vous assurer que vous avez créé et lié votre propre rôle IAM de rôle utilisateur.

Ressources supplémentaires

3.2.1. Création d’un rôle Ocm-role IAM
Copier lien

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
    Copy to Clipboard Toggle word wrap

  • 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
    Copy to Clipboard Toggle word wrap

    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

I: Creating ocm role
? Role prefix: ManagedOpenShift
1 

? Enable admin capabilities for the OCM role (optional): No
2 

? Permissions boundary ARN (optional):
3 

? Role Path (optional):
4 

? Role creation mode: auto
5 

I: Creating role using 'arn:aws:iam::<ARN>:user/<UserName>'
? Create the 'ManagedOpenShift-OCM-Role-182' role? Yes
6 

I: Created role 'ManagedOpenShift-OCM-Role-182' with ARN  'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182'
I: Linking OCM role
? OCM Role ARN: arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182
7 

? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' role with organization '<AWS ARN>'? Yes
8 

I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' with organization account '<AWS ARN>'
Copy to Clipboard Toggle word wrap

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.

3.3. À propos du rôle utilisateur-rôle IAM
Copier lien

Il faut créer un rôle IAM de rôle utilisateur par utilisateur utilisateur pour permettre à ces utilisateurs de créer des clusters ROSA.

Certaines considérations pour votre rôle d’utilisateur IAM sont:

  • Il vous suffit d’un rôle IAM de rôle utilisateur par compte d’utilisateur Red Hat, mais votre organisation Red Hat peut avoir beaucoup de ces ressources IAM.
  • Chaque utilisateur d’une organisation Red Hat peut créer et lier un rôle IAM à rôle utilisateur.
  • Il peut y avoir de nombreux rôles IAM de rôle utilisateur par compte AWS par organisation Red Hat.
  • Le Red Hat utilise le rôle IAM de rôle utilisateur pour identifier l’utilisateur. Cette ressource IAM n’a pas d’autorisation de compte AWS.
  • Le compte AWS peut avoir plusieurs rôles IAM à rôle utilisateur, mais vous devez lier chaque rôle IAM à chaque utilisateur de votre organisation Red Hat. Aucun utilisateur ne peut avoir plus d’un rôle IAM de rôle utilisateur lié.
Note

« Lier » ou « associer » vos ressources IAM à votre compte AWS signifie créer une politique de confiance avec votre rôle IAM de rôle utilisateur et le rôle AWS Red Hat OpenShift Cluster Manager. Après avoir créé et lié cette ressource IAM, vous voyez une relation de confiance de votre rôle IAM utilisateur dans AWS avec la ressource arn:aws:iam::710019948333:role/RH-Managed-OpenShift-Installer.

3.3.1. Création d’un rôle IAM de rôle utilisateur
Copier lien

Il est possible de créer vos rôles IAM à l’aide de l’interface ligne de commande (CLI).

Conditions préalables

  • Il y a un compte 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 un rôle IAM de rôle utilisateur avec des privilèges de base, exécutez la commande suivante: 

    $ rosa create user-role
    Copy to Clipboard Toggle word wrap

    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 « Comprendre les modes de déploiement automatique et manuel » pour plus d’informations.

Exemple de sortie

I: Creating User role
? Role prefix: ManagedOpenShift
1 

? Permissions boundary ARN (optional):
2 

? Role Path (optional):
3 

? Role creation mode: auto
4 

I: Creating ocm user role using 'arn:aws:iam::2066:user'
? Create the 'ManagedOpenShift-User.osdocs-Role' role? Yes
5 

I: Created role 'ManagedOpenShift-User.osdocs-Role' with ARN 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role'
I: Linking User role
? User Role ARN: arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role
? Link the 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role' role with account '1AGE'? Yes
6 

I: Successfully linked role ARN 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role' with account '1AGE'
Copy to Clipboard Toggle word wrap

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
Le nom de ressource Amazon (ARN) de la politique pour définir les limites d’autorisation.
3
Indiquez un chemin IAM pour le nom d’utilisateur.
4
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.
5
La méthode automatique vous demande si vous souhaitez créer un rôle utilisateur spécifique en utilisant votre préfixe.
6
Relie le rôle créé à votre organisation AWS.
Important

Lorsque vous déconnectez ou supprimez votre rôle IAM de rôle utilisateur avant de supprimer votre cluster, une erreur vous empêche de supprimer votre cluster. Il faut créer ou reconnecter ce rôle pour procéder au processus de suppression. Consultez Réparation d’un cluster qui ne peut pas être supprimé pour plus d’informations.

3.4. Association de compte AWS
Copier lien

Lorsque vous fournissez Red Hat OpenShift Service sur AWS (ROSA) à l’aide d’OpenShift Cluster Manager, vous devez associer les rôles ocm-rôle et utilisateur IAM à votre compte AWS à l’aide de votre nom de ressource Amazon (ARN). Ce processus d’association est également connu sous le nom de lien de compte.

L’ARN ocm-role est stocké sous forme d’étiquette dans votre organisation Red Hat tandis que l’ARN du rôle utilisateur est stocké sous forme d’étiquette à l’intérieur de votre compte utilisateur Red Hat. Le Red Hat utilise ces étiquettes ARN pour confirmer que l’utilisateur est un titulaire de compte valide et que les autorisations correctes sont disponibles pour effectuer des tâches de provisionnement dans le compte AWS.

3.4.1. Associer votre compte AWS aux rôles IAM
Copier lien

Il est possible d’associer ou de lier votre compte AWS aux rôles IAM existants en utilisant le service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.

Conditions préalables

  • Il y a un compte AWS.
  • Les autorisations requises pour installer les rôles AWS à l’échelle du compte sont requises. Consultez les « Ressources supplémentaires » de cette section pour plus d’informations.
  • L’installation et la configuration des derniers CLI AWS (aws) et ROSA (rosa) sur votre hôte d’installation.

  • « vous avez créé les rôles ocm-role et user-role IAM, mais vous ne les avez pas encore liés à votre compte AWS. Il est possible de vérifier si vos rôles IAM sont déjà liés en exécutant les commandes suivantes: 

    $ rosa list ocm-role
    Copy to Clipboard Toggle word wrap 
    $ rosa list user-role
    Copy to Clipboard Toggle word wrap

    Lorsque Oui est affiché dans la colonne Linked pour les deux rôles, vous avez déjà lié les rôles à un compte AWS.

Procédure

  1. À partir du CLI, liez votre ressource ocm-role à votre organisation Red Hat en utilisant votre nom de ressource Amazon (ARN):

    Note

    Il faut avoir les privilèges d’administrateur de l’organisation Red Hat pour exécuter la commande rosa link. Après avoir lié la ressource ocm-role à votre compte AWS, elle est visible pour tous les utilisateurs de l’organisation. 

    $ rosa link ocm-role --role-arn <arn>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    I: Linking OCM role
? Link the '<AWS ACCOUNT ID>` role with organization '<ORG ID>'? Yes
I: Successfully linked role-arn '<AWS ACCOUNT ID>' with organization account '<ORG ID>'
    Copy to Clipboard Toggle word wrap

  2. À partir du CLI, liez votre ressource de rôle utilisateur à votre compte d’utilisateur Red Hat en utilisant votre nom de ressource Amazon (ARN): 

    $ rosa link user-role --role-arn <arn>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    I: Linking User role
? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' role with organization '<AWS ID>'? Yes
I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' with organization account '<AWS ID>'
    Copy to Clipboard Toggle word wrap

Il est possible d’associer plusieurs comptes AWS à votre organisation Red Hat. L’association de plusieurs comptes vous permet de créer des clusters Red Hat OpenShift Service sur AWS (ROSA) sur l’un des comptes AWS associés de votre organisation Red Hat.

Avec cette fonctionnalité, vous pouvez créer des clusters dans différentes régions AWS en utilisant plusieurs profils AWS en tant qu’environnements liés à la région.

Conditions préalables

  • Il y a un compte AWS.
  • Il est possible d’utiliser OpenShift Cluster Manager pour créer des clusters.
  • Les autorisations requises pour installer les rôles AWS à l’échelle du compte sont requises.
  • L’installation et la configuration des derniers CLI AWS (aws) et ROSA (rosa) sur votre hôte d’installation.
  • C’est vous qui avez créé vos rôles Ocm-role et user-role IAM.

Procédure

Afin d’associer un compte AWS supplémentaire, créez d’abord un profil dans votre configuration AWS locale. Ensuite, associez le compte à votre organisation Red Hat en créant les rôles ocm-rôle, utilisateur et compte dans le compte AWS supplémentaire.

Afin de créer les rôles dans une région supplémentaire, spécifiez le paramètre --profile &lt;aws-profile&gt; lors de l’exécution de la rosa créer des commandes et remplacer &lt;aws_profile&gt; par le nom de profil de compte supplémentaire:

  • De spécifier un profil de compte AWS lors de la création d’un rôle OpenShift Cluster Manager: 

    $ rosa create --profile <aws_profile> ocm-role
    Copy to Clipboard Toggle word wrap

  • De spécifier un profil de compte AWS lors de la création d’un rôle utilisateur: 

    $ rosa create --profile <aws_profile> user-role
    Copy to Clipboard Toggle word wrap

  • De spécifier un profil de compte AWS lors de la création des rôles de compte: 

    $ rosa create --profile <aws_profile> account-roles
    Copy to Clipboard Toggle word wrap
Note

Dans le cas où vous ne spécifiez pas un profil, le profil AWS par défaut est utilisé.

3.5. Limites d’autorisation pour le rôle d’installateur
Copier lien

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.

Note

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.1. accueil &gt; Sts_installer_core_permission_border_policy.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
		    "autoscaling:DescribeAutoScalingGroups",
		    "ec2:AllocateAddress",
		    "ec2:AssociateAddress",
		    "ec2:AttachNetworkInterface",
		    "ec2:AuthorizeSecurityGroupEgress",
		    "ec2:AuthorizeSecurityGroupIngress",
		    "ec2:CopyImage",
		    "ec2:CreateNetworkInterface",
		    "ec2:CreateSecurityGroup",
		    "ec2:CreateTags",
		    "ec2:CreateVolume",
		    "ec2:DeleteNetworkInterface",
		    "ec2:DeleteSecurityGroup",
		    "ec2:DeleteSnapshot",
		    "ec2:DeleteTags",
		    "ec2:DeleteVolume",
		    "ec2:DeregisterImage",
		    "ec2:DescribeAccountAttributes",
		    "ec2:DescribeAddresses",
		    "ec2:DescribeAvailabilityZones",
		    "ec2:DescribeDhcpOptions",
		    "ec2:DescribeImages",
		    "ec2:DescribeInstanceAttribute",
		    "ec2:DescribeInstanceCreditSpecifications",
		    "ec2:DescribeInstances",
		    "ec2:DescribeInstanceStatus",
		    "ec2:DescribeInstanceTypeOfferings",
		    "ec2:DescribeInstanceTypes",
		    "ec2:DescribeInternetGateways",
		    "ec2:DescribeKeyPairs",
		    "ec2:DescribeNatGateways",
		    "ec2:DescribeNetworkAcls",
		    "ec2:DescribeNetworkInterfaces",
		    "ec2:DescribePrefixLists",
		    "ec2:DescribeRegions",
		    "ec2:DescribeReservedInstancesOfferings",
		    "ec2:DescribeRouteTables",
		    "ec2:DescribeSecurityGroups",
		    "ec2:DescribeSecurityGroupRules",
		    "ec2:DescribeSubnets",
		    "ec2:DescribeTags",
		    "ec2:DescribeVolumes",
		    "ec2:DescribeVpcAttribute",
		    "ec2:DescribeVpcClassicLink",
		    "ec2:DescribeVpcClassicLinkDnsSupport",
		    "ec2:DescribeVpcEndpoints",
		    "ec2:DescribeVpcs",
		    "ec2:GetConsoleOutput",
		    "ec2:GetEbsDefaultKmsKeyId",
		    "ec2:ModifyInstanceAttribute",
		    "ec2:ModifyNetworkInterfaceAttribute",
		    "ec2:ReleaseAddress",
		    "ec2:RevokeSecurityGroupEgress",
		    "ec2:RevokeSecurityGroupIngress",
		    "ec2:RunInstances",
		    "ec2:StartInstances",
		    "ec2:StopInstances",
		    "ec2:TerminateInstances",
		    "elasticloadbalancing:AddTags",
		    "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
		    "elasticloadbalancing:AttachLoadBalancerToSubnets",
		    "elasticloadbalancing:ConfigureHealthCheck",
		    "elasticloadbalancing:CreateListener",
		    "elasticloadbalancing:CreateLoadBalancer",
		    "elasticloadbalancing:CreateLoadBalancerListeners",
		    "elasticloadbalancing:CreateTargetGroup",
		    "elasticloadbalancing:DeleteLoadBalancer",
		    "elasticloadbalancing:DeleteTargetGroup",
		    "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
		    "elasticloadbalancing:DeregisterTargets",
		    "elasticloadbalancing:DescribeInstanceHealth",
		    "elasticloadbalancing:DescribeListeners",
		    "elasticloadbalancing:DescribeLoadBalancerAttributes",
		    "elasticloadbalancing:DescribeLoadBalancers",
		    "elasticloadbalancing:DescribeTags",
		    "elasticloadbalancing:DescribeTargetGroupAttributes",
		    "elasticloadbalancing:DescribeTargetGroups",
		    "elasticloadbalancing:DescribeTargetHealth",
		    "elasticloadbalancing:ModifyLoadBalancerAttributes",
		    "elasticloadbalancing:ModifyTargetGroup",
		    "elasticloadbalancing:ModifyTargetGroupAttributes",
		    "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
		    "elasticloadbalancing:RegisterTargets",
		    "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
		    "elasticloadbalancing:SetSecurityGroups",
		    "iam:AddRoleToInstanceProfile",
		    "iam:CreateInstanceProfile",
		    "iam:DeleteInstanceProfile",
		    "iam:GetInstanceProfile",
		    "iam:TagInstanceProfile",
		    "iam:GetRole",
		    "iam:GetRolePolicy",
		    "iam:GetUser",
		    "iam:ListAttachedRolePolicies",
		    "iam:ListInstanceProfiles",
		    "iam:ListInstanceProfilesForRole",
		    "iam:ListRolePolicies",
		    "iam:ListRoles",
		    "iam:ListUserPolicies",
		    "iam:ListUsers",
		    "iam:PassRole",
		    "iam:RemoveRoleFromInstanceProfile",
		    "iam:SimulatePrincipalPolicy",
		    "iam:TagRole",
		    "iam:UntagRole",
		    "route53:ChangeResourceRecordSets",
		    "route53:ChangeTagsForResource",
		    "route53:CreateHostedZone",
		    "route53:DeleteHostedZone",
		    "route53:GetAccountLimit",
		    "route53:GetChange",
		    "route53:GetHostedZone",
		    "route53:ListHostedZones",
		    "route53:ListHostedZonesByName",
		    "route53:ListResourceRecordSets",
		    "route53:ListTagsForResource",
		    "route53:UpdateHostedZoneComment",
		    "s3:CreateBucket",
		    "s3:DeleteBucket",
		    "s3:DeleteObject",
		    "s3:GetAccelerateConfiguration",
		    "s3:GetBucketAcl",
		    "s3:GetBucketCORS",
		    "s3:GetBucketLocation",
		    "s3:GetBucketLogging",
		    "s3:GetBucketObjectLockConfiguration",
		    "s3:GetBucketPolicy",
		    "s3:GetBucketRequestPayment",
		    "s3:GetBucketTagging",
		    "s3:GetBucketVersioning",
		    "s3:GetBucketWebsite",
		    "s3:GetEncryptionConfiguration",
		    "s3:GetLifecycleConfiguration",
		    "s3:GetObject",
		    "s3:GetObjectAcl",
		    "s3:GetObjectTagging",
		    "s3:GetObjectVersion",
		    "s3:GetReplicationConfiguration",
		    "s3:ListBucket",
		    "s3:ListBucketVersions",
		    "s3:PutBucketAcl",
		    "s3:PutBucketPolicy",
		    "s3:PutBucketTagging",
		    "s3:PutEncryptionConfiguration",
		    "s3:PutObject",
		    "s3:PutObjectAcl",
		    "s3:PutObjectTagging",
		    "servicequotas:GetServiceQuota",
		    "servicequotas:ListAWSDefaultServiceQuotas",
		    "sts:AssumeRole",
		    "sts:AssumeRoleWithWebIdentity",
		    "sts:GetCallerIdentity",
		    "tag:GetResources",
		    "tag:UntagResources",
		    "kms:DescribeKey",
		    "cloudwatch:GetMetricData",
		    "ec2:CreateRoute",
		    "ec2:DeleteRoute",
		    "ec2:CreateVpcEndpoint",
		    "ec2:DeleteVpcEndpoints",
		    "ec2:CreateVpcEndpointServiceConfiguration",
		    "ec2:DeleteVpcEndpointServiceConfigurations",
		    "ec2:DescribeVpcEndpointServiceConfigurations",
		    "ec2:DescribeVpcEndpointServicePermissions",
		    "ec2:DescribeVpcEndpointServices",
		    "ec2:ModifyVpcEndpointServicePermissions"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/red-hat-managed": "true"
                }
            }
        }
    ]
}
Copy to Clipboard Toggle word wrap
Important

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

  1. 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
    Copy to Clipboard Toggle word wrap

  2. 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"
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    {
    "Policy": {
        "PolicyName": "rosa-core-permissions-boundary-policy",
        "PolicyId": "<Policy ID>",
        "Arn": "arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy",
        "Path": "/",
        "DefaultVersionId": "v1",
        "AttachmentCount": 0,
        "PermissionsBoundaryUsageCount": 0,
        "IsAttachable": true,
        "CreateDate": "<CreateDate>",
        "UpdateDate": "<UpdateDate>"
    }
}
    Copy to Clipboard Toggle word wrap

  3. 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
    Copy to Clipboard Toggle word wrap

  4. 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
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    PERMISSIONSBOUNDARY	arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy	Policy
    Copy to Clipboard Toggle word wrap

    D’autres exemples de politiques de limites d’autorisation PL et VPC voir:

    Exemple 3.2. sts_installer_ privatelink_permission_border_policy.json

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:ModifyVpcEndpointServiceConfiguration",
        "route53:ListHostedZonesByVPC",
        "route53:CreateVPCAssociationAuthorization",
        "route53:AssociateVPCWithHostedZone",
        "route53:DeleteVPCAssociationAuthorization",
        "route53:DisassociateVPCFromHostedZone",
        "route53:ChangeResourceRecordSets"
      ],
      "Resource": "*"
    }
  ]
}
    Copy to Clipboard Toggle word wrap

    Exemple 3.3. accueil &gt; Sts_installer_vpc_permission_border_policy.json

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
		    "ec2:AssociateDhcpOptions",
		    "ec2:AssociateRouteTable",
		    "ec2:AttachInternetGateway",
		    "ec2:CreateDhcpOptions",
		    "ec2:CreateInternetGateway",
		    "ec2:CreateNatGateway",
		    "ec2:CreateRouteTable",
		    "ec2:CreateSubnet",
		    "ec2:CreateVpc",
		    "ec2:DeleteDhcpOptions",
		    "ec2:DeleteInternetGateway",
		    "ec2:DeleteNatGateway",
		    "ec2:DeleteRouteTable",
		    "ec2:DeleteSubnet",
		    "ec2:DeleteVpc",
		    "ec2:DetachInternetGateway",
		    "ec2:DisassociateRouteTable",
		    "ec2:ModifySubnetAttribute",
		    "ec2:ModifyVpcAttribute",
		    "ec2:ReplaceRouteTableAssociation"
            ],
            "Resource": "*"
        }
    ]
}
    Copy to Clipboard Toggle word wrap

Chapitre 4. Limites et évolutivité
Copier lien

Ce document détaille les maximums de cluster testés pour Red Hat OpenShift Service sur les clusters AWS (ROSA), ainsi que des informations sur l’environnement de test et la configuration utilisée pour tester les maximums. Des informations sur le dimensionnement et la mise à l’échelle des nœuds de contrôle et d’infrastructure sont également fournies.

4.1. Les maximums de clusters
Copier lien

Considérez les maximums d’objets testés suivants lorsque vous planifiez une installation de cluster Red Hat OpenShift sur AWS (ROSA). Le tableau spécifie les limites maximales pour chaque type testé dans un cluster (ROSA).

Ces lignes directrices sont basées sur un cluster de 249 nœuds de calcul (également connus sous le nom de travailleur) dans une configuration de zone de disponibilité multiple. Dans le cas des groupes plus petits, les maximums sont inférieurs.

Expand
Tableau 4.1. Grappes testées maximales
Le type maximum4.x testé maximum

Le nombre de gousses [1]

25 000

Le nombre de gousses par nœud

250

Le nombre de gousses par noyau

Il n’y a pas de valeur par défaut

Le nombre d’espaces de noms [2]

5 000

Le nombre de gousses par espace de noms [3]

25 000

Le nombre de services [4]

10 000

Le nombre de services par espace de noms

5 000

Le nombre d’extrémités arrière par service

5 000

Le nombre de déploiements par espace de noms [3]

2 000

  1. Le nombre de pods affiché ici est le nombre de dosettes de test. Le nombre réel de pods dépend de la mémoire, du CPU et des besoins de stockage de l’application.
  2. Lorsqu’il y a un grand nombre de projets actifs, etcd peut souffrir d’une mauvaise performance si l’espace clé grandit excessivement et dépasse le quota spatial. L’entretien périodique de etcd, y compris la défragmentation, est fortement recommandé pour rendre le stockage etcd disponible.
  3. Il y a plusieurs boucles de contrôle dans le système qui doivent itérer sur tous les objets dans un espace de noms donné en réaction à certains changements d’état. Avoir un grand nombre d’objets d’un type, dans un seul espace de noms, peut rendre ces boucles coûteuses et ralentir le traitement des changements d’état. La limite suppose que le système a suffisamment de CPU, de mémoire et de disque pour satisfaire les exigences de l’application.
  4. Chaque port de service et chaque service arrière ont une entrée correspondante dans iptables. Le nombre d’extrémités arrière d’un service donné a une incidence sur la taille des objets des points de terminaison, ce qui a ensuite une incidence sur la taille des données envoyées dans tout le système.

Le tableau suivant répertorie l’environnement OpenShift Container Platform et la configuration sur laquelle les maximums de cluster sont testés pour la plate-forme cloud AWS.

Expand
Le nœudLe typeà propos de vCPULa RAM (GiB)Le type de disqueTaille du disque (GiB)/IOPSComptezLa région

Avion de contrôle/etcd [1]

largeur de M5.4xlarge

16

64

Gp3

350 / 1 000

3

à l’ouest-2

Nœuds d’infrastructure [2]

le r5.2xlarge

8

64

Gp3

300 / 900

3

à l’ouest-2

Charge de travail [3]

largeur de M5.2xlarge

8

32

Gp3

350 / 900

3

à l’ouest-2

Calculer les nœuds

largeur de M5.2xlarge

8

32

Gp3

350 / 900

102

à l’ouest-2

  1. les disques io1 sont utilisés pour les nœuds plan/etcd de contrôle dans toutes les versions antérieures au 4.10.
  2. Les nœuds d’infrastructure sont utilisés pour héberger des composants de surveillance, car Prometheus peut revendiquer une grande quantité de mémoire, en fonction des habitudes d’utilisation.
  3. Les nœuds de charge de travail sont dédiés à la performance et à l’évolutivité des générateurs de charge de travail.

Des tailles de grappes plus grandes et des nombres d’objets plus élevés pourraient être accessibles. Cependant, le dimensionnement des nœuds d’infrastructure limite la quantité de mémoire disponible pour Prometheus. Lors de la création, de la modification ou de la suppression d’objets, Prometheus stocke les métriques dans sa mémoire pendant environ 3 heures avant de persister les métriques sur le disque. Lorsque le taux de création, de modification ou de suppression d’objets est trop élevé, Prometheus peut devenir submergé et échouer en raison du manque de ressources mémoire.

Lorsque vous installez un Red Hat OpenShift Service sur AWS (ROSA), le dimensionnement du plan de contrôle et des nœuds d’infrastructure est automatiquement déterminé par le nombre de nœuds de calcul.

Lorsque vous modifiez le nombre de nœuds de calcul dans votre cluster après l’installation, l’équipe Red Hat Site Reliability Engineering (SRE) met à l’échelle le plan de contrôle et les nœuds d’infrastructure au besoin pour maintenir la stabilité du cluster.

4.3.1. Dimensionnement des nœuds pendant l’installation
Copier lien

Au cours du processus d’installation, le dimensionnement du plan de contrôle et des nœuds d’infrastructure est calculé dynamiquement. Le calcul du dimensionnement est basé sur le nombre de nœuds de calcul dans un cluster.

Le tableau suivant répertorie le dimensionnement du plan de contrôle et des nœuds d’infrastructure qui est appliqué pendant l’installation.

Expand
Le nombre de nœuds de calculContrôle de la taille du planDimension du nœud d’infrastructure

1 à 25

largeur de M5.2xlarge

le r5.xlarge

26 à 100

largeur de M5.4xlarge

le r5.2xlarge

101 à 249

largeur de M5.8xlarge

largeur de r5.4xlarge

Note

Le nombre maximum de nœuds de calcul sur les clusters ROSA version 4.14.14 et ultérieure est de 249. Dans les versions précédentes, la limite est de 180.

Lorsque vous modifiez le nombre de nœuds de calcul après l’installation, le plan de contrôle et les nœuds d’infrastructure sont mis à l’échelle par l’équipe de Red Hat Site Reliability Engineering (SRE) au besoin. Les nœuds sont mis à l’échelle pour maintenir la stabilité de la plate-forme.

Les besoins de mise à l’échelle après l’installation pour les nœuds des plans de contrôle et de l’infrastructure sont évalués au cas par cas. La consommation des ressources des nœuds et les alertes reçues sont prises en considération.

Les règles pour les alertes de redimensionnement des nœuds d’avion de contrôle

L’alerte de redimensionnement est déclenchée pour les nœuds de plan de contrôle dans un cluster lorsque ce qui suit se produit:

  • Les nœuds de plan de contrôle maintiennent une utilisation moyenne de plus de 66% dans un cluster.

    Note

    Le nombre maximum de nœuds de calcul sur ROSA est de 180.

Les règles pour les alertes de redimensionnement des nœuds d’infrastructure

Les alertes de redimensionnement sont déclenchées pour les nœuds d’infrastructure d’un cluster lorsqu’il a une utilisation CPU ou mémoire hautement soutenue. Ce statut d’utilisation durable élevé est:

  • Les nœuds d’infrastructure permettent une utilisation moyenne de plus de 50 % dans un cluster avec une seule zone de disponibilité à l’aide de 2 nœuds d’infrastructure.

  • Les nœuds d’infrastructure permettent une utilisation moyenne de plus de 66% dans un cluster avec plusieurs zones de disponibilité à l’aide de 3 nœuds d’infrastructure.

    Note

    Le nombre maximal de nœuds de calcul sur les versions 4.14.14 et ultérieures du cluster ROSA est de 249. Dans les versions précédentes, la limite est de 180.

    Les alertes de redimensionnement n’apparaissent qu’après des périodes prolongées d’utilisation élevée. Les pics d’utilisation courts, tels qu’un nœud qui descend temporairement, provoquant l’augmentation de l’autre nœud, ne déclenchent pas ces alertes.

L’équipe SRE pourrait mettre à l’échelle le plan de contrôle et les nœuds d’infrastructure pour des raisons supplémentaires, par exemple pour gérer une augmentation de la consommation de ressources sur les nœuds.

Lorsque la mise à l’échelle est appliquée, le client est informé par l’intermédiaire d’une entrée de journal de service. En savoir plus sur le journal des services, voir Accès aux journaux de services pour les clusters ROSA.

Dans le cas des grands groupes, le dimensionnement des nœuds d’infrastructure peut devenir un facteur important d’impact de l’évolutivité. Il existe de nombreux facteurs qui influencent les seuils indiqués, y compris la version etcd ou le format de données de stockage.

Dépasser ces limites ne signifie pas nécessairement que le cluster échouera. Dans la plupart des cas, le dépassement de ces chiffres entraîne une performance globale plus faible.

4.4. Les prochaines étapes
Copier lien

Chapitre 5. La ROSA avec les limites HCP et l’évolutivité
Copier lien

Ce document détaille les maximums de cluster testés pour Red Hat OpenShift Service sur AWS (ROSA) avec des clusters de plans de contrôle hébergés (HCP), ainsi que des informations sur l’environnement de test et la configuration utilisée pour tester les maximums. Dans le cas de ROSA avec des clusters HCP, le plan de contrôle est entièrement géré dans le compte AWS de service et sera automatiquement mis à l’échelle avec le cluster.

5.1. Le ROSA avec les maximums de cluster HCP
Copier lien

Considérez les maximums d’objets testés suivants lorsque vous planifiez un service OpenShift Red Hat sur AWS (ROSA) avec l’installation de clusters de plans de contrôle hébergés (HCP). Le tableau spécifie les limites maximales pour chaque type testé dans un ROSA avec cluster HCP.

Ces lignes directrices sont basées sur un groupe de 500 nœuds de calcul (également appelés travailleurs). Dans le cas des groupes plus petits, les maximums sont inférieurs.

Expand
Tableau 5.1. Grappes testées maximales
Le type maximum4.x testé maximum

Le nombre de gousses [1]

25 000

Le nombre de gousses par nœud

250

Le nombre de gousses par noyau

Il n’y a pas de valeur par défaut

Le nombre d’espaces de noms [2]

5 000

Le nombre de gousses par espace de noms [3]

25 000

Le nombre de services [4]

10 000

Le nombre de services par espace de noms

5 000

Le nombre d’extrémités arrière par service

5 000

Le nombre de déploiements par espace de noms [3]

2 000

  1. Le nombre de pods affiché ici est le nombre de dosettes de test. Le nombre réel de pods dépend de la mémoire, du CPU et des besoins de stockage de l’application.
  2. Lorsqu’il y a un grand nombre de projets actifs, etcd peut souffrir d’une mauvaise performance si l’espace clé grandit excessivement et dépasse le quota spatial. L’entretien périodique de etcd, y compris la défragmentation, est fortement recommandé pour rendre le stockage etcd disponible.
  3. Il y a plusieurs boucles de contrôle dans le système qui doivent itérer sur tous les objets dans un espace de noms donné en réaction à certains changements d’état. Avoir un grand nombre d’objets d’un type, dans un seul espace de noms, peut rendre ces boucles coûteuses et ralentir le traitement des changements d’état. La limite suppose que le système a suffisamment de CPU, de mémoire et de disque pour satisfaire les exigences de l’application.
  4. Chaque port de service et chaque service arrière ont une entrée correspondante dans iptables. Le nombre d’extrémités arrière d’un service donné a une incidence sur la taille des objets des points de terminaison, ce qui a ensuite une incidence sur la taille des données envoyées dans tout le système.

5.2. Les prochaines étapes
Copier lien

Ce document décrit comment planifier votre service Red Hat OpenShift sur l’environnement AWS en fonction des maximums de cluster testés.

La sursouscription des ressources physiques sur un nœud affecte les garanties de ressources que le programmeur Kubernetes fait pendant le placement de pod. Apprenez quelles mesures vous pouvez prendre pour éviter l’échange de mémoire.

Certains des maximums testés ne sont étirés que dans une seule dimension. Ils varieront lorsque de nombreux objets s’exécutent sur le cluster.

Les chiffres notés dans cette documentation sont basés sur la méthodologie de test Red Hat, la configuration, la configuration et les réglages. Ces chiffres peuvent varier en fonction de vos propres configurations et environnements individuels.

Lors de la planification de votre environnement, déterminez combien de gousses sont censées s’adapter par nœud en utilisant la formule suivante: 

required pods per cluster / pods per node = total number of nodes needed
Copy to Clipboard Toggle word wrap

Le nombre maximum actuel de gousses par nœud est de 250. Cependant, le nombre de gousses qui s’adaptent à un nœud dépend de l’application elle-même. Considérez les exigences de mémoire, de CPU et de stockage de l’application, telles que décrites dans Planifier votre environnement en fonction des exigences de l’application.

Exemple de scénario

Afin d’étendre votre cluster à 2200 pods par cluster, vous auriez besoin d’au moins neuf nœuds, en supposant qu’il y a 250 pods maximum par nœud: 

2200 / 250 = 8.8
Copy to Clipboard Toggle word wrap

Lorsque vous augmentez le nombre de nœuds à 20, la distribution de la gousse passe à 110 gousses par nœud: 

2200 / 20 = 110
Copy to Clipboard Toggle word wrap

Là où: 

required pods per cluster / total number of nodes = expected pods per node
Copy to Clipboard Toggle word wrap

Ce document décrit comment planifier votre service Red Hat OpenShift sur l’environnement AWS en fonction des exigences de votre application.

Considérez un exemple d’environnement d’application:

Expand
Le type de podLa quantité de gousseLa mémoire MaxCœurs de CPULe stockage persistant

Apache

100

500 MO

0,5

1 GO

à propos de Node.js

200

1 GO

1

1 GO

à propos de PostgreSQL

100

1 GO

2

10 GO

JBoss EAP

100

1 GO

1

1 GO

Exigences extrapolées: 550 cœurs CPU, 450 Go de RAM et 1,4 To de stockage.

La taille de l’instance pour les nœuds peut être modulée vers le haut ou vers le bas, selon vos préférences. Les nœuds sont souvent surengagés par des ressources. Dans ce scénario de déploiement, vous pouvez choisir d’exécuter des nœuds plus petits ou moins grands pour fournir la même quantité de ressources. Des facteurs tels que l’agilité opérationnelle et le coût par instance devraient être pris en considération.

Expand
Le type de nœudLa quantitéCPUsLA RAM (GB)

Nœuds (option 1)

100

4

16

Nœuds (option 2)

50

8

32

Nœuds (option 3)

25

16

64

Certaines applications se prêtent bien à des environnements surengagés, et d’autres ne le font pas. La plupart des applications Java et des applications qui utilisent d’énormes pages sont des exemples d’applications qui ne permettraient pas de surengagement. Cette mémoire ne peut pas être utilisée pour d’autres applications. Dans l’exemple ci-dessus, l’environnement serait d’environ 30 pour cent surengagé, un ratio commun.

Les pods d’applications peuvent accéder à un service en utilisant des variables d’environnement ou DNS. En utilisant des variables d’environnement, pour chaque service actif, les variables sont injectées par le kubelet lorsqu’un pod est exécuté sur un nœud. Le serveur DNS conçu par cluster surveille l’API Kubernetes pour de nouveaux services et crée un ensemble d’enregistrements DNS pour chacun d’entre eux. Lorsque DNS est activé tout au long de votre cluster, tous les pods doivent automatiquement être en mesure de résoudre les services par leur nom DNS. La découverte de service à l’aide de DNS peut être utilisée au cas où vous devez aller au-delà de 5000 services. Lors de l’utilisation de variables d’environnement pour la découverte de service, si la liste d’arguments dépasse la longueur autorisée après 5000 services dans un espace de noms, alors les pods et les déploiements commenceront à échouer.

Désactiver les liens de service dans le fichier de spécification de service du déploiement pour surmonter ceci:

Exemple :

Kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: deploymentConfigTemplate
  creationTimestamp:
  annotations:
    description: This template will create a deploymentConfig with 1 replica, 4 env vars and a service.
    tags: ''
objects:
  - kind: DeploymentConfig
    apiVersion: apps.openshift.io/v1
    metadata:
      name: deploymentconfig${IDENTIFIER}
    spec:
      template:
        metadata:
          labels:
            name: replicationcontroller${IDENTIFIER}
        spec:
          enableServiceLinks: false
          containers:
          - name: pause${IDENTIFIER}
            image: "${IMAGE}"
            ports:
            - containerPort: 8080
              protocol: TCP
            env:
            - name: ENVVAR1_${IDENTIFIER}
              value: "${ENV_VALUE}"
            - name: ENVVAR2_${IDENTIFIER}
              value: "${ENV_VALUE}"
            - name: ENVVAR3_${IDENTIFIER}
              value: "${ENV_VALUE}"
            - name: ENVVAR4_${IDENTIFIER}
              value: "${ENV_VALUE}"
            resources: {}
            imagePullPolicy: IfNotPresent
            capabilities: {}
            securityContext:
              capabilities: {}
              privileged: false
          restartPolicy: Always
          serviceAccount: ''
      replicas: 1
      selector:
        name: replicationcontroller${IDENTIFIER}
      triggers:
      - type: ConfigChange
      strategy:
        type: Rolling
  - kind: Service
    apiVersion: v1
    metadata:
      name: service${IDENTIFIER}
    spec:
      selector:
        name: replicationcontroller${IDENTIFIER}
      ports:
      - name: serviceport${IDENTIFIER}
        protocol: TCP
        port: 80
        targetPort: 8080
      portalIP: ''
      type: ClusterIP
      sessionAffinity: None
    status:
      loadBalancer: {}
  parameters:
  - name: IDENTIFIER
    description: Number to append to the name of resources
    value: '1'
    required: true
  - name: IMAGE
    description: Image to use for deploymentConfig
    value: gcr.io/google-containers/pause-amd64:3.0
    required: false
  - name: ENV_VALUE
    description: Value to use for environment variables
    generate: expression
    from: "[A-Za-z0-9]{255}"
    required: false
  labels:
template: deploymentConfigTemplate
Copy to Clipboard Toggle word wrap

Le nombre de pods d’application pouvant s’exécuter dans un espace de noms dépend du nombre de services et de la longueur du nom de service lorsque les variables d’environnement sont utilisées pour la découverte de service. ARG_MAX sur le système définit la longueur d’argument maximale pour un nouveau processus et il est réglé sur 2097152 octets (2 MiB) par défaut. Le kubelet injecte des variables d’environnement dans chaque pod prévu pour s’exécuter dans l’espace de noms, y compris:

  • &LT;SERVICE_NAME&GT;_SERVICE_HOST=&LT;IP&GT;
  • &LT;SERVICE_NAME&GT;_SERVICE_PORT=&LT;PORT&GT;
  • &Lt;SERVICE_NAME&gt;_PORT=tcp://&lt;IP&gt;:&lt;PORT&gt;
  • &Lt;SERVICE_NAME&gt;_PORT_&lt;PORT&gt;_TCP=tcp://&lt;IP&gt;:&lt;PORT&gt;
  • &Lt;SERVICE_NAME&gt;_PORT_&lt;PORT&gt;_TCP_PROTO=tcp
  • &LT;SERVICE_NAME&GT;_PORT_&LT;PORT&GT;_TCP_PORT=&LT;PORT&GT;
  • &LT;SERVICE_NAME&GT;_PORT_&LT;PORT&GT;_TCP_ADDR=&LT;ADDR&GT;

Les pods dans l’espace de noms commencent à échouer si la longueur de l’argument dépasse la valeur autorisée et si le nombre de caractères d’un nom de service l’affecte.

Chapitre 7. Quotas de service AWS requis
Copier lien

Consultez cette liste des quotas de service Amazon Web Service (AWS) requis pour exécuter un service Red Hat OpenShift sur AWS cluster.

7.1. Quotas de service AWS requis
Copier lien

Le tableau ci-dessous décrit les quotas de service AWS et les niveaux requis pour créer et exécuter un service Red Hat OpenShift sur le cluster AWS. Bien que la plupart des valeurs par défaut conviennent à la plupart des charges de travail, vous devrez peut-être demander un quota supplémentaire pour les cas suivants:

  • Les clusters ROSA nécessitent un quota minimum de service AWS EC2 de 100 vCPU pour assurer la création, la disponibilité et les mises à niveau de clusters. La valeur maximale par défaut pour les vCPU assignés aux instances Amazon EC2 d’exécution à la demande standard est 5. Donc, si vous n’avez pas créé un cluster ROSA en utilisant le même compte AWS précédemment, vous devez demander un quota EC2 supplémentaire pour les instances de Running On-Demand Standard (A, C, D, H, I, M, R, T, Z).
  • Certaines fonctionnalités de configuration de cluster optionnelles, telles que des groupes de sécurité personnalisés, peuvent vous obliger à demander un quota supplémentaire. Ainsi, parce que ROSA associe 1 groupe de sécurité à des interfaces réseau dans les pools de machines de travail par défaut, et que le quota par défaut pour les groupes de sécurité par interface réseau est de 5, si vous souhaitez ajouter 5 groupes de sécurité personnalisés, vous devez demander un quota supplémentaire, car cela porterait le nombre total de groupes de sécurité sur les interfaces réseau des travailleurs à 6.
Note

Le SDK AWS permet à ROSA de vérifier les quotas, mais le calcul AWS SDK ne tient pas compte de votre utilisation existante. Il est donc possible que le contrôle des quotas puisse passer dans le SDK AWS, mais la création de cluster peut échouer. Afin de résoudre ce problème, augmentez votre quota.

Lorsque vous devez modifier ou augmenter un quota spécifique, consultez la documentation d’Amazon sur la demande d’augmentation de quota. Les demandes de quotas importantes sont soumises à Amazon Support pour examen, et prennent un certain temps pour être approuvées. En cas d’urgence, contactez AWS Support.

Expand
Tableau 7.1. Contingent de service requis par ROSA
Le nom du quotaCode de serviceCode de quotaAWS par défautLe minimum requisDescription

Instances en cours d’exécution (A, C, D, H, I, M, R, T, Z)

ec2

L-1216C47A

5

100

Le nombre maximal de vCPU assignés aux instances Running On-Demand Standard (A, C, D, H, I, M, R, T, Z). La valeur par défaut de 5 vCPUs n’est pas suffisante pour créer des clusters ROSA.

Stockage pour stockage de volume SSD à usage général (gp2) dans TiB

EBS

L-D18FCD1D

50

300

La quantité de stockage agrégée maximale, en TiB, qui peut être fournie sur des volumes SSD à usage général (gp2) dans cette région.

Stockage pour stockage de volume SSD à usage général (gp3) dans TiB

EBS

L-7A658B76

50

300

La quantité de stockage agrégée maximale, en TiB, qui peut être fournie sur des volumes SSD à usage général (gp3) dans cette région. 300 TIB de stockage est le minimum requis pour une performance optimale.

Entreposage pour les volumes IOPS SSD (io1) provisoires en TiB

EBS

L-FD252861

50

300

La quantité de stockage agrégée maximale, en TiB, qui peut être approvisionnée sur les volumes de SSD IOPS provisoires (io1) dans cette région.

300 TIB de stockage est le minimum requis pour une performance optimale.

Expand
Tableau 7.2. Quotas généraux de service AWS
Le nom du quotaCode de serviceCode de quotaAWS par défautLe minimum requisDescription

EC2-VPC Elastic IPs

ec2

L-0263D0A3

5

5

Le nombre maximal d’adresses IP élastiques que vous pouvez allouer pour EC2-VPC dans cette région.

Le VPCS par région

le VPC

L-F678F1CE

5

5

Le nombre maximal de VPC par région. Ce quota est directement lié au nombre maximal de passerelles Internet par région.

Passerelles Internet par région

le VPC

L-A4707A72

5

5

Le nombre maximal de passerelles Internet par région. Ce quota est directement lié au nombre maximal de VPC par région. Afin d’augmenter ce quota, augmenter le nombre de VPC par région.

Interfaces réseau par région

le VPC

L-DF5E4CA3

5 000

5 000

Le nombre maximal d’interfaces réseau par région.

Groupes de sécurité par interface réseau

le VPC

L-2AFB9258

5

5

Le nombre maximum de groupes de sécurité par interface réseau. Ce quota, multiplié par le quota pour les règles par groupe de sécurité, ne peut excéder 1000.

Instantanés par région

EBS

L-309BACF6

10 000

10 000

Le nombre maximal d’instantanés par région

IOPS for Provisioned IOPS SSD (Io1) volumes

EBS

L-B3A130E6

300 000

300 000

Le nombre total maximal d’IOPS pouvant être approvisionné entre les volumes prévus de DDD (io1) de l’IOPS dans cette région.

Balanceurs de charge d’application par région

élasticité de charge

L-53DA6B97

50

50

Le nombre maximal d’équilibreurs de charge d’application pouvant exister dans chaque région.

Balanceurs de charge classiques par région

élasticité de charge

L-E9E9831D

20

20

Le nombre maximal d’équilibreurs de charge classiques pouvant exister dans chaque région.

7.2. Les prochaines étapes
Copier lien

Après avoir rencontré les prérequis AWS, configurez votre environnement et installez Red Hat OpenShift Service sur AWS (ROSA).

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.

8.1. La mise en place de l’environnement pour STS
Copier lien

Avant de créer un Red Hat OpenShift Service sur AWS (ROSA) cluster qui utilise AWS Security Token Service (STS), complétez les étapes suivantes pour configurer votre environnement.

Conditions préalables

  • Examiner et compléter les prérequis et les politiques de déploiement.
  • Créez un compte Red Hat, si vous n’en avez pas déjà un. Ensuite, vérifiez votre email pour obtenir un lien de vérification. Il vous faudra ces informations d’identification pour installer ROSA.

Procédure

  1. Connectez-vous au compte Amazon Web Services (AWS) que vous souhaitez utiliser.

    Il est recommandé d’utiliser un compte AWS dédié pour exécuter des clusters de production. Lorsque vous utilisez AWS Organizations, vous pouvez utiliser un compte AWS au sein de votre organisation ou en créer un nouveau.

    Lorsque vous utilisez AWS Organizations et que vous devez faire appliquer une stratégie de contrôle des services (SCP) au compte AWS que vous envisagez d’utiliser, ces politiques ne doivent pas être plus restrictives que les rôles et les politiques requis par le cluster.

  2. Activer le service ROSA dans la console de gestion AWS.

    1. Connectez-vous à votre compte AWS.
    2. Afin d’activer ROSA, accédez au service ROSA et sélectionnez Activer OpenShift.

  3. Installez et configurez le CLI AWS.

    1. Consultez la documentation de l’interface de ligne de commande AWS pour installer et configurer le CLI AWS pour votre système d’exploitation.

      Indiquez les corrects aws_access_key_id et aws_secret_access_key dans le fichier .aws/credentials. Consultez les bases de configuration AWS dans la documentation AWS.

    2. Définissez une région AWS par défaut.

      Note

      La variable d’environnement permet de définir la région AWS par défaut.

      Le service ROSA évalue les régions dans l’ordre de priorité suivant:

      1. La région spécifiée lors de l’exécution de la commande rosa avec le drapeau --région.
      2. La région définie dans la variable d’environnement AWS_DEFAULT_REGION. Consultez les variables Environnement pour configurer le CLI AWS dans la documentation AWS.
      3. La région par défaut définie dans votre fichier de configuration AWS. Consultez la configuration rapide avec aws configuré dans la documentation AWS.

    3. En option : Configurez vos paramètres et informations d’identification AWS CLI à l’aide d’un profil AWS nommé. dans l’ordre de priorité suivant, Rosa évalue les profils nommés AWS:

      1. Le profil spécifié lors de l’exécution de la commande rosa avec le drapeau --profile.
      2. Le profil défini dans la variable d’environnement AWS_PROFILE. Consultez les profils nommés dans la documentation AWS.

    4. Assurez-vous que le CLI AWS est installé et configuré correctement en exécutant la commande suivante pour interroger l’API AWS: 

      $ aws sts get-caller-identity
      Copy to Clipboard Toggle word wrap

  4. Installez la dernière version de la ROSA CLI (rosa).

    1. Cliquez ici pour télécharger la dernière version de la ROSA CLI pour votre système d’exploitation.

    2. Facultatif: Renommer le fichier que vous avez téléchargé sur rosa et rendre le fichier exécutable. Cette documentation utilise rosa pour se référer au fichier exécutable. 

      $ chmod +x rosa
      Copy to Clipboard Toggle word wrap

    3. En option: Ajoutez rosa à votre chemin. 

      $ mv rosa /usr/local/bin/rosa
      Copy to Clipboard Toggle word wrap

    4. Entrez la commande suivante pour vérifier votre installation: 

      $ rosa
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      Command line tool for Red Hat OpenShift Service on AWS.
For further documentation visit https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws

Usage:
  rosa [command]

Available Commands:
  completion  Generates completion scripts
  create      Create a resource from stdin
  delete      Delete a specific resource
  describe    Show details of a specific resource
  download    Download necessary tools for using your cluster
  edit        Edit a specific resource
  grant       Grant role to a specific resource
  help        Help about any command
  init        Applies templates to support Red Hat OpenShift Service on AWS
  install     Installs a resource into a cluster
  link        Link a ocm/user role from stdin
  list        List all resources of a specific type
  login       Log in to your Red Hat account
  logout      Log out
  logs        Show installation or uninstallation logs for a cluster
  revoke      Revoke role from a specific resource
  uninstall   Uninstalls a resource from a cluster
  unlink      UnLink a ocm/user role from stdin
  upgrade     Upgrade a resource
  verify      Verify resources are configured correctly for cluster install
  version     Prints the version of the tool
  whoami      Displays user account information

Flags:
      --color string   Surround certain characters with escape sequences to display them in color on the terminal. Allowed options are [auto never always] (default "auto")
      --debug          Enable debug mode.
  -h, --help           help for rosa

Use "rosa [command] --help" for more information about a command.
      Copy to Clipboard Toggle word wrap

    5. Générez les scripts d’achèvement de la commande pour le ROSA CLI. L’exemple suivant génère les scripts d’achèvement Bash pour une machine Linux: 

      $ rosa completion bash | sudo tee /etc/bash_completion.d/rosa
      Copy to Clipboard Toggle word wrap

    6. Lancez les scripts pour activer l’achèvement de la commande rosa à partir de votre terminal existant. L’exemple suivant fournit les scripts d’achèvement Bash pour rosa sur une machine Linux: 

      $ source /etc/bash_completion.d/rosa
      Copy to Clipboard Toggle word wrap

  5. Connectez-vous à votre compte Red Hat avec le ROSA CLI.

    1. Entrez la commande suivante. 

      $ rosa login
      Copy to Clipboard Toggle word wrap

    2. &lt;my_offline_access_token&gt; par votre jeton.

      Exemple de sortie

      To login to your Red Hat account, get an offline access token at https://console.redhat.com/openshift/token/rosa
? Copy the token and paste it here: <my-offline-access-token>
      Copy to Clipboard Toggle word wrap

      Exemple de sortie continue

      I: Logged in as '<rh-rosa-user>' on 'https://api.openshift.com'
      Copy to Clipboard Toggle word wrap

  6. Assurez-vous que votre compte AWS dispose du quota nécessaire pour déployer un cluster ROSA. 

    $ rosa verify quota [--region=<aws_region>]
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    I: Validating AWS quota...
I: AWS quota ok
    Copy to Clipboard Toggle word wrap

    Note

    Il arrive que votre quota AWS varie selon les régions. En cas d’erreur, essayez une autre région.

    Lorsque vous avez besoin d’augmenter votre quota, accédez à la console de gestion AWS et demandez une augmentation de quota pour le service qui a échoué.

    Après le succès de la vérification des quotas, passez à l’étape suivante.

  7. Créez votre compte AWS pour le déploiement de clusters:

    1. Exécutez la commande suivante pour vérifier que vos identifiants Red Hat et AWS sont configurés correctement. Assurez-vous que votre ID de compte AWS, votre région par défaut et votre ARN correspondent à ce que vous attendez. En toute sécurité, vous pouvez ignorer les lignes commençant par OpenShift Cluster Manager pour l’instant. 

      $ rosa whoami
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      AWS Account ID:               000000000000
AWS Default Region:           us-east-1
AWS ARN:                      arn:aws:iam::000000000000:user/hello
OCM API:                      https://api.openshift.com
OCM Account ID:               1DzGIdIhqEWyt8UUXQhSoWaaaaa
OCM Account Name:             Your Name
OCM Account Username:         you@domain.com
OCM Account Email:            you@domain.com
OCM Organization ID:          1HopHfA2hcmhup5gCr2uH5aaaaa
OCM Organization Name:        Red Hat
OCM Organization External ID: 0000000
      Copy to Clipboard Toggle word wrap

  8. Installez l’OpenShift CLI (oc), version 4.7.9 ou plus, à partir de la ROSA (rosa) CLI.

    1. Entrez cette commande pour télécharger la dernière version du CLI oc: 

      $ rosa download openshift-client
      Copy to Clipboard Toggle word wrap
    2. Après avoir téléchargé le CLI oc, décompressez-le et ajoutez-le à votre chemin.

    3. Entrez cette commande pour vérifier que le CLI oc est installé correctement: 

      $ rosa verify openshift-client
      Copy to Clipboard Toggle word wrap

Créer des rôles

Après avoir terminé ces étapes, vous êtes prêt à configurer des rôles basés sur l’accès IAM et OIDC.

8.2. Les prochaines étapes
Copier lien

  • Créez rapidement un cluster ROSA avec STS ou créez un cluster à l’aide de personnalisations.

Legal Notice
Copier lien

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.

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