Risoluzione dei problemi dei servizi canonici in Cloud Service Mesh

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

Questa sezione illustra i problemi comuni di Cloud Service Mesh e come risolverli. Se hai bisogno di ulteriore aiuto, vedi 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 Canonical Service disabilitato, i cluster (e i servizi in esecuzione su di essi) non verranno visualizzati nella UI di Service Mesh. Per utilizzare Canonical Per i servizi, è necessario eseguire l'upgrade di ogni cluster a Cloud Service Mesh 1.6.8 o versioni successive e usa l'opzione di installazione predefinita che include il controller del servizio canonico. Per ulteriori informazioni, consulta Upgrade di Cloud Service Mesh alla versione più recente se i tuoi cluster si trovano su GKE Upgrade di Cloud Service Mesh on-premise.

In alternativa, se preferisci non installare il controller nei cluster, puoi abilitare il controller di servizi canonici gestiti (attualmente in anteprima) per il mesh.

Per ulteriori informazioni sull'abilitazione del controller del servizio canonico, consulta Abilitazione del controller del servizio canonico.

Cloud Service Mesh non è installato sul cluster

Se Cloud Service Mesh non è installato su nessuno dei tuoi cluster, questi verranno non vengono visualizzati nella UI di Service Mesh. Per ulteriori informazioni sull'installazione 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 alla 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 Accesso a un cluster dalla console Cloud.

Il tuo cluster on-premise non è raggiungibile

Se nella mesh è presente un cluster on-premise che non è raggiungibile tramite connetti l'agente, non potrai visualizzare i servizi corrispondenti in un cluster Kubernetes. Per visualizzare questi servizi nella dashboard, assicurati che di un cluster è in esecuzione ed è connesso a Google Cloud. Per ulteriori informazioni sulla connessione del cluster a Google Cloud, Panoramica di Connect.

Un servizio con SLO definiti non mappa 1:1 con un servizio canonico

Prima del passaggio al servizio canonico, Cloud Service Mesh ha mostrato le dashboard per i servizi Kubernetes. Mentre Kubernetes I servizi e i servizi canonici predefiniti spesso sono allineati, è possibile che Il servizio Kubernetes non può essere abbinato automaticamente alla versione canonica corrispondente o che il limite predefinito del servizio canonico è non desiderato.

Se hai degli obiettivi del livello di servizio (SLO) configurati su servizi esistenti che non possono essere abbinati automaticamente a un servizio canonico predefinito, di cui è stata eseguita la migrazione. Per iniziare a utilizzare i servizi canonici, devi eliminare gli SLO per il servizio problematico. Se vuoi, puoi crea nuovi SLO per l'ambiente canonico I servizi che più corrispondono a quel servizio prima di eliminare il vecchio SLO.

La mia dashboard non include i contenuti previsti

Ciascuna dashboard del servizio di Service Mesh ha come ambito una Servizio canonico nel tuo mesh di servizi, dove un servizio canonico è un concetto di servizio logico di alto livello che si estende per tutti i carichi di lavoro, le regioni e così via pertinenti

Per impostazione predefinita, le etichette esistenti in ogni istanza del carico di lavoro (pod o WorkloadEntry) definire i servizi canonici e seguire queste regole per diminuire priorità:

L'etichetta service.istio.io/canonical-name è già stata impostata in modo esplicito. Non verranno intraprese ulteriori azioni.
In caso contrario, viene aggiunta l'etichetta service.istio.io/canonical-name con il relativo valore è impostato su quello dell'etichetta app.kubernetes.io/name.
In caso contrario, viene aggiunta l'etichetta service.istio.io/canonical-name con il relativo valore è impostato su quello dell'etichetta app.
In caso contrario, viene aggiunta l'etichetta service.istio.io/canonical-name con il relativo valore è impostato sul valore name del carico di lavoro proprietario. Il "carico di lavoro di proprietà" in questo se il pod viene eseguito da solo oppure il deployment, lo StatefulSet e così via. mediante un'orchestrazione di livello superiore.

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

In alcuni casi d'uso più personalizzati o più complessi, tuttavia, l'euristica predefinita non acquisiscono in modo appropriato il servizio e, a loro volta, Cloud Service Mesh che vedi non include i contenuti previsti.

Puoi risolvere questo problema definendo manualmente l'ambito del servizio canonico.

Definizione manuale dell'ambito di un servizio

Ove possibile, ti consigliamo di utilizzare il raggruppamento predefinito automatico i meccanismi della ricerca di informazioni. Tuttavia, se vuoi eseguire l'override di questi raggruppamenti predefiniti, quindi applicando l'etichetta Kubernetes service.istio.io/canonical-name configurazioni di pod Kubernetes e WorkloadEntry.

Per maggiori dettagli, consulta la sezione Definizione manuale di un servizio canonico.