Administration des clusters
Configuration de clusters dédiés OpenShift
Résumé
Chapitre 1. Les notifications de cluster Copier lienLien copié sur presse-papiers!
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 lienLien copié sur presse-papiers!
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 lienLien copié sur presse-papiers!
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 lienLien copié sur presse-papiers!
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 lienLien copié sur presse-papiers!
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 lienLien copié sur presse-papiers!
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 lienLien copié sur presse-papiers!
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 lienLien copié sur presse-papiers!
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 lienLien copié sur presse-papiers!
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 lienLien copié sur presse-papiers!
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 lienLien copié sur presse-papiers!
2.1. Configuration des connexions privées pour AWS Copier lienLien copié sur presse-papiers!
2.1.1. Comprendre l’accès à l’infrastructure cloud AWS Copier lienLien copié sur presse-papiers!
L’accès à l’infrastructure cloud AWS ne s’applique pas au type d’infrastructure d’abonnement cloud client (CCS) qui est choisi lors de la création d’un cluster car les clusters CCS sont déployés sur votre compte.
L’accès à l’infrastructure Amazon Web Services (AWS) permet aux administrateurs d’organisation du portail client et aux propriétaires de clusters de permettre aux utilisateurs d’AWS Identity and Access Management (IAM) d’avoir un accès fédéré à la console de gestion AWS pour leur cluster dédié OpenShift. L’accès AWS peut être accordé aux utilisateurs AWS clients, et l’accès au cluster privé peut être mis en œuvre pour répondre aux besoins de votre environnement dédié OpenShift.
- Commencez par configurer l’accès à l’infrastructure AWS pour votre cluster dédié OpenShift. En créant un utilisateur et un compte AWS et en fournissant à cet utilisateur un accès au compte AWS dédié OpenShift.
Après avoir accès au compte AWS dédié OpenShift, 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.
Après avoir configuré l’accès à votre infrastructure cloud, apprenez-en davantage sur la configuration d’un cluster privé.
2.1.2. Configuration de l’accès à l’infrastructure AWS Copier lienLien copié sur presse-papiers!
L’accès à l’infrastructure Amazon Web Services (AWS) permet aux administrateurs d’organisation du portail client et aux propriétaires de clusters de permettre aux utilisateurs d’AWS Identity and Access Management (IAM) d’avoir un accès fédéré à la console de gestion AWS pour leur cluster dédié OpenShift. Les administrateurs peuvent choisir entre les options de gestion de réseau ou d’accès en lecture seule.
Conditions préalables
- Compte AWS avec les autorisations IAM.
Procédure
- Connectez-vous à votre compte AWS. Au besoin, vous pouvez créer un nouveau compte AWS en suivant la documentation AWS.
Créez un utilisateur IAM avec les autorisations STS:AllowAssumeRole dans le compte AWS.
- Ouvrez le tableau de bord IAM de la console de gestion AWS.
- Dans la section Politiques, cliquez sur Créer une stratégie.
Choisissez l’onglet JSON et remplacez le texte existant par ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Cliquez sur Next:Tags.
- Facultatif: Ajouter des tags. Cliquez sur Suivant:Review
- Fournissez un nom et une description appropriés, puis cliquez sur Créer une stratégie.
- Dans la section Utilisateurs, cliquez sur Ajouter un utilisateur.
- Fournir un nom d’utilisateur approprié.
- Choisissez AWS Management Console comme type d’accès AWS.
- Ajustez les exigences de mot de passe si nécessaire pour votre organisation, puis cliquez sur Next:Permissions.
Cliquez sur l’option attacher directement les politiques existantes. Cherchez et vérifiez la stratégie créée lors des étapes précédentes.
NoteIl n’est pas recommandé de définir une limite d’autorisations.
- Cliquez sur Suivant: Tags, puis cliquez sur Suivant: Review. Confirmez que la configuration est correcte.
- Cliquez sur Créer un utilisateur, une page de succès apparaît.
- Collectez le nom de ressource Amazon (ARN) de l’utilisateur IAM. L’ARN aura le format suivant: arn:aws:iam::000111222333:user/nom d’utilisateur. Cliquez sur Close.
- Ouvrez OpenShift Cluster Manager dans votre navigateur et sélectionnez le cluster que vous souhaitez autoriser l’accès à l’infrastructure AWS.
- Choisissez l’onglet Contrôle d’accès et faites défiler la section Accès à l’infrastructure AWS.
- Collez l’ARN AWS IAM et sélectionnez les autorisations de gestion de réseau ou de lecture seule, puis cliquez sur le rôle Subvention.
- Copiez l’URL de la console AWS OSD dans votre presse-papiers.
- Connectez-vous à votre compte AWS avec votre identifiant ou alias de compte, votre nom d’utilisateur IAM et votre mot de passe.
- Dans un nouvel onglet de navigateur, collez l’URL AWS OSD Console qui sera utilisée pour acheminer vers la page AWS Switch Role.
- Le numéro et le rôle de votre compte seront déjà remplis. Choisissez un nom d’affichage si nécessaire, puis cliquez sur Switch Role.
La vérification
- Aujourd’hui, vous voyez VPC sous Services récemment visités.
2.1.3. Configuration du peering AWS VPC Copier lienLien copié sur presse-papiers!
La connexion de peering Virtual Private Cloud (VPC) est une connexion réseau entre deux VPC qui vous permet d’acheminer le trafic entre eux à l’aide d’adresses IPv4 privées ou d’adresses IPv6. Il est possible de configurer un VPC Amazon Web Services (AWS) contenant un cluster OpenShift dédié à un autre réseau AWS VPC.
Avant de tenter de désinstaller un cluster, vous devez supprimer toutes les connexions de peering VPC du cluster VPC. Le défaut de le faire pourrait entraîner un cluster ne pas terminer le processus de désinstallation.
AWS prend en charge l’interrégion VPC peering entre toutes les régions commerciales à l’exclusion de la Chine.
Conditions préalables
Collecter les informations suivantes sur le VPC du Client qui est nécessaire 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 OpenShift Dedicated 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 d’Amazon VPC pour plus de détails. Lorsque les blocs CIDR ne se chevauchent pas, vous pouvez procéder à la procédure.
Procédure
- Initier la demande de peering VPC.
- Acceptez la demande de peering VPC.
- Actualisez vos tables Route pour la connexion de peering VPC.
2.1.4. Configuration d’un VPN AWS Copier lienLien copié sur presse-papiers!
Il est possible de configurer un cluster OpenShift dédié à Amazon Web Services (AWS) pour utiliser l’appareil du réseau privé virtuel (VPN) matériel d’un client. Les instances que vous lancez dans un cloud privé virtuel AWS (VPC) ne peuvent pas communiquer avec votre propre réseau (à distance). Il est possible d’activer l’accès à votre réseau distant à partir de votre PCV en créant une connexion VPN Site-à-Site AWS et en configurant le routage pour passer du trafic via la connexion.
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.
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.
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 la documentation AWS 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.
Procédure
- Créez une passerelle client pour configurer la connexion VPN.
- Lorsque vous n’avez pas déjà une passerelle privée virtuelle attachée au PCV prévu, créez et attachez une passerelle privée virtuelle.
- Configurez le routage et activez la propagation des routes VPN.
- Actualisez votre groupe de sécurité.
Établir la connexion VPN Site à Site.
NoteÀ noter les informations de sous-réseau VPC, que vous devez ajouter à votre configuration en tant que réseau distant.
2.1.5. Configuration d’AWS Direct Connect Copier lienLien copié sur presse-papiers!
Amazon Web Services (AWS) 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 cloud privé virtuel distant (VPC) 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 votre compte AWS.
Lorsque vous avez un DXGateway existant connecté à un ou plusieurs VGW existants, le processus implique que votre compte AWS envoie 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.
Conditions préalables
- Confirmez que la gamme CIDR du PCV dédié OpenShift 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
- Créez un VIF ou visualisez vos VIF existants pour déterminer le type de connexion directe que vous devez créer.
Créez votre passerelle.
- Lorsque le type Direct Connect VIF est privé, créez une passerelle privée virtuelle.
- Lorsque le VIF Direct Connect est public, créez une passerelle Direct Connect.
Lorsque vous avez une passerelle existante que vous souhaitez utiliser, créez une proposition d’association et envoyez la proposition au propriétaire de DXGateway pour approbation.
AvertissementLorsque vous vous connectez à un DXGateway existant, vous êtes responsable des coûts.
2.2. Configuration d’un cluster privé Copier lienLien copié sur presse-papiers!
Le cluster dédié OpenShift peut être privé de sorte que les applications internes puissent être hébergées à l’intérieur d’un réseau d’entreprise. En outre, les clusters privés peuvent être configurés pour n’avoir que des points de terminaison internes d’API pour une sécurité accrue.
Les administrateurs dédiés d’OpenShift peuvent choisir entre la configuration de cluster public et privé dans OpenShift Cluster Manager. Les paramètres de confidentialité peuvent être configurés pendant la création de cluster ou après la création d’un cluster.
2.2.1. Activer un cluster privé lors de la création de clusters Copier lienLien copié sur presse-papiers!
Lors de la création d’un nouveau cluster, vous pouvez activer les paramètres de cluster privé.
Conditions préalables
Les connexions privées suivantes doivent être configurées pour permettre un accès privé:
- Le VPC Peering
- Cloud VPN
- DirectConnect (AWS seulement)
- TransitGateway (AWS seulement)
- Interconnexion cloud (GCP uniquement)
Procédure
- Connectez-vous à OpenShift Cluster Manager.
- Cliquez sur Créer un cluster → OpenShift Dédié → Créer un cluster.
- Configurez les détails de votre cluster.
- Lors de la sélection de votre configuration réseau préférée, sélectionnez Advanced.
Choisissez Privé.
AvertissementLorsque vous êtes défini sur Private, vous ne pouvez pas accéder à votre cluster à moins que vous n’ayez configuré les connexions privées de votre fournisseur de cloud comme indiqué dans les prérequis.
- Cliquez sur Créer un cluster. Le processus de création de cluster commence et prend environ 30 à 40 minutes à compléter.
La vérification
- La rubrique Installing cluster, sous l’onglet Aperçu, indique que le cluster est en train d’installer et que vous pouvez afficher les journaux d’installation de cette rubrique. L’indicateur d’état sous la rubrique Détails indique quand votre cluster est prêt à être utilisé.
2.2.2. Permettre à un cluster existant d’être privé Copier lienLien copié sur presse-papiers!
Après la création d’un cluster, vous pouvez plus tard activer le cluster pour être privé.
Conditions préalables
Les connexions privées suivantes doivent être configurées pour permettre un accès privé:
- Le VPC Peering
- Cloud VPN
- DirectConnect (AWS seulement)
- TransitGateway (AWS seulement)
- Interconnexion cloud (GCP uniquement)
Procédure
- Connectez-vous à OpenShift Cluster Manager.
- Choisissez le cluster public que vous souhaitez rendre privé.
Dans l’onglet Networking, sélectionnez Rendre l’API privée sous Control Plane API endpoint.
AvertissementLorsque vous êtes défini sur Private, vous ne pouvez pas accéder à votre cluster à moins que vous n’ayez configuré les connexions privées de votre fournisseur de cloud comme indiqué dans les prérequis.
Cliquez sur Modifier les paramètres.
NoteLa transition de votre cluster entre privé et public peut prendre plusieurs minutes.
2.2.3. Permettre à un cluster privé existant d’être public Copier lienLien copié sur presse-papiers!
Après la création d’un cluster privé, vous pouvez ensuite activer le cluster pour être public.
Procédure
- Connectez-vous à OpenShift Cluster Manager.
- Choisissez le cluster privé que vous souhaitez rendre public.
- Dans l’onglet Networking, désélectionnez l’API privée sous Control Plane API endpoint.
Cliquez sur Modifier les paramètres.
NoteLa transition de votre cluster entre privé et public peut prendre plusieurs minutes.
Chapitre 3. Cluster autoscaling Copier lienLien copié sur presse-papiers!
Appliquer l’autoscaling à OpenShift Dedicated clusters implique la configuration d’un cluster autoscaler puis la configuration d’une machine autoscaler pour au moins un pool de machines dans votre cluster.
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 lienLien copié sur presse-papiers!
Le cluster autoscaler ajuste la taille d’un cluster dédié OpenShift 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.
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.
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 lienLien copié sur presse-papiers!
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.
- 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 lienLien copié sur presse-papiers!
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 lienLien copié sur presse-papiers!
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 lienLien copié sur presse-papiers!
Le réglage | Description | Le type ou la gamme | Défaut par défaut |
---|---|---|---|
| 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. |
| 1 |
| Dans l’affirmative, le cluster autoscaler ne supprime jamais les nœuds avec des pods avec stockage local, par exemple EmptyDir ou HostPath. |
| C’est vrai |
| Donne aux pods un temps de terminaison gracieux en quelques secondes avant de baisser. |
| 600 |
| Le temps maximum que le cluster autoscaler attend que les nœuds soient fournis. |
| 15M |
| 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. |
| -10 |
| 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. |
| faux |
| 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. |
| faux |
| 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. |
| Le format doit être une liste d’étiquettes séparées par les virgules. |
3.4.2. Limites de ressources Copier lienLien copié sur presse-papiers!
Le réglage | Description | Le type ou la gamme | Défaut par défaut |
---|---|---|---|
| Le nombre minimum de cœurs en cluster. Le cluster autoscaler ne met pas à l’échelle le cluster moins que ce nombre. |
| 0 |
| Le nombre maximum de cœurs en cluster. Le cluster autoscaler ne met pas à l’échelle le cluster supérieur à ce nombre. |
| 180 * 64 (11520) |
| Le nombre minimum de gigaoctets de mémoire en cluster. Le cluster autoscaler ne met pas à l’échelle le cluster moins que ce nombre. |
| 0 |
| Le nombre maximum de gigaoctets de mémoire en cluster. Le cluster autoscaler ne met pas à l’échelle le cluster supérieur à ce nombre. |
| 180 * 64 * 20 (230400) |
| 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. |
| 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 format doit être une liste séparée par les virgules de ":<gpu_type> <min>:<max>". |
3.4.3. Faites baisser la configuration Copier lienLien copié sur presse-papiers!
Le réglage | Description | Le type ou la gamme | Défaut par défaut |
---|---|---|---|
| Le cluster autoscaler devrait-il réduire le cluster? |
| C’est vrai |
| 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. |
| 0,5 |
| Combien de temps un nœud devrait être inutile avant qu’il ne soit admissible à la réduction de l’échelle. |
| 10M |
| Combien de temps après l’augmentation de l’échelle de l’évaluation reprend. |
| 10M |
| Combien de temps après la suppression du nœud cette évaluation d’échelle reprend. |
| 0s |
| Combien de temps après l’échec de l’échelle d’échelle reprend l’évaluation. |
| 3M |
Chapitre 4. Les nœuds Copier lienLien copié sur presse-papiers!
4.1. À propos des piscines de machines Copier lienLien copié sur presse-papiers!
L’OpenShift Dedicated utilise des 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 et les pools de machines.
À partir de OpenShift Dedicated 4.11, la limite PID par défaut par-pod est 4096. Lorsque vous souhaitez activer cette limite de PID, vous devez mettre à niveau vos clusters OpenShift Dedicated vers cette version ou ultérieure. Les clusters dédiés qui exécutent des versions antérieures à 4.11 utilisent une limite PID par défaut de 1024.
Il est impossible de configurer la limite PID par pod sur un cluster dédié OpenShift.
4.1.1. Les machines Copier lienLien copié sur presse-papiers!
La machine est une unité fondamentale qui décrit l’hôte pour un nœud ouvrier.
4.1.2. Ensembles de machines Copier lienLien copié sur presse-papiers!
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.
4.1.3. Les piscines de machines Copier lienLien copié sur presse-papiers!
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.
Par défaut, un cluster est créé avec un pool de machines. Il est possible d’ajouter des pools de machines supplémentaires à un cluster existant, de modifier le pool de machines par défaut et de supprimer les pools de machines.
De multiples pools de machines peuvent exister sur un seul cluster, et ils peuvent chacun avoir des types différents ou des nœuds de taille différentes.
4.1.4. Pools de machines dans plusieurs clusters de zones Copier lienLien copié sur presse-papiers!
Lorsque vous créez un pool de machines dans un cluster de zones de disponibilité multiple (Multi-AZ), un pool de machines dispose de 3 zones. Le pool de machines, à son tour, crée un total de 3 ensembles de machines de calcul - un pour chaque zone du cluster. Chacun de ces ensembles de machines de calcul gère une ou plusieurs machines dans sa zone de disponibilité respective.
Lorsque vous créez un nouveau cluster Multi-AZ, les pools de machines sont répliqués automatiquement dans ces zones. Lorsque vous ajoutez un pool de machines à un Multi-AZ existant, le nouveau pool est automatiquement créé dans ces zones. 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.
4.1.4.1. Déploiement d’un pool de machines dans une seule zone de disponibilité au sein d’un cluster Multi-AZ Copier lienLien copié sur presse-papiers!
Les utilisateurs de Google Cloud Platform (GCP) peuvent déployer un pool de machines unique dans une zone de disponibilité spécifique qui fait partie d’un cluster Multi-AZ à l’aide de l’OpenShift Cluster Manager CLI (ocm). Cette option est particulièrement utile dans les situations où un type d’instance souhaité n’est pas disponible dans toutes les zones de disponibilité d’une région spécifique ainsi que lorsque votre cluster n’a pas besoin de plus d’un des types d’instance souhaités.
Lors de la mise à disposition d’un cluster Multi-AZ, vous ne pouvez pas assigner le pool de machines par défaut à une seule zone de disponibilité.
Conditions préalables
- L’interface de ligne de commande de l’API OpenShift Cluster Manager (ocm) a été installée.
L’interface de ligne de commande de l’API OpenShift Cluster Manager (ocm) est uniquement une fonctionnalité de prévisualisation des développeurs. Afin d’obtenir de plus amples informations sur la portée du support des fonctionnalités Red Hat Developer Preview, consultez le champ d’application du support d’aperçu du développeur.
Procédure
- Déployez un pool de machines vers une zone de disponibilité spécifique en exécutant la commande suivante:
- 1
- <cluster_name|cluster_id> par le nom ou l’ID du cluster auquel vous souhaitez ajouter le pool de machines.
- 2
- <instance_type> par le type d’instance que vous souhaitez déployer dans la zone de disponibilité unique.
- 3
- <replicas> par le nombre de répliques du type d’instance sélectionné que vous souhaitez inclure dans le pool de machines.
- 4
- <availability_zone> par la zone de disponibilité à laquelle vous souhaitez ajouter le pool de machines.
- 5
- Facultatif: Remplacer [flags] par tous les drapeaux supplémentaires disponibles pour la création de pool machine.
- 6
- <machine_pool_id> par un identifiant pour votre pool de machines.
Afin d’afficher les drapeaux supplémentaires disponibles pour la création de pool de machines, exécutez la commande ocm Créer machine-pool --help.
Consultez la section Ressources supplémentaires pour plus d’informations sur les types d’instances Google Cloud Platform (GCP) et les zones de disponibilité.
4.2. Gérer les nœuds de calcul Copier lienLien copié sur presse-papiers!
Ce document décrit comment gérer les nœuds de calcul (également connus sous le nom de travailleur) avec OpenShift Dedicated.
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.
4.2.1. Création d’un pool de machines Copier lienLien copié sur presse-papiers!
Le pool de machines est créé lorsque vous installez un cluster dédié OpenShift. Après l’installation, vous pouvez créer des pools de machines supplémentaires pour votre cluster en utilisant OpenShift Cluster Manager.
Les types d’instances de nœuds de calcul (également connus sous le nom de travailleur), les options de mise à l’échelle automatique et les nombres de nœuds disponibles dépendent de vos abonnements dédiés OpenShift, des quotas de ressources et du scénario de déploiement. Contactez votre représentant commercial ou votre support Red Hat pour plus d’informations.
Conditions préalables
- Création d’un cluster OpenShift dédié.
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.
NoteIl 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:
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.
NoteL’option Enable autoscaling n’est disponible que pour OpenShift Dedicated si vous avez l’abonnement capacity.cluster.autoscale_clusters. Contactez votre représentant commercial ou votre support Red Hat pour plus d’informations.
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.
NoteAlternativement, 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.
En option: Ajoutez des étiquettes et des taches de nœud pour votre piscine de machines:
- Développez le menu Edit node et taints.
- Dans les étiquettes Node, ajoutez des entrées Clé et Valeur pour vos étiquettes de nœuds.
Dans Taints, ajoutez des entrées Clé et Valeur pour vos taints.
NoteLa 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.
Dans chaque tainte, sélectionnez un effet dans le menu déroulant. Les options disponibles incluent NoSchedule, PreferNoSchedule et NoExecute.
NoteAlternativement, 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: Si vous avez déployé OpenShift Dedicated sur AWS à l’aide du modèle d’abonnement au cloud client (CCS), 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:
- Choisissez Utilisez Amazon EC2 Spot Instances.
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.
ImportantAmazon EC2 Spot Instances peut être interrompue à tout moment. Amazon EC2 Spot Instances n’utilise que des charges de travail pouvant tolérer des interruptions.
NoteLorsque 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.
4.2.2. La suppression d’une piscine de machines Copier lienLien copié sur presse-papiers!
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 à l’aide de Red Hat OpenShift Cluster Manager.
Conditions préalables
- « vous avez créé un cluster dédié OpenShift.
- Le cluster est dans l’état prêt.
- Il y a un pool de machines existant sans taintes et avec au moins deux répliques pour un cluster Single-AZ ou trois répliques 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é.
4.2.3. Calcul à l’échelle des nœuds manuellement Copier lienLien copié sur presse-papiers!
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
- Création d’un cluster OpenShift dédié.
- Il y a une piscine de machines existante.
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 que vous souhaitez mettre à l’échelle.
- Choisissez l’échelle.
Indiquez le nombre de nœuds:
- Lorsque vous avez déployé votre cluster à l’aide d’une seule zone de disponibilité, spécifiez le nombre de nœuds dans le menu déroulant.
Lorsque vous avez déployé votre cluster à l’aide de plusieurs zones de disponibilité, spécifiez le nombre de nœuds par zone dans le menu déroulant.
NoteL’abonnement détermine le nombre de nœuds que vous pouvez sélectionner.
- Cliquez sur Appliquer pour mettre à l’échelle le pool de machines.
La vérification
- Dans l’onglet Machine pools, vérifiez que le nombre de nœuds pour votre pool de machines est comme prévu.
4.2.4. Étiquettes des nœuds Copier lienLien copié sur presse-papiers!
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.
4.2.4.1. Ajout d’étiquettes de nœuds à un pool de machines Copier lienLien copié sur presse-papiers!
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
- Création d’un cluster OpenShift dédié.
- Il y a une piscine de machines existante.
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 une étiquette.
- Choisissez Modifier les étiquettes.
- Lorsque vous avez des étiquettes existantes dans le pool de machines que vous souhaitez supprimer, sélectionnez x à côté de l’étiquette pour la supprimer.
- Ajoutez une étiquette en utilisant le format <key>=<value> et appuyez sur Entrée. Ajoutez par exemple app=db, puis appuyez sur Entrée. Lorsque le format est correct, la paire de valeurs de clé est alors mise en surbrillance.
- Répétez l’étape précédente si vous souhaitez ajouter des étiquettes supplémentaires.
- Cliquez sur Enregistrer pour appliquer les étiquettes 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 étiquettes sont répertoriées sous Labels dans la vue élargie.
4.2.5. Ajout de taintes à une piscine de machines Copier lienLien copié sur presse-papiers!
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.
Le cluster doit avoir au moins un pool de machines qui ne contient pas de taintes.
Conditions préalables
- Création d’un cluster OpenShift dédié.
- 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.
- Choisissez Ajouter du taint si vous souhaitez ajouter d’autres 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.
4.3. À propos des nœuds autoscaling sur un cluster Copier lienLien copié sur presse-papiers!
L’autoscaling est disponible uniquement sur les clusters achetés via Google Cloud Marketplace et Red Hat Marketplace.
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.
Les propriétaires de clusters et les administrateurs d’organisation peuvent mettre à l’échelle ou supprimer un cluster.
4.3.1. Activer les nœuds de mise à l’échelle automatique sur un cluster Copier lienLien copié sur presse-papiers!
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.
4.3.2. Désactivation des nœuds autoscaling sur un cluster Copier lienLien copié sur presse-papiers!
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.
Désactivez la mise à l’échelle automatique sur un cluster à l’aide de la console OpenShift Cluster Manager.
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.
Appliquer l’autoscaling à un cluster dédié OpenShift implique le déploiement d’un cluster autoscaler, puis le déploiement d’autoscaleurs de machine pour chaque type de machine de votre cluster.
Il est possible de configurer le cluster autoscaler uniquement dans les clusters où l’API Machine est opérationnelle.
4.3.3. À propos du cluster autoscaler Copier lienLien copié sur presse-papiers!
Le cluster autoscaler ajuste la taille d’un cluster dédié OpenShift 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.
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.
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.
Legal Notice
Copier lienLien copié sur presse-papiers!
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.