Accueiil
Products
OpenShift Dedicated
4
La planification de votre environnement

La planification de votre environnement

OpenShift Dedicated 4

Aperçu de la planification pour Dédié 4

Red Hat OpenShift Documentation Team

Résumé

Ce document fournit des considérations de planification pour les déploiements de clusters dédiés à OpenShift.

Chapitre 1. Limites et évolutivité
Copier lien

Ce document détaille les maximums de cluster testés pour les clusters dédiés OpenShift, 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.

1.1. Les maximums de clusters
Copier lien

Considérez les maximums d’objets testés suivants lorsque vous planifiez une installation de cluster OpenShift Dedicated. Le tableau spécifie les limites maximales pour chaque type testé dans un cluster dédié OpenShift.

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 1.1. Grappes testées maximales
Le type maximum	4.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

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

1.2. Environnement et configuration des tests OpenShift Container Platform
Copier lien

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œud	Le type	à propos de vCPU	La RAM (GiB)	Le type de disque	Taille du disque (GiB)/IOPS	Comptez	La 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

les disques io1 sont utilisés pour les nœuds plan/etcd de contrôle dans toutes les versions antérieures au 4.10.
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.
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.

1.3. Dimensionnement et mise à l’échelle des nœuds de plan de contrôle et d’infrastructure
Copier lien

Lorsque vous installez un cluster dédié OpenShift, 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.

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

Les tableaux suivants répertorient le dimensionnement du plan de contrôle et des nœuds d’infrastructure qui est appliqué pendant l’installation.

AWS contrôle la taille de l’avion et des nœuds d’infrastructure:

Expand

Le nombre de nœuds de calcul	Contrôle de la taille du plan	Dimension 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

GCP plan de contrôle et la taille des nœuds d’infrastructure:

Expand

Le nombre de nœuds de calcul	Contrôle de la taille du plan	Dimension du nœud d’infrastructure
1 à 25	Custom-8-32768	Custom-4-32768-ext
26 à 100	Custom-16-65536	Custom-8-65536-ext
101 à 249	Custom-32-131072	Custom-16-131072-ext

Le plan de contrôle GCP et la taille des nœuds d’infrastructure pour les clusters créés le 21 juin 2024 ou après:

Expand

Le nombre de nœuds de calcul	Contrôle de la taille du plan	Dimension du nœud d’infrastructure
1 à 25	la norme N2-8	le N2-highmem-4
26 à 100	la norme N2-16	le N2-highmem-8
101 à 249	le n2-standard-32	le N2-highmem-16

Note

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

1.3.2. La mise à l’échelle du nœud après l’installation
Copier lien

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 OpenShift Dedicated 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 OpenShift Dedicated cluster version 4.14.14 et ultérieure est 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.

1.3.3. Considérations de dimensionnement pour les grands groupes
Copier lien

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.

Chapitre 2. Abonnements au cloud client sur GCP
Copier lien

La société OpenShift Dedicated fournit un modèle d’abonnement au cloud client (CCS) qui permet à Red Hat de déployer et de gérer des clusters dans le compte Google Cloud Platform (GCP) existant d’un client.

2.1. Comprendre les abonnements au cloud client sur GCP
Copier lien

Le Red Hat OpenShift Dedicated fournit un modèle d’abonnement au cloud client (CCS) qui permet à Red Hat de déployer et de gérer OpenShift Dedicated dans le compte Google Cloud Platform (GCP) existant d’un client. Le Red Hat nécessite plusieurs conditions préalables pour fournir ce service.

Le Red Hat recommande l’utilisation du projet GCP, géré par le client, pour organiser l’ensemble de vos ressources GCP. Le projet consiste en un ensemble d’utilisateurs et d’API, ainsi que des paramètres de facturation, d’authentification et de surveillance pour ces API.

Il est recommandé que le cluster dédié OpenShift utilisant un modèle CCS soit hébergé dans un projet GCP au sein d’une organisation GCP. La ressource de l’Organisation est le nœud racine de la hiérarchie des ressources du GCP et toutes les ressources qui appartiennent à une organisation sont regroupées sous le nœud de l’organisation. Les clients ont le choix d’utiliser les clés de compte de service ou Workload Identity Federation lors de la création des rôles et des informations d’identification nécessaires pour accéder aux ressources Google Cloud dans un projet GCP.

2.2. Exigences du client
Copier lien

Les clusters dédiés utilisant un modèle d’abonnement au cloud client (CCS) sur Google Cloud Platform (GCP) doivent répondre à plusieurs prérequis avant de pouvoir être déployés.

2.2.1. Compte
Copier lien

Le client veille à ce que les limites de Google Cloud soient suffisantes pour prendre en charge OpenShift Dedicated provisionné dans le compte GCP fourni par le client.
Le compte GCP fourni par le client devrait être dans l’organisation Google Cloud du client.
Le compte GCP fourni par le client ne doit pas être transférable à Red Hat.
Le client ne peut pas imposer de restrictions d’utilisation GCP aux activités Red Hat. L’imposition de restrictions entrave gravement la capacité de Red Hat à réagir aux incidents.
Le Red Hat déploie une surveillance dans GCP pour alerter Red Hat lorsqu’un compte hautement privilégié, tel qu’un compte root, se connecte au compte GCP fourni par le client.
Le client peut déployer des services GCP natifs dans le même compte GCP fourni par le client.
Note
Les clients sont encouragés, mais non mandatés, à déployer des ressources dans un Cloud privé virtuel (VPC) distinct de l’hébergement VPC OpenShift Dedicated et d’autres services pris en charge par Red Hat.

2.2.2. Exigences d’accès
Copier lien

Afin de gérer correctement le service OpenShift Dedicated, Red Hat doit faire appliquer en tout temps la politique AdministratorAccess au rôle d’administrateur.
Note
Cette politique fournit uniquement à Red Hat des autorisations et des capacités pour modifier les ressources du compte GCP fourni par le client.
Le Red Hat doit avoir accès à la console GCP au compte GCP fourni par le client. Cet accès est protégé et géré par Red Hat.
Le client ne doit pas utiliser le compte GCP pour élever ses autorisations au sein du cluster dédié OpenShift.
Les actions disponibles dans le gestionnaire de cluster OpenShift ne doivent pas être effectuées directement dans le compte GCP fourni par le client.

2.2.3. Besoins de soutien
Copier lien

Le Red Hat recommande que le client dispose au moins d’un support amélioré de GCP.
La société Red Hat a l’autorité du client pour demander l’assistance GCP en son nom.
Le client a le pouvoir de demander des augmentations de limite de ressources GCP sur le compte fourni par le client.
Le Red Hat gère les restrictions, limitations, attentes et défaut pour tous les clusters dédiés OpenShift de la même manière, sauf indication contraire dans cette section d’exigences.

2.2.4. Exigences de sécurité
Copier lien

Les informations d’identification IAM fournies par le client doivent être uniques au compte GCP fourni par le client et ne doivent pas être stockées nulle part dans le compte GCP fourni par le client.
Les instantanés de volume resteront dans le compte GCP fourni par le client et dans la région spécifiée par le client.
Afin de gérer, surveiller et dépanner les clusters dédiés OpenShift, Red Hat doit avoir un accès direct au serveur API du cluster. Il ne faut pas restreindre ou empêcher l’accès de Red Hat au serveur API du cluster OpenShift Dedicated.
Note
La SRE utilise diverses méthodes pour accéder aux clusters, en fonction de la configuration du réseau. L’accès aux clusters privés est limité aux adresses IP de confiance de Red Hat uniquement. Ces restrictions d’accès sont gérées automatiquement par Red Hat.
L’OpenShift Dedicated nécessite l’accès à certains points finaux sur Internet. Les clusters déployés avec Private Service Connect peuvent utiliser un pare-feu pour contrôler le trafic sortant. Consultez la section prérequis du pare-feu GCP pour plus d’informations.

2.3. La procédure client requise
Copier lien

Le modèle Customer Cloud Subscription (CCS) permet à Red Hat de déployer et de gérer OpenShift Dedicated dans le projet Google Cloud Platform (GCP) d’un client. Le Red Hat nécessite plusieurs conditions préalables pour fournir ces services.

Note

Les exigences suivantes dans cette rubrique s’appliquent aux clusters OpenShift Dedicated on Google Cloud Platform (GCP) créés à la fois à l’aide du compte de service et du type d’authentification de la Fédération d’identité de charge de travail. En ce qui concerne les exigences supplémentaires qui s’appliquent uniquement au type d’authentification de compte de service, consultez la procédure d’authentification de compte Service. En ce qui concerne les exigences supplémentaires qui s’appliquent uniquement au type d’authentification de la Fédération d’identité de la charge de travail, consultez la procédure d’authentification de la Fédération des identités de travail.

Conditions préalables

Avant d’utiliser OpenShift Dedicated dans votre projet GCP, confirmez que les contraintes de stratégie organisationnelles suivantes sont configurées correctement le cas échéant:

contraintes/iam.allowedPolicyMemberDomains
- Cette contrainte de politique n’est prise en charge que si les identifiants C02k0l5e8 et C04j7mbwl de Red Hat sont inclus dans la liste d’autorisation.
contraintes/calcul.restrictLoadBalancerCreationForTypes
- Cette contrainte de stratégie n’est prise en charge que lors de la création d’un cluster privé avec GCP Private Service Connect (PSC). Il faut s’assurer que le type d’équilibreur de charge INTERNAL_TCP_UDP est inclus dans la liste d’autorisation ou exclu de la liste de refus.
  Important
  Bien que le type d’équilibrage de charge EXTERNAL_NETWORK_TCP_UDP ne soit pas nécessaire lors de la création d’un cluster privé avec GCP Private Service Connect (PSC), son refus via cette contrainte empêchera le cluster de créer des équilibreurs de charge accessibles en externe.
contraintes/calcul.requireShieldedVm
- Cette contrainte de stratégie n’est prise en charge que si le cluster est créé avec le support Enable Secure Boot pour les machines virtuelles protégées sélectionnées lors de la création initiale du cluster.
contraintes/calcul.vmExternalIpAccess
- Cette contrainte de stratégie n’est prise en charge que lors de la création d’un cluster privé avec GCP Private Service Connect (PSC). Dans tous les autres types de clusters, cette contrainte de stratégie n’est prise en charge qu’après la création de clusters.

Procédure

Créez un projet Google Cloud pour héberger le cluster OpenShift dédié.

Activez les API requises suivantes dans le projet qui héberge votre cluster OpenShift Dedicated:

Expand

Tableau 2.1. Les services d’API requis
Le service d’API	Console Nom du service	But
Cloud Deployment Manager V2 API	`déploiementmanager.googleapis.com`	Utilisé pour le déploiement et la gestion automatisés des ressources de l’infrastructure.
Calcul de l’API du moteur	`calcul.googleapis.com`	Il est utilisé pour créer et gérer des machines virtuelles, des pare-feu, des réseaux, des volumes de disque persistants et des équilibreurs de charge.
API Cloud Resource Manager	`cloudresourcemanager.googleapis.com`	Utilisé pour obtenir des projets, obtenir ou définir une politique IAM pour les projets, valider les autorisations requises et le marquage.
API DNS dans le cloud	`DNS.googleapis.com`	Il est utilisé pour créer des zones DNS et gérer les enregistrements DNS pour les domaines de cluster.
IAM Service Credentials API	`iamcredentials.googleapis.com`	Il est utilisé pour créer des informations d’identification de courte durée pour usurper les comptes de services IAM.
API de gestion des identités et des accès (IAM)	`IAM.googleapis.com`	Il est utilisé pour gérer la configuration IAM pour le cluster.
API de gestion des services	`à propos de ServiceManagement.googleapis.com`	Utilisé indirectement pour obtenir des informations sur les quotas pour les ressources du PCG.
API d’utilisation du service	`à propos de Serviceusage.googleapis.com`	Il est utilisé pour déterminer quels services sont disponibles dans le compte Google Cloud du client.
Cloud Storage JSON API	`débarrasseurs-api.googleapis.com`	Il est utilisé pour accéder à Cloud Storage pour le registre des images, l’allumage et les sauvegardes de clusters (le cas échéant).
Le stockage en nuage	`le site Storage-component.googleapis.com`	Il est utilisé pour gérer le stockage en nuage pour le registre des images, l’allumage et les sauvegardes de clusters (le cas échéant).
API de stratégie d’organisation	`le site Orgpolicy.googleapis.com`	Il est utilisé pour identifier les règles de gouvernance appliquées au Google Cloud du client qui pourraient avoir un impact sur la création ou la gestion de clusters.
API Cloud Identity-Aware Proxy	IAP.googleapis.com [*]	Il est utilisé dans les situations d’urgence pour dépanner les nœuds de cluster qui sont autrement inaccessibles. Cette API est requise pour les clusters déployés avec Private Service Connect.

2.3.1. Procédure d’authentification de compte de service
Copier lien

En plus des procédures client requises énumérées dans la procédure client requise, il y a d’autres actions spécifiques que vous devez prendre lors de la création d’un cluster dédié OpenShift sur Google Cloud Platform (GCP) en utilisant un compte de service comme type d’authentification.

Procédure

Afin d’assurer que Red Hat puisse effectuer les actions nécessaires, vous devez créer un utilisateur de compte de service IAM osd-ccs-admin dans le cadre du projet GCP.

Les rôles suivants doivent être attribués au compte de service:

Expand

Tableau 2.2. Les rôles requis
Le rôle	Console nom de rôle
Calculer l’admin	`les rôles/calcul.admin`
Administrateur DNS	`les rôles/dns.admin`
Affichage de la politique d’organisation	`les rôles/orgpolicy.policyViewer`
Administrateur de la gestion des services	`les rôles et la gestion des services.admin`
Administration d’utilisation du service	`les rôles/serviceusage.serviceUsageAdmin`
Administrateur de stockage	`les rôles/storage.admin`
Calculez l’équilibreur de charge Admin	`fonctions/compute.loadBalancerAdmin`
Affichage des rôles	`les rôles et le spectateur`
Administrateur de rôle	`les rôles/iam.roleAdmin`
Administration de sécurité	`les rôles/iam.securityAdmin`
Compte de service Admin clé	`les rôles/iam.serviceAccountKeyAdmin`
Compte de service Admin	`les rôles/iam.serviceAccountAdmin`
Compte de service Utilisateur	`les rôles/iam.serviceAccountUser`

Créez la clé de compte de service pour le compte de service osd-ccs-admin IAM. Exportez la clé vers un fichier nommé osServiceAccount.json; ce fichier JSON sera téléchargé dans Red Hat OpenShift Cluster Manager lorsque vous créez votre cluster.

2.3.2. La procédure de type d’authentification de la Fédération d’identité de la charge de travail
Copier lien

En plus des procédures client requises énumérées dans la procédure client requise, il y a d’autres actions spécifiques que vous devez prendre lors de la création d’un cluster dédié OpenShift sur Google Cloud Platform (GCP) en utilisant Workload Identity Federation comme type d’authentification.

Procédure

Attribuez les rôles suivants au compte de service de l’utilisateur mettant en œuvre le type d’authentification de la Fédération d’identité de la charge de travail:

Expand

Tableau 2.3. Les rôles requis
Le rôle	Console nom de rôle	But du rôle
Administrateur de rôle	`les rôles/iam.roleAdmin`	Requis par le client GCP dans le CLI OCM pour créer des rôles personnalisés.
Compte de service Admin	`les rôles/iam.serviceAccountAdmin`	Besoin de pré-créer le compte de services requis par le déployeur OSD, le support et les opérateurs.
Gestion du pool d’identité de la charge de travail	`les rôles/iam.workloadIdentityPoolAdmin`	Il est nécessaire de créer et de configurer le pool d’identités de la charge de travail.
Administration du projet IAM	`les rôles/resourcemanager.projectIamAdmin`	Il est nécessaire d’attribuer des rôles au compte de service et de donner des autorisations aux rôles nécessaires à l’exécution des opérations sur les ressources cloud.

Installez l’interface de ligne de commande de l’API OpenShift Cluster Manager (ocm).
Afin d’utiliser le CLI OCM, vous devez vous authentifier auprès de votre compte Red Hat OpenShift Cluster Manager. Ceci est accompli avec le jeton API OpenShift Cluster Manager.
Ici, vous pouvez obtenir votre jeton.
Afin de vous authentifier par rapport à votre compte Red Hat OpenShift Cluster Manager, exécutez la commande suivante:
```
ocm login --token <token>
```
```
$ ocm login --token <token> 
```
1
Copy to Clipboard Toggle word wrap
1
<token> avec votre jeton API OpenShift Cluster Manager.
Important
L’interface de ligne de commande de l’API OpenShift Cluster Manager (ocm) est uniquement une fonctionnalité d’aperçu technologique. En savoir plus sur la portée du support des fonctionnalités de Red Hat Technology Preview, voir la portée du support des fonctionnalités d’aperçu de la technologie.
Installez le gcloud CLI.
Authentifier le gcloud CLI avec les identifiants par défaut d’application (ADC).

2.4. Les ressources Google Cloud gérées par Red Hat
Copier lien

La société Red Hat est responsable de la création et de la gestion des ressources suivantes de la plateforme Google Cloud Platform (GCP) de l’IAM.

Important

Le compte et les rôles de service IAM et les sujets de groupe et de rôles IAM ne s’appliquent qu’aux clusters créés à l’aide du type d’authentification de compte de service.

2.4.1. Compte et rôles de service IAM
Copier lien

Le compte de service IAM géré par osd-admin est créé immédiatement après avoir pris le contrôle du compte GCP fourni par le client. C’est l’utilisateur qui effectuera l’installation du cluster OpenShift Dedicated.

Les rôles suivants sont joints au compte de service:

Expand

Tableau 2.4. IAM rôles pour osd-managed-admin
Le rôle	Console nom de rôle	Description
Calculer l’admin	`les rôles/calcul.admin`	Fournit un contrôle total de toutes les ressources du moteur de calcul.
Administrateur DNS	`les rôles/dns.admin`	Fournit un accès en lecture-écriture à toutes les ressources DNS Cloud.
Administration de sécurité	`les rôles/iam.securityAdmin`	Le rôle d’administrateur de sécurité, avec des autorisations pour obtenir et définir n’importe quelle politique IAM.
Administrateur de stockage	`les rôles/storage.admin`	Donne le contrôle total des objets et des seaux. Lorsqu’il est appliqué sur un seau individuel, le contrôle ne s’applique qu’au seau spécifié et aux objets à l’intérieur du seau.
Compte de service Admin	`les rôles/iam.serviceAccountAdmin`	Créez et gérez des comptes de service.
Compte de service Admin clé	`les rôles/iam.serviceAccountKeyAdmin`	Créez et gérez (et tournez) les clés de compte de service.
Compte de service Utilisateur	`les rôles/iam.serviceAccountUser`	Exécutez des opérations en tant que compte de service.
Administrateur de rôle	`les rôles/iam.roleAdmin`	Donne accès à tous les rôles personnalisés dans le projet.

2.4.2. Groupe IAM et rôles
Copier lien

Le groupe Google sd-sre-plateforme-gcp-access bénéficie d’un accès au projet GCP pour permettre à Red Hat Site Reliability Engineering (SRE) d’accéder à la console à des fins de dépannage d’urgence.

Note

En ce qui concerne les rôles au sein du groupe d’accès sd-sre-plateforme-gcp qui sont spécifiques aux clusters créés lors de l’utilisation du type d’authentification WIF (Workload Identity Federation), consultez la configuration du cluster géré.
Afin d’obtenir des informations sur la création d’un cluster à l’aide du type d’authentification de la Fédération de l’identité de la charge de travail, consultez les ressources supplémentaires.

Les rôles suivants sont attachés au groupe:

Expand

Tableau 2.5. IAM rôles pour sd-sre-platform-gcp-access
Le rôle	Console nom de rôle	Description
Calculer l’admin	`les rôles/calcul.admin`	Fournit un contrôle total de toutes les ressources du moteur de calcul.
Éditeur	`les rôles/rédacteurs`	Fournit toutes les permissions de téléspectateur, plus les autorisations pour les actions qui modifient l’état.
Affichage de la politique d’organisation	`les rôles/orgpolicy.policyViewer`	Donne accès à l’affichage des politiques organisationnelles sur les ressources.
Administration du projet IAM	`les rôles/resourcemanager.projectIamAdmin`	Fournit des autorisations pour administrer les politiques IAM sur les projets.
Administrateur des quotas	`les rôles et la gestion des services.quotaAdmin`	Donne accès à l’administration des quotas de service.
Administrateur de rôle	`les rôles/iam.roleAdmin`	Donne accès à tous les rôles personnalisés dans le projet.
Compte de service Admin	`les rôles/iam.serviceAccountAdmin`	Créez et gérez des comptes de service.
Administration d’utilisation du service	`les rôles/serviceusage.serviceUsageAdmin`	Capacité à activer, désactiver et inspecter les états de service, inspecter les opérations et consommer le quota et la facturation pour un projet de consommation.
Éditeur de support technique	`accueil / Cloudsupport.techSupportEditor`	Fournit un accès complet en lecture-écriture aux cas d’assistance technique.

2.5. Infrastructure GCP provisionnée
Copier lien

Il s’agit d’un aperçu des composants fournis par Google Cloud Platform (GCP) sur un cluster dédié OpenShift déployé. Consultez la documentation OpenShift Container Platform pour obtenir une liste plus détaillée de tous les composants GCP fournis.

2.5.1. Calcul des instances
Copier lien

Les instances de calcul GCP sont nécessaires pour déployer les fonctions de plan de contrôle et de plan de données d’OpenShift Dedicated dans GCP. 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.

La zone de disponibilité unique
- 2 nœuds infrarouges (type de machine personnalisée: 4 vCPU et 32 Go de RAM)
- 3 nœuds de plan de contrôle (type de machine personnalisée: 8 vCPU et 32 Go de RAM)
- 2 nœuds ouvriers (type de machine personnalisée: 4 vCPU et 16 Go de RAM)
Des zones de disponibilité multiples
- 3 nœuds infra (type de machine personnalisée: 4 vCPU et 32 Go de RAM)
- 3 nœuds de plan de contrôle (type de machine personnalisée: 8 vCPU et 32 Go de RAM)
- 3 nœuds ouvriers (type de machine personnalisée: 4 vCPU et 16 Go de RAM)

2.5.2. Le stockage
Copier lien

Les volumes d’infrastructures:
- Disque persistant SSD de 300 Go (supprimé lors de la suppression d’instance)
- 110 Go Disque persistant standard (conservé sur la suppression d’instance)
Les volumes des travailleurs:
- Disque persistant SSD de 300 Go (supprimé lors de la suppression d’instance)
Contrôle des volumes de plans:
- 350 Go disque persistant SSD (supprimé sur suppression d’instance)

2.5.3. LE VPC
Copier lien

Les sous-réseaux: un sous-réseau principal pour les charges de travail des plans de contrôle et un sous-réseau de travail pour tous les autres.
Les tables de routeur: une table de route globale par VPC.
Passerelles Internet: une passerelle Internet par cluster.
Passerelles NAT: une passerelle NAT maître et une passerelle NAT de travail par cluster.

2.5.4. Les services
Copier lien

Les services suivants doivent être activés sur un cluster CCS GCP:

gestionnaire de déploiement
calculer
cloudapis
cloudresourcemanager
DNS
iamcredentials
IAM
gestion des services
consommation de service
entreposage-api
composant de stockage
l’Orgpolitie
la sécurité du réseau

2.6. Limites de compte GCP
Copier lien

Le cluster OpenShift Dedicated utilise un certain nombre de composants Google Cloud Platform (GCP), mais les quotas par défaut n’affectent pas votre capacité à installer un cluster dédié OpenShift.

Le cluster standard OpenShift Dedicated utilise les ressources suivantes. Il est à noter que certaines ressources ne sont nécessaires que pendant le processus bootstrap et sont supprimées après le déploiement du cluster.

Expand

Tableau 2.6. Les ressources GCP utilisées dans un cluster par défaut
Le service	Composante	L’emplacement	A) Total des ressources nécessaires	Les ressources supprimées après bootstrap
Compte de service	IAM	À l ' échelle mondiale	5	0
Les règles du pare-feu	Calculer	À l ' échelle mondiale	11	1
Les règles de transmission	Calculer	À l ' échelle mondiale	2	0
Adresses IP globales en service	Calculer	À l ' échelle mondiale	4	1
Contrôles de santé	Calculer	À l ' échelle mondiale	3	0
Images	Calculer	À l ' échelle mondiale	1	0
Les réseaux	Calculer	À l ' échelle mondiale	2	0
Adresses IP statiques	Calculer	La région	4	1
Les routeurs	Calculer	À l ' échelle mondiale	1	0
Itinéraires	Calculer	À l ' échelle mondiale	2	0
Les sous-réseaux	Calculer	À l ' échelle mondiale	2	0
Les piscines cibles	Calculer	À l ' échelle mondiale	3	0
CPUs	Calculer	La région	28	4
Disque persistant SSD (GB)	Calculer	La région	896	128

Note

Lorsque l’un des quotas est insuffisant pendant l’installation, le programme d’installation affiche une erreur indiquant à la fois quel quota a été dépassé et la région.

Assurez-vous de prendre en compte la taille réelle de votre cluster, la croissance planifiée des clusters et toute utilisation d’autres clusters associés à votre compte. Le CPU, les adresses IP statiques et les quotas SSD de disque persistant (Storage) sont ceux qui sont les plus susceptibles d’être insuffisants.

Lorsque vous prévoyez de déployer votre cluster dans l’une des régions suivantes, vous dépasserez le quota de stockage maximal et dépasserez probablement la limite de quota CPU:

Asie-Est2
Asie-nord-est2
Asie-sud1
Australie-sud-est1
Europe-Nord1
Europe-Ouest2
Europe-Ouest3
Europe-Ouest6
Amérique du Nord-nord-est1
Amérique du Sud-Est1
à l’ouest2

Il est possible d’augmenter les quotas de ressources à partir de la console GCP, mais vous devrez peut-être déposer un ticket d’assistance. Assurez-vous de planifier la taille de votre cluster tôt afin que vous puissiez laisser le temps de résoudre le ticket de support avant d’installer votre cluster OpenShift dédié.

2.7. Conditions préalables du pare-feu GCP
Copier lien

Lorsque vous utilisez un pare-feu pour contrôler le trafic de sortie d’OpenShift Dedicated sur Google Cloud Platform (GCP), vous devez configurer votre pare-feu pour permettre l’accès à certains domaines et combinaisons de ports énumérés dans les tableaux ci-dessous. Le service OpenShift Dedicated nécessite cet accès pour fournir un service OpenShift entièrement géré.

Important

Les clusters de Google Cloud Platform (GCP) déployés avec Private Service Connect peuvent utiliser un pare-feu pour contrôler le trafic de sortie.

Procédure

Ajoutez les URL suivantes qui sont utilisées pour installer et télécharger des paquets et des outils à une liste d’autorisations:

Expand

Domaine	Le port	Fonction
`Greffe.redhat.io`	443	Fournit des images de conteneur de base.
`à propos de Quay.io`	443	Fournit des images de conteneur de base.
`cdn01.quay.io` `cdn02.quay.io` `cdn03.quay.io` `cdn04.quay.io` `cdn05.quay.io` `cdn06.quay.io`	443	Fournit des images de conteneur de base.
`à propos de SSO.redhat.com`	443	C’est nécessaire. Le site https://console.redhat.com/openshift utilise l’authentification de sso.redhat.com pour télécharger le secret de traction et utiliser les solutions Red Hat SaaS pour faciliter la surveillance de vos abonnements, de l’inventaire des clusters, des rapports de rétrofacturation, etc.
`ajouter au panier Quayio-production-s3.s3.amazonaws.com`	443	Fournit des images de conteneur de base.
`le site pull.q1w2.quay.rhcloud.com`	443	Fournit des images de conteneur de base.
`Registry.access.redhat.com`	443	Héberge toutes les images du conteneur qui sont stockées sur le catalogue Ecosytem Red Hat. De plus, le registre donne accès à l’outil odo CLI qui aide les développeurs à s’appuyer sur OpenShift et Kubernetes.
`Registry.connect.redhat.com`	443	Requis pour toutes les images tierces et les opérateurs certifiés.
`console.redhat.com`	443	C’est nécessaire. Autorise les interactions entre le cluster et Red Hat OpenShift Cluster Manager pour activer les fonctionnalités, telles que la planification des mises à niveau.
`à propos de SSO.redhat.com`	443	Le site https://console.redhat.com/openshift utilise l’authentification de sso.redhat.com.
`catalogue.redhat.com`	443	Les sites Registry.access.redhat.com et https://registry.redhat.io redirigent vers catalog.redhat.com.

Ajoutez les URL de télémétrie suivantes à une liste d’autorisations:

Expand

Domaine	Le port	Fonction
`CERT-api.access.redhat.com`	443	Requis pour la télémétrie.
`API.access.redhat.com`	443	Requis pour la télémétrie.
`infogw.api.openshift.com`	443	Requis pour la télémétrie.
`console.redhat.com`	443	Requis pour la télémétrie et Red Hat Insights.
`le site Observatorium-mst.api.openshift.com`	443	Requis pour la télémétrie spécifique à OpenShift gérée.
`bienvenue sur Observatorium.api.openshift.com`	443	Requis pour la télémétrie spécifique à OpenShift gérée.

Note

Les clusters gérés nécessitent l’activation de la télémétrie pour permettre à Red Hat de réagir plus rapidement aux problèmes, de mieux soutenir les clients et de mieux comprendre l’impact des mises à jour des produits sur les clusters. De plus amples renseignements sur la façon dont les données de surveillance de la santé à distance sont utilisées par Red Hat, voir À propos de la surveillance de la santé à distance dans la section Ressources supplémentaires.

Ajoutez les URL OpenShift dédiées suivantes à une liste d’autorisations:

Expand

Domaine	Le port	Fonction
`le site Mirror.openshift.com`	443	Il est utilisé pour accéder au contenu et aux images d’installation en miroir. Ce site est également une source de signatures d’images de libération.
`API.openshift.com`	443	Il est utilisé pour vérifier si des mises à jour sont disponibles pour le cluster.

Ajoutez les URL d’ingénierie de fiabilité (SRE) et de gestion suivantes à une liste d’autorisations:

Expand

Domaine	Le port	Fonction
`API.pagerduty.com`	443	Ce service d’alerte est utilisé par le gestionnaire d’alertes inclus pour envoyer des alertes notifiant Red Hat SRE d’un événement pour agir.
`événements.pagerduty.com`	443	Ce service d’alerte est utilisé par le gestionnaire d’alertes inclus pour envoyer des alertes notifiant Red Hat SRE d’un événement pour agir.
`API.deadmanssnitch.com`	443	Le service d’alerte utilisé par OpenShift Dedicated pour envoyer des pings périodiques indiquant si le cluster est disponible et en cours d’exécution.
`à propos de nosnch.in`	443	Le service d’alerte utilisé par OpenShift Dedicated pour envoyer des pings périodiques indiquant si le cluster est disponible et en cours d’exécution.
`HTTP-inputs-osdsecuritylogs.splunkcloud.com`	443	Utilisé par le splunk-forwarder-operator comme point de terminaison de journalisation à utiliser par Red Hat SRE pour l’alerte log-based.
le site SFTP.access.redhat.com (recommandé)	22	Le serveur SFTP utilisé par l’opérateur must-collectther pour télécharger des journaux de diagnostic pour aider à résoudre les problèmes avec le cluster.

Ajoutez les URL suivantes pour les points de terminaison de l’API Google Cloud Platform (GCP) à une liste d’autorisations:

Expand

Domaine Le port Fonction

Domaine	Le port	Fonction
`comptes.google.com`	443	Il est utilisé pour accéder à votre compte GCP.
`*.googleapis.com` A) OU `à propos de Storage.googleapis.com` `IAM.googleapis.com` `à propos de Serviceusage.googleapis.com` `cloudresourcemanager.googleapis.com` `calcul.googleapis.com` `le site Oauth2.googleapis.com` `DNS.googleapis.com` `iamcredentials.googleapis.com`	443	Il est utilisé pour accéder aux services et aux ressources du GCP. Examinez Cloud Endpoints dans la documentation GCP pour déterminer les points de terminaison pour autoriser vos API.

comptes.google.com

443

Il est utilisé pour accéder à votre compte GCP.

*.googleapis.com

A) OU

à propos de Storage.googleapis.com

IAM.googleapis.com

à propos de Serviceusage.googleapis.com

cloudresourcemanager.googleapis.com

calcul.googleapis.com

le site Oauth2.googleapis.com

DNS.googleapis.com

iamcredentials.googleapis.com

443

Il est utilisé pour accéder aux services et aux ressources du GCP. Examinez Cloud Endpoints dans la documentation GCP pour déterminer les points de terminaison pour autoriser vos API.

Note

Les API Google requises peuvent être exposées à l’aide de l’IP virtuel privé Google Access (VIP), à l’exception de l’API d’utilisation du service (serviceusage.googleapis.com). Afin de contourner cela, vous devez exposer l’API d’utilisation du service en utilisant le VIP privé Google Access privé.

2.8. Ressources supplémentaires
Copier lien

À propos de la surveillance à distance de la santé
En savoir plus sur la création d’un cluster dédié OpenShift avec le type d’authentification WIF (Workload Identity Federation), voir Création d’une configuration WIF.
Afin d’obtenir de plus amples informations sur les rôles et autorisations spécifiques aux clusters créés lors de l’utilisation du type d’authentification WIF (Workload Identity Federation), consultez la configuration Manag-cluster-config.

Chapitre 3. Abonnements au cloud client sur AWS
Copier lien

La société OpenShift Dedicated fournit un modèle d’abonnement au cloud client (CCS) qui permet à Red Hat de déployer et de gérer des clusters dans le compte Amazon Web Service (AWS) existant d’un client.

3.1. Comprendre les abonnements au cloud client sur AWS
Copier lien

Afin de déployer OpenShift Dédié dans votre compte Amazon Web Services (AWS) existant à l’aide du modèle d’abonnement au cloud client (CCS), Red Hat nécessite plusieurs conditions préalables.

Le Red Hat recommande l’utilisation d’une organisation AWS pour gérer plusieurs comptes AWS. L’organisation AWS, gérée par le client, héberge plusieurs comptes AWS. Il y a un compte racine dans l’organisation auquel tous les comptes se référeront dans la hiérarchie des comptes.

Il est recommandé que le cluster dédié OpenShift utilisant un modèle CCS soit hébergé 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. Le SCP ne s’applique qu’aux autorisations disponibles dans un seul compte AWS pour tous les sous-comptes AWS au sein de l’Unité organisationnelle. Il est également possible d’appliquer un SCP à un seul compte AWS. Les autres comptes de l’organisation AWS du client sont gérés de la manière dont le client a besoin. Les ingénieurs de fiabilité du site Red Hat (SRE) n’auront aucun contrôle sur les SCP au sein de l’organisation AWS.

3.2. Exigences du client
Copier lien

Les clusters dédiés utilisant un modèle d’abonnement au cloud client (CCS) sur Amazon Web Services (AWS) doivent répondre à plusieurs prérequis avant de pouvoir être déployés.

3.2.1. Compte
Copier lien

Le client veille à ce que les limites AWS soient suffisantes pour prendre en charge OpenShift Dedicated provisionné dans le compte AWS fourni par le client.
Le compte AWS fourni par le client doit être dans l’organisation AWS du client avec la politique de contrôle du service (SCP) applicable.
Note
Il n’est pas nécessaire que le compte fourni par le client soit au sein d’une organisation AWS ou que le SCP soit appliqué, mais Red Hat doit être en mesure d’effectuer toutes les actions énumérées dans le SCP sans restriction.
Le compte AWS fourni par le client ne doit pas être transférable à Red Hat.
Le client ne peut pas imposer de restrictions d’utilisation AWS aux activités Red Hat. L’imposition de restrictions entrave gravement la capacité de Red Hat à réagir aux incidents.
Le Red Hat déploie une surveillance sur AWS pour alerter Red Hat lorsqu’un compte hautement privilégié, tel qu’un compte root, se connecte au compte AWS fourni par le client.
Le client peut déployer des services AWS natifs dans le même compte AWS fourni par le client.
Note
Les clients sont encouragés, mais non mandatés, à déployer des ressources dans un Cloud privé virtuel (VPC) distinct de l’hébergement VPC OpenShift Dedicated et d’autres services pris en charge par Red Hat.

3.2.2. Exigences d’accès
Copier lien

Afin de gérer correctement le service OpenShift Dedicated, Red Hat doit faire appliquer en tout temps la politique AdministratorAccess au rôle d’administrateur.
Note
Cette politique fournit uniquement à Red Hat des autorisations et des capacités pour modifier les ressources du compte AWS fourni par le client.
Le Red Hat doit avoir accès à la console AWS au compte AWS fourni par le client. Cet accès est protégé et géré par Red Hat.
Le client ne doit pas utiliser le compte AWS pour élever ses autorisations au sein du cluster dédié OpenShift.
Les actions disponibles dans OpenShift Cluster Manager ne doivent pas être effectuées directement dans le compte AWS fourni par le client.

3.2.3. Besoins de soutien
Copier lien

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

3.2.4. Exigences de sécurité
Copier lien

Les informations d’identification IAM fournies par le client doivent être uniques au compte AWS fourni par le client et ne doivent pas être stockées nulle part dans le compte AWS fourni par le client.
Les instantanés de volume resteront dans le compte AWS fourni par le client et dans la région spécifiée par le client.
Le Red Hat doit avoir accès aux hôtes EC2 et au serveur API via des machines Red Hat blanc.
Le Red Hat doit avoir le droit d’envoyer le système et les journaux d’audit vers une pile de journalisation centrale gérée par Red Hat.

3.3. La procédure client requise
Copier lien

Le modèle Customer Cloud Subscription (CCS) permet à Red Hat de déployer et de gérer OpenShift Dedicated dans le compte Amazon Web Services (AWS) d’un client. Le Red Hat nécessite plusieurs conditions préalables pour fournir ces services.

Procédure

Lorsque le client utilise AWS Organizations, vous devez utiliser un compte AWS au sein de votre organisation ou en créer un nouveau.
Afin de vous assurer que Red Hat peut effectuer les actions nécessaires, vous devez soit créer une stratégie de contrôle du service (SCP) soit s’assurer qu’aucune n’est appliquée au compte AWS.
Attachez le SCP au compte AWS.
Dans le compte AWS, vous devez créer un utilisateur osdCcsAdmin IAM avec les exigences suivantes:
- Cet utilisateur a besoin au moins d’un accès programmatique activé.
- Cet utilisateur doit avoir la politique AdministratorAccess qui lui est associée.
Fournissez les identifiants d’utilisateur IAM à Red Hat.
- Dans OpenShift Cluster Manager, vous devez fournir l’ID de clé d’accès et la clé d’accès secrète.

3.4. La politique minimale de contrôle du service requis (SCP)
Copier lien

La gestion de la politique de contrôle du service (SCP) relève de la responsabilité du client. Ces politiques sont maintenues dans l’organisation AWS et contrôlent les services disponibles dans les comptes AWS ci-joints.

Expand

Requis/facultatif	Le service	Actions	Effet
A) requis	Amazon EC2	Le tout	Autoriser
	Amazon EC2 Auto Scaling	Le tout	Autoriser
	Amazon S3	Le tout	Autoriser
	Gestion de l’identité et de l’accès	Le tout	Autoriser
	Équilibrage de charge élastique	Le tout	Autoriser
	Équilibrage de charge élastique V2	Le tout	Autoriser
	Amazon CloudWatch	Le tout	Autoriser
	Événements Amazon CloudWatch	Le tout	Autoriser
	Journaux Amazon CloudWatch	Le tout	Autoriser
	Le support AWS	Le tout	Autoriser
	AWS Key Management Service	Le tout	Autoriser
	AWS Security Token Service	Le tout	Autoriser
	Étiquettes des ressources AWS	Le tout	Autoriser
	AWS Route53 DNS	Le tout	Autoriser
	Quotas de service AWS	Liste des services GetRequestedServiceQuotaChange GetServiceQuota DemandeServiceQuotaaugmentation ListeServiceQuotas	Autoriser
Facultatif	Facturation AWS	AfficherAccount Affichage de la facturation AffichageUsage	Autoriser
	AWS Rapport sur les coûts et l’utilisation	Le tout	Autoriser
	AWS Cost Explorer Services	Le tout	Autoriser

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "events:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "support:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "sts:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "tag:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "servicequotas:ListServices",
                "servicequotas:GetRequestedServiceQuotaChange",
                "servicequotas:GetServiceQuota",
                "servicequotas:RequestServiceQuotaIncrease",
                "servicequotas:ListServiceQuotas"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "events:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "support:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "sts:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "tag:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:*"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "servicequotas:ListServices",
                "servicequotas:GetRequestedServiceQuotaChange",
                "servicequotas:GetServiceQuota",
                "servicequotas:RequestServiceQuotaIncrease",
                "servicequotas:ListServiceQuotas"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

Copy to Clipboard

Toggle word wrap

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

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

3.5.1. Les politiques de l’IAM
Copier lien

Note

Les politiques IAM sont sujettes à modification en tant que capacités de changement dédié OpenShift.

La politique AdministratorAccess est utilisée par le rôle d’administration. Cette politique fournit à Red Hat l’accès nécessaire pour administrer le cluster OpenShift Dedicated dans le compte AWS fourni par le client.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "*",
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "*",
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

Copy to Clipboard

Toggle word wrap

Le rôle CustomerAdministratorAccess permet au client d’administrer un sous-ensemble de services au sein du compte AWS. À l’heure actuelle, les conditions suivantes sont autorisées:

Le VPC Peering
Configuration VPN

Direct Connect (disponible uniquement s’il est accordé par le biais de la politique de contrôle du service)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:AttachVpnGateway",
                "ec2:DescribeVpnConnections",
                "ec2:AcceptVpcPeeringConnection",
                "ec2:DeleteVpcPeeringConnection",
                "ec2:DescribeVpcPeeringConnections",
                "ec2:CreateVpnConnectionRoute",
                "ec2:RejectVpcPeeringConnection",
                "ec2:DetachVpnGateway",
                "ec2:DeleteVpnConnectionRoute",
                "ec2:DeleteVpnGateway",
                "ec2:DescribeVpcs",
                "ec2:CreateVpnGateway",
                "ec2:ModifyVpcPeeringConnectionOptions",
                "ec2:DeleteVpnConnection",
                "ec2:CreateVpcPeeringConnection",
                "ec2:DescribeVpnGateways",
                "ec2:CreateVpnConnection",
                "ec2:DescribeRouteTables",
                "ec2:CreateTags",
                "ec2:CreateRoute",
          "directconnect:*"
            ],
            "Resource": "*"
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:AttachVpnGateway",
                "ec2:DescribeVpnConnections",
                "ec2:AcceptVpcPeeringConnection",
                "ec2:DeleteVpcPeeringConnection",
                "ec2:DescribeVpcPeeringConnections",
                "ec2:CreateVpnConnectionRoute",
                "ec2:RejectVpcPeeringConnection",
                "ec2:DetachVpnGateway",
                "ec2:DeleteVpnConnectionRoute",
                "ec2:DeleteVpnGateway",
                "ec2:DescribeVpcs",
                "ec2:CreateVpnGateway",
                "ec2:ModifyVpcPeeringConnectionOptions",
                "ec2:DeleteVpnConnection",
                "ec2:CreateVpcPeeringConnection",
                "ec2:DescribeVpnGateways",
                "ec2:CreateVpnConnection",
                "ec2:DescribeRouteTables",
                "ec2:CreateTags",
                "ec2:CreateRoute",
          "directconnect:*"
            ],
            "Resource": "*"
        }
    ]
}

Copy to Clipboard

Toggle word wrap

En cas d’activation, le rôle BillingReadOnlyAccess fournit un accès en lecture seule pour afficher les informations de facturation et d’utilisation du compte.
L’accès à la facturation et à l’utilisation n’est accordé que si le compte racine de l’organisation AWS l’a activé. Il s’agit d’une étape facultative que le client doit effectuer pour permettre l’accès à la facturation et à l’utilisation en lecture seule et n’affecte pas la création de ce profil et le rôle qui l’utilise. Dans le cas où ce rôle n’est pas activé, les utilisateurs ne verront pas d’informations sur la facturation et l’utilisation. Consultez ce tutoriel sur la façon d’activer l’accès aux données de facturation.
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "aws-portal:ViewAccount",
                "aws-portal:ViewBilling"
            ],
            "Resource": "*"
        }
    ]
}
```
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "aws-portal:ViewAccount",
                "aws-portal:ViewBilling"
            ],
            "Resource": "*"
        }
    ]
}
```
Copy to Clipboard Toggle word wrap

3.5.2. Les utilisateurs de l’IAM
Copier lien

L’utilisateur osdManagedAdmin est créé immédiatement après avoir pris le contrôle du compte AWS fourni par le client. C’est l’utilisateur qui effectuera l’installation du cluster OpenShift Dedicated.

3.5.3. Les rôles de l’IAM
Copier lien

Le rôle réseau-mgmt fournit un accès administratif géré par le client au compte AWS via un compte AWS distinct. Il a également le même accès qu’un rôle en lecture seule. Le rôle réseau-mgmt s’applique uniquement aux clusters non-Customer Cloud Subscription (CCS). Les politiques suivantes sont attachées au rôle:
- AmazonEC2ReadOnlyAccess
- CustomerAdministratorAccès
Le rôle en lecture seule fournit un accès en lecture seule par le client au compte AWS via un compte AWS distinct. Les politiques suivantes sont attachées au rôle:
- AWSAccountUsageReportAccess
- AmazonEC2ReadOnlyAccess
- AmazonS3ReadOnlyAccess
- IAMReadOnlyAccess
- BillingReadOnlyAccess

3.6. Infrastructure AWS provisionnée
Copier lien

Il s’agit d’un aperçu des composants Amazon Web Services (AWS) fournis sur un cluster dédié OpenShift déployé. Consultez la documentation OpenShift Container Platform pour obtenir une liste plus détaillée de tous les composants AWS fournis.

3.6.1. Instances AWS Elastic Computing (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 d’OpenShift Dedicated dans le cloud public 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.

La zone de disponibilité unique
- 3 m5.2xlarge minimum (nœuds de plan de contrôle)
- 2 r5.xlarge minimum (nœuds d’infrastructure)
- 2 m5.xlarge minimum mais très variable (nœuds de travail)
Des zones de disponibilité multiples
- 3 m5.2xlarge minimum (nœuds de plan de contrôle)
- 3 r5.xlarge minimum (nœuds d’infrastructure)
- 3 m5.xlarge minimum mais très variable (nœuds de travail)

3.6.2. AWS Elastic Block Store (EBS) stockage
Copier lien

Le stockage de blocs Amazon EBS est utilisé à la fois pour le stockage des nœuds locaux et le stockage en volume persistant.

Exigences en volume pour chaque instance EC2:

Contrôle des volumes de plans
- Dimensions: 350 Go
- Catégorie: io1
- Entrées/sorties par seconde: 1000
Les volumes d’infrastructures
- Dimensions: 300 Go
- Catégorie: gp2
- Entrées/sorties par seconde : 900
Les volumes des travailleurs
- Dimensions: 300 Go
- Catégorie: gp2
- Entrées/sorties par seconde : 900

3.6.3. Équilibrage de charge élastique (ELB)
Copier lien

Jusqu’à deux balanceurs de charge réseau pour API et jusqu’à deux balanceurs de charge classiques pour routeur d’application. Consultez la documentation ELB pour AWS.

3.6.4. Le stockage S3
Copier lien

Le registre des images et les instantanés de volume Elastic Block Store (EBS) sont soutenus par le stockage AWS S3. L’élagage des ressources est effectué régulièrement pour optimiser l’utilisation de S3 et la performance des clusters.

Note

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

3.6.5. LE VPC
Copier lien

Les clients devraient s’attendre à voir un VPC par cluster. En outre, le VPC a besoin des configurations 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é.
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.

3.6.5.1. Exemple d’architecture VPC
Copier lien

3.6.6. Groupes de sécurité
Copier lien

Les groupes de sécurité AWS fournissent la sécurité au niveau du protocole et de l’accès au port; ils sont associés aux instances EC2 et Elastic Load Balancing. Chaque groupe de sécurité contient un ensemble de règles qui filtrent le trafic entrant et sortant d’une instance EC2. Assurez-vous que les ports requis pour l’installation OpenShift Container Platform sont ouverts sur votre réseau et configurés pour permettre l’accès entre les hôtes.

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

Lorsque vous créez un cluster en utilisant un VPC non géré, vous pouvez ajouter des groupes de sécurité personnalisés 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 la demande d’augmentation du quota AWS, consultez Demander une augmentation de quota.

3.7. Conditions préalables du pare-feu AWS
Copier lien

Lorsque vous utilisez un pare-feu pour contrôler le trafic de sortie d’OpenShift Dedicated, vous devez configurer votre pare-feu pour permettre l’accès à certaines combinaisons de domaines et de ports ci-dessous. Le service OpenShift Dedicated nécessite cet accès pour fournir un service OpenShift entièrement géré.

Conditions préalables

Dans votre AWS Virtual Private Cloud (VPC), vous avez configuré un point de terminaison Amazon S3 Gateway. Ce point de terminaison est nécessaire pour compléter les demandes du cluster vers le service Amazon S3.

Procédure

Autoriser les URL suivantes qui sont utilisées pour installer et télécharger des paquets et des outils:

Expand

Domaine	Le port	Fonction
`Greffe.redhat.io`	443	Fournit des images de conteneur de base.
`à propos de Quay.io`	443	Fournit des images de conteneur de base.
`cdn01.quay.io`	443	Fournit des images de conteneur de base.
`cdn02.quay.io`	443	Fournit des images de conteneur de base.
`cdn03.quay.io`	443	Fournit des images de conteneur de base.
`cdn04.quay.io`	443	Fournit des images de conteneur de base.
`cdn05.quay.io`	443	Fournit des images de conteneur de base.
`cdn06.quay.io`	443	Fournit des images de conteneur de base.
`à propos de SSO.redhat.com`	443	C’est nécessaire. Le site https://console.redhat.com/openshift utilise l’authentification de sso.redhat.com pour télécharger le secret de traction et utiliser les solutions Red Hat SaaS pour faciliter la surveillance de vos abonnements, de l’inventaire des clusters, des rapports de rétrofacturation, etc.
`bienvenue sur Quay-registry.s3.amazonaws.com`	443	Fournit des images de conteneur de base.
`ajouter au panier Quayio-production-s3.s3.amazonaws.com`	443	Fournit des images de conteneur de base.
`Registry.access.redhat.com`	443	Héberge toutes les images du conteneur qui sont stockées sur le catalogue Ecosytem Red Hat. De plus, le registre donne accès à l’outil odo CLI qui aide les développeurs à s’appuyer sur OpenShift et Kubernetes.
`Access.redhat.com`	443	C’est nécessaire. Héberge un magasin de signature dont un client conteneur a besoin pour vérifier les images lors de leur retrait de register.access.redhat.com.
`Registry.connect.redhat.com`	443	Requis pour toutes les images tierces et les opérateurs certifiés.
`console.redhat.com`	443	C’est nécessaire. Autorise les interactions entre le cluster et OpenShift Console Manager pour activer les fonctionnalités, telles que la planification des mises à niveau.
`à propos de SSO.redhat.com`	443	Le site https://console.redhat.com/openshift utilise l’authentification de sso.redhat.com.
`le site pull.q1w2.quay.rhcloud.com`	443	Fournit des images de conteneur de base en tant que repli lorsque quay.io n’est pas disponible.
`catalogue.redhat.com`	443	Les sites Registry.access.redhat.com et https://registry.redhat.io redirigent vers catalog.redhat.com.
`le site OIDC.op1.openshiftapps.com`	443	Utilisé par ROSA pour l’implémentation STS avec la configuration OIDC gérée.

Autoriser les URL de télémétrie suivantes:

Expand

Domaine	Le port	Fonction
`CERT-api.access.redhat.com`	443	Requis pour la télémétrie.
`API.access.redhat.com`	443	Requis pour la télémétrie.
`infogw.api.openshift.com`	443	Requis pour la télémétrie.
`console.redhat.com`	443	Requis pour la télémétrie et Red Hat Insights.
`le site Observatorium-mst.api.openshift.com`	443	Requis pour la télémétrie spécifique à OpenShift gérée.
`bienvenue sur Observatorium.api.openshift.com`	443	Requis pour la télémétrie spécifique à OpenShift gérée.

Les clusters gérés nécessitent d’activer la télémétrie pour permettre à Red Hat de réagir plus rapidement aux problèmes, de mieux soutenir les clients et de mieux comprendre l’impact des mises à niveau des produits sur les clusters. De plus amples renseignements sur la façon dont les données de surveillance de la santé à distance sont utilisées par Red Hat, voir À propos de la surveillance de la santé à distance dans la section Ressources supplémentaires.

Autoriser les URls d’API Amazon Web Services (AWS) suivantes:

Expand

Domaine	Le port	Fonction
`.amazonaws.com`	443	Besoin d’accéder aux services et aux ressources AWS.

Alternativement, si vous choisissez de ne pas utiliser de wildcard pour les API Amazon Web Services (AWS), vous devez autoriser la liste des URL suivantes:

Expand

Domaine	Le port	Fonction
`ec2.amazonaws.com`	443	Il est utilisé pour installer et gérer des clusters dans un environnement AWS.
`événements.<aws_region>.amazonaws.com`	443	Il est utilisé pour installer et gérer des clusters dans un environnement AWS.
`IAM.amazonaws.com`	443	Il est utilisé pour installer et gérer des clusters dans un environnement AWS.
`itinéraire53.amazonaws.com`	443	Il est utilisé pour installer et gérer des clusters dans un environnement AWS.
`à propos de STS.amazonaws.com`	443	Il est utilisé pour installer et gérer des clusters dans un environnement AWS, pour les clusters configurés pour utiliser le point de terminaison global d’AWS STS.
`le site STS.<aws_region>.amazonaws.com`	443	Il est utilisé pour installer et gérer des clusters dans un environnement AWS, pour les clusters configurés pour utiliser des points de terminaison régionalisés pour AWS STS. Consultez les points de terminaison régionalisés AWS STS pour plus d’informations.
`étiquettes.us-east-1.amazonaws.com`	443	Il est utilisé pour installer et gérer des clusters dans un environnement AWS. Ce point de terminaison est toujours nous-Est-1, quelle que soit la région dans laquelle le cluster est déployé.
`ec2.<aws_region>.amazonaws.com`	443	Il est utilisé pour installer et gérer des clusters dans un environnement AWS.
`élastique d’équilibrage.<aws_region>.amazonaws.com`	443	Il est utilisé pour installer et gérer des clusters dans un environnement AWS.
`étiquettes.<aws_region>.amazonaws.com`	443	Autorise l’attribution de métadonnées sur les ressources AWS sous forme de balises.

Autoriser les URL OpenShift suivantes:

Expand

Domaine	Le port	Fonction
`le site Mirror.openshift.com`	443	Il est utilisé pour accéder au contenu et aux images d’installation en miroir. Ce site est également une source de signatures d’images de libération.
`API.openshift.com`	443	Il est utilisé pour vérifier si des mises à jour sont disponibles pour le cluster.

Autoriser l’ingénierie de la fiabilité du site (SRE) et les URL de gestion suivantes:

Expand

Domaine	Le port	Fonction
`API.pagerduty.com`	443	Ce service d’alerte est utilisé par le gestionnaire d’alertes inclus pour envoyer des alertes notifiant Red Hat SRE d’un événement pour agir.
`événements.pagerduty.com`	443	Ce service d’alerte est utilisé par le gestionnaire d’alertes inclus pour envoyer des alertes notifiant Red Hat SRE d’un événement pour agir.
`API.deadmanssnitch.com`	443	Le service d’alerte utilisé par OpenShift Dedicated pour envoyer des pings périodiques indiquant si le cluster est disponible et en cours d’exécution.
`à propos de nosnch.in`	443	Le service d’alerte utilisé par OpenShift Dedicated pour envoyer des pings périodiques indiquant si le cluster est disponible et en cours d’exécution.
`HTTP-inputs-osdsecuritylogs.splunkcloud.com`	443	C’est nécessaire. Utilisé par le splunk-forwarder-operator comme point de terminaison de journalisation à utiliser par Red Hat SRE pour l’alerte log-based.
le site SFTP.access.redhat.com (recommandé)	22	Le serveur SFTP utilisé par l’opérateur must-collectther pour télécharger des journaux de diagnostic pour aider à résoudre les problèmes avec le cluster.

3.8. Limites de compte AWS
Copier lien

Le cluster OpenShift Dedicated utilise un certain nombre de composants Amazon Web Services (AWS), et les limites de service par défaut affectent votre capacité à installer des clusters dédiés OpenShift. Lorsque vous utilisez certaines configurations de cluster, déployez votre cluster dans certaines régions AWS ou exécutez plusieurs clusters à partir de votre compte, vous devrez peut-être demander des ressources supplémentaires pour votre compte AWS.

Le tableau suivant résume les composants AWS dont les limites peuvent affecter votre capacité à installer et à exécuter des clusters dédiés OpenShift.

Expand

Composante	Le nombre de clusters disponibles par défaut	Limite AWS par défaut	Description
Limites d’instance	Varie	Varie	Au minimum, chaque cluster crée les instances suivantes: 1 machine bootstrap, qui est retirée après l’installation 3 nœuds d’avion de contrôle Deux nœuds d’infrastructure pour une seule zone de disponibilité; trois nœuds d’infrascture pour les zones multidisponibilité Deux nœuds ouvriers pour une seule zone de disponibilité; trois nœuds ouvriers pour les zones multidisponibilités Ces nombres de types d’instances sont dans la limite par défaut d’un nouveau compte. Afin de déployer plus de nœuds de travail, de déployer de grandes charges de travail ou d’utiliser un type d’instance différent, passez en revue les limites de votre compte pour vous assurer que votre cluster peut déployer les machines dont vous avez besoin. Dans la plupart des régions, les machines de démarrage et de travail utilisent un m4.large machines et les machines de plan de commande utilisent m4.xlarge instances. Dans certaines régions, y compris toutes les régions qui ne supportent pas ces types d’instances, les instances m5.large et m5.xlarge sont utilisées à la place.
IP élastiques (EIP)	0 à 1	5 EIP par compte	Afin de fournir le cluster dans une configuration hautement disponible, le programme d’installation crée un sous-réseau public et privé pour chaque zone de disponibilité dans une région. Chaque sous-réseau privé nécessite une passerelle NAT, et chaque passerelle NAT nécessite une IP élastique séparée. Consultez la carte de la région AWS pour déterminer le nombre de zones de disponibilité dans chaque région. Afin de profiter de la haute disponibilité par défaut, installez le cluster dans une région avec au moins trois zones de disponibilité. Afin d’installer un cluster dans une région avec plus de cinq zones de disponibilité, vous devez augmenter la limite EIP. Important Afin d’utiliser la région us-east-1, vous devez augmenter la limite d’EIP pour votre compte.
Clouds privés virtuels (VPC)	5	5 VPCS par région	Chaque cluster crée son propre VPC.
Équilibrage de charge élastique (ELB)	3	20 par région	Chaque cluster crée par défaut des balanceurs de charge réseau internes et externes pour le serveur API principal et un balanceur de charge classique unique pour le routeur. Le déploiement de plus d’objets Kubernetes LoadBalancer Service créera des équilibreurs de charge supplémentaires.
Passerelles NAT	5	5 par zone de disponibilité	Le cluster déploie une passerelle NAT dans chaque zone de disponibilité.
Interfaces réseau élastiques (ENIs)	Au moins 12	350 par région	L’installation par défaut crée 21 ENI et un ENI pour chaque zone de disponibilité de votre région. À titre d’exemple, la région us-est-1 contient six zones de disponibilité, de sorte qu’un cluster qui est déployé dans cette zone utilise 27 ENI. Consultez la carte de la région AWS pour déterminer le nombre de zones de disponibilité dans chaque région. Des ENI supplémentaires sont créées pour des machines supplémentaires et des équilibreurs de charge créés par l’utilisation de clusters et des charges de travail déployées.
Passerelle VPC	20	20 par compte	Chaque cluster crée une passerelle VPC unique pour l’accès S3.
Godets S3	99	100 seaux par compte	Étant donné que le processus d’installation crée un seau temporaire et que le composant de registre de chaque cluster crée un seau, vous ne pouvez créer que 99 clusters dédiés OpenShift par compte AWS.
Groupes de sécurité	250	2.500 par compte	Chaque cluster crée 10 groupes de sécurité distincts.

Legal Notice
Copier lien

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

La planification de votre environnement

Aperçu de la planification pour Dédié 4

Chapitre 1. Limites et évolutivitéCopier lienLien copié sur presse-papiers!

1.1. Les maximums de clustersCopier lienLien copié sur presse-papiers!

1.2. Environnement et configuration des tests OpenShift Container PlatformCopier lienLien copié sur presse-papiers!

1.3. Dimensionnement et mise à l’échelle des nœuds de plan de contrôle et d’infrastructureCopier lienLien copié sur presse-papiers!

1.3.1. Dimensionnement des nœuds pendant l’installationCopier lienLien copié sur presse-papiers!

1.3.2. La mise à l’échelle du nœud après l’installationCopier lienLien copié sur presse-papiers!

1.3.3. Considérations de dimensionnement pour les grands groupesCopier lienLien copié sur presse-papiers!

Chapitre 2. Abonnements au cloud client sur GCPCopier lienLien copié sur presse-papiers!

2.1. Comprendre les abonnements au cloud client sur GCPCopier lienLien copié sur presse-papiers!

2.2. Exigences du clientCopier lienLien copié sur presse-papiers!

2.2.1. CompteCopier lienLien copié sur presse-papiers!

2.2.2. Exigences d’accèsCopier lienLien copié sur presse-papiers!

2.2.3. Besoins de soutienCopier lienLien copié sur presse-papiers!

2.2.4. Exigences de sécuritéCopier lienLien copié sur presse-papiers!

2.3. La procédure client requiseCopier lienLien copié sur presse-papiers!

2.3.1. Procédure d’authentification de compte de serviceCopier lienLien copié sur presse-papiers!

2.3.2. La procédure de type d’authentification de la Fédération d’identité de la charge de travailCopier lienLien copié sur presse-papiers!

2.4. Les ressources Google Cloud gérées par Red HatCopier lienLien copié sur presse-papiers!

2.4.1. Compte et rôles de service IAMCopier lienLien copié sur presse-papiers!

2.4.2. Groupe IAM et rôlesCopier lienLien copié sur presse-papiers!

2.5. Infrastructure GCP provisionnéeCopier lienLien copié sur presse-papiers!

2.5.1. Calcul des instancesCopier lienLien copié sur presse-papiers!

2.5.2. Le stockageCopier lienLien copié sur presse-papiers!

2.5.3. LE VPCCopier lienLien copié sur presse-papiers!

2.5.4. Les servicesCopier lienLien copié sur presse-papiers!

2.6. Limites de compte GCPCopier lienLien copié sur presse-papiers!

2.7. Conditions préalables du pare-feu GCPCopier lienLien copié sur presse-papiers!

2.8. Ressources supplémentairesCopier lienLien copié sur presse-papiers!

Chapitre 3. Abonnements au cloud client sur AWSCopier lienLien copié sur presse-papiers!

3.1. Comprendre les abonnements au cloud client sur AWSCopier lienLien copié sur presse-papiers!

3.2. Exigences du clientCopier lienLien copié sur presse-papiers!

3.2.1. CompteCopier lienLien copié sur presse-papiers!

3.2.2. Exigences d’accèsCopier lienLien copié sur presse-papiers!

3.2.3. Besoins de soutienCopier lienLien copié sur presse-papiers!

3.2.4. Exigences de sécuritéCopier lienLien copié sur presse-papiers!

3.3. La procédure client requiseCopier lienLien copié sur presse-papiers!

3.4. La politique minimale de contrôle du service requis (SCP)Copier lienLien copié sur presse-papiers!

3.5. Les références de Red Hat gérées par IAM pour AWSCopier lienLien copié sur presse-papiers!

3.5.1. Les politiques de l’IAMCopier lienLien copié sur presse-papiers!

3.5.2. Les utilisateurs de l’IAMCopier lienLien copié sur presse-papiers!

3.5.3. Les rôles de l’IAMCopier lienLien copié sur presse-papiers!

3.6. Infrastructure AWS provisionnéeCopier lienLien copié sur presse-papiers!

3.6.1. Instances AWS Elastic Computing (EC2)Copier lienLien copié sur presse-papiers!

3.6.2. AWS Elastic Block Store (EBS) stockageCopier lienLien copié sur presse-papiers!

3.6.3. Équilibrage de charge élastique (ELB)Copier lienLien copié sur presse-papiers!

3.6.4. Le stockage S3Copier lienLien copié sur presse-papiers!

3.6.5. LE VPCCopier lienLien copié sur presse-papiers!

3.6.5.1. Exemple d’architecture VPCCopier lienLien copié sur presse-papiers!

3.6.6. Groupes de sécuritéCopier lienLien copié sur presse-papiers!

3.6.6.1. Groupes de sécurité personnalisés supplémentairesCopier lienLien copié sur presse-papiers!

3.7. Conditions préalables du pare-feu AWSCopier lienLien copié sur presse-papiers!

3.8. Limites de compte AWSCopier lienLien copié sur presse-papiers!

Legal Notice Copier lienLien copié sur presse-papiers!

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Rendre l’open source plus inclusif

À propos de Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

Chapitre 1. Limites et évolutivité
Copier lien

1.1. Les maximums de clusters
Copier lien

1.2. Environnement et configuration des tests OpenShift Container Platform
Copier lien

1.3. Dimensionnement et mise à l’échelle des nœuds de plan de contrôle et d’infrastructure
Copier lien

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

1.3.2. La mise à l’échelle du nœud après l’installation
Copier lien

1.3.3. Considérations de dimensionnement pour les grands groupes
Copier lien

Chapitre 2. Abonnements au cloud client sur GCP
Copier lien

2.1. Comprendre les abonnements au cloud client sur GCP
Copier lien

2.2. Exigences du client
Copier lien

2.2.1. Compte
Copier lien

2.2.2. Exigences d’accès
Copier lien

2.2.3. Besoins de soutien
Copier lien

2.2.4. Exigences de sécurité
Copier lien

2.3. La procédure client requise
Copier lien

2.3.1. Procédure d’authentification de compte de service
Copier lien

2.3.2. La procédure de type d’authentification de la Fédération d’identité de la charge de travail
Copier lien

2.4. Les ressources Google Cloud gérées par Red Hat
Copier lien

2.4.1. Compte et rôles de service IAM
Copier lien

2.4.2. Groupe IAM et rôles
Copier lien

2.5. Infrastructure GCP provisionnée
Copier lien

2.5.1. Calcul des instances
Copier lien

2.5.2. Le stockage
Copier lien

2.5.3. LE VPC
Copier lien

2.5.4. Les services
Copier lien

2.6. Limites de compte GCP
Copier lien

2.7. Conditions préalables du pare-feu GCP
Copier lien

2.8. Ressources supplémentaires
Copier lien

Chapitre 3. Abonnements au cloud client sur AWS
Copier lien

3.1. Comprendre les abonnements au cloud client sur AWS
Copier lien

3.2. Exigences du client
Copier lien

3.2.1. Compte
Copier lien

3.2.2. Exigences d’accès
Copier lien

3.2.3. Besoins de soutien
Copier lien

3.2.4. Exigences de sécurité
Copier lien

3.3. La procédure client requise
Copier lien

3.4. La politique minimale de contrôle du service requis (SCP)
Copier lien

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

3.5.1. Les politiques de l’IAM
Copier lien

3.5.2. Les utilisateurs de l’IAM
Copier lien

3.5.3. Les rôles de l’IAM
Copier lien

3.6. Infrastructure AWS provisionnée
Copier lien

3.6.1. Instances AWS Elastic Computing (EC2)
Copier lien

3.6.2. AWS Elastic Block Store (EBS) stockage
Copier lien

3.6.3. Équilibrage de charge élastique (ELB)
Copier lien

3.6.4. Le stockage S3
Copier lien

3.6.5. LE VPC
Copier lien

3.6.5.1. Exemple d’architecture VPC
Copier lien

3.6.6. Groupes de sécurité
Copier lien

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

3.7. Conditions préalables du pare-feu AWS
Copier lien

3.8. Limites de compte AWS
Copier lien

Legal Notice
Copier lien