Eseguire l'upgrade di Apigee hybrid alla versione 1.12

Questa procedura riguarda l'upgrade dalla versione 1.11.x di Apigee hybrid alla versione 1.12.2 di Apigee hybrid.

Modifiche rispetto alla versione 1.11 di Apigee hybrid

La versione 1.12 di Apigee hybrid introduce le seguenti modifiche che influiscono sul processo di upgrade. Per un elenco completo delle funzionalità della versione 1.12 vedi il Note di rilascio ibrida v1.12.0.

  • Cassandra 4.x: a partire dalla versione 1.12, Apigee Hybrid utilizza Cassandra versione 4 e successive.
  • apigeectl Ritiro: a partire dalla versione 1.12, Apigee hybrid supporta solo Helm per l'installazione e la gestione dell'installazione ibrida.
  • È ora disponibile una nuova suite di metriche per il monitoraggio dei proxy e degli endpoint di destinazione Apigee. Per la versione ibrida 1.12, le risorse monitorate ProxyV2 e TargetV2 non saranno più in uso per impostazione predefinita. Tutte le metriche del proxy e di destinazione verranno pubblicate in Proxy e Target risorse monitorate.

    Per continuare a emettere metriche per le risorse monitorate ProxyV2 e TargetV2, imposta metrics.disablePrometheusPipeline su true in overrides.yaml.

    Se hai configurato avvisi basati su metriche, verifica di utilizzare le metriche corrette per l'installazione ibrida. Per ulteriori informazioni, consulta Avvisi basati sulle metriche.

Considerazioni prima di iniziare un upgrade alla versione 1.12

L'upgrade da Apigee ibrido dalla versione 1.11 alla versione 1.12 include un upgrade di Cassandra dalla versione 3.11.x alla versione 4.x. L'upgrade di Cassandra è gestito nell'ambito La procedura di upgrade ibrido di Apigee, prepara le seguenti considerazioni:

  • L'upgrade della versione di Cassandra verrà eseguito in background e su un pod (o un nodo Cassandra) alla volta, quindi pianifica una capacità ridotta del database durante l'upgrade.
  • Scala la capacità di Cassandra e assicurati che l'utilizzo del disco sia vicino o inferiore al 50% prima di iniziare l'upgrade.
  • Convalida e testa le procedure di backup e ripristino di Cassandra.
  • Esegui il backup dei dati di Cassandra nell'installazione ibrida della versione 1.11 prima di iniziare l'upgrade e convalida i backup.
  • L'upgrade di apigee-datastore comporterà un aumento temporaneo del consumo della CPU a causa delle attività di post-upgrade eseguite da Cassandra
  • Una volta eseguito l'upgrade del componente apigee-datastore (Cassandra), non potrai eseguire il rollback del componente alla versione precedente. Esistono due scenari per eseguire il rollback di un upgrade alla versione 1.12 ibrida dopo l'upgrade del componente apigee-datastore:
    • Se il componente apigee-datastore è in buono stato, ma gli altri componenti non è necessario eseguire il rollback, puoi eseguirne il rollback singolarmente agli altri componenti.
    • Se il componente apigee-datastore è in uno stato non valido, devi eseguire il ripristino da un backup della versione 1.11 in un'installazione della versione 1.11.

Considerazioni prima di eseguire l'upgrade di un'installazione in una singola regione

Se devi eseguire il rollback a una versione precedente di Apigee Hybrid, la procedura potrebbe richiedere un tempo di riposo. Pertanto, se stai eseguendo l'upgrade di un'installazione con una sola regione, ti consigliamo di creare una seconda regione ed eseguire l'upgrade di una sola regione alla volta nella seguente sequenza:

  1. Aggiungi una seconda regione all'installazione esistente utilizzando la stessa versione ibrida. Consulta Deployment in più regioni nella documentazione della versione 1.11.
  2. Esegui il backup e convalida i dati della prima regione prima di iniziare un upgrade. Consulta: Cassandra Panoramica del backup nella documentazione della versione 1.11.
  3. Esegui l'upgrade della regione appena aggiunta alla versione ibrida 1.12.
  4. Sposta il traffico nella nuova regione e convalidalo.
  5. Una volta convalidata, esegui l'upgrade della regione precedente con la versione ibrida 1.12.
  6. Ripristina tutto il traffico nella regione precedente e convalidalo.
  7. Esegui la dismissione della nuova regione.

Considerazioni prima di eseguire l'upgrade di un'installazione multi-regione

Apigee consiglia la seguente sequenza per l'upgrade di un'installazione multiregionale:

  1. Esegui il backup e convalida i dati di ogni regione prima di iniziare l'upgrade.
  2. Esegui l'upgrade della versione ibrida in una regione e assicurati che tutti i pod siano in stato di esecuzione per convalidare l'upgrade.
  3. Convalida il traffico nella regione di cui è stato eseguito l'upgrade.
  4. Esegui l'upgrade di ogni regione successiva solo dopo aver convalidato il traffico nella regione precedente.
  5. Se c'è la necessità di eseguire il rollback di un upgrade in un deployment multiregionale, per allontanare il traffico dalle regioni con errori, valuta la possibilità di aggiungere capacità sufficiente nella regione in cui il traffico verrà per gestire il traffico in entrambe le regioni.

Prerequisiti

Prima di eseguire l'upgrade alla versione ibrida 1.12, assicurati che la tua installazione soddisfi i seguenti requisiti:

Limitazioni

Tieni presente le seguenti limitazioni quando pianifichi l'upgrade dalla versione ibrida di Apigee Dalla versione 1.11 alla versione 1.12. La pianificazione può contribuire a ridurre la necessità di tempi di inattività se devi eseguire il rollback o il ripristino dopo l'upgrade.

  • Impossibile ripristinare i backup dalla versione ibrida 1.12 nella versione ibrida 1.11 e viceversa a causa incompatibilità tra le due versioni.
  • Non puoi scalare i pod del datastore durante l'upgrade alla versione 1.12. Soddisfa le tue esigenze di scalabilità in tutte le regioni prima di iniziare l'upgrade dell'installazione ibrida.
  • In un'installazione ibrida a regione singola, non puoi eseguire il rollback del componente Datastore una volta Il processo di upgrade del datastore è terminato. Non puoi eseguire il rollback di un datastore Cassandra 4.x a un Datastore Cassandra 3.x. Sarà necessario ripristinare il backup più recente del Dati di Cassandra 3.x (dall'installazione ibrida della versione 1.11).
  • L'eliminazione o l'aggiunta di una regione non è supportata durante l'upgrade. In un upgrade multiregione, devi completare l'upgrade di tutte le regioni prima di poter aggiungere o eliminare regioni.

Panoramica dell'aggiornamento alla versione 1.12.2

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

  1. Prepara l'upgrade.
    • Esegui il backup di Cassandra.
    • Esegui il backup delle directory di installazione ibrida.
  2. Installa il runtime di hybrid versione 1.12.2.

Prepararsi all'upgrade alla versione 1.12

Esegui il backup di Cassandra

  • Esegui il backup del tuo database Cassandra in tutte le regioni applicabili e convalida i dati dell'installazione ibrida della versione 1.11 prima di iniziare l'upgrade. Consulta Monitoraggio dei backup nella documentazione della versione 1.11.
  • Riavviare tutti i pod Cassandra nel cluster prima di avviare la procedura di upgrade, in modo che eventuali problemi in sospeso possano emergere.

    Per riavviare e testare i pod Cassandra, elimina ogni pod singolarmente, un pod alla volta, quindi verifica che sia nuovamente in esecuzione e che il probe di idoneità superi l'esito:

    1. Elenca i pod Cassandra:
      kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

      Ad esempio:

      kubectl get pods -n apigee -l app=apigee-cassandra
      NAME                         READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          2h
      apigee-cassandra-default-1   1/1     Running   0          2h
      apigee-cassandra-default-2   1/1     Running   0          2h
      
      . . .
    2. Elimina un pod:
      kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME

      Ad esempio:

      kubectl delete pod -n apigee apigee-cassandra-default-0
    3. Controlla lo stato elencando di nuovo i pod Cassandra:
      kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

      Ad esempio:

      kubectl get pods -n apigee -l app=apigee-cassandra
      NAME                         READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          16s
      apigee-cassandra-default-1   1/1     Running   0          2h
      apigee-cassandra-default-2   1/1     Running   0          2h
      
      . . .
  • Applica di nuovo l'ultimo file di override noto per assicurarti che non siano state apportate modifiche in modo da poter utilizzare la stessa configurazione per eseguire l'upgrade alla versione ibrida 1.12.
  • Assicurati che tutti i nodi Cassandra in tutte le regioni si trovino nella zona UN (Up / Normal). Se un nodo Cassandra si trova in uno stato diverso, devi prima indirizzarlo prima di iniziare l'upgrade.

    Puoi convalidare lo stato dei nodi Cassandra con i seguenti comandi:

    1. Elenca i pod Cassandra:
      kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

      Ad esempio:

      kubectl get pods -n apigee -l app=apigee-cassandra
      NAME                         READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          2h
      apigee-cassandra-default-1   1/1     Running   0          2h
      apigee-cassandra-default-2   1/1     Running   0          2h
      apigee-cassandra-default-3   1/1     Running   0          16m
      apigee-cassandra-default-4   1/1     Running   0          14m
      apigee-cassandra-default-5   1/1     Running   0          13m
      apigee-cassandra-default-6   1/1     Running   0          9m
      apigee-cassandra-default-7   1/1     Running   0          9m
      apigee-cassandra-default-8   1/1     Running   0          8m
    2. Controlla lo stato dei nodi per ogni pod Cassandra con il comando kubectl nodetool status
      kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME nodetool status

      Ad esempio:

      kubectl -n apigee exec -it apigee-cassandra-default-0 nodetool status
      Datacenter: us-east1
      ====================
      Status=Up/Down
      |/ State=Normal/Leaving/Joining/Moving
      --  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
      UN  10.16.2.6    690.17 KiB  256          48.8%             b02089d1-0521-42e1-bbed-900656a58b68  ra-1
      UN  10.16.4.6    705.55 KiB  256          51.6%             dc6b7faf-6866-4044-9ac9-1269ebd85dab  ra-1
      UN  10.16.11.11  674.36 KiB  256          48.3%             c7906366-6c98-4ff6-a4fd-17c596c33cf7  ra-1
      UN  10.16.1.11   697.03 KiB  256          49.8%             ddf221aa-80aa-497d-b73f-67e576ff1a23  ra-1
      UN  10.16.5.13   703.64 KiB  256          50.9%             2f01ac42-4b6a-4f9e-a4eb-4734c24def95  ra-1
      UN  10.16.8.15   700.42 KiB  256          50.6%             a27f93af-f8a0-4c88-839f-2d653596efc2  ra-1
      UN  10.16.11.3   697.03 KiB  256          49.8%             dad221ff-dad1-de33-2cd3-f1.672367e6f  ra-1
      UN  10.16.14.16  704.04 KiB  256          50.9%             1feed042-a4b6-24ab-49a1-24d4cef95473  ra-1
      UN  10.16.16.1   699.82 KiB  256          50.6%             beef93af-fee0-8e9d-8bbf-efc22d653596  ra-1

Esegui il backup delle directory di installazione ibrida

  1. Queste istruzioni utilizzano la variabile di ambiente APIGEE_HELM_CHARTS_HOME per la directory nel file system in cui hai installato i grafici Helm. Se necessario, cambia directory in questa directory e definisci la variabile con il seguente comando:

    Linux

    export APIGEE_HELM_CHARTS_HOME=$PWD
    echo $APIGEE_HELM_CHARTS_HOME

    Mac OS

    export APIGEE_HELM_CHARTS_HOME=$PWD
    echo $APIGEE_HELM_CHARTS_HOME

    Windows

    set APIGEE_HELM_CHARTS_HOME=%CD%
    echo %APIGEE_HELM_CHARTS_HOME%
  2. Crea una copia di backup della directory $APIGEE_HELM_CHARTS_HOME/ della versione 1.11. Puoi utilizzare qualsiasi processo di backup. Ad esempio: puoi creare un file tar dell'intera directory con:
    tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.11-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
  3. Esegui il backup del database Cassandra seguendo le istruzioni riportate in Backup e recupero di Cassandra.
  4. Se utilizzi i file di certificato di servizio (.json) in per autenticare gli account di servizio, assicurati che i file del certificato degli account di servizio la directory corretta del grafico Helm. I grafici Helm non possono leggere i file esterni a ogni directory del grafico.

    Questo passaggio non è obbligatorio se utilizzi secret di Kubernetes o Workload Identity per di autenticare gli account di servizio.

    La tabella seguente mostra la destinazione di ciascun file dell'account di servizio, a seconda del tipo di installazione:

    Produzione

    Service account Nome file predefinito Directory dei grafici Helm
    apigee-cassandra PROJECT_ID-apigee-cassandra.json $APIGEE_HELM_CHARTS_HOME/apigee-datastore/
    apigee-logger PROJECT_ID-apigee-logger.json $APIGEE_HELM_CHARTS_HOME/apigee-telemetry/
    apigee-mart PROJECT_ID-apigee-mart.json $APIGEE_HELM_CHARTS_HOME/apigee-org/
    apigee-metrics PROJECT_ID-apigee-metrics.json $APIGEE_HELM_CHARTS_HOME/apigee-telemetry/
    apigee-runtime PROJECT_ID-apigee-runtime.json $APIGEE_HELM_CHARTS_HOME/apigee-env
    apigee-synchronizer PROJECT_ID-apigee-synchronizer.json $APIGEE_HELM_CHARTS_HOME/apigee-env/
    apigee-udca PROJECT_ID-apigee-udca.json $APIGEE_HELM_CHARTS_HOME/apigee-org/
    apigee-watcher PROJECT_ID-apigee-watcher.json $APIGEE_HELM_CHARTS_HOME/apigee-org/

    Non prod

    Crea una copia del file dell'account di servizio apigee-non-prod in ciascuna delle seguenti directory:

    Service account Nome file predefinito Directory dei grafici Helm
    apigee-non-prod PROJECT_ID-apigee-non-prod.json $APIGEE_HELM_CHARTS_HOME/apigee-datastore/
    $APIGEE_HELM_CHARTS_HOME/apigee-telemetry/
    $APIGEE_HELM_CHARTS_HOME/apigee-org/
    $APIGEE_HELM_CHARTS_HOME/apigee-env/
  5. Assicurati che i file del certificato e della chiave TLS (.crt, .key e/o .pem) si trovino nella directory $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/.

Esegui l'upgrade della versione di Kubernetes

Controlla la versione della piattaforma Kubernetes e, se necessario, esegui l'upgrade a una versione supportata sia da hybrid 1.11 sia da hybrid 1.12. Se hai bisogno di aiuto, consulta la documentazione della tua piattaforma.

Installa il runtime di hybrid 1.12.2

Prepararsi per l'upgrade dei grafici Helm

  1. Eseguire il pull dei grafici Apigee Helm.

    I grafici di Apigee hybrid sono ospitati in Google Artifact Registry:

    oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts

    Utilizzando il comando pull, copia tutti i grafici Helm hybrid di Apigee nel tuo spazio di archiviazione locale con il seguente comando:

    export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
    export CHART_VERSION=1.12.2
    helm pull $CHART_REPO/apigee-operator --version $CHART_VERSION --untar
    helm pull $CHART_REPO/apigee-datastore --version $CHART_VERSION --untar
    helm pull $CHART_REPO/apigee-env --version $CHART_VERSION --untar
    helm pull $CHART_REPO/apigee-ingress-manager --version $CHART_VERSION --untar
    helm pull $CHART_REPO/apigee-org --version $CHART_VERSION --untar
    helm pull $CHART_REPO/apigee-redis --version $CHART_VERSION --untar
    helm pull $CHART_REPO/apigee-telemetry --version $CHART_VERSION --untar
    helm pull $CHART_REPO/apigee-virtualhost --version $CHART_VERSION --untar
    
  2. Se necessario, esegui l'upgrade di cert-manager.

    Se devi eseguire l'upgrade della versione di cert-manager, installa la nuova versione con il seguente comando:

    kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml
    
  3. Installa i CRD di Apigee aggiornati:
    1. Utilizza la funzionalità di prova di kubectl eseguendo il seguente comando:

      kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false --dry-run=server
      
    2. Dopo la convalida con il comando dry-run, esegui questo comando:

      kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false
      
    3. Convalida l'installazione con il comando kubectl get crds:
      kubectl get crds | grep apigee

      Dovresti vedere un output simile al seguente:

      apigeedatastores.apigee.cloud.google.com                    2023-10-09T14:48:30Z
      apigeedeployments.apigee.cloud.google.com                   2023-10-09T14:48:30Z
      apigeeenvironments.apigee.cloud.google.com                  2023-10-09T14:48:31Z
      apigeeissues.apigee.cloud.google.com                        2023-10-09T14:48:31Z
      apigeeorganizations.apigee.cloud.google.com                 2023-10-09T14:48:32Z
      apigeeredis.apigee.cloud.google.com                         2023-10-09T14:48:33Z
      apigeerouteconfigs.apigee.cloud.google.com                  2023-10-09T14:48:33Z
      apigeeroutes.apigee.cloud.google.com                        2023-10-09T14:48:33Z
      apigeetelemetries.apigee.cloud.google.com                   2023-10-09T14:48:34Z
      cassandradatareplications.apigee.cloud.google.com           2023-10-09T14:48:35Z
      
  4. Controlla le etichette sui nodi del cluster. Per impostazione predefinita, Apigee pianifica i pod di dati sui nodi con l'etichetta cloud.google.com/gke-nodepool=apigee-data e i pod di runtime vengono pianificati sui nodi con l'etichetta cloud.google.com/gke-nodepool=apigee-runtime. Puoi personalizzare le etichette del pool di nodi nel file overrides.yaml.

    Per ulteriori informazioni, consulta la pagina Configurare i pool di nodi dedicati.

Installa i grafici Helm di Apigee hybrid

  1. In caso contrario, vai alla directory APIGEE_HELM_CHARTS_HOME. Esegui i seguenti comandi da quella directory.
  2. Esegui l'upgrade dell'operatore/del controller Apigee:

    Prova:

    helm upgrade operator apigee-operator/ \
      --install \
      --create-namespace \
      --namespace apigee-system \
      -f OVERRIDES_FILE \
      --dry-run
    

    Esegui l'upgrade del grafico:

    helm upgrade operator apigee-operator/ \
      --install \
      --create-namespace \
      --namespace apigee-system \
      -f OVERRIDES_FILE
    

    Verifica l'installazione dell'operatore Apigee:

    helm ls -n apigee-system
    
    NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
    operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.2   1.12.2

    Verifica che sia attivo e funzionante controllandone la disponibilità:

    kubectl -n apigee-system get deploy apigee-controller-manager
    
    NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
    apigee-controller-manager   1/1     1            1           7d20h
  3. Esegui l'upgrade del datastore Apigee:

    Prova:

    helm upgrade datastore apigee-datastore/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE \
      --dry-run
    

    Esegui l'upgrade del grafico:

    helm upgrade datastore apigee-datastore/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE
    

    Verifica che apigeedatastore sia attivo controllandone lo stato:

    kubectl -n apigee get apigeedatastore default
    
    NAME      STATE       AGE
    default   running    2d
  4. Esegui l'upgrade della telemetria Apigee:

    Prova:

    helm upgrade telemetry apigee-telemetry/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE \
      --dry-run
    

    Esegui l'upgrade del grafico:

    helm upgrade telemetry apigee-telemetry/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE
    

    Verifica che sia attivo e funzionante controllandone lo stato:

    kubectl -n apigee get apigeetelemetry apigee-telemetry
    
    NAME               STATE     AGE
    apigee-telemetry   running   2d
  5. Esegui l'upgrade di Apigee Redis:

    Prova:

    helm upgrade redis apigee-redis/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE \
      --dry-run
    

    Esegui l'upgrade del grafico:

    helm upgrade redis apigee-redis/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE
    

    Verifica che sia attivo e funzionante controllandone lo stato:

    kubectl -n apigee get apigeeredis default
    
    NAME      STATE     AGE
    default   running   2d
  6. Esegui l'upgrade del gestore in entrata Apigee:

    Prova:

    helm upgrade ingress-manager apigee-ingress-manager/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE \
      --dry-run
    

    Esegui l'upgrade del grafico:

    helm upgrade ingress-manager apigee-ingress-manager/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE
    

    Verifica che sia attivo e funzionante controllandone la disponibilità:

    kubectl -n apigee get deployment apigee-ingressgateway-manager
    
    NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
    apigee-ingressgateway-manager   2/2     2            2           2d
  7. Esegui l'upgrade dell'organizzazione Apigee:

    Prova:

    helm upgrade ORG_NAME apigee-org/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE \
      --dry-run
    

    Esegui l'upgrade del grafico:

    helm upgrade ORG_NAME apigee-org/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE
    

    Verifica che sia attivo e funzionante controllando lo stato dell'organizzazione corrispondente:

    kubectl -n apigee get apigeeorg
    
    NAME                      STATE     AGE
    apigee-org1-xxxxx          running   2d
  8. Esegui l'upgrade dell'ambiente.

    Devi installare un ambiente alla volta. Specifica l'ambiente con --set env=ENV_NAME:

    Prova:

    helm upgrade ENV_RELEASE_NAME apigee-env/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      --set env=ENV_NAME \
      -f OVERRIDES_FILE \
      --dry-run
    
    • ENV_RELEASE_NAME è il nome con cui hai installato in precedenza il grafico apigee-env. In Hybrid v1.10, in genere è apigee-env-ENV_NAME. In Hybrid versione 1.11 e successive, in genere è ENV_NAME.
    • ENV_NAME è il nome dell'ambiente di cui esegui l'upgrade.
    • OVERRIDES_FILE è il nuovo file delle sostituzioni per la versione 1.12.2

    Esegui l'upgrade del grafico:

    helm upgrade ENV_RELEASE_NAME apigee-env/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      --set env=ENV_NAME \
      -f OVERRIDES_FILE
    

    Verifica che sia attivo controllando lo stato del rispettivo env:

    kubectl -n apigee get apigeeenv
    
    NAME                          STATE       AGE   GATEWAYTYPE
    apigee-org1-dev-xxx            running     2d
  9. Esegui l'upgrade dei gruppi di ambienti (virtualhosts).
    1. Devi eseguire l'upgrade di un gruppo di ambienti (virtualhost) alla volta. Specifica il gruppo di ambienti con --set envgroup=ENV_GROUP_NAME. Ripeti i seguenti comandi per ogni gruppo env menzionato nel file overrides.yaml:

      Prova:

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --set envgroup=ENV_GROUP_NAME \
        -f OVERRIDES_FILE \
        --dry-run
      

      ENV_GROUP_RELEASE_NAME è il nome con cui hai installato in precedenza il grafico apigee-virtualhost. In Hybrid v1.10, in genere è apigee-virtualhost-ENV_GROUP_NAME. Nella versione ibrida v1.11 e successive viene di solito ENV_GROUP_NAME.

      Esegui l'upgrade del grafico:

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --set envgroup=ENV_GROUP_NAME \
        -f OVERRIDES_FILE
      
    2. Controlla lo stato di ApigeeRoute (AR).

      Installazione di virtualhosts crea ApigeeRouteConfig (ARC), che crea internamente ApigeeRoute (AR) dopo che l'osservatore Apigee ha eseguito il pull del gruppo env correlato i dettagli dal piano di controllo. Pertanto, verifica che lo stato corrispondente dell'AR sia in esecuzione:

      kubectl -n apigee get arc
      
      NAME                                STATE   AGE
      apigee-org1-dev-egroup                       2d
      kubectl -n apigee get ar
      
      NAME                                        STATE     AGE
      apigee-org1-dev-egroup-xxxxxx                running   2d

Rollback a una versione precedente in corso

Questa sezione è suddivisa in sezioni a seconda dello stato del componente apigee-datastore dopo l'upgrade alla versione 1.12 di Apigee hybrid. Esistono procedure per il rollback a livello di singola regione o multiregione con il componente apigee-datastore in uno stato buono e procedure per il recupero o il ripristino da un backup quando apigee-datastore è in uno stato non valido.

Rollback e recupero di una singola regione

Rollback in corso quando apigee-datastore è in stato buono

Questa procedura spiega come eseguire il rollback di ogni componente Apigee hybrid dalla versione 1.12 alla versione 1.11 tranne apigee-datastore. Il componente apigee-datastore v1.12 è compatibile con le versioni precedenti dei componenti ibrida v1.11.

Per eseguire il rollback dell'installazione in una singola regione alla versione 1.11:

  1. Prima di avviare il rollback, verifica che tutti i pod siano in esecuzione:
    kubectl get pods -n APIGEE_NAMESPACE
    kubectl get pods -n apigee-system
  2. Convalida il rilascio dei componenti utilizzando Helm:
    helm -n APIGEE_NAMESPACE list
    helm -n apigee-system list

    Ad esempio:

    helm -n apigee list
    NAME              NAMESPACE   REVISION   UPDATED                                   STATUS     CHART                           APP VERSION
    datastore         apigee      2          2024-03-29 17:08:07.917848253 +0000 UTC   deployed   apigee-datastore-1.12.0         1.12.0
    ingress-manager   apigee      2          2024-03-29 17:21:02.917333616 +0000 UTC   deployed   apigee-ingress-manager-1.12.0   1.12.0
    redis             apigee      2          2024-03-29 17:19:51.143728084 +0000 UTC   deployed   apigee-redis-1.12.0             1.12.0
    telemetry         apigee      2          2024-03-29 17:16:09.883885403 +0000 UTC   deployed   apigee-telemetry-1.12.0         1.12.0
    myhybridorg       apigee      2          2024-03-29 17:21:50.899855344 +0000 UTC   deployed   apigee-org-1.12.0               1.12.0
  3. Esegui il rollback di ogni componente tranne apigee-datastore con quanto segue :
    1. Crea la seguente variabile di ambiente:
      • PREVIOUS_HELM_CHARTS_HOME: la directory in cui si trovava la versione ibrida di Apigee precedente I grafici Helm sono installati. Questa è la versione a cui esegui il rollback.
    2. Esegui il rollback dei virtualhost. Ripeti il comando seguente per ogni gruppo di ambienti menzionati nel file degli override.
      helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set envgroup=ENV_GROUP_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_GROUP_RELEASE_NAME è il nome con cui hai installato in precedenza il grafico apigee-virtualhost. Nella versione ibrida v1.10, di solito viene apigee-virtualhost-ENV_GROUP_NAME. Nella versione ibrida v1.11 e successive viene di solito ENV_GROUP_NAME.

    3. Esegui il rollback degli ambienti. Ripeti il seguente comando per ogni ambiente menzionato nel file delle sostituzioni.
      helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set env=ENV_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_RELEASE_NAME è il nome con cui hai installato in precedenza il grafico apigee-env. Nella versione ibrida v1.10, di solito viene apigee-env-ENV_NAME. In Hybrid versione 1.11 e successive, solitamente è ENV_NAME.

      Verifica che sia attivo e funzionante controllando lo stato del rispettivo ambiente:

      kubectl -n apigee get apigeeenv
      
      NAME                  STATE     AGE   GATEWAYTYPE
      apigee-org1-dev-xxx   running   2d
    4. Esegui il rollback dell'organizzazione:
      helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Verifica che sia attivo controllando lo stato della rispettiva organizzazione:

      kubectl -n apigee get apigeeorg
      
      NAME                STATE     AGE
      apigee-org1-xxxxx   running   2d
    5. Esegui il rollback di Ingress Manager:
      helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Verifica che sia attivo e funzionante controllandone la disponibilità:

      kubectl -n apigee get deployment apigee-ingressgateway-manager
      
      NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-ingressgateway-manager   2/2     2            2           2d
    6. Esegui il rollback di Redis:
      helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Verifica che sia attivo e funzionante controllandone lo stato:

      kubectl -n apigee get apigeeredis default
      
      NAME      STATE     AGE
      default   running   2d
    7. Esegui il rollback di Apigee Telemetry:
      helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Verifica che sia attivo e funzionante controllandone lo stato:

      kubectl -n apigee get apigeetelemetry apigee-telemetry
      
      NAME               STATE     AGE
      apigee-telemetry   running   2d
    8. Esegui il rollback del controller Apigee:
      helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
        --install \
        --namespace apigee-system \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE

      Verifica l'installazione di Apigee Operator:

      helm ls -n apigee-system
      
      NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
      operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.2   1.12.2

      Verifica che sia attivo e funzionante controllandone la disponibilità:

      kubectl -n apigee-system get deploy apigee-controller-manager
      
      NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-controller-manager   1/1     1            1           7d20h
    9. Ripristina i CRD di Apigee hybrid:
      kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false
      
  4. Verifica che tutti i pod siano in esecuzione o completati:
    kubectl get pods -n APIGEE_NAMESPACE
    kubectl get pods -n apigee-system
  5. Convalida la release di tutti i componenti. Tutti i componenti devono essere nella versione precedente tranne datastore:
    helm -n APIGEE_NAMESPACE list
    helm -n apigee-system list

    Ad esempio:

    helm -n apigee  list
    NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
    datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
    ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
    redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
    telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
    myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0

Ripristino quando apigee-datastore non è in buono stato

Se l'upgrade del componente apigee-datastore non è andato a buon fine, non puoi eseguire il rollback apigee-datastore dalla versione 1.12 alla versione 1.11. Invece, deve eseguire il ripristino da un backup effettuato da un'installazione v1.11. Utilizza la seguente sequenza per ripristinare la versione precedente.

  1. Se non hai un'installazione attiva di Apigee versione ibrida 1.11 (ad esempio in un'altra regione), crea una nuova installazione v1.11 utilizzando i grafici di cui hai eseguito il backup e i file di override. Consulta le Versione ibrida Apigee 1.11 Istruzioni per l'installazione.
  2. Ripristina la regione della versione 1.11 (o la nuova installazione) dal backup seguendo le istruzioni riportate in:
  3. Verifica il traffico verso l'installazione ripristinata
  4. (Facoltativo) Rimuovi l'installazione della versione 1.12 seguendo le istruzioni riportate in Disinstallare il runtime di hybrid.

Rollback e ripristino multiregionale

Eseguire il rollback quando apigee-datastore è in uno stato buono

Questa procedura spiega come eseguire il rollback di ogni componente Apigee hybrid dalla versione 1.12 alla versione 1.11 tranne apigee-datastore. Il componente apigee-datastore v1.12 è compatibile con le versioni precedenti dei componenti ibrida v1.11.

  1. Prima di avviare il rollback, verifica che tutti i pod siano in esecuzione:
    kubectl get pods -n APIGEE_NAMESPACE
    kubectl get pods -n apigee-system
  2. Assicurati che tutti i nodi Cassandra in tutte le regioni si trovino nella zona UN (Up / Normal). Se un nodo Cassandra si trova in uno stato diverso, devi prima indirizzarlo prima di iniziare il processo di upgrade.

    Puoi convalidare lo stato dei nodi Cassandra con i seguenti comandi:

    1. Elenca i pod Cassandra:
      kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

      Ad esempio:

      kubectl get pods -n apigee -l app=apigee-cassandra
      NAME                         READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          2h
      apigee-cassandra-default-1   1/1     Running   0          2h
      apigee-cassandra-default-2   1/1     Running   0          2h
      apigee-cassandra-default-3   1/1     Running   0          16m
      apigee-cassandra-default-4   1/1     Running   0          14m
      apigee-cassandra-default-5   1/1     Running   0          13m
      apigee-cassandra-default-6   1/1     Running   0          9m
      apigee-cassandra-default-7   1/1     Running   0          9m
      apigee-cassandra-default-8   1/1     Running   0          8m
    2. Controlla lo stato dei nodi per ogni pod Cassandra con il comando kubectl nodetool status
      kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME -- nodetool -u JMX_USER -pw JMX_PASSWORD

      Ad esempio:

      kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u jmxuser -pw JMX_PASSWORD status
      Datacenter: us-east1
      ====================
      Status=Up/Down
      |/ State=Normal/Leaving/Joining/Moving
      --  Address      Load        Tokens   Owns (effective)   Host ID                                Rack
      UN  10.16.2.6    690.17 KiB  256      48.8%              b02089d1-0521-42e1-bbed-900656a58b68   ra-1
      UN  10.16.4.6    705.55 KiB  256      51.6%              dc6b7faf-6866-4044-9ac9-1269ebd85dab   ra-1
      UN  10.16.11.11  674.36 KiB  256      48.3%              c7906366-6c98-4ff6-a4fd-17c596c33cf7   ra-1
      UN  10.16.1.11   697.03 KiB  256      49.8%              ddf221aa-80aa-497d-b73f-67e576ff1a23   ra-1
      UN  10.16.5.13   703.64 KiB  256      50.9%              2f01ac42-4b6a-4f9e-a4eb-4734c24def95   ra-1
      UN  10.16.8.15   700.42 KiB  256      50.6%              a27f93af-f8a0-4c88-839f-2d653596efc2   ra-1
      UN  10.16.11.3   697.03 KiB  256      49.8%              dad221ff-dad1-de33-2cd3-f1.672367e6f   ra-1
      UN  10.16.14.16  704.04 KiB  256      50.9%              1feed042-a4b6-24ab-49a1-24d4cef95473   ra-1
      UN  10.16.16.1   699.82 KiB  256      50.6%              beef93af-fee0-8e9d-8bbf-efc22d653596   ra-1

    Se non tutti i pod Cassandra sono in stato UN, segui le istruzioni in Rimuovi i nodi DISPONIBILI dal cluster Cassandra.

  3. Vai alla directory in cui sono installati i precedenti grafici Helm di Apigee hybrid
  4. Modifica il contesto nella regione di cui è stato eseguito l'upgrade
    kubectl config use-context UPGRADED_REGION_CONTEXT
        
  5. Verifica che tutti i pod siano in esecuzione:
    kubectl get pods -n APIGEE_NAMESPACE
    kubectl get pods -n apigee-system
  6. Usa il comando helm per assicurarti che sia stato eseguito l'upgrade di tutte le release alla versione ibrida 1.12:
    helm -n APIGEE_NAMESPACE list
    helm -n apigee-system list

    Ad esempio:

    helm -n apigee list
    NAME             NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
    datastore        apigee     2         2024-03-29 17:08:07.917848253 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
    ingress-manager  apigee     2         2024-03-29 17:21:02.917333616 +0000 UTC  deployed  apigee-ingress-manager-1.12.0  1.12.0
    redis            apigee     2         2024-03-29 17:19:51.143728084 +0000 UTC  deployed  apigee-redis-1.12.0            1.12.0
    telemetry        apigee     2         2024-03-29 17:16:09.883885403 +0000 UTC  deployed  apigee-telemetry-1.12.0        1.12.0
    myhybridorg      apigee     2         2024-03-29 17:21:50.899855344 +0000 UTC  deployed  apigee-org-1.12.0              1.12.0
  7. Esegui il rollback di ogni componente tranne apigee-datastore con quanto segue :
    1. Crea la seguente variabile di ambiente:
      • PREVIOUS_HELM_CHARTS_HOME: la directory in cui si trovava la versione ibrida di Apigee precedente I grafici Helm sono installati. Questa è la versione a cui esegui il rollback.
    2. Esegui il rollback dei virtualhost. Ripeti il comando seguente per ogni gruppo di ambienti menzionati nel file degli override.
      helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set envgroup=ENV_GROUP_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_GROUP_RELEASE_NAME è il nome con cui hai installato in precedenza il grafico apigee-virtualhost. Nella versione ibrida v1.10, di solito viene apigee-virtualhost-ENV_GROUP_NAME. Nella versione ibrida v1.11 e successive viene di solito ENV_GROUP_NAME.

    3. Esegui il rollback degli ambienti. Ripeti il seguente comando per ogni ambiente menzionato nel file delle sostituzioni.
      helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set env=ENV_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_RELEASE_NAME è il nome con cui hai installato in precedenza il grafico apigee-env. Nella versione ibrida v1.10, di solito viene apigee-env-ENV_NAME. Nella versione ibrida v1.11 e successive viene di solito ENV_NAME.

      Verifica che ogni ambiente sia attivo e in esecuzione controllando lo stato del rispettivo ambiente:

      kubectl -n apigee get apigeeenv
      
      NAME                  STATE     AGE   GATEWAYTYPE
      apigee-org1-dev-xxx   running   2d
    4. Esegui il rollback dell'organizzazione:
      helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Verifica che sia attivo controllando lo stato della rispettiva organizzazione:

      kubectl -n apigee get apigeeorg
      
      NAME                STATE     AGE
      apigee-org1-xxxxx   running   2d
    5. Esegui il rollback di Ingress Manager:
      helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Verifica che sia attivo e funzionante controllandone la disponibilità:

      kubectl -n apigee get deployment apigee-ingressgateway-manager
      
      NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-ingressgateway-manager   2/2     2            2           2d
    6. Esegui il rollback di Redis:
      helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Verifica che sia attivo e funzionante controllandone lo stato:

      kubectl -n apigee get apigeeredis default
      
      NAME      STATE     AGE
      default   running   2d
    7. Esegui il rollback di Apigee Telemetry:
      helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Verifica che sia attivo e funzionante controllandone lo stato:

      kubectl -n apigee get apigeetelemetry apigee-telemetry
      
      NAME               STATE     AGE
      apigee-telemetry   running   2d
    8. Esegui il rollback del controller Apigee:
      helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
        --install \
        --namespace apigee-system \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Verifica l'installazione di Apigee Operator:

      helm ls -n apigee-system
      
      NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
      operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.2   1.12.2

      Verifica che sia attivo e funzionante controllandone la disponibilità:

      kubectl -n apigee-system get deploy apigee-controller-manager
      
      NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-controller-manager   1/1     1            1           7d20h
    9. Esegui il rollback dei CRD ibridi di Apigee:
      kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false
      
  8. Convalida la release di tutti i componenti. Tutti i componenti devono essere nella versione precedente tranne datastore:
    helm -n APIGEE_NAMESPACE list
    helm -n apigee-system list

    Ad esempio:

    helm -n apigee  list
    NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
    datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
    ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
    redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
    telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
    myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0
    

    A questo punto, per tutte le release tranne datastore è stato eseguito il rollback alla versione precedente.

Ripristino di un'installazione multiregione a una versione precedente

Recupera la regione in cui l'upgrade non è riuscito in un upgrade in più regioni rimuovendo i riferimenti a quest'ultima da installazioni di più regioni. Questo metodo è possibile solo se è presente almeno una regione attiva su Hybrid 1.11. Il datastore della versione 1.12 è compatibile con i componenti della versione 1.11.

Per recuperare una o più regioni non riuscite da una regione integra, segui questi passaggi:

  1. Reindirizza il traffico API dalle regioni interessate alla regione funzionante. Pianifica la capacità in modo da supportare il traffico deviato dalle regioni in cui si sono verificati errori.
  2. Esegui la dismissione della regione interessata. Per ogni regione interessata, segui i passaggi descritti in Rimuovere una regione ibrida. Attendi il completamento del ritiro prima di procedere al passaggio successivo.

  3. Ripulisci la regione con errore seguendo le istruzioni riportate in Ripristinare una regione da un upgrade non riuscito.
  4. Recupera la regione interessata. Per eseguire il ripristino, crea una nuova regione, come descritto in Deployment multiregionale su GKE, GKE On-Prem e AKS.

Ripristino di un'installazione multiregionale da un backup con apigee-datastore in stato non valido

Se l'upgrade del componente apigee-datastore non è andato a buon fine, non puoi eseguire il rollback dalla versione 1.12 alla versione 1.11. Invece, deve eseguire il ripristino da un backup effettuato da un'installazione v1.11. Utilizza quanto segue per ripristinare la versione precedente.

  1. Se non hai un'installazione attiva di Apigee versione ibrida 1.11 (ad esempio in un'altra regione), crea una nuova installazione v1.11 utilizzando i grafici di cui hai eseguito il backup e i file di override. Consulta le istruzioni di installazione della versione 1.11 di Apigee hybrid.
  2. Ripristina la regione della versione 1.11 (o la nuova installazione) dal backup seguendo le istruzioni riportate in:
  3. Verifica il traffico verso l'installazione ripristinata
  4. Per le installazioni multiregione, ricostruisci e ripristina la regione successiva. Consulta le istruzioni in Ripristino da un backup in Ripristino in più regioni.
  5. Rimuovi l'installazione della versione 1.12 seguendo le istruzioni in Disinstalla il runtime ibrido.

APPENDICE: ripristinare una regione da un upgrade non riuscito

Rimuovi un data center se l'upgrade da 1.11 a 1.12 non va a buon fine.

  1. Convalida lo stato del cluster Cassandra da una regione attiva:
    1. Cambia il contesto kubectl sulla regione da rimuovere:
      kubectl config use-context CONTEXT_OF_LIVE_REGION
    2. Elenca i pod Cassandra:
      kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

      Ad esempio:

      kubectl get pods -n apigee -l app=apigee-cassandra
      NAME                 READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          2h
      apigee-cassandra-default-1   1/1     Running   0          2h
      apigee-cassandra-default-2   1/1     Running   0          2h
    3. Esegui in uno dei pod Cassandra:
      kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash
    4. Controlla lo stato del cluster Cassandra:
      nodetool -u JMX_USER -pw JMX_PASSWORD status

      L'output dovrebbe essere simile al seguente:

      Datacenter: dc-1
      ================
      Status=Up/Down
      |/ State=Normal/Leaving/Joining/Moving
      --  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
      UN  10.48.12.16  813.84 KiB  256          100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
      UN  10.48.14.16  859.89 KiB  256          100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
      UN  10.48.0.18   888.95 KiB  256          100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
      
    5. Descrivi il cluster per verificare di vedere solo gli IP dei pod Cassandra della regione attiva e tutti con la stessa versione dello schema:
      nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

      L'output dovrebbe essere simile al seguente:

      nodetool -u JMX_USER -pw JMX_PASSWORD describecluster
      
      Schema versions:
          4bebf2de-0582-31b4-9c5f-e36f60127e1b: [10.48.14.16, 10.48.12.16, 10.48.0.18]
      
  2. Ripulire la replica dello spazio chiavi Cassandra:
    1. Recupera il job user-setup ed eliminalo. Verrà creato immediatamente un nuovo job user-setup.
      kubectl get jobs -n APIGEE_NAMESPACE

      Ad esempio:

      kubectl get jobs -n apigee
        NAME                                                           COMPLETIONS   DURATION   AGE
        apigee-cassandra-schema-setup-myhybridorg-8b3e61d          1/1           6m35s      3h5m
        apigee-cassandra-schema-val-myhybridorg-8b3e61d-28499150   1/1           10s        9m22s
       apigee-cassandra-user-setup-myhybridorg-8b3e61d            0/1           21s        21s
      
      kubectl delete jobs USER_SETUP_JOB_NAME -n APIGEE_NAMESPACE

      L'output dovrebbe mostrare il nuovo job che inizia:

      kubectl delete jobs apigee-cassandra-user-setup-myhybridorg-8b3e61d -n apigee
      
        apigee-cassandra-user-setup-myhybridorg-8b3e61d-wl92b         0/1     Init:0/1    0               1s
        
    2. Convalida le impostazioni di replica dello spazio chiavi Cassandra creando un contenitore client seguendo le istruzioni riportate in Creare il contenitore client.
    3. Recupera tutti gli spazi delle chiavi. Esegui il pod cassandra-client e avvia un client cqlsh:
      kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

      Connettiti al server Cassandra con ddl user, in quanto dispone delle autorizzazioni necessarie per eseguire i seguenti comandi:

      cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

      Recupera gli spazi delle chiavi:

      select * from system_schema.keyspaces;

      L'output dovrebbe essere simile al seguente, dove dc-1 è il DC live:

      select * from system_schema.keyspaces;
      
       keyspace_name            | durable_writes | replication
      --------------------------+----------------+--------------------------------------------------------------------------------
         kvm_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                    system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                  system_schema |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
       quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
       cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         rtc_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
             system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                         system |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                         perses |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                  system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         kms_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      
      (11 rows)
      
    4. Se per qualche motivo il job user-setup continua a restituire un errore e la convalida non va a buon fine, utilizza i comandi seguenti per correggere la replica negli spazi delle chiavi.
      kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

      Connettiti al server Cassandra con ddl user, in quanto dispone delle autorizzazioni necessarie per eseguire i seguenti comandi:

      cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

      Ottieni gli spazi chiavi:

      select * from system_schema.keyspaces;

      Utilizza i nomi dello spazio chiavi del comando precedente e sostituiscili nei seguenti esempi

      alter keyspace quota_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace kms_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace kvm_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace cache_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace perses_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace rtc_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace system_distributed WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace system_traces WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
    5. Verifica che tutti gli spazi delle chiavi siano replicati nella regione corretta con il seguente comando cqlsh:
      select * from system_schema.keyspaces;

      Ad esempio:

      select * from system_schema.keyspaces;
      
       keyspace_name           | durable_writes | replication
      -------------------------+----------------+--------------------------------------------------------------------------------
      kvm_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                system_auth    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
              system_schema    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
      quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      rtc_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         system_distributed    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                     system    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                     perses    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
              system_traces    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      kms_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      
      (11 rows)

In questa fase hai rimosso completamente tutti i riferimenti per il controller di dominio non attivo dal cluster Cassandra.

APPENDICE: rimuovi i nodi DOWN dal cluster Cassandra

Utilizza questa procedura quando esegui il rollback di un'installazione multiregionale e non tutti i pod Cassandra sono in stato attivo / normale (UN).

  1. Esegui in uno dei pod Cassandra:
    kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash
  2. Controlla lo stato del cluster Cassandra:
    nodetool -u JMX_USER -pw JMX_PASSWORD status
  3. Verifica che il nodo sia effettivamente in stato Down (DN). Esegui il comando Exec nel pod Cassandra in una regione in cui il pod Cassandra non riesce ad avviarsi.
    Datacenter: dc-1
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
    UN  10.48.12.16  1.15 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
    UN  10.48.0.18   1.21 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
    UN  10.48.14.16  1.18 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
    
    Datacenter: us-west1
    ====================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
    DN  10.8.4.4     432.42 KiB  256     100.0%            cd672398-5c45-4c88-a424-86d757951e53  rc-1
    UN  10.8.19.6    5.8 MiB     256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
    UN  10.8.21.5    5.74 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1
    
  4. Rimuovi il riferimento al nodo verso il basso (DN). Dall'esempio riportato sopra, rimuoveremo il riferimento all'host 10.8.4.4
    kubectl exec -it -n apigee apigee-cassandra-default-2 -- /bin/bash
     nodetool -u JMX_USER -pw JMX_PASSWORD removenode HOST_ID
    
  5. Dopo aver rimosso il riferimento, termina il pod. Il nuovo pod Cassandra dovrebbe essere avviato e unirsi al cluster
    kubectl delete pod -n POD_NAME
  6. Verifica che il nuovo pod Cassandra sia unito al cluster.
    Datacenter: dc-1
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
    UN  10.48.12.16  1.16 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
    UN  10.48.0.18   1.22 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
    UN  10.48.14.16  1.19 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
    
    Datacenter: us-west1
    ====================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
    UN  10.8.19.6    5.77 MiB    256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
    UN  10.8.4.5     246.99 KiB  256     100.0%            0182e675-eec8-4d68-a465-69211b621601  rc-1
    UN  10.8.21.5    5.69 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

A questo punto puoi procedere con l'upgrade o il rollback delle regioni rimanenti del cluster.

APPENDICE: Risoluzione dei problemi: apigee-datastore in stato bloccato dopo il rollback

Utilizza questa procedura se hai eseguito il rollback di apigee-datastore all'ibrido 1.11 dopo l'upgrade e il dispositivo è bloccato.

  1. Prima di correggere di nuovo lo stato del controller del datastore, verifica che sia in uno stato releasing e che i pod non vengano avviati insieme allo stato del cluster Cassandra.
    1. Verifica mediante il comando Helm il rollback del datastore:
      helm -n APIGEE_NAMESPACE list

      Ad esempio:

      helm -n apigee list
      NAME              NAMESPACE  REVISION  UPDATED                                   STATUS    CHART                              APP VERSION
      datastore         apigee     3         2024-04-04 22:15:08.792539892 +0000 UTC   deployed   apigee-datastore-1.11.0           1.11.0
      ingress-manager   apigee     1         2024-04-02 22:24:27.564184968 +0000 UTC   deployed   apigee-ingress-manager-1.12.0     1.12.0
      redis             apigee     1         2024-04-02 22:23:59.938637491 +0000 UTC   deployed   apigee-redis-1.12.0               1.12.0
      telemetry         apigee     1         2024-04-02 22:23:39.458134303 +0000 UTC   deployed   apigee-telemetry-1.12             1.12.0
      myhybridorg       apigee     1         2024-04-02 23:36:32.614927914 +0000 UTC   deployed   apigee-org-1.12.0                 1.12.0
      
    2. Ottieni lo stato dei pod Cassandra:
      kubectl get pods -n APIGEE_NAMESPACE

      Ad esempio:

      kubectl get pods -n apigee
      NAME                         READY   STATUS             RESTARTS      AGE
      apigee-cassandra-default-0   1/1     Running            0             2h
      apigee-cassandra-default-1   1/1     Running            0             2h
      apigee-cassandra-default-2   0/1     CrashLoopBackOff   4 (13s ago)   2m13s
      
    3. Verifica che il controller apigeeds sia bloccato in stato di rilascio:
      kubectl get apigeeds -n APIGEE_NAMESPACE

      Ad esempio:

      kubectl get apigeeds -n apigee
      NAME      STATE       AGE
      default   releasing   46h
    4. Convalida lo stato dei nodi Cassandra (tieni presente che un nodo è in uno stato DN, ovvero bloccato in uno stato CrashLoopBackOff):
      kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

      Ad esempio:

      kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
      Defaulted container "apigee-cassandra" out of: apigee-cassandra, apigee-cassandra-ulimit-init (init)
      Datacenter: us-west1
      ====================
      Status=Up/Down
      |/ State=Normal/Leaving/Joining/Moving
      --   Address       Load       Tokens   Owns (effective)   Host ID                               Rack
      UN   10.68.7.28    2.12 MiB   256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3  rc-1
      UN   10.68.10.29   2.14 MiB   256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452  rc-1
      DN   10.68.6.26    5.77 MiB   256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1
      
  2. Eseguire l'upgrade del datastore utilizzando i grafici 1.12.
    helm upgrade datastore APIGEE_HELM_1.12.0_HOME/apigee-datastore/   --install   --namespace APIGEE_NAMESPACE   -f overrides.yaml
  3. Verifica che tutti i pod siano Running e che il cluster Cassandra sia di nuovo integro.
    1. Verifica che tutti i pod siano di nuovo READY:
      kubectl get pods -n APIGEE_NAMESPACE

      Ad esempio:

      kubectl get pods -n apigee
      NAME                         READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          29h
      apigee-cassandra-default-1   1/1     Running   0          29h
      apigee-cassandra-default-2   1/1     Running   0          60m
    2. Convalida lo stato del cluster Cassandra:
      kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

      Ad esempio:

      kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
      Datacenter: us-west1
      ====================
      Status=Up/Down
      |/ State=Normal/Leaving/Joining/Moving
      --   Address       Load      Tokens   Owns (effective)   Host ID                                Rack
      UN   10.68.4.15    2.05 MiB  256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1
      UN   10.68.7.28    3.84 MiB  256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3   rc-1
      UN   10.68.10.29   3.91 MiB  256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452   rc-1
        
    3. Stato della convalida del controller apigeeds:
      kubectl get apigeeds -n APIGEE_NAMESPACE

      Ad esempio:

      kubectl get apigeeds -n apigee
      NAME      STATE     AGE
      default   running   2d1h

A questo punto, il datastore dovrebbe essere stato corretto e dovrebbe essere nello stato running.