Administration des clusters

Red Hat OpenShift Service on AWS 4

Configuration de Red Hat OpenShift Service sur les clusters AWS

Red Hat OpenShift Documentation Team

Résumé

Ce document fournit des informations sur la configuration de Red Hat OpenShift Service sur les clusters AWS (ROSA).

Chapitre 1. Les notifications de cluster
Copier lien

Les notifications de cluster sont des messages sur l’état, la santé ou les performances de votre cluster.

Les notifications de cluster sont la principale façon dont Red Hat Site Reliability Engineering (SRE) communique avec vous sur la santé de votre cluster géré. Le SRE peut également utiliser des notifications de cluster pour vous inviter à effectuer une action afin de résoudre ou d’empêcher un problème avec votre cluster.

Les propriétaires de clusters et les administrateurs doivent régulièrement examiner et agir les notifications de clusters pour s’assurer que les clusters restent en bonne santé et pris en charge.

Dans l’onglet Historique des clusters de votre cluster, vous pouvez afficher les notifications de cluster dans la console de cloud hybride Red Hat. Par défaut, seul le propriétaire du cluster reçoit des notifications de cluster sous forme d’e-mails. Lorsque d’autres utilisateurs doivent recevoir des e-mails de notification en cluster, ajoutez chaque utilisateur comme contact de notification pour votre cluster.

1.2. À quoi s’attendre des notifications de cluster
Copier lien

En tant qu’administrateur de cluster, vous devez savoir quand et pourquoi les notifications de cluster sont envoyées, ainsi que leurs types et niveaux de gravité, afin de comprendre efficacement les besoins de santé et d’administration de votre cluster.

1.2.1. La politique de notification par groupe
Copier lien

Les notifications de cluster sont conçues pour vous tenir informé de la santé de votre cluster et des événements à fort impact qui l’affectent.

La plupart des notifications de cluster sont générées et envoyées automatiquement pour vous assurer que vous êtes immédiatement informé des problèmes ou des changements importants à l’état de votre cluster.

Dans certaines situations, Red Hat Site Reliability Engineering (SRE) crée et envoie des notifications de cluster pour fournir un contexte supplémentaire et des conseils pour un problème complexe.

Les notifications de cluster ne sont pas envoyées pour les événements à faible impact, les mises à jour de sécurité à faible risque, les opérations et la maintenance de routine, ou les problèmes transitoires mineurs qui sont rapidement résolus par SRE.

Les services Red Hat envoient automatiquement des notifications lorsque:

Les contrôles de surveillance de la santé ou de vérification de l’environnement à distance détectent un problème dans votre cluster, par exemple lorsqu’un nœud de travail a peu d’espace disque.
Des événements importants du cycle de vie des clusters se produisent, par exemple, lorsque la maintenance ou les mises à niveau programmées commencent, ou que les opérations de cluster sont touchées par un événement, mais ne nécessitent pas d’intervention du client.
D’importants changements de gestion des clusters se produisent, par exemple, lorsque la propriété de clusters ou le contrôle administratif est transféré d’un utilisateur à un autre.
L’abonnement à votre cluster est modifié ou mis à jour, par exemple lorsque Red Hat met à jour les conditions d’abonnement ou les fonctionnalités disponibles pour votre cluster.

La SRE crée et envoie des notifications lorsque:

L’incident entraîne une dégradation ou une panne qui affecte la disponibilité ou les performances de votre cluster, par exemple, votre fournisseur de cloud a une panne régionale. La SRE envoie des notifications ultérieures pour vous informer de l’état d’avancement de la résolution des incidents et lorsque l’incident est résolu.
Des failles de sécurité, des failles de sécurité ou des activités inhabituelles sont détectées sur votre cluster.
Le Red Hat détecte que les changements que vous avez apportés sont en train de créer ou peuvent entraîner une instabilité des clusters.
Le Red Hat détecte que vos charges de travail causent une dégradation des performances ou une instabilité dans votre cluster.

1.2.2. Les niveaux de gravité de la notification par groupe
Copier lien

Chaque notification de cluster a un niveau de gravité associé pour vous aider à identifier les notifications ayant le plus d’impact sur votre entreprise. Dans l’onglet Historique des clusters de votre cluster, vous pouvez filtrer les notifications en fonction de ces niveaux de gravité dans la console de cloud hybride Red Hat.

Le Red Hat utilise les niveaux de sévérité suivants pour les notifications en grappe, de la plupart au moins sévère:

Critique: Des mesures immédiates sont nécessaires. « une ou plusieurs fonctions clés d’un service ou d’un cluster ne fonctionnent pas, ou cesseront de fonctionner bientôt. Il est suffisamment important d’alerter le personnel sur appel et d’interrompre les flux de travail réguliers.
A) Majeur: L’action immédiate est fortement recommandée. « une ou plusieurs fonctions clés du cluster cesseront bientôt de fonctionner. Il se peut qu’une question majeure puisse mener à une question critique si elle n’est pas traitée en temps opportun.
Avertissement: Il faut agir dès que possible. B) Une ou plusieurs fonctions clés du cluster ne fonctionnent pas de manière optimale et peuvent se dégrader davantage, mais ne constituent pas un danger immédiat pour le fonctionnement du groupe.
Infos: Aucune action nécessaire. Cette gravité ne décrit pas les problèmes qui doivent être résolus, seulement des informations importantes sur le cycle de vie significatif ou important, le service ou les événements en grappe.
Débogage: Aucune action nécessaire. Les notifications de débogage fournissent des informations de bas niveau sur le cycle de vie, le service ou les événements de cluster moins importants pour aider à déboger un comportement inattendu.

1.2.3. Les types de notification de cluster
Copier lien

Chaque notification de cluster a un type de notification associé pour vous aider à identifier les notifications qui sont pertinentes pour votre rôle et vos responsabilités. Dans l’onglet Historique des clusters de votre cluster, vous pouvez filtrer les notifications de cluster en fonction de ces types dans la console de cloud hybride Red Hat.

Le Red Hat utilise les types de notification suivants pour indiquer la pertinence de la notification.

Gestion des capacités: Les notifications d’événements liés à la mise à jour, à la création ou à la suppression de pools de nœuds, de pools de machines, de répliques de calcul ou de quotas (équilibrage de charge, stockage, etc.).
Accès au cluster: Les notifications pour les événements liés à l’ajout ou à la suppression de groupes, de rôles ou de fournisseurs d’identité, par exemple, lorsque SRE ne peut pas accéder à votre cluster parce que les informations d’identification STS ont expiré, lorsqu’il y a un problème de configuration avec vos rôles AWS, ou lorsque vous ajoutez ou supprimez des fournisseurs d’identité.
Modules complémentaires: Les notifications d’événements liés à la gestion d’add-on ou à la maintenance des mises à niveau pour les add-ons, par exemple, lorsqu’un module est installé, mis à niveau ou supprimé, ou ne peuvent pas être installés en raison d’exigences non satisfaites.
Configuration du cluster: Les notifications pour les événements d’accord de cluster, la surveillance de la charge de travail et les vérifications en vol.
Cycle de vie des clusters: Les notifications pour la création, la suppression et l’enregistrement de ressources de cluster ou de cluster, ou la modification de l’état du cluster ou de la ressource (par exemple, prêt ou hibernation).
La mise en réseau de clusters: Les notifications liées au réseau de clusters, y compris le proxy HTTP/S, le routeur et l’état d’entrée.
La propriété des clusters: Les notifications liées au transfert de propriété de cluster d’un utilisateur à un autre.
La mise à l’échelle des clusters: Les notifications liées à la mise à jour, à la création ou à la suppression de pools de nœuds, de pools de machines, de répliques de calcul ou de quota.
La sécurité des clusters: Les événements liés à la sécurité des clusters, par exemple, un nombre accru de tentatives d’accès manquées, de mises à jour de paquets de confiance ou de mises à jour logicielles ayant un impact sur la sécurité.
Abonnement au cluster: Expiration de cluster, notifications de cluster d’essai, ou passage de Free to Pay.
Les mises à jour des clusters: Ce qui concerne les mises à niveau, telles que la maintenance ou l’activation des mises à niveau.
Assistance à la clientèle: Des mises à jour sur l’état de l’affaire de soutien.
La notification générale: Le type de notification par défaut. Ceci n’est utilisé que pour les notifications qui n’ont pas une catégorie plus spécifique.

1.3. Affichage des notifications de cluster à l’aide de la console Red Hat Hybrid Cloud
Copier lien

Les notifications de cluster fournissent des informations importantes sur la santé de votre cluster. Dans l’onglet Historique du cluster, vous pouvez afficher les notifications envoyées à votre cluster dans la console de cloud hybride Red Hat.

Conditions préalables

Connectez-vous à la console hybride Cloud.

Procédure

Accédez à la page Clusters de la console hybride Cloud.
Cliquez sur le nom de votre cluster pour accéder à la page de détails du cluster.
Cliquez sur l’onglet Historique du cluster.
Les notifications de cluster apparaissent sous l’en-tête de l’historique du cluster.
Facultatif: Filtre pour les notifications de cluster pertinentes
Les contrôles de filtre permettent de masquer les notifications de cluster qui ne sont pas pertinentes pour vous, afin que vous puissiez vous concentrer sur votre domaine d’expertise ou sur la résolution d’un problème critique. Il est possible de filtrer les notifications en fonction du texte dans la description de la notification, le niveau de gravité, le type de notification, le moment où la notification a été reçue, et quel système ou personne a déclenché la notification.

1.4. Courriels de notification de cluster
Copier lien

Lorsqu’une notification de cluster est envoyée au cluster par défaut, elle est également envoyée sous forme d’e-mail au propriétaire du cluster. Il est possible de configurer d’autres destinataires pour les e-mails de notification afin de s’assurer que tous les utilisateurs appropriés restent informés de l’état du cluster.

1.4.1. Ajout de contacts de notification à votre cluster
Copier lien

Les contacts de notification reçoivent des e-mails lorsque des notifications de cluster sont envoyées au cluster. Par défaut, seul le propriétaire du cluster reçoit des e-mails de notification de cluster. Dans les paramètres de support de votre cluster, vous pouvez configurer d’autres utilisateurs de clusters en tant que contacts de notification supplémentaires.

Conditions préalables

Le cluster est déployé et enregistré sur la console de cloud hybride Red Hat.
En tant que propriétaire du cluster ou en tant qu’utilisateur avec le rôle d’éditeur de clusters, vous êtes connecté à la console hybride Cloud Console.
Le destinataire de la notification prévu a un compte Red Hat Customer Portal associé à la même organisation que le propriétaire du cluster.

Procédure

Accédez à la page Clusters de la console hybride Cloud.
Cliquez sur le nom de votre cluster pour accéder à la page de détails du cluster.
Cliquez sur l’onglet Support.
Dans l’onglet Support, trouvez la section Contacts de notification.
Cliquez sur Ajouter un contact de notification.
Dans le champ Nom d’utilisateur ou e-mail Red Hat, entrez l’adresse e-mail ou le nom d’utilisateur du nouveau destinataire.
Cliquez sur Ajouter un contact.

Étapes de vérification

Le message « Contact de notification ajouté avec succès » s’affiche.

Résolution de problèmes

Le bouton de contact Ajouter une notification est désactivé: Ce bouton est désactivé pour les utilisateurs qui n’ont pas la permission d’ajouter un contact de notification. Connectez-vous à un compte avec le rôle du propriétaire du cluster, de l’éditeur de cluster ou du cluster et essayez à nouveau.
Erreur: impossible de trouver un compte identifié par <nom d’utilisateur> ou <email-address>: Cette erreur se produit lorsque le destinataire de notification prévu ne fait pas partie de la même organisation de compte Red Hat que le propriétaire du cluster. Contactez l’administrateur de votre organisation pour ajouter le destinataire prévu à l’organisation concernée et essayer à nouveau.

1.4.2. La suppression des contacts de notification de votre cluster
Copier lien

Les contacts de notification reçoivent des e-mails lorsque des notifications de cluster sont envoyées au cluster.

Dans les paramètres de support de votre cluster, vous pouvez supprimer les contacts de notification pour les empêcher de recevoir des e-mails de notification.

Conditions préalables

Le cluster est déployé et enregistré sur la console de cloud hybride Red Hat.
En tant que propriétaire du cluster ou en tant qu’utilisateur avec le rôle d’éditeur de clusters, vous êtes connecté à la console hybride Cloud Console.

Procédure

Accédez à la page Clusters de la console hybride Cloud.
Cliquez sur le nom de votre cluster pour accéder à la page de détails du cluster.
Cliquez sur l’onglet Support.
Dans l’onglet Support, trouvez la section Contacts de notification.
Cliquez sur le menu des options à côté du destinataire que vous souhaitez supprimer.
Cliquez sur Supprimer.

Étapes de vérification

Le message « Contact de notification supprimé avec succès » s’affiche.

1.5. Résolution de problèmes
Copier lien

Lorsque vous ne recevez pas d’e-mails de notification de cluster

Assurez-vous que les e-mails envoyés à partir des adresses @redhat.com ne sont pas filtrés hors de votre boîte de réception.
Assurez-vous que votre adresse e-mail correcte est répertoriée comme contact de notification pour le cluster.
Demandez au propriétaire ou à l’administrateur du cluster de vous ajouter en tant que contact de notification: Cluster les e-mails de notification.

Dans le cas où votre cluster ne reçoit pas de notifications

Assurez-vous que votre cluster peut accéder aux ressources sur api.openshift.com.
Assurez-vous que votre pare-feu est configuré selon les prérequis documentés : prérequis du pare-feu AWS

Chapitre 2. Configuration des connexions privées
Copier lien

2.1. Configuration des connexions privées
Copier lien

L’accès aux clusters privés peut être mis en œuvre pour répondre aux besoins de votre Red Hat OpenShift Service sur AWS (ROSA).

Procédure

Accédez à votre compte AWS ROSA et utilisez une ou plusieurs des méthodes suivantes pour établir une connexion privée à votre cluster:
- Configurer AWS VPC peering: Activer VPC peering pour acheminer le trafic réseau entre deux adresses IP privées.
- Configurer AWS VPN : Créer un réseau privé virtuel pour connecter en toute sécurité votre réseau privé à votre Amazon Virtual Private Cloud.
- Configuration d’AWS Direct Connect : Configurer AWS Direct Connect pour établir une connexion réseau dédiée entre votre réseau privé et un emplacement AWS Direct Connect.
Configurez un cluster privé sur ROSA.

2.2. Configuration du peering AWS VPC
Copier lien

Cet exemple de processus configure un VPC Amazon Web Services (AWS) contenant un Red Hat OpenShift Service sur AWS cluster pour faire l’expérience d’un autre réseau AWS VPC. Consultez le guide AWS VPC Peering pour plus d’informations sur la création d’une connexion AWS VPC Peering ou pour d’autres configurations possibles.

2.2.1. Conditions de peering VPC
Copier lien

Lors de la mise en place d’une connexion de peering VPC entre deux VPC sur deux comptes AWS distincts, les termes suivants sont utilisés:

Le Red Hat OpenShift Service sur le compte AWS AWS	Le compte AWS qui contient le service Red Hat OpenShift sur le cluster AWS.
Le Red Hat OpenShift Service sur AWS Cluster VPC	Le VPC qui contient le service Red Hat OpenShift sur le cluster AWS.
Compte AWS client	Le service OpenShift OpenShift non rouge sur le compte AWS AWS que vous souhaitez consulter.
Client VPC	Le VPC dans votre compte AWS que vous souhaitez comparer avec.
Client VPC Région	La région où réside le VPC du client.

Note

En juillet 2018, AWS prend en charge l’interrégion VPC peering entre toutes les régions commerciales à l’exclusion de la Chine.

2.2.2. Lancement de la demande de pairs VPC
Copier lien

Il est possible d’envoyer une demande de connexion VPC à partir du service Red Hat OpenShift sur le compte AWS AWS au compte AWS client.

Conditions préalables

Collecter les informations suivantes sur le VPC client requis pour lancer la demande de peering:
- Le numéro de compte AWS du client
- ID de VPC client
- Client VPC Région
- Client VPC CIDR
Consultez le bloc CIDR utilisé par le service OpenShift Red Hat sur AWS Cluster VPC. Lorsqu’il chevauche ou correspond au bloc CIDR pour le VPC Client, il n’est pas possible de regarder entre ces deux VPC; consultez la documentation des Configurations de Peering VPC non prise en charge d’Amazon VPC pour plus de détails. Lorsque les blocs CIDR ne se chevauchent pas, vous pouvez continuer avec la procédure.

Procédure

Connectez-vous à la console Web pour le service Red Hat OpenShift sur le compte AWS et accédez au tableau de bord VPC dans la région où le cluster est hébergé.
Allez à la page Connexions de Peering et cliquez sur le bouton Créer une connexion de Peering.
Vérifiez les détails du compte auquel vous êtes connecté et les détails du compte et du VPC auxquels vous vous connectez:
1. Balise nom de connexion de peering: Définir un nom descriptif pour la connexion VPC Peering.
2. Cliquez sur Red Hat OpenShift Service sur AWS Cluster VPC ID dans la liste déroulante.
3. Compte: Sélectionnez un autre compte et fournissez le numéro de compte AWS du client * (sans tirets).
4. La région: Si la région VPC client diffère de la région actuelle, sélectionnez Une autre région et sélectionnez la région VPC client dans la liste déroulante.
5. Le VPC (Accepter): Définir l’identifiant VPC client.
Cliquez sur Créer une connexion Peering.
Confirmez que la demande entre dans un état en attente. En cas d’échec, confirmez les détails et répétez le processus.

2.2.3. Accepter la demande de pairs VPC
Copier lien

Après avoir créé la connexion de peering VPC, vous devez accepter la demande dans le Compte AWS Client.

Conditions préalables

Initier la demande de pairs VPC.

Procédure

Connectez-vous à la console Web AWS.
Accédez au service VPC.
Allez à Peering Connections.
Cliquez sur En attente d’une connexion de peering.
Confirmez le compte AWS et l’identifiant VPC d’où provient la demande. Cela devrait provenir du service Red Hat OpenShift sur AWS AWS Account et Red Hat OpenShift Service sur AWS Cluster VPC.
Cliquez sur Accepter la demande.

2.2.4. Configuration des tables de routage
Copier lien

Après avoir accepté la demande de peering VPC, les deux VPC doivent configurer leurs itinéraires pour communiquer à travers la connexion de peering.

Conditions préalables

Initier et accepter la demande de pairs VPC.

Procédure

Connectez-vous à la console Web AWS pour le service Red Hat OpenShift sur le compte AWS AWS.
Accédez au Service VPC, puis Routez les Tables.
Choisissez la table de route pour le service OpenShift Red Hat sur AWS Cluster VPC.
Note
Dans certains clusters, il peut y avoir plus d’une table de route pour un VPC particulier. Choisissez celui qui a un certain nombre de sous-réseaux explicitement associés.
Choisissez l’onglet Routes, puis Editez.
Entrez le bloc VPC CIDR Client dans la zone de texte Destination.
Entrez l’ID de connexion Peering dans la zone de texte cible.
Cliquez sur Save.
Il faut compléter le même processus avec le bloc CIDR de l’autre VPC:
1. Connectez-vous à la console Web AWS → Service VPC → Tables de route.
2. Choisissez la table d’itinéraire pour votre VPC.
3. Choisissez l’onglet Routes, puis Editez.
4. Entrez le Red Hat OpenShift Service sur AWS Cluster VPC CIDR bloc dans la zone de texte Destination.
5. Entrez l’ID de connexion Peering dans la zone de texte cible.
6. Cliquez sur Save.

La connexion de peering VPC est maintenant terminée. Il faut suivre la procédure de vérification pour s’assurer que la connectivité à travers la connexion de pairing fonctionne.

2.2.5. La vérification et le dépannage de VPC peering
Copier lien

Après avoir configuré une connexion de peering VPC, il est préférable de confirmer qu’elle a été configurée et fonctionne correctement.

Conditions préalables

Initier et accepter la demande de pairs VPC.
Configurez les tables de routage.

Procédure

Dans la console AWS, regardez la table d’itinéraire pour le cluster VPC qui est jumelé. Assurez-vous que les étapes de configuration des tables de routage ont été suivies et qu’il y a une entrée de table de route pointant la destination de la plage CIDR VPC vers la cible de connexion de peering.
Lorsque les itinéraires sont corrects sur le Red Hat OpenShift Service sur la table d’itinéraire VPC AWS Cluster et sur la table d’itinéraire VPC Client, la connexion doit être testée en utilisant la méthode netcat ci-dessous. En cas de succès des appels de test, le peering VPC fonctionne correctement.
Afin de tester la connectivité réseau à un terminal, nc (ou netcat) est un outil de dépannage utile. Il est inclus dans l’image par défaut et fournit une sortie rapide et claire si une connexion peut être établie:
1. Créez un pod temporaire à l’aide de l’image busybox, qui nettoie après elle-même:
  $ oc run netcat-test \ --image=busybox -i -t \ --restart=Never --rm \ -- /bin/sh
  Copy to Clipboard Toggle word wrap
2. Consultez la connexion à l’aide de nc.
  - Exemple de résultats de connexion réussis:
    
    / nc -zvv 192.168.1.1 8080 10.181.3.180 (10.181.3.180:8080) open sent 0, rcvd 0
    
    Copy to Clipboard Toggle word wrap
  - Exemple de résultats de connexion échoués:
    
    / nc -zvv 192.168.1.2 8080 nc: 10.181.3.180 (10.181.3.180:8081): Connection refused sent 0, rcvd 0
    
    Copy to Clipboard Toggle word wrap
3. Sortez du conteneur, qui supprime automatiquement le Pod:
  / exit
  Copy to Clipboard Toggle word wrap

2.3. Configuration du VPN AWS
Copier lien

Cet exemple de processus configure un service Red Hat OpenShift d’Amazon Web Services (AWS) sur le cluster AWS pour utiliser le périphérique VPN matériel d’un client.

Note

AWS VPN ne fournit actuellement pas d’option gérée pour appliquer NAT au trafic VPN. Consultez le centre de connaissances AWS pour plus de détails.

Note

Le routage de tout le trafic, par exemple 0.0.0.0/0, via une connexion privée n’est pas pris en charge. Cela nécessite la suppression de la passerelle Internet, qui désactive le trafic de gestion SRE.

Consultez la documentation Amazon VPC VPN pour plus d’informations sur la connexion d’un VPC AWS à des réseaux distants à l’aide d’un périphérique VPN matériel.

2.3.1. Création d’une connexion VPN
Copier lien

Il est possible de configurer un service Red Hat OpenShift d’Amazon Web Services (AWS) sur le cluster AWS pour utiliser le périphérique VPN matériel d’un client en utilisant les procédures suivantes.

Conditions préalables

Le modèle et la version logicielle de périphérique de passerelle VPN matériel, par exemple Cisco ASA en cours d’exécution version 8.3. Consultez le Guide de l’administrateur réseau Amazon VPC pour confirmer si votre périphérique passerelle est pris en charge par AWS.
Adresse IP publique et statique pour le périphérique passerelle VPN.
BGP ou routage statique: si BGP, l’ASN est requis. En cas de routage statique, vous devez configurer au moins une route statique.
Facultatif: IP et port/protocole d’un service accessible pour tester la connexion VPN.

2.3.1.1. Configuration de la connexion VPN
Copier lien

Procédure

Connectez-vous au service Red Hat OpenShift sur AWS Account Dashboard et accédez au tableau de bord VPC.
Cliquez sur Vos VPC et identifiez le nom et l’identifiant VPC pour le VPC contenant le service Red Hat OpenShift sur le cluster AWS.
Dans le tableau de bord VPC, cliquez sur Passerelle client.
Cliquez sur Créer une passerelle client et donnez-lui un nom significatif.
Choisissez la méthode de routage: dynamique ou statique.
Dans le cas de Dynamic, entrez le BGP ASN dans le champ qui apparaît.
Collez dans l’adresse IP de la passerelle VPN.
Cliquez sur Create.
Dans le cas où vous n’avez pas déjà une passerelle privée virtuelle attachée au VPC prévu:
1. À partir du tableau de bord VPC, cliquez sur Virtual Private Gateway.
2. Cliquez sur Créer une passerelle privée virtuelle, donnez-lui un nom significatif et cliquez sur Créer.
3. Laissez l’ASN par défaut Amazon par défaut.
4. Choisissez la passerelle nouvellement créée, cliquez sur Attach à VPC, et attachez-la au cluster VPC que vous avez identifié plus tôt.

2.3.1.2. Établir la connexion VPN
Copier lien

Procédure

À partir du tableau de bord VPC, cliquez sur Connexions VPN Site à Site.
Cliquez sur Créer une connexion VPN.
1. Donnez-lui une étiquette de nom significative.
2. Choisissez la passerelle privée virtuelle créée précédemment.
3. Dans le cas de la passerelle client, sélectionnez Existing.
4. Choisissez le périphérique de passerelle client par nom.
5. Dans le cas où le VPN utilise BGP, sélectionnez Dynamic, autrement, sélectionnez Static. Entrez les CIDR IP statiques. Lorsqu’il existe plusieurs CIDR, ajoutez chaque CIDR en tant qu’autre règle.
6. Cliquez sur Create.
7. Attendez que le statut VPN passe à Disponible, environ 5 à 10 minutes.
Choisissez le VPN que vous venez de créer et cliquez sur Télécharger la configuration.
1. Dans la liste déroulante, sélectionnez le fournisseur, la plate-forme et la version du périphérique de passerelle client, puis cliquez sur Télécharger.
2. La configuration du fournisseur générique est également disponible pour récupérer des informations dans un format texte clair.

Note

Après la connexion VPN a été établie, assurez-vous de configurer Route Propagation ou le VPN peut ne pas fonctionner comme prévu.

Note

À noter les informations de sous-réseau VPC, que vous devez ajouter à votre configuration en tant que réseau distant.

2.3.1.3. Activer la propagation d’itinéraire VPN
Copier lien

Après avoir configuré la connexion VPN, vous devez vous assurer que la propagation de l’itinéraire est activée afin que les itinéraires nécessaires soient ajoutés à la table d’itinéraires du VPC.

Procédure

À partir du tableau de bord VPC, cliquez sur Tables de Route.
Choisissez la table Route privée associée au VPC qui contient votre Red Hat OpenShift Service sur le cluster AWS.
Note
Dans certains clusters, il peut y avoir plus d’une table de route pour un VPC particulier. Choisissez celui qui a un certain nombre de sous-réseaux explicitement associés.
Cliquez sur l’onglet Propagation de route.
Dans le tableau qui apparaît, vous devriez voir la passerelle privée virtuelle que vous avez créée précédemment. Cochez la valeur dans la colonne Propagate.
1. Lorsque Propagate est réglé sur Non, cliquez sur Modifier la propagation de l’itinéraire, cochez la case à cocher Propagate à côté du nom de la passerelle privée virtuelle et cliquez sur Enregistrer.

Après avoir configuré votre tunnel VPN et AWS le détecte comme Up, vos routes statiques ou BGP sont automatiquement ajoutées à la table d’itinéraires.

2.3.2. La vérification de la connexion VPN
Copier lien

Après avoir configuré votre côté du tunnel VPN, vous pouvez vérifier que le tunnel est dans la console AWS et que la connectivité à travers le tunnel fonctionne.

Conditions préalables

Création d’une connexion VPN.

Procédure

Assurez-vous que le tunnel est en haut dans AWS.
1. À partir du tableau de bord VPC, cliquez sur Connexions VPN.
2. Choisissez la connexion VPN que vous avez créée précédemment et cliquez sur l’onglet Détails du tunnel.
3. Il faut être en mesure de voir qu’au moins l’un des tunnels VPN est Up.
Contrôlez la connexion.
Afin de tester la connectivité réseau à un terminal, nc (ou netcat) est un outil de dépannage utile. Il est inclus dans l’image par défaut et fournit une sortie rapide et claire si une connexion peut être établie:
1. Créez un pod temporaire à l’aide de l’image busybox, qui nettoie après elle-même:
  $ oc run netcat-test \ --image=busybox -i -t \ --restart=Never --rm \ -- /bin/sh
  Copy to Clipboard Toggle word wrap
2. Consultez la connexion à l’aide de nc.
  - Exemple de résultats de connexion réussis:
    
    / nc -zvv 192.168.1.1 8080 10.181.3.180 (10.181.3.180:8080) open sent 0, rcvd 0
    
    Copy to Clipboard Toggle word wrap
  - Exemple de résultats de connexion échoués:
    
    / nc -zvv 192.168.1.2 8080 nc: 10.181.3.180 (10.181.3.180:8081): Connection refused sent 0, rcvd 0
    
    Copy to Clipboard Toggle word wrap
3. Sortez du conteneur, qui supprime automatiquement le Pod:
  / exit
  Copy to Clipboard Toggle word wrap

2.3.3. Dépannage de la connexion VPN
Copier lien

Le tunnel ne se connecte pas

Lorsque la connexion du tunnel est toujours en panne, il y a plusieurs choses que vous pouvez vérifier:

Le tunnel AWS n’initiera pas de connexion VPN. La tentative de connexion doit être initiée à partir de la passerelle client.
Assurez-vous que votre trafic source provient de la même IP que la passerelle client configurée. AWS déposera silencieusement tout le trafic vers la passerelle dont l’adresse IP source ne correspond pas.
Assurez-vous que votre configuration correspond aux valeurs prises en charge par AWS. Cela inclut les versions IKE, les groupes DH, IKE à vie, et plus encore.
Cochez le tableau d’itinéraire pour le VPC. Assurez-vous que la propagation est activée et qu’il y a des entrées dans la table de route qui ont la passerelle privée virtuelle que vous avez créée plus tôt en tant que cible.
Confirmez que vous n’avez pas de règles de pare-feu qui pourraient causer une interruption.
Vérifiez si vous utilisez un VPN basé sur une stratégie, car cela peut causer des complications en fonction de la façon dont il est configuré.
D’autres étapes de dépannage peuvent être trouvées au centre de connaissances AWS.

Le tunnel ne reste pas connecté

Lorsque la connexion du tunnel a du mal à rester en haut, sachez que toutes les connexions de tunnel AWS doivent être initiées à partir de votre passerelle. Les tunnels AWS n’initient pas de tunnel.

Le Red Hat recommande de configurer un moniteur SLA (Cisco ASA) ou un appareil de votre côté du tunnel qui envoie constamment du trafic "intéressant", par exemple ping, nc ou telnet, à n’importe quelle adresse IP configurée dans la gamme VPC CIDR. Il n’a pas d’importance si la connexion est réussie, juste que le trafic est dirigé vers le tunnel.

Tunnel secondaire dans l’état de Down

Lorsqu’un tunnel VPN est créé, AWS crée un tunnel de basculement supplémentaire. En fonction du périphérique de passerelle, parfois le tunnel secondaire sera vu comme dans l’état Down.

La notification AWS est la suivante:

You have new non-redundant VPN connections

One or more of your vpn connections are not using both tunnels. This mode of
operation is not highly available and we strongly recommend you configure your
second tunnel. View your non-redundant VPN connections.

You have new non-redundant VPN connections

One or more of your vpn connections are not using both tunnels. This mode of
operation is not highly available and we strongly recommend you configure your
second tunnel. View your non-redundant VPN connections.

Copy to Clipboard

Toggle word wrap

2.4. Configuration d’AWS Direct Connect
Copier lien

Ce processus décrit l’acceptation d’une interface virtuelle AWS Direct Connect avec Red Hat OpenShift Service sur AWS. Consultez la documentation des composants AWS Direct Connect pour plus d’informations sur les types et la configuration d’AWS Direct Connect.

2.4.1. AWS Direct Connect méthodes
Copier lien

La connexion Direct Connect nécessite une interface virtuelle hébergée (VIF) connectée à une passerelle Direct Connect (DXGateway), qui est à son tour associée à une passerelle virtuelle (VGW) ou à une passerelle de transit afin d’accéder à un VPC distant dans le même compte ou un autre compte.

Dans le cas où vous n’avez pas de DXGateway existant, le processus typique consiste à créer le VIF hébergé, le DXGateway et le VGW étant créés dans le service Red Hat OpenShift sur le compte AWS AWS.

Lorsque vous avez un DXGateway existant connecté à un ou plusieurs VGW existants, le processus implique le service Red Hat OpenShift sur le compte AWS AWS envoyant une proposition d’association au propriétaire de DXGateway. Le propriétaire de DXGateway doit s’assurer que le CIDR proposé ne sera pas en conflit avec d’autres VGW qu’ils ont associés.

Consultez la documentation AWS suivante pour plus de détails:

Important

Lorsque vous vous connectez à un DXGateway existant, vous êtes responsable des coûts.

Il existe deux options de configuration disponibles:

La méthode 1	Créez le VIF hébergé, puis le DXGateway et le VGW.
La méthode 2	Demandez une connexion via une passerelle Direct Connect existante que vous possédez.

2.4.2. Création de l’interface virtuelle hébergée
Copier lien

Conditions préalables

Collectez Red Hat OpenShift Service sur AWS Account ID.

2.4.2.1. Déterminer le type de connexion Direct Connect
Copier lien

Consultez les détails de l’interface virtuelle Direct Connect pour déterminer le type de connexion.

Procédure

Connectez-vous au service Red Hat OpenShift sur AWS Account Dashboard et sélectionnez la région correcte.
Choisissez Direct Connect dans le menu Services.
Il y aura une ou plusieurs interfaces virtuelles en attente d’être acceptées, sélectionnez l’une d’elles pour afficher le Résumé.
Afficher le type d’interface virtuelle: privé ou public.
Enregistrez la valeur ASN côté Amazon.

Lorsque le type d’interface virtuelle Direct Connect est privé, une passerelle privée virtuelle est créée. Lorsque l’interface virtuelle Direct Connect est publique, une passerelle Direct Connect est créée.

2.4.2.2. Création d’une connexion directe privée
Copier lien

La connexion directe privée est créée si le type d’interface virtuelle Direct Connect est privé.

Procédure

Connectez-vous au service Red Hat OpenShift sur AWS Account Dashboard et sélectionnez la région correcte.
Dans la région AWS, sélectionnez VPC dans le menu Services.
Choisissez les passerelles privées virtuelles à partir des connexions VPN.
Cliquez sur Créer une passerelle privée virtuelle.
Donnez à la passerelle privée virtuelle un nom approprié.
Choisissez Custom ASN et entrez la valeur ASN côté Amazon recueillie précédemment.
Créez la passerelle privée virtuelle.
Cliquez sur la passerelle privée virtuelle nouvellement créée et choisissez Attach to VPC dans l’onglet Actions.
Choisissez le service Red Hat OpenShift sur AWS Cluster VPC dans la liste, et joindre la passerelle privée virtuelle au VPC.
Dans le menu Services, cliquez sur Direct Connect. Choisissez l’une des interfaces virtuelles Direct Connect dans la liste.
Je reconnais que les frais de port Direct Connect s’appliquent une fois que j’ai cliqué sur Accepter le message de connexion, puis choisissez Accepter la connexion.
Choisissez d’accepter la connexion de passerelle privée virtuelle et sélectionnez la passerelle privée virtuelle créée dans les étapes précédentes.
Cliquez sur Accepter pour accepter la connexion.
Répétez les étapes précédentes s’il y a plus d’une interface virtuelle.

2.4.2.3. Création d’une connexion publique directe
Copier lien

La connexion publique directe est créée si le type d’interface virtuelle Direct Connect est public.

Procédure

Connectez-vous au service Red Hat OpenShift sur AWS Account Dashboard et sélectionnez la région correcte.
À partir du Red Hat OpenShift Service sur AWS AWS Account, sélectionnez Direct Connect dans le menu Services.
Choisissez Direct Connect Gateways et créez Direct Connect Gateway.
Donnez à la passerelle Direct Connect un nom approprié.
Dans l’ASN côté Amazon, entrez la valeur ASN côté Amazon collectée précédemment.
Créez la passerelle Direct Connect.
Choisissez Direct Connect dans le menu Services.
Choisissez l’une des interfaces virtuelles Direct Connect dans la liste.
Je reconnais que les frais de port Direct Connect s’appliquent une fois que j’ai cliqué sur Accepter le message de connexion, puis choisissez Accepter la connexion.
Choisissez d’accepter la connexion passerelle Direct Connect et sélectionnez Direct Connect Gateway qui a été créé dans les étapes précédentes.
Cliquez sur Accepter pour accepter la connexion.
Répétez les étapes précédentes s’il y a plus d’une interface virtuelle.

2.4.2.4. La vérification des interfaces virtuelles
Copier lien

Après l’acceptation des interfaces virtuelles Direct Connect, attendez une courte période et visualisez l’état des interfaces.

Procédure

Connectez-vous au service Red Hat OpenShift sur AWS Account Dashboard et sélectionnez la région correcte.
À partir du Red Hat OpenShift Service sur AWS AWS Account, sélectionnez Direct Connect dans le menu Services.
Choisissez l’une des interfaces virtuelles Direct Connect dans la liste.
L’état de l’interface est devenu disponible
Le statut BGP de l’interface est devenu Up.
Il faut répéter cette vérification pour toutes les interfaces de connexion directe restantes.

Après que les interfaces virtuelles Direct Connect soient disponibles, vous pouvez vous connecter au service OpenShift Red Hat sur le tableau de bord AWS de compte AWS et télécharger le fichier de configuration Direct Connect pour la configuration de votre côté.

2.4.3. Connexion à une passerelle de connexion directe existante
Copier lien

Conditions préalables

Confirmez que la gamme CIDR du service OpenShift Red Hat sur AWS VPC ne sera pas en conflit avec les autres VGW que vous avez associés.
Collectez les informations suivantes:
- L’ID Direct Connect Gateway.
- L’ID de compte AWS associé à l’interface virtuelle.
- Le BGP ASN assigné pour le DXGateway. Facultatif : l’ASN par défaut Amazon peut également être utilisé.

Procédure

Connectez-vous au service Red Hat OpenShift sur AWS Account Dashboard et sélectionnez la région correcte.
À partir du Red Hat OpenShift Service sur AWS AWS Account, sélectionnez VPC dans le menu Services.
À partir des connexions VPN, sélectionnez Virtual Private Gateways.
Choisissez Créer une passerelle privée virtuelle.
Donnez à la passerelle privée virtuelle un nom approprié.
Cliquez sur Custom ASN et entrez la valeur ASN côté Amazon recueillie précédemment ou utilisez l’ASN fourni par Amazon.
Créez la passerelle privée virtuelle.
Dans le volet Navigation du Service OpenShift Red Hat sur AWS Account Dashboard, choisissez les passerelles privées virtuelles et sélectionnez la passerelle privée virtuelle. Choisissez Afficher les détails.
Choisissez Direct Connect associations de passerelles et cliquez sur la passerelle Associate Direct Connect.
Dans le type de compte d’association, pour le propriétaire du compte, choisissez un autre compte.
Dans le cas du propriétaire de la passerelle Direct Connect, entrez l’ID du compte AWS qui possède la passerelle Direct Connect.
Dans Paramètres d’association, pour Direct Connect Gateway ID, entrez l’ID de la passerelle Direct Connect.
Dans Paramètres d’association, pour le propriétaire de l’interface virtuelle, entrez l’ID du compte AWS qui possède l’interface virtuelle pour l’association.
Facultatif: Ajoutez des préfixes aux préfixes autorisés, les séparant à l’aide de virgules.
Choisissez la passerelle Associate Direct Connect.
Après l’envoi de la proposition d’association, elle attendra votre acceptation. Les dernières étapes que vous devez effectuer sont disponibles dans la Documentation AWS.

2.4.4. Dépannage Direct Connect
Copier lien

D’autres dépannages peuvent être trouvés dans la documentation AWS Direct Connect.

Chapitre 3. Cluster autoscaling
Copier lien

L’application d’autoscaling à Red Hat OpenShift Service sur les clusters AWS (ROSA) (architecture classique) implique la configuration d’un autoscaleur de cluster puis la configuration d’un autoscaleur de machine pour au moins un pool de machines dans votre cluster.

Important

Il est possible de configurer le cluster autoscaler uniquement dans les clusters où l’API de machine est opérationnelle.

Il n’y a qu’un seul cluster autoscaler qui peut être créé par cluster.

3.1. À propos du cluster autoscaler
Copier lien

Le cluster autoscaler ajuste la taille d’un service Red Hat OpenShift sur le cluster AWS pour répondre à ses besoins de déploiement actuels. Il utilise des arguments déclaratifs de style Kubernetes pour fournir une gestion de l’infrastructure qui ne repose pas sur des objets d’un fournisseur de cloud spécifique. Le cluster autoscaler a une portée de cluster, et n’est pas associé à un espace de noms particulier.

Le cluster autoscaler augmente la taille du cluster lorsqu’il y a des pods qui n’arrivent pas à planifier l’un des nœuds de travail actuels en raison de ressources insuffisantes ou lorsqu’un autre nœud est nécessaire pour répondre aux besoins de déploiement. Le cluster autoscaler n’augmente pas les ressources de cluster au-delà des limites que vous spécifiez.

Le cluster autoscaler calcule la mémoire totale et le CPU sur tous les nœuds du cluster, même s’il ne gère pas les nœuds de plan de contrôle. Ces valeurs ne sont pas orientées monomachine. Ils constituent une agrégation de toutes les ressources dans l’ensemble du cluster. Ainsi, si vous définissez la limite maximale de ressources de mémoire, le cluster autoscaler inclut tous les nœuds du cluster lors du calcul de l’utilisation actuelle de la mémoire. Ce calcul est ensuite utilisé pour déterminer si le cluster autoscaler a la capacité d’ajouter plus de ressources de travail.

Important

Assurez-vous que la valeur maxNodesTotal dans la définition de ressource ClusterAutoscaler que vous créez est suffisamment grande pour tenir compte du nombre total de machines dans votre cluster. Cette valeur doit englober le nombre de machines de plan de contrôle et le nombre possible de machines de calcul que vous pourriez mettre à l’échelle.

Élimination automatique des nœuds

Chaque 10 secondes, le cluster autoscaler vérifie quels nœuds sont inutiles dans le cluster et les supprime. L’autoscaleur de cluster considère un nœud pour l’enlèvement si les conditions suivantes s’appliquent:

L’utilisation des nœuds est inférieure au seuil d’utilisation des nœuds pour le cluster. Le niveau d’utilisation des nœuds correspond à la somme des ressources demandées divisées par les ressources allouées au nœud. Lorsque vous ne spécifiez pas une valeur dans la ressource personnalisée ClusterAutoscaler, le cluster autoscaler utilise une valeur par défaut de 0,5, ce qui correspond à une utilisation de 50%.
Le cluster autoscaler peut déplacer tous les pods s’exécutant sur le nœud vers les autres nœuds. Le planificateur de Kubernetes est responsable de la planification des pods sur les nœuds.
Le cluster autoscaler n’a pas de mise à l’échelle vers le bas annotation désactivée.

Lorsque les types de gousses suivants sont présents sur un nœud, le cluster autoscaler ne supprimera pas le nœud:

Les pods avec des budgets de perturbation des pod restrictifs (PDB).
Les pods du système Kube qui ne s’exécutent pas sur le nœud par défaut.
Les gousses de système Kube qui n’ont pas de PDB ou qui ont un PDB trop restrictif.
Les pods qui ne sont pas soutenus par un objet de contrôleur tel qu’un déploiement, un ensemble de répliques ou un ensemble étatique.
Gousses avec stockage local.
Des pods qui ne peuvent pas être déplacés ailleurs en raison d’un manque de ressources, de sélecteurs de nœuds incompatibles ou d’affinité, et ainsi de suite.
À moins qu’ils aient également une "cluster-autoscaler.kubernetes.io/safe-to-evict": "vrai" annotation, pods qui ont un "cluster-autoscaler.kubernetes.io/safe-to-evict": "faux" annotation.

À titre d’exemple, vous définissez la limite maximale de CPU à 64 cœurs et configurez le cluster autoscaler pour créer uniquement des machines qui ont 8 cœurs chacun. Lorsque votre cluster commence avec 30 cœurs, le cluster autoscaler peut ajouter jusqu’à 4 nœuds supplémentaires avec 32 cœurs, pour un total de 62.

Limites

Lorsque vous configurez le cluster autoscaler, des restrictions d’utilisation supplémentaires s’appliquent:

Il ne faut pas modifier directement les nœuds qui sont dans les groupes de nœuds autoscalenés. Dans le même groupe de nœuds, tous les nœuds ont la même capacité et les mêmes étiquettes et exécutent les mêmes pods système.
Indiquez les demandes pour vos pods.
Lorsque vous devez éviter que les pods ne soient supprimés trop rapidement, configurez les PDB appropriés.
Confirmez que votre quota de fournisseur de cloud est suffisamment important pour prendre en charge les pools de nœuds maximum que vous configurez.
Il ne faut pas exécuter d’autoscaleurs de groupe de nœuds supplémentaires, en particulier ceux offerts par votre fournisseur de cloud.

Note

Le cluster autoscaler n’ajoute des nœuds dans les groupes de nœuds autoscales que si cela se traduirait par un pod programmé. Lorsque les types de nœuds disponibles ne peuvent pas répondre aux exigences d’une demande de pod, ou si les groupes de nœuds qui pourraient répondre à ces exigences sont à leur taille maximale, l’autoscaleur de cluster ne peut pas augmenter.

Interaction avec d’autres fonctions de planification

Le pod horizontal autoscaler (HPA) et le cluster autoscaler modifient les ressources de cluster de différentes manières. L’HPA modifie le nombre de répliques du déploiement ou de la réplique en fonction de la charge CPU actuelle. En cas d’augmentation de la charge, la HPA crée de nouvelles répliques, quelle que soit la quantité de ressources disponibles pour le cluster. En l’absence de ressources, le cluster autoscaler ajoute des ressources afin que les gousses créées par HPA puissent s’exécuter. En cas de diminution de la charge, la HPA arrête certaines répliques. Lorsque cette action fait que certains nœuds sont sous-utilisés ou complètement vides, le cluster autoscaler supprime les nœuds inutiles.

Le cluster autoscaler prend en compte les priorités des pod. La fonction Pod Priority and Preemption permet de planifier les pods en fonction des priorités si le cluster n’a pas suffisamment de ressources, mais le cluster autoscaler garantit que le cluster dispose de ressources pour exécuter tous les pods. Afin d’honorer l’intention des deux fonctionnalités, le cluster autoscaler inclut une fonction de coupure prioritaire. Cette coupure peut être utilisée pour programmer les pods "meilleur effort", ce qui n’entraîne pas le cluster autoscaler d’augmenter les ressources, mais plutôt de s’exécuter uniquement lorsque des ressources de rechange sont disponibles.

Les gousses de priorité inférieures à la valeur de coupure n’entraînent pas la mise à l’échelle du cluster ou n’empêchent pas le cluster de descendre à l’échelle. Aucun nouveau nœud n’est ajouté pour exécuter les pods, et les nœuds exécutant ces pods peuvent être supprimés sur des ressources gratuites.

3.2. Activer la mise à l’échelle automatique lors de la création de clusters avec OpenShift Cluster Manager
Copier lien

Lors de la création de clusters, vous pouvez utiliser OpenShift Cluster Manager à l’échelle automatique.

Procédure

Lors de la création de cluster, cochez la case Autoscaling Activer. Le bouton Modifier les paramètres de mise à l’échelle du cluster devient sélectionnable.
1. Il est également possible de choisir la quantité minimale ou maximale de nœuds à l’échelle automatique.
Cliquez sur Modifier les paramètres d’autoscaling du cluster.
Éditez les paramètres que vous voulez, puis cliquez sur Fermer.

3.3. Activer l’autoscaling après la création de clusters avec OpenShift Cluster Manager
Copier lien

Après la création de cluster, vous pouvez utiliser OpenShift Cluster Manager.

Procédure

Dans OpenShift Cluster Manager, cliquez sur le nom du cluster que vous souhaitez mettre à l’échelle automatique. La page Aperçu du cluster comporte un élément Autoscaling qui indique s’il est activé ou désactivé.
Cliquez sur l’onglet Machine Pools.
Cliquez sur le bouton Modifier la mise à l’échelle du cluster. La fenêtre Modifier les paramètres de mise à l’échelle du cluster est affichée.
Cliquez sur le cluster Autoscale en haut de la fenêtre. Les paramètres sont désormais modifiables.
Éditez les paramètres que vous voulez, puis cliquez sur Enregistrer.
Cliquez sur le x en haut à droite de l’écran pour fermer la fenêtre des paramètres.

Afin de retourner tous les paramètres de mise à l’échelle automatique sur les paramètres par défaut s’ils ont été modifiés, cliquez sur le bouton Retourner tous les paramètres par défaut.

3.4. Cluster Autoscaling paramètres à l’aide d’OpenShift Cluster Manager
Copier lien

Les tables expliquent tous les paramètres d’interface utilisateur configurables lors de l’utilisation d’autoscaling de cluster avec OpenShift Cluster Manager.

3.4.1. Les paramètres généraux
Copier lien

Expand

Tableau 3.1. Configurations générales configurables pour la mise à l’échelle automatique des clusters lors de l’utilisation du gestionnaire de cluster OpenShift
Le réglage	Description	Le type ou la gamme	Défaut par défaut
`log-verbosity`	Définit le niveau de journal d’autoscaler. La valeur par défaut est 1. Le niveau 4 est recommandé pour le débogage. Le niveau 6 permet presque tout.	`entier`	1
`Skip-nodes-avec-local-stockage`	Dans l’affirmative, le cluster autoscaler ne supprime jamais les nœuds avec des pods avec stockage local, par exemple EmptyDir ou HostPath.	`booléen`	C’est vrai
`le Max-pod-grace-période`	Donne aux pods un temps de terminaison gracieux en quelques secondes avant de baisser.	`entier`	600
`le Max-node-provision-time`	Le temps maximum que le cluster autoscaler attend que les nœuds soient fournis.	`chaîne de caractères`	15M
`le seuil pod-priorité-seuil`	Permet aux utilisateurs de programmer des pods "meilleur effort", qui ne sont pas censés déclencher des actions de cluster autoscaler. Ces gousses ne fonctionnent que lorsque des ressources de rechange sont disponibles.	`entier`	-10
`ignorer-daemonsets-utilisation`	Détermine si le cluster autoscaler ignore les gousses de jeu de démon lors du calcul de l’utilisation des ressources pour la mise à l’échelle.	`booléen`	faux
`équilibre-semblable-node-groupes`	Dans l’affirmative, ce paramètre identifie automatiquement les groupes de nœuds avec le même type d’instance et le même ensemble d’étiquettes et tente de garder les tailles respectives de ces groupes de nœuds équilibrés.	`booléen`	faux
`équilibrage-ignoré-étiquettes`	Cette option spécifie les étiquettes que le cluster autoscaler devrait ignorer lors de l’examen de la similitude du groupe de nœuds. Cette option ne peut pas contenir d’espaces.	`tableau (chaîne)`	Le format doit être une liste d’étiquettes séparées par les virgules.

3.4.2. Limites de ressources
Copier lien

Expand

Tableau 3.2. Configuration des limites de ressources configurables pour l’autoscaling des clusters lors de l’utilisation du gestionnaire de cluster OpenShift
Le réglage	Description	Le type ou la gamme	Défaut par défaut
`coeurs-total-min`	Le nombre minimum de cœurs en cluster. Le cluster autoscaler ne met pas à l’échelle le cluster moins que ce nombre.	`l’objet`	0
`coeurs-total-max`	Le nombre maximum de cœurs en cluster. Le cluster autoscaler ne met pas à l’échelle le cluster supérieur à ce nombre.	`l’objet`	180 * 64 (11520)
`la mémoire totale-min`	Le nombre minimum de gigaoctets de mémoire en cluster. Le cluster autoscaler ne met pas à l’échelle le cluster moins que ce nombre.	`l’objet`	0
`la mémoire-total-max`	Le nombre maximum de gigaoctets de mémoire en cluster. Le cluster autoscaler ne met pas à l’échelle le cluster supérieur à ce nombre.	`l’objet`	180 * 64 * 20 (230400)
`les nœuds Max-total`	Le nombre maximum de nœuds dans tous les groupes de nœuds. Inclut tous les nœuds, pas seulement les nœuds à l’échelle automatique. Le cluster autoscaler ne fait pas croître le cluster plus grand que ce nombre.	`entier`	180
GPUs	Le nombre minimum et maximum de GPU différents en cluster. Le cluster autoscaler ne met pas le cluster à l’échelle inférieure ou supérieure à ces nombres.	`le tableau`	Le format doit être une liste séparée par les virgules de ":<gpu_type> <min>:<max>".

3.4.3. Faites baisser la configuration
Copier lien

Expand

Tableau 3.3. Configurations de mise à l’échelle configurables pour le cluster autoscaling lors de l’utilisation de OpenShift Cluster Manager
Le réglage	Description	Le type ou la gamme	Défaut par défaut
`dégressivité activée`	Le cluster autoscaler devrait-il réduire le cluster?	`booléen`	C’est vrai
`la réduction de l’utilisation-le seuil`	Le niveau d’utilisation des nœuds, défini comme la somme des ressources demandées divisées par capacité, au-dessous duquel un nœud peut être considéré pour réduire l’échelle.	`flotter`	0,5
`la réduction du temps inutile`	Combien de temps un nœud devrait être inutile avant qu’il ne soit admissible à la réduction de l’échelle.	`chaîne de caractères`	10M
`calibrage-delay-après-ajouter`	Combien de temps après l’augmentation de l’échelle de l’évaluation reprend.	`chaîne de caractères`	10M
`échelle-down-delay-après-delete`	Combien de temps après la suppression du nœud cette évaluation d’échelle reprend.	`chaîne de caractères`	0s
`échelle-down-delay-après-échec`	Combien de temps après l’échec de l’échelle d’échelle reprend l’évaluation.	`chaîne de caractères`	3M

3.5. Activer la mise à l’échelle automatique lors de la création de clusters en utilisant le mode interactif avec le ROSA CLI
Copier lien

Il est possible d’utiliser le mode interactif de votre terminal, s’il est disponible, pour définir le comportement d’autoscaling à l’échelle du cluster lors de la création de clusters.

Le mode interactif fournit plus d’informations sur les paramètres configurables disponibles. Le mode interactif effectue également des vérifications de base et des validations prévol, ce qui signifie que si une valeur fournie est invalide, le terminal produit une invitation pour une entrée valide.

Procédure

Lors de la création de cluster, utilisez les paramètres --enable-autoscaling et --interactive pour activer l’autoscaling du cluster:
Exemple :
```
rosa create cluster --cluster-name <cluster_name> --enable-autoscaling --interactive
```
```
$ rosa create cluster --cluster-name <cluster_name> --enable-autoscaling --interactive
```
Copy to Clipboard Toggle word wrap

Note

Lorsque le nom de votre cluster est supérieur à 15 caractères, il contiendra un préfixe de domaine généré automatiquement en tant que sous-domaine pour votre cluster fourni sur *.openshiftapps.com.

Afin de personnaliser le sous-domaine, utilisez l’indicateur --domain-prefix. Le préfixe de domaine ne peut pas dépasser 15 caractères, doit être unique et ne peut pas être modifié après la création de clusters.

Lorsque l’invite suivante apparaît, entrez y pour passer par toutes les options de mise à l’échelle automatique disponibles.

Exemple d’invite interactive

? Configure cluster-autoscaler (optional): [? for help] (y/N) y <enter>

? Configure cluster-autoscaler (optional): [? for help] (y/N) y <enter>

Copy to Clipboard

Toggle word wrap

3.6. Activer l’autoscaling après la création de clusters en utilisant le mode interactif avec le ROSA CLI
Copier lien

Le mode interactif de votre terminal, s’il est disponible, permet de définir le comportement d’autoscaling à l’échelle du cluster après la création de clusters.

Procédure

Après avoir créé un cluster, tapez la commande suivante:
Exemple :
```
rosa create autoscaler --cluster=<mycluster> --interactive
```
```
$ rosa create autoscaler --cluster=<mycluster> --interactive
```
Copy to Clipboard Toggle word wrap
Ensuite, vous pouvez définir tous les paramètres de mise à l’échelle automatique disponibles.

3.7. Activer l’autoscaling lors de la création de clusters avec le ROSA CLI
Copier lien

Il est possible d’utiliser le ROSA CLI (rosa) pour définir le comportement d’autoscaling à l’échelle du cluster lors de la création de clusters. Il est possible d’activer l’autoscaler sur l’ensemble de la machine ou simplement sur un cluster.

Procédure

Lors de la création de cluster, type --enable autoscaling après le nom du cluster pour activer l’autoscaling de machine:

Note

Exemple :

rosa create cluster --cluster-name <cluster_name> --enable-autoscaling

$ rosa create cluster --cluster-name <cluster_name> --enable-autoscaling

Copy to Clipboard

Toggle word wrap

Définissez au moins un paramètre pour activer l’autoscaling du cluster en exécutant la commande suivante:

Exemple :

rosa create cluster --cluster-name <cluster_name> --enable-autoscaling <parameter>

$ rosa create cluster --cluster-name <cluster_name> --enable-autoscaling <parameter>

Copy to Clipboard

Toggle word wrap

3.8. Activer l’autoscaling après la création de clusters avec le ROSA CLI
Copier lien

Il est possible d’utiliser le ROSA CLI (rosa) pour définir l’autoscaling à l’échelle du cluster après la création de clusters.

Procédure

Après avoir créé un cluster, créez l’autoscaler:
Exemple :
```
rosa create autoscaler --cluster=<mycluster>
```
```
$ rosa create autoscaler --cluster=<mycluster>
```
Copy to Clipboard Toggle word wrap
- Il est également possible de créer l’autoscaler avec des paramètres spécifiques à l’aide de la commande suivante:
  Exemple :
  $ rosa create autoscaler --cluster=<mycluster> <parameter>
  
  Copy to Clipboard Toggle word wrap

Les prochaines étapes

Activer l’autoscaling après la création de clusters avec le ROSA CLI

3.9. Éditer l’autoscaling après la création de cluster avec le ROSA CLI
Copier lien

Après la création de l’autoscaler, vous pouvez modifier tous les paramètres spécifiques du cluster autoscaler.

Procédure

Afin d’éditer le cluster autoscaler, exécutez la commande suivante:
Exemple :
```
rosa edit autoscaler --cluster=<mycluster>
```
```
$ rosa edit autoscaler --cluster=<mycluster>
```
Copy to Clipboard Toggle word wrap
- Afin de modifier un paramètre spécifique, exécutez la commande suivante:
  Exemple :
  $ rosa edit autoscaler --cluster=<mycluster> <parameter>
  
  Copy to Clipboard Toggle word wrap

3.10. Afficher les configurations d’autoscaler avec le ROSA CLI
Copier lien

Il est possible d’afficher les configurations de votre cluster autoscaler à l’aide de la commande rosa décrire autoscaler.

Procédure

Afin d’afficher les configurations de cluster autoscaler, exécutez la commande suivante:
Exemple :
```
rosa describe autoscaler --cluster=<mycluster>
```
```
$ rosa describe autoscaler --cluster=<mycluster>
```
Copy to Clipboard Toggle word wrap

3.11. Effacer la mise à l’échelle automatique à l’aide du ROSA CLI
Copier lien

Il est possible de supprimer le cluster autoscaler si vous ne voulez plus l’utiliser.

Procédure

Afin de supprimer le cluster autoscaler, exécutez la commande suivante:
Exemple :
```
rosa delete autoscaler --cluster=<mycluster>
```
```
$ rosa delete autoscaler --cluster=<mycluster>
```
Copy to Clipboard Toggle word wrap

3.12. Cluster de paramètres de mise à l’échelle automatique à l’aide de la ROSA CLI
Copier lien

Lorsque vous utilisez le ROSA CLI (rosa), vous pouvez ajouter les paramètres suivants à la commande de création de clusters pour configurer les paramètres d’autoscaler.

Expand

Tableau 3.4. Les paramètres d’autoscale configurables disponibles avec le ROSA CLI (rosa)
Le réglage	Description	Le type ou la gamme	Exemple/Instruction
`--autoscaler-balance-similar-node-groupes`	Identifiez les groupes de nœuds avec le même type d’instance et le même ensemble d’étiquettes, et essayez d’équilibrer les tailles respectives de ces groupes de nœuds.	`booléen`	Ajoutez-le à true, omettez l’option à définir sur false.
`--autoscaler-skip-nodes-avec-local-stockage`	Lorsqu’il est défini, le cluster autoscaler ne supprime pas les nœuds avec des pods ayant un stockage local, par exemple, EmptyDir ou HostPath.	`booléen`	Ajoutez-le à true, omettez l’option à définir sur false.
`--autoscaler-log-verbosity int`	Le niveau de journal autoscaler. Dans la commande, remplacer int par le numéro que vous souhaitez utiliser.	`entier`	`--autoscaler-log-verbosity 4`
`--autoscaler-max-pod-grace-période int`	Donne aux pods un temps de terminaison gracieux avant de baisser, mesuré en secondes. Dans la commande, remplacer int par le nombre de secondes que vous souhaitez utiliser.	`entier`	`--autoscaler-max-pod-grace-période 0`
`--autoscaler-pod-priorité-seuil int`	La priorité qu’un pod doit dépasser pour amener le cluster autoscaler à déployer des nœuds supplémentaires. Le remplacement de l’int dans la commande par le numéro que vous souhaitez utiliser peut être négatif.	`entier`	`--autoscaler-pod-priority-threshold -10`
`--autoscaler-gpu-limit stringArray`	Le nombre minimum et maximum de GPU différents en cluster. Cluster autoscaler ne met pas à l’échelle le cluster moins ou plus que ces nombres. Le format doit être une liste séparée par virgule de ",<gpu_type> <min>,<max>".	`le tableau`	`--autoscaler-gpu-limit nvidia.com/gpu,0,10 --autoscaler-gpu-limit amd.com/gpu,1,5`
`--autoscaler-ignore-daemonsets-utilization`	Lorsqu’il est défini, le cluster-autoscaler ignore les pods de jeu de démon lors du calcul de l’utilisation des ressources pour la mise à l’échelle.	`booléen`	Ajoutez-le à true, omettez l’option à définir sur false.
`--autoscaler-max-node-provision-time string`	Durée maximale pendant laquelle le cluster autoscaler attend qu’un nœud soit fourni. Dans la commande, remplacez la chaîne par un entier et une unité de temps (ns,us, is, ms, m, m,h).	`chaîne de caractères`	`--autoscaler-max-node-provision-time 35m`
`--autoscaler-équilibrage-ignoré-étiquettes cordes`	Liste des clés d’étiquette séparées par les virgules que le cluster autoscaler devrait ignorer lors de la comparaison des groupes de nœuds pour la similitude. Dans la commande, remplacez les chaînes par les étiquettes pertinentes..	`chaîne de caractères`	`--autoscaler-balancing-ignored-labels topology.ebs.csi.aws.com/zone,alpha.eksctl.io/instance-id`
`--autoscaler-max-nodes-total int`	La quantité maximale de nœuds dans le cluster, y compris les nœuds à échelle automatique. Dans la commande, remplacer int par le numéro que vous souhaitez utiliser.	`entier`	`--autoscaler-max-nodes-total 180`
`--autoscaler-min-cores int`	Le nombre minimum de cœurs à déployer dans le cluster. Dans la commande, remplacer int par le numéro que vous souhaitez utiliser.	`entier`	`--autoscaler-min-cores 0`
`--autoscaler-max-cores int`	Le nombre maximum de cœurs à déployer dans le cluster. Dans la commande, remplacer int par le numéro que vous souhaitez utiliser.	`entier`	`--autoscaler-max-cores 100`
`--autoscaler-min-memory int`	La quantité minimale de mémoire, dans GiB, dans le cluster. Dans la commande, remplacer int par le numéro que vous souhaitez utiliser.	`entier`	`--autoscaler-min-memory 0`
`--autoscaler-max-memory int`	La quantité maximale de mémoire, dans GiB, dans le cluster. Dans la commande, remplacer int par le numéro que vous souhaitez utiliser.	`entier`	`--autoscaler-max-memory 4096`
`--autoscaler-scale-down-enabled`	Lorsqu’il est défini, le cluster autoscaler devrait réduire le cluster.	`booléen`	Ajoutez-le à true, omettez l’option à définir sur false.
`--autoscaler-scale-down-une chaîne de temps inutile`	Combien de temps un nœud devrait être inutile avant qu’il ne soit admissible à la réduction de l’échelle. Dans la commande, remplacez la chaîne par un entier et une unité de temps (ns,us, is, ms, m, m,h).	`chaîne de caractères`	`--autoscaler-scale-down-inné-temps 1h`
`--autoscaler-scale-down-utilization-threshold float`	Le niveau d’utilisation des nœuds, défini comme la somme des ressources demandées divisées par capacité, au-dessous duquel un nœud peut être considéré pour la réduction de l’échelle. La valeur doit être comprise entre 0 et 1.	`flotter`	`--autoscale-scale-down-utilization-threshold 0.5`
`--autoscaler-scale-down-delay-after-add chaîne`	Combien de temps après l’échelle de l’évaluation reprend. Dans la commande, remplacez la chaîne par un entier et une unité de temps (ns,us, is, ms, m, m,h).	`chaîne de caractères`	`--autoscaler-scale-down-delay-after-add 1h`
`--autoscaler-scale-down-delay-after-delete string`	Combien de temps après la suppression du nœud cette évaluation d’échelle reprend. Dans la commande, remplacez la chaîne par un entier et une unité de temps (ns,us, is, ms, m, m,h).	`chaîne de caractères`	`--autoscaler-scale-down-delay-après-delete 1h`
`--autoscaler-scale-down-delay-after-failure string`	Combien de temps après l’échec de l’échelle d’échelle reprend l’évaluation. Dans la commande, remplacez la chaîne par un entier et une unité de temps (ns,us, is, ms, m, m,h).	`chaîne de caractères`	`--autoscaler-scale-down-delay-après-échec 1h`

Chapitre 4. Cluster autoscaling pour ROSA HCP
Copier lien

L’application d’autoscaling à Red Hat OpenShift Service sur AWS (ROSA) avec des clusters de plans de contrôle hébergés (HCP) implique la configuration d’un ou de plusieurs pools de machines avec autoscaling. Il est possible d’utiliser le Cluster Autoscaler pour configurer davantage l’autoscaling à l’échelle du cluster qui s’applique à tous les pools de machines qui sont autoscaling.

4.1. À propos du cluster autoscaler
Copier lien

Le cluster autoscaler ajuste la taille d’un ROSA avec le cluster HCP pour répondre à ses besoins actuels de déploiement. Il utilise des arguments déclaratifs de style Kubernetes pour fournir une gestion de l’infrastructure qui ne repose pas sur des objets d’un fournisseur de cloud spécifique. Le cluster autoscaler a une portée de cluster, et n’est pas associé à un espace de noms particulier. Dans ROSA avec HCP, le Cluster Autoscaler est entièrement géré, ce qui signifie qu’il est hébergé avec le plan de contrôle.

Le cluster autoscaler calcule la mémoire totale, le CPU et le GPU uniquement sur les nœuds qui appartiennent aux pools de machines d’autoscaling. L’ensemble des nœuds de pool de machines qui ne sont pas autoscaling sont exclus de cette agrégation. À titre d’exemple, si vous définissez le maxNodesTotal à 50 sur un ROSA avec cluster HCP avec trois pools de machines dans lesquels un seul pool de machines n’est pas autoscaling, le cluster autoscaler limite les nœuds totaux à 50 dans seulement les deux pools de machines qui sont autoscaling. Le pool de machines à mise à l’échelle manuelle unique peut avoir des nœuds supplémentaires, ce qui fait que les nœuds de cluster totalisent plus de 50.

Élimination automatique des nœuds

L’utilisation des nœuds est inférieure au seuil d’utilisation des nœuds pour le cluster. Le niveau d’utilisation des nœuds correspond à la somme des ressources demandées divisées par les ressources allouées au nœud. Lorsque vous ne spécifiez pas une valeur dans la ressource personnalisée ClusterAutoscaler, le cluster autoscaler utilise une valeur par défaut de 0,5, ce qui correspond à une utilisation de 50%.
Le cluster autoscaler peut déplacer tous les pods s’exécutant sur le nœud vers les autres nœuds. Le planificateur de Kubernetes est responsable de la planification des pods sur les nœuds.
Le cluster autoscaler n’a pas de mise à l’échelle vers le bas annotation désactivée.

Lorsque les types de gousses suivants sont présents sur un nœud, le cluster autoscaler ne supprimera pas le nœud:

Les pods avec des budgets de perturbation des pod restrictifs (PDB).
Les pods du système Kube qui ne s’exécutent pas sur le nœud par défaut.
Les gousses de système Kube qui n’ont pas de PDB ou qui ont un PDB trop restrictif.
Les pods qui ne sont pas soutenus par un objet de contrôleur tel qu’un déploiement, un ensemble de répliques ou un ensemble étatique.
Gousses avec stockage local.
Des pods qui ne peuvent pas être déplacés ailleurs en raison d’un manque de ressources, de sélecteurs de nœuds incompatibles ou d’affinité, et ainsi de suite.
À moins qu’ils aient également une "cluster-autoscaler.kubernetes.io/safe-to-evict": "vrai" annotation, pods qui ont un "cluster-autoscaler.kubernetes.io/safe-to-evict": "faux" annotation.

Limites

Lorsque vous configurez le cluster autoscaler, des restrictions d’utilisation supplémentaires s’appliquent:

Il ne faut pas modifier directement les nœuds qui sont dans les groupes de nœuds autoscalenés. Dans le même groupe de nœuds, tous les nœuds ont la même capacité et les mêmes étiquettes et exécutent les mêmes pods système.
Indiquez les demandes pour vos pods.
Lorsque vous devez éviter que les pods ne soient supprimés trop rapidement, configurez les PDB appropriés.
Confirmez que votre quota de fournisseur de cloud est suffisamment important pour prendre en charge les pools de nœuds maximum que vous configurez.
Il ne faut pas exécuter d’autoscaleurs de groupe de nœuds supplémentaires, en particulier ceux offerts par votre fournisseur de cloud.

Note

Interaction avec d’autres fonctions de planification

4.2. Éditer l’autoscaling après la création de cluster avec le ROSA CLI
Copier lien

Après la création de l’autoscaler, vous pouvez modifier tous les paramètres spécifiques du cluster autoscaler.

Procédure

Afin d’éditer le cluster autoscaler, exécutez la commande suivante:
Exemple :
```
rosa edit autoscaler -h --cluster=<mycluster>
```
```
$ rosa edit autoscaler -h --cluster=<mycluster>
```
Copy to Clipboard Toggle word wrap
1. Afin de modifier un paramètre spécifique, exécutez la commande suivante:
  Exemple :
  $ rosa edit autoscaler -h --cluster=<mycluster> <parameter>
  
  Copy to Clipboard Toggle word wrap

4.3. Afficher les configurations d’autoscaler avec le ROSA CLI
Copier lien

Il est possible d’afficher les configurations de votre cluster autoscaler à l’aide de la commande rosa décrire autoscaler.

Procédure

Afin d’afficher les configurations de cluster autoscaler, exécutez la commande suivante:
Exemple :
```
rosa describe autoscaler -h --cluster=<mycluster>
```
```
$ rosa describe autoscaler -h --cluster=<mycluster>
```
Copy to Clipboard Toggle word wrap

4.4. Cluster de paramètres de mise à l’échelle automatique à l’aide de la ROSA CLI
Copier lien

Lorsque vous utilisez le ROSA CLI (rosa), vous pouvez ajouter les paramètres suivants à la commande de création de clusters pour configurer les paramètres d’autoscaler.

Expand

Tableau 4.1. Les paramètres d’autoscale configurables disponibles avec le ROSA CLI (rosa)
Le réglage	Description	Le type ou la gamme	Exemple/Instruction
`--autoscaler-max-pod-grace-période int`	Donne aux pods un temps de terminaison gracieux avant de baisser, mesuré en secondes. Dans la commande, remplacer int par le nombre de secondes que vous souhaitez utiliser.	`entier`	`--autoscaler-max-pod-grace-période 0`
`--autoscaler-pod-priorité-seuil int`	La priorité qu’un pod doit dépasser pour amener le cluster autoscaler à déployer des nœuds supplémentaires. Le remplacement de l’int dans la commande par le numéro que vous souhaitez utiliser peut être négatif.	`entier`	`--autoscaler-pod-priority-threshold -10`
`--autoscaler-max-node-provision-time string`	Durée maximale pendant laquelle le cluster autoscaler attend qu’un nœud soit fourni. Dans la commande, remplacez la chaîne par un entier et une unité de temps (ns,us, is, ms, m, m,h).	`chaîne de caractères`	`--autoscaler-max-node-provision-time 35m`
`--autoscaler-max-nodes-total int`	La quantité maximale de nœuds dans le cluster, y compris les nœuds à échelle automatique. Dans la commande, remplacer int par le numéro que vous souhaitez utiliser.	`entier`	`--autoscaler-max-nodes-total 180`

Chapitre 5. Gérer les nœuds à l’aide de pools de machines
Copier lien

5.1. À propos des piscines de machines
Copier lien

Le service OpenShift Red Hat sur AWS utilise les pools de machines comme méthode de provisionnement élastique et dynamique au-dessus de votre infrastructure cloud.

Les ressources primaires sont les machines, les ensembles de machines de calcul et les pools de machines.

5.1.1. Les machines
Copier lien

La machine est une unité fondamentale qui décrit l’hôte pour un nœud ouvrier.

5.1.2. Ensembles de machines
Copier lien

Les ressources Machineset sont des groupes de machines de calcul. Lorsque vous avez besoin de plus de machines ou que vous devez les réduire, modifiez le nombre de répliques dans le pool de machines à laquelle appartiennent les ensembles de machines de calcul.

Les ensembles de machines ne sont pas directement modifiables dans ROSA.

5.1.3. Les piscines de machines
Copier lien

Les pools de machines sont une construction de niveau supérieur pour calculer les ensembles de machines.

Le pool de machines crée des ensembles de machines de calcul qui sont tous des clones de la même configuration dans les zones de disponibilité. Les pools de machines effectuent toutes les actions de gestion du nœud hôte sur un nœud ouvrier. Lorsque vous avez besoin de plus de machines ou que vous devez les réduire, modifiez le nombre de répliques dans le pool de machines pour répondre à vos besoins de calcul. Il est possible de configurer manuellement la mise à l’échelle ou de définir l’autoscaling.

De multiples pools de machines peuvent exister sur un seul cluster, et chaque pool de machines peut contenir un type de nœud unique et une configuration de taille de nœud.

5.1.3.1. Pools de machines pendant l’installation du cluster
Copier lien

Par défaut, un cluster dispose d’un pool de machines. Lors de l’installation du cluster, vous pouvez définir le type d’instance ou la taille et ajouter des étiquettes à ce pool de machines.

5.1.3.2. Configuration des pools de machines après l’installation du cluster
Copier lien

Après l’installation d’un cluster:

Il est possible de supprimer ou d’ajouter des étiquettes à n’importe quel pool de machines.
Il est possible d’ajouter des pools de machines supplémentaires à un cluster existant.
Il est possible d’ajouter des taintes à n’importe quelle piscine de machine s’il y a une piscine de machine sans taintes.
Il est possible de créer ou de supprimer un pool de machines s’il y a un pool de machines sans taintes et au moins deux répliques pour un cluster Single-AZ ou trois répliques pour un cluster Multi-AZ.
Note
Il n’est pas possible de modifier le type ou la taille du nœud de piscine de la machine. Le type ou la taille du nœud de pool de machine est spécifié lors de leur création uniquement. Lorsque vous avez besoin d’un type de nœud ou d’une taille différente, vous devez recréer un pool de machines et spécifier les valeurs de type de nœud ou de taille requises.
Il est possible d’ajouter une étiquette à chaque pool de machines ajouté.

5.1.4. Pools de machines dans plusieurs clusters de zones
Copier lien

Dans un cluster créé sur plusieurs zones de disponibilité (AZ), les pools de machines peuvent être créés à travers les trois AZ ou n’importe quelle AZ de votre choix. Le pool de machines créé par défaut au moment de la création de clusters sera créé avec des machines dans les trois AZ et échelle en multiples de trois.

Lorsque vous créez un nouveau cluster Multi-AZ, les pools de machines sont répliqués automatiquement dans ces zones. Par défaut, si vous ajoutez un pool de machines à un cluster Multi-AZ existant, le nouveau pool de machines est automatiquement créé dans toutes les zones.

Note

Il est possible de remplacer ce paramètre par défaut et de créer un pool de machines dans une ZAZ unique de votre choix.

De même, la suppression d’un pool de machines le supprimera de toutes les zones. En raison de cet effet multiplicatif, l’utilisation de pools de machines dans le cluster Multi-AZ peut consommer une plus grande partie du quota de votre projet pour une région spécifique lors de la création de pools de machines.

5.1.5. Ressources supplémentaires
Copier lien

Gérer les nœuds de calcul
À propos de l’autoscaling
Configuration des limites PID

5.2. Gérer les nœuds de calcul
Copier lien

Ce document décrit comment gérer les nœuds de calcul (également connus sous le nom de travailleur) avec Red Hat OpenShift Service sur AWS (ROSA).

La majorité des changements pour les nœuds de calcul sont configurés sur des pools de machines. Le pool de machines est un groupe de nœuds de calcul dans un cluster qui a la même configuration, offrant une facilité de gestion.

Il est possible d’éditer des options de configuration de pool de machines telles que l’échelle, l’ajout d’étiquettes de nœuds et l’ajout de taintes.

5.2.1. Création d’un pool de machines
Copier lien

Le pool de machines est créé lorsque vous installez un Red Hat OpenShift Service sur AWS (ROSA). Après l’installation, vous pouvez créer des pools de machines supplémentaires pour votre cluster en utilisant OpenShift Cluster Manager ou ROSA CLI (rosa).

Note

Dans le cas des utilisateurs de ROSA CLI rosa version 1.2.25 et des versions antérieures, le pool de machines créé avec le cluster est identifié comme par défaut. Dans le cas des utilisateurs de ROSA CLI rosa version 1.2.26 et plus tard, le pool de machines créé avec le cluster est identifié comme travailleur.

5.2.1.1. Création d’un pool de machines à l’aide d’OpenShift Cluster Manager
Copier lien

Créez des pools de machines supplémentaires pour votre cluster Red Hat OpenShift sur AWS (ROSA) en utilisant OpenShift Cluster Manager.

Conditions préalables

« vous avez créé un cluster ROSA.

Procédure

Accédez à OpenShift Cluster Manager et sélectionnez votre cluster.
Dans l’onglet pools de machines, cliquez sur Ajouter un pool de machine.
Ajoutez un nom de pool machine.
Choisissez un type d’instance de nœud de calcul dans le menu déroulant. Le type d’instance définit la vCPU et l’allocation de mémoire pour chaque nœud de calcul dans le pool de machines.
Note
Il est impossible de modifier le type d’instance d’un pool de machines après la création du pool.
Facultatif: Configurer l’autoscaling pour le pool de machines:
1. Activez la mise à l’échelle automatique pour augmenter automatiquement le nombre de machines de votre pool de machines pour répondre aux besoins de déploiement.
2. Définissez les limites minimales et maximales de comptage des nœuds pour l’autoscaling. Le cluster autoscaler ne réduit pas ou n’augmente pas le nombre de nœuds de pool de machines au-delà des limites que vous spécifiez.
  - Lorsque vous avez déployé votre cluster à l’aide d’une seule zone de disponibilité, définissez le nombre minimum et maximum de nœuds. Cela définit les limites minimales et maximales des nœuds de calcul dans la zone de disponibilité.
  - Lorsque vous avez déployé votre cluster à l’aide de plusieurs zones de disponibilité, définissez les nœuds minimum par zone et les nœuds maximaux par zone. Cela définit les limites minimales et maximales des nœuds de calcul par zone.
    Note
    Alternativement, vous pouvez définir vos préférences de mise à l’échelle automatique pour le pool de machines après la création du pool de machines.
Dans le cas où vous n’avez pas activé la mise à l’échelle automatique, sélectionnez un nombre de nœuds de calcul:
- Lorsque vous avez déployé votre cluster à l’aide d’une seule zone de disponibilité, sélectionnez un compte de nœuds de calcul dans le menu déroulant. Cela définit le nombre de nœuds de calcul à fournir au pool de machines pour la zone.
- Lorsque vous avez déployé votre cluster à l’aide de plusieurs zones de disponibilité, sélectionnez le nombre de nœuds de calcul (par zone) dans le menu déroulant. Cela définit le nombre de nœuds de calcul à fournir au pool de machine par zone.
Facultatif: Configurer la taille du disque Root.
En option: Ajoutez des étiquettes et des taches de nœud pour votre piscine de machines:
1. Développez le menu Edit node et taints.
2. Dans les étiquettes Node, ajoutez des entrées Clé et Valeur pour vos étiquettes de nœuds.
3. Dans Taints, ajoutez des entrées Clé et Valeur pour vos taints.
  Note
  La création d’un pool de machines avec des taints n’est possible que si le cluster a déjà au moins un pool de machines sans tainte.
4. Dans chaque tainte, sélectionnez un effet dans le menu déroulant. Les options disponibles incluent NoSchedule, PreferNoSchedule et NoExecute.
  Note
  Alternativement, vous pouvez ajouter les étiquettes et les taches de nœud après avoir créé le pool de machines.
Facultatif: Sélectionnez des groupes de sécurité personnalisés supplémentaires à utiliser pour les nœuds dans ce pool de machines. Il faut déjà avoir créé les groupes de sécurité et les associer au VPC que vous avez sélectionné pour ce cluster. Il est impossible d’ajouter ou de modifier des groupes de sécurité après avoir créé le pool de machines. Consultez les exigences relatives aux groupes de sécurité dans la section « Ressources supplémentaires ».
Facultatif: Utilisez Amazon EC2 Spot Instances si vous souhaitez configurer votre pool de machines pour déployer des machines en tant qu’instances AWS Spot non garanties:
1. Choisissez Utilisez Amazon EC2 Spot Instances.
2. Laissez Utiliser le prix de l’instance à la demande sélectionné pour utiliser le prix de l’instance à la demande. Alternativement, sélectionnez Définir le prix maximum pour définir un prix horaire maximum pour une instance Spot.
  Consultez la documentation AWS pour plus d’informations sur Amazon EC2 Spot Instances.
  Important
  Amazon EC2 Spot Instances peut être interrompue à tout moment. Amazon EC2 Spot Instances n’utilise que des charges de travail pouvant tolérer des interruptions.
  Note
  Lorsque vous sélectionnez Utilisez Amazon EC2 Spot Instances pour un pool de machines, vous ne pouvez pas désactiver l’option après la création du pool de machines.
Cliquez sur Ajouter un pool de machine pour créer le pool de machines.

La vérification

Assurez-vous que le pool de machines est visible sur la page des pools de machines et que la configuration est comme prévu.

5.2.1.2. Création d’un pool de machines à l’aide du ROSA CLI
Copier lien

Il est possible de créer des pools de machines supplémentaires pour votre cluster Red Hat OpenShift Service sur AWS (ROSA) à l’aide du ROSA CLI (rosa).

Conditions préalables

Dans votre poste de travail, vous avez installé et configuré le dernier service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.
Connectez-vous à votre compte Red Hat à l’aide du ROSA CLI (rosa).
« vous avez créé un cluster ROSA.

Procédure

Ajouter un pool de machines qui n’utilise pas d’autoscaling, créer le pool de machines et définir le type d’instance, calculer (également connu sous le nom de travailleur) le nombre de nœuds et les étiquettes des nœuds:
```
rosa create machinepool --cluster=<cluster-name> \
                          --name=<machine_pool_id> \
                          --replicas=<replica_count> \
                          --instance-type=<instance_type> \
                          --labels=<key>=<value>,<key>=<value> \
                          --taints=<key>=<value>:<effect>,<key>=<value>:<effect> \
                          --use-spot-instances \
                          --spot-max-price=<price> \
                          --disk-size=<disk_size> \
                          --availability-zone=<availability_zone_name> \
                          --additional-security-group-ids <sec_group_id> \
                          --subnet <subnet_id>
```
```
$ rosa create machinepool --cluster=<cluster-name> \
                          --name=<machine_pool_id> \
                          --replicas=<replica_count> \
                          --instance-type=<instance_type> \
                          --labels=<key>=<value>,<key>=<value> \
                          --taints=<key>=<value>:<effect>,<key>=<value>:<effect> \
                          --use-spot-instances \
                          --spot-max-price=<price> \
                          --disk-size=<disk_size> \
                          --availability-zone=<availability_zone_name> \
                          --additional-security-group-ids <sec_group_id> \
                          --subnet <subnet_id>
```
Copy to Clipboard Toggle word wrap
là où:
--nom=<machine_pool_id>
Indique le nom du pool de machines.
--replicas=<replica_count>
Indique le nombre de nœuds de calcul à disposition. Lorsque vous avez déployé ROSA à l’aide d’une seule zone de disponibilité, cela définit le nombre de nœuds de calcul à fournir au pool de machines pour la zone. Lorsque vous avez déployé votre cluster à l’aide de plusieurs zones de disponibilité, cela définit le nombre de nœuds de calcul à fournir au total dans toutes les zones et le nombre doit être un multiple de 3. L’argument --replicas est requis lorsque l’autoscaling n’est pas configuré.
--instance-type=<instance_type>
Facultatif: Définit le type d’instance pour les nœuds de calcul dans votre pool de machines. Le type d’instance définit la vCPU et l’allocation de mémoire pour chaque nœud de calcul dans le pool. <instance_type> par un type d’instance. La valeur par défaut est m5.xlarge. Il est impossible de modifier le type d’instance d’un pool de machines après la création du pool.
--labels=<key>=<valeur>,<key>=<valeur>
Facultatif: Définit les étiquettes pour la piscine de machines. <key>=<valeur>,<key>=<value> par une liste délimitée par virgule de paires clé-valeur, par exemple --labels=key1=value1,key2=value2.
--taints=<key>=<valeur>:<effet>,<key>=<valeur>:<effet>
Facultatif: Définit les taintes pour la piscine de la machine. <key>=<valeur>:<effet>,<key>=<valeur>:<effet> par une clé, une valeur et un effet pour chaque taint, par exemple --taints=key1=value1:NoSchedule,key2=value2:NoExecute. Les effets disponibles incluent NoSchedule, PreferNoSchedule et NoExecute.
--utilisation-spot-instances
Facultatif : Configure votre pool de machines pour déployer des machines en tant qu’instances AWS Spot non garanties. À titre d’information, consultez Amazon EC2 Spot Instances dans la documentation AWS. Lorsque vous sélectionnez Utilisez Amazon EC2 Spot Instances pour un pool de machines, vous ne pouvez pas désactiver l’option après la création du pool de machines.
--spot-max-prix=<prix>
Facultatif: Si vous choisissez d’utiliser Spot Instances, vous pouvez spécifier cet argument pour définir un prix horaire maximum pour une instance Spot. Dans le cas où cet argument n’est pas spécifié, le prix à la demande est utilisé.
Important
Amazon EC2 Spot Instances peut être interrompue à tout moment. Amazon EC2 Spot Instances n’utilise que des charges de travail pouvant tolérer des interruptions.
--disk-size=<disk_size>
Facultatif: Spécifie la taille du disque du nœud de travail. La valeur peut être en GB, GiB, TB ou TiB. <disk_size> par une valeur numérique et une unité, par exemple --disk-size=200GiB.
--disponibilité-zone=<availability_zone_name>
En option: Pour les clusters Multi-AZ, vous pouvez créer un pool de machines dans une seule AZ de votre choix. <availability_zone_name> par un nom unique.
Note
Les clusters multi-AZ conservent un plan de commande Multi-AZ et peuvent avoir des pools de machines de travail à travers une seule AZ ou une Multi-AZ. Les pools de machines distribuent les machines (nœuds) uniformément sur les zones de disponibilité.
Avertissement
Lorsque vous choisissez un pool de machines de travail avec un Single-AZ, il n’y a pas de tolérance aux défauts pour ce pool de machine, quel que soit le nombre de répliques de la machine. En ce qui concerne les piscines de machines de travail tolérantes aux pannes, le choix d’un pool de machines multi-AZ distribue des machines dans des multiples de 3 zones de disponibilité.
La piscine de machines multi-AZ avec trois zones de disponibilité peut avoir un nombre de machines en multiples de 3 seulement, tels que 3, 6, 9, et ainsi de suite.
La piscine de machines monoAZ avec une zone de disponibilité peut avoir un nombre de machines en multiples de 1, tel que 1, 2, 3, 4, et ainsi de suite.
--addition-sécurité-groupe-ID <sec_group_id>
Facultatif: Pour les pools de machines dans des clusters qui n’ont pas de VPC gérés par Red Hat, vous pouvez sélectionner des groupes de sécurité personnalisés supplémentaires à utiliser dans vos pools de machines. Il faut déjà avoir créé les groupes de sécurité et les associer au VPC que vous avez sélectionné pour ce cluster. Il est impossible d’ajouter ou de modifier des groupes de sécurité après avoir créé le pool de machines. Consultez les exigences relatives aux groupes de sécurité dans la section « Ressources supplémentaires ».
--subnet <subnet_id>
Facultatif: Pour les clusters BYO VPC, vous pouvez sélectionner un sous-réseau pour créer un pool de machines mono-AZ. Lorsque le sous-réseau est sorti de vos sous-réseaux de création de clusters, il doit y avoir une balise avec une clé kubernetes.io/cluster/<infra-id> et la valeur partagée. Les clients peuvent obtenir l’ID Infra en utilisant la commande suivante:
$ rosa describe cluster -c <cluster name>|grep "Infra ID:"

Copy to Clipboard Toggle word wrap
Exemple de sortie

Infra ID: mycluster-xqvj7

Copy to Clipboard Toggle word wrap
Note
En même temps, vous ne pouvez pas définir à la fois --subnet et --disponibilité-zone, seulement 1 est autorisé pour une création de pool de machine Single-AZ.
L’exemple suivant crée un pool de machines appelé mymachinepool qui utilise le type d’instance m5.xlarge et possède 2 répliques de nœuds de calcul. L’exemple ajoute également 2 étiquettes spécifiques à la charge de travail:
```
rosa create machinepool --cluster=mycluster --name=mymachinepool --replicas=2 --instance-type=m5.xlarge --labels=app=db,tier=backend
```
```
$ rosa create machinepool --cluster=mycluster --name=mymachinepool --replicas=2 --instance-type=m5.xlarge --labels=app=db,tier=backend
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
I: Machine pool 'mymachinepool' created successfully on cluster 'mycluster'
I: To view all machine pools, run 'rosa list machinepools -c mycluster'
```
```
I: Machine pool 'mymachinepool' created successfully on cluster 'mycluster'
I: To view all machine pools, run 'rosa list machinepools -c mycluster'
```
Copy to Clipboard Toggle word wrap
Ajouter un pool de machines qui utilise l’autoscaling, créer le pool de machines et définir la configuration d’autoscaling, le type d’instance et les étiquettes de nœud:
```
rosa create machinepool --cluster=<cluster-name> \
                          --name=<machine_pool_id> \
                          --enable-autoscaling \
                          --min-replicas=<minimum_replica_count> \
                          --max-replicas=<maximum_replica_count> \
                          --instance-type=<instance_type> \
                          --labels=<key>=<value>,<key>=<value> \
                          --taints=<key>=<value>:<effect>,<key>=<value>:<effect> \
                          --availability-zone=<availability_zone_name> \
                          --use-spot-instances \
                          --spot-max-price=<price>
```
```
$ rosa create machinepool --cluster=<cluster-name> \
                          --name=<machine_pool_id> \
                          --enable-autoscaling \
                          --min-replicas=<minimum_replica_count> \
                          --max-replicas=<maximum_replica_count> \
                          --instance-type=<instance_type> \
                          --labels=<key>=<value>,<key>=<value> \
                          --taints=<key>=<value>:<effect>,<key>=<value>:<effect> \
                          --availability-zone=<availability_zone_name> \
                          --use-spot-instances \
                          --spot-max-price=<price>
```
Copy to Clipboard Toggle word wrap
là où:
--nom=<machine_pool_id>
Indique le nom du pool de machines. <machine_pool_id> par le nom de votre pool de machines.
--enable-autoscaling
Active la mise à l’échelle automatique dans le pool de machines pour répondre aux besoins de déploiement.
--min-replicas=<minimum_replica_count> et --max-replicas=<maxum_replica_count>
Définit les limites minimales et maximales des nœuds de calcul. Le cluster autoscaler ne réduit pas ou n’augmente pas le nombre de nœuds de pool de machines au-delà des limites que vous spécifiez.
Lorsque vous avez déployé ROSA à l’aide d’une seule zone de disponibilité, les arguments --min-replicas et --max-replicas définissent les limites d’autoscaling dans le pool de machines pour la zone. Lorsque vous avez déployé votre cluster à l’aide de plusieurs zones de disponibilité, les arguments définissent les limites d’autoscaling au total dans toutes les zones et les nombres doivent être multiples de 3.
--instance-type=<instance_type>
Facultatif: Définit le type d’instance pour les nœuds de calcul dans votre pool de machines. Le type d’instance définit la vCPU et l’allocation de mémoire pour chaque nœud de calcul dans le pool. <instance_type> par un type d’instance. La valeur par défaut est m5.xlarge. Il est impossible de modifier le type d’instance d’un pool de machines après la création du pool.
--labels=<key>=<valeur>,<key>=<valeur>
Facultatif: Définit les étiquettes pour la piscine de machines. <key>=<valeur>,<key>=<value> par une liste délimitée par virgule de paires clé-valeur, par exemple --labels=key1=value1,key2=value2.
--taints=<key>=<valeur>:<effet>,<key>=<valeur>:<effet>
Facultatif: Définit les taintes pour la piscine de la machine. <key>=<valeur>:<effet>,<key>=<valeur>:<effet> par une clé, une valeur et un effet pour chaque taint, par exemple --taints=key1=value1:NoSchedule,key2=value2:NoExecute. Les effets disponibles incluent NoSchedule, PreferNoSchedule et NoExecute.
--disponibilité-zone=<availability_zone_name>
En option: Pour les clusters Multi-AZ, vous pouvez créer un pool de machines dans une seule AZ de votre choix. <availability_zone_name> par un nom unique.
--utilisation-spot-instances
Facultatif : Configure votre pool de machines pour déployer des machines en tant qu’instances AWS Spot non garanties. À titre d’information, consultez Amazon EC2 Spot Instances dans la documentation AWS. Lorsque vous sélectionnez Utilisez Amazon EC2 Spot Instances pour un pool de machines, vous ne pouvez pas désactiver l’option après la création du pool de machines.
Important
Amazon EC2 Spot Instances peut être interrompue à tout moment. Amazon EC2 Spot Instances n’utilise que des charges de travail pouvant tolérer des interruptions.
--spot-max-prix=<prix>
Facultatif: Si vous choisissez d’utiliser Spot Instances, vous pouvez spécifier cet argument pour définir un prix horaire maximum pour une instance Spot. Dans le cas où cet argument n’est pas spécifié, le prix à la demande est utilisé.
L’exemple suivant crée un pool de machines appelé mymachinepool qui utilise le type d’instance m5.xlarge et a activé l’autoscaling. La limite minimale de nœud de calcul est de 3 et le maximum est de 6 dans l’ensemble. L’exemple ajoute également 2 étiquettes spécifiques à la charge de travail:
```
rosa create machinepool --cluster=mycluster --name=mymachinepool --enable-autoscaling --min-replicas=3 --max-replicas=6 --instance-type=m5.xlarge --labels=app=db,tier=backend
```
```
$ rosa create machinepool --cluster=mycluster --name=mymachinepool --enable-autoscaling --min-replicas=3 --max-replicas=6 --instance-type=m5.xlarge --labels=app=db,tier=backend
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
I: Machine pool 'mymachinepool' created successfully on cluster 'mycluster'
I: To view all machine pools, run 'rosa list machinepools -c mycluster'
```
```
I: Machine pool 'mymachinepool' created successfully on cluster 'mycluster'
I: To view all machine pools, run 'rosa list machinepools -c mycluster'
```
Copy to Clipboard Toggle word wrap

Afin d’ajouter une licence Windows incluse dans un pool de machines activée à une ROSA avec le cluster HCP, consultez la licence AWS Windows incluse pour ROSA avec HCP.
Les pools de machines activés ne peuvent être créés que lorsque les critères suivants sont satisfaits:
- Le cluster hôte est un ROSA avec le cluster HCP.
- Le type d’instance est en métal nu EC2.
  Important
  La licence AWS Windows incluse pour ROSA avec HCP est uniquement une fonctionnalité d’aperçu technologique. Les fonctionnalités d’aperçu technologique ne sont pas prises en charge avec les accords de niveau de service de production de Red Hat (SLA) et pourraient ne pas être fonctionnellement complètes. Le Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès précoce aux fonctionnalités du produit à venir, permettant aux clients de tester les fonctionnalités et de fournir des commentaires pendant le processus de développement.
  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.

La vérification

Il est possible de répertorier tous les pools de machines sur votre cluster ou de décrire des pools de machines individuels.

Énumérez les pools de machines disponibles sur votre cluster:

rosa list machinepools --cluster=<cluster_name>

$ rosa list machinepools --cluster=<cluster_name>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

ID             AUTOSCALING  REPLICAS  INSTANCE TYPE  LABELS                  TAINTS    AVAILABILITY ZONES                    SPOT INSTANCES
Default        No           3         m5.xlarge                                        us-east-1a, us-east-1b, us-east-1c    N/A
mymachinepool  Yes          3-6       m5.xlarge      app=db, tier=backend              us-east-1a, us-east-1b, us-east-1c    No

ID             AUTOSCALING  REPLICAS  INSTANCE TYPE  LABELS                  TAINTS    AVAILABILITY ZONES                    SPOT INSTANCES
Default        No           3         m5.xlarge                                        us-east-1a, us-east-1b, us-east-1c    N/A
mymachinepool  Yes          3-6       m5.xlarge      app=db, tier=backend              us-east-1a, us-east-1b, us-east-1c    No

Copy to Clipboard

Toggle word wrap

Décrivez les informations d’un pool de machines spécifique dans votre cluster:

rosa describe machinepool --cluster=<cluster_name> --machinepool=mymachinepool

$ rosa describe machinepool --cluster=<cluster_name> --machinepool=mymachinepool

Copy to Clipboard

Toggle word wrap

Exemple de sortie

ID:                         mymachinepool
Cluster ID:                 27iimopsg1mge0m81l0sqivkne2qu6dr
Autoscaling:                Yes
Replicas:                   3-6
Instance type:              m5.xlarge
Labels:                     app=db, tier=backend
Taints:
Availability zones:         us-east-1a, us-east-1b, us-east-1c
Subnets:
Spot instances:             No
Disk size:                  300 GiB
Security Group IDs:

ID:                         mymachinepool
Cluster ID:                 27iimopsg1mge0m81l0sqivkne2qu6dr
Autoscaling:                Yes
Replicas:                   3-6
Instance type:              m5.xlarge
Labels:                     app=db, tier=backend
Taints:
Availability zones:         us-east-1a, us-east-1b, us-east-1c
Subnets:
Spot instances:             No
Disk size:                  300 GiB
Security Group IDs:

Copy to Clipboard

Toggle word wrap

Assurez-vous que le pool de machines est inclus dans la sortie et que la configuration est comme prévu.

5.2.2. Configuration du volume de disque de pool machine
Copier lien

La taille du volume du disque de pool machine peut être configurée pour plus de flexibilité. La taille du disque par défaut est de 300 GiB.

Dans le cas des clusters Red Hat OpenShift sur AWS (architecture classique) version 4.13 ou antérieures, la taille du disque peut être configurée d’un minimum de 128 GiB à un maximum de 1 TiB. Dans le cas de la version 4.14 et ultérieure, la taille du disque peut être configurée à un minimum de 128 GiB jusqu’à un maximum de 16 TiB.

Configurez la taille du disque de pool machine pour votre cluster en utilisant OpenShift Cluster Manager ou ROSA CLI (rosa).

Note

Les volumes existants de clusters et de nœuds de pool de machines ne peuvent pas être redimensionnés.

5.2.2.1. Configuration du volume de disque de pool machine à l’aide d’OpenShift Cluster Manager
Copier lien

Conditions préalables à la création de clusters

Lors de l’installation du cluster, vous avez la possibilité de sélectionner le dimensionnement du disque de nœud pour le pool de machines par défaut.

La procédure de création de clusters

À partir de l’Assistant cluster ROSA, accédez aux paramètres de cluster.
Accédez à l’étape du pool machine.
Choisissez la taille du disque racine souhaitée.
Choisissez Suivant pour continuer à créer votre cluster.

Condition préalable à la création de pool de machines

Après l’installation du cluster, vous avez la possibilité de sélectionner le dimensionnement du disque de nœud pour le nouveau pool de machines.

La procédure pour la création de pool de machines

Accédez à OpenShift Cluster Manager et sélectionnez votre cluster.
Accédez à l’onglet Machine pool.
Cliquez sur Ajouter un pool de machine.
Choisissez la taille du disque racine souhaitée.
Cliquez sur Ajouter un pool de machine pour créer le pool de machines.

5.2.2.2. Configuration du volume de disque de pool machine à l’aide du ROSA CLI
Copier lien

Conditions préalables à la création de clusters

Lors de l’installation du cluster, vous avez la possibilité de sélectionner le dimensionnement du disque racine pour le pool de machines par défaut.

La procédure de création de clusters

Exécutez la commande suivante lors de la création de votre cluster OpenShift pour la taille du disque racine souhaitée:
```
rosa create cluster --worker-disk-size=<disk_size>
```
```
$ rosa create cluster --worker-disk-size=<disk_size>
```
Copy to Clipboard Toggle word wrap
La valeur peut être en GB, GiB, TB ou TiB. <disk_size> par une valeur numérique et une unité, par exemple --worker-disk-size=200GiB. Il est impossible de séparer le chiffre et l’unité. Aucun espace n’est autorisé.

Condition préalable à la création de pool de machines

Après l’installation du cluster, vous avez la possibilité de sélectionner le dimensionnement du disque racine pour le nouveau pool de machines.

La procédure pour la création de pool de machines

Augmentez le cluster en exécutant la commande suivante:
```
rosa create machinepool --cluster=<cluster_id> \
                          --disk-size=<disk_size>
```
```
$ rosa create machinepool --cluster=<cluster_id> \
```
1
```
                          --disk-size=<disk_size> 
```
2
Copy to Clipboard Toggle word wrap
1
Indique l’ID ou le nom de votre cluster OpenShift existant.
2
Indique la taille du disque du nœud de travail. La valeur peut être en GB, GiB, TB ou TiB. <disk_size> par une valeur numérique et une unité, par exemple --disk-size=200GiB. Il est impossible de séparer le chiffre et l’unité. Aucun espace n’est autorisé.
Confirmez la nouvelle taille du volume du disque de pool machine en vous connectant à la console AWS et trouvez la taille du volume de la racine de la machine virtuelle EC2.

5.2.3. La suppression d’une piscine de machines
Copier lien

Il est possible de supprimer un pool de machines dans le cas où vos besoins de charge de travail ont changé et que vos pools de machines actuels ne répondent plus à vos besoins.

Il est possible de supprimer les pools de machines avec Red Hat OpenShift Cluster Manager ou ROSA CLI (rosa).

5.2.3.1. La suppression d’un pool de machines à l’aide d’OpenShift Cluster Manager
Copier lien

Il est possible de supprimer un pool de machines pour votre Red Hat OpenShift Service sur AWS cluster en utilisant Red Hat OpenShift Cluster Manager.

Conditions préalables

« vous avez créé un cluster ROSA.
Le cluster est dans l’état prêt.
Il y a un pool de machines existant sans taintes et avec au moins deux instances pour un cluster monoAZ ou trois instances pour un cluster multi-AZ.

Procédure

À partir d’OpenShift Cluster Manager, accédez à la page Liste des clusters et sélectionnez le cluster qui contient le pool de machines que vous souhaitez supprimer.
Dans le cluster sélectionné, sélectionnez l’onglet Machine pools.
Dans l’onglet pools de machines, cliquez sur le menu Options du pool de machines que vous souhaitez supprimer.
Cliquez sur Supprimer.
Le pool de machines sélectionné est supprimé.

5.2.3.2. La suppression d’un pool de machines à l’aide de la ROSA CLI
Copier lien

Il est possible de supprimer un pool de machines pour votre Red Hat OpenShift Service sur AWS cluster en utilisant le ROSA CLI.

Note

Dans le cas des utilisateurs de ROSA CLI rosa version 1.2.25 et des versions antérieures, le pool de machines (ID='Default') qui est créé avec le cluster ne peut pas être supprimé. Dans le cas des utilisateurs de ROSA CLI rosa version 1.2.26 et ultérieure, le pool de machines (ID='ouvrier') qui est créé avec le cluster peut être supprimé s’il y a un pool de machines dans le cluster qui ne contient pas de taintes, et au moins deux répliques pour un cluster Single-AZ ou trois répliques pour un cluster Multi-AZ.

Conditions préalables

« vous avez créé un cluster ROSA.
Le cluster est dans l’état prêt.
Il y a un pool de machines existant sans taintes et avec au moins deux instances pour un cluster Single-AZ ou trois instances pour un cluster Multi-AZ.

Procédure

À partir du ROSA CLI, exécutez la commande suivante:

rosa delete machinepool -c=<cluster_name> <machine_pool_ID>

$ rosa delete machinepool -c=<cluster_name> <machine_pool_ID>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

? Are you sure you want to delete machine pool <machine_pool_ID> on cluster <cluster_name>? (y/N)

? Are you sure you want to delete machine pool <machine_pool_ID> on cluster <cluster_name>? (y/N)

Copy to Clipboard

Toggle word wrap

Entrez y pour supprimer le pool de machines.
Le pool de machines sélectionné est supprimé.

5.2.4. Calcul à l’échelle des nœuds manuellement
Copier lien

Lorsque vous n’avez pas activé la mise à l’échelle automatique de votre pool de machines, vous pouvez mettre à l’échelle manuellement le nombre de nœuds de calcul (également appelés travailleurs) dans le pool pour répondre à vos besoins de déploiement.

Il faut mettre à l’échelle chaque pool de machines séparément.

Conditions préalables

Dans votre poste de travail, vous avez installé et configuré le dernier service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.
Connectez-vous à votre compte Red Hat à l’aide du ROSA CLI (rosa).
Création d’un Red Hat OpenShift Service sur AWS (ROSA).
Il y a une piscine de machines existante.

Procédure

Liste des pools de machines dans le cluster:

rosa list machinepools --cluster=<cluster_name>

$ rosa list machinepools --cluster=<cluster_name>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

ID        AUTOSCALING   REPLICAS    INSTANCE TYPE  LABELS    TAINTS   AVAILABILITY ZONES    DISK SIZE   SG IDs
default   No            2           m5.xlarge                         us-east-1a            300GiB      sg-0e375ff0ec4a6cfa2
mp1       No            2           m5.xlarge                         us-east-1a            300GiB      sg-0e375ff0ec4a6cfa2

ID        AUTOSCALING   REPLICAS    INSTANCE TYPE  LABELS    TAINTS   AVAILABILITY ZONES    DISK SIZE   SG IDs
default   No            2           m5.xlarge                         us-east-1a            300GiB      sg-0e375ff0ec4a6cfa2
mp1       No            2           m5.xlarge                         us-east-1a            300GiB      sg-0e375ff0ec4a6cfa2

Copy to Clipboard

Toggle word wrap

Augmenter ou diminuer le nombre de répliques de nœuds de calcul dans un pool de machines:
```
rosa edit machinepool --cluster=<cluster_name> \
                        --replicas=<replica_count> \
                        <machine_pool_id>
```
```
$ rosa edit machinepool --cluster=<cluster_name> \
                        --replicas=<replica_count> \
```
1
```
                        <machine_pool_id> 
```
2
Copy to Clipboard Toggle word wrap
1
Lorsque vous avez déployé Red Hat OpenShift Service sur AWS (ROSA) (architecture classique) à l’aide d’une seule zone de disponibilité, le nombre de répliques définit le nombre de nœuds de calcul à fournir au pool de machines pour la zone. Lorsque vous avez déployé votre cluster à l’aide de plusieurs zones de disponibilité, le nombre de nœuds de calcul dans le pool de machines dans toutes les zones doit être un multiple de 3.
2
<machine_pool_id> par l’ID de votre pool de machines, comme indiqué dans la sortie de la commande précédente.

La vérification

Énumérez les pools de machines disponibles dans votre cluster:

rosa list machinepools --cluster=<cluster_name>

$ rosa list machinepools --cluster=<cluster_name>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

ID        AUTOSCALING   REPLICAS    INSTANCE TYPE  LABELS    TAINTS   AVAILABILITY ZONES    DISK SIZE   SG IDs
default   No            2           m5.xlarge                         us-east-1a            300GiB      sg-0e375ff0ec4a6cfa2
mp1       No            3           m5.xlarge                         us-east-1a            300GiB      sg-0e375ff0ec4a6cfa2

ID        AUTOSCALING   REPLICAS    INSTANCE TYPE  LABELS    TAINTS   AVAILABILITY ZONES    DISK SIZE   SG IDs
default   No            2           m5.xlarge                         us-east-1a            300GiB      sg-0e375ff0ec4a6cfa2
mp1       No            3           m5.xlarge                         us-east-1a            300GiB      sg-0e375ff0ec4a6cfa2

Copy to Clipboard

Toggle word wrap

Dans la sortie de la commande précédente, vérifiez que le nombre de répliques de nœuds de calcul est comme prévu pour votre pool de machines. Dans l’exemple de sortie, le nombre de répliques de nœuds de calcul pour le pool de machines mp1 est mis à l’échelle à 3.

5.2.5. Étiquettes des nœuds
Copier lien

L’étiquette est une paire clé-valeur appliquée à un objet Node. Il est possible d’utiliser des étiquettes pour organiser des ensembles d’objets et contrôler la planification des pods.

Il est possible d’ajouter des étiquettes lors de la création de clusters ou après. Les étiquettes peuvent être modifiées ou mises à jour à tout moment.

5.2.5.1. Ajout d’étiquettes de nœuds à un pool de machines
Copier lien

Ajouter ou modifier des étiquettes pour les nœuds de calcul (également connus sous le nom de travailleur) à tout moment pour gérer les nœuds d’une manière qui vous intéresse. À titre d’exemple, vous pouvez attribuer des types de charges de travail à des nœuds spécifiques.

Les étiquettes sont attribuées en paires clé-valeur. Chaque clé doit être unique à l’objet auquel elle est assignée.

Conditions préalables

Dans votre poste de travail, vous avez installé et configuré le dernier service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.
Connectez-vous à votre compte Red Hat à l’aide du ROSA CLI (rosa).
Création d’un Red Hat OpenShift Service sur AWS (ROSA).
Il y a une piscine de machines existante.

Procédure

Liste des pools de machines dans le cluster:

rosa list machinepools --cluster=<cluster_name>

$ rosa list machinepools --cluster=<cluster_name>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

ID           AUTOSCALING  REPLICAS  INSTANCE TYPE  LABELS    TAINTS    AVAILABILITY ZONES    SPOT INSTANCES
Default      No           2         m5.xlarge                          us-east-1a            N/A
db-nodes-mp  No           2         m5.xlarge                          us-east-1a            No

ID           AUTOSCALING  REPLICAS  INSTANCE TYPE  LABELS    TAINTS    AVAILABILITY ZONES    SPOT INSTANCES
Default      No           2         m5.xlarge                          us-east-1a            N/A
db-nodes-mp  No           2         m5.xlarge                          us-east-1a            No

Copy to Clipboard

Toggle word wrap

Ajouter ou mettre à jour les étiquettes des nœuds pour un pool de machines:
- Afin d’ajouter ou de mettre à jour les étiquettes des nœuds pour un pool de machines qui n’utilise pas d’autoscaling, exécutez la commande suivante:
  $ rosa edit machinepool --cluster=<cluster_name> \ --replicas=<replica_count> \
  1
  --labels=<key>=<value>,<key>=<value> \
  2
  <machine_pool_id>
  Copy to Clipboard Toggle word wrap
  1
  Dans le cas des pools de machines qui n’utilisent pas d’autoscaling, vous devez fournir un compte de réplique lors de l’ajout d’étiquettes de nœuds. Lorsque vous ne spécifiez pas l’argument --replicas, vous êtes invité à compter une réplique avant que la commande ne soit terminée. Lorsque vous avez déployé Red Hat OpenShift Service sur AWS (ROSA) à l’aide d’une seule zone de disponibilité, le nombre de répliques définit le nombre de nœuds de calcul à fournir au pool de machines pour la zone. Lorsque vous avez déployé votre cluster à l’aide de plusieurs zones de disponibilité, le nombre de nœuds de calcul dans le pool de machines dans toutes les zones doit être un multiple de 3.
  2
  <key>=<valeur>,<key>=<value> par une liste délimitée par virgule de paires clé-valeur, par exemple --labels=key1=value1,key2=value2. Cette liste écrase les modifications apportées aux étiquettes des nœuds sur une base continue.
  L’exemple suivant ajoute des étiquettes au pool de machines db-nodes-mp:
  $ rosa edit machinepool --cluster=mycluster --replicas=2 --labels=app=db,tier=backend db-nodes-mp
  Copy to Clipboard Toggle word wrap
  Exemple de sortie
  I: Updated machine pool 'db-nodes-mp' on cluster 'mycluster'
  
  Copy to Clipboard Toggle word wrap
- Afin d’ajouter ou de mettre à jour les étiquettes des nœuds pour un pool de machines qui utilise l’autoscaling, exécutez la commande suivante:
  $ rosa edit machinepool --cluster=<cluster_name> \ --min-replicas=<minimum_replica_count> \
  1
  --max-replicas=<maximum_replica_count> \
  2
  --labels=<key>=<value>,<key>=<value> \
  3
  <machine_pool_id>
  Copy to Clipboard Toggle word wrap
  1 2
  Dans le cas des pools de machines qui utilisent l’autoscaling, vous devez fournir des limites minimales et maximales de réplique des nœuds de calcul. Lorsque vous ne spécifiez pas les arguments, vous êtes invité pour les valeurs avant la fin de la commande. Le cluster autoscaler ne réduit pas ou n’augmente pas le nombre de nœuds de pool de machines au-delà des limites que vous spécifiez. Lorsque vous avez déployé ROSA à l’aide d’une seule zone de disponibilité, les arguments --min-replicas et --max-replicas définissent les limites d’autoscaling dans le pool de machines pour la zone. Lorsque vous avez déployé votre cluster à l’aide de plusieurs zones de disponibilité, les arguments définissent les limites d’autoscaling au total dans toutes les zones et les nombres doivent être multiples de 3.
  3
  <key>=<valeur>,<key>=<value> par une liste délimitée par virgule de paires clé-valeur, par exemple --labels=key1=value1,key2=value2. Cette liste écrase les modifications apportées aux étiquettes des nœuds sur une base continue.
  L’exemple suivant ajoute des étiquettes au pool de machines db-nodes-mp:
  $ rosa edit machinepool --cluster=mycluster --min-replicas=2 --max-replicas=3 --labels=app=db,tier=backend db-nodes-mp
  Copy to Clipboard Toggle word wrap
  Exemple de sortie
  I: Updated machine pool 'db-nodes-mp' on cluster 'mycluster'
  
  Copy to Clipboard Toggle word wrap

La vérification

Décrivez les détails de la piscine de machines avec les nouvelles étiquettes:

rosa describe machinepool --cluster=<cluster_name> --machinepool=<machine-pool-name>

$ rosa describe machinepool --cluster=<cluster_name> --machinepool=<machine-pool-name>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

ID:                         db-nodes-mp
Cluster ID:                 <ID_of_cluster>
Autoscaling:                No
Replicas:                   2
Instance type:              m5.xlarge
Labels:                     app=db, tier=backend
Taints:
Availability zones:         us-east-1a
Subnets:
Spot instances:             No
Disk size:                  300 GiB
Security Group IDs:

ID:                         db-nodes-mp
Cluster ID:                 <ID_of_cluster>
Autoscaling:                No
Replicas:                   2
Instance type:              m5.xlarge
Labels:                     app=db, tier=backend
Taints:
Availability zones:         us-east-1a
Subnets:
Spot instances:             No
Disk size:                  300 GiB
Security Group IDs:

Copy to Clipboard

Toggle word wrap

Assurez-vous que les étiquettes sont incluses pour votre pool de machines dans la sortie.

5.2.6. Ajout de tags à un pool de machines
Copier lien

Dans un pool de machines, vous pouvez ajouter des tags pour les nœuds de calcul, également connus sous le nom de nœuds de travail, pour introduire des balises utilisateur personnalisées pour les ressources AWS qui sont générées lorsque vous fournissez votre pool de machines.

5.2.6.1. Ajout de tags à un pool de machines à l’aide du ROSA CLI
Copier lien

Il est possible d’ajouter des tags à un pool de machines pour votre Red Hat OpenShift Service sur AWS cluster en utilisant l’interface de ligne de commande ROSA (CLI).

Important

Assurez-vous que vos clés de balise ne sont pas aws, red-hat-gaged, Red-hat-clustertype, ou Nom. De plus, vous ne devez pas définir une balise qui commence par kubernetes.io/cluster/. La clé de votre balise ne peut pas dépasser 128 caractères, tandis que la valeur de votre balise ne peut pas dépasser 256 caractères. Le Red Hat se réserve le droit d’ajouter des balises supplémentaires réservées à l’avenir.

Conditions préalables

Dans votre poste de travail, vous avez installé et configuré les derniers CLI AWS (aws), ROSA (rosa) et OpenShift (oc).
Connectez-vous à votre compte Red Hat en utilisant la rosa CLI.
Création d’un Red Hat OpenShift Service sur AWS (ROSA).

Procédure

Créez un pool de machines avec une balise personnalisée en exécutant la commande suivante:

rosa create machinepools --cluster=<name> --replicas=<replica_count> \
     --name <mp_name> --tags='<key> <value>,<key> <value>'

$ rosa create machinepools --cluster=<name> --replicas=<replica_count> \
     --name <mp_name> --tags='<key> <value>,<key> <value>'

Copy to Clipboard

Toggle word wrap

1: <key> <value>,<key> <value> par une clé et une valeur pour chaque balise.

Exemple de sortie

rosa create machinepools --cluster=mycluster --replicas 2 --tags='tagkey1 tagvalue1,tagkey2 tagvaluev2'

$ rosa create machinepools --cluster=mycluster --replicas 2 --tags='tagkey1 tagvalue1,tagkey2 tagvaluev2'

I: Checking available instance types for machine pool 'mp-1'
I: Machine pool 'mp-1' created successfully on cluster 'mycluster'
I: To view the machine pool details, run 'rosa describe machinepool --cluster mycluster --machinepool mp-1'
I: To view all machine pools, run 'rosa list machinepools --cluster mycluster'

Copy to Clipboard

Toggle word wrap

La vérification

Faites appel à la commande de description pour voir les détails du pool de machines avec les balises, et vérifiez que les balises sont incluses pour votre pool de machines dans la sortie:

rosa describe machinepool --cluster=<cluster_name> --machinepool=<machinepool_name>

$ rosa describe machinepool --cluster=<cluster_name> --machinepool=<machinepool_name>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

ID:                                    mp-1
Cluster ID:                            2baiirqa2141oreotoivp4sipq84vp5g
Autoscaling:                           No
Replicas:                              2
Instance type:                         m5.xlarge
Labels:
Taints:
Availability zones:                    us-east-1a
Subnets:
Spot instances:                        No
Disk size:                             300 GiB
Additional Security Group IDs:
Tags:                                  red-hat-clustertype=rosa, red-hat-managed=true, tagkey1=tagvalue1, tagkey2=tagvaluev2

ID:                                    mp-1
Cluster ID:                            2baiirqa2141oreotoivp4sipq84vp5g
Autoscaling:                           No
Replicas:                              2
Instance type:                         m5.xlarge
Labels:
Taints:
Availability zones:                    us-east-1a
Subnets:
Spot instances:                        No
Disk size:                             300 GiB
Additional Security Group IDs:
Tags:                                  red-hat-clustertype=rosa, red-hat-managed=true, tagkey1=tagvalue1, tagkey2=tagvaluev2

Copy to Clipboard

Toggle word wrap

5.2.7. Ajout de taintes à une piscine de machines
Copier lien

Dans un pool de machines, vous pouvez ajouter des taintes pour le calcul (également connu sous le nom d’ouvrier) pour contrôler les gousses qui leur sont programmées. Lorsque vous appliquez une tainte sur un pool de machines, le programmeur ne peut pas placer un pod sur les nœuds dans le pool à moins que la spécification de la gousse ne comporte une tolérance pour la tainte. Les taints peuvent être ajoutés à un pool de machines à l’aide de Red Hat OpenShift Cluster Manager ou du Red Hat OpenShift Service sur AWS (ROSA) CLI, rosa.

Note

Le cluster doit avoir au moins un pool de machines qui ne contient pas de taintes.

5.2.7.1. Ajout de taintes à un pool de machines à l’aide d’OpenShift Cluster Manager
Copier lien

Ajoutez des taintes à un pool de machines pour votre Red Hat OpenShift Service sur AWS cluster à l’aide de Red Hat OpenShift Cluster Manager.

Conditions préalables

Création d’un Red Hat OpenShift Service sur AWS (ROSA).
Il existe un pool de machines qui ne contient pas de taintes et qui contient au moins deux instances.

Procédure

Accédez à OpenShift Cluster Manager et sélectionnez votre cluster.
Dans l’onglet pools de machines, cliquez sur le menu Options du pool de machines auquel vous souhaitez ajouter un taint.
Choisissez Modifier les taintes.
Ajoutez des entrées de clé et de valeur pour votre taint.
Choisissez un effet pour votre taint dans le menu déroulant. Les options disponibles incluent NoSchedule, PreferNoSchedule et NoExecute.
Facultatif: Sélectionnez Ajouter taint si vous voulez ajouter plus de taintes à la piscine de la machine.
Cliquez sur Enregistrer pour appliquer les taints sur le pool de machines.

La vérification

Dans l’onglet Machine pools, sélectionnez > à côté de votre pool de machines pour élargir la vue.
Assurez-vous que vos taintes sont répertoriées sous Taints dans la vue élargie.

5.2.7.2. Ajout de taintes à un pool de machines à l’aide du ROSA CLI
Copier lien

Ajoutez des taintes à un pool de machines pour votre Red Hat OpenShift Service sur AWS cluster à l’aide du ROSA CLI.

Note

Dans le cas des utilisateurs de ROSA CLI rosa version 1.2.25 et des versions antérieures, le nombre de taints ne peut pas être modifié dans le pool de machines (ID=Default) créé avec le cluster. Dans le cas des utilisateurs de ROSA CLI rosa version 1.2.26 et au-delà, le nombre de taintes peut être modifié dans le pool de machines (ID=worker) créé avec le cluster. Il doit y avoir au moins un pool de machines sans taintes et avec au moins deux répliques pour un cluster Single-AZ ou trois répliques pour un cluster Multi-AZ.

Conditions préalables

Dans votre poste de travail, vous avez installé et configuré les derniers CLI AWS (aws), ROSA (rosa) et OpenShift (oc).
Connectez-vous à votre compte Red Hat en utilisant la rosa CLI.
Création d’un Red Hat OpenShift Service sur AWS (ROSA).
Il existe un pool de machines qui ne contient pas de taintes et qui contient au moins deux instances.

Procédure

Énumérez les pools de machines dans le cluster en exécutant la commande suivante:
```
rosa list machinepools --cluster=<cluster_name>
```
```
$ rosa list machinepools --cluster=<cluster_name>
```
Copy to Clipboard Toggle word wrap
Ajouter ou mettre à jour les taints pour un pool de machines:
- Afin d’ajouter ou de mettre à jour des taints pour un pool de machines qui n’utilise pas d’autoscaling, exécutez la commande suivante:
  $ rosa edit machinepool --cluster=<cluster_name> \ --replicas=<replica_count> \
  1
  --taints=<key>=<value>:<effect>,<key>=<value>:<effect> \
  2
  <machine_pool_id>
  Copy to Clipboard Toggle word wrap
  1
  Dans le cas des pools de machines qui n’utilisent pas d’autoscaling, vous devez fournir un compte de réplique lors de l’ajout de taintes. Lorsque vous ne spécifiez pas l’argument --replicas, vous êtes invité à compter une réplique avant que la commande ne soit terminée. Lorsque vous avez déployé Red Hat OpenShift Service sur AWS (ROSA) à l’aide d’une seule zone de disponibilité, le nombre de répliques définit le nombre de nœuds de calcul à fournir au pool de machines pour la zone. Lorsque vous avez déployé votre cluster à l’aide de plusieurs zones de disponibilité, le nombre de nœuds de calcul dans le pool de machines dans toutes les zones doit être un multiple de 3.
  2
  <key>=<valeur>:<effet>,<key>=<valeur>:<effet> par une clé, une valeur et un effet pour chaque taint, par exemple --taints=key1=value1:NoSchedule,key2=value2:NoExecute. Les effets disponibles incluent NoSchedule, PreferNoSchedule et NoExecute.Cette liste écrase les modifications apportées aux taches de nœud sur une base continue.
  L’exemple suivant ajoute des taintes au pool de machines db-nodes-mp:
  $ rosa edit machinepool --cluster=mycluster --replicas 2 --taints=key1=value1:NoSchedule,key2=value2:NoExecute db-nodes-mp
  Copy to Clipboard Toggle word wrap
  Exemple de sortie
  I: Updated machine pool 'db-nodes-mp' on cluster 'mycluster'
  
  Copy to Clipboard Toggle word wrap
- Afin d’ajouter ou de mettre à jour des taints pour un pool de machines qui utilise l’autoscaling, exécutez la commande suivante:
  $ rosa edit machinepool --cluster=<cluster_name> \ --min-replicas=<minimum_replica_count> \
  1
  --max-replicas=<maximum_replica_count> \
  2
  --taints=<key>=<value>:<effect>,<key>=<value>:<effect> \
  3
  <machine_pool_id>
  Copy to Clipboard Toggle word wrap
  1 2
  Dans le cas des pools de machines qui utilisent l’autoscaling, vous devez fournir des limites minimales et maximales de réplique des nœuds de calcul. Lorsque vous ne spécifiez pas les arguments, vous êtes invité pour les valeurs avant la fin de la commande. Le cluster autoscaler ne réduit pas ou n’augmente pas le nombre de nœuds de pool de machines au-delà des limites que vous spécifiez. Lorsque vous avez déployé ROSA à l’aide d’une seule zone de disponibilité, les arguments --min-replicas et --max-replicas définissent les limites d’autoscaling dans le pool de machines pour la zone. Lorsque vous avez déployé votre cluster à l’aide de plusieurs zones de disponibilité, les arguments définissent les limites d’autoscaling au total dans toutes les zones et les nombres doivent être multiples de 3.
  3
  <key>=<valeur>:<effet>,<key>=<valeur>:<effet> par une clé, une valeur et un effet pour chaque taint, par exemple --taints=key1=value1:NoSchedule,key2=value2:NoExecute. Les effets disponibles incluent NoSchedule, PreferNoSchedule et NoExecute. Cette liste annule les modifications apportées aux taches de nœud sur une base continue.
  L’exemple suivant ajoute des taintes au pool de machines db-nodes-mp:
  $ rosa edit machinepool --cluster=mycluster --min-replicas=2 --max-replicas=3 --taints=key1=value1:NoSchedule,key2=value2:NoExecute db-nodes-mp
  Copy to Clipboard Toggle word wrap
  Exemple de sortie
  I: Updated machine pool 'db-nodes-mp' on cluster 'mycluster'
  
  Copy to Clipboard Toggle word wrap

La vérification

Décrivez les détails de la piscine de machines avec les nouvelles taintes:

rosa describe machinepool --cluster=<cluster_name> --machinepool=<machinepool_name>

$ rosa describe machinepool --cluster=<cluster_name> --machinepool=<machinepool_name>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

ID:                         db-nodes-mp
Cluster ID:                 <ID_of_cluster>
Autoscaling:                No
Replicas:                   2
Instance type:              m5.xlarge
Labels:
Taints:                     key1=value1:NoSchedule, key2=value2:NoExecute
Availability zones:         us-east-1a
Subnets:
Spot instances:             No
Disk size:                  300 GiB
Security Group IDs:

ID:                         db-nodes-mp
Cluster ID:                 <ID_of_cluster>
Autoscaling:                No
Replicas:                   2
Instance type:              m5.xlarge
Labels:
Taints:                     key1=value1:NoSchedule, key2=value2:NoExecute
Availability zones:         us-east-1a
Subnets:
Spot instances:             No
Disk size:                  300 GiB
Security Group IDs:

Copy to Clipboard

Toggle word wrap

Assurez-vous que les taintes sont incluses pour votre pool de machines dans la sortie.

5.2.8. Ressources supplémentaires
Copier lien

À propos des piscines de machines
À propos de l’autoscaling
Activer l’autoscaling
Désactivation de l’autoscaling
Définition du service ROSA (architecture classique)

5.3. Configuration des pools de machines dans les zones locales
Copier lien

Ce document décrit comment configurer des zones locales dans des pools de machines avec Red Hat OpenShift Service sur AWS (ROSA).

5.3.1. Configuration des pools de machines dans les zones locales
Copier lien

Les étapes suivantes permettent de configurer les pools de machines dans les zones locales.

Important

Les zones locales AWS sont prises en charge sur Red Hat OpenShift Service sur AWS 4.12. Consultez l’article de la base de connaissances Red Hat pour obtenir des informations sur la façon d’activer les zones locales.

Conditions préalables

Le service OpenShift Red Hat sur AWS (ROSA) est généralement disponible dans la région mère de choix. Consultez la liste des emplacements généralement disponibles pour déterminer la zone locale disponible pour certaines régions AWS.
Le cluster ROSA a été initialement construit dans un VPC Amazon existant (BYO-VPC).
L’unité de transmission maximale (MTU) pour le cluster ROSA est fixée à 1200.
Important
Généralement, l’unité de transmission maximale (MTU) entre une instance Amazon EC2 dans une zone locale et une instance Amazon EC2 dans la région est de 1300. Découvrez comment les zones locales fonctionnent dans la documentation AWS. Le réseau de cluster MTU doit toujours être inférieur à l’EC2 MTU pour tenir compte des frais généraux. Les frais généraux spécifiques sont déterminés par votre plugin réseau, par exemple: - OVN-Kubernetes: 100 octets - OpenShift SDN: 50 octets
Le plugin réseau pourrait fournir des fonctionnalités supplémentaires qui peuvent également diminuer le MTU. Consultez la documentation pour plus d’informations.
Le compte AWS a activé Zones Locales.
Le compte AWS dispose d’un sous-réseau Zone Locale pour le même VPC que le cluster.
Le compte AWS a un sous-réseau qui est associé à une table de routage qui a un itinéraire vers une passerelle NAT.
Le compte AWS a la balise 'kubernetes.io/cluster/<infra_id>: partagée' sur le sous-réseau associé.

Procédure

Créez un pool de machines sur le cluster en exécutant la commande ROSA CLI (rosa) suivante.
```
rosa create machinepool -c <cluster-name> -i
```
```
$ rosa create machinepool -c <cluster-name> -i
```
Copy to Clipboard Toggle word wrap
Ajoutez le sous-réseau et le type d’instance pour le pool de machines dans le ROSA CLI. Après plusieurs minutes, le cluster fournira les nœuds.
```
I: Enabling interactive mode 
? Machine pool name: xx-lz-xx 
? Create multi-AZ machine pool: No 
? Select subnet for a single AZ machine pool (optional): Yes 
? Subnet ID: subnet-<a> (region-info) 
? Enable autoscaling (optional): No 
? Replicas: 2 
I: Fetching instance types 
? disk-size (optional): 
```
```
I: Enabling interactive mode 
```
1
```
? Machine pool name: xx-lz-xx 
```
2
```
? Create multi-AZ machine pool: No 
```
3
```
? Select subnet for a single AZ machine pool (optional): Yes 
```
4
```
? Subnet ID: subnet-<a> (region-info) 
```
5
```
? Enable autoscaling (optional): No 
```
6
```
? Replicas: 2 
```
7
```
I: Fetching instance types 
```
8
```
? disk-size (optional): 
```
9
Copy to Clipboard Toggle word wrap
1
Active le mode interactif.
2
Donne le nom de la piscine de machines. Ceci est limité à l’alphanumérique et à une longueur maximale de 30 caractères.
3
Définissez cette option sur non.
4
Définissez cette option sur oui.
5
Sélectionne un ID de sous-réseau dans la liste.
6
Choisissez oui pour activer l’autoscaling ou non pour désactiver l’autoscaling.
7
Sélectionne le nombre de machines pour le pool de machines. Ce nombre peut être n’importe où de 1 à 180.
8
Sélectionne un type d’instance dans la liste. Les types d’instances qui sont pris en charge dans la zone locale sélectionnée apparaîtront.
9
Facultatif: Spécifie la taille du disque du nœud de travail. La valeur peut être en GB, GiB, TB ou TiB. Définissez une valeur numérique et une unité, par exemple '200GiB'. Il est impossible de séparer le chiffre et l’unité. Aucun espace n’est autorisé.
Fournissez l’ID de sous-réseau pour approvisionner le pool de machines dans la zone locale.

Consultez la liste des emplacements AWS Local Zones sur AWS pour les emplacements généralement disponibles et annoncés.

5.4. À propos des nœuds autoscaling sur un cluster
Copier lien

L’option autoscaler peut être configurée pour mettre automatiquement à l’échelle le nombre de machines d’un cluster.

Le cluster autoscaler augmente la taille du cluster lorsqu’il y a des pods qui n’ont pas planifié l’un des nœuds actuels en raison de ressources insuffisantes ou lorsqu’un autre nœud est nécessaire pour répondre aux besoins de déploiement. Le cluster autoscaler n’augmente pas les ressources de cluster au-delà des limites que vous spécifiez.

En outre, le cluster autoscaler diminue la taille du cluster lorsque certains nœuds ne sont pas constamment nécessaires pendant une période significative, comme lorsqu’il a une faible utilisation des ressources et que tous ses gousses importants peuvent s’adapter à d’autres nœuds.

Lorsque vous activez l’autoscaling, vous devez également définir un nombre minimum et maximum de nœuds de travail.

Note

Les propriétaires de clusters et les administrateurs d’organisation peuvent mettre à l’échelle ou supprimer un cluster.

5.4.1. Activer les nœuds de mise à l’échelle automatique sur un cluster
Copier lien

La mise à l’échelle automatique sur les nœuds de travail permet d’augmenter ou de diminuer le nombre de nœuds disponibles en modifiant la définition du pool de machines pour un cluster existant.

Activer les nœuds autoscaling dans un cluster existant à l’aide de Red Hat OpenShift Cluster Manager

Activer l’autoscaling pour les nœuds de travail dans la définition du pool de machines à partir de la console OpenShift Cluster Manager.

Procédure

À partir d’OpenShift Cluster Manager, accédez à la page Liste des clusters et sélectionnez le cluster que vous souhaitez activer automatiquement.
Dans le cluster sélectionné, sélectionnez l’onglet Machine pools.
Cliquez sur le menu Options à la fin du pool de machines que vous souhaitez activer automatiquement et sélectionnez Modifier.
Dans la boîte de dialogue Modifier le pool de machines, sélectionnez la case à cocher Activer l’autoscaling.
Cliquez sur Enregistrer pour enregistrer ces modifications et activez l’autoscaling pour le pool de machines.

Note

En outre, vous pouvez configurer l’autoscaling sur le pool de machines par défaut lorsque vous créez le cluster en mode interactif.

Activer les nœuds autoscaling dans un cluster existant à l’aide du ROSA CLI

Configurez la mise à l’échelle automatique pour mettre à l’échelle dynamiquement le nombre de nœuds de travail vers le haut ou vers le bas en fonction de la charge.

Le succès de l’autoscaling dépend du fait d’avoir les bons quotas de ressources AWS dans votre compte AWS. Contrôlez les quotas de ressources et demandez des augmentations de quotas sur la console AWS.

Procédure

Afin d’identifier les identifiants du pool de machines dans un cluster, entrez la commande suivante:

rosa list machinepools --cluster=<cluster_name>

$ rosa list machinepools --cluster=<cluster_name>

Copy to Clipboard

Toggle word wrap

Exemple de sortie

ID      AUTOSCALING  REPLICAS  INSTANCE TYPE  LABELS    TAINTS    AVAILABILITY ZONES    SUBNETS    SPOT INSTANCES  DISK SIZE  SG IDs
worker  No           2         m5.xlarge                          us-east-2a                       No              300 GiB
mp1     No           2         m5.xlarge                          us-east-2a                       No              300 GiB

ID      AUTOSCALING  REPLICAS  INSTANCE TYPE  LABELS    TAINTS    AVAILABILITY ZONES    SUBNETS    SPOT INSTANCES  DISK SIZE  SG IDs
worker  No           2         m5.xlarge                          us-east-2a                       No              300 GiB
mp1     No           2         m5.xlarge                          us-east-2a                       No              300 GiB

Copy to Clipboard

Toggle word wrap

Obtenez l’identifiant des pools de machines que vous souhaitez configurer.

Afin d’activer la mise à l’échelle automatique sur un pool de machines, entrez la commande suivante:

rosa edit machinepool --cluster=<cluster_name> <machinepool_ID> --enable-autoscaling --min-replicas=<number> --max-replicas=<number>

$ rosa edit machinepool --cluster=<cluster_name> <machinepool_ID> --enable-autoscaling --min-replicas=<number> --max-replicas=<number>

Copy to Clipboard

Toggle word wrap

Exemple :

Activer la mise à l’échelle automatique sur un pool de machines avec l’ID mp1 sur un cluster nommé mycluster, avec le nombre de répliques définie à l’échelle entre 2 et 5 nœuds ouvriers:

rosa edit machinepool --cluster=mycluster mp1 --enable-autoscaling --min-replicas=2 --max-replicas=5

$ rosa edit machinepool --cluster=mycluster mp1 --enable-autoscaling --min-replicas=2 --max-replicas=5

Copy to Clipboard

Toggle word wrap

5.4.2. Désactivation des nœuds autoscaling sur un cluster
Copier lien

Désactivez la mise à l’échelle automatique sur les nœuds ouvriers pour augmenter ou diminuer le nombre de nœuds disponibles en modifiant la définition du pool de machines pour un cluster existant.

Il est possible de désactiver la mise à l’échelle automatique sur un cluster à l’aide de Red Hat OpenShift Cluster Manager ou du Red Hat OpenShift Service sur AWS CLI.

Note

En outre, vous pouvez configurer l’autoscaling sur le pool de machines par défaut lorsque vous créez le cluster en mode interactif.

Désactivation des nœuds automatiques dans un cluster existant à l’aide de Red Hat OpenShift Cluster Manager

Désactivez l’autoscaling pour les nœuds de travail dans la définition du pool de machines à partir d’OpenShift Cluster Manager.

Procédure

À partir d’OpenShift Cluster Manager, accédez à la page Liste des clusters et sélectionnez le cluster avec autoscaling qui doit être désactivé.
Dans le cluster sélectionné, sélectionnez l’onglet Machine pools.
Cliquez sur le menu Options à la fin du pool de machines avec autoscaling et sélectionnez Modifier.
Dans la boîte de dialogue Modifier le pool de machine, désactivez la case à cocher Activer l’échelle automatique.
Cliquez sur Enregistrer pour enregistrer ces modifications et désactiver l’autoscaling à partir du pool de machines.

Désactivation des nœuds automatiques dans un cluster existant à l’aide du ROSA CLI

Désactivez l’autoscaling pour les nœuds de travail dans la définition du pool de machines en utilisant le Red Hat OpenShift Service sur AWS (ROSA) CLI, rosa.

Procédure

Entrez la commande suivante:

rosa edit machinepool --cluster=<cluster_name> <machinepool_ID> --enable-autoscaling=false --replicas=<number>

$ rosa edit machinepool --cluster=<cluster_name> <machinepool_ID> --enable-autoscaling=false --replicas=<number>

Copy to Clipboard

Toggle word wrap

Exemple :

Désactivez l’autoscaling sur le pool de machines par défaut sur un cluster nommé mycluster:

rosa edit machinepool --cluster=mycluster default --enable-autoscaling=false --replicas=3

$ rosa edit machinepool --cluster=mycluster default --enable-autoscaling=false --replicas=3

Copy to Clipboard

Toggle word wrap

5.4.3. Ressources supplémentaires
Copier lien

5.5. Configuration de la mémoire cluster pour répondre aux exigences de mémoire de conteneur et de risque
Copier lien

En tant qu’administrateur de clusters, vous pouvez aider vos clusters à fonctionner efficacement grâce à la gestion de la mémoire d’application en:

Déterminer les exigences en matière de mémoire et de risque d’un composant d’application conteneurisé et configurer les paramètres de mémoire du conteneur pour répondre à ces exigences.
Configuration d’exécutions d’applications conteneurisées (par exemple, OpenJDK) pour adhérer de manière optimale aux paramètres de mémoire de conteneur configurés.
Diagnostiquer et résoudre les conditions d’erreur liées à la mémoire associées à l’exécution dans un conteneur.

5.5.1. Comprendre la gestion de la mémoire applicative
Copier lien

Il est recommandé de lire pleinement l’aperçu de la façon dont Red Hat OpenShift Service sur AWS gère les ressources de calcul avant de procéder.

Dans chaque type de ressource (mémoire, CPU, stockage), Red Hat OpenShift Service sur AWS permet de placer des valeurs de requête et limites optionnelles sur chaque conteneur dans un pod.

À noter ce qui suit au sujet des requêtes de mémoire et des limites de mémoire:

Demande de mémoire
- La valeur de la demande de mémoire, si elle est spécifiée, influence le service Red Hat OpenShift sur AWS. Le planificateur prend en compte la demande de mémoire lors de la planification d’un conteneur à un nœud, puis clôture la mémoire demandée sur le nœud choisi pour l’utilisation du conteneur.
- En cas d’épuisement de la mémoire d’un nœud, Red Hat OpenShift Service sur AWS donne la priorité à l’expulsion de ses conteneurs dont l’utilisation de la mémoire dépasse le plus leur demande de mémoire. Dans les cas graves d’épuisement de la mémoire, le tueur OOM peut sélectionner et tuer un processus dans un conteneur en fonction d’une métrique similaire.
- L’administrateur du cluster peut attribuer un quota ou attribuer des valeurs par défaut pour la valeur de demande de mémoire.
- L’administrateur de cluster peut outrepasser les valeurs de requête de mémoire qu’un développeur spécifie, pour gérer le cluster overcommit.
Limite de mémoire
- La valeur limite de mémoire, si spécifiée, fournit une limite dure sur la mémoire qui peut être allouée sur tous les processus d’un conteneur.
- Lorsque la mémoire allouée par tous les processus d’un conteneur dépasse la limite de mémoire, le tueur hors mémoire (OOM) sélectionne et tue immédiatement un processus dans le conteneur.
- Lorsque la requête mémoire et la limite sont spécifiées, la valeur limite de mémoire doit être supérieure ou égale à la requête mémoire.
- L’administrateur du cluster peut attribuer un quota ou attribuer des valeurs par défaut pour la valeur limite de mémoire.
- La limite minimale de mémoire est de 12 Mo. En cas de démarrage d’un conteneur en raison d’un événement de Pod de mémoire impossible, la limite de mémoire est trop faible. Augmentez ou supprimez la limite de mémoire. La suppression de la limite permet aux gousses de consommer des ressources de nœuds non limitées.

5.5.1.1. Gestion de la stratégie de mémoire des applications
Copier lien

Les étapes de dimensionnement de la mémoire de l’application sur Red Hat OpenShift Service sur AWS sont les suivantes:

Déterminer l’utilisation prévue de la mémoire de conteneur
Déterminer l’utilisation prévue de la mémoire moyenne et maximale du conteneur, empiriquement si nécessaire (par exemple, par des tests de charge séparés). Considérez tous les processus qui peuvent potentiellement s’exécuter en parallèle dans le conteneur: par exemple, l’application principale génère-t-elle des scripts auxiliaires?
Déterminer l’appétit du risque
Déterminer l’appétit de risque pour l’expulsion. Lorsque l’appétit de risque est faible, le conteneur doit demander de la mémoire en fonction de l’utilisation maximale prévue plus un pourcentage de marge de sécurité. Lorsque l’appétit de risque est plus élevé, il peut être plus approprié de demander de la mémoire en fonction de l’utilisation moyenne prévue.
Définir la demande de mémoire de conteneur
Définissez la demande de mémoire de conteneur en fonction de ce qui précède. Le plus précisément la demande représente l’utilisation de la mémoire de l’application, mieux c’est. Lorsque la demande est trop élevée, l’utilisation des grappes et des quotas sera inefficace. Lorsque la demande est trop faible, les chances d’expulsion de l’application augmentent.
Définir la limite de mémoire du conteneur, si nécessaire
Définissez la limite de mémoire du conteneur, si nécessaire. Fixer une limite a pour effet de tuer immédiatement un processus de conteneur si l’utilisation combinée de la mémoire de tous les processus dans le conteneur dépasse la limite, et est donc une bénédiction mixte. D’une part, il peut rendre l’utilisation excessive de mémoire imprévue évidente tôt ("échec rapide"); d’autre part, il met également fin aux processus brusquement.
Il est à noter que certains Red Hat OpenShift Service sur les clusters AWS peuvent nécessiter une valeur limite à définir; certains peuvent outrepasser la demande en fonction de la limite; et certaines images de l’application dépendent d’une valeur limite définie car cela est plus facile à détecter qu’une valeur de requête.
Lorsque la limite de mémoire est définie, elle ne doit pas être inférieure à l’utilisation prévue de la mémoire du conteneur de pointe plus une marge de sécurité en pourcentage.
Assurez-vous que l’application est réglée
Assurez-vous que l’application est réglée en ce qui concerne les valeurs de requête configurées et les valeurs limites, le cas échéant. Cette étape est particulièrement pertinente pour les applications qui mettent en commun la mémoire, comme le JVM. Le reste de cette page en traite.

5.5.2. Comprendre les paramètres OpenJDK pour Red Hat OpenShift Service sur AWS
Copier lien

Les paramètres OpenJDK par défaut ne fonctionnent pas bien avec les environnements conteneurisés. En conséquence, certains paramètres de mémoire Java supplémentaires doivent toujours être fournis chaque fois qu’on exécute l’OpenJDK dans un conteneur.

La mise en page de la mémoire JVM est complexe, dépendante de la version, et la décrire en détail dépasse le champ d’application de cette documentation. Cependant, comme point de départ pour l’exécution d’OpenJDK dans un conteneur, au moins les trois tâches suivantes liées à la mémoire sont essentielles:

Dépassement de la taille maximale du tas JVM.
Encourager le JVM à libérer la mémoire inutilisée au système d’exploitation, le cas échéant.
Assurer la configuration appropriée de tous les processus JVM dans un conteneur.

Le réglage optimal des charges de travail JVM pour l’exécution dans un conteneur est au-delà de la portée de cette documentation, et peut impliquer la définition de plusieurs options JVM supplémentaires.

5.5.2.1. Comprendre comment remplacer la taille maximale du tas JVM
Copier lien

« pour de nombreuses charges de travail Java, le tas JVM est le plus grand consommateur de mémoire. Actuellement, l’OpenJDK permet par défaut de permettre jusqu’à 1/4 (1/-XX:MaxRAMFraction) de la mémoire du nœud de calcul à utiliser pour le tas, que l’OpenJDK fonctionne ou non dans un conteneur. Il est donc essentiel de remplacer ce comportement, surtout si une limite de mémoire de conteneur est également définie.

Il y a au moins deux façons d’atteindre ce qui précède:

Lorsque la limite de mémoire du conteneur est définie et que les options expérimentales sont prises en charge par le JVM, set -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap.
Note
L’option UseCGroupMemoryLimitForHeap a été supprimée dans JDK 11. À la place, utilisez -XX:+UseContainerSupport.
Ceci définit -XX:MaxRAM à la limite de mémoire du conteneur, et la taille maximale du tas (-XX:MaxHeapSize / -Xmx) à 1/-XX:MaxRAMFraction (1/4 par défaut).
Remplacez directement l’un des -XX:MaxRAM, -XX:MaxHeapSize ou -Xmx.
Cette option implique un codage dur d’une valeur, mais a l’avantage de permettre le calcul d’une marge de sécurité.

5.5.2.2. Comprendre comment encourager le JVM à libérer de la mémoire inutilisée au système d’exploitation
Copier lien

L’OpenJDK ne renvoie pas de manière agressive la mémoire inutilisée au système d’exploitation. Cela peut être approprié pour de nombreuses charges de travail Java conteneurisées, mais des exceptions notables incluent des charges de travail où des processus actifs supplémentaires coexistent avec un JVM dans un conteneur, que ces processus supplémentaires soient natifs, JVM supplémentaires ou une combinaison des deux.

Les agents basés sur Java peuvent utiliser les arguments JVM suivants pour encourager le JVM à libérer de la mémoire inutilisée au système d’exploitation:

-XX:+UseParallelGC
-XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=10 -XX:GCTimeRatio=4
-XX:AdaptiveSizePolicyWeight=90.

-XX:+UseParallelGC
-XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=10 -XX:GCTimeRatio=4
-XX:AdaptiveSizePolicyWeight=90.

Copy to Clipboard

Toggle word wrap

Ces arguments sont destinés à renvoyer la mémoire tas au système d’exploitation chaque fois que la mémoire allouée dépasse 110% de la mémoire en usage (-XX:MaxHeapFreeRatio), passant jusqu’à 20% du temps CPU dans le collecteur d’ordures (-XX:GCTimeRatio). À aucun moment, l’allocation du tas d’application ne sera inférieure à l’allocation initiale du tas (surpassée par -XX:InitialHeapSize / -Xms). L’empreinte de Java dans OpenShift (Partie 1), l’empreinte de Java dans OpenShift (Partie 2) et OpenJDK et Containers.

5.5.2.3. Comprendre comment s’assurer que tous les processus JVM dans un conteneur sont correctement configurés
Copier lien

Dans le cas où plusieurs JVM s’exécutent dans le même conteneur, il est essentiel de s’assurer qu’ils sont tous configurés de manière appropriée. Dans de nombreuses charges de travail, il sera nécessaire d’accorder à chaque JVM un budget de mémoire en pourcentage, laissant une marge de sécurité supplémentaire peut-être substantielle.

De nombreux outils Java utilisent différentes variables d’environnement (JAVA_OPTS, GRADLE_OPTS, etc.) pour configurer leurs JVM et il peut être difficile de s’assurer que les bons paramètres sont passés au bon JVM.

La variable d’environnement JAVA_TOOL_OPTIONS est toujours respectée par OpenJDK, et les valeurs spécifiées dans JAVA_TOOL_OPTIONS seront remplacées par d’autres options spécifiées sur la ligne de commande JVM. Afin de s’assurer que ces options sont utilisées par défaut pour toutes les charges de travail JVM exécutées dans l’image de l’agent basé sur Java, le Red Hat OpenShift Service sur AWS Jenkins Maven jeu d’image d’agent:

JAVA_TOOL_OPTIONS="-XX:+UnlockExperimentalVMOptions
-XX:+UseCGroupMemoryLimitForHeap -Dsun.zip.disableMemoryMapping=true"

JAVA_TOOL_OPTIONS="-XX:+UnlockExperimentalVMOptions
-XX:+UseCGroupMemoryLimitForHeap -Dsun.zip.disableMemoryMapping=true"

Copy to Clipboard

Toggle word wrap

Note

L’option UseCGroupMemoryLimitForHeap a été supprimée dans JDK 11. À la place, utilisez -XX:+UseContainerSupport.

Cela ne garantit pas que d’autres options ne sont pas nécessaires, mais est destinée à être un point de départ utile.

5.5.3. La recherche de la requête et de la limite de mémoire à l’intérieur d’un pod
Copier lien

L’application qui souhaite découvrir dynamiquement sa demande de mémoire et sa limite à partir d’un pod doit utiliser l’API Downward.

Procédure

Configurez le pod pour ajouter les sanzas MEMORY_REQUEST et MEMORY_LIMIT:

Créez un fichier YAML similaire à ce qui suit:

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: test
    image: fedora:latest
    command:
    - sleep
    - "3600"
    env:
    - name: MEMORY_REQUEST 
      valueFrom:
        resourceFieldRef:
          containerName: test
          resource: requests.memory
    - name: MEMORY_LIMIT 
      valueFrom:
        resourceFieldRef:
          containerName: test
          resource: limits.memory
    resources:
      requests:
        memory: 384Mi
      limits:
        memory: 512Mi
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: test
    image: fedora:latest
    command:
    - sleep
    - "3600"
    env:
    - name: MEMORY_REQUEST


      valueFrom:
        resourceFieldRef:
          containerName: test
          resource: requests.memory
    - name: MEMORY_LIMIT


      valueFrom:
        resourceFieldRef:
          containerName: test
          resource: limits.memory
    resources:
      requests:
        memory: 384Mi
      limits:
        memory: 512Mi
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]

Copy to Clipboard

Toggle word wrap

1: Ajoutez cette strophe pour découvrir la valeur de demande de mémoire de l’application.
2: Ajoutez cette strophe pour découvrir la valeur limite de mémoire de l’application.

Créez le pod en exécutant la commande suivante:
```
oc create -f <file_name>.yaml
```
```
$ oc create -f <file_name>.yaml
```
Copy to Clipboard Toggle word wrap

La vérification

Accédez au pod à l’aide d’un shell distant:
```
oc rsh test
```
```
$ oc rsh test
```
Copy to Clipboard Toggle word wrap
Assurez-vous que les valeurs demandées ont été appliquées:
```
env | grep MEMORY | sort
```
```
$ env | grep MEMORY | sort
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
MEMORY_LIMIT=536870912
MEMORY_REQUEST=402653184
```
```
MEMORY_LIMIT=536870912
MEMORY_REQUEST=402653184
```
Copy to Clipboard Toggle word wrap

Note

La valeur limite de mémoire peut également être lue à l’intérieur du conteneur par le fichier /sys/fs/cgroup/memory.limit_in_bytes.

5.5.4. Comprendre la politique de l’OOM
Copier lien

Le service OpenShift de Red Hat sur AWS peut tuer un processus dans un conteneur si l’utilisation totale de la mémoire de tous les processus dans le conteneur dépasse la limite de mémoire, ou dans les cas graves d’épuisement de la mémoire des nœuds.

Lorsqu’un processus est hors mémoire (OOM) tué, cela peut entraîner la sortie immédiate du conteneur. Lorsque le procédé PID 1 du conteneur reçoit le SIGKILL, le conteneur sortira immédiatement. Dans le cas contraire, le comportement du conteneur dépend du comportement des autres processus.

À titre d’exemple, un processus de conteneur est sorti avec le code 137, indiquant qu’il a reçu un signal SIGKILL.

Dans le cas où le conteneur ne sort pas immédiatement, une mise à mort d’OOM est détectable comme suit:

Accédez au pod à l’aide d’un shell distant:
```
oc rsh test
```
```
# oc rsh test
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante pour voir le compte de destruction OOM actuel dans /sys/fs/cgroup/memory/memory.oom_control:
```
grep '^oom_kill ' /sys/fs/cgroup/memory/memory.oom_control
```
```
$ grep '^oom_kill ' /sys/fs/cgroup/memory/memory.oom_control
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
oom_kill 0
```
```
oom_kill 0
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante pour provoquer un meurtre d’OOM:
```
sed -e '' </dev/zero
```
```
$ sed -e '' </dev/zero
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
Killed
```
```
Killed
```
Copy to Clipboard Toggle word wrap
Exécutez la commande suivante pour afficher l’état de sortie de la commande sed:
```
echo $?
```
```
$ echo $?
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
137
```
```
137
```
Copy to Clipboard Toggle word wrap
Le code 137 indique le processus de conteneur sorti avec le code 137, indiquant qu’il a reçu un signal SIGKILL.
Exécutez la commande suivante pour voir que le compteur OOM kill dans /sys/fs/cgroup/memory/memory.oom_control incrémented:
```
grep '^oom_kill ' /sys/fs/cgroup/memory/memory.oom_control
```
```
$ grep '^oom_kill ' /sys/fs/cgroup/memory/memory.oom_control
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
oom_kill 1
```
```
oom_kill 1
```
Copy to Clipboard Toggle word wrap
Lorsqu’un ou plusieurs processus dans une gousse sont tués, lorsque la gousse quitte par la suite, que ce soit immédiatement ou non, elle aura échoué et raisonne OOMKilled. Il est possible qu’une gousse tuée par OOM soit redémarrée en fonction de la valeur de redémarragePolicy. En cas de redémarrage, les contrôleurs tels que le contrôleur de réplication remarqueront l’état raté du pod et créeront un nouveau pod pour remplacer l’ancien.
Faites appel à la commande follwing pour obtenir le statut du pod:
```
oc get pod test
```
```
$ oc get pod test
```
Copy to Clipboard Toggle word wrap
Exemple de sortie
```
NAME      READY     STATUS      RESTARTS   AGE
test      0/1       OOMKilled   0          1m
```
```
NAME      READY     STATUS      RESTARTS   AGE
test      0/1       OOMKilled   0          1m
```
Copy to Clipboard Toggle word wrap
- Lorsque le pod n’a pas redémarré, exécutez la commande suivante pour afficher le pod:
  $ oc get pod test -o yaml
  Copy to Clipboard Toggle word wrap
  Exemple de sortie
  ... status: containerStatuses: - name: test ready: false restartCount: 0 state: terminated: exitCode: 137 reason: OOMKilled phase: Failed
  
  Copy to Clipboard Toggle word wrap
- En cas de redémarrage, exécutez la commande suivante pour afficher le pod:
  $ oc get pod test -o yaml
  Copy to Clipboard Toggle word wrap
  Exemple de sortie
  ... status: containerStatuses: - name: test ready: true restartCount: 1 lastState: terminated: exitCode: 137 reason: OOMKilled state: running: phase: Running
  
  Copy to Clipboard Toggle word wrap

5.5.5. Comprendre l’expulsion des pod
Copier lien

Le service OpenShift Red Hat sur AWS peut expulser un pod de son nœud lorsque la mémoire du nœud est épuisée. En fonction de l’ampleur de l’épuisement de la mémoire, l’expulsion peut ou peut ne pas être gracieuse. L’expulsion gracieuse implique le processus principal (PID 1) de chaque conteneur recevant un signal SIGTERM, puis quelque temps plus tard un signal SIGKILL si le processus n’est pas déjà sorti. L’expulsion non gracieuse implique le processus principal de chaque conteneur recevant immédiatement un signal SIGKILL.

La phase d’expulsion d’une gousse a échoué et la raison de l’expulsion. Il ne sera pas redémarré, quelle que soit la valeur de redémarragePolicy. Cependant, les contrôleurs tels que le contrôleur de réplication remarqueront l’état défaillant du pod et créeront un nouveau pod pour remplacer l’ancien.

oc get pod test

$ oc get pod test

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME      READY     STATUS    RESTARTS   AGE
test      0/1       Evicted   0          1m

NAME      READY     STATUS    RESTARTS   AGE
test      0/1       Evicted   0          1m

Copy to Clipboard

Toggle word wrap

oc get pod test -o yaml

$ oc get pod test -o yaml

Copy to Clipboard

Toggle word wrap

Exemple de sortie

...
status:
  message: 'Pod The node was low on resource: [MemoryPressure].'
  phase: Failed
  reason: Evicted

...
status:
  message: 'Pod The node was low on resource: [MemoryPressure].'
  phase: Failed
  reason: Evicted

Copy to Clipboard

Toggle word wrap

Chapitre 6. Configuration des limites PID
Copier lien

L’identificateur de processus (PID) est un identifiant unique attribué par le noyau Linux à chaque processus ou thread actuellement exécuté sur un système. Le nombre de processus pouvant s’exécuter simultanément sur un système est limité à 4 194 304 par le noyau Linux. Ce nombre pourrait également être affecté par un accès limité à d’autres ressources du système telles que la mémoire, le CPU et l’espace disque.

Dans Red Hat OpenShift Service sur AWS 4.11 et plus tard, par défaut, un pod peut avoir un maximum de 4 096 PID. Lorsque votre charge de travail nécessite plus que cela, vous pouvez augmenter le nombre maximal autorisé de PID en configurant un objet KubeletConfig.

Le service OpenShift Red Hat sur les clusters AWS exécutant des versions antérieures à 4.11 utilise une limite PID par défaut de 1024.

6.1. Comprendre les limites d’identification du processus
Copier lien

Dans Red Hat OpenShift Service sur AWS, considérez ces deux limites prises en charge pour l’utilisation de l’ID de processus (PID) avant de planifier le travail sur votre cluster:

Le nombre maximum de PID par dose.
La valeur par défaut est 4,096 dans Red Hat OpenShift Service sur AWS 4.11 et versions ultérieures. Cette valeur est contrôlée par le paramètre podPidsLimit défini sur le nœud.
Le nombre maximum de PID par nœud.
La valeur par défaut dépend des ressources des nœuds. Dans Red Hat OpenShift Service sur AWS, cette valeur est contrôlée par le paramètre --system-réservé, qui réserve des PID sur chaque nœud en fonction des ressources totales du nœud.

Lorsqu’une gousse dépasse le nombre maximal autorisé de PID par dose, la gousse peut cesser de fonctionner correctement et peut être expulsée du nœud. Consultez la documentation Kubernetes pour les signaux d’expulsion et les seuils pour plus d’informations.

Lorsqu’un nœud dépasse le nombre maximal autorisé de PID par nœud, le nœud peut devenir instable car les nouveaux processus ne peuvent pas avoir de PID assignés. Lorsque les processus existants ne peuvent pas s’achever sans créer de processus supplémentaires, l’ensemble du nœud peut devenir inutilisable et nécessiter un redémarrage. Cette situation peut entraîner une perte de données, en fonction des processus et des applications en cours d’exécution. Les administrateurs clients et Red Hat Site Reliability Engineering sont informés lorsque ce seuil est atteint, et un nœud de travail connaît un avertissement de sécurité PIDP apparaîtra dans les journaux des clusters.

6.2. Les risques de définir des limites d’identification de processus plus élevées pour Red Hat OpenShift Service sur les pods AWS
Copier lien

Le paramètre podPidsLimit pour un pod contrôle le nombre maximum de processus et de threads qui peuvent s’exécuter simultanément dans ce pod.

Il est possible d’augmenter la valeur de podPidsLimit de la valeur par défaut de 4,096 à un maximum de 16 384. Changer cette valeur peut entraîner des temps d’arrêt pour les applications, car changer le podPidsLimit nécessite le redémarrage du nœud affecté.

Lorsque vous exécutez un grand nombre de gousses par nœud et que vous avez une valeur podPidsLimit élevée sur vos nœuds, vous risquez de dépasser le maximum de PID pour le nœud.

Afin de trouver le nombre maximal de gousses que vous pouvez exécuter simultanément sur un seul nœud sans dépasser le maximum de PID pour le nœud, divisez 3 650 000 par votre valeur podPidsLimit. À titre d’exemple, si votre valeur podPidsLimit est 16 384 et que vous vous attendez à ce que les gousses utilisent près de ce nombre d’IDs de processus, vous pouvez exécuter en toute sécurité 222 gousses sur un seul nœud.

Note

La mémoire, le CPU et le stockage disponible peuvent également limiter le nombre maximum de gousses pouvant fonctionner simultanément, même lorsque la valeur podPidsLimit est définie de manière appropriée. En savoir plus, voir « Planifier votre environnement » et « Limites et évolutivité ».

6.3. Définition d’une limite d’identification de processus plus élevée sur un service Red Hat OpenShift existant sur le cluster AWS
Copier lien

Il est possible de définir un podPidsLimit supérieur sur un cluster Red Hat OpenShift Service sur AWS (ROSA) en créant ou en modifiant un objet KubeletConfig qui modifie le paramètre --pod-pids-limit.

Important

Changer le podPidsLimit sur un cluster existant déclenchera des nœuds de plan non de contrôle dans le cluster pour redémarrer un à la fois. Faites ce changement en dehors des heures d’utilisation maximales pour votre cluster et évitez de mettre à niveau ou d’hiber votre cluster jusqu’à ce que tous les nœuds aient redémarré.

Conditions préalables

Il y a un Red Hat OpenShift Service sur AWS cluster.
Le ROSA CLI (rosa) a été installé.
L’OpenShift CLI (oc) a été installé.
En utilisant le ROSA CLI, vous vous êtes connecté à votre compte Red Hat.

Procédure

Créez ou modifiez l’objet KubeletConfig pour modifier la limite PID.
- Lorsque c’est la première fois que vous modifiez la limite PID par défaut, créez l’objet KubeletConfig et définissez la valeur --pod-pids-limit en exécutant la commande suivante:
  $ rosa create kubeletconfig -c <cluster_name> --name <kubeletconfig_name> --pod-pids-limit=<value>
  Copy to Clipboard Toggle word wrap
  Note
  Le paramètre --name est facultatif sur les clusters ROSA Classic, car un seul objet KubeletConfig est pris en charge par le cluster ROSA Classic.
  À titre d’exemple, la commande suivante définit un maximum de 16 384 PID par pod pour le cluster my-cluster:
  $ rosa create kubeletconfig -c my-cluster --name set-high-pids --pod-pids-limit=16384
  Copy to Clipboard Toggle word wrap
- Lorsque vous avez précédemment créé un objet KubeletConfig, modifiez l’objet KubeletConfig existant et définissez la valeur --pod-pids-limit en exécutant la commande suivante:
  $ rosa edit kubeletconfig -c <cluster_name> --name <kubeletconfig_name> --pod-pids-limit=<value>
  Copy to Clipboard Toggle word wrap
Le redémarrage des nœuds ouvriers à l’échelle du cluster est déclenché.

Assurez-vous que tous les nœuds ouvriers ont redémarré en exécutant la commande suivante:

oc get machineconfigpool

$ oc get machineconfigpool

Copy to Clipboard

Toggle word wrap

Exemple de sortie

NAME      CONFIG                    UPDATED  UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT  AGE
master    rendered-master-06c9c4…   True     False      False     3             3                  3                   0                     4h42m
worker    rendered-worker-f4b64…    True     False      False     4             4                  4                   0                     4h42m

NAME      CONFIG                    UPDATED  UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT  AGE
master    rendered-master-06c9c4…   True     False      False     3             3                  3                   0                     4h42m
worker    rendered-worker-f4b64…    True     False      False     4             4                  4                   0                     4h42m

Copy to Clipboard

Toggle word wrap

La vérification

Lorsque chaque nœud du cluster est redémarré, vous pouvez vérifier que le nouveau paramètre est en place.

Consultez la limite de Pod Pids dans l’objet KubeletConfig:
```
rosa describe kubeletconfig --cluster=<cluster_name>
```
```
$ rosa describe kubeletconfig --cluster=<cluster_name>
```
Copy to Clipboard Toggle word wrap
La nouvelle limite de PID apparaît dans la sortie, comme indiqué dans l’exemple suivant:
Exemple de sortie
```
Pod Pids Limit:                       16384
```
```
Pod Pids Limit:                       16384
```
Copy to Clipboard Toggle word wrap

6.4. La suppression de la configuration personnalisée d’un cluster
Copier lien

Il est possible de supprimer la configuration personnalisée de votre cluster en supprimant l’objet KubeletConfig qui contient les détails de configuration.

Conditions préalables

Il existe un service Red Hat OpenShift sur AWS cluster.
Le ROSA CLI (rosa) a été installé.
En utilisant le ROSA CLI, vous vous êtes connecté à votre compte Red Hat.

Procédure

Enlevez la configuration personnalisée du cluster en supprimant l’objet KubeletConfig personnalisé pertinent:
```
rosa delete kubeletconfig --cluster <cluster_name> --name <kubeletconfig_name>
```
```
$ rosa delete kubeletconfig --cluster <cluster_name> --name <kubeletconfig_name>
```
Copy to Clipboard Toggle word wrap

Étapes de vérification

Confirmez que l’objet KubeletConfig personnalisé n’est pas listé pour le cluster:
```
rosa describe kubeletconfig --name <cluster_name>
```
```
$ rosa describe kubeletconfig --name <cluster_name>
```
Copy to Clipboard Toggle word wrap

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

Administration des clusters

Configuration de Red Hat OpenShift Service sur les clusters AWS

Chapitre 1. Les notifications de clusterCopier lienLien copié sur presse-papiers!

1.2. À quoi s’attendre des notifications de clusterCopier lienLien copié sur presse-papiers!

1.2.1. La politique de notification par groupeCopier lienLien copié sur presse-papiers!

1.2.2. Les niveaux de gravité de la notification par groupeCopier lienLien copié sur presse-papiers!

1.2.3. Les types de notification de clusterCopier lienLien copié sur presse-papiers!

1.3. Affichage des notifications de cluster à l’aide de la console Red Hat Hybrid CloudCopier lienLien copié sur presse-papiers!

1.4. Courriels de notification de clusterCopier lienLien copié sur presse-papiers!

1.4.1. Ajout de contacts de notification à votre clusterCopier lienLien copié sur presse-papiers!

1.4.2. La suppression des contacts de notification de votre clusterCopier lienLien copié sur presse-papiers!

1.5. Résolution de problèmesCopier lienLien copié sur presse-papiers!

Chapitre 2. Configuration des connexions privéesCopier lienLien copié sur presse-papiers!

2.1. Configuration des connexions privéesCopier lienLien copié sur presse-papiers!

2.2. Configuration du peering AWS VPCCopier lienLien copié sur presse-papiers!

2.2.1. Conditions de peering VPCCopier lienLien copié sur presse-papiers!

2.2.2. Lancement de la demande de pairs VPCCopier lienLien copié sur presse-papiers!

2.2.3. Accepter la demande de pairs VPCCopier lienLien copié sur presse-papiers!

2.2.4. Configuration des tables de routageCopier lienLien copié sur presse-papiers!

2.2.5. La vérification et le dépannage de VPC peeringCopier lienLien copié sur presse-papiers!

2.3. Configuration du VPN AWSCopier lienLien copié sur presse-papiers!

2.3.1. Création d’une connexion VPNCopier lienLien copié sur presse-papiers!

2.3.1.1. Configuration de la connexion VPNCopier lienLien copié sur presse-papiers!

2.3.1.2. Établir la connexion VPNCopier lienLien copié sur presse-papiers!

2.3.1.3. Activer la propagation d’itinéraire VPNCopier lienLien copié sur presse-papiers!

2.3.2. La vérification de la connexion VPNCopier lienLien copié sur presse-papiers!

2.3.3. Dépannage de la connexion VPNCopier lienLien copié sur presse-papiers!

Le tunnel ne se connecte pas

Le tunnel ne reste pas connecté

Tunnel secondaire dans l’état de Down

2.4. Configuration d’AWS Direct ConnectCopier lienLien copié sur presse-papiers!

2.4.1. AWS Direct Connect méthodesCopier lienLien copié sur presse-papiers!

2.4.2. Création de l’interface virtuelle hébergéeCopier lienLien copié sur presse-papiers!

2.4.2.1. Déterminer le type de connexion Direct ConnectCopier lienLien copié sur presse-papiers!

2.4.2.2. Création d’une connexion directe privéeCopier lienLien copié sur presse-papiers!

2.4.2.3. Création d’une connexion publique directeCopier lienLien copié sur presse-papiers!

2.4.2.4. La vérification des interfaces virtuellesCopier lienLien copié sur presse-papiers!

2.4.3. Connexion à une passerelle de connexion directe existanteCopier lienLien copié sur presse-papiers!

2.4.4. Dépannage Direct ConnectCopier lienLien copié sur presse-papiers!

Chapitre 3. Cluster autoscalingCopier lienLien copié sur presse-papiers!

3.1. À propos du cluster autoscalerCopier lienLien copié sur presse-papiers!

Élimination automatique des nœuds

Limites

Interaction avec d’autres fonctions de planification

3.2. Activer la mise à l’échelle automatique lors de la création de clusters avec OpenShift Cluster ManagerCopier lienLien copié sur presse-papiers!

3.3. Activer l’autoscaling après la création de clusters avec OpenShift Cluster ManagerCopier lienLien copié sur presse-papiers!

3.4. Cluster Autoscaling paramètres à l’aide d’OpenShift Cluster ManagerCopier lienLien copié sur presse-papiers!

3.4.1. Les paramètres générauxCopier lienLien copié sur presse-papiers!

3.4.2. Limites de ressourcesCopier lienLien copié sur presse-papiers!

3.4.3. Faites baisser la configurationCopier lienLien copié sur presse-papiers!

3.5. Activer la mise à l’échelle automatique lors de la création de clusters en utilisant le mode interactif avec le ROSA CLICopier lienLien copié sur presse-papiers!

3.6. Activer l’autoscaling après la création de clusters en utilisant le mode interactif avec le ROSA CLICopier lienLien copié sur presse-papiers!

3.7. Activer l’autoscaling lors de la création de clusters avec le ROSA CLICopier lienLien copié sur presse-papiers!

3.8. Activer l’autoscaling après la création de clusters avec le ROSA CLICopier lienLien copié sur presse-papiers!

3.9. Éditer l’autoscaling après la création de cluster avec le ROSA CLICopier lienLien copié sur presse-papiers!

3.10. Afficher les configurations d’autoscaler avec le ROSA CLICopier lienLien copié sur presse-papiers!

3.11. Effacer la mise à l’échelle automatique à l’aide du ROSA CLICopier lienLien copié sur presse-papiers!

3.12. Cluster de paramètres de mise à l’échelle automatique à l’aide de la ROSA CLICopier lienLien copié sur presse-papiers!

Chapitre 4. Cluster autoscaling pour ROSA HCPCopier lienLien copié sur presse-papiers!

4.1. À propos du cluster autoscalerCopier lienLien copié sur presse-papiers!

Élimination automatique des nœuds

Limites

Interaction avec d’autres fonctions de planification

4.2. Éditer l’autoscaling après la création de cluster avec le ROSA CLICopier lienLien copié sur presse-papiers!

4.3. Afficher les configurations d’autoscaler avec le ROSA CLICopier lienLien copié sur presse-papiers!

4.4. Cluster de paramètres de mise à l’échelle automatique à l’aide de la ROSA CLICopier lienLien copié sur presse-papiers!

Chapitre 5. Gérer les nœuds à l’aide de pools de machinesCopier lienLien copié sur presse-papiers!

5.1. À propos des piscines de machinesCopier lienLien copié sur presse-papiers!

5.1.1. Les machinesCopier lienLien copié sur presse-papiers!

5.1.2. Ensembles de machinesCopier lienLien copié sur presse-papiers!

5.1.3. Les piscines de machinesCopier lienLien copié sur presse-papiers!

5.1.3.1. Pools de machines pendant l’installation du clusterCopier lienLien copié sur presse-papiers!

5.1.3.2. Configuration des pools de machines après l’installation du clusterCopier lienLien copié sur presse-papiers!

5.1.4. Pools de machines dans plusieurs clusters de zonesCopier lienLien copié sur presse-papiers!

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

5.2. Gérer les nœuds de calculCopier lienLien copié sur presse-papiers!

5.2.1. Création d’un pool de machinesCopier lienLien copié sur presse-papiers!

5.2.1.1. Création d’un pool de machines à l’aide d’OpenShift Cluster ManagerCopier lienLien copié sur presse-papiers!

5.2.1.2. Création d’un pool de machines à l’aide du ROSA CLICopier lienLien copié sur presse-papiers!

5.2.2. Configuration du volume de disque de pool machineCopier lienLien copié sur presse-papiers!

Chapitre 1. Les notifications de cluster
Copier lien

1.2. À quoi s’attendre des notifications de cluster
Copier lien

1.2.1. La politique de notification par groupe
Copier lien

1.2.2. Les niveaux de gravité de la notification par groupe
Copier lien

1.2.3. Les types de notification de cluster
Copier lien

1.3. Affichage des notifications de cluster à l’aide de la console Red Hat Hybrid Cloud
Copier lien

1.4. Courriels de notification de cluster
Copier lien

1.4.1. Ajout de contacts de notification à votre cluster
Copier lien

1.4.2. La suppression des contacts de notification de votre cluster
Copier lien

1.5. Résolution de problèmes
Copier lien

Chapitre 2. Configuration des connexions privées
Copier lien

2.1. Configuration des connexions privées
Copier lien

2.2. Configuration du peering AWS VPC
Copier lien

2.2.1. Conditions de peering VPC
Copier lien

2.2.2. Lancement de la demande de pairs VPC
Copier lien

2.2.3. Accepter la demande de pairs VPC
Copier lien

2.2.4. Configuration des tables de routage
Copier lien

2.2.5. La vérification et le dépannage de VPC peering
Copier lien

2.3. Configuration du VPN AWS
Copier lien

2.3.1. Création d’une connexion VPN
Copier lien

2.3.1.1. Configuration de la connexion VPN
Copier lien

2.3.1.2. Établir la connexion VPN
Copier lien

2.3.1.3. Activer la propagation d’itinéraire VPN
Copier lien

2.3.2. La vérification de la connexion VPN
Copier lien

2.3.3. Dépannage de la connexion VPN
Copier lien

2.4. Configuration d’AWS Direct Connect
Copier lien

2.4.1. AWS Direct Connect méthodes
Copier lien

2.4.2. Création de l’interface virtuelle hébergée
Copier lien

2.4.2.1. Déterminer le type de connexion Direct Connect
Copier lien

2.4.2.2. Création d’une connexion directe privée
Copier lien

2.4.2.3. Création d’une connexion publique directe
Copier lien

2.4.2.4. La vérification des interfaces virtuelles
Copier lien

2.4.3. Connexion à une passerelle de connexion directe existante
Copier lien

2.4.4. Dépannage Direct Connect
Copier lien

Chapitre 3. Cluster autoscaling
Copier lien

3.1. À propos du cluster autoscaler
Copier lien

3.2. Activer la mise à l’échelle automatique lors de la création de clusters avec OpenShift Cluster Manager
Copier lien

3.3. Activer l’autoscaling après la création de clusters avec OpenShift Cluster Manager
Copier lien

3.4. Cluster Autoscaling paramètres à l’aide d’OpenShift Cluster Manager
Copier lien

3.4.1. Les paramètres généraux
Copier lien

3.4.2. Limites de ressources
Copier lien

3.4.3. Faites baisser la configuration
Copier lien

3.5. Activer la mise à l’échelle automatique lors de la création de clusters en utilisant le mode interactif avec le ROSA CLI
Copier lien

3.6. Activer l’autoscaling après la création de clusters en utilisant le mode interactif avec le ROSA CLI
Copier lien

3.7. Activer l’autoscaling lors de la création de clusters avec le ROSA CLI
Copier lien

3.8. Activer l’autoscaling après la création de clusters avec le ROSA CLI
Copier lien

3.9. Éditer l’autoscaling après la création de cluster avec le ROSA CLI
Copier lien

3.10. Afficher les configurations d’autoscaler avec le ROSA CLI
Copier lien

3.11. Effacer la mise à l’échelle automatique à l’aide du ROSA CLI
Copier lien

3.12. Cluster de paramètres de mise à l’échelle automatique à l’aide de la ROSA CLI
Copier lien

Chapitre 4. Cluster autoscaling pour ROSA HCP
Copier lien

4.1. À propos du cluster autoscaler
Copier lien

4.2. Éditer l’autoscaling après la création de cluster avec le ROSA CLI
Copier lien

4.3. Afficher les configurations d’autoscaler avec le ROSA CLI
Copier lien

4.4. Cluster de paramètres de mise à l’échelle automatique à l’aide de la ROSA CLI
Copier lien

Chapitre 5. Gérer les nœuds à l’aide de pools de machines
Copier lien

5.1. À propos des piscines de machines
Copier lien

5.1.1. Les machines
Copier lien

5.1.2. Ensembles de machines
Copier lien

5.1.3. Les piscines de machines
Copier lien

5.1.3.1. Pools de machines pendant l’installation du cluster
Copier lien

5.1.3.2. Configuration des pools de machines après l’installation du cluster
Copier lien

5.1.4. Pools de machines dans plusieurs clusters de zones
Copier lien

5.1.5. Ressources supplémentaires
Copier lien

5.2. Gérer les nœuds de calcul
Copier lien

5.2.1. Création d’un pool de machines
Copier lien

5.2.1.1. Création d’un pool de machines à l’aide d’OpenShift Cluster Manager
Copier lien

5.2.1.2. Création d’un pool de machines à l’aide du ROSA CLI
Copier lien

5.2.2. Configuration du volume de disque de pool machine
Copier lien

5.2.2.1. Configuration du volume de disque de pool machine à l’aide d’OpenShift Cluster Manager
Copier lien

5.2.2.2. Configuration du volume de disque de pool machine à l’aide du ROSA CLI
Copier lien

5.2.3. La suppression d’une piscine de machines
Copier lien

5.2.3.1. La suppression d’un pool de machines à l’aide d’OpenShift Cluster Manager
Copier lien

5.2.3.2. La suppression d’un pool de machines à l’aide de la ROSA CLI
Copier lien

5.2.4. Calcul à l’échelle des nœuds manuellement
Copier lien

5.2.5. Étiquettes des nœuds
Copier lien

5.2.5.1. Ajout d’étiquettes de nœuds à un pool de machines
Copier lien

5.2.6. Ajout de tags à un pool de machines
Copier lien

5.2.6.1. Ajout de tags à un pool de machines à l’aide du ROSA CLI
Copier lien

5.2.7. Ajout de taintes à une piscine de machines
Copier lien