Paramètres de noeud worker par défaut

Par défaut, vos nœuds de travail disposent 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.

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 du 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 : Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

1. 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.

   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
   

2. Appliquez l'ensemble de démons à vos noeuds worker. Les modifications sont appliquées immédiatement.

   kubectl apply -f worker-node-kernel-settings.yaml
   

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

1. Supprimez l'ensemble de démons. Les éléments initContainers qui appliquaient les paramètres personnalisés sont supprimés.

   kubectl delete ds kernel-optimization
   

2. 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 performances de pod

Si vous avez des exigences spécifiques en termes de charges de travail pour les performances, vous pouvez modifier les paramètres par défaut sysctl du noyau Linux dans les espaces de noms de réseau de pods.

Pour optimiser les paramètres du noyau pour les pods d'application, vous pouvez insérer un patch initContainer dans le fichier YAML pod/ds/rs/deployment de chaque déploiement. L'élément initContainer est ajouté à chaque déploiement d'application figurant dans l'espace de noms du réseau de pods dont vous souhaitez optimiser les performances.

Avant de commencer, assurez-vous de disposer du rôle d’accès au service IAM Manager IBM Cloud pour tous les espaces de noms afin de pouvoir 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.

1. Sauvegardez le correctif initContainer suivant dans un fichier nommé pod-patch.yaml et ajoutez les zones et les valeurs pour les paramètres sysctl que vous désirez optimiser. Cet exemple d'élément initContainer 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.

   spec:
     template:
       spec:
         initContainers:
           - command:
               - sh
               - -c
               - sysctl -e -w net.core.somaxconn=32768;  sysctl -e -w net.ipv4.ip_local_port_range="1025 65535";
             image: alpine:3.6
             imagePullPolicy: IfNotPresent
             name: sysctl
             resources: {}
             securityContext:
               privileged: true
   

2. Appliquez le correctif à chacun de vos déploiements.

   kubectl patch deployment <deployment_name> --patch pod-patch.yaml
   

3. Si vous avez modifié la valeur net.core.somaxconn dans les paramètres du noyau, la plupart des applications peuvent utiliser automatiquement la valeur mise à jour. En revanche, certaines applications pourront nécessiter la modification manuelle de la valeur correspondante dans le code de votre application pour qu'elle corresponde à la valeur du noyau. Par exemple, si vous optimisez les performances d'un pod dans lequel s'exécute une application NGINX, vous devez modifier la valeur de la zone backlog dans le code d'application NGINX pour qu'elle corresponde. Pour plus d'informations, consultez cet article du blog NGINX.

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.

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

Ajustement des ressources du fournisseur de métriques du cluster

Votre cluster dispose d'un service de mesures fourni par le déploiement metrics-server dans l'espace de nom kube-system. Les demandes de ressources metrics-server sont basées sur le nombre de nœuds du cluster et sont optimisées pour les clusters avec 30 pods ou moins par nœud worker. Le service de mesure correspond aux limites de la mémoire et d'unité centrale des demandes de ressources.

Les conteneurs metrics-service peuvent être "hors de la mémoire arrêtée" si les demandes de mémoire sont trop faibles. Ils peuvent répondre très lentement ou échouer aux tests de disponibilité et de bon fonctionnement, en raison d'une limitation du processeur si les requêtes adressées au processeur sont trop faibles.

L'utilisation de la mémoire est fonction du nombre de pods dans le cluster. L'utilisation de l'UC est déterminée par le nombre de demandes de métriques (HPAs, kubectl top nodes / pods, etc.) et par les demandes de reconnaissance d'API. metrics-server fournit une API Kubernetes, de sorte que les clients, tels que kubectl qui utilisent la reconnaissance d'API, augmente légèrement la charge sur metrics-server même s'ils n'utilisent pas de mesures.

Les symptômes suivants peuvent indiquer la nécessité d'ajuster les ressources metrics-server :

• metrics-server redémarre fréquemment.

• La suppression d'un espace de nom a pour conséquence de bloquer l'espace de noms dans l'état Terminating, et kubectl describe namespace inclut une condition signalant une erreur de découverte de l'API de mesure.

• kubectl top pods, kubectl top nodes, d'autres commandes kubectl ou les applications qui utilisent l'API Kubernetes pour consigner les erreurs Kubernetes telles que :

The server is currently unable to handle the request (get pods.metrics.k8s.io)

Discovery failed for some groups, 1 failing: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request

• HorizontalPodAutoscalers (HPA) ne mettent pas à l'échelle les déploiements.

• L'exécution de kubectl get apiservices v1beta1.metrics.k8s.io génère un statut tel que :

NAME                     SERVICE                      AVAILABLE                      AGE
v1beta1.metrics.k8s.io   kube-system/metrics-server   False (FailedDiscoveryCheck)   139d

cpuRequest = baseCPU + cpuPerNode * number_of_nodes
memoryRequest = baseMemory + memoryPerNode * number_of_nodes

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
    kubernetes.io/cluster-service: "true"
  name: metrics-server-config
  namespace: kube-system
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
    kubernetes.io/cluster-service: "true"
  name: metrics-server-config
  namespace: kube-system
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration
    baseCPU: 200m
    cpuPerNode: 1m
    baseMemory: 40Mi
    memoryPerNode: 6Mi

baseCPU: 200m
cpuPerNode: 1m
baseMemory: 40Mi
memoryPerNode: 6Mi

kubectl edit cm metrics-server-config -n kube-system

kubectl delete cm metrics-server-config -n kube-system

kubectl get pod -n kube-system -l k8s-app=metrics-server
NAME                             READY   STATUS    RESTARTS   AGE
metrics-server-9fb4947d6-s6sgl   3/3     Running   0          2d4h
kubectl describe pod -n kube-system metrics-server-9fb4947d6-s6sgl

Containers:
  metrics-server:
    Container ID:  containerd://fe3d07c9a2541242d36da8097de3896f740c1363f6d2bfd01b8d96a641192b1b
    Image:         us.icr.io/armada-master/metrics-server:v0.4.4
    Image ID:      us.icr.io/armada-master/metrics-server@sha256:c2c63900d0e080c2413b5f35c5a59b5ed3b809099355728cf47527aa3f35477c
    Port:          4443/TCP
    Host Port:     0/TCP
    Command:
      /metrics-server
      --metric-resolution=45s
      --secure-port=4443
      --tls-cert-file=/etc/metrics-server-certs/tls.crt
      --tls-private-key-file=/etc/metrics-server-certs/tls.key
    State:          Running
      Started:      Fri, 10 Sep 2021 17:31:39 +0000
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Fri, 10 Sep 2021 05:59:51 +0000
      Finished:     Fri, 10 Sep 2021 17:31:37 +0000
    Ready:          True
    Restart Count:  36

Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137

Last State:     Terminated
  Reason: Error
  Exit Code: 137

Events:
Warning Unhealthy 46m (x5 over 80m) kubelet Liveness probe failed: Get "https://198.18.68.236:4443/livez": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
Warning Unhealthy 26m (x65 over 89m) kubelet Liveness probe failed: Get "https://198.18.68.236:4443/livez": net/http: TLS handshake timeout
Warning Unhealthy 21m (x10 over 76m) kubelet Readiness probe failed: Get "https://198.18.68.236:4443/readyz": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
Warning Unhealthy 115s (x93 over 90m) kubelet Readiness probe failed: Get "https://198.18.68.236:4443/readyz": net/http: TLS handshake timeout

Activation de la fonction HugePages

Infrastructure classique Cloud privé virtuel

Vous pouvez activer KubernetesHugePages planification dans les clusters exécutant Kubernetes version 1.19 ou ultérieure. La seule taille de page prise en charge est de 2 Mo par page, qui est la taille par défaut de la ressource FeatureGate Kubernetes.

La planification de la fonction HugePages est une fonction bêta dans IBM Cloud Kubernetes Service et est susceptible d'être modifiée.

Par défaut, l'unité centrale de vos noeuds worker alloue la mémoire RAM en blocs, ou pages, de 4 Ko. Lorsque votre application requiert davantage de mémoire RAM, le système doit continuer à rechercher d'autres pages, ce qui peut ralentir le traitement. La fonction HugePages vous permet d'augmenter la taille de page et de la faire passer à 2 Mo afin d'accroître les performances de vos applications à forte consommation de mémoire RAM, telles que des bases de données pour l'intelligence artificielle (IA), Internet of Things (IoT) ou les charges de travail d'apprentissage automatique. Pour plus d'informations sur les huge pages, consultez la documentation du noyau Linux.

La configuration de la fonction HugePages est conservée même lorsque vous réamorcez le noeud worker. Cependant, la configuration des huge pages ne persiste pas lors des autres opérations du cycle de vie d'un nœud de travail. Vous devez répéter les étapes d'activation chaque fois que vous mettez à jour, rechargez, remplacez ou ajoutez des noeuds worker.

• Rôle d'accès à la plateforme Opérateur et rôle d'accès au service Responsable pour le cluster dans IBM Cloud IAM

Avant de commencer : Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

1. Créez un fichier de configuration hugepages-ds.yaml pour activer la fonction HugePages. L'exemple de fichier YAML suivant utilise un ensemble de démons pour exécuter le pod sur chaque noeud worker de votre cluster. Vous pouvez définir l'allocation des ressources HugePages qui sont disponibles sur le noeud worker à l'aide du paramètre vm.nr_hugepages. Cet exemple alloue 512 pages de 2 Mo chacune, pour un total de 1 Go de mémoire RAM alloué exclusivement pour les ressources HugePages.

   Vous souhaitez activer la fonction HugePages pour certains noeuds worker uniquement, par exemple, un pool de noeuds worker que vous utilisez pour les applications à forte consommation de mémoire RAM ? Attribuez des étiquettes et des contraintes à votre pool de nœuds de travail, puis ajoutez des règles d'affinité au daemon set afin que les pods ne soient déployés que sur les nœuds de travail du pool que vous spécifiez.

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: hugepages-enablement
     namespace: kube-system
     labels:
       tier: management
       app: hugepages-enablement
   spec:
     selector:
       matchLabels:
         name: hugepages-enablement
     template:
       metadata:
         labels:
           name: hugepages-enablement
       spec:
         hostPID: true
         initContainers:
           - command:
               - sh
               - -c
               # Customize allocated Hugepages by providing the value
               - "echo vm.nr_hugepages=512 > /etc/sysctl.d/90-hugepages.conf"
             image: alpine:3.6
             imagePullPolicy: IfNotPresent
             name: sysctl
             resources: {}
             securityContext:
               privileged: true
             volumeMounts:
               - name: modify-sysctld
                 mountPath: /etc/sysctl.d
         containers:
           - resources:
               requests:
                 cpu: 0.01
             image: alpine:3.6
             # once the init container completes, keep the pod running for worker node changes
             name: sleepforever
             command: ["/bin/sh", "-c"]
             args:
               - >
                 while true; do
                     sleep 100000;
                 done
         volumes:
           - name: modify-sysctld
             hostPath:
               path: /etc/sysctl.d
   

2. Appliquez le fichier que vous avez créé précédemment.

   kubectl apply -f hugepages-ds.yaml
   

3. Vérifiez que les pods sont à l'état En cours d'exécution.

   kubectl get pods
   

4. Redémarrez le kubelet qui s'exécute sur chaque noeud worker en réamorçant les noeuds worker. Ne rechargez pas le noeud worker pour redémarrer le kubelet. Si le noeud worker est rechargé avant la reprise du kubelet lors de l'activation de la fonction HugePages, cette activation échoue.

   1. Répertoriez les noeuds worker présents dans votre cluster.

       ibmcloud ks worker ls -c CLUSTER_NAME_OR_ID
       ```
   2. Réamorcer les noeuds worker. Vous pouvez redémarrer plusieurs nœuds de travail en spécifiant plusieurs `-w` options, mais veillez à laisser suffisamment de nœuds de travail en fonctionnement simultanément pour vos applications afin d’éviter toute interruption de service.
   ```sh {: pre}
       ibmcloud ks worker reboot -c CLUSTER_NAME_OR_ID -w WORKER1_ID -w WORKER2_ID
       ```
   

5. Créez un pod de test hugepages-test.yaml qui monte des ressources HugePages en tant que volume et utilise des limites et des demandes de ressource pour définir la quantité de ressources HugePages utilisées par le pod. Remarque : si vous avez utilisé des libellés, des annotations taint et des règles d'affinité pour activer la fonction HugePages uniquement sur certains noeuds worker, ajoutez ces mêmes règles dans votre pod de test.

   apiVersion: v1
   kind: Pod
   metadata:
     name: hugepages-example
   spec:
     containers:
       - name: hugepages-example
         image: fedora:34
         command:
           - sleep
           - inf
         volumeMounts:
           - mountPath: /hugepages-2Mi
             name: hugepage-2mi
         resources:
           limits:
             hugepages-2Mi: 100Mi
             memory: 100Mi
           requests:
             memory: 100Mi
     volumes:
       - name: hugepage-2mi
         emptyDir:
           medium: HugePages-2Mi
   

6. Appliquez le fichier Pod que vous avez créé précédemment.

   kubectl apply -f hugepages-pod.yaml
   

7. Vérifiez que votre pod utilise les ressources HugePages.

   1. Vérifiez que votre pod est En cours d'exécution. Le pod ne s'exécute pas s'il n'existe aucun noeud worker avec des ressources HugePages.

       kubectl get pods
       ```
   2. Connectez-vous au pod.
   ```sh {: pre}
       kubectl exec -it <pod> /bin/sh
       ```
   3. Vérifiez que votre pod peut visualiser les tailles des ressources HugePages.
   ```sh {: pre}
       ls /sys/kernel/mm/hugepages
       ```
       Exemple de sortie
       ```sh {: screen}
       hugepages-1048576kB  hugepages-2048kB
       ```
   

8. Facultatif : retirez l'ensemble de démons d'activation. N'oubliez pas que vous devez recréer l'ensemble de démons si vous devez mettre à jour, recharger, remplacer ou ajouter ultérieurement des noeuds worker avec des ressources HugePages.

   kubectl -n kube-system delete daemonset hugepages-enablement
   

9. Répétez ces étapes chaque fois que vous mettez à jour, rechargez, remplacez ou ajoutez des noeuds worker.

Pour identifier et résoudre les incidents liés aux noeuds worker avec des ressources HugePages, vous pouvez uniquement réamorcer le noeud worker. La configuration de la fonction HugePages n'est pas conservée pour les autres opérations de cycle de vie des noeuds worker, telles que la mise à jour, le rechargement, le replacement ou l'ajout de noeuds worker. Pour retirer la configuration de la fonction HugePages de votre cluster, vous pouvez mettre à jour, recharger ou remplacer tous les noeuds worker.

Modification de l'unité de transmission maximale (MTU) pour les clusters qui utilisent Calico

Vous pouvez augmenter ou réduire la taille de l'unité de transmission maximale (MTU) des nœuds de travail et du plug-in 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 IBM Cloud Kubernetes Service 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 à la fois le MTU hôte et le MTU 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 modifier la taille de la trame (MTU) de vos nœuds de travail et la porter à 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;

1. 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.

       kubectl get nodes -o wide
       ```
   1. Connectez-vous à l'un des nœuds. Indiquez le nom du nœud.
   
   
   
   ```sh {: pre}
       kubectl debug --image=us.icr.io/armada-master/network-alpine -it node/<NODE_NAME> -- sh
       ```
   
   
   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>
       ```
   

2. 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
   

3. Appliquez le daemonset pour modifier la valeur MTU du nœud.

     kubectl apply -f <file_name>
   

4. 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.

   kubectl debug --image=us.icr.io/armada-master/network-alpine -it node/<NODE_NAME> -- sh
   

   ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
   

5. 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.

6. 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.

   kubectl patch installation.operator.tigera.io default --type='merge' -p '{"spec":{"calicoNetwork":{"mtu":<MTU_VALUE>}}}'
   

   Vous pouvez également modifier la ressource directement en exécutant 'kubectl edit installation.operator.tigera.io default.

7. 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.

Pendant le 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 de mappage de ports, 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.

1. Editez la ressource default de l'installation Calico.

   kubectl edit installation default -n calico-system
   

2. 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
   

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