14.2. Approvisionnement des charges de travail en temps réel et à faible latence
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.
L'utilisation de sondes d'exécution en conjonction avec des applications qui nécessitent des CPU garantis peut provoquer des pics de latence. Il est recommandé d'utiliser d'autres sondes, telles qu'un ensemble de sondes réseau correctement configurées, comme alternative.
Dans les versions antérieures d'OpenShift Container Platform, l'opérateur Performance Addon était utilisé pour mettre en œuvre un réglage automatique afin d'obtenir des performances de faible latence pour les applications OpenShift. Dans OpenShift Container Platform 4.11 et les versions ultérieures, ces fonctions font partie de l'opérateur Node Tuning.
14.2.1. Limitations connues pour le temps réel
Dans la plupart des déploiements, kernel-rt est pris en charge uniquement sur les nœuds de travail lorsque vous utilisez un cluster standard avec trois nœuds de plan de contrôle et trois nœuds de travail. Il existe des exceptions pour les nœuds compacts et uniques dans les déploiements de OpenShift Container Platform. Pour les installations sur un seul nœud, kernel-rt est pris en charge sur le seul nœud de plan de contrôle.
Pour utiliser pleinement le mode temps réel, les conteneurs doivent être exécutés avec des privilèges élevés. Voir Définir les capacités d'un conteneur pour plus d'informations sur l'octroi de privilèges.
OpenShift Container Platform limite les capacités autorisées, il se peut donc que vous deviez également créer un site SecurityContext
.
Cette procédure est entièrement prise en charge par les installations "bare metal" utilisant les systèmes Red Hat Enterprise Linux CoreOS (RHCOS).
L'établissement d'attentes correctes en matière de performances renvoie au fait que le noyau en temps réel n'est pas une panacée. Son objectif est un déterminisme cohérent, à faible latence, offrant des temps de réponse prévisibles. Le noyau en temps réel entraîne des frais généraux supplémentaires. Cela est dû principalement à la gestion des interruptions matérielles dans des threads programmés séparément. L'augmentation des frais généraux dans certaines charges de travail entraîne une dégradation du débit global. L'ampleur exacte de la dégradation dépend fortement de la charge de travail, allant de 0 % à 30 %. Cependant, c'est le coût du déterminisme.
14.2.2. Fournir à un travailleur des capacités en temps réel
- Facultatif : Ajoutez un nœud au cluster OpenShift Container Platform. Voir Définition des paramètres du BIOS pour le réglage du système.
-
Ajoutez le label
worker-rt
aux nœuds de travail qui ont besoin de la capacité en temps réel en utilisant la commandeoc
. Créer un nouveau pool de configuration de machines pour les nœuds en temps réel :
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: name: worker-rt labels: machineconfiguration.openshift.io/role: worker-rt spec: machineConfigSelector: matchExpressions: - { key: machineconfiguration.openshift.io/role, operator: In, values: [worker, worker-rt], } paused: false nodeSelector: matchLabels: node-role.kubernetes.io/worker-rt: ""
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: name: worker-rt labels: machineconfiguration.openshift.io/role: worker-rt spec: machineConfigSelector: matchExpressions: - { key: machineconfiguration.openshift.io/role, operator: In, values: [worker, worker-rt], } paused: false nodeSelector: matchLabels: node-role.kubernetes.io/worker-rt: ""
Copy to Clipboard Copied! Notez qu'un pool de configuration de machines worker-rt est créé pour le groupe de nœuds ayant l'étiquette
worker-rt
.Ajoutez le nœud au pool de configuration de la machine appropriée en utilisant les étiquettes de rôle de nœud.
NoteVous devez décider quels nœuds sont configurés avec des charges de travail en temps réel. Vous pouvez configurer tous les nœuds de la grappe ou un sous-ensemble de nœuds. Le Node Tuning Operator qui s'attend à ce que tous les nœuds fassent partie d'un pool de configuration de machines dédiées. Si vous utilisez tous les nœuds, vous devez indiquer à l'opérateur de réglage des nœuds l'étiquette de rôle du nœud travailleur. Si vous utilisez un sous-ensemble, vous devez regrouper les nœuds dans un nouveau pool de configuration de machine.
-
Créez le site
PerformanceProfile
avec l'ensemble approprié de noyaux d'entretien etrealTimeKernel: enabled: true
. Vous devez définir
machineConfigPoolSelector
dansPerformanceProfile
:apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: example-performanceprofile spec: ... realTimeKernel: enabled: true nodeSelector: node-role.kubernetes.io/worker-rt: "" machineConfigPoolSelector: machineconfiguration.openshift.io/role: worker-rt
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: example-performanceprofile spec: ... realTimeKernel: enabled: true nodeSelector: node-role.kubernetes.io/worker-rt: "" machineConfigPoolSelector: machineconfiguration.openshift.io/role: worker-rt
Copy to Clipboard Copied! Vérifier qu'il existe un pool de configuration machine correspondant avec un label :
oc describe mcp/worker-rt
$ oc describe mcp/worker-rt
Copy to Clipboard Copied! Exemple de sortie
Name: worker-rt Namespace: Labels: machineconfiguration.openshift.io/role=worker-rt
Name: worker-rt Namespace: Labels: machineconfiguration.openshift.io/role=worker-rt
Copy to Clipboard Copied! - OpenShift Container Platform va commencer à configurer les nœuds, ce qui peut impliquer plusieurs redémarrages. Attendez que les nœuds s'installent. Cela peut prendre beaucoup de temps en fonction du matériel spécifique que vous utilisez, mais il faut compter 20 minutes par nœud.
- Vérifier que tout fonctionne comme prévu.
14.2.3. Vérification de l'installation du noyau en temps réel
Cette commande permet de vérifier que le noyau temps réel est installé :
oc get node -o wide
$ oc get node -o wide
Notez le travailleur avec le rôle worker-rt
qui contient la chaîne 4.18.0-305.30.1.rt7.102.el8_4.x86_64 cri-o://1.25.0-99.rhaos4.10.gitc3131de.el8
:
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 [...]
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
[...]
14.2.4. Créer une charge de travail en temps réel
Utilisez les procédures suivantes pour préparer une charge de travail qui utilisera les capacités en temps réel.
Procédure
-
Créer un pod avec une classe QoS de
Guaranteed
. - En option : Désactiver l'équilibrage de la charge du CPU pour DPDK.
- Attribuer un sélecteur de nœud approprié.
Lorsque vous écrivez vos applications, suivez les recommandations générales décrites dans la section Réglage et déploiement des applications.
14.2.5. Création d'un pod avec une classe de QoS de Guaranteed
Gardez les points suivants à l'esprit lorsque vous créez un pod auquel est attribuée une classe de qualité de service (QoS) de Guaranteed
:
- Chaque conteneur du pod doit avoir une limite de mémoire et une demande de mémoire, et elles doivent être identiques.
- Chaque conteneur du pod doit avoir une limite et une demande de CPU, et elles doivent être identiques.
L'exemple suivant montre le fichier de configuration d'un module qui a un conteneur. Le conteneur a une limite de mémoire et une demande de mémoire, toutes deux égales à 200 MiB. Le conteneur a une limite de CPU et une demande de CPU, toutes deux égales à 1 CPU.
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:
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"
Créer la capsule :
oc apply -f qos-pod.yaml --namespace=qos-example
$ oc apply -f qos-pod.yaml --namespace=qos-example
Copy to Clipboard Copied! Afficher des informations détaillées sur le pod :
oc get pod qos-demo --namespace=qos-example --output=yaml
$ oc get pod qos-demo --namespace=qos-example --output=yaml
Copy to Clipboard Copied! Exemple de sortie
spec: containers: ... status: qosClass: Guaranteed
spec: containers: ... status: qosClass: Guaranteed
Copy to Clipboard Copied! NoteSi un conteneur spécifie sa propre limite de mémoire, mais ne spécifie pas de demande de mémoire, OpenShift Container Platform attribue automatiquement une demande de mémoire qui correspond à la limite. De même, si un conteneur spécifie sa propre limite de CPU, mais ne spécifie pas de demande de CPU, OpenShift Container Platform attribue automatiquement une demande de CPU qui correspond à la limite.
14.2.6. Optionnel : Désactivation de l'équilibrage de la charge du CPU pour DPDK
La fonctionnalité permettant de désactiver ou d'activer l'équilibrage de la charge du CPU est mise en œuvre au niveau du CRI-O. Le code sous le CRI-O ne désactive ou n'active l'équilibrage de la charge du CPU que lorsque les conditions suivantes sont remplies.
Le pod doit utiliser la classe d'exécution
performance-<profile-name>
. Vous pouvez obtenir le nom approprié en regardant le statut du profil de performance, comme indiqué ici :apiVersion: performance.openshift.io/v2 kind: PerformanceProfile ... status: ... runtimeClass: performance-manual
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile ... status: ... runtimeClass: performance-manual
Copy to Clipboard Copied!
Actuellement, la désactivation de l'équilibrage de la charge du CPU n'est pas prise en charge par cgroup v2.
L'opérateur de réglage des nœuds est responsable de la création de l'extrait de configuration du gestionnaire d'exécution haute performance sous les nœuds concernés et de la création de la classe d'exécution haute performance sous le cluster. Son contenu sera le même que celui du gestionnaire d'exécution par défaut, sauf qu'il activera la fonctionnalité de configuration de l'équilibrage de la charge du processeur.
Pour désactiver l'équilibrage de la charge du CPU pour le pod, la spécification Pod
doit inclure les champs suivants :
apiVersion: v1 kind: Pod metadata: ... annotations: ... cpu-load-balancing.crio.io: "disable" ... ... spec: ... runtimeClassName: performance-<profile_name> ...
apiVersion: v1
kind: Pod
metadata:
...
annotations:
...
cpu-load-balancing.crio.io: "disable"
...
...
spec:
...
runtimeClassName: performance-<profile_name>
...
Ne désactivez l'équilibrage de la charge du CPU que lorsque la politique statique du gestionnaire de CPU est activée et pour les pods avec QoS garantie qui utilisent des CPU entiers. Dans le cas contraire, la désactivation de l'équilibrage de la charge du CPU peut affecter les performances d'autres conteneurs dans le cluster.
14.2.7. Attribution d'un sélecteur de nœud approprié
La meilleure façon d'assigner un pod à des nœuds est d'utiliser le même sélecteur de nœuds que celui utilisé par le profil de performance, comme indiqué ici :
apiVersion: v1 kind: Pod metadata: name: example spec: # ... nodeSelector: node-role.kubernetes.io/worker-rt: ""
apiVersion: v1
kind: Pod
metadata:
name: example
spec:
# ...
nodeSelector:
node-role.kubernetes.io/worker-rt: ""
Pour plus d'informations, voir Placer des pods sur des nœuds spécifiques à l'aide de sélecteurs de nœuds.
14.2.8. Programmation d'une charge de travail sur un travailleur doté de capacités en temps réel
Utilisez des sélecteurs d'étiquettes qui correspondent aux nœuds attachés au pool de configuration de machines qui a été configuré pour une faible latence par l'opérateur de réglage des nœuds. Pour plus d'informations, voir Affectation de pods à des nœuds.
14.2.9. Réduire la consommation d'énergie en mettant les unités centrales hors ligne
Vous pouvez généralement anticiper les charges de travail des télécommunications. Lorsque toutes les ressources de l'unité centrale ne sont pas nécessaires, l'opérateur Node Tuning vous permet de mettre hors ligne les unités centrales inutilisées afin de réduire la consommation d'énergie en mettant à jour manuellement le profil de performance.
Pour mettre hors ligne les unités centrales inutilisées, vous devez effectuer les tâches suivantes :
Définissez les CPU hors ligne dans le profil de performance et enregistrez le contenu du fichier YAML :
Exemple de profil de performance avec des unités centrales hors ligne
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: additionalKernelArgs: - nmi_watchdog=0 - audit=0 - mce=off - processor.max_cstate=1 - intel_idle.max_cstate=0 - idle=poll cpu: isolated: "2-23,26-47" reserved: "0,1,24,25" offlined: “48-59” nodeSelector: node-role.kubernetes.io/worker-cnf: "" numa: topologyPolicy: single-numa-node realTimeKernel: enabled: true
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: additionalKernelArgs: - nmi_watchdog=0 - audit=0 - mce=off - processor.max_cstate=1 - intel_idle.max_cstate=0 - idle=poll cpu: isolated: "2-23,26-47" reserved: "0,1,24,25" offlined: “48-59”
1 nodeSelector: node-role.kubernetes.io/worker-cnf: "" numa: topologyPolicy: single-numa-node realTimeKernel: enabled: true
Copy to Clipboard Copied! - 1
- Facultatif. Vous pouvez répertorier les unités centrales dans le champ
offlined
pour mettre hors ligne les unités centrales spécifiées.
Appliquez le profil mis à jour en exécutant la commande suivante :
oc apply -f my-performance-profile.yaml
$ oc apply -f my-performance-profile.yaml
Copy to Clipboard Copied!
14.2.10. En option : Configurations d'économie d'énergie
Vous pouvez activer l'économie d'énergie pour un nœud dont les charges de travail à faible priorité sont colocalisées avec des charges de travail à haute priorité sans avoir d'impact sur la latence ou le débit des charges de travail à haute priorité. L'économie d'énergie est possible sans modifier les charges de travail elles-mêmes.
Cette fonctionnalité est prise en charge par les processeurs Intel Ice Lake et les générations suivantes. Les capacités du processeur peuvent avoir un impact sur la latence et le débit des charges de travail hautement prioritaires.
Lorsque vous configurez un nœud avec une configuration d'économie d'énergie, vous devez configurer les charges de travail hautement prioritaires avec une configuration de performance au niveau du pod, ce qui signifie que la configuration s'applique à tous les cœurs utilisés par le pod.
En désactivant les états P et les états C au niveau du pod, vous pouvez configurer les charges de travail hautement prioritaires pour obtenir les meilleures performances et la latence la plus faible.
Annotation | Description |
---|---|
annotations: cpu-c-states.crio.io: "disable" cpu-freq-governor.crio.io: "<governor>"
|
Permet d'obtenir les meilleures performances pour un pod en désactivant les états C et en spécifiant le type de gouverneur pour la mise à l'échelle du CPU. Le gouverneur |
Conditions préalables
- Vous avez activé les états C et les états P contrôlés par le système d'exploitation dans le BIOS
Procédure
Générer un
PerformanceProfile
avecper-pod-power-management
fixé àtrue
:podman run --entrypoint performance-profile-creator -v \ /must-gather:/must-gather:z registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.12 \ --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true \ --split-reserved-cpus-across-numa=false --topology-manager-policy=single-numa-node \ --must-gather-dir-path /must-gather -power-consumption-mode=low-latency \ --per-pod-power-management=true > my-performance-profile.yaml
$ podman run --entrypoint performance-profile-creator -v \ /must-gather:/must-gather:z registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.12 \ --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true \ --split-reserved-cpus-across-numa=false --topology-manager-policy=single-numa-node \ --must-gather-dir-path /must-gather -power-consumption-mode=low-latency \
1 --per-pod-power-management=true > my-performance-profile.yaml
Copy to Clipboard Copied! - 1
- L'adresse
power-consumption-mode
doit êtredefault
oulow-latency
lorsque l'adresseper-pod-power-management
esttrue
.
Exemple
PerformanceProfile
avecperPodPowerManagement
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: [.....] workloadHints: realTime: true highPowerConsumption: false perPodPowerManagement: true
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: [.....] workloadHints: realTime: true highPowerConsumption: false perPodPowerManagement: true
Copy to Clipboard Copied! Définir le gouverneur par défaut de
cpufreq
comme argument supplémentaire du noyau dans la ressource personnalisée (CR) dePerformanceProfile
:apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: ... additionalKernelArgs: - cpufreq.default_governor=schedutil
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: ... additionalKernelArgs: - cpufreq.default_governor=schedutil
1 Copy to Clipboard Copied! - 1
- Il est recommandé d'utiliser le régulateur
schedutil
, mais il est possible d'utiliser d'autres régulateurs tels que les régulateursondemand
oupowersave
.
Définissez la fréquence maximale de l'unité centrale sur le site
TunedPerformancePatch
CR :spec: profile: - data: | [sysfs] /sys/devices/system/cpu/intel_pstate/max_perf_pct = <x>
spec: profile: - data: | [sysfs] /sys/devices/system/cpu/intel_pstate/max_perf_pct = <x>
1 Copy to Clipboard Copied! - 1
- La valeur
max_perf_pct
contrôle la fréquence maximale que le pilotecpufreq
est autorisé à définir en tant que pourcentage de la fréquence maximale supportée par le processeur. Cette valeur s'applique à tous les processeurs. Vous pouvez vérifier la fréquence maximale supportée sur/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
. Comme point de départ, vous pouvez utiliser un pourcentage qui plafonne tous les CPU à la fréquenceAll Cores Turbo
. La fréquenceAll Cores Turbo
est la fréquence à laquelle tous les cœurs fonctionneront lorsqu'ils seront tous occupés.
Ajoutez les annotations souhaitées à vos pods de charge de travail hautement prioritaires. Les annotations remplacent les paramètres de
default
.Exemple d'annotation de charge de travail hautement prioritaire
apiVersion: v1 kind: Pod metadata: ... annotations: ... cpu-c-states.crio.io: "disable" cpu-freq-governor.crio.io: "<governor>" ... ... spec: ... runtimeClassName: performance-<profile_name> ...
apiVersion: v1 kind: Pod metadata: ... annotations: ... cpu-c-states.crio.io: "disable" cpu-freq-governor.crio.io: "<governor>" ... ... spec: ... runtimeClassName: performance-<profile_name> ...
Copy to Clipboard Copied! - Redémarrer les pods.
14.2.11. Gestion du traitement des interruptions de périphériques pour les unités centrales isolées à pods garantis
Le Node Tuning Operator peut gérer les CPU de l'hôte en les divisant en CPU réservés pour les tâches d'entretien du cluster et du système d'exploitation, y compris les conteneurs pod infra, et en CPU isolés pour les conteneurs d'application afin d'exécuter les charges de travail. Cela vous permet de définir les CPU pour les charges de travail à faible latence comme étant isolées.
Les interruptions de périphériques sont réparties entre toutes les unités centrales isolées et réservées afin d'éviter que les unités centrales ne soient surchargées, à l'exception des unités centrales pour lesquelles un module garanti est en cours d'exécution. Les CPU des pods garantis sont empêchés de traiter les interruptions de périphériques lorsque les annotations correspondantes sont définies pour le pod.
Dans le profil de performance, globallyDisableIrqLoadBalancing
est utilisé pour gérer le traitement ou non des interruptions de périphériques. Pour certaines charges de travail, les CPU réservées ne sont pas toujours suffisantes pour traiter les interruptions de périphériques, et pour cette raison, les interruptions de périphériques ne sont pas globalement désactivées sur les CPU isolées. Par défaut, Node Tuning Operator ne désactive pas les interruptions de périphériques sur les unités centrales isolées.
Pour obtenir une faible latence pour les charges de travail, certains pods (mais pas tous) exigent que les CPU sur lesquels ils s'exécutent ne traitent pas les interruptions de périphériques. Une annotation de pod, irq-load-balancing.crio.io
, est utilisée pour définir si les interruptions de périphériques sont traitées ou non. Lorsqu'il est configuré, CRI-O désactive les interruptions de périphérique tant que le module est en cours d'exécution.
14.2.11.1. Désactivation du quota CFS de l'unité centrale
Pour réduire l'étranglement du CPU pour les pods individuels garantis, créez une spécification de pod avec l'annotation cpu-quota.crio.io: "disable"
. Cette annotation désactive le quota CFS (completely fair scheduler) de l'unité centrale au moment de l'exécution du pod. La spécification de pod suivante contient cette annotation :
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: Pod
metadata:
annotations:
cpu-quota.crio.io: "disable"
spec:
runtimeClassName: performance-<profile_name>
...
Ne désactivez le quota CFS CPU que lorsque la politique statique du gestionnaire de CPU est activée et pour les pods avec QoS garantie qui utilisent des CPU entiers. Dans le cas contraire, la désactivation du quota de CPU CFS peut affecter les performances d'autres conteneurs dans le cluster.
14.2.11.2. Désactivation de la gestion des interruptions globales de périphériques dans Node Tuning Operator
Pour configurer Node Tuning Operator afin qu'il désactive les interruptions de périphérique globales pour l'ensemble de CPU isolées, définissez le champ globallyDisableIrqLoadBalancing
dans le profil de performance à true
. Lorsque true
, les annotations de pods conflictuelles sont ignorées. Avec false
, les charges d'IRQ sont équilibrées entre tous les processeurs.
Un extrait de profil de performance illustre ce paramètre :
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: manual spec: globallyDisableIrqLoadBalancing: true ...
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
name: manual
spec:
globallyDisableIrqLoadBalancing: true
...
14.2.11.3. Désactivation du traitement des interruptions pour les pods individuels
Pour désactiver le traitement des interruptions pour les pods individuels, assurez-vous que globallyDisableIrqLoadBalancing
est défini sur false
dans le profil de performance. Ensuite, dans la spécification du pod, définissez l'annotation du pod irq-load-balancing.crio.io
sur disable
. La spécification du pod suivante contient cette annotation :
apiVersion: performance.openshift.io/v2 kind: Pod metadata: annotations: irq-load-balancing.crio.io: "disable" spec: runtimeClassName: performance-<profile_name> ...
apiVersion: performance.openshift.io/v2
kind: Pod
metadata:
annotations:
irq-load-balancing.crio.io: "disable"
spec:
runtimeClassName: performance-<profile_name>
...
14.2.12. Mise à jour du profil de performance pour utiliser le traitement des interruptions de périphériques
Lorsque vous mettez à niveau la définition de ressource personnalisée (CRD) du profil de performance de l'opérateur Node Tuning de v1 ou v1alpha1 vers v2, globallyDisableIrqLoadBalancing
est défini sur true
pour les profils existants.
globallyDisableIrqLoadBalancing
permet de désactiver ou non l'équilibrage de la charge d'IRQ pour l'ensemble de CPU isolés. Lorsque l'option est définie sur true
, elle désactive l'équilibrage de la charge d'IRQ pour l'ensemble de CPU isolés. Le réglage de l'option sur false
permet d'équilibrer les IRQ sur tous les CPU.
14.2.12.1. Versions de l'API prises en charge
L'opérateur de réglage des nœuds prend en charge v2
, v1
, et v1alpha1
pour le champ apiVersion
du profil de performance. Les API v1 et v1alpha1 sont identiques. L'API v2 comprend un champ booléen facultatif globallyDisableIrqLoadBalancing
dont la valeur par défaut est false
.
14.2.12.1.1. Mise à jour de l'API Node Tuning Operator de v1alpha1 à v1
Lors de la mise à niveau de la version API de l'opérateur de réglage des nœuds de v1alpha1 à v1, les profils de performance de v1alpha1 sont convertis à la volée à l'aide d'une stratégie de conversion "None" et servis à l'opérateur de réglage des nœuds avec la version API v1.
14.2.12.1.2. Mise à jour de l'API de l'opérateur Node Tuning de v1alpha1 ou v1 à v2
Lors d'une mise à niveau à partir d'une ancienne version de l'API Node Tuning Operator, les profils de performance v1 et v1alpha1 existants sont convertis à l'aide d'un webhook de conversion qui injecte le champ globallyDisableIrqLoadBalancing
avec une valeur de true
.