Kong, API Gateway

Indice

• Introduzione

• Installazione di Kong in Kubernetes

• Creazione di servizi e percorsi

• Configurazione di plugin e impostazioni

• Conclusioni

Introduzione

In un’architettura a microservizi basata su Kubernetes, un API Gateway come Kong assume un ruolo chiave nel gestire il traffico, applicare sicurezza e semplificare il routing verso i servizi backend. Piuttosto che lasciare che ciascun servizio esponga direttamente le proprie API, Kong offre un unico punto di ingresso unificato. All’interno del cluster Kubernetes, Kong può essere installato come Ingress Controller; questo significa che, tramite risorse native di Kubernetes (Ingress o il più recente Gateway API), Kong traduce le specifiche di routing in configurazioni effettive del Gateway. Nel seguito di questo articolo esamineremo come installare Kong nel cluster, come definire i servizi Kubernetes e le route che Kong deve gestire, e come applicare plugin e altre configurazioni per controllare il comportamento del traffico API.

Installazione di Kong in Kubernetes

Il primo passo consiste nel distribuire Kong all’interno del cluster Kubernetes. Un metodo molto comune è utilizzare il chart Helm ufficiale di Kong. Dopo aver aggiunto il repository di Kong (helm repo add kong https://charts.konghq.com), possiamo creare un namespace dedicato e installare Kong con una configurazione personalizzata. Ad esempio, il file values.yaml potrebbe includere impostazioni come queste:

In questo frammento definiamo che Kong userà la modalità database-less (database: "off") e abilitiamo l’Ingress Controller integrato di Kong (ingressController.enabled: true). Altri parametri di configurazione – come KONG_ADMIN_LISTEN, gestione di prefissi di percorso o abilitazione di componenti addizionali – possono essere inseriti nello stesso file. Una volta preparato il values.yaml, l’installazione avviene con helm install kong kong/kong -n kong -f values.yaml. Questo comando crea le risorse Kubernetes necessarie: pod di Kong (che contengono proxy e controller), servizi di tipo ClusterIP per la comunicazione interna e un service di tipo LoadBalancer (o l’equivalente del tuo cluster) che espone l’interfaccia proxy di Kong (porta 8000 per HTTP e 8443 per HTTPS) agli utilizzatori esterni. Dopo qualche istante, Kong sarà in ascolto nel cluster e pronto a ricevere la configurazione delle route e dei servizi.

Creazione di servizi e percorsi

A questo punto possiamo definire i servizi backend e associare delle route tramite risorse Kubernetes. Supponiamo di avere un servizio di test “echo” che risponde con alcuni dati. Creeremo prima un Deployment e un Service per questo microservizio. Un esempio di manifest YAML potrebbe essere il seguente:

Questo manifest definisce un semplice pod che esegue l’immagine hashicorp/http-echo, esponendo sulla porta 80 un messaggio di risposta. Il Service echo instrada il traffico verso il pod in base alla label app: echo. Dopo aver applicato (kubectl apply -f echo.yaml) questi oggetti, il servizio echo è attivo nel cluster ma non ancora esposto verso l’esterno del cluster.

Per esporre il servizio tramite Kong, utilizziamo una risorsa Ingress di Kubernetes. Di default Kong Ingress Controller intercetta tutti gli Ingress con ingressClassName: kong o con l’annotazione kubernetes.io/ingress.class: kong. Ecco un esempio di manifest per un Ingress che instrada le richieste al servizio echo:

Questa configurazione dichiara che tutte le richieste HTTP inviate a kong.local:80/echo devono essere consegnate al servizio echo sulla porta 80. L’annotazione konghq.com/strip-path: 'true' indica a Kong di rimuovere il prefisso /echo prima di inoltrare la richiesta al pod, mantenendo solo ciò che segue nel percorso. Una volta applicato questo Ingress (kubectl apply -f echo-ingress.yaml), Kong apprenderà la nuova route: se ora effettuiamo una chiamata al dominio kong.local (mappato al cluster, ad esempio tramite /etc/hosts o configurazione del LoadBalancer) con percorso /echo, Kong instraderà il traffico al servizio echo. Di fatto Kong funge da proxy: i client non conoscono direttamente l’esistenza del pod echo, ma accedono alle sue funzionalità attraverso Kong.

Configurazione di plugin e impostazioni

Uno dei punti di forza di Kong è il suo sistema di plugin: componenti riutilizzabili che si inseriscono nel flusso di richiesta e risposta per aggiungere funzionalità come autenticazione, rate limiting, trasformazioni, logging e molto altro. Nella modalità Ingress Controller di Kubernetes, i plugin si applicano tipicamente definendo risorse personalizzate di Kong o usando annotazioni sugli oggetti Ingress. Ad esempio, immaginiamo di voler proteggere il servizio echo con una semplice autenticazione tramite chiave API. Dovremmo allora creare un consumer Kong e associare una chiave.

Per creare un consumatore Kong (cioè un client autorizzato), utilizziamo la risorsa KongConsumer:

Poi creiamo una credential di tipo key-auth per questo consumer. Questo si fa definendo un oggetto KongCredential oppure direttamente usando una Secret Kubernetes con la chiave. Ecco un approccio con KongCredential:

Abbiamo quindi definito una chiave segreta supersegreto per l’utente myuser. Infine, applichiamo il plugin Key Authentication alle richieste destinate al nostro servizio. Possiamo farlo con un’annotazione nell’Ingress:

L’annotazione konghq.com/plugins: key-auth indica al controller di abilitare il plugin di tipo key-auth su questa route. Il nome del plugin configurato è proprio key-auth. In questo modo, ogni richiesta a /echo dovrà includere la chiave API corrispondente, altrimenti Kong risponderà con un errore di autenticazione. Nel complesso, ciò richiede che il client fornisca il parametro apikey=supersegreto (oppure un header HTTP specifico), in accordo alle configurazioni di default del plugin.

Oltre all’autenticazione, Kong permette di configurare in modo simile numerosi altri plugin – ad esempio per limitare il numero di richieste al minuto (rate limiting), aggiungere log esterni (syslog, datadog, ecc.), crittografare token, e così via. La logica rimane la stessa: si definiscono risorse Kubernetes di tipo KongPlugin (e KongConsumer/KongCredential se necessario) oppure si usa un’annotazione nell’Ingress per attivare il plugin desiderato.

Un ultimo aspetto di configurazione riguarda l’amministrazione dello stesso Kong Gateway. Se servisse, ad esempio, modificare dinamicamente i livelli di log o impostare parametri particolari, ciò avviene tipicamente via Admin API di Kong. Tuttavia, quando Kong è distribuito in cluster Kubernetes con modalità database-less, molte configurazioni vengono caricate in fase di deploy (tramite Helm o file dichiarativi) o tramite risorse Custom come KongClusterPlugin, KongGlobalPlugin per scope più ampio. Queste sono opzioni avanzate; nel contesto di un blog introduttivo ci limitiamo a segnalare che il comportamento di Kong può essere ulteriormente personalizzato anche tramite ConfigMap o parametri dell’Helm chart se necessario.

Conclusioni

In questo articolo abbiamo visto come utilizzare Kong come API Gateway all’interno di un cluster Kubernetes, mantenendo la flessibilità del controllo su routing e sicurezza. Installando Kong via Helm e configurandone l’Ingress Controller, abbiamo potuto definire servizi Kubernetes e specificare percorsi di traffico con oggetti standard (come Service e Ingress). Kong traduce queste risorse in configurazioni di gateway reali, instradando le chiamate dei client ai microservizi appropriati. Inoltre, grazie al sistema di plugin, è possibile applicare facilmente politiche di autenticazione, limitazione delle richieste, logging e altre funzionalità non funzionali senza modificare il codice dei servizi stessi. Questo approccio “API-led” semplifica la gestione centralizzata delle API, accresce la sicurezza e consente di scalare orizzontalmente i componenti indipendentemente.

Naturalmente, le potenzialità di Kong nel contesto Kubernetes sono molto più ampie: si può procedere verso l’uso del Gateway API (Kubernetes Gateway) anziché dell’Ingress classica, distribuire Kong in modalità a database-backend per funzioni enterprise, integrare il Developer Portal, monitorare le metriche tramite Vitals o Prometheus, e così via. L’esempio qui trattato fornisce però un punto di partenza solido per comprendere come iniziare a utilizzare Kong come gateway nel proprio ambiente Kubernetes, accompagnando il lettore passo per passo nell’installazione, nella definizione delle rotte e nella protezione delle API.