Ottimizzazione delle prestazioni

Se hai specifici requisiti di ottimizzazione delle prestazioni, puoi modificare le impostazioni predefinite per alcuni componenti cluster in Red Hat® OpenShift® on IBM Cloud®.

Se scegli di modificare le impostazioni predefinite, lo fai a tuo proprio rischio. Sei responsabile dell'esecuzione di test sulle eventuali impostazioni modificate e per qualsiasi eventuale interruzione causata dalle impostazioni modificate nel tuo ambiente.

Invece di ottimizzare le prestazioni dei nodi worker con MachineConfig i file in Red Hat OpenShift, è possibile modificare l'host con un daemonset file. Per ulteriori informazioni, vedere Modifica Calico dell'MTU o Ottimizzazione delle prestazioni per i nodi Red HatCoreOS di lavoro.

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.

Personalizzazione del sistema operativo

È possibile trovare un elenco dei sistemi operativi supportati per versione del cluster nelle informazioni Red Hat OpenShift on IBM Cloud sulla versione. Il cluster non può combinare sistemi operativi o utilizzare sistemi operativi differenti.

Per ottimizzare i tuoi nodi di lavoro, considera le seguenti informazioni.

  • Aggiornamenti di immagine e versione: gli aggiornamenti del nodo di lavoro, come le patch di sicurezza per l'immagine o le versioni Red Hat OpenShift, vengono forniti da IBM per tuo conto. Tuttavia, scegli quando applicare gli aggiornamenti ai nodi di lavoro. Per ulteriori informazioni, vedi Aggiornamento di cluster, nodi di lavoro e componenti cluster.
  • Modifiche temporanee: se esegui l'accesso a un pod o utilizzi qualche altro processo per modificare l'impostazione di un nodo di lavoro, le modifiche sono temporanee. Le operazioni del ciclo di vita del nodo di lavoro, come l'autorecovery, il ricaricamento, l'aggiornamento o la sostituzione di un nodo di lavoro, modificano le modifiche alle impostazioni predefinite.
  • Modifiche persistenti: per rendere persistenti le modifiche tra le operazioni del ciclo di vita del nodo di lavoro, crea una serie di daemon che utilizzi un contenitore init. Per ulteriori informazioni, vedi Modifica delle impostazioni del nodo di lavoro predefinito per ottimizzare le prestazioni.

Le modifiche al sistema operativo non sono supportate. Se si modificano le impostazioni predefinite, si è responsabili del debug e della risoluzione dei problemi che potrebbero verificarsi.

Modifiche hardware

Per modificare l'hardware di calcolo, come la CPU e la memoria per nodo di lavoro, scegli tra le seguenti opzioni.

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 cluster Red Hat OpenShift.

  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.

    A seconda delle systctl impostazioni che si tenta di modificare, è possibile configurare il contesto di sicurezza. Per ulteriori informazioni, consultare la documentazione di 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

  2. Applica la serie di daemon ai tuoi nodi di lavoro. Le modifiche vengono applicate immediatamente.

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

Per ripristinare i valori predefiniti dei parametri dei nodi di lavoro ( sysctl ), procedere come segue.

  1. Elimina la serie di daemon. Gli initContainers che applicavano le impostazioni personalizzate vengono rimossi.
    oc 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 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.

Consenti il privilegio initContainers nello spazio dei nomi test-ns:

oc adm policy add-scc-to-group privileged system:serviceaccounts: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

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

È possibile aumentare o ridurre il valore della MTU (Maximum Transmission Unit) dei nodi 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 Red Hat OpenShift on IBM Cloud 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 del cloud provider, come le macchine virtuali Azure, potrebbero non supportare jumbo frame o supportare solo un valore di 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.
        oc get nodes -o wide
    ```
1. Accedi a uno dei nodi. Specificare il nome del nodo.


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



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.

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

    oc debug node/<NODE_NAME>

    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.

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

    Si può anche modificare la risorsa direttamente eseguendo 'oc 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 " 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.

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