Jak odbywa się przekierowanie ruchu do ingressu z wnętrza klastra?

Aby przekierować ruch z wnętrza klastra do Ingress, używa się nazwy DNS serwisu Ingress Controller. W standardowej konfiguracji, Ingress Controller jest wdrażany jako Service typu LoadBalancer lub NodePort.

1. Odkrywanie serwisu: Aplikacja wewnątrz klastra używa nazwy DNS serwisu, który eksponuje (ujawnia) Ingress Controller. Na przykład nginx-ingress-controller.ingress-nginx.svc.cluster.local, jeśli używany jest nginx-ingress z odpowiednią nazwą serwisu.

2. IP serwisu/ClusterIP: Serwer DNS klastra Kubernetes (np. CoreDNS) rozwiązuje tę nazwę DNS na ClusterIP serwisu Ingress Controller.

3. kube-proxy: kube-proxy na węźle, na którym działa aplikacja, przechwytuje ruch skierowany do ClusterIP serwisu Ingress Controller.

4. iptables/ipvs: kube-proxy używa reguł iptables lub ipvs do routowania ruchu do jednego z podów Ingress Controller.

5. Przetwarzanie w Ingress Controller: Pody Ingress Controller otrzymują ruch i, zgodnie z regułami zasobów Ingress, przekierowują go do odpowiedniego serwisu wewnątrz klastra.

Przykład zapytania z poda:

# Zapytanie do serwisu przez Ingress, używając wewnętrznego DNS
curl http://my-app.example.com

Tutaj my-app.example.com jest rozwiązywane przez serwer DNS klastra na ClusterIP serwisu Ingress Controller, jeśli odpowiednie wpisy są skonfigurowane lub jeśli Ingress Controller jest skonfigurowany do obsługi takich zapytań bezpośrednio (mniej typowe dla ruchu wewnętrznego). Większość ruchu wewnętrznego odwołuje się do serwisu po jego nazwie DNS. Jeśli konieczne jest wyraźne przejście przez Ingress z wnętrza klastra, należy upewnić się, że Ingress Controller jest dostępny przez ClusterIP lub lokalny IP podów i że wpis DNS lub mechanizm routingu kieruje do niego.

Najbardziej powszechny wzorzec komunikacji między serwisami wewnątrz klastra to bezpośredni dostęp do serwisu po jego nazwie DNS (<nazwa-serwisu>.<namespace>.svc.cluster.local), pomijając Ingress. Przekierowanie ruchu do Ingress z wnętrza klastra jest zwykle potrzebne do testowania lub w specyficznych scenariuszach routingu.