Optimisation des performances

Si vous avez des exigences spécifiques en termes d'optimisation des performances, vous pouvez modifier les paramètres par défaut de certains composants de cluster dans Red Hat® OpenShift® on IBM Cloud®.

Si vous choisissez de modifier les paramètres par défaut, vous le faites à vos propres risques. Vous êtes responsable de l'exécution des tests sur les paramètres modifiés et de toute interruption potentielle qui serait provoquée par les paramètres modifiés dans votre environnement.

Au lieu d'ajuster les performances des nœuds de travail à l'aide MachineConfig des fichiers dans Red Hat OpenShift, vous pouvez modifier l'hôte à l'aide d'un daemonset fichier. Pour plus d'informations, consultez Modifier la Calico MTU ou Optimiser les performances pour les Red HatCoreOS nœuds de travail.

Paramètres de noeud worker par défaut

Par défaut, vos nœuds de travail sont équipés du système d'exploitation et du matériel de calcul correspondant au type de nœud de travail que vous avez choisi lors de la création du pool de nœuds de travail.

Personnalisation du système d'exploitation

Vous trouverez une liste des systèmes d'exploitation pris en charge par version de cluster dans les informations Red Hat OpenShift on IBM Cloud sur la version. Votre cluster ne peut pas combiner des systèmes d'exploitation ou utiliser des systèmes d'exploitation différents.

Pour optimiser vos noeuds worker, prenez en compte les informations suivantes :

Mises à jour de version et d'image : les mises à jour de noeud worker, par exemple les correctifs de sécurité apportés à l'image ou aux versions Red Hat OpenShift, vous sont fournies par IBM. Toutefois, c'est vous qui choisissez quand appliquer les mises à jour aux noeuds worker. Pour plus d'informations, voir Mise à jour des clusters, des noeuds worker et des composants de cluster.
Modifications temporaires : si vous vous connectez à un pod ou utilisez un autre processus pour modifier des paramètres de noeud worker, ces modifications sont temporaires. Les opérations de cycle de vie sur les noeuds worker, telles que la reprise automatique, le rechargement, la mise à jour ou le remplacement d'un noeud worker rétablissent les paramètres par défaut et annulent toute modification.
Modifications persistantes: pour que les modifications soient conservées tout au long du cycle de vie des nœuds de travail, créez un ensemble de démons utilisant un conteneur de type « init ». Pour plus d'informations, voir Modification des paramètres de noeud worker par défaut pour optimiser les performances.

Les modifications apportées au système d'exploitation ne sont pas prises en charge. Si vous modifiez les paramètres par défaut, il vous incombe de déboguer et résoudre les problèmes qui pourraient survenir.

Changements matériels

Pour changer le matériel de calcul, tel que l'unité centrale et la mémoire pour chaque noeud worker, vous pouvez au choix :

Créez un pool de noeuds worker. Les instructions varient en fonction du type d'infrastructure du cluster, qu'il s'agisse d'une infrastructure classique, d'un VPC ou d'un cluster « Satellite ». Pour plus d'informations, voir Ajout de noeuds worker à des clusters classiques ou Ajout de noeuds worker à des clusters de VPC.
Mettre à jour la version dans votre cluster en créant un pool de noeuds worker et en retirant le pool de noeuds worker précédent.

Modification des paramètres du noyau des nœuds de travail pour optimiser les performances

Les noeuds worker de cluster sont configurés pour un niveau de stabilité, d'optimisation et de performances qui doit répondre aux besoins de la plupart des charges de travail. En règle générale, il n'est pas recommandé de modifier les paramètres du noyau de votre noeud worker, car ces modifications peuvent créer des problèmes inhabituels et non intentionnels. Toutefois, si votre charge de travail a des exigences d'optimisation des performances très uniques qui nécessitent des modifications de vos paramètres de noyau, un daemonset Kubernetes personnalisé peut être appliqué pour modifier la configuration du noyau. Comprenez que ces modifications peuvent avoir des conséquences négatives importantes et que vous implémentez les modifications apportées à la configuration des paramètres de noyau à vos propres risques.

Si vous modifiez la configuration des paramètres de votre noyau, assurez-vous de documenter et de sauvegarder les modifications exactes que vous apportez. Si vous ouvrez un ticket de demande de service pour des problèmes liés au cluster, vous devez spécifier ces modifications. Ces modifications de configuration peuvent être responsables du problème et vous pouvez être invité à annuler les modifications dans le cadre de l'enquête sur le problème. Dans ce cas, vous êtes responsable de l'annulation des modifications de configuration du noyau que vous implémentez.

La modification des paramètres de noyau par défaut peut avoir des effets négatifs sur votre cluster. Effectuez ces modifications à vos propres risques.

Vous pouvez modifier les paramètres de noyau par défaut en appliquant un Kubernetes DaemonSet personnalisé avec un conteneur init à votre cluster. Cet objet modifie les paramètres de tous les noeuds worker existants et appliquent les paramètres à tous les nouveaux noeuds worker mis à disposition dans le cluster. Le conteneur « init » garantit que ces modifications soient effectuées avant que d'autres pods ne soient planifiés sur le nœud de travail. Aucun pod n'est affecté.

Vous devez disposer de l'Responsable IBM Cloud Rôle d'accès au service IAM pour tous les espaces de noms afin de pouvoir exécuter l'exemple « initContainer » (privilégié). Une fois que les conteneurs pour les déploiements sont initialisés, les privilèges sont supprimés.

Avant de commencer : accédez à votre cluster Red Hat OpenShift.

Sauvegardez l'ensemble de démons (DaemonSet) suivant dans un fichier nommé worker-node-kernel-settings.yaml. Dans la section spec.template.spec.initContainers, ajoutez les zones et les valeurs pour les paramètres sysctl que vous désirez optimiser. Cet exemple d'ensemble de démons modifie le nombre maximal par défaut de connexions autorisées dans l'environnement via le paramètre net.core.somaxconn et la plage de ports éphémères via le paramètre net.ipv4.ip_local_port_range.

En fonction des paramètres systctl que vous essayez de modifier, vous souhaiterez peut-être configurer le contexte de sécurité. Pour plus d'informations, consultez la documentation d' Red Hat OpenShift.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kernel-optimization
  namespace: kube-system
  labels:
    tier: management
    app: kernel-optimization
spec:
  selector:
    matchLabels:
      name: kernel-optimization
  template:
    metadata:
      labels:
        name: kernel-optimization
    spec:
      hostNetwork: true
      hostPID: true
      hostIPC: true
      initContainers:
        - command:
            - sh
            - -c
            - sysctl -w net.ipv4.tcp_syn_retries="5"; sysctl -w net.ipv4.tcp_fin_timeout="15";
          image: us.icr.io/armada-master/network-alpine:latest
          imagePullPolicy: Always
          name: sysctl
          resources: {}
          securityContext:
            privileged: true
            capabilities:
              add:
                - NET_ADMIN
          volumeMounts:
            - name: modifysys
              mountPath: /sys
      containers:
        - resources:
            requests:
              cpu: 0.01
          image: us.icr.io/armada-master/network-alpine:latest
          name: sleepforever
          command: ["/bin/sh", "-c"]
          args:
            - >
              while true; do
                sleep 100000;
              done
      volumes:
        - name: modifysys
          hostPath:
            path: /sys

Appliquez l'ensemble de démons à vos noeuds worker. Les modifications sont appliquées immédiatement.
```
oc apply -f worker-node-kernel-settings.yaml
```

Pour rétablir les valeurs par défaut des paramètres d' sysctl s de vos nœuds de travail, procédez comme suit.

Supprimez l'ensemble de démons. Les éléments initContainers qui appliquaient les paramètres personnalisés sont supprimés.
```
oc delete ds kernel-optimization
```
Réamorcez tous les noeuds worker dans le cluster. Les noeuds worker sont à nouveau en ligne dès que les valeurs par défaut sont appliquées.

Optimisation des paramètres `sysctl` de signal de présence du réseau

Si un pod a des connexions TCP de longue durée qui sont occasionnellement déconnectées lorsqu'elles sont inactives pendant un certain temps, il peut être utile de modifier les paramètres de keepalive de sysctl pour le pod.

Il n'existe actuellement aucun moyen de définir ces paramètres de signal de présence sysctl sur tous les pods par défaut dans un cluster. La meilleure façon de modifier les paramètres sur tous les pods consiste à utiliser un initContainer privilégié. Consultez l'exemple suivant pour savoir comment configurer un initContainer pour un déploiement dans un espace de nom test-ns.

Autorisez les initContainers privilégiés dans l'espace de nom test-ns:

oc adm policy add-scc-to-group privileged system:serviceaccounts:test-ns

Déployez l'exemple suivant: initContainer. N'oubliez pas de remplacer la section containers: par vos propres conteneurs d'application. initContainer définit ensuite les paramètres sysctl pour tous les conteneurs standard du pod car ils partagent tous le même espace de nom réseau.

kubectl apply -f - << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
	name: test-sysctl
	namespace: test-ns
	labels:
	run: test-sysctl
spec:
	replicas: 2
	selector:
	matchLabels:
		run: test-sysctl
	template:
	metadata:
		labels:
		run: test-sysctl
	spec:
		initContainers:
		- command:
		- sh
		- -c
		- sysctl -e -w net.ipv4.tcp_keepalive_time=40; sysctl -e -w net.ipv4.tcp_keepalive_intvl=15; sysctl -e -w net.ipv4.tcp_keepalive_probes=6;
		image: us.icr.io/armada-master/alpine:latest
		imagePullPolicy: IfNotPresent
		name: sysctl-init
		resources: {}
		securityContext:
			privileged: true
		containers:
		- name: test-sysctl
		image: us.icr.io/armada-master/alpine:latest
		command: ["sleep", "2592000"]
	EOF

Modification de l'unité de transmission maximale (MTU) pour les clusters utilisant des Calico

Vous pouvez augmenter ou réduire la taille de l'unité de transmission maximale (MTU) des nœuds de travail et du plug- Calico, afin de répondre aux exigences de débit réseau de votre environnement.

Tous les nœuds de travail VPC supportent jusqu'à 9000 MTU, et les nœuds de travail bare metal classiques supportent également jusqu'à 9000 MTU. Les serveurs virtuels classiques ne prennent en charge que le MTU standard de 1500. Par conséquent, si votre cluster comporte des nœuds de travail de serveurs virtuels classiques, n'augmentez ni le MTU du nœud de travail ni celui de Calico.

La modification des valeurs de l'unité de transmission maximale (MTU) peut avoir des résultats inattendus, en particulier dans les environnements de réseau complexes. Pour éviter de perturber votre flux de travail, il est fortement recommandé de tester ces modifications sur un cluster de développement avant d'apporter des changements à vos clusters de production.

Par défaut, le plug-in réseau Calico de votre cluster Red Hat OpenShift on IBM Cloud a un MTU de 1450 octets pour les clusters Satellite et de 1480 octets pour les clusters Satellite. Dans la plupart des cas, cette valeur par défaut du MTU de Calico est suffisante pour éviter les chutes de paquets et la fragmentation. Comme la plupart des hôtes utilisent une valeur MTU de 1500, ces valeurs par défaut fournissent aux clusters Satellite 50 octets supplémentaires pour les en-têtes VXLAN et aux clusters Satellite 20 octets supplémentaires pour les en-têtes IP utilisés dans certains trafics réseau entre clusters pods. Notez que tous les nœuds de travail du cluster doivent utiliser la même valeur MTU Calico.

Passez en revue les cas suivants pour lesquels vous devrez peut-être modifier la MTU Calico par défaut :

Si vous avez besoin d'améliorer le débit de votre réseau pod-to-pod et que vos nœuds de cluster sont capables d'utiliser un MTU hôte plus élevé, vous pouvez augmenter le MTU de l'hôte et celui de Calico. C'est ce qu'on appelle utiliser des "trames jumbo". Le MTU typique d'une trame jumbo est de 9000. Dans ce cas, vous pouvez définir l'interface du réseau privé de l'hôte sur une valeur MTU de 9000 et le MTU de Calico sur une valeur légèrement inférieure -- 8950 pour les clusters Satellite et 8980 pour les clusters Satellite. Notez que le matériel ou les ressources de certains fournisseurs de cloud, tels que les machines virtuelles Azure, peuvent ne pas prendre en charge les trames jumbo ou ne prendre en charge qu'une valeur MTU allant jusqu'à 4000.
Si une connexion VPN est configurée pour votre cluster, certaines connexions VPN nécessitent une MTU Calico plus petite que celle définie par défaut. Contactez le fournisseur de services VPN pour déterminer si une MTU Calico plus petite est requise.

Avant de commencer

Si vos nœuds de travail utilisent toujours la valeur MTU par défaut, augmentez d'abord la valeur MTU de vos nœuds de travail avant d'augmenter celle du plug-in « Calico ». Par exemple, vous pouvez appliquer le daemon set suivant pour définir la taille de la MTU de vos nœuds de travail à 9 000 octets. Notez que les noms d'interface utilisés dans la commande ip link varient en fonction du type de vos noeuds worker.

Exemple de commande pour les noeuds worker Bare Metal: ip link set dev bond0 mtu 9000;ip link set dev bond1 mtu 9000;
Exemple de commande Nœuds de travail VPC : ip link set dev ens3 mtu 9000;

Exécutez les commandes suivantes pour vous connecter à un nœud de travail du cluster et envoyer une commande ping d'un nœud à un autre. Comme le MTU de votre nœud n'est défini que sur 1500 ou 1480, cette tentative devrait échouer. Dans les étapes suivantes, vous pouvez exécuter à nouveau ces commandes pour vérifier que les modifications ont été effectuées avec succès.
1. Répertoriez les noeuds présents dans votre cluster. Enregistrez les noms et les adresses IP de deux nœuds sains.
```
    oc get nodes -o wide
    ```
1. Connectez-vous à l'un des nœuds. Indiquez le nom du nœud.


```sh {: pre}
    oc debug node/<NODE_NAME>
    ```



1. Exécutez la commande ping d'un nœud à l'autre. Spécifiez l'adresse IP du nœud que vous n'avez pas référencé dans l'étape précédente.
```sh {: pre}
    ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
    ```
```

Modifiez le MTU du nœud à l'aide de l'exemple suivant. Cette valeur MTU s'applique au trafic de nœud à nœud. Modifiez la ligne - ip link set dev ens3 mtu <MTU_VALUE> pour inclure votre valeur MTU (l'exemple utilise une valeur MTU de 9000). Notez que vous devrez peut-être aussi changer le nom de l'interface " ens3 si ens3 n'est pas approprié pour vos nœuds.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    app: set-host-mtu
  name: set-host-mtu
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: set-host-mtu
  template:
    metadata:
      labels:
        name: set-host-mtu
    spec:
      containers:
        - args:
            - |
              while true; do
                sleep 100000;
              done
          command:
            - /bin/sh
            - -c
          image: us.icr.io/armada-master/network-alpine:latest
          imagePullPolicy: IfNotPresent
          name: sleepforever
          resources:
            requests:
              cpu: 10m
      hostNetwork: true
      initContainers:
        - command:
            - sh
            - -c
            - ip link set dev ens3 mtu 9000
          image: us.icr.io/armada-master/network-alpine:latest
          imagePullPolicy: IfNotPresent
          name: set-host-mtu
          securityContext:
            capabilities:
              add:
                - NET_ADMIN
            privileged: true
          volumeMounts:
            - mountPath: /sys
              name: modifysys
      restartPolicy: Always
      terminationGracePeriodSeconds: 2
      tolerations:
        - operator: Exists
      volumes:
        - hostPath:
            path: /sys
            type: ""
          name: modifysys
  updateStrategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
    type: RollingUpdate

Appliquez le daemonset pour modifier la valeur du MTU du nœud.
```
  oc apply -f <file_name>
```
Exécutez à nouveau les commandes pour vous connecter à un nœud et faire un ping d'un hôte à l'autre, en utilisant une taille de paquet importante. Maintenant que vous avez augmenté la valeur du MTU du nœud, la commande 'ping devrait réussir.
```
oc debug node/<NODE_NAME>
```
```
ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
```
Prenez le temps de tester votre cluster avec la nouvelle valeur MTU du nœud. Avant de continuer à modifier la valeur MTU de Calico, il est recommandé de vérifier que vos applications fonctionnent toujours comme prévu.
Exécutez la commande pour mettre à jour les valeurs MTU de Calico afin que le trafic de pod à pod puisse également utiliser le MTU plus important. Pour les clusters Satellite Core OS, la valeur MTU de Calico doit être inférieure de 50 octets à la valeur MTU du nœud. Pour tous les autres clusters, la valeur MTU de Calico doit être inférieure de 20 octets. Par exemple, si vous avez spécifié 9000 pour le MTU du nœud, votre MTU Calico doit être de 8950 pour les clusters Satellite Core OS ou de 8980 pour tous les autres clusters.
```
oc patch installation.operator.tigera.io default --type='merge' -p '{"spec":{"calicoNetwork":{"mtu":<MTU_VALUE>}}}'
```
Vous pouvez également modifier la ressource directement en exécutant 'oc edit installation.operator.tigera.io default.
Appliquez ces modifications à tous vos nœuds en les redémarrant soigneusement. Assurez-vous d'avoir testé ce processus sur un cluster de développement avant de poursuivre cette étape, car ces changements pourraient perturber votre charge de travail. Pour redémarrer vos nœuds, il est recommandé de les boucler, de les drainer et de les redémarrer un par un.

Si vous effectuez ces étapes sur un cluster de production, vous devez utiliser la même procédure que pour la mise à jour ou le remplacement des nœuds de production. Il est fortement recommandé de tester l'ensemble du processus sur un cluster de test avant d'effectuer ces étapes sur un cluster de production.

Au cours du processus de redémarrage, certains pods utilisent le nouveau MTU plus grand et d'autres pods ont toujours le MTU original, plus petit. En général, ce scénario ne pose pas de problème car les deux parties négocient la taille maximale correcte des paquets. Cependant, si vous bloquez les paquets ICMP, la négociation risque de ne pas fonctionner et votre cluster risque de connaître des problèmes de connexion de pods jusqu'à ce que tous les redémarrages soient terminés. Il est essentiel que ce processus soit d'abord testé sur un groupe de développement.

Désactivation du plug-in de cartographie des ports dans Calico

Le plug-in portmap pour l'interface CNI (Container Network Interface) de Calico vous permet d'utiliser un port d'hôte (hostPort) pour exposer vos pods d'application sur un port spécifique sur le noeud worker. Pour éviter les problèmes de performances liés à iptables, retirez le plug-in de mappage de port de la configuration CNI Calico de votre cluster.

Lorsque vous disposez de nombreux services dans votre cluster, tels que plus de 500 services ou de nombreux ports sur des services, tels que plus de 50 ports par service pour 10 services ou plus, de nombreuses règles iptables sont générées pour les stratégies réseau Calico et Kubernetes pour ces services. L'utilisation d'un grand nombre de règles iptables peut entraîner des problèmes de performances pour le plug-in « port map » et pourrait empêcher les futures mises à jour des règles iptables ou provoquer le redémarrage du conteneur « calico-node » si aucun verrou n'est reçu pour effectuer les mises à jour des règles iptables dans un délai spécifié. Pour éviter ces problèmes de performances, vous pouvez désactiver le plug-in de mappage de port en le supprimant de la configuration CNI Calico de votre cluster.

Si vous devez utiliser hostPorts, ne désactivez pas le plug-in de mappe de port.

Editez la ressource default de l'installation Calico.
```
oc edit installation default -n calico-system
```

Dans la section spec.calicoNetwork, remplacez la valeur de hostPorts par Disabled.

...
spec:
  calicoNetwork:
    hostPorts: Disabled
    ipPools:
      - cidr: 172.30.0.0/16
        encapsulation: IPIPCrossSubnet
        natOutgoing: Enabled
        nodeSelector: all()
    mtu: 1480
    nodeAddressAutodetectionV4:
      interface: (^bond0$|^eth0$|^ens6$|^ens3$)
  kubernetesProvider: OpenShift
  registry: us.icr.io/armada-master/
  variant: Calico
status:
  variant: Calico

Sauvegardez et fermez le fichier. Vos modifications sont appliquées automatiquement.

Optimisation des performances

Optimisation des performances

Paramètres de noeud worker par défaut

Personnalisation du système d'exploitation

Changements matériels

Modification des paramètres du noyau des nœuds de travail pour optimiser les performances

Optimisation des paramètres sysctl de signal de présence du réseau

Modification de l'unité de transmission maximale (MTU) pour les clusters utilisant des Calico

Désactivation du plug-in de cartographie des ports dans Calico

Optimisation des paramètres `sysctl` de signal de présence du réseau