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.

I

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.

M

TLS reciproco: Anthos Service Mesh utilizza il protocollo TLS (mTLS) reciprocamente per l'autenticazione e la crittografia dei peer. mTLS consente ai carichi di lavoro di verificare le reciproche identità e di autenticarsi tra loro.

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.

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

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.

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.