Risolvere i problemi relativi ai servizi canonici in Anthos Service Mesh

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

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

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

Se in uno dei tuoi cluster è in esecuzione una versione precedente di Anthos Service Mesh (<1.6.8) o se in un cluster è in esecuzione 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 la pagina relativa all'upgrade di Anthos Service Mesh alla versione più recente se i cluster sono su GKE o a l'upgrade di Anthos Service Mesh on-premise

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

Per ulteriori informazioni sull'attivazione del controller dei servizi canonici, consulta l'articolo Attivare il controller dei servizi canonici.

Anthos Service Mesh non è installato nel cluster

Se Anthos Service Mesh non è installato in nessuno dei cluster, questi cluster non verranno visualizzati nella UI di Service Mesh. Per saperne di più 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 al cluster. Per visualizzare questi servizi nella dashboard, devi accedere al cluster. Per saperne di più su come accedere a un cluster, consulta Accesso a un cluster da Cloud Console.

Il 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 al 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 tuo cluster a Google Cloud, consulta Panoramica della connessione

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

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

Se hai configurato obiettivi dei livelli di servizio (SLO) su servizi esistenti che non possono essere abbinati automaticamente a un servizio canonico predefinito, non è possibile eseguirne la migrazione. Per iniziare a utilizzare i servizi canonici, dovrai eliminare gli SLO per il servizio problematico. Se vuoi, puoi creare nuovi SLO per i servizi canonici che corrispondono il più possibile al servizio in questione prima di eliminare il vecchio SLO.

La mia dashboard non ha i contenuti che mi aspettavo

Le dashboard di servizio di Mesh di servizi hanno un ambito per un servizio canonico nel mesh di servizi, in cui un servizio canonico è un concetto logico di alto livello che copre tutti i carichi di lavoro, le regioni e così via.

Per impostazione predefinita, le etichette esistenti in ogni istanza del carico di lavoro (pod o WorkloadEntry) definiscono i servizi canonici e seguono queste regole in ordine di priorità decrescente:

L'etichetta service.istio.io/canonical-name è già stata impostata in modo esplicito. Non vengono intraprese altre 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 proprietario" se viene eseguito il deployment del pod in modo autonomo, oppure il deployment, lo StatefulSet e così via se viene utilizzata l'orchestrazione di livello superiore.

Per la maggior parte degli utenti idiomatici di Kubernetes e Kube Run / Knative, queste regole mappano direttamente il 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 acquisisce correttamente il servizio e, a sua volta, la dashboard di Anthos Service Mesh visualizzata non include i contenuti previsti.

Per risolvere il problema, definisci manualmente l'ambito del servizio canonico.

Definizione manuale dell'ambito di un servizio

Dove possibile, ti consigliamo di utilizzare i meccanismi di raggruppamento predefiniti automatici. Se invece vuoi eseguire l'override di questi raggruppamenti predefiniti, puoi farlo applicando l'etichetta Kubernetes service.istio.io/canonical-name alle configurazioni del pod e del carico di lavoro Kubernetes.

Per i dettagli, vedi Definire manualmente un servizio canonico.