Ingress - NGINX in IBM Cloud
Ingress è un metodo di scoperta dei servizi Kubernetes che espone i servizi del cluster alla rete pubblica o privata, inoltrando le richieste alle applicazioni e bilanciando i carichi di lavoro del traffico di rete. Ingress gestisce l'accesso esterno ai tuoi servizi in base a una serie di regole di instradamento che configuri e che vengono applicate a tutto il traffico in entrata.
Quando esegui il provisioning di un cluster IBM Cloud Kubernetes Service, IBM fornisce tutti i componenti necessari per utilizzare Ingress. Quindi, quando sei pronto per iniziare, crei una risorsa Ingress per specificare come funzionano insieme questi componenti.
Per ulteriori informazioni su Kubernetes Ingress, consulta la documentazione diKubernetes.
Componenti Ingress forniti da IBM
Tutti i componenti richiesti per utilizzare Ingress vengono forniti per te quando crei un cluster. Specifica questi componenti quando crei la tua risorsa Ingress.
- Dominio ingresso
- classe Ingress
- ALB (Application Load Balancer)
- Certificato TLS
Dominio ingresso
Il dominio di Ingress predefinito viene utilizzato per formare un URL unico per ogni applicazione nel cluster ed è il dominio a cui fanno riferimento gli indirizzi IP di tutti gli ALB del cluster. Quando crei un cluster, un dominio secondario Ingress univoco viene creato automaticamente e registrato come dominio predefinito. Puoi modificare il dominio predefinito in qualsiasi dominio esistente nel tuo cluster.
È inoltre possibile creare o aggiungere un proprio dominio registrato presso il provider interno di domini IBM Cloud o presso un provider esterno IBM Cloud Internet Services.
Gli ALB privati non fanno riferimento al sottodominio Ingress fornito da IBM e richiedono invece un dominio personalizzato.
Il sottodominio è registrato nel seguente formato.
<cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud
La tabella seguente descrive ciascuna parte del sottodominio.
| Componente del dominio secondario | Descrizione |
|---|---|
<cluster_name> |
Il nome del tuo cluster.
|
<globally_unique_account_HASH> |
Viene creato un HASH univoco a livello globale per il tuo account IBM Cloud, Tutti i domini secondari che crei per gli NLB nei cluster nel tuo account utilizzano questo HASH univoco a livello globale. |
0000 |
Agisce come contatore per ogni sottodominio creato nel tuo cluster. |
<region> |
La regione in cui viene creato il cluster. |
containers.appdomain.cloud |
Il dominio secondario per i domini secondari IBM Cloud Kubernetes Service. |
Per formare un URL univoco per ciascuna applicazione, i percorsi dei servizi della tua applicazione vengono accodati alla rotta pubblica. Ad esempio, vedi il seguente URLdell'applicazione.
mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud/myapp1
classe Ingress
La classe Ingress determina il tipo di controller Ingress utilizzato. IBM fornisce due classi Ingress, una pubblica (public-iks-k8s-nginx) e una privata (private-iks-k8s-nginx). Entrambe le classi implementano il
controllore di ingress NGINX. Quando crei la tua risorsa Ingress, la classe Ingress che specifichi determina se le tue applicazioni sono esposte pubblicamente o privatamente.
Puoi utilizzare una classe Ingress personalizzata creando la tua propria risorsa IngressClass.
ALB (Application Load Balancer)
Gli ALB ascoltano le richieste di servizio HTTP, HTTPS o TCP in arrivo e le inoltrano all'app pod appropriata in base alle regole definite nella risorsa Ingress. Quando crei un cluster standard con un'infrastruttura classica o VPC, un ALB pubblico e un privato vengono creati automaticamente per te in ciascuna zona.
ALB nei cluster classici
Quando crei un cluster classico, un ALB pubblico e uno privato vengono creati automaticamente per te in ogni zona. Agli ALB pubblici e privati nei cluster classici viene assegnato un indirizzo IP statico che non cambia per tutta la durata del cluster.
Gli ALB pubblici condividono lo stesso dominio secondario Ingress fornito da IBMregistrato per te quando esegui il provisioning di un cluster e ogni indirizzo IP singolo dell'ALB pubblico è collegato a questo dominio secondario. Per trovare
l'indirizzo IP di un ALB pubblico, esegui ibmcloud ks ingress alb ls e controlla il campo ALB IP nell'output.
Gli ALB privati nei cluster classici non utilizzano il sottodominio Ingress fornito da IBMe non sono abilitati automaticamente. Devi prima abilitare gli ALB privati nella CLI e quindi specificare la classe private-iks-k8s-nginx nella tua risorsa Ingress. Una volta abilitati gli ALB privati, puoi trovare gli indirizzi IP privati eseguendo ibmcloud ks ingress alb ls e controllando il campo ALB IP nell'output.
Se un pod ALB pubblico o privato viene ripianificato, conserva lo stesso indirizzo IP. Tuttavia, la rimozione di una zona con un ALB o la rimozione di tutti i nodi di lavoro su una VLAN in tale zona, rimuove l'indirizzo IP di tale ALB.
ALB in VPC
Quando crei un cluster VPC, in ogni zona vengono creati automaticamente un ALB pubblico e uno privato. Inoltre, un programma di bilanciamento del carico VPC pubblico viene creato automaticamente al di fuori del tuo cluster nel VPC. Quando abiliti gli ALB privati nel tuo cluster VPC, viene creato anche un programma di bilanciamento del carico VPC privato.
Gli indirizzi IP per gli ALB nei cluster VPC non sono statici e potrebbero cambiare nel tempo, pertanto i programmi di bilanciamento del carico VPC inseriscono l'indirizzo IP pubblico o privato dei tuoi ALB dietro un nome host statico. I nomi host separati vengono applicati per gli ALB pubblici o privati. Tieni presente che il nome host ALB è separato dal dominio secondario Ingress del cluster.
Per trovare il nome host di un ALB in un cluster VPC, esegui ibmcloud ks ingress alb ls. I nomi host privati vengono elencati solo se sono abilitati gli ALB privati.
Requisiti del nodo di lavoro per ALB
Sono richiesti almeno due nodi di lavoro per zona nel tuo cluster affinché gli ALB funzionino con l'alta disponibilità e ricevano aggiornamenti periodici. Le regole anti - affinità sui pod ALB assicurano che solo un pod sia pianificato per ogni nodo di lavoro. Quando vengono applicati gli aggiornamenti automatici ai pod ALB, il pod viene ricaricato. Se hai solo un nodo di lavoro e quindi un pod ALB, il pod non si aggiorna automaticamente per evitare interruzioni del traffico e gli aggiornamenti si applicano solo quando elimini manualmente il pod e ne ripianifichi uno nuovo. Avere almeno due nodi di lavoro per zona evita questo scenario.
Si noti che, in caso di guasto di una zona, potrebbero verificarsi interruzioni intermittenti nelle richieste all'ALB Ingress in quella zona.
Certificato predefinito TLS
Quando si crea un cluster, viene creato un certificato predefinito TLS che può essere utilizzato con il sottodominio Ingress IBM fornito. È possibile specificare il certificato predefinito di TLS o un certificato personalizzato fornito dall'utente nella risorsa Ingress.
Considerate l'utilizzo di Secrets Manager per gestire centralmente e aggiornare automaticamente i certificati dei sottodomini Ingress e altri segreti.
L'impostazione di Ingress con i certificati TLS comporta la creazione o l'importazione di segreti. Se si desidera utilizzare l'API IBM Cloud Ingress per completare questi passaggi, è necessario disporre di un'istanza Secrets Manager predefinita.
Altrimenti, è possibile utilizzare i comandi kubectl per copiare i certificati.
Introduzione a Ingress
Quando sei pronto a utilizzare Ingress nel tuo cluster, crea una risorsa Ingress per configurare i tuoi componenti Ingress, definire regole per l'instradamento delle richieste e specificare il percorso ai servizi dell'applicazione. È richiesta una risorsa Ingress separata per ogni spazio dei nomi che contiene un'applicazione o un servizio che vuoi esporre.