Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Chapitre 7. Planifier votre environnement en fonction des maxima d'objets

Prenez en compte les maximums d'objets testés suivants lorsque vous planifiez votre cluster OpenShift Container Platform.

Ces lignes directrices sont basées sur la plus grande grappe possible. Pour les clusters plus petits, les maxima sont inférieurs. De nombreux facteurs influencent les seuils indiqués, notamment la version d'etcd ou le format des données de stockage.

Dans la plupart des cas, le dépassement de ces nombres entraîne une baisse des performances globales. Cela ne signifie pas nécessairement que la grappe échouera.

Avertissement

Les clusters qui subissent des changements rapides, tels que ceux qui ont de nombreux pods qui démarrent et s'arrêtent, peuvent avoir une taille maximale pratique inférieure à celle qui est documentée.

Note

Red Hat ne fournit pas de conseils directs sur le dimensionnement de votre cluster OpenShift Container Platform. En effet, pour déterminer si votre cluster est dans les limites supportées par OpenShift Container Platform, il faut prendre en compte tous les facteurs multidimensionnels qui limitent l'échelle du cluster.

OpenShift Container Platform prend en charge des maximums de clusters testés plutôt que des maximums absolus de clusters. Toutes les combinaisons de version d'OpenShift Container Platform, de charge de travail du plan de contrôle et de plugin réseau ne sont pas testées, de sorte que le tableau suivant ne représente pas une attente absolue d'échelle pour tous les déploiements. Il se peut qu'il ne soit pas possible d'atteindre une échelle maximale sur toutes les dimensions simultanément. Le tableau contient des maxima testés pour des charges de travail et des configurations de déploiement spécifiques, et sert de guide d'échelle pour ce à quoi on peut s'attendre avec des déploiements similaires.

Expand
Type maximum4.x maximum testé

Nombre de nœuds

2,000 [1]

Nombre de nacelles [2]

150,000

Nombre de pods par nœud

500 [3]

Nombre de pods par cœur

Il n'y a pas de valeur par défaut.

Nombre d'espaces de noms [4]

10,000

Nombre de constructions

10 000 (pod par défaut RAM 512 Mi) - Stratégie de construction Source-to-Image (S2I)

Nombre de pods par espace de noms [5]

25,000

Nombre de routes et de back ends par contrôleur d'entrée

2 000 euros par routeur

Nombre de secrets

80,000

Nombre de cartes de configuration

90,000

Nombre de services [6]

10,000

Nombre de services par espace de noms

5,000

Nombre de backends par service

5,000

Nombre de déploiements par espace de noms [5]

2,000

Nombre de configurations de construction

12,000

Nombre de définitions de ressources personnalisées (CRD)

512 [7]

  1. Les pods de pause ont été déployés pour mettre à l'épreuve les composants du plan de contrôle d'OpenShift Container Platform à l'échelle de 2000 nœuds. La capacité à évoluer vers des nombres similaires variera en fonction des paramètres spécifiques de déploiement et de charge de travail.
  2. Le nombre de modules affiché ici correspond au nombre de modules de test. Le nombre réel de modules dépend des besoins de l'application en matière de mémoire, d'unité centrale et de stockage.
  3. Ceci a été testé sur un cluster de 100 nœuds de travail avec 500 pods par nœud de travail. La valeur par défaut de maxPods est toujours de 250. Pour atteindre 500 maxPods, le cluster doit être créé avec un maxPods défini sur 500 en utilisant une configuration kubelet personnalisée. Si vous avez besoin de 500 user pods, vous avez besoin d'un hostPrefix de 22 parce qu'il y a 10-15 system pods déjà en cours d'exécution sur le nœud. Le nombre maximum de pods avec des réclamations de volumes persistants (PVC) dépend du backend de stockage à partir duquel les PVC sont alloués. Dans nos tests, seul OpenShift Data Foundation v4 (OCS v4) a été en mesure de satisfaire le nombre de pods par nœud discuté dans ce document.
  4. Lorsqu'il y a un grand nombre de projets actifs, etcd peut souffrir de mauvaises performances si l'espace-clé devient excessivement grand et dépasse le quota d'espace. Une maintenance périodique de etcd, y compris une défragmentation, est fortement recommandée pour libérer l'espace de stockage de etcd.
  5. Le système comporte un certain nombre de boucles de contrôle qui doivent passer en revue tous les objets d'un espace de noms donné en réaction à certains changements d'état. Le fait d'avoir un grand nombre d'objets d'un type donné dans un seul espace de noms peut rendre ces boucles coûteuses et ralentir le traitement des changements d'état. La limite suppose que le système dispose de suffisamment d'unité centrale, de mémoire et de disque pour répondre aux exigences de l'application.
  6. Chaque port de service et chaque back-end de service a une entrée correspondante dans iptables. Le nombre de back-ends d'un service donné a un impact sur la taille des objets des endpoints, ce qui a un impact sur la taille des données qui sont envoyées dans tout le système.
  7. OpenShift Container Platform a une limite de 512 définitions de ressources personnalisées (CRD), y compris celles installées par OpenShift Container Platform, les produits intégrant OpenShift Container Platform et les CRD créés par l'utilisateur. S'il y a plus de 512 CRD créés, il est possible que les demandes de commandes oc soient limitées.

7.1.1. Exemple de scénario
Copier lien

À titre d'exemple, 500 nœuds de travail (m5.2xl) ont été testés et sont pris en charge avec OpenShift Container Platform 4.12, le plugin réseau OVN-Kubernetes et les objets de charge de travail suivants :

  • 200 espaces de noms, en plus des valeurs par défaut
  • 60 pods par nœud ; 30 pods serveur et 30 pods client (30k au total)
  • 57 flux d'images/ns (11,4k au total)
  • 15 services/ns soutenus par les pods serveurs (3k au total)
  • 15 routes/ns soutenues par les services précédents (3k au total)
  • 20 secrets/ns (4k au total)
  • 10 cartes de configuration/ns (2k au total)
  • 6 politiques réseau/ns, y compris les règles de refus d'accès, d'autorisation d'accès à l'entrée et à l'intérieur de l'espace de nommage
  • 57 constructions/ns

Les facteurs suivants sont connus pour affecter la mise à l'échelle des charges de travail des clusters, positivement ou négativement, et doivent être pris en compte dans les chiffres d'échelle lors de la planification d'un déploiement. Pour plus d'informations et de conseils, contactez votre représentant commercial ou l'assistance Red Hat.

  • Nombre de pods par nœud
  • Nombre de conteneurs par gousse
  • Type de sondes utilisées (par exemple, vivacité/préparation, exec/http)
  • Nombre de politiques de réseau
  • Nombre de projets ou d'espaces de noms
  • Nombre de flux d'images par projet
  • Nombre de constructions par projet
  • Nombre de services/points de terminaison et type
  • Nombre d'itinéraires
  • Nombre de tessons
  • Nombre de secrets
  • Nombre de cartes de configuration

  • Taux d'appels à l'API, ou "churn" du cluster, qui est une estimation de la vitesse à laquelle les choses changent dans la configuration du cluster.

    • Requête Prometheus pour les demandes de création de pods par seconde sur des fenêtres de 5 minutes : sum(irate(apiserver_request_count{resource="pods",verb="POST"}[5m]))
    • Requête Prometheus pour toutes les demandes d'API par seconde sur des fenêtres de 5 minutes : sum(irate(apiserver_request_count{}[5m]))
  • Consommation de ressources du nœud de la grappe par l'unité centrale
  • Consommation de ressources de la mémoire par le nœud de la grappe
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red HatRetour au début