Questa pagina è stata tradotta dall'API Cloud Translation.

Eseguire l'upgrade di Apigee hybrid alla versione 1.8

<0x

Utilizza le stesse procedure per gli upgrade delle versioni secondarie (ad esempio dalla versione 1.7 alla 1.8) e per gli upgrade delle release delle patch (ad esempio dalla versione 1.8.0 alla 1.8.8).

Se esegui l'upgrade da Apigee hybrid versione 1.6 o precedente, devi prima eseguire l'upgrade alla versione 1.7 prima di eseguire l'upgrade alla versione 1.8.8. Consulta le istruzioni per eseguire l'upgrade di Apigee Hybrid alla versione 1.7.

Se utilizzi già la versione ibrida 1.8.0 e vuoi eseguire la migrazione al gateway in entrata Apigee da Anthos Service Mesh, consulta Eseguire la migrazione al gateway in entrata Apigee.

Introduzione al gateway in entrata Apigee

A partire dalla versione 1.8, Apigee hybrid offre una nuova funzionalità per gestire il gateway in entrata per l'installazione ibrida, Apigee ingress gateway. Anthos Service Mesh non è più un prerequisito per l'installazione ibrida. Con il gateway in entrata Apigee, Apigee smetterà di fornire la configurazione di routing ad Anthos Service Mesh. Dopo l'upgrade, devi eseguire la migrazione del traffico al nuovo gateway in entrata Apigee prima di poter iniziare a utilizzare la funzionalità.

Apigee utilizza un piccolo sottoinsieme delle funzionalità di Anthos Service Mesh per il gateway in entrata. A partire dalla versione ibrida 1.8, Apigee hybrid include un gateway in entrata che viene installato e aggiornato nell'ambito degli upgrade di Apigee hybrid. Pertanto, non devi acquisire competenze su Anthos Service Mesh per installare, eseguire l'upgrade e gestire Apigee hybrid. I problemi relativi alle versioni del gateway in entrata e alla compatibilità con le release di Apigee Hybrid vengono gestiti automaticamente.

Due scenari per la migrazione sono:

Migrazione multi-cluster o multiregionale (consigliata):
Prima di passare a un nuovo Ingress per Apigee, reindirizza tutto il traffico a un altro cluster o regione dal cluster di cui stai eseguendo la migrazione. In questo modo, avrai il tempo di verificare se il nuovo gateway in entrata Apigee funziona come previsto. Poi sposta di nuovo il traffico sul cluster di cui è stato eseguito l'upgrade.
Upgrade sul posto (non consigliato negli ambienti di produzione):
Durante l'upgrade, Apigee visualizzerà il nuovo gateway in entrata con un indirizzo IP specificato. A questo punto puoi verificare se il nuovo gateway in entrata Apigee funziona come previsto e poi spostare il traffico sul nuovo ingresso. Durante questo upgrade potrebbe verificarsi un tempo di inattività.

Quando esegui l'upgrade di Apigee hybrid alla versione 1.8, devi configurare il gateway in entrata Apigee nel file di override. Dopo l'upgrade, controlli il tipo di gateway in entrata che i tuoi cluster utilizzeranno indirizzando i record A o CNAME al tuo registrar all'indirizzo IP per il gateway in entrata Apigee o per Anthos Service Mesh.

Panoramica dell'upgrade alla versione 1.8.8

L'upgrade alla versione 1.8 di Apigee hybrid potrebbe richiedere tempi di inattività.

Quando esegui l'upgrade del controller Apigee alla versione 1.8.8, tutti i deployment Apigee vengono riavviati in sequenza. Per ridurre al minimo i tempi di inattività negli ambienti ibridi di produzione durante un riavvio graduale, assicurati di eseguire almeno due cluster (nello stesso o in un data center/regione diverso). Devia tutto il traffico di produzione a un singolo cluster e metti offline il cluster che stai per eseguire l'upgrade, quindi procedi con il processo di upgrade. Ripeti la procedura per ogni cluster.

Apigee consiglia di eseguire l'upgrade di tutti i cluster il prima possibile per ridurre le possibilità di impatto sulla produzione. Non esiste un limite di tempo per l'upgrade di tutti i cluster rimanenti dopo l'upgrade del primo. Tuttavia, fino a quando non verrà eseguito l'upgrade di tutti i cluster rimanenti, le seguenti operazioni saranno interessate:

Il backup e il ripristino di Cassandra non possono funzionare con versioni miste. Ad esempio, un backup di Hybrid 1.7 non può essere utilizzato per ripristinare un'istanza Hybrid 1.8.
Lo streaming dei dati di Cassandra non funzionerà tra versioni ibride miste. Pertanto, i tuoi cluster Cassandra non possono essere scalati orizzontalmente.
L'espansione e il ritiro delle regioni saranno interessati, perché queste operazioni dipendono dallo streaming di dati Cassandra.

Le procedure per l'upgrade di Apigee hybrid sono organizzate nelle seguenti sezioni:

Preparati all'upgrade.
Installa la versione 1.8.8 del runtime di hybrid.
Per il gateway in entrata, scegli una delle seguenti opzioni:
- (Consigliato) Utilizza il nuovo gateway di ingresso Apigee, segui i passaggi descritti in Sposta il traffico da Anthos Service Mesh al gateway di ingresso Apigee.
- Continua a utilizzare Anthos Service Mesh per il gateway in entrata.

Prerequisito

Queste istruzioni per l'upgrade presuppongono che tu abbia installato Apigee hybrid versione 1.7.x o una patch release precedente della versione 1.8.x e che tu voglia eseguire l'upgrade alla versione 1.8.8. Se esegui l'aggiornamento da una versione precedente, consulta le istruzioni per l'upgrade di Apigee hybrid alla versione 1.7.

Se preferisci continuare a utilizzare Anthos Service Mesh, devi assicurarti che venga eseguito l'upgrade a una versione supportata. Consulta la tabella Piattaforme supportate per le versioni supportate di Anthos Service Mesh.

Prepararsi all'upgrade alla versione 1.8

Eseguire il backup dell'installazione ibrida (consigliato)

Queste istruzioni utilizzano la variabile di ambiente APIGEECTL_HOME per la directory nel file system in cui hai installato apigeectl. Se necessario, cambia directory nella directory apigeectl e definisci la variabile con il seguente comando:
Linux
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Mac OS
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
echo %APIGEECTL_HOME%
```
Crea una copia di backup della directory $APIGEECTL_HOME/ della versione 1.7. Ad esempio:
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.7-backup.tar.gz $APIGEECTL_HOME
```
Esegui il backup del database Cassandra seguendo le istruzioni riportate in Backup e ripristino di Cassandra.

Aggiungi il ruolo Agente Cloud Trace all'account di servizio per il runtime Apigee. (Facoltativo)

(Facoltativo) Se prevedi di utilizzare Cloud Trace e non hai già eseguito questo passaggio nell'installazione ibrida v1.7, assicurati che il service account per i servizi di runtime Apigee disponga del ruolo Google Agente Cloud Trace. (roles/cloudtrace.agent).

Per gli ambienti di produzione, in genere si tratta del account di servizio apigee-runtime. Per gli ambienti non di produzione, in genere si tratta del account di servizio apigee-non-prod.

Puoi aggiungere il ruolo nell'interfaccia utente console Google Cloud > IAM e amministrazione > Service account o con i seguenti comandi:

Ottieni l'indirizzo email del tuo account di servizio con il seguente comando:
Produzione
```
gcloud iam service-accounts list --filter "apigee-runtime"
```
Se corrisponde al pattern apigee-runtime@$ORG_NAME.iam.gserviceaccount.com, puoi utilizzarlo nel passaggio successivo.
Non di produzione
```
gcloud iam service-accounts list --filter "apigee-non-prod"
```
Se corrisponde al pattern apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com, puoi utilizzarlo nel passaggio successivo.

Assegna il ruolo Agente Cloud Trace al account di servizio:

Produzione

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-runtime@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

Non di produzione

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-non-prod@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

Esempio

gcloud projects add-iam-policy-binding hybrid-example-project \
    --member="serviceAccount:apigee-runtime@hybrid-example-project.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

Dove $PROJECT_ID è il nome del progetto Google Cloud in cui è installato Apigee Hybrid.

Nota: se l'installazione utilizza un nome personalizzato per il account di servizio, sostituisci questo nome con apigee-runtime o apigee-non-prod nel comando.

Prepararsi a installare il gateway in entrata Apigee

Per installare il gateway in entrata Apigee nell'ambito dell'upgrade. Devi aggiungere la seguente proprietà ingressGateways al file di override.

Sintassi

ingressGateways:
- name: INGRESS_NAME
  replicaCountMin: REPLICAS_MIN
  replicaCountMax: REPLICAS_MAX
  resources:
    requests:
      cpu: CPU_COUNT_REQ
      memory: MEMORY_REQ
    limits:
      cpu: CPU_COUNT_LIMIT
      memory: MEMORY_LIMIT
  svcAnnotations:  # optional. See Known issue 243599452.
    SVC_ANNOTATIONS_KEY: SVC_ANNOTATIONS_VALUE
  svcLoadBalancerIP: SVC_LOAD_BALANCER_IP # optional

Esempio

ingressGateways:
- name: prod1
  replicaCountMin: 2
  replicaCountMax: 100
  resources:
    requests:
      cpu: 1
      memory: 1Gi
    limits:
      cpu: 2
      memory: 2Gi

INGRESS_NAME è il nome del deployment Ingress. Può essere qualsiasi nome che soddisfi i seguenti requisiti:
- Avere una lunghezza massima di 17 caratteri
- Contenere solo caratteri alfanumerici minuscoli, '-' o '.'
- Iniziare con un carattere alfanumerico
- Terminare con un carattere alfanumerico
Consulta ingressGateways[].name nel Riferimento per le proprietà di configurazione
REPLICAS_MIN e REPLICAS_MAX sono il numero minimo e massimo di repliche per il gateway in entrata Apigee nell'installazione. Per ulteriori informazioni e impostazioni predefinite, vedi ingressGateways[].replicaCountMin e ingressGateways[].replicaCountMax nella Guida di riferimento alle proprietà di configurazione.
CPU_COUNT_REQ e MEMORY_REQ sono la richiesta di CPU e memoria per ogni replica del gateway in entrata Apigee nell'installazione.
Imposta queste proprietà solo se le hai già impostate per il gateway in entrata di Anthos Service Mesh, ad esempio nel file overlay.yaml.

Per ulteriori informazioni e impostazioni predefinite, vedi ingressGateways[].resources.requests.cpu e ingressGateways[].resources.requests.memory nel riferimento alla proprietà di configurazione.
CPU_COUNT_LIMIT e MEMORY_LIMIT I limiti massimi di CPU e memoria per ogni replica del gateway in entrata Apigee nell'installazione.
Imposta queste proprietà solo se le hai già impostate per il gateway in entrata di Anthos Service Mesh, ad esempio nel file overlay.yaml.

Per ulteriori informazioni e impostazioni predefinite, vedi ingressGateways[].resources.limits.cpu e ingressGateways[].resources.limits.memory nel riferimento alla proprietà di configurazione.
SVC_ANNOTATIONS_KEY e SVC_ANNOTATIONS_VALUE (facoltativo):
Nota:il campo ingressGateways[].svcAnnotations in overrides.yaml non funziona come previsto. Vedi Problema noto 243599452

Si tratta di una coppia chiave-valore che fornisce annotazioni per il servizio di ingresso predefinito. Le annotazioni vengono utilizzate dalla tua piattaforma cloud per aiutare a configurare l'installazione ibrida, ad esempio impostando il tipo di bilanciatore del carico su interno o esterno. Ad esempio:
```
ingressGateways:
  svcAnnotations:
    networking.gke.io/load-balancer-type: "Internal"
```
Le annotazioni variano da piattaforma a piattaforma. Consulta la documentazione della piattaforma per le annotazioni richieste e suggerite.

Nota:non è necessario impostare Annotations se stai creando un tuo servizio Kubernetes per il deployment di Ingress come descritto in Esporre il gateway Ingress di Apigee.
Consulta ingressGateways[].svcAnnotations nel Riferimento per le proprietà di configurazione.
SVC_LOAD_BALANCER_IP (facoltativo) Consente di assegnare un indirizzo IP statico al bilanciatore del carico. Sulle piattaforme che supportano la specifica dell'indirizzo IP del bilanciatore del carico, il bilanciatore del carico verrà creato con questo indirizzo IP. Sulle piattaforme che non consentono di specificare l'indirizzo IP del bilanciatore del carico, questa proprietà viene ignorata.
Se non hai un indirizzo IP statico allocato per il bilanciatore del carico, escludi questa proprietà dal file di override.

Attenzione:assicurati di non specificare lo stesso indirizzo IP dell'attuale istio-ingressgateway. Ciò potrebbe causare problemi mentre il servizio è ancora sul cluster.

Nota:non è necessario impostare LoadBalancerIP se stai creando un tuo servizio Kubernetes per il deployment di Ingress, come descritto in Esponi il gateway Ingress di Apigee.
Consulta ingressGateways[].svcLoadBalancerIP in Riferimento per le proprietà di configurazione.

Apporta ulteriori modifiche al file di override per attivare o disattivare le funzionalità facoltative della versione 1.8

Aggiungi le seguenti proprietà al file overrides.yaml per abilitare le nuove funzionalità in hybrid v1.8. Queste funzionalità sono facoltative.

L'UDCA con ambito organizzazione è ora attivo per impostazione predefinita. L'utilizzo di un singolo deployment UDCA per gestire il traffico per tutti gli ambienti impedisce il sottoutilizzo dei pod UDCA e aumenta la disponibilità delle risorse dei nodi per altri componenti Apigee. L'UDCA con ambito organizzazione utilizza un unico account di servizio per tutti gli ambienti, apigee-udca.
Se utilizzi service account diversi per UDCA in ambienti diversi, tieni presente che ora utilizzerà ilaccount di serviziot specificato a livello di organizzazione nel file di override con udca:serviceAccountPath, anziché quelli specificati a livello di ambiente con envs:udca:serviceAccountPath.

Apigee hybrid versione 1.8 supporta UDCA con ambito ambiente. Per mantenere l'UDCA per ambiente, imposta orgScopedUDCA: false.

Nota: il supporto per UDCA con ambito ambiente non sarà disponibile nelle versioni future di Apigee Hybrid.

Consulta orgScopedUDCA nel riferimento alle proprietà di configurazione.
Attiva validateOrg per richiedere una convalida rigorosa che l'organizzazione e l'ambiente Apigee siano attivi e funzionino con il progetto Google Cloud Platform specificato nel file overrides.
```
validateOrg: true
```
Nota:Apigee Hybrid supporta la mancata convalida rigorosa dell'organizzazione. Per disattivare la funzionalità, imposta validateOrg: false.

Consulta validateOrg nel riferimento alle proprietà di configurazione.

Installa il runtime di hybrid 1.8.8

Assicurati di trovarti nella directory di base ibrida (il genitore della directory in cui si trova il file eseguibile apigeectl):
```
cd $APIGEECTL_HOME/..
```

Scarica il pacchetto di rilascio per il tuo sistema operativo utilizzando il seguente comando. Assicurati di selezionare la tua piattaforma nella tabella seguente:

Linux

Linux a 64 bit:

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_linux_64.tar.gz

Mac OS

Mac a 64 bit:

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_mac_64.tar.gz

Windows

Windows a 64 bit:

curl -LO ^
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_windows_64.zip

Rinomina la directory apigeectl/ attuale con il nome di una directory di backup. Ad esempio:

Linux

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/

Mac OS

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/

Windows

rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.7

Estrai i contenuti del file gzip scaricato nella directory di base ibrida. La directory di base ibrida è la directory in cui si trova la directory apigeectl-v1.7 rinominata:
Linux
```
tar xvzf filename.tar.gz -C ./
```
Mac OS
```
tar xvzf filename.tar.gz -C ./
```
Windows
```
tar xvzf filename.zip -C ./
```
Per impostazione predefinita, i contenuti del file tar vengono espansi in una directory con la versione e la piattaforma nel nome. Ad esempio: ./apigeectl_1.8.8-xxxxxxx_linux_64. Rinomina la directory in apigeectl utilizzando il seguente comando:
Linux
```
mv apigeectl_1.8.8-xxxxxxx_linux_64 apigeectl
```
Mac OS
```
mv apigeectl_1.8.8-xxxxxxx_mac_64 apigeectl
```
Windows
```
rename apigeectl_1.8.8-xxxxxxx_windows_64 apigeectl
```
Passa alla directory apigeectl:
```
cd ./apigeectl
```
Questa directory è la home directory di apigeectl. È la posizione del comando eseguibile apigeectl.
Queste istruzioni utilizzano la variabile di ambiente $APIGEECTL_HOME per la directory nel file system in cui è installata l'utilità apigeectl. Se necessario, cambia directory nella directory apigeectl e definisci la variabile con il seguente comando:
Linux
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Mac OS
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
```
```
echo %APIGEECTL_HOME%
```
Verifica la versione di apigeectl con il comando version:
```
./apigeectl version
```
```
Version: 1.8.8
```
Passa alla directory hybrid-base-directory/hybrid-files. La directory hybrid-files contiene i file di configurazione, ad esempio il file di override, i certificati e gli account di servizio. Ad esempio:
```
cd $APIGEECTL_HOME/../hybrid-files
```
Verifica che kubectl sia impostato sul contesto corretto utilizzando il seguente comando. Il contesto attuale deve essere impostato sul cluster in cui esegui l'upgrade di Apigee hybrid.
```
kubectl config get-contexts | grep \*
```
Nella directory hybrid-files:
1. Aggiorna i seguenti link simbolici a $APIGEECTL_HOME. Questi link ti consentono di eseguire il comando apigeectl appena installato dall'interno della directory hybrid-files:
```
ln -nfs $APIGEECTL_HOME/tools tools
ln -nfs $APIGEECTL_HOME/config config
ln -nfs $APIGEECTL_HOME/templates templates
ln -nfs $APIGEECTL_HOME/plugins plugins
```
2. Per verificare che i link simbolici siano stati creati correttamente, esegui questo comando e assicurati che i percorsi dei link puntino alle posizioni corrette:
```
ls -l | grep ^l
```
Esegui un'inizializzazione di prova per verificare la presenza di errori:
```
${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client
```
dove OVERRIDES_FILE è il nome del file di override, ad esempio ./overrides/overrides.yaml.

Suggerimento:puoi sostituire OVERRIDES_FILE nell'esempio di codice riportato sopra con il nome e il percorso del file di override e ogni istanza in questa pagina verrà sostituita.
Se non ci sono errori, inizializza la versione ibrida 1.8.8. Questo comando installa e configura anche il gateway in entrata Apigee:
```
$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
```
Controlla lo stato di inizializzazione:
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```
Se l'operazione riesce, l'output è: All containers ready.

Problema noto: dopo aver eseguito init e aver confermato che check-ready è andato a buon fine, potresti notare, se visualizzi i pod, che la convalida dello schema Cassandra è in stato di errore. Questo stato è considerato un problema noto (#245664917) ed è innocuo. Puoi ignorare l'errore e passare al passaggio successivo: apigeectl apply.

Come ulteriore controllo, puoi anche eseguire questo comando per verificare lo stato di ApigeeDataStore:
```
kubectl describe apigeeds -n apigee
```
Nell'output, cerca State: running.
Controlla la presenza di errori con una prova dry run del comando apply utilizzando il flag --dry-run:
```
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
```
Se non ci sono errori, applica gli override. Seleziona e segui le istruzioni per gli ambienti di produzione o non di produzione, a seconda dell'installazione.
Durante la procedura di upgrade, ogni componente eseguirà un riavvio in sequenza. Pertanto, per gli ambienti di produzione, è consigliabile applicare l'upgrade a un componente alla volta.
Produzione

Per gli ambienti di produzione, devi eseguire l'upgrade di ogni componente ibrido singolarmente e controllare lo stato del componente aggiornato prima di procedere con il componente successivo.
1. Assicurati di trovarti nella directory hybrid-files.
2. Applica gli override per eseguire l'upgrade di Cassandra:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
3. Completamento del controllo:
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
  Suggerimento: se check-ready non va a buon fine, puoi ottenere maggiori informazioni sui tuoi pod con:
  kubectl -n NAMESPACE get pods
  
  dove NAMESPACE è lo spazio dei nomi di Apigee hybrid.
  Procedi al passaggio successivo solo quando i pod sono pronti.
4. Applica gli override per eseguire l'upgrade dei componenti di Telemetry e verifica il completamento:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
5. Avvia i componenti Redis:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
6. Applica gli override per eseguire l'upgrade dei componenti a livello di organizzazione (MART, Watcher e Apigee Connect) e verifica il completamento:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
7. Applica gli override per eseguire l'upgrade degli ambienti. Hai due opzioni:
  - Ambiente per ambiente: applica gli override a un ambiente alla volta e verifica il completamento. Ripeti questo passaggio per ogni ambiente:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    
    Dove ENV_NAME è il nome dell'ambiente di cui stai eseguendo l'upgrade.
  - Tutti gli ambienti contemporaneamente: applica gli override a tutti gli ambienti contemporaneamente e verifica il completamento:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
8. Applica gli override per eseguire l'upgrade dei componenti virtualhosts e verifica il completamento:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
Non di produzione

Nella maggior parte degli ambienti non di produzione, demo o sperimentali, puoi applicare gli override a tutti i componenti contemporaneamente. Se il tuo ambiente non di produzione è ampio e complesso o imita da vicino un ambiente di produzione, ti consigliamo di utilizzare le istruzioni per l'upgrade degli ambienti di produzione.
1. Assicurati di trovarti nella directory hybrid-files.
2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
3. Controlla lo stato:
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Esegui l'upgrade della versione di Kubernetes

Esegui l'upgrade della piattaforma Kubernetes alle versioni supportate da hybrid 1.8. Se hai bisogno di aiuto, consulta la documentazione della tua piattaforma.

Fai clic per espandere l'elenco delle piattaforme supportate

	Versioni di Apigee hybrid
Piattaforme	1.6 ⁽³⁾	1.7 ⁽³⁾	1,8 ⁽³⁾	1,9	1,10
Anthos (Google Cloud - GKE)	1.19.x 1.20.x 1.21.x	1.20.x 1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.21.x ^{(≤ 1.8.3)} 1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
Anthos (AWS)	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.25⁽¹³⁾	1.12.x 1.13.x 1.25⁽¹³⁾	1.13.x 1.25⁽¹³⁾ 1.26⁽¹³⁾
Anthos (Azure)	1.8.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x	1.12.x 1.13.x 1.14.x	1.13.x 1.14.x 1.15.x
Anthos (on-premise - VMware)⁽¹⁾	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x ⁽⁴⁾ 1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} 1.12.x ⁽⁴⁾ ^{(≥ 1.7.2)}	1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ 1.12.x ⁽⁴⁾ ⁽⁵⁾ 1.13.x ⁽⁵⁾ 1.14.x ⁽⁵⁾ 1.15.x	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
Anthos (Bare Metal)⁽¹⁾	1.7.x 1.8.2+ 1.9.3+ 1.10.x	1.9.x ⁽⁴⁾ 1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} 1.12.x ⁽⁴⁾ ^{(≥ 1.7.2)}	1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ 1.12.x ⁽⁴⁾ ⁽⁵⁾ 1.13.x ⁽⁵⁾ 1.14.x ⁽⁵⁾ 1.15.x	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
EKS⁽⁷⁾	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
AKS⁽⁷⁾	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
OpenShift⁽⁷⁾	4.6 4.7 4.8	4.7 4.8	4.8 4.9 4.10	4.10 4.11	4.11 4.12
Rancher Kubernetes Engine (RKE)⁽⁷⁾	N/D	N/D	N/D	1.3.8	v1.26.2+rke2r1
Componenti	1.6 ⁽³⁾	1.7 ⁽³⁾	1.8	1,9	1,10
Anthos Service Mesh (ASM)	1.9.x 1.10.x 1.12.x 1.13.x	1.10.x 1.11.x 1.12.x 1.13.x ^{(≥ 1.7.2)} 1.14.x 1.15.x ^{(≥ 1.7.6)}	1.11.x 1.12.x 1.13.x 1.14.x 1.15.x	1.17.x⁽¹¹⁾	1.17.x⁽¹¹⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.5.4	1.7.x	1.7.x 1.8.x 1.9.x 1.10.x 1.11.x	1.10.x 1.11.x	1.10.x 1.11.x 1.12.x
Cassandra	3.11.10	3.11.10	3.11.10	3.11.10	3.11.10
⁽¹⁾ Nelle versioni 1.8, 1.9 e 1.10 di Anthos, segui le istruzioni riportate in questi documenti per evitare conflitti con `cert-manager`: Anthos 1.8.2+: Conflitto con `cert-manager` durante l'upgrade alla versione 1.8.2 o successive. Anthos 1.9: Conflitto con `cert-manager` durante l'upgrade alla versione 1.9.0 o 1.9.1. Anthos 1.10+: Installazione di `cert-manager` in conflitto. ⁽²⁾ Supporto disponibile con Apigee hybrid versione 1.7.2 e successive. ⁽³⁾ Sono state raggiunte le date di fine del ciclo di vita ufficiali per le versioni 1.8 e precedenti di Apigee hybrid. Le patch mensili regolari non sono più disponibili. Queste versioni non sono più supportate ufficialmente, ad eccezione dei clienti con eccezioni esplicite e ufficiali per il supporto continuo. Gli altri clienti devono eseguire l'upgrade. ⁽⁴⁾Le versioni 1.12 e precedenti di Anthos on Bare Metal e VMware non sono più supportate. Consulta le Norme di assistenza per le versioni di Anthos on bare metal e le Cluster Anthos su VMware VMware. ⁽⁵⁾Anthos on Bare Metal e VMWare richiede ASM 1.14 o versioni successive. Ti consigliamo di eseguire l'upgrade a hybrid v1.8 e passare al gateway in entrata Apigee, che non richiede più l'installazione di ASM sul cluster ibrido. ⁽⁶⁾ Supporto disponibile con Apigee hybrid versione 1.8.4 e successive. ⁽⁷⁾ I cluster collegati non sono necessari per Apigee hybrid v1.8 e versioni successive che utilizzano Apigee ingressgateway.. ⁽⁸⁾ Non supportato con Apigee hybrid versione 1.8.4 e successive. ⁽⁹⁾ Supporto disponibile con Apigee hybrid versione 1.7.6 e successive. ⁽¹⁰⁾ Non supportato con Apigee hybrid versione 1.8.5 e successive. ⁽¹¹⁾ ASM viene installato automaticamente con Apigee hybrid 1.9 e versioni successive. ⁽¹²⁾ Supporto disponibile con Apigee hybrid versione 1.9.2 e successive. ⁽¹³⁾ I numeri di versione dei cluster Anthos su AWS (multi-cloud) ora riflettono le versioni di Kubernetes. Per i dettagli della versione e le patch consigliate, consulta Versione di Anthos e assistenza per l'upgrade.

Informazioni sui cluster collegati

Per Apigee hybrid versioni 1.7.x e precedenti, devi utilizzare i cluster allegati di Anthos se vuoi eseguire Apigee hybrid in un contesto multicloud su Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) o un altro provider di servizi Kubernetes di terze parti supportato. Il collegamento del cluster consente a Google di misurare l'utilizzo di Anthos Service Mesh (ASM). La registrazione del cluster di terze parti è facoltativa. Registrati solo se vuoi visualizzare il cluster allegato in Google Cloud console. Per ulteriori informazioni, consulta Collegare cluster Kubernetes di terze parti a Google Cloud.

Per Apigee Hybrid versione 1.8.x, i cluster collegati ad Anthos sono necessari se utilizzi Anthos Service Mesh per il gateway in entrata. Se utilizzi il gateway di ingresso Apigee, i cluster Anthos allegati sono facoltativi.

Sposta il traffico da Anthos Service Mesh al gateway in entrata Apigee

Per trasferire il traffico al gateway in entrata Apigee:

Esporre il gateway di ingresso Apigee. Segui le procedure descritte in Esporre il gateway di ingresso Apigee.
Testa il nuovo gateway di ingresso chiamando un proxy. Idealmente, testa tutti i proxy cruciali che hai attualmente implementato.
Per cambiare il traffico, aggiorna i record DNS in modo che puntino all'indirizzo IP del nuovo gateway di ingresso Apigee. A seconda del provider DNS, potresti essere in grado di spostare gradualmente il traffico sul nuovo endpoint.
Suggerimento: puoi trovare l'indirizzo IP esterno del gateway di ingresso Apigee con il seguente comando:
```
kubectl get svc -n apigee -l app=apigee-ingressgateway
```
L'output dovrebbe essere simile a questo:
```
NAME                                        TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                      AGE
apigee-ingressgateway-prod-hybrid-37a39bd   LoadBalancer   192.0.2.123   233.252.0.123   15021:32049/TCP,80:31624/TCP,443:30723/TCP   16h
```
Assicurati che tutto il traffico di runtime funzioni monitorando le dashboard. Procedi al passaggio successivo solo se tutto funziona come previsto. Assicurati che nessun traffico passi attraverso il vecchio gateway in entrata (Anthos Service Mesh), poiché la propagazione dell'aggiornamento DNS potrebbe essere lenta a causa della memorizzazione nella cache DNS.
Per impedire ad Apigee di fornire la configurazione ad Anthos Service Mesh, segui i passaggi descritti in Interrompere la fornitura della configurazione ad ASM nella guida Gestione del gateway in entrata Apigee.
Esegui nuovamente il test e monitora il traffico proxy API.
Segui le istruzioni riportate nella documentazione di Anthos Service Mesh per disinstallare Anthos Service Mesh dal cluster.

Esegui l'upgrade di Anthos Service Mesh alla versione 1.15

Esegui le procedure utilizzando la documentazione di Anthos Service Mesh appropriata per la tua piattaforma:

Le istruzioni per installare e configurare Anthos Service Mesh variano a seconda della piattaforma. Le piattaforme sono suddivise nelle seguenti categorie:

GKE: cluster Google Kubernetes Engine in esecuzione su Google Cloud.
Al di fuori di Google Cloud: cluster Anthos in esecuzione su:
- Cluster Anthos su VMware (GKE On-Prem)
- Anthos on bare metal
- Anthos clusters on AWS
- Amazon EKS
Altre piattaforme Kubernetes: cluster conformi creati ed eseguiti su:
- AKS
- EKS
- OpenShift

GKE

La sequenza per l'upgrade ad Anthos Service Mesh versione 1.17.8 per l'installazione ibrida è la seguente:

Preparati per l'upgrade.
Installa la nuova versione di Anthos Service Mesh.
Elimina i deployment, i servizi e gli webhook della versione precedente di Anthos Service Mesh dall'installazione attuale.
Esegui l'upgrade dei gateway e configura i nuovi webhook.

Preparati all'upgrade di Anthos Service Mesh alla versione 1.17.8

Esamina i requisiti in Esegui l'upgrade di Anthos Service Mesh, ma non eseguire ancora l'upgrade.
Prima di installare la nuova versione, determina la revisione corrente. Avrai bisogno di queste informazioni per eliminare i deployment, i servizi e gli webhook della versione precedente di Anthos Service Mesh dall'installazione corrente. Utilizza questo comando per archiviare la revisione istiod corrente in una variabile di ambiente:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
L'output dovrebbe essere simile a 1.16

Nota:se il comando restituisce più valori, imposta il valore di DELETE_REV sulla versione precedente e segui la procedura per eliminare la versione precedente, quindi ripeti la procedura finché non hai eliminato tutte le versioni.

Crea un nuovo file overlay.yaml o verifica che il file overlay.yaml esistente contenga i seguenti contenuti:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Segui le istruzioni nelle sezioni seguenti della documentazione di Anthos Service Mesh:
Importante:assicurati di seguire le istruzioni per eseguire l'upgrade di Anthos Service Mesh con funzionalità facoltative e includere overlay.yaml.
1. Scarica asmcli
2. Concedere le autorizzazioni di amministratore del cluster
3. Convalida progetto e cluster
4. Esegui l'upgrade con funzionalità facoltative. Fermati prima di iniziare la sezione "Aggiorna gateway".
Passa al nuovo control plane:
1. Recupera l'etichetta di revisione presente su istiod:
```
kubectl get pod -n istio-system -L istio.io/rev
```
  L'output del comando è simile al seguente.
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
```
2. Assegna l'etichetta della revisione più recente a una variabile di ambiente.
  Nell'output, nella colonna REV, prendi nota del valore dell'etichetta di revisione per la nuova versione. In questo esempio, il valore è asm-1178-1
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Aggiungi l'etichetta di revisione allo spazio dei nomi istio-system e rimuovi l'etichetta istio-injection (se esiste) con il seguente comando.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Se nell'output vedi "istio-injection not found", puoi ignorarlo. Ciò significa che lo spazio dei nomi non aveva in precedenza l'etichetta istio-injection. Poiché l'iniezione automatica non riesce se uno spazio dei nomi ha sia l'etichetta istio-injection sia quella di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh includono la rimozione dell'etichetta istio-injection.
4. Riavvia i pod per attivare la reiniezione.
```
kubectl rollout restart deployment -n istio-system
```
5. Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.
6. Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavvia i pod.

Elimina le versioni precedenti:

Vai alla directory in cui hai installato asmcli.
Memorizza la directory di output per l'installazione di Anthos Service Mesh nella variabile di ambiente DIR_PATH. Si tratta della stessa directory che hai specificato nella procedura Esegui l'upgrade con funzionalità facoltative.
```
export DIR_PATH=OUTPUT_DIR
```

Crea uno script shell contenente i seguenti comandi:

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Esegui lo script per eliminare le versioni precedenti.

Al di fuori di Google Cloud

Queste istruzioni riguardano l'upgrade di Anthos Service Mesh su:

Cluster Anthos su VMware (GKE On-Prem)
Anthos on bare metal
Anthos clusters on AWS
Amazon EKS

La sequenza per l'upgrade ad Anthos Service Mesh versione 1.17.8 per l'installazione ibrida è la seguente:

Preparati per l'upgrade.
Installa la nuova versione di Anthos Service Mesh.
Elimina i deployment, i servizi e gli webhook della versione precedente di Anthos Service Mesh dall'installazione attuale.
Esegui l'upgrade dei gateway e configura i nuovi webhook.

Preparati all'upgrade di Anthos Service Mesh alla versione 1.17.8

Esamina i requisiti in Esegui l'upgrade di Anthos Service Mesh, ma non eseguire ancora l'upgrade.
Prima di installare la nuova versione, determina la revisione corrente. Avrai bisogno di queste informazioni per eliminare i deployment, i servizi e gli webhook della versione precedente di Anthos Service Mesh dall'installazione corrente. Utilizza questo comando per archiviare la revisione istiod corrente in una variabile di ambiente:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
L'output dovrebbe essere simile a 1.16

Nota:se il comando restituisce più valori, imposta il valore di DELETE_REV sulla versione precedente e segui la procedura per eliminare la versione precedente, quindi ripeti la procedura finché non hai eliminato tutte le versioni.

Crea un nuovo file overlay.yaml o verifica che il file overlay.yaml esistente contenga i seguenti contenuti:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:  
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  values:
    gateways:
      istio-ingressgateway:
        runAsRoot: true

  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Segui le istruzioni nelle sezioni seguenti della documentazione di Anthos Service Mesh:
Importante:assicurati di seguire le istruzioni per eseguire l'upgrade di Anthos Service Mesh con funzionalità facoltative e includere overlay.yaml.
1. Scarica asmcli
2. Concedere le autorizzazioni di amministratore del cluster
3. Convalida progetto e cluster
4. Esegui l'upgrade con funzionalità facoltative. Fermati prima di iniziare la sezione "Aggiorna gateway".
Passa al nuovo control plane:
1. Recupera l'etichetta di revisione presente su istiod:
```
kubectl get pod -n istio-system -L istio.io/rev
```
  L'output del comando è simile al seguente.
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
```
2. Assegna l'etichetta della revisione più recente a una variabile di ambiente.
  Nell'output, nella colonna REV, prendi nota del valore dell'etichetta di revisione per la nuova versione. In questo esempio, il valore è asm-1178-1
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Aggiungi l'etichetta di revisione allo spazio dei nomi istio-system e rimuovi l'etichetta istio-injection (se esiste) con il seguente comando.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Se nell'output vedi "istio-injection not found", puoi ignorarlo. Ciò significa che lo spazio dei nomi non aveva in precedenza l'etichetta istio-injection. Poiché l'iniezione automatica non riesce se uno spazio dei nomi ha sia l'etichetta istio-injection sia quella di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh includono la rimozione dell'etichetta istio-injection.
4. Riavvia i pod per attivare la reiniezione.
```
kubectl rollout restart deployment -n istio-system
```
5. Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.
6. Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavvia i pod.

Elimina le versioni precedenti:

Vai alla directory in cui hai installato asmcli.
Memorizza la directory di output per l'installazione di Anthos Service Mesh nella variabile di ambiente DIR_PATH. Si tratta della stessa directory che hai specificato nella procedura Esegui l'upgrade con funzionalità facoltative.
```
export DIR_PATH=OUTPUT_DIR
```

Crea uno script shell contenente i seguenti comandi:

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Esegui lo script per eliminare le versioni precedenti.

AKS / EKS

In queste istruzioni, la procedura di upgrade di Anthos Service Mesh (Anthos Service Mesh) versione 1.17.8-asm.4-distroless sui cluster Anthos allegati è la stessa di una nuova installazione.

Preparazione per l'installazione di Anthos Service Mesh

Prima di installare la nuova versione, determina la revisione corrente. Avrai bisogno di queste informazioni per eliminare il webhook di convalida e il webhook di mutazione dall'installazione corrente di Anthos Service Mesh. Utilizza questo comando per archiviare la revisione istiod corrente in una variabile di ambiente:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
L'output dovrebbe essere simile a 1.16

Nota:se il comando restituisce più valori, imposta il valore di DELETE_REV sulla versione meno recente e segui la procedura per eliminare la versione meno recente, poi ripeti la procedura finché non avrai eliminato tutte le versioni.

Linux

Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro corrente:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz

Scarica il file della firma e utilizza OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature 1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Estrai i contenuti del file in qualsiasi posizione del file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:

tar xzf 1.17.8-asm.4-distroless-linux-amd64.tar.gz

Il comando crea una directory di installazione nella directory di lavoro corrente denominata 1.17.8-asm.4-distroless che contiene:

Applicazioni di esempio nella directory samples.
Lo strumento a riga di comando istioctl che utilizzi per installare Anthos Service Mesh si trova nella directory bin.
I profili di configurazione di Anthos Service Mesh si trovano nella directory manifests/profiles.

Assicurati di trovarti nella directory principale dell'installazione di Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

Per comodità, aggiungi gli strumenti nella directory /bin al tuo PATH:

export PATH=$PWD/bin:$PATH

Mac OS

Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro corrente:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz

Scarica il file della firma e utilizza OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature 1.17.8-asm.4-distroless-osx.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Estrai i contenuti del file in qualsiasi posizione del file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:

tar xzf 1.17.8-asm.4-distroless-osx.tar.gz

Il comando crea una directory di installazione nella directory di lavoro corrente denominata 1.17.8-asm.4-distroless che contiene:

Applicazioni di esempio nella directory samples.
Lo strumento a riga di comando istioctl che utilizzi per installare Anthos Service Mesh si trova nella directory bin.
I profili di configurazione di Anthos Service Mesh si trovano nella directory manifests/profiles.

Assicurati di trovarti nella directory principale dell'installazione di Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

Per comodità, aggiungi gli strumenti nella directory /bin al tuo PATH:

export PATH=$PWD/bin:$PATH

Windows

Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro corrente:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip

Scarica il file della firma e utilizza OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip.1.sig

openssl dgst -verify - -signature 1.17.8-asm.4-distroless-win.zip.1.sig 1.17.8-asm.4-distroless.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Estrai i contenuti del file in qualsiasi posizione del file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:

tar xzf 1.17.8-asm.4-distroless-win.zip

Il comando crea una directory di installazione nella directory di lavoro corrente denominata 1.17.8-asm.4-distroless che contiene:

Applicazioni di esempio nella directory samples.
Lo strumento a riga di comando istioctl che utilizzi per installare Anthos Service Mesh si trova nella directory bin.
I profili di configurazione di Anthos Service Mesh si trovano nella directory manifests\profiles.

Assicurati di trovarti nella directory principale dell'installazione di Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

Per comodità, aggiungi gli strumenti nella directory \bin al tuo PATH:

set PATH=%CD%\bin:%PATH%

Ora che Anthos Service Mesh Istio è installato, controlla la versione di istioctl:
```
istioctl version
```
Crea uno spazio dei nomi denominato istio-system per i componenti del control plane:
```
kubectl create namespace istio-system
```

Installazione di Anthos Service Mesh

Modifica il file overlay.yaml o creane uno nuovo con il seguente contenuto:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        service:
          type: LoadBalancer
          ports:
          - name: status-port
            port: 15021
            targetPort: 15021
          - name: http2
            port: 80
            targetPort: 8080
          - name: https
            port: 443
            targetPort: 8443

Installa Anthos Service Mesh con istioctl utilizzando il profilo asm-multicloud:
```
istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1178-1" \
    --filename overlay.yaml
```
L'output dovrebbe essere simile a questo:
```
kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1178-1-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1178-1-798ffb964-fnj8c       1/1     Running   1          3m21s
```
L'argomento --set revision aggiunge un'etichetta di revisione nel formato istio.io/rev=asm-1178-1 a istiod. L'etichetta di revisione viene utilizzata dal webhook di inserimento automatico dei sidecar per associare i sidecar inseriti a una determinata revisione istiod. Per attivare l'iniezione automatica di sidecar per uno spazio dei nomi, devi etichettarlo con una revisione che corrisponda all'etichetta su istiod.

Verifica che l'installazione sia stata completata:

kubectl get svc -n istio-system

L'output dovrebbe essere simile a questo:

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1178-1       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

Passa al nuovo control plane:
1. Recupera l'etichetta di revisione presente su istiod:
```
kubectl get pod -n istio-system -L istio.io/rev
```
  L'output del comando è simile al seguente.
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
```
2. Assegna l'etichetta della revisione più recente a una variabile di ambiente.
  Nell'output, nella colonna REV, prendi nota del valore dell'etichetta di revisione per la nuova versione. In questo esempio, il valore è asm-1178-1
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Aggiungi l'etichetta di revisione allo spazio dei nomi istio-system e rimuovi l'etichetta istio-injection (se esiste) con il seguente comando.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Se nell'output vedi "istio-injection not found", puoi ignorarlo. Ciò significa che lo spazio dei nomi non aveva in precedenza l'etichetta istio-injection. Poiché l'iniezione automatica non riesce se uno spazio dei nomi ha sia l'etichetta istio-injection sia quella di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh includono la rimozione dell'etichetta istio-injection.
4. Riavvia i pod per attivare la reiniezione.
```
kubectl rollout restart deployment -n istio-system
```
5. Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.
6. Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavvia i pod.

Elimina le versioni precedenti:

Vai alla directory in cui hai installato asmcli.

Crea uno script shell contenente i seguenti comandi:

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Esegui lo script per eliminare le versioni precedenti.

OpenShift

In queste istruzioni, la procedura di upgrade di Anthos Service Mesh (Anthos Service Mesh) versione 1.17.8-asm.4-distroless sui cluster Anthos allegati è la stessa di una nuova installazione.

Preparazione per l'installazione di Anthos Service Mesh

Prima di installare la nuova versione, determina la revisione corrente. Avrai bisogno di queste informazioni per eliminare il webhook di convalida e il webhook di mutazione dall'installazione corrente di Anthos Service Mesh. Utilizza questo comando per archiviare la revisione istiod corrente in una variabile di ambiente:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
L'output dovrebbe essere simile a 1.16

Nota:se il comando restituisce più valori, imposta il valore di DELETE_REV sulla versione meno recente e segui la procedura per eliminare la versione meno recente, poi ripeti la procedura finché non avrai eliminato tutte le versioni.

Linux

Concedi il vincolo del contesto di sicurezza (SCC) anyuid a istio-system con il seguente comando dell'interfaccia a riga di comando OpenShift (oc):

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro corrente:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz

Scarica il file della firma e utilizza OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature 1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Estrai i contenuti del file in qualsiasi posizione del file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:

tar xzf 1.17.8-asm.4-distroless-linux-amd64.tar.gz

Il comando crea una directory di installazione nella directory di lavoro corrente denominata 1.17.8-asm.4-distroless che contiene:

Applicazioni di esempio nella directory samples.
Lo strumento a riga di comando istioctl che utilizzi per installare Anthos Service Mesh si trova nella directory bin.
I profili di configurazione di Anthos Service Mesh si trovano nella directory manifests/profiles.

Assicurati di trovarti nella directory principale dell'installazione di Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

Per comodità, aggiungi gli strumenti nella directory /bin al tuo PATH:

export PATH=$PWD/bin:$PATH

Mac OS

Concedi il vincolo del contesto di sicurezza (SCC) anyuid a istio-system con il seguente comando dell'interfaccia a riga di comando OpenShift (oc):

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro corrente:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz

Scarica il file della firma e utilizza OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature 1.17.8-asm.4-distroless-osx.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Estrai i contenuti del file in qualsiasi posizione del file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:

tar xzf 1.17.8-asm.4-distroless-osx.tar.gz

Il comando crea una directory di installazione nella directory di lavoro corrente denominata 1.17.8-asm.4-distroless che contiene:

Applicazioni di esempio nella directory samples.
Lo strumento a riga di comando istioctl che utilizzi per installare Anthos Service Mesh si trova nella directory bin.
I profili di configurazione di Anthos Service Mesh si trovano nella directory manifests/profiles.

Assicurati di trovarti nella directory principale dell'installazione di Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

Per comodità, aggiungi gli strumenti nella directory /bin al tuo PATH:

export PATH=$PWD/bin:$PATH

Windows

Concedi il vincolo del contesto di sicurezza (SCC) anyuid a istio-system con il seguente comando dell'interfaccia a riga di comando OpenShift (oc):

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

Scarica il file di installazione di Anthos Service Mesh nella directory di lavoro corrente:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip

Scarica il file della firma e utilizza OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip.1.sig

openssl dgst -verify - -signature 1.17.8-asm.4-distroless-win.zip.1.sig 1.17.8-asm.4-distroless.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Estrai i contenuti del file in qualsiasi posizione del file system. Ad esempio, per estrarre i contenuti nella directory di lavoro corrente:

tar xzf 1.17.8-asm.4-distroless-win.zip

Il comando crea una directory di installazione nella directory di lavoro corrente denominata 1.17.8-asm.4-distroless che contiene:

Applicazioni di esempio nella directory samples.
Lo strumento a riga di comando istioctl che utilizzi per installare Anthos Service Mesh si trova nella directory bin.
I profili di configurazione di Anthos Service Mesh si trovano nella directory manifests\profiles.

Assicurati di trovarti nella directory principale dell'installazione di Anthos Service Mesh:

cd 1.17.8-asm.4-distroless

Per comodità, aggiungi gli strumenti nella directory \bin al tuo PATH:

set PATH=%CD%\bin:%PATH%

Ora che Anthos Service Mesh Istio è installato, controlla la versione di istioctl:
```
istioctl version
```
Crea uno spazio dei nomi denominato istio-system per i componenti del control plane:
```
kubectl create namespace istio-system
```

Configura il webhook di convalida

Quando installi Anthos Service Mesh, imposti un'etichetta di revisione su istiod. Devi impostare la stessa revisione sul webhook di convalida.

Crea un file denominato istiod-service.yaml con i seguenti contenuti:

apiVersion: v1
kind: Service
metadata:
  name: istiod
  namespace: istio-system
  labels:
    istio.io/rev: asm-1178-1
    app: istiod
    istio: pilot
    release: istio
spec:
  ports:
    - port: 15010
      name: grpc-xds # plaintext
      protocol: TCP
    - port: 15012
      name: https-dns # mTLS with k8s-signed cert
      protocol: TCP
    - port: 443
      name: https-webhook # validation and injection
      targetPort: 15017
      protocol: TCP
    - port: 15014
      name: http-monitoring # prometheus stats
      protocol: TCP
  selector:
    app: istiod
    istio.io/rev: asm-1178-1
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Utilizza kubectl per applicare la configurazione del webhook di convalida:
```
kubectl apply -f istiod-service.yaml
```

Verifica che la configurazione sia stata applicata:

kubectl get svc -n istio-system

La risposta dovrebbe essere simile alla seguente:

NAME     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                 AGE
istiod   ClusterIP   172.200.18.133   <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP   22s

Installazione di Anthos Service Mesh

Modifica il file overlay.yaml o creane uno nuovo con il seguente contenuto:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        k8s:
          service:
            type: LoadBalancer
            ports:
            - name: status-port
              port: 15021
              targetPort: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443

Installa Anthos Service Mesh con istioctl utilizzando il profilo asm-multicloud:
```
istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1178-1" \
    --filename overlayfile.yaml
```
L'output dovrebbe essere simile a questo:
```
kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1178-1-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1178-1-798ffb964-fnj8c       1/1     Running   1          3m21s
```
L'argomento --set revision aggiunge un'etichetta di revisione nel formato istio.io/rev=1.6.11-asm.1 a istiod. L'etichetta di revisione viene utilizzata dal webhook di inserimento automatico dei sidecar per associare i sidecar inseriti a una determinata revisione istiod. Per attivare l'iniezione automatica di sidecar per uno spazio dei nomi, devi etichettarlo con una revisione che corrisponda all'etichetta su istiod.

Verifica che l'installazione sia stata completata:

kubectl get svc -n istio-system

L'output dovrebbe essere simile a questo:

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1178-1       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

Passa al nuovo control plane:
1. Recupera l'etichetta di revisione presente su istiod:
```
kubectl get pod -n istio-system -L istio.io/rev
```
  L'output del comando è simile al seguente.
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
```
2. Assegna l'etichetta della revisione più recente a una variabile di ambiente.
  Nell'output, nella colonna REV, prendi nota del valore dell'etichetta di revisione per la nuova versione. In questo esempio, il valore è asm-1178-1
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Aggiungi l'etichetta di revisione allo spazio dei nomi istio-system e rimuovi l'etichetta istio-injection (se esiste) con il seguente comando.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Se nell'output vedi "istio-injection not found", puoi ignorarlo. Ciò significa che lo spazio dei nomi non aveva in precedenza l'etichetta istio-injection. Poiché l'iniezione automatica non riesce se uno spazio dei nomi ha sia l'etichetta istio-injection sia quella di revisione, tutti i comandi kubectl label nella documentazione di Anthos Service Mesh includono la rimozione dell'etichetta istio-injection.
4. Riavvia i pod per attivare la reiniezione.
```
kubectl rollout restart deployment -n istio-system
```
5. Testa l'applicazione per verificare che i carichi di lavoro funzionino correttamente.
6. Se hai carichi di lavoro in altri spazi dei nomi, ripeti i passaggi per etichettare lo spazio dei nomi e riavvia i pod.

Elimina le versioni precedenti:

Vai alla directory in cui hai installato asmcli.

Crea uno script shell contenente i seguenti comandi:

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Esegui lo script per eliminare le versioni precedenti.

Eseguire il rollback di un upgrade

Per eseguire il rollback di un upgrade precedente:

Pulisci i job completati per lo spazio dei nomi del runtime ibrido, dove NAMESPACE è lo spazio dei nomi specificato nel file di override, se ne hai specificato uno. In caso contrario, lo spazio dei nomi predefinito è apigee:
```
kubectl delete job -n NAMESPACE \
  $(kubectl get job -n NAMESPACE \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

Pulisci i job completati per lo spazio dei nomi apigee-system:

kubectl delete job -n apigee-system \
  $(kubectl get job -n apigee-system \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

Modifica la variabile APIGEECTL_HOME in modo che punti alla directory che contiene la versione precedente di apigeectl. Ad esempio:
```
export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
```
Annulla le modifiche apportate al file overrides:
1. Rimuovi o commenta ingressGateways e tutte le relative proprietà.
2. Imposta il valore di virtualhosts.selector.app sul valore precedente, ad esempio:
```
virtualhosts:
  - name: my-env-group
    selector:
      app: istio-ingressgateway
```
3. Rimuovi o commenta ao.args.disableIstioConfigInAPIServer.
Nella directory radice dell'installazione a cui vuoi eseguire il rollback, esegui apigeectl apply, controlla lo stato dei pod e poi esegui apigeectl init. Assicurati di utilizzare il file di override originale per la versione a cui vuoi eseguire il rollback:
1. Nella directory hybrid-files, esegui apigeectl apply:
```
$APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE
```
  Dove ORIGINAL_OVERRIDES_FILE è il percorso relativo e il nome del file degli override per l'installazione ibrida della versione precedente, ad esempio, ./overrides/overrides1.7.yaml.
2. Controlla lo stato dei pod:
```
kubectl -n NAMESPACE get pods
```
  dove NAMESPACE è lo spazio dei nomi di Apigee hybrid.
3. Controlla lo stato di apigeeds:
```
kubectl describe apigeeds -n apigee
```
  L'output dovrebbe essere simile a questo:
```
Status:
  Cassandra Data Replication:
  Cassandra Pod Ips:
    10.8.2.204
  Cassandra Ready Replicas:  1
  Components:
    Cassandra:
      Last Successfully Released Version:
        Revision:  v1-f8aa9a82b9f69613
        Version:   v1
      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  Scaling:
    In Progress:         false
    Operation:
    Requested Replicas:  0
  State:                 running
```
  Procedi al passaggio successivo solo quando il pod apigeeds è in esecuzione.
4. Esegui il seguente comando per annotare i nuovi valori del conteggio delle repliche per il processore di messaggi dopo l'upgrade.Se questi valori non corrispondono a quelli impostati in precedenza, modificali nel file di override in modo che corrispondano alla configurazione precedente.
```
apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2
```
  L'output dovrebbe essere simile a questo:
```
      autoScaler:
        minReplicas: 2
        maxReplicas: 10
```
5. Se esegui il rollback alla versione ibrida 1.8.4 o precedente, elimina il deployment del controller utilizzato dalla versione ibrida 1.8.5 e successive:
```
kubectl -n apigee-system delete deploy apigee-controller-manager
```
6. Corsa apigeectl init:
```
$APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE
```
Elimina il deployment del gestore del gateway Ingress di Apigee. Questo componente è pertinente solo per Apigee hybrid versione 1.8 e successive.
```
kubectl delete deployment -n NAMESPACE apigee-ingress-gateway-manager
```
dove NAMESPACE è lo spazio dei nomi di Apigee hybrid.

Eseguire l'upgrade di Apigee hybrid alla versione 1.8 Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Introduzione al gateway in entrata Apigee

Panoramica dell'upgrade alla versione 1.8.8

Prerequisito

Prepararsi all'upgrade alla versione 1.8

Eseguire il backup dell'installazione ibrida (consigliato)

Linux

Mac OS

Windows

Aggiungi il ruolo Agente Cloud Trace all'account di servizio per il runtime Apigee. (Facoltativo)

Produzione

Non di produzione

Produzione

Non di produzione

Esempio

Prepararsi a installare il gateway in entrata Apigee

Sintassi

Esempio

Apporta ulteriori modifiche al file di override per attivare o disattivare le funzionalità facoltative della versione 1.8

Installa il runtime di hybrid 1.8.8

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Produzione

Non di produzione

Esegui l'upgrade della versione di Kubernetes

Fai clic per espandere l'elenco delle piattaforme supportate

Piattaforme

Componenti

Informazioni sui cluster collegati

Sposta il traffico da Anthos Service Mesh al gateway in entrata Apigee

Esegui l'upgrade di Anthos Service Mesh alla versione 1.15

GKE

Preparati all'upgrade di Anthos Service Mesh alla versione 1.17.8

Al di fuori di Google Cloud

Preparati all'upgrade di Anthos Service Mesh alla versione 1.17.8

AKS / EKS

Preparazione per l'installazione di Anthos Service Mesh

Linux

Mac OS

Windows

Installazione di Anthos Service Mesh

OpenShift

Preparazione per l'installazione di Anthos Service Mesh

Linux

Mac OS

Windows

Configura il webhook di convalida

Installazione di Anthos Service Mesh

Eseguire il rollback di un upgrade

Eseguire l'upgrade di Apigee hybrid alla versione 1.8