Kā notiek trafika novirzīšana uz ingress no iekšpuses klastera?

Klastera iekšienē trafika novirzīšanai uz Ingress tiek izmantots Ingress Controller DNS nosaukums. Standarta konfigurācijā Ingress Controller tiek izvietots kā LoadBalancer vai NodePort tipa pakalpojums.

1. Service Discovery: Programmatūra iekšienē klasterī izmanto Service DNS nosaukumu, kas atklāj (izvieto) Ingress Controller. Piemēram, nginx-ingress-controller.ingress-nginx.svc.cluster.local, ja tiek izmantots nginx-ingress ar atbilstošo Service nosaukumu.

2. Service IP/ClusterIP: Kubernetes klastera DNS serveris (piemēram, CoreDNS) risina šo DNS nosaukumu uz ClusterIP Service, kas pārstāv Ingress Controller.

3. kube-proxy: kube-proxy uz mezgla, kurā darbojas programma, pārtrauc trafiku, kas virzīts uz ClusterIP Service, kas pārstāv Ingress Controller.

4. iptables/ipvs: kube-proxy izmanto iptables vai ipvs noteikumus trafika maršrutēšanai uz vienu no Ingress Controller podiem.

5. Apstrāde Ingress Controller: Ingress Controller podi saņem trafiku un, saskaņā ar Ingress resursu noteikumiem, to novirza uz atbilstošo iekšējo klastera servisu.

Piemērs pieprasījumam no poda:

# Pieprasījums caur Ingress, izmantojot iekšējo DNS
curl http://my-app.example.com 

Šeit my-app.example.com tiek risināts DNS serverī uz ClusterIP Service Ingress Controller, ja ir konfigurēti atbilstoši ieraksti vai ja Ingress Controller ir konfigurēts apstrādāt šādus pieprasījumus tieši (mazāk tipisks gadījums iekšējam trafikam). Visbiežāk iekšējais trafiks vēršas pie servisa pēc tā DNS nosaukuma. Ja nepieciešams tieši caur Ingress iekšā klasterī, jānodrošina, ka Ingress Controller ir pieejams caur ClusterIP vai vietējo IP, un DNS ieraksts vai maršrutēšanas mehānisms to virza uz to.

Visizplatītākais modelis klastera iekšienē ir tieša piekļuve servisam pēc tā DNS nosaukuma (<service-name>.<namespace>.svc.cluster.local), apejot Ingress. Trafika pāradresācija uz Ingress no iekšienes klasterī parasti ir nepieciešama testēšanai vai specifiskiem maršrutēšanas scenārijiem.