Servizio canonico

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

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

Che cos'è un servizio canonico?

Cloud Service Mesh 1.6.8 introduce il supporto per Canonical Services, un modello concettuale e architetturale per la rappresentazione dei carichi di lavoro di produzione come un unico servizio più facile da osservare e gestire. Questi carichi di lavoro possono coprire più cluster, varie piattaforme di backend e schemi e configurazioni differenti.

Per gli utenti Kubernetes: Canonical Service è più o meno analogo al concetto di "app" Kubernetes e alla CRD dell'applicazione.

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

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

  • Un servizio ha subito un'interruzione.
  • Un servizio viene eseguito sia in loco che su un cloud pubblico.
  • Deployment di una nuova revisione di un servizio.
  • Il servizio Foo invia troppo traffico e potrebbe superare la nostra capacità.

I servizi canonici esistono all'interno di un singolo mesh, il che significa che sono univoci anche all'interno di un parco risorse e di 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 del livello di servizio e avvisi

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

Requisiti e limitazioni del servizio canonico

I servizi canonici sono disponibili solo su Cloud Service Mesh 1.6.8 e versioni successive.

Ogni servizio canonico esiste all'interno di un singolo spazio dei nomi Kubernetes/Istio e non può superare i confini 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, non sono fattori che determinano l'ambito o l'univocità di un servizio.

Di conseguenza, 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 tra le revisioni di un servizio canonico etichettando un singolo carico di lavoro con la relativa "revisione canonica". Questa etichetta è una stringa arbitraria che puoi definire. Sebbene l'etichetta possa essere impostata automaticamente in alcuni casi, tu o il sistema CI/CD che esegue il deployment del servizio dovete applicarla. Per indicazioni sull'impostazione di questa etichetta, consulta la sezione Definizione di un servizio canonico.

Tieni presente che più revisioni possono essere in produzione contemporaneamente. L'esecuzione di più revisioni contemporaneamente consente di:

  • L'implementazione progressiva di un nuovo programma binario, di una nuova configurazione o di entrambi in tutte le istanze di un servizio. 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 vengono esposte a sottoinsiemi di chiamanti downstream per testare l'effetto di una modifica.

Passaggi successivi