Anthos Service Mesh 1.8 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 (ultima versione)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Glossario

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

C

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 (anteprima): questo è un servizio Google Cloud completamente gestito che devi solo configurare, mentre Google ne gestisce affidabilità, upgrade, scalabilità e sicurezza al posto tuo.
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.

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.

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

istiod

Istiod è il programma binario monolitico consolidato che fornisce i servizi del piano di controllo. Prima di Anthos Service Mesh 1.5, i servizi del piano di controllo erano forniti da componenti separati chiamati Pilota, Citadel, Mixer e Galley.

IstioOperator

Una risorsa personalizzata che utilizzi per configurare il piano di controllo. Per ulteriori informazioni, consulta IstioOperator nella documentazione di Istio.

M

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.

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 a istiod per identificare la versione. Per abilitare l'inserimento automatico di file collaterali, aggiungi l'etichetta di revisione agli spazi dei nomi e riavvii i pod. Puoi utilizzare l'etichetta di revisione per associare i pod in uno spazio dei nomi a una determinata revisione istiod, in modo da poter eseguire in sicurezza l'upgrade a un nuovo piano di controllo e il rollback alla revisione originale in caso di problemi.

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, nel formato project-id.svc.id.goog o project-id.hub.id.goog.

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.