Informazioni su Service Discovery

Questo documento spiega come 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 Cloud DNS, i servizi multicluster (MCS) e Service Directory.

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

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

Panoramica

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. Il servizio di rilevamento aiuta a garantire che le applicazioni abbiano sempre accesso a indirizzi IP dei pod aggiornati, anche quando i pod vengono riprogrammati o vengono aggiunti nuovi pod. GKE offre diversi modi per implementare il service discovery, tra cui kube-dns, deployment kube-dns personalizzati e Cloud DNS. Puoi ottimizzare ulteriormente le prestazioni del DNS con NodeLocal DNSCache.

Vantaggi di Service Discovery

Il rilevamento dei servizi offre i seguenti vantaggi:

  • Gestione semplificata delle applicazioni: l'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 in ambienti dinamici in cui gli indirizzi IP dei pod potrebbero cambiare a causa di scalabilità o riprogrammazione.
  • Scalabilità e resilienza semplificate: Service Discovery semplifica la scalabilità separando i consumer di servizi dagli indirizzi IP dei pod, che cambiano di frequente. Man mano che l'applicazione viene scalata o se i pod si arrestano e vengono sostituiti, Kubernetes aggiorna automaticamente i pod disponibili per ricevere traffico per un determinato servizio. Il rilevamento dei servizi contribuisce a garantire che le richieste al nome del servizio stabile vengano indirizzate solo ai pod integri, il che consente alla tua applicazione di scalare o ripristinarsi in caso di errori senza intervento manuale o riconfigurazione del client.
  • Alta disponibilità: GKE utilizza il bilanciamento del carico insieme al Service Discovery per garantire un'alta disponibilità e migliorare la reattività delle applicazioni, anche in condizioni di carico elevato.

Bilanciamento del carico con service discovery

GKE contribuisce a garantire l'alta disponibilità delle tue applicazioni combinando diversi livelli di bilanciamento del carico con il 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 il traffico in entrata in modo uniforme su più pod integri, evitando il sovraccarico e contribuendo a garantire l'alta disponibilità.
  • Servizi esterni: per i servizi che devono essere accessibili dall'esterno del cluster, GKE esegue il provisioning dei bilanciatori del carico. Google Cloud 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 tua 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, il 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 bilanciatori del carico Google Cloud (per i servizi esterni) indirizzino il traffico solo alle istanze integre.

Casi d'uso per Service Discovery

Di seguito sono riportati alcuni casi d'uso comuni per 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. Il Service Discovery consente a queste applicazioni di trovarsi e scambiarsi informazioni, anche durante lo scaling del cluster.
  • Attiva i deployment senza tempi di inattività e migliora la resilienza: Service Discovery facilita gli aggiornamenti senza tempi di inattività per le applicazioni, inclusi i rollout controllati e i deployment canary. Automatizza il rilevamento di nuove versioni del servizio e sposta il traffico su queste, contribuendo a ridurre i tempi di inattività durante il deployment e a garantire una transizione senza problemi per gli utenti. Service Discovery migliora anche la resilienza. Quando un pod non funziona in GKE, viene eseguito il deployment di un nuovo pod e il servizio di rilevamento registra il nuovo pod e reindirizza il traffico verso di esso, contribuendo a ridurre al minimo i tempi di inattività dell'applicazione.

Come funziona Service Discovery

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

Come 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 loro configurazione DNS locale.

Nomi DNS del servizio

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 personalizzarlo quando crei il cluster. Ad esempio, un servizio denominato my-web-app 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 seguente tabella descrive l'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 siano indirizzate al componente corretto:

  • NodeLocal DNSCache: fornisce ricerche locali rapide sul nodo.
  • IP server 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.
  • kube-dns Indirizzo IP del servizio: viene utilizzato per la risoluzione standard in-cluster quando Cloud DNS per GKE è disattivato.

Architettura DNS in GKE

GKE fornisce un'architettura flessibile per la Service Discovery, principalmente tramite 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:servizio DNS completamente gestito di Google Cloud. 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 personalizzato di kube-dns: un deployment che ti consente di eseguire il deployment e gestire la tua istanza di kube-dns, il che ti offre 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 loro funzionalità e quando scegliere ciascuno:

Provider Funzionalità Quando scegliere
`kube-dns` Risoluzione DNS nel cluster per servizi e pod. Tutti i cluster con esigenze di networking standard. La nuova versione di `kube-dns` è adatta a cluster di piccole e grandi dimensioni.
Cloud DNS Funzionalità DNS avanzate (zone private, gestione del traffico, bilanciamento del carico globale) e integrazione con altri servizi Google Cloud . Esposizione esterna dei servizi, ambienti multicluster o per cluster con tassi di query DNS elevati (QPS).
Deployment personalizzato di `kube-dns` Maggiore controllo su configurazione, allocazione delle risorse e possibilità di utilizzare provider DNS alternativi. Cluster su larga scala o esigenze DNS specifiche che richiedono una scalabilità più aggressiva o un controllo granulare sull'allocazione delle risorse.

Service Discovery al di fuori di un singolo cluster

Puoi estendere il 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 del servizio Kubernetes: <svc>.<ns>.svc.cluster.local.
  • Ambito VPC additivo: questa funzionalità facoltativa estende l'ambito del cluster rendendo risolvibili i servizi headless da altre risorse all'interno della stessa rete VPC, ad esempio VM Compute Engine o 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 quest'ultimo (tramite Cloud VPN o Cloud Interconnect) può risolvere direttamente i nomi dei servizi.

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

Servizi multi-cluster

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

MCS utilizza il Service Discovery basato su DNS per connettere i servizi tra i cluster. Quando crei un'istanza MCS, vengono generati record DNS nel formato <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 qualsiasi dei cluster partecipanti. Questa distribuzione del traffico è gestita da kube-proxy (o Cilium in GKE 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 registry unificato per l'individuazione dei servizi nei deployment Kubernetes e non Kubernetes. Service Directory può registrare servizi GKE e non GKE in un unico registry.

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 gestiti.
  • La possibilità di archiviare metadati sul tuo servizio a cui altri clienti 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ò compilare i record Cloud DNS che corrispondono ai servizi in Service Directory.

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

Ottimizzare le prestazioni e le best practice del DNS

Per garantire Service Discovery affidabile ed efficiente, soprattutto in 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'alta densità di pod o applicazioni che generano un volume elevato di query DNS, puoi migliorare la velocità di ricerca DNS attivando 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 sullo stesso nodo. Questo approccio riduce la latenza e il traffico di rete.

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

Scalare il provider DNS

Se utilizzi kube-dns e riscontri timeout intermittenti, in particolare durante i periodi di traffico elevato, potresti dover scalare il numero di repliche di 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 in tempi più brevi.

Per istruzioni dettagliate, consulta Scalabilità di kube-dns.

Best practice generali

  • Seleziona il provider DNS appropriato: scegli il provider DNS in base alle esigenze del tuo cluster. Cloud DNS è consigliato per i carichi di lavoro con QPS elevato, per gli ambienti multicluster 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, che hanno esigenze standard di Service Discovery in-cluster.
  • Evita 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. La chiusura imprevista dei nodi può causare problemi di risoluzione DNS.
  • Utilizza nomi di servizio 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.
  • Organizza con gli spazi dei nomi: utilizza gli spazi dei nomi Kubernetes per raggruppare i servizi correlati. Questo approccio aiuta a evitare conflitti di denominazione e migliora l'organizzazione delle risorse del cluster.
  • Monitora e convalida il DNS: monitora regolarmente le metriche e i log DNS per identificare potenziali problemi prima che influiscano sulle tue applicazioni. Esegui periodicamente test di risoluzione DNS dall'interno dei pod per assicurarti che la Service Discovery funzioni come previsto.

Passaggi successivi