Questa pagina è stata tradotta dall'API Cloud Translation.

Upgrade di Apigee hybrid alla versione 1.3.6

Panoramica dell'upgrade alla versione 1.3.6.

L'upgrade ad Apigee versione ibrida 1.3.6 richiede tempi di inattività durante
Per ridurre al minimo i tempi di inattività negli ambienti ibridi di produzione, assicurati di eseguire almeno due cluster e aggiornali uno alla volta.

Inoltre, al momento dell'upgrade, ogni componente eseguirà un riavvio in sequenza.

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

preparazione

Creare e aggiornare gli account di servizio.

Pianifica i gruppi di ambienti.

Copia e aggiorna il file di override.

Esegui l'upgrade di Istio e di cert-manager.

Installa il runtime ibrido versione 1.3.

Eseguire la pulizia.

Nota: non creare nuovi ambienti durante il processo di upgrade.

Prerequisiti

Apigee hybrid versione 1.2. Se esegui l'aggiornamento da una versione precedente, consulta le istruzioni per eseguire l'upgrade di Apigee hybrid alla versione 1.2.

preparazione

(Consigliato) Crea una copia di backup della directory $APIGEECTL_HOME/ della versione 1.2. Ad esempio:
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.2-backup.tar.gz $APIGEECTL_HOME

(Consigliato) Esegui il backup del database Cassandra seguendo le istruzioni in Backup e ripristino Cassandra

Esegui l'upgrade della tua piattaforma Kubernetes come descritto di seguito. Segui la documentazione della tua piattaforma se hai bisogno di assistenza:

Piattaforma Esegui l'upgrade alla versione

GKE 1,15 x

Anthos 1,5

AKS 1.16.x con cluster collegati ad Anthos

Se non utilizzi Apigee Connect nell'installazione ibrida, abilita Apigee Connect.

Controlla se l'API Apigee Connect è abilitata:
gcloud services list | grep apigeeconnect apigeeconnect.googleapis.com Apigee Connect API

In caso contrario, abilita l'API:
gcloud services enable apigeeconnect.googleapis.com --project $PROJECT_ID

Dove $PROJECT_ID è l'ID progetto Google Cloud.

Nella riga di comando, recupera le tue credenziali di autenticazione gcloud, come mostrato nell'esempio seguente:
TOKEN=$(gcloud auth print-access-token)

Per verificare che il token sia stato compilato, utilizza echo, come illustrato nell'esempio seguente:

echo $TOKEN

Il token dovrebbe essere visualizzato come stringa codificata.

Per maggiori informazioni, consulta la panoramica dello strumento a riga di comando gcloud.

Controlla se Apigee Connect è abilitato per la tua organizzazione:
curl -H "Authorization: Bearer $TOKEN" \ "https://apigee.googleapis.com/v1/organizations/$ORG_NAME"

Dove $ORG_NAME è l'ID della tua organizzazione.
Se l'output contiene:

"name" : "features.mart.connect.enabled", "value" : "true"

Apigee Connect è abilitato.

Se Apigee Connect non è abilitato, assegna il ruolo Agente Apigee Connect all'account di servizio MART:
gcloud projects add-iam-policy-binding $PROJECT_ID \ --member serviceAccount:apigee-mart@$PROJECT_ID.iam.gserviceaccount.com \ --role roles/apigeeconnect.Agent

Suggerimento: se hai bisogno di ottenere l'indirizzo email del tuo account di servizio MART, esegui questo comando:
gcloud iam service-accounts list | grep mart

Abilita Apigee Connect con il seguente comando:
curl -H "Authorization: Bearer $TOKEN" -X PUT \ -H "Content-Type: application/json" \ -d '{ "name" : "'"$ORG_NAME"'", "properties" : { "property" : [ { "name" : "features.hybrid.enabled", "value" : "true" }, { "name" : "features.mart.connect.enabled", "value" : "true" } ] } }' \ "https://apigee.googleapis.com/v1/organizations/$ORG_NAME"

Se l'output contiene le due proprietà seguenti, Apigee Connect è stato abilitato correttamente:

{ "name": "features.mart.connect.enabled", "value": "true" }, { "name": "features.hybrid.enabled", "value": "true" }

Crea l'account di servizio apigee-watcher. Apigee Watcher è un nuovo account di servizio introdotto nella versione 1.3. Esegue il sincronizzatore per le modifiche a livello di organizzazione e applica queste modifiche per configurare il traffico in entrata Istio.
Dalla directory ibrida principale:

./tools/create-service-account apigee-watcher ./service-accounts

Assegna il ruolo Agente di runtime Apigee all'account di servizio Watcher:
gcloud projects add-iam-policy-binding $PROJECT_ID \ --member serviceAccount:apigee-watcher@$PROJECT_ID.iam.gserviceaccount.com \ --role roles/apigee.runtimeAgent

Dove PROJECT_ID è l'ID progetto Google Cloud. Se gli indirizzi email dell'account di servizio sono diversi da questo pattern, sostituiscili di conseguenza.

Suggerimento: se hai bisogno di recuperare l'indirizzo email del tuo account di servizio Watcher, esegui questo comando:
gcloud iam service-accounts list | grep watcher

L'output dovrebbe includere un elenco di tutti gli account di servizio e i relativi ruoli, tra cui:

... - members: - serviceAccount:apigee-watcher@hybrid13rc5.iam.gserviceaccount.com role: roles/apigee.runtimeAgent ...

Pianifica il routing nei tuoi gruppi di ambienti. Apigee hybrid 1.3 gestisce il routing dei percorsi di base con gruppi di ambienti anziché routingRules. Se utilizzi routingRules nella configurazione ibrida, progetta i gruppi di ambienti per replicare il routing.
Devi creare almeno un gruppo di ambienti.

Vedi Informazioni sui gruppi di ambienti.

Fai clic per visualizzare un esempio di utilizzo dei gruppi di ambienti per sostituire routingRules

In questo esempio, il seguente routingRules nel file overrides.yaml instrada le richieste ai proxy API foo e bar per l'ambiente prod-env-1 e il proxy foo-test all'ambiente test-env:

virtualhosts: - name: default hostAliases: - "*.acme.com" sslCertPath: ./certs/keystore.pem sslKeyPath: ./certs/keystore.key routingRules: - paths: - /foo - /bar - env: prod-env-1 - paths: - foo-test -env: test-env

Per duplicarlo nella versione ibrida 1.3.6:

Esegui il deployment dei proxy foo e bar nell'ambiente prod-env-1.

Esegui il deployment del proxy foo-test e bar nell'ambiente test-env.

Crea un gruppo di ambienti con un alias host per i proxy, ad esempio api.acme.com.
Suggerimento: crea un gruppo di ambienti con lo stesso nome del nome virtualhosts che hai utilizzato nella versione 1.2.

Rivedere la stanza virtualhosts in overrides.yaml in

Sostituisci virtualhosts:name con il nome del gruppo di ambienti.

Rimuovi l'virtualhosts:routingRules.

Ad esempio:

virtualhosts: - name: default # environment group name sslCertPath: ./certs/keystore.pem sslKeyPath: ./certs/keystore.key

Aggiorna il file di override:

Crea una copia del file di override.

Aggiorna le stanze gcp e k8sCluster.
Le seguenti proprietà di configurazione sono state sostituite nella versione ibrida 1.3:

gcpRegion sostituita con gcp:region

gcpProjectID sostituita con gcp:projectID

gcpProjectIDRuntime sostituita con gcp:gcpProjectIDRuntime

k8sClusterName sostituita con k8s:clusterName

k8sClusterRegion sostituita con k8s:clusterRegion

Ad esempio, sostituisci la seguente struttura:

gcpRegion: gcp region gcpProjectID: gcp project ID gcpProjectIDRuntime: gcp project ID k8sClusterName: name k8sClusterRegion: region

with:

gcp: projectID: gcp project ID region: gcp region gcpProjectIDRuntime: gcp project ID # optional. This is only required if you # want logger/metrics data to be sent in # different gcp project. k8sCluster: name: gcp project ID region: gcp region

Se non hai già un identificatore di istanza univoco nel file di override, aggiungine uno:
# unique identifier for this installation. 63 chars length limit instanceID: ID

Dove ID è un identificatore univoco per questa installazione ibrida, come "my-hybrid-131-installation" o "acmecorp-hybrid-131".

Aggiungi l'account di servizio Watcher (apigee-watcher) al file di override:
# Note: the SA should have the "Apigee Runtime Agent" role watcher: serviceAccountPath: "service account file"

Aggiungi l'account di servizio delle metriche (apigee-metrics) al file di override:
metrics: serviceAccountPath: "service account file"

Aggiorna la stanza virtualhosts: per sostituire routingRules con il tuo gruppo di ambienti.

-name: Sostituisci il nome con il nome del tuo gruppo di ambienti. Puoi avere più voci di nome, una per ogni gruppo di ambienti.

hostAliases:[] Elimina questa riga.

Mantieni (o aggiungi) le voci sslCertPath: e sslKeyPath:.

Elimina tutte le voci routingRules.

Ad esempio:

virtualhosts: - name: default hostAliases: - "*.acme.com" sslCertPath: ./certs/keystore.pem sslKeyPath: ./certs/keystore.key routingRules: - paths: - /foo - /bar - env: my-environment

Diventa:

virtualhosts: - name: example-env-group sslCertPath: ./certs/keystore.pem sslKeyPath: ./certs/keystore.key

Aggiorna le stanze mart e connectAgent:.
Nota: se non prevedi di utilizzare Apigee Connect nell'installazione ibrida 1.3, salta questo passaggio e segui il suggerimento nel passaggio 5 in Apigee Connect dopo l'upgrade.

In mart: rimuovi le voci hostAlias:, sslCertPath: e sslKeyPath:.

Aggiungi una stanza connectAgent:.

In connectAgent: aggiungi una voce serviceAccountPath: e fornisci il percorso al file dell'account di servizio a cui è assegnato il ruolo Agente Apigee Connect (di solito l'account di servizio MART).

Ad esempio:

mart: hostAlias: "mart.apigee-hybrid-docs.net" serviceAccountPath: ./service-accounts/hybrid-project-apigee-mart.json sslCertPath: ./certs/fullchain.pem sslKeyPath: ./certs/privkey.key

Diventa:

mart: serviceAccountPath: ./service-accounts/hybrid-project-apigee-mart.json connectAgent: serviceAccountPath: ./service-accounts/hybrid-project-apigee-mart.json

Esegui l'upgrade di Istio e di cert-manager

Apigee hybrid versione 1.3 richiede cert-manager v0.14.2 per gestire e verificare i certificati e la distribuzione Istio fornita con Anthos Service Mesh (ASM) versione 1.5.7 (o successiva) per creare e gestire il gateway in entrata di runtime.

Esegui l'upgrade di Istio 1.4.6 ad ASM 1.5.7 (o versioni successive)

Durante il processo di upgrade potrebbero verificarsi interruzioni del traffico. Per ridurre al minimo l'interruzione, assicurati che siano in esecuzione almeno due repliche di ogni componente (tranne Citadel).

Per ridurre al minimo i tempi di inattività, i deployment Istio e gli HPA devono avere almeno due repliche ciascuno. Esegui questi comandi per determinare il numero di repliche:
kubectl -n istio-system get deployments # list of deployments kubectl -n istio-system get hpa # list of hpa

Modifica ogni deployment che ha una sola replica e aumenta il valore replicas: a 2 o più:
kubectl -n istio-system edit deployment name

Ad esempio:

spec: progressDeadlineSeconds: 600 replicas: 2

Modifica ogni HPA che ha una sola replica e aumenta il valore minReplicas: a 2 o più:
kubectl -n istio-system edit hpa name

Ad esempio:

spec: maxReplicas: 5 minReplicas: 2

Scarica e installa ASM seguendo le istruzioni di installazione in Scaricare e installare ASM.

Dopo l'installazione, esegui il comando della versione per assicurarti che la versione 1.5.x sia installata correttamente:
./bin/istioctl version client version: 1.5.8-asm.0 apigee-mart-ingressgateway version: citadel version: 1.4.6 galley version: 1.4.6 ingressgateway version: 1.5.8-asm.0 pilot version: 1.4.6 policy version: 1.4.6 sidecar-injector version: 1.4.6 telemetry version: 1.4.6 pilot version: 1.5.8-asm.0 data plane version: 1.4.6 (1 proxies), 1.5.8-asm.0 (2 proxies)

Esegui l'upgrade di cert-manager

Apigee ibrido versione 1.3 richiede cert-manager versione 0.14.2. Puoi seguire le istruzioni complete sul sito di cert-manager per Eseguire l'upgrade dalla v0.13 alla v0.14. Di seguito sono riportati i passaggi necessari per il modello ibrido.

Elimina il deployment attuale di cert-manager:
kubectl delete -n cert-manager deployment cert-manager cert-manager-cainjector cert-manager-webhook

Verifica la tua versione di Kubernetes:
kubectl version

Esegui questo comando per installare cert-manager da Jetstack:
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.14.2/cert-manager.yaml

Installa il runtime ibrido

Memorizza il numero di versione più recente in una variabile:
export VERSION=$(curl -s \ https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/current-version.txt?ignoreCache=1)

Verifica che la variabile sia stata compilata con un numero di versione. Se vuoi utilizzare una versione diversa, salvala in una variabile di ambiente. Ad esempio:
echo $VERSION 1.3.6

Scarica il pacchetto di rilascio per il tuo sistema operativo:

Mac 64 bit:

curl -LO \ https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/$VERSION/apigeectl_mac_64.tar.gz

Linux a 64 bit:

curl -LO \ https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/$VERSION/apigeectl_linux_64.tar.gz

Mac 32 bit:

curl -LO \ https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/$VERSION/apigeectl_mac_32.tar.gz

Linux a 32 bit:

curl -LO \ https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/$VERSION/apigeectl_linux_32.tar.gz

Rinomina la directory apigeectl/ attuale in un nome di directory di backup. Ad esempio:
mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.2/

Estrai il contenuto del file gzip scaricato nella directory base ibrida. Ad esempio:
tar xvzf filename.tar.gz -C hybrid-base-directory

cd alla directory di base.

I contenuti tar vengono, per impostazione predefinita, espansi in una directory che contiene la versione e la piattaforma nel nome. Ad esempio: ./apigeectl_1.0.0-f7b96a8_linux_64. Rinomina la directory in apigeectl:

mv apigeectl_1.0.0-f7b96a8_linux_64 apigeectl

Elimina il job apigee-resources-install da apigee-system:
kubectl -n apigee-system delete job apigee-resources-install

Elimina il CRD precedente:
kubectl delete crd apigeetelemetries.apigee.cloud.google.com

Aggiorna la stanza cassandra: nel file di override con una proprietà externalSeedHost. Questa proprietà ti aiuterà a garantire che la tua nuova installazione ibrida versione 1.3.6 utilizzerà lo stesso cluster Kubernetes dell'installazione della versione 1.2. Questo passaggio una tantum è necessario solo per l'upgrade dalla versione ibrida 1.2 alla versione 1.3.6 (o successiva).

Trova uno degli indirizzi IP di Cassandra esistente nello stesso cluster Kubernetes in cui esegui l'upgrade dell'installazione 1.2.0.
kubectl -n namespace get pods -o wide

Dove namespace è lo spazio dei nomi ibrido di Apigee.

Prendi nota dell'indirizzo IP di un nodo Cassandra. Ad esempio:

kubectl -n apigee get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE apigee-cassandra-0 1/1 Running 0 33d 10.68.8.24 gke-example-cluster-rc5-apigee-data-c8bf1234-09kc apigee-cassandra-1 1/1 Running 0 16d 10.68.8.33 gke-example-cluster-rc5-apigee-data-c9221ee7-10kc apigee-cassandra-2 1/1 Running 0 23h 10.68.9.11 gke-example-cluster-rc5-apigee-data-d123e456-11kc

Aggiungi il valore per la proprietà externalSeedHost:
cassandra: externalSeedHost: Cassandra_node_IP

Dove Cassandra_node_IP è l'IP del nodo cassandra (10.68.8.24 nell'esempio precedente).

Nota: rimuoverai la proprietà externalSeedHost in un passaggio successivo, dopo che la nuova Cassandra sarà in esecuzione e verificata.

Nella nuova directory apigeectl/, esegui apigeectl init, apigeectl apply e apigeectl check-ready:

Inizializza l'ibrido 1.3.6:
apigeectl init -f overrides_1.3.yaml

Dove overrides_1.3.yaml si trova il file override.yaml modificato.

Nella versione ibrida 1.3, la sintassi del flag --dry-run dipende dalla versione di kubectl in esecuzione. Controlla la versione di kubectl:
gcloud version

Verifica la presenza di errori con una prova:
kubectl versione 1.17 e precedenti:

apigeectl apply -f overrides_1.3.yaml --dry-run=true

kubectl 1.18 e versioni successive:

apigeectl apply -f overrides_1.3.yaml --dry-run=client

Applica gli override. Seleziona e segui le istruzioni per gli ambienti di produzione o per gli ambienti demo/sperimentali, a seconda dell'installazione.
Durante il processo di upgrade, ogni componente eseguirà un riavvio in sequenza. Pertanto, per gli ambienti di produzione, è meglio applicare l'upgrade a un componente alla volta.

Produzione

Per gli ambienti di produzione, devi eseguire l'upgrade di ogni componente ibrido singolarmente e controllare lo stato del componente aggiornato prima di passare al componente successivo.

Applica gli override per eseguire l'upgrade di Cassandra:
apigeectl apply -f overrides_1.3.yaml --datastore

Completamento del controllo:
kubectl -n namespace get pods

Dove namespace è lo spazio dei nomi ibrido di Apigee.

Procedi al passaggio successivo solo quando i pod sono pronti.

Applica gli override per eseguire l'upgrade dei componenti di telemetria e controlla il completamento:
apigeectl apply -f overrides_1.3.yaml --telemetry

kubectl -n namespace get pods

Applica gli override per eseguire l'upgrade dei componenti a livello di organizzazione (MART, Watcher e Apigee Connect) e verifica il completamento:
apigeectl apply -f overrides_1.3.yaml --org

kubectl -n namespace get pods

Applica gli override per eseguire l'upgrade dei tuoi ambienti. Hai due possibilità:

Applica gli override a un ambiente alla volta e verifica il completamento. Ripeti questo passaggio per ogni ambiente:
apigeectl apply -f overrides_1.3.yaml --env env_name

kubectl -n namespace get pods

Dove env_name è il nome dell'ambiente di cui stai eseguendo l'upgrade.

Applica gli override a tutti gli ambienti contemporaneamente e controlla il completamento:
apigeectl apply -f overrides_1.3.yaml --all-envs

kubectl -n namespace get pods

Demo/sperimentale

Nella maggior parte degli ambienti dimostrativi o sperimentali, puoi applicare gli override a tutti i componenti contemporaneamente. Se il tuo ambiente demo/sperimentale è di grandi dimensioni e complesso o riproduce da vicino un ambiente di produzione, puoi utilizzare le istruzioni per l'upgrade degli ambienti di produzione

apigeectl apply -f overrides_1.3.yaml

Controlla lo stato:
apigeectl check-ready -f overrides_1.3.yaml

Per ulteriori istruzioni, consulta Configurazione di GKE Hybrid - Passaggio 5: installazione di ibrido su GKE.

Una volta avviata la configurazione di ibrido 1.3 e in esecuzione, verifica che tutti i nodi Cassandra (vecchi e nuovi) facciano parte dello stesso cluster Cassandra. Esegui questo comando su uno dei nodi Cassandra:
kubectl -n namespace get pods kubectl -n namespace exec old Cassandra pod -- nodetool status

Nell'output di esempio seguente, 10.68.8.24 proviene dalla versione 1.2.0 ed è l'IP del nodo utilizzato come externalSeedHost. 10.68.7.11 è dalla versione 1.3.6:

Datacenter: dc-1 ================ Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.68.8.24 379.41 KiB 256 50.8% 11bbd43b-af64-464b-a96d-0d6dd0521de1 ra-1 UN 10.68.7.11 1.35 MiB 256 49.2% 0b4d9e08-f353-413a-b4a9-7d18a8d07e58 ra-1

Se non si trovano nello stesso cluster, controlla il valore di externalSeedHost.

Quando tutti i pod sono in esecuzione, rimuovi externalSeedHost dal file di override ed esegui di nuovo apigeectl apply con l'opzione --datastore:
apigeectl apply --datastore -f overrides_1.3.6.yaml

Esegui la pulizia

Dopo aver verificato che tutti i pod sono integri e integri e che gli endpoint ASM siano validi per la nuova installazione, puoi eseguire la pulizia:

Risorse ibride 1.2.

L'istanza Cassandra precedente

Risorse Istio 1.4.6.

Eliminazione risorse ibride 1.2.0

Nota: questa procedura richiede il comando apigeectl versione 1.2 nella directory di cui è stato eseguito il backup. Se devi scaricare un'altra copia di apigeectl versione 1.2, puoi utilizzare il seguente comando:
curl -LO \ https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/1.2.0/apigeectl_your_system.tar.gz

Dove your_system è uno dei seguenti: linux_32, linux_64, mac_32 o mac_64.

Rimuovi i dettagli del routing virtualhost 1.2.0:
$APIGEECTL_HOME-v1.2/apigeectl delete -s virtualhost -f 1.2.0_overrides.yaml

Dove $APIGEECTL_HOME-v1.2 è la directory in cui hai eseguito il backup della directory apigeectl versione 1.2.

Se l'endpoint funziona ancora come previsto e hai verificato che tutti i componenti della versione 1.3.0 funzionino, esegui questo comando per eliminare le risorse ibride:
$APIGEECTL_HOME-v1.2/apigeectl delete -c "mart,connect-agent,synchronizer,runtime,udca,metrics,logger" \ -f 1.2.0_overrides.yaml

Ritira la vecchia istanza Cassandra

cd nella directory apigeectl appena installata.

Esegui lo script tools/cas_cleanup.sh.
Questo script disattiva il vecchio pod Cassandra dall'anello Cassandra, elimina il vecchio STS ed elimina le PVC.

bash cas_cleanup.sh Apigee namespace

Elimina risorse Istio versione 1.4.6

Nota: l'eliminazione delle risorse Istio versione 1.4.6 comporta anche l'eliminazione del traffico in entrata MART. Il traffico MART in entrata viene sostituito con Apigee Connect nella versione ibrida di Apigee 1.3.

Esegui questo comando per eliminare le risorse Istio v.1.4.6 più recenti:
kubectl delete all -n istio-system --selector \ 'app in (apigee-mart-istio-ingressgateway, galley, security, istio-nodeagent, istio-mixer, sidecarInjectorWebhook, istio-mixer)'

Esegui i comandi seguenti per eliminare i job meno recenti dall'installazione di Istio 1.4.6:
kubectl -n istio-system delete job istio-init-crd-10-1.4.6 kubectl -n istio-system delete job istio-init-crd-11-1.4.6 kubectl -n istio-system delete job istio-init-crd-14-1.4.6

Complimenti! Hai eseguito l'upgrade alla versione ibrida di Apigee 1.3.6.

Upgrade di Apigee hybrid alla versione 1.3.6

Panoramica dell'upgrade alla versione 1.3.6.

Prerequisiti

preparazione

Fai clic per visualizzare un esempio di utilizzo dei gruppi di ambienti per sostituire routingRules

Esegui l'upgrade di Istio e di cert-manager

Esegui l'upgrade di Istio 1.4.6 ad ASM 1.5.7 (o versioni successive)

Esegui l'upgrade di cert-manager

Installa il runtime ibrido

Produzione

Demo/sperimentale

Esegui la pulizia

Eliminazione risorse ibride 1.2.0

Ritira la vecchia istanza Cassandra

Elimina risorse Istio versione 1.4.6

Fai clic per visualizzare un esempio di utilizzo dei gruppi di ambienti per sostituire `routingRules`