Risoluzione dei problemi dei servizi canonici in Anthos Service Mesh

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

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

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

Se uno dei tuoi cluster esegue una versione precedente di Anthos Service Mesh (<1.6.8) o se un cluster esegue Anthos Service Mesh con il controller di servizio canonico disabilitato, i cluster (e i servizi in esecuzione) non verranno visualizzati nella UI di Service Mesh. Per utilizzare i servizi canonici, devi eseguire l'upgrade di ogni cluster ad Anthos Service Mesh 1.6.8 o versioni successive e utilizzare l'opzione di installazione predefinita che include il controller del servizio canonico. Per ulteriori informazioni, consulta Upgrade di Anthos Service Mesh alla versione più recente se i tuoi cluster si trovano su GKE o Upgrade di Anthos 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.

Anthos Service Mesh non è installato sul cluster

Se Anthos Service Mesh non è installato su nessuno dei tuoi cluster, questi cluster non verranno visualizzati nella UI di Service Mesh. Per ulteriori informazioni su come installare Anthos Service Mesh, consulta la documentazione di Anthos 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 tuo cluster on-premise non è raggiungibile

Se hai un cluster on-premise nel mesh e 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 cluster sia in esecuzione e connesso a Google Cloud. Per ulteriori informazioni sulla connessione del cluster a Google Cloud, consulta la panoramica della connessione.

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

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

Se hai degli obiettivi del livello di servizio (SLO) configurati sui servizi esistenti che non possono essere abbinati automaticamente a un servizio canonico predefinito, non è possibile eseguire la migrazione di questi obiettivi. Per iniziare a utilizzare i servizi canonici, devi eliminare gli SLO per il servizio problematico. Se vuoi, puoi creare nuovi SLO per i servizi canonici più simili a quel servizio prima di eliminare il vecchio SLO.

La mia dashboard non include i contenuti previsti

Ciascuna dashboard di servizio Mesh di servizi ha come ambito un servizio canonico nel tuo mesh di servizi, dove un servizio canonico è un concetto di servizio logico di alto livello che abbraccia 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) definiscono i servizi canonici e seguono queste regole per diminuire la 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 e il suo 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 suo valore viene impostato su quello dell'etichetta app.
In caso contrario, viene aggiunta l'etichetta service.istio.io/canonical-name e il suo valore viene impostato su name del carico di lavoro proprietario. In questo caso è il "carico di lavoro in possesso della proprietà", se il pod viene eseguito da solo, oppure il deployment, lo StatefulSet e così via se si utilizza 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 tuoi servizi e carichi di lavoro.

In alcuni casi d'uso più personalizzati o più complessi, tuttavia, l'euristica predefinita non acquisisce il servizio in modo appropriato e, a sua volta, la dashboard di Anthos Service Mesh 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 i meccanismi di raggruppamento automatico predefinito. Tuttavia, se vuoi eseguire l'override di questi raggruppamenti predefiniti, puoi applicare l'etichetta Kubernetes service.istio.io/canonical-name alle configurazioni di pod Kubernetes e WorkloadEntry.

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