Service Discovery

Questo documento offre una panoramica del Service Discovery Kubernetes basato su DNS e di come può essere utilizzato con Kf.

Quando utilizzare Kubernetes Service Discovery con Kf

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

Service Discovery aiuta i team dedicati alle applicazioni a:

  • Ridurre la quantità di configurazione per ambiente.
  • Disaccoppiamento delle applicazioni client e server.
  • Consentono la portabilità delle applicazioni in nuovi ambienti.

Puoi utilizzare Kubernetes Service Discovery quando:

  • Le applicazioni utilizzano le configurazioni DNS del container per risolvere gli host.
  • Il deployment delle applicazioni viene eseguito con i relativi servizi di supporto nello stesso cluster o spazio dei nomi Kubernetes.
  • Ai servizi di supporto è associato un servizio Kubernetes. Kf le crea per ogni app.
  • I criteri di rete Kubernetes consentono il traffico tra un'applicazione e il servizio Kubernetes con cui deve comunicare. Kf crea questi criteri in ogni spazio Kf.

Non devi utilizzare Kubernetes Service Discovery se:

  • Le applicazioni devono eseguire il failover tra più cluster.
  • Esegui l'override del resolver DNS utilizzato dall'applicazione.
  • Le applicazioni richiedono tipi specifici di bilanciamento del carico.

Come funziona Kubernetes Service Discovery

Kubernetes Service Discovery 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 tenta innanzitutto 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 container. Ogni app Kf crea un servizio Kubernetes con lo stesso nome. Se viene eseguito il deployment di due app Kf ping e pong nello stesso spazio Kf, ping potrebbe utilizzare l'URL http://pong per inviare traffico all'altro servizio.

I domini con un singolo 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 esistesse 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

Il Service Discovery basato su DNS di Kubernetes può essere utilizzato 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 attuale 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 in ascolto di una porta personalizzata utilizzando protocol://app-name.space-name:port.

best practice

Le applicazioni che saranno la destinazione 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 basato su DNS non devono memorizzare nella cache gli indirizzi IP dei servizi risolti perché non è garantita la loro stabilità.

Se esistono servizi specifici per l'ambiente al di fuori del cluster, possono essere risolti utilizzando il DNS di Kubernetes se configuri i servizi Kubernetes esterni dei nomi. Questi servizi Kubernetes offrono le stesse capacità 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. È comunemente utilizzato come parte del service broker Spring Cloud Services. Eureka è stata realizzata per essere un bilanciatore del carico a livello di regione e Service Discovery servizi per i servizi in esecuzione in un ambiente che causava frequenti interruzioni dei carichi di lavoro portando a indirizzi IP instabili.

Eureka è progettata come modello client/server. I client si registrano al server indicando i nomi a cui vogliono essere associati e inviano periodicamente gli heartbeat del server. Il server consente a tutti i client connessi di risolvere i nomi.

In generale, dovresti utilizzare il DNS di Kubernetes invece di 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 della tua 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 di criteri e RBAC del resto di Kubernetes.

Esistono alcuni casi in cui il deployment di un server Eureka può essere vantaggioso:

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

Passaggi successivi