Sobes.tech
Middle+

Wie erfolgt die Weiterleitung des Datenverkehrs zum Ingress aus dem Inneren des Clusters?

sobes.tech KI

Antwort von AI

Um den Datenverkehr innerhalb des Clusters an Ingress weiterzuleiten, wird der DNS-Name des Ingress-Controller-Dienstes verwendet. In der Standardkonfiguration wird der Ingress-Controller als Service vom Typ LoadBalancer oder NodePort bereitgestellt.

  1. Service Discovery: Die Anwendung innerhalb des Clusters verwendet den DNS-Namen des Service, der den Ingress-Controller exponiert (macht sichtbar). Zum Beispiel nginx-ingress-controller.ingress-nginx.svc.cluster.local, wenn nginx-ingress mit dem entsprechenden Service-Namen verwendet wird.

  2. Service IP/ClusterIP: Der DNS-Server des Kubernetes-Clusters (z.B. CoreDNS) löst diesen DNS-Namen in die ClusterIP des Ingress-Controller-Services auf.

  3. kube-proxy: kube-proxy auf dem Knoten, auf dem die Anwendung läuft, fängt den Traffic ab, der an den ClusterIP-Service des Ingress-Controllers gerichtet ist.

  4. iptables/ipvs: kube-proxy verwendet iptables- oder ipvs-Regeln, um den Traffic an einen der Pods des Ingress-Controllers weiterzuleiten.

  5. Verarbeitung im Ingress-Controller: Die Pods des Ingress-Controllers empfangen den Traffic und leiten ihn gemäß den Ingress-Regeln an den entsprechenden Service im Cluster weiter.

Beispiel für eine Anfrage aus einem Pod:

# Anfrage an den Service über Ingress, unter Verwendung des internen DNS
curl http://my-app.example.com

Hier wird my-app.example.com vom DNS-Server des Clusters in die ClusterIP des Ingress-Controller-Services aufgelöst, sofern die entsprechenden Einträge konfiguriert sind oder der Ingress-Controller so eingerichtet ist, dass er solche Anfragen direkt verarbeitet (weniger typisch für internen Traffic). Der interne Traffic greift meist auf den Service über seinen DNS-Namen zu. Wenn man explizit durch Ingress von innerhalb des Clusters gehen möchte, muss sichergestellt werden, dass der Ingress-Controller über die ClusterIP oder die lokale IP der Pods erreichbar ist und dass der DNS-Eintrag oder der Routing-Mechanismus auf ihn zeigt.

Das gängigste Muster für die Kommunikation zwischen Services im Cluster ist der direkte Zugriff auf den Service über seinen DNS-Namen (<service-name>.<namespace>.svc.cluster.local), wobei Ingress umgangen wird. Das Weiterleiten des Traffics zu Ingress innerhalb des Clusters ist in der Regel für Tests oder spezielle Routing-Szenarien erforderlich.