Impostazioni del nodo di lavoro predefinito

Per impostazione predefinita, i nodi worker hanno il sistema operativo e l'hardware di calcolo del tipo di nodo worker scelto al momento della creazione del pool worker.

Modifica delle impostazioni del kernel del nodo di lavoro per ottimizzare le prestazioni

I nodi di lavoro del cluster sono configurati per un livello di stabilità, ottimizzazione e prestazioni che si prevede soddisfi le esigenze della maggior parte dei carichi di lavoro. Di solito, non è consigliabile modificare le impostazioni del kernel del proprio nodo di lavoro, poiché tali modifiche possono creare problemi insoliti e indesiderati. Tuttavia, se il tuo carico di lavoro ha requisiti di ottimizzazione delle prestazioni altamente univoci che richiedono modifiche alle impostazioni del kernel, è possibile applicare un set di daemon Kubernetes personalizzato per modificare la configurazione del kernel. Comprendere che queste modifiche possono avere conseguenze negative significative e che è possibile implementare modifiche alla configurazione delle impostazioni del kernel a proprio rischio.

Se si modifica la configurazione delle impostazioni del kernel, assicurarsi di documentare e salvare le modifiche esatte apportate. Se si apre un ticket di supporto per eventuali problemi relativi al cluster, è necessario specificare queste modifiche. Queste modifiche di configurazione potrebbero essere responsabili del problema e potrebbe essere richiesto di ripristinare le modifiche come parte dell'indagine del problema. In questo caso, l'utente è responsabile del ripristino delle modifiche di configurazione del kernel implementate.

La modifica delle impostazioni kernel predefinite può avere effetti negativi sul cluster. Apporta queste modifiche a tuo rischio e pericolo.

Puoi modificare le impostazioni kernel predefinite applicando un Kubernetes DaemonSet personalizzato con un Contenitore init al tuo cluster. Il daemon set modifica le impostazioni di tutti i nodi di lavoro esistenti e le applica a qualsiasi nuovo nodo di lavoro che venga creato nel cluster. Il contenitore init garantisce che queste modifiche si verifichino prima che altri pod siano pianificati nel nodo di lavoro. Nessun pod è interessato.

Per eseguire l'esempio " initContainer" con privilegi, è necessario disporre del ruolo di accesso al servizio IAM "Manager IBM Cloud " per tutti gli spazi dei nomi. Dopo che i contenitori per le distribuzioni sono stati inizializzati, i privilegi vengono eliminati.

Prima di iniziare: Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

1. Salva la seguente serie di daemon in un file denominato worker-node-kernel-settings.yaml. Nella sezione spec.template.spec.initContainers, aggiungi i campi e i valori per i parametri sysctl che vuoi ottimizzare. Questa serie di daemon di esempio modifica il numero massimo predefinito di connessioni consentite nell'ambiente tramite l'impostazione net.core.somaxconn e l'intervallo di porte temporanee tramite l'impostazione 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. Applica la serie di daemon ai tuoi nodi di lavoro. Le modifiche vengono applicate immediatamente.

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

Per ripristinare i valori predefiniti dei parametri " sysctl " dei nodi di lavoro, segui questi passaggi.

1. Elimina la serie di daemon. Gli initContainers che applicavano le impostazioni personalizzate vengono rimossi.

   kubectl delete ds kernel-optimization
   

2. Riavvia tutti i nodi di lavoro nel cluster. I nodi di lavoro tornano online con i valori predefiniti applicati.

Ottimizzazione delle prestazioni dei pod

Se hai richieste di carico di lavoro specifiche per le prestazioni, puoi modificare le impostazioni predefinite per i parametri sysctl del kernel Linux sugli spazi dei nomi della rete di pod.

Per ottimizzare le impostazioni del kernel per i pod delle app, è possibile inserire una initContainer patch nel file YAML di pod/ds/rs/deployment per ogni distribuzione. L'initContainer viene aggiunto a ciascuna distribuzione dell'applicazione che si trova nello spazio dei nomi della rete di pod per cui vuoi ottimizzare le prestazioni.

Prima di iniziare, assicurati di disporre del ruolo di accesso al servizio IAM "Manager IBM Cloud " per tutti gli spazi dei nomi, al fine di poter eseguire l'esempio " initContainer" con privilegi. Dopo che i contenitori per le distribuzioni sono stati inizializzati, i privilegi vengono eliminati.

1. Salva la seguente patch initContainer in un file denominato pod-patch.yaml e aggiungi i campi e i valori per i parametri sysctl che vuoi ottimizzare. Questo initContainer di esempio modifica il numero massimo predefinito di connessioni consentite nell'ambiente tramite l'impostazione net.core.somaxconn e l'intervallo di porte temporanee tramite l'impostazione 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. Applica la patch a ciascuna delle tue distribuzioni.

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

3. Se hai modificato il valore net.core.somaxconn nelle impostazioni del kernel, la maggior parte delle applicazioni può utilizzare automaticamente il valore aggiornato. Tuttavia, alcune applicazioni potrebbero richiedere che tu modifichi manualmente il valore corrispondente nel codice dell'applicazione in modo che corrisponda al valore del kernel. Ad esempio, se stai ottimizzando le prestazioni di un pod su cui viene eseguita un'applicazione NGINX, devi modificare il valore del campo backlog nel codice dell'applicazione NGINX in modo che corrisponda. Per ulteriori informazioni, consulta questo post sul blog “ NGINX ”.

Ottimizzazione delle impostazioni di rete keepalive sysctl

Se un pod ha connessioni TCP di lunga durata che vengono occasionalmente scollegate quando sono inattive per un certo periodo di tempo, potrebbe essere utile modificare le impostazioni di keepalive di sysctl per il pod.

Attualmente non esiste un modo per impostare queste sysctl impostazioni keepalive su tutti i pod per impostazione predefinita in un cluster. Il modo migliore per modificare le impostazioni su tutti i pod è utilizzare un initContainer privilegiato. Esamina il seguente esempio di come configurare un initContainer per una distribuzione in uno spazio dei nomi test-ns.

Distribuire il seguente esempio initContainer. Ricordati di modificare la sezione containers: nei tuoi contenitori dell'applicazione. Il initContainer quindi imposta le impostazioni sysctl per tutti i contenitori regolari nel pod perché condividono tutti lo stesso spazio dei nomi di rete.

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

Regolazione delle risorse del provider di metriche del cluster

Il tuo cluster ha un servizio di metrica fornito dalla distribuzione metrics-server nello spazio dei nomi kube-system. Le richieste di risorse metrics-server si basano sul numero di nodi nel cluster e sono ottimizzate per i cluster con 30 o meno pod per nodo di lavoro. Il servizio di metrica corrisponde ai limiti di memoria e CPU delle richieste di risorse.

I contenitori del servizio metriche possono essere "esauriti" se le richieste di memoria sono troppo basse. È possibile che rispondano molto lentamente o che non riescano a eseguire le analisi di disponibilità e di attività, a causa della limitazione della CPU se le richieste di CPU sono troppo basse.

L'utilizzo della memoria è determinato dal numero di pod nel cluster. L'utilizzo della CPU è determinato dal numero di richieste per le metriche (HPA, kubectl top nodes / pods e così via) e dalle richieste di rilevamento API. metrics-server fornisce un'API Kubernetes, in modo che client come kubectl che utilizzano il rilevamento API effettuino un certo carico su metrics-server anche se non utilizzano le metriche.

I seguenti sintomi potrebbero indicare la necessità di regolare le risorse metrics-server:

• Il sito metrics-server si riavvia frequentemente.

• L'eliminazione di uno spazio dei nomi provoca il blocco dello spazio dei nomi in uno stato Terminating e kubectl describe namespace include una condizione che segnala un errore di rilevamento dell'API delle metriche.

• kubectl top pods, kubectl top nodes, altri comandi di kubectl o applicazioni che utilizzano le API Kubernetes per registrare gli errori di Kubernetes, come ad esempio:

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 ) non scalano le distribuzioni.

• Eseguendo kubectl get apiservices v1beta1.metrics.k8s.io si ottiene uno stato come:

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

Abilitazione di pagine di grandi dimensioni

Infrastruttura classica Nuvola privata virtuale

È possibile abilitare la pianificazione Kubernetes HugePages nei cluster che eseguono Kubernetes versione 1.19 o successiva. L'unica dimensione di pagina supportata è 2 MB per pagina, che è la dimensione predefinita del gate della funzione Kubernetes.

La programmazione di pagine enormi è una funzione beta di IBM Cloud Kubernetes Service ed è soggetta a modifiche.

Per impostazione predefinita, la CPU dei tuoi nodi di lavoro assegna la RAM in blocchi o pagine di 4 KB. Quando la tua app richiede più RAM, il sistema deve continuare a cercare più pagine, il che può rallentare l'elaborazione. Con pagine enormi, puoi aumentare la dimensione della pagina a 2 MB per aumentare le prestazioni per le tue applicazioni ad alta intensità di RAM come i database per l'intelligenza artificiale (AI), l'internet delle cose (IoT) o i carichi di lavoro di machine learning. Per ulteriori informazioni sulle pagine di dimensioni notevoli, consultare la documentazione del kernel di Linux.

Puoi riavviare il nodo di lavoro e la configurazione delle pagine di notevoli dimensioni persiste. Tuttavia, la configurazione delle pagine enormi non persiste in nessun'altra operazione del ciclo di vita del nodo worker. Devi ripetere i passi di abilitazione ogni volta che aggiorni, ricarichi, sostituisci o aggiungi i nodi di lavoro.

• Ruolo di accesso della piattaforma Operatore e ruolo di accesso del servizio Gestore per il cluster in IAM IBM Cloud

Prima di iniziare: Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

1. Creare un file di configurazione hugepages-ds.yaml per abilitare le pagine di grandi dimensioni. Il seguente YAML di esempio usa una serie di daemon per eseguire il pod su ogni nodo di lavoro nel tuo cluster. Puoi impostare l'assegnazione di pagine di dimensioni notevoli disponibili nel nodo di lavoro utilizzando il parametro vm.nr_hugepages. Questo esempio assegna 512 pagine a 2 MB per pagina, per 1 GB di RAM totale assegnata esclusivamente per le pagine di grandi dimensioni.

   Si desidera abilitare le pagine di grandi dimensioni solo per alcuni nodi di lavoro, come ad esempio un pool di nodi di lavoro che si utilizza per le applicazioni ad uso intensivo di RAM? Label e taint il pool di nodi di lavoro, quindi aggiungi le regole di affinità alla serie di daemon in modo che i pod vengano distribuiti solo ai nodi di lavoro nel pool di nodi di lavoro che specifichi.

   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. Applica il file che hai creato in precedenza.

   kubectl apply -f hugepages-ds.yaml
   

3. Verificare che i pod siano in esecuzione.

   kubectl get pods
   

4. Riavviare il kubelet che viene eseguito su ciascun nodo di lavoro riavviando i nodi di lavoro. Non ricaricare il nodo di lavoro per riavviare kubelet. Ricaricando il nodo di lavoro prima che il kubelet si rilevi sull'abilitazione delle pagine di grandi dimensioni, l'abilitazione non riesce.

   1. Elenca i nodi di lavoro nel tuo cluster.

       ibmcloud ks worker ls -c CLUSTER_NAME_OR_ID
       ```
   2. Riavviare i nodi di lavoro. Puoi riavviare più nodi di lavoro includendo più opzioni `-w` ma assicurati di lasciare abbastanza nodi di lavoro in esecuzione contemporaneamente per le tue applicazioni per evitare un'interruzione.
   ```sh {: pre}
       ibmcloud ks worker reboot -c CLUSTER_NAME_OR_ID -w WORKER1_ID -w WORKER2_ID
       ```
   

5. Crea un pod di test hugepages-test.yaml che monta le pagine di notevoli dimensioni come un volume e utilizza i limiti per le risorse e le richieste per impostare la quantità di risorse di pagine di notevoli dimensioni utilizzate dal pod. Nota: se hai utilizzato etichette, corruzioni e regole di affinità per abilitare le pagine di grandi dimensioni solo su nodi di lavoro selezionati, includi queste stesse regole nel tuo pod di 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. Applica il file.pod che hai creato in precedenza.

   kubectl apply -f hugepages-pod.yaml
   

7. Verifica che il tuo pod utilizzi le risorse di pagine di grandi dimensioni.

   1. Controlla che il tuo pod sia Running. Il pod non viene eseguito se non sono disponibili nodi di lavoro con pagine di notevoli dimensioni.

       kubectl get pods
       ```
   2. Accedi al pod.
   ```sh {: pre}
       kubectl exec -it <pod> /bin/sh
       ```
   3. Verifica che il tuo pod possa visualizzare le dimensioni delle pagine di dimensioni notevoli.
   ```sh {: pre}
       ls /sys/kernel/mm/hugepages
       ```
       Output di esempio
       ```sh {: screen}
       hugepages-1048576kB  hugepages-2048kB
       ```
   

8. Facoltativo: rimuovere la serie di daemon di abilitazione. Tieni presente che devi ricreare la serie di daemon se hai bisogno di aggiornare, ricaricare, sostituire o aggiungere nodi di lavoro con pagine di grandi dimensioni in un secondo momento.

   kubectl -n kube-system delete daemonset hugepages-enablement
   

9. Ripeti questi passi ogni volta che aggiorni, ricarichi, sostituisci o aggiungi nodi di lavoro.

Per risolvere i problemi dei nodi di lavoro con pagine di grandi dimensioni, puoi solo riavviare il nodo di lavoro. La configurazione delle pagine di dimensioni notevoli non persiste in altre operazioni del ciclo di vita del nodo di lavoro, come l'aggiornamento, il ricaricamento, la sostituzione o l'aggiunta di nodi di lavoro. Per rimuovere la configurazione delle pagine di notevoli dimensioni dal cluster, è possibile aggiornare, ricaricare o sostituire tutti i nodi di lavoro.

Modifica dell'unità massima di trasmissione (MTU) per i cluster che utilizzano Calico

È possibile aumentare o ridurre il valore della Maximum Transmission Unit (MTU) del nodo di lavoro e del plug-in Calico per soddisfare i requisiti di throughput di rete del proprio ambiente.

Tutti i nodi worker VPC supportano un MTU massimo di 9000 e anche i nodi worker bare metal classici supportano un MTU massimo di 9000. I server virtuali classici supportano solo l'MTU standard di 1500, quindi se il cluster ha nodi worker di server virtuali classici, non aumentare l'MTU del nodo worker o di Calico.

La modifica dei valori dell'unità di trasmissione massima (MTU) può avere risultati inaspettati, soprattutto in ambienti di rete complessi. Per evitare interruzioni del flusso di lavoro, si consiglia di testare queste modifiche su un cluster di sviluppo prima di apportarle ai cluster di produzione.

Per impostazione predefinita, il plug-in di rete Calico nel cluster IBM Cloud Kubernetes Service ha un MTU di 1450 byte per i cluster Satellite e di 1480 byte per i cluster Satellite. Nella maggior parte dei casi, questo valore predefinito della MTU Calico è sufficiente per evitare la caduta e la frammentazione dei pacchetti. Poiché la maggior parte degli host utilizza un valore MTU di 1500, questi valori predefiniti forniscono ai cluster Satellite 50 byte in più per le intestazioni VXLAN e ai cluster Satellite Satellite 20 byte in più per le intestazioni IP utilizzate in alcuni tipi di traffico di rete tra cluster di pod. Si noti che tutti i nodi worker del cluster devono utilizzare lo stesso valore di MTU Calico.

Esamina i seguenti casi in cui potresti dover modificare la MTU predefinita di Calico:

• Se è necessario migliorare il throughput della rete pod-to-pod e i nodi del cluster sono in grado di utilizzare un MTU dell'host più elevato, è possibile aumentare sia l'MTU dell'host che quello di Calico. Questo si chiama "jumbo frame". L'MTU tipico dei jumbo frame è 9000. In questo caso, è possibile impostare l'interfaccia di rete privata dell'host su un valore MTU di 9000 e l'MTU di Calico su un valore leggermente inferiore: 8950 per i cluster Satellite e 8980 per i cluster Satellite. Si noti che alcuni hardware o risorse dei provider cloud, come le macchine virtuali Azure, potrebbero non supportare jumbo frame o supportare solo un valore MTU fino a 4000.
• Se hai una connessione VPN configurata per il tuo cluster, alcune connessioni VPN richiedono una MTU Calico inferiore rispetto al valore predefinito. Verificare con il fornitore del servizio VPN se è necessario impostare un valore MTU inferiore Calico.

Prima di iniziare

Se i tuoi nodi di lavoro eseguono ancora il valore MTU predefinito, aumenta il valore MTU per i tuoi nodi di lavoro prima di aumentare il valore MTU per il plug-in Calico. Ad esempio, è possibile applicare il seguente set di demoni per modificare l'MTU dei nodi worker a 9000 byte. Tieni presente che i nomi dell'interfaccia utilizzati nel comando ip link variano a seconda del tipo di nodi di lavoro.

• Comando di esempio per i nodi di lavoro Bare Metal: ip link set dev bond0 mtu 9000;ip link set dev bond1 mtu 9000;
• Esempio di comando nodi worker VPC: ip link set dev ens3 mtu 9000;

1. Esegui i seguenti comandi per accedere a un nodo cluster worker e inviare un ping da un nodo all'altro. Poiché l'MTU del nodo è impostato solo su 1500 o 1480, questo tentativo è destinato a fallire. Nei passaggi successivi, è possibile eseguire nuovamente questi comandi per verificare che le modifiche siano state apportate con successo.

   1. Elenca i nodi nel tuo cluster. Salvare i nomi e gli indirizzi IP di due nodi sani.

       kubectl get nodes -o wide
       ```
   1. Accedi a uno dei nodi. Specificare il nome del nodo.
   
   
   
   ```sh {: pre}
       kubectl debug --image=us.icr.io/armada-master/network-alpine -it node/<NODE_NAME> -- sh
       ```
   
   
   1. Eseguire il comando per eseguire il ping da un nodo all'altro. Specificare l'indirizzo IP del nodo di cui non si è fatto riferimento nel passaggio precedente.
   ```sh {: pre}
       ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
       ```
   

2. Modificare l'MTU del nodo con il seguente esempio di daemonset. Questo valore MTU si applica al traffico da nodo a nodo. Modificare la riga - ip link set dev ens3 mtu <MTU_VALUE> per includere il proprio valore MTU (l'esempio utilizza un valore MTU di 9000). Si noti che potrebbe essere necessario cambiare il nome dell'interfaccia 'ens3 se ens3 non è appropriato per i propri nodi.

   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. Applicare il daemonset per modificare il valore MTU del nodo.

     kubectl apply -f <file_name>
   

4. Eseguite nuovamente i comandi per accedere a un nodo e per eseguire il ping da un host all'altro, utilizzando un pacchetto di grandi dimensioni. Ora che è stato aumentato il valore MTU del nodo, il comando 'ping dovrebbe avere successo.

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

   ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
   

5. Prendete tempo per testare il vostro cluster con il nuovo valore di MTU dei nodi. Prima di continuare a modificare il valore MTU di Calico, si consiglia di verificare che le applicazioni continuino a funzionare come previsto.

6. Eseguire il comando per aggiornare i valori MTU di Calico in modo che anche il traffico pod-to-pod possa utilizzare l'MTU più grande. Per i cluster Satellite Core OS, il valore MTU di Calico deve essere inferiore di 50 byte rispetto al valore MTU del nodo. Per tutti gli altri cluster, il valore MTU di Calico deve essere inferiore di 20 byte. Ad esempio, se si è specificato 9000 per l'MTU del nodo, l'MTU di Calico deve essere 8950 per i cluster Satellite Core OS o 8980 per tutti gli altri cluster.

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

   Si può anche modificare la risorsa direttamente eseguendo 'kubectl edit installation.operator.tigera.io default.

7. Applicare queste modifiche a tutti i nodi riavviando con cura tutti i nodi. Assicurarsi di aver testato questo processo su un cluster di sviluppo prima di continuare con questa fase, poiché queste modifiche potrebbero causare interruzioni del carico di lavoro. Per riavviare i nodi, si consiglia di cordonare, svuotare e riavviare i nodi uno alla volta.

Se si completano questi passaggi su un cluster di produzione, si deve usare lo stesso processo utilizzato per l'aggiornamento o la sostituzione dei nodi di produzione. Si consiglia vivamente di testare l'intero processo su un cluster di prova prima di completare questi passaggi su un cluster di produzione.

Durante il processo di riavvio, alcuni pod utilizzano il nuovo MTU più grande e altri hanno ancora l'MTU originale, più piccolo. In genere, questo scenario non causa problemi perché entrambe le parti negoziano la dimensione massima corretta dei pacchetti. Tuttavia, se si bloccano i pacchetti ICMP, la negoziazione potrebbe non funzionare e il cluster potrebbe avere problemi di connessione al pod fino al completamento di tutti i riavvii. È fondamentale che questo processo venga prima testato su un cluster di sviluppo.

Disabilitare il plug-in della mappa delle porte in Calico

Il plugin portmap per la CNI (container network interface) Calico ti consente di utilizzare una hostPort per esporre i tuoi pod dell'applicazione in una porta specifica sul nodo di lavoro. Per evitare problemi di prestazioni di iptables, rimuovi il plug-in "port map" dalla configurazione CNI " Calico " del tuo cluster.

Quando nel cluster sono presenti molti servizi, ad esempio più di 500, oppure molti porti sui servizi, ad esempio più di 50 porti per servizio su 10 o più servizi, vengono generate numerose regole iptables per le politiche di rete “ Calico ” e “ Kubernetes ” relative a tali servizi. L'utilizzo di un numero elevato di regole iptables può causare problemi di prestazioni per il plug-in port map e potrebbe impedire futuri aggiornamenti delle regole iptables o provocare il riavvio del container calico-node qualora non venga ricevuto alcun blocco per effettuare gli aggiornamenti delle regole iptables entro un determinato periodo di tempo. Per evitare questi problemi di prestazioni, è possibile disabilitare il plug-in di mappatura delle porte rimuovendolo dalla configurazione CNI di Calico del proprio cluster.

Se è necessario utilizzare hostPorts, non disabilitare il plug-in della mappa di porte.

1. Modifica la risorsa di installazione Calico default.

   kubectl edit installation default -n calico-system
   

2. Nella sezione spec.calicoNetwork, modifica il valore di hostPorts con 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. Salva e chiudi il file. Le tue modifiche vengono applicate automaticamente.