Informazioni su Service Discovery

Questo documento spiega in che modo la Service Discovery in Google Kubernetes Engine (GKE) semplifica la gestione delle applicazioni e come estendere la Service Discovery oltre un singolo cluster utilizzando gli ambiti di Cloud DNS, i servizi multi-cluster (MCS) e Service Directory.

Questo documento è rivolto agli utenti, agli sviluppatori, agli amministratori e agli architetti di GKE. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli e attività comuni degli utenti GKE. Google Cloud

Prima di leggere questo documento, assicurati di comprendere i seguenti concetti:

Panoramica

La Service Discovery è un meccanismo che consente a servizi e applicazioni di trovarsi e comunicare tra loro in modo dinamico senza codificare gli indirizzi IP o le configurazioni degli endpoint. La Service Discovery contribuisce a garantire che le applicazioni abbiano sempre accesso agli indirizzi IP dei pod aggiornati, anche quando i pod vengono riprogrammati o ne vengono aggiunti di nuovi. GKE offre diversi modi per implementare la Service Discovery, tra cui kube-dns, deployment kube-dns personalizzati e Cloud DNS. Puoi ottimizzare ulteriormente le prestazioni del DNS con NodeLocal DNSCache.

Vantaggi della Service Discovery

La Service Discovery offre i seguenti vantaggi:

  • Gestione semplificata delle applicazioni: la Service Discovery elimina la necessità di codificare gli indirizzi IP nelle configurazioni delle applicazioni. Le applicazioni comunicano utilizzando nomi di servizi logici, che vengono risolti automaticamente negli indirizzi IP dei pod corretti. Questo approccio semplifica la configurazione, soprattutto negli ambienti dinamici in cui gli indirizzi IP dei pod potrebbero cambiare a causa dello scaling o della riprogrammazione.
  • Scaling e resilienza semplificati: la Service Discovery semplifica lo scaling disaccoppiando i consumer di servizi dagli indirizzi IP dei pod, che cambiano di frequente. Mentre l'applicazione esegue lo scaling o se i pod si arrestano e vengono sostituiti, Kubernetes aggiorna automaticamente i pod disponibili per ricevere traffico per un determinato servizio. La Service Discovery contribuisce a garantire che le richieste al nome del servizio stabile vengano indirizzate solo ai pod integri, il che consente all'applicazione di eseguire lo scaling o di ripristinare gli errori senza interventi manuali o riconfigurazione del client.
  • Alta affidabilità: GKE utilizza il bilanciamento del carico insieme alla Service Discovery per garantire l'alta affidabilità e migliorare la reattività delle applicazioni, anche in caso di carichi elevati.

Bilanciamento del carico con la Service Discovery

GKE contribuisce a garantire l'alta affidabilità delle applicazioni combinando diversi livelli di bilanciamento del carico con la Service Discovery.

  • Servizi interni: per i servizi accessibili solo all'interno del cluster, il piano dati di GKE (kube-proxy o Cilium) funge da bilanciatore del carico. Distribuisce uniformemente il traffico in entrata tra più pod integri, impedendo il sovraccarico e contribuendo a garantire l'alta affidabilità.
  • Servizi esterni: per i servizi che devono essere accessibili dall'esterno del cluster, GKE esegue il provisioning dei Google Cloud bilanciatori del carico. Questi bilanciatori del carico includono bilanciatori del carico esterni Google Cloud per l'accesso a internet pubblico e bilanciatori del carico interni Google Cloud per l'accesso all'interno della rete Virtual Private Cloud. Questi bilanciatori del carico distribuiscono il traffico tra i nodi del cluster. Il piano dati su ogni nodo instrada ulteriormente il traffico ai pod appropriati.

Negli scenari interni ed esterni, la Service Discovery aggiorna continuamente l'elenco dei pod disponibili per ogni servizio. Questo aggiornamento continuo contribuisce a garantire che sia il piano dati (per i servizi interni) sia i Google Cloud bilanciatori del carico (per i servizi esterni) indirizzino il traffico solo alle istanze integre.

Casi d'uso per la Service Discovery

Di seguito sono riportati alcuni casi d'uso comuni della Service Discovery:

  • Architettura dei microservizi: in un'architettura dei microservizi, le applicazioni spesso sono costituite da molti servizi più piccoli e indipendenti che devono interagire. La Service Discovery consente a queste applicazioni di trovarsi e scambiarsi informazioni, anche durante lo scaling del cluster.
  • Abilitare i deployment senza tempi di inattività e migliorare la resilienza: la Service Discovery facilita gli aggiornamenti senza tempi di inattività per le applicazioni, inclusi i rollout controllati e i deployment canary. Automatizza la scoperta di nuove versioni del servizio e sposta il traffico su di esse, il che contribuisce a ridurre i tempi di inattività durante il deployment e a garantire una transizione senza problemi per gli utenti. La Service Discovery migliora anche la resilienza. Quando un pod si arresta in GKE, ne viene eseguito il deployment di uno nuovo e la Service Discovery registra il nuovo pod e reindirizza il traffico verso di esso, il che contribuisce a ridurre al minimo i tempi di inattività dell'applicazione.

Come funziona la Service Discovery

In GKE, le applicazioni spesso sono costituite da più pod che devono trovarsi e comunicare tra loro. La Service Discovery fornisce questa funzionalità utilizzando il DNS (Domain Name System). Analogamente a come utilizzi il DNS per trovare siti web su internet, i pod in un cluster GKE utilizzano il DNS per individuare i servizi e connettersi a essi utilizzando i nomi dei servizi. Questo approccio consente ai pod di interagire in modo efficace, indipendentemente da dove sono in esecuzione nel cluster, e consente alle applicazioni di comunicare utilizzando nomi di servizi coerenti anziché indirizzi IP instabili.

In che modo i pod eseguono la risoluzione DNS

I pod in un cluster GKE risolvono i nomi DNS per i servizi e altri pod utilizzando una combinazione di record DNS generati automaticamente e la configurazione DNS locale.

Nomi DNS dei servizi

Quando crei un servizio Kubernetes, GKE gli assegna automaticamente un nome DNS. Questo nome segue un formato prevedibile, che qualsiasi pod nel cluster può utilizzare per accedere al servizio:

<service-name>.<namespace>.svc.cluster.local

Il dominio del cluster predefinito è cluster.local, ma puoi personalizzare il dominio quando crei il cluster. Ad esempio, un servizio denominato my-web-app in nello spazio dei nomi predefinito avrebbe il nome DNS my-web-app.default.svc.cluster.local.

Il ruolo di /etc/resolv.conf

Per risolvere questi nomi DNS, i pod si basano sul file /etc/resolv.conf. Questo file di configurazione indica al pod a quale server dei nomi inviare le query DNS. L'indirizzo IP del server dei nomi elencato in questo file dipende dalle funzionalità DNS specifiche abilitate nel cluster GKE. La tabella seguente descrive l'indirizzo IP del server dei nomi utilizzato da un pod, in base alla configurazione:

Cloud DNS per GKE NodeLocal DNSCache Valore del server dei nomi `/etc/resolv.conf`
Abilitato Abilitato `169.254.20.10`
Abilitato Disabilitato `169.254.169.254`
Disabilitato Abilitato Indirizzo IP del servizio `kube-dns`
Disabilitato Disabilitato Indirizzo IP del servizio `kube-dns`

Questa configurazione contribuisce a garantire che le query DNS del pod vengano indirizzate al componente corretto:

  • NodeLocal DNSCache: fornisce ricerche locali rapide sul nodo.
  • Indirizzo IP del server di metadati (169.254.169.254): viene utilizzato quando Cloud DNS per GKE è abilitato senza NodeLocal DNSCache. Le query DNS vengono indirizzate a questo indirizzo IP, che Cloud DNS utilizza per intercettare e gestire le richieste DNS.
  • Indirizzo IP del servizio kube-dns: viene utilizzato per la risoluzione standard in-cluster quando Cloud DNS per GKE è disabilitato.

Architettura DNS in GKE

GKE fornisce un'architettura flessibile per la Service Discovery, principalmente utilizzando il DNS. I seguenti componenti collaborano per risolvere le query DNS all'interno del cluster:

  • kube-dns: il provider DNS in-cluster predefinito per i cluster GKE Standard. Viene eseguito come deployment gestito di pod nello spazio dei nomi kube-system e monitora l'API Kubernetes per i nuovi servizi per creare i record DNS necessari.
  • Cloud DNS: Google Cloudservizio DNS completamente gestito. Offre un'alternativa altamente scalabile e affidabile a kube-dns ed è il provider DNS predefinito per i cluster GKE Autopilot.
  • NodeLocal DNSCache: un componente aggiuntivo GKE che migliora le prestazioni di ricerca DNS. Esegue una cache DNS su ogni nodo del cluster, funzionando con kube-dns o Cloud DNS per gestire le query DNS localmente, il che riduce la latenza e il carico sul provider DNS centrale del cluster. Per i cluster GKE Autopilot, NodeLocal DNSCache è abilitato per impostazione predefinita e non può essere sostituito.
  • Deployment kube-dns personalizzato: un deployment che consente di eseguire il deployment e gestire la propria istanza di kube-dns, che fornisce un maggiore controllo sulla configurazione e sulle risorse di kube-dns.

Scegli il tuo provider DNS

La tabella seguente riassume i provider DNS disponibili in GKE, incluse le relative funzionalità e quando scegliere ciascuno di essi:

Provider Funzionalità Quando scegliere
`kube-dns` Risoluzione DNS in-cluster per servizi e pod. Tutti i cluster con esigenze di rete standard. La nuova versione di `kube-dns` è adatta sia per cluster di piccole che di grandi dimensioni.
Cloud DNS Funzionalità DNS avanzate (zone private, gestione del traffico, bilanciamento del carico globale ) e integrazione con altri servizi. Google Cloud Esposizione di servizi esternamente, ambienti multi-cluster o per cluster con elevate frequenze di query DNS (QPS).
Deployment `kube-dns` personalizzato Controllo aggiuntivo sulla configurazione, sull'allocazione delle risorse e sulla possibilità di utilizzare provider DNS alternativi. Cluster di grandi dimensioni o esigenze DNS specifiche che richiedono uno scaling più aggressivo scaling o un controllo granulare sull'allocazione delle risorse.

Service Discovery al di fuori di un singolo cluster

Puoi estendere la Service Discovery oltre un singolo cluster GKE utilizzando i seguenti metodi:

Ambito di Cloud DNS

I cluster che utilizzano Cloud DNS per il DNS del cluster possono operare in uno dei tre ambiti disponibili:

  • Ambito cluster: questo è il comportamento predefinito di Cloud DNS. In questa modalità, Cloud DNS funziona in modo equivalente a kube-dns fornendo la risoluzione DNS esclusivamente per le risorse che si trovano all'interno del cluster. I record DNS sono risolvibili solo dall'interno del cluster e rispettano lo schema standard dei servizi Kubernetes: <svc>.<ns>.svc.cluster.local.
  • Ambito VPC additivo: questa funzionalità facoltativa estende l' ambito del cluster rendendo i servizi headless risolvibili da altre risorse all'interno della stessa rete VPC, come le VM Compute Engine o i client on-premise che si connettono utilizzando Cloud VPN o Cloud Interconnect.
  • Ambito VPC: con questa configurazione, i record DNS per i servizi del cluster sono risolvibili all'interno dell'intera rete VPC. Questo approccio significa che qualsiasi client che si trova nello stesso VPC o è connesso a esso (tramite Cloud VPN o Cloud Interconnect) può risolvere direttamente i nomi dei servizi.

Per saperne di più sul DNS con ambito VPC, consulta Utilizzare Cloud DNS per GKE.

Servizi multi-cluster

I servizi multi-cluster (MCS) consentono la Service Discovery e la gestione del traffico su più cluster GKE. MCS consente di creare applicazioni che si estendono su più cluster mantenendo un'esperienza di servizio unificata.

MCS utilizza la Service Discovery basata su DNS per connettere i servizi tra i cluster. Quando crei un'istanza MCS, questa genera record DNS nel formato di <svc>.<ns>.svc.clusterset.local. Questi record vengono risolti negli indirizzi IP degli endpoint del servizio in ogni cluster partecipante.

Quando un client in un cluster accede a un MCS, le richieste vengono instradate all'endpoint disponibile più vicino in uno dei cluster partecipanti. Questa distribuzione del traffico è gestita da kube-proxy (o Cilium in GKE Dataplane V2) su ogni nodo, il che contribuisce a garantire una comunicazione efficiente e il bilanciamento del carico tra i cluster.

Service Directory per GKE

Service Directory per GKE fornisce un registro unificato per la Service Discovery nei deployment Kubernetes e non Kubernetes. Service Directory può registrare sia i servizi GKE che quelli non GKE in un unico registro.

Service Directory è particolarmente utile se vuoi:

  • Un unico registro per le applicazioni Kubernetes e non Kubernetes per scoprirsi a vicenda.
  • Uno strumento di Service Discovery gestito.
  • La possibilità di archiviare metadati sul tuo servizio a cui altri client possono accedere.
  • La possibilità di impostare le autorizzazioni di accesso a livello di servizio. I servizi Service Directory possono essere risolti utilizzando DNS, HTTP e gRPC. Service Directory è integrato con Cloud DNS e può popolare i record Cloud DNS che corrispondono ai servizi in Service Directory.

Per saperne di più, consulta Configurare Service Directory per GKE.

Ottimizzare le prestazioni DNS e le best practice

Per garantire una Service Discovery affidabile ed efficiente, soprattutto nei cluster di grandi dimensioni o con traffico elevato, prendi in considerazione le seguenti best practice e strategie di ottimizzazione.

Ottimizzare le prestazioni con NodeLocal DNSCache

Per i cluster con un'elevata densità di pod o per le applicazioni che generano un volume elevato di query DNS, puoi migliorare la velocità di ricerca DNS abilitando NodeLocal DNSCache. NodeLocal DNSCache è un componente aggiuntivo GKE che esegue una cache DNS su ogni nodo del cluster. Quando un pod effettua una richiesta DNS, la richiesta viene inviata alla cache presente sullo stesso nodo. Questo approccio riduce la latenza e il traffico di rete.

Per saperne di più su come abilitare e configurare questa funzionalità, consulta Configurare NodeLocal DNSCache.

Scalare il provider DNS

Se utilizzi kube-dns e riscontri timeout intermittenti, soprattutto durante i periodi di traffico elevato, potresti dover scalare il numero di repliche kube-dns. kube-dns-autoscaler regola il numero di repliche in base al numero di nodi e core nel cluster e i relativi parametri possono essere ottimizzati per eseguire il deployment di più repliche prima.

Per istruzioni dettagliate, consulta Configurare un deployment kube-dns personalizzato.

Best practice generali

  • Selezionare il provider DNS appropriato: scegli il provider DNS in base alle esigenze del cluster. Cloud DNS è consigliato per i workload con QPS elevato, gli ambienti multi-cluster e quando è necessaria l'integrazione con la rete VPC più ampia. La nuova versione di kube-dns è adatta a un'ampia gamma di cluster, da piccoli a grandi, con esigenze di Service Discovery in-cluster standard.
  • Evitare VM spot o VM preemptible per kube-dns: contribuisci a garantire la stabilità del servizio DNS del cluster non eseguendo componenti di sistema critici come kube-dns su VM spot o VM preemptible. Le terminazioni impreviste dei nodi possono causare problemi di risoluzione DNS.
  • Utilizzare nomi di servizi chiari e descrittivi: adotta convenzioni di denominazione coerenti e significative per i tuoi servizi per semplificare la lettura e la manutenzione delle configurazioni delle applicazioni.
  • Organizzare con gli spazi dei nomi: utilizza gli spazi dei nomi Kubernetes per raggruppare i servizi correlati. Questo approccio contribuisce a evitare conflitti di denominazione e migliora l'organizzazione delle risorse del cluster.
  • Monitorare e convalidare il DNS: monitora regolarmente le metriche e i log DNS per identificare potenziali problemi prima che influiscano sulle applicazioni. Esegui periodicamente il test della risoluzione DNS dall'interno dei pod per assicurarti che la Service Discovery funzioni come previsto.

Passaggi successivi