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

È 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 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 canonico un nome univoco all'interno dello spazio dei nomi padre. Per ulteriori informazioni, vedi definizione di 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. 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 l'impostazione di questa etichetta, consulta la sezione Definizione di 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 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 "esperimento in tempo reale", in cui due diverse versioni sono esposti a sottoinsiemi di chiamanti downstream per testare l'effetto modifica.

Passaggi successivi