Questa guida spiega come installare o migrare ad Anthos Service Mesh versione 1.6.14 per un mesh contenente uno o più cluster GKE che si trovano nello stesso progetto. Utilizzerai uno script fornito da Google, che configura il progetto e il cluster, quindi installa Anthos Service Mesh.
Puoi utilizzare questa guida per i seguenti casi d'uso:
Nuove installazioni di Anthos Service Mesh. Se hai installato una versione precedente di Anthos Service Mesh, consulta Upgrade di Anthos Service Mesh su GKE. Lo script 1.6 non gestisce gli upgrade.
Migrazione da Istio 1.6 open source ad Anthos Service Mesh. La migrazione da una versione precedente di Istio non è supportata. La versione 1.7 dello script supporta la migrazione da Istio 1.6 o 1.7 ad Anthos Service Mesh 1.7. Poiché stai eseguendo la migrazione, potresti preferire la migrazione ad Anthos Service Mesh 1.7.
Migrazione dalla versione 1.6 del componente aggiuntivo Istio su GKE ad Anthos Service Mesh. Prima di poter eseguire la migrazione ad Anthos Service Mesh, devi eseguire l'upgrade a Istio 1.6 con Operator. Per la procedura di migrazione completa dal componente aggiuntivo, consulta Migrazione ad Anthos Service Mesh nella documentazione di Istio su GKE.
Devi utilizzare la guida Installazione e migrazione avanzate su GKE per i seguenti casi d'uso:
Quando devi personalizzare l'installazione per eseguire l'override delle impostazioni nel profilo
asm-gcp
e hai più di un file YAMLIstioOperator
overlay. Lo script consente di specificare un solo file YAMl.Per un mesh multi-cluster in cui i cluster si trovano in progetti diversi.
Prima di iniziare
Questa guida presuppone che tu abbia già:
- Un progetto Google Cloud.
- Un account di fatturazione Cloud.
- Un cluster GKE che soddisfa i requisiti.
Se esegui la migrazione da Istio, assicurati di consultare la sezione Preparazione per la migrazione da Istio.
Differenze tra Anthos e Anthos Service Mesh
Abbonati a GKE Enterprise, assicurati di abilitare l'API GKE Enterprise.
Se non hai un abbonamento a GKE Enterprise, puoi comunque installare Anthos Service Mesh, ma alcuni elementi dell'interfaccia utente e funzionalità della console Google Cloud sono disponibili solo per gli abbonati a GKE Enterprise. Per informazioni su cosa è disponibile per gli abbonati e i non abbonati, consulta le 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
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 tuo cluster non ha almeno quattro vCPU, modifica il tipo di macchina come descritto in Migrazione dei carichi di lavoro a tipi di macchina diversi.Il numero minimo di nodi dipende dal tipo di macchina. Anthos Service Mesh richiede almeno otto vCPU. Se il tipo di macchina ha quattro vCPU, il cluster deve avere almeno due nodi. Se il tipo di macchina ha 8 vCPU, il cluster ha bisogno di un solo nodo. Se devi aggiungere nodi, consulta Ridimensionamento di un cluster.
Lo script abilita Workload Identity sul tuo cluster. 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.
(Facoltativo 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.6.14. Per ulteriori informazioni, consulta la sezione Ambienti supportati. Segui le istruzioni in Registrazione di un cluster esistente in un canale di rilascio se hai una versione di GKE statica.
Per essere incluse nel mesh di servizi, è necessario assegnare un nome alle porte di servizio e il nome deve includere il protocollo della porta con la seguente sintassi:
name: protocol[-suffix]
dove le parentesi quadre indicano un suffisso facoltativo che deve iniziare con un trattino. Per ulteriori informazioni, consulta Denominazione delle porte dei servizi.Se stai installando Anthos Service Mesh su un cluster privato, devi aprire la porta 15017 nel firewall affinché il webhook utilizzato con l'inserimento collaterale automatico funzioni correttamente. Per maggiori informazioni, consulta Apertura di una porta su un cluster privato.
Se hai creato un perimetro di servizio nella tua organizzazione, potrebbe essere necessario aggiungere il servizio Mesh CA al perimetro. Per ulteriori informazioni, consulta Aggiunta di mesh CA a un perimetro di servizio.
Per le migrazioni,
istiod
deve essere installato nello spazio dei nomiistio-system
, che in genere è il caso.
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 l'emissione di certificati
mTLS (mutual TLS).
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 usare 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 stai eseguendo la migrazione da Istio o dal componente aggiuntivo Istio su GKE.
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é il traffico mTLS non riesce fino al riavvio di tutti i pod in tutti gli spazi dei nomi.
I certificati di CA mesh includono i seguenti dati sui servizi dell'applicazione:
- L'ID progetto Google Cloud
- Lo spazio dei nomi GKE
- Il nome dell'account di servizio GKE
Installazione degli strumenti richiesti
Puoi eseguire lo script su Cloud Shell o sulla tua macchina locale che esegue Linux o macOS. Cloud Shell preinstalla tutti gli strumenti richiesti.
Per eseguire lo script localmente:
Assicurati di aver installato i seguenti strumenti:
- Google Cloud CLI
- Gli strumenti a riga di comando standard:
awk
,curl
,grep
,sed
,sha256sum
etr
- git
- KPT
- kubectl
- jq
Esegui l'autenticazione con gcloud CLI:
gcloud auth login
Aggiorna i componenti:
gcloud components update
Assicurati che
git
sia nel tuo percorso in modo chekpt
possa trovarlo.
Esecuzione dello script
Questa sezione descrive come scaricare lo script, impostare i parametri obbligatori e facoltativi e come eseguire lo script. Per una spiegazione dettagliata di ciò che fa lo script, consulta Comprensione dello script.
Scarica lo script nella directory di lavoro corrente:
curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.6 > install_asm
Scarica l'algoritmo SHA-256 del file nella directory di lavoro corrente:
curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.6.sha256 > install_asm.sha256
Poiché entrambi i file si trovano nella stessa directory, verifica il download:
sha256sum -c --ignore-missing install_asm.sha256
Se la verifica ha esito positivo, il comando restituisce:
install_asm: OK
Per la compatibilità, il file
install_asm.sha256
include il checksum due volte per consentire a qualsiasi versione dello script di essere rinominata ininstall_asm
. Se viene visualizzato un errore che indica che--ignore-missing
non esiste, esegui nuovamente il comando precedente senza il flag--ignore-missing
.Rendi eseguibile lo script:
chmod +x install_asm
Imposta le opzioni e specifica i flag per eseguire lo script. Includi sempre le seguenti opzioni:
project_id
,cluster_name
,cluster_location
emode
. A seconda delmode
, potrebbe essere necessario includere l'opzioneca
.- Le opzioni
project_id
,cluster_name
ecluster_location
identificano il cluster su cui installare Anthos Service Mesh. - Il valore
mode
èinstall
omigrate
. - Il parametro
ca
specifica l'autorità di certificazione comemesh_ca
ocitadel
.
La seguente sezione fornisce esempi tipici per l'esecuzione dello script. Per una descrizione completa degli argomenti dello script, consulta Opzioni e flag.
- Le opzioni
Per completare la configurazione di Anthos Service Mesh, devi abilitare l'inserimento automatico di file collaterali e eseguire il deployment o rieseguire il deployment dei carichi di lavoro.
Esempi
Questa sezione mostra esempi di esecuzione dello script in ogni mode
e alcuni argomenti aggiuntivi che potresti trovare utili. Guarda la barra di navigazione a destra
per un elenco di esempi.
Solo convalida
L'esempio seguente mostra l'esecuzione dello script con l'opzione --only_validate
. Con questa opzione, lo script non apporta modifiche al cluster e non installa Anthos Service Mesh. Lo script verifica che:
- Il tuo ambiente dispone degli strumenti necessari.
- Disponi dell'autorizzazione richiesta per il progetto specificato.
- Il cluster soddisfa i requisiti minimi.
- Nel progetto sono abilitate tutte le API di Google richieste.
Per impostazione predefinita, lo script scarica ed estrae il file di installazione e scarica il pacchetto di configurazione di asm
da GitHub a una directory temporanea. Prima di uscire, lo script genera un messaggio che fornisce il nome della directory temporanea.
Puoi specificare una directory esistente per i download con l'opzione --output_dir DIR_PATH
. L'opzione --output_dir
consente di utilizzare facilmente lo strumento a riga di comando istioctl
in caso di necessità.
Crea una directory denominata
asm-packages
:mkdir asm-packages
Esegui questo comando per convalidare la configurazione e scaricare il file di installazione e il pacchetto
asm
nella directoryasm-packages
:./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode install \ --output_dir ./asm-packages \ --only_validate
Se l'operazione riesce, lo script restituisce quanto segue:
./install_asm \ install_asm: Setting up necessary files... install_asm: Creating temp directory... install_asm: Generating a new kubeconfig... install_asm: Checking installation tool dependencies... install_asm: Downloading ASM.. % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 57.0M 100 57.0M 0 0 30.6M 0 0:00:01 0:00:01 --:--:-- 30.6M install_asm: Downloading ASM kpt package... fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm install_asm: Checking for project PROJECT_ID... install_asm: Confirming cluster information... install_asm: Confirming node pool requirements... install_asm: Fetching/writing GCP credentials to kubeconfig file... Fetching cluster endpoint and auth data. kubeconfig entry generated for cluster-1. install_asm: Checking Istio installations... install_asm: Checking required APIs... install_asm: Successfully validated all requirements to install ASM from this computer.
Se uno dei test non supera la convalida, lo script restituisce un messaggio di errore. Ad esempio, se nel progetto non sono abilitate tutte le API di Google richieste, viene visualizzato il seguente errore:
ERROR: One or more APIs are not enabled. Please enable them and retry, or re-run the script with the '--enable_apis' flag to allow the script to enable them on your behalf.
Nuova installazione
Il comando seguente esegue lo script per una nuova installazione, abilita
Mesh CA (la CA predefinita per le nuove installazioni, quindi in questo caso non è necessaria
l'opzione ca
) e consente allo script di abilitare le API di Google richieste.
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode install \ --enable_apis
Nuova installazione con un file di overlay
L'esempio seguente esegue una nuova installazione e include un file YAML che abilita una funzionalità facoltativa.
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode install \ --enable_apis \ --operator_overlay egressgateways.yaml
Migrazione da Istio
Se stai eseguendo la migrazione da Istio open source, stai utilizzando Citadel come CA. Il seguente comando esegue lo script per una migrazione ad Anthos Service Mesh e attiva Citadel come CA. Questa migrazione esegue il deployment solo del piano di controllo. Questo non modifica la CA radice e non interrompe i carichi di lavoro esistenti.
./install_asm \ -p PROJECT_ID \ -n CLUSTER_NAME \ -l CLUSTER_LOCATION \ -m migrate \ -c citadel \ --enable_apis
Opzioni e flag
Opzioni
-p|--project_id CLUSTER_PROJECT_ID
- L'ID progetto in cui è stato creato il cluster.
-n|--cluster_name CLUSTER_NAME
- Il nome del cluster.
-l|--cluster_location CLUSTER_LOCATION
- La zona (per i cluster a zona singola) o la regione (per i cluster a livello di regione) in cui è stato creato il cluster.
-m|--mode {install|migrate}
- Inserisci
install
se stai eseguendo una nuova installazione di Anthos Service Mesh. Inseriscimigrate
se stai eseguendo la migrazione da Istio o dal componente aggiuntivo Istio su GKE ad Anthos Service Mesh. -c|--ca {mesh_ca|citadel}
- Se stai eseguendo una nuova installazione, questo parametro per impostazione predefinita sarà
Mesh CA e non è necessario includerlo. Se esegui la migrazione da Istio, devi specificare
citadel
omesh_ca
. Se puoi pianificare il tempo di inattività per la migrazione, ti consigliamo di utilizzaremesh_ca
. Se non riesci a pianificare il tempo di riposo per la migrazione, utilizzacitadel
. -o|--operator_overlay YAML_FILE
- Il nome del file YAML per abilitare una funzionalità che non è abilitata nel profilo
asm-gcp
. Lo script deve essere in grado di individuare il file YAML. Quindi il file deve trovarsi nella stessa directory dello script oppure puoi specificare un percorso relativo come:../manifests/asm-features.yaml
-s|--service_account ACCOUNT
- Il nome di un account di servizio utilizzato per installare Anthos Service Mesh. Se non specificato, viene utilizzato l'account utente attivo nell'attuale configurazione di
gcloud
. Se devi modificare l'account utente attivo, esegui gcloud auth login. -k|--key_file FILE PATH
- Il file della chiave per un account di servizio. Ometti questa opzione se non utilizzi un account di servizio.
-D|--output_dir DIR_PATH
- Se non specificata, lo script crea una directory temporanea in cui scarica i file e le configurazioni necessari per l'installazione di Anthos Service Mesh.
Specifica il flag
--output-dir
per designare una directory esistente da utilizzare al suo posto. Al termine, la directory specificata contiene le sottodirectoryasm
eistio-1.6.14-asm.2
. La directoryasm
contiene la configurazione per l'installazione. La directoryistio-1.6.14-asm.2
contiene i contenuti estratti del file di installazione, che includonoistioctl
, esempi e manifest.
Flag
-e|--enable_apis
- Consenti allo script di attivare le API Google richieste da Anthos Service Mesh. Senza questo flag, lo script viene chiuso se le API richieste non sono già abilitate. Per un elenco delle API abilitate dallo script, consulta set_up_project.
-v|--verbose
- Stampa i comandi prima e dopo l'esecuzione.
--dry_run
- Stampare i comandi, ma non eseguirli.
--only_validate
- Esegui la convalida, ma non installare Anthos Service Mesh.
--disable_canonical_service
- Per impostazione predefinita, lo script esegue il deployment del controller del servizio canonico nel cluster. Se non vuoi che lo script esegua il deployment del controller, specifica
--disable_canonical_service
. Per maggiori informazioni, consulta Attivare e disattivare il controller di servizio canonico. -h|--help
- Mostra un messaggio della guida che descrive le opzioni e i flag e l'uscita.
Deployment e nuovo deployment dei carichi di lavoro
L'installazione non è completa finché non abiliti l'inserimento automatico del proxy sidecar (inserimento automatico).
Per le nuove installazioni, devi abilitare l'inserimento automatico e riavviare i pod per tutti i carichi di lavoro in esecuzione sul cluster prima dell'installazione di Anthos Service Mesh.
Le migrazioni da Istio seguono il processo di upgrade del piano di controllo doppio (definito "upgrade canary" nella documentazione di Istio). Con un upgrade del piano di controllo doppio, lo script installa una nuova versione di
istiod
oltre all'attualeistiod
. quindi trasferirai alcuni carichi di lavoro alla nuova versione. Questo processo consente di monitorare l'effetto della nuova versione con una piccola percentuale dei carichi di lavoro prima di eseguire la migrazione di tutto il traffico alla nuova versione.Prima di eseguire il deployment di nuovi carichi di lavoro, assicurati di abilitare l'inserimento automatico per consentire ad Anthos Service Mesh di monitorare e proteggere il traffico.
Per abilitare l'inserimento automatico, ricevi l'etichetta di revisione applicata dallo script a istiod
ed etichetta gli spazi dei nomi con l'etichetta di revisione. Le seguenti
sezioni forniscono i dettagli.
Recupera l'etichetta della revisione
Lo script aggiunge un'etichetta di revisione nel formato istio.io/rev=asm-1614-2
a istiod
. Per abilitare l'inserimento automatico, aggiungi un'etichetta di revisione corrispondente agli spazi dei nomi. L'etichetta della revisione viene utilizzata dal webhook dell'iniettore collaterale per associare i file collaterali inseriti a una determinata revisione istiod
. Dopo aver aggiunto l'etichetta, tutti i pod esistenti nello spazio dei nomi devono essere riavviati per poter inserire i file collaterali.
Imposta il contesto corrente per
kubectl
:gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID
Visualizza le etichette su
istiod
per ottenere l'etichetta di revisione impostata dallo script:kubectl -n istio-system get pods -l app=istiod --show-labels
L'output del comando è simile al seguente.
NAME READY STATUS RESTARTS AGE LABELS istiod-7744bc8dd7-qhlss 1/1 Running 0 49m app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7 istiod-asm-1614-2-85d86774f7-flrt2 1/1 Running 0 26m app=istiod,istio.io/rev=asm-1614-2,istio=istiod,pod-template-hash=85d86774f7 istiod-asm-1614-2-85d86774f7-tcwtn 1/1 Running 0 26m app=istiod,istio.io/rev=asm-1614-2,istio=istiod,pod-template-hash=85d86774f7
Nell'output, nella colonna
LABELS
, prendi nota del valore dell'etichetta di revisioneistiod
, che segue il prefissoistio.io/rev=
. In questo esempio il valore è asm-1614-2, ma potresti avere un valore diverso.Per le migrazioni, tieni presente anche il valore nell'etichetta di revisione per la versione precedente di
istiod
. È necessario per eliminare la versione precedente diistiod
al termine della migrazione. Nell'output di esempio, il valore nell'etichetta della revisione per la versione precedente diistiod
èdefault
, ma potresti avere un valore diverso.
Abilitazione dell'inserimento automatico in corso...
Segui questi passaggi per le nuove installazioni e migrazioni per abilitare l'inserimento automatico.
Recupera il valore nell'etichetta di revisione per
istiod
.Aggiungi l'etichetta di revisione a uno spazio dei nomi e rimuovi l'etichetta
istio-injection
. Nel comando seguente, modificaREVISION
impostandolo sul valore corrispondente alla revisione del giornoistiod
.kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
Riavvia i pod per attivare la reiniezione.
kubectl rollout restart deployment -n NAMESPACE
Verifica che i pod siano configurati in modo da puntare alla nuova versione di
istiod
.kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.
Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavviare i pod.
Per la migrazione:
Se sei soddisfatto del funzionamento previsto dell'applicazione, continua con la sezione successiva per completare la transizione alla nuova versione di
istiod
.Se si verifica un problema con la tua applicazione, segui la procedura per il rollback alla versione precedente.
Completa la transizione
Per le migrazioni, devi rimuovere la versione precedente di istiod
. Se l'applicazione funziona come previsto, rimuovi il piano di controllo precedente per completare la transizione alla nuova versione.
Recupera il valore nell'etichetta di revisione per la versione precedente di
istiod
.Elimina la versione precedente di
istiod
. Nel comando seguente, sostituisciOLD_REVISION
con la revisione del passaggio precedente.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
Esegui il rollback alla versione precedente
Per le migrazioni, se hai riscontrato un problema durante il test dell'applicazione con la nuova versione di istiod
, segui questi passaggi per tornare alla versione precedente:
Aggiorna i carichi di lavoro da inserire con la versione precedente di
istiod
:kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
Riavvia i pod per attivare la reiniezione in modo che i proxy abbiano la versione precedente:
kubectl rollout restart deployment -n NAMESPACE
Esegui di nuovo il deployment della versione precedente di
istio-ingressgateway
:kubectl -n istio-system rollout undo deploy istio-ingressgateway
Rimuovi il nuovo
istiod
:kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
Se non hai incluso il flag
--disable_canonical_service
, lo script abilitava il controller del servizio canonico. Segui i passaggi descritti in Attivazione e disattivazione del controller di servizio canonico per disabilitarlo.
Visualizzazione delle dashboard di Anthos Service Mesh
Questa sezione è applicabile solo se hai installato Anthos Service Mesh con il profilo di configurazione asm-gcp
. Se hai utilizzato il profilo asm-gcp-multiproject
per installare Anthos Service Mesh, i dati di telemetria non saranno disponibili nelle dashboard di Anthos Service Mesh nella console Google Cloud.
Dopo aver eseguito il deployment dei carichi di lavoro nel cluster con i proxy collaterali inseriti, puoi esplorare le pagine Anthos Service Mesh nella console Google Cloud per vedere tutte le funzionalità di osservabilità offerte da Anthos Service Mesh. Tieni presente che dopo il deployment dei carichi di lavoro sono necessari circa uno o due minuti per la visualizzazione dei dati di telemetria nella console Google Cloud.
L'accesso ad Anthos Service Mesh nella console Google Cloud è controllato da Identity and Access Management (IAM). Per accedere alle pagine Anthos Service Mesh, un Proprietario progetto deve concedere agli utenti il ruolo Visualizzatore o Visualizzatore progetto oppure i ruoli più restrittivi descritti in Controllare l'accesso ad Anthos Service Mesh nella console Google Cloud.
Nella console Google Cloud, vai ad Anthos Service Mesh.
Seleziona il progetto Google Cloud dall'elenco a discesa nella barra dei menu.
Se hai più di un mesh di servizi, selezionalo dall'elenco a discesa Mesh di servizi.
Per saperne di più, consulta Esplorazione di Anthos Service Mesh nella console Google Cloud.
Oltre alle pagine Anthos Service Mesh, le metriche relative ai tuoi servizi (come il numero di richieste ricevute da un determinato servizio) vengono inviate a Cloud Monitoring, dove vengono visualizzate in Metrics Explorer.
Per visualizzare le metriche:
Nella console Google Cloud, vai alla pagina Monitoring:
Seleziona Risorse > Metrics Explorer.
Per un elenco completo delle metriche, consulta Metriche IoT nella documentazione di Cloud Monitoring.
Registrazione del cluster
Devi registrare il tuo cluster con il parco risorse del progetto per ottenere l'accesso all'interfaccia utente unificata nella console Google Cloud. Un parco risorse fornisce un modo unificato per visualizzare e gestire i cluster e i relativi carichi di lavoro, inclusi i cluster esterni a Google Cloud.
Consulta Registrazione dei cluster nel parco risorse per informazioni sulla registrazione del cluster.
Comprensione dello script
Anche se scarichi lo script da una posizione sicura di Cloud Source Repositories, lo script è disponibile anche su GitHub in modo che tu possa vedere cosa fa prima di scaricarlo. Lo script verifica che il cluster soddisfi i requisiti e automatizza tutti i passaggi che eseguiresti manualmente in Installazione di Anthos Service Mesh su GKE.
validate_args
e validate_dependencies
Le funzioni validate_args
e validate_dependencies
:
- Verifica che tutti gli strumenti necessari siano installati.
- Verifica che l'ID progetto, il nome e la località del cluster che hai inserito come valori dei parametri siano validi.
- Garantisce che il cluster soddisfi il tipo di macchina minimo richiesto e il numero di nodi.
set_up_project
Se hai incluso il flag --enable_apis
, la funzione set_up_project
abilita le API richieste:
set_up_cluster
La funzione set_up_cluster
esegue i seguenti aggiornamenti al cluster:
Abilita Workload Identity, che rappresenta il metodo consigliato per accedere in sicurezza ai servizi Google Cloud dalle applicazioni GKE.
Imposta sul cluster l'etichetta
mesh_id
, necessaria per visualizzare le metriche nelle pagine Anthos Service Mesh nella console Google Cloud.Imposta un'etichetta come
asmv=asm-1614-2
, in modo che tu possa capire che il cluster è stato modificato dallo script.Associa l'account utente o di servizio della piattaforma Google Cloud che esegue lo script al ruolo cluster-admin sul tuo cluster.
install_asm
La funzione install_asm
:
- Scarica il pacchetto
kpt
in una directory temporanea. - Esegue i setter
kpt
per configurare il fileistio-operator.yaml
. - Installa Anthos Service Mesh.
Differenze con lo script 1.7
Script 1.7 | Script 1.6 |
---|---|
Supporta gli upgrade. | Non esegue upgrade. |
Supporta le migrazioni da Istio 1.6 e Istio 1.7. | Supporta la migrazione da Istio 1.6. |
--print_config Fornisce la configurazione che hai utilizzato al momento dell'installazione mediante lo script install_asm . Questo flag ti consente di
reinstallare più facilmente la stessa versione di Anthos Service Mesh (non consentita dallo script) con la stessa configurazione che hai utilizzato durante l'installazione precedente. |
Non disponibile |
--custom_overlay Consente più file overlay. |
--custom_overlay Consente un solo file di overlay. |
--option Estrae file di overlay dal pacchetto asm su GitHub.
|
Non disponibile. |
Supporta una CA personalizzata con le seguenti opzioni:
|
Non disponibile. |