Versione 1.14

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Servizio canonico

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

Questa pagina spiega che cos'è un servizio canonico in Anthos Service Mesh.

Che cos'è un servizio canonico?

Anthos Service Mesh 1.6.8 introduce il supporto per i servizi canonici, un modello concettuale e architettonico per rappresentare i tuoi carichi di lavoro di produzione come servizio unico, più semplice da osservare e gestire. Questi carichi di lavoro possono comprendere più cluster, piattaforme di backend disparate e schemi e configurazioni diversi.

Per gli utenti di Kubernetes: il servizio canonico è più o meno analogo al concetto di "Kubernetes" dell'app e al CRD dell'applicazione.

Per gli utenti serverless: il servizio di canonicalizzazione è molto simile ai concetti di servizio App Engine e servizio Cloud Run. L'unica differenza è che i servizi Google Serverless sono intrinsecamente a livello di area geografica, mentre i servizi canonici sono un'astrazione globale / a più aree geografiche.

Ad esempio, i seguenti scenari descrivono tutti i modi in cui puoi fare riferimento a un servizio canonico:

  • Si è verificata un'interruzione del servizio.
  • Un servizio viene eseguito sia on-premise che su 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 Anthos Service Mesh sono anche univoci all'interno di un parco risorse e di un progetto Google Cloud (tutti integrati con Mesh).

Un determinato carico di lavoro può far parte di un solo servizio canonico.

Puoi determinare l'ambito completo di un servizio canonico dal gruppo di 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
  • Aree geografiche
  • Sistema CI/CD
  • Codice sorgente
  • Telemetria
  • Obiettivi e avvisi del livello del servizio

Puoi visualizzare le dashboard che mostrano questi dettagli operativi per ogni servizio nella pagina Anthos Services.

Requisiti e limitazioni dei servizi canonici

I servizi canonici sono disponibili solo su Anthos 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ò attraversare 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, consulta l'articolo Definire un servizio canonico.

I servizi canonici possono esistere in più cluster e aree geografiche. Sebbene sia possibile suddividere le risorse e la telemetria per cluster e area geografica, queste non sono fattori determinanti per la determinazione dell'ambito o dell'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" dei tuoi servizi.

Distinguere 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 esegue il deployment del servizio dovete applicarla. Per indicazioni sull'impostazione di questa etichetta, consulta la sezione Definire un servizio canonico.

Tieni presente che più revisioni possono essere in produzione contemporaneamente. L'esecuzione di più revisioni contemporaneamente viene utilizzata con maggiore frequenza:

  • Implementazione progressiva di un nuovo programma binario, una nuova configurazione o entrambe le istanze di un solo servizio. In questo caso, sia la vecchia che la nuova revisione sono attive durante la transizione.
  • Un "test A/B" o "un esperimento in tempo reale", in cui due diverse versioni del servizio sono esposte a sottoinsiemi di chiamanti downstream per verificare l'effetto di una modifica.

Passaggi successivi