Ich habe einen Einzelknoten-Kubernetes-Cluster, der auf RHEL 7 läuft.
Ich habe auch einen Windows Server 2019-Server.
Sowohl die Windows- als auch die RHEL-Server sind virtuelle Maschinen auf demselben Host.
Wenn ich an einer Eingabeaufforderung auf RHEL sitze und versuche, curlein 500 KB großes Dokument von einer URL auf IIS abzurufen, ist die Anforderung „schnell“ (weniger als 1 Sekunde).
Wenn ich dieselbe Anfrage innerhalb eines Containers ausführe, der in einem Kubernetes-Pod ausgeführt wird, ist die Anfrage „langsam“ (4 Sekunden oder mehr).
Dies geschieht sowohl mit Calico (Original) als auch mit Weave (jetzt stattdessen eingesetzt) als Kubernetes-Pod-Netzwerkanbieter.
Ich bin so weit gekommen, dass ich es tcpdumpin einem Container laufen lasse und feststelle, dass es während der HTTP-Anforderung zu einer großen Zahl von TCP-Neuübertragungen und Aktualisierungen der Fenstergröße kommt.
Dies sieht (soweit ich weiß) nach einem MTU-bezogenen Problem aus. Die Reduzierung der MTU sowohl auf der IIS-Seite als auch innerhalb des Weave-Netzwerks hat jedoch nicht geholfen.
Ich warte auf Paketdumps vom Kunden, die sowohl am IIS-Ende als auch direkt auf der RHEL-Maschine ausgeführt werden, damit ich feststellen kann, wo Pakete gelöscht werden.
In der Zwischenzeit sind alle Ideen herzlich willkommen.
Antwort1
Wir haben das Problem behoben, waren uns der Grundursache jedoch nie hundertprozentig sicher.
Paket-Dumps zeigten Jumbo-Frames (weit größer als 1500 Bytes), die von IIS bei der K8s-Box ankamen und dann von Linux mit der Meldung „Fragmentierung erforderlich“ abgelehnt wurden, da die Weave-MTU ein Standardwert von 1376 war.
Die MTU an beiden Enden der Verbindung betrug 1500, aber wir denken, dass vielleicht TCP-Segmentierungs-Offloading im Spiel war (der Kunde verwendet VMWare undMysteriöse „Fragmentierung erforderlich“-Ablehnungen von der Gateway-VMklingt irgendwie ähnlich)
Wir haben letztendlich eine sehr hohe MTU für das Weave-Netzwerk festgelegt – 65404 –, da sich alles innerhalb einer einzigen VM befindet. Warum also nicht?
Dadurch wurde die Paketfragmentierung behoben und HTTP-Anfragen innerhalb der Container sind jetzt genauso schnell wie von außerhalb auf dem K8s-Host.