Questa guida spiega come installare o eseguire la migrazione ad Anthos Service Mesh da Istio open source per un mesh contenente più cluster GKE in progetti Google Cloud diversi. Per installazioni, migrazioni o upgrade per uno o più cluster GKE nello stesso progetto Google Cloud, consulta Installazione, migrazione e upgrade per GKE.
Puoi utilizzare questa guida per i seguenti casi d'uso:
Nuove installazioni di Anthos Service Mesh 1.7.8.
Migrazione da Istio 1.6 o 1.7 open source ad Anthos Service Mesh 1.7.8. Se hai una versione precedente di Istio, devi eseguire l'upgrade prima di eseguire la migrazione ad Anthos Service Mesh.
La configurazione di cluster in progetti Google Cloud diversi richiede il profilo asm-gcp-multiproject (beta). Con questo profilo:
Le dashboard di Anthos Service Mesh nella console Google Cloud al momento non sono disponibili. Tuttavia, puoi comunque visualizzare i log in Cloud Logging e le metriche in Cloud Monitoring per ciascun progetto.
Le altre funzionalità predefinite supportate elencate nella pagina Funzionalità supportate per il profilo di configurazione
asm-gcp-multiprojectsono abilitate.
Prima di iniziare
Questa guida presuppone che tu abbia già:
- Un progetto Google Cloud.
- Un account di fatturazione Cloud.
- Un cluster GKE che soddisfi i requisiti.
Se stai eseguendo la migrazione da Istio, consulta la pagina Preparazione per la migrazione da Istio.
Differenze tra Anthos e Anthos Service Mesh
Gli abbonati a GKE Enterprise devono abilitare l'API GKE Enterprise.
Se non sei un abbonato a GKE Enterprise, puoi comunque installare Anthos Service Mesh, ma alcuni elementi e funzionalità dell'interfaccia utente nella console Google Cloud sono disponibili solo per gli abbonati a GKE Enterprise. Per informazioni su ciò che è disponibile per gli abbonati e i non abbonati, consulta Differenze nell'interfaccia utente di GKE Enterprise e Anthos Service Mesh. Per informazioni sui prezzi di Anthos Service Mesh per i non abbonati, consulta i prezzi.
Requisiti
Poiché i cluster si trovano in progetti diversi, devono trovarsi in un VPC (Virtual Private Cloud) condiviso. Per informazioni sulla configurazione dei cluster, consulta Configurazione dei cluster con un VPC condiviso.
Il cluster GKE deve soddisfare i seguenti requisiti:
Un tipo di macchina con almeno quattro vCPU, ad esempio
e2-standard-4. Se il tipo di macchina per il cluster non ha almeno quattro vCPU, cambia il tipo di macchina come descritto in Migrazione di carichi di lavoro in tipi di macchine diversi.Il numero minimo di nodi dipende dal tipo di macchina. Anthos Service Mesh richiede almeno 8 vCPU. Se il tipo di macchina ha 4 vCPU, il cluster deve avere almeno due nodi. Se il tipo di macchina ha otto vCPU, il cluster ha bisogno di un solo nodo. Se devi aggiungere nodi, consulta Ridimensionamento di un cluster.
Per preparare il cluster prima di installare Anthos Service Mesh, devi abilitare Workload Identity. Workload Identity è il metodo consigliato per chiamare le API di Google. L'abilitazione di Workload Identity cambia il modo in cui vengono protette le chiamate dai carichi di lavoro alle API di Google, come descritto in Limitazioni di Workload Identity.
Facoltativamente, ma consigliato, registra il cluster in un canale di rilascio. Ti consigliamo di registrarti al canale di rilascio regolare perché altri canali potrebbero essere basati su una versione di GKE non supportata con Anthos Service Mesh 1.7.8. Per ulteriori informazioni, consulta la sezione Ambienti supportati. Segui le istruzioni riportate in Registrare un cluster esistente in un canale di rilascio se hai una versione GKE statica.
Per essere incluse nel mesh di servizi, è necessario assegnare un nome alle porte di servizio, che deve includere il protocollo della porta nella seguente sintassi:
name: protocol[-suffix]dove le parentesi quadre indicano un suffisso facoltativo che deve iniziare con un trattino. Per maggiori informazioni, consulta Denominazione delle porte dei servizi.Se stai installando Anthos Service Mesh su un cluster privato, devi aprire la porta 15017 nel firewall per far funzionare correttamente il webhook utilizzato con l'inserimento automatico di sidecar. Per maggiori informazioni, consulta Apertura di una porta su un cluster privato.
Se hai creato un perimetro di servizio nell'organizzazione, potrebbe essere necessario aggiungere il servizio Mesh CA al perimetro. Per ulteriori informazioni, consulta Aggiunta di Mesh CA a un perimetro di servizio.
Limitazioni
A un progetto Google Cloud è possibile associare un solo mesh.
Scelta di un'autorità di certificazione
Sia per le nuove installazioni che per le migrazioni, puoi utilizzare
l'autorità di certificazione Anthos Service Mesh (Mesh CA) o
Citadel
(ora incorporata in istiod) come autorità di certificazione (CA) per emettere certificati
TLS reciproca (mTLS).
In genere consigliamo di utilizzare Mesh CA per i seguenti motivi:
- Mesh CA è un servizio altamente affidabile e scalabile, ottimizzato per carichi di lavoro con scalabilità dinamica su Google Cloud.
- Con Mesh CA, Google gestisce la sicurezza e la disponibilità del backend della CA.
- Mesh CA consente di fare affidamento su un'unica radice di attendibilità tra i cluster.
Tuttavia, in alcuni casi potresti prendere in considerazione l'utilizzo di Citadel, ad esempio:
- Se hai una CA personalizzata,
Se esegui la migrazione da Istio.
Se scegli Citadel, non ci sono tempi di inattività perché il traffico mTLS non viene interrotto durante la migrazione. Se scegli Mesh CA, devi pianificare il tempo di inattività per la migrazione perché la radice di attendibilità cambia da Citadel a Mesh CA. Per completare la migrazione alla radice di attendibilità della CA mesh, è necessario riavviare tutti i pod in tutti gli spazi dei nomi. Durante questo processo, i pod precedenti non possono stabilire connessioni mTLS con i nuovi pod.
I certificati di Mesh CA includono i seguenti dati sui servizi dell'applicazione:
- ID progetto Google Cloud
- Lo spazio dei nomi GKE
- Il nome dell'account di servizio GKE
Supporto multi-cluster
Sebbene non sia attualmente obbligatorio, ti consigliamo di registrare il cluster nel parco risorse del progetto (precedentemente noto come environ). che consente di organizzare i cluster per semplificare la gestione multi-cluster. Registrando i cluster in un parco risorse, puoi raggruppare servizi e altre infrastrutture in base alle esigenze per applicare criteri coerenti. 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 ulteriori informazioni, consulta Registrazione dei cluster nel parco risorse.
Il concetto di progetto host del parco risorse è importante quando configuri il cluster per abilitare le opzioni richieste da Anthos Service Mesh. Il mesh di servizi per il tuo cluster è identificato con un valore basato su un numero di progetto. Quando configuri cluster da progetti diversi, devi utilizzare il numero di progetto per il progetto host del parco risorse.