Cos'è Kubernetes Ingress?

In questo articolo, esamineremo come e perché potrebbe essere necessario esporre un'applicazione all'esterno del cluster Kubernetes, le diverse opzioni disponibili e le situazioni in cui Kubernetes Ingress è più utile. Questo blog presuppone che tu abbia una conoscenza di base di Kubernetes, ma se hai bisogno di maggiori informazioni di base, consulta le seguenti risorse:

• Cos'è Kubernetes?
• Kubernetes Clusters: Architecture for Rapid, Controlled Cloud App Delivery
• Kubernetes Explained:

Esistono diversi modi per esporre la tua applicazione all'esterno del tuo cluster Kubernetes e dovrai selezionare quello appropriato in base al tuo caso d'uso specifico. 

Le quattro opzioni principali che confronteremo in questo post sono: ClusterIP, NodePort, LoadBalancer e Ingress. Ognuno fornisce un modo per esporre i service ed è utile in diverse situazioni. Un service è essenzialmente un'interfaccia frontend per la tua applicazione che instrada automaticamente il traffico verso i pod disponibili in modo distribuito equamente. I service rappresentano un modo astratto per esporre un'applicazione in esecuzione su un insieme di pod come servizio di rete. I pod sono immutabili, il che significa che quando muoiono non vengono ripristinati. Il cluster Kubernetes crea nuovi pod nello stesso nodo o in un nodo diverso una volta che un pod muore. 

Similmente a pod e distribuzioni, anche i service sono risorse in Kubernetes. Un service fornisce un unico punto di accesso dall'esterno del cluster Kubernetes e consente di accedere dinamicamente a un gruppo di pod replicati. 

Per l'accesso interno alle applicazioni all'interno di un cluster Kubernetes, ClusterIP è il metodo preferito. Si tratta di un'impostazione predefinita in Kubernetes e utilizza un indirizzo IP interno per accedere al service.

Per esporre un service alle richieste di rete esterne, NodePort, LoadBalancer e Ingress sono opzioni possibili. Analizzeremo Ingress per primo e confronteremo i service più avanti nell'articolo.

Kubernetes Ingress è un oggetto API che fornisce regole di routing per gestire l'accesso degli utenti esterni ai servizi in un cluster, in genere tramite HTTPS/HTTP. Con Ingress, è possibile impostare facilmente regole per il routing del traffico senza creare una serie di Load Balancer o esporre ogni service sul nodo. Questo lo rende l'opzione migliore da utilizzare negli ambienti di produzione. 

Negli ambienti di produzione, in genere è necessario il routing basato sul contenuto, il supporto per più protocolli e l'autenticazione. Ingress consente di configurare e gestire queste funzionalità all'interno del cluster.

Ingress è composto da un oggetto API Ingress e dal controller Ingress. Come abbiamo detto, Kubernetes Ingress è un oggetto API che descrive lo stato desiderato per esporre i service all'esterno del cluster Kubernetes. Un controller Ingress è essenziale perché è l'effettiva implementazione dell'API Ingress. Un controller Ingress legge ed elabora le informazioni sulle risorse Ingress e di solito viene eseguito come pod all'interno del cluster Kubernetes.

Un Ingress fornisce quanto segue:

• URL raggiungibili esternamente per le applicazioni implementate nei cluster Kubernetes
• Supporto per il routing basato su nomi di host virtuali e URI
• Regole di bilanciamento del carico, gestione del traffico e terminazione SSL

Per una rapida panoramica visiva di Kubernetes Ingress, guarda il seguente video:

Se Kubernetes Ingress è l'oggetto API che fornisce le regole di routing per gestire l'accesso esterno ai service, il controller Ingress è l'implementazione effettiva dell'API Ingress. Il controller Ingress è di solito un sistema di bilanciamento del carico per indirizzare il traffico esterno verso il cluster Kubernetes ed è responsabile dei servizi di rete L4-L7. 

Il livello 4 (L4) si riferisce al livello di connessione dello stack di rete OSI: connessioni esterne con bilanciamento del carico tra i pod, in modo rotatorio. Il livello 7 (L7) si riferisce al livello di applicazione dello stack OSI: connessioni esterne con bilanciamento del carico tra i pod, in base alle richieste. Il livello 7 è spesso preferito, ma è consigliabile selezionare un controller Ingress che soddisfi i requisiti di bilanciamento del carico e routing.

Il controller Ingress è responsabile della lettura delle informazioni sulle risorse Ingress e del trattamento di tali dati di conseguenza. Di seguito è riportato un esempio di risorsa Ingress:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress 
spec:
  backend:
    serviceName:ServiceName
    servicePort:<Port Number>

Per analogia, se Kubernetes Ingress è un computer, il controller Ingress è un programmatore che usa il computer e agisce. Inoltre, le regole Ingress agiscono come il manager che ordina al programmatore di svolgere il lavoro utilizzando il computer. Le regole Ingress sono un insieme di regole per l'elaborazione del traffico HTTP in entrata. Un Ingress senza regole invia tutto il traffico a un singolo servizio backend predefinito. 

Guardando più a fondo, il controller Ingress è un'applicazione che viene eseguita in un cluster e configura un load balancer HTTP secondo le risorse Ingress. Il load balancer può essere un load balancer software in esecuzione nel cluster o un load balancer hardware o cloud eseguito esternamente. Diversi sistemi di bilanciamento del carico richiedono diverse implementazioni di controller Ingress.

Sul mercato sono disponibili diversi controller Ingress ed è importante scegliere quello giusto per gestire il traffico e il carico in arrivo nel tuo cluster Kubernetes.

Ingress, ClusterIP, NodePort e LoadBalancer sono tutti metodi per far entrare traffico esterno nel cluster, e ognuno lo fa in modo diverso. Diamo un'occhiata a come funzionano e dove li useresti.

ClusterIP

ClusterIP è l'opzione preferita per l'accesso interno al service e utilizza un indirizzo IP interno per accedere al service. Alcuni esempi in cui ClusterIP potrebbe essere l'opzione migliore includono il debug dei service durante lo sviluppo e il test, il traffico interno e le dashboard.

NodePort

Un NodePort è una macchina virtuale (VM) utilizzata per esporre un service su un numero di porta statico. Viene utilizzato principalmente per esporre i service in un ambiente non di produzione (in effetti, l'uso in produzione non è consigliato). Ad esempio, un NodePort verrebbe utilizzato per esporre un singolo service (senza requisiti di bilanciamento del carico per più service).

Bilanciamento del carico

Questo metodo utilizza un LoadBalancer esterno per esporre i service a Internet. È possibile utilizzare LoadBalancer in un ambiente di produzione, ma spesso è preferibile Ingress.

Ingress

Ingress consente di consolidare le regole di routing del traffico in una singola risorsa e viene eseguito come parte di un cluster Kubernetes. Di seguito sono riportati alcuni motivi per cui Kubernetes Ingress è l'opzione preferita per l'esposizione di un service in un ambiente di produzione:

• Il routing del traffico è controllato da regole definite nella risorsa Ingress.
• Ingress fa parte del cluster Kubernetes e funziona come pod.
• Un Load Balancer esterno è costoso e deve essere gestito al di fuori del cluster Kubernetes. Kubernetes Ingress è gestito dall'interno del cluster.

Negli ambienti di produzione, in genere si usa Ingress per esporre le applicazioni a Internet. Si accede a un'applicazione da Internet tramite la porta 80 (HTTP) o la porta 443 (HTTPS) e Ingress è un oggetto che consente l'accesso ai tuoi service Kubernetes dall'esterno del cluster. 

L'API Kubernetes Ingress consente di esporre le applicazioni implementate in un cluster Kubernetes a Internet con regole di routing in un'unica fonte. Per implementare Ingress, devi configurare un controller Ingress nel tuo cluster: è responsabile dell'elaborazione delle informazioni sulle risorse Ingress e della autorizzazione del traffico in base alle regole Ingress. È importante scegliere il service corretto con una configurazione appropriata per esporre l'applicazione a Internet in base alle linee guida elencate in precedenza.