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 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 abbracciare diversi, varie piattaforme di backend e schemi e configurazioni differenti.

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, i seguenti scenari descrivono tutti i modi in cui potresti fare riferimento a un servizio canonical:

  • Si è verificata un'interruzione del servizio.
  • Un servizio viene eseguito sia on-premise sia in 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, 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 canonico.

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.

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 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 Canonical 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.

Distingui le revisioni di un servizio canonico etichettando un singolo workload 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 come impostare questa etichetta, consulta Definire un servizio canonico.

Tieni presente che è possibile avere più revisioni in produzione contemporaneamente. L'esecuzione di più revisioni contemporaneamente viene utilizzata più spesso per:

  • L'implementazione progressiva di un nuovo file binario, di una nuova configurazione o di entrambi in tutte le istanze del servizio. In questo caso, sia il vecchio che il le nuove revisioni sono disponibili 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 a valle per testare l'effetto di una modifica.

Passaggi successivi