Risolvere i problemi relativi ai servizi canonici in Cloud Service Mesh

Nota: i servizi canonici sono supportati automaticamente in Cloud Service Mesh versione 1.6.8 e successive.

Questa sezione illustra i problemi comuni di Cloud Service Mesh e come risolverli. Se hai bisogno di ulteriore assistenza, consulta la sezione Ricevere assistenza.

I cluster nel tuo mesh eseguono una versione precedente di Cloud Service Mesh

Se uno dei tuoi cluster esegue una versione precedente di Cloud Service Mesh (<1.6.8) o un cluster esegue Cloud Service Mesh con il controller di servizio Canonical disattivato, questi cluster (e i servizi in esecuzione su di essi) non verranno visualizzati nell'interfaccia utente di Service Mesh. Per utilizzare Canonical Services, devi eseguire l'upgrade di ogni cluster a Cloud Service Mesh 1.6.8 o versioni successive e utilizzare l'opzione di installazione predefinita che include il controller Canonical Service. Per saperne di più, consulta Eseguire l'upgrade di Cloud Service Mesh alla versione più recente se i tuoi cluster sono su GKE o Eseguire l'upgrade di Cloud Service Mesh on-premise.

In alternativa, se preferisci non installare il controller nei tuoi cluster, puoi attivare il controller di servizio Canonical gestito (attualmente in anteprima) per il tuo mesh.

Per ulteriori informazioni sull'abilitazione del controller del servizio di canonicalizzazione, vedi Abilitare il controller del servizio di canonicalizzazione.

Cloud Service Mesh non è installato nel cluster

Se Cloud Service Mesh non è installato su nessuno dei tuoi cluster, questi cluster non verranno visualizzati nell'interfaccia utente di Service Mesh. Per ulteriori informazioni su come installare Cloud Service Mesh, consulta la documentazione di Cloud Service Mesh.

Non hai eseguito l'accesso al cluster on-premise

Se hai un cluster on-premise nel mesh e non hai eseguito l'accesso al cluster, non potrai visualizzare i servizi corrispondenti a quel cluster. Per visualizzare questi servizi nella dashboard, devi accedere al cluster. Per ulteriori informazioni sull'accesso a un cluster, consulta Accedere a un cluster dalla console Cloud.

Il cluster on-premise non è raggiungibile

Se nel mesh è presente un cluster on-premise non raggiungibile tramite l'agente di connessione, non potrai visualizzare i servizi corrispondenti a quel cluster. Per visualizzare questi servizi nella dashboard, assicurati che il tuo cluster sia in esecuzione e connesso a Google Cloud. Per ulteriori informazioni sulla connessione del cluster a Google Cloud, consulta la panoramica di Connect.

Un servizio con SLO definite non viene mappato 1:1 con un servizio canonico

Prima del passaggio a Canonical Service, Cloud Service Mesh mostrava le dashboard per i servizi Kubernetes. Sebbene i servizi Kubernetes e i servizi Canonical predefiniti siano spesso in linea, è possibile che un servizio Kubernetes non possa essere associato automaticamente al servizio Canonical corrispondente o che il confine del servizio Canonical predefinito non sia desiderato.

Se hai configurato obiettivi del livello di servizio (SLO) per i servizi esistenti che non possono essere abbinati automaticamente a un servizio canonico predefinito, non è possibile eseguire la migrazione. Per iniziare a utilizzare i servizi Canonical, devi eliminare gli SLO per il servizio problematico. Se vuoi, puoi creare nuovi SLO per i servizi canonicali più adatti al servizio prima di eliminare il vecchio SLO.

La mia dashboard non contiene i contenuti che mi aspetto

Le dashboard dei servizi di Service Mesh sono ciascuna associate a un servizio canonico nel tuo mesh di servizi, dove un servizio canonico è un concetto di servizio logico di alto livello che si estende a tutti i carichi di lavoro, le regioni e così via pertinenti.

Per impostazione predefinita, le etichette esistenti in ogni istanza di workload (Pod o WorkloadEntry) definiscono i servizi canonici e rispettano queste regole in ordine di priorità decrescente:

L'etichetta service.istio.io/canonical-name è già stata impostata in modo esplicito. Non vengono presi ulteriori provvedimenti.
In caso contrario, viene aggiunta l'etichetta service.istio.io/canonical-name e il relativo valore viene impostato su quello dell'etichetta app.kubernetes.io/name.
In caso contrario, viene aggiunta l'etichetta service.istio.io/canonical-name e il relativo valore viene impostato su quello dell'etichetta app.
In caso contrario, viene aggiunta l'etichetta service.istio.io/canonical-name e il relativo valore viene impostato sul name del workload proprietario. In questo caso, il "carico di lavoro proprietario" è il pod se viene eseguito il deployment solo del pod oppure il deployment, StatefulSet e così via se viene utilizzata l'orchestrazione di livello superiore.

Per la maggior parte degli utenti esperti di Kubernetes e Kube Run / Knative, queste regole si mappano direttamente al modo in cui gestisci già i tuoi servizi e carichi di lavoro.

Tuttavia, in alcuni casi d'uso più personalizzati o più complessi, le strategie di euristica predefinite non acquisiscono il servizio in modo appropriato e, di conseguenza, la dashboard di Cloud Service Mesh che vedi non include i contenuti previsti.

Il problema può essere risolto definendo manualmente l'ambito del servizio canonico.

Definire manualmente l'ambito di un servizio

Se possibile, ti consigliamo di utilizzare i meccanismi di raggruppamento predefiniti automatici. Tuttavia, se vuoi ignorare questi raggruppamenti predefiniti, puoi farlo applicando l'etichetta Kubernetes service.istio.io/canonical-name alle configurazioni del pod e di WorkloadEntry di Kubernetes.

Per maggiori dettagli, vedi Definire manualmente un servizio Canonical.