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 modello concettuale e architettonico per rappresentare i carichi di lavoro di produzione come un singolo servizio più facile 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 di Kubernetes: il servizio Canonical è approssimativamente analogo al concetto di "app" di Kubernetes e al CRD Application.

Per gli utenti serverless: il servizio canonico è molto simile ai concetti di servizio App Engine e 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, gli scenari che seguono descrivono tutti modi in cui potresti fare riferimento a un Servizio canonico:

  • Un servizio ha subito un'interruzione.
  • 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 in Cloud Service Mesh significa che sono unici anche all'interno di un flotta e di un progetto Google Cloud (tutti in uno a uno con il 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 dashboard che mostrano questi dettagli operativi per ciascun servizio sulla 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 e non può oltrepassare i confini dello spazio dei nomi.

Devi assegnare a un servizio Canonical un nome univoco all'interno del relativo spazio dei nomi principale. Per maggiori informazioni, consulta la sezione Definire un servizio canonico.

I servizi Canonical possono esistere in più cluster e regioni. Anche se è possibile suddividere le risorse e la telemetria per cluster e regione, non fattori nel determinare 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. Sebbene in alcuni casi l'etichetta possa essere impostata automaticamente, devi essere tu o il sistema CI/CD che esegue il deployment del servizio ad applicarla. Per indicazioni su l'impostazione di questa etichetta, consulta Definire un servizio canonico.

Tieni presente che più revisioni possono essere in produzione contemporaneamente. L'esecuzione di 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 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