Questa pagina è stata tradotta dall'API Cloud Translation.

Upgrade di Apigee hybrid alla versione 1.8 in corso...

Nota: questa procedura riguarda l'upgrade da Apigee hybrid versione 1.7.x o dalle release precedenti della versione ibrida di Apigee Dalla versione 1.8.x alla versione ibrida di Apigee, 1.8.8.

Utilizza le stesse procedure per gli upgrade della versione secondaria (ad esempio versione 1.7) alla versione 1.8) e per gli upgrade delle release delle patch (ad esempio da 1.8.0 a 1.8.8).

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

Se utilizzi già la versione ibrida v1.8.0 e vuoi eseguire la migrazione Gateway Apigee in entrata di Anthos Service Mesh, consulta 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 la tua installazione ibrida, il gateway Apigee Ingress. Anthos Service Mesh non è più prerequisito per l'installazione ibrida. Con il gateway in entrata Apigee, Apigee smetterà di fornire il routing configurazione in Anthos Service Mesh. Dopo l'upgrade, devi eseguire la migrazione del traffico al nuovo gateway Apigee in entrata prima di poter iniziare a utilizzare la funzionalità.

Apigee utilizza un piccolo sottoinsieme di funzionalità Anthos Service Mesh per il gateway in entrata. A partire dalla versione ibrida 1.8, Apigee hybrid include un gateway in entrata che installato e sottoposto a upgrade nell'ambito degli upgrade ibridi di Apigee. Pertanto non è necessario per sviluppare competenze relative ad Anthos Service Mesh per installare, eseguire l'upgrade e gestire Apigee ibrido. Problemi sulle versioni del gateway in entrata e sulla compatibilità con Apigee hybrid le release vengono gestite automaticamente.

Gli scenari per la migrazione sono due:

Migrazione multi-cluster o multiregionale (consigliata):
Prima di passare a un nuovo Ingress per Apigee, svuota tutto il traffico su un altro cluster oppure regione dal cluster di cui stai eseguendo la migrazione. In questo modo avrai il tempo di verificare se la nuova Il gateway in entrata Apigee funziona come previsto. quindi sposta il traffico sulla piattaforma di cui è stato eseguito in un cluster Kubernetes.
Upgrade in loco (non consigliato negli ambienti di produzione):
Durante l'upgrade, Apigee visualizzerà il nuovo gateway in entrata con un indirizzo IP da te specificato. Puoi quindi verificare se il nuovo gateway in entrata Apigee funziona come previsto e quindi spostare il traffico verso il nuovo traffico in entrata. Durante l'upgrade potrebbero verificarsi tempi di inattività.

Quando esegui l'upgrade di Apigee hybrid alla versione 1.8, devi configurare Gateway Apigee in entrata nel file di override. Dopo l'upgrade, potrai controllare il tipo di traffico indirizzando i record A o CNAME del registrar all'indirizzo IP per il gateway Apigee in entrata o per Anthos Service Mesh.

Panoramica dell'aggiornamento alla versione 1.8.8

L'upgrade ad Apigee versione ibrida 1.8 potrebbe richiedere o un tempo di inattività.

Con l'upgrade del controller Apigee alla versione 1.8.8, tutte le istanze vengono sottoposti a un riavvio in sequenza. Per ridurre al minimo i tempi di inattività negli ambienti ibridi di produzione durante un riavvio in sequenza, assicurati di eseguire almeno due cluster (nello stesso in una regione/un data center differente). Deviare tutto il traffico di produzione in un unico cluster e utilizzare cluster di cui stai per eseguire l'upgrade offline, quindi procedi con il processo di upgrade. Ripeti il processo per ogni cluster.

Apigee consiglia di eseguire l'upgrade di tutti i cluster il prima possibile per ridurre le probabilità dell'impatto sulla produzione. Non è previsto alcun limite di tempo per il quale deve essere eseguito l'upgrade di tutti i cluster rimanenti dopo l'upgrade della prima. Tuttavia, fino a quando non sarà stato eseguito l'upgrade di tutti i cluster rimanenti, operazioni successive saranno interessate:

Il backup e il ripristino di Cassandra non funzionano con le versioni miste. Ad esempio, un backup da Hybrid 1.7 non può essere utilizzato per ripristinare 1.8.
I flussi di dati Cassandra non funzionano tra versioni ibride miste. Pertanto, I cluster Cassandra non possono scalare orizzontalmente.
Saranno interessate l'espansione e il ritiro delle regioni, in quanto queste operazioni dipendono Flusso di dati di Cassandra.

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

Prepara l'upgrade.
Installa il runtime ibrido versione 1.8.8.
Per il gateway in entrata, scegli una delle seguenti opzioni:
- (Consigliato) Usa il nuovo gateway Apigee in entrata, segui i passaggi Cambia il traffico da Anthos Service Mesh al gateway in entrata Apigee.
- Continua a utilizzare Anthos Service Mesh per il gateway in entrata.

Prerequisito

Queste istruzioni per l'upgrade presuppongono che la versione ibrida di Apigee sia 1.7.x o una patch release precedente della versione 1.8.x installata e si desidera aggiornarlo alla versione 1.8.8. Se esegui l'aggiornamento da una versione precedente consulta le istruzioni per Eseguire l'upgrade Apigee hybrid alla versione 1.7.

Se preferisci continuare a utilizzare Anthos Service Mesh, devi assicurarti che venga eseguito l'upgrade di Anthos Service Mesh a un ambiente completamente gestita. Consulta la tabella Piattaforme supportate per conoscere le piattaforme supportate. di Anthos Service Mesh.

Prepara l'upgrade alla versione 1.8

Esegui il backup dell'installazione ibrida (opzione consigliata)

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 della versione 1.7 $APIGEECTL_HOME/. Ad esempio:
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.7-backup.tar.gz $APIGEECTL_HOME
```
Esegui il backup del tuo database Cassandra seguendo le istruzioni in Backup e recupero 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 sull'installazione ibrida v1.7, assicurati che il servizio per i tuoi servizi di runtime Apigee abbia il ruolo Google Agente Cloud Trace. (roles/cloudtrace.agent)

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

Puoi aggiungere il ruolo nel Console Cloud > IAM e Amministratore > UI account di servizio o con i seguenti comandi:

Recupera 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 usare questo pattern 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 usare questo pattern nel passaggio successivo.

Assegna il ruolo Agente Cloud Trace all'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 l'account di servizio, sostituisci apigee-runtime o apigee-non-prod nel nome .

Preparati a installare il gateway in entrata Apigee

Per installare il gateway in entrata Apigee nell'ambito dell'upgrade. Devi aggiungere il parametro seguo ingressGateways al file degli 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 in entrata. Può essere qualsiasi nome che soddisfi le i seguenti requisiti:
- Avere una lunghezza massima di 17 caratteri
- Contenere solo caratteri alfanumerici minuscoli, "-" o "."
- Inizia con un carattere alfanumerico
- Termina con un carattere alfanumerico
Vedi ingressGateways[].name nel riferimento della proprietà di configurazione
REPLICAS_MIN e REPLICAS_MAX sono il numero minimo e massimo di repliche per il gateway in entrata Apigee nella tua installazione. Per ulteriori informazioni e impostazioni predefinite, vedi ingressGateways[].replicaCountMin e ingressGateways[].replicaCountMax nel riferimento della proprietà Configurazione.
CPU_COUNT_REQ e MEMORY_REQ sono le richieste di CPU e memoria per ogni del gateway Apigee in entrata nella tua installazione.
Imposta queste proprietà solo se le hai precedentemente impostate per i tuoi 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 della proprietà di configurazione.
CPU_COUNT_LIMIT e MEMORY_LIMIT I limiti massimi di CPU e memoria per ogni replica del gateway Apigee in entrata nella tua installazione.
Imposta queste proprietà solo se le hai precedentemente impostate per i tuoi 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 della proprietà di configurazione.
SVC_ANNOTATIONS_KEY e SVC_ANNOTATIONS_VALUE (facoltativo):
Nota: il campo ingressGateways[].svcAnnotations in overrides.yaml non funziona come previsto. Consulta Problema noto: 243599452

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

Nota: non è necessario impostare Annotations se ne stai creando uno personalizzato Servizio Kubernetes per il deployment in entrata come documentato in Esponi il gateway in entrata Apigee.
di Gemini Advanced. Vedi ingressGateways[].svcAnnotations nel riferimento della proprietà di configurazione.
SVC_LOAD_BALANCER_IP (facoltativo) ti consente di assegnare un indirizzo IP statico per il tuo con il bilanciatore del carico di rete passthrough esterno regionale. Sulle piattaforme che supportano la specifica dell'indirizzo IP del bilanciatore del carico, verrà creato con questo indirizzo IP. Sulle piattaforme che non consentono di specificare indirizzo IP del bilanciatore del carico, questa proprietà viene ignorata.
Se non hai un indirizzo IP statico allocato per il bilanciatore del carico, esci da questa proprietà dal file di override.

Attenzione:assicurati di non specificare lo stesso indirizzo IP dell'attuale gateway istio in entrata. Ciò potrebbe causare problemi mentre il servizio è ancora nel cluster.
di Gemini Advanced.
Nota: non è necessario impostare LoadBalancerIP se ne stai creando una personalizzata Servizio Kubernetes per il deployment in entrata come documentato in Esponi il gateway in entrata Apigee.
di Gemini Advanced. Consulta ingressGateways[].svcLoadBalancerIP nella documentazione di riferimento delle proprietà di configurazione.

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

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

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

Apigee hybrid v 1.8 supporta UDCA con ambito a livello di ambiente. Per mantenere l'UDCA per ambiente, imposta orgScopedUDCA: false.

Nota: il supporto per le funzioni definite dall'utente con ambito a livello di ambiente non sarà disponibile nelle versioni future delle Apigee hybrid.

Vedi orgScopedUDCA nella sezione Configurazione. di riferimento delle proprietà.
Abilita validateOrg per richiedere una verifica rigorosa del fatto che l'organizzazione Apigee e sono attivi e funzionano con il progetto Google Cloud Platform specificato overrides file.
```
validateOrg: true
```
Nota: Apigee hybrid supporta non utilizzare la convalida rigorosa dell'organizzazione. A disattiva la funzionalità, imposta validateOrg: false.

Vedi validateOrg nella sezione Configurazione proprietà di riferimento.

Installazione del runtime ibrido 1.8.8

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

Scarica il pacchetto di release 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 della 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 il contenuto 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 tar vengono espansi in una directory con la versione e la piattaforma in il nome. Ad esempio: ./apigeectl_1.8.8-xxxxxxx_linux_64. Rinomina la directory a 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 è la home directory apigeectl. È dove dove si trova il 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. hybrid-files è la directory in cui i file di configurazione, come file di override, certificati e account di servizio, in cui si trovano. 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 stai eseguendo 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 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 collegamenti simbolici siano stati creati correttamente, esegui questo comando ed esegui assicurati che i percorsi dei link indirizzino alle posizioni corrette:
```
ls -l | grep ^l
```
Esegui un'inizializzazione dry run 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 nel codice esempio riportato sopra con il nome e il percorso del file degli override e di ogni istanza in questa pagina verrà sostituito.
Se non ci sono errori, inizializzare ibrido 1.8.8. Questo comando inoltre installa e configura 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'esito è positivo, l'output dice: All containers ready.

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

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

Per gli ambienti di produzione dovresti eseguire l'upgrade di ogni componente ibrido individualmente, e controlla lo stato del componente di cui è stato eseguito l'upgrade prima di passare al componente successivo.
1. Assicurati di essere nella directory hybrid-files.
2. Applica gli override per eseguire l'upgrade di Cassandra:
```
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
```
3. Verifica di completamento:
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```
  Suggerimento: se check-ready non va a buon fine, puoi ricevere più informazioni sui tuoi pod con:
  kubectl -n NAMESPACE get pods
  
  Dove NAMESPACE è il tuo spazio dei nomi ibrido Apigee.
  Procedi al passaggio successivo solo quando i pod sono pronti.
4. Applica gli override per eseguire l'upgrade dei componenti di telemetria e verificare il completamento:
```
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
```
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```
5. Visualizza 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) connettiti) 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 a disposizione due opzioni:
  - Ambiente per ambiente: applica gli override a un ambiente alla volta e controlla 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 esegui 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 verificare 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 è grande e complesso che imitano da vicino un ambiente di produzione, ti consigliamo di utilizzare le istruzioni per l'upgrade degli ambienti di produzione.
1. Assicurati di essere 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 tua piattaforma Kubernetes alle versioni supportate da hybrid 1.8. Se hai bisogno di assistenza, segui la documentazione della piattaforma.

Fai clic per espandere un elenco di piattaforme supportate

	Versioni ibride di Apigee
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
ApriMaiusc⁽⁷⁾	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/A	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,14x 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
⁽¹⁾ Su Anthos versioni 1.8, 1.9 e 1.10, segui le istruzioni in questi documenti per evitare conflitti con `cert-manager`: Anthos 1.8.2 e versioni successive: Conflitto con `cert-manager` durante l'upgrade alla versione 1.8.2 o successiva. Anthos 1.9: Conflitto con `cert-manager` durante l'upgrade alla versione 1.9.0 o 1.9.1. Anthos 1.10 e versioni successive: Installazione di `cert-manager` in conflitto. ⁽²⁾ Assistenza disponibile con Apigee ibrido versione 1.7.2 e successive. ⁽³⁾ Le date EOL ufficiali per Apigee hybrid sono state raggiunte le versioni 1.8 e precedenti. Le normali patch mensili non sono più disponibili. Queste release non sono più supportate ufficialmente, ad eccezione di i clienti con eccezioni esplicite e ufficiali per assistenza in tempo reale. Gli altri clienti devono eseguire l'upgrade. ⁽⁴⁾Anthos su Bare Metal e VMWare le versioni 1.12 e precedenti non sono più supportate. Consulta le i criteri relativi all'assistenza per la versione Anthos on Bare Metal e . Cluster Anthos su VMware VMware. ⁽⁵⁾Anthos su Bare Metal e VMWare richiede ASM 1.14 o versioni successive. Ti consigliamo di eseguire l'upgrade a ibrido v1.8 e passaggio al gateway Apigee in entrata, che non è più richiede l'installazione di ASM sul cluster ibrido. ⁽⁶⁾ Assistenza disponibile con Apigee ibrido versione 1.8.4 e successive. ⁽⁷⁾ I cluster collegati non sono necessari per Apigee hybrid v1.8 e più recenti con Gateway in entrata Apigee. ⁽⁸⁾ Non supportato con Apigee ibrido versione 1.8.4 e successive. ⁽⁹⁾ Assistenza disponibile con Apigee ibrido 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. ⁽¹²⁾ Assistenza disponibile con Apigee hybrid versione 1.9.2 e successive. ⁽¹³⁾ Numeri di versione di Cluster Anthos on AWS (multi-cloud) ora tutte le versioni di Kubernetes. Consulta Anthos il supporto della versione e dell'upgrade per i dettagli della versione e le patch consigliate.

Informazioni sui cluster collegati

Per le versioni ibride di Apigee 1.7.x e precedenti, devi utilizzare Anthos allegato se vuoi eseguire Apigee hybrid in un contesto multi-cloud su Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) o un altro servizio Kubernetes di terze parti supportato o il provider di servizi di terze parti. Il collegamento al cluster consente a Google di misurare l'utilizzo di Anthos Service Mesh (ASM). Registrazione il cluster di terze parti è facoltativo. Registrati solo se vuoi visualizzare il cluster collegato nell' nella console Google Cloud. Per ulteriori informazioni, vedi Allegare cluster Kubernetes di terze parti a Google Cloud.

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

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

Per trasferire il traffico al gateway in entrata Apigee:

Esporre il gateway in entrata Apigee. Segui le procedure in Esponi il gateway in entrata Apigee.
Testa il nuovo gateway in entrata chiamando un proxy. Idealmente, testa tutti i proxy cruciali di cui hai eseguito il deployment.
Per cambiare il traffico, aggiorna i record DNS in modo che puntino all'indirizzo IP del nuovo gateway in entrata Apigee. A seconda del tuo provider DNS, potresti essere in grado di spostare gradualmente il traffico sul nuovo endpoint.
Suggerimento : puoi trovare l'indirizzo IP esterno del gateway Apigee in entrata con il seguente comando:
```
kubectl get svc -n apigee -l app=apigee-ingressgateway
```
L'output dovrebbe essere simile al seguente:
```
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 del runtime funzioni monitorando le tue dashboard. Procedi solo con la successiva passaggio se tutto funziona come previsto. Assicurati che non ci sia traffico lungo il vecchio gateway in entrata (Anthos Service Mesh), poiché l'aggiornamento del DNS può essere lento a propagarsi a causa della memorizzazione nella cache del DNS.
Per interrompere la fornitura della configurazione ad Anthos Service Mesh da parte di Apigee, segui i passaggi descritti in Interrompi l'invio della configurazione ad ASM in la guida alla gestione del gateway in entrata Apigee.
Ripeti il test e monitora il traffico del proxy API.
Segui le istruzioni nella documentazione di Anthos Service Mesh per Disinstalla Anthos Service Mesh da nel cluster.

Esegui l'upgrade di Anthos Service Mesh alla versione 1.15

di Gemini Advanced.

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. La piattaforme sono suddivise nelle seguenti categorie:

GKE: cluster di Google Kubernetes Engine in esecuzione su Google Cloud.
All'esterno di Google Cloud: cluster Anthos in esecuzione su:
- Cluster Anthos su VMware (GKE On-Prem)
- Anthos su Bare Metal
- Cluster Anthos su AWS
- Amazon EKS
Altre piattaforme Kubernetes: cluster conformi creati e in esecuzione su:
- AKS
- EKS
- OpenShift

GKE

La sequenza per eseguire l'upgrade alla versione di Anthos Service Mesh 1.13.9 per il tuo modello ibrido l'installazione è la seguente:

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

Prepara l'upgrade di Anthos Service Mesh alla versione 1.13.9

Esamina i requisiti in Eseguire l'upgrade di Anthos Service Mesh, ma non eseguire ancora l'upgrade.
Prima di installare la nuova versione, determina la revisione corrente. Ti serviranno queste informazioni per eliminare i deployment, i servizi e i webhook dalla tua installazione attuale. Utilizza il seguente comando per archiviare revisione istiod corrente a 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.12.9-asm.2

Nota: se il comando restituisce più valori, imposta il valore valore DELETE_REV alla versione meno recente e segui la procedura per eliminare la versione meno recente, quindi ripetere la procedura finché non e versioni successive.

Crea un nuovo file overlay.yaml o verifica che gli asset esistenti overlay.yaml include 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 seguenti sezioni 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 il tuo overlay.yaml.
1. Scarica asmcli
2. Concedi autorizzazioni di amministratore del cluster
3. Convalida progetto e cluster
4. Upgrade con funzionalità facoltative. Interrompi prima di avviare la sezione "Esegui l'upgrade dei gateway".
Passa al nuovo piano di controllo:
1. Scarica l'etichetta di revisione in 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-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. Assegna l'etichetta di revisione più recente a una variabile di ambiente.
  Nell'output, sotto la colonna REV, annota il valore della revisione l'etichetta per la nuova versione. In questo esempio, il valore è asm-1139-10
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Aggiungi l'etichetta di revisione allo spazio dei nomi istio-system e rimuovi lo Etichetta istio-injection (se esistente) con il seguente comando.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Se vedi "istio-injection not found" nell'output, puoi ignoralo. Ciò significa che in precedenza lo spazio dei nomi non aveva Etichetta istio-injection. Poiché l'inserimento automatico non va a buon fine se include sia l'etichetta di revisione istio-injection sia l'etichetta di revisione, tutti i comandi kubectl label in Anthos Service Mesh documentazione relativa alla 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.
Archivia la directory di output per l'installazione di Anthos Service Mesh nel Variabile di ambiente DIR_PATH. Questa è la stessa directory in cui specificato nel Upgrade con le caratteristiche 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 su Bare Metal
Cluster Anthos su AWS
Amazon EKS

La sequenza per eseguire l'upgrade alla versione di Anthos Service Mesh 1.13.9 per il tuo modello ibrido l'installazione è la seguente:

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

Prepara l'upgrade di Anthos Service Mesh alla versione 1.13.9

Esamina i requisiti in Eseguire l'upgrade di Anthos Service Mesh, ma non eseguire ancora l'upgrade.
Prima di installare la nuova versione, determina la revisione corrente. Ti serviranno queste informazioni per eliminare i deployment, i servizi e i servizi della versione precedente di Anthos Service Mesh i webhook dalla tua installazione attuale. Utilizza il seguente comando per archiviare revisione istiod corrente a 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.12.9-asm.2

Nota: se il comando restituisce più valori, imposta il valore valore DELETE_REV alla versione meno recente e segui la procedura per eliminare la versione meno recente, quindi ripetere la procedura finché non e versioni successive.

Crea un nuovo file overlay.yaml o verifica che gli asset esistenti overlay.yaml include 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 seguenti sezioni 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 il tuo overlay.yaml.
1. Scarica asmcli
2. Concedi autorizzazioni di amministratore del cluster
3. Convalida progetto e cluster
4. Upgrade con funzionalità facoltative. Interrompi prima di avviare la sezione "Esegui l'upgrade dei gateway".
Passa al nuovo piano di controllo:
1. Scarica l'etichetta di revisione in 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-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. Assegna l'etichetta di revisione più recente a una variabile di ambiente.
  Nell'output, sotto la colonna REV, annota il valore della revisione l'etichetta per la nuova versione. In questo esempio, il valore è asm-1139-10
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Aggiungi l'etichetta di revisione allo spazio dei nomi istio-system e rimuovi lo Etichetta istio-injection (se esistente) con il seguente comando.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Se vedi "istio-injection not found" nell'output, puoi ignoralo. Ciò significa che in precedenza lo spazio dei nomi non aveva Etichetta istio-injection. Poiché l'inserimento automatico non va a buon fine se include sia l'etichetta di revisione istio-injection sia l'etichetta di revisione, tutti i comandi kubectl label in Anthos Service Mesh documentazione relativa alla 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.
Archivia la directory di output per l'installazione di Anthos Service Mesh nel Variabile di ambiente DIR_PATH. Questa è la stessa directory in cui specificato nel Upgrade con le caratteristiche 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 viene spiegato come eseguire l'upgrade della versione Anthos Service Mesh (Anthos Service Mesh). istio-1.13.9-asm.10 su cluster collegati ad Anthos è la stessa cosa che eseguire una nuova installazione.

Preparazione dell'installazione di Anthos Service Mesh

Prima di installare la nuova versione, determina la revisione corrente. Ti serviranno queste informazioni per eliminare il webhook di convalida e il webhook mutante. dalla tua attuale installazione di Anthos Service Mesh. Utilizza il seguente comando per archiviare l'oggetto istiod revisione 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.12.9-asm.2

Nota: se il comando restituisce più valori, imposta il valore valore DELETE_REV alla versione meno recente e segui la procedura per eliminare la versione meno recente, quindi ripetere la procedura finché non e versioni successive.

Linux

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

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz

Scarica il file della firma e usa OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig

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

Estrai i contenuti del file in qualsiasi posizione nel tuo file system. Ad esempio: per estrarre il contenuto della directory di lavoro corrente:

tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

Il comando crea una directory di installazione nella directory di lavoro corrente denominata istio-1.13.9-asm.10 che contiene:

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

Assicurati di essere nella directory root dell'installazione di Anthos Service Mesh:

cd istio-1.13.9-asm.10

Per praticità, aggiungi gli strumenti della directory /bin a PATH:

export PATH=$PWD/bin:$PATH

Mac OS

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

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz

Scarica il file della firma e usa OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig

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

Estrai i contenuti del file in qualsiasi posizione nel tuo file system. Ad esempio: per estrarre il contenuto della directory di lavoro corrente:

tar xzf istio-1.13.9-asm.10-osx.tar.gz

Il comando crea una directory di installazione nella directory di lavoro corrente denominata istio-1.13.9-asm.10 che contiene:

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

Assicurati di essere nella directory root dell'installazione di Anthos Service Mesh:

cd istio-1.13.9-asm.10

Per praticità, aggiungi gli strumenti della directory /bin a PATH:

export PATH=$PWD/bin:$PATH

Windows

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

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip

Scarica il file della firma e usa OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig

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

Estrai i contenuti del file in qualsiasi posizione nel tuo file system. Ad esempio: per estrarre il contenuto della directory di lavoro corrente:

tar xzf istio-1.13.9-asm.10-win.zip

Il comando crea una directory di installazione nella directory di lavoro corrente denominata istio-1.13.9-asm.10 che contiene:

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

Assicurati di essere nella directory root dell'installazione di Anthos Service Mesh:

cd istio-1.13.9-asm.10

Per praticità, aggiungi gli strumenti della 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 piano di controllo:
```
kubectl create namespace istio-system
```

Installazione di Anthos Service Mesh

Modifica il tuo 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-1139-10" \
    --filename overlay.yaml
```
L'output dovrebbe essere simile al seguente:
```
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-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s
```
L'argomento --set revision aggiunge un'etichetta di revisione nel formato istio.io/rev=asm-1139-10 a istiod. L'etichetta di revisione viene utilizzata webhook di inserimento del file collaterale automatico per associare i file collaterali inseriti a un determinato istiod revisione. Per abilitare l'inserimento automatico del file collaterale per uno spazio dei nomi, devi etichettarlo con una revisione che corrisponde all'etichetta su istiod.

Verifica che l'installazione sia stata completata:

kubectl get svc -n istio-system

L'output dovrebbe essere simile al seguente:

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-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

Passa al nuovo piano di controllo:
1. Scarica l'etichetta di revisione in 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-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. Assegna l'etichetta di revisione più recente a una variabile di ambiente.
  Nell'output, sotto la colonna REV, annota il valore della revisione l'etichetta per la nuova versione. In questo esempio, il valore è asm-1139-10
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Aggiungi l'etichetta di revisione allo spazio dei nomi istio-system e rimuovi lo Etichetta istio-injection (se esistente) con il seguente comando.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Se vedi "istio-injection not found" nell'output, puoi ignoralo. Ciò significa che in precedenza lo spazio dei nomi non aveva Etichetta istio-injection. Poiché l'inserimento automatico non va a buon fine se include sia l'etichetta di revisione istio-injection sia l'etichetta di revisione, tutti i comandi kubectl label in Anthos Service Mesh documentazione relativa alla 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

Preparazione dell'installazione di Anthos Service Mesh

Prima di installare la nuova versione, determina la revisione corrente. Ti serviranno queste informazioni per eliminare il webhook di convalida e il webhook mutante. dalla tua attuale installazione di Anthos Service Mesh. Utilizza il seguente comando per archiviare l'oggetto istiod revisione 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.12.9-asm.2

Nota: se il comando restituisce più valori, imposta il valore valore DELETE_REV alla versione meno recente e segui la procedura per eliminare la versione meno recente, quindi ripetere la procedura finché non e versioni successive.

Linux

Concedi il vincolo di contesto di sicurezza (SCC) anyuid al sistema istio con il seguente comando OpenShift CLI (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 attuale:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz

Scarica il file della firma e usa OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig

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

Estrai i contenuti del file in qualsiasi posizione nel tuo file system. Ad esempio: per estrarre il contenuto della directory di lavoro corrente:

tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz

Il comando crea una directory di installazione nella directory di lavoro corrente denominata istio-1.13.9-asm.10 che contiene:

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

Assicurati di essere nella directory root dell'installazione di Anthos Service Mesh:

cd istio-1.13.9-asm.10

Per praticità, aggiungi gli strumenti della directory /bin a PATH:

export PATH=$PWD/bin:$PATH

Mac OS

Concedi il vincolo di contesto di sicurezza (SCC) anyuid al sistema istio con il seguente comando OpenShift CLI (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 attuale:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz

Scarica il file della firma e usa OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig

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

Estrai i contenuti del file in qualsiasi posizione nel tuo file system. Ad esempio: per estrarre il contenuto della directory di lavoro corrente:

tar xzf istio-1.13.9-asm.10-osx.tar.gz

Il comando crea una directory di installazione nella directory di lavoro corrente denominata istio-1.13.9-asm.10 che contiene:

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

Assicurati di essere nella directory root dell'installazione di Anthos Service Mesh:

cd istio-1.13.9-asm.10

Per praticità, aggiungi gli strumenti della directory /bin a PATH:

export PATH=$PWD/bin:$PATH

Windows

Concedi il vincolo di contesto di sicurezza (SCC) anyuid al sistema istio con il seguente comando OpenShift CLI (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 attuale:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip

Scarica il file della firma e usa OpenSSL per verificarla:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig

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

Estrai i contenuti del file in qualsiasi posizione nel tuo file system. Ad esempio: per estrarre il contenuto della directory di lavoro corrente:

tar xzf istio-1.13.9-asm.10-win.zip

Il comando crea una directory di installazione nella directory di lavoro corrente denominata istio-1.13.9-asm.10 che contiene:

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

Assicurati di essere nella directory root dell'installazione di Anthos Service Mesh:

cd istio-1.13.9-asm.10

Per praticità, aggiungi gli strumenti della 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 piano di controllo:
```
kubectl create namespace istio-system
```

Configura il webhook di convalida

Quando installi Anthos Service Mesh, imposti un'etichetta di revisione su istiod. Devi impostare lo stesso 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-1139-10
    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-1139-10
  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 di convalida del webhook:
```
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 tuo 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-1139-10" \
    --filename overlayfile.yaml
```
L'output dovrebbe essere simile al seguente:
```
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-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1139-10-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 webhook di inserimento del file collaterale automatico per associare i file collaterali inseriti a un determinato istiod revisione. Per abilitare l'inserimento automatico del file collaterale per uno spazio dei nomi, devi etichettarlo con una revisione che corrisponde all'etichetta su istiod.

Verifica che l'installazione sia stata completata:

kubectl get svc -n istio-system

L'output dovrebbe essere simile al seguente:

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-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

Passa al nuovo piano di controllo:
1. Scarica l'etichetta di revisione in 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-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. Assegna l'etichetta di revisione più recente a una variabile di ambiente.
  Nell'output, sotto la colonna REV, annota il valore della revisione l'etichetta per la nuova versione. In questo esempio, il valore è asm-1139-10
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Aggiungi l'etichetta di revisione allo spazio dei nomi istio-system e rimuovi lo Etichetta istio-injection (se esistente) con il seguente comando.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Se vedi "istio-injection not found" nell'output, puoi ignoralo. Ciò significa che in precedenza lo spazio dei nomi non aveva Etichetta istio-injection. Poiché l'inserimento automatico non va a buon fine se include sia l'etichetta di revisione istio-injection sia l'etichetta di revisione, tutti i comandi kubectl label in Anthos Service Mesh documentazione relativa alla 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.

di Gemini Advanced.

Rollback di un upgrade in corso...

Per eseguire il rollback di un upgrade precedente:

Esegui la pulizia dei job completati per lo spazio dei nomi del runtime ibrido, dove NAMESPACE è specificato nel file degli override, se hai specificato uno spazio dei nomi. 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}')
```

Esegui la pulizia dei 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 precedente di apigeectl. Ad esempio:
```
export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
```
Annulla le modifiche al file overrides:
1. Rimuovi o commenta ingressGateways e tutte le sue 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 root dell'installazione di cui vuoi eseguire il rollback, apigeectl apply, controlla lo stato dei pod ed esegui apigeectl init. Assicurati di utilizzare il file di override originale per la versione vuoi eseguire il rollback a:
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 file degli override per l'installazione ibrida precedente, ad esempio: ./overrides/overrides1.7.yaml.
2. Controlla lo stato dei tuoi pod:
```
kubectl -n NAMESPACE get pods
```
  Dove NAMESPACE è il tuo spazio dei nomi ibrido Apigee.
3. Controlla lo stato di apigeeds:
```
kubectl describe apigeeds -n apigee
```
  L'output dovrebbe essere simile al seguente:
```
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 questo comando per prendere nota dei nuovi valori del conteggio delle repliche processore di messaggi dopo l'upgrade.Se questi valori non corrispondono a quanto in precedenza, modifica i valori nel file delle sostituzioni affinché corrispondano ai valori configurazione.
```
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 al seguente:
```
      autoScaler:
        minReplicas: 2
        maxReplicas: 10
```
5. Se stai eseguendo il rollback alla versione ibrida v1.8.4 o precedente, elimina il deployment del controller utilizzato con hybrid v1.8.5 e versioni successive:
```
kubectl -n apigee-system delete deploy apigee-controller-manager
```
6. Corsa di apigeectl init:
```
$APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE
```
Elimina il deployment del gestore gateway in entrata di Apigee. Questo componente è rilevante solo per Apigee hybrid versione 1.8 e successive.
```
kubectl delete deployment -n NAMESPACE apigee-ingress-gateway-manager
```
Dove NAMESPACE è il tuo spazio dei nomi ibrido Apigee.

Upgrade di Apigee hybrid alla versione 1.8 in corso...

Introduzione al gateway in entrata Apigee

Panoramica dell'aggiornamento alla versione 1.8.8

Prerequisito

Prepara l'upgrade alla versione 1.8

Esegui il backup dell'installazione ibrida (opzione consigliata)

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

Preparati a installare il gateway in entrata Apigee

Sintassi

Esempio

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

Installazione del runtime ibrido 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 un elenco di piattaforme supportate

Piattaforme

Componenti

Informazioni sui cluster collegati

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

Esegui l'upgrade di Anthos Service Mesh alla versione 1.15

GKE

Prepara l'upgrade di Anthos Service Mesh alla versione 1.13.9

Al di fuori di Google Cloud

Prepara l'upgrade di Anthos Service Mesh alla versione 1.13.9

AKS / EKS

Preparazione dell'installazione di Anthos Service Mesh

Linux

Mac OS

Windows

Installazione di Anthos Service Mesh

OpenShift

Preparazione dell'installazione di Anthos Service Mesh

Linux

Mac OS

Windows

Configura il webhook di convalida

Installazione di Anthos Service Mesh

Rollback di un upgrade in corso...