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
- Definizione di un servizio canonico.
- Best practice per i servizi Canonical.
- Risoluzione dei problemi relativi ai servizi canonici.