Anthos Service Mesh 1.8 ha raggiunto la fine del ciclo di vita e non è più supportato. Vedi Upgrade da versioni precedenti.

Visualizza la documentazione più recente o seleziona un'altra versione disponibile:

Versioni disponibili

1.20 (ultima versione)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Risoluzione dei problemi del servizio canonico in Anthos Service Mesh

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

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

I carichi di lavoro Kubernetes senza un servizio Kubernetes non vengono visualizzati

Se viene visualizzato il messaggio "I carichi di lavoro Kubernetes senza un servizio Kubernetes non vengono visualizzati. Crea un servizio Kubernetes per ogni carico di lavoro per visualizzarli di seguito", devi eseguire manualmente la migrazione ai servizi canonici.

Le cause principali di questo problema sono due:

I cluster nel tuo mesh eseguono una versione precedente di Anthos Service Mesh (< 1.6.8)
Un servizio con SLO definiti non mappa 1:1 con un servizio canonico

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

Se uno dei tuoi cluster esegue una versione precedente di ASM (<1.6.8), non hai l'idoneità per le dashboard basate su Canonical Service. Per utilizzare i servizi canonici, devi eseguire l'upgrade di tutti i cluster ad Anthos Service Mesh 1.6.8 o versioni successive. Per ulteriori informazioni, consulta Upgrade di Anthos Service Mesh alla versione più recente se i cluster sono su GKE o Upgrade di Anthos Service Mesh on-premise se i cluster sono on-premise.

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. Anche se i servizi Kubernetes e i servizi canonici predefiniti spesso sono allineati, è possibile che un servizio Kubernetes non possa essere abbinato automaticamente al servizio canonico corrispondente o che il confine del servizio canonico predefinito non sia desiderato.

Se hai configurato obiettivi del livello 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, devi eliminare gli SLO per il servizio problematico. Se vuoi, puoi creare nuovi SLO per i servizi canonici che corrispondono maggiormente al servizio prima di eliminare il vecchio SLO.

Nella mia dashboard non sono presenti i contenuti previsti

Le dashboard di servizio del mesh di servizi hanno ciascun ambito di 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, 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 con priorità decrescente:

L'etichetta service.istio.io/canonical-name è già stata impostata esplicitamente. Non vengono intraprese ulteriori azioni.
In caso contrario, l'etichetta service.istio.io/canonical-name viene aggiunta e il suo valore viene impostato su quello dell'etichetta app.kubernetes.io/name.
In caso contrario, l'etichetta service.istio.io/canonical-name viene aggiunta e il suo valore viene impostato su quello dell'etichetta app.
In caso contrario, l'etichetta service.istio.io/canonical-name viene aggiunta e il suo valore viene impostato sul name del carico di lavoro proprietario. Il "carico di lavoro proprietario" in questo caso, se viene eseguito il deployment del pod in modo indipendente, oppure del deployment, dello 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 sono mappate 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, l'euristica predefinita non acquisisce il servizio in modo appropriato e, a sua volta, la dashboard Anthos Service Mesh che vedi non include i contenuti previsti.

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

Definizione manuale dell'ambito di un servizio

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

Per maggiori dettagli, vedi Definire manualmente un servizio canonico.