Servizio canonico

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

Questa pagina spiega 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 architetturale per rappresentare i tuoi workload di produzione come un singolo servizio più facile da osservare e gestire. Questi workload possono estendersi su più cluster, piattaforme backend disparate e schemi e configurazioni diversi.

Per gli utenti di Kubernetes: il servizio canonico è approssimativamente analogo al concetto di "app" di Kubernetes e di definizione di risorsa personalizzata delle applicazioni.

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 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 canonico:

  • Un servizio ha un'interruzione.
  • Un servizio viene eseguito sia on-premise sia su un cloud pubblico.
  • Viene eseguito il 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 anche univoci all'interno di un parco risorse e di un progetto Google Cloud(che hanno tutti una corrispondenza one-to-one con il mesh).

Un determinato workload 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
  • Policy 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 ogni servizio nella pagina Servizi.

Requisiti e limitazioni dei servizi canonici

I servizi canonici sono disponibili solo su Cloud Service Mesh versione 1.6.8 e 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 del suo spazio dei nomi padre. Per saperne di più, consulta Definisci 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, questi non sono fattori determinanti per 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 alle modifiche incrementali di un servizio, utili per distinguere e identificare diverse "versioni" o "release" dei servizi.

Per distinguere le revisioni di un servizio canonico, etichetta un singolo workload con la relativa "revisione canonica". Questa etichetta è una stringa arbitraria che puoi definire. Anche se in alcuni casi l'etichetta può essere impostata automaticamente, deve essere applicata da te o dal sistema CI/CD che esegue il deployment del servizio. Per indicazioni sull'impostazione di questa etichetta, consulta Definisci un servizio canonico.

Tieni presente che più revisioni possono essere in produzione nello stesso momento. L'esecuzione di più revisioni contemporaneamente viene spesso utilizzata per:

  • L'implementazione progressiva di un nuovo file binario, una nuova configurazione o entrambi in tutte le istanze di un servizio. In questo caso, sia la revisione precedente sia quella nuova sono attive durante la transizione.
  • Un "test A/B" o "esperimento in tempo reale", in cui due versioni diverse del servizio vengono mostrate a sottoinsiemi di chiamanti downstream per testare l'effetto di una modifica.

Passaggi successivi