Architecture-center: Sichern Sie den Netzwerkfluss – wie funktioniert das

Vielen Dank für die Meldung. Dieses Problem wird derzeit überprüft. Dies ist eine Microsoft interne DevOps- Fehler- ID

Vielen Dank, dass Sie sich an @melzayet gewendet haben. Die beiden Verkehrsströme haben unterschiedliche Ursprünge. Der oberste (grüne) Flow ist HTTP-Datenverkehr, der für die Workloads Ihres Clusters (die Web-App/API usw.) bestimmt ist, die auf Knoten im Cluster ausgeführt werden. die HTTP-Antwort für diese Anforderungen wird wieder an die WAF und an den Client ausgegeben.

Der untere (orange) Fluss ist Verkehr, der aus dem Subnetz stammt, das die Knoten enthält. Dies wäre Datenverkehr, der an externe Container-Registrys, den Kubernetes-API-Server usw. gesendet wird. Im Grunde genommen jeder vom Cluster stammende Datenverkehr, den wir mit unseren unternehmensinternen Firewallregeln für ausgehenden Traffic schützen möchten.

Da der Datenverkehr von außerhalb des UDR-regulierten Netzwerks stammt und wir den _internen_ Load Balancer in einem separaten Subnetz verwenden, nimmt er denselben Rückweg. Die UDR-Regel gilt für Verkehr, der aus ihrem Geltungsbereich stammt.

Um es klar zu sagen, löst diese Lösung nur die

Ich gehe davon aus, dass der DNAT-Teil, von dem Sie sprechen, aus diesem Abschnitt in den AKS-Dokumenten stammt ( insbesondere dieser ). In diesem Fall erzwingen sie auch, dass der gesamte eingehende Datenverkehr auch durch die Firewall fließt. In ihrem Fall verwenden sie einen _öffentlichen_ Load Balancer für den Ingress, unsere Lösung verwendet KEINEN öffentlichen Load Balancer für den Ingress. Wir nehmen Kontakt mit AAG auf, das dann über einen _internal_ Load Balancer in einem dedizierten Ingress-Subnetz geroutet wird, das dann nicht dem asymmetrischen Routing-Problem unterliegt. Wenn Sie Ihre Dienste direkt über die öffentliche Lastenausgleichs-IP verfügbar gemacht haben, würden Sie mit Sicherheit auf das Problem des asymmetrischen Routings stoßen.

Lassen Sie es mich wissen, wenn ich zur Klärung beitragen kann - ich weiß, dass dies ein bisschen "kontra-intuitiv" erscheint. Fühlen Sie sich frei, mit der Referenzimplementierung bereitzustellen. Am Ende dieser Reise haben Sie eine Website, auf der der HTTP-Datenverkehr der Arbeitslast über die Eingangsroute abgewickelt wird (Client -> WAF -> interner LB -> Nodepool -> WAF -> Client). und vom Cluster stammender Verkehr (Nodepool -> FW -> externe Ressource -> FW -> Nodepool) wird über die Egress-Route abgewickelt.

@ckittel Danke für das Teilen von Erkenntnissen dazu! Ich weise Ihnen dieses Problem zu.

@ckittel vielen Dank für die ausführliche und informative Antwort. Ich denke, meine Verwirrung kam von dem asymmetrischen Problem, aber Sie haben es sehr gut geklärt. Danke nochmal, dass du dir die Zeit genommen hast