Anthos Service Mesh 1.10 ha raggiunto la fine del ciclo di vita e non è più supportato. Vedi Upgrade da versioni precedenti.

Visualizza la documentazione più recente o seleziona un'altra versione disponibile:

Versioni disponibili

1.20 (più recente)
1,19
1,18
1,17
1,16
1,15
1,14
1.13
1.12
1.12

Glossario

Questa pagina fornisce brevi definizioni e link a ulteriori informazioni dei termini utilizzati nella documentazione di Anthos Service Mesh.

A

Anthos Workload Identity: una tuple di trust domain, namespace e service account. Ha un formato di identità SPIFFE spiffe://<workload_identity_pool>/ns/<namespace>/sa/<serviceaccount> nei certificati x509 dei carichi di lavoro Anthos. Per altri tipi di credenziali (ad es. i token OIDC), il formato può variare.

C

upgrade canary

Consulta l'articolo sull'upgrade basato su revisione.

Servizio canonico

Etichetta applicata ai carichi di lavoro in Anthos Service Mesh che consente di raggruppare uno o più carichi di lavoro come servizio logico all'interno del mesh di servizi. Un carico di lavoro appartiene esattamente a un servizio canonico, mentre può appartenere a più servizi Kubernetes. Un servizio canonico è identificato da un nome e da uno spazio dei nomi e può essere ulteriormente suddiviso in una o più revisioni canoniche.

piano di controllo

Un piano di controllo è un insieme di servizi di sistema che configurano il mesh o un sottoinsieme del mesh per gestire la comunicazione tra le istanze dei carichi di lavoro all'interno. Anthos Service Mesh 1.9 e versioni successive forniscono due piani di controllo:

Piano di controllo gestito da Google: si tratta di un servizio Google Cloud completamente gestito che devi solo configurare, mentre Google ne gestisce affidabilità, upgrade, scalabilità e sicurezza al posto tuo. Anthos Service Mesh gestito è costituito dal piano di controllo gestito da Google e dal piano dati facoltativo gestito da Google, disponibile in Anteprima.
Piano di controllo nel cluster: è una distribuzione di istiod supportata da Google che viene installata sul cluster. Quando installi Anthos Service Mesh con istiod, sei responsabile dell'upgrade e della configurazione della sicurezza e della scalabilità.

Sebbene il piano di controllo distribuisca la propria configurazione ai proxy collaterali, non partecipa direttamente alla gestione del traffico per i carichi di lavoro nel mesh.

D

piano dati: Il piano dati è la parte del mesh che gestisce direttamente la comunicazione tra le istanze dei carichi di lavoro. Il piano dati di Anthos Service Mesh utilizza proxy distribuiti come file collaterali per mediare e controllare tutto il traffico TCP inviato e ricevuto dai tuoi servizi mesh. Anthos Service Mesh gestito offre un piano dati gestito da Google, disponibile in anteprima.

E

gateway in uscita: Un gateway in uscita è un proxy Envoy che consente di configurare un nodo di uscita dedicato per il traffico in uscita dal mesh. Puoi utilizzare la risorsa personalizzata Gateway per configurare il proxy. Un gateway in uscita consente di limitare i servizi che possono o devono accedere a reti esterne. Per ulteriori informazioni, consulta Installare ed eseguire l'upgrade dei gateway.

V

parco dispositivi, parco X (where X is the device type): Un parco risorse (precedentemente noto come environ) consente di organizzare i cluster per semplificare la gestione multi-cluster. La registrazione dei cluster in un parco risorse semplifica la gestione di un mesh multi-cluster introducendo il concetto di "uguaglianza" per identità, spazi dei nomi e servizi. Se hai cluster in progetti diversi, devi registrarli nel progetto host del parco risorse anziché con il progetto in cui è stato creato il cluster. Per scoprire di più sui parchi risorse, consulta Introduzione ai parchi risorse.

H

manifest idratati: Un manifest pronto per il deployment nella destinazione. Per idratare un manifest, in genere si utilizza uno strumento come Helm, Kustomize o kpt per impostare i valori per le variabili nel manifest.

I

identity

L'identità è un concetto fondamentale dell'infrastruttura di sicurezza. Il modello di identità Anthos Service Mesh si basa su un'identità dei carichi di lavoro all'avanguardia. All'inizio della comunicazione tra servizi, le due parti scambiano le credenziali con le proprie informazioni sull'identità per l'autenticazione reciproca.

I client verificano l'identità del server in base alle loro informazioni di denominazione sicura per determinare se il server è autorizzato a eseguire il servizio.

I server controllano l'identità del client per determinare a quali informazioni può accedere. I server decidono se consentire l'accesso in base ai criteri di autorizzazione configurati.

Utilizzando l'identità, i server possono controllare la data e l'ora di accesso alle informazioni a cui un client specifico ha eseguito l'accesso. Possono inoltre addebitare costi ai clienti in base ai servizi utilizzati e rifiutare gli eventuali client che non hanno pagato la fattura per l'accesso ai servizi.

Il modello di identità Anthos Service Mesh è abbastanza flessibile e granulare da rappresentare un utente umano, un singolo servizio o un gruppo di servizi. Sulle piattaforme senza identità di servizio di prima classe, Anthos Service Mesh può utilizzare altre identità che possono raggruppare le istanze di servizio, ad esempio i nomi di servizio.

Anthos Service Mesh supporta le seguenti identità di servizio su diverse piattaforme:

Kubernetes: account di servizio Kubernetes
Google Kubernetes Engine: account di servizio Google Cloud
Google Cloud: account di servizio Google Cloud

Gateway in entrata

Un gateway in entrata è un proxy Envoy che funge da bilanciatore del carico per gestire il traffico in entrata dall'esterno del mesh. Puoi utilizzare la risorsa personalizzata Gateway per configurare il bilanciatore del carico e creare servizi virtuali e criteri di autenticazione per controllare il modo in cui il traffico in entrata viene protetto e instradato ai tuoi carichi di lavoro. Per ulteriori informazioni, consulta Installare ed eseguire l'upgrade dei gateway.

iniezione

L'inserimento automatico, o inserimento automatico, fa riferimento all'uso di hook mutanti per modificare le specifiche del pod al momento della creazione. Puoi utilizzare l'inserimento per aggiungere la configurazione sidecar del proxy Envoy per i servizi mesh o per configurare il proxy dei gateway di Envoy.

upgrade in loco

Un upgrade in loco sostituisce il piano di controllo esistente con una nuova revisione. Come best practice, consigliamo gli upgrade basati su revisioni.

istiod

istiod ("d" sta per "daemon)" è il programma binario monolitico consolidato che fornisce servizi per il piano di controllo. Prima di Anthos Service Mesh 1.5, i servizi del piano di controllo erano forniti da componenti separati chiamati Pilota, Cittadella, Mixer e Galley.

IstioOperator

Una risorsa personalizzata che utilizzi per configurare il piano di controllo nel cluster. Per ulteriori informazioni, consulta Abilitazione delle funzionalità facoltative.

M

Gruppo di istanze gestite: Consente di eseguire applicazioni su più VM identiche, a partire da una dimensione minima del gruppo di istanze gestite di una VM. Puoi rendere i tuoi carichi di lavoro scalabili e ad alta disponibilità sfruttando i servizi di gruppo di istanze gestite automatici, tra cui: scalabilità automatica, riparazione automatica, deployment a livello di regione (più zone) e aggiornamento automatico. Per ulteriori informazioni, consulta Gruppi di istanze gestite.

Manifest

Un oggetto di configurazione Kubernetes utilizzato per creare, modificare ed eliminare risorse Kubernetes come pod, deployment, servizi o entrate. Nella documentazione di Anthos Service Mesh, il manifest utilizzato per configurare il piano di controllo è definito file di overlay.

I manifest esistono in uno dei due seguenti stati: renderizzati (indicati anche come idratati) o non visualizzati. Un manifest non sottoposto a rendering non è pronto per il deployment in una destinazione. Il processo di rendering, che include l'inserimento di valori specifici nel file manifest, viene spesso eseguito da strumenti come Helm, Kustomize e kpt.

Mesh CA: Il nome dell'autorità di certificazione gestita da Google che gestisce i certificati mTLS. Mesh CA è abilitato per impostazione predefinita quando installi Anthos Service Mesh su cluster GKE su Google Cloud. Facoltativamente, puoi attivare Mesh CA quando installi Anthos Service Mesh 1.10 o versioni successive su GKE su VMware o Bare Metal.
TLS reciproco: Anthos Service Mesh utilizza il protocollo TLS (mTLS) reciprocamente (TLS) per l'autenticazione e la crittografia tra i servizi nel mesh. mTLS consente ai carichi di lavoro di verificare le reciproche identità e di autenticarsi tra loro. Potresti già conoscere TLS semplice, in quanto utilizza HTTPS per consentire ai browser di considerare attendibili i server web e criptare i dati scambiati. Quando si utilizza il protocollo TLS semplice, il client stabilisce che il server è attendibile convalidandone il certificato. mTLS è un'implementazione di TLS in cui client e server presentano certificati reciprocamente e si verificano le rispettive identità.

N

rete: Anthos Service Mesh utilizza una definizione semplificata di rete basata sulla connettività generale. Le istanze del carico di lavoro si trovano sulla stessa rete se sono in grado di comunicare direttamente, senza un gateway.

O

file overlay: Un file YAML contenente una risorsa personalizzata (RP) di IstioOperator. Puoi utilizzare i file di overlay per configurare il piano di controllo. Puoi eseguire l'override della configurazione predefinita del piano di controllo e abilitare le funzionalità facoltative supportate in un file YAML che passi a istioctl install o allo script install_asm. Puoi aggiungere più overlay: ogni file di overlay sostituisce la configurazione dei livelli precedenti. Consulta Abilitazione delle funzionalità facoltative per il codice YAML che puoi usare per abilitare le funzionalità che non sono abilitate per impostazione predefinita.

P

cluster primario: Un cluster primario è un cluster con un piano di controllo. Un singolo mesh può avere più di un cluster primario per l'alta disponibilità o per ridurre la latenza. Nella documentazione di Inspire 1.7, un deployment multi-primary è indicato come piano di controllo replicato.

R

cluster remoto: Un cluster remoto è un cluster che si connette a un piano di controllo che risiede al di fuori del cluster. Un cluster remoto può connettersi a un piano di controllo in esecuzione in un cluster principale o a un piano di controllo esterno.
revisione: Una revisione rappresenta uno snapshot in tempo della versione e della configurazione del codice dell'applicazione. Quando installi o esegui l'upgrade di Anthos Service Mesh, viene aggiunta un'etichetta di revisione al piano di controllo. Per abilitare l'inserimento automatico di file collaterali, aggiungi l'etichetta di revisione agli spazi dei nomi e riavvii i pod. L'etichetta di revisione associa i pod in uno spazio dei nomi a una particolare revisione del piano di controllo.
upgrade basato su revisione: Le migrazioni da OSS Istio e gli upgrade seguono il processo di upgrade basato sulle revisioni (indicati come "upgrade canary" nella documentazione di Istio). Con un upgrade basato su revisione, la nuova revisione del piano di controllo viene installata insieme al piano di controllo esistente. Puoi quindi spostare alcuni dei tuoi carichi di lavoro nella nuova revisione, che ti consente di monitorare l'effetto dell'upgrade con una piccola percentuale dei carichi di lavoro prima di eseguire la migrazione di tutto il traffico alla nuova revisione.

S

denominazione sicura: Le identità server sono codificate nei certificati, ma i nomi dei servizi vengono recuperati tramite il servizio di rilevamento o DNS. Le informazioni sulla denominazione sicura associano le identità server ai nomi dei servizi. Una mappatura dell'identità A al nome del servizio B significa che "A è autorizzato a eseguire il servizio B". Il piano di controllo controlla apiserver, genera mappature di denominazione sicure e le distribuisce in modo sicuro ai proxy sidecar.
mesh di servizi: Un mesh di servizi, o semplicemente, un mesh di servizi è un livello di infrastruttura che consente comunicazioni gestite, osservabili e sicure tra le istanze dei carichi di lavoro.
file collaterale: Un pattern per eseguire un'utilità o un helper insieme a un carico di lavoro. Se utilizzi Kubernetes, i file collaterali vengono eseguiti insieme al container workload in un pod. Quando si parla di mesh di servizi, spesso il termine "sidecar" si riferisce al proxy.

T

dominio di attendibilità

Il dominio di attendibilità corrisponde alla radice di attendibilità di un sistema e fa parte di un'identità del carico di lavoro.

Anthos Service Mesh utilizza un dominio di attendibilità per creare tutte le identità all'interno di un mesh. Ad esempio, in ID SPIFFE spiffe://mytrustdomain.com/ns/default/sa/myname, la sottostringa mytrustdomain.com specifica che il carico di lavoro proviene da un dominio di attendibilità chiamato mytrustdomain.com.

Quando utilizzi Mesh CA, il dominio di attendibilità viene generato automaticamente da Anthos Service Mesh. Si basa sul pool di carico di lavoro del cluster.

Puoi avere uno o più domini di attendibilità in una mesh multi-cluster, a patto che i cluster condividano la stessa radice di attendibilità.

W

workload: Un carico di lavoro è un'applicazione, un servizio o un altro programma containerizzato, come un job batch o un daemon in esecuzione su una piattaforma. La piattaforma può essere un cluster Kubernetes, una macchina virtuale o un altro ambiente come Google Distributed Cloud Virtual for Bare Metal. I carichi di lavoro hanno nomi, spazi dei nomi e ID univoci. Su Kubernetes, un carico di lavoro corrisponde in genere a un deployment, ma esistono altri tipi di carichi di lavoro, ad esempio uno StatefulSet.
WorkloadEntry: ti consente di descrivere endpoint non Kubernetes pod che dovrebbero far parte del mesh e di trattarli come un pod Kubernetes. Nel nostro caso, ogni VM è registrata come WorkloadEntry nel mesh. Per ulteriori informazioni, visita la pagina https://istio.io/latest/blog/2020/workload-entry/
WorkloadGroup: descrive una raccolta di istanze di carichi di lavoro. Vedi WorkloadGroup.
Pool Workload Identity: Il confine di attendibilità, anche noto come dominio di attendibilità di Anthos Service Mesh.