Les conseils de cette section ne s'appliquent qu'aux installations intégrant un fournisseur de services en nuage.

Appliquez les meilleures pratiques suivantes pour faire évoluer le nombre de machines de travail dans votre cluster OpenShift Container Platform. Vous faites évoluer les machines de travail en augmentant ou en diminuant le nombre de répliques définies dans l'ensemble de machines de travail.

Lors de l'extension de la grappe à un plus grand nombre de nœuds :

Le contrôleur peut ne pas être en mesure de créer les machines si les répliques dans les ensembles de machines de calcul sont réglées sur des nombres plus élevés en une seule fois. Le nombre de requêtes que la plateforme cloud, sur laquelle OpenShift Container Platform est déployée, est capable de traiter a un impact sur le processus. Le contrôleur commencera à faire plus de requêtes en essayant de créer, de vérifier et de mettre à jour l'état des machines. La plateforme cloud sur laquelle OpenShift Container Platform est déployée a des limites de requêtes API ; des requêtes excessives peuvent conduire à des échecs de création de machines en raison des limitations de la plateforme cloud.

Activez les contrôles de santé des machines lorsque vous passez à un grand nombre de nœuds. En cas de défaillance, les contrôles de santé surveillent l'état des machines et les réparent automatiquement.

Les besoins en ressources des nœuds du plan de contrôle dépendent du nombre et du type de nœuds et d'objets dans le cluster. Les recommandations suivantes concernant la taille des nœuds du plan de contrôle sont basées sur les résultats d'un test focalisé sur la densité du plan de contrôle, ou Cluster-density. Ce test crée les objets suivants dans un nombre donné d'espaces de noms :

Les données du tableau ci-dessus sont basées sur une plateforme de conteneurs OpenShift fonctionnant au-dessus d'AWS, utilisant des instances r5.4xlarge comme nœuds de plan de contrôle et des instances m5.2xlarge comme nœuds de travail.

Dans un grand cluster dense comprenant trois nœuds de plan de contrôle, l'utilisation du processeur et de la mémoire augmente lorsque l'un des nœuds est arrêté, redémarré ou tombe en panne. Les pannes peuvent être dues à des problèmes inattendus d'alimentation, de réseau, d'infrastructure sous-jacente, ou à des cas intentionnels où le cluster est redémarré après avoir été arrêté pour réduire les coûts. Les deux nœuds restants du plan de contrôle doivent gérer la charge afin d'être hautement disponibles, ce qui entraîne une augmentation de l'utilisation des ressources. Ce phénomène se produit également lors des mises à niveau, car les nœuds du plan de contrôle sont isolés, vidés et redémarrés en série pour appliquer les mises à jour du système d'exploitation, ainsi que la mise à jour des opérateurs du plan de contrôle. Pour éviter les défaillances en cascade, maintenez l'utilisation globale des ressources CPU et mémoire sur les nœuds du plan de contrôle à un maximum de 60 % de la capacité disponible afin de gérer les pics d'utilisation des ressources. Augmentez l'UC et la mémoire des nœuds du plan de contrôle en conséquence pour éviter les temps d'arrêt potentiels dus au manque de ressources.

Operator Lifecycle Manager (OLM) s'exécute sur les nœuds du plan de contrôle et son empreinte mémoire dépend du nombre d'espaces de noms et d'opérateurs installés par l'utilisateur qu'OLM doit gérer sur la grappe. Les nœuds du plan de contrôle doivent être dimensionnés en conséquence afin d'éviter les pertes de mémoire (OOM kills). Les points de données suivants sont basés sur les résultats des tests de maximisation des grappes.

Comme etcd écrit des données sur le disque et y conserve des propositions, ses performances dépendent de celles du disque. Bien que etcd ne soit pas particulièrement gourmand en E/S, il a besoin d'un périphérique de bloc à faible latence pour des performances et une stabilité optimales. Comme le protocole de consensus d'etcd dépend du stockage persistant des métadonnées dans un journal (WAL), etcd est sensible à la latence de l'écriture sur disque. Les disques lents et l'activité du disque par d'autres processus peuvent causer de longues latences de synchronisation.

Ces latences peuvent amener etcd à manquer des battements de cœur, à ne pas livrer de nouvelles propositions sur le disque à temps et, en fin de compte, à subir des dépassements de délai de requête et des pertes de leader temporaires. Des latences d'écriture élevées entraînent également une lenteur de l'API OpenShift, ce qui affecte les performances du cluster. Pour ces raisons, évitez de colocaliser d'autres charges de travail sur les nœuds du plan de contrôle.

En termes de latence, exécutez etcd au-dessus d'un périphérique bloc qui peut écrire au moins 50 IOPS de 8000 octets de long séquentiellement. C'est-à-dire avec une latence de 10 ms, en gardant à l'esprit que etcd utilise fdatasync pour synchroniser chaque écriture dans le WAL. Pour les clusters très chargés, 500 IOPS séquentiels de 8000 octets (2 ms) sont recommandés. Pour mesurer ces chiffres, vous pouvez utiliser un outil d'analyse comparative, tel que fio.

Pour obtenir de telles performances, exécutez etcd sur des machines soutenues par des disques SSD ou NVMe avec une faible latence et un débit élevé. Considérons les disques d'état solide (SSD) à cellule à niveau unique (SLC), qui fournissent 1 bit par cellule de mémoire, sont durables et fiables, et sont idéaux pour les charges de travail à forte intensité d'écriture.

Les caractéristiques suivantes du disque dur permettent d'optimiser les performances du système etcd :

Évitez les configurations NAS ou SAN et les disques en rotation. Effectuez toujours des analyses comparatives à l'aide d'utilitaires tels que fio. Surveillez en permanence les performances de la grappe au fur et à mesure qu'elles augmentent.

Certaines mesures clés à surveiller sur un cluster OpenShift Container Platform déployé sont p99 of etcd disk write ahead log duration et le nombre de changements de leader etcd. Utilisez Prometheus pour suivre ces métriques.

Pour valider le matériel pour etcd avant ou après la création du cluster OpenShift Container Platform, vous pouvez utiliser fio.

La sortie indique si le disque est assez rapide pour héberger etcd en comparant le 99ème percentile de la métrique fsync capturée lors de l'exécution pour voir si elle est inférieure à 10 ms. Voici quelques-unes des métriques etcd les plus importantes qui peuvent être affectées par les performances d'E/S :

Comme etcd réplique les requêtes entre tous les membres, ses performances dépendent fortement de la latence des entrées/sorties du réseau. Des latences réseau élevées entraînent des battements de cœur etcd plus longs que le délai d'élection, ce qui se traduit par des élections de leaders qui perturbent le cluster. Une mesure clé à surveiller sur un cluster OpenShift Container Platform déployé est le 99e percentile de la latence des pairs du réseau etcd sur chaque membre du cluster etcd. Utilisez Prometheus pour suivre cette métrique.

La métrique histogram_quantile(0.99, rate(etcd_network_peer_round_trip_time_seconds_bucket[2m])) indique le temps d'aller-retour pour que etcd finisse de répliquer les requêtes des clients entre les membres. Assurez-vous qu'il est inférieur à 50 ms.

Vous pouvez déplacer etcd d'un disque partagé vers un disque séparé afin d'éviter ou de résoudre les problèmes de performances.

L'opérateur de configuration de machine (MCO) est chargé de monter un disque secondaire pour un stockage de conteneur OpenShift Container Platform 4.12.

Procédez comme suit pour déplacer etcd vers un autre périphérique :

Pour les clusters importants et denses, etcd peut souffrir de mauvaises performances si l'espace-clé devient trop grand et dépasse le quota d'espace. Maintenez et défragmentez périodiquement etcd pour libérer de l'espace dans le magasin de données. Surveillez les métriques etcd dans Prometheus et défragmentez-le si nécessaire ; sinon, etcd peut déclencher une alarme à l'échelle de la grappe qui la met en mode de maintenance n'acceptant que les lectures et les suppressions de clés.

Surveillez ces paramètres clés :

Défragmenter les données etcd pour récupérer de l'espace disque après des événements qui provoquent la fragmentation du disque, comme le compactage de l'historique etcd.

Le compactage de l'historique est effectué automatiquement toutes les cinq minutes et laisse des trous dans la base de données back-end. Cet espace fragmenté peut être utilisé par etcd, mais n'est pas disponible pour le système de fichiers hôte. Vous devez défragmenter etcd pour rendre cet espace disponible au système de fichiers hôte.

La défragmentation se produit automatiquement, mais vous pouvez également la déclencher manuellement.

le membre etcd a été défragmenté : <member_name>, memberID : <member_id>

échec de la défragmentation sur le membre : <member_name>, memberID : <member_id>: <error_message>

Infrastructure nodes sont des nœuds étiquetés pour exécuter des éléments de l'environnement OpenShift Container Platform. Les besoins en ressources des nœuds d'infrastructure dépendent de l'âge du cluster, des nœuds et des objets du cluster, car ces facteurs peuvent entraîner une augmentation du nombre de métriques ou de séries temporelles dans Prometheus. Les recommandations suivantes concernant la taille des nœuds d'infrastructure sont basées sur les résultats observés lors des tests de densité des clusters détaillés dans la section Control plane node sizing, où la pile de surveillance et le contrôleur d'entrée par défaut ont été déplacés vers ces nœuds.

En général, trois nœuds d'infrastructure sont recommandés par grappe.

Dans un environnement IBM zSystems hautement virtualisé, vous devez planifier avec soin la configuration et le dimensionnement de l'infrastructure. L'une des caractéristiques les plus importantes de la virtualisation est la possibilité de surcharger les ressources, c'est-à-dire d'allouer aux machines virtuelles plus de ressources qu'il n'y en a réellement au niveau de l'hyperviseur. Cela dépend beaucoup de la charge de travail et il n'existe pas de règle d'or applicable à toutes les configurations.

En fonction de votre configuration, tenez compte des meilleures pratiques suivantes concernant le surengagement du processeur :

Les pages volumineuses transparentes (THP) tentent d'automatiser la plupart des aspects de la création, de la gestion et de l'utilisation des pages volumineuses. Comme THP gère automatiquement les pages volumineuses, cela n'est pas toujours optimal pour tous les types de charges de travail. THP peut entraîner une régression des performances, car de nombreuses applications gèrent elles-mêmes les pages volumineuses. Par conséquent, envisagez de désactiver THP.

Receive Flow Steering (RFS) étend Receive Packet Steering (RPS) en réduisant davantage la latence du réseau. Le RFS est techniquement basé sur le RPS et améliore l'efficacité du traitement des paquets en augmentant le taux de réussite du cache de l'unité centrale. Pour ce faire, et en plus de tenir compte de la longueur de la file d'attente, RFS détermine l'unité centrale la plus pratique pour le calcul, de sorte que les occurrences dans la mémoire cache ont plus de chances de se produire au sein de l'unité centrale. Ainsi, le cache de l'unité centrale est moins invalidé et nécessite moins de cycles pour le reconstruire. Cela peut contribuer à réduire le temps d'exécution du traitement des paquets.

La pile réseau est l'un des composants les plus importants pour un produit basé sur Kubernetes comme OpenShift Container Platform. Pour les installations IBM zSystems, la configuration du réseau dépend de l'hyperviseur de votre choix. En fonction de la charge de travail et de l'application, la meilleure adaptation change généralement avec le cas d'utilisation et le modèle de trafic.

En fonction de votre configuration, tenez compte des meilleures pratiques suivantes :

Les périphériques DASD et ECKD sont des types de disques couramment utilisés dans les environnements IBM zSystems. Dans une configuration typique d'OpenShift Container Platform dans des environnements z/VM, les disques DASD sont généralement utilisés pour prendre en charge le stockage local des nœuds. Vous pouvez configurer des périphériques alias HyperPAV pour fournir plus de débit et de meilleures performances d'E/S pour les disques DASD qui prennent en charge les invités z/VM.

L'utilisation d'HyperPAV pour les périphériques de stockage locaux permet d'améliorer considérablement les performances. Cependant, vous devez être conscient qu'il existe un compromis entre le débit et les coûts de l'unité centrale.

L'optimisation d'un environnement de serveurs virtuels KVM dépend fortement des charges de travail des serveurs virtuels et des ressources disponibles. La même action qui améliore les performances dans un environnement peut avoir des effets négatifs dans un autre. Trouver le meilleur équilibre pour un environnement particulier peut s'avérer difficile et implique souvent des expérimentations.

La section suivante présente quelques bonnes pratiques lors de l'utilisation d'OpenShift Container Platform avec RHEL KVM sur les environnements IBM zSystems et IBM® LinuxONE.

<interface type="direct">
    <source network="net01"/>
    <model type="virtio"/>
    <driver ... queues="2"/>
</interface>

...
<domain>
 	<iothreads>3</iothreads>1
  	 ...
    	<devices>
       ...
          <disk type="block" device="disk">2
<driver ... iothread="2"/>
    </disk>
       ...
    	</devices>
   ...
</domain>

<disk type="block" device="disk">
    <driver name="qemu" type="raw" cache="none" io="native" iothread="1"/>
...
</disk>

# sysctl kernel.sched_migration_cost_ns=60000

kernel.sched_migration_cost_ns=60000

L'opérateur d'optimisation des nœuds vous aide à gérer l'optimisation au niveau des nœuds en orchestrant le démon TuneD et à obtenir des performances à faible latence en utilisant le contrôleur de profil de performance. La majorité des applications à hautes performances nécessitent un certain niveau de réglage du noyau. Le Node Tuning Operator offre une interface de gestion unifiée aux utilisateurs de sysctls au niveau des nœuds et plus de flexibilité pour ajouter des réglages personnalisés en fonction des besoins de l'utilisateur.

L'opérateur gère le démon TuneD conteneurisé pour OpenShift Container Platform en tant qu'ensemble de démons Kubernetes. Il s'assure que la spécification de réglage personnalisé est transmise à tous les démons TuneD conteneurisés s'exécutant dans le cluster dans le format que les démons comprennent. Les démons s'exécutent sur tous les nœuds du cluster, un par nœud.

Les paramètres de niveau nœud appliqués par le démon TuneD conteneurisé sont annulés lors d'un événement qui déclenche un changement de profil ou lorsque le démon TuneD conteneurisé se termine de manière élégante en recevant et en gérant un signal de fin.

L'opérateur de réglage des nœuds utilise le contrôleur de profil de performance pour mettre en œuvre un réglage automatique afin d'obtenir des performances de faible latence pour les applications OpenShift Container Platform. L'administrateur du cluster configure un profil de performance pour définir des paramètres au niveau du nœud, tels que les suivants :

L'opérateur Node Tuning fait partie de l'installation standard d'OpenShift Container Platform à partir de la version 4.1.

Cette procédure permet d'accéder à un exemple de spécification de l'opérateur de réglage des nœuds.

Le CR par défaut est destiné à fournir un réglage standard au niveau du nœud pour la plateforme OpenShift Container Platform et il ne peut être modifié que pour définir l'état de gestion de l'opérateur. Toute autre modification personnalisée de la CR par défaut sera écrasée par l'opérateur. Pour un réglage personnalisé, créez vos propres CR réglés. Les CR nouvellement créés seront combinés avec le CR par défaut et les réglages personnalisés appliqués aux nœuds d'OpenShift Container Platform en fonction des étiquettes de nœuds ou de pods et des priorités de profil.

Les profils par défaut définis sur un cluster sont les suivants.

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: default
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Optimize systems running OpenShift (provider specific parent profile)
      include=-provider-${f:exec:cat:/var/lib/tuned/provider},openshift
    name: openshift
  recommend:
  - profile: openshift-control-plane
    priority: 30
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
  - profile: openshift-node
    priority: 40

Depuis OpenShift Container Platform 4.9, tous les profils OpenShift TuneD sont livrés avec le package TuneD. Vous pouvez utiliser la commande oc exec pour voir le contenu de ces profils :

$ oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/openshift{,-control-plane,-node} -name tuned.conf -exec grep -H ^ {} \;

Vérifiez les profils TuneD appliqués à votre nœud de cluster.

$ oc get profile -n openshift-cluster-node-tuning-operator

NAME             TUNED                     APPLIED   DEGRADED   AGE
master-0         openshift-control-plane   True      False      6h33m
master-1         openshift-control-plane   True      False      6h33m
master-2         openshift-control-plane   True      False      6h33m
worker-a         openshift-node            True      False      6h28m
worker-b         openshift-node            True      False      6h28m

La ressource personnalisée (CR) de l'opérateur comporte deux sections principales. La première section, profile:, est une liste de profils TuneD et de leurs noms. La seconde, recommend:, définit la logique de sélection des profils.

Plusieurs spécifications de réglage personnalisées peuvent coexister en tant que CR multiples dans l'espace de noms de l'opérateur. L'existence de nouveaux CR ou la suppression d'anciens CR est détectée par l'Opérateur. Toutes les spécifications de réglage personnalisées existantes sont fusionnées et les objets appropriés pour les démons TuneD conteneurisés sont mis à jour.

Management state

L'état de gestion de l'opérateur est défini en ajustant le CR accordé par défaut. Par défaut, l'opérateur est en état de gestion et le champ spec.managementState n'est pas présent dans le CR accordé par défaut. Les valeurs valides pour l'état de gestion de l'opérateur sont les suivantes :

Profile data

La section profile: dresse la liste des profils TuneD et de leurs noms.

profile:
- name: tuned_profile_1
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_1 profile

    [sysctl]
    net.ipv4.ip_forward=1
    # ... other sysctl's or other TuneD daemon plugins supported by the containerized TuneD

# ...

- name: tuned_profile_n
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_n profile

    # tuned_profile_n profile settings

Recommended profiles

La logique de sélection de profile: est définie par la section recommend: du CR. La section recommend: est une liste d'éléments permettant de recommander les profils sur la base d'un critère de sélection.

recommend:
<recommend-item-1>
# ...
<recommend-item-n>

Les différents éléments de la liste :

- machineConfigLabels: 1
    <mcLabels> 2
  match: 3
    <match> 4
  priority: <priority> 5
  profile: <tuned_profile_name> 6
  operand: 7
    debug: <bool> 8
    tunedConfig:
      reapply_sysctl: <bool> 9

<match> est une liste optionnelle définie récursivement comme suit :

- label: <label_name> 1
  value: <label_value> 2
  type: <label_type> 3
    <match> 4

Si <match> n'est pas omis, toutes les sections imbriquées <match> doivent également être évaluées à true. Sinon, false est supposé et le profil avec la section <match> correspondante ne sera pas appliqué ou recommandé. Par conséquent, l'imbrication (sections <match> enfant) fonctionne comme un opérateur logique ET. Inversement, si un élément de la liste <match> correspond, toute la liste <match> est évaluée à true. La liste agit donc comme un opérateur logique OU.

Si machineConfigLabels est défini, la correspondance basée sur le pool de configuration de la machine est activée pour l'élément de liste recommend: donné. <mcLabels> spécifie les étiquettes d'une configuration de la machine. La configuration de la machine est créée automatiquement pour appliquer les paramètres de l'hôte, tels que les paramètres de démarrage du noyau, pour le profil <tuned_profile_name>. Il s'agit de trouver tous les pools de configuration de machine dont le sélecteur de configuration de machine correspond à <mcLabels> et de définir le profil <tuned_profile_name> sur tous les nœuds auxquels sont attribués les pools de configuration de machine trouvés. Pour cibler les nœuds qui ont à la fois un rôle de maître et de travailleur, vous devez utiliser le rôle de maître.

Les éléments de la liste match et machineConfigLabels sont reliés par l'opérateur logique OR. L'élément match est évalué en premier, en court-circuit. Par conséquent, s'il est évalué à true, l'élément machineConfigLabels n'est pas pris en compte.

- match:
  - label: tuned.openshift.io/elasticsearch
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
    type: pod
  priority: 10
  profile: openshift-control-plane-es
- match:
  - label: node-role.kubernetes.io/master
  - label: node-role.kubernetes.io/infra
  priority: 20
  profile: openshift-control-plane
- priority: 30
  profile: openshift-node

Le CR ci-dessus est traduit pour le démon TuneD conteneurisé dans son fichier recommend.conf en fonction des priorités du profil. Le profil ayant la priorité la plus élevée (10) est openshift-control-plane-es et, par conséquent, il est considéré en premier. Le démon TuneD conteneurisé fonctionnant sur un nœud donné vérifie s'il existe un pod fonctionnant sur le même nœud avec l'étiquette tuned.openshift.io/elasticsearch définie. Si ce n'est pas le cas, toute la section <match> est évaluée comme false. S'il existe un pod avec le label, pour que la section <match> soit évaluée comme true, le label du nœud doit également être node-role.kubernetes.io/master ou node-role.kubernetes.io/infra.

Si les étiquettes du profil ayant la priorité 10 correspondent, le profil openshift-control-plane-es est appliqué et aucun autre profil n'est pris en considération. Si la combinaison d'étiquettes nœud/pod ne correspond pas, le deuxième profil le plus prioritaire (openshift-control-plane) est pris en compte. Ce profil est appliqué si le pod TuneD conteneurisé fonctionne sur un nœud avec les étiquettes node-role.kubernetes.io/master ou node-role.kubernetes.io/infra.

Enfin, le profil openshift-node a la priorité la plus basse de 30. Il ne contient pas la section <match> et, par conséquent, correspondra toujours. Il sert de profil fourre-tout pour définir le profil openshift-node si aucun autre profil ayant une priorité plus élevée ne correspond à un nœud donné.

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-custom
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile with an additional kernel parameter
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_custom=+skew_tick=1
    name: openshift-node-custom

  recommend:
  - machineConfigLabels:
      machineconfiguration.openshift.io/role: "worker-custom"
    priority: 20
    profile: openshift-node-custom

Pour minimiser les redémarrages de nœuds, il faut étiqueter les nœuds cibles avec une étiquette que le sélecteur de nœuds du pool de configuration de la machine fera correspondre, puis créer le Tuned CR ci-dessus et enfin créer le pool de configuration de la machine personnalisé lui-même.

Cloud provider-specific TuneD profiles

Avec cette fonctionnalité, tous les nœuds spécifiques à un fournisseur de Cloud peuvent commodément se voir attribuer un profil TuneD spécifiquement adapté à un fournisseur de Cloud donné sur un cluster OpenShift Container Platform. Cela peut être accompli sans ajouter d'étiquettes de nœuds supplémentaires ou regrouper les nœuds dans des pools de configuration de machines.

Cette fonctionnalité tire parti des valeurs de l'objet de nœud spec.providerID sous la forme de <cloud-provider>://<cloud-provider-specific-id> et écrit le fichier /var/lib/tuned/provider avec la valeur <cloud-provider> dans les conteneurs d'opérandes NTO. Le contenu de ce fichier est ensuite utilisé par TuneD pour charger le profil provider-<cloud-provider> s'il existe.

Le profil openshift dont les profils openshift-control-plane et openshift-node héritent des paramètres est maintenant mis à jour pour utiliser cette fonctionnalité grâce à l'utilisation du chargement conditionnel de profil. Ni NTO ni TuneD ne fournissent actuellement de profils spécifiques aux fournisseurs de Cloud. Cependant, il est possible de créer un profil personnalisé provider-<cloud-provider> qui sera appliqué à tous les nœuds de cluster spécifiques au fournisseur de cloud.

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: provider-gce
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=GCE Cloud provider-specific profile
      # Your tuning for GCE Cloud provider goes here.
    name: provider-gce

Using TuneD profiles from the default CR

La CR suivante applique un réglage personnalisé au niveau du nœud pour les nœuds OpenShift Container Platform dont l'étiquette tuned.openshift.io/ingress-node-label est définie sur n'importe quelle valeur.

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: ingress
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=A custom OpenShift ingress profile
      include=openshift-control-plane
      [sysctl]
      net.ipv4.ip_local_port_range="1024 65535"
      net.ipv4.tcp_tw_reuse=1
    name: openshift-ingress
  recommend:
  - match:
    - label: tuned.openshift.io/ingress-node-label
    priority: 10
    profile: openshift-ingress

Using built-in TuneD profiles

Étant donné le succès du déploiement de l'ensemble des démons gérés par NTO, les opérandes TuneD gèrent tous la même version du démon TuneD. Pour obtenir la liste des profils TuneD intégrés pris en charge par le démon, interrogez n'importe quel module TuneD de la manière suivante :

$ oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/ -name tuned.conf -printf '%h\n' | sed 's|^.*/||'

Vous pouvez utiliser les noms de profil ainsi récupérés dans votre spécification de réglage personnalisé.

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-hpc-compute
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile for HPC compute workloads
      include=openshift-node,hpc-compute
    name: openshift-node-hpc-compute

  recommend:
  - match:
    - label: tuned.openshift.io/openshift-node-hpc-compute
    priority: 20
    profile: openshift-node-hpc-compute

En plus du profil intégré hpc-compute, l'exemple ci-dessus inclut le profil du démon openshift-node TuneD fourni avec le CR Tuned par défaut afin d'utiliser un réglage spécifique à OpenShift pour les nœuds de calcul.

À l'exception de la section [main], les plugins TuneD suivants sont pris en charge lors de l'utilisation des profils personnalisés définis dans la section profile: du CR Tuned :

Certains de ces plugins offrent une fonctionnalité d'accord dynamique qui n'est pas prise en charge. Les plugins TuneD suivants ne sont actuellement pas pris en charge :

Voir Plugins TuneD disponibles et Démarrer avec TuneD pour plus d'informations.

Pour définir le réglage au niveau du nœud sur les nœuds de votre cluster hébergé, vous pouvez utiliser l'opérateur de réglage des nœuds. Dans les plans de contrôle hébergés, vous pouvez configurer l'optimisation des nœuds en créant des cartes de configuration contenant des objets Tuned et en référençant ces cartes de configuration dans vos pools de nœuds.

Pour des réglages plus avancés dans les plans de contrôle hébergés, qui nécessitent la définition de paramètres d'amorçage du noyau, vous pouvez également utiliser l'opérateur de réglage des nœuds. L'exemple suivant montre comment créer un pool de nœuds avec d'énormes pages réservées.

Topology Manager aligne les ressources Pod de toutes les classes de qualité de service (QoS) en recueillant des indices topologiques auprès des fournisseurs d'indices, tels que CPU Manager et Device Manager, et en utilisant les indices recueillis pour aligner les ressources Pod.

Topology Manager prend en charge quatre politiques d'allocation, que vous attribuez dans la ressource personnalisée (CR) cpumanager-enabled:

Pour utiliser le gestionnaire de topologie, vous devez configurer une politique d'allocation dans la ressource personnalisée (CR) cpumanager-enabled. Ce fichier peut exister si vous avez configuré le Gestionnaire de CPU. Si le fichier n'existe pas, vous pouvez le créer.

Les exemples de spécifications Pod ci-dessous permettent d'illustrer les interactions entre les pods et Topology Manager.

Le pod suivant s'exécute dans la classe de qualité de service BestEffort car aucune demande ou limite de ressources n'est spécifiée.

spec:
  containers:
  - name: nginx
    image: nginx

Le pod suivant fonctionne dans la classe de qualité de service Burstable car les demandes sont inférieures aux limites.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

Si la politique sélectionnée est autre que none, Topology Manager ne tiendra compte d'aucune de ces spécifications Pod.

Le dernier exemple de pod ci-dessous s'exécute dans la classe de qualité de service garantie parce que les demandes sont égales aux limites.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"
      requests:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"

Le gestionnaire de topologie prend en compte ce module. Le gestionnaire de topologie consulte les fournisseurs d'indices, à savoir le gestionnaire de CPU et le gestionnaire de périphériques, afin d'obtenir des indices topologiques pour le module.

Le gestionnaire de topologie utilisera ces informations pour stocker la meilleure topologie pour ce conteneur. Dans le cas de ce module, le gestionnaire de CPU et le gestionnaire de périphériques utiliseront ces informations stockées lors de la phase d'allocation des ressources.

L'accès non uniforme à la mémoire (NUMA) est une architecture de plate-forme informatique qui permet à différents processeurs d'accéder à différentes régions de la mémoire à des vitesses différentes. La topologie des ressources NUMA fait référence à l'emplacement des unités centrales, de la mémoire et des périphériques PCI les uns par rapport aux autres dans le nœud de calcul. Les ressources co-localisées sont dites être dans le même NUMA zone. Pour les applications à haute performance, le cluster doit traiter les charges de travail des pods dans une seule zone NUMA.

L'architecture NUMA permet à une unité centrale dotée de plusieurs contrôleurs de mémoire d'utiliser toute la mémoire disponible dans les complexes d'unités centrales, quel que soit l'emplacement de la mémoire. Cela permet d'accroître la flexibilité au détriment des performances. Une unité centrale traitant une charge de travail utilisant une mémoire située en dehors de sa zone NUMA est plus lente qu'une charge de travail traitée dans une seule zone NUMA. En outre, pour les charges de travail soumises à des contraintes d'E/S, l'interface réseau située dans une zone NUMA éloignée ralentit la vitesse à laquelle les informations peuvent atteindre l'application. Les charges de travail à haute performance, telles que les charges de travail de télécommunications, ne peuvent pas fonctionner selon les spécifications dans ces conditions. L'ordonnancement NUMA-aware permet d'aligner les ressources de calcul du cluster (CPU, mémoire, périphériques) demandées dans la même zone NUMA afin de traiter efficacement les charges de travail sensibles à la latence ou très performantes. L'ordonnancement NUMA-aware améliore également la densité de pods par nœud de calcul pour une meilleure efficacité des ressources.

La logique de planification par défaut du planificateur de pods d'OpenShift Container Platform prend en compte les ressources disponibles de l'ensemble du nœud de calcul, et non des zones NUMA individuelles. Si l'alignement des ressources le plus restrictif est demandé dans le gestionnaire de topologie des kubelets, des conditions d'erreur peuvent survenir lors de l'admission du pod sur un nœud. Inversement, si l'alignement des ressources le plus restrictif n'est pas demandé, le module peut être admis dans le nœud sans que l'alignement des ressources soit correct, ce qui entraîne des performances moins bonnes ou imprévisibles. Par exemple, la création de pods avec des statuts Topology Affinity Error peut se produire lorsque le planificateur de pods prend des décisions de planification sous-optimales pour des charges de travail de pods garanties, car il ne sait pas si les ressources demandées par le pod sont disponibles. Les décisions d'inadéquation de l'ordonnancement peuvent entraîner des retards indéfinis dans le démarrage des modules. En outre, en fonction de l'état du cluster et de l'allocation des ressources, de mauvaises décisions d'ordonnancement de pods peuvent entraîner une charge supplémentaire sur le cluster en raison de l'échec des tentatives de démarrage.

L'opérateur de ressources NUMA déploie un planificateur secondaire de ressources NUMA personnalisé et d'autres ressources pour atténuer les lacunes du planificateur de pods par défaut d'OpenShift Container Platform. Le diagramme suivant fournit un aperçu de haut niveau de la planification de pods tenant compte de la NUMA.

Figure 5.1. Vue d'ensemble de l'ordonnancement NUMA

NUMA Resources Operator déploie des ressources qui vous permettent de planifier des charges de travail et des déploiements compatibles avec NUMA. Vous pouvez installer l'opérateur de ressources NUMA à l'aide de la CLI d'OpenShift Container Platform ou de la console Web.

Une fois l'opérateur de ressources NUMA installé, créez la ressource personnalisée (CR) NUMAResourcesOperator qui demande à l'opérateur de ressources NUMA d'installer toute l'infrastructure de cluster nécessaire à la prise en charge du planificateur NUMA, y compris les jeux de démons et les API.

$ oc get numaresourcesoperators.nodetopology.openshift.io

NAME                    AGE
numaresourcesoperator   10m

Après avoir installé l'opérateur de ressources NUMA, procédez comme suit pour déployer le planificateur de pods secondaire compatible NUMA :

$ oc get all -n openshift-numaresources

NAME                                                    READY   STATUS    RESTARTS   AGE
pod/numaresources-controller-manager-7575848485-bns4s   1/1     Running   0          13m
pod/numaresourcesoperator-worker-dvj4n                  2/2     Running   0          16m
pod/numaresourcesoperator-worker-lcg4t                  2/2     Running   0          16m
pod/secondary-scheduler-56994cf6cf-7qf4q                1/1     Running   0          16m
NAME                                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                     AGE
daemonset.apps/numaresourcesoperator-worker   2         2         2       2            2           node-role.kubernetes.io/worker=   16m
NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/numaresources-controller-manager   1/1     1            1           13m
deployment.apps/secondary-scheduler                1/1     1            1           16m
NAME                                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/numaresources-controller-manager-7575848485   1         1         1       13m
replicaset.apps/secondary-scheduler-56994cf6cf                1         1         1       16m

Vous pouvez planifier des charges de travail avec le planificateur NUMA-aware à l'aide de Deployment CR qui spécifient les ressources minimales requises pour traiter la charge de travail.

L'exemple de déploiement suivant utilise l'ordonnancement NUMA-aware pour un exemple de charge de travail.

Pour résoudre les problèmes courants liés à l'ordonnancement de pods NUMA-aware, procédez comme suit.

Info: couldn't find configuration in "/etc/resource-topology-exporter/config.yaml"

$ oc get configmap

NAME                           DATA   AGE
0e2a6bd3.openshift-kni.io      0      6d21h
kube-root-ca.crt               1      6d21h
openshift-service-ca.crt       1      6d21h
topo-aware-scheduler-config    1      6d18h

Red Hat a effectué plusieurs tests pour différentes tailles d'échelle.

Environ 20 % de la taille prévue a été ajoutée comme frais généraux pour garantir que les besoins de stockage ne dépassent pas la valeur calculée.

Le calcul ci-dessus concerne l'opérateur de surveillance de cluster par défaut d'OpenShift Container Platform.

Recommendations for OpenShift Container Platform

Vous pouvez augmenter la capacité de stockage du composant Prometheus dans la pile de surveillance des clusters.

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.

Lors de la planification de votre environnement, déterminez le nombre de pods par nœud :

required pods per cluster / pods per node = total number of nodes needed

Par défaut, le nombre maximal de pods par nœud est de 250. Cependant, le nombre de pods pouvant être installés sur un nœud dépend de l'application elle-même. Prenez en compte les besoins de l'application en termes de mémoire, de CPU et de stockage, comme décrit dans "Comment planifier votre environnement en fonction des besoins de l'application".

2200 / 500 = 4.4

Si vous augmentez le nombre de nœuds à 20, la distribution des pods passe à 110 pods par nœud :

2200 / 20 = 110

Où ?

required pods per cluster / total number of nodes = expected pods per node

OpenShift Container Platform est livré avec plusieurs pods système, tels que SDN, DNS, Operators, et d'autres, qui s'exécutent sur chaque nœud de travail par défaut. Par conséquent, le résultat de la formule ci-dessus peut varier.

Prenons un exemple d'environnement d'application :

Exigences extrapolées : 550 cœurs de CPU, 450 Go de RAM et 1,4 To de stockage.

La taille de l'instance pour les nœuds peut être modulée à la hausse ou à la baisse, selon vos préférences. Les nœuds sont souvent surchargés en ressources. Dans ce scénario de déploiement, vous pouvez choisir d'exécuter des nœuds supplémentaires plus petits ou moins de nœuds plus grands pour fournir la même quantité de ressources. Des facteurs tels que l'agilité opérationnelle et le coût par instance doivent être pris en compte.

Certaines applications se prêtent bien aux environnements de surengagement, d'autres non. La plupart des applications Java et des applications qui utilisent d'énormes pages sont des exemples d'applications qui ne permettraient pas un surengagement. Cette mémoire ne peut pas être utilisée pour d'autres applications. Dans l'exemple ci-dessus, l'environnement serait sur-engagé à environ 30 %, un ratio courant.

Les modules d'application peuvent accéder à un service en utilisant des variables d'environnement ou le DNS. Si l'on utilise des variables d'environnement, pour chaque service actif, les variables sont injectées par le kubelet lorsqu'un pod est exécuté sur un nœud. Un serveur DNS conscient du cluster surveille l'API Kubernetes pour les nouveaux services et crée un ensemble d'enregistrements DNS pour chacun d'entre eux. Si le DNS est activé dans l'ensemble de votre cluster, tous les pods devraient automatiquement être en mesure de résoudre les services par leur nom DNS. La découverte de services à l'aide du DNS peut être utilisée si vous devez aller au-delà de 5000 services. Lorsque vous utilisez des variables d'environnement pour la découverte de services, la liste d'arguments dépasse la longueur autorisée après 5000 services dans un espace de noms, les pods et les déploiements commenceront alors à échouer. Désactivez les liens de service dans le fichier de spécification de service du déploiement pour résoudre ce problème :

---
apiVersion: template.openshift.io/v1
kind: Template
metadata:
  name: deployment-config-template
  creationTimestamp:
  annotations:
    description: This template will create a deploymentConfig with 1 replica, 4 env vars and a service.
    tags: ''
objects:
- apiVersion: apps.openshift.io/v1
  kind: DeploymentConfig
  metadata:
    name: deploymentconfig${IDENTIFIER}
  spec:
    template:
      metadata:
        labels:
          name: replicationcontroller${IDENTIFIER}
      spec:
        enableServiceLinks: false
        containers:
        - name: pause${IDENTIFIER}
          image: "${IMAGE}"
          ports:
          - containerPort: 8080
            protocol: TCP
          env:
          - name: ENVVAR1_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR2_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR3_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR4_${IDENTIFIER}
            value: "${ENV_VALUE}"
          resources: {}
          imagePullPolicy: IfNotPresent
          capabilities: {}
          securityContext:
            capabilities: {}
            privileged: false
        restartPolicy: Always
        serviceAccount: ''
    replicas: 1
    selector:
      name: replicationcontroller${IDENTIFIER}
    triggers:
    - type: ConfigChange
    strategy:
      type: Rolling
- apiVersion: v1
  kind: Service
  metadata:
    name: service${IDENTIFIER}
  spec:
    selector:
      name: replicationcontroller${IDENTIFIER}
    ports:
    - name: serviceport${IDENTIFIER}
      protocol: TCP
      port: 80
      targetPort: 8080
    clusterIP: ''
    type: ClusterIP
    sessionAffinity: None
  status:
    loadBalancer: {}
parameters:
- name: IDENTIFIER
  description: Number to append to the name of resources
  value: '1'
  required: true
- name: IMAGE
  description: Image to use for deploymentConfig
  value: gcr.io/google-containers/pause-amd64:3.0
  required: false
- name: ENV_VALUE
  description: Value to use for environment variables
  generate: expression
  from: "[A-Za-z0-9]{255}"
  required: false
labels:
  template: deployment-config-template

Le nombre de modules d'application pouvant être exécutés dans un espace de noms dépend du nombre de services et de la longueur du nom du service lorsque les variables d'environnement sont utilisées pour la découverte des services. ARG_MAX sur le système définit la longueur maximale des arguments pour un nouveau processus et elle est fixée à 2097152 octets (2 MiB) par défaut. Le Kubelet injecte des variables d'environnement dans chaque pod programmé pour s'exécuter dans l'espace de noms, y compris :

Les pods de l'espace de noms commenceront à échouer si la longueur de l'argument dépasse la valeur autorisée et si le nombre de caractères dans le nom d'un service a un impact. Par exemple, dans un espace de noms comprenant 5000 services, la limite du nom de service est de 33 caractères, ce qui vous permet d'exécuter 5000 pods dans l'espace de noms.

Comprenez vos options de stockage persistant afin d'optimiser votre environnement OpenShift Container Platform.

Le tableau suivant résume les technologies de stockage recommandées et configurables pour l'application de cluster OpenShift Container Platform donnée.

Le tableau suivant résume les principaux répertoires dans lesquels les composants d'OpenShift Container Platform écrivent des données.

Le contrôleur d'entrée de la plateforme OpenShift Container, ou routeur, est le point d'entrée du trafic d'entrée pour les applications et les services qui sont configurés à l'aide de routes et d'entrées.

Lorsque l'on évalue les performances d'un routeur HAProxy unique en termes de requêtes HTTP traitées par seconde, les performances varient en fonction de nombreux facteurs. En particulier :

Bien que les performances dans votre environnement spécifique varient, les tests du laboratoire Red Hat sur une instance de cloud public de taille 4 vCPU/16GB RAM. Un routeur HAProxy unique gérant 100 routes terminées par des backends servant des pages statiques de 1kB est capable de gérer le nombre suivant de transactions par seconde.

Dans les scénarios du mode "keep-alive" de HTTP :

Dans les scénarios de fermeture HTTP (pas de keep-alive) :

La configuration par défaut du contrôleur d'entrée a été utilisée avec le champ spec.tuningOptions.threadCount défini sur 4. Deux stratégies différentes de publication des points finaux ont été testées : Load Balancer Service et Host Network. La reprise de session TLS a été utilisée pour les itinéraires cryptés. Avec HTTP keep-alive, un seul routeur HAProxy est capable de saturer un NIC de 1 Gbit avec des pages d'une taille aussi petite que 8 kB.

Lorsque le système est exécuté sur du métal nu avec des processeurs modernes, vous pouvez vous attendre à des performances environ deux fois supérieures à celles de l'instance de nuage public ci-dessus. Cette surcharge est introduite par la couche de virtualisation en place sur les nuages publics et s'applique également à la virtualisation basée sur les nuages privés. Le tableau suivant indique le nombre d'applications à utiliser derrière le routeur :

En général, HAProxy peut prendre en charge des routes pour un maximum de 1 000 applications, en fonction de la technologie utilisée. Les performances du contrôleur d'entrée peuvent être limitées par les capacités et les performances des applications qui se trouvent derrière lui, comme la langue ou le contenu statique par rapport au contenu dynamique.

La mise en commun des entrées, ou routeurs, devrait être utilisée pour servir davantage de routes vers les applications et contribuer à la mise à l'échelle horizontale du niveau de routage.

Pour plus d'informations sur la répartition des entrées, voir Configuration de la répartition du contrôleur d'entrée à l'aide d'étiquettes d'itinéraire et Configuration de la répartition du contrôleur d'entrée à l'aide d'étiquettes d'espace de noms.

Vous pouvez modifier le déploiement du contrôleur d'ingestion à l'aide des informations fournies dans la section Définition du nombre de threads du contrôleur d'ing estion et des paramètres de configuration du contrôleur d'ing estion pour les délais d'attente, ainsi que d'autres configurations de réglage dans la spécification du contrôleur d'ingestion.

Les administrateurs de cluster peuvent configurer les valeurs de délai d'attente pour les sondes de disponibilité, de préparation et de démarrage du kubelet pour les déploiements de routeurs qui sont gérés par le contrôleur d'entrée de la plateforme OpenShift Container (routeur). Les sondes de disponibilité et de préparation du routeur utilisent la valeur de temporisation par défaut de 1 seconde, qui est trop courte lorsque les performances du réseau ou de l'exécution sont gravement dégradées. Les délais d'attente des sondes peuvent entraîner des redémarrages intempestifs du routeur qui interrompent les connexions des applications. La possibilité de définir des valeurs de délai plus importantes peut réduire le risque de redémarrages inutiles et non désirés.

Vous pouvez mettre à jour la valeur timeoutSeconds dans les paramètres livenessProbe, readinessProbe et startupProbe du conteneur de routeur.

L'exemple suivant montre comment vous pouvez corriger directement le déploiement du routeur par défaut pour définir un délai d'attente de 5 secondes pour les sondes de disponibilité et d'état de préparation :

$ oc -n openshift-ingress patch deploy/router-default --type=strategic --patch='{"spec":{"template":{"spec":{"containers":[{"name":"router","livenessProbe":{"timeoutSeconds":5},"readinessProbe":{"timeoutSeconds":5}}]}}}}'

$ oc -n openshift-ingress describe deploy/router-default | grep -e Liveness: -e Readiness:
    Liveness:   http-get http://:1936/healthz delay=0s timeout=5s period=10s #success=1 #failure=3
    Readiness:  http-get http://:1936/healthz/ready delay=0s timeout=5s period=10s #success=1 #failure=3

Lorsque vous mettez à jour une route ou un point d'extrémité associé à une route, le routeur OpenShift Container Platform met à jour la configuration de HAProxy. Ensuite, HAProxy recharge la configuration mise à jour pour que ces modifications prennent effet. Lorsque HAProxy se recharge, il génère un nouveau processus qui gère les nouvelles connexions à l'aide de la configuration mise à jour.

HAProxy maintient l'ancien processus en cours d'exécution pour gérer les connexions existantes jusqu'à ce qu'elles soient toutes fermées. Lorsque d'anciens processus ont des connexions de longue durée, ils peuvent accumuler et consommer des ressources.

L'intervalle minimum de rechargement de HAProxy par défaut est de cinq secondes. Vous pouvez configurer un contrôleur d'entrée à l'aide de son champ spec.tuningOptions.reloadInterval pour définir un intervalle de recharge minimum plus long.

Il existe deux unités de transmission maximale (MTU) importantes : la MTU du contrôleur d'interface réseau (NIC) et la MTU du réseau en grappe.

Le MTU de la carte réseau n'est configuré qu'au moment de l'installation d'OpenShift Container Platform. Le MTU doit être inférieur ou égal à la valeur maximale supportée par le NIC de votre réseau. Si vous optimisez le débit, choisissez la valeur la plus élevée possible. Si vous optimisez la latence, choisissez une valeur plus faible.

Le MTU du plugin réseau OpenShift SDN doit être inférieur au MTU du NIC d'au moins 50 octets. Cela tient compte de l'en-tête de la couche SDN. Ainsi, sur un réseau Ethernet normal, cette valeur doit être fixée à 1450. Sur un réseau Ethernet à trame jumbo, elle doit être réglée sur 8950. Ces valeurs doivent être réglées automatiquement par l'opérateur de réseau de cluster en fonction du MTU configuré de la carte d'interface réseau. Par conséquent, les administrateurs de clusters ne mettent généralement pas à jour ces valeurs. Les environnements Amazon Web Services (AWS) et bare-metal prennent en charge les réseaux Ethernet à trame jumbo. Ce paramètre améliore le débit, en particulier avec le protocole de contrôle de transmission (TCP).

Pour OVN et Geneve, le MTU doit être inférieur au MTU du NIC de 100 octets au minimum.

Lors de l'installation de clusters de grande taille ou de l'extension du cluster à un plus grand nombre de nœuds, définissez le réseau du cluster cidr en conséquence dans votre fichier install-config.yaml avant d'installer le cluster :

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes
  serviceNetwork:
  - 172.30.0.0/16

Le réseau de cluster par défaut cidr 10.128.0.0/14 ne peut pas être utilisé si la taille du cluster est supérieure à 500 nœuds. Il doit être défini sur 10.128.0.0/12 ou 10.128.0.0/10 pour obtenir un nombre de nœuds supérieur à 500.

Étant donné que le chiffrement et le déchiffrement des hôtes des nœuds utilisent l'énergie du processeur, les performances sont affectées à la fois en termes de débit et d'utilisation du processeur sur les nœuds lorsque le chiffrement est activé, quel que soit le système de sécurité IP utilisé.

IPSec crypte le trafic au niveau de la charge utile IP, avant qu'il n'atteigne la carte réseau, protégeant ainsi les champs qui seraient autrement utilisés pour le délestage de la carte réseau. Cela signifie que certaines fonctions d'accélération de la carte réseau peuvent ne pas être utilisables lorsque l'IPSec est activé, ce qui entraînera une diminution du débit et une augmentation de l'utilisation de l'unité centrale.

Les espaces de noms de montage sont utilisés pour isoler les points de montage afin que les processus dans différents espaces de noms ne puissent pas voir les fichiers des autres. L'encapsulation est le processus qui consiste à déplacer les espaces de noms de montage Kubernetes vers un autre emplacement où ils ne seront pas constamment analysés par le système d'exploitation hôte.

Le système d'exploitation hôte utilise systemd pour analyser en permanence tous les espaces de noms de montage : à la fois les montages Linux standard et les nombreux montages que Kubernetes utilise pour fonctionner. L'implémentation actuelle de kubelet et de CRI-O utilise l'espace de noms de premier niveau pour tous les points de montage de l'exécution du conteneur et de kubelet. Cependant, l'encapsulation de ces points de montage spécifiques aux conteneurs dans un espace de noms privé réduit la charge de travail de systemd sans différence de fonctionnalité. L'utilisation d'un espace de noms de montage distinct pour CRI-O et kubelet permet d'encapsuler les montages spécifiques aux conteneurs à partir de toute interaction avec systemd ou d'autres systèmes d'exploitation hôtes.

Cette capacité à réaliser potentiellement une optimisation majeure du CPU est désormais disponible pour tous les administrateurs d'OpenShift Container Platform. L'encapsulation peut également améliorer la sécurité en stockant les points de montage spécifiques à Kubernetes dans un emplacement à l'abri de l'inspection par des utilisateurs non privilégiés.

Les diagrammes suivants illustrent une installation Kubernetes avant et après l'encapsulation. Les deux scénarios montrent des exemples de conteneurs dont les paramètres de propagation des montages sont bidirectionnels, host-to-container et none.

Ici, nous voyons systemd, les processus du système d'exploitation hôte, kubelet et le runtime du conteneur partager un seul espace de noms de montage.

Le diagramme suivant illustre l'état du système après l'encapsulation.

Vous pouvez configurer l'encapsulation de l'espace de noms de montage de manière à ce qu'un cluster fonctionne avec moins de ressources.

Ces commandes renvoient les espaces de noms de montage associés à systemd, kubelet et à l'exécution du conteneur. Dans OpenShift Container Platform, l'exécution du conteneur est CRI-O.

L'encapsulation est effective si systemd se trouve dans un espace de noms de montage différent de kubelet et CRI-O, comme dans l'exemple ci-dessus. L'encapsulation n'est pas effective si les trois processus se trouvent dans le même espace de noms de montage.

Vous pouvez inspecter les points de montage spécifiques à Kubernetes dans le système d'exploitation hôte du cluster à des fins de débogage ou d'audit en utilisant le script kubensenter disponible dans Red Hat Enterprise Linux CoreOS (RHCOS).

Les sessions shell SSH vers l'hôte du cluster sont dans l'espace de noms par défaut. Pour inspecter les points de montage spécifiques à Kubernetes dans une invite du shell SSH, vous devez exécuter le script kubensenter en tant que root. Le script kubensenter est conscient de l'état de l'encapsulation du montage, et peut être exécuté en toute sécurité même si l'encapsulation n'est pas activée.

Si la fonction d'encapsulation n'est pas activée, les commandes kubensenter findmnt et findmnt produisent le même résultat, qu'elles soient exécutées dans une session oc debug ou dans une invite du shell SSH.

Tout outil de surveillance qui s'appuie sur la capacité à s'exécuter dans le système d'exploitation hôte et à avoir une visibilité sur les points de montage créés par kubelet, CRI-O ou les conteneurs eux-mêmes, doit entrer dans l'espace de noms de montage de conteneur pour voir ces points de montage. Le script kubensenter fourni avec OpenShift Container Platform exécute une autre commande à l'intérieur du point de montage Kubernetes et peut être utilisé pour adapter les outils existants.

Le script kubensenter est conscient de l'état de la fonctionnalité d'encapsulation du montage et peut être exécuté en toute sécurité même si l'encapsulation n'est pas activée. Dans ce cas, le script exécute la commande fournie dans l'espace de noms mount par défaut.

Par exemple, si un service systemd doit s'exécuter dans le nouvel espace de noms Kubernetes mount, modifiez le fichier de service et utilisez la ligne de commande ExecStart= avec kubensenter.

[Unit]
Description=Example service
[Service]
ExecStart=/usr/bin/kubensenter /path/to/original/command arg1 arg2

Pour provisionner un hôte bare metal de Red Hat Enterprise Linux CoreOS (RHCOS) en tant que nœud dans votre cluster, créez d'abord un objet custom resource (CR) MachineSet qui correspond au matériel de l'hôte bare metal. Les ensembles de machines de calcul de l'hôte bare metal décrivent les composants d'infrastructure spécifiques à votre configuration. Vous appliquez des étiquettes Kubernetes spécifiques à ces ensembles de machines de calcul, puis vous mettez à jour les composants d'infrastructure pour qu'ils s'exécutent uniquement sur ces machines.

Machine Les CR sont créés automatiquement lorsque vous mettez à l'échelle le site MachineSet contenant une annotation metal3.io/autoscale-to-hosts. OpenShift Container Platform utilise les CR Machine pour provisionner le nœud bare metal correspondant à l'hôte spécifié dans le CR MachineSet.

Vous pouvez maintenir les détails des hôtes bare metal de votre cluster à partir de la console web d'OpenShift Container Platform. Naviguez vers Compute → Bare Metal Hosts, et sélectionnez une tâche dans le menu déroulant Actions. Ici, vous pouvez gérer des éléments tels que les détails BMC, l'adresse MAC de démarrage pour l'hôte, activer la gestion de l'alimentation, etc. Vous pouvez également consulter les détails des interfaces réseau et des lecteurs de l'hôte.

Vous pouvez déplacer un hôte bare metal en mode maintenance. Lorsque vous mettez un hôte en mode maintenance, le planificateur déplace toutes les charges de travail gérées hors du nœud bare metal correspondant. Aucune nouvelle charge de travail n'est planifiée en mode maintenance.

Vous pouvez déprovisionner un hôte bare metal dans la console web. Le déprovisionnement d'un hôte permet d'effectuer les actions suivantes :

La mémoire est gérée par blocs appelés pages. Sur la plupart des systèmes, une page correspond à 4Ki. 1Mi de mémoire équivaut à 256 pages ; 1Gi de mémoire équivaut à 256 000 pages, et ainsi de suite. Les unités centrales de traitement disposent d'une unité de gestion de la mémoire intégrée qui gère une liste de ces pages au niveau matériel. Le Translation Lookaside Buffer (TLB) est une petite mémoire cache matérielle des correspondances entre les pages virtuelles et les pages physiques. Si l'adresse virtuelle transmise dans une instruction matérielle peut être trouvée dans le TLB, la correspondance peut être déterminée rapidement. Si ce n'est pas le cas, la TLB est manquée et le système revient à une traduction d'adresse plus lente, basée sur le logiciel, ce qui entraîne des problèmes de performance. La taille de la TLB étant fixe, le seul moyen de réduire le risque d'erreur de la TLB est d'augmenter la taille de la page.

Une page énorme est une page de mémoire dont la taille est supérieure à 4Ki. Sur les architectures x86_64, il existe deux tailles courantes de pages énormes : 2Mi et 1Gi. Les tailles varient sur les autres architectures. Pour utiliser les pages énormes, le code doit être écrit de manière à ce que les applications en soient conscientes. Les pages énormes transparentes (THP) tentent d'automatiser la gestion des pages énormes sans que l'application en ait connaissance, mais elles ont des limites. En particulier, elles sont limitées à des tailles de page de 2Mi. Les THP peuvent entraîner une dégradation des performances sur les nœuds à forte utilisation ou fragmentation de la mémoire en raison des efforts de défragmentation des THP, qui peuvent bloquer les pages de mémoire. Pour cette raison, certaines applications peuvent être conçues pour (ou recommander) l'utilisation d'énormes pages pré-allouées au lieu de THP.

Dans OpenShift Container Platform, les applications d'un pod peuvent allouer et consommer des pages énormes pré-allouées.

Les nœuds doivent pré-allouer des pages volumineuses pour que le nœud puisse indiquer sa capacité de pages volumineuses. Un nœud ne peut pré-allouer des pages volumineuses que pour une seule taille.

Les pages volumineuses peuvent être consommées par le biais des exigences de ressources au niveau du conteneur en utilisant le nom de la ressource hugepages-<size>, où la taille est la notation binaire la plus compacte utilisant des valeurs entières prises en charge par un nœud particulier. Par exemple, si un nœud prend en charge des tailles de page de 2048 Ko, il expose une ressource planifiable hugepages-2Mi. Contrairement à l'unité centrale ou à la mémoire, les pages volumineuses ne permettent pas le surengagement.

apiVersion: v1
kind: Pod
metadata:
  generateName: hugepages-volume-
spec:
  containers:
  - securityContext:
      privileged: true
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi 1
        memory: "1Gi"
        cpu: "1"
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

Allocating huge pages of a specific size

Certaines plates-formes prennent en charge plusieurs tailles de pages volumineuses. Pour allouer des pages volumineuses d'une taille spécifique, faites précéder les paramètres de la commande d'amorçage des pages volumineuses d'un paramètre de sélection de la taille des pages volumineuses hugepagesz=<size>. La valeur de <size> doit être spécifiée en octets avec un suffixe d'échelle facultatif [kKmMgG]. La taille par défaut des pages énormes peut être définie à l'aide du paramètre d'amorçage default_hugepagesz=<size>.

Huge page requirements

Vous pouvez utiliser l'API Downward pour injecter des informations sur les ressources de pages volumineuses consommées par un conteneur.

Vous pouvez injecter l'allocation des ressources sous la forme de variables d'environnement, d'un plugin de volume ou des deux. Les applications que vous développez et exécutez dans le conteneur peuvent déterminer les ressources disponibles en lisant les variables d'environnement ou les fichiers dans les volumes spécifiés.

Les nœuds doivent pré-allouer les pages volumineuses utilisées dans un cluster OpenShift Container Platform. Il existe deux façons de réserver des pages volumineuses : au démarrage et à l'exécution. La réservation au démarrage augmente les chances de succès car la mémoire n'a pas encore été fragmentée de manière significative. Le Node Tuning Operator prend actuellement en charge l'allocation de pages volumineuses au moment du démarrage sur des nœuds spécifiques.

$ oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"
100Mi

Les pages volumineuses transparentes (THP) tentent d'automatiser la plupart des aspects de la création, de la gestion et de l'utilisation des pages volumineuses. Comme THP gère automatiquement les pages volumineuses, cela n'est pas toujours optimal pour tous les types de charges de travail. THP peut entraîner une régression des performances, car de nombreuses applications gèrent elles-mêmes les pages volumineuses. Il convient donc d'envisager la désactivation de THP. Les étapes suivantes décrivent comment désactiver THP à l'aide de Node Tuning Operator (NTO).

L'émergence de l'Edge computing dans le domaine Telco / 5G joue un rôle clé dans la réduction des problèmes de latence et de congestion et dans l'amélioration des performances des applications.

En termes simples, la latence détermine la vitesse à laquelle les données (paquets) se déplacent de l'expéditeur au destinataire et reviennent à l'expéditeur après avoir été traitées par le destinataire. Le maintien d'une architecture de réseau avec un délai de latence le plus faible possible est essentiel pour répondre aux exigences de performance du réseau de la 5G. Par rapport à la technologie 4G, dont le temps de latence moyen est de 50 ms, la 5G vise à atteindre des temps de latence de 1 ms ou moins. Cette réduction du temps de latence multiplie par 10 le débit des réseaux sans fil.

De nombreuses applications déployées dans l'espace Telco nécessitent une faible latence qui ne peut tolérer qu'une perte de paquets nulle. Le réglage pour une perte de paquets nulle permet d'atténuer les problèmes inhérents qui dégradent les performances du réseau. Pour plus d'informations, voir Tuning for Zero Packet Loss dans Red Hat OpenStack Platform (RHOSP).

L'initiative Edge computing entre également en jeu pour réduire les taux de latence. Il s'agit d'être à la périphérie du nuage et plus proche de l'utilisateur. Cela réduit considérablement la distance entre l'utilisateur et les centres de données éloignés, ce qui permet de réduire les temps de réponse des applications et la latence des performances.

Les administrateurs doivent pouvoir gérer leurs nombreux sites Edge et services locaux de manière centralisée afin que tous les déploiements puissent fonctionner au coût de gestion le plus bas possible. Ils ont également besoin d'un moyen simple de déployer et de configurer certains nœuds de leur cluster pour des applications en temps réel à faible latence et à haute performance. Les nœuds à faible latence sont utiles pour des applications telles que Cloud-native Network Functions (CNF) et Data Plane Development Kit (DPDK).

OpenShift Container Platform fournit actuellement des mécanismes pour régler les logiciels sur un cluster OpenShift Container Platform pour un fonctionnement en temps réel et une faible latence (environ <20 microsecondes de temps de réaction). Cela inclut le réglage du noyau et des valeurs d'ensemble d'OpenShift Container Platform, l'installation d'un noyau et la reconfiguration de la machine. Mais cette méthode nécessite de configurer quatre opérateurs différents et d'effectuer de nombreuses configurations qui, lorsqu'elles sont effectuées manuellement, sont complexes et peuvent être sujettes à des erreurs.

OpenShift Container Platform utilise le Node Tuning Operator pour mettre en œuvre un réglage automatique afin d'obtenir des performances de faible latence pour les applications OpenShift Container Platform. L'administrateur du cluster utilise cette configuration de profil de performance qui facilite la réalisation de ces changements de manière plus fiable. L'administrateur peut spécifier s'il faut mettre à jour le noyau vers kernel-rt, réserver les CPU pour les tâches d'entretien du cluster et du système d'exploitation, y compris les conteneurs pod infra, et isoler les CPU pour les conteneurs d'application afin d'exécuter les charges de travail.

OpenShift Container Platform prend également en charge les indices de charge de travail pour le Node Tuning Operator qui peut régler le site PerformanceProfile pour répondre aux exigences des différents environnements industriels. Des indices de charge de travail sont disponibles pour highPowerConsumption (très faible latence au prix d'une consommation d'énergie accrue) et realTime (priorité donnée à une latence optimale). Une combinaison de paramètres true/false pour ces conseils peut être utilisée pour traiter les profils et les exigences de charge de travail spécifiques à l'application.

Les indices de charge de travail simplifient l'ajustement des performances aux paramètres sectoriels. Au lieu d'une approche "unique", les indices de charge de travail peuvent s'adapter aux schémas d'utilisation, par exemple en donnant la priorité à.. :

Dans un monde idéal, tous ces éléments seraient prioritaires : dans la réalité, certains le sont au détriment d'autres. L'opérateur d'optimisation des nœuds est maintenant conscient des attentes de la charge de travail et est mieux à même de répondre aux exigences de la charge de travail. L'administrateur du cluster peut maintenant spécifier dans quel cas d'utilisation cette charge de travail s'inscrit. L'opérateur de réglage des nœuds utilise le site PerformanceProfile pour affiner les paramètres de performance de la charge de travail.

L'environnement dans lequel une application fonctionne influence son comportement. Pour un centre de données typique sans exigences strictes en matière de temps de latence, seul un réglage par défaut minimal est nécessaire pour permettre le partitionnement de l'unité centrale pour certains modules de charge de travail à haute performance. Pour les centres de données et les charges de travail où la latence est une priorité plus importante, des mesures sont toujours prises pour optimiser la consommation d'énergie. Les cas les plus complexes sont les clusters situés à proximité d'équipements sensibles à la latence, tels que les machines de production et les radios logicielles. Cette dernière catégorie de déploiement est souvent appelée "Far edge". Pour les déploiements en périphérie lointaine, une latence ultra-faible est la priorité absolue et est obtenue au détriment de la gestion de l'énergie.

Dans OpenShift Container Platform version 4.10 et les versions précédentes, l'opérateur Performance Addon était utilisé pour mettre en œuvre un réglage automatique afin d'obtenir des performances de faible latence. Désormais, cette fonctionnalité fait partie de l'opérateur Node Tuning.

De nombreuses industries et organisations ont besoin d'un calcul extrêmement performant et pourraient avoir besoin d'une latence faible et prévisible, en particulier dans les secteurs de la finance et des télécommunications. Pour ces industries, avec leurs exigences uniques, OpenShift Container Platform fournit le Node Tuning Operator pour mettre en œuvre un réglage automatique afin d'obtenir des performances de faible latence et un temps de réponse cohérent pour les applications OpenShift Container Platform.

L'administrateur du cluster peut utiliser cette configuration du profil de performance pour effectuer ces changements de manière plus fiable. L'administrateur peut spécifier s'il faut mettre à jour le noyau vers kernel-rt (temps réel), réserver les CPU pour les tâches de maintenance du cluster et du système d'exploitation, y compris les conteneurs pod infra, isoler les CPU pour les conteneurs d'application afin d'exécuter les charges de travail, et désactiver les CPU inutilisés afin de réduire la consommation d'énergie.

$ oc get node -o wide

NAME                               	STATUS   ROLES           	AGE 	VERSION                  	INTERNAL-IP
EXTERNAL-IP   OS-IMAGE                                       	KERNEL-VERSION
CONTAINER-RUNTIME
rt-worker-0.example.com	          Ready	 worker,worker-rt   5d17h   v1.25.0
128.66.135.107   <none>    	        Red Hat Enterprise Linux CoreOS 46.82.202008252340-0 (Ootpa)
4.18.0-305.30.1.rt7.102.el8_4.x86_64   cri-o://1.25.0-99.rhaos4.10.gitc3131de.el8
[...]

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr
    image: <image-pull-spec>
    resources:
      limits:
        memory: "200Mi"
        cpu: "1"
      requests:
        memory: "200Mi"
        cpu: "1"

apiVersion: v1
kind: Pod
metadata:
  ...
  annotations:
    ...
    cpu-load-balancing.crio.io: "disable"
    ...
  ...
spec:
  ...
  runtimeClassName: performance-<profile_name>
  ...

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  # ...
  nodeSelector:
    node-role.kubernetes.io/worker-rt: ""

annotations:
  cpu-c-states.crio.io: "disable"
  cpu-freq-governor.crio.io: "<governor>"

apiVersion: performance.openshift.io/v2
kind: Pod
metadata:
  annotations:
      cpu-quota.crio.io: "disable"
spec:
    runtimeClassName: performance-<profile_name>
...

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: manual
spec:
  globallyDisableIrqLoadBalancing: true
...

apiVersion: performance.openshift.io/v2
kind: Pod
metadata:
  annotations:
      irq-load-balancing.crio.io: "disable"
spec:
    runtimeClassName: performance-<profile_name>
...

Le profil de performance vous permet de contrôler les aspects de réglage de la latence des nœuds qui appartiennent à un certain pool de configuration de machines. Après avoir spécifié vos paramètres, l'objet PerformanceProfile est compilé en plusieurs objets qui effectuent le réglage au niveau du nœud :

Vous pouvez utiliser un profil de performance pour spécifier s'il faut mettre à jour le noyau vers kernel-rt, allouer d'énormes pages et partitionner les CPU pour qu'ils effectuent des tâches ménagères ou exécutent des charges de travail.

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
 name: performance
spec:
 cpu:
  isolated: "5-15" 1
  reserved: "0-4" 2
 hugepages:
  defaultHugepagesSize: "1G"
  pages:
  - size: "1G"
    count: 16
    node: 0
 realTimeKernel:
  enabled: true  3
 numa:  4
  topologyPolicy: "best-effort"
 nodeSelector:
  node-role.kubernetes.io/worker-cnf: "" 5

hugepages:
   defaultHugepagesSize: "1G"
   pages:
   - size:  "1G"
     count:  4
     node:  0 1

spec:
  hugepages:
    defaultHugepagesSize: 1G
    pages:
    - count: 1024
      node: 0
      size: 2M
    - count: 4
      node: 1
      size: 1G

$ cat /proc/irq/<irq-num>/effective_affinity

workloadHints:
highPowerConsumption: false
realTime: false

workloadHints:
highPowerConsumption: false
realTime: true

workloadHints:
highPowerConsumption: true
realTime: true

workloadHints:
realTime: true
highPowerConsumption: false
perPodPowerManagement: true

L'opérateur de réglage des nœuds vous permet d'ajuster le nombre de files d'attente du contrôleur d'interface réseau (NIC) pour chaque périphérique réseau en configurant le profil de performance. Les files d'attente des périphériques réseau permettent de répartir les paquets entre différentes files d'attente physiques et chaque file d'attente dispose d'un fil d'exécution distinct pour le traitement des paquets.

Dans les systèmes en temps réel ou à faible latence, toutes les lignes de demande d'interruption (IRQ) inutiles reliées aux unités centrales isolées doivent être déplacées vers des unités centrales réservées ou de maintien.

Dans les déploiements avec des applications qui nécessitent un système, une mise en réseau OpenShift Container Platform ou dans les déploiements mixtes avec des charges de travail Data Plane Development Kit (DPDK), plusieurs files d'attente sont nécessaires pour obtenir un bon débit et le nombre de files d'attente NIC devrait être ajusté ou rester inchangé. Par exemple, pour obtenir une faible latence, le nombre de files d'attente NIC pour les charges de travail basées sur le DPDK doit être réduit au nombre de CPU réservés ou de maintenance.

Trop de files d'attente sont créées par défaut pour chaque unité centrale et elles ne s'intègrent pas dans les tables d'interruption des unités centrales de gestion lorsque l'on cherche à réduire la latence. La réduction du nombre de files d'attente permet un réglage correct. Un plus petit nombre de files d'attente signifie un plus petit nombre d'interruptions qui s'intègrent alors dans la table IRQ.

apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
  spec:
    cpu:
      reserved: 0-1  #total = 2
      isolated: 2-8
    net:
      userLevelNetworking: true
# ...

apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
  spec:
    cpu:
      reserved: 0-1  #total = 2
      isolated: 2-8
    net:
      userLevelNetworking: true
      devices:
      - vendorID = 0x1af4
# ...

# udevadm info -p /sys/class/net/ens4
...
E: ID_MODEL_ID=0x1000
E: ID_VENDOR_ID=0x1af4
E: INTERFACE=ens4
...

# udevadm info -p /sys/class/net/eth0
...
E: ID_MODEL_ID=0x1002
E: ID_VENDOR_ID=0x1001
E: INTERFACE=eth0
...

La ressource personnalisée (CR) PerformanceProfile contient des champs d'état permettant de signaler l'état des réglages et de déboguer les problèmes de dégradation de la latence. Ces champs indiquent les conditions qui décrivent l'état de la fonctionnalité de rapprochement de l'opérateur.

Un problème typique peut survenir lorsque l'état des pools de configuration de machines attachés au profil de performance est dégradé, ce qui entraîne une dégradation de l'état de PerformanceProfile. Dans ce cas, le pool de configuration de machines émet un message d'échec.

L'opérateur Node Tuning contient le champ d'état performanceProfile.spec.status.Conditions:

Status:
  Conditions:
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                True
    Type:                  Available
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                True
    Type:                  Upgradeable
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                False
    Type:                  Progressing
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                False
    Type:                  Degraded

Le champ Status contient Conditions qui spécifie les valeurs Type indiquant le statut du profil de performance :

Chacun de ces types contient les champs suivants :

Lorsque vous ouvrez un dossier d'assistance, il est utile de fournir des informations de débogage sur votre cluster à l'équipe d'assistance de Red Hat.

L'outil must-gather vous permet de collecter des informations de diagnostic sur votre cluster OpenShift Container Platform, y compris le réglage des nœuds, la topologie NUMA et d'autres informations nécessaires pour déboguer les problèmes de configuration à faible latence.

Pour une assistance rapide, fournissez des informations de diagnostic pour OpenShift Container Platform et pour le réglage de la faible latence.

--image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.12.

Votre cluster doit remplir les conditions suivantes pour que vous puissiez effectuer les tests de latence :

Le mode découverte permet de valider le fonctionnement d'un cluster sans en modifier la configuration. Les configurations existantes de l'environnement sont utilisées pour les tests. Les tests peuvent trouver les éléments de configuration nécessaires et les utiliser pour exécuter les tests. Si les ressources nécessaires à l'exécution d'un test spécifique ne sont pas trouvées, le test est ignoré et un message approprié est envoyé à l'utilisateur. Une fois les tests terminés, aucun nettoyage des éléments de configuration préconfigurés n'est effectué et l'environnement de test peut être immédiatement utilisé pour un autre test.

Limiter les nœuds utilisés lors des tests

Les nœuds sur lesquels les tests sont exécutés peuvent être limités en spécifiant une variable d'environnement NODES_SELECTOR, par exemple -e NODES_SELECTOR=node-role.kubernetes.io/worker-cnf. Toutes les ressources créées par le test sont limitées aux nœuds dont les étiquettes correspondent.

L'image cnf-tests utilise trois outils pour mesurer la latence du système :

Chaque outil a un usage spécifique. Utilisez les outils dans l'ordre pour obtenir des résultats de test fiables.

Les tests introduisent les variables d'environnement suivantes :

Exécutez les tests de latence du cluster pour valider le réglage des nœuds pour votre charge de travail Cloud-native Network Functions (CNF).

hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:
Latency threshold: 10us
Sample window: 1000000us
Sample width: 950000us
Non-sampling period: 50000us
Output File: None

Starting test
test finished
Max Latency: Below threshold
Samples recorded: 0

hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:Latency threshold: 10usSample window: 1000000us
Sample width: 950000usNon-sampling period: 50000usOutput File: None

Starting tests:1610542421.275784439, inner:78, outer:81
ts: 1610542444.330561619, inner:27, outer:28
ts: 1610542445.332549975, inner:39, outer:38
ts: 1610542541.568546097, inner:47, outer:32
ts: 1610542590.681548531, inner:13, outer:17
ts: 1610543033.818801482, inner:29, outer:30
ts: 1610543080.938801990, inner:90, outer:76
ts: 1610543129.065549639, inner:28, outer:39
ts: 1610543474.859552115, inner:28, outer:35
ts: 1610543523.973856571, inner:52, outer:49
ts: 1610543572.089799738, inner:27, outer:30
ts: 1610543573.091550771, inner:34, outer:28
ts: 1610543574.093555202, inner:116, outer:63

running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000001 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000002 579506   535967  418614  573648  532870  529897  489306  558076  582350  585188  583793  223781  532480  569130  472250  576043
More histogram entries ...
# Total: 000600000 000600000 000600000 000599999 000599999 000599999 000599998 000599998 000599998 000599997 000599997 000599996 000599996 000599995 000599995 000599995
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00005 00005 00004 00005 00004 00004 00005 00005 00006 00005 00004 00005 00004 00004 00005 00004
# Histogram Overflows: 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000
# Histogram Overflow at cycle number:
# Thread 0:
# Thread 1:
# Thread 2:
# Thread 3:
# Thread 4:
# Thread 5:
# Thread 6:
# Thread 7:
# Thread 8:
# Thread 9:
# Thread 10:
# Thread 11:
# Thread 12:
# Thread 13:
# Thread 14:
# Thread 15:

running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000001 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000002 564632   579686  354911  563036  492543  521983  515884  378266  592621  463547  482764  591976  590409  588145  589556  353518
More histogram entries ...
# Total: 000599999 000599999 000599999 000599997 000599997 000599998 000599998 000599997 000599997 000599996 000599995 000599996 000599995 000599995 000599995 000599993
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00493 00387 00271 00619 00541 00513 00009 00389 00252 00215 00539 00498 00363 00204 00068 00520
# Histogram Overflows: 00001 00001 00001 00002 00002 00001 00000 00001 00001 00001 00002 00001 00001 00001 00001 00002
# Histogram Overflow at cycle number:
# Thread 0: 155922
# Thread 1: 110064
# Thread 2: 110064
# Thread 3: 110063 155921
# Thread 4: 110063 155921
# Thread 5: 155920
# Thread 6:
# Thread 7: 110062
# Thread 8: 110062
# Thread 9: 155919
# Thread 10: 110061 155919
# Thread 11: 155918
# Thread 12: 155918
# Thread 13: 110060
# Thread 14: 110060
# Thread 15: 110059 155917

Utilisez les procédures suivantes pour générer un résultat de test de latence JUnit et un rapport d'échec de test.

Utilisez les procédures suivantes pour générer un résultat de test de latence JUnit et un rapport d'échec de test.

Vous pouvez effectuer des tests de latence sur des clusters OpenShift à nœud unique.

L'image de tests CNF peut exécuter des tests dans un cluster déconnecté qui n'est pas en mesure d'accéder à des registres externes. Cela nécessite deux étapes :

Mise en miroir des images dans un registre personnalisé accessible depuis le cluster

Un exécutable mirror est livré avec l'image afin de fournir les données requises par oc pour reproduire l'image de test dans un registre local.

Configurer les tests pour qu'ils consomment des images provenant d'un registre personnalisé

Vous pouvez exécuter les tests de latence à l'aide d'une image de test personnalisée et d'un registre d'images en utilisant les variables CNF_TESTS_IMAGE et IMAGE_REGISTRY.

Mise en miroir des images vers le registre d'images OpenShift du cluster

OpenShift Container Platform fournit un registre d'images de conteneurs intégré, qui s'exécute comme une charge de travail standard sur le cluster.

Miroir d'un ensemble différent d'images de test

Vous pouvez éventuellement modifier les images en amont par défaut qui sont mises en miroir pour les tests de latence.

Pour effectuer des tests de latence, le cluster doit être accessible depuis le conteneur cnf-tests.

Les profils de latence des travailleurs sont des ensembles multiples de valeurs soigneusement ajustées pour les paramètres node-status-update-frequency, node-monitor-grace-period, default-not-ready-toleration-seconds et default-unreachable-toleration-seconds. Ces paramètres vous permettent de contrôler la réaction du cluster aux problèmes de latence sans avoir à déterminer manuellement les meilleures valeurs.

Tous les profils de latence des travailleurs configurent les paramètres suivants :

Les opérateurs suivants surveillent les modifications apportées aux profils de latence des travailleurs et réagissent en conséquence :

Bien que la configuration par défaut fonctionne dans la plupart des cas, OpenShift Container Platform propose deux autres profils de latence du travailleur pour les situations où le réseau connaît une latence plus élevée que d'habitude. Les trois profils de latence des travailleurs sont décrits dans les sections suivantes :

Pour mettre en œuvre un profil de latence du travailleur afin de gérer la latence du réseau, modifiez l'objet node.config pour ajouter le nom du profil. Vous pouvez modifier le profil à tout moment lorsque la latence augmente ou diminue.

Vous devez déplacer un profil de latence de travailleur à la fois. Par exemple, vous ne pouvez pas passer directement du profil Default au profil LowUpdateSlowReaction. Vous devez d'abord passer du profil default au profil MediumUpdateAverageReaction, puis à LowUpdateSlowReaction. De même, lorsque vous revenez au profil par défaut, vous devez d'abord passer du profil bas au profil moyen, puis au profil par défaut.

Pour transformer le profil bas en profil moyen ou le profil moyen en profil bas, modifiez l'objet node.config et réglez le paramètre spec.workerLatencyProfile sur la valeur appropriée.

Le Topology Aware Lifecycle Manager (TALM) gère le déploiement des politiques de Red Hat Advanced Cluster Management (RHACM) pour un ou plusieurs clusters d'OpenShift Container Platform. L'utilisation de TALM dans un grand réseau de clusters permet le déploiement progressif des politiques vers les clusters en lots limités. Cela permet de minimiser les éventuelles interruptions de service lors de la mise à jour. Avec TALM, vous pouvez contrôler les actions suivantes :

Pour OpenShift à nœud unique, le Topology Aware Lifecycle Manager (TALM) offre les fonctionnalités suivantes :

TALM prend en charge l'orchestration des mises à jour des y-streams et z-streams d'OpenShift Container Platform, ainsi que les opérations du deuxième jour sur les y-streams et z-streams.

Le Topology Aware Lifecycle Manager (TALM) utilise les stratégies RHACM pour les mises à jour des clusters.

TALM peut être utilisé pour gérer le déploiement de toute politique CR dont le champ remediationAction est défini sur inform. Les cas d'utilisation pris en charge sont les suivants :

Pour les politiques qui mettent à jour un abonnement d'opérateur avec une approbation manuelle, TALM fournit une fonctionnalité supplémentaire qui approuve l'installation de l'opérateur mis à jour.

Pour plus d'informations sur les politiques gérées, voir Policy Overview dans la documentation RHACM.

Pour plus d'informations sur le CRD PolicyGenTemplate, voir la section "À propos du CRD PolicyGenTemplate" dans "Configuration des clusters gérés avec des stratégies et des ressources PolicyGenTemplate".

Vous pouvez utiliser la console web d'OpenShift Container Platform pour installer le Topology Aware Lifecycle Manager.

Si l'opérateur n'est pas installé correctement :

Vous pouvez utiliser le CLI OpenShift (oc) pour installer le Topology Aware Lifecycle Manager (TALM).

Le Topology Aware Lifecycle Manager (TALM) construit le plan de remédiation à partir de la CR ClusterGroupUpgrade pour un groupe de clusters. Vous pouvez définir les spécifications suivantes dans un CR ClusterGroupUpgrade:

Vous pouvez contrôler l'heure de début d'une mise à jour en utilisant le champ enable dans le CR ClusterGroupUpgrade. Par exemple, si vous avez une fenêtre de maintenance programmée de quatre heures, vous pouvez préparer un CR ClusterGroupUpgrade avec le champ enable défini sur false.

Vous pouvez définir le délai d'attente en configurant le paramètre spec.remediationStrategy.timeout comme suit :

spec
  remediationStrategy:
          maxConcurrency: 1
          timeout: 240

Vous pouvez utiliser l'adresse batchTimeoutAction pour déterminer ce qui se passe si une mise à jour échoue pour un cluster. Vous pouvez spécifier continue pour ignorer le cluster défaillant et continuer à mettre à jour les autres clusters, ou abort pour arrêter la remédiation des politiques pour tous les clusters. Une fois le délai écoulé, TALM supprime toutes les politiques enforce pour s'assurer qu'aucune autre mise à jour n'est effectuée sur les clusters.

Pour appliquer les modifications, vous définissez le champ enabled sur true.

Pour plus d'informations, voir la section "Application des stratégies de mise à jour aux clusters gérés".

Au fur et à mesure que TALM remédie aux politiques vers les clusters spécifiés, le CR ClusterGroupUpgrade peut signaler des statuts vrais ou faux pour un certain nombre de conditions.

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  creationTimestamp: '2022-11-18T16:27:15Z'
  finalizers:
    - ran.openshift.io/cleanup-finalizer
  generation: 1
  name: talm-cgu
  namespace: talm-namespace
  resourceVersion: '40451823'
  uid: cca245a5-4bca-45fa-89c0-aa6af81a596c
Spec:
  actions:
    afterCompletion:
      deleteObjects: true
    beforeEnable: {}
  backup: false
  clusters: 1
    - spoke1
  enable: false 2
  managedPolicies: 3
    - talm-policy
  preCaching: false
  remediationStrategy: 4
    canaries: 5
        - spoke1
    maxConcurrency: 2 6
    timeout: 240
  clusterLabelSelectors: 7
    - matchExpressions:
      - key: label1
      operator: In
      values:
        - value1a
        - value1b
  batchTimeoutAction: 8
status: 9
    computedMaxConcurrency: 2
    conditions:
      - lastTransitionTime: '2022-11-18T16:27:15Z'
        message: All selected clusters are valid
        reason: ClusterSelectionCompleted
        status: 'True'
        type: ClustersSelected 10
      - lastTransitionTime: '2022-11-18T16:27:15Z'
        message: Completed validation
        reason: ValidationCompleted
        status: 'True'
        type: Validated 11
      - lastTransitionTime: '2022-11-18T16:37:16Z'
        message: Not enabled
        reason: NotEnabled
        status: 'False'
        type: Progressing
    managedPoliciesForUpgrade:
      - name: talm-policy
        namespace: talm-namespace
    managedPoliciesNs:
      talm-policy: talm-namespace
    remediationPlan:
      - - spoke1
      - - spoke2
        - spoke3
    status: