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 Kubernetes: Canonical Service è più o meno analogo alla "App" Kubernetes e l'Application CRD.

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

È possibile determinare l'ambito completo di un servizio canonico dal gruppo carichi di lavoro 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 canonici sono disponibili solo su Cloud Service Mesh versione 1.6.8 e in alto.

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 Canonical un nome univoco all'interno del relativo spazio dei nomi principale. Per ulteriori informazioni, vedi definizione di 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.

Pertanto, l'identità univoca di un servizio canonico è determinata da:

mesh id + namespace + canonical name.

Revisioni

Le revisioni si riferiscono a modifiche incrementali a un servizio che puoi utilizzare distinguere e identificare diverse "versioni" o "uscite" dei tuoi 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 come impostare questa etichetta, consulta Definire 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 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