Service Discovery

Questo documento contiene una panoramica della Service Discovery basata su DNS di Kubernetes e su come può essere utilizzata con Kf.

Quando utilizzare il Service Discovery di Kubernetes con Kf

La Service Discovery di Kubernetes può essere utilizzata dalle applicazioni che devono individuare i servizi di supporto in modo coerente, indipendentemente da dove viene eseguito il deployment dell'applicazione. Ad esempio, un team potrebbe voler utilizzare un URI comune nella configurazione che indichi sempre il gateway SMTP locale per disaccoppiare il codice dall'ambiente in cui è stato eseguito.

Service Discovery aiuta i team di applicazioni a:

  • Riduzione della quantità di configurazione per ambiente.
  • Scollegare le applicazioni client e server.
  • Consente alle applicazioni di essere trasferite in nuovi ambienti.

Puoi utilizzare Service Discovery Kubernetes quando:

  • Le applicazioni utilizzano le configurazioni DNS del proprio contenitore per risolvere gli host.
  • Le applicazioni vengono implementate con i relativi servizi di supporto nello stesso cluster o nello stesso spazio dei nomi Kubernetes.
  • I servizi di supporto hanno un servizio Kubernetes associato. Kf li crea per ogni app.
  • I NetworkPolicy di Kubernetes consentono il traffico tra un'applicazione e il servizio Kubernetes con cui deve comunicare. Kf crea queste norme in ogni spazio Kf.

Non devi utilizzare Service Discovery Kubernetes se:

  • Le applicazioni devono eseguire il failover tra più cluster.
  • Sostituisci il resolver DNS utilizzato dalla tua applicazione.
  • Le applicazioni richiedono tipi specifici di bilanciamento del carico.

Come funziona Service Discovery Kubernetes

Il Service Discovery di Kubernetes funziona modificando la configurazione DNS dei container in esecuzione su un nodo Kubernetes. Quando un'applicazione cerca un nome di dominio non qualificato, il resolver DNS locale tenterà prima di risolvere il nome nel cluster locale.

I domini senza più parti verranno risolti in base ai nomi dei servizi Kubernetes nello spazio dei nomi del contenitore. Ogni app Kf crea un servizio Kubernetes con lo stesso nome. Se due app KF ping e pong sono state implementate nello stesso spazio KF, ping potrebbe utilizzare l'URL http://pong per inviare traffico all'altro servizio.

I domini con un solo punto verranno risolti in base ai servizi Kubernetes nello spazio dei nomi Kubernetes con lo stesso nome dell'etichetta dopo il punto. Ad esempio, se esiste un database PostgreSQL con un servizio customers nello spazio dei nomi database, un'applicazione in un altro spazio dei nomi potrebbe risolverlo utilizzando postgres://customers.database.

Come utilizzare Service Discovery con Kf

La Service Discovery basata su DNS di Kubernetes può essere utilizzata in qualsiasi app Kf. Ogni app Kf crea un servizio Kubernetes con lo stesso nome e ogni spazio Kf crea uno spazio dei nomi Kubernetes con lo stesso nome.

  • Fai riferimento a un'app Kf nello spazio corrente utilizzando protocol://app-name.
  • Fai riferimento a un'app Kf in uno spazio diverso utilizzando protocol://app-name.space-name.
  • Fai riferimento a un'app Kf nello spazio corrente in ascolto su una porta personalizzata utilizzando protocol://app-name:port.
  • Fai riferimento a un'app Kf in uno spazio diverso che ascolta una porta personalizzata utilizzando protocol://app-name.space-name:port.

Best practice

Le applicazioni che saranno il target del Service Discovery basato su DNS devono essere sottoposte a frequenti controlli di integrità per garantire che vengano aggiunte e rimosse rapidamente dal pool di host che accettano le connessioni.

Le applicazioni che utilizzano Service Discovery basata su DNS non devono memorizzare nella cache gli indirizzi IP degli servizi risolti perché non è garantita la loro stabilità.

Se esistono servizi specifici per l'ambiente all'esterno del cluster, possono essere risolti utilizzando il DNS di Kubernetes se configuri i servizi Kubernetes ExternalName. Questi servizi Kubernetes forniscono le stesse funzionalità di risoluzione, ma restituiscono un record CNAME per reindirizzare le richieste a un'autorità esterna.

Confronto con Eureka

Eureka è un bilanciatore del carico lato client open source creato da Netflix. Viene comunemente utilizzato come parte del service broker Spring Cloud Services. Eureka è stato creato per essere un bilanciatore del carico e un meccanismo di Service Discovery a livello di regione per i servizi in esecuzione in un ambiente che causava frequenti interruzioni dei carichi di lavoro, con conseguente instabilità degli indirizzi IP.

Eureka è progettato come modello client/server. I client si registrano sul server indicando i nomi a cui vogliono essere associati e inviando periodicamente i heartbeat del server. Il server consente a tutti i client collegati di risolvere i nomi.

In generale, ti consigliamo di utilizzare Kubernetes DNS anziché Eureka in Kubernetes per i seguenti motivi:

  • Il DNS funziona con tutti i linguaggi di programmazione e le applicazioni senza la necessità di librerie.
  • Il controllo di integrità esistente dell'applicazione verrà riutilizzato riducendo le combinazioni di errori.
  • Kubernetes gestisce il server DNS, consentendoti di fare affidamento su meno dipendenze.
  • Il DNS di Kubernetes rispetta gli stessi vincoli dei criteri e del RBAC del resto di Kubernetes.

Esistono alcuni casi in cui è vantaggioso eseguire il deployment di un server Eureka:

  • Hai bisogno Service Discovery nelle applicazioni basate su Kubernetes e VM.
  • È necessario il bilanciamento del carico basato sul client.
  • Sono necessari controlli di integrità indipendenti.

Passaggi successivi