Condividi tramite

Linee guida per l'esecuzione di gateway self-hosted in Kubernetes nell'ambiente di produzione

  • Articolo

SI APPLICA A: Sviluppatore | Premium

Per eseguire il gateway self-hosted nell'ambiente di produzione, è necessario tenere presenti vari aspetti. Ad esempio, deve essere distribuito in modo a disponibilità elevata, usare i backup di configurazione per gestire le disconnessioni temporanee e molto altro ancora.

Questo articolo fornisce indicazioni su come eseguire un gateway self-hosted in Kubernetes per i carichi di lavoro di produzione per garantire che venga eseguito in modo uniforme e affidabile.

Importante

Il supporto per le immagini del contenitore del gateway self-hosted di Gestione API di Azure versione 0 e versione 1 termina il 1° ottobre 2023, insieme all'API di configurazione corrispondente v1. Consultare la guida alla migrazione per usare il gateway self-hosted v2.0.0 o versione successiva con l'API di configurazione v2. Altre informazioni nella documentazione di deprecazione

Token di accesso

Senza un token di accesso valido, un gateway self-hosted non può accedere e scaricare i dati di configurazione dall'endpoint del servizio Gestione API associato. Il token di accesso può essere valido per un massimo di 30 giorni. Deve essere rigenerato e il cluster configurato con un nuovo token, manualmente o tramite automazione prima della scadenza.

Quando si automatizza l'aggiornamento dei token, usare questa operazione api di gestione per generare un nuovo token. Per informazioni sulla gestione dei segreti Kubernetes, vedere il sito Web Kubernetes.

Suggerimento

È anche possibile distribuire il gateway self-hosted in Kubernetes e abilitare l'autenticazione nell'istanza di Gestione API usando Microsoft Entra ID.

Scalabilità automatica

Anche se vengono fornite indicazioni sul numero minimo di repliche per il gateway self-hosted, è consigliabile usare la scalabilità automatica per il gateway self-hosted per soddisfare la domanda del traffico in modo più proattivo.

Esistono due modi per ridimensionare automaticamente il gateway self-hosted orizzontalmente:

  • Scalabilità automatica in base all'utilizzo delle risorse (CPU e memoria)
  • Scalabilità automatica in base al numero di richieste al secondo

Ciò è possibile tramite la funzionalità Kubernetes nativa o tramite la scalabilità automatica basata su eventi di Kubernetes (KEDA). KEDA è un progetto di incubazione CNF che cerca di semplificare la scalabilità automatica delle applicazioni.

Nota

KEDA è una tecnologia open source che non è supportata da supporto tecnico di Azure e deve essere gestita dai clienti.

Scalabilità automatica basata sulle risorse

Kubernetes consente di ridimensionare automaticamente il gateway self-hosted in base all'utilizzo delle risorse usando un'utilità di scalabilità automatica orizzontale dei pod. Consente di definire soglie di CPU e memoria e il numero di repliche da aumentare o ridurre.

Un'alternativa consiste nell'usare la scalabilità automatica basata su eventi di Kubernetes (KEDA) che consente di ridimensionare i carichi di lavoro in base a un'ampia gamma di scaler, tra cui CPU e memoria.

Suggerimento

Se si usa già KEDA per ridimensionare altri carichi di lavoro, è consigliabile usare KEDA come ridimensionamento automatico delle app unificato. In caso contrario, è consigliabile basarsi sulla funzionalità kubernetes nativa tramite Horizontal Pod Autoscaler.

Scalabilità automatica basata sul traffico

Kubernetes non fornisce un meccanismo predefinito per la scalabilità automatica basata sul traffico.

La scalabilità automatica basata su eventi di Kubernetes offre alcuni modi per semplificare la scalabilità automatica basata sul traffico:

  • È possibile ridimensionare in base alle metriche da un ingresso Kubernetes se sono disponibili in Prometheus o Monitoraggio di Azure usando un scaler risolto
  • È possibile installare il componente aggiuntivo HTTP, disponibile in versione beta e ridimensionare in base al numero di richieste al secondo.

Backup della configurazione

Configurare un volume di archiviazione locale per il contenitore gateway self-hosted, in modo che possa salvare in modo permanente una copia di backup della configurazione scaricata più recente. Se la connettività è inattiva, il volume di archiviazione può usare la copia di backup al riavvio. Il percorso di montaggio del volume deve essere /apim/config e deve essere di proprietà dell'ID 1001gruppo . Vedere un esempio in GitHub. Per informazioni sull'archiviazione in Kubernetes, vedere il sito Web Kubernetes. Per modificare la proprietà di un percorso montato, vedere l'impostazione securityContext.fsGroup nel sito Web Kubernetes.

Nota

Per informazioni sul comportamento del gateway self-hosted in presenza di un'interruzione temporanea della connettività di Azure, vedere Panoramica del gateway self-hosted.

Tag dell'immagine del contenitore

Il file YAML fornito nella portale di Azure usa il tag più recente. Questo tag fa sempre riferimento alla versione più recente dell'immagine del contenitore del gateway self-hosted.

È consigliabile usare un tag di versione specifico nell'ambiente di produzione per evitare l'aggiornamento involontario a una versione più recente.

È possibile scaricare un elenco completo dei tag disponibili.

Suggerimento

Quando si esegue l'installazione con Helm, l'assegnazione di tag alle immagini è ottimizzata per l'utente. La versione dell'applicazione del grafico Helm aggiunge il gateway a una determinata versione e non si basa su latest.

Altre informazioni su come installare un gateway self-hosted Gestione API in Kubernetes con Helm.

Risorse del contenitore

Per impostazione predefinita, il file YAML fornito nella portale di Azure non specifica le richieste di risorse del contenitore.

È impossibile prevedere e consigliare in modo affidabile la quantità di risorse di CPU e memoria per contenitore e il numero di repliche necessarie per supportare un carico di lavoro specifico. Molti fattori sono in gioco, ad esempio:

  • Hardware specifico su cui è in esecuzione il cluster.
  • Presenza e tipo di virtualizzazione.
  • Numero e frequenza delle connessioni client simultanee.
  • Frequenza delle richieste.
  • Tipologia e numero di criteri configurati.
  • Dimensioni del payload e se i payload vengono memorizzati nel buffer o trasmessi.
  • Latenza del servizio back-end.

È consigliabile impostare le richieste di risorse su due core e 2 GiB come punto di partenza. Eseguire un test di carico e aumentare/ridurre o ridurre le prestazioni in base ai risultati.

Nomi di dominio personalizzati e certificati SSL

Se si usano nomi di dominio personalizzati per gli endpoint Gestione API, in particolare se si usa un nome di dominio personalizzato per l'endpoint di gestione, potrebbe essere necessario aggiornare il valore di config.service.endpoint nel <file gateway-name.yaml> per sostituire il nome di dominio predefinito con il nome di dominio personalizzato. Assicurarsi che l'endpoint di gestione sia accessibile dal pod del gateway self-hosted nel cluster Kubernetes.

In questo scenario, se il certificato SSL usato dall'endpoint di gestione non è firmato da un certificato CA noto, è necessario assicurarsi che il certificato della CA sia considerato attendibile dal pod del gateway self-hosted.

Nota

Con il gateway self-hosted v2, Gestione API fornisce un nuovo endpoint di configurazione: <apim-service-name>.configuration.azure-api.net. I nomi host personalizzati sono supportati per questo endpoint e possono essere usati anziché il nome host predefinito.

Criteri DNS

La risoluzione dei nomi DNS svolge un ruolo fondamentale nella capacità di un gateway self-hosted di connettersi alle dipendenze in Azure e inviare chiamate API ai servizi back-end.

Il file YAML fornito nella portale di Azure applica il criterio predefinito ClusterFirst. Questo criterio fa sì che le richieste di risoluzione dei nomi non vengano risolte dal DNS del cluster per l'inoltro al server DNS upstream ereditato dal nodo.

Per informazioni sulla risoluzione dei nomi in Kubernetes, vedere il sito Web Kubernetes. Valutare la possibilità di personalizzare i criteri DNS o la configurazione DNS in base alle esigenze della configurazione.

Criteri di traffico esterno

Il file YAML fornito nel campo portale di Azure imposta externalTrafficPolicy l'oggetto Service su Local. In questo modo viene mantenuto l'indirizzo IP del chiamante (accessibile nel contesto della richiesta) e viene disabilitato il bilanciamento del carico tra nodi, eliminando gli hop di rete causati da esso. Tenere presente che questa impostazione potrebbe causare la distribuzione asimmetrica del traffico nelle distribuzioni con un numero diverso di pod gateway per nodo.

Disponibilità elevata

Il gateway self-hosted è un componente fondamentale nell'infrastruttura e deve essere a disponibilità elevata. Tuttavia, l'errore può verificarsi.

Valutare la possibilità di proteggere il gateway self-hosted da interruzioni.

Suggerimento

Quando si esegue l'installazione con Helm, abilitare facilmente la pianificazione a disponibilità elevata abilitando l'opzione highAvailability.enabled di configurazione.

Altre informazioni su come installare un gateway self-hosted Gestione API in Kubernetes con Helm.

Protezione da un errore del nodo

Per evitare di essere interessati a causa di errori del data center o dei nodi, è consigliabile usare un cluster Kubernetes che usa le zone di disponibilità per ottenere una disponibilità elevata a livello di nodo.

Le zone di disponibilità consentono di pianificare il pod del gateway self-hosted nei nodi distribuiti tra le zone usando:

Nota

Se si usa servizio Azure Kubernetes, vedere come usare le zone di disponibilità in questo articolo.

Protezione dalle interruzioni dei pod

I pod possono riscontrare interruzioni a causa di vari motivi, ad esempio l'eliminazione manuale dei pod, la manutenzione dei nodi e così via.

Prendere in considerazione l'uso dei budget di interruzione dei pod per applicare un numero minimo di pod per essere disponibili in qualsiasi momento.

Proxy HTTP(S)

Il gateway self-hosted fornisce il supporto per il proxy HTTP(S) usando le variabili di ambiente tradizionali HTTP_PROXYHTTPS_PROXY e NO_PROXY .

Dopo la configurazione, il gateway self-hosted userà automaticamente il proxy per tutte le richieste HTTP(S) in uscita ai servizi back-end.

A partire dalla versione 2.1.5 o successiva, il gateway self-hosted offre osservabilità correlata al proxy delle richieste:

  • Controllo API mostrerà passaggi aggiuntivi quando viene usato il proxy HTTP(S) e le relative interazioni.
  • I log dettagliati vengono forniti per fornire un'indicazione del comportamento del proxy di richiesta.

Nota

A causa di un problema noto con proxy HTTP che usano l'autenticazione di base, l'uso della convalida dell'elenco di revoche di certificati (CRL) non è supportato. Per altre informazioni, vedere Le impostazioni del gateway self-hosted fanno riferimento a come configurarlo in modo appropriato.

Avviso

Assicurarsi che i requisiti dell'infrastruttura siano stati soddisfatti e che il gateway self-hosted possa comunque connettersi a tali gateway o che alcune funzionalità non funzionino correttamente.

Log e metriche locali

Il gateway self-hosted invia dati di telemetria a Monitoraggio di Azure e app Azure lication Insights in base alle impostazioni di configurazione nel servizio Gestione API associato. Quando la connettività ad Azure viene temporaneamente persa, il flusso di dati di telemetria in Azure viene interrotto e i dati vengono persi per la durata dell'interruzione.

È consigliabile usare Azure Monitor Container Insights per monitorare i contenitori o configurare il monitoraggio locale per garantire la possibilità di osservare il traffico dell'API e prevenire la perdita di dati di telemetria durante le interruzioni della connettività di Azure.

Spazio dei nomi

Gli spazi dei nomi Kubernetes consentono di dividere un singolo cluster tra più team, progetti o applicazioni. Gli spazi dei nomi forniscono un ambito per le risorse e i nomi. Possono essere associati a una quota di risorse e ai criteri di controllo di accesso.

Il portale di Azure fornisce comandi per creare risorse del gateway self-hosted nello spazio dei nomi predefinito. Questo spazio dei nomi viene creato automaticamente, esiste in ogni cluster e non può essere eliminato. Prendere in considerazione la creazione e la distribuzione di un gateway self-hosted in uno spazio dei nomi separato nell'ambiente di produzione.

Numero di repliche

Il numero minimo di repliche adatte per la produzione è tre, preferibilmente combinato con la pianificazione a disponibilità elevata delle istanze.

Per impostazione predefinita, un gateway self-hosted viene distribuito con una strategia di distribuzione RollingUpdate. Esaminare i valori predefiniti e prendere in considerazione l'impostazione esplicita dei campi maxUnavailable e maxSurge , soprattutto quando si usa un numero di repliche elevato.

Prestazioni

È consigliabile ridurre i log dei contenitori agli avvisi (warn) per migliorare le prestazioni. Per altre informazioni, vedere le informazioni di riferimento sulla configurazione del gateway self-hosted.

Limitazione delle richieste

La limitazione delle richieste in un gateway self-hosted può essere abilitata usando il criterio di Gestione API limite di velocità o limite di frequenza per chiave. Configurare i conteggi dei limiti di frequenza per la sincronizzazione tra le istanze del gateway tra i nodi del cluster esponendo le porte seguenti nella distribuzione kubernetes per l'individuazione delle istanze:

  • Porta 4290 (UDP), per la sincronizzazione della limitazione della frequenza
  • Porta 4291 (UDP), per l'invio di heartbeat ad altre istanze

Nota

I conteggi dei limiti di frequenza in un gateway self-hosted possono essere configurati per la sincronizzazione locale (tra le istanze del gateway tra i nodi del cluster), ad esempio tramite la distribuzione del grafico Helm per Kubernetes o usando i modelli di distribuzione portale di Azure. Tuttavia, i conteggi dei limiti di frequenza non vengono sincronizzati con altre risorse del gateway configurate nell'istanza di Gestione API, incluso il gateway gestito nel cloud.

Sicurezza

Il gateway self-hosted è in grado di essere eseguito come non radice in Kubernetes, consentendo ai clienti di eseguire il gateway in modo sicuro.

Di seguito è riportato un esempio del contesto di sicurezza per il contenitore del gateway self-hosted:

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  runAsUser: 1001       # This is a built-in user, but you can use any user ie 1000 as well
  runAsGroup: 2000      # This is just an example
  privileged: false
  capabilities:
    drop:
    - all

Avviso

L'esecuzione del gateway self-hosted con file system di sola lettura (readOnlyRootFilesystem: true) non è supportata.

Avviso

Quando si usano certificati CA locali, il gateway self-hosted deve essere eseguito con l'ID utente (UID) 1001 per gestire i certificati DELLA CA. In caso contrario, il gateway non verrà avviato.

Passaggi successivi