Servizio canonico

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

Questa pagina spiega cos'è un servizio canonico in Anthos Service Mesh.

Che cos'è un servizio canonico?

Anthos Service Mesh 1.6.8 introduce il supporto per i servizi canonici, un modello concettuale e architettonico per la rappresentazione dei carichi di lavoro di produzione come un singolo servizio più facile da osservare e gestire. Questi carichi di lavoro possono comprendere più cluster, piattaforme di backend e schemi e configurazioni differenti.

Per gli utenti di Compute Engine: il servizio canonico è sostanzialmente analogo ai gruppi di istanze gestite, anche se un servizio canonico può essere multiregionale.

Per gli utenti di Kubernetes: il servizio Canonical è simile al concetto di "app" di Kubernetes e al CRD dell'applicazione.

Per gli utenti serverless: il servizio canonico è molto simile ai concetti del servizio App Engine e del servizio Cloud Run. L'unica differenza è che i servizi Google Serverless sono intrinsecamente regionali, mentre i servizi canonici sono un'astrazione globale o multiregionale.

Ad esempio, tutti gli scenari seguenti descrivono modi in cui potresti fare riferimento a un servizio canonico:

  • Un servizio ha un'interruzione.
  • Un servizio viene eseguito sia on-premise che su un cloud pubblico.
  • Deployment di una nuova revisione di un servizio.
  • Il servizio Foo sta inviando troppo traffico e potrebbe superare la nostra capacità.

I servizi canonici esistono all'interno di un singolo mesh, quindi in Anthos Service Mesh sono univoci anche all'interno di un parco risorse e un progetto Google Cloud (tutti one-to-one con mesh).

Un determinato carico di lavoro può far parte di un solo servizio canonico.

Puoi determinare l'ambito completo di un servizio canonico dal gruppo di carichi di lavoro che lo definiscono, tra cui:

  • Nomi host e indirizzi IP
  • Reti
  • Criteri di rete e sicurezza
  • Routing e bilanciamento del carico
  • Immagini VM e container
  • Infrastruttura fisica o virtuale
  • Regioni geografiche
  • Sistema CI/CD
  • Codice sorgente
  • Telemetria
  • Obiettivi e avvisi del livello di servizio

Puoi visualizzare le dashboard che mostrano questi dettagli operativi per ciascun servizio nella pagina Servizi GKE Enterprise.

Requisiti e limitazioni del servizio canonico

I servizi canonici sono disponibili solo su Anthos Service Mesh versione 1.6.8 e successive.

Ogni servizio canonico esiste all'interno di un singolo spazio dei nomi Kubernetes/Istio e non può superare i limiti dello spazio dei nomi.

Devi assegnare a un servizio canonico un nome univoco all'interno dello spazio dei nomi padre. Per ulteriori informazioni, consulta la sezione Definizione di un servizio canonico.

I servizi canonici possono esistere in più cluster e regioni. Sebbene sia possibile suddividere le risorse e la telemetria per cluster e regione, questi non sono fattori nel determinare l'ambito o l'univocità di un servizio.

Pertanto, l'identità univoca di un servizio canonico è determinata da:

mesh id + namespace + canonical name.

Revisioni

Le revisioni si riferiscono a modifiche incrementali a un servizio che puoi utilizzare per distinguere e identificare diverse "versioni" o "release" dei servizi.

Distinguere le revisioni di un servizio canonico etichettando un singolo carico di lavoro con la "revisione canonica". Questa etichetta è una stringa arbitraria che puoi definire. Sebbene in alcuni casi l'etichetta possa essere impostata automaticamente, è necessario applicarla tu o il sistema CI/CD che esegue il deployment del servizio. Per indicazioni sull'impostazione di questa etichetta, consulta Definizione di un servizio canonico.

Tieni presente che più revisioni possono essere in produzione contemporaneamente. Il più delle volte è possibile eseguire più revisioni contemporaneamente per:

  • L'implementazione progressiva di un nuovo programma binario, di una nuova configurazione o di entrambi in tutte le istanze del servizio in questione. In questo caso, sia la vecchia che la nuova revisione sono attive durante la transizione.
  • Un "test A/B" o un "esperimento in tempo reale", in cui due versioni diverse del servizio sono esposte a sottoinsiemi di chiamanti a valle per testare l'effetto di una modifica.

Passaggi successivi