Créez un cluster ROSA classique qui utilise AWS PrivateLink

ROSAles clusters classiques peuvent être déployés de différentes manières : public, privé ou privé avec AWS PrivateLink. Pour plus d'informations sur la ROSA version classique, consultezModèles d'architecture. Pour les cluster configurations publiques et privées, ils OpenShift cluster ont accès à Internet et la confidentialité est définie sur les charges de travail des applications au niveau de la couche application.

Si vous souhaitez que les charges de travail cluster et les charges de travail des applications soient privées, vous pouvez effectuer la configuration AWS PrivateLink avec la ROSA version classique. AWS PrivateLink est une technologie hautement disponible et évolutive qui permet ROSA de créer une connexion privée entre le ROSA service et les ressources du cluster dans le compte AWS client. L'équipe d' AWS PrivateLink ingénierie de fiabilité des sites Red Hat (SRE) peut ainsi accéder au cluster à des fins de support et de correction en utilisant un sous-réseau privé connecté au point de terminaison du AWS PrivateLink cluster.

Pour plus d'informations AWS PrivateLink, voir Qu'est-ce que c'est AWS PrivateLink ?

Prérequis

Effectuez les actions préalables répertoriées dansConfigurer pour utiliser ROSA.

Création Amazon VPC d'une architecture pour le cluster

Pour créer une solution ROSA cluster qui utilise AWS PrivateLink, vous devez d'abord configurer votre propre Amazon VPC architecture dans laquelle déployer votre solution. La procédure suivante utilise le AWS CLI pour créer un sous-réseau public et privé dans une seule zone de disponibilité pour un cluster mono-AZ. Toutes les cluster ressources se trouvent dans le sous-réseau privé. Le sous-réseau public achemine le trafic sortant à l'aide d'une NAT passerelle vers Internet.

Cet exemple utilise le CIDR bloc 10.0.0.0/16 pour le Amazon VPC. Vous pouvez toutefois choisir un autre CIDR bloc. Pour plus d'informations, consultez la section VPCDimensionnement.

Important

Si Amazon VPC les exigences ne sont pas satisfaites, la création du cluster échoue.

1. Définissez une variable d'environnement pour le cluster nom en exécutant la commande suivante.

    ROSA_CLUSTER_NAME=rosa-hcp

2. Créez un VPC avec un 10.0.0.0/16 CIDR bloc.

    aws ec2 create-vpc --cidr-block 10.0.0.0/16 --query Vpc.VpcId --output text

   La commande précédente renvoie l'ID du nouveauVPC. Voici un exemple de sortie.

   vpc-0410832ee325aafea

3. À l'aide de l'VPCID de l'étape précédente, VPC balisez la ROSA_CLUSTER_NAME variable using.

   aws ec2 create-tags --resources <VPC_ID_VALUE> --tags Key=Name,Value=$ROSA_CLUSTER_NAME

4. Activez la prise en charge des DNS noms d'hôte sur le. VPC

   aws ec2 modify-vpc-attribute --vpc-id <VPC_ID_VALUE> --enable-dns-hostnames

5. Créez un sous-réseau public dans le 10.0.1.0/24 CIDR bloc VPC with a, en spécifiant la zone de disponibilité dans laquelle la ressource doit être créée.

   Important

   ROSAavec HCP exige que les clients configurent au moins un sous-réseau public et privé par zone de disponibilité utilisée pour créer des clusters. Pour les clusters mono-AZ, une seule zone de disponibilité est nécessaire. Pour les clusters multi-AZ, trois zones de disponibilité sont nécessaires. Si ces conditions ne sont pas remplies, la création du cluster échoue.

   Note

   Lorsque vous créez des sous-réseaux, assurez-vous qu'ils sont créés dans une zone de disponibilité dans laquelle des types d' ROSA instances sont disponibles. Si vous ne choisissez pas de zone de disponibilité spécifique, le sous-réseau est créé dans l'une des zones de disponibilité Région AWS que vous spécifiez.

   Pour spécifier une zone de disponibilité spécifique, utilisez l'--availability zoneargument de la create-subnet commande. Vous pouvez utiliser la rosa list instance-types commande pour répertorier tous les types d' ROSA instances disponibles. Pour vérifier si un type d'instance est disponible pour une zone de disponibilité donnée, utilisez la commande suivante.

   aws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=<availability_zone> --region <region> --output text | egrep "<instance_type>"

   aws ec2 create-subnet --vpc-id <VPC_ID_VALUE> --cidr-block 10.0.1.0/24 --availability-zone <AZ_NAME> --query Subnet.SubnetId --output text

   La commande précédente renvoie l'ID du nouveau sous-réseau. Voici un exemple de sortie.

   subnet-0b6a7e8cbc8b75920

6. À l'aide de l'ID de sous-réseau indiqué à l'étape précédente, balisez le sous-réseau à l'aide de la ROSA_CLUSTER_NAME-public variable.

   aws ec2 create-tags --resources <PUBLIC_SUBNET_ID> --tags Key=Name,Value=$ROSA_CLUSTER_NAME-public

7. Créez un sous-réseau privé dans le 10.0.0.0/24 CIDR bloc VPC with a, en spécifiant la même zone de disponibilité que celle dans laquelle le sous-réseau public a été déployé.

   aws ec2 create-subnet --vpc-id <VPC_ID_VALUE> --cidr-block 10.0.0.0/24 --availability-zone <AZ_NAME> --query Subnet.SubnetId --output text

   La commande précédente renvoie l'ID du nouveau sous-réseau. Voici un exemple de sortie.

   subnet-0b6a7e8cbc8b75920

8. À l'aide de l'ID de sous-réseau indiqué à l'étape précédente, balisez le sous-réseau à l'aide de la ROSA_CLUSTER_NAME-private variable.

   aws ec2 create-tags --resources <PRIVATE_SUBNET_ID> --tags Key=Name,Value=$ROSA_CLUSTER_NAME-private

9. Créez une passerelle Internet pour le trafic sortant et connectez-la auVPC.

   aws ec2 create-internet-gateway --query InternetGateway.InternetGatewayId --output text
   
   aws ec2 attach-internet-gateway --vpc-id <VPC_ID_VALUE> --internet-gateway-id <IG_ID_VALUE>

10. Marquez la passerelle Internet avec la ROSA_CLUSTER_NAME variable.

    aws ec2 create-tags --resources <IG_ID_VALUE> --tags Key=Name,Value=$ROSA_CLUSTER_NAME

11. Créez une table de routage pour le trafic sortant, associez-la au sous-réseau public et configurez le trafic pour qu'il soit acheminé vers la passerelle Internet.

    aws ec2 create-route-table --vpc-id <VPC_ID_VALUE> --query RouteTable.RouteTableId --output text
    
    aws ec2 associate-route-table --subnet-id <PUBLIC_SUBNET_ID> --route-table-id <PUBLIC_RT_ID>
    
    aws ec2 create-route --route-table-id <PUBLIC_RT_ID> --destination-cidr-block 0.0.0.0/0 --gateway-id <IG_ID_VALUE>

12. Marquez la table de routage publique avec la ROSA_CLUSTER_NAME variable et vérifiez que la table de routage a été correctement configurée.

    aws ec2 create-tags --resources <PUBLIC_RT_ID> --tags Key=Name,Value=$ROSA_CLUSTER_NAME
    
    aws ec2 describe-route-tables --route-table-id <PUBLIC_RT_ID>

13. Créez une NAT passerelle dans le sous-réseau public avec une adresse IP élastique pour permettre le trafic vers le sous-réseau privé.

    aws ec2 allocate-address --domain vpc --query AllocationId --output text
    
    aws ec2 create-nat-gateway --subnet-id <PUBLIC_SUBNET_ID> --allocation-id <EIP_ADDRESS>  --query NatGateway.NatGatewayId --output text

14. Ajoutez la $ROSA_CLUSTER_NAME variable à la NAT passerelle et à l'adresse IP élastique.

    aws ec2 create-tags --resources <EIP_ADDRESS>  --resources <NAT_GATEWAY_ID> --tags Key=Name,Value=$ROSA_CLUSTER_NAME

15. Créez une table de routage pour le trafic de sous-réseau privé, associez-la au sous-réseau privé et configurez le trafic pour qu'il soit acheminé vers la NAT passerelle.

    aws ec2 create-route-table --vpc-id <VPC_ID_VALUE> --query RouteTable.RouteTableId --output text
    
    aws ec2 associate-route-table --subnet-id <PRIVATE_SUBNET_ID> --route-table-id <PRIVATE_RT_ID>
    
    aws ec2 create-route --route-table-id <PRIVATE_RT_ID> --destination-cidr-block 0.0.0.0/0 --gateway-id <NAT_GATEWAY_ID>

16. Ajoutez la $ROSA_CLUSTER_NAME-private variable à la table de routage privée et à l'adresse IP élastique.

    aws ec2 create-tags --resources <PRIVATE_RT_ID> <EIP_ADDRESS> --tags Key=Name,Value=$ROSA_CLUSTER_NAME-private

Créez un cluster ROSA classique à l'aide ROSA CLI des AWS PrivateLink

Vous pouvez utiliser le ROSA CLI et {privatelinkg} pour créer une cluster zone de disponibilité unique (mono-AZ) ou plusieurs zones de disponibilité (multi-AZ). Dans les deux cas, la CIDR valeur de votre machine doit correspondre à VPC la CIDR vôtre.

La procédure suivante utilise la rosa create cluster commande pour créer un mono-AZ ROSA cluster. Pour créer un Multi-AZ cluster, spécifiez multi-az dans la commande et le sous-réseau privé IDs pour chaque sous-réseau privé sur lequel vous souhaitez effectuer le déploiement.

Note

Si vous utilisez un pare-feu, vous devez le configurer de manière à ROSA pouvoir accéder aux sites dont il a besoin pour fonctionner.

Pour plus d'informations, consultez les conditions requises pour le AWS pare-feu dans la OpenShift documentation Red Hat.

1. Créez un mono-AZ cluster en exécutant la commande suivante.

   rosa create cluster --private-link --cluster-name=<CLUSTER_NAME> --machine-cidr=10.0.0.0/16 --subnet-ids=<PRIVATE_SUBNET_ID>

   Note

   Pour créer un cluster qui utilise des informations d'identification de courte durée AWS PrivateLink with AWS Security Token Service (AWS STS), ajoutez --sts --mode auto ou --sts --mode manual à la fin de la rosa create cluster commande.

2. Créez les IAM rôles d' cluster opérateur en suivant les instructions interactives.

   rosa create operator-roles --interactive -c <CLUSTER_NAME>

3. Créez le fournisseur OpenID Connect (OIDC) que les cluster opérateurs utilisent pour s'authentifier.

   rosa create oidc-provider --interactive -c <CLUSTER_NAME>

4. Vérifiez l'état de votre cluster.

   rosa describe cluster -c <CLUSTER_NAME>

   Note

   L'affichage du ready statut dans le cluster State champ peut prendre jusqu'à 40 minutes. Si le provisionnement échoue ou ne s'affiche pas au ready bout de 40 minutes, consultezRésolution des problèmes.

   Pour contacter le support Red Hat AWS Support ou obtenir de l'aide, consultezObtenir de ROSA l'aide.

5. Suivez la progression de la cluster création en consultant les journaux du OpenShift programme d'installation.

   rosa logs install -c <CLUSTER_NAME> --watch

Configurer le AWS PrivateLink DNS transfert

Les clusters utilisés AWS PrivateLink créent une zone hébergée publique et une zone hébergée privée dans Route 53. Les enregistrements de la zone hébergée Route 53 privée ne peuvent être résolus qu'à partir de la zone à VPC laquelle ils sont assignés.

La validation Let's Encrypt DNS -01 nécessite une zone publique afin que des certificats valides et approuvés par le public puissent être émis pour le domaine. Les enregistrements de validation sont supprimés une fois la validation de Let's Encrypt terminée. La zone est toujours requise pour la délivrance et le renouvellement de ces certificats, qui sont généralement requis tous les 60 jours. Bien que ces zones semblent généralement vides, une zone publique joue un rôle essentiel dans le processus de validation.

Pour plus d'informations sur les zones hébergées AWS privées, consultez la section Utilisation des zones privées. Pour plus d'informations sur les zones hébergées publiques, consultez la section Utilisation des zones hébergées publiques.

Configuration d'un point de Route 53 Resolver terminaison entrant

Pour autoriser des enregistrements tels que api.<cluster_domain> et pour les *.apps.<cluster_domain> résoudre en dehors deVPC, configurez un point de terminaison Route 53 Resolver entrant.

1. Ouvrez la Route 53 console.

2. Dans le volet de navigation, sous Resolver, sélectionnez Inbound endpoints.

3. Choisissez Configurer les points de terminaison.

4. Dans le coin supérieur droit, utilisez le Région AWS sélecteur pour choisir Région AWS celui qui contient le nom VPC utilisé pour le cluster.

5. Sous Configuration de base, choisissez Inbound only, puis Next.

6. Sur la page Configurer le point de terminaison entrant, complétez la section Paramètres généraux pour le point de terminaison entrant. Sous Groupe de sécurité pour ce point de terminaison, choisissez un groupe de sécurité qui autorise le TCP trafic entrant UDP et en provenance du réseau distant sur le port de destination 53.

7. Dans la section Adresse IP, choisissez les zones de disponibilité et les sous-réseaux privés utilisés lors de la création du cluster, puis choisissez Next.

8. (Facultatif) Complétez la section Balises.

9. Sélectionnez Envoyer.

Configurer DNS le transfert pour le cluster

Une fois que le point de terminaison Route 53 Resolver interne est associé et opérationnel, configurez le DNS transfert afin que les DNS requêtes puissent être traitées par les serveurs désignés sur votre réseau.

1. Configurez votre réseau d'entreprise pour transférer les DNS requêtes vers les adresses IP du domaine de premier niveau, telles quedrow-pl-01.htno.p1.openshiftapps.com.

2. Si vous transférez DNS des requêtes de l'un VPC à l'autreVPC, suivez les instructions de la section Gestion des règles de transfert.

3. Si vous configurez votre DNS serveur réseau distant, consultez la documentation de votre DNS serveur spécifique pour configurer le DNS transfert sélectif pour le domaine de cluster installé.

Configuration d'un fournisseur d'identité et autorisation cluster d'accès

ROSA inclut un OAuth serveur intégré. Une fois votre ROSA cluster identifiant créé, vous devez le configurer OAuth pour utiliser un fournisseur d'identité. Vous pouvez ensuite ajouter des utilisateurs à votre fournisseur d'identité configuré pour leur accorder l'accès à votre cluster. Vous pouvez accorder ces utilisateurs cluster-admin ou dedicated-admin autorisations selon les besoins.

Vous pouvez configurer différents types de fournisseurs d'identité pour votre cluster. Les types pris en charge incluent GitHub Enterprise GitHub GitLab, GoogleLDAP, OpenID Connect et les fournisseurs HTPasswd d'identité.

Important

Le fournisseur HTPasswd d'identité est inclus uniquement pour permettre la création d'un seul utilisateur administrateur statique. HTPasswdn'est pas pris en charge en tant que fournisseur d'identité à usage général pour. ROSA

La procédure suivante configure un fournisseur d' GitHub identité à titre d'exemple. Pour obtenir des instructions sur la configuration de chacun des types de fournisseurs d'identité pris en charge, consultez la section Configuration des fournisseurs d'identité pour AWS STS.

1. Accédez à github.com et connectez-vous à votre GitHub compte.

2. Si vous n'avez aucune GitHub organisation à utiliser pour vous fournir des identités ROSA cluster, créez-en une. Pour plus d'informations, consultez les étapes décrites dans la GitHub documentation.

3. À l'aide ROSA CLI du mode interactif, configurez un fournisseur d'identité pour votre cluster en exécutant la commande suivante.

   rosa create idp --cluster=<CLUSTER_NAME> --interactive

4. Suivez les instructions de configuration affichées dans le résultat pour restreindre cluster l'accès aux membres de votre GitHub organisation.

   I: Interactive mode enabled.
   Any optional fields can be left empty and a default will be selected.
   ? Type of identity provider: github
   ? Identity provider name: github-1
   ? Restrict to members of: organizations
   ? GitHub organizations: <GITHUB_ORG_NAME>
   ? To use GitHub as an identity provider, you must first register the application:
     - Open the following URL:
       https://github.com/organizations/<GITHUB_ORG_NAME>/settings/applications/new?oauth_application%5Bcallback_url%5D=https%3A%2F%2Foauth-openshift.apps.<CLUSTER_NAME>/<RANDOM_STRING>.p1.openshiftapps.com%2Foauth2callback%2Fgithub-1&oauth_application%5Bname%5D=<CLUSTER_NAME>&oauth_application%5Burl%5D=https%3A%2F%2Fconsole-openshift-console.apps.<CLUSTER_NAME>/<RANDOM_STRING>.p1.openshiftapps.com
     - Click on 'Register application'
   ...

5. Ouvrez le URL dans la sortie, en le <GITHUB_ORG_NAME> remplaçant par le nom de votre GitHub organisation.

6. Sur la page GitHub Web, choisissez Enregistrer une application pour enregistrer une nouvelle OAuth application dans votre GitHub organisation.

7. Utilisez les informations de la GitHub OAuth page pour remplir les autres invites rosa create idp interactives, en remplaçant <GITHUB_CLIENT_ID> et <GITHUB_CLIENT_SECRET> par les informations d'identification de votre GitHub OAuth application.

   ...
   ? Client ID: <GITHUB_CLIENT_ID>
   ? Client Secret: [? for help] <GITHUB_CLIENT_SECRET>
   ? GitHub Enterprise Hostname (optional):
   ? Mapping method: claim
   I: Configuring IDP for cluster '<CLUSTER_NAME>'
   I: Identity Provider 'github-1' has been created.
      It will take up to 1 minute for this configuration to be enabled.
      To add cluster administrators, see 'rosa grant user --help'.
      To login into the console, open https://console-openshift-console.apps.<CLUSTER_NAME>.<RANDOM_STRING>.p1.openshiftapps.com and click on github-1.

   Note

   L'activation de la configuration du fournisseur d'identité peut prendre environ deux minutes. Si vous avez configuré un cluster-admin utilisateur, vous pouvez exécuter la oc get pods -n openshift-authentication --watch commande pour voir les OAuth pods se redéployer avec la configuration mise à jour.

8. Vérifiez que le fournisseur d'identité a été correctement configuré.

   rosa list idps --cluster=<CLUSTER_NAME>

Accorder à l'utilisateur l'accès à un cluster

Vous pouvez accorder à un utilisateur l'accès à votre cluster compte en l'ajoutant au fournisseur d'identité configuré.

La procédure suivante ajoute un utilisateur à une GitHub organisation configurée pour l'attribution d'identités au cluster.

1. Accédez à github.com et connectez-vous à votre GitHub compte.

2. Invitez les utilisateurs qui ont besoin cluster d'accéder à votre GitHub organisation. Pour plus d'informations, consultez la section Inviter des utilisateurs à rejoindre votre organisation dans la GitHub documentation.

Configuration cluster-admin des autorisations

1. Accordez les cluster-admin autorisations à l'aide de la commande suivante. Remplacez <IDP_USER_NAME> et <CLUSTER_NAME> par votre nom d'utilisateur et de cluster.

   rosa grant user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

2. Vérifiez que l'utilisateur est répertorié comme membre du cluster-admins groupe.

   rosa list users --cluster=<CLUSTER_NAME>

Configuration dedicated-admin des autorisations

1. Accordez les dedicated-admin autorisations à l'aide de la commande suivante. Remplacez <IDP_USER_NAME> et <CLUSTER_NAME> par votre nom d'utilisateur et votre cluster nom.

   rosa grant user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

2. Vérifiez que l'utilisateur est répertorié comme membre du cluster-admins groupe.

   rosa list users --cluster=<CLUSTER_NAME>

Accédez à un cluster via la console Red Hat Hybrid Cloud

Après avoir créé un utilisateur cluster administrateur ou ajouté un utilisateur à votre fournisseur d'identité configuré, vous pouvez vous connecter à votre compte cluster via la Red Hat Hybrid Cloud Console.

1. Procurez-vous la console URL qui vous convient cluster à l'aide de la commande suivante. Remplacez <CLUSTER_NAME> par le nom de votre cluster.

   rosa describe cluster -c <CLUSTER_NAME> | grep Console

2. Accédez à la console URL dans la sortie et connectez-vous.

   • Si vous avez créé un cluster-admin utilisateur, connectez-vous à l'aide des informations d'identification fournies.

   • Si vous avez configuré un fournisseur d'identité pour vous cluster, choisissez le nom du fournisseur d'identité dans la boîte de dialogue Se connecter avec... et répondez aux demandes d'autorisation présentées par votre fournisseur.

Déployer une application depuis le catalogue des développeurs

À partir de la console Red Hat Hybrid Cloud, vous pouvez déployer une application de test Developer Catalog et l'exposer à l'aide d'un itinéraire.

1. Accédez à Red Hat Hybrid Cloud Console et choisissez le cluster dans lequel vous souhaitez déployer l'application.

2. Sur la page du cluster, choisissez Open console.

3. Du point de vue de l'administrateur, choisissez Accueil > Projets > Créer un projet.

4. Entrez un nom pour votre projet et ajoutez éventuellement un nom d'affichage et une description.

5. Choisissez Create pour créer le projet.

6. Passez au point de vue Développeur et choisissez +Ajouter. Assurez-vous que le projet sélectionné est bien celui qui vient d'être créé.

7. Dans la boîte de dialogue Developer Catalog, sélectionnez Tous les services.

8. Sur la page du catalogue pour développeurs, choisissez Langues > dans le JavaScriptmenu.

9. Choisissez Node.js, puis choisissez Create Application pour ouvrir la page Create Source-to-Image Application.

   Note

   Vous devrez peut-être choisir Effacer tous les filtres pour afficher l'option Node.js.

10. Dans la section Git, choisissez Try Sample.

11. Dans le champ Nom, ajoutez un nom unique.

12. Choisissez Créer.

    Note

    Le déploiement de la nouvelle application prend plusieurs minutes.

13. Lorsque le déploiement est terminé, choisissez l'itinéraire URL de l'application.

    Un nouvel onglet du navigateur s'ouvre avec un message similaire au suivant.

    Welcome to your Node.js application on OpenShift

14. (Facultatif) Supprimez l'application et nettoyez les ressources.

    1. Du point de vue de l'administrateur, choisissez Accueil > Projets.

    2. Ouvrez le menu d'actions de votre projet et choisissez Supprimer le projet.

Révoquer cluster-admin les autorisations d'un utilisateur

1. Révoquez les cluster-admin autorisations à l'aide de la commande suivante. Remplacez <IDP_USER_NAME> et <CLUSTER_NAME> par votre nom d'utilisateur et votre cluster nom.

   rosa revoke user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

2. Vérifiez que l'utilisateur n'est pas répertorié comme membre du cluster-admins groupe.

   rosa list users --cluster=<CLUSTER_NAME>

Révoquer dedicated-admin les autorisations d'un utilisateur

1. Révoquez les dedicated-admin autorisations à l'aide de la commande suivante. Remplacez <IDP_USER_NAME> et <CLUSTER_NAME> par votre nom d'utilisateur et votre cluster nom.

   rosa revoke user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>

2. Vérifiez que l'utilisateur n'est pas répertorié comme membre du dedicated-admins groupe.

   rosa list users --cluster=<CLUSTER_NAME>

Révoquer l'accès d'un utilisateur à un cluster

Vous pouvez révoquer cluster l'accès d'un utilisateur du fournisseur d'identité en le supprimant du fournisseur d'identité configuré.

Vous pouvez configurer différents types de fournisseurs d'identité pour votre cluster. La procédure suivante révoque cluster l'accès d'un membre d'une GitHub organisation.

1. Accédez à github.com et connectez-vous à votre GitHub compte.

2. Supprimez l'utilisateur de votre GitHub organisation. Pour plus d'informations, consultez la section Suppression d'un membre de votre organisation dans la GitHub documentation.

Supprimer un cluster et des AWS STS ressources

Vous pouvez utiliser le ROSA CLI pour supprimer un cluster qui utilise AWS Security Token Service (AWS STS). Vous pouvez également utiliser le ROSA CLI pour supprimer les IAM rôles et le OIDC fournisseur créés par ROSA. Pour supprimer les IAM politiques créées par ROSA, vous pouvez utiliser la IAM console.

Important

IAM les rôles et les politiques créés par ROSA peuvent être utilisés par d'autres ROSA clusters du même compte.

1. cluster Supprimez-les et observez les journaux. Remplacez <CLUSTER_NAME> par le nom ou l'identifiant de votre cluster.

   rosa delete cluster --cluster=<CLUSTER_NAME> --watch

   Important

   Vous devez attendre que la cluster suppression soit complète avant de supprimer les IAM rôles, les politiques et le OIDC fournisseur. Les IAM rôles de compte sont nécessaires pour supprimer les ressources créées par le programme d'installation. Les IAM rôles d'opérateur sont nécessaires pour nettoyer les ressources créées par les OpenShift opérateurs. Les opérateurs utilisent le OIDC fournisseur pour s'authentifier.

2. Supprimez le OIDC fournisseur que les cluster opérateurs utilisent pour s'authentifier en exécutant la commande suivante.

   rosa delete oidc-provider -c <CLUSTER_ID> --mode auto

3. Supprimez les rôles d'opérateur spécifiques au cluster. IAM

   rosa delete operator-roles -c <CLUSTER_ID> --mode auto

4. Supprimez les IAM rôles du compte à l'aide de la commande suivante. Remplacez <PREFIX> par le préfixe des IAM rôles de compte à supprimer. Si vous avez spécifié un préfixe personnalisé lors de la création des IAM rôles de compte, spécifiez le ManagedOpenShift préfixe par défaut.

   rosa delete account-roles --prefix <PREFIX> --mode auto

5. Supprimez les IAM politiques créées par ROSA.

   1. Connectez-vous à la console IAM.

   2. Dans le menu de gauche, sous Gestion des accès, sélectionnez Politiques.

   3. Sélectionnez la politique que vous souhaitez supprimer, puis sélectionnez Actions > Supprimer.

   4. Entrez le nom de la politique et choisissez Supprimer.

   5. Répétez cette étape pour supprimer chacune des IAM politiques du cluster.