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'optimiser les performances des noeuds worker avec des fichiers MachineConfig dans Red Hat OpenShift, vous pouvez modifier l'hôte avec un fichier daemonset. Pour plus d'informations, voir Modification de la MTU Calico ou Optimisation des performances pour les noeuds worker Red Hat CoreOS.

Paramètres de noeud worker par défaut

Par défaut, vos nœuds de travail sont dotés du système d'exploitation et du matériel de calcul de la variante de nœud de travail que vous avez choisie lors de la création du pool de travailleurs.

Personnalisation du système d'exploitation

Vous trouverez la liste des systèmes d'exploitation pris en charge par version de cluster dans les informations de version deRed Hat OpenShift on IBM Cloud. 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 persistent pendant les opérations de cycle de vie des nœuds de travail, créez un ensemble de démons qui utilise un conteneur 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, tel que classique, VPC ou 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 du nœud 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 de vos paramètres de noyau, veillez à documenter et à sauvegarder les modifications exactes que vous avez apportées. 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 s'assure que ces modifications interviennent avant que d'autres pods ne soient programmés sur le nœud de travail. Aucun pod n'est affecté.

Vous devez avoir le rôle d'accès au service IAM Manager IBM Cloud pour tous les espaces de noms afin d'exécuter l'exemple privilégié initContainer. 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, voir la documentationRed 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 de vos nœuds de travail sysctl, 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 possède des connexions TCP à exécution longue qui sont parfois déconnectées lorsqu'elles sont inactives pendant un certain temps, il peut être utile de modifier les paramètres de signal de présence 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 :

```sh {: pre}
oc adm policy add-scc-to-groupl 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.

```sh {: pre}
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) Calico

Augmentez ou diminuez l'unité de transmission maximale (MTU) du plug-in Calico en fonction des exigences de capacité de traitement réseau de votre environnement.

Tous les nœuds de travail VPC prennent en charge les trames jumbo, mais l'infrastructure classique ne prend en charge les trames jumbo que sur les travailleurs en métal nu.

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 la valeur MTU du plug-in Calico. Par exemple, vous pouvez appliquer le jeu de démons suivant pour modifier le MTU de vos nœuds de travail en 9000 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 de noeuds worker VPC Génération 2: 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
```
2. Connectez-vous à l'un des nœuds. Indiquez le nom du nœud.
```
oc debug node/<NODE_NAME>
```
3. 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.
```
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 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 modifications 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 mappage de port

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 de nombreuses règles iptables peut entraîner des problèmes de performance pour le plug-in de cartographie des ports et peut empêcher les mises à jour futures des règles iptables ou provoquer le redémarrage du conteneur calico-node lorsqu'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: registry.ng.bluemix.net/armada-master/
  variant: Calico
status:
  variant: Calico

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