Servizio canonico

Nota: i servizi canonici sono supportati automaticamente in Cloud Service Mesh versione 1.6.8 e 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 i servizi canonici, un concetto concettuale e architetturale per la rappresentazione dei carichi di lavoro di produzione come singolare più semplice da osservare e gestire. Questi carichi di lavoro possono essere distribuiti su più cluster, piattaforme di backend diverse e schemi e configurazioni diversi.

Per gli utenti Kubernetes: Canonical Service è più o meno analogo alla "App" Kubernetes e l'Application CRD.

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

Ad esempio, gli scenari che seguono descrivono tutti modi in cui potresti fare riferimento a un Servizio canonico:

  • Si è verificata un'interruzione del servizio.
  • 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 in Cloud Service Mesh sono univoci anche all'interno fleet e una piattaforma Google Cloud progetto (tutti one-to-one con mesh).

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

Puoi determinare l'ambito completo di un servizio canonico dal gruppo di workload 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 Servizi GKE Enterprise.

Requisiti e limitazioni del servizio canonico

I servizi Canonical sono disponibili solo su Cloud Service Mesh versione 1.6.8 e superiori.

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

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

I servizi canonici possono esistere in più cluster e regioni. Sebbene sia possibile suddividere le risorse e la telemetria in base a cluster e regione, questi non sono fattori che determinano l'ambito o l'unicità 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 di un servizio, utili 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. In alcuni casi l'etichetta può essere impostata automaticamente, ma tu o il sistema CI/CD che distribuisce il servizio deve applicare l'etichetta. Per indicazioni su l'impostazione di questa etichetta, consulta la sezione Definizione di un servizio canonico.

Tieni presente che è possibile avere più revisioni in produzione contemporaneamente. Esecuzione più revisioni contemporaneamente viene utilizzata più spesso per:

  • L'implementazione progressiva di un nuovo programma binario, una nuova configurazione o entrambi in tutte le istanze del proprio servizio. In questo caso, sia il vecchio che il le nuove revisioni sono disponibili durante la transizione.
  • Un "test A/B" o "esperimento in tempo reale", in cui due diverse versioni sono esposti a sottoinsiemi di chiamanti downstream per testare l'effetto modifica.

Passaggi successivi