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 workload 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, 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 in Cloud Service Mesh significa che sono unici anche all'interno di un flotta e di un progetto Google Cloud (tutti uno a uno con il mesh).

Un determinato workload 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 Canonical

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

Pertanto, 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. Sebbene in alcuni casi l'etichetta possa essere impostata automaticamente, devi applicarla tu o il sistema CI/CD che esegue il deployment del servizio. 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 le revisioni vecchie che quelle nuove 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 a valle per testare l'effetto di una modifica.

Passaggi successivi