operatore ingress

L 'operatore Red Hat OpenShift Ingress implementa regole di routing che vengono applicate a tutto il traffico in entrata per le app nel cluster.

I controller Ingress sono gestiti dall'operatore Ingress. Durante la creazione del cluster, il controller Ingress predefinito viene registrato con il sottodominio Ingress predefinito del cluster nel formato <cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud. Quando registri la tua app su questo sottodominio creando una risorsa Route, il controller Ingress garantisce che le richieste indirizzate alla tua app tramite questo sottodominio vengano correttamente inoltrate ai pod della tua app. Per visualizzare il controller Ingress predefinito nel tuo cluster, esegui oc describe ingresscontroller/default -n openshift-ingress-operator.

Se vuoi registrare la tua applicazione con un dominio differente, puoi invece creare un controller Ingress personalizzato che implementa le regole di instradamento per un dominio personalizzato.

Controller Ingress

Viene creato un controller Ingress Red Hat OpenShift basato su HAProxy One per ciascuno IngressController, e un servizio controller Ingress in ciascuna zona in cui sono presenti nodi di lavoro.

L'operatore Ingress configura il controller Ingress con lo stesso dominio specificato nel file IngressController. Il controller Ingress è in ascolto delle richieste di servizio in entrata HTTP, HTTPS o TCP provenienti da quel dominio. Il componente di bilanciamento del carico del controller Ingress inoltra quindi le richieste ai pod relativi a quella specifica applicazione, esclusivamente in base alle regole definite nella risorsa Route e implementate dal controller Ingress.

Se hai un cluster multizona, un controller Ingress ad alta disponibilità viene distribuito al tuo cluster e configurato con un programma di bilanciamento del carico VPC multizona. Sono necessari due nodi di lavoro per ogni zona, affinché le due repliche del controller Ingress possano essere distribuite e aggiornate correttamente.

Se crei manualmente un controller Ingress, il controller Ingress non viene registrato automaticamente con il dominio secondario Ingress o con un'applicazione nel tuo cluster.

Risorsa instradamento

Per rendere accessibile un'app tramite Route, è necessario creare un servizio Kubernetes per l'app e registrare tale servizio presso il controller Ingress definendo una risorsa Route. La risorsa Ingress è una risorsa di tipo " Red Hat OpenShift " che definisce le regole per l'instradamento delle richieste in entrata destinate alle app.

La risorsa Route specifica inoltre il percorso dei servizi della tua app. I percorsi ai tuoi servizi dell'applicazione sono accodati al dominio secondario Ingress dl tuo cluster per formare un URL applicazione univoco come mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud/myapp1.

È necessaria una risorsa Route per ogni progetto in cui sono presenti app che si desidera rendere accessibili.

• Se le app presenti nel cluster fanno tutte parte dello stesso progetto, è necessario creare una risorsa Route per definire le regole di instradamento relative alle app che si desidera rendere accessibili. Nota che, se vuoi utilizzare dei domini differenti per le applicazioni nello stesso progetto, puoi creare una singola risorsa per ogni dominio.
• Se le app presenti nel cluster appartengono a progetti diversi, è necessario creare una risorsa Route per ciascun progetto al fine di definire le regole di instradamento dell'app.

Per ulteriori informazioni, vedi Pianificazione della rete per progetti singoli o multipli.

Se desideri personalizzare le regole di routing per la tua app, puoi utilizzare le annotazioni " HAProxy " specifiche per ogni route, che gestiscono il traffico della tua app. Queste annotazioni supportate sono nel formato haproxy.router.openshift.io/<annotation> o router.openshift.io/<annotation>. Si noti che le annotazioni " IBM Cloud Kubernetes Service " (ingress.bluemix.net/<annotation>) e " NGINX " (nginx.ingress.kubernetes.io/<annotation>) non sono supportate per il controller Ingress né per la risorsa Route nella versione 4 di Red Hat OpenShift.

Cluster a zona singola

Il seguente diagramma mostra in che modo Ingress indirizza le comunicazioni da Internet a un'applicazione in un cluster a zona singola classico.

1. Un utente invia una richiesta alla tua applicazione accedendo all'URL dell'applicazione. Questo URL è il sottodominio Ingress del tuo cluster, seguito dal percorso della risorsa Ingress relativa alla tua app esposta, ad esempio mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp.

2. Un servizio DNS risolve il sottodominio URL nell'indirizzo IP pubblico portabile del bilanciatore di carico che espone il controller Ingress nel proprio cluster.

3. In base all'indirizzo IP risolto, il client invia la richiesta al servizio del controller Ingress.

4. Il controller Ingress verifica le regole di instradamento da esso implementate alla ricerca di una regola di instradamento per il percorso myapp. Se viene individuata una regola corrispondente, la richiesta viene inoltrata tramite proxy, in base alle regole definite nel controller Ingress e nella risorsa Route, al pod in cui è distribuita l'applicazione. L'indirizzo IP di origine del pacchetto viene modificato in modo da corrispondere all'indirizzo IP del nodo worker su cui è in esecuzione il pod del controller Ingress. Se nel cluster sono distribuite più istanze dell'applicazione, il controller Ingress distribuisce il carico delle richieste tra i pod dell'applicazione.

5. Quando l'app restituisce un pacchetto di risposta, utilizza l'indirizzo IP del nodo worker su cui si trova il controller Ingress che ha inoltrato la richiesta. Il controller Ingress invia quindi il pacchetto di risposta al client.

Cluster multizona

Il seguente diagramma mostra in che modo Ingress indirizza le comunicazioni da Internet a un'applicazione in un cluster multizona classico.

1. Un utente invia una richiesta alla tua applicazione accedendo all'URL dell'applicazione. Questo URL è il sottodominio Ingress del tuo cluster, seguito dal percorso della risorsa Ingress relativa alla tua app esposta, ad esempio mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp.

2. Un servizio del sistema DNS risolve il sottodominio di instradamento nell'indirizzo IP pubblico flottante di un servizio di controller Ingress che è stato segnalato come funzionante dall'MZLB. L'MZLB verifica costantemente gli indirizzi IP pubblici portabili dei servizi che espongono il controller Ingress in ciascuna zona del cluster. Le richieste vengono gestite dai servizi del controller Ingress presenti in varie zone secondo un ciclo round-robin.

3. Il client invia la richiesta all'indirizzo IP del servizio che espone il controller Ingress.

4. Il controller Ingress verifica le regole di instradamento da esso implementate per il percorso myapp. Se viene individuata una regola corrispondente, la richiesta viene inoltrata tramite proxy, in base alle regole definite nel file IngressController e nella risorsa Route, al pod in cui è distribuita l'applicazione. L'indirizzo IP di origine del pacchetto viene modificato in modo da corrispondere all'indirizzo IP del nodo worker su cui è in esecuzione il pod del controller Ingress. Se nel cluster sono distribuite più istanze dell'applicazione, il servizio del controller Ingress inoltra le richieste tra i pod dell'applicazione in tutte le zone.

5. Quando l'app restituisce un pacchetto di risposta, utilizza l'indirizzo IP del nodo worker su cui è in esecuzione il servizio del controller Ingress che ha inoltrato la richiesta. Il controller Ingress invia quindi il pacchetto di risposta al client.

Cluster VPC con un endpoint di servizio nel cloud pubblico

Quando si crea un cluster VPC multizona con l'endpoint del servizio cloud pubblico abilitato, viene creato per impostazione predefinita un controller Ingress pubblico. Il seguente diagramma mostra in che modo Ingress indirizza le comunicazioni da Internet a un'applicazione in un cluster multizona VPC.

1. Un utente invia una richiesta alla tua applicazione accedendo all'URL dell'applicazione. Questo URL è il sottodominio Ingress del cluster dell'app esposta, a cui è stato aggiunto il percorso della risorsa Ingress, ad esempio mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp.

2. Un servizio DNS risolve il sottodominio "route" nel nome host del bilanciatore di carico VPC assegnato al controller Ingress. Nei cluster VPC, gli indirizzi IP esterni sono fluttuanti e vengono gestiti tramite un nome host assegnato dal VPC.

3. Il programma di bilanciamento del carico VPC risolve il nome host VPC in un indirizzo IP disponibile in una zona per il controller Ingress che è stato segnalato come integro. Il bilanciatore di carico VPC verifica costantemente gli indirizzi IP esterni del controller Ingress in ciascuna zona del cluster.

4. In base all'indirizzo IP identificato, il bilanciatore di carico VPC invia la richiesta a un controller Ingress.

5. Il controller Ingress verifica le regole di instradamento da esso implementate per il percorso myapp. Se viene individuata una regola corrispondente, la richiesta viene inoltrata tramite proxy, in base alle regole definite nel file IngressController e nella risorsa Route, al pod in cui è distribuita l'applicazione. L'indirizzo IP di origine del pacchetto viene modificato in modo da corrispondere all'indirizzo IP del nodo worker su cui è in esecuzione il pod del controller Ingress. Se nel cluster sono distribuite più istanze dell'applicazione, il controller Ingress bilancia il carico delle richieste tra i pod dell'applicazione in tutte le zone.

6. Quando l'app restituisce un pacchetto di risposta, utilizza l'indirizzo IP del nodo worker su cui è in esecuzione il servizio del controller Ingress che ha inoltrato la richiesta. Il programma di bilanciamento del carico VPC invia quindi il pacchetto di risposta al client.

Cluster VPC con solo un endpoint del servizio cloud privato

Quando si crea un cluster VPC multizona utilizzando esclusivamente l'endpoint del servizio cloud privato, viene creato per impostazione predefinita un controller Ingress privato. Solo i client connessi alla tua rete VPC privata possono accedere alle applicazioni esposte da un controller Ingress privato. Il seguente diagramma mostra in che modo Ingress indirizza le comunicazioni dalle reti private a un'applicazione in un cluster multizona VPC.

1. Un client connesso alla tua rete VPC privata invia una richiesta alla tua applicazione utilizzando l'URL dell'applicazione. Questo URL è il sottodominio Ingress del cluster dell'app esposta, a cui è stato aggiunto il percorso della risorsa Ingress, ad esempio mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp. Ad esempio, potresti utilizzare la VPN Virtual Private Cloud, IBM Cloud Transit Gateway o IBM Cloud Direct Link per consentire le richieste da una rete in loco, da un altro VPC o dall'infrastruttura classica IBM Cloud alle applicazioni che vengono eseguite nel tuo cluster.

2. Un servizio DNS risolve il sottodominio "route" nell'hostname del bilanciatore di carico VPC assegnato ai servizi del controller Ingress. Nei cluster VPC, gli indirizzi IP privati dei servizi del controller Ingress sono fluttuanti e vengono gestiti tramite un nome host assegnato dalla VPC. Tieni presente che sebbene il record DNS per il dominio secondario di instradamento sia registrato nel sistema DNS pubblico, i server di risoluzione DNS sono raggiungibili dal VPC.

3. Il bilanciatore di carico privato della VPC risolve il nome host della VPC in un indirizzo IP privato disponibile di un servizio di controller Ingress che è stato segnalato come funzionante. Il bilanciatore di carico VPC verifica costantemente gli indirizzi IP dei servizi che espongono il controller Ingress in ciascuna zona del cluster.

4. In base all'indirizzo IP identificato, il bilanciatore di carico VPC invia la richiesta a un servizio di controller Ingress.

5. Il controller Ingress verifica le regole di instradamento da esso implementate per il percorso myapp. Se viene individuata una regola corrispondente, la richiesta viene inoltrata tramite proxy, in base alle regole definite nel file IngressController e nella risorsa Route, al pod in cui è distribuita l'applicazione. L'indirizzo IP di origine del pacchetto viene modificato in modo da corrispondere all'indirizzo IP del nodo worker su cui è in esecuzione il pod del controller Ingress. Se nel cluster sono distribuite più istanze dell'applicazione, il controller Ingress bilancia il carico delle richieste tra i pod dell'applicazione in tutte le zone.

6. Quando l'app restituisce un pacchetto di risposta, utilizza l'indirizzo IP del nodo worker su cui si trova il controller Ingress che ha inoltrato la richiesta del client. Il controller Ingress invia quindi il pacchetto di risposta al client tramite il bilanciatore di carico VPC.