Traefik Ingress in IBM Cloud
Ingress rende accessibili i servizi presenti nel cluster a una rete pubblica o privata. Inoltra le richieste alle tue app e gestisce l'accesso esterno in base alle regole di instradamento da te configurate.
Quando si configura un cluster IBM Cloud Kubernetes Service, è possibile abilitare uno o più controller Ingress basati su Traefik. IBM fornisce i componenti necessari per utilizzare il controller Ingress. Per definire come i componenti interagiscono tra loro, crea delle risorse Ingress.
Per ulteriori informazioni su Ingress di Kubernetes, consulta la documentazione all'indirizzo Kubernetes.
IBM-componenti Ingress forniti
Quando si crea un cluster, IBM fornisce i componenti necessari per utilizzare Ingress. Nella risorsa Ingress si specifica come vengono utilizzati questi componenti.
- Dominio ingresso
- Classe di Ingress
- ALB (Application Load Balancer)
- Certificato TLS
Dominio ingresso
Il dominio Ingress predefinito crea un URL univoco per ogni app presente nel cluster. Questo dominio è associato agli indirizzi IP di tutti gli ALB presenti nel cluster.
Quando si crea un cluster, viene automaticamente generato un sottodominio Ingress univoco, che viene registrato come dominio predefinito. È possibile modificare il dominio predefinito sostituendolo con qualsiasi dominio presente nel proprio cluster.
Gli ALB privati non fanno riferimento al sottodominio Ingress fornito da IBM, ma richiedono invece un dominio personalizzato.
È inoltre possibile creare o aggiungere un proprio dominio registrato presso il provider di domini interno di IBM Cloud oppure presso un provider esterno IBM Cloud Internet Services.
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 cluster.
|
<globally_unique_account_HASH> |
Viene creato un HASH univoco a livello globale per il tuo account IBM Cloud, Tutti i sottodomini creati per gli NLB nei cluster presenti nel proprio account utilizzano questo hash. |
0000 |
Funge da contatore per ogni sottodominio creato nel 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 generare un URL unico ( URL ) per ogni app, i percorsi dei servizi dell'app vengono aggiunti alla route pubblica. Ad esempio, dai un'occhiata alla seguente app URL.
mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud/myapp1
Classe di Ingress
La classe Ingress determina il tipo di controller Ingress utilizzato. IBM mette a disposizione due classi Ingress: una pubblica (public-iks-traefik) e una privata (private-iks-traefik). Entrambe le classi implementano
il controller Ingress di Traefik. Quando crei la tua risorsa Ingress, la classe Ingress che specifichi determina se le tue app saranno accessibili pubblicamente o privatamente.
È possibile utilizzare una classe Ingress personalizzata configurando ingressClass nella configurazione di distribuzione personalizzabile.
ALB (Application Load Balancer)
Gli ALB ascoltano le richieste in entrata rivolte ai servizi HTTP, HTTPS o TCP e le inoltrano al pod dell'applicazione appropriato in base alle regole definite nella risorsa Ingress.
Quando si crea un cluster standard con infrastruttura classica o VPC, in ogni zona vengono creati automaticamente un ALB pubblico e uno privato.
ALB nei cluster classici
Quando si crea un cluster classico, in ogni zona vengono creati automaticamente un ALB pubblico e uno privato. Agli ALB pubblici e privati nei cluster classici viene assegnato un indirizzo IP statico che rimane invariato per tutta la durata del cluster.
Gli ALB pubblici condividono lo stesso sottodominio Ingress fornito da IBM, registrato a nome dell'utente al momento della creazione di un cluster, e l'indirizzo IP individuale di ciascun ALB pubblico è associato a tale sottodominio. Per
individuare l'indirizzo IP di un ALB pubblico, eseguire il comando ibmcloud ks ingress alb ls e controllare il campo " ALB IP " nell'output.
Gli ALB privati nei cluster classici non utilizzano il sottodominio Ingress fornito da IBM e non vengono abilitati automaticamente. È necessario innanzitutto abilitare gli ALB privati nella CLI e poi specificare la classe private-iks-traefik nella risorsa Ingress. Una volta abilitati gli ALB privati, è possibile individuare gli indirizzi IP privati eseguendo il comando ibmcloud ks ingress alb ls e controllando il campo "ALB IP " nell'output.
Se un pod ALB pubblico o privato viene riprogrammato, mantiene lo stesso indirizzo IP. Tuttavia, la rimozione di una zona con un ALB, oppure la rimozione di tutti i worker presenti su una VLAN all’interno di quella zona, comporta la rimozione dell’indirizzo IP di quell’ALB.
ALB nel VPC
Quando si crea un cluster VPC, in ogni zona vengono creati automaticamente un ALB pubblico e uno privato. Inoltre, all'interno della VPC viene creato automaticamente un bilanciatore di carico VPC pubblico al di fuori del cluster. Quando si abilitano gli ALB privati nel proprio cluster VPC, viene creato anche un bilanciatore di carico VPC privato.
Gli indirizzi IP degli ALB nei cluster VPC non sono statici e potrebbero cambiare nel tempo. Pertanto, i bilanciatori di carico VPC associano l'indirizzo IP pubblico o privato dei vostri ALB a un nome host statico. Per gli ALB pubblici e privati vengono utilizzati nomi host distinti. Il nome host dell'ALB è distinto dal sottodominio Ingress del cluster.
Per individuare il nome host di un ALB in un cluster VPC, eseguire il comando ibmcloud ks ingress alb ls``. I nomi host privati vengono elencati solo se sono abilitati gli ALB privati.
Requisiti dei nodi di lavoro per gli ALB
Per garantire l'alta disponibilità degli ALB e consentire loro di ricevere aggiornamenti periodici, sono necessari almeno due nodi di lavoro per ogni zona del cluster.
Le regole anti-affinità sui pod ALB garantiscono che venga pianificato un solo pod per ogni nodo di lavoro. Quando vengono applicati gli aggiornamenti automatici ai pod ALB, il pod viene ricaricato.
Se si dispone di un solo nodo di lavoro, e quindi di un solo pod ALB, il pod non si aggiorna automaticamente per evitare interruzioni del traffico. In tal caso, gli aggiornamenti vengono applicati solo quando si elimina manualmente il pod e se ne pianifica uno nuovo. Avere almeno due nodi di lavoro per zona permette di evitare questa situazione.
Si noti che, in caso di guasto di una zona, potrebbero verificarsi interruzioni intermittenti nelle richieste all'ALB Ingress in quella zona.
Certificato predefinito di TLS
Quando si crea un cluster, viene generato un certificato predefinito TLS che è possibile utilizzare con il sottodominio Ingress fornito da IBM. È possibile specificare sia il certificato predefinito TLS sia un certificato personalizzato fornito nella risorsa Ingress.
Ti consigliamo di utilizzare Secrets Manager per gestire centralmente e aggiornare automaticamente i certificati dei sottodomini di Ingress e altre informazioni riservate.
La configurazione di Ingress con i certificati " TLS " comporta la creazione o l'importazione di segreti. Se desideri utilizzare l'API Ingress di IBM Cloud per completare questi passaggi, devi disporre di un'istanza predefinita di
Secrets Manager. In alternativa, puoi utilizzare i comandi kubectl per copiare i tuoi certificati.
Guida introduttiva a Ingress
Quando sei pronto a utilizzare Ingress nel tuo cluster, crea una risorsa Ingress per configurare i componenti di Ingress, definire le regole di instradamento delle richieste e specificare il percorso dei servizi dell'app. È necessaria una risorsa Ingress distinta per ogni namespace che contenga un'app o un servizio che si desidera rendere accessibile.