Componenti gateway applicativo per contenitori

Questo articolo fornisce descrizioni dettagliate e requisiti per i componenti del gateway applicazione per i contenitori. Informazioni sul modo in cui il gateway applicazione per contenitori accetta le richieste in ingresso e le instrada in una destinazione back-end. Per una panoramica generale delle gateway applicazione per i contenitori, vedere Che cos'è gateway applicazione per i contenitori.

Componenti principali

• Una gateway applicazione per la risorsa Contenitori è una risorsa padre di Azure che distribuisce il piano di controllo.
• Il pannello di controllo è responsabile dell'orchestrazione della configurazione del proxy in base alla finalità del cliente.
• gateway applicazione per Contenitori include due risorse figlio, le associazioni e i front-end.
  • Le risorse figlio sono esclusive solo dei gateway applicazione padre per i contenitori e potrebbero non essere referenziate da un'altra gateway applicazione per la risorsa Contenitore.

Gateway applicazione per i front-end dei contenitori

• Una gateway applicazione per la risorsa front-end contenitori è una risorsa figlio di Azure della gateway applicazione per la risorsa padre contenitori.
• Un gateway applicazione per il front-end contenitori definisce che il traffico client del punto di ingresso deve essere ricevuto da un determinato gateway applicazione per contenitori.
  • Un front-end non può essere associato a più gateway applicazione per contenitori.
  • Ogni front-end fornisce un FQDN univoco a cui è possibile fare riferimento tramite il record CNAME di un cliente.
  • Gli indirizzi IP privati non sono attualmente supportati.
• Una singola gateway applicazione per contenitori può supportare più front-end.

Gateway applicazione per le associazioni di contenitori

• Una gateway applicazione per la risorsa di associazione Contenitori è una risorsa figlio di Azure del gateway applicazione per la risorsa padre Contenitori.
• Un'associazione gateway applicazione per contenitori definisce un punto di connessione in una rete virtuale. Un'associazione è un mapping 1:1 di una risorsa di associazione a una subnet di Azure delegata.
• gateway applicazione per contenitori è progettato per consentire più associazioni.
  • Al momento, il numero corrente di associazioni è attualmente limitato a 1.
• Durante la creazione di un'associazione, viene effettuato il provisioning del piano dati sottostante e viene connesso a una subnet all'interno della subnet della rete virtuale definita.
• Ogni associazione deve presupporre che almeno 256 indirizzi siano disponibili nella subnet al momento del provisioning.
  • Subnet mask minima /24 per ogni distribuzione (presupponendo che non sia stato eseguito il provisioning di risorse nella subnet).
    • Se viene effettuato il provisioning di un numero indefinito di gateway applicazione per contenitori, presupponendo che ogni gateway applicazione per contenitori contenga un'associazione e che la finalità sia condividere la stessa subnet, gli indirizzi necessari disponibili devono essere 256.
  • Tutte le gateway applicazione per le risorse di associazione contenitori devono corrispondere alla stessa area del gateway applicazione per la risorsa padre Contenitori.

Gateway applicazione per contenitori CONTROLLER ALB

• Un gateway applicazione per contenitori ALB Controller è una distribuzione Kubernetes che orchestra la configurazione e la distribuzione del gateway applicazione per i contenitori guardando Kubernetes sia risorse personalizzate che configurazioni delle risorse, ad esempio, in ingresso, gateway e ApplicationLoadBalancer. Usa entrambe le API di configurazione ARM/gateway applicazione per contenitori per propagare la configurazione al gateway applicazione per la distribuzione di Azure per contenitori.
• Il controller ALB viene distribuito/installato tramite Helm.
• Il controller ALB è costituito da due pod in esecuzione.
  • il pod alb-controller è responsabile dell'orchestrazione della finalità del cliente di gateway applicazione per la configurazione del bilanciamento del carico dei contenitori.
  • alb-controller-bootstrap pod è responsabile della gestione dei CRL.

Concetti generali di Azure

Indirizzo IP privato

• Un indirizzo IP privato non è definito in modo esplicito come risorsa di Azure Resource Manager. Un indirizzo IP privato fa riferimento a un indirizzo host specifico all'interno di una determinata subnet della rete virtuale.

Delega subnet

• Microsoft.ServiceNetworking/trafficControllers è lo spazio dei nomi adottato dal gateway applicazione per contenitori e può essere delegato alla subnet di una rete virtuale.
• Quando si verifica la delega, il provisioning del gateway applicazione per le risorse contenitori né avviene, né esiste un mapping esclusivo per una risorsa di associazione del gateway applicazione per contenitori.
• Qualsiasi numero di subnet può avere una delega di subnet uguale o diversa da gateway applicazione per contenitori. Una volta definito il provisioning, non è possibile effettuarlo per altre risorse diverse dal servizio definito nella subnet, a meno che non venga definito in modo esplicito dall'implementazione del servizio.

Identità gestita assegnata dall'utente

• Le identità gestite per le risorse di Azure eliminano la necessità di gestire le credenziali nel codice.
• Per ogni controller di Azure Load Balancer è necessaria un'identità gestita dall'utente per apportare modifiche ai gateway applicazione per i contenitori.
• AppGw per contenitori Configuration Manager è un ruolo controllo degli accessi in base al ruolo predefinito che consente al controller ALB di accedere e configurare la risorsa gateway applicazione per contenitori.

Nota

Il ruolo AppGw per Contenitori di Configuration Manager dispone di autorizzazioni per l'azione dati non disponibili nei ruoli Proprietario e Collaboratore. È fondamentale delegare le autorizzazioni appropriate per evitare problemi con il controller ALB che apporta modifiche al servizio Gateway applicazione per contenitori.

Modalità di accettazione di una richiesta da parte del gateway applicazione per contenitori

Ogni front-end del gateway applicazione per contenitori fornisce un nome di dominio completo generato gestito da Azure. Il nome di dominio completo può essere usato così come è, oppure i clienti possono scegliere di mascherare il nome di dominio completo con un record CNAME.

Prima che un client invii una richiesta al gateway applicazione per contenitori, il client risolve un CNAME che punta al nome di dominio completo del front-end; o il client può risolvere direttamente il nome di dominio completo fornito dal gateway applicazione per i contenitori usando un server DNS.

Il resolver DNS converte il record DNS in un indirizzo IP.

Quando il client avvia la richiesta, il nome DNS specificato viene passato come intestazione host al gateway applicazione per contenitori nel front-end definito.

Un set di regole di routing valuta il modo in cui la richiesta per tale nome host deve essere avviata ad una destinazione back-end definita.

Come il gateway applicazione per contenitori instrada una richiesta

Richieste HTTP/2

gateway applicazione per contenitori supporta completamente il protocollo HTTP/2 per la comunicazione dal client al front-end. La comunicazione da gateway applicazione per contenitori alla destinazione back-end usa il protocollo HTTP/1.1. L'impostazione HTTP/2 è sempre abilitata e non può essere modificata. Se i client preferiscono usare HTTP/1.1 per la comunicazione con il front-end di gateway applicazione per contenitori, possono continuare a negoziare di conseguenza.

Modifiche alla richiesta

gateway applicazione per contenitori inserisce tre intestazioni aggiuntive a tutte le richieste prima che le richieste vengano avviate da gateway applicazione per contenitori a una destinazione back-end:

• x-forwarded-for
• x-forwarded-proto
• x-request-id

x-forwarded-for è l'indirizzo IP client del richiedente originale. Se la richiesta viene inviata tramite un proxy, il valore dell'intestazione aggiunge l'indirizzo ricevuto, delimitato da virgole. Ad esempio: 1.2.3.4,5.6.7.8; dove 1.2.3.4 è l'indirizzo IP client al proxy davanti al gateway applicazione per contenitori e 5.6.7.8 è l'indirizzo del proxy che inoltra il traffico al gateway applicazione per contenitori.

x-forwarded-proto rinvia il protocollo ricevuto dal gateway applicazione per contenitori dal client. Il valore è http o https.

x-request-id è un GUID univoco generato dal gateway applicazione per contenitori per ogni richiesta client e presentato nella richiesta inoltrata alla destinazione back-end. Il guid è costituito da 32 caratteri alfanumerici, separati da trattini (ad esempio: d23387ab-e629-458a-9c93-6108d374bc75). Questo GUID può essere usato per correlare una richiesta ricevuta dal gateway applicazione per contenitori e avviata ad una destinazione back-end come definito nei log di accesso.

Timeout test

gateway applicazione per Contenitori applica i timeout seguenti man mano che le richieste vengono avviate e mantenute tra il client, AGC e il back-end.

Timeout	Durata	Descrizione
Timeout richiesta	60 secondi	tempo per il quale AGC attende la risposta di destinazione back-end.
Timeout di inattività HTTP	5 minuti	timeout di inattività prima di chiudere una connessione HTTP.
Timeout di inattività flusso	5 minuti	timeout di inattività prima di chiudere un singolo flusso trasportato da una connessione HTTP.
Timeout upstream Connessione	5 secondi	tempo per stabilire una connessione alla destinazione back-end.