Kubernetes ha molte parti mobili. Questo è prevedibile da qualsiasi modello pensato per il calcolo distribuito. Per esplorare ciò che Kubernetes Ingress ci aiuta a realizzare, ricapitoliamo prima alcuni dettagli rilevanti su un tipico cluster Kubernetes:

Un'applicazione distribuita su un cluster Kubernetes viene eseguita come pod di raccolta.
I pod sono essenzialmente contenitori pianificati su più nodi.
I nodi possono essere server fisici o VM offerti dal tuo provider di hosting. Ovviamente, puoi anche Kubernetes su un server on-premise, se lo desideri.
Ogni Pod ha un indirizzo IP univoco.
La tua applicazione è suddivisa in molti sottocomponenti, spesso indicati come microservizi.
Per ogni microservizio della tua applicazione, ha un servizio corrispondente in Kubernetes.
Nel contesto di Kubernetes, a Servizio espone una raccolta di pod al resto del cluster come una singola astrazione. Un unico IP virtuale.
Questo aiuta un servizio della tua applicazione a comunicare con un altro servizio. È un'astrazione che ti consente di indirizzare una raccolta di pod, piuttosto che specificare l'indirizzo IP di un pod, ogni volta che vuoi parlare con esso.
Un servizio Kubernetes funge anche da bilanciatore del carico per tutti i pod che rappresenta. Il traffico viene distribuito uniformemente su tutti i nodi.

Fin qui tutto bene. Ogni servizio può parlare con un altro servizio. Questa comunicazione è possibile attraverso l'intero cluster Kubernetes

Servizi Espositivi

“Se un albero cade in una foresta e nessuno è in giro per sentirlo, emette un suono??"

In una nota simile, se la tua applicazione non ha uno scopo al di fuori del cluster Kubernetes, è davvero importante se il tuo cluster è ben costruito o meno? Probabilmente no.

Per farti un esempio concreto, diciamo di avere una web app classica composta da un frontend scritto in Nodejs e un backend scritto in Python che usa database MySQL. Distribuisci due servizi corrispondenti sul tuo cluster Kubernetes.

Crei un Dockerfile specificando come impacchettare il software frontend in un contenitore e allo stesso modo impacchetta il tuo backend. Successivamente, nel tuo cluster Kubernetes, distribuirai due servizi ciascuno che esegue un set di pod dietro di esso. Il servizio web può parlare con il cluster di database e viceversa.

Tuttavia, Kubernetes non espone nessuno di questi servizi (che sono endpoint HTTP essenziali) al resto del mondo. Come indicato nei documenti ufficiali:

“Si presume che i servizi abbiano IP virtuali instradabili solo all'interno della rete del cluster"

Questo è perfettamente ragionevole dal punto di vista della sicurezza, i tuoi servizi possono parlare tra loro, ma il cluster non consentirà alle entità esterne di parlare direttamente con i servizi. Ad esempio, solo il tuo frontend web può parlare con il servizio di database e nessun altro può nemmeno inviare richieste al servizio di database.

Il problema sorge quando esaminiamo il caso d'uso di un servizio frontend. Deve essere esposto al resto del pubblico in modo che gli utenti finali possano utilizzare la tua applicazione. Esponiamo tali servizi utilizzando Kubernetes Ingress.

Ingresso Kubernetes

Ingress espone le route HTTP e HTTPS dall'esterno del cluster ai servizi all'interno del cluster. Puoi controllare le regole di routing definendo la risorsa Kubernetes Ingress. Ma fa molto di più. L'esposizione di un singolo servizio può essere ottenuta utilizzando varie altre alternative come NodePort o Load Balancer, ma queste strutture non hanno funzionalità abbastanza sofisticate per un'app Web moderna.

Funzionalità come l'esposizione di più app su un singolo IP, la definizione di percorsi, ecc.

Quindi capiamo queste caratteristiche per il resto dell'articolo:

Ingresso servizio singolo

Questa è la versione più semplice per esporre un singolo servizio come un frontend web con un IP (o un nome di dominio) e porte HTTP e HTTPS predefinite (i.e, 80 e 443).

Fanout singolo

Questa è una configurazione in ingresso che ti consente di consentire il traffico in entrata a un singolo IP e instradarlo a più servizi.

Esso consiste in:

Una risorsa in ingresso è costituita da un nome host foo.bar.come
Un elenco di percorsi in cui il traffico verrà instradato come foo.bar.com/admin foo.bar.com/home foo.bar.com/sso

Il singolo fanout è il caso in cui un singolo IP viene utilizzato per più servizi. I servizi possono trovarsi in percorsi diversi nell'URI come foo.bar.com/admin può essere un servizio per amministratori e foo.bar.com/home può essere il servizio che genera la home page di ogni utente.

La porta di ingresso sarà sempre 80 o 443, ma la porta in cui sono in esecuzione i servizi (all'interno del cluster) potrebbe differire un po'.

Questo tipo di ingresso ci aiuta a ridurre al minimo il numero di bilanciatori di carico nel cluster, poiché essenzialmente agisce come uno.

Hosting virtuale basato sul nome

Gli indirizzi IP pubblici sono limitati. Sono anche piuttosto costosi. L'idea dell'hosting virtuale basato sul nome è più vecchia di Kubernetes. Il succo è che punti i record DNS per diversi siti Web come ww1.esempio.com e ww2.esempio.com allo stesso indirizzo IP. Il server in esecuzione a quell'indirizzo IP vedrà la richiesta in arrivo e se il nome host menzionato nella richiesta è per ww1.esempio.com allora serve quel sito web per te, e se ww2.esempio.com è richiesto, quindi è servito.

Nel contesto di Kubernetes, possiamo eseguire due servizi in esecuzione, ad esempio, sulla porta 80 ed esporli entrambi su un singolo indirizzo IP utilizzando un ingresso anche della porta 80. Al punto di ingresso il traffico di ww1.esempio.com verrà separato dal traffico per la seconda guerra mondiale.esempio.come. Da qui il termine hosting virtuale basato sul nome.

Conclusione

Ingress in Kubernetes è abbastanza sofisticato per essere trattato in un singolo post. Ci sono una varietà di casi d'uso per questo e una varietà di controller Ingress che aggiungeranno la funzionalità Ingress al tuo cluster. Consiglierei di iniziare con Nginx Ingress Controller.

Per ulteriori dettagli e specifiche potete seguire anche la documentazione ufficiale.