Standard-Workerknoteneinstellungen

Standardmäßig verfügen Ihre Arbeitsknoten über das Betriebssystem und die Rechenhardware der Arbeitsknotenvariante, die Sie bei der Erstellung des Arbeitspools ausgewählt haben.

Ändern der Kernel-Einstellungen des Arbeitsknotens zur Leistungsoptimierung

Cluster-Workerknoten werden für ein Maß an Stabilität, Optimierung und Leistung konfiguriert, von dem erwartet wird, dass sie die Anforderungen der meisten Workloads erfüllen. Normalerweise wird es nicht empfohlen, die Kerneleinstellungen Ihres Workerknotens zu ändern, da solche Änderungen zu ungewöhnlichen und unbeabsichtigten Problemen führen können. Wenn Ihre Workload jedoch sehr eindeutige Anforderungen an die Leistungsoptimierung hat, die Änderungen an Ihren Kerneleinstellungen erfordern, können Sie ein angepasstes Kubernetes-DaemonSet anwenden, um die Kernelkonfiguration zu ändern. Stellen Sie fest, dass diese Änderungen erhebliche negative Folgen haben können und dass Sie Änderungen an der Konfiguration der Kerneleinstellungen auf eigenes Risiko implementieren.

Wenn Sie die Konfiguration Ihrer Kerneleinstellungen ändern, stellen Sie sicher, dass Sie die genau vorgenommenen Änderungen dokumentieren und speichern. Wenn Sie ein Support-Ticket für Probleme im Zusammenhang mit dem Cluster öffnen, müssen Sie diese Änderungen angeben. Diese Konfigurationsänderungen können für das Problem verantwortlich sein und Sie werden möglicherweise aufgefordert, die Änderungen im Rahmen der Problemuntersuchung zurückzusetzen. In diesem Fall sind Sie für das Zurücksetzen von Änderungen an der Kernelkonfiguration verantwortlich, die Sie implementieren.

Das Ändern der Standardkerneleinstellungen kann sich negativ auf Ihren Cluster auswirken. Nehmen Sie diese Änderungen auf eigenes Risiko vor.

Sie können die Standardkerneleinstellungen ändern, indem Sie ein angepasstes Kubernetes DaemonSet mit einem init-Container auf Ihren Cluster anwenden. Die Dämongruppe (DaemonSet) ändert die Einstellungen für alle vorhandenen Workerknoten und wendet die Einstellungen auf alle neuen Workerknoten an, die im Cluster eingerichtet werden. Der Container init sorgt dafür, dass diese Änderungen vorgenommen werden, bevor andere Pods auf dem Arbeitsknoten eingeplant werden. Es sind keine Pods betroffen.

Sie müssen über die Servicezugriffsrolle Manager in IBM Cloud IAM für alle Namensbereiche verfügen, in denen der privilegierte Beispielinitialisierungscontainer initContainer ausgeführt wird. Nachdem die Container für die Bereitstellungen initialisiert wurden, werden die Privilegien gelöscht.

Vorbereitende Schritte: Greifen Sie auf Ihren Red Hat OpenShift-Cluster zu.

1. Speichern Sie die folgende Dämongruppe (DaemonSet) in einer Datei mit dem Namen worker-node-kernel-settings.yaml. Fügen Sie im Abschnitt spec.template.spec.initContainers die Felder und Werte für die sysctl-Parameter hinzu, die Sie optimieren möchten. Dieses Beispiel für eine Dämongruppe ändert den Standardwert für die Anzahl Verbindungen, die maximal in der Umgebung zulässig sind, über die Einstellung net.core.somaxconn und den Bereich ephemerer Ports über die Einstellung net.ipv4.ip_local_port_range.

   Abhängig von den Einstellungen für systctl, die Sie ändern wollen, können Sie den Sicherheitskontext konfigurieren. Weitere Informationen finden Sie in der Red Hat OpenShift-Dokumentation.

   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. Wenden Sie die Dämongruppe auf Ihre Workerknoten an. Die Änderungen werden sofort angewendet.

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

Um die Parameter Ihrer Arbeitsknoten sysctl auf die Standardwerte zurückzusetzen, gehen Sie wie folgt vor.

1. Löschen Sie die Dämongruppe. Die initContainers, die die angepassten Einstellungen angewendet haben, werden entfernt.

   oc delete ds kernel-optimization
   

2. Führen Sie einen Warmstart aller Workerknoten im Cluster aus.. Die Workerknoten werden mit den angewendeten Standardwerten wieder gestartet.

sysctl-Einstellungen für Netz-Keepalive optimieren

Wenn ein Pod lange aktive TCP-Verbindungen hat, die gelegentlich getrennt werden, während sie inaktiv sind, kann es hilfreich sein, die sysctl-Keepalive-Einstellungen für den Pod zu ändern.

Es gibt derzeit keine Möglichkeit, diese sysctl-Keepalive-Einstellungen standardmäßig für alle Pods in einem Cluster festzulegen. Die beste Methode, die Einstellungen für alle Pods zu ändern, ist die Verwendung einer privilegierten initContainer. Sehen Sie sich das folgende Beispiel an, wie ein initContainer für eine Bereitstellung in einem test-ns-Namensbereich eingerichtet wird.

Privilegierte initContainers im Namensbereich test-ns zulassen:

```sh {: pre}
oc adm policy add-scc-to-groupl privileged system:serviceaccounts:test-ns
```

Implementieren Sie das folgende Beispiel initContainer. Denken Sie daran, den Abschnitt containers: in Ihre eigenen Anwendungscontainer zu ändern. initContainer legt dann die sysctl-Einstellungen für alle regulären Container im Pod fest, da sie alle denselben Netznamensbereich gemeinsam nutzen.

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

Calico-MTU (maximum transmission unit) ändern

Sie können die Calico-Plug-in-MTU (maximum transmission unit) erhöhen oder verringern, um die Netzdurchsatz-Anforderungen Ihrer Umgebung zu erfüllen.

Alle VPC-Arbeitsknoten unterstützen Jumbo-Frames, aber die klassische Infrastruktur unterstützt Jumbo-Frames nur auf Bare Metal Workern.

Die Änderung von MTU-Werten (Maximum Transmission Unit) kann zu unerwarteten Ergebnissen führen, insbesondere in komplexen Netzwerkumgebungen. Um eine Unterbrechung Ihres Arbeitsablaufs zu vermeiden, wird dringend empfohlen, diese Änderungen auf einem Entwicklungscluster zu testen, bevor Sie Änderungen an Ihren Produktionsclustern vornehmen.

Standardmäßig hat das Calico in Ihrem Red Hat OpenShift on IBM Cloud eine MTU von 1450 Byte für Satellite und 1480 Byte für Satellite. In den meisten Fällen ist dieser Standard-MTU-Wert von Calico ausreichend, um Paketverluste und Fragmentierung zu verhindern. Da die meisten Hosts einen MTU-Wert von 1500 verwenden, bieten diese Standardwerte Satellite 50 zusätzliche Bytes für VXLAN-Header und Satellite 20 zusätzliche Bytes für die IP-Header, die in einigen Pod-zu-Pod-Cluster-Netzwerkverkehren verwendet werden. Beachten Sie, dass alle Arbeitsknoten im Cluster denselben Calico verwenden müssen.

Sehen Sie sich die folgenden Fälle an, in denen Sie möglicherweise die Standard-Calico-MTU ändern müssen:

• Wenn Sie den Netzwerkdurchsatz zwischen den Pods verbessern müssen und Ihre Clusterknoten eine höhere Host-MTU verwenden können, können Sie sowohl die Host- als auch die Calico erhöhen. Dies wird als "Jumbo-Frames" bezeichnet. Die typische Jumbo Frame MTU beträgt 9000. In diesem Fall können Sie die private Netzwerkschnittstelle des Hosts auf einen MTU-Wert von 9000 und die Calico auf einen etwas niedrigeren Wert einstellen - 8950 für Satellite und 8980 für Satellite. Beachten Sie, dass einige Hardware oder Ressourcen von Cloud-Anbietern, wie z. B. virtuelle Azure, möglicherweise keine Jumbo-Frames oder nur einen MTU-Wert von bis zu 4000 unterstützen.
• Wenn Sie über eine VPN-Verbindung für Ihren Cluster verfügen, benötigen einige VPN-Verbindungen eine kleinere Calico-MTU als den Standardwert. Überprüfen Sie beim Provider des VPN-Service, ob eine kleinere Calico-MTU erforderlich ist.

Vorbereitende Schritte

Wenn Ihre Arbeitsknoten noch den Standard-MTU-Wert verwenden, erhöhen Sie zuerst den MTU-Wert für Ihre Arbeitsknoten, bevor Sie den MTU-Wert für das Calico Plug-in erhöhen. Sie können zum Beispiel den folgenden Daemon-Satz anwenden, um die MTU für Ihre Arbeitsknoten auf 9000 Bytes zu ändern. Beachten Sie, dass die im Befehl ip link verwendeten Schnittstellennamen abhängig vom Typ Ihrer Workerknoten variieren.

• Beispielbefehl für Bare-Metal-Workerknoten: ip link set dev bond0 mtu 9000;ip link set dev bond1 mtu 9000;
• Beispielbefehl für VPC-Workerknoten der 2. Generation: ip link set dev ens3 mtu 9000;

1. Führen Sie die folgenden Befehle aus, um sich bei einem Cluster-Worker-Knoten anzumelden und von einem Knoten zum anderen zu pingen. Da die MTU Ihres Knotens nur auf 1500 oder 1480 eingestellt ist, wird dieser Versuch voraussichtlich fehlschlagen. In den folgenden Schritten können Sie diese Befehle erneut ausführen, um zu überprüfen, ob die Änderungen erfolgreich waren.

   1. Listen Sie die Knoten in Ihrem Cluster auf. Speichern Sie die Namen und IP-Adressen von zwei gesunden Knoten.

      oc get nodes -o wide
      

   2. Melden Sie sich bei einem der Knoten an. Geben Sie den Namen des Knotens an.

      oc debug node/<NODE_NAME>
      

   3. Führen Sie den Befehl aus, um von einem Knoten zum anderen zu pingen. Geben Sie die IP-Adresse des Knotens an, auf den Sie im vorherigen Schritt nicht verwiesen haben.

      ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
      

2. Ändern Sie die Knoten-MTU mit dem folgenden Beispiel-Daemonset. Dieser MTU-Wert gilt für den Verkehr von Knoten zu Knoten. Ändern Sie die Zeile - ip link set dev ens3 mtu <MTU_VALUE> so, dass sie Ihren MTU-Wert enthält (im Beispiel wird ein MTU-Wert von 9000 verwendet). Beachten Sie, dass Sie möglicherweise auch den Schnittstellennamen " ens3 ändern müssen, wenn ens3 für Ihre Knoten nicht geeignet ist.

   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. Wenden Sie das Daemonset an, um den MTU-Wert des Knotens zu ändern.

     oc apply -f <file_name>
   

4. Führen Sie die Befehle erneut aus, um sich bei einem Knoten anzumelden und einen Ping von einem Host zu einem anderen zu senden, wobei Sie eine große Paketgröße verwenden. Da Sie nun den MTU-Wert des Knotens erhöht haben, sollte der Befehl " ping erfolgreich sein.

   oc debug node/<NODE_NAME>
   

   ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
   

5. Nehmen Sie sich die Zeit, Ihren Cluster mit dem neuen Knoten-MTU-Wert zu testen. Bevor Sie mit dem Ändern des Calico MTU-Wertes fortfahren, sollten Sie überprüfen, ob Ihre Anwendungen noch wie erwartet funktionieren.

6. Führen Sie den Befehl aus, um die Calico zu aktualisieren, so dass der Pod-zu-Pod-Verkehr auch die größere MTU verwenden kann. Bei Satellite Core OS-Clustern sollte der Calico 50 Byte kleiner sein als der Knoten-MTU-Wert. Bei allen anderen Clustern sollte der Calico 20 Byte niedriger sein. Wenn Sie beispielsweise 9000 für die Knoten-MTU angegeben haben, sollte Ihre Calico 8950 für Satellite Core OS-Cluster oder 8980 für alle anderen Cluster betragen.

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

   Sie können die Ressource auch direkt bearbeiten, indem Sie ' oc edit installation.operator.tigera.io default ausführen.

7. Wenden Sie diese Änderungen auf alle Ihre Knoten an, indem Sie alle Knoten vorsichtig neu starten. Stellen Sie sicher, dass Sie diesen Prozess auf einem Entwicklungscluster getestet haben, bevor Sie mit diesem Schritt fortfahren, da diese Änderungen zu Unterbrechungen Ihrer Arbeitslast führen können. Um die Knoten neu zu starten, wird empfohlen, die Knoten nacheinander abzusperren, zu entleeren und neu zu starten.

Wenn Sie diese Schritte auf einem Produktionscluster durchführen, sollten Sie denselben Prozess anwenden, den Sie für die Aktualisierung oder den Austausch von Produktionsknoten verwenden. Es wird dringend empfohlen, diesen gesamten Prozess auf einem Testcluster zu testen, bevor Sie diese Schritte auf einem Produktionscluster durchführen.

Während des Neustarts verwenden einige Pods die neue, größere MTU und einige Pods haben noch die ursprüngliche, kleinere MTU. Normalerweise verursacht dieses Szenario keine Probleme, da beide Seiten die korrekte maximale Paketgröße aushandeln. Wenn Sie jedoch ICMP-Pakete blockieren, kann es sein, dass die Aushandlung nicht funktioniert und Ihr Cluster Probleme mit der Pod-Verbindung bekommt, bis alle Neustarts abgeschlossen sind. Es ist von entscheidender Bedeutung, dass dieser Prozess zunächst in einem Entwicklungscluster getestet wird.

Plug-in für die Portzuordnung inaktivieren

Der Plug-in portmap für die Containernetzschnittstelle (Container Network Interface, CNI) von Calico ermöglicht Ihnen, einen Host-Port (hostPort) zu verwenden, um Ihre App-Pods über einen bestimmten Port auf dem Workerknoten zugänglich zu machen. Verhindern Sie Leistungsprobleme für 'iptables', indem Sie das Plug-in für Portzuordnungen aus der Calico-CNI-Konfiguration Ihres Clusters entfernen.

Wenn Sie über viele Services in Ihrem Cluster verfügen, z. B. mehr als 500 Services, oder viele Ports auf Services, z. B. mehr als 50 Ports pro Service für 10 oder mehr Services, werden viele iptables-Regeln für die Calico- und Kubernetes-Netzrichtlinien für diese Services generiert. Die Verwendung vieler iptables-Regeln kann zu Leistungsproblemen für das Port-Map-Plugin führen und könnte künftige Aktualisierungen von iptables-Regeln verhindern oder dazu führen, dass der calico-node-Container neu gestartet wird, wenn keine Sperre empfangen wird, um iptables-Regeln innerhalb einer bestimmten Zeit zu aktualisieren. Zur Vermeidung solcher Leistungsprobleme können Sie das Plug-in für Portzuordnungen inaktivieren, indem Sie es aus der Calico-CNI-Konfiguration Ihres Clusters entfernen.

Wenn Sie hostPorts verwenden müssen, inaktivieren Sie das Plug-in für die Portzuordnung nicht.

1. Bearbeiten Sie die Calico-Installationsressource default.

   oc edit installation default -n calico-system
   

2. Ändern Sie im Abschnitt spec.calicoNetwork den Wert für das Feld hostPorts in 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
   

3. Speichern und schließen Sie die Datei. Daraufhin werden Ihre Änderungen automatisch angewendet.